Re: [Development] important: upcoming rename of _qpa.h to _p.h
Not work for nmake install INSTALL_ROOT=..., missed 'qba' headers in QtGui. progressmanager_win.cpp Header QtGui/QPlatformNativeInterface is deprecated. Please include qpa/qplatformnativeinterface.h instead. ..\..\..\..\Qt5\qtbase\include\QtGui\QPlatformNativeInterface(8) : fatal error C1083: Cannot open include file: 'qpa/qplatformnativeinterface.h': No such file or directory NMAKE : fatal error U1077: 'D:\qpSOFT\DEVx86\bin\cl.EXE' : return code '0x2' Stop. NMAKE : fatal error U1077: 'D:\qpSOFT\DEVx86\bin\nmake.exe' : return code '0x2' 2012/5/9 Girish Ramakrishnan gir...@forwardbias.in On Tue, May 8, 2012 at 5:31 PM, Girish Ramakrishnan gir...@forwardbias.in wrote: On Tuesday, May 8, 2012, Girish Ramakrishnan gir...@forwardbias.in wrote: Hi, On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan gir...@forwardbias.in wrote: The change landed. For some reason, the ci is failing compile in all other modules. Works locally with shadow builds but not on CI. I am on it. Fix is integrating: https://codereview.qt-project.org/#change,25570. Sorry for blocking the CI. Girish Ci is unblocked. fixes for wayland, qtmm and declarative have landed. https://codereview.qt-project.org/#change,23444 is needed for complete source compat. That's the wrong change :) I meant https://codereview.qt-project.org/#change,25654 Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Please don't ask where I come from, It's a shame! Best Regards Yuchen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
AFAIK, Installing with INSTALL_ROOT is known not to work with Qt5's modular projects. BTW, does windows even support make install? Has it started supported it these days? Girish On Thu, May 10, 2012 at 5:02 PM, Loaden loa...@gmail.com wrote: Not work for nmake install INSTALL_ROOT=..., missed 'qba' headers in QtGui. progressmanager_win.cpp Header QtGui/QPlatformNativeInterface is deprecated. Please include qpa/qplatformnativeinterface.h instead. ..\..\..\..\Qt5\qtbase\include\QtGui\QPlatformNativeInterface(8) : fatal error C1083: Cannot open include file: 'qpa/qplatformnativeinterface.h': No such file or directory NMAKE : fatal error U1077: 'D:\qpSOFT\DEVx86\bin\cl.EXE' : return code '0x2' Stop. NMAKE : fatal error U1077: 'D:\qpSOFT\DEVx86\bin\nmake.exe' : return code '0x2' 2012/5/9 Girish Ramakrishnan gir...@forwardbias.in On Tue, May 8, 2012 at 5:31 PM, Girish Ramakrishnan gir...@forwardbias.in wrote: On Tuesday, May 8, 2012, Girish Ramakrishnan gir...@forwardbias.in wrote: Hi, On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan gir...@forwardbias.in wrote: The change landed. For some reason, the ci is failing compile in all other modules. Works locally with shadow builds but not on CI. I am on it. Fix is integrating: https://codereview.qt-project.org/#change,25570. Sorry for blocking the CI. Girish Ci is unblocked. fixes for wayland, qtmm and declarative have landed. https://codereview.qt-project.org/#change,23444 is needed for complete source compat. That's the wrong change :) I meant https://codereview.qt-project.org/#change,25654 Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Please don't ask where I come from, It's a shame! Best Regards Yuchen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
It has always supported it. It's just not used that much. -- Sent from my Nokia N9 On 5/11/12 3:50 ext Girish Ramakrishnan wrote: AFAIK, Installing with INSTALL_ROOT is known not to work with Qt5's modular projects. BTW, does windows even support make install? Has it started supported it these days? Girish On Thu, May 10, 2012 at 5:02 PM, Loaden loa...@gmail.com wrote: Not work for nmake install INSTALL_ROOT=..., missed 'qba' headers in QtGui. progressmanager_win.cpp Header QtGui/QPlatformNativeInterface is deprecated. Please include qpa/qplatformnativeinterface.h instead. ..\..\..\..\Qt5\qtbase\include\QtGui\QPlatformNativeInterface(8) : fatal error C1083: Cannot open include file: 'qpa/qplatformnativeinterface.h': No such file or directory NMAKE : fatal error U1077: 'D:\qpSOFT\DEVx86\bin\cl.EXE' : return code '0x2' Stop. NMAKE : fatal error U1077: 'D:\qpSOFT\DEVx86\bin\nmake.exe' : return code '0x2' 2012/5/9 Girish Ramakrishnan gir...@forwardbias.in On Tue, May 8, 2012 at 5:31 PM, Girish Ramakrishnan gir...@forwardbias.in wrote: On Tuesday, May 8, 2012, Girish Ramakrishnan gir...@forwardbias.in wrote: Hi, On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan gir...@forwardbias.in wrote: The change landed. For some reason, the ci is failing compile in all other modules. Works locally with shadow builds but not on CI. I am on it. Fix is integrating: https://codereview.qt-project.org/#change,25570. Sorry for blocking the CI. Girish Ci is unblocked. fixes for wayland, qtmm and declarative have landed. https://codereview.qt-project.org/#change,23444 is needed for complete source compat. That's the wrong change :) I meant https://codereview.qt-project.org/#change,25654 Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Please don't ask where I come from, It's a shame! Best Regards Yuchen ___ 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] important: upcoming rename of _qpa.h to _p.h
Girish Ramakrishnan said: Hi, On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan gir...@forwardbias.in wrote: The change landed. For some reason, the ci is failing compile in all other modules. Works locally with shadow builds but not on CI. I am on it. Fix is integrating: https://codereview.qt-project.org/#change,25570. Sorry for blocking the CI. Ideally this would have been caught by the reverse dependency qtdeclarative test in qtbase's CI, but apparently the issue only affected shadow builds, which weren't covered. We'll add a shadow build revdep-qtdeclarative config to prevent similar issues in the future. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Tuesday, May 8, 2012, Girish Ramakrishnan girish@gir...@forwardbias.in forwardbias.in gir...@forwardbias.in wrote: Hi, On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan girish@ gir...@forwardbias.inforwardbias.in gir...@forwardbias.in wrote: The change landed. For some reason, the ci is failing compile in all other modules. Works locally with shadow builds but not on CI. I am on it. Fix is integrating: https://https://codereview.qt-project.org/#change,25570 codereview.qt https://codereview.qt-project.org/#change,25570-https://codereview.qt-project.org/#change,25570 project.org https://codereview.qt-project.org/#change,25570/#change,25570https://codereview.qt-project.org/#change,25570 . Sorry for blocking the CI. Girish Ci is unblocked. fixes for wayland, qtmm and declarative have landed. https://codereview.qt-project.org/#change,23444 is needed for complete source compat. Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Tue, May 8, 2012 at 5:31 PM, Girish Ramakrishnan gir...@forwardbias.in wrote: On Tuesday, May 8, 2012, Girish Ramakrishnan gir...@forwardbias.in wrote: Hi, On Tue, May 8, 2012 at 3:07 AM, Girish Ramakrishnan gir...@forwardbias.in wrote: The change landed. For some reason, the ci is failing compile in all other modules. Works locally with shadow builds but not on CI. I am on it. Fix is integrating: https://codereview.qt-project.org/#change,25570. Sorry for blocking the CI. Girish Ci is unblocked. fixes for wayland, qtmm and declarative have landed. https://codereview.qt-project.org/#change,23444 is needed for complete source compat. That's the wrong change :) I meant https://codereview.qt-project.org/#change,25654 Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Thursday 19 April 2012 14:45:29 ext Girish Ramakrishnan wrote: Paul did say on irc this proposal sounds 'better', but I am not sure that means I have his +2. Is this any better? (read: compromise) At least it means that I am withdrawing my -1 :) - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On 04/18/2012 04:03 PM, ext Girish Ramakrishnan wrote: Hi, On Wed, Apr 18, 2012 at 3:28 AM, lars.kn...@nokia.com wrote: Still the QPA headers are sort of a different beast from private headers. While I don't want to promise anything on them yet (I think we might want to keep SC and BC for them in patch level releases), they are supposed to be used by third parties and supported. Our private headers are not supported. Fair enough. Can we agree that: 1. _qpa suffix serves no purpose. qplatform prefix already says that it's qpa specific. 2. We don't want the 'we mean it' header in the qpa files since these files are meant for third party plugin authors. Sounds good to me. Here's my opinion: Whatever 'new' convention we come up with will require educating the masses. The number of plugin authors can be counted, what 50? The number of Qt app developers are possibly in tens of thousands. We have to now teach these tens of thousands that whatever convention we come up with these qpa files is not for their use. I can count the number of plugin authors who work on QPA but not on Qt code itself to exactly two (that's the android and ios port, but for all I know they hack on Qt too). Agreed, the ideal is to hide this from application developers. Since there's been no proposal, here's an alternate proposal: 1. We drop _qpa completely. So, it would become qplatformbackingstore.h 2. We teach syncqt that qplatform* is special and we move them all to a special qpa/ directory. So, instead of #include QtGui/private/qplatformbackingstore.h, it will be #include QtGui/qpa/qplatformbackingstore.h Yeah, I can get behind using this type of include. A good reason why the _qpa.h suffix should be removed, as QtGui/qpa/qplatformbackingstore_qpa.h looks quite ugly. 3. We teach syncqt to create QtGui/QPA or #include QPA headers. (I think we need the latter since qpa headers are not restricted to gui) Not sure about the latter, it would include widget headers even for a platform plugin that might not want to link against widgets. Would QtGui/QPA and QtWidgets/QPA as separate includes be an option? 4. We teach the world that qpa is not meant for apps. 5. Add a more benign header pointing out the fact that these files are qpa files. 6. Rename the handle() to platformXXX() since it's easy to educate that anything that has platform in it is out of reach of app developers. Yep. What follows is an OT/rant and not relevant to the discussion as such: 'plugin' usually refers to things add capabilities to an existing thing. qpa plugins are not really plugins, they are the thing itself. Without qpa plugin, Qt doesn't do anything. That's not a plugin. It is well and truly a part of Qt. As opposed to codec plugins - Qt will run just fine without those codec plugins. I would argue that QPA plugins are very much implementation detail, they are not part of Qt API and we really do mean it that the headers can change any time (hence the 'we mean it' header). I fail to see why we want BC with QPA plugins. While this is a noble notion, I don't see any real benefit. QPA code are not plugins, it's Qt itself. The dynamic loading of QPA is an implementation detail/convenience. Good points. BC might not be that important, not sure Jeremy's scenario of binary only platform plugins will become an issue on platforms where people build their own Qt. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
Proposal sounds ok to me as well. If someone still has concerns, please speak up. Cheers, Lars On 4/20/12 9:02 AM, ext Samuel Rødal samuel.ro...@nokia.com wrote: On 04/18/2012 04:03 PM, ext Girish Ramakrishnan wrote: Hi, On Wed, Apr 18, 2012 at 3:28 AM, lars.kn...@nokia.com wrote: Still the QPA headers are sort of a different beast from private headers. While I don't want to promise anything on them yet (I think we might want to keep SC and BC for them in patch level releases), they are supposed to be used by third parties and supported. Our private headers are not supported. Fair enough. Can we agree that: 1. _qpa suffix serves no purpose. qplatform prefix already says that it's qpa specific. 2. We don't want the 'we mean it' header in the qpa files since these files are meant for third party plugin authors. Sounds good to me. Here's my opinion: Whatever 'new' convention we come up with will require educating the masses. The number of plugin authors can be counted, what 50? The number of Qt app developers are possibly in tens of thousands. We have to now teach these tens of thousands that whatever convention we come up with these qpa files is not for their use. I can count the number of plugin authors who work on QPA but not on Qt code itself to exactly two (that's the android and ios port, but for all I know they hack on Qt too). Agreed, the ideal is to hide this from application developers. Since there's been no proposal, here's an alternate proposal: 1. We drop _qpa completely. So, it would become qplatformbackingstore.h 2. We teach syncqt that qplatform* is special and we move them all to a special qpa/ directory. So, instead of #include QtGui/private/qplatformbackingstore.h, it will be #include QtGui/qpa/qplatformbackingstore.h Yeah, I can get behind using this type of include. A good reason why the _qpa.h suffix should be removed, as QtGui/qpa/qplatformbackingstore_qpa.h looks quite ugly. 3. We teach syncqt to create QtGui/QPA or #include QPA headers. (I think we need the latter since qpa headers are not restricted to gui) Not sure about the latter, it would include widget headers even for a platform plugin that might not want to link against widgets. Would QtGui/QPA and QtWidgets/QPA as separate includes be an option? 4. We teach the world that qpa is not meant for apps. 5. Add a more benign header pointing out the fact that these files are qpa files. 6. Rename the handle() to platformXXX() since it's easy to educate that anything that has platform in it is out of reach of app developers. Yep. What follows is an OT/rant and not relevant to the discussion as such: 'plugin' usually refers to things add capabilities to an existing thing. qpa plugins are not really plugins, they are the thing itself. Without qpa plugin, Qt doesn't do anything. That's not a plugin. It is well and truly a part of Qt. As opposed to codec plugins - Qt will run just fine without those codec plugins. I would argue that QPA plugins are very much implementation detail, they are not part of Qt API and we really do mean it that the headers can change any time (hence the 'we mean it' header). I fail to see why we want BC with QPA plugins. While this is a noble notion, I don't see any real benefit. QPA code are not plugins, it's Qt itself. The dynamic loading of QPA is an implementation detail/convenience. Good points. BC might not be that important, not sure Jeremy's scenario of binary only platform plugins will become an issue on platforms where people build their own Qt. -- Samuel ___ 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] important: upcoming rename of _qpa.h to _p.h
On Friday, April 20, 2012 07:35:39 lars.kn...@nokia.com wrote: Proposal sounds ok to me as well. If someone still has concerns, please speak up. I lost track of what the proposal currently is. Could it be restated? -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions 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] important: upcoming rename of _qpa.h to _p.h
2012/4/20 Stephen Kelly stephen.ke...@kdab.com: On Friday, April 20, 2012 07:35:39 lars.kn...@nokia.com wrote: Proposal sounds ok to me as well. If someone still has concerns, please speak up. I lost track of what the proposal currently is. Could it be restated? 1. We drop _qpa completely. So, it would become qplatformbackingstore.h 2. We teach syncqt that qplatform* is special and we move them all to a special qpa/ directory. So, instead of #include QtGui/private/qplatformbackingstore.h, it will be #include QtGui/qpa/qplatformbackingstore.h 3. We teach syncqt to create QtGui/QPA or #include QPA headers. (I think we need the latter since qpa headers are not restricted to gui) 4. We teach the world that qpa is not meant for apps. 5. Add a more benign header pointing out the fact that these files are qpa files. 6. Rename the handle() to platformXXX() since it's easy to educate that anything that has platform in it is out of reach of app developers. Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On quinta-feira, 19 de abril de 2012 05.45.29, Girish Ramakrishnan wrote: Hi Guys, On Wed, Apr 18, 2012 at 7:03 AM, Girish Ramakrishnan gir...@forwardbias.in wrote: Since there's been no proposal, here's an alternate proposal: 1. We drop _qpa completely. So, it would become qplatformbackingstore.h 2. We teach syncqt that qplatform* is special and we move them all to a special qpa/ directory. So, instead of #include QtGui/private/qplatformbackingstore.h, it will be #include QtGui/qpa/qplatformbackingstore.h 3. We teach syncqt to create QtGui/QPA or #include QPA headers. (I think we need the latter since qpa headers are not restricted to gui) 4. We teach the world that qpa is not meant for apps. 5. Add a more benign header pointing out the fact that these files are qpa files. 6. Rename the handle() to platformXXX() since it's easy to educate that anything that has platform in it is out of reach of app developers. Paul did say on irc this proposal sounds 'better', but I am not sure that means I have his +2. Is this any better? (read: compromise) How should I proceed? Go ahead. And good luck with syncqt. Don't forget qplatform can appear elsewhere (e.g., qplatformdefs.h) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden 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] important: upcoming rename of _qpa.h to _p.h
Hi, On Wed, Apr 18, 2012 at 3:28 AM, lars.kn...@nokia.com wrote: Still the QPA headers are sort of a different beast from private headers. While I don't want to promise anything on them yet (I think we might want to keep SC and BC for them in patch level releases), they are supposed to be used by third parties and supported. Our private headers are not supported. Fair enough. Can we agree that: 1. _qpa suffix serves no purpose. qplatform prefix already says that it's qpa specific. 2. We don't want the 'we mean it' header in the qpa files since these files are meant for third party plugin authors. Here's my opinion: Whatever 'new' convention we come up with will require educating the masses. The number of plugin authors can be counted, what 50? The number of Qt app developers are possibly in tens of thousands. We have to now teach these tens of thousands that whatever convention we come up with these qpa files is not for their use. I can count the number of plugin authors who work on QPA but not on Qt code itself to exactly two (that's the android and ios port, but for all I know they hack on Qt too). Since there's been no proposal, here's an alternate proposal: 1. We drop _qpa completely. So, it would become qplatformbackingstore.h 2. We teach syncqt that qplatform* is special and we move them all to a special qpa/ directory. So, instead of #include QtGui/private/qplatformbackingstore.h, it will be #include QtGui/qpa/qplatformbackingstore.h 3. We teach syncqt to create QtGui/QPA or #include QPA headers. (I think we need the latter since qpa headers are not restricted to gui) 4. We teach the world that qpa is not meant for apps. 5. Add a more benign header pointing out the fact that these files are qpa files. 6. Rename the handle() to platformXXX() since it's easy to educate that anything that has platform in it is out of reach of app developers. What follows is an OT/rant and not relevant to the discussion as such: 'plugin' usually refers to things add capabilities to an existing thing. qpa plugins are not really plugins, they are the thing itself. Without qpa plugin, Qt doesn't do anything. That's not a plugin. It is well and truly a part of Qt. As opposed to codec plugins - Qt will run just fine without those codec plugins. I would argue that QPA plugins are very much implementation detail, they are not part of Qt API and we really do mean it that the headers can change any time (hence the 'we mean it' header). I fail to see why we want BC with QPA plugins. While this is a noble notion, I don't see any real benefit. QPA code are not plugins, it's Qt itself. The dynamic loading of QPA is an implementation detail/convenience. Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
Hi, On 4/18/12 4:03 PM, ext Girish Ramakrishnan gir...@forwardbias.in wrote: Since there's been no proposal, here's an alternate proposal: 1. We drop _qpa completely. So, it would become qplatformbackingstore.h 2. We teach syncqt that qplatform* is special and we move them all to a special qpa/ directory. So, instead of #include QtGui/private/qplatformbackingstore.h, it will be #include QtGui/qpa/qplatformbackingstore.h 3. We teach syncqt to create QtGui/QPA or #include QPA headers. (I think we need the latter since qpa headers are not restricted to gui) 4. We teach the world that qpa is not meant for apps. 5. Add a more benign header pointing out the fact that these files are qpa files. 6. Rename the handle() to platformXXX() since it's easy to educate that anything that has platform in it is out of reach of app developers. Just for my mental state of mind: will these classes then be documented as normal classes, or \internal, or do we need something special for them still? Casper ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On 04/18/2012 04:03 PM, ext Girish Ramakrishnan wrote: Hi, ... What follows is an OT/rant and not relevant to the discussion as such: 'plugin' usually refers to things add capabilities to an existing thing. qpa plugins are not really plugins, they are the thing itself. Without qpa plugin, Qt doesn't do anything. That's not a plugin. It is well and truly a part of Qt. As opposed to codec plugins - Qt will run just fine without those codec plugins. I would argue that QPA plugins are very much implementation detail, they are not part of Qt API and we really do mean it that the headers can change any time (hence the 'we mean it' header). I fail to see why we want BC with QPA plugins. While this is a noble notion, I don't see any real benefit. QPA code are not plugins, it's Qt itself. The dynamic loading of QPA is an implementation detail/convenience. I think the word you're looking for is backend. QPA is a (partial) port of Qt, and dynamically loaded QPA modules implement a backend for the relevant portion. BC is relevant because the backend a particular system uses may not be available with upstream Qt, while the system may otherwise be compatible with a widely used and hence upstream build. I think of this as equivalent to a hardware vendor providing a binary-only Linux kernel module. If you have to wait for the vendor to provide the complete kernel, delivery of unrelated fixes and features suffer. That said, I suspect that most implementors of custom backends are going to be dealing with embedded devices where they will not want to support upstream builds or upgrades asynchronous to their release cycle. Offering a lengthy BC promise for this case doesn't have much value. Compatible patch level releases sound like a nice target if they don't involve excessive pain. Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
the current _qpa situation is legacy and makes working with the code more painful. It will never be less painful to address than right now and I am really glad you have undertaken this Kamikaze initiative on our behalf. I am also glad you are going through the code busy cleaning up these internal tendrils that are still draped everywhere as of the alpha release. You make the QPA internals sound like Shelob's lair. On Wed, Apr 18, 2012 at 12:54 PM, Girish Ramakrishnan gir...@forwardbias.in wrote: On Wed, Apr 18, 2012 at 12:36 PM, Richard Moore r...@kde.org wrote: On 18 April 2012 15:18, casper.vandonde...@nokia.com wrote: Just for my mental state of mind: will these classes then be documented as normal classes, or \internal, or do we need something special for them still? I'd say we still want something special for them. We want these classes to be documented somewhere (even if it's in a standalone set of docs) and \internal would hide them. I already added \group qpa (for grouping) and \preliminary (for subject to change) for all QPA classes. I added \internal only because most of the stuff is undocumented :-) As we add documentation, we can start removing the \internal tags. Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- --- °v° Donald Carr /(_)\ Vaguely Professional Penguin lover ^ ^ Cave canem, te necet lingendo Chasing my own tail; hate to see me leave, love to watch me go ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Tue, Apr 17, 2012 at 4:12 AM, Girish Ramakrishnan gir...@forwardbias.in wrote: 1. qtestlib ends up exposing qpa api and thus testcases might end up being binary incompatible - This should be fixed in AFAIK qtestlib doesn't promise binary compatibility (see e.g. http://qt.gitorious.org/qt/qtqa/commit/0a67286dcc3513880dbbb01a72596b1e08741fea/diffs) so I'm not sure if this actually needs fixing - but I'll leave that up to the folks working on testlib :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Tue, Apr 17, 2012 at 4:12 AM, Girish Ramakrishnan gir...@forwardbias.in wrote: 1. qtestlib ends up exposing qpa api and thus testcases might end up being binary incompatible - This should be fixed in AFAIK qtestlib doesn't promise binary compatibility (see e.g. http://qt.gitorious.org/qt/qtqa/commit/0a67286dcc3513880dbbb01a72596b1e08741fea/diffs) so I'm not sure if this actually needs fixing - but I'll leave that up to the folks working on testlib :) That's right, testlib isn't included in the BC promises (there's way too much code in testlib that gets inlined via macros and no use of Qt-style private classes), but should still maintain source-compatibility once 5.0.0 is out. That said, testlib shouldn't needlessly expose other private APIs, so it would be good to fix the issue with qpa properly. -- Jason McDonald QTestLib Maintainer ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote: As per the previous discuss, I renamed all the _qpa.h to _p.h with a couple of helper scripts I just added the following -1 comment on gerrit: I do not agree with this change. We have made a difference between public API and plugin API, and this is different from private implementation detail. The rest of the Lighthouse team are also skeptical. The main issue, as far as I can see, is documentation. This can be solved much in a much simpler way by using the \internal tag, as discussed earlier. There should also be a warning in the _qpa.h files, but it shouldn't be the don't even think of using this file warning from the _p.h file; these files are there for platform plugin authors to use. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
Hi Paul, On Tue, Apr 17, 2012 at 1:34 AM, Paul Olav Tvete paul.tv...@nokia.com wrote: On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote: As per the previous discuss, I renamed all the _qpa.h to _p.h with a couple of helper scripts I just added the following -1 comment on gerrit: I do not agree with this change. We have made a difference between public API and plugin API, and this is different from private implementation detail. The rest of the Lighthouse team are also skeptical. The main issue, as far as I can see, is documentation. This can be solved much in a much simpler way by using the \internal tag, as discussed earlier. There should also be a warning in the _qpa.h files, but it shouldn't be the don't even think of using this file warning from the _p.h file; these files are there for platform plugin authors to use. I marked them all as internal, preliminary and ingroup qpa for qdoc with a718a99438aaca7d4cd4379726a8e131d3c4bf89. I also added the 'we mean it' header (the one which you don't want) in 5369f506867532b039c7b2300d8319ff925b1434. I can change that header depending on the outcome of this discussion :) The current problems are: 1. _qpa.h ends up the QtGui master file. This means code completion in qt-creator. Since we have handle(), this means users will use these functions without thinking about the impact. 2. _qpa.h is now a new convention that end users need to be aware of. qdoc also creates the forwarding header #include ClassName for these files. What is the QPA team's suggestion to solve the above problems? (Fix syncqt, add pragmas to tell creator to stop processing them and/or educate people about _qpa headers? Do you guys also want people to develop plugins using creator? Do you guys even think the current state of affairs is not acceptable?). Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
Hi Marius, On Tue, Apr 17, 2012 at 4:03 AM, marius.storm-ol...@nokia.com wrote: On 17/04/2012 03:34, ext Paul Olav Tvete wrote: On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote: As per the previous discuss, I renamed all the _qpa.h to _p.h with a couple of helper scripts I just added the following -1 comment on gerrit: I do not agree with this change. We have made a difference between public API and plugin API, and this is different from private implementation detail. The rest of the Lighthouse team are also skeptical. The main issue, as far as I can see, is documentation. This can be solved much in a much simpler way by using the \internal tag, as discussed earlier. There should also be a warning in the _qpa.h files, but it shouldn't be the don't even think of using this file warning from the _p.h file; these files are there for platform plugin authors to use. Also remember that yes, we don't promise BC from 5.0.0, but at some point we would want the QPA api to stabilize at let it keep the same promise as the rest of Qt, don't we? At which point, we would have to rename the files again? This is how we have always done development in Qt. It starts out with _p.h and then becomes .h :) Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
-Original Message- From: ext Girish Ramakrishnan [mailto:gir...@forwardbias.in] On Tue, Apr 17, 2012 at 4:03 AM, marius.storm-ol...@nokia.com wrote: On 17/04/2012 03:34, ext Paul Olav Tvete wrote: On Tuesday 17 April 2012 03:57:16 ext Girish Ramakrishnan wrote: As per the previous discuss, I renamed all the _qpa.h to _p.h with a couple of helper scripts I just added the following -1 comment on gerrit: I do not agree with this change. We have made a difference between public API and plugin API, and this is different from private implementation detail. The rest of the Lighthouse team are also skeptical. The main issue, as far as I can see, is documentation. This can be solved much in a much simpler way by using the \internal tag, as discussed earlier. There should also be a warning in the _qpa.h files, but it shouldn't be the don't even think of using this file warning from the _p.h file; these files are there for platform plugin authors to use. Also remember that yes, we don't promise BC from 5.0.0, but at some point we would want the QPA api to stabilize at let it keep the same promise as the rest of Qt, don't we? At which point, we would have to rename the files again? This is how we have always done development in Qt. It starts out with _p.h and then becomes .h :) Well, that breaks SC for existing projects, which have been ok with the missing BC. So you want to improve by promising BC by breaking SC? -- .marius ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Tuesday, April 17, 2012 15:05:49 marius.storm-ol...@nokia.com wrote: Well, that breaks SC for existing projects, which have been ok with the missing BC. So you want to improve by promising BC by breaking SC? _p also means SC is not maintained. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions 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] important: upcoming rename of _qpa.h to _p.h
Yes, it does. And for the case of QPA, we have said that we don't want to promise BC, but we haven't said that we will go around breaking SC for every patch release. (And we shouldn't, since SC breakage uses quite a bit of resources on all parties, so avoid them if you can.) Like some others, I would prefer it to remain in non-private headers, while mark the QPA API with non-BC promise. IMO, in Qt 5.1 we should be able to promise BC on the QPA APIs too. -- .marius From: development-bounces+marius.storm-olsen=nokia@qt-project.org [mailto:development-bounces+marius.storm-olsen=nokia@qt-project.org] On Behalf Of ext Stephen Kelly Sent: Tuesday, April 17, 2012 10:27 AM To: development@qt-project.org Subject: Re: [Development] important: upcoming rename of _qpa.h to _p.h On Tuesday, April 17, 2012 15:05:49 marius.storm-ol...@nokia.commailto:marius.storm-ol...@nokia.com wrote: Well, that breaks SC for existing projects, which have been ok with the missing BC. So you want to improve by promising BC by breaking SC? _p also means SC is not maintained. Thanks, -- Stephen Kelly stephen.ke...@kdab.commailto:stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.comhttp://www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] important: upcoming rename of _qpa.h to _p.h
Hi, If you are a module maintainer, please check the patches below and provide comments. As per the previous discuss, I renamed all the _qpa.h to _p.h with a couple of helper scripts - one script renamed the files and another fixed the includes. Practically all the hardwork was done by my trusty i-7 :) I lost one the renaming scripts because of a git clean -dxf. The other scripts is below [2]. The scripts are not important since I have done most of the work already. There's no need to test anything now, let's just wait for api_changes to merge. Once api_changes is merged, I will rebase and fix any conflicts in the patches below. And then each module owner has to check if the below compiles well. The main reason for this mail is the size of the change itself and if there is any concern now is a good time to voice it. The patch is ~13000 lines: (tests, examples all compile and work) (qtbase) https://codereview.qt-project.org/#change,23443 (qtdeclarative) https://codereview.qt-project.org/#change,23444 (qtsystem - not compiled) https://codereview.qt-project.org/#change,23445 (qtwayland - not uncompiled) https://codereview.qt-project.org/23446 QtWebKit needs to have a small fix too. Girish # script is something like this # QtGui/QPlatformHeader # QPlatformHeader # QtGui/qplatformheader_qpa.h # qplatformheader_qpa.h # QtGui/private/qplatformheader_qpa_p.h # private/qplatformheader_qpa_p.h # inputcontext and evendispatcher are special.. for file in `find . -name *.h -or -name *.cpp`; do sed -i -e 's,#include \(QtGui/\)\?\(QPlatform.*\),#include QtGui/private/\L\2_p.h,g' \ -e 's,#include \(QtGui/\)\?\(QPlatform.*\),#include QtGui/private/\L\2_p.h,g' \ -e 's,#include \(QtGui/\|QtGui/private/\|private/\)\?\(qplatform.*\)_qpa\(.*\),#include QtGui/private/\2_p\3,g' \ -e 's,#include \(QtGui/\|QtGui/private/\|private/\)\?\(qplatform.*\)_qpa\(.*\),#include QtGui/private/\2_p\3,g' \ $file done ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] important: upcoming rename of _qpa.h to _p.h
On Mon, Apr 16, 2012 at 6:57 PM, Girish Ramakrishnan gir...@forwardbias.in wrote: Hi, If you are a module maintainer, please check the patches below and provide comments. As per the previous discuss, I renamed all the _qpa.h to _p.h with a couple of helper scripts - one script renamed the files and another fixed the includes. Practically all the hardwork was done by my trusty i-7 :) I lost one the renaming scripts because of a git clean -dxf. The other scripts is below [2]. The scripts are not important since I have done most of the work already. There's no need to test anything now, let's just wait for api_changes to merge. Once api_changes is merged, I will rebase and fix any conflicts in the patches below. And then each module owner has to check if the below compiles well. I forgot to mention the issues I found: 1. qtestlib ends up exposing qpa api and thus testcases might end up being binary incompatible - This should be fixed in https://codereview.qt-project.org/#change,23440 2. widgets/ contains some qplatform* files. They should probably be inside gui 3. src/platformsupport/inputcontext contains some qplatform* files. They should probably be called something else 4. qgeneric plugin has no reason to be in gui. Should probably move to platformsupport Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
