Re: [Development] UDS feedback
On Mon, May 21, 2012 at 08:32:31AM -0700, ext Girish Ramakrishnan wrote: It would be nice if we can make things simpler for all distros by renaming our tools. What do we gain from keeping the same name for all our tools across major versions? we don't complicate our own release process with a downstream issue. we don't complicate things for non-distro users. also, we are not going to call our tools moc-qt5, etc., as that's just ugly. as many distros do just that, so we would break their standard anyway. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] UDS feedback
On Tue, May 22, 2012 at 01:44:36PM +0200, ext Thiago Macieira wrote: On terça-feira, 22 de maio de 2012 11.16.31, Oswald Buddenhagen wrote: On Mon, May 21, 2012 at 08:32:31AM -0700, ext Girish Ramakrishnan wrote: It would be nice if we can make things simpler for all distros by renaming our tools. What do we gain from keeping the same name for all our tools across major versions? we don't complicate our own release process with a downstream issue. we don't complicate things for non-distro users. Aren't the two statements contradictory? if we don't complicate things for non-distro users, then it stands to reason that we want to facilitate for distro users. Then we do care about a downstream issue. huuuh? changing the names of the executables complicates life for everyone, including distro [package] users. for the latter it just happens to be the lesser evil. also, we are not going to call our tools moc-qt5, etc., as that's just ugly. as many distros do just that, so we would break their standard anyway. I agree it's ugly, but it is what Linux users are likely to find. Should we not standardise on that? there is a tad more out there than linux ... ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] UDS feedback
On Sat, May 12, 2012 at 1:34 PM, Thiago Macieira thiago.macie...@intel.com wrote: On sábado, 12 de maio de 2012 12.13.09, Girish Ramakrishnan wrote: 5. QPA plugins + packaging: One can install the wayland and xcb plugin simultaneously. We need a mechanism to switch the QPA plugin globally for all apps. One can use environment variables right now, but maybe we should also pick up from qt.conf (if it doesn't already) ? I don't see the problem with an environment variable. I think the most important part is that we actually have a reasonable, auto- detected default. If the application is run under Wayland, it loads the Wayland plugin. Currently, our default on each platform is hardcoded. Windows - windows Linux - xcb Mac - cocoa The default can be changed by passing -qpa wayland to configure. IOW, the default is built into the qtgui binary. There is no runtime detection of default. The use case where the env variable doesn't work well is: User is running qt/xcb today. User installs qt/wayland plugin to test wayland support. I guess the distro package has to then modify /etc/environ or something? Is there a better way environment variables can be set (and better just for Qt apps). I don't really have a solution. (qt.conf seems an OK solution) Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] UDS feedback
On Mon, May 14, 2012 at 2:28 AM, Oswald Buddenhagen oswald.buddenha...@nokia.com wrote: On Sat, May 12, 2012 at 12:13:09PM -0700, ext Girish Ramakrishnan wrote: 2. Rename our qt5 tool binaries - the binary names of moc, uic, qmake conflict in qt3 and qt4. Now with qt5, we will have another conflict. Is it possible to rename all our tool binaries to be moc5, qmake5? i don't want to do that upstream. our answer is to use disjoint binary paths. as distributors fiddle with our directory structure anyway, they can continue to adjust that as well. if uniformity across distros is a concern, *they* should harmonize it. qt-project.org can host a Packaging_Recommendations wiki, if that is deemed to be helpful. I guess they install the binaries (or create symlinks) in /usr/bin because that's what is in the users path. It would be nice if we can make things simpler for all distros by renaming our tools. What do we gain from keeping the same name for all our tools across major versions? Girish ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] UDS feedback
On 05/22/2012 01:27 AM, ext Girish Ramakrishnan wrote: I think the most important part is that we actually have a reasonable, auto- detected default. If the application is run under Wayland, it loads the Wayland plugin. Currently, our default on each platform is hardcoded. Windows - windows Linux - xcb Mac - cocoa The default can be changed by passing -qpa wayland to configure. IOW, the default is built into the qtgui binary. There is no runtime detection of default. The use case where the env variable doesn't work well is: User is running qt/xcb today. User installs qt/wayland plugin to test wayland support. I guess the distro package has to then modify /etc/environ or something? Is there a better way environment variables can be set (and better just for Qt apps). I don't really have a solution. (qt.conf seems an OK solution) This bug was created some time ago to bring order to the platform plugin problem. It proposes configure arguments for selecting the platform plugins to build as well as a way to select the default platform plugin to use. If there's a way to detect the environment you're running under that would be even better than a compiled-in default. https://bugreports.qt-project.org/browse/QTBUG-21881 -- Lincoln Ramsay - Senior Software Engineer Qt Development Frameworks, Nokia - http://qt.nokia.com/ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] UDS feedback
On Sat, May 12, 2012 at 12:13:09PM -0700, ext Girish Ramakrishnan wrote: 2. Rename our qt5 tool binaries - the binary names of moc, uic, qmake conflict in qt3 and qt4. Now with qt5, we will have another conflict. Is it possible to rename all our tool binaries to be moc5, qmake5? i don't want to do that upstream. our answer is to use disjoint binary paths. as distributors fiddle with our directory structure anyway, they can continue to adjust that as well. if uniformity across distros is a concern, *they* should harmonize it. qt-project.org can host a Packaging_Recommendations wiki, if that is deemed to be helpful. Are Qt4 qmake and Qt5 qmake completely compatible (I think not). *something* will break for sure. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] UDS feedback
Hi, On 12 May 2012 21:13, Girish Ramakrishnan gir...@forwardbias.in wrote: Hi Guys, Here's some comments that I collected from UDS last week. Quim, Donald, Thiago and Adam might have more to add. I have cc'ed Jonathan who was giving us a lot of the feedback, he should be able to point us to the right people for further collaboration. 1. Qt SDK vs Ubuntu repo install - Currently, Qt SDK is a separate download from Nokia website. Ubuntu packages creator and Qt. This could cause confusion as to which to choose. I think the decision made here was that this is not entirely solvable since Qt SDK contains much more than creator and Qt (it has the sysroots and toolchains required for the devices). Is it possible for us to bundle sysroots and toolchains separately? That way, ubuntu repos can be the definitive place to download creator and qt. please consider that in the near future Ubuntu will have *more* Qt applications (I'm talking about system applications, just like now they have the UbuntuOne client etc...) and I suppose they will want to avoid regressions or incompatibility problems caused by a newer version of QtSDK. If we think about Qt and QtCreator just as an SDK to write applications I agree with you that developers should have the latest tools available, but about the *runtime* I think that a distribution should stay with the one they've used for months to test the applications with. p.s: don't take this wrongly... I'm not saying that newer versions of Qt usually cause regressions or incompatibility, but even a could is enough to make me think about a stable runtime. Best regards, -- Andrea Grandi - Nokia Qt Ambassador Ubuntu Member: https://launchpad.net/~andreagrandi website: http://www.andreagrandi.it ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] UDS feedback
Hi, 1. Qt SDK vs Ubuntu repo install - Currently, Qt SDK is a separate download from Nokia website. Ubuntu packages creator and Qt. This could cause confusion as to which to choose. I think the decision made here was that this is not entirely solvable since Qt SDK contains much more than creator and Qt (it has the sysroots and toolchains required for the devices). Is it possible for us to bundle sysroots and toolchains separately? That way, ubuntu repos can be the definitive place to download creator and qt. Are you saying that I'll have to download Qt 5 for my Fedora 17 from an Ubuntu repository ? I think I didn't understand this point. 2. Rename our qt5 tool binaries - the binary names of moc, uic, qmake conflict in qt3 and qt4. Now with qt5, we will have another conflict. Is it possible to rename all our tool binaries to be moc5, qmake5? Are Qt4 qmake and Qt5 qmake completely compatible (I think not). Ossi, comments? Why not to rename qmake (from Qt3 and Qt4) as qmake-qt3 and qmake-qt4 respectively in the distribution ? 4. gerrit does not have a patch download system. For the moment, you can use gitorious like http://qt.gitorious.org/qt/qtbase/commit/f1ea4ed3d4b45b2eda0a695c61f743cecc0644da?format=patch git fetch https://codereview.qt-project.org/p/qt/qtbase refs/changes/45/26045/1 git format-patch -1 --stdout FETCH_HEAD You can get this link from the Web UI Cheers, -- Sergio Ahumada Navea s...@sansano.inf.utfsm.cl ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] UDS feedback
On sábado, 12 de maio de 2012 22.01.09, Sergio Ahumada Navea wrote: 1. Qt SDK vs Ubuntu repo install - Currently, Qt SDK is a separate download from Nokia website. Ubuntu packages creator and Qt. This could cause confusion as to which to choose. I think the decision made here was that this is not entirely solvable since Qt SDK contains much more than creator and Qt (it has the sysroots and toolchains required for the devices). Is it possible for us to bundle sysroots and toolchains separately? That way, ubuntu repos can be the definitive place to download creator and qt. Are you saying that I'll have to download Qt 5 for my Fedora 17 from an Ubuntu repository ? I think I didn't understand this point. No, that was only in the context of what the Ubuntu community officially recommends to its own users. Other distributions may choose to do the same, or point to the official SDK which we release. 2. Rename our qt5 tool binaries - the binary names of moc, uic, qmake conflict in qt3 and qt4. Now with qt5, we will have another conflict. Is it possible to rename all our tool binaries to be moc5, qmake5? Are Qt4 qmake and Qt5 qmake completely compatible (I think not). Ossi, comments? Why not to rename qmake (from Qt3 and Qt4) as qmake-qt3 and qmake-qt4 respectively in the distribution ? They already have a qmake-qt4, which they accomplish by applying a patch. The question is whether we're willing to rename the tool ourselves. From what I understand, their build will have a renamed tool anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] UDS feedback
On sábado, 12 de maio de 2012 12.13.09, Girish Ramakrishnan wrote: 5. QPA plugins + packaging: One can install the wayland and xcb plugin simultaneously. We need a mechanism to switch the QPA plugin globally for all apps. One can use environment variables right now, but maybe we should also pick up from qt.conf (if it doesn't already) ? I don't see the problem with an environment variable. I think the most important part is that we actually have a reasonable, auto- detected default. If the application is run under Wayland, it loads the Wayland plugin. Changing anything would only be necessary if you want to test (and, usually, have more than one system). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] UDS feedback
On Saturday 12 May 2012 22:01:09 Sergio Ahumada Navea wrote: Hi, 1. Qt SDK vs Ubuntu repo install - Currently, Qt SDK is a separate download from Nokia website. Ubuntu packages creator and Qt. This could cause confusion as to which to choose. I think the decision made here was that this is not entirely solvable since Qt SDK contains much more than creator and Qt (it has the sysroots and toolchains required for the devices). Is it possible for us to bundle sysroots and toolchains separately? That way, ubuntu repos can be the definitive place to download creator and qt. Are you saying that I'll have to download Qt 5 for my Fedora 17 from an Ubuntu repository ? I think I didn't understand this point. I beleive this was only related to Ubuntu user, But you would have the same problem with every distribution. On Fedora, one would typically download Qt from a fedora repository. Each linux distribution will do its own package. 2. Rename our qt5 tool binaries - the binary names of moc, uic, qmake conflict in qt3 and qt4. Now with qt5, we will have another conflict. Is it possible to rename all our tool binaries to be moc5, qmake5? Are Qt4 qmake and Qt5 qmake completely compatible (I think not). Ossi, comments? Why not to rename qmake (from Qt3 and Qt4) as qmake-qt3 and qmake-qt4 respectively in the distribution ? That is not a bad idea. But this is leaving the problem to the distributions. Then all the distributions will have to solve this problem again. And they might use different ways, leading in inconsistencies accross distributions. We probably would like to avoid fragmentation. Another solution for moc and uic could be to move them to some libexec path (as they are only supposed to be called by the build system) 4. gerrit does not have a patch download system. For the moment, you can use gitorious like http://qt.gitorious.org/qt/qtbase/commit/f1ea4ed3d4b45b2eda0a695c61f743cec c0644da?format=patch git fetch https://codereview.qt-project.org/p/qt/qtbase refs/changes/45/26045/1 git format-patch -1 --stdout FETCH_HEAD You can get this link from the Web UI If I understand the problem here, Ubuntu would like easy way to get patches they can backport into their packages. I think gerrit is not the tool for that, so i don't see that as an issue. -- Olivier Woboq - Qt services and support - http://woboq.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
