Re: [Development] High-dpi Qt best practices
On 10.10.2012, at 16:56, Olivier Goffart wrote: What is wrong with this alternative: All the API stays always in pixel (QIcon, QWidget::geometry, ...) QCoreApplication::setAttribute(Qt::AA_MacHighDPI) (should it maybe be even be set by default?) Setting it as default would make it impossible to just run an application If that is set, everything is in pixel, but the default font size is twice as big, the mac style returns pixelmetrics ans sizes that are twice as big, and all the widgets are then automatically twice as big In general, that's the way to do it. Having hardcoded pixel value has always been a bad practice with Qt. * it's a reality * in painting code there is just no other way So, that would mean spreading factors round all of the code. Application that did it will possibly look bad on high-res display and will need to be fixed. But I think they will need the same amount of fixes with the other appreach because sometimes they really mean pixel, sometimes they mean point. You should have a look at Qt Creator in HiDPI *as it is now*. Without any special high resolution code. Basically the only problem is that any part that is based on images in there looks bad compared to the rest. I believe that for most applications solving that problem, high resolution images, is the only need. If you'd now be able to change the unit in Qt to pixel metrics for certain widgets (and optionally sub widgets) where you really want to take advantage of each and every pixel in e.g. painting code, then every case would be covered. (And you could decide to do what you suggest.) The only thing is about QPen. should we draw lines twice as large? that is bascically what QPen::isCosmetic is for. -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] High-dpi Qt best practices
On 10/11/2012 08:23 AM, Ziller Eike wrote: On 10.10.2012, at 16:56, Olivier Goffart wrote: If you'd now be able to change the unit in Qt to pixel metrics for certain widgets (and optionally sub widgets) where you really want to take advantage of each and every pixel in e.g. painting code, then every case would be covered. (And you could decide to do what you suggest.) Agreed, it definitely needs to be possible to turn off the 2x2 scaling for widgets that _do_ care about individual device pixels. The only thing is about QPen. should we draw lines twice as large? that is bascically what QPen::isCosmetic is for Tricky question. As Shawn said, a 0-width pen might mean people want the thinnest pen possible, which would mean not scaling those by 2x2. However, it is also the default pen, and might be used in styles and other code in combinations with rectangles etc to create insets / outset shading effects for buttons. In those cases scaling is probably the right choice. So I'd say the safest choice would be to scale cosmetic pens by 2x2 as well in the HiDpi mode. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] High-dpi Qt best practices
The only thing is about QPen. should we draw lines twice as large? that is bascically what QPen::isCosmetic is for Absolutely. The problem is that for some reason we have cosmetic as the default. In practice people hardly use cosmetic pens for what it was designed for, it is imply treated as 1px thick pen by pretty much anything QPainter is used for. And even when cosmetic pens are used intentionally, 1 pixel thick lines simply don't look proper on a Retina display. I would definitely +2 this idea. Jens ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] High-dpi Qt best practices
On Oct 11, 2012, at 9:36 AM, Samuel Rødal samuel.ro...@digia.com wrote: On 10/11/2012 08:23 AM, Ziller Eike wrote: On 10.10.2012, at 16:56, Olivier Goffart wrote: If you'd now be able to change the unit in Qt to pixel metrics for certain widgets (and optionally sub widgets) where you really want to take advantage of each and every pixel in e.g. painting code, then every case would be covered. (And you could decide to do what you suggest.) Agreed, it definitely needs to be possible to turn off the 2x2 scaling for widgets that _do_ care about individual device pixels. How about: QPainter p(this); qreal scaleFactor = this-windowHandle()-dpiScaleFactor(); p.scale(1.0 / scaleFactor, 1.0 / scaleFactor); QRect pxelRect(QPoint(0, 0), this-size() * scaleFactor); // paint within pxelRect A bit cumbersome, but it is a special case. Also, we need to make sure the call to scale cancel out properly with the 2x device scale and that the final transform has a proper QTransform::TransformationType . Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] High-dpi Qt best practices
On 10/11/2012 10:16 AM, Sorvig Morten wrote: On Oct 11, 2012, at 9:36 AM, Samuel Rødal samuel.ro...@digia.com wrote: On 10/11/2012 08:23 AM, Ziller Eike wrote: On 10.10.2012, at 16:56, Olivier Goffart wrote: If you'd now be able to change the unit in Qt to pixel metrics for certain widgets (and optionally sub widgets) where you really want to take advantage of each and every pixel in e.g. painting code, then every case would be covered. (And you could decide to do what you suggest.) Agreed, it definitely needs to be possible to turn off the 2x2 scaling for widgets that _do_ care about individual device pixels. How about: QPainter p(this); qreal scaleFactor = this-windowHandle()-dpiScaleFactor(); p.scale(1.0 / scaleFactor, 1.0 / scaleFactor); QRect pxelRect(QPoint(0, 0), this-size() * scaleFactor); // paint within pxelRect A bit cumbersome, but it is a special case. Also, we need to make sure the call to scale cancel out properly with the 2x device scale and that the final transform has a proper QTransform::TransformationType . That might be acceptable :) -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Proposal: Make QPen non-cosmetic by default
This issue came up while preparing some code to be High-dpi aware but it is really a completely separate issue. While I previously supported the idea that cosmetic pens should be two pixels wide by default on HDPI screens, I think we should take it one step further as the real issue is caused by the default values of QPen. QPen defaults to a pen width of 0, which might or might not be an intentional behaviour. This is interpreted as a Cosmetic pen which will have 1 pixel thickness regardless of the scale on the scene. Any code that simply does painter-setPen(someColor) will have this behaviour. The only way to avoid it is to explicitly create a QPen(Qt::Black, 1.0). Since normally there would be no difference between these behaviours, I assume that the majority of code will simply ignore the pen with altogether. Most existing styles certainly does this and mostly break with HDPI set unless every pen is explicitly set to 1.0. I have personally never seen an actual use case where a cosmetic pen makes sense, but I assume there are reasons for having i so anyone creating an explicit QPen(Qt::black, 0.0) should get a 1.0 pixel thick line regardless of scaling. With this in mind, I would propose that we change the initialisation value of QPen to be 1.0 for pen width by default in Qt5, and invert the name and behaviour of the QPainter::NonCosmeticDefaultPen render hint. Most code should not be affected by it and code that depends on this really needs cosmetic pen should already be initialising their QPen explicitly. Regards, Jens ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 file hierarchy
On Wed, Oct 10, 2012 at 10:39:35AM -0700, Thiago Macieira wrote: On quarta-feira, 10 de outubro de 2012 18.04.18, Oswald Buddenhagen wrote: On Fri, Sep 21, 2012 at 06:01:28PM +0200, Thiago Macieira wrote: As for mkspecs, I believe they should be in share, since they are technically- speaking arch-independent. except for qconfig.pri, which spoils the whole party. Right... how difficult would it be to make qmake search for the mkspecs in two different paths? $prefix/share/qt5/mkspecs $prefix/lib/qt5/mkspecs ? If it's hard, then we need to put them all in lib. it wouldn't be terribly hard. it would just make some (well spread) code more complex. basically, $$[QT_HOST_DATA]/mkspecs/somefile would turn into $$search_path(QMAKE_MKSPECS, somefile) or something like that (that function needs to be written yet). fwiw, the default mkspec links would need to go to lib, too, obviously. ___ 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 10, 2012, at 7:46 PM, Thiago Macieira thiago.macie...@intel.com wrote: nterpreted as good reasons to have a 4.9 release Exceptions given on a case-by-case basis. The above is much more than adding a symbol as an artifact of a change. It's whole new API and features. It should not go into 4.8. I think we need to take a second look at the 4.8 submit policy. I'd like to make a special argument for allowing 33266, and then a general argument for allowing API additions to Qt 4 in response to platform changes. Qt 4 works well on retina displays. If you have't seen it, find someone with a Mac and ask to see Qt Creator in hidpi mode - either real or emulated. What is missing is features to handle raster graphics where you need to provide high-dpi artwork and in some cases be aware of the points/pixels distinction. This requires new API and fixes to Qt itself. These fixes are something we have ready since we're implementing them for Qt 5. Qt users are to a large degree using Qt 4 now. If you ask support they'll tell you porting from Qt/Carbon to Qt/Cocoa is a hot topic. The platform implementation in Qt 5 is a (another) rewrite, and we can not expect bug-for-bug compatibility in 5.0. The expected outcome is then that many Qt users will stay on Qt 4 in the near future. It would be quite counterproductive of us to hold back on good fixes that we already have developed due to a policy of not updating Qt 4. It gives the impression that we don't care about users and that we are not protecting the investments that has been made in writing code against the Qt API. 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. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Behavior change: A sane and consistent QPainter coordinate system in Qt 5
While we're on the topic of pixels, in Qt 4 we in effect have two coordinate systems. The antialiased coordinate system where (0, 0) corresponds to the top left corner of the top left pixel, and the aliased coordinate system where (0, 0) corresponds to the center of the top left pixel. That means if you fill a rectangle QRectF(0.1, 0.1, 10, 10) without QPainter::Antialiasing enabled it will actually round up and start filling at (1, 1). The reason for the aliased coordinate system being that way goes all the way back to X11 only having integer coordinate line drawing and polygon filling. The raster paint engine was made to match the behavior of the X11 paint engine and thus the half pixel offset became the de facto standard for the fill rules in our painting systems. _Except_ in cases like image / pixmap painting, where both the X11 and raster paint engine simply rounded the QPointF coordinate. Thus drawing a rect and an image of the same size at the same sub-pixel coordinates would lead to a one pixel delta between the two (a bug that occasionally gets reported but typically closed as Won't fix). Once we became fully aware of this inconsistency (well into the 4.x series) we were too afraid to fix it, to avoid breaking existing applications that relied on the current behavior. Well, this has left us with a coordinate system that is neither internally consistent, nor consistent with the antialiased coordinate system (which closely matches how the OpenGL coordinate system works, although in that case the y axis is flipped). The result of these inconsistencies can easily be seen in the filltest.qps arthur test run with the lance tool against 4.8: http://chaos.troll.no/~sroedal/fillrules.png As the arthur test shows, in some cases the way we fill and the way we sample brush textures don't even match. Although it's a bit late, I think Qt 5 is a good time to fix this so that we finally get a consistent coordinate system without gotchas at every corner when using sub-pixel coordinates. I have a work in progress patch in Code Review that gets rid of the half pixel aliased coordinate offset by default: https://codereview.qt-project.org/#change,36757 Here is how the arthur test looks with the new behavior: http://chaos.troll.no/~sroedal/fillrules-qt5.png For applications that do depend on the old behavior, I introduce a new render hint, QPainter::LegacyFillRules, which restores the 4.x behavior. The patch makes use of this render hint in some of Qt's style painting code (mostly to make the Windows 95 and Cleanlooks styles look good, as they draw aliased polygons in some places). It's unfortunate to potentially cause some extra trouble for a subset of existing applications that wish to port to Qt 5, but weighed against the utter embarrassment of the current fill rules I think we need this change. -- Samuel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Behavior change: A sane and consistent QPainter coordinate system in Qt 5
On Oct 11, 2012, at 1:57 PM, Samuel Rødal samuel.ro...@digia.com wrote: It's unfortunate to potentially cause some extra trouble for a subset of existing applications that wish to port to Qt 5, but weighed against the utter embarrassment of the current fill rules I think we need this change. +1 from me for utter embarrassment. A slight tangent, perhaps we should be less afraid of making behavioural changes to Qt in minor releases, as long as they are flagged and old behaviour can be restored. The flags could serve for say 3 minor releases and then be retired together with the old code path. An even softer path could be to make changes opt-in, then opt-out, and finally mandatory over the course of several minor releases. Morten ___ 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 11, 2012, at 10:58 AM, Bache-Wiig Jens jens.bache-w...@digia.com wrote: I have personally never seen an actual use case where a cosmetic pen makes sense, but I assume there are reasons for having i so anyone creating an explicit QPen(Qt::black, 0.0) should get a 1.0 pixel thick line regardless of scaling. I agree in general. I'm wondering if a 2 pixel-wide line for QPen(Qt::black, 0.0) would be a better option in high-dpi mode - the user is expecting to fill one point. The result will look like a scaled pixmap, but won't have gaps. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Thursday, October 11, 2012 11:45:27 AM Oswald Buddenhagen wrote: [...] nope, sorry, the version-based namespacing simply does not belong into upstream. it's a problem specific to FHS, and should be addressed by those concerned with it. It belongs in Qt and people have already agreed to it. We need to fix it in Qt. not all people have agreed on it. the linux distro centric camp (which has a disproportionate representation in this channel) has agreed on it. which is a very good indication that they should, indeed, have a common standard. *their* standard. which reaches way beyond qt. Yes, in an ideal world the FHS would solve this. But unfortunately the reality of the matter is that this just isn't going to be solved there. That's probably also why other middleware projects have decided to solve the issue on their end years ago (gstreamer, dbus, glib, gtk and many more), because at the end of the day what _really_ matters are the users of Qt. Without the users of Qt we're not relevant. It is _our_ goal that Qt 5 is a no-brainer to install and use, on as many developer workstations as possible. In the process of that we should make life easier for middlemen like the Linux distro packagers, and with this proposal also unify the naming of Qt 5 libraries/binaries throughout the different distros (because we solve the problem in a central place). Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtNetwork: using system proxy by default
Hello, I remember this has been discussed before, but yet again: How about using the system proxy by default, at least on some platforms or by configure switch? Right now every app developer has to call QNetworkProxyFactory::setUseSystemConfiguration(true) in his code to use the system proxies. On desktop you might want to avoid this depending on your app, but on mobile (e.g. Blackberry) it might happen that you just have to use the system configuration and it will not work without it. IMO there are 4 options: 1. leave as it is, tell everybody to call above method in their app 2. just #ifdef for the platforms where it should be used automatically 3. introduce a configure switch -use-system-proxy or so (default no) 4. enable usage of system proxy globally 1. sounds a bit cumbersome for me; I prefer 2. for pragmatic reasons. If people think 3. is cleaner that is fine with me as well. As Shane told me, using the system proxy on Windows might lead to several seconds of delay until the synchronous method that determines the proxy returns, so for now 4. seems too risky. Please suggest / comment etc. Peter - 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] QtNetwork: using system proxy by default
-Original Message- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Peter Hartmann Sent: 11 October 2012 14:12 To: development@qt-project.org Subject: [Development] QtNetwork: using system proxy by default Hello, I remember this has been discussed before, but yet again: How about using the system proxy by default, at least on some platforms or by configure switch? Right now every app developer has to call QNetworkProxyFactory::setUseSystemConfiguration(true) in his code to use the system proxies. On desktop you might want to avoid this depending on your app, but on mobile (e.g. Blackberry) it might happen that you just have to use the system configuration and it will not work without it. Many mobile networks have a mandatory http proxy for the access point. System configuration is the only reasonable way to get this. IMO there are 4 options: 1. leave as it is, tell everybody to call above method in their app 2. just #ifdef for the platforms where it should be used automatically 3. introduce a configure switch -use-system-proxy or so (default no) 4. enable usage of system proxy globally 1. sounds a bit cumbersome for me; I prefer 2. for pragmatic reasons. If people think 3. is cleaner that is fine with me as well. As Shane told me, using the system proxy on Windows might lead to several seconds of delay until the synchronous method that determines the proxy returns, so for now 4. seems too risky. A refinement of option 1 would be to include the setUseSystemConfiguration call in the SDK boilerplate code (along with using showFullScreen() instead of show() on mobiles). The windows issues are documented in https://bugreports.qt-project.org/browse/QTBUG-10106 - normally it's ok, but the worst case is terrible. - the worst case is reproduced with some consumer wlan routers, so affects many users. Nobody complained yet about performance on Mac, but it's a more recent feature and hasn't been tested for perf. Libproxy performance is unknown, I've only done functional testing. In all cases, the API is synchronous. For option 4, I think we need to make an asynchronous wrapper and use it internally anywhere we might block the UI thread with the synchronous version. 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
[Development] QML, v8 and freezing the global object
Hi, the QML engine freezes the global JS object. This is apparently(?) to prevent accidental writes to the global object. For those who don't know, the global object in JS provides objects and properties available in global scope, such as console (for console.log) or qsTr. Now, it turned out that freezing the global object takes a lot of time with v8 on BB10 devices. Even in release mode, just the call to freeze the global object makes the startup time 100ms longer. v8 seems to have an implmentation of freezing that is suboptimal, see for example the benchmark at http://jsperf.com/performance-frozen-object. Note this benchmark is for iterating over properties of frozen objects, not freezing an object, though likely freezing an object would get similar benchmark results. Could we maybe simple get rid of object freezing, and not freeze the global object? What would the consequences of that be, anything bad? I am the opinion that if the user wants to override the console object, let him. Maybe there were other reasons for freezing the global object though? 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
Re: [Development] QtNetwork: using system proxy by default
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? How do other apps (i.e. Chrome) handle this without blocking the user experience? Simon -- Sendt fra min Nokia N911.10.12 15:12 skrev Peter Hartmann: Hello, I remember this has been discussed before, but yet again: How about using the system proxy by default, at least on some platforms or by configure switch? Right now every app developer has to call QNetworkProxyFactory::setUseSystemConfiguration(true) in his code to use the system proxies. On desktop you might want to avoid this depending on your app, but on mobile (e.g. Blackberry) it might happen that you just have to use the system configuration and it will not work without it. IMO there are 4 options: 1. leave as it is, tell everybody to call above method in their app 2. just #ifdef for the platforms where it should be used automatically 3. introduce a configure switch -use-system-proxy or so (default no) 4. enable usage of system proxy globally 1. sounds a bit cumbersome for me; I prefer 2. for pragmatic reasons. If people think 3. is cleaner that is fine with me as well. As Shane told me, using the system proxy on Windows might lead to several seconds of delay until the synchronous method that determines the proxy returns, so for now 4. seems too risky. Please suggest / comment etc. Peter - 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 11, 2012, at 10:58, Bache-Wiig Jens jens.bache-w...@digia.com wrote: This issue came up while preparing some code to be High-dpi aware but it is really a completely separate issue. While I previously supported the idea that cosmetic pens should be two pixels wide by default on HDPI screens, I think we should take it one step further as the real issue is caused by the default values of QPen. QPen defaults to a pen width of 0, which might or might not be an intentional behaviour. This is interpreted as a Cosmetic pen which will have 1 pixel thickness regardless of the scale on the scene. Any code that simply does painter-setPen(someColor) will have this behaviour. The only way to avoid it is to explicitly create a QPen(Qt::Black, 1.0). Since normally there would be no difference between these behaviours, I assume that the majority of code will simply ignore the pen with altogether. Most existing styles certainly does this and mostly break with HDPI set unless every pen is explicitly set to 1.0. I have personally never seen an actual use case where a cosmetic pen makes sense, but I assume there are reasons for having i so anyone creating an explicit QPen(Qt::black, 0.0) should get a 1.0 pixel thick line regardless of scaling. PDF/PS define it this way, and is used when writing that kind of output. With this in mind, I would propose that we change the initialisation value of QPen to be 1.0 for pen width by default in Qt5, and invert the name and behaviour of the QPainter::NonCosmeticDefaultPen render hint. Most code should not be affected by it and code that depends on this really needs cosmetic pen should already be initialising their QPen explicitly. Agreed, I only ever used it when I knew I was painting to PDF. So +1 from me. -- Erik. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork: using system proxy by default
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
Re: [Development] Co-installation library naming rules
On quinta-feira, 11 de outubro de 2012 11.45.27, Oswald Buddenhagen wrote: Indeed. But their output affects a lot of people, including the majority of future Qt contributors, that's not relevant, because if those 20 people do a good job, the millions using the packages will not be bothered by this topic. i find it more important to optimize for those who use custom builds with path-based setups (actual contributors and ISVs). You're assuming that they will all do the *same* good job. If they don't, then we'll have different solutions in different distributions and the pain of supporting the users will fall on us, not on them. Who do you think staffs #qt on Freenode? The other thing is, we still need to rename the libraries. Otherwise, we can't install both sets of *.so files to /usr/lib. If we do that, we've solved the majority of the problem anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 file hierarchy
On quinta-feira, 11 de outubro de 2012 12.01.51, Oswald Buddenhagen wrote: fwiw, the default mkspec links would need to go to lib, too, obviously. True. -- 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] Is overriding an existing virtual method 'BC' in Qt 4?
On quinta-feira, 11 de outubro de 2012 11.48.26, Sorvig Morten wrote: The above is much more than adding a symbol as an artifact of a change. It's whole new API and features. It should not go into 4.8. I think we need to take a second look at the 4.8 submit policy. I'd like to make a special argument for allowing 33266, and then a general argument for allowing API additions to Qt 4 in response to platform changes. I understand your request. But it is nonetheless a new feature and Lars needs to approve the breaking of the freeze in 4.8. We could name it 4.9.0 if we wanted to, but it would probably open a bigger can of worms. -- 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] Is overriding an existing virtual method 'BC' in Qt 4?
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. 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Thu, Oct 11, 2012 at 02:59:03PM +0200, Simon Hausmann wrote: On Thursday, October 11, 2012 11:45:27 AM Oswald Buddenhagen wrote: not all people have agreed on it. the linux distro centric camp (which has a disproportionate representation in this channel) has agreed on it. which is a very good indication that they should, indeed, have a common standard. *their* standard. which reaches way beyond qt. Yes, in an ideal world the FHS would solve this. But unfortunately the reality of the matter is that this just isn't going to be solved there. everyone knows that the FHS is not going to move. i'm arguing that those who are dealing with it should build upon it, which is the distributors. On Thu, Oct 11, 2012 at 08:06:47AM -0700, Thiago Macieira wrote: On quinta-feira, 11 de outubro de 2012 11.45.27, Oswald Buddenhagen wrote: Indeed. But their output affects a lot of people, including the majority of future Qt contributors, that's not relevant, because if those 20 people do a good job, the millions using the packages will not be bothered by this topic. You're assuming that they will all do the *same* good job. that's a rather reasonable assumption. that's why they are here. i don't see why they should be able to compel the qt project to do something they apparently all want, but be incapable of agreeing on a standard under the qt project's umbrella and implementing it only in their own repos. The other thing is, we still need to rename the libraries. Otherwise, we can't install both sets of *.so files to /usr/lib. that's simply not a relevant concern. production libraries can be co-installed just fine. and development libraries can live in their respective subfolders and be found via the respective -L options (which come out of pkg-config - which is why i'm _considering_ making the .pc files co-installable out of the box). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Thu, Oct 11, 2012 at 11:46 AM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: On Thu, Oct 11, 2012 at 02:59:03PM +0200, Simon Hausmann wrote: On Thursday, October 11, 2012 11:45:27 AM Oswald Buddenhagen wrote: not all people have agreed on it. the linux distro centric camp (which has a disproportionate representation in this channel) has agreed on it. which is a very good indication that they should, indeed, have a common standard. *their* standard. which reaches way beyond qt. Yes, in an ideal world the FHS would solve this. But unfortunately the reality of the matter is that this just isn't going to be solved there. everyone knows that the FHS is not going to move. i'm arguing that those who are dealing with it should build upon it, which is the distributors. On Thu, Oct 11, 2012 at 08:06:47AM -0700, Thiago Macieira wrote: On quinta-feira, 11 de outubro de 2012 11.45.27, Oswald Buddenhagen wrote: Indeed. But their output affects a lot of people, including the majority of future Qt contributors, that's not relevant, because if those 20 people do a good job, the millions using the packages will not be bothered by this topic. You're assuming that they will all do the *same* good job. that's a rather reasonable assumption. that's why they are here. i don't see why they should be able to compel the qt project to do something they apparently all want, but be incapable of agreeing on a standard under the qt project's umbrella and implementing it only in their own repos. Why would forcing multiple implementations in different repos be better than agreeing upon and implementing this in the upstream repo? If there is no cooperation then yes distro packagers need to come up with their own solutions, and can work to coordinate this across distros. If there is a general agreement that this is needed then it would seem that doing this in the context of the Qt project is the ideal solution. This would also reduce the amount of work required as there is already an agreed upon place to collaborate (the Qt project), and as we all get our source from the Qt project there is minimal opportunity for solutions to diverge. Marcus ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 5 QMessageBox doesn't respond?
I am wondering if this is the result of switching qtbase to master instead of staying wiht qt5. When I call this on a Mac: QMessageBox::warning(NULL, , warning!); The dialog shows up but clicking at the OK button doesn't dismiss it. And QMessageBox code is taking 100% of a core spinning. Before I file a bug report, can someone with latest qtbase (from yesterday) try this? Thanks. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 QMessageBox doesn't respond?
On Thursday October 11 2012, Stephen Chu wrote: I am wondering if this is the result of switching qtbase to master instead of staying wiht qt5. When I call this on a Mac: QMessageBox::warning(NULL, , warning!); The dialog shows up but clicking at the OK button doesn't dismiss it. And QMessageBox code is taking 100% of a core spinning. Before I file a bug report, can someone with latest qtbase (from yesterday) try this? Works on Linux, but that uses a completely different implementation, of course. If it worked for you before, try bisecting qtbase to find the commit that introduced the regression. -- Marc Mutz marc.m...@kdab.com | Senior 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On quinta-feira, 11 de outubro de 2012 17.46.11, Oswald Buddenhagen wrote: The other thing is, we still need to rename the libraries. Otherwise, we can't install both sets of *.so files to /usr/lib. that's simply not a relevant concern. production libraries can be co-installed just fine. and development libraries can live in their respective subfolders and be found via the respective -L options (which come out of pkg-config - which is why i'm considering making the .pc files co-installable out of the box). I'd simply version the libraries. We already do that on Windows too, for example. -- 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] Co-installation library naming rules
On quinta-feira, 11 de outubro de 2012 12.00.41, Marcus D. Hanwell wrote: If there is a general agreement that this is needed then it would seem that doing this in the context of the Qt project is the ideal solution. This would also reduce the amount of work required as there is already an agreed upon place to collaborate (the Qt project), and as we all get our source from the Qt project there is minimal opportunity for solutions to diverge. Agreed. Think about this: There are a certain number of people who build Qt from sources. Those are usually the Qt developers, the embedded device developers, the packagers and a handful of KDE developers. The vast majority will get it pre-built. Considering all the changes I am proposing do NOT harm any of the people that build from sources, why should we NOT do them? Other than that it requires work on your part, Ossi. -- 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] Co-installation library naming rules
On Thu, Oct 11, 2012 at 11:54:28AM -0700, Thiago Macieira wrote: I'd simply version the libraries. yes. me too. i wouldn't rename them, though. ;) We already do that on Windows too, for example. only because windows has no built-in support for versioning dlls. and fwiw, what qmake does is an utter hack which causes trouble on a regular basis. your whole argument is built on the premise that the system-provided versioning is broken enough that we should ignore it and just claim that different major versions are different libraries alltogether. i disagree with this premise. and i dislike what consequences it has for everything else which is not a library, and the effect it has on *me*, a qt developer. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On Thu, Oct 11, 2012 at 11:56:44AM -0700, Thiago Macieira wrote: Considering all the changes I am proposing do NOT harm any of the people that build from sources, they *do* harm. i positively do *not* want to use qmake-qt5 just because it's the least evil for linux package users. Other than that it requires work on your part, Ossi. oh, i'm not worried about the work. saying no is easy. the patches would of course be written by those who want the changes. ;) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QT 5 beta 2 snapshot : no debug dll for qml
Hi, I have tryed last beta 2 snapshot for windows and there is always no debug version of qml 2 import ... so It's impossible to debug an application that use qml. ___ 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 Thu, 11 Oct 2012 14:33:30 +, Verbruggen Erik wrote: I have personally never seen an actual use case where a cosmetic pen makes sense, but I assume there are reasons for having i so anyone creating an explicit QPen(Qt::black, 0.0) should get a 1.0 pixel thick line regardless of scaling. Think about a scatter plot with many points displayed as crosses. On a large zoom level you only see a cloud but when zooming in you can see each cross and its position in detail. When the pen for the crosses would have been scaled you would end with huge fat symbols - each probably larger than the plot widget itself. Or think about a grid ( or ticks on an axis ), where each line indicates a position according to scale. This line has to be one pixel regardless of the scaling. PDF/PS define it this way, and is used when writing that kind of output. The important part with PDF and cosmetic pens is when you zoom in the generated document later in a PDF viewer. The cosmetic attribute used in the Qt application code decided if the line gets scaled in the viewer or not. Please note that when you change the default setting to non-cosmetic almost all applications using Qwt for generating PDF documents will be broken ( zooming itself is not a problem for Qwt as it is not implemented using painter transformations, but I know other packages doing it ). And as f.e curve pens are set in the application code I can't fix it with a new version of the Qwt library. I bet you will cause similar issues with any type of application that implements zooming ( in the application itself or via PDF ). Uwe ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Build Qt 5 in 32-bit with mingw-builds 4.7.2
I just installed mingw-build 4.7.2 on Windows 7 64-bit. I then configured Qt 5 this way: configure -developer-build -opensource -confirm-license -nomake tests -nomake examples -c++11 The built libraries are in 64-bit. How do I configure Qt 5 to build 32-bit libs? Thanks. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On quinta-feira, 11 de outubro de 2012 21.16.56, Oswald Buddenhagen wrote: On Thu, Oct 11, 2012 at 11:56:44AM -0700, Thiago Macieira wrote: Considering all the changes I am proposing do NOT harm any of the people that build from sources, they *do* harm. i positively do *not* want to use qmake-qt5 just because it's the least evil for linux package users. That's the very most important change that needs to be done: renaming qmake. All the other tools could be separated elsewhere, the libs could be in different dirs. But qmake is the one tool run directly by users, the one tool that Qt Creator asks users to locate. It needs to be renamed.. If you don't want to make it the default, then at the very least we need to add the option to our configure script to force the renaming. We need to adapt our buildsystem to creating the renamed tool. This is not debatable... we simply need to do it in Qt. I don't want distribution packagers choosing different methods: I want them all to have the same solution, the one solution that will be recommended to LSB 5.0, the one solution that the helpful people in #qt, interest@ and other discussion channels will need to know. In other words, the renaming will be the de-facto default for everyone using Linux. Why the hell shouldn't it be the de jure default too? Other than that it requires work on your part, Ossi. oh, i'm not worried about the work. saying no is easy. the patches would of course be written by those who want the changes. ;) I'm willing to put in the effort to make it happen. I've already created one patch going in that direction[1]. But you're the maintainer of the buildsystem and your objections so far would indicate a -2 on your part. [1] https://codereview.qt-project.org/#change,35495 -- 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] Co-installation library naming rules
On quinta-feira, 11 de outubro de 2012 21.09.24, Oswald Buddenhagen wrote: On Thu, Oct 11, 2012 at 11:54:28AM -0700, Thiago Macieira wrote: I'd simply version the libraries. yes. me too. i wouldn't rename them, though. ;) We already do that on Windows too, for example. only because windows has no built-in support for versioning dlls. and fwiw, what qmake does is an utter hack which causes trouble on a regular basis. Kill two birds with one stone: remove the hacks by inserting the 5 into the actual name. your whole argument is built on the premise that the system-provided versioning is broken enough that we should ignore it and just claim that different major versions are different libraries alltogether. It's not broken. What I'm saying is that the rules we've followed so far are insufficient. They need to be amended for source-incompatible and co-installable libraries. i disagree with this premise. and i dislike what consequences it has for everything else which is not a library, and the effect it has on *me*, a qt developer. The only tools that need renaming are the tools that are run by users but are tied to a specific library version. That's basically qmake. If we had a generic build tool that worked with multiple Qt versions (like cmake), we wouldn't need to do it. Since our tool hardcodes Qt specifics and is not backwards compatible with older versions, we need to. That was our decision. Most of the other tools can go unrenamed: they'll either be in libexec because they're not run directly by the user, or they're end-user applications that retain compatibility (creator, qdbus, assistant, linguist and its tools, etc.). The only exceptions are tools that load plugins, like designer, and even then, one could argue that the same .ui should work with either uic. -- 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] QtNetwork: using system proxy by default
On quinta-feira, 11 de outubro de 2012 14.02.11, shane.kea...@accenture.com wrote: Libproxy performance is unknown, I've only done functional testing. I'd rather not use libproxy until we're certain we can tell it which JS library to use. It needs to be one of ours, not webkit-gtk or mozjs. -- 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] Build Qt 5 in 32-bit with mingw-builds 4.7.2
On quinta-feira, 11 de outubro de 2012 18.44.39, Stephen Chu wrote: I just installed mingw-build 4.7.2 on Windows 7 64-bit. I then configured Qt 5 this way: configure -developer-build -opensource -confirm-license -nomake tests -nomake examples -c++11 The built libraries are in 64-bit. How do I configure Qt 5 to build 32-bit libs? There's no option and that is not a bug. The build is what the compiler wants, period. If you want a 32-bit build, make sure that the compiler that produces 32-bit code is found first in $PATH. PS: this is the development mailing list, not interest. -- 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 change: A sane and consistent QPainter coordinate system in Qt 5
On 11/10/12 15:06, BRM wrote: - Original Message - From: Sorvig Mortenmorten.sor...@digia.com Subject: Re: [Development] Behavior change: A sane and consistent QPainter coordinate system in Qt 5 On Oct 11, 2012, at 1:57 PM, Samuel Rødalsamuel.ro...@digia.com wrote: It's unfortunate to potentially cause some extra trouble for a subset of existing applications that wish to port to Qt 5, but weighed against the utter embarrassment of the current fill rules I think we need this change. +1 from me for utter embarrassment. A slight tangent, perhaps we should be less afraid of making behavioural changes to Qt in minor releases, as long as they are flagged and old behaviour can be restored. The flags could serve for say 3 minor releases and then be retired together with the old code path. An even softer path could be to make changes opt-in, then opt-out, and finally mandatory over the course of several minor releases. 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. This could in general be addressed with a QT_LOOKS_LIKE=4.7.4 in /etc/profile, per user or per application. Specific overrides could be opted in/out with QT_COORDS_LOOKS_LIKE=5.0.0. This could even be back-ported. My 2c. Philip 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. Ben ___ 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] Co-installation library naming rules
On 12/10/12 09:18, Thiago Macieira wrote: The only tools that need renaming are the tools that are run by users but are tied to a specific library version. That's basically qmake. If we had a generic build tool that worked with multiple Qt versions (like cmake), we wouldn't need to do it. Since our tool hardcodes Qt specifics and is not backwards compatible with older versions, we need to. That was our decision. So why the arbitrary distinction of major version then? I can trivially produce source-incompatible builds of Qt from the source sources. Are we really going to guarantee that you'd never need more than one minor version of a specific major Qt installed at the same time? I don't see this as any different to a tool like the compiler. What I run in 99% of cases is gcc and the distro has decided which version that should be. For installing multiple versions, I can use the complete name (arch-platform-etc-version-gcc) or set my PATH to where that version's actual binaries are and continue to use gcc. -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation library naming rules
On sexta-feira, 12 de outubro de 2012 10.01.03, Lincoln Ramsay wrote: On 12/10/12 09:18, Thiago Macieira wrote: The only tools that need renaming are the tools that are run by users but are tied to a specific library version. That's basically qmake. If we had a generic build tool that worked with multiple Qt versions (like cmake), we wouldn't need to do it. Since our tool hardcodes Qt specifics and is not backwards compatible with older versions, we need to. That was our decision. So why the arbitrary distinction of major version then? It's not arbitrary. See the rationale and the other emails. But it boils down to the fact that we're breaking source compatibility and it is a major release, with major changes, changes we don't usually do in other releases. I can trivially produce source-incompatible builds of Qt from the source sources. I don't see how that's relevant. Are we really going to guarantee that you'd never need more than one minor version of a specific major Qt installed at the same time? Yes... that's the policy, at least per architecture. Whether we succeed or not, that's different. It's also what everyone else does. I don't see why we should be different. I don't see this as any different to a tool like the compiler. Nor do I, for a user tool that maintains compatibility. qmake does not fit that description, so it's out. What I run in 99% of cases is gcc and the distro has decided which version that should be. For installing multiple versions, I can use the complete name (arch-platform-etc-version-gcc) or set my PATH to where that version's actual binaries are and continue to use gcc. Sure, and that's fine if we wanted to have multiple qmake from the same major version installed, including for cross-compilations. What I'm asking for is to include the Qt major version as part of the differentiation, since it really is a change that people want to make. -- 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
[Development] RFC: banning _q_slot() in favour of new-style connect()?
Hi, I was wondering whether we should stop using the pattern of declaring _q_privateSlots() in favour of connecting to functors or functions directly. Rationale: R1. the _q_ prefix is just a convention, the slot can still be called through the meta-object and still can be reimplemented in more-derived classes. With new-style connects, there'd be no slot to call or reimplement, so the code would become easier to understand (d/t more narrow scope). R2: less space used in meta-object R3: allows patch releases to add or remove code that would formerly have required _q_slots(). Gotchas: G1. The slot could have been overridden in a more-derived class G2. The Private pointer could change in between the connect() and the emit. Currently, this is transparently handled by injecting a call to d_func() into the moc-generated code. For new-style connect, such a situation would require a disconnect/connect pair. The full solution would be to try to remove all _q_slots() from Qt 5.0. Seeing as this change could also be done in 5.1, I'd only propose to ban _new_ _q_slots() from being added. Opinions? Thanks, Marc -- Marc Mutz marc.m...@kdab.com | Senior 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
