[Development] Qt Platform Extras

[Sascha Cunz]

On Monday, February 25, 2013 05:50:06 PM Joerg Bornemann wrote:
> On 25/02/2013 17:25, Sascha Cunz wrote:
> > Why would a function that is "potentially useful on more than one
> > platform" go to platform extras?
> 
> Because it's working on native types (more than just one) and encoding
> all type names into the function name would be strange. The same
> function name could make sense on a different platform. Note that I'm
> talking about the function name, not the full signature.

Actually, i don't get this:
If there is some feature that is reasonable to have on more than one platform, 
then Qt should probably abstract it with a Qt-ish API, right? That's at least 
how things worked for ages.
In terms of Qt 5, this would probably result in an add on QtFooFeature, which 
is tagged as available for the platforms it works upon.

If on the other hand there's a complex feature that is bound to one platform 
and it is not yet covered by a add on on it's own, this feature should be 
properly abstracted into a Qt-ish Api, too, right?
Properly abstracted here refers to a class inside the add on's namespace.

As far as i can see, this leaves two kinds of functions that could possibly 
become members of the "Qt"- or the addon's namespace:

- Functions that extent the API of an already abstracted feature (i.e. QString 
or QImage) with platform specific code. These would provide platform specific 
additions to the feature itself. If there is one of them, they could as well 
go to a namespace; If it is foreseeable that their number will increase by 
time, they should probably go into a class; c.f. qt4's qt_mac_XXX stuff for 
unified toolbar support.

- Functions that convert Qt objects into their native pendant. These don't 
introduce new "features" themselves. They just provide compatibility to 
additional features of the native platform. These usually don't overlap in 
signature.

Sascha