[Development] Qt Platform Extras

Tue Sep 10 08:27:51 CEST 2013

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" <Morten.Sorvig at digia.com> 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 <jpnurmi at digia.com> 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ø <tor.arne.vestbo at digia.com>
>>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
>>>><joseph.w.crowell at 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.petroules at 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.petroules at petroules.com
>>>>>>> 
>>>>>>> On Aug 30, 2013, at 9:17 AM, Nurmi J-P <jpnurmi at 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 at qt-project.org
>>>>>>>> http://lists.qt-project.org/mailman/listinfo/development
>>>>>>> _______________________________________________
>>>>>>> Development mailing list
>>>>>>> Development at qt-project.org
>>>>>>> http://lists.qt-project.org/mailman/listinfo/development
>>>>>> _______________________________________________
>>>>>> Development mailing list
>>>>>> Development at qt-project.org
>>>>>> http://lists.qt-project.org/mailman/listinfo/development
>>>>> 
>>>>> _______________________________________________
>>>>> Development mailing list
>>>>> Development at qt-project.org
>>>>> http://lists.qt-project.org/mailman/listinfo/development
>>> _______________________________________________
>>> Development mailing list
>>> Development at qt-project.org
>>> http://lists.qt-project.org/mailman/listinfo/development
>> 
>> 
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
>_______________________________________________
>Development mailing list
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development