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

Reply via email to