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.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Feb 25, 2013, at 6:03 AM, Joerg Bornemann <joerg.bornem...@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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development