Re: [Development] How to disable Qt cache mechanism?
2012/9/21 Alessandro Portale > On Fri, Sep 21, 2012 at 12:01 PM, Fred Fung wrote: > > Hi all, > > > > I want to know how to turn off caching mechanism of Qt? > > Including font cache, pixmap cache and so on. > > > > Or, how can I set the limit of memory cache? > > The Pixmap cache can be specified via API at application run-time: >http://doc.qt.digia.com/latest/qpixmapcache.html#setCacheLimit > > The font cache is afaik hard coded and different from system to > system, I don't think that it can actively be adjusted easily. To keep > font cache usage low, it helps to use less different font variations > (fontface/size/style). > > Hope that helped, > Alessandro > -- Dear Alessandro, Thank you very much for your help. I had adjusted Qt4.8.3 as you suggest, but the issue is not resolved... The problem I encountered makes me confused. My application is a simply QtWebkit based browser and it running on MIPS embedded linux platform without SWAP. But when I visited http://www.youtube.com/leanback#search?q=a and looked over the contents of searching result one by one, the system memory usage kept increasing. I think it could be Qt related problem because I has disabled all the cache in Webkit by QWebSettings's API. For more information : https://bugreports.qt-project.org/browse/QTWEBKIT-346 Regards, FF ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 file hierarchy
On sexta-feira, 21 de setembro de 2012 18.01.28, Thiago Macieira wrote: > qt5/ - arch-specific support files: > bin/ or libexec/ > - executables not run by the user, like syncqt, lrelease, > lupdate imports/ > - QtDeclarative imports > qml2/ > - QML2 (including QtQuick2) arch-specific imports > mkspecs/ ? I forgot to add plugins to lib/qt5 too. Those are the plugins for Qt's own libraries. Applications should not install plugins there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Two days left: Qt Developers Conference CFP
This is the right mailing list :-) The Qt Developers Conference Call for Papers is still open. If you haven't yet, please submit your presentation proposal for the conference. We're looking for topics by developers, for developers, about Qt: developing with it, developing it; what's coming, what's already present, how to use it with or on other technology (devices, architectures, other libraries, frameworks, etc.) Be creative and submit your proposal at https://qtconference.kdab.com/node/12 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5 file hierarchy
On Friday, September 21, 2012 06:01:28 PM Thiago Macieira wrote: > The Qt 5 file hierarchy upon installation should be: > > bin/ - executables run by the user > - unversioned applications, like assistant, linguist, qdbus, > qdbusviewer > - versioned applications, like qmake[35], qdoc5, qmlviewer5, >maybe moc5, uic5, rcc5 > doc/ - gone to share/qt5/doc > examples/ - gone to share/qt5/examples > include/ - versioned include dirs: > QtCore5 or QtCore-5 or QtCore.5 or Qt5Core/ > [...] > Qt/ - gone, forever, no replacement > imports/ - horribly flawed design, see below > lib/ - arch-specific files (also lib or lib//) > ./ - versioned libraries (.a, .so, .la, .prl) > pkgconfig/ - versioned .pc files > qt5/ - arch-specific support files: > bin/ or libexec/ >- executables not run by the user, like syncqt, lrelease, > lupdate > imports/ >- QtDeclarative imports > qml2/ >- QML2 (including QtQuick2) arch-specific imports > mkspecs/ ? > share/- arch-independent files > qml2/- QML2 (including QtQuick2) arch-independent imports > qt5/ > doc/ > examples/ > mkspecs/? > > Note on imports: the design is flawed. It was flawed in Qt 4 and it's worse > now on Qt 5. For Qt 4, the flaw was that it did not differentiate QML > imports that were arch-independent from the ones that required plugins. > With Qt 5, it becomes worse because Qt Quick 1 and 2 share the same > directory. > > Instead, I recommend we immediately change QML2 to the system that Perl > uses: put the arch-specific files inside the lib hierarchy, for which > distributions have already solved the multiarch problem, but put > arch-independent files in the share hierarchy. > > In addition, the loader should be clever to merge similar names from the two > different paths. That is, imagine a .qml file in share/qml2 that requires a > plugin: if the loader is a 32-bit application, it would search for the > plugin in lib/qt5/qml2, but if it's a 64-bit application it would search in > lib64/qt5/qml2. > > Additionally, if we're still using QML2 by the Qt 6 release, the plugins > could be made available in lib/qt6/qml2. > > As for mkspecs, I believe they should be in share, since they are > technically- speaking arch-independent. +1, especially the mkspecs part. Cheers, Romain -- Romain Pokrzywka | rom...@kdab.com | Senior Qt Software Engineer & Trainer 303 Twin Dolphin Dr., Redwood City, CA-94065 KDAB (USA) LLC, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Maintainership for some APIs
On 21/09/12 21:00, Knoll Lars wrote: > On Sep 21, 2012, at 7:52 AM, ext Lorn Potter > wrote: > >> >> On 31/08/2012, at 3:45 AM, Lorn Potter wrote: >> >>> >>> On 14/08/2012, at 6:12 PM, >>> wrote: >>> On Aug 14, 2012, at 7:35 AM, ext alex.blas...@nokia.com wrote: >> -Original Message- >> From: development-bounces+alex.blasche=nokia@qt-project.org > >> Qt SystemInfo and Qt Sensors could find a new owner in Lorn Potter and >> Aaron Mccarthy expressed interest in Qt NFC. The other API's remain >> open. If nobody violently disagrees then I would update the wiki of >> maintainers >> accordingly to indicate vacant spots or new maintainers. > > In hindsight the above statement could be read the wrong way. What I > wanted to express is a nomination of the maintainer role for Aaron (NFC) > and Lorn (SystemInfo & Sensors). Both have contributed a substantial > amount to those libraries already and although we (Brisbane folks) may > not have the time to contribute on a fulltime basis there is a > substantial interest among individuals. Lorn and Aaron are such > developers and I am glad for their participation and energy. Both Aaron and Lorn have my full support. It's great to see them step up! >>> >>> *bump* Where are we on this maintainership issue? >> >> What is our next step here? > > Congratulating you…: > > Congratulations Aaron and Lorn!!! ;-) > >> It's been well over 15 days now. > > I've added you to the maintainers group in gerrit, and updated the wiki > pages. Matias will do the required changes in Jira. > Ok, thanks! The page at http://qt-project.org/wiki/Maintainers lists my email wrong. It's gmail.com not gmai.com :) > Cheers, > Lars > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QBasicMutex::lockInternal() race condition?
On sexta-feira, 21 de setembro de 2012 17.45.27, Tony Van Eerd wrote: > I have no solutions (yet?). I just want to know how to constrain my > thinking. I basically won't even try going down the DCAS road. Nor the > LL/SC road, since C++11 has basically shunned that idea, sadly. > > Solutions that map to C++11 concepts, with single-sized atomics, would > probably be best. Like what is there now. Better, yes, but we're not constrained by C++11 constraints. We can write assembly. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QBasicMutex::lockInternal() race condition?
I have no solutions (yet?). I just want to know how to constrain my thinking. I basically won't even try going down the DCAS road. Nor the LL/SC road, since C++11 has basically shunned that idea, sadly. Solutions that map to C++11 concepts, with single-sized atomics, would probably be best. Like what is there now. > -Original Message- > From: development-bounces+tvaneerd=rim@qt-project.org > [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf > Of Thiago Macieira > Sent: Friday, September 21, 2012 1:32 PM > To: development@qt-project.org > Subject: Re: [Development] QBasicMutex::lockInternal() race condition? > > On sexta-feira, 21 de setembro de 2012 16.46.44, Tony Van Eerd wrote: > > I'll take that as a 'No'. ie use of DCAS would be limited to the > point of > > it not being worth maintaining 2 separate implementations - one with > DCAS, > > one without. I think DCAS is only worth using if it could be used > > everywhere. > > Right. Because of the silly x86-64 early mistake, we need to support a > non- > DCAS version. Or ban those early processors without "cx16" support. > > Even then, we need a separate implementation for LL/SC architectures. > > We don't need to decide on that now. But if you do have a good solution > with > DCAS, we could consider it later. We just need to double the size of > QMutex > now. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > Intel Sweden AB - Registration Number: 556189-6027 > Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden - 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] QBasicMutex::lockInternal() race condition?
On sexta-feira, 21 de setembro de 2012 16.46.44, Tony Van Eerd wrote: > I'll take that as a 'No'. ie use of DCAS would be limited to the point of > it not being worth maintaining 2 separate implementations - one with DCAS, > one without. I think DCAS is only worth using if it could be used > everywhere. Right. Because of the silly x86-64 early mistake, we need to support a non- DCAS version. Or ban those early processors without "cx16" support. Even then, we need a separate implementation for LL/SC architectures. We don't need to decide on that now. But if you do have a good solution with DCAS, we could consider it later. We just need to double the size of QMutex now. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QBasicMutex::lockInternal() race condition?
I'll take that as a 'No'. ie use of DCAS would be limited to the point of it not being worth maintaining 2 separate implementations - one with DCAS, one without. I think DCAS is only worth using if it could be used everywhere. > -Original Message- > From: development-bounces+tvaneerd=rim@qt-project.org > [mailto:development-bounces+tvaneerd=rim@qt-project.org] On Behalf > Of Thiago Macieira > Sent: Friday, September 21, 2012 10:52 AM > To: development@qt-project.org > Subject: Re: [Development] QBasicMutex::lockInternal() race condition? > > On sexta-feira, 21 de setembro de 2012 13.42.13, Tony Van Eerd wrote: > > By the way, I assume the intent is to limit the implementation to > only using > > int/pointer-sized atomics, not double width atomics? > > We can use double-width atomics if necessary. But the only architecture > for > which I implemented that is x86 32-bit (via cmpxchg8b). And even then, > the > assembly is very fragile, since it requires no less than 5 registers > and a > memory operand. Very often, gcc bails out by not being able to allocate > registers. > > Double-width atomics must be a solution to other problems, not a > requirement, > since they don't exist on all platforms. For LL/SC platforms, we need a > different implementation. For Itanium, we must figure out a way of > working with > the weird "compare 8 exchange 16" instruction. Finally, for x86-64, we > need a > fallback because early 64-bit processors were missing the CMPXCHG16B > instruction. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > Intel Sweden AB - Registration Number: 556189-6027 > Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden - 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 sexta-feira, 21 de setembro de 2012 18.01.28, Thiago Macieira wrote: > include/- versioned include dirs: > QtCore5 or QtCore-5 or QtCore.5 or Qt5Core/ Oops, this won't work, as it breaks source-compatibility completely. It needs to be: include/ qt5/ QtCore/ Just like D-Bus: /usr/include/dbus-1.0 has dbus/dbus.h, except we don't repeat the mistake of having a .0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation & library naming rules
On sexta-feira, 21 de setembro de 2012 17.33.01, Stephen Kelly wrote: > On Friday, September 21, 2012 16:47:11 Thiago Macieira wrote: > > Rationale: > > -- > > > > This is a rewriting of the book in how to name a library. > > It seems like it might be something to bring up in a wider scope (with > distros for example). This isn't Qt specific. Has it been an issue before? > Why solve it now? Because we're about to release 5.0 and these problems need to be solved. I forgot to link: here's where the discussion originated: https://bugreports.qt-project.org/browse/QTBUG-27137 > but I couldn't build concensus to remove the major version number from > there. Of course, to disabmiguate, users could have used > > find_package(QtCore VERSION 5) > > or > > find_package(QtCore VERSION 6) This is the right way of doing it, provided that the VERSION is mandatory. Which is why I am recommending that it be hardcoded in the name instead. > as desired. Having the version number in the name in the case of the CMake > files is not really required, but I gave up trying to build consensus on > that. > > Buildsystems based on pkgconfig will often have a requirement of the form: > > QtCore >= 4.6 QtGui >= 4.6 > > > > or even simply: > > QtCore QtGui > > It is also possible to specify QtGui < 5.0. Any distro where that is needed, > but not present is a bug in the distro. This is not a permanent solution nor does it work now. There are three problems it doesn't solve: *Currently*, the packages and dependencies are listed like I listed. We cannot require that everyone replace everything now. Won't work. Further, it won't work for "QtGui < 6.0" since that would select either 4 or 5. People would have to write "QtGui >= 4.6 QtGui < 6.0", but as I said, reality is different. And it doesn't solve the co-installation problem. We need both 4 and 5 to install at the same time. > > Those requirements do match the Qt 5 libraries: > > $ pkg-config --libs QtCore \>= 4.6 QtGui \>= 4.6 > > -L/home/thiago/obj/qt/qt5/qtbase/lib -lQtCore -lQtGui > > $ pkg-config --libs QtCore \>= 4.6 QtCore \< 5.0 > Requested 'QtCore < 5.0' but version of Qtcore is 5.0.0 > > > Whether that is correct or not is unknown to pkg-config. > > But it is known to the user of pkg-config. Who didn't think this far ahead. This is the right way to do it, but two of the problems remain. > > It could be right > > if the application has already been ported to Qt 5. In the case of most > > applications existing today, it is incorrect. > > > > But it could be right for other libraries. For example, for libpng: > > $ pkg-config --libs libpng \>= 1.2 > > -lpng15 > > It seems like it would be nice for pkg-config files to be able to contain a > maximum version number for some start-number. Is that possible? Sorry, what? I didn't understand. > > The fact that our pkg-config files have the same name also impacts the co- > > installability of Qt 4 and Qt 5, and a little more: Linux distributions > > *will* carry Qt 4 for a number of years to come (they still have Qt 3). > > Therefore, they must be able to at least have both sets of packages in > > their > > repositories. The problem comes when their buildsystems make reference to > > pkg- config files, such as in RPM-based distros: > > > > BuildRequires: pkgconfig(QtCore) > > I don't know anything about RPM, but I would be surprised if they can't > specify versions there. If they can't, then that's a global bug for them, > not a local one for us. They can. But we can't require all distros to patch all their .spec files to say < 5.0 and >= 5.0 in other places. We could try and this could be done for most distros, but it wouldn't solve the problem of source packages by third parties. > > == Proposal => > > > The library naming rules must be modified. > > Is this the first light for this proposal, or have you brought this to > distros attention already? First light putting it to words like this. However, note that glib & family libs *already* follow this convention and have done so for years, since their 2.0 release. I just don't think it has been codified like I've done. > Why do you think it's our problem to solve and not theirs? I don't think it's their problem to solve. I think that this is a correct change to do. They won't see it as their problem because the GTK camp has already solved this problem for years. From their point of view, they'll see us as the ones breaking the rules they already have in place. And if we refuse to act, they might opt for a path of least resistance and rename our files, which in the end hurts us more than it hurts them. See the qmake vs qmake-qt4 issue, just like the LSB 4 solution that can't co-install Qt 3 and Qt 4. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Descr
[Development] Qt 5 file hierarchy
The Qt 5 file hierarchy upon installation should be: bin/- executables run by the user - unversioned applications, like assistant, linguist, qdbus, qdbusviewer - versioned applications, like qmake[35], qdoc5, qmlviewer5, maybe moc5, uic5, rcc5 doc/- gone to share/qt5/doc examples/ - gone to share/qt5/examples include/- versioned include dirs: QtCore5 or QtCore-5 or QtCore.5 or Qt5Core/ [...] Qt/ - gone, forever, no replacement imports/- horribly flawed design, see below lib/- arch-specific files (also lib or lib//) ./ - versioned libraries (.a, .so, .la, .prl) pkgconfig/ - versioned .pc files qt5/ - arch-specific support files: bin/ or libexec/ - executables not run by the user, like syncqt, lrelease, lupdate imports/ - QtDeclarative imports qml2/ - QML2 (including QtQuick2) arch-specific imports mkspecs/ ? share/ - arch-independent files qml2/- QML2 (including QtQuick2) arch-independent imports qt5/ doc/ examples/ mkspecs/? Note on imports: the design is flawed. It was flawed in Qt 4 and it's worse now on Qt 5. For Qt 4, the flaw was that it did not differentiate QML imports that were arch-independent from the ones that required plugins. With Qt 5, it becomes worse because Qt Quick 1 and 2 share the same directory. Instead, I recommend we immediately change QML2 to the system that Perl uses: put the arch-specific files inside the lib hierarchy, for which distributions have already solved the multiarch problem, but put arch-independent files in the share hierarchy. In addition, the loader should be clever to merge similar names from the two different paths. That is, imagine a .qml file in share/qml2 that requires a plugin: if the loader is a 32-bit application, it would search for the plugin in lib/qt5/qml2, but if it's a 64-bit application it would search in lib64/qt5/qml2. Additionally, if we're still using QML2 by the Qt 6 release, the plugins could be made available in lib/qt6/qml2. As for mkspecs, I believe they should be in share, since they are technically- speaking arch-independent. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation & library naming rules
On Fri, Sep 21, 2012 at 04:47:11PM +0200, Thiago Macieira wrote: > This is long, so I'll give you my recommendation first. If you agree with me, > you don't have to read the rest. If you disagree, you have to read my > arguments. > fwiw, this refers to https://bugreports.qt-project.org/browse/QTBUG-27137 - i stand by my last comment. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation & executable naming rules
On sexta-feira, 21 de setembro de 2012 17.24.16, Thiago Macieira wrote: > Good examples are: qtcreator, assistant, linguist, qmlviewer, qmlscene, > qmlplugindump, qmlprofiler, xmlpatterns, qdbus, qdbusviewer, qglinfo Actually, the qml ones are not good examples since they can load plugins. They need to be moved to category 2.a) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation & library naming rules
On Friday, September 21, 2012 16:47:11 Thiago Macieira wrote: > Rationale: > -- > > This is a rewriting of the book in how to name a library. It seems like it might be something to bring up in a wider scope (with distros for example). This isn't Qt specific. Has it been an issue before? Why solve it now? > == Enter other tools == > As was shown by CMake months ago, we cannot have the > Qt 5 packages called "Qt" as those conflict with the ones in Qt 4. For clarity, I guess you mean that we chose not to use find_package(Qt VERSION 5) We could have, but for several reasons (for example, symmetry with find_package(Qt4), easier to implement without having to think about conflicts, etc). but instead we chose to have multiple separate modules like this: find_package(Qt5Core) We could also have used find_package(QtCore) but I couldn't build concensus to remove the major version number from there. Of course, to disabmiguate, users could have used find_package(QtCore VERSION 5) or find_package(QtCore VERSION 6) as desired. Having the version number in the name in the case of the CMake files is not really required, but I gave up trying to build consensus on that. > Buildsystems based on pkgconfig will often have a requirement of the form: > QtCore >= 4.6 QtGui >= 4.6 > or even simply: > QtCore QtGui It is also possible to specify QtGui < 5.0. Any distro where that is needed, but not present is a bug in the distro. > > Those requirements do match the Qt 5 libraries: > $ pkg-config --libs QtCore \>= 4.6 QtGui \>= 4.6 > -L/home/thiago/obj/qt/qt5/qtbase/lib -lQtCore -lQtGui $ pkg-config --libs QtCore \>= 4.6 QtCore \< 5.0 Requested 'QtCore < 5.0' but version of Qtcore is 5.0.0 > Whether that is correct or not is unknown to pkg-config. But it is known to the user of pkg-config. > It could be right > if the application has already been ported to Qt 5. In the case of most > applications existing today, it is incorrect. > > But it could be right for other libraries. For example, for libpng: > $ pkg-config --libs libpng \>= 1.2 > -lpng15 It seems like it would be nice for pkg-config files to be able to contain a maximum version number for some start-number. Is that possible? > The fact that our pkg-config files have the same name also impacts the co- > installability of Qt 4 and Qt 5, and a little more: Linux distributions > *will* carry Qt 4 for a number of years to come (they still have Qt 3). > Therefore, they must be able to at least have both sets of packages in > their > repositories. The problem comes when their buildsystems make reference to > pkg- config files, such as in RPM-based distros: > > BuildRequires: pkgconfig(QtCore) I don't know anything about RPM, but I would be surprised if they can't specify versions there. If they can't, then that's a global bug for them, not a local one for us. > > Since the distribution contains packages for both versions of QtCore, it is > now ambiguous which one would be selected for building. >From what I know about distros, they are capable of handling versions like this, so this is a solved problem, no? > Selecting the 5 > version now would be wrong, just as selecting version 4 in a few years' > time. This is a distro problem to solve. > == Proposal == > > The library naming rules must be modified. Is this the first light for this proposal, or have you brought this to distros attention already? Why do you think it's our problem to solve and not theirs? Thanks, -- Stephen Kelly | 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] Co-installation & executable naming rules
On sexta-feira, 21 de setembro de 2012 16.47.11, Thiago Macieira wrote: > Include the major version number (5) in all library base names, like on > Windows, on all platforms. On Windows we already have QtCore5.dll and > QtV85.dll, so I recommend having libQtCore5.so.5. For Mac, I'm not sure of > the naming scheme, but the recommendation applies. > > This recommendation also applies to the static library archives > (libQtCore5.a), qmake library files (libQtCore5.prl), libtool archives > (libQtCore5.la) and pkgconfig files (QtCore5.pc). CMake files already have > the version number. but in a different place (Qt5Core). > > I recommend harmonising the cmake names, either by changing them to QtCore5 > or by changing the library naming to match the cmake files (libQt5Core.so, > Qt5Core.pc, etc). Or one of the other alternatives at the bottom of this > email. > > PS: this recommendation does not apply to executables. See follow-up email. For executables, the situation is similar. The difference is that executables have three categories, not just two: 1) executables that are user applications 2) executables used for development; subdivides into: a) executables run by the user b) executables run only by the buildsystem 3) executables run by libraries Fortunately for us in Qt, we have none that fall into the third category at this point. But the proposal contemplates them. 1) Applications Application executables are not versioned and they are installed in standard locations, like /usr/bin. They have only a base name and that's all. An upgrade must retain compatibility with previous versions, upgrade user settings whenever possible, etc. Good examples are: qtcreator, assistant, linguist, qmlviewer, qmlscene, qmlplugindump, qmlprofiler, xmlpatterns, qdbus, qdbusviewer, qglinfo Questionable: qdoc (does it parse Qt4 docs? do we retain any compatibility?) designer (the .ui format hasn't changed, but can it still save qt3 .ui?) 2.a) Development, run by the user For anybody else, the first sub-category would be a user application. But we've not been good at this, so I had to create this category to accommodate its only member: qmake, though qdoc may join it. Since they're run by the user, they must be installed in standard locations (/usr/bin). But since they do not retain backwards compatibility, they must be versioned. => qmake must be renamed, either to qmake3 or to qmake5. Depending on how we categorise them, these executables may be 2.a) or 2.b): designer, lconvert, lrelease, lupdate, moc, rcc, uic If we determine that they are run by the user, we must rename them and add a version number. 2.b & 3) Support executables, not normally run by the user Since they are not run by the user, those executables should not be in /usr/bin. Instead, they should either be in /usr/libexec/ or in /usr/lib/ The component depends on how shared these executables are. All the executables I listed for 2.a) could be 2.b), plus a few that are definitely never run by users, like syncqt and mkv8snapshot. If we determine that they are not run by the user, we should move them to a suitable location and choose a "qt5" key. Future, hypothetical executable needed at runtime, would be installed to the same location if they are shared by different versions of Qt 5. The exception would be an executable that is used by a library that has two different binary versions. In that case, they must be in that directory above *and* be versioned. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QBasicMutex::lockInternal() race condition?
On sexta-feira, 21 de setembro de 2012 13.42.13, Tony Van Eerd wrote: > By the way, I assume the intent is to limit the implementation to only using > int/pointer-sized atomics, not double width atomics? We can use double-width atomics if necessary. But the only architecture for which I implemented that is x86 32-bit (via cmpxchg8b). And even then, the assembly is very fragile, since it requires no less than 5 registers and a memory operand. Very often, gcc bails out by not being able to allocate registers. Double-width atomics must be a solution to other problems, not a requirement, since they don't exist on all platforms. For LL/SC platforms, we need a different implementation. For Itanium, we must figure out a way of working with the weird "compare 8 exchange 16" instruction. Finally, for x86-64, we need a fallback because early 64-bit processors were missing the CMPXCHG16B instruction. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Co-installation & library naming rules
This is long, so I'll give you my recommendation first. If you agree with me, you don't have to read the rest. If you disagree, you have to read my arguments. Recommendation: --- Include the major version number (5) in all library base names, like on Windows, on all platforms. On Windows we already have QtCore5.dll and QtV85.dll, so I recommend having libQtCore5.so.5. For Mac, I'm not sure of the naming scheme, but the recommendation applies. This recommendation also applies to the static library archives (libQtCore5.a), qmake library files (libQtCore5.prl), libtool archives (libQtCore5.la) and pkgconfig files (QtCore5.pc). CMake files already have the version number. but in a different place (Qt5Core). I recommend harmonising the cmake names, either by changing them to QtCore5 or by changing the library naming to match the cmake files (libQt5Core.so, Qt5Core.pc, etc). Or one of the other alternatives at the bottom of this email. PS: this recommendation does not apply to executables. See follow-up email. Rationale: -- This is a rewriting of the book in how to name a library. == Current = Up until now, libraries on Linux and other ELF-based Unix systems have been named freely. Since the dynamic linker and the compile linker operate on different names, this has opened up some opportunities for co-installation. The regular linker searches for libXXX.so or libXXX.a when given the -lXXX flag. When it links to a shared object, it reads that object's soname (so- called because it appears in the ELF dynamic tag DT_SONAME) and records it in this object's header, with the tag DT_NEEDED. That's the name that the dynamic linker will search for at runtime. The linker also offers an option to set the soname of the library being created to anything, defaulting to the output file name. By *convention*, version numbers are numerical and include two or more numbers. Qt uses the same scheme that Linux kernels did prior to the 2.6.x series and now again with the 3.x series: three numbers, labeled "major", "minor" and "micro" (or "patch-level"). Also by convention, buildsystems include the major version number in the library's soname. That is, when building QtCore version 4.8.2, the following files are relevant: libQtCore.sothe file that -lQtCore will search libQtCore.so.4 the file that matches the soname libQtCore.so.4.8.2 the actual library, not a symlink (libQtCore.so.4.8 is not relevant, since absolutely no one uses it) As a consequence of the behaviour of the dynamic linker, it is possible to install in parallel two different major versions of a given library, so that applications and other libraries built with the previous version can continue working. In particular, note that it's also possible to load two different major versions of a given library into memory, as the dynamic linker only cares about the full soname. More often than not, that's a bad idea. Note: does not apply to Qt Quick 2, since the version number is already part of the base library name. == Enter other tools = CMake, libtool, pkgconfig and tools built around them introduce another level of complexity. As was shown by CMake months ago, we cannot have the Qt 5 packages called "Qt" as those conflict with the ones in Qt 4. The same now applies to the pkgconfig files. Buildsystems based on pkgconfig will often have a requirement of the form: QtCore >= 4.6 QtGui >= 4.6 or even simply: QtCore QtGui Those requirements do match the Qt 5 libraries: $ pkg-config --libs QtCore \>= 4.6 QtGui \>= 4.6 -L/home/thiago/obj/qt/qt5/qtbase/lib -lQtCore -lQtGui Whether that is correct or not is unknown to pkg-config. It could be right if the application has already been ported to Qt 5. In the case of most applications existing today, it is incorrect. But it could be right for other libraries. For example, for libpng: $ pkg-config --libs libpng \>= 1.2 -lpng15 The fact that our pkg-config files have the same name also impacts the co- installability of Qt 4 and Qt 5, and a little more: Linux distributions *will* carry Qt 4 for a number of years to come (they still have Qt 3). Therefore, they must be able to at least have both sets of packages in their repositories. The problem comes when their buildsystems make reference to pkg- config files, such as in RPM-based distros: BuildRequires: pkgconfig(QtCore) Since the distribution contains packages for both versions of QtCore, it is now ambiguous which one would be selected for building. Selecting the 5 version now would be wrong, just as selecting version 4 in a few years' time. == Proposal = The library naming rules must be modified. They should be: 1) when making a new release that retains source and binary compatibility, retain the library soname; 2) when making a new release that retains source compatibility but not binary, change the soname but retain the base library name; 3) when making a new release
Re: [Development] Retina display support
On 21 Sep 2012, at 15:30, P Bai wrote: > Thank you, Eike. From what I read in the codereview, a function to get the > scale factor qt_mac_get_scalefactor() is available as a patch, but > QPixmap/QImage HiDPI support is still a WIP. Does that mean even if I were > able to detect HiDPI mode, I still can't do anything until QPixmap/QImage > support becomes available. Is that right? That's how I read it, yes. Note though that qt_mac_get_scalefactor() is a private method in a private header. Br Eike > Thank you again! > P > > > - Original Message - > From: Ziller Eike > To: Kai-Uwe Behrmann > Cc: P Bai ; "development@qt-project.org" > > Sent: Friday, September 21, 2012 4:37 AM > Subject: Re: [Development] Retina display support > > > On 21 Sep 2012, at 07:12, Kai-Uwe Behrmann wrote: > >> Am 20.09.12, 19:09 -0700 schrieb P Bai: >>> I have a few questions about how to add retina display support to my >>> application. I understand by reading an earlier discuss that you can add a >>> few lines in the info.plist to enable HiDPI render. That would only work >>> for text and standard widgets, right? > > Right. > >>> How about icons and pixmaps? How do I detect if the application is running >>> in HiDPI mode? > > At the moment only through platform API, e.g. UIScreen scale > >>> For example if I write an image viewer program, how do I know when to draw >>> a high resolution image? I guess I can just always force draw the high-res >>> image to the rect of a regular sized image, > > I don't think that would work atm. Afaik Qt doesn't draw at "sub-point" > coordinates as is and would downscale your high-res image to the point size > of the rectangle. (See below for an explanation what I mean with that.) > > Morten Sørvig is working on a solution for the HiDPI issue, a (probably > outdated) experiment is on https://codereview.qt-project.org/33266 > >>> but that would be a huge waste of system resource and performance drag when >>> running on non-retina system. Are there any better solutions? >> >> Aren't you seeing the window size in pixels as usual? With that available, >> you would have a generic answere for your kind of question. > > Well, no. "Pixel" in the Qt world atm means something different than "pixel" > in the physical world (when talking about Cocoa / Mac). > The integer coordinates in Qt actually are mapped to what Cocoa calls > "points" which is referring to "logical" coordinate space, not "device" > coordinate space. > A HiDPI screen has the same number of "points" as a corresponding non-HiDPI > screen, but it has a "scale" (of 2). Applications see the same number of > points when they run on a HiDPI screen as they would on a non-HiDPI screen > (--> everything has exactly the same physical dimensions when running on > different screens). > That means that Qt also reports the same dimensions. Rastering for pixmaps is > also done based on "points". > > -- > Eike Ziller > Senior Software Engineer > > Digia Germany GmbH > Rudower Chausse 13, 12489 D-Berlin > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B, > Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius > Email: eike.zil...@digia.com > Tel: +49 30 63 92 32 55 > > Digia Germany is a group company of Digia Plc, > Valimotie 21, FI-00380 Helsinki Finland > Visit us at: www.digia.com > -- > PRIVACY AND CONFIDENTIALITY NOTICE > This message and any attachments are intended only for use by the named > addressee and may contain privileged and/or confidential information. If you > are not the named addressee you should not disseminate, copy or take any > action in reliance on it. If you have received this message in error, please > contact the sender immediately and delete the message and any attachments > accompanying it. Digia Germany GmbH and Digia Plc do not accept liability for > any corruption, interception, amendment, tampering or viruses occurring to > this message. -- Eike Ziller Senior Software Engineer Digia Germany GmbH Rudower Chaussee 13, 12489 D-Berlin Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B, Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Tel: +49 30 63 92 32 55 Digia Germany is a group company of Digia Plc, Valimotie 21, FI-00380 Helsinki Finland Visit us at: www.digia.com -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Germany GmbH and Digia Plc do not
Re: [Development] QBasicMutex::lockInternal() race condition?
> -Original Message- > > Not really, the id can't change. > The id is only set once when the QMutexPrivate is used for the first > time. > (And that change has already been aquired for a long time) > > Acquire is uneccessary. > > It was added in commit 5bfeab87 when the uses of the operator were > removed. I > guess a lot of the barers where added for safety, because it would have > been > too much work to look in so many place which one were necessary. > > -- > Olivier > And removing barriers is always scary. By the way, I assume the intent is to limit the implementation to only using int/pointer-sized atomics, not double width atomics? - 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] Retina display support
Thank you, Eike. From what I read in the codereview, a function to get the scale factor qt_mac_get_scalefactor() is available as a patch, but QPixmap/QImage HiDPI support is still a WIP. Does that mean even if I were able to detect HiDPI mode, I still can't do anything until QPixmap/QImage support becomes available. Is that right? Thank you again! P - Original Message - From: Ziller Eike To: Kai-Uwe Behrmann Cc: P Bai ; "development@qt-project.org" Sent: Friday, September 21, 2012 4:37 AM Subject: Re: [Development] Retina display support On 21 Sep 2012, at 07:12, Kai-Uwe Behrmann wrote: > Am 20.09.12, 19:09 -0700 schrieb P Bai: >> I have a few questions about how to add retina display support to my >> application. I understand by reading an earlier discuss that you can add a >> few lines in the info.plist to enable HiDPI render. That would only work for >> text and standard widgets, right? Right. >> How about icons and pixmaps? How do I detect if the application is running >> in HiDPI mode? At the moment only through platform API, e.g. UIScreen scale >> For example if I write an image viewer program, how do I know when to draw a >> high resolution image? I guess I can just always force draw the high-res >> image to the rect of a regular sized image, I don't think that would work atm. Afaik Qt doesn't draw at "sub-point" coordinates as is and would downscale your high-res image to the point size of the rectangle. (See below for an explanation what I mean with that.) Morten Sørvig is working on a solution for the HiDPI issue, a (probably outdated) experiment is on https://codereview.qt-project.org/33266 >> but that would be a huge waste of system resource and performance drag when >> running on non-retina system. Are there any better solutions? > > Aren't you seeing the window size in pixels as usual? With that available, > you would have a generic answere for your kind of question. Well, no. "Pixel" in the Qt world atm means something different than "pixel" in the physical world (when talking about Cocoa / Mac). The integer coordinates in Qt actually are mapped to what Cocoa calls "points" which is referring to "logical" coordinate space, not "device" coordinate space. A HiDPI screen has the same number of "points" as a corresponding non-HiDPI screen, but it has a "scale" (of 2). Applications see the same number of points when they run on a HiDPI screen as they would on a non-HiDPI screen (--> everything has exactly the same physical dimensions when running on different screens). That means that Qt also reports the same dimensions. Rastering for pixmaps is also done based on "points". -- Eike Ziller Senior Software Engineer Digia Germany GmbH Rudower Chausse 13, 12489 D-Berlin Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B, Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Email: eike.zil...@digia.com Tel: +49 30 63 92 32 55 Digia Germany is a group company of Digia Plc, Valimotie 21, FI-00380 Helsinki Finland Visit us at: www.digia.com -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Germany GmbH and Digia Plc do not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Maintainership for some APIs
On Sep 21, 2012, at 7:52 AM, ext Lorn Potter wrote: > > On 31/08/2012, at 3:45 AM, Lorn Potter wrote: > >> >> On 14/08/2012, at 6:12 PM, >> wrote: >> >>> On Aug 14, 2012, at 7:35 AM, ext alex.blas...@nokia.com >>> wrote: > -Original Message- > From: development-bounces+alex.blasche=nokia@qt-project.org > Qt SystemInfo and Qt Sensors could find a new owner in Lorn Potter and > Aaron Mccarthy expressed interest in Qt NFC. The other API's remain open. > If nobody violently disagrees then I would update the wiki of maintainers > accordingly to indicate vacant spots or new maintainers. In hindsight the above statement could be read the wrong way. What I wanted to express is a nomination of the maintainer role for Aaron (NFC) and Lorn (SystemInfo & Sensors). Both have contributed a substantial amount to those libraries already and although we (Brisbane folks) may not have the time to contribute on a fulltime basis there is a substantial interest among individuals. Lorn and Aaron are such developers and I am glad for their participation and energy. >>> >>> Both Aaron and Lorn have my full support. It's great to see them step up! >> >> *bump* Where are we on this maintainership issue? > > What is our next step here? Congratulating you…: Congratulations Aaron and Lorn!!! ;-) > It's been well over 15 days now. I've added you to the maintainers group in gerrit, and updated the wiki pages. Matias will do the required changes in Jira. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] How to disable Qt cache mechanism?
Hi all, I want to know how to turn off caching mechanism of Qt? Including font cache, pixmap cache and so on. Or, how can I set the limit of memory cache? thanks. Br, FF ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Maintainer for Editors&C++support in Qt Creator
Another +1 from me. Cheers, Lars On Sep 21, 2012, at 11:14 AM, leandro.m...@nokia.com wrote: > I certainly second Erik's proposal. > > > Kind regards, > Leandro T. C. Melo > > > From: development-bounces+leandro.melo=nokia@qt-project.org > [development-bounces+leandro.melo=nokia@qt-project.org] on behalf of > Ziller Eike (EXT-Digia/Berlin)-Qt > Sent: Friday, September 21, 2012 9:49 AM > To: development@qt-project.org > Cc: list > Subject: [Development] Maintainer for Editors&C++support in Qt Creator > > I propose Erik Verbruggen as the new maintainer for Editor & C++ Support in > Qt Creator, taking over the responsibilities from Leandro who unfortunately > left us. > > Erik has already been working on the language support in Qt Creator for a > long time, including the whole c++ preprocessor in 2.6, work on the C++11 > support, and the Clang initiative. > > -- > Eike Ziller > Senior Software Engineer > > Digia Germany GmbH > Rudower Chausse 13, 12489 D-Berlin > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B, > Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius > Email: eike.zil...@digia.com > Tel: +49 30 63 92 32 55 > > Digia Germany is a group company of Digia Plc, > Valimotie 21, FI-00380 Helsinki Finland > Visit us at: www.digia.com > -- > PRIVACY AND CONFIDENTIALITY NOTICE > This message and any attachments are intended only for use by the named > addressee and may contain privileged and/or confidential information. If you > are not the named addressee you should not disseminate, copy or take any > action in reliance on it. If you have received this message in error, please > contact the sender immediately and delete the message and any attachments > accompanying it. Digia Germany GmbH and Digia Plc do not accept liability for > any corruption, interception, amendment, tampering or viruses occurring to > this message. > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Stepping down as maintainer
> However, I've recently decided to follow a different path and I will no > longer be able to maintain the text editors and C++ language support. Thanks for all your work. The C++ language/API assistance implementation in Qt Creator is great to work with. Regards, Rob. On 20 September 2012 22:08, wrote: > Hi everyone, > > it's been an awesome time participating in the development of Qt Creator. > However, I've recently decided to follow a different path and I will no > longer be able to maintain the text editors and C++ language support. A new > maintainer will be suggested soon. > > Thanks for all of those who contribute to the success of Qt and let it > continues to rock! > > > Kind regards, > Leandro T. C. Melo > > ___ > 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] Maintainer for Editors&C++support in Qt Creator
I certainly second Erik's proposal. Kind regards, Leandro T. C. Melo From: development-bounces+leandro.melo=nokia@qt-project.org [development-bounces+leandro.melo=nokia@qt-project.org] on behalf of Ziller Eike (EXT-Digia/Berlin)-Qt Sent: Friday, September 21, 2012 9:49 AM To: development@qt-project.org Cc: list Subject: [Development] Maintainer for Editors&C++support in Qt Creator I propose Erik Verbruggen as the new maintainer for Editor & C++ Support in Qt Creator, taking over the responsibilities from Leandro who unfortunately left us. Erik has already been working on the language support in Qt Creator for a long time, including the whole c++ preprocessor in 2.6, work on the C++11 support, and the Clang initiative. -- Eike Ziller Senior Software Engineer Digia Germany GmbH Rudower Chausse 13, 12489 D-Berlin Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B, Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Email: eike.zil...@digia.com Tel: +49 30 63 92 32 55 Digia Germany is a group company of Digia Plc, Valimotie 21, FI-00380 Helsinki Finland Visit us at: www.digia.com -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Germany GmbH and Digia Plc do not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. ___ 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] Retina display support
On 21 Sep 2012, at 07:12, Kai-Uwe Behrmann wrote: > Am 20.09.12, 19:09 -0700 schrieb P Bai: >> I have a few questions about how to add retina display support to my >> application. I understand by reading an earlier discuss that you can add a >> few lines in the info.plist to enable HiDPI render. That would only work for >> text and standard widgets, right? Right. >> How about icons and pixmaps? How do I detect if the application is running >> in HiDPI mode? At the moment only through platform API, e.g. UIScreen scale >> For example if I write an image viewer program, how do I know when to draw a >> high resolution image? I guess I can just always force draw the high-res >> image to the rect of a regular sized image, I don't think that would work atm. Afaik Qt doesn't draw at "sub-point" coordinates as is and would downscale your high-res image to the point size of the rectangle. (See below for an explanation what I mean with that.) Morten Sørvig is working on a solution for the HiDPI issue, a (probably outdated) experiment is on https://codereview.qt-project.org/33266 >> but that would be a huge waste of system resource and performance drag when >> running on non-retina system. Are there any better solutions? > > Aren't you seeing the window size in pixels as usual? With that available, > you would have a generic answere for your kind of question. Well, no. "Pixel" in the Qt world atm means something different than "pixel" in the physical world (when talking about Cocoa / Mac). The integer coordinates in Qt actually are mapped to what Cocoa calls "points" which is referring to "logical" coordinate space, not "device" coordinate space. A HiDPI screen has the same number of "points" as a corresponding non-HiDPI screen, but it has a "scale" (of 2). Applications see the same number of points when they run on a HiDPI screen as they would on a non-HiDPI screen (--> everything has exactly the same physical dimensions when running on different screens). That means that Qt also reports the same dimensions. Rastering for pixmaps is also done based on "points". -- Eike Ziller Senior Software Engineer Digia Germany GmbH Rudower Chausse 13, 12489 D-Berlin Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B, Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Email: eike.zil...@digia.com Tel: +49 30 63 92 32 55 Digia Germany is a group company of Digia Plc, Valimotie 21, FI-00380 Helsinki Finland Visit us at: www.digia.com -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Germany GmbH and Digia Plc do not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] required QTextBoundaryFinder behavior [and API] fixes
Had a chat with Konstantin on IRC today. We agreed to go for a1-a3 for now. In
addition, iteration will start at -1 (ie. an invalid boundary), so that you can
get all info by doing a loop starting with toNextBoundary().
But it needs to go in before beta 2, and all usages of QTBF in qt5.git and
qt-creator.git need to be checked and fixed where required.
We can still consider adding a QTextBreakIterator class in 5.x if it gives
makes things better or faster.
Cheers,
Lars
On Sep 10, 2012, at 8:27 PM, ext Konstantin Ritt wrote:
> Hi folks,
>
> In fact, the current QTBF behaves just like if it were a broken break
> iterator...
> I mean that, [Issue1] despite it's name, it stops at every break
> opportunity and reports NotAtBoundary via boundaryReasons() method for
> the break opportunities that are not boundaries (this affects Line and
> Word modes).
> [Issue2] As for Grapheme and Sentence modes, there are no optional
> break opportunities and thus such behavior is ok, except of
> boundaryReasons() does a wild guess based on surrounding white space
> characters
> and reports (StartWord | EndWord) or NotAtBoundary reasons most of the time.
> [Issue3] All this requires the developer to use two different
> iteration models according to which of QTBF modes is currently set:
> iterating by using toNextBoundary() - for Grapheme and Sentence modes,
> and iterating by using toNextBoundary() with extra checking the
> boundaryReasons() result - for Line and Word modes.
>
> But even then, there is no guarantee QTBF will produce expected results.
> A good example of what I'm saying about is searching the word
> start/end positions at some [arbitrary] position:
>
> [code] // -- from src/plugins/platforms/windows/qwindowsinputcontext.cpp:~560
>// Find the word in the surrounding text.
>QTextBoundaryFinder bounds(QTextBoundaryFinder::Word, surroundingText);
>bounds.setPosition(pos);
>if (bounds.isAtBoundary()) {
>if (QTextBoundaryFinder::EndWord == bounds.boundaryReasons())
>bounds.toPreviousBoundary();
>} else {
>bounds.toPreviousBoundary();
>}
> const int startPos = bounds.position();
> bounds.toNextBoundary();
> const int endPos = bounds.position();
> [/code]
>
> In the code above, if the surroundingText doesn't contain a word or if
> it ends up with a several white space characters at \a pos, then the
> result is a garbage.
>
>
> I see a two major ways to fix the behavior and make the iteration
> process consistent unaware of which mode is in use:
>
> A) a1. introduce BreakOpportunity BoundaryReason enum value and make
> boundaryReasons() report BreakOpportunity (instead of NotAtBoundary)
> for the break opportunities that are not boundaries in Line and Word
> modes, and for the boundaries in Grapheme and Sentence modes;
>a2. introduce MandatoryBreak BoundaryReason enum value and make
> boundaryReasons() report MandatoryBreak (instead of combination of
> StartWord and EndWord values) for the mandatory line breaks (CR, LF,
> NEL, EOT);
>a3. make boundaryReasons() carefully report StartWord and/or
> EndWord exactly for word start and word end positions.
>
> B) b1. fix QTBF to *not* stop at break opportunities that are not
> boundaries in Line and Word modes in order to fix Issue1;
>b2. apply a2 and a3 to QTBF in order to fix Issues 2 and 3;
>b3. introduce a new QTextBreakIterator class that would implement
> everything described in A (this could be delayed for 5.1). Then, QTBF
> could be a cheap convenience layer on top of QTBI. Alternatively, QTBI
> could provide both "toNextBreak()" and "toNextBoundary()" methods in
> order to replace QTBF completely.
>
> Either way, a major impact of such a change is that that
> boundaryReasons() will never report StartWord/EndWord in modes other
> than Word + boundaryReasons() will never report NotAtBoundary when
> toPreviousBoundary()/toNextBoundary() stops at a valid position.
> Because of QTBF is broken-by-design and the code that uses it should
> be revised anyways, I believe Qt5 is a most-correct time to fix it and
> such an API and behavior change is still acceptable for 5.0 even now,
> after beta1 is released.
>
> I, personally, like the second option quite more.
> What do you think? Any objections on making described changes in 5.0?
>
> Kind regards,
> Konstantin
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Maintainer for Editors&C++support in Qt Creator
A very strong +1 -Original Message- From: development-bounces+bill.king=nokia@qt-project.org [mailto:development-bounces+bill.king=nokia@qt-project.org] On Behalf Of Ziller Eike (EXT-Digia/Berlin)-Qt Sent: 21 September 2012 09:49 To: development@qt-project.org Cc: list Subject: [Development] Maintainer for Editors&C++support in Qt Creator I propose Erik Verbruggen as the new maintainer for Editor & C++ Support in Qt Creator, taking over the responsibilities from Leandro who unfortunately left us. Erik has already been working on the language support in Qt Creator for a long time, including the whole c++ preprocessor in 2.6, work on the C++11 support, and the Clang initiative. -- Eike Ziller Senior Software Engineer Digia Germany GmbH Rudower Chausse 13, 12489 D-Berlin Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B, Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Email: eike.zil...@digia.com Tel: +49 30 63 92 32 55 Digia Germany is a group company of Digia Plc, Valimotie 21, FI-00380 Helsinki Finland Visit us at: www.digia.com -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Germany GmbH and Digia Plc do not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Maintainer for Editors&C++support in Qt Creator
I propose Erik Verbruggen as the new maintainer for Editor & C++ Support in Qt Creator, taking over the responsibilities from Leandro who unfortunately left us. Erik has already been working on the language support in Qt Creator for a long time, including the whole c++ preprocessor in 2.6, work on the C++11 support, and the Clang initiative. -- Eike Ziller Senior Software Engineer Digia Germany GmbH Rudower Chausse 13, 12489 D-Berlin Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B, Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Email: eike.zil...@digia.com Tel: +49 30 63 92 32 55 Digia Germany is a group company of Digia Plc, Valimotie 21, FI-00380 Helsinki Finland Visit us at: www.digia.com -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Germany GmbH and Digia Plc do not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Stepping down as maintainer
21.09.2012, 01:08, "leandro.m...@nokia.com" : > Hi everyone, > > it's been an awesome time participating in the development of Qt Creator. > However, I've recently decided to follow a different path and I will no > longer be able to maintain the text editors and C++ language support. A new > maintainer will be suggested soon. > > Thanks for all of those who contribute to the success of Qt and let it > continues to rock! We will miss you :( -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
