Re: [Development] QtContacts - New class QContactCollection
On Monday 19 January 2015 17:27:40 Renato Araujo wrote: Hey guys, I started to implement the class QContactCollection based on QOrganizeCollection[1]. Until now I just copy the code from QOrganizer module and renamed some classes. The idea of QContactCollection is to represent an address-book. And with this we can create/remove/modify collection and query contacts based on the collection id. This looks great, but I have one concern about that. How to represent contacts that are present in more than one Address book (merged contacts)? In this case the contact can have more than one collection. Do you have any idea how to solve that? Should we use a different approach? What about use QContactCollectionId as a derived class from QContactDetails? Is QtPim still alive? Anyhow, sounds like you are reinventing KPeople from KDE. Maybe you could reuse that instead, and polish it to fit your needs? Bye -- Milian Wolff m...@milianw.de http://milianw.de ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtContacts - New class QContactCollection
That type was in fact added, as QContactType::TypeFacet in commit 03be9e28b. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Monday 19 January 2015 15:01:20 Harri Porten wrote: On Sun, 18 Jan 2015, Kevin Kofler wrote: Thiago Macieira wrote: The one requirement that came from the Qt Project was that the tools would not be renamed. And the one requirement that came from the distros was that the tools must be renamed. This was made very clear from the beginning. All other solutions are and will always be inherently flawed. You also never gave any convincing argument as to why you refused to rename the binaries. Distributors are going a great job creating Qt packages. But not everyone is using their distro's Qt. In fact, looking at our customers I'd say that most of them have their own Qt install somewhere on their disk. Possible several installations even. Renamed binaries won't cope with that variety. Our product relies on a --with-qmake switch or PATH for selection. Version detections follows wherever named. Renamed binaries won't help. Or even make our life harder as it needs to be. I think there is a point which we might be missing in this long thread. For Qt5 we are not asking for a simple rename because that *would* break stuff for other people, and that's not fair. What we ask is *adding* an executable with a suffixed -qt5, be it as a symlink where the OS allows it or as copy of the executable if there is no other way out. And we want to do it upstream because it's by far the best place to standardize it, because we also want people to build only one code to rule them all ;) -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.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
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 01:11:55 Lisandro Damián Nicanor Pérez Meyer wrote: On Monday 19 January 2015 19:30:46 Thiago Macieira wrote: [snip] So, as Sune Vuorela also explained, having multiple major versions of Qt in parallel is always going to be a fact of life. Indeed, but the Qt devs' original proposal was to simply put it outside /usr/bin, possibly even outside of $PATH. If distros had accepted to install Qt in (say) /opt/qt5, there would have been no qtchooser, no renaming and no need for change anywhere in our buildsystem. But distros refused to do what we asked... For the sake of completeness, we are not allowed to do so in the same strength that the Qt project doesn't allows binary incompatibility between minor versions, and for which us downstreamers are very grateful :) I know you're not allowed to do that, but there's no technical reason why that is so. Unlike binary compatibility. It's a choice. But contrast that to the distros asking for the renaming and the majority of Qt developers rejecting that. The ideal solution for either group was rejected outright as soon as the discussion began. So we had to come up with alternatives and compromises. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 01:49:01 Lisandro Damián Nicanor Pérez Meyer wrote: For the sake of completeness, we are not allowed to do so in the same strength that the Qt project doesn't allows binary incompatibility between minor versions, and for which us downstreamers are very grateful :) I know you're not allowed to do that, but there's no technical reason why that is so. Unlike binary compatibility. It's a choice. You might want to take the Filesystem Hierarchy Standard as a technical reason, plus the fact that we do our best to keep stuff installed by packages away from stuff installed by the system's admin, like /opt, simply to avoid problems. The FHS does not restrict /opt to admin-installed packages. It simply says add-on application software packages, unlike /usr/local, for which it says for use by the system administrator when installing software locally. Is it in that same light of alternatives and compromises that I'm at least asking to reconsider the case of user-facing stuff, and to take into consideration all the experience we gained during this for the next major release. We distros might not get the best solution, but at least let's work to try to let users don't get into bugs we know might happen. I'm willing to hear it again, but only if people agree to approach it with an open mind. Given the emails by both Kevin and Ossi, I don't think we'll have that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 00:57:55 Lisandro Damián Nicanor Pérez Meyer wrote: qdbus should be the same in all versions. I don't plan on making breaking changes in the future -- I can't see what I could do to create such problems... I just wrote an example in another mail, supposing a feature is added. We might argue that the same could be said for assistant, but at least that one is fairly obvious to spot ;) Indeed, applications wouldn't be able to depend on the new feature because qdbus would be the old, Qt 4 version. Which is why I think the solution of having some binaries be declared user applications and the other non-user-facing tools was superior. But it's not the solution we went for. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 00:47:50 Lisandro Damián Nicanor Pérez Meyer wrote: I think there is a point which we might be missing in this long thread. For Qt5 we are not asking for a simple rename because that *would* break stuff for other people, and that's not fair. What we ask is *adding* an executable with a suffixed -qt5, be it as a symlink where the OS allows it or as copy of the executable if there is no other way out. You're forgetting the documentation. It's not just adding the symlink or new binary. We have to tell people that this is what they should use. If we're going to do this, we should do it for ALL operating systems and all builds, plus adapt Qt Creator. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Monday 19 January 2015 18:44:14 Thiago Macieira wrote: On Sunday 18 January 2015 18:06:45 Lisandro Damián Nicanor Pérez Meyer wrote: If I'm wrong then simply unmasking qdbus with qtchooser should be enough. /usr/bin/qdbus should be provided by the default version (qt4's one in our case) and we might even let qt5-qdbus depend upon it's qt4 version, so packages depending on it would get both for the time being. If I'm *not* wrong then I have no other choice but to tell qt5-apps' maintainers to patch their software to call qdbus with the -qt5 parameter. And we can't even upstream those patches because on platforms other than Linux there is no qtchooser available, and most of the tools will fail saying a wrong parameter has been issued. So we have no other option than to keep a delta from upstream. qdbus should be the same in all versions. I don't plan on making breaking changes in the future -- I can't see what I could do to create such problems... I just wrote an example in another mail, supposing a feature is added. We might argue that the same could be said for assistant, but at least that one is fairly obvious to spot ;) -- The generation of random numbers is too important to be left to chance. http://www.devtopics.com/best-programming-jokes/ Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.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
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 05:06:10 Kevin Kofler wrote: Thiago Macieira wrote: I'm not sure I see the distinction between users and customers here. When you say users, are you thinking of a person who builds a Qt-using software from a 3rdparty? There are also developers who are not paying customers of Qt Commercial. Those developers using Qt Open Source will very often get it from their distribution, unless of course they are on an operating system that does not include Qt. I'm not making the distinction between paying and non-paying. I was trying to understand what Lisandro meant by customers. Given his other email, customer is the developer who writes Qt software, independent of how Qt was installed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 05:04:05 Kevin Kofler wrote: Remember: you (implicitly) agreed with the solution in 2012. I did not agree with anything at all. You brought up a discussion on a Qt Project mailing list, to which most distribution packagers are not even subscribed. You got only very limited feedback from distributors. You never bothered to approach distributors through places they follow, such as the kde-packager (at the time) mailing list (or even OUR mailing lists, or aliases such as qt-ow...@distro.example.com), at least not before the decision was made. It is only coincidence that I learned of the discussion at all, when it was already at a late stage. Assuming that all the people you did not ask agree with you just does not make any sense whatsoever. I specifically went out and asked packagers to join the discussion. I did post to kde-packager, so don't claim I didn't. So packagers knew about it. You can't claim ignorance of the discussion. What's more, you're saying that you knew about the discussion and intended on sending feedback, but didn't. If you choose not to voice your feedback, you're implicitly agreeing with the solution of those who did participate. Abstention does not give you the right to whatever you choose. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 05:04:05 Kevin Kofler wrote: Software on GNU/Linux often gets developed against distribution -devel packages. I definitely do that whenever possible. Do you really think that all developers of Qt-using software download your upstream binaries or build your source code themselves, when they can just yum install qt-devel? That said, what Qt setup is encountered of course depends on the distribution the developer(s) is/are using. No, I don't think all of them do. Just the majority. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] forkfd help on OS X 10.7
On Tuesday 13 January 2015 10:45:07 Thiago Macieira wrote: On Friday 02 January 2015 15:39:31 Thiago Macieira wrote: I need a little help with forkfd for OS X 10.7. The builds with forkfd have failed on the CI on 10.7 only for no reason I can determine. If you have access to 10.7 -- especially those in the CI system -- please build QtCore after checking out https://codereview.qt-project.org/102805 and run the attached simple program. If it locks up, please rerun with: sudo dtruss -dl ./qprocess-test 2trace Count to 5, Ctrl+C, then send me the trace file. Anyone? The build failed again and I can't tell why. http://testresults.qt-project.org/ci/QtBase_dev_Integration/build_05137/macx -clang_developer-build_qtnamespace_OSX_10.7/log.txt.gz Hi, it's been a week again and I still have no clue what to do. If we're going to drop OS X 10.7 support, please get it out of the dev CI run so I can stage my changes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] optimizing QComposeInputContext / TableGenerator?
On Monday 19 January 2015 20:48:54 Olivier Goffart wrote: On Monday 19 January 2015 20:15:22 Milian Wolff wrote: Hello all, when I run my heaptrack [1] tool on Qt 5 applications, I often stumble upon the compose TableGenerator. It initializes many QStrings and also consumes ruoghly 400KB of memory. I wonder whether we could optimize this somehow? The best approach of course would be to have a OpenDesktop standard that allows mmapping the compose table in and using it from there. Probably not feasible. Creating our own cache brings the usual issues of having to update the cache when the original changes... So what I wonder about is whether one could delay the table generation? I usually don't use the compose key, so my naive assumption would be that lazy-loading this table would help the common case of startup quite a bit already. Or is this required for other things that I don't expect? Looking at the hotspot from void TableGenerator::parseKeySequence: elem.value = QString::fromLocal8Bit(composeValue).at(0).unicode(); So if I understand correctly, it needs to convert the full line to QString just to take the first character. Surely this can be improved. It can, indeed. But funnily enough it's not going to be much faster, at least in the tests I did. Still, one should probably be doing this anyways. I'll try to dig up my patch for that and sent it to Gerrit. It's a pity that one cannot just convert a const char* to a QChar directly, i.e. without any allocations. One cannot even reuse the same QString buffer to my knowledge... The code is here: http://code.woboq.org/qt5/qtbase/src/plugins/platforminputcontexts/compose/g enerator/qtablegenerator.cpp.html#_ZN14TableGenerator16parseKeySequenceEPc But yes, some mmapable on-disk cache would probably be the best. One would just need to make sure that the cache is invalidated properly when it should. Which is a can of worms, but yes - probably worth it in the long run. I wonder whether this is handled by libxkbcommon. Bye -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
Oswald Buddenhagen wrote: correct. as far as i'm concerned, the purpose of qtchooser is to be a frontend tool which targets developers working with multiple qt versions, regardless whether these versions come from distro packages or own builds. The thing is, we asked for something that fulfills distro's needs. You shot that down and instead got Thiago to implement something different. And now you say yourself that it is not what was asked for. Developers working with multiple versions of Qt 5 are by far the minority. Most users of Qt development packages actually just want to compile software somebody else wrote. And even those that actually are developers are usually happy with our regularly-updated builds of the latest stable Qt release. To all those users, different major versions are the ONLY coinstallation case that matters. build systems which target specific (major) qt versions are simply out of scope. Says who? That is by far the common case. Very few programs support more than one major version of Qt. your problem is a self-made one: the attempt to co-install major versions of everything. As long as there are new major versions of Qt (i.e., new versions that are not 100% drop-in replacements for the previous version), there WILL be a need for coinstallation. Programs do not magically port themselves instantly. Even the upstream developers themselves need time to port things. Distribution packagers are usually not qualified to do such a port, so we need to wait for upstream to do it (and even if we were to attempt porting the software ourselves, it would probably take even longer). And then, as I wrote in the first paragraph, there is also software compiled by end users on their own. And finally, there is some software that never gets ported. It is stuck on an obsolete Qt version, but it works and is useful to our users, so dropping it would be a disservice to our users. So, as Sune Vuorela also explained, having multiple major versions of Qt in parallel is always going to be a fact of life. this is a linux distro specific problem, Only because we are the only operating system to actually support building software without messing with path settings all over the place. I'll also add that even for those operating systems (such as Windows) where you do have to tweak PATH, having non-conflicting executable names allows setting the PATH once in the user-wide or system-wide settings in the control panel and not having to run a setpaths.bat once for every single build. and demanding x-platform upstreams to accept trade-offs to adjust to it is *unreasonable*. What trade-offs do they have to accept? They just need to add -qt5 to the name of the binary / .EXE file / whatever that they run in their build scripts, once. (And only if they do not simply use a third-party build tool that does the right thing for them already.) In exchange, the program will always compile fine even if there is also a Qt 4 in the systemwide PATH, a situation that can occur on ALL operating systems (including ones not supported by qtchooser), as I explained. now, you will say that most users under linux use qt via distro packages. that's right. and you know what? it's *your* task to make it work for them. And we are. But Thiago is complaining about it. if upstreams of qt-using applications choose to support distro-packaged qt (via having preference lists of suffixed qmakes, for example), that's a perfectly reasonable thing to do. if distros among themselves want to standardize on a pattern to ease this, i'm all for it. it's still not something *we* (qt upstream) need to be concerned with. Now this is really funny. We wanted to do the renaming upstream. You were one of those people who shot it down. Now you are saying we should just do it downstream. On the other hand, Thiago also wanted to do the renaming upstream, he was told not to, so he implemented qtchooser instead, and now says that everybody should use qtchooser and that anything else is broken. Since it is clear even to you that qtchooser is not what we want, why did you force Thiago to implement it, and why are you still not willing to allow the proper solution to be implemented upstream? I'll also point out that, while Debian currently does use qtchooser by default, Lisandro from Debian also stated that he would prefer suffixed binaries. I am not sure there is even ONE distro that is happy with qtchooser. i consider this discussion closed, including for qt6. And I think that this is a mistake. There is a real problem here, one that affects ALL your downstreams (not just GNU/Linux distributions). In Qt 4, upstream's answer was to ignore the issue. In Qt 5, qtchooser was introduced, which solves a different problem from the one we are having (namely, letting the USER choose between different Qt versions that ARE drop-in replacements, i.e., different variants of the same major version).
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Monday 19 January 2015 20:14:33 Thiago Macieira wrote: On Tuesday 20 January 2015 00:57:55 Lisandro Damián Nicanor Pérez Meyer wrote: qdbus should be the same in all versions. I don't plan on making breaking changes in the future -- I can't see what I could do to create such problems... I just wrote an example in another mail, supposing a feature is added. We might argue that the same could be said for assistant, but at least that one is fairly obvious to spot ;) Indeed, applications wouldn't be able to depend on the new feature because qdbus would be the old, Qt 4 version. Which is why I think the solution of having some binaries be declared user applications and the other non-user-facing tools was superior. But it's not the solution we went for. But maybe now with two years of experience is a subject we need to reopen. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.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
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 01:01:57 Lisandro Damián Nicanor Pérez Meyer wrote: On Monday 19 January 2015 18:46:18 Thiago Macieira wrote: [snip] As for Designer, the discussion in 2012 was that its output is compatible with Qt 4 and will remain so, but distributions need to upgrade the plugins to use Qt 5 instead and we can't be blamed if the plugins break their behaviour. Well, this is new to me :) Maybe we should put all this things somewhere? It's the road not taken. We did not go with this solution, so at this point this is just trivia. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtContacts - New class QContactCollection
QContactType::TypeGroup is meant to represent a group of entities with shared contact details (eg, a local football club might have a mailing-list email address, a clubhouse phone number, etc). Individual contacts can have membership in groups (so various friends can be members of the football club group). I don't think that overloading TypeGroup with aggregation semantics is a great idea, personally. We had a discussion a while ago (I cannot remember where, and a quick grep through QTBUG-31824 failed me) about adding a new QContactType::TypeFacet (to match stdlib nomenclature) or QContactType::TypeConstituent where contacts of those types represent service- or sync-endpoint-specific contact instances which are aggregated into a 'full' contact. The full contact would be a QContactType::TypeContact contact, and it would have QContactRelationship::Aggregates relationships with the Facet/Constituent contacts. Then it comes back to what Konstantin suggests: each Facet/Constituent belongs to the particular addressbook (eg, the OwnCloud addressbook, the Fruux addressbook etc) and the Aggregate/Full contact belongs to the FullContacts addressbook. If the user edits the contact on the device, you generate a local Facet/Constituent which is also linked into the aggregate. The aggregate can be regenerated on every write, or on every read, depending on the desired performance characteristics for the device / which trade-offs are preferred. Note that this is the way we do it in nemomobile's qtcontacts-sqlite engine, however we use rather artificial separations based on synctarget (string) filtering, rather than Addressbook collections (we'd definitely prefer Addressbook collections, going forward). Cheers, Chris. www.qinetic.com.au - Qt And QML User Experience Specialists On Tue, Jan 20, 2015 at 7:23 AM, Renato Araujo rena...@gmail.com wrote: For what I understand every detail already have such functionality [QContact.detailUri] with this field you can specify from which contact this detail belongs, based on QContact.Guid; Is correct to say that a contact which the type is TypeGroup is a meta contact with information from different contacts (A merged contact)? Renato Araujo Oliveira Filho On Mon, Jan 19, 2015 at 6:12 PM, Konstantin Ritt ritt...@gmail.com wrote: IMO, such a merged contact should belong to a special address book - one that aggregates contacts and knows which field/detail came from this or that real contact. Regards, Konstantin 2015-01-20 0:27 GMT+04:00 Renato Araujo rena...@gmail.com: Hey guys, I started to implement the class QContactCollection based on QOrganizeCollection[1]. Until now I just copy the code from QOrganizer module and renamed some classes. The idea of QContactCollection is to represent an address-book. And with this we can create/remove/modify collection and query contacts based on the collection id. This looks great, but I have one concern about that. How to represent contacts that are present in more than one Address book (merged contacts)? In this case the contact can have more than one collection. Do you have any idea how to solve that? Should we use a different approach? What about use QContactCollectionId as a derived class from QContactDetails? [1] https://codereview.qt-project.org/#/c/104026/ Thanks Renato Araujo Oliveira Filho ___ 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] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Monday 19 January 2015 19:07:29 Thiago Macieira wrote: On Monday 19 January 2015 15:18:41 Lisandro Damián Nicanor Pérez Meyer wrote: Distributors are going a great job creating Qt packages. But not everyone is using their distro's Qt. In fact, looking at our customers I'd say that most of them have their own Qt install somewhere on their disk. Possible several installations even. Renamed binaries won't cope with that variety. Our product relies on a --with-qmake switch or PATH for selection. Version detections follows wherever named. Renamed binaries won't help. Or even make our life harder as it needs to be. If we are going to focus *just* on customers, yes, you might be right. But as far as I understand this is not just about customers, but also about users. And believe me, we have plenty of those I'm not sure I see the distinction between users and customers here. When you say users, are you thinking of a person who builds a Qt-using software from a 3rdparty? No, actually I'm meaning people who use software made with Qt in the special case of shadowed executables, ie. executables that are called at runtime and might differ between Qt major versions. The truth we face is that we need to ship both major versions at the same time. True, as Ossi wrote: - We could just hope for the same-named tools to behave in the same way. But would it be a bug if they start not doing so? Allow me an example. Due to the fact that Qt4 existed before Qt5 we need to set the default Qt version to 4. Now we know that right now Qt5's qdbus is backwards-compatible. Let's now assume Qt5's qdbus adds a new feature. Now a Qt5 application calls qdbus expecting this feature, but as Qt4 is the default it won't get it. We maintainers get a fairly reasonable bug. - We could ask upstream to call qmake and harcode the path at build time. This solution sounded right at first, but then I *think* it won't work on windows. And if this is the case we still need the app's developer to add an #ifdef or something alike. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.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
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Monday 19 January 2015 20:25:55 Thiago Macieira wrote: On Tuesday 20 January 2015 01:11:55 Lisandro Damián Nicanor Pérez Meyer wrote: On Monday 19 January 2015 19:30:46 Thiago Macieira wrote: [snip] So, as Sune Vuorela also explained, having multiple major versions of Qt in parallel is always going to be a fact of life. Indeed, but the Qt devs' original proposal was to simply put it outside /usr/bin, possibly even outside of $PATH. If distros had accepted to install Qt in (say) /opt/qt5, there would have been no qtchooser, no renaming and no need for change anywhere in our buildsystem. But distros refused to do what we asked... For the sake of completeness, we are not allowed to do so in the same strength that the Qt project doesn't allows binary incompatibility between minor versions, and for which us downstreamers are very grateful :) I know you're not allowed to do that, but there's no technical reason why that is so. Unlike binary compatibility. It's a choice. You might want to take the Filesystem Hierarchy Standard as a technical reason, plus the fact that we do our best to keep stuff installed by packages away from stuff installed by the system's admin, like /opt, simply to avoid problems. But contrast that to the distros asking for the renaming and the majority of Qt developers rejecting that. The ideal solution for either group was rejected outright as soon as the discussion began. So we had to come up with alternatives and compromises. Yes, I know. And I think it was with that good faith of trying to work out an alternative that Sune and I (and mostly thanks to Sune, because at first I was really confused with the situation) decided to go the qtchooser way. Is it in that same light of alternatives and compromises that I'm at least asking to reconsider the case of user-facing stuff, and to take into consideration all the experience we gained during this for the next major release. We distros might not get the best solution, but at least let's work to try to let users don't get into bugs we know might happen. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.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
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Tuesday 20 January 2015 04:05:20 Kevin Kofler wrote: Oswald Buddenhagen wrote: correct. as far as i'm concerned, the purpose of qtchooser is to be a frontend tool which targets developers working with multiple qt versions, regardless whether these versions come from distro packages or own builds. The thing is, we asked for something that fulfills distro's needs. You shot that down and instead got Thiago to implement something different. And now you say yourself that it is not what was asked for. I'm agreeing with Kevin here. We were trying to solve the distro problems back in 2012. If we were trying to keep ourselves happy, we didn't have to do anything. Every single one of us developing Qt already had scripts to update the environment to target one Qt or another. In fact, I wouldn't be surprised if most devs in the Oslo office don't still keep the old 15-year-old qset function. No, we were trying to create one environment to rule them all: something that worked for us developers, for our official binaries on Linux, possibly on OS X and Windows too, as well as for the Linux distros. Other buildsystems would be created to address this environment, so we had to come up with a single recommendation for them. When you say that distros should have just come up with a solution by themselves, you're forgetting one important detail: our binaries for Linux. If we wanted to let distros come up with a solution, we'd have to adapt our binaries too. If they thought the best solution was renaming, we'd have to do it too. Oh, and update the documentation to say that you'd run qmake on Windows and OS X but qmake-qt5 on Linux. Oops, no, only when on Linux and targeting Linux, because if you're cross-compiling to QNX on Linux, it's also qmake. Ugh, no. So no, don't tell us qtchooser is not meant to solve distros' problems. It's meant exactly for them. Developers working with multiple versions of Qt 5 are by far the minority. Most users of Qt development packages actually just want to compile software somebody else wrote. And even those that actually are developers are usually happy with our regularly-updated builds of the latest stable Qt release. To all those users, different major versions are the ONLY coinstallation case that matters. I agree with the statement that the developers using multiple versions are the minority, but I disagree that most users are just people who want to compile other people's software. That's also not true. Those people are also the minority: distro packagers and users of build-from-source distros. The majority of people who ever run qmake are people who are developing their own software, against one single Qt version. build systems which target specific (major) qt versions are simply out of scope. Says who? That is by far the common case. Very few programs support more than one major version of Qt. I'm going to guess this varies with time. The number of programs targetting both Qt N and Qt N+1 is highest close to N+1's first release, then diminishes over time as Qt N becomes old news. That means we have to support both use-cases: targetting one only and targetting multiple. your problem is a self-made one: the attempt to co-install major versions of everything. As long as there are new major versions of Qt (i.e., new versions that are not 100% drop-in replacements for the previous version), there WILL be a need for coinstallation. Programs do not magically port themselves instantly. Even the upstream developers themselves need time to port things. Distribution packagers are usually not qualified to do such a port, so we need to wait for upstream to do it (and even if we were to attempt porting the software ourselves, it would probably take even longer). And then, as I wrote in the first paragraph, there is also software compiled by end users on their own. And finally, there is some software that never gets ported. It is stuck on an obsolete Qt version, but it works and is useful to our users, so dropping it would be a disservice to our users. To be clear: Ossi was talking about development files and tools, not about the libraries. And also note he's referring to another self-made problem of not allowing binaries outside of /usr/bin. So, as Sune Vuorela also explained, having multiple major versions of Qt in parallel is always going to be a fact of life. Indeed, but the Qt devs' original proposal was to simply put it outside /usr/bin, possibly even outside of $PATH. If distros had accepted to install Qt in (say) /opt/qt5, there would have been no qtchooser, no renaming and no need for change anywhere in our buildsystem. But distros refused to do what we asked... Only because we are the only operating system to actually support building software without messing with path settings all over the place. This statement is easily disproven: I don't change my $PATH on OS X. Not even to change between
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Sunday 18 January 2015 22:24:15 Kevin Kofler wrote: Konstantin Ritt wrote: There is no need for moc/rcc/uic to be suffixed. In fact, they are an internal build tools invoked by qmake and thus they should normally reside in libexec dir (or you may query qmake for its specific libexec dir path to invoke them manually) -- just like GCC's cc1 or fixincl. That is just not true. Many Qt programs out there are NOT built using qmake, but more flexible build systems. Those build systems need to call those tools themselves. Even Qt itself is experimenting with qmake replacements (see e.g. QBS). cc1 is almost never invoked directly (only through gcc), but this is not true for moc, rcc, uic etc. So hiding them in a non-PATH directory is not an ideal solution (even if that directory can be found by invoking qmake). We're not making the point that qmake is the only program that runs those tools. We're making the point that the user never runs them directly, buildsystems do. And this whole discussion started about qmake, which is how you find those tools in the first place. In 2012, the alternate solution to renaming everything was to put the non-user applications in libexec. I also had a patch to that when the renaming was declared a non-starter. This proposal was also discarded due to being in the losing side of the argument. Today, a blue-sky proposal, given infinite resources, would be: 1) qmake works for all Qt versions 2) there's a tool for Qt's config, separate from qmake (say, qt5-config) 3) user applications are in $(bindir) and promise to retain compatibility 4) non-user tools are in $(libexec) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Sunday 18 January 2015 22:24:40 Kevin Kofler wrote: Thiago Macieira wrote: That said, back in 2012 when we were discussing the renaming, I made the argument that some of our binary executables are not build tools but are instead user applications. Those should not be installed in a private libexec dir, but should be global in /usr/bin and not proxied by qtchooser. Distros would also take care to install only one and we would take care to keep compatibility with Qt 4 and, if necessary, Qt 3. Some of the executables are user applications, but still need to be renamed. For example assistant-qt4 vs. assistant-qt5. At least, they show different content by default (and the Qt 3 version that is unsuffixed assistant here is completely different, it is what has become the deprecated assistant_adp in Qt 4). The same goes for designer, linguist etc. You're right for Assistant, even though that's actually just a configuration. Linguist has no such problem. As for Designer, the discussion in 2012 was that its output is compatible with Qt 4 and will remain so, but distributions need to upgrade the plugins to use Qt 5 instead and we can't be blamed if the plugins break their behaviour. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Monday 19 January 2015 00:16:48 Kevin Kofler wrote: Thiago Macieira wrote: Because we're in 2014. Qt 4.0 was released in 2005 and the binary wasn't renamed. Software is supposed to work with the official version too and there are 9 years of history of us releasing qmake. Therefore, that buildsystem needs to try qmake alone. The point is, try qmake-qt4 first, and if it doesn't exist, try just qmake. That will work in all cases, and does not need test-running anything, only checking existence. That logic is inverted. It needs to try qmake first because it might be a more recent version, installed by a binary from the Qt Project, since we don't rename. Any qmake-qt4 tool, if present, is an older version from the distribution. I'm ignoring qmake-qt5 because it's totally non-standard. It is only non-standard because you (Qt upstream) refused to settle on the convention almost every distribution in the world has been successfully using for years (for Qt 4). (I know that at least Fedora, RHEL and derivatives, Debian and Mandriva used -qt4 suffixes at some point. There were probably several more. Some of them, like Debian, dropped the suffixes as a result of dropping Qt 3.) So YOU created the mess where we now have 2 competing approaches. We only decided to stick to the standard that has worked for years. There was no convention about Qt 5 prior to the Qt 5 launch. I described how this solution would have worked if you guys hadn't created the problem. But yes, they need to run things. How is that different from running pkg-config? Or running mysql_config? That is not a try to run something and catch the error approach. Approach which also assumes that you get an error to begin with, and the unhandled argument is not silently misinterpreted as meaning something completely different. I don't see how it could be silently misinterpreted. qmake from Qt 4 does not handle an argument of -qt5, so it will fail to run. You can catch that situation just the same way as you'd catch a pkg-config --cflags Qt5Core. That check is irrelevant. You either run a full path to moc, which you obtained from qtchooser or qmake, or you run moc -qt5. Any of those three are going to successfully run the Qt 5 moc if it's there or it's going to fail. The tool can always be in the default path. True, but any decent buildsystem would be adapted to the case when it isn't, in which case it gets the full path and uses that. Which should be zero. All systems should use qtchooser, except Windows. Yet even the tool's own documentation explicitly claims that it is also not for OS X. It works fine on OS X. I use it there. It just happens that most OS X users don't need it because they don't put Qt in PATH. They only use it via Qt Creator or by running qmake with full path to create an XCode project. And at this point, we really cannot expect qtchooser to catch on anymore. It is always going to be an obscure hack that only some Qt developers and Debian are using. It is time for you to admit that it was a failure, and finally ditch it. Why do you make such a prediction? Qtchooser blatantly violates the KISS principle. (It is completely overengineered.) It also introduces some very nondeterministic behavior, such as invoking one and the same executable ending up running a completely different binary depending on the contents of a configuration file (!) or an envionment variable (!). There is a very simple solution to the problem of coexistence of multiple Qt versions: the -qt5 suffix. Your qtchooser wrapper is much more complicated and thus much harder to maintain. (Even with our only optional support for qtchooser, we ran into several packaging issues caused by it. The multilib issue I mentioned was one of them.) Renaming the tools creates other problems. We needed a compromise and qtchooser is it. And like I said, Fedora's and RHEL's refusal to follow the recommendation is their own problem. It is also going to be your problem if programs get written for Fedora and/or RHEL and thus hardcode qmake-qt5 (which in fact I may well actually start RECOMMENDING to developers, to force both other distros and upstream to start supporting it). Welcome to the real world! That won't happen because those applications will get written for the official binaries from the Qt Project, which do not contain renamed tools. Do you really think people will write software that doesn't compile with the official version? Instead, you'll have the burden to keep sending people patches so they can be built on your distro. If we get any issues reported to us about Fedora or RHEL's non-renamed binaries, we'll send back to you, with the recommendation that people file bug reports about not using qtchooser. I already do that. Remember: you (implicitly) agreed with the solution in 2012. If you unilaterally choose to deviate from it, you should be the one to bear the
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Monday 19 January 2015 15:18:41 Lisandro Damián Nicanor Pérez Meyer wrote: Distributors are going a great job creating Qt packages. But not everyone is using their distro's Qt. In fact, looking at our customers I'd say that most of them have their own Qt install somewhere on their disk. Possible several installations even. Renamed binaries won't cope with that variety. Our product relies on a --with-qmake switch or PATH for selection. Version detections follows wherever named. Renamed binaries won't help. Or even make our life harder as it needs to be. If we are going to focus *just* on customers, yes, you might be right. But as far as I understand this is not just about customers, but also about users. And believe me, we have plenty of those I'm not sure I see the distinction between users and customers here. When you say users, are you thinking of a person who builds a Qt-using software from a 3rdparty? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Monday 19 January 2015 19:30:46 Thiago Macieira wrote: [snip] So, as Sune Vuorela also explained, having multiple major versions of Qt in parallel is always going to be a fact of life. Indeed, but the Qt devs' original proposal was to simply put it outside /usr/bin, possibly even outside of $PATH. If distros had accepted to install Qt in (say) /opt/qt5, there would have been no qtchooser, no renaming and no need for change anywhere in our buildsystem. But distros refused to do what we asked... For the sake of completeness, we are not allowed to do so in the same strength that the Qt project doesn't allows binary incompatibility between minor versions, and for which us downstreamers are very grateful :) -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.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
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
Thiago Macieira wrote: And like I said, Fedora's and RHEL's refusal to follow the recommendation is their own problem. You get to pick the pieces from what you broke. As an additional data point, openSUSE is also shipping qmake as qmake-qt5, and as far as I can tell, they do not even have qtchooser packaged at all (unlike Fedora, where it can be optionally installed). So we are not alone. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Sunday 18 January 2015 18:06:45 Lisandro Damián Nicanor Pérez Meyer wrote: If I'm wrong then simply unmasking qdbus with qtchooser should be enough. /usr/bin/qdbus should be provided by the default version (qt4's one in our case) and we might even let qt5-qdbus depend upon it's qt4 version, so packages depending on it would get both for the time being. If I'm *not* wrong then I have no other choice but to tell qt5-apps' maintainers to patch their software to call qdbus with the -qt5 parameter. And we can't even upstream those patches because on platforms other than Linux there is no qtchooser available, and most of the tools will fail saying a wrong parameter has been issued. So we have no other option than to keep a delta from upstream. qdbus should be the same in all versions. I don't plan on making breaking changes in the future -- I can't see what I could do to create such problems... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] optimizing QComposeInputContext / TableGenerator?
Milian Wolff wrote:
It can, indeed. But funnily enough it's not going to be much faster, at
least in the tests I did. Still, one should probably be doing this
anyways. I'll try to dig up my patch for that and sent it to Gerrit. It's
a pity that one cannot just convert a const char* to a QChar directly,
i.e. without any allocations. One cannot even reuse the same QString
buffer to my knowledge...
Why not something like this?
QChar getQChar(const char *p)
{
unsigned short uc = 0;
char c = *(p++);
if (c -64) // invalid UTF-8
uc = 0;
else if (c -32) { // 2 chars
uc = ((unsigned short) (c 31)) 6;
c = *(p++);
if (c = 0)
uc = 0; // error (ASCII or end of string as continuation char)
else
uc |= (unsigned short) (c 63);
} else if (c -16) { // 3 chars
uc = ((unsigned short) (c 15)) 12;
c = *(p++);
if (c = 0)
uc = 0; // error (ASCII or end of string as continuation char)
else {
uc |= ((unsigned short) (c 63)) 6;
c = *(p++);
if (c = 0)
uc = 0; // error (ASCII or end of string as continuation char)
else
uc |= (unsigned short) (c 63);
}
} else if (c 0) // 4 chars, codepoint above 65536, would need 2 QChars
uc = 0;
else
uc = c;
return QChar(uc);
}
Kevin Kofler
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
Thiago Macieira wrote:
That logic is inverted. It needs to try qmake first because it might be a
more recent version, installed by a binary from the Qt Project, since we
don't rename. Any qmake-qt4 tool, if present, is an older version from the
distribution.
The only thing I promised is that if there is a Qt 4 qmake in the PATH, it
WILL find it. Now if there is more than one version, which one is the
preferred version is arguable. I'd argue that the distribution's Qt is
always the preferred one unless the user explicitly requests something
different. (And by the way, we wouldn't have this problem if you were
finally shipping suffixed binaries upstream.)
As for an older version from the distribution, some koji latest-pkg
output for you:
Build Tag Built by
qt-4.8.6-20.fc22 f22 rdieter
qt-4.8.6-18.fc21 f21-updates rdieter
qt-4.8.6-18.fc20 f20-updates rdieter
Older, you say? It's actually NEWER than your latest upstream release
because it includes some backported patches.
Now, before you claim this is easy for the legacy Qt 4, here's the data for
Qt 5:
Build Tag Built by
qt5-qtbase-5.4.0-6.fc22 f22 rdieter
qt5-qtbase-5.4.0-2.fc21 f21-updates rdieter
qt5-qtbase-5.4.0-2.fc20 f20-updates rdieter
Renaming the tools creates other problems. We needed a compromise and
qtchooser is it.
I still have not heard of a single problem that renaming the tools upstream
(and thus for all downstreams) would cause. (Of course, you would actually
ship BOTH the old and new name for the lifetime of Qt 5, otherwise the
compatibility problems are obvious. This would not have been an issue if the
rename had been done back in 5.0.0. Qt 6.0.0 will be the next opportunity to
get rid of the legacy names.)
That won't happen because those applications will get written for the
official binaries from the Qt Project, which do not contain renamed tools.
Do you really think people will write software that doesn't compile with
the official version?
Software on GNU/Linux often gets developed against distribution -devel
packages. I definitely do that whenever possible. Do you really think that
all developers of Qt-using software download your upstream binaries or build
your source code themselves, when they can just yum install qt-devel? That
said, what Qt setup is encountered of course depends on the distribution the
developer(s) is/are using.
Remember: you (implicitly) agreed with the solution in 2012.
I did not agree with anything at all.
You brought up a discussion on a Qt Project mailing list, to which most
distribution packagers are not even subscribed. You got only very limited
feedback from distributors. You never bothered to approach distributors
through places they follow, such as the kde-packager (at the time) mailing
list (or even OUR mailing lists, or aliases such as
qt-ow...@distro.example.com), at least not before the decision was made. It
is only coincidence that I learned of the discussion at all, when it was
already at a late stage. Assuming that all the people you did not ask agree
with you just does not make any sense whatsoever.
If you unilaterally choose to deviate from it,
Our intentions have been clearly announced on our mailing list, IRC channel
and publicly-logged IRC meetings from day 1. By not objecting, by your own
logic, you implicitly agreed to them.
Kevin Kofler
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Monday 19 January 2015 18:46:18 Thiago Macieira wrote: [snip] As for Designer, the discussion in 2012 was that its output is compatible with Qt 4 and will remain so, but distributions need to upgrade the plugins to use Qt 5 instead and we can't be blamed if the plugins break their behaviour. Well, this is new to me :) Maybe we should put all this things somewhere? So if a distro ships both Qt4 and Qt5 in the special case of designer we can call Qt5's version in all cases? I'm pretty sure I'm missing something wrt plugins here (ie, I'm not correctly getting the right thing to do, sorry). -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.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
Re: [Development] JIRA broken
I can confirm there is a problem with Jira. We'll investigate. -- Alex From: development-bounces+alexander.blasche=theqtcompany@qt-project.org development-bounces+alexander.blasche=theqtcompany@qt-project.org on behalf of Guido Seifert warg...@gmx.de Sent: Sunday, January 18, 2015 13:22 To: development@qt-project.org Subject: [Development] JIRA broken when I add: Project: Qt Issue Type: Bug Summary: Ninja for qtwebengine out-of-source build not possible Affects Version/s: 5.5 Component/s: Build System Description: When I do an out-of-source build, e.g. sources in 'qt5' and a '../qt5/configure' in a separate 'qt5-build' folder, ninja for the qtwebengine is still build within qt5/qtwebengine/src/3rdparty/ninja/ and not in the qt5-build tree. Apart from the pure cosmetic ugliness to have created code in a folder below 'src', it is ugly because it taints the sources, which prevents to move the source tree easily to a different machine, or have the sources read-only. Environment: Apparently all I get: Error creating issue: Indexing completed with 1 errors Guido ___ 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] JIRA broken
Everything is back to normal. -- Alex From: development-bounces+alexander.blasche=theqtcompany@qt-project.org development-bounces+alexander.blasche=theqtcompany@qt-project.org on behalf of Blasche Alexander alexander.blas...@theqtcompany.com Sent: Monday, January 19, 2015 09:25 To: development@qt-project.org Subject: Re: [Development] JIRA broken I can confirm there is a problem with Jira. We'll investigate. -- Alex From: development-bounces+alexander.blasche=theqtcompany@qt-project.org development-bounces+alexander.blasche=theqtcompany@qt-project.org on behalf of Guido Seifert warg...@gmx.de Sent: Sunday, January 18, 2015 13:22 To: development@qt-project.org Subject: [Development] JIRA broken when I add: Project: Qt Issue Type: Bug Summary: Ninja for qtwebengine out-of-source build not possible Affects Version/s: 5.5 Component/s: Build System Description: When I do an out-of-source build, e.g. sources in 'qt5' and a '../qt5/configure' in a separate 'qt5-build' folder, ninja for the qtwebengine is still build within qt5/qtwebengine/src/3rdparty/ninja/ and not in the qt5-build tree. Apart from the pure cosmetic ugliness to have created code in a folder below 'src', it is ugly because it taints the sources, which prevents to move the source tree easily to a different machine, or have the sources read-only. Environment: Apparently all I get: Error creating issue: Indexing completed with 1 errors Guido ___ 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] Adding new third party component three.js to Qt?
The thread seems to have derailed quite badly, so let's reboot it and return to the original topic of how to bundle the javascript code. If I understand correctly, there is a desire to be able to provide the modified three.js code as a separate package. We have an existing solution for this, the configure script. Wouldn't the whole issue be solved by just adding a compile-time check for the library? If it's found on the system, fine, use that code. If not, use the code bundled with Qt. Add a switch to override the selection. Treat like any other library, because it is. -- Louai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Sun, 18 Jan 2015, Kevin Kofler wrote: Thiago Macieira wrote: The one requirement that came from the Qt Project was that the tools would not be renamed. And the one requirement that came from the distros was that the tools must be renamed. This was made very clear from the beginning. All other solutions are and will always be inherently flawed. You also never gave any convincing argument as to why you refused to rename the binaries. Distributors are going a great job creating Qt packages. But not everyone is using their distro's Qt. In fact, looking at our customers I'd say that most of them have their own Qt install somewhere on their disk. Possible several installations even. Renamed binaries won't cope with that variety. Our product relies on a --with-qmake switch or PATH for selection. Version detections follows wherever named. Renamed binaries won't help. Or even make our life harder as it needs to be. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
consider this a meta-reply to the entire thread. On Sat, Jan 17, 2015 at 11:46:58PM +0100, Kevin Kofler wrote: Thiago Macieira wrote: packagers, like we did in the past for qtchooser (a solution designed for distro's needs). Hahaha, that's a good one! Qtchooser is designed completely PAST distros' needs and entirely useless for distros. What we actually asked for (and have always been shipping, and at least in Fedora, still ship for Qt 5) is suffixed binaries. correct. as far as i'm concerned, the purpose of qtchooser is to be a frontend tool which targets developers working with multiple qt versions, regardless whether these versions come from distro packages or own builds. build systems which target specific (major) qt versions are simply out of scope. your problem is a self-made one: the attempt to co-install major versions of everything. this is a linux distro specific problem, and demanding x-platform upstreams to accept trade-offs to adjust to it is *unreasonable*. now, you will say that most users under linux use qt via distro packages. that's right. and you know what? it's *your* task to make it work for them. if upstreams of qt-using applications choose to support distro-packaged qt (via having preference lists of suffixed qmakes, for example), that's a perfectly reasonable thing to do. if distros among themselves want to standardize on a pattern to ease this, i'm all for it. it's still not something *we* (qt upstream) need to be concerned with. the rest should be considered non-normative, to use RFC speak. it's mostly re-iterating already made points from 2011: - for build systems based on cmake this whole discussion is irrelevant, because they make use of the module registration system via *Config files, which is the *right* thing to do. this is the case because you are right that the build system should choose which qt version [range] it wants to use. only your conclusion that this should happen via the name of the qmake binary (or even other tools) is a tad narrow-minded - even multi-arch shows that your approach is too limited. - build systems which use qt tools without querying qmake (or cmake) for their location are *broken*. - for build systems based on qmake, there isn't a *good* way to choose the right version, simply because qmake is not a generic build tool, but bound to a particular qt version. one can choose to make a configure script around the qmake build system, or one can delegate it to the user. the conventional way to do the latter would be setting PATH. qtchooser is just a nicer way to do the same (on the command line - scripted use is not really in scope, as i wrote above). the upshot is that it doesn't matter much whether the build system uses qmake as the workhorse or not, because it needs qmake as a frontend anyway. note that this poses no problem for packaged qt-using apps/libs, because you can instruct their build to use a specific qt easily (e.g., via the environment or configure options). however, we *can* have a distro-friendly qt5-config tool which replaces qmake -query for configuring external build systems, as adding this doesn't break any existing workflows. in fact, in qt6 there won't be qmake any more (one way or another), so we should add a dedicated tool already to ensure a smoother transition. - for frontend applications like designer and linguist the same applies as to qmake. so distros may choose to provide aliases to them in $PATH, like for qmake. - for backend tools like qdbus, you can either a) assume backwards compatibility and rely on PATH or b) ask qmake for the correct paths (at build time, obviously, and embed the result in the binaries/scripts). this also applies to attempts to script frontend apps, like the mentioned assistant case. i consider this discussion closed, including for qt6. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-39477 - Enable QWidget based classes to be used in QML files
On Sat, Jan 17, 2015 at 4:49 PM, Fanda Vacek fanda.va...@gmail.com wrote: Hi, please, is there anybody with +2 who can make review for patch on this bug (https://bugreports.qt.io/browse/QTBUG-39477)? It is marked as CRITICAL since 5.2 and patch is prepared for review. We have 5.4.1 now and the bug is still here. The bug is really blocker for my project (https://github.com/fvacek/quickbox), so please, can somebody help me? Best Regards Fanda I don't even get why a P1 bug isn't blocking the release in the first place. P1 bugs are supposed to be release blockers, right? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
Thiago Macieira wrote: On Saturday 17 January 2015 23:46:58 Kevin Kofler wrote: Therefore, we are NOT shipping qtchooser in Fedora by default, and our qtchooser package in the online repository (package which we only ship at all due to the insistence of one individual packager – both I and the primary maintainer of Qt in Fedora have requested its removal from Fedora more than once) does NOT automatically add itself to the PATH. Please reconsider. There's something to gain just by being compliant with what we standardised and recommend. I just realized yet another showstopper that precludes supporting qtchooser in Fedora by default: A core assumption in qtchooser's design is that the unsuffixed binaries in the default PATH (default binaries) all default to the same version of Qt. But this is not how things work in Fedora: In an effort of being as compatible with upstream as possible, we have only added suffixes where there are actually conflicts. As a result, the default binary is the one where the given binary was first introduced (except that we do not support Qt 1 or 2 anymore, so Qt 3 is the minimum we care about). For example, the default qmake is the Qt 3 one, the default qdbus is the Qt 4 one, the default qtpaths is the Qt 5 one. The qtchooser wrapper does not support this setup, and thus enabling it by default would be a backwards-incompatible change and might break several Qt 3 or 4 packages. This would have been an issue even if we had picked up qtchooser immediately when it was introduced, because we already had this mixed setup for Qt 3 and 4 binaries. (Excluding the Qt = 4 binaries from qtchooser wrapping entirely would not have worked because of Qt 5.) Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Building Qt3D
Hi, Il 16/01/2015 21:28, Ben Beckwith ha scritto: I'm building on Ubuntu 14.04. I git the Qt 5.4.1 source and then git the Qt3D source (dev branch). Here's my config line: Unfortunately 5.4.1 is not enough, you need qtbase and qtdeclarative from dev branch as well. See http://qt-project.org/wiki/Building_Qt_5_from_Git for further instructions. Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Adding new third party component three.js to Qt?
Hi Louai, Thank you for returning this thread back to the original topic. I think what you propose there is very good idea indeed! Why make JavaScript libraries more complex to handle than any other library? - Pasi On 19/01/15 13:19, Al-Khanji Louai louai.al-kha...@theqtcompany.com wrote: The thread seems to have derailed quite badly, so let's reboot it and return to the original topic of how to bundle the javascript code. If I understand correctly, there is a desire to be able to provide the modified three.js code as a separate package. We have an existing solution for this, the configure script. Wouldn't the whole issue be solved by just adding a compile-time check for the library? If it's found on the system, fine, use that code. If not, use the code bundled with Qt. Add a switch to override the selection. Treat like any other library, because it is. -- Louai ___ 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] Building Qt3D
Howdy! I'm trying to build the latest Qt3D and I'm runing into following issue: g++ -c -pipe -g -fvisibility=hidden -fvisibility-inlines-hidden -std=c++0x -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_MTDEV -DQT3DRENDERER_LIBRARY -DQT_BUILD_3DRENDERER_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x05 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_3DCORE_LIB -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DQT_OPENGLEXTENSIONS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/media/RaidData/qt/qt5/qtbase/mkspecs/linux-g++ -I. -I../../include -I../../include/Qt3DRenderer -I../../include/Qt3DRenderer/5.5.0 -I../../include/Qt3DRenderer/5.5.0/Qt3DRenderer -Ibackend -Ibackend/framegraph -Ibackend/jobs -Ifrontend -Ifrontend/framegraph-components -Iio -Idefaults -I/media/RaidData/qt/qt5/qtbase/include/QtGui/5.4.1 -I/media/RaidData/qt/qt5/qtbase/include/QtGui/5.4.1/QtGui -I../../include/Qt3DCore/5.5.0 -I../../include/Qt3DCore/5.5.0/Qt3DCore -I../../include/Qt3DCore -I/media/RaidData/qt/qt5/qtbase/include -I/media/RaidData/qt/qt5/qtbase/include/QtOpenGL -I/media/RaidData/qt/qt5/qtbase/include/QtWidgets -I/media/RaidData/qt/qt5/qtbase/include/QtOpenGLExtensions -I/media/RaidData/qt/qt5/qtbase/include/QtGui -I/media/RaidData/qt/qt5/qtbase/include/QtCore/5.4.1 -I/media/RaidData/qt/qt5/qtbase/include/QtCore/5.4.1/QtCore -I/media/RaidData/qt/qt5/qtbase/include/QtCore -I.moc -o .obj/qrenderaspect.o backend/qrenderaspect.cpp In file included from /media/RaidData/qt/qt5/qtbase/include/QtCore/qglobal.h:1:0, from ../../include/Qt3DRenderer/../../src/render/qt3drenderer_global.h:45, from ../../include/Qt3DRenderer/qt3drenderer_global.h:1, from backend/qrenderaspect.h:45, from backend/qrenderaspect.cpp:42: /media/RaidData/qt/qt5/qtbase/include/QtCore/../../src/corelib/kernel/qmetatype.h: In instantiation of ‘constexpr int qMetaTypeId() [with T = QSurface*]’: /media/RaidData/qt/qt5/qtbase/include/QtCore/../../src/corelib/kernel/qvariant.h:678:44: required from ‘static T QtPrivate::QVariantValueHelperT::metaType(const QVariant) [with T = QSurface*]’ /media/RaidData/qt/qt5/qtbase/include/QtCore/../../src/corelib/kernel/qvariant.h:105:39: required from ‘static ReturnType QtPrivate::MetaTypeInvokerDerived, Argument, ReturnType::invoke(Argument) [with Derived = QtPrivate::QVariantValueHelperQSurface*; Argument = const QVariant; ReturnType = QSurface*]’ /media/RaidData/qt/qt5/qtbase/include/QtCore/../../src/corelib/kernel/qvariant.h:817:64: required from ‘T qvariant_cast(const QVariant) [with T = QSurface*]’ /media/RaidData/qt/qt5/qtbase/include/QtCore/../../src/corelib/kernel/qvariant.h:343:36: required from ‘T QVariant::value() const [with T = QSurface*]’ backend/qrenderaspect.cpp:303:39: required from here /media/RaidData/qt/qt5/qtbase/include/QtCore/../../src/corelib/global/qglobal.h:684:47: error: static assertion failed: Type is not registered, please use the Q_DECLARE_METATYPE macro to make it known to Qt's meta-object system #define Q_STATIC_ASSERT_X(Condition, Message) static_assert(bool(Condition), Message) ^ /media/RaidData/qt/qt5/qtbase/include/QtCore/../../src/corelib/kernel/qmetatype.h:1648:5: note: in expansion of macro ‘Q_STATIC_ASSERT_X’ Q_STATIC_ASSERT_X(QMetaTypeId2T::Defined, Type is not registered, please use the Q_DECLARE_METATYPE macro to make it known to Qt's meta-object system); ^ In file included from /media/RaidData/qt/qt5/qtbase/include/QtCore/qmetatype.h:1:0, from /media/RaidData/qt/qt5/qtbase/include/QtCore/../../src/corelib/kernel/qobject.h:48, from /media/RaidData/qt/qt5/qtbase/include/QtCore/qobject.h:1, from /media/RaidData/qt/qt5/qtbase/include/QtCore/QObject:1, from ../../include/Qt3DCore/../../src/core/aspects/qabstractaspect.h:45, from ../../include/Qt3DCore/qabstractaspect.h:1, from backend/qrenderaspect.h:46, from backend/qrenderaspect.cpp:42: /media/RaidData/qt/qt5/qtbase/include/QtCore/../../src/corelib/kernel/qmetatype.h: In instantiation of ‘static constexpr int QMetaTypeId2T::qt_metatype_id() [with T = QSurface*]’: /media/RaidData/qt/qt5/qtbase/include/QtCore/../../src/corelib/kernel/qmetatype.h:1649:44: required from ‘constexpr int qMetaTypeId() [with T = QSurface*]’ /media/RaidData/qt/qt5/qtbase/include/QtCore/../../src/corelib/kernel/qvariant.h:678:44: required from ‘static T QtPrivate::QVariantValueHelperT::metaType(const QVariant) [with T = QSurface*]’ /media/RaidData/qt/qt5/qtbase/include/QtCore/../../src/corelib/kernel/qvariant.h:105:39: required from ‘static ReturnType QtPrivate::MetaTypeInvokerDerived, Argument, ReturnType::invoke(Argument) [with Derived = QtPrivate::QVariantValueHelperQSurface*; Argument = const
Re: [Development] Android Serial Port USB device
I don’t know if it is on a patch somewhere, but I did upload it. I did have a working version that used the usb-serial-for-android library. In fact I used that version on a project. There was talk of changing that to a library that I would write, but I was pulled off onto other projects at work and was unable to work on it further. Mike Goza From: Pau Garcia i Quiles [mailto:pgqui...@elpauer.org] Sent: Sunday, January 18, 2015 11:02 AM To: development@qt-project.org Cc: name...@comcast.net Subject: Android Serial Port USB device Hello, Mike Gonza worked on a wrapper of usb-serial-for-android and provided patches a while ago but they were not accepted because usb-serial-for-android is LGPLv2.1 only: https://codereview.qt-project.org/#/c/83480/ https://codereview.qt-project.org/#/c/84338/ https://github.com/mik3y/usb-serial-for-android As a consequence, Qt has no support for non-rooted serial port on Android. AFAIK there is no alternative to usb-serial-for-android (other than reinventing it from scratch with a more acceptable license). Or is there? Is there any chance Mike's patches are at least merged as an optional feature which is not compiled by default? Thank you -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Under Windows QWindow receiving QExposeEvent on window drag.
I am attempting to animate a QOpenGLWindow, so I'm connecting SIGNAL(frameSwapped()) with SLOT(update()) to force update on vsync as recommended in the documentation. So far so good, under *nix OSes this works fine. (Tested on x64 Ubuntu and OS X) But on Windows, when dragging a window around, the QExposeEvent gets sent out while dragging the window, causing the window to lag noticeably. (This does NOT happen on *nix OSes!) I am able to hack a fix by caching the previous QRegion in my derived QOpenGLWindow class, and checking to see if the new exposeEvent-region() is the same as the cached QRegion. If the cached region is the same, I ignore the event. If they are different, I pass it down to QOpenGLWindow. This appears to fix the problem. Here is my change that fixes the problem under my own project: https://github.com/TReed0803/QtOpenGL/commit/f243e879b1d639fd838deffd6b2ca095062addc1 I feel I shouldn't have to do this, it seems kind of hacky. Is this a bug? Thanks, - Trent Reed ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Jan 18, 2015, at 10:24 PM, Kevin Kofler kevin.kof...@chello.at wrote: Konstantin Ritt wrote: There is no need for moc/rcc/uic to be suffixed. In fact, they are an internal build tools invoked by qmake and thus they should normally reside in libexec dir (or you may query qmake for its specific libexec dir path to invoke them manually) -- just like GCC's cc1 or fixincl. That is just not true. Many Qt programs out there are NOT built using qmake, but more flexible build systems. Those build systems need to call those tools themselves. Even Qt itself is experimenting with qmake replacements (see e.g. QBS). cc1 is almost never invoked directly (only through gcc), but this is not true for moc, rcc, uic etc. So hiding them in a non-PATH directory is not an ideal solution (even if that directory can be found by invoking qmake). I don’t know how you could use QBS to support your case of renaming the Qt tools. To use a specific Qt version with QBS, you configure a profile in QBS with the corresponding paths to the binaries/libraries/etc. I do not see how QBS would benefit from renamed tool names, actually it would get more complicated. -- Eike Ziller, Senior Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Jan 18, 2015, at 6:34 AM, Kevin Kofler kevin.kof...@chello.at wrote: Thiago Macieira wrote: Now we have a legacy to keep, so we can't accept a radical change. Only incremental improvements. You will find that very few deployments out there in the real world use qtchooser. The widely-used RHEL most definitely does not, it inherits the exact same Qt setup Fedora uses. (In fact, the maintainers from Red Hat were also against using qtchooser in Fedora.) Operating systems other than GNU/Linux also do not use qtchooser. So doing away with it would only make the world more uniform. Though doing away with qtchooser would make the world more uniform You, the Qt Project, need to accept that qtchooser has just not caught on, it was an attempt that turned out a failure, and needs to be replaced by a better and much simpler solution (just renaming the binaries). I do not see how a more uniform world would support your case of renaming the binaries. No other OS would benefit from it. To the contrary, it would make it more complicated there. Which is most probably also the reason why there is no interest in having qtchooser on other OSes. There is just no problem that it solves there. Br, Eike Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Under Windows QWindow receiving QExposeEvent on window drag.
Because some unfortunate code in the Windows platform plugin generates expose events even when the size has not changed. This is of course wrong. It will be corrected by https://codereview.qt-project.org/#/c/103932 Cheers, Laszlo From: development-bounces+laszlo.agocs=theqtcompany@qt-project.org development-bounces+laszlo.agocs=theqtcompany@qt-project.org on behalf of Trent Reed treed0...@gmail.com Sent: Sunday, January 18, 2015 6:04 AM To: development@qt-project.org Subject: [Development] Under Windows QWindow receiving QExposeEvent on window drag. I am attempting to animate a QOpenGLWindow, so I'm connecting SIGNAL(frameSwapped()) with SLOT(update()) to force update on vsync as recommended in the documentation. So far so good, under *nix OSes this works fine. (Tested on x64 Ubuntu and OS X) But on Windows, when dragging a window around, the QExposeEvent gets sent out while dragging the window, causing the window to lag noticeably. (This does NOT happen on *nix OSes!) I am able to hack a fix by caching the previous QRegion in my derived QOpenGLWindow class, and checking to see if the new exposeEvent-region() is the same as the cached QRegion. If the cached region is the same, I ignore the event. If they are different, I pass it down to QOpenGLWindow. This appears to fix the problem. Here is my change that fixes the problem under my own project: https://github.com/TReed0803/QtOpenGL/commit/f243e879b1d639fd838deffd6b2ca095062addc1 I feel I shouldn't have to do this, it seems kind of hacky. Is this a bug? Thanks, - Trent Reed ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] optimizing QComposeInputContext / TableGenerator?
On Monday 19 January 2015 20:15:22 Milian Wolff wrote: I usually don't use the compose key, so my naive assumption would be that lazy-loading this table would help the common case of startup quite a bit already. Or is this required for other things that I don't expect? It applies to dead keys too. In fact, I don't know what keys are allowed to trigger composition... any key could be. Though very few people in their sane minds would use anything besides dead keys and the Compose key. The reason this is loaded at runtime was at my insistence because I patch mine so dead_acute c is ç instead of ć. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] optimizing QComposeInputContext / TableGenerator?
Hello all, when I run my heaptrack [1] tool on Qt 5 applications, I often stumble upon the compose TableGenerator. It initializes many QStrings and also consumes ruoghly 400KB of memory. I wonder whether we could optimize this somehow? The best approach of course would be to have a OpenDesktop standard that allows mmapping the compose table in and using it from there. Probably not feasible. Creating our own cache brings the usual issues of having to update the cache when the original changes... So what I wonder about is whether one could delay the table generation? I usually don't use the compose key, so my naive assumption would be that lazy-loading this table would help the common case of startup quite a bit already. Or is this required for other things that I don't expect? 5786 calls to allocation functions from: QArrayData::allocate(unsigned long, unsigned long, unsigned long, QFlags) at sources/qtbase/src/corelib/tools/qarraydata.cpp:105 in /home/milian/projects/compiled/qt5/lib/libQt5Core.so.5 QTypedArrayData::allocate(unsigned long, QFlags) at ../../include/QtCore/../../../src/corelib/tools/qarraydata.h:217 in /home/milian/projects/compiled/qt5/lib/libQt5Core.so.5 QString::QString(int, Qt::Initialization) at sources/qtbase/src/corelib/tools/qstring.cpp:1497 in /home/milian/projects/compiled/qt5/lib/libQt5Core.so.5 QUtf8::convertToUnicode(char const*, int, QTextCodec::ConverterState*) at sources/qtbase/src/corelib/codecs/qutfcodec.cpp:316 in /home/milian/projects/compiled/qt5/lib/libQt5Core.so.5 QUtf8Codec::convertToUnicode(char const*, int, QTextCodec::ConverterState*) const at sources/qtbase/src/corelib/codecs/qutfcodec.cpp:671 in /home/milian/projects/compiled/qt5/lib/libQt5Core.so.5 QTextCodec::toUnicode(char const*, int, QTextCodec::ConverterState*) const at ../../include/QtCore/../../../src/corelib/codecs/qtextcodec.h:103 in /home/milian/projects/compiled/qt5/lib/libQt5Core.so.5 QString::fromLocal8Bit_helper(char const*, int) at sources/qtbase/src/corelib/tools/qstring.cpp:4554 in /home/milian/projects/compiled/qt5/lib/libQt5Core.so.5 QString::fromLocal8Bit(char const*, int) at ../../../../include/QtCore/../../../src/corelib/tools/qstring.h:533 in prefix/qt5/plugins/platforminputcontexts/libcomposeplatforminputcontextplugin.so TableGenerator::parseKeySequence(char*) at sources/qtbase/src/plugins/platforminputcontexts/compose/generator/qtablegenerator.cpp:402 in prefix/qt5/plugins/platforminputcontexts/libcomposeplatforminputcontextplugin.so TableGenerator::parseComposeFile(QFile*) at sources/qtbase/src/plugins/platforminputcontexts/compose/generator/qtablegenerator.cpp:293 in prefix/qt5/plugins/platforminputcontexts/libcomposeplatforminputcontextplugin.so TableGenerator::processFile(QString) at sources/qtbase/src/plugins/platforminputcontexts/compose/generator/qtablegenerator.cpp:267 in prefix/qt5/plugins/platforminputcontexts/libcomposeplatforminputcontextplugin.so TableGenerator::findComposeFile() at sources/qtbase/src/plugins/platforminputcontexts/compose/generator/qtablegenerator.cpp:112 in prefix/qt5/plugins/platforminputcontexts/libcomposeplatforminputcontextplugin.so TableGenerator::TableGenerator() at sources/qtbase/src/plugins/platforminputcontexts/compose/generator/qtablegenerator.cpp:56 in prefix/qt5/plugins/platforminputcontexts/libcomposeplatforminputcontextplugin.so QComposeInputContext::QComposeInputContext() at sources/qtbase/src/plugins/platforminputcontexts/compose/qcomposeplatforminputcontext.cpp:85 in prefix/qt5/plugins/platforminputcontexts/libcomposeplatforminputcontextplugin.so QComposePlatformInputContextPlugin::create(QString const, QStringList const) at sources/qtbase/src/plugins/platforminputcontexts/compose/main.cpp:56 in prefix/qt5/plugins/platforminputcontexts/libcomposeplatforminputcontextplugin.so QPlatformInputContext* qLoadPlugin1(QFactoryLoader const*, QString const, QStringList const) at ../../include/QtCore/5.5.0/QtCore/private/../../../../../../src/corelib/plugin/qfactoryloader_p.h:107 in /home/milian/projects/compiled/qt5/lib/libQt5Gui.so.5 QPlatformInputContextFactory::create(QString const) at sources/qtbase/src/gui/kernel/qplatforminputcontextfactory.cpp:65 in /home/milian/projects/compiled/qt5/lib/libQt5Gui.so.5 QPlatformInputContextFactory::create() at sources/qtbase/src/gui/kernel/qplatforminputcontextfactory.cpp:80 in /home/milian/projects/compiled/qt5/lib/libQt5Gui.so.5 QXcbIntegration::initialize() at sources/qtbase/src/plugins/platforms/xcb/qxcbintegration.cpp:260 in /home/milian/projects/compiled/qt5/lib/libQt5XcbQpa.so.5 QGuiApplicationPrivate::eventDispatcherReady() at
Re: [Development] optimizing QComposeInputContext / TableGenerator?
On Monday 19 January 2015 20:15:22 Milian Wolff wrote: Hello all, when I run my heaptrack [1] tool on Qt 5 applications, I often stumble upon the compose TableGenerator. It initializes many QStrings and also consumes ruoghly 400KB of memory. I wonder whether we could optimize this somehow? The best approach of course would be to have a OpenDesktop standard that allows mmapping the compose table in and using it from there. Probably not feasible. Creating our own cache brings the usual issues of having to update the cache when the original changes... So what I wonder about is whether one could delay the table generation? I usually don't use the compose key, so my naive assumption would be that lazy-loading this table would help the common case of startup quite a bit already. Or is this required for other things that I don't expect? Looking at the hotspot from void TableGenerator::parseKeySequence: elem.value = QString::fromLocal8Bit(composeValue).at(0).unicode(); So if I understand correctly, it needs to convert the full line to QString just to take the first character. Surely this can be improved. The code is here: http://code.woboq.org/qt5/qtbase/src/plugins/platforminputcontexts/compose/generator/qtablegenerator.cpp.html#_ZN14TableGenerator16parseKeySequenceEPc But yes, some mmapable on-disk cache would probably be the best. One would just need to make sure that the cache is invalidated properly when it should. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On 2015-01-19, Oswald Buddenhagen oswald.buddenha...@theqtcompany.com wrote: your problem is a self-made one: the attempt to co-install major versions of everything. this is a linux distro specific problem, and demanding x-platform upstreams to accept trade-offs to adjust to it is *unreasonable*. I do wonder about one thing here. Are you suggesting that linux distributions doesn't ship Qt5 until everything is ready to use it ? /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtchooser (was: Re: Adding new third party component three.js to Qt?)
On Monday 19 January 2015 15:01:20 Harri Porten wrote: On Sun, 18 Jan 2015, Kevin Kofler wrote: Thiago Macieira wrote: The one requirement that came from the Qt Project was that the tools would not be renamed. And the one requirement that came from the distros was that the tools must be renamed. This was made very clear from the beginning. All other solutions are and will always be inherently flawed. You also never gave any convincing argument as to why you refused to rename the binaries. Distributors are going a great job creating Qt packages. But not everyone is using their distro's Qt. In fact, looking at our customers I'd say that most of them have their own Qt install somewhere on their disk. Possible several installations even. Renamed binaries won't cope with that variety. Our product relies on a --with-qmake switch or PATH for selection. Version detections follows wherever named. Renamed binaries won't help. Or even make our life harder as it needs to be. If we are going to focus *just* on customers, yes, you might be right. But as far as I understand this is not just about customers, but also about users. And believe me, we have plenty of those ;) -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.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
Re: [Development] QtContacts - New class QContactCollection
IMO, such a merged contact should belong to a special address book - one that aggregates contacts and knows which field/detail came from this or that real contact. Regards, Konstantin 2015-01-20 0:27 GMT+04:00 Renato Araujo rena...@gmail.com: Hey guys, I started to implement the class QContactCollection based on QOrganizeCollection[1]. Until now I just copy the code from QOrganizer module and renamed some classes. The idea of QContactCollection is to represent an address-book. And with this we can create/remove/modify collection and query contacts based on the collection id. This looks great, but I have one concern about that. How to represent contacts that are present in more than one Address book (merged contacts)? In this case the contact can have more than one collection. Do you have any idea how to solve that? Should we use a different approach? What about use QContactCollectionId as a derived class from QContactDetails? [1] https://codereview.qt-project.org/#/c/104026/ Thanks Renato Araujo Oliveira Filho ___ 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] QtContacts - New class QContactCollection
For what I understand every detail already have such functionality [QContact.detailUri] with this field you can specify from which contact this detail belongs, based on QContact.Guid; Is correct to say that a contact which the type is TypeGroup is a meta contact with information from different contacts (A merged contact)? Renato Araujo Oliveira Filho On Mon, Jan 19, 2015 at 6:12 PM, Konstantin Ritt ritt...@gmail.com wrote: IMO, such a merged contact should belong to a special address book - one that aggregates contacts and knows which field/detail came from this or that real contact. Regards, Konstantin 2015-01-20 0:27 GMT+04:00 Renato Araujo rena...@gmail.com: Hey guys, I started to implement the class QContactCollection based on QOrganizeCollection[1]. Until now I just copy the code from QOrganizer module and renamed some classes. The idea of QContactCollection is to represent an address-book. And with this we can create/remove/modify collection and query contacts based on the collection id. This looks great, but I have one concern about that. How to represent contacts that are present in more than one Address book (merged contacts)? In this case the contact can have more than one collection. Do you have any idea how to solve that? Should we use a different approach? What about use QContactCollectionId as a derived class from QContactDetails? [1] https://codereview.qt-project.org/#/c/104026/ Thanks Renato Araujo Oliveira Filho ___ 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] optimizing QComposeInputContext / TableGenerator?
Hi, The idea is to move the compose file reading code out of Qt. libxkbcommon 5.0 (released on 2014-10-18 [1]) added support for the compose keys. I did look at the new API already in October [2]. It should be simple enough to remove the table generation code and use xkbcommon's API instead. I have not done any benchmarking because I never got around to finishing that patch. There are several projects that use xkbcommon (Wayland, GTK), so we can benefit from the optimizations done by others if we use this new API. Also if somebody has suggestions for improvements, those should be done in [3]. [1] http://lists.freedesktop.org/archives/wayland-devel/2014-October/017836.html [2] *WIP* https://codereview.qt-project.org/#/c/98062/ [3] https://github.com/xkbcommon/libxkbcommon From: development-bounces+gatis.paeglis=theqtcompany@qt-project.org development-bounces+gatis.paeglis=theqtcompany@qt-project.org on behalf of Thiago Macieira thiago.macie...@intel.com Sent: Monday, January 19, 2015 9:38 PM To: development@qt-project.org Subject: Re: [Development] optimizing QComposeInputContext / TableGenerator? On Monday 19 January 2015 21:17:00 Giuseppe D'Angelo wrote: The best approach of course would be to have a OpenDesktop standard that allows mmapping the compose table in and using it from there. Probably not feasible. Why not? x...@freedesktop.org. I think I can easily convince the EFL folks for this. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ 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] optimizing QComposeInputContext / TableGenerator?
On Monday 19 January 2015 21:17:00 Giuseppe D'Angelo wrote: The best approach of course would be to have a OpenDesktop standard that allows mmapping the compose table in and using it from there. Probably not feasible. Why not? x...@freedesktop.org. I think I can easily convince the EFL folks for this. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android Serial Port USB device
Hi all, Yes, thanks to Mike! He started it implementation, but does not complete it. ;) For example, some people (e.g. on our russians forums) ask me about non-rooted Android support. In this case I always forward/point these people to Mike's patches (to looks and to try those patches). But this people faced with many errors in this implementation where it does not worked on their side, and then refuses from the serial ports in favor to WiFi/Bluetooth sockets. So, need to complete and to test this implementation. I would be glad if someone could continue and complete it. But I am not able to do it himself since I am not an expert in Android. Thus this task still is in air. BR, Denis 19.01.2015 5:54, Mike Goza пишет: I don’t know if it is on a patch somewhere, but I did upload it. I did have a working version that used the usb-serial-for-android library. In fact I used that version on a project. There was talk of changing that to a library that I would write, but I was pulled off onto other projects at work and was unable to work on it further. Mike Goza *From:*Pau Garcia i Quiles [mailto:pgqui...@elpauer.org] *Sent:* Sunday, January 18, 2015 11:02 AM *To:* development@qt-project.org *Cc:* name...@comcast.net *Subject:* Android Serial Port USB device Hello, Mike Gonza worked on a wrapper of usb-serial-for-android and provided patches a while ago but they were not accepted because usb-serial-for-android is LGPLv2.1 only: https://codereview.qt-project.org/#/c/83480/ https://codereview.qt-project.org/#/c/84338/ https://github.com/mik3y/usb-serial-for-android As a consequence, Qt has no support for non-rooted serial port on Android. AFAIK there is no alternative to usb-serial-for-android (other than reinventing it from scratch with a more acceptable license). Or is there? Is there any chance Mike's patches are at least merged as an optional feature which is not compiled by default? Thank you -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ 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] optimizing QComposeInputContext / TableGenerator?
Il 19/01/2015 20:15, Milian Wolff ha scritto: The best approach of course would be to have a OpenDesktop standard that allows mmapping the compose table in and using it from there. Probably not feasible. Why not? Also cf. https://codereview.qt-project.org/#/c/74524/ https://codereview.qt-project.org/#/c/74537/ -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtContacts - New class QContactCollection
Hey guys, I started to implement the class QContactCollection based on QOrganizeCollection[1]. Until now I just copy the code from QOrganizer module and renamed some classes. The idea of QContactCollection is to represent an address-book. And with this we can create/remove/modify collection and query contacts based on the collection id. This looks great, but I have one concern about that. How to represent contacts that are present in more than one Address book (merged contacts)? In this case the contact can have more than one collection. Do you have any idea how to solve that? Should we use a different approach? What about use QContactCollectionId as a derived class from QContactDetails? [1] https://codereview.qt-project.org/#/c/104026/ Thanks Renato Araujo Oliveira Filho ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
