Re: [Qt5-feedback] Qt5 lighthouse plugins and clean up on exit
On 09/29/2011 10:59 PM, ext Holger Freyther wrote:
Holger Freytherholgerat freyther.de writes:
Hi,
it appears to me that the EventDispatcher and FontDatabase are leaked
on exit (even on the XCB plugin). Is there any plan to resolve that?
One example that got introduced when Qt Quick2 was imported into the
qtbase repository.
operator new(unsigned int) (vg_replace_malloc.c:255)
QUnifiedTimer::instance(bool) (qabstractanimation.cpp:183)
QAnimationDriver::~QAnimationDriver() (qabstractanimation.cpp:461)
QDefaultAnimationDriver::~QDefaultAnimationDriver()
QUnifiedTimer::~QUnifiedTimer()
QUnifiedTimer::~QUnifiedTimer() (qabstractanimation_p.h:146)
void qThreadStorage_deleteDataQUnifiedTimer(void*, QUnifiedTimer**)
QThreadStorageQUnifiedTimer*::deleteData(void*) (qthreadstorage.h:140)
QThreadStorageData::finish(void**) (qthreadstorage.cpp:203)
QCoreApplicationPrivate::cleanupThreadData() (qcoreapplication.cpp:377)
QGuiApplicationPrivate::~QGuiApplicationPrivate() (qguiapcpp:406)
QApplicationPrivate::~QApplicationPrivate() (qapplication.cpp:208)
QApplicationPrivate::~QApplicationPrivate() (qapplication.cpp:212)
QScopedPointerDeleterQObjectData::cleanup(QObjectData*)
...
the easiest fix would be:
QAnimationDriver::~QAnimationDriver()
{
-QUnifiedTimer *timer = QUnifiedTimer::instance(true);
-if (timer-canUninstallAnimationDriver(this))
+QUnifiedTimer *timer = QUnifiedTimer::instance(false);
+if (time timer-canUninstallAnimationDriver(this))
uninstall();
}
ask the 'factory' to not create an instance. I could only trace this
code back to import of Qt Quick2 (anyone has nice git grafts?). Can
we get a 'clean' shutdown into the goals of Qt5, even if it is only
done in a debug build?
Clean shutdown is something that's needed, but that hasn't been
prioritized as much as certain more 'visible' issues so far. Could you
create tasks for all the issues you see? Maybe we should label all Qt 5
related issues with #qt5 from now on. There's
https://bugreports.qt.nokia.com/browse/QTBUG-20080 but it seems
impractical add all bug reports as sub-tasks there (it's mainly meant
for todos, features, and required API changes). Although if it's a more
generic sub-task like Clean shutdown that could work, but we still
want to track each issue individually (through sub-sub-tasks?).
--
Samuel
___
Qt5-feedback mailing list
Qt5-feedback@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Safe access to QPlatformNativeInterface resources
On 09/29/2011 02:43 PM, ext Girish Ramakrishnan wrote: Hi, On Thu, Sep 29, 2011 at 5:25 PM, Paul Olav Tvetepaul.tv...@nokia.com wrote: On Thursday 29 September 2011 13:33:28 ext Thiago Macieira wrote: A wayland server has nothing to do with the wayland plugin to lighthouse, aside from the fact that they speak the same protocol and may be using the same low-level library. The low-level library in question is Qt :p Samuel used this example to show that being able to use two different platform plugins on the same system, without having to have two separate installations of Qt, is not just a cool geeky feature: it's absolutely essential for the Wayland use case. Once you have chosen to use Qt on Wayland, the only sane choice is to use Qt to implement your compositor too. I mean, we use Qt because we don't actually enjoy low-level C programming. The Wayland compositor will then be run with a command line like qwindow-compositor -platform eglfs -plugin linuxinputmouse while the client will do something like hellowindow -platform wayland Exactly the same Qt libraries involved, but two different lighthouse back-ends. Yes, this is a very good reason to have platform plugins. As I explained a little more on irc, I wanted to see if we could build the lighthouse code as (dynamic) plugins with just -nokia-developer builds. For normal builds, it would compile them statically and an app could figure which platform was in use using ifdefs. This way I could do in the app code #ifdef QPA_X11 #includeXlib.h #elif defined(QPA_XCB) ... #endif With the current approach to platforms as plugins, the app has to load symbols dynamically OR link to both Xlib+Xcb. In this case you might be able to use the X display and Xlib whether the xcb or xlib plugin is being used, since xcb is also using Xlib internally for _some_ stuff that's not supported by pure xcb (like GLX). Just to take my idea to conclusion before we kill it, can the wayland and eglfs platforms be merged into one :) ? i.e we have a QPA_WAYLAND and the platform plugin code itself determines what mode it is (presumably by passing some command line option). In some ways this is like the -qws option where the server and client reside in same library. It's possible, but might lead to slightly messier plugin code and is less practical during development since it makes it harder to test the application against multiple backends (both wayland and using the same backend the compositor uses to run non-composited). We also test qt-compositor using at least xcb, xlib, kms, openwf backends, not just eglfs. And since you're in charge of configuring Qt in this case it's still up to you to know which platform plugin is being used. In the end, if you have the power to do a static build where the plugin is known at compile time, you probably also have the power to limit yourself to that plugin whether it's done statically or dynamically. -- Samuel ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Web service functionality in Qt5
Sorry for the delay, I was busy the whole week. OK, so I'll move my code into and add-on. I've looked through a ton of documents, mostly QtDN wikis and Qt documentation, a few new questions have emerged. 1) I cannot find a definite answer on what is actually considered to be an add-on. For example, the newly separated widgets is said to be an add-on, and resides in qt5/qtbase/src/widgets. QtXmlPatterns is also considered an add-on, but occupies a full separate repo at qt5/qtxmlpatterns. Where should I put my code, then? Into Qt5 main repository, or into qtbase? I would kind of opt for the former, as it would help me keep sources, examples and tests in one place (for example qt5/qwebservice). 2) What about tests and examples? Tests for various add-ons that reside inside qtbase seem to be placed there in a more or less random fashion, with some having their own subfolders, while others happily share directory structure with the rest of the suite (that is, with tests of Qt Essentials). 3) Can I include the WSDL converter application in my add-on, or does it have to stay separate? 4) Should I delete my current merge request now? Cheers, sierdzio On 23 September 2011 22:15, lars.kn...@nokia.com wrote: I've filled merge request (#51) for QWebService (converter is temporarily waiting), and got some feedback from Thiago. He did propose to move my sources from QtNetwork into an add-on. I find this idea very good, but wish to enquiry here. What is your view on that? (if anyone happens to have any, that is). Same view as Thiago from my side. Having it as an addon is IMO the best solution here. It gives you some more freedom in terms of developing and maintaining the code and I personally also don't want to add this directly to QtNetwork. Cheers, Lars ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Web service functionality in Qt5
On Friday, 30 de September de 2011 11:18:05 Tomasz Siekierda wrote: 1) I cannot find a definite answer on what is actually considered to be an add-on. For example, the newly separated widgets is said to be an add-on, and resides in qt5/qtbase/src/widgets. QtXmlPatterns is also considered an add-on, but occupies a full separate repo at qt5/qtxmlpatterns. Where should I put my code, then? Into Qt5 main repository, or into qtbase? I would kind of opt for the former, as it would help me keep sources, examples and tests in one place (for example qt5/qwebservice). Hi Tomasz The definition is somewhat in flux. I think Henry produced some documents and placed them on the QtDN. We divide Qt into the Qt essentials and the addons. The essentials are those libraries and repositories that all installations of Qt offering Qt as an API must have: that's Qt Base, Qt Quick and QtWebKit. Everything else is an addon, some of which will become quite standard and widespread. As for the qt5 repository, it was created as a way for ease transition from Qt 4. But I'm personally not sure how we should treat it going forward. For example, the qtphonon sub-module makes no sense to continue, as Phonon building should be done using CMake, not qmake. 2) What about tests and examples? Tests for various add-ons that reside inside qtbase seem to be placed there in a more or less random fashion, with some having their own subfolders, while others happily share directory structure with the rest of the suite (that is, with tests of Qt Essentials). They should stay as close as possible to the code itself. The randomness you see is a result of moving legacy code around. 3) Can I include the WSDL converter application in my add-on, or does it have to stay separate? Keep it together if you think it's useful. 4) Should I delete my current merge request now? You can leave it there, but it won't get merged to QtNetwork. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] MIME type support in Qt5
On Friday 30 September 2011 11:11:47 Wolf-Michael Bolle wrote: It took me a while but I have a code base now for QtCreator that keeps all� previous functionality. For that I separated the MIME type handling code in QtCreator in the stuff that� is also in qmime and the application-specific code that needs to run on top of that. The continued development in the qmime repository made this task quite challenging. Until the code in qmime becomes a part of Qt 5 I'd likd to keep the code synchronzied between the qmime and the QtCreator repository. Who should I contact about adding my changes into QtCreator? My favorite� scenario would be to add a branch where I add changes step by step. Is there a� review person I should contact? How do you integrate contributors into the QtCreator team? Thanks in advance IMHO this is premature; at some point I'll change qmime to use QStandardPaths to locate the mimetype files to read; shouldn't QtCreator simply install XML files into the right location? That will make its code quite different from what you probably have right now. And meanwhile you'll have to keep syncing the two copies and porting the code all the time... -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Qt5-feedback Digest, Vol 5, Issue 104
Thanks a lot, Thiago, you're a diamond. The definition is somewhat in flux. I think Henry produced some documents and placed them on the QtDN. [...] As for the qt5 repository, it was created as a way for ease transition from Qt 4. But I'm personally not sure how we should treat it going forward. For example, the qtphonon sub-module makes no sense to continue, as Phonon building should be done using CMake, not qmake. The 2 most advertised ones are the product definition (http://developer.qt.nokia.com/groups/qt_contributors_summit/wiki/Qt5ProductDefinition), and Qt 5.0 wiki (http://developer.qt.nokia.com/wiki/Qt_5.0), they are certainly informative in general way, but lack some essential details (it's not a reproach, I know it's still a work in progress, no problem there). I'm afraid this may trigger some big discussion on the subject (which is probably good), as it turns out to be about contribution in general. Ben (responsible for QtDeamonService) seems to be in similar position to mine here, and more people might be in the future, so I guess it should be discussed/clarified in detail. Ben put his work into Qt5 repository itself. If every person, including me, is expected to do that, it should be put in clear text somewhere. But, most of the Qt stuff is included in the repo as a git submodule. Now, if that is the desired way of contributing an add-on, then how exactly is anything going to be accepted into Qt? A contributor would have to create his own repository, then add it as a submodule to qt5 clone and request merge of just the git submodule? This will lead to a more distributed qt source, as some submodules would not actually reside in qt.gitorious.org/qt. Thinking about it now, I realized it might be a bit too early to ask, as qt-project is still not open. But even a good 'official' hint as to what to expect would be nice, or - if it's not been decided yet internally - a discussion. Which leaves me in a situation, where I still do not know what to do :) I don't want to flood you with more problematic merge requests, but make just one, that would be well placed and with good code quality. They should stay as close as possible to the code itself. The randomness you see is a result of moving legacy code around. Ok, that's what I've suspected, thanks. Good day to you, sierdzio/ Thomas/ Tomasz/ whatever ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] MIME type support in Qt5
On Friday 30 September 2011 11:11:47 ext Wolf-Michael Bolle wrote: For that I separated the MIME type handling code in QtCreator in the stuff that is also in qmime and the application-specific code that needs to run on top of that. The continued development in the qmime repository made this task quite challenging. Until the code in qmime becomes a part of Qt 5 I'd likd to keep the code synchronzied between the qmime and the QtCreator repository. Who should I contact about adding my changes into QtCreator? My favorite scenario would be to add a branch where I add changes step by step. Is there a review person I should contact? How do you integrate contributors into the QtCreator team? A merge request on gitorious is currently probably the easiest to handle. Andre' ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QStringLiteral vs QLatin1String performance
On Friday, 30 de September de 2011 12:57:28 Kent Hansen wrote: Hi, You might have seen Thiago's blog about QStringLiteral [1], and his idea on replacing QLatin1String usage by QStringLiteral in Qt (where possible). I like the idea, but wanted to do some benchmarking first to get an impression of the performance impact. [2] My results so far (on Linux 32-bit) indicate that QString::appends are way faster when switching to using QStringLiteral: 7x faster than QLatin1String for a 2-character literal and 14x for a ~50-character literal. Not unexpected. The conversion from Latin 1 to UTF-16 required for the appending needs to be done at runtime for a QLatin1String, whereas the compiler does it with QStringLiteral. And that's assuming you didn't get an implicit conversion to QString somewhere. QString::append has a QLatin1String overload, but some methods don't and those cause a temporary to be created, which involves a malloc (non- deterministic time). Now, the not-so-good news: operator==(QString) is a bit (just a bit) slower than operator==(QLatin1String) for short strings. It seems that, for short strings, the overhead of calling qMemEquals() and performing its housecleaning chores outweigh the benefits of its fast comparison loop. Sounds like the result I found in the investigation of using SIMD in QString: the best algorithm is the least complex possible. There are some better algorithms for qMemEquals in tests/benchmarks/corelib/tools/qstring.cpp (the ucstrncmp functions). But as the comment above qMemEquals shows, the performance varies a lot depending on the architecture. In other words, if someone were to optimize QString::operator==(QString) to perform better for small strings, the total replacement would be a done deal. The code is already there. Just replace qMemEquals with the contents of ucstrncmp_sse2, but you need to keep the generic code for other architectures. They'll still benefit on the unrolling of the loop for small strings (less than 8 characters). As for Neon optimisation, the lack of a movemask instruction like SSE2 makes it very hard to produce optimal code. If you look at fromUtf8_neon, you'll see you need to execute two Neon instructions, two comparisons and then rbit and clz. If anyone wants to try this, be my guest. I won't be doing any more Neon optimisations :-) -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QStringLiteral vs QLatin1String performance
On Friday 30 September 2011 12:57:28 Kent Hansen wrote: Hi, You might have seen Thiago's blog about QStringLiteral [1], and his idea on replacing QLatin1String usage by QStringLiteral in Qt (where possible). I like the idea, but wanted to do some benchmarking first to get an impression of the performance impact. [2] You could have used template instead of macros :-) My results so far (on Linux 32-bit) indicate that QString::appends are way faster when switching to using QStringLiteral: 7x faster than QLatin1String for a 2-character literal and 14x for a ~50-character literal. That is because you append to a null string. Appending a QString to a null string is equivalent to the operator= (that is, only setting a pointer) could you change the benchmark to append to something? Also, appending with QLatin1String currently do not do the sse2 fromLatin1, it would be trivial do so by extracting the fromLatin1 code to a helper helper function. Now, the not-so-good news: operator==(QString) is a bit (just a bit) slower than operator==(QLatin1String) for short strings. It seems that, for short strings, the overhead of calling qMemEquals() and performing its housecleaning chores outweigh the benefits of its fast comparison loop. It would be nice to compare with different lenght AND different on the first char. Or better, with actual data extracted form a qDebug in the operator== for a random application. In other words, if someone were to optimize QString::operator==(QString) to perform better for small strings, the total replacement would be a done deal. Another thing that need to be taken in account is that QStringLiteral takes more memory in the binary. Hence, more cache misses. This is difficult to show in a benchmark that runs over the same data all the time. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QStringLiteral vs QLatin1String performance
Den 30. sep. 2011 14:11, skrev ext Olivier Goffart: On Friday 30 September 2011 12:57:28 Kent Hansen wrote: Hi, You might have seen Thiago's blog about QStringLiteral [1], and his idea on replacing QLatin1String usage by QStringLiteral in Qt (where possible). I like the idea, but wanted to do some benchmarking first to get an impression of the performance impact. [2] You could have used template instead of macros :-) Nope :) My results so far (on Linux 32-bit) indicate that QString::appends are way faster when switching to using QStringLiteral: 7x faster than QLatin1String for a 2-character literal and 14x for a ~50-character literal. That is because you append to a null string. Appending a QString to a null string is equivalent to the operator= (that is, only setting a pointer) could you change the benchmark to append to something? Good point :) Also, appending with QLatin1String currently do not do the sse2 fromLatin1, it would be trivial do so by extracting the fromLatin1 code to a helper helper function. So appending QLatin1String can be made faster?! That's horrible news, we want QStringLiteral to beat it massively, remember :P Now, the not-so-good news: operator==(QString) is a bit (just a bit) slower than operator==(QLatin1String) for short strings. It seems that, for short strings, the overhead of calling qMemEquals() and performing its housecleaning chores outweigh the benefits of its fast comparison loop. It would be nice to compare with different lenght AND different on the first char. Or better, with actual data extracted form a qDebug in the operator== for a random application. Lots of good ideas here, please update the benchmark and pass it around :D In other words, if someone were to optimize QString::operator==(QString) to perform better for small strings, the total replacement would be a done deal. Another thing that need to be taken in account is that QStringLiteral takes more memory in the binary. Hence, more cache misses. This is difficult to show in a benchmark that runs over the same data all the time. Yeah. On a related note, I replaced as many QLatin1Strings by QStringLiteral in QtCore as possible, and the library size increase was 1% (40K) on ia32. Regards, Kent ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QStringLiteral vs QLatin1String performance
On Friday 30 September 2011 14:11:33 ext Olivier Goffart wrote: Another thing that need to be taken in account is that QStringLiteral takes more memory in the binary. Actually quite a few of the string literals we have in Creator are essentially plain ASCII identifiers that are only converted to QStrings to be able to interface QVariantMap, QSettings etc. I have this nagging gut feeling that it would be better for performance if these would take QByteArray keys instead. If someone has the desparate wish to use more than 7 bits for his key strings (I certainly don't), the convention could just be that the encoding is implicitly assumed to be UTF-8. I understand that this is (a) not possible to change, and (b) would mean falling back to the Dark Ages of std::string-with-uncertain-encoding, but still, we are discussing making a conversion fast that could be avoided altogether in a lot of cases by just having another API. Andre' ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QStringLiteral vs QLatin1String performance
30.09.2011, 16:54, Andr Pnitz andre.poen...@nokia.com: Actually quite a few of the string literals we have in Creator are essentially plain ASCII identifiers that are only converted to QStrings to be able to interface QVariantMap, QSettings etc. I have this nagging gut feeling that it would be better for performance if these would take QByteArray keys instead. If someone has the desparate wish to use more than 7 bits for his key strings (I certainly don't), the convention could just be that the encoding is implicitly assumed to be UTF-8. +1 char * would be fine too -- Regards, Konstantin ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QStringLiteral vs QLatin1String performance
On Friday, 30 de September de 2011 14:37:10 Kent Hansen wrote: Also, appending with QLatin1String currently do not do the sse2 fromLatin1, it would be trivial do so by extracting the fromLatin1 code to a helper helper function. So appending QLatin1String can be made faster?! That's horrible news, we want QStringLiteral to beat it massively, remember :P Heh, talk about adjusting the data... Anyway, let me give you another argument: yes, you can make QString::append faster for QLatin1String. You can also make QString::prepend faster. And you can make QString::indexOf, QString::startsWith, QString::endsWith, etc. The point being: QLatin1String is an *additional* code path we'd need to optimise. If we can instead use the same codepath that is already optimal, it's probably better. Now, the not-so-good news: operator==(QString) is a bit (just a bit) slower than operator==(QLatin1String) for short strings. It seems that, for short strings, the overhead of calling qMemEquals() and performing its housecleaning chores outweigh the benefits of its fast comparison loop. It would be nice to compare with different lenght AND different on the first char. Or better, with actual data extracted form a qDebug in the operator== for a random application. Lots of good ideas here, please update the benchmark and pass it around :D Different-length comparison means qMemEquals isn't even called. Given that QLatin1String carries the length just like QString (QStringLiteral) does, those will have the exact same time. The question of comparison time is only for same-length. Note that includes startsWith and endsWith. Yeah. On a related note, I replaced as many QLatin1Strings by QStringLiteral in QtCore as possible, and the library size increase was 1% (40K) on ia32. I've got the same commit. It's a trivial increase. The only drawback is that, due to a bug in gcc 4.6, the read-only data initialised by a constexpr is placed in .data instead of .rodata. GCC 4.7 has that fixed. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QStringLiteral vs QLatin1String performance
On Friday 30 September 2011 16:55:53 Konstantin Tokarev wrote: Great news! Is it possible to use this superfast QStringLiteral with Qt 4.x? No. This is a binary incompatible change in QString. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QStringLiteral vs QLatin1String performance
30.09.2011, 17:00, Olivier Goffart oliv...@woboq.com: On Friday 30 September 2011 16:55:53 Konstantin Tokarev wrote: Great news! Is it possible to use this superfast QStringLiteral with Qt 4.x? No. This is a binary incompatible change in QString. It's sad to realize that many embedded and legacy platforms are banned from QString improvements because they don't support OpenGL ES 2. -- Regards, Konstantin ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QStringLiteral vs QLatin1String performance
On Friday, 30 de September de 2011 14:54:32 André Pönitz wrote: On Friday 30 September 2011 14:11:33 ext Olivier Goffart wrote: Another thing that need to be taken in account is that QStringLiteral takes more memory in the binary. Actually quite a few of the string literals we have in Creator are essentially plain ASCII identifiers that are only converted to QStrings to be able to interface QVariantMap, QSettings etc. I have this nagging gut feeling that it would be better for performance if these would take QByteArray keys instead. If someone has the desparate wish to use more than 7 bits for his key strings (I certainly don't), the convention could just be that the encoding is implicitly assumed to be UTF-8. I understand that this is (a) not possible to change, and (b) would mean falling back to the Dark Ages of std::string-with-uncertain-encoding, but still, we are discussing making a conversion fast that could be avoided altogether in a lot of cases by just having another API. For an application's internal data, if all it wants is to store 7-bit keys to variants, it can simply use QMapQByteArray, QVariant It doesn't have to use QVariantMap. That's what std::basic_string does: if you want to use something other than char, you can (hence, std::wstring). However, asking QSettings to have a QByteArray API is asking too much in my opinion. That would mean either implicit conversions anyway into the internal storage type, or increasing the complexity of every function dealing with the multiple types of keys. Neither option is interesting. Increasing the complexity of code means we may have lingering bugs for years due to less-tested codepaths, missing fixes that go to one branch but not the other, etc. It also means increased library size, increased runtime due to the extra checks when compared to the library taking one single type. The implicit conversions just hide the problem. Instead of doing the right thing and using QStringLiteral or caching your QStrings, you might be deceived into writing bad code. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QStringLiteral vs QLatin1String performance
On Friday, 30 de September de 2011 16:55:53 Konstantin Tokarev wrote: Great news! Is it possible to use this superfast QStringLiteral with Qt 4.x? No. The blog explains why. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] MIME type support in Qt5
Hi David, It took me a while but I have a code base now for QtCreator that keeps all previous functionality. For that I separated the MIME type handling code in QtCreator in the stuff that is also in qmime and the application-specific code that needs to run on top of that. The continued development in the qmime repository made this task quite challenging. Until the code in qmime becomes a part of Qt 5 I'd likd to keep the code synchronzied between the qmime and the QtCreator repository. Who should I contact about adding my changes into QtCreator? My favorite scenario would be to add a branch where I add changes step by step. Is there a review person I should contact? How do you integrate contributors into the QtCreator team? IMHO this is premature; at some point I'll change qmime to use QStandardPaths to locate the mimetype files to read; shouldn't QtCreator simply install XML files into the right location? That will make its code quite different from what you probably have right now. QtCreator actually provides a UI to modify the MIME type information that already is in the MIME database. Unfortunately you just brought up a problem with the approach I have been following. QtCreator allows you modify the entries in the MIME database. In my current code I allow that on the contents of the singleton that stores the information. I need to fix that. And meanwhile you'll have to keep syncing the two copies and porting the code all the time... I agree. That will not be nice. I need to cover the time though between now and when QtCreator may officially depend on a Qt MIME type addon. If I could add patches to QtCreator until the file structure of qmime could be used then synching the two copies wouldn't be that hard to maintain. What do you think? Michael ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] MIME type support in Qt5
On Friday 30 September 2011 15:33:29 Wolf-Michael Bolle wrote: QtCreator actually provides a UI to modify the MIME type information that already is in the MIME database. Yes, and so does KDE (keditfiletype). It's quite simple, when one just has to write an xml file into the user's dir and re-run update-mime-database. Unfortunately you just brought up a problem with the approach I have been following. QtCreator allows you modify the entries in the MIME database. In my current code I allow that on the contents of the singleton that stores the information. I need to fix that. Not sure I understand the issue. And meanwhile you'll have to keep syncing the two copies and porting the code all the time... I agree. That will not be nice. I need to cover the time though between now and when QtCreator may officially depend on a Qt MIME type addon. Well we could port QtCreator to qmime once qmime is done; I don't see why we (well, you) need to port it regularly, that just seems like more work given that the whole technical solution will change (not just API bits). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. Konqueror (http://www.konqueror.org). ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] QStringLiteral vs QLatin1String performance
On Friday, 30 de September de 2011 17:20:58 Konstantin Tokarev wrote: 30.09.2011, 17:00, Olivier Goffart oliv...@woboq.com: On Friday 30 September 2011 16:55:53 Konstantin Tokarev wrote: Great news! Is it possible to use this superfast QStringLiteral with Qt 4.x? No. This is a binary incompatible change in QString. It's sad to realize that many embedded and legacy platforms are banned from QString improvements because they don't support OpenGL ES 2. Install Mesa. I thought the message was clear. Some benchmarks showed that the Mesa-based software OpenGL support is faster than the Qt raster engine. If you want to backport the QString changes to Qt 4 in your project, you can. We can't do it because of the binary incompatibility. Don't forget to upgrade to GCC 4.6. Anything less and you're better off leaving as it is. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
[Qt5-feedback] Replace qmake with cmake??
Hello, from time to time i have heard rumours tha Qt5 will use cmake instead of qmake. Is that correct? I believe that it is pointless to mention the pros of cmake and the big feedback that it receives. thanks in advance -- Tsiapaliwkas Giorgos (terietor) KDE Developer terietor.gr ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Replace qmake with cmake??
On Friday, 30 de September de 2011 12:18:06 Giorgos Tsiapaliwkas wrote: Hello, from time to time i have heard rumours tha Qt5 will use cmake instead of qmake. Is that correct? No. No decision has been made to move. So for the moment we stick to what we have. But if someone did the work and proved it to work, we probably wouldn't say no. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
Re: [Qt5-feedback] Replace qmake with cmake??
On 9/30/11 10:21 PM, ext Thiago Macieira thi...@kde.org wrote: On Friday, 30 de September de 2011 12:18:06 Giorgos Tsiapaliwkas wrote: Hello, from time to time i have heard rumours tha Qt5 will use cmake instead of qmake. Is that correct? No. No decision has been made to move. So for the moment we stick to what we have. Let's not change this for 5.0. Changing the build system is something that can be potentially rather disruptive to our work. We'd then deal with both changing larger pieces in the architecture as well as a changing build system. It's better to look at options there once Qt itself has a stable branch to work with again (ie. after we have 5.0). Cheers, Lars But if someone did the work and proved it to work, we probably wouldn't say no. ___ Qt5-feedback mailing list Qt5-feedback@qt.nokia.com http://lists.qt.nokia.com/mailman/listinfo/qt5-feedback
