Ok, let's use QtWin for the namespace. For the module itself it makes IMO to keep the 'Extras' in the name.
Cheers, Lars On 06.09.13 15:52, "Sorvig Morten" <[email protected]> wrote: >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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
