[Development] Request for new Playground Repo

[Vladimir Minenko]

We actually have got a few more APIs which we would move to that
repository either right now, or later when it becomes an add-on. Some of
those APIs need to go under a review to sort our what would be the place
to put them in.

For now, we are asking for a home to start with.

Cheers!

--
Vladimir

On 20.11.13 23:47, "André Pönitz"
<andre.poenitz at mathematik.tu-chemnitz.de> wrote:

>On Wed, Nov 20, 2013 at 07:51:34PM +0000, Knoll Lars wrote:
>> On 20/11/13 20:36, "Andrew Wooster" <awooster at blackberry.com> wrote:
>> 
>> >Hi, I'd like to request the creation of a new playground repository.
>> >
>> >Name: BlackBerry Extras
>> >
>> >Description: A repository for creating BlackBerry specific APIs that
>>are
>> >useful for implementing Qt functionality.
>> >
>> >Let me know if there are any questions.
>> 
>> If the purpose is the same as the other QPlatformExtras modules, I¹m
>>happy
>> to add it.
>
>I am not.
>
>The general approach is wrong, for several reasons:
>
>1. Splitting the platform extras already on the module level means that
>everybody who wants to use some of the extras even buried behind #ifdef's
>somewhere deep in his code has to add platform specific conditional code
>like
>
>   !isEmpty(QT.x11extras.name) {
>        QT += x11extras
>        DEFINES += I_CAN_USE_X11EXTRAS
>    } else {
>        warning("x11extras module not found, ....")
>    }
>
>to his buildsystem(s), for each of the platforms he want to "fully"
>support. This is a maintanance burden not just for the buildsystem itself
>but also extends to conditional packaging/installation.
>
>2. The setup is inherently fragile as only part of the code is used, and
>part
>not even checked on a specific developer's machine at a time, bearing the
>risk of the classic "compile fix" or "CI" "ping pong".
>
>3. The approach does not scale as it does not offer a natural place for
>features that are not available on all platforms, but on more then one.
>Putting random sort-of-sharable code into qtbase is not a good alternative
>either.
>
>
>There is no perfect solution, but the further "down" the conditionals
>are in the code the less impact they have on all three aspects, and
>the more code can be shared between the "backends".
>
>Merging the platform into a single module with fat #ifdefs QT_OS_XYZ
>in the headers would already alleviate the problem on the build system
>level, and upwards (packaging...), while providing the same interface
>to the actual code. That'd be a uniform improvemnt over the current setup.
>
>Andre'
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.