Re: [Development] Qt Platform Extras
On 11 September 2013 01:07, Laszlo Papp lp...@kde.org wrote: On Tue, Sep 10, 2013 at 4:46 PM, Thiago Macieira thiago.macie...@intel.com wrote: On terça-feira, 10 de setembro de 2013 22:31:53, Sze Howe Koh wrote: On 10 September 2013 14:27, Knoll Lars lars.kn...@digia.com wrote: Ok, let's use QtWin for the namespace. For the module itself it makes IMO to keep the 'Extras' in the name. Cheers, Lars QtWin or QWin? QtWin, it's a namespace. I believe he is aware of that... I think, Sze please correct me if I am wrong, he just wanted to make sure because there was several emails last year about QFoo or QtFoo for the namespace, and it seemed that the suboptimal naming was chosen for other reasons. Laszlo is correct. Before Qt 5 was released, most public namespaces had the QFoo format -- QSsl, QDBus, QAudio, etc. A few had the QtFoo format -- QtMultimedia::MetaData (unreleased), QtMultimedia (unreleased), and QtConcurrent. I suggested making them uniform. [1] Lars said that he preferred QFoo - QtFoo, but that change was the much more intrusive one. Qt 5 was close to Beta 2 at the time, so he chose the lower-risk QtFoo - QFoo. [2] As of Qt 5.1, all public namespaces are QFoo, except Qt and QtConcurrent. Thiago blocked the latter on the basis that (i) development on that module has stopped, and (ii) QtConcurrent is quite different from all the other namespaces anyway. [3] With all that in mind, do we want QtWin or QWin? The benefit of QWin is consistency with existing conventions; the downside is having to wait till Qt 6 if we want to switch to the preferred QtFoo. QtWin has the benefit of introducing users to the preferred naming convention now (and a smaller list of namespace changes if/when the change occurs), at the cost of introducing more inconsistencies. I vote for QWin for consistency, and I'm not sure that an extra ':%s/QWin::/QtWin::/g' will make a difference to users if they're doing the same for all other namespaces in Qt 6. Regards, Sze-Howe [1] http://lists.qt-project.org/pipermail/development/2012-October/007421.html [2] http://lists.qt-project.org/pipermail/development/2012-October/007591.html [3] https://codereview.qt-project.org/#change,39375 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
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.sor...@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 jpnu...@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.ves...@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.crow...@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.petrou...@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.petrou...@petroules.com On Aug 30, 2013, at 9:17 AM, Nurmi J-P jpnu...@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
Re: [Development] Qt Platform Extras
On 10 September 2013 14:27, Knoll Lars lars.kn...@digia.com wrote: Ok, let's use QtWin for the namespace. For the module itself it makes IMO to keep the 'Extras' in the name. Cheers, Lars QtWin or QWin? Comparison with other namespaces: http://qt-project.org/wiki/Qt_5_Structure Earlier discussion on this topic: http://thread.gmane.org/gmane.comp.lib.qt.devel/7464/focus=7634 Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On terça-feira, 10 de setembro de 2013 22:31:53, Sze Howe Koh wrote: On 10 September 2013 14:27, Knoll Lars lars.kn...@digia.com wrote: Ok, let's use QtWin for the namespace. For the module itself it makes IMO to keep the 'Extras' in the name. Cheers, Lars QtWin or QWin? QtWin, it's a namespace. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Tue, Sep 10, 2013 at 4:46 PM, Thiago Macieira thiago.macie...@intel.comwrote: On terça-feira, 10 de setembro de 2013 22:31:53, Sze Howe Koh wrote: On 10 September 2013 14:27, Knoll Lars lars.kn...@digia.com wrote: Ok, let's use QtWin for the namespace. For the module itself it makes IMO to keep the 'Extras' in the name. Cheers, Lars QtWin or QWin? QtWin, it's a namespace. I believe he is aware of that... I think, Sze please correct me if I am wrong, he just wanted to make sure because there was several emails last year about QFoo or QtFoo for the namespace, and it seemed that the suboptimal naming was chosen for other reasons. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
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.ves...@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.crow...@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.petrou...@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.petrou...@petroules.com On Aug 30, 2013, at 9:17 AM, Nurmi J-P jpnu...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
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 jpnu...@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.ves...@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.crow...@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.petrou...@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.petrou...@petroules.com On Aug 30, 2013, at 9:17 AM, Nurmi J-P jpnu...@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 -
Re: [Development] Qt Platform Extras
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.crow...@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.petrou...@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.petrou...@petroules.com On Aug 30, 2013, at 9:17 AM, Nurmi J-P jpnu...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
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.crow...@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.petrou...@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.petrou...@petroules.com On Aug 30, 2013, at 9:17 AM, Nurmi J-P jpnu...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
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.petrou...@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.petrou...@petroules.com On Aug 30, 2013, at 9:17 AM, Nurmi J-P jpnu...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
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.petrou...@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.petrou...@petroules.com On Aug 30, 2013, at 9:17 AM, Nurmi J-P jpnu...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
+1 from me for doing it everywhere, including in the library names. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com On Aug 30, 2013, at 9:17 AM, Nurmi J-P jpnu...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Mar 4, 2013, at 8:13 AM, Samuel Rødal samuel.ro...@digia.com wrote: What about things such as offscreen platform plugins used for testing? Or what about a theoretical platform plugin that would stream rendering commands to somewhere else? Imagine running wayland clients on Mac or Windows for instance, with the server being a Linux machine. Or a platform plugin that lets you run your Qt applications inside Second Life. There might be these and other use cases on Windows and Mac in the future, so I wouldn't recommend going back to the Qt 4 way of thinking. I don't think this is a problem in practice since you can run against e.g. Wayland on on Mac and still link against ApplicationServices. Of course, the native conversion functions would be of little use then. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On 03/04/2013 01:08 PM, Sorvig Morten wrote: On Mar 4, 2013, at 8:13 AM, Samuel Rødal samuel.ro...@digia.com wrote: What about things such as offscreen platform plugins used for testing? Or what about a theoretical platform plugin that would stream rendering commands to somewhere else? Imagine running wayland clients on Mac or Windows for instance, with the server being a Linux machine. Or a platform plugin that lets you run your Qt applications inside Second Life. There might be these and other use cases on Windows and Mac in the future, so I wouldn't recommend going back to the Qt 4 way of thinking. I don't think this is a problem in practice since you can run against e.g. Wayland on on Mac and still link against ApplicationServices. Of course, the native conversion functions would be of little use then. True, so conversion to from plain structures such as CGRect etc is probably not a big deal. Let's however not expose any platform plugin implementation details in the QtCore / QtGui APIs. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On 3/4/13 13:16 , Samuel Rødal wrote: On 03/04/2013 01:08 PM, Sorvig Morten wrote: On Mar 4, 2013, at 8:13 AM, Samuel Rødal samuel.ro...@digia.com wrote: What about things such as offscreen platform plugins used for testing? Or what about a theoretical platform plugin that would stream rendering commands to somewhere else? Imagine running wayland clients on Mac or Windows for instance, with the server being a Linux machine. Or a platform plugin that lets you run your Qt applications inside Second Life. There might be these and other use cases on Windows and Mac in the future, so I wouldn't recommend going back to the Qt 4 way of thinking. I don't think this is a problem in practice since you can run against e.g. Wayland on on Mac and still link against ApplicationServices. Of course, the native conversion functions would be of little use then. True, so conversion to from plain structures such as CGRect etc is probably not a big deal. Let's however not expose any platform plugin implementation details in the QtCore / QtGui APIs. Agreed. Also, as a data point, QtCore already links to ApplicationServices. Tor Arne ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On 03/01/2013 11:22 AM, Friedemann Kleint wrote: Hi, I suppose it would not be a detriment. Where do you draw the line? Which platforms, what functions and types? Here are some candidate types for constructors and conversion operators... The thing to keep in mind is basically that the decision to remove the pixmap conversion functions was mainly motivated by the situation on Linux. With Qt 5, it is possible to run executables by the same build of Qt with different platform plugins (XCB/X11 or Wayland, for example). QtGui no longer links against libX11/libXCB and thus for example QPixmap::x11PictureHandle() can no longer be provided within #ifdefs in Qt 5. The situation on Mac and Windows is different, though, in that there is basically only one platform plugin (running Windows/Mac with Wayland is a slightly theoretical possibility). QtGui already links against the libraries that provide the image conversion functions and it is easily possible to provide the image conversion functions within #ifdef Q_OS_XX. What about things such as offscreen platform plugins used for testing? Or what about a theoretical platform plugin that would stream rendering commands to somewhere else? Imagine running wayland clients on Mac or Windows for instance, with the server being a Linux machine. Or a platform plugin that lets you run your Qt applications inside Second Life. There might be these and other use cases on Windows and Mac in the future, so I wouldn't recommend going back to the Qt 4 way of thinking. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Mar 1, 2013, at 8:27 AM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: Why are we discussing adding conversion operators from/to native objects in QtCore/QtGui? The methods that did so were removed in Qt 5 in order to increase modularity, why would we go the opposite direction again? The argument for would be along the lines of: We went too far in the name of modularity. Adding conversion operators to QtCore and QtGui makes it easier to mix Qt and native development. It makes Qt better. I'm positive to the idea myself, and so far I haven't seen really convincing arguments against. I don't think adjusting the course of Qt 5 is a big problem. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
I suppose it would not be a detriment. Where do you draw the line? Which platforms, what functions and types? Here are some candidate types for constructors and conversion operators on their corresponding Qt types, which I can think of off the top of my head: Windows: POINT RECT HICON HBITMAP Darwin (OS X + iOS): CGPoint CGSize CGRect NSPoint NSSize NSRect CGImageRef CIImage NSImage NSString and CFArrayRef/NSArray - QListT ? I'm not sure about other platforms/environments like X11, Wayland, or perhaps GNOME. Jake Petroules Petroules Corporation (www.petroules.com) Email: jake.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Mar 1, 2013, at 4:24 AM, Sorvig Morten morten.sor...@digia.com wrote: On Mar 1, 2013, at 8:27 AM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: Why are we discussing adding conversion operators from/to native objects in QtCore/QtGui? The methods that did so were removed in Qt 5 in order to increase modularity, why would we go the opposite direction again? The argument for would be along the lines of: We went too far in the name of modularity. Adding conversion operators to QtCore and QtGui makes it easier to mix Qt and native development. It makes Qt better. I'm positive to the idea myself, and so far I haven't seen really convincing arguments against. I don't think adjusting the course of Qt 5 is a big problem. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Mar 1, 2013, at 10:37 AM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: I suppose it would not be a detriment. Where do you draw the line? Which platforms, what functions and types? I would leave that decision to the platform maintainers. An initial minimal set would be good though, for example OS X/iOS and windows. Here are some candidate types for constructors and conversion operators on their corresponding Qt types, which I can think of off the top of my head: Windows: POINT RECT HICON HBITMAP Darwin (OS X + iOS): CGPoint CGSize CGRect NSPoint NSSize NSRect CGImageRef CIImage NSImage NSString and CFArrayRef/NSArray - QListT ? Seems like a good list to me. I would wait with the last one.. NSArray is really QListQVariant. I'm not sure about other platforms/environments like X11, Wayland, or perhaps GNOME. It does require a Q_OS define, so it might not make sense for those platforms. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Hi,
I suppose it would not be a detriment. Where do you draw the line?
Which platforms, what functions and types? Here are some candidate types
for constructors and conversion operators...
The thing to keep in mind is basically that the decision to remove the
pixmap conversion functions was mainly motivated by the situation on
Linux. With Qt 5, it is possible to run executables by the same build of
Qt with different platform plugins (XCB/X11 or Wayland, for example).
QtGui no longer links against libX11/libXCB and thus for example
QPixmap::x11PictureHandle() can no longer be provided within #ifdefs in
Qt 5.
The situation on Mac and Windows is different, though, in that there is
basically only one platform plugin (running Windows/Mac with Wayland is
a slightly theoretical possibility). QtGui already links against the
libraries that provide the image conversion functions and it is easily
possible to provide the image conversion functions within #ifdef Q_OS_XX.
The image conversion functions are now in the platform extras, and the
question is whether to bring them back and in which way. Pros are
customer convenience; cons are basically #ifdef clutter and hacks.
I personally think operators are too magic (except for the QRect stuff),
given that the conversions can potentially fail. From the QPA
perspective, we could introduce something like
void *QPixmap::toNativeFormat(enum Format {} ) const
which would then call #ifdefed code or into the platform backend.
Regards,
Friedemann
--
Friedemann Kleint
Digia, Qt
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On 2/25/13 17:12 , Joerg Bornemann wrote:
On 25/02/2013 16:27, Jake Thomas Petroules wrote:
I'd prefer Qt namespace with no platform indicators, i.e.:
Qt::toHICON
Qt::toHBITMAP
Qt::toCGImageRef
Qt::toNSString
I'm probably missing something obvious here, but why are these not with
the class that they convert from?
- conversion operator (or toFoo function if expensive)
- constructor (explicit if expensive)
If it's not an expensive conversion, it should just be:
class QRect
{
#if defined(Q_OS_MAC)
QRect(const CGRect rect);
operator CGRect() const;
#endif
};
So that I can write code like this:
someQtFunction(someCGRect);
someCocoaFunction(someQtRect);
Without having to wrap it in QRect::to/from -- or even worse, some sort
of global namespace for all to/from conversion functions.
tor arne
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Actually, I would like Qt Addons to live in a namespace, esp. for new ones. The namespace name ought the be the same as the module's name. This is really there to avoid name clashes with other parts of Qt. With a namespace, you have all the freedom you want on how to name methods inside. developers using the module can simply use a using declaration, and then won't have to worry about long names. Cheers, Lars On 2/25/13 12:03 PM, Joerg Bornemann joerg.bornem...@digia.com wrote: On 25/02/2013 09:35, Sorvig Morten wrote: - Stand-alone function namespace: * Qt::toPlatformType (³Qt::toWindowsHBITMAP². ³Qt::toMacCGImageRef²) -OR- * QPlatform::toType(³QWindows::toHBITMAP², QMac::toCGImageRef) I vote for the latter naming scheme. We should not simulate namespaces by cluttering the function names. Looking at the Windows example, it might be wise to call the platform namespaces QtPlatform, not QPlatform to make the namespace QtWindows and the class QWindow easier distinguishable. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Thu, Feb 28, 2013 at 2:08 PM, Knoll Lars lars.kn...@digia.com wrote: Actually, I would like Qt Addons to live in a namespace, esp. for new ones. The namespace name ought the be the same as the module's name. This is really there to avoid name clashes with other parts of Qt. With a namespace, you have all the freedom you want on how to name methods inside. developers using the module can simply use a using declaration, and then won't have to worry about long names. This recommendation seems to be more or less documented: http://qt-project.org/wiki/Creating-a-new-module-or-tool-for-Qt#03fa1e2be330cf40074c0a55dafe27c4 Laszlo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On quinta-feira, 28 de fevereiro de 2013 14.42.53, Tor Arne Vestbø wrote: I'm probably missing something obvious here, but why are these not with the class that they convert from? - conversion operator (or toFoo function if expensive) - constructor (explicit if expensive) Because we cannot assure that the library that contains the class in question is actually linking to the necessary libraries. This is the case on Mac OS X. QtGui does not link to ApplicationServices, so it does not have access to CGRect. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Feb 28, 2013, at 4:50 PM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 14.42.53, Tor Arne Vestbø wrote: I'm probably missing something obvious here, but why are these not with the class that they convert from? - conversion operator (or toFoo function if expensive) - constructor (explicit if expensive) Because we cannot assure that the library that contains the class in question is actually linking to the necessary libraries. This is the case on Mac OS X. QtGui does not link to ApplicationServices, so it does not have access to CGRect. Well, we can make QtGui link to ApplicationServices if needed - It already links to CoreFoundation. Why would it be a problem in practice? Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On quinta-feira, 28 de fevereiro de 2013 21.32.26, Sorvig Morten wrote: On Feb 28, 2013, at 4:50 PM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 14.42.53, Tor Arne Vestbø wrote: I'm probably missing something obvious here, but why are these not with the class that they convert from? - conversion operator (or toFoo function if expensive) - constructor (explicit if expensive) Because we cannot assure that the library that contains the class in question is actually linking to the necessary libraries. This is the case on Mac OS X. QtGui does not link to ApplicationServices, so it does not have access to CGRect. Well, we can make QtGui link to ApplicationServices if needed - It already links to CoreFoundation. Why would it be a problem in practice? Because we can't do the same for other architectures and windowing systems. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Mar 1, 2013, at 12:28 AM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 21.32.26, Sorvig Morten wrote: On Feb 28, 2013, at 4:50 PM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 14.42.53, Tor Arne Vestbø wrote: I'm probably missing something obvious here, but why are these not with the class that they convert from? - conversion operator (or toFoo function if expensive) - constructor (explicit if expensive) Because we cannot assure that the library that contains the class in question is actually linking to the necessary libraries. This is the case on Mac OS X. QtGui does not link to ApplicationServices, so it does not have access to CGRect. Well, we can make QtGui link to ApplicationServices if needed - It already links to CoreFoundation. Why would it be a problem in practice? Because we can't do the same for other architectures and windowing systems. Which ones? It seems reasonable to divide the platform set in two then: 1) The platform can guarantee the presence of certain libraries at runtime. QtCore and QtGui can contain conversion functions to native types. 2) It's uncertain what libraries you'll find. No conversion functions. In other words, optimize for the capabilities of each platform instead of using the lowest common denominator. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Why are we discussing adding conversion operators from/to native objects in QtCore/QtGui? The methods that did so were removed in Qt 5 in order to increase modularity, why would we go the opposite direction again? Jake Petroules Petroules Corporation (www.petroules.com) Email: jake.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Mar 1, 2013, at 2:21 AM, Sorvig Morten morten.sor...@digia.com wrote: On Mar 1, 2013, at 12:28 AM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 21.32.26, Sorvig Morten wrote: On Feb 28, 2013, at 4:50 PM, Thiago Macieira thiago.macie...@intel.com wrote: On quinta-feira, 28 de fevereiro de 2013 14.42.53, Tor Arne Vestbø wrote: I'm probably missing something obvious here, but why are these not with the class that they convert from? - conversion operator (or toFoo function if expensive) - constructor (explicit if expensive) Because we cannot assure that the library that contains the class in question is actually linking to the necessary libraries. This is the case on Mac OS X. QtGui does not link to ApplicationServices, so it does not have access to CGRect. Well, we can make QtGui link to ApplicationServices if needed - It already links to CoreFoundation. Why would it be a problem in practice? Because we can't do the same for other architectures and windowing systems. Which ones? It seems reasonable to divide the platform set in two then: 1) The platform can guarantee the presence of certain libraries at runtime. QtCore and QtGui can contain conversion functions to native types. 2) It's uncertain what libraries you'll find. No conversion functions. In other words, optimize for the capabilities of each platform instead of using the lowest common denominator. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Platform Extras
Hi, Getting ready for the 5.1 feature freeze, I think we should take some time unifying the structure and API of the platform extras modules. There has already been some private discussion on this topic, and this is an attempt at reaching a final consensus. I think it's important that these modules are as similar as possible. API: - Some classes and functions are named for Qt 4 compatbilty. These need to stay as is. * qt_mac_set_dock_menu(QMenu *) - Classes: QPlatformFoo (QMacNativeWidget, QX11Info) - Stand-alone function namespace: * Qt::toPlatformType (“Qt::toWindowsHBITMAP”. “Qt::toMacCGImageRef”) -OR- * QPlatform::toType(“QWindows::toHBITMAP”, QMac::toCGImageRef) Structure: - Filesystem structure: - src/ - examples/ - tests/ - Public header naming: * Cross-platform header: qplatformfoo.h (qmacunifiedtoolbar.h) * Platform-dependent header: qplatformfoo_platform.h (qx11info_x11.h) * Build a .so/dll/dylib/framework: QtMacExtras.framework, QtX11Extras.so * If Qt is built with widgets, then qplatformextras may depend on QtWidgets. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Hello, Don't forget about the documentation. Some links: http://qt-project.org/wiki/Category:Developing_Qt::Documentation http://qt-project.org/wiki/Qt5DocumentationProject Cheers, Jerome P. Documentation Engineer - Digia, Qt Fra: development-bounces+jerome.pasion=digia@qt-project.org [development-bounces+jerome.pasion=digia@qt-project.org] p#229; vegne av Sorvig Morten [morten.sor...@digia.com] Sendt: 25. februar 2013 09:35 To: development@qt-project.org Emne: [Development] Qt Platform Extras Hi, Getting ready for the 5.1 feature freeze, I think we should take some time unifying the structure and API of the platform extras modules. There has already been some private discussion on this topic, and this is an attempt at reaching a final consensus. I think it's important that these modules are as similar as possible. API: - Some classes and functions are named for Qt 4 compatbilty. These need to stay as is. * qt_mac_set_dock_menu(QMenu *) - Classes: QPlatformFoo (QMacNativeWidget, QX11Info) - Stand-alone function namespace: * Qt::toPlatformType (“Qt::toWindowsHBITMAP”. “Qt::toMacCGImageRef”) -OR- * QPlatform::toType(“QWindows::toHBITMAP”, QMac::toCGImageRef) Structure: - Filesystem structure: - src/ - examples/ - tests/ - Public header naming: * Cross-platform header: qplatformfoo.h (qmacunifiedtoolbar.h) * Platform-dependent header: qplatformfoo_platform.h (qx11info_x11.h) * Build a .so/dll/dylib/framework: QtMacExtras.framework, QtX11Extras.so * If Qt is built with widgets, then qplatformextras may depend on QtWidgets. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On 25/02/2013 09:35, Sorvig Morten wrote: - Stand-alone function namespace: * Qt::toPlatformType (“Qt::toWindowsHBITMAP”. “Qt::toMacCGImageRef”) -OR- * QPlatform::toType(“QWindows::toHBITMAP”, QMac::toCGImageRef) I vote for the latter naming scheme. We should not simulate namespaces by cluttering the function names. Looking at the Windows example, it might be wise to call the platform namespaces QtPlatform, not QPlatform to make the namespace QtWindows and the class QWindow easier distinguishable. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
I'd prefer Qt namespace with no platform indicators, i.e.: Qt::toHICON Qt::toHBITMAP Qt::toCGImageRef Qt::toNSString It's obvious to which platform each function belongs; there's no need to qualify it beyond necessary. If WinRT introduces an NSString class and OS X adds HBITMAPs only then should we think about adding the platform name to the function. :) Also, despite that qt_mac_set_dock_menu is around for backwards compatibility, how about we introduce a second name for it, like Qt::setDockMenu and deprecate the original or otherwise advise against its usage? Then we can both maintain compatibility and not force usage of a disgustingly named function. Jake Petroules Petroules Corporation (www.petroules.com) Email: jake.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Feb 25, 2013, at 6:03 AM, Joerg Bornemann joerg.bornem...@digia.com wrote: On 25/02/2013 09:35, Sorvig Morten wrote: - Stand-alone function namespace: * Qt::toPlatformType (“Qt::toWindowsHBITMAP”. “Qt::toMacCGImageRef”) -OR- * QPlatform::toType(“QWindows::toHBITMAP”, QMac::toCGImageRef) I vote for the latter naming scheme. We should not simulate namespaces by cluttering the function names. Looking at the Windows example, it might be wise to call the platform namespaces QtPlatform, not QPlatform to make the namespace QtWindows and the class QWindow easier distinguishable. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Why is that...? Jake Petroules Petroules Corporation (www.petroules.com) Email: jake.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Feb 25, 2013, at 11:12 AM, Joerg Bornemann joerg.bornem...@digia.com wrote: On 25/02/2013 16:27, Jake Thomas Petroules wrote: I'd prefer Qt namespace with no platform indicators, i.e.: Qt::toHICON Qt::toHBITMAP Qt::toCGImageRef Qt::toNSString It's obvious to which platform each function belongs; there's no need to qualify it beyond necessary. If WinRT introduces an NSString class and OS X adds HBITMAPs only then should we think about adding the platform name to the function. :) That means we're restricting ourselves to type conversion functions? A function that's potentially useful on more than one platform wouldn't be possible. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Monday, February 25, 2013 05:12:48 PM Joerg Bornemann wrote: On 25/02/2013 16:27, Jake Thomas Petroules wrote: I'd prefer Qt namespace with no platform indicators, i.e.: Qt::toHICON Qt::toHBITMAP Qt::toCGImageRef Qt::toNSString It's obvious to which platform each function belongs; there's no need to qualify it beyond necessary. If WinRT introduces an NSString class and OS X adds HBITMAPs only then should we think about adding the platform name to the function. :) That means we're restricting ourselves to type conversion functions? A function that's potentially useful on more than one platform wouldn't be possible. Why would a function that is potentially useful on more than one platform go to platform extras? Sascha ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On 25/02/2013 17:25, Sascha Cunz wrote: Why would a function that is potentially useful on more than one platform go to platform extras? Because it's working on native types (more than just one) and encoding all type names into the function name would be strange. The same function name could make sense on a different platform. Note that I'm talking about the function name, not the full signature. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Monday, February 25, 2013 05:50:06 PM Joerg Bornemann wrote: On 25/02/2013 17:25, Sascha Cunz wrote: Why would a function that is potentially useful on more than one platform go to platform extras? Because it's working on native types (more than just one) and encoding all type names into the function name would be strange. The same function name could make sense on a different platform. Note that I'm talking about the function name, not the full signature. Actually, i don't get this: If there is some feature that is reasonable to have on more than one platform, then Qt should probably abstract it with a Qt-ish API, right? That's at least how things worked for ages. In terms of Qt 5, this would probably result in an add on QtFooFeature, which is tagged as available for the platforms it works upon. If on the other hand there's a complex feature that is bound to one platform and it is not yet covered by a add on on it's own, this feature should be properly abstracted into a Qt-ish Api, too, right? Properly abstracted here refers to a class inside the add on's namespace. As far as i can see, this leaves two kinds of functions that could possibly become members of the Qt- or the addon's namespace: - Functions that extent the API of an already abstracted feature (i.e. QString or QImage) with platform specific code. These would provide platform specific additions to the feature itself. If there is one of them, they could as well go to a namespace; If it is foreseeable that their number will increase by time, they should probably go into a class; c.f. qt4's qt_mac_XXX stuff for unified toolbar support. - Functions that convert Qt objects into their native pendant. These don't introduce new features themselves. They just provide compatibility to additional features of the native platform. These usually don't overlap in signature. Sascha ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Hi Sascha, My point is that we cannot know whether we'll have to encode the platform in a function name again in the future, in which case we'll have functions with and without the platform in their name. Your point is that this won't ever happen. We can just avoid this risk of an inconsistent future API by using different namespaces. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
