Re: [Development] Proposal: Make QPen non-cosmetic by default
On Oct 12, 2012, at 6:31 PM, Tony Van Eerd tvane...@rim.com wrote: I think Windows also uses 0-width to mean the same thing. On the other hand, I worked on a drawing library that used sub-pixel lines. Via good anti-aliasing, A 0.5 width line, even if vertical/horizontal, would be drawn semi-transparent. A 0-width line would thus be invisible. Qt 4.8 and 5.0 are actually doing this when using the raster paint engine. The exception is that 0 jumps back to 1 due to the definition of QPen. Cheers, Lars -Original Message- From: development-bounces+tvaneerd=rim@qt-project.org [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf Of Samuel Rødal Sent: Friday, October 12, 2012 11:02 AM To: development@qt-project.org Subject: Re: [Development] Proposal: Make QPen non-cosmetic by default On 10/12/2012 03:17 PM, Uwe Rathmann wrote: On Fri, 12 Oct 2012 12:21:30 +, Bache-Wiig Jens wrote: After all what is the point of doing a major version unless we don't even allow ourselves to change broken defaults. There is nothing broken: it's a well defined API that behaves exactly like it is documented. Your suggestion is about modifying an illogical API. I don't know the reasons why the API was decided once the way it is - but it is so confusing, that I can't believe that it happened by accident ( being documented later ). My guess is that it was following some other system that did it this way. Originally a 0-width pen was the only way to get the cosmetic pen behavior. Later on setCosmetic() was added to be able to have any pen width be cosmetic. I guess the whole 0-width thing comes from X11, where 0 is a special value with the following documentation: Thin lines (zero line-width) are one-pixel-wide lines drawn using an unspecified, device-dependent algorithm. http://tronche.com/gui/x/xlib/GC/manipulating.html also contains this bit of documentation: A line-width of zero may differ from a line-width of one in which pixels are drawn. This permits the use of many manufacturers' line drawing hardware, which may run many times faster than the more precisely specified wide lines. In general, drawing a thin line will be faster than drawing a wide line of width one. However, because of their different drawing algorithms, thin lines may not mix well aesthetically with wide lines. If it is desirable to obtain precise and uniform results across all displays, a client should always use a line-width of one rather than a line-width of zero. So 0-width lines in X11 are not only implicitly cosmetic, but also have less strict guarantees when it comes to correctness, so that they can be optimized by custom hardware. I guess originally QPen simply mirrored this behavior, which is probably why as you noted 0-width pens are faster than 1-width pens with the X11 paint engine in 4.x. Still, I agree with Jens that the API of having 0-width pens and cosmetic pens as separate concepts is confusing. If we wanted something akin to the 0-width concept of X11 it should rather have been a render hint saying that it's acceptable for the application to get less accurate line drawing in exchange for better performance. I'm not sure how valid that use case is these days though. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ 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] Proposal: Make QPen non-cosmetic by default
On Oct 12, 2012, at 3:17 PM, Uwe Rathmann uwe.rathm...@tigertal.de wrote: On Fri, 12 Oct 2012 12:21:30 +, Bache-Wiig Jens wrote: After all what is the point of doing a major version unless we don't even allow ourselves to change broken defaults. There is nothing broken: it's a well defined API that behaves exactly like it is documented. Your suggestion is about modifying an illogical API. I don't know the reasons why the API was decided once the way it is - but it is so confusing, that I can't believe that it happened by accident ( being documented later ). My guess is that it was following some other system that did it this way. In the end it is about to decide if the improvement is it worth to introduce a hard to find incompatibility to the application world. As far as I understood Jens, the reason to change this would be to avoid lots of drawing issues with High-DPI support (for e.g. the new Macs). If this is the case, we'll get into some problems whether we change the default or not. If we don't change it, the developers will likely run into issues on computers with High-DPI displays. If we change it plotting apps such as Qwt will have different issues. Both types of problems are unfortunately difficult to find when testing (as you might not test all use cases). Changing this in a minor release is obviously not going to happen so its either now or never. Thought Qt 5.0 API is already frozen - but if you really want to do it now is indeed by far the best moment for changes like this one. It's now or never really. To collect pros and cons that I've heard so far: + Logical API (to make it really logical would probably also require to make 0 width pens invisible) + Better compatibility on High-DPI displays - Breaks plotting/graphing apps/libraries (Qwt) Do we have any other arguments? Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Andy Shaw for Approver
João Abecasis wrote: Hi, I'd like to nominate Andy Shaw for Approver status. Andy's history with Qt is longer than my own, having catered to commercial customers in Trolltech, Nokia and Digia. Looking over the main repositories, I count 150 commits in the 4.x public timeline. 31 so far in Qt 5's qtbase -- I did not look into other modules, but I'm sure I'd find commits from him scattered all over the place. It looks like the waiting period has passed. Mark ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Is overriding an existing virtual method 'BC' in Qt 4?
On Oct 11, 2012, at 5:37 PM, André Pönitz andre.poen...@mathematik.tu-chemnitz.de wrote: On Thu, Oct 11, 2012 at 11:48:26AM +, Sorvig Morten wrote: [...] In general, I think this is something we'll see again. Platforms change under our feet and we need to adapt. Apple and Microsoft do not put OS updates on hold because we are working on a major release. The fact that Qt often lags platform releases is a major point against using Qt and something we must get better at. A sensible solution is, in my opinion, to allow feature and API development in Qt 4 when the platform maintainers find it necessary. In case it matters, I fully agree. Even with the goal to encourage people to move from Qt 4 to Qt 5, backporting the easy parts makes sense to give them a kind of stepping stone before they actually jump. That is _if_ they jump. A part of the audience seems to be quite happy with 4.x nowadays. Forcing them to invest in an upgrade does not sound overly prudent, and neither does anything that might be interpreted as leaving them behind. I do agree as well for places where we need to keep up with changes in the underlying platforms. We should make sure Qt 4 users are not feeling like they are being left behind. At the same time we should be careful about what we add to 4.8.x, both to not destabilise it and to make sure most of our focus goes towards Qt 5. And to address Thiago's question: I'm against making further API additions to Qt 4 than what's strictly required to keep up with platform changes. Ie. let's not add any other new APIs into the 4.x series. Whether we then call it 4.8.5 or 4.9.0 is then a pure policy decision. Maybe it's generally time to reconsider the set of existing goals. Some of them are from a time when - let's put it politely - the circumstances were different. I would be surprised if an honest re-evaluation today would lead to the same priorities as a it did only a couple of months ago. Andre' PS: Before the shouting starts: I am all for getting Qt 5 out as soon as possible. I am _only_ saying that alienating Qt 4 users makes no sense. Not now, and very likely not for quite a while. Existing users are a benefit, not a burden. Yes, many things have changed over the last couple of months. I fully agree with you that there we need to do our best not to alienate any user of Qt (whichever version they are currently using). At the same time getting Qt 5 out should be the top priority for all of us. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Un-messifying Qt Quick
On Oct 10, 2012, at 10:03 PM, Thiago Macieira thiago.macie...@intel.com wrote: On quarta-feira, 10 de outubro de 2012 18.23.49, Knoll Lars wrote: I am against making QML2 a subdirectory of imports (ie. option a1). So either a separate directory, or we keep the QML 1 modules in a subdirectory. Both are ok for me. cf the layout proposal: lib/qt5/imports - Qt Quick 1.x imports, all lib/qt5/qml2 - Qt Quick 2.x imports, arch-depedent share/qt5/qml2- Qt Quick 2.x imports, arch-independent We don't need to implement the arch-independent support now. We can add it later with Qt 5.1. Yes, let's please leave it out for now. Note that I called it qml2 because it's based on the QML 2 engine. That means it would apply to Cascades code using QML 2, not just Qt Quick 2. Should we have the '2' in the name? We've avoided it other places as well so far. Another option would be to call the directory 'modules'. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Make QPen non-cosmetic by default
On 10/12/2012 08:18 PM, Uwe Rathmann wrote: Qt/Embedded is the platform where you find this type of widget most what usually means a combination of the weakest hardware and the slowest graphic path. Unfortunately the implementation of the subsurfaces concept is so very broken, that embedding OpenGL is no option. Hope that using QPainter in combination with the scene graph opens a way to a faster implementation with Qt 5. Could you elaborate on what you mean regarding the implementation of the subsurfaces concept? -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Andy Shaw for Approver
On Oct 15, 2012, at 9:39 AM, Mark Brand mabr...@mabrand.nl wrote: João Abecasis wrote: Hi, I'd like to nominate Andy Shaw for Approver status. Andy's history with Qt is longer than my own, having catered to commercial customers in Trolltech, Nokia and Digia. Looking over the main repositories, I count 150 commits in the 4.x public timeline. 31 so far in Qt 5's qtbase -- I did not look into other modules, but I'm sure I'd find commits from him scattered all over the place. It looks like the waiting period has passed. Indeed. Congratulations Andy! Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Behavior changes in Qt
On Oct 11, 2012, at 4:06 PM, BRM bm_witn...@yahoo.com wrote: How about opt-in (via configure or extra flags) until the next major release? I don't think doing the opt-in/opt-out/mandatory over several minor release would bode well for compatibility between minor releases, which is a big must. For example, I have some software that is still running on Qt 4.5.1 in production; and component is running on Qt 4.7.4. Yet I need the behaviors in the overlapping code to be the same; without having to worry about getting the compilations right in both cases. If I understand correctly you are compiling a shared code base against both Qt 4.5.1 and Qt 4.7.4? I agree that use case would be harder if there were significant changes between 4.5 and 4.7. There are still changes between them today though, in the sense that each bugfix usually comes with a change in behaviour. One solution is workarounds based on the Qt version. We are running Qt Creator against both Qt 4 and 5 using QT_VERSION #ifdefs for example. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Andy Shaw for Approver
On Oct 15, 2012, at 9:39 AM, Mark Brand mabr...@mabrand.nl wrote: João Abecasis wrote: Hi, I'd like to nominate Andy Shaw for Approver status. Andy's history with Qt is longer than my own, having catered to commercial customers in Trolltech, Nokia and Digia. Looking over the main repositories, I count 150 commits in the 4.x public timeline. 31 so far in Qt 5's qtbase -- I did not look into other modules, but I'm sure I'd find commits from him scattered all over the place. It looks like the waiting period has passed. Indeed. Congratulations Andy! Thanks everyone! Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 and dynamic meta object
Forwarding to qt-devel. The qt-qml mailing list should be closed. Renato Araujo wrote: Hi guys, I'm working to port a library based on qt4.8 and qtquick 1.1 to qt5 and qtquick 2.0. This library uses dynamic metaobject to export dynamic properties signals and slot. What this library does is override the metaObject() function to return a new custom metaobject. This use to work on qt4 as you can see on this example[1], but during my port to qt5 this stoped to work, I'm not sure whats happen but now the same code ported to qt5 [2] does not work as expected. Could someone help me on that, I'm afraid of that now qtquick check on static metaobject information, before query for any property value. This will make impossible to port the current code to work in the same way in qt5. [1] Qt4.8 example: https://github.com/renatofilho/qml4.git [2] Qt5.0 beta1 example: https://github.com/renatofilho/test-qml.git Thanks Renato ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving QtMobility to qt-project.org
+1 for this. Everyone is solving their own problems with QtMobility and if is becoming fragmented. Regards, Àngel El 15/10/12 10:24, Thomas McGuire escribió: Hi, I'd like to propose to move QtMobility to the qt-project.org. The main reason I am proposing this is that we (RIM + KDAB) right now have a fork of QtMobility living on Gitorious [1]. This fork contains backends for sensors and multimedia for the new BB10 mobile OS, and will likely gain support for NFC and Bluetooth as well. It contains some API additions too. In addition to BB10, the Mer project also has patches for QtMobility [2], and the Android port has a backend [3]. Lorn Potter is working on backporting sensor gestures to QtMobility [4]. As you can see, there is still interest in QtMobility. Having it on qt- project.org would potentially reduce the number of forks and patches that are around. At least we are committed to properly upstream all patches of the BB10 fork. There are multiple advantages of making qt-project.org the home for QtMobility. First of all, we'd gain a proper review process through Gerrit. The docs would live on qt-project.org as well, which is naturally the first place people look for documentation. Right now the documenation for the API additions for BB10 are hard to find, for example. In general, getting rid of a fork is almost always a good idea. Any objections to this? How can we make this happen? The first steps would be to set up Gerrit for QtMobility and make sure commits to Gerrit end up on Gitorious. After that, we'd upstream the BlackBerry backend and the new API via Gerrit and get rid of the forked repository. There is already documentation at [5]. Is that auto-generated from the Gitorious repository automatically? If so, there is nothing to do in that area, hopefully. Eventually, we'd create a new 1.3 release with the BlackBerry backend and the new API (or maybe a 2.0 release even). Any thoughts? Regards, Thomas [1] https://gitorious.org/+kdab-developers/qt-mobility/qnx-qt-mobility [2] http://gitweb.merproject.org/gitweb?p=mer-core/qt-mobility.git;a=summary [3] http://quickgit.kde.org/?p=android-qt-mobility.git [4] https://qt.gitorious.org/~lpotter/qt-mobility/lpotters-qt- mobility/commit/2fd397a87e567dad8c48e2d7c1d35050a569d160 [5] http://doc.qt.digia.com/qtmobility/index.html ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- 2ª edición Curso CFP Introducción a los microcontroladores ARM Cortex-M http://armcortexm.blogs.upv.es/ * Angel F. Perles Ivars Departament d'Informàtica de Sistemes i Computadors - DISCA Universitat Politècnica de València - E.U.Informàtica Cami de Vera s/n. 46022-Valencia Edifici 1G Despatx 2S-13 e-mail: aper...@disca.upv.es Telf.+34 963877007 Ext. 75775 Fax.+34 963877579 http://www.disca.upv.es/aperles ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 and dynamic meta object
Renato Araujo wrote: Hi guys, I'm working to port a library based on qt4.8 and qtquick 1.1 to qt5 and qtquick 2.0. This library uses dynamic metaobject to export dynamic properties signals and slot. What this library does is override the metaObject() function to return a new custom metaobject. This use to work on qt4 as you can see on this example[1], but during my port to qt5 this stoped to work, I'm not sure whats happen but now the same code ported to qt5 [2] does not work as expected. Could someone help me on that, I'm afraid of that now qtquick check on static metaobject information, before query for any property value. This will make impossible to port the current code to work in the same way in qt5. [1] Qt4.8 example: https://github.com/renatofilho/qml4.git [2] Qt5.0 beta1 example: https://github.com/renatofilho/test-qml.git The format of QMetaObject has change a lot in Qt5. You need to adapt to those changes. You need to re-generate the moc generated code with the new moc, and start again from there. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 and dynamic meta object
Renato Araujo wrote: Hi guys, I'm working to port a library based on qt4.8 and qtquick 1.1 to qt5 and qtquick 2.0. This library uses dynamic metaobject to export dynamic properties signals and slot. What this library does is override the metaObject() function to return a new custom metaobject. This use to work on qt4 as you can see on this example[1], but during my port to qt5 this stoped to work, I'm not sure whats happen but now the same code ported to qt5 [2] does not work as expected. Could someone help me on that, I'm afraid of that now qtquick check on static metaobject information, before query for any property value. This will make impossible to port the current code to work in the same way in qt5. [1] Qt4.8 example: https://github.com/renatofilho/qml4.git [2] Qt5.0 beta1 example: https://github.com/renatofilho/test-qml.git The format of QMetaObject has change a lot in Qt5. You need to adapt to those changes. You need to re-generate the moc generated code with the new moc, and start again from there. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving QtMobility to qt-project.org
I agree as well. I'll check if there's any legal issues in moving the code to the project, and then try to get it done as soon as possible. Cheers, Lars On Oct 15, 2012, at 11:46 AM, Angel Perles aper...@disca.upv.es wrote: +1 for this. Everyone is solving their own problems with QtMobility and if is becoming fragmented. Regards, Àngel El 15/10/12 10:24, Thomas McGuire escribió: Hi, I'd like to propose to move QtMobility to the qt-project.org. The main reason I am proposing this is that we (RIM + KDAB) right now have a fork of QtMobility living on Gitorious [1]. This fork contains backends for sensors and multimedia for the new BB10 mobile OS, and will likely gain support for NFC and Bluetooth as well. It contains some API additions too. In addition to BB10, the Mer project also has patches for QtMobility [2], and the Android port has a backend [3]. Lorn Potter is working on backporting sensor gestures to QtMobility [4]. As you can see, there is still interest in QtMobility. Having it on qt- project.org would potentially reduce the number of forks and patches that are around. At least we are committed to properly upstream all patches of the BB10 fork. There are multiple advantages of making qt-project.org the home for QtMobility. First of all, we'd gain a proper review process through Gerrit. The docs would live on qt-project.org as well, which is naturally the first place people look for documentation. Right now the documenation for the API additions for BB10 are hard to find, for example. In general, getting rid of a fork is almost always a good idea. Any objections to this? How can we make this happen? The first steps would be to set up Gerrit for QtMobility and make sure commits to Gerrit end up on Gitorious. After that, we'd upstream the BlackBerry backend and the new API via Gerrit and get rid of the forked repository. There is already documentation at [5]. Is that auto-generated from the Gitorious repository automatically? If so, there is nothing to do in that area, hopefully. Eventually, we'd create a new 1.3 release with the BlackBerry backend and the new API (or maybe a 2.0 release even). Any thoughts? Regards, Thomas [1] https://gitorious.org/+kdab-developers/qt-mobility/qnx-qt-mobility [2] http://gitweb.merproject.org/gitweb?p=mer-core/qt-mobility.git;a=summary [3] http://quickgit.kde.org/?p=android-qt-mobility.git [4] https://qt.gitorious.org/~lpotter/qt-mobility/lpotters-qt- mobility/commit/2fd397a87e567dad8c48e2d7c1d35050a569d160 [5] http://doc.qt.digia.com/qtmobility/index.html ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- 2ª edición Curso CFP Introducción a los microcontroladores ARM Cortex-M http://armcortexm.blogs.upv.es/ * Angel F. Perles Ivars Departament d'Informàtica de Sistemes i Computadors - DISCA Universitat Politècnica de València - E.U.Informàtica Cami de Vera s/n. 46022-Valencia Edifici 1G Despatx 2S-13 e-mail: aper...@disca.upv.es Telf.+34 963877007 Ext. 75775 Fax.+34 963877579 http://www.disca.upv.es/aperles ___ 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] Moving QtMobility to qt-project.org
Pardon my ignorance; before reading this I thought that QtMobility had been merged into Qt 5 as add-on modules. May I ask why functionality is still being kept duplicated? Sze-Howe On Mon, Oct 15, 2012 at 7:50 PM, Knoll Lars lars.kn...@digia.com wrote: I agree as well. I'll check if there's any legal issues in moving the code to the project, and then try to get it done as soon as possible. Cheers, Lars On Oct 15, 2012, at 11:46 AM, Angel Perles aper...@disca.upv.es wrote: +1 for this. Everyone is solving their own problems with QtMobility and if is becoming fragmented. Regards, Àngel El 15/10/12 10:24, Thomas McGuire escribió: Hi, I'd like to propose to move QtMobility to the qt-project.org. The main reason I am proposing this is that we (RIM + KDAB) right now have a fork of QtMobility living on Gitorious [1]. This fork contains backends for sensors and multimedia for the new BB10 mobile OS, and will likely gain support for NFC and Bluetooth as well. It contains some API additions too. In addition to BB10, the Mer project also has patches for QtMobility [2], and the Android port has a backend [3]. Lorn Potter is working on backporting sensor gestures to QtMobility [4]. As you can see, there is still interest in QtMobility. Having it on qt- project.org would potentially reduce the number of forks and patches that are around. At least we are committed to properly upstream all patches of the BB10 fork. There are multiple advantages of making qt-project.org the home for QtMobility. First of all, we'd gain a proper review process through Gerrit. The docs would live on qt-project.org as well, which is naturally the first place people look for documentation. Right now the documenation for the API additions for BB10 are hard to find, for example. In general, getting rid of a fork is almost always a good idea. Any objections to this? How can we make this happen? The first steps would be to set up Gerrit for QtMobility and make sure commits to Gerrit end up on Gitorious. After that, we'd upstream the BlackBerry backend and the new API via Gerrit and get rid of the forked repository. There is already documentation at [5]. Is that auto-generated from the Gitorious repository automatically? If so, there is nothing to do in that area, hopefully. Eventually, we'd create a new 1.3 release with the BlackBerry backend and the new API (or maybe a 2.0 release even). Any thoughts? Regards, Thomas [1] https://gitorious.org/+kdab-developers/qt-mobility/qnx-qt-mobility [2] http://gitweb.merproject.org/gitweb?p=mer-core/qt-mobility.git;a=summary [3] http://quickgit.kde.org/?p=android-qt-mobility.git [4] https://qt.gitorious.org/~lpotter/qt-mobility/lpotters-qt- mobility/commit/2fd397a87e567dad8c48e2d7c1d35050a569d160 [5] http://doc.qt.digia.com/qtmobility/index.html -- 2ª edición Curso CFP Introducción a los microcontroladores ARM Cortex-M http://armcortexm.blogs.upv.es/ * Angel F. Perles Ivars Departament d'Informàtica de Sistemes i Computadors - DISCA Universitat Politècnica de València - E.U.Informàtica Cami de Vera s/n. 46022-Valencia Edifici 1G Despatx 2S-13 e-mail: aper...@disca.upv.es Telf.+34 963877007 Ext. 75775 Fax.+34 963877579 http://www.disca.upv.es/aperles ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Moving QtMobility to qt-project.org
On 10/15/2012 10:21 PM, Sze Howe Koh wrote: Pardon my ignorance; before reading this I thought that QtMobility had been merged into Qt 5 as add-on modules. May I ask why functionality is still being kept duplicated? So did I, as well as QtMultimediaKit now being renamed to QtMultimedia and made an essentials model. Sze-Howe On Mon, Oct 15, 2012 at 7:50 PM, Knoll Lars lars.kn...@digia.com mailto:lars.kn...@digia.com wrote: I agree as well. I'll check if there's any legal issues in moving the code to the project, and then try to get it done as soon as possible. Cheers, Lars On Oct 15, 2012, at 11:46 AM, Angel Perles aper...@disca.upv.es mailto:aper...@disca.upv.es wrote: +1 for this. Everyone is solving their own problems with QtMobility and if is becoming fragmented. Regards, Àngel El 15/10/12 10:24, Thomas McGuire escribió: Hi, I'd like to propose to move QtMobility to the qt-project.org http://qt-project.org. The main reason I am proposing this is that we (RIM + KDAB) right now have a fork of QtMobility living on Gitorious [1]. This fork contains backends for sensors and multimedia for the new BB10 mobile OS, and will likely gain support for NFC and Bluetooth as well. It contains some API additions too. In addition to BB10, the Mer project also has patches for QtMobility [2], and the Android port has a backend [3]. Lorn Potter is working on backporting sensor gestures to QtMobility [4]. As you can see, there is still interest in QtMobility. Having it on qt- project.org http://project.org would potentially reduce the number of forks and patches that are around. At least we are committed to properly upstream all patches of the BB10 fork. There are multiple advantages of making qt-project.org http://qt-project.org the home for QtMobility. First of all, we'd gain a proper review process through Gerrit. The docs would live on qt-project.org http://qt-project.org as well, which is naturally the first place people look for documentation. Right now the documenation for the API additions for BB10 are hard to find, for example. In general, getting rid of a fork is almost always a good idea. Any objections to this? How can we make this happen? The first steps would be to set up Gerrit for QtMobility and make sure commits to Gerrit end up on Gitorious. After that, we'd upstream the BlackBerry backend and the new API via Gerrit and get rid of the forked repository. There is already documentation at [5]. Is that auto-generated from the Gitorious repository automatically? If so, there is nothing to do in that area, hopefully. Eventually, we'd create a new 1.3 release with the BlackBerry backend and the new API (or maybe a 2.0 release even). Any thoughts? Regards, Thomas [1] https://gitorious.org/+kdab-developers/qt-mobility/qnx-qt-mobility [2] http://gitweb.merproject.org/gitweb?p=mer-core/qt-mobility.git;a=summary [3] http://quickgit.kde.org/?p=android-qt-mobility.git [4] https://qt.gitorious.org/~lpotter/qt-mobility/lpotters-qt- https://qt.gitorious.org/%7Elpotter/qt-mobility/lpotters-qt- mobility/commit/2fd397a87e567dad8c48e2d7c1d35050a569d160 [5] http://doc.qt.digia.com/qtmobility/index.html -- 2ª edición Curso CFP Introducción a los microcontroladores ARM Cortex-M http://armcortexm.blogs.upv.es/ * Angel F. Perles Ivars Departament d'Informàtica de Sistemes i Computadors - DISCA Universitat Politècnica de València - E.U.Informàtica Cami de Vera s/n. 46022-Valencia Edifici 1G Despatx 2S-13 e-mail: aper...@disca.upv.es mailto:aper...@disca.upv.es Telf.+34 963877007 Ext. 75775 tel:%2B34%20963877007%20Ext.%2075775 Fax.+34 963877579 tel:%2B34%20963877579 http://www.disca.upv.es/aperles ___ 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] Moving QtMobility to qt-project.org
Hi, On Monday 15 October 2012 14:21:18 Sze Howe Koh wrote: Pardon my ignorance; before reading this I thought that QtMobility had been merged into Qt 5 as add-on modules. May I ask why functionality is still being kept duplicated? Right, all of qtmobility has been split up for Qt5, as different add-on modules like QtSensors and QtMultimedia. This is about bringing qtmobility, the Qt4 version, to qt-project.org. Regards, Thomas -- ** Qt Developer Conference: http://qtconference.kdab.com/ ** Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Deprecate the QThread::terminated() signal?
Discussion at https://codereview.qt-project.org/#patch,sidebyside,36806,5,src/corelib/thread/qthread.cpp Thiago: Shouldn't this say that it's undefined if the [terminated()] signal is emitted at all [upon forced termination]? Olivier: Then should we just remove that signal? (Because it is undefined if the program will not deadlock if one call terminate. If terminate() is called when the thread holds the QThread's internal mutex for example, or any other Qt mutex (there is so many), Or even user mutexes.) Is there any value in keeping a signal that is: - Only emitted after the program destabilises, and - Not even guaranteed to be emitted? Regards, Sze-Howe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecate the QThread::terminated() signal?
On Monday 15 October 2012 20:38:04 Sze Howe Koh wrote: Discussion at https://codereview.qt-project.org/#patch,sidebyside,36806,5,src/corelib/thre ad/qthread.cpp Thiago: Shouldn't this say that it's undefined if the [terminated()] signal is emitted at all [upon forced termination]? Olivier: Then should we just remove that signal? (Because it is undefined if the program will not deadlock if one call terminate. If terminate() is called when the thread holds the QThread's internal mutex for example, or any other Qt mutex (there is so many), Or even user mutexes.) Is there any value in keeping a signal that is: - Only emitted after the program destabilises, and - Not even guaranteed to be emitted? I even go as far as removing it. Source compatibility is not really broken since you will just get a runtime warning saying the signal don't exist. -- Olivier PS: sorry for the few last duplicate emails. Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Replacing Cleanlooks and Plastique
The main focus of Qt on the desktop is to provide a native look and feel on all platforms. Until now, Qt has come bundled with a few extra styles that were not used intentionally anywhere. Historically plastique was designed to blend with KDE 3.0 and cleanlooks in early Gnome environments. They have long since been replaced by Oxygen and GTK+ styles on these platforms but have been left in our repository for historical and compatibility reasons. We certainly don't need multiple non-native looks and feels included in every build of Qt so I think we should clean it up a bit now that we have the opportunity. For those that want a reminder on what the old styles look like, you can see them here: Plastique : http://i.imgur.com/JLuwo.png Cleanlooks: http://i.imgur.com/VrF05.png There are still a few use cases where including a non-native theme is useful. This can be on platforms that don't have a desktop environment or if an application wants to customise the colours of certain widgets. For that reason, I created a single new style dubbed Fusion that I propose could replace both of these two ageing themes. It was not designed to have a strong personality on its own, but rather be a simple and clean alternative to the styles it replaces. For a quick glance of what it looks like with a few different colour settings, you can have a look at the following screenshot: http://i.imgur.com/kn67x.png Code is available in https://codereview.qt-project.org/#change,34458 I expect it to have some more visual tweaks, but unless there are loud protests, I would like to have this change in before the next beta. The old styles will of course continue to be usable, but no longer bundled in qtbase itself. Jens ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Un-messifying Qt Quick
On segunda-feira, 15 de outubro de 2012 07.55.56, Knoll Lars wrote: Note that I called it qml2 because it's based on the QML 2 engine. That means it would apply to Cascades code using QML 2, not just Qt Quick 2. Should we have the '2' in the name? We've avoided it other places as well so far. Another option would be to call the directory 'modules'. We could call it simply qml, that's fine too. modules is way, way too generic. Or did you mean qmlmodules ? PS: I tried modifying QLibraryInfo to add the new path but I somehow broke qmake for some unknown reason... -- 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] Deprecate the QThread::terminated() signal?
On segunda-feira, 15 de outubro de 2012 14.53.39, Olivier Goffart wrote: Is there any value in keeping a signal that is: - Only emitted after the program destabilises, and - Not even guaranteed to be emitted? I even go as far as removing it. Source compatibility is not really broken since you will just get a runtime warning saying the signal don't exist. Agreed. The terminated signal works properly if and only if the thread terminates in synchronous termination mode and the cleanup handlers are run. If the thread is killed or terminated asynchronously, or if the handlers aren't run, all bets are lost. -- 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] Un-messifying Qt Quick
On segunda-feira, 15 de outubro de 2012 07.54.42, Thiago Macieira wrote: On segunda-feira, 15 de outubro de 2012 07.55.56, Knoll Lars wrote: Note that I called it qml2 because it's based on the QML 2 engine. That means it would apply to Cascades code using QML 2, not just Qt Quick 2. Should we have the '2' in the name? We've avoided it other places as well so far. Another option would be to call the directory 'modules'. We could call it simply qml, that's fine too. modules is way, way too generic. Or did you mean qmlmodules ? PS: I tried modifying QLibraryInfo to add the new path but I somehow broke qmake for some unknown reason... By the way, adding the QML2 path is what's holding the QtQuick1 un-messifying back. I have all the other changes already ready and uploaded to Gerrit. -- 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] Behavior changes in Qt
From: Sorvig Morten morten.sor...@digia.com Subject: Re: [Development] Behavior changes in Qt On Oct 11, 2012, at 4:06 PM, BRM bm_witn...@yahoo.com wrote: How about opt-in (via configure or extra flags) until the next major release? I don't think doing the opt-in/opt-out/mandatory over several minor release would bode well for compatibility between minor releases, which is a big must. For example, I have some software that is still running on Qt 4.5.1 in production; and component is running on Qt 4.7.4. Yet I need the behaviors in the overlapping code to be the same; without having to worry about getting the compilations right in both cases. If I understand correctly you are compiling a shared code base against both Qt 4.5.1 and Qt 4.7.4? I agree that use case would be harder if there were significant changes between 4.5 and 4.7. There are still changes between them today though, in the sense that each bugfix usually comes with a change in behaviour. Yes that is correct. I have a series of libraries that do things from networking to graphical interface to services. All of them need to run on well on Qt 4.5 and 4.7; I typically stay away from APIs that are newer than 4.5 to maintain compatibility. However, having something change under the hood of Qt that introduces a change in the existing APIs is not, IMHO, an option as it would break support for codebases like mine. One solution is workarounds based on the Qt version. We are running Qt Creator against both Qt 4 and 5 using QT_VERSION #ifdefs for example. That works for Qt4 to Qt5, but it would not work if you had something subtly fix an API under the hood in a way that you cannot detect with QT_VERSION. Having a configure option to opt-in for the fix makes it easy, but then you're not guaranteed the fix will be there for 3rd party provided versions. Likewise for opt-out. However, with opt-in, you can enable the support it you need it, and compatibility is much easier to maintain as you are compatible by default and if you need the fix you can apply it to your install. So I'd say it would need to be 'opt-in' only until a bigger release that makes it mandatory; KISS is a very good principle. In my case, would not apply the fix for the version I develop with and provide to customers. $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Un-messifying Qt Quick
On Oct 15, 2012, at 5:04 PM, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 15 de outubro de 2012 07.54.42, Thiago Macieira wrote: On segunda-feira, 15 de outubro de 2012 07.55.56, Knoll Lars wrote: Note that I called it qml2 because it's based on the QML 2 engine. That means it would apply to Cascades code using QML 2, not just Qt Quick 2. Should we have the '2' in the name? We've avoided it other places as well so far. Another option would be to call the directory 'modules'. We could call it simply qml, that's fine too. modules is way, way too generic. Or did you mean qmlmodules ? PS: I tried modifying QLibraryInfo to add the new path but I somehow broke qmake for some unknown reason... By the way, adding the QML2 path is what's holding the QtQuick1 un-messifying back. I have all the other changes already ready and uploaded to Gerrit. Let's go for qml then. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 file hierarchy
On Thursday, October 11, 2012 12:01:51 Oswald Buddenhagen wrote: fwiw, the default mkspec links would need to go to lib, too, obviously. Or the default mkspec should be removed entirely. The default can be hardcoded in qmake, or am I missing something? It wouldn't make sense to compile 3rd party code using a different mkspec than the one used to build Qt, right? 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 ** Qt Developer Conference: http://qtconference.kdab.com/ ** 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
[Development] FW: Digia and the comunity for Qt
Forwarding this from the marketing list. I think folks who commented on Blurring the lines between Qt-Project and Digia, but not subscribing to the Marketing list, might be interested in reading this. Cheers! -- Vladimir From: marketing-bounces+vminenko=rim@qt-project.org [mailto:marketing-bounces+vminenko=rim@qt-project.org] On Behalf Of Barrios Katherine Sent: 15 October 2012 13:20 To: market...@qt-project.org Cc: Yrvin Knut; Verma Gurudutt Subject: [Marketing] Digia and the comunity for Qt Hi all, I thought I would write a short note to let everyone know that, we at Digia, haven't forgotten about the community and definitely want to work together with you to help promote Qt. We have started a project to look for community moderators for our social media channels. Since we have an incredibly small marketing team compared to what Nokia had and no web community people, this will take some time, and we therefore, need your help. That said, as we are evaluating all the channels, unfinished projects, projects in the works and more from what we inherited from Nokia, we can't move as fast as we would want. Please note that we don't want to in any way make the Qt channels and promotions, Digia only. This is a misconception and has never been the intent. Let's continue the conversation on how to promote Qt together via this Qt Project marketing mailing list. Thanks and regards, Katherine Digia, Qt - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 file hierarchy
On Mon, Oct 15, 2012 at 06:03:46PM +0200, Stephen Kelly wrote: On Thursday, October 11, 2012 12:01:51 Oswald Buddenhagen wrote: fwiw, the default mkspec links would need to go to lib, too, obviously. Or the default mkspec should be removed entirely. The default can be hardcoded in qmake, or am I missing something? It wouldn't make sense to compile 3rd party code using a different mkspec than the one used to build Qt, right? hmm, yeah, we could do that, indeed. just write the spec names out to qconfig.cpp, like the paths, etc. this would allow us to remove some obscure code which even deviates between platforms. the problem being that a lot of unix-based 3rd party build systems rely on the symlink's presence. but we'd break that if we move it to a different directory anyway. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork: using system proxy by default
Apparently not, I don't know why Microsoft implemented it this way.
The result is only cached if a PAC script is successfully downloaded.
The DHCP method doesn't serve the PAC url together with the IP address, it's a
separate query sent to the DHCP server by the browser (or us)
If autodetection fails, it returns no proxy for this request, but tries
autodetection again next time the API is called.
The autodetection procedure looks like this pseudocode (but is all one API call
to us):
for(tries=0;tries2;tries++) {
send(DHCP_INFORM requesting option 252);
if (wait_for_response(6 seconds)) {
pac_url = response;
break;
}
}
if(!pac_url) {
pac_url = http://wpad/wpad.dat;;
}
When using the windows API, we can enable either DNS, DHCP or both.
Using DNS only would be faster, but may not work for some users if their office
network used DHCP only deployment.
Also, I checked today and it looks like Chromium have now implemented DHCP
autodetection by themselves as well. They are checking it on startup caching
the results.
From: Knoll Lars [lars.kn...@digia.com]
Sent: 15 October 2012 16:00
To: Kearns, Shane
Cc: development@qt-project.org
Subject: Re: [Development] QtNetwork: using system proxy by default
Hi Shane,
(adding the ML back in again…)
wouldn't Windows run the DHCP detection only once at startup (or when network
status changes) and cache the result? Why would we need to re-run this inside
the Qt app?
Cheers,
Lars
On Oct 15, 2012, at 4:00 PM, shane.kea...@accenture.com wrote:
Hi Lars,
It happens the first time only (because we have a workaround to disable
autodetection if it fails)
When I reproduced it, it was 12 seconds.
The problem is windows sends a DHCP packet with a microsoft extension, and
has a long timeout waiting for a reply.
With good DHCP servers, they'll reply (negatively if they don't support that
extension)
With bad DHCP servers, there is no reply which triggers the problem.
It seems like some wireless access points/home routers have a bad or
incomplete DHCP implementation
I agree that enabling system proxy by default is what most app developers
would want.
An option would be to always disable DHCP detection, which gets rid of this
worst case.
From: Knoll Lars [lars.kn...@digia.com]
Sent: 15 October 2012 08:39
To: Kearns, Shane
Subject: Re: [Development] QtNetwork: using system proxy by default
I'd agree with Simon that #4 would be the best default option from a user
experience point of view. Most likely it's also what most app developers want.
Is the windows problem purely something happening once when initiating the
first connection, or does it happen with every connection? And what does this
mean in a real use case (ie. how many seconds are we talking about)?
Cheers,
Lars
On Oct 11, 2012, at 4:34 PM, shane.kea...@accenture.com wrote:
IMHO #4 gives the best out-of-the-box experience.
Is there a way to do the blocking winapi call in a thread on app start-
up maybe?
Doesn't help if the first thing an application wants to do is download
something from the network.
It would only help because of the workaround we already have to disable WPAD
if it fails (which is not ideal if you start an app at home, then take your
laptop to work)
How do other apps (i.e. Chrome) handle this without blocking the user
experience?
Chrome doesn't use the windows API, they make a request to http://wpad; and
interpret the pac script themselves.
Firefox is slow to load pages, but UI is not blocked (which points to using
the windows API in a thread)
WPAD is inherently spoofable, but the Chrome method is worse than the
windows API, as you can't tell if the name came from DNS or multicast name
resolution.
In any case, we don't have a javascript interpreter available at the
QtNetwork level.
Subject to local law, communications with Accenture and its affiliates
including telephone calls and emails (including content), may be monitored
by our systems for the purposes of security and the assessment of internal
compliance with Accenture policy.
__
www.accenture.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any
other use of the e-mail by you is prohibited.
Where allowed by local law, electronic communications with Accenture and its
affiliates, including e-mail and instant messaging (including content), may
be scanned by our systems for the purposes of information security and
Re: [Development] Replacing Cleanlooks and Plastique
Hi, On Monday 15 October 2012 15:56:23 Bache-Wiig Jens wrote: The main focus of Qt on the desktop is to provide a native look and feel on all platforms. Until now, Qt has come bundled with a few extra styles that were not used intentionally anywhere. Historically plastique was designed to blend with KDE 3.0 and cleanlooks in early Gnome environments. They have long since been replaced by Oxygen and GTK+ styles on these platforms but have been left in our repository for historical and compatibility reasons. We certainly don't need multiple non-native looks and feels included in every build of Qt so I think we should clean it up a bit now that we have the opportunity. Those are not obsolete. They still ship with KDE 4, it just uses Oxygen by default. So I wouldn't call then non-native, just less common. Call me a hopeless case, but the first thing I do on a fresh KDE is changing the style to one of those two because I find them more visually aiding than Oxygen (they have better contrast and are less flashy). There are still a few use cases where including a non-native theme is useful. This can be on platforms that don't have a desktop environment or if an application wants to customise the colours of certain widgets. Changing color is not the only reason to change the style. There are other subtle differences - e.g. Cleanlooks displays labels on menu separators and looks almost completely native on Windows (I use it for exactly those reasons in one of my applications). If I just wanted to change colors, I'd use a style sheet. I expect it to have some more visual tweaks, but unless there are loud protests, I would like to have this change in before the next beta. Does this count as loud protest? Konrad 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] Replacing Cleanlooks and Plastique
On Monday 15 October 2012 18:35:01 Konrad Rosenbaum wrote: Hi, On Monday 15 October 2012 15:56:23 Bache-Wiig Jens wrote: The main focus of Qt on the desktop is to provide a native look and feel on all platforms. Until now, Qt has come bundled with a few extra styles that were not used intentionally anywhere. Historically plastique was designed to blend with KDE 3.0 and cleanlooks in early Gnome environments. They have long since been replaced by Oxygen and GTK+ styles on these platforms but have been left in our repository for historical and compatibility reasons. We certainly don't need multiple non-native looks and feels included in every build of Qt so I think we should clean it up a bit now that we have the opportunity. Those are not obsolete. They still ship with KDE 4, it just uses Oxygen by default. So I wouldn't call then non-native, just less common. Call me a hopeless case, but the first thing I do on a fresh KDE is changing the style to one of those two because I find them more visually aiding than Oxygen (they have better contrast and are less flashy). +1 here There are still a few use cases where including a non-native theme is useful. This can be on platforms that don't have a desktop environment or if an application wants to customise the colours of certain widgets. Changing color is not the only reason to change the style. There are other subtle differences - e.g. Cleanlooks displays labels on menu separators and looks almost completely native on Windows (I use it for exactly those reasons in one of my applications). Same for me but using plastique in one of my applications - with _many_ addons. If I just wanted to change colors, I'd use a style sheet. I expect it to have some more visual tweaks, but unless there are loud protests, I would like to have this change in before the next beta. Does this count as loud protest? ++PROTEST Frank ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replacing Cleanlooks and Plastique
On 15/10/12 18:44, Frank Hemer wrote: On Monday 15 October 2012 18:35:01 Konrad Rosenbaum wrote: Hi, On Monday 15 October 2012 15:56:23 Bache-Wiig Jens wrote: The main focus of Qt on the desktop is to provide a native look and feel on all platforms. Until now, Qt has come bundled with a few extra styles that were not used intentionally anywhere. Historically plastique was designed to blend with KDE 3.0 and cleanlooks in early Gnome environments. They have long since been replaced by Oxygen and GTK+ styles on these platforms but have been left in our repository for historical and compatibility reasons. We certainly don't need multiple non-native looks and feels included in every build of Qt so I think we should clean it up a bit now that we have the opportunity. Those are not obsolete. They still ship with KDE 4, it just uses Oxygen by default. So I wouldn't call then non-native, just less common. Call me a hopeless case, but the first thing I do on a fresh KDE is changing the style to one of those two because I find them more visually aiding than Oxygen (they have better contrast and are less flashy). +1 here +1 here too There are still a few use cases where including a non-native theme is useful. This can be on platforms that don't have a desktop environment or if an application wants to customise the colours of certain widgets. Changing color is not the only reason to change the style. There are other subtle differences - e.g. Cleanlooks displays labels on menu separators and looks almost completely native on Windows (I use it for exactly those reasons in one of my applications). Same for me but using plastique in one of my applications - with _many_ addons. I use plastique too in my apps. If I just wanted to change colors, I'd use a style sheet. I expect it to have some more visual tweaks, but unless there are loud protests, I would like to have this change in before the next beta. Does this count as loud protest? ++PROTEST Frank ___ 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] Replacing Cleanlooks and Plastique
I'll fourth the motion! Grab your pitch forks and touches. Haydania-Capri Hummel Founder of Oscailt Foundation, Inc. It's what you make it; it's fate in your hands not ours... -Original Message- From: Frank Hemer fr...@hemer.org Sender: development-bounces+oscailt=oscailtfoundation.org...@qt-project.org Date: Mon, 15 Oct 2012 18:44:24 To: development@qt-project.org Reply-To: development@qt-project.org Subject: Re: [Development] Replacing Cleanlooks and Plastique On Monday 15 October 2012 18:35:01 Konrad Rosenbaum wrote: Hi, On Monday 15 October 2012 15:56:23 Bache-Wiig Jens wrote: The main focus of Qt on the desktop is to provide a native look and feel on all platforms. Until now, Qt has come bundled with a few extra styles that were not used intentionally anywhere. Historically plastique was designed to blend with KDE 3.0 and cleanlooks in early Gnome environments. They have long since been replaced by Oxygen and GTK+ styles on these platforms but have been left in our repository for historical and compatibility reasons. We certainly don't need multiple non-native looks and feels included in every build of Qt so I think we should clean it up a bit now that we have the opportunity. Those are not obsolete. They still ship with KDE 4, it just uses Oxygen by default. So I wouldn't call then non-native, just less common. Call me a hopeless case, but the first thing I do on a fresh KDE is changing the style to one of those two because I find them more visually aiding than Oxygen (they have better contrast and are less flashy). +1 here There are still a few use cases where including a non-native theme is useful. This can be on platforms that don't have a desktop environment or if an application wants to customise the colours of certain widgets. Changing color is not the only reason to change the style. There are other subtle differences - e.g. Cleanlooks displays labels on menu separators and looks almost completely native on Windows (I use it for exactly those reasons in one of my applications). Same for me but using plastique in one of my applications - with _many_ addons. If I just wanted to change colors, I'd use a style sheet. I expect it to have some more visual tweaks, but unless there are loud protests, I would like to have this change in before the next beta. Does this count as loud protest? ++PROTEST Frank ___ 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] Replacing Cleanlooks and Plastique
15.10.2012, 20:35, Konrad Rosenbaum kon...@silmor.de: Call me a hopeless case, but the first thing I do on a fresh KDE is changing the style to one of those two because I find them more visually aiding than Oxygen (they have better contrast and are less flashy). +1 -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replacing Cleanlooks and Plastique
On Monday 15 October 2012 18:47:44 Konstantin Tokarev wrote: 15.10.2012, 20:35, Konrad Rosenbaum kon...@silmor.de: Call me a hopeless case, but the first thing I do on a fresh KDE is changing the style to one of those two because I find them more visually aiding than Oxygen (they have better contrast and are less flashy). +1 I let my users decide, but personally I don't like Oxygen as well (due to the same reasons). So, count that as +1 ;)! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replacing Cleanlooks and Plastique
Call me a hopeless case, but the first thing I do on a fresh KDE is changing the style to one of those two because I find them more visually aiding than Oxygen (they have better contrast and are less flashy). +1 here +1 here too Before everyone rushes up to throw his/her protest on the table, I'd like to invite you take another look at the replacement proposal. I'm getting the feeling that people didn't even take a look at it before protesting the removal of cleanlooks plastique. The Fusion style: http://i.imgur.com/kn67x.png Do you really call that flashy? Don't let the colors fool you, it's just showing off the capabilities of the new fusion style and custom palettes. The idea is to unite cleanlooks plastique in order to reduce the maintenance burden and refresh the looks to make it look modern, not flashy bling bling. -- J-P Nurmi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Replacing Cleanlooks and Plastique
On 15/10/12 19:06, Nurmi J-P wrote: Call me a hopeless case, but the first thing I do on a fresh KDE is changing the style to one of those two because I find them more visually aiding than Oxygen (they have better contrast and are less flashy). +1 here +1 here too Before everyone rushes up to throw his/her protest on the table, I'd like to invite you take another look at the replacement proposal. I'm getting the feeling that people didn't even take a look at it before protesting the removal of cleanlooks plastique. The Fusion style: http://i.imgur.com/kn67x.png Do you really call that flashy? Don't let the colors fool you, it's just showing off the capabilities of the new fusion style and custom palettes. The idea is to unite cleanlooks plastique in order to reduce the maintenance burden and refresh the looks to make it look modern, not flashy bling bling. -- J-P Nurmi Actually i like the proposed style, i am not sure if it's better that Plastique but seems fine for me, the problem it's that with a new style we can have, for example, new bugs of stylesheets. I am not sure remove the actual working styles with the first release of Fusion it's a good idea. Regards, Miguel Angel. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 file hierarchy
On segunda-feira, 15 de outubro de 2012 18.24.25, Oswald Buddenhagen wrote: hmm, yeah, we could do that, indeed. just write the spec names out to qconfig.cpp, like the paths, etc. this would allow us to remove some obscure code which even deviates between platforms. the problem being that a lot of unix-based 3rd party build systems rely on the symlink's presence. but we'd break that if we move it to a different directory anyway. Considering that everyone has moved to a different directory for the past... oh, 15 years, I don't see the problem. It's /usr/lib64/qt4/mkspecs on the Fedora packages. -- 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] Un-messifying Qt Quick
On segunda-feira, 15 de outubro de 2012 15.42.34, Knoll Lars wrote: PS: I tried modifying QLibraryInfo to add the new path but I somehow broke qmake for some unknown reason... By the way, adding the QML2 path is what's holding the QtQuick1 un-messifying back. I have all the other changes already ready and uploaded to Gerrit. Let's go for qml then. Will do. I need help from Ossi to figure out how I broke qmake, because it's not evident. -- 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] Replacing Cleanlooks and Plastique
Actually i like the proposed style, i am not sure if it's better that Plastique but seems fine for me, the problem it's that with a new style we can have, for example, new bugs of stylesheets. I am not sure remove the actual working styles with the first release of Fusion it's a good idea. They must be removed from Qt 5.0. If not, the next chance is Qt 6.0. Naturally KDE or any application may still deploy them if desired. We are looking for options to provide them as easily integratable addons. They just wouldn't be part of the core distribution, and no longer actively maintained (unless someone steps up and volunteers to maintain the addon). -- J-P Nurmi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork: using system proxy by default
On segunda-feira, 15 de outubro de 2012 16.33.39, shane.kea...@accenture.com wrote: When using the windows API, we can enable either DNS, DHCP or both. Using DNS only would be faster, but may not work for some users if their office network used DHCP only deployment. Also, I checked today and it looks like Chromium have now implemented DHCP autodetection by themselves as well. They are checking it on startup caching the results. IIRC, DHCP requires binding to port 67 in order to send the request, which requires root privileges on Unix systems. That means we can't do it. I'd create a (wall-clock) timer and enable the DHCP resolution on Windows only once every 10 minutes. I'd also use it as a fallback if and only if the DNS resolution failed. The only drawback is that we'll insist on a bad, cached result if the user moves from a network with DHCP and no DNS, to a network with no autoproxy. We could cache the host's IP addresses and discard the cache if they have changed too. Since we'll do that only once every 10 minutes, the overhead will be minimal. -- 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] Replacing Cleanlooks and Plastique
I'm +1 on replacing Plastique and Cleanlooks styles in qtbase iff the replaced styles would remain accessible/usable as add-ons (or a single add-on, e.g. squashed with recently removed Motif and CDE styles). Konstantin 2012/10/15 Nurmi J-P jpnu...@digia.com: Actually i like the proposed style, i am not sure if it's better that Plastique but seems fine for me, the problem it's that with a new style we can have, for example, new bugs of stylesheets. I am not sure remove the actual working styles with the first release of Fusion it's a good idea. They must be removed from Qt 5.0. If not, the next chance is Qt 6.0. Naturally KDE or any application may still deploy them if desired. We are looking for options to provide them as easily integratable addons. They just wouldn't be part of the core distribution, and no longer actively maintained (unless someone steps up and volunteers to maintain the addon). -- 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] New branch in qtdoc for Qt 5.0 documentation brush-up (update)
Update to documentatin and branches. Fredag 5. oktober 2012 09.15.48 skrev Eskil Abrahamsen Blomfeldt: On 10/04/2012 05:21 PM, Stephen Kelly wrote: On Thursday, October 04, 2012 17:06:08 Eskil Abrahamsen Blomfeldt wrote: If you are working on changes to the qtdoc repository, could you please move it over to newdocs branch so we can minimize conflicts? Excuse my circular logic, but if everyone should commit to newdocs and no one should commit to master, let's delete the master branch entirely, rename newdocs to master and work there instead. That way, we we're done with this complicated branch issue before the newdocs branch was even created. In other words: Why create a branch at all? We had Tor Arne volunteering to make the build of the modularized documentation properly (awesome). He now spent some time fixing the build and voila, we will have properly modularized documentation that can do two pass runs and will work nicely for everyone (we hope ;) ). In order not to mess up the beta 2 docs completely (we don't know if we get done in time), we created a newdocs branch in every repo now. The plan is to update and fix all the overview documentation in these branches and getting rid of the modularized doc building left-overs. Instead we will have it properly working from toplevel qt5.git. Building docs = in the qt5.git repo (with the other modules checked out and configure run) run make docs Run make docs again to get all links right. Since this is pretty disruptive, we'll wait until the new documentation and the new way of building it is somewhat usable. In the mean time, if you want to work on overview docs (qdoc files, not inline documentation in the code), it would be great if you used the newdocs branches. Greetings Frederik This is most likely just poor communication on my part. The newdocs branch is a topic branch where we can break the current documentation without delaying the next beta. If you have changes that need to go into the beta, they can be put in the master branch and we will deal with any potential conflicts when they appear, but if they do not, and especially if you are participating in the Qt 5 documentation clean-up, it would be great if you could commit to newdocs so we working against the same version of the code. The main conflicts we're worried about now is work on pages that are deleted in the new structure for instance or duplicate work, which would become much more visible if everyone working to make the Qt 5 documentation great are on the same branch. The branch will go away and be merged into master once its contents are considered usable, so this is in no way meant to be a permanent solution. Hopefully that will not take too long. Thanks, Eskil ___ 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] New branch in qtdoc for Qt 5.0 documentation brush-up (update)
Update to documentatin and branches. Fredag 5. oktober 2012 09.15.48 skrev Eskil Abrahamsen Blomfeldt: On 10/04/2012 05:21 PM, Stephen Kelly wrote: On Thursday, October 04, 2012 17:06:08 Eskil Abrahamsen Blomfeldt wrote: If you are working on changes to the qtdoc repository, could you please move it over to newdocs branch so we can minimize conflicts? Excuse my circular logic, but if everyone should commit to newdocs and no one should commit to master, let's delete the master branch entirely, rename newdocs to master and work there instead. That way, we we're done with this complicated branch issue before the newdocs branch was even created. In other words: Why create a branch at all? We had Tor Arne volunteering to make the build of the modularized documentation properly (awesome). He now spent some time fixing the build and voila, we will have properly modularized documentation that can do two pass runs and will work nicely for everyone (we hope ;) ). In order not to mess up the beta 2 docs completely (we don't know if we get done in time), we created a newdocs branch in every repo now. The plan is to update and fix all the overview documentation in these branches and getting rid of the modularized doc building left-overs. Instead we will have it properly working from toplevel qt5.git. Building docs = in the qt5.git repo (with the other modules checked out and configure run) run make docs Run make docs again to get all links right. Since this is pretty disruptive, we'll wait until the new documentation and the new way of building it is somewhat usable. In the mean time, if you want to work on overview docs (qdoc files, not inline documentation in the code), it would be great if you used the newdocs branches. Greetings Frederik This is most likely just poor communication on my part. The newdocs branch is a topic branch where we can break the current documentation without delaying the next beta. If you have changes that need to go into the beta, they can be put in the master branch and we will deal with any potential conflicts when they appear, but if they do not, and especially if you are participating in the Qt 5 documentation clean-up, it would be great if you could commit to newdocs so we working against the same version of the code. The main conflicts we're worried about now is work on pages that are deleted in the new structure for instance or duplicate work, which would become much more visible if everyone working to make the Qt 5 documentation great are on the same branch. The branch will go away and be merged into master once its contents are considered usable, so this is in no way meant to be a permanent solution. Hopefully that will not take too long. Thanks, Eskil ___ 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] status and use cases for QScreen
On 15/10/2012, at 6:23 PM, Samuel Rødal samuel.ro...@digia.com wrote: On 10/12/2012 10:24 PM, Shawn Rutledge wrote: On 12 October 2012 21:03, Lorn Potter lorn.pot...@gmail.com wrote: On 13/10/2012, at 12:47 AM, Shawn Rutledge shawn.t.rutle...@gmail.com wrote: I got started working on QScreen, its properties, notifiers, and implementation on all 3 platforms after I noticed that the documentation was out of sync with the implementation in Qt5. [on a side note] While getting reacquainted with qsystems, I noticed that if you added brightness, contrast, and maybe backlight state from qsystems to QScreen, we could get rid of the now mostly QScreen wrapper of QDisplayInfo. OK, that would be interesting. Sorry to say I didn't know about it. But I wonder if it's reliable on all platforms? Are these getters or setters? If getters only, what's the typical use case for knowing these in the application? getters only. QSystemInfo in mobility was 99% 'read-only' information. If setters, are those settings something each application is typically allowed to control? I don't think a typical gui app would need to control the brightness or contrast of any screen, unless it was some more advanced video editing or playback software. Something in the middleware layer might - brightness applet, or a daemon that controls brightness based upon ambient light sensor would. The question should really be whether there is a use case for brightness/contrast getter without a setter, if that belongs in QScreen, and if it needs to be exposed to qml. Lorn Potter Senior Software Engineer, QtSensors/QtSensorGestures ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Un-messifying Qt Quick
On 16/10/12 03:35, Thiago Macieira wrote: Will do. I need help from Ossi to figure out how I broke qmake, because it's not evident. Most likely it's qconfig.cpp, which contains the paths returned by QLibrary. There's a special version of this file just for qmake (generated by configure). -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
