[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