Yes yes a thousand times yes!
On 9/3/13 14:41 , Sorvig Morten wrote: > 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 <[email protected]> > 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 <[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 >> >> _______________________________________________ >> 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
