I agree, QtWin::foo looks much better. We can rename the QtMacExtras namespace as well.
What about the module name itself? Would we still say "import QtWinExtras" and "#include <QtWinExtras/QWinFunctions>"? Morten On Sep 6, 2013, at 11:49 AM, Nurmi J-P <[email protected]> wrote: > I also very much like the idea of sticking the conversion functions right > into the respective classes in QtCore and QtGui. > > At least QtWinExtras still has lots of helper methods that do not fall into > this category, though. All that Windows specific window blurring, peeking, > colorization etc. stuff will remain in QtWinExtras, and I'd still prefer > QtWin as the namespace for those methods. > > So my original question still remains valid - can we rename the > QtPlatformExtras namespaces to QtPlatform? Friedemann already prepared the > first step for QtWinExtras: https://codereview.qt-project.org/#change,64803. > > -- > J-P Nurmi > > On Sep 4, 2013, at 2:35 PM, Tor Arne Vestbø <[email protected]> wrote: > >> 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 > > > _______________________________________________ > 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
