I agree the "Extra" looks superfluous. In fact I'd like to go a bit further and suggest we don't have platform extras at all and instead integrate the functionality into Qt:
- Conversion functions for types in QtCore to QtCore - Conversion functions for types in QtGui to QtGui - Widgets to QtWidgets - Non-trivial implementation to the platform plugin - etc. I've prepared a set of patches showing how (for parts of QtMacExtras): https://codereview.qt-project.org/64342 https://codereview.qt-project.org/64343 https://codereview.qt-project.org/64344 https://codereview.qt-project.org/64345 https://codereview.qt-project.org/64346 Notes: - The platform extras will continue to exist as research playgrounds. - This approach works for platforms that has an Q_OS #define - The function header is named "qmacfunctions.h", the namespace is "QMac" - We can now use the public NSString conversion functions in QtCore when implementing rest of Qt. - Conversion functions in QtCore And Gui can be used without bringing in QtMacExtras and its widgets dependency One case is still unsolved: classes that wrap native UI elements but are neither widgets nor Qt Quick Items. (Mac native tool bar and windows task bar for example). A possible solution could be to add the implementation to the platform plugin and add public API in QtWidgets and Qt Quick Controls. QMacNativeWidget and QMacCocoaViewContainer are done this way now, and are basically API wrappers around the implementation in QCococaWindow. Morten On Aug 30, 2013, at 3:27 PM, Jake Petroules <[email protected]> wrote: > +1 from me for doing it everywhere, including in the library names. > -- > Jake Petroules > Chief Technology Officer > Petroules Corporation · www.petroules.com > Email: [email protected] > > On Aug 30, 2013, at 9:17 AM, Nurmi J-P <[email protected]> wrote: > >> Hi all, >> >> While we still have a chance to tweak things before releasing 5.2, I'd like >> to re-open the discussion about platform extras naming. >> >> Short version: >> >> Could we rename the QtMacExtras & QtWinExtras namespaces to just QtMac & >> QtWin? (QtX11Extras namespace doesn't exist, at least yet) >> >> Long version: >> >> The current status: >> >> - Classes: QPlatformFoo >> - QX11Info (*) >> - QMacNativeWidget, ... >> - QWinTaskbarButton, ... >> >> (*) The only thing in QtX11Extras - already released in Qt 5.1. >> >> - Stand-alone function namespaces: QtPlatformExtras::toType() >> - QtWinExtras::toHBITMAP(), ... >> - QtMacExtras::toCGImageRef(), ... >> >> >> I'm not entirely happy with how the current stand-alone function namespaces >> look in application code. I would find it prettier if we dropped the >> "Extras" part from the namespace names. IMHO that would still remain >> distinctive enough, just making it look more professional and... convenient >> to type. :) >> >> if (QtWinExtras::isCompositionEnabled()) >> // ... >> >> vs. >> >> if (QtWin::isCompositionEnabled()) >> // ... >> >> >> Open questions: >> - What about the headers? >> - Could #include <QtMacExtras/qmacfoo.h> also become <QtMac/qmacfoo.h>? >> - <QX11Extras/QX11Info> was already released - so it would have to remain >> as a compatibility header if we chose the latter >> >> - What about the lib names? Should we keep them intact? >> - QtWinExtras.dll vs. QtWin.dll, or QtMacExtras.framework vs. >> QtMac.framework is not necessarily an improvement >> - The lib names are IMHO not that important, because users rarely have to >> care. >> >> -- >> J-P Nurmi >> >> _______________________________________________ >> Development mailing list >> [email protected] >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
