[Development] Qt Platform Extras

Jake Thomas Petroules jake.petroules at petroules.com
Mon Feb 25 16:27:57 CET 2013


I'd prefer Qt namespace with no platform indicators, i.e.:

Qt::toHICON
Qt::toHBITMAP
Qt::toCGImageRef
Qt::toNSString

It's obvious to which platform each function belongs; there's no need to qualify it beyond necessary. If WinRT introduces an NSString class and OS X adds HBITMAPs only then should we think about adding the platform name to the function. :)

Also, despite that qt_mac_set_dock_menu is around for backwards compatibility, how about we introduce a second name for it, like Qt::setDockMenu and deprecate the original or otherwise advise against its usage? Then we can both maintain compatibility and not force usage of a disgustingly named function.

Jake Petroules
Petroules Corporation (www.petroules.com)
Email: jake.petroules at petroules.com
Telephone: +1 (970) 587-3821

On Feb 25, 2013, at 6:03 AM, Joerg Bornemann <joerg.bornemann at digia.com> wrote:

> On 25/02/2013 09:35, Sorvig Morten wrote:
> 
>>     - Stand-alone function namespace:
>>         * Qt::toPlatformType (“Qt::toWindowsHBITMAP”. “Qt::toMacCGImageRef”)
>> 	-OR-
>>         * QPlatform::toType(“QWindows::toHBITMAP”, "QMac::toCGImageRef")
> 
> I vote for the latter naming scheme. We should not simulate namespaces 
> by cluttering the function names.
> Looking at the Windows example, it might be wise to call the platform 
> namespaces QtPlatform, not QPlatform to make the namespace QtWindows and 
> the class QWindow easier distinguishable.
> 
> 
> BR,
> 
> Joerg
> 
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development




More information about the Development mailing list