I think the advantages of having these functions available in QtCore/Gui outweighs the risk of customers accidentally using platform-dependent code. Maintenance will be easier since there is less code duplication.
Morten On Sep 2, 2013, at 11:38 PM, Joseph Crowell <joseph.w.crow...@gmail.com> wrote: > Most of the functionality was already in Qt 4 and was moved out for Qt 5 > because of maintenance issues and different code for different platforms > exposed to the customer. > > On 02/09/2013 10:35 PM, Sorvig Morten wrote: >> 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 <jake.petrou...@petroules.com> >> wrote: >> >>> +1 from me for doing it everywhere, including in the library names. >>> -- >>> Jake Petroules >>> Chief Technology Officer >>> Petroules Corporation · www.petroules.com >>> Email: jake.petrou...@petroules.com >>> >>> On Aug 30, 2013, at 9:17 AM, Nurmi J-P <jpnu...@digia.com> 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 >>>> 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 >> _______________________________________________ >> 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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
