Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
On 23/10/12 15:10, d3fault wrote: Also please tell me why I can't join the Qt Security Team without contradicting yourselves. You haven't earned the trust of the people in charge. The current security team members have earned the trust of the people in charge. No contradictions there. -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
You haven't earned the trust of the people in charge. The current security team members have earned the trust of the people in charge. No contradictions there. Why do they need to trust me? Because the information is dangerous. By admitting that the information is dangerous, they are admitting that having + holding the information is dangerous (even for them!!!). By holding onto the information, they are putting us all in danger. Thus, contradiction. Full Disclosure levels the playing field. It gives a slight advantage to script kiddies, yes... ...but it gives us a [different] much larger advantage: Knowledge. Knowledge is useful for shutting down to thwart ongoing zero day attacks... and also the mere availability of the knowledge prevents entirely the analyst leakage (or anal. leakage for short :-P) scenario I've described countless times. d3fault Other: The public disclosure increases the incentive for a fix to be researched/discovered/published/audited(more eyes = less bugs), but this argument is weak so I probably shouldn't even have mentioned it. not to mention: the people in the security team are the people in charge -_-. flawed logic is flawed. You're like the priests in the early days hiding information (the ability to read and write) and trying to convince us it's for our own good. Time will tell who is right. su time; echo d3fault is right; exit; ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Heads up for Windows devs: ANGLE landing soon
This is just a heads up for people developing Qt on Windows. We will shortly add a copy of the ANGLE project into the Qt 3rdparty tree and make it the default OpenGL configuration if no other option is given. If you're not familiar with ANGLE, you can read about it here: http://code.google.com/p/angleproject/ You need to have the DirectX SDK installed to build ANGLE. It works on MSVC and MinGW (both 32-bit and 64-bit). If you would prefer to continue using desktop OpenGL, then simply pass -opengl desktop to configure and you should get the same behavior as before. The change on Gerrit is here: https://codereview.qt-project.org/#change,37290 I'm working on updating the installation and deployment docs as well as writing a blog post to give some more details. Regards, Jason ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Patch for dynamic updates to the screen's DPI settings
Dear Qt developers, I got a new toy at work -- a 27 LCD with some crazy resolution (2560x1440 IIRC), i,e. its pixel density is roughly 109 PPI. The LCD I use at home has got a 94 PPI grid. I frequently move my laptop between these two places and I have yet to make my KDE 4.9 use fonts which look great no matter which display I switched to at runtime. The current state is driving me nuts; I have to constantly adjust the font size in KDE's preferences *and* restart the applications afterwards, so that they pick up the new font preferences. That's not the first thing I want to do when I get to work in the morning. It looks like Qt 4.8.3 doesn't provide dynamic updates to the DPI value to the applications. The attached patch does just that; it simply updates the value which is returned by QX11Info::appDpiX() and appDpiY when XRandR informs about new geometry. No fancy signalling is done. The results are actually pretty funny; it looks like a QTreeView would use the new font size only for text items whose font previously did not fit the column width while those which fit will remain in the previous size; there are also no changes to stuff like height of the menu bars, the layouts won't change, and so on. On the other hand, it's now enough to reopen the current file in Qt Creator and the font size reflects the new DPI. I don't know anything about Qt internals (and I suspect that this is not exactly an area a newcomer should dive into), so I'll appreciate some pointers about what else would need changing in order for dynamic DPI to work. Or is this a futile attempt which is doomed to failure anyway? Are there any chances of getting this accepted, eventually? Yes and no (depending). There are several approaches to DPI scaling. I'm working on a patch to Qt 5 that implements the retina or web bowser type of scaling that creates a distinction between device independent pixels and device pixels. Detecting and reacting to DPI changes would be a natural addition to the patch, but it's for Qt 5 only so it won't help you right away. (I have a smaller mac-only patch for Qt 4). This approach has the following characteristics: - Everything is scaled: fonts, layouts and all. There should be no funny results. - Scaling means that Qt apps see a smaller desktop geometry. The graphics backing store and OpenGL contexts are full resolution. - A 2x scale factor (around 200 PPI) works best, since there are no misaligned pixels then. - How well it works outside of Mac OS X is uncertain. We're adapting the new fusion style to work in high-dpi mode and I'm optimistic that it can be useful. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Heads up for Windows devs: ANGLE landing soon
On Oct 23, 2012, at 11:38 AM, Sean Harmer sean.har...@kdab.com wrote: On Tuesday 23 October 2012 08:26:51 Jason Barron wrote: This is just a heads up for people developing Qt on Windows. We will shortly add a copy of the ANGLE project into the Qt 3rdparty tree and make it the default OpenGL configuration if no other option is given. Hmm, I would much rather this was opt-in rather than being the default and having to opt-out. It unnecessarily limits the OpenGL version for people who don't have crappy Intel OpenGL drivers on windows. Well, currently we need this so that Qt runs out of the box on a stock windows installation. This is because stock Windows only supports OpenGL 1.x and we need 2.0 for QML. Is it possible to defer the choice to runtime rather than have it at compile time? In principle yes, but quite some work to get it done. You need to dynamically reroute all GL calls. The main problem here is that applications using Qt often also call into the GL library directly. But it's out of scope for 5.0. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt 4.8.4 release candidates are available
Hi all, Now there are Qt 4.8.4 release candidate packages available for public review. These are not yet the official release packages and should not be used as such. Packages are built against SHA1: 8869b3b30a29b1dd4218b3f5ac0bec9dd936b664 and are available at http://origin.releases.qt-project.org/digia/4.8.4_RC/ Have fun! Br, Juhani -- Juhani Taipale Software Specialist - Digia, Qt Visit us on: http://qt.digia.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Heads up for Windows devs: ANGLE landing soon
2012/10/23 Jason Barron jason.bar...@outlook.com It works on MSVC and MinGW (both 32-bit and 64-bit). Sounds great! But I thought it should only work with mingw-w64 (support directx9), not mingw.org, that right? -- *Please don't ask where I come from, It's a shame!* Best Regards Yuchen ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Fwd: Proposing Thomas Hartmann as my successor
Hi, since I am no longer working full time on Qt Creator, I am hereby stepping back from my position as the maintainer of the Qt Creator Welcome Mode (http://qt-project.org/wiki/Maintainers) to ensure it doesn't get blocked by me not being able to respond in a timely manner or to maintain it. I propose that Thomas should be my successor, since he has practically filled that role for more than half a year by now. Cheers, Daniel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fwd: Proposing Thomas Hartmann as my successor
On 23.10.2012, at 14:27, Daniel Molkentin wrote: I propose that Thomas should be my successor, since he has practically filled that role for more than half a year by now. Thomas being Thomas Hartmann obviously, since I forgot to set him on CC before sending, that context got lost. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Fwd: Proposing Thomas Hartmann as my successor
On 23 Oct 2012, at 14:28, Daniel Molkentin dan...@molkentin.de wrote: On 23.10.2012, at 14:27, Daniel Molkentin wrote: I propose that Thomas should be my successor, since he has practically filled that role for more than half a year by now. Thomas being Thomas Hartmann obviously, since I forgot to set him on CC before sending, that context got lost. +1 The UI implementation is mostly his already now. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On Mon, Oct 22, 2012 at 01:38:56PM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 20.52.49, Oswald Buddenhagen wrote: I can't fix what's already broken due to the Qt 3 and Qt 4 mess. I can only fix going forward for Qt 5. i fail to see your argument here. what exactly is the reason why having the apps and the tools in the same bindir would be bad? Because qdbus should be in /usr/bin but the version- and arch-specific qmake should be somewhere in /usr/lib*/qt5. ok, i can buy that as such. however, i totally see no point in us doing this upstream, and why qmake (or even qlibraryinfo) should be in any way concerned with it. Symlinking the other tools is optional and should not be the default. as i said three times already, lupdate is usefully user-invokable, and the gui tools will be renamed by some distros anyway - so it is only reasonable to isolate and include them into the aliasing magic - always, to avoid fragmentation. So we provide symlinks for a few of the tools in addition to qmake, but I don't see why moc should be in $PATH. The number of people who actually run it manually must be countable in one hand. i'm pretty sure that *some* build systems rely on moc being in the path. one could argue that they are broken - but then, it exactly fits the /usr/bin philosophy, so it's hard to blame them. On the other hand (the one not counting people), applications like qdbus or xmlpatterns make no sense to have in duplication. actually, xmlpatterns (just like lupdate) can be usefully called both manually and from build scripts. i meant a qt tool without the symlink trick. you totally don't want to update all documentation to say qt qmake, etc., and as a user i positively don't want to type that. I do want to update all the documentation to say qmake -qt5. well, i'm pretty sure you didn't really think about that. otherwise i'd have to declare you insane. (all the documentation is a tad more than a few qdoc files). Yes, I really meant it. We have to start somewhere. it's official then: you are insane. :D anyway, i would think that both we and our users have better things to do ... and as you may have noticed, rewriting the book (in this case kinda literally) is typically met with skepticism, to put it mildly. I would prefer to have the tool inside qtbase, [...] since this tool is the entry point for building Qt5-based applications, it must either come with Qt or not depend upon it. actually, not at all. as we established, this is an entirely optional, external add-on. it's not necessary for building qt at all - the environment in which qt is built can be very well self-contained, as it has always been. i strongly prefer to have it outside qt itself. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
Re on adjusting all the documentation to say run qmake -qt5: Let's count who will have Qt5 co-/installed: 1) Those who's DE is built against Qt5 and thus Qt5 is the default Qt there; though, they may have Qt4 co-installed until all the qt-apps in-use are ported to Qt5; 2) Those who are still on Qt4-based DE but want some qt-apps where Qt5 is installed as a dependency (most-probably they'll have the libraries only); 3) Developers who need to build something against Qt5; 4) Ones who installs everything because they do not know what they are doing ;) Only 1) and 3) are the ones who do need qmake. In both cases, it seems to be safe to make Qt5 the default version that qmake is pointing to. Moreover, shouldn't we mention Qt5 as a drop-in replacement for Qt3/Qt4? So if the user does need to build something Qt based, let the latest system-wide Qt version be the default one! I fhe doesn't, he don't need qmake either. Summary: to me, it seems like keep saying run qmake in the docs is quite enough... kind regards, Konstantin 2012/10/23 Oswald Buddenhagen oswald.buddenha...@digia.com: On Mon, Oct 22, 2012 at 01:38:56PM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 20.52.49, Oswald Buddenhagen wrote: I can't fix what's already broken due to the Qt 3 and Qt 4 mess. I can only fix going forward for Qt 5. i fail to see your argument here. what exactly is the reason why having the apps and the tools in the same bindir would be bad? Because qdbus should be in /usr/bin but the version- and arch-specific qmake should be somewhere in /usr/lib*/qt5. ok, i can buy that as such. however, i totally see no point in us doing this upstream, and why qmake (or even qlibraryinfo) should be in any way concerned with it. Symlinking the other tools is optional and should not be the default. as i said three times already, lupdate is usefully user-invokable, and the gui tools will be renamed by some distros anyway - so it is only reasonable to isolate and include them into the aliasing magic - always, to avoid fragmentation. So we provide symlinks for a few of the tools in addition to qmake, but I don't see why moc should be in $PATH. The number of people who actually run it manually must be countable in one hand. i'm pretty sure that *some* build systems rely on moc being in the path. one could argue that they are broken - but then, it exactly fits the /usr/bin philosophy, so it's hard to blame them. On the other hand (the one not counting people), applications like qdbus or xmlpatterns make no sense to have in duplication. actually, xmlpatterns (just like lupdate) can be usefully called both manually and from build scripts. i meant a qt tool without the symlink trick. you totally don't want to update all documentation to say qt qmake, etc., and as a user i positively don't want to type that. I do want to update all the documentation to say qmake -qt5. well, i'm pretty sure you didn't really think about that. otherwise i'd have to declare you insane. (all the documentation is a tad more than a few qdoc files). Yes, I really meant it. We have to start somewhere. it's official then: you are insane. :D anyway, i would think that both we and our users have better things to do ... and as you may have noticed, rewriting the book (in this case kinda literally) is typically met with skepticism, to put it mildly. I would prefer to have the tool inside qtbase, [...] since this tool is the entry point for building Qt5-based applications, it must either come with Qt or not depend upon it. actually, not at all. as we established, this is an entirely optional, external add-on. it's not necessary for building qt at all - the environment in which qt is built can be very well self-contained, as it has always been. i strongly prefer to have it outside qt itself. ___ 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] Updating Serializing Qt Data Types documentation
After https://codereview.qt-project.org/#change,37988, the Serializing Qt Data Types page lists the QDataStream version as 13. I thought it'd be a good idea to ask everyone who is interested to take a look and see if the descriptions of the data types serialised are still accurate. If they're not, please update the page (the path to which can be found in the aforementioned patch). Cheers.___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposing Thomas Hartmann as my successor
On Oct 23, 2012, at 2:34 PM, Ziller Eike eike.zil...@digia.com wrote: On 23 Oct 2012, at 14:28, Daniel Molkentin dan...@molkentin.de wrote: On 23.10.2012, at 14:27, Daniel Molkentin wrote: I propose that Thomas should be my successor, since he has practically filled that role for more than half a year by now. Thomas being Thomas Hartmann obviously, since I forgot to set him on CC before sending, that context got lost. +1 The UI implementation is mostly his already now. Another +1. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On terça-feira, 23 de outubro de 2012 15.04.10, Oswald Buddenhagen wrote: Because qdbus should be in /usr/bin but the version- and arch-specific qmake should be somewhere in /usr/lib*/qt5. ok, i can buy that as such. however, i totally see no point in us doing this upstream, and why qmake (or even qlibraryinfo) should be in any way concerned with it. We've been over this: because I'd rather do this right and once and for all. Who are the best people to make sure that all tools continue to work under those conditions? Upstream is. The alternative is that we're responsible for the configuration that dowsntreams use as well as the patches they may have had to apply to make it work. So we provide symlinks for a few of the tools in addition to qmake, but I don't see why moc should be in $PATH. The number of people who actually run it manually must be countable in one hand. i'm pretty sure that *some* build systems rely on moc being in the path. one could argue that they are broken - but then, it exactly fits the /usr/bin philosophy, so it's hard to blame them. We've been over this, again. If they rely on $PATH without user intervention, they are already broken, as /usr/bin/moc might be Qt 4's. But I'm not against wrapping the tools. On the other hand (the one not counting people), applications like qdbus or xmlpatterns make no sense to have in duplication. actually, xmlpatterns (just like lupdate) can be usefully called both manually and from build scripts. True, but unlike lupdate, the functionality, purpose and output do not change from version to version. The Qt 5 xmlpatterns cleanly replaces the old Qt 4 one. There's no need to duplicate. I do want to update all the documentation to say qmake -qt5. well, i'm pretty sure you didn't really think about that. otherwise i'd have to declare you insane. (all the documentation is a tad more than a few qdoc files). Yes, I really meant it. We have to start somewhere. it's official then: you are insane. :D anyway, i would think that both we and our users have better things to do ... and as you may have noticed, rewriting the book (in this case kinda literally) is typically met with skepticism, to put it mildly. Correcting 15 years of doing installations takes time and usually meets with resistance. I would prefer to have the tool inside qtbase, [...] since this tool is the entry point for building Qt5-based applications, it must either come with Qt or not depend upon it. actually, not at all. as we established, this is an entirely optional, external add-on. it's not necessary for building qt at all - the environment in which qt is built can be very well self-contained, as it has always been. i strongly prefer to have it outside qt itself. If we add the -qt5 option to the traditional qmake, then it can be considered optional. I still prefer to develop it inside qtbase. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
From: Thiago Macieira thiago.macie...@intel.com Subject: Re: [Development] New proposal for the tool naming On segunda-feira, 22 de outubro de 2012 21.21.17, André Pönitz wrote: On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald Buddenhagen wrote: On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote: Note: this applies to the *tools* only. The library naming and installation paths for plugins and QML files has remained uncontested so far, so we appear to have a consensus. only if you conveniently ignore my two (or three?) mails saying the exact opposite. the problem with renaming the libraries is the same as with tools: project files not based on qmake need to be adjusted. Indeed, but I contest that those changes are minor, expected and understandable. The vast majority of the users are probably using either qmake or cmake (99%?) and those are taken care of already. That would leave Visual Studio at less than 1%, which is certainly not in sync with any survey I've seen during the last ten years. I must confess I have no idea how many people are using Visual Studio today and I must also admit I have not a clue about how the add-in or qmake- generated .vcproj files work. But I can make one qualified assumption: if you can start Visual Studio from outside the Qt prompt, then those .vcproj files and the add-in must work -- somehow -- without depending on $PATH. That means they either hardcode a path or they find it somewhere in the registry. My guess is both: qmake hardcodes the paths in the .vcproj it generates and the add-in finds Qt through the registry. That would put them in Bucket B in my list. Qmake puts hard coded values into the VC Project files. The Visual Studios Plug-in, last I used it, puts in a referential value - $(QtDir) IIRC - that it defines, and is suppose to let you switch between versions. Where it finds the versions, I don't know. $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On 22 Oct 2012, at 17:11, Thiago Macieira thiago.macie...@intel.com wrote: On segunda-feira, 22 de outubro de 2012 14.59.09, Ziller Eike wrote: Just as a side note, that requires that Windows and Mac to also have this tool, and e.g. on Windows to have that tool in the PATH and pointing to the corresponding Qt for the environment set up shell scripts. In the SDK, the tools/ directory might be a good place for it. It's easy to add a -qt5 ignored option to the regular qmake too. So that if you happen to have a real qmake instead of the wrapper in the PATH on linux, you don't realize that when you are doing qmake -qt5 to force most current qt5 version (or whatever the semantics would be), you actually execute a completely different qmake? I don't think that would be a good idea. It will do that too if it's in a separate build looking at a non-standard configuration path. I don't get what you mean with that. That's mostly what's going to happen on Windows anyway, isn't it? My concerns are about having -qt5 ignored for the real qmake on linux. On Windows and Mac the -qt option is useless anyhow (which makes it questionable to use it there IMO, so it makes it questionable to use it in the documentation that way too IMO) I think all this becomes much too confusing. -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote: So that if you happen to have a real qmake instead of the wrapper in the PATH on linux, you don't realize that when you are doing qmake -qt5 to force most current qt5 version (or whatever the semantics would be), you actually execute a completely different qmake? I don't think that would be a good idea. It will do that too if it's in a separate build looking at a non-standard configuration path. I don't get what you mean with that. Er... convoluted way of saying that if you only have one Qt build visible from the wrapper, qmake -qt5 can mean exactly one Qt build. Therefore, by exclusion of any other alternatives, it's the most recent build available :-) In any case, -qt5 may not mean latest, but simply default 5.x version. The implementation will decide what that means. That's mostly what's going to happen on Windows anyway, isn't it? My concerns are about having -qt5 ignored for the real qmake on linux. On Windows and Mac the -qt option is useless anyhow (which makes it questionable to use it there IMO, so it makes it questionable to use it in the documentation that way too IMO) I think all this becomes much too confusing. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On terça-feira, 23 de outubro de 2012 18.29.34, Oswald Buddenhagen wrote: We've been over this: because I'd rather do this right and once and for all. Who are the best people to make sure that all tools continue to work under those conditions? Upstream is. the thing is that this is a non-change. *nothing* needs to be changed in the sources - it's only a question of where the package manager is told to put the executable. i don't see why we should introduce any complexity upstream for a problem that is cleanly solved by downstream for decades. You do realise that there has been *no* clean solution developed downstream, right? Much less for decades. Renaming qmake to qmake-qt4 is not a clean solution. Our heretofore requirement of changing PATH has been largely ignored by everyone on the Linux world, and has been applied to the Mac world only recently (up until the SDKs, we distributed globally-installed frameworks). History so far shows that if we don't do it, distributions won't do it cleanly either. I have much more confidence in them getting it right if *we* get it right for them. I'd much rather make it easier for them by making it so they have to do very little or nothing. I know packagers are intelligent people, but they're also busy people. Qt is hardly the only package they take care of. But it's one that takes a disproportionate amount of resources to maintain and also to build. i'm pretty sure that *some* build systems rely on moc being in the path. one could argue that they are broken - but then, it exactly fits the /usr/bin philosophy, so it's hard to blame them. We've been over this, again. If they rely on $PATH without user intervention, they are already broken, as /usr/bin/moc might be Qt 4's. they are not broken, because relying on a correctly set up $PATH is an entirely reasonable position. I beg to differ, again. That's the position we've been taking for the 15 years of the existence of moc and the 10 years of qmake, but we've not been listened to. We may think and we definitely have thought it was reasonable to ask. But history shows that we haven't been listened to. Therefore, it's not reasonable to *keep* asking. the problem you are trying to solve is limited to co-installation into a single path, which is a policy-imposed problem of linux distributions. it is incredibly silly to claim that something that does not comply with this policy is broken by definition. I understand and even agree with your interpretation: the brokenness isn't our doing, not alone anyway. Nevertheless, it is broken. Blame all you want the distributors. They won't change their policies for us or for the handful of other packages that aren't distro-friendly. We have a saying in Portuguese, dar murro em ponta de faca (roughly translates to punching the pointy edge of a knife), which applies to when one insists in doing something painful and clearly ill-advised. Insisting on our Qt 4 advice is that, since there's no indication our advice will be listened to any more than in the past. We tried, we failed. Time to try something different. True, but unlike lupdate, the functionality, purpose and output do not change from version to version. The Qt 5 xmlpatterns cleanly replaces the old Qt 4 one. There's no need to duplicate. your idea doesn't work anyway. the distros won't have the users install the qt5 libraries just because the user requested an xmlpatterns package, when a qt4-based xmlpatterns can be had almost for free for those which already have qt4 libs installed. and some distros won't have two alternative xmlpatterns packages which provide the same binary - because of non-conflict policies. the bottom line is that there will be qt version bound sets of all tools and apps, and that they will have to meet the co-installability requirements. The difference is that xmlpatterns, like qdbus and the other applications, can be updated by the Debian alternatives mechanism. They're just two different implementations of the same functionality. The solution for that problem already exists. The solution for the qmake problem does not, at least not a solution that has been applied. Though I want to hear from distros what they think of the fact that Designer is being put in the same bucket. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating Serializing Qt Data Types documentation
On Tue, 23 Oct 2012, Mitch Curtis wrote: After https://codereview.qt-project.org/#change,37988, the Serializing Qt Data Types page lists the QDataStream version as 13. I thought it'd be a good idea to ask everyone who is interested to take a look and see if the descriptions of the data types serialised are still accurate. If they're not, please update the page (the path to which can be found in the aforementioned patch). Coincidentally we noticed a over-the-wire serialization problem today. With QVariant. But it's likely not an issue with above mentioned format version 13. Rather with a backward compat mode. Do I see it correctly that tests/ only cover 4.9 and 5.0 versions? Hmmm. I now realize that I can answer this question myself given that the coverage results we just posted... http://download.froglogic.com/public/qt5-squishcoco-report/QtBase/source_143.html (see QVariant::load() and save()) We'll investigate what's going on and submit a patch if it's a problem in QVariant or QDataStream. Harri. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
From: Thiago Macieira thiago.macie...@intel.com Sent: Tuesday, October 23, 2012 1:03 PM Subject: Re: [Development] New proposal for the tool naming On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote: So that if you happen to have a real qmake instead of the wrapper in the PATH on linux, you don't realize that when you are doing qmake -qt5 to force most current qt5 version (or whatever the semantics would be), you actually execute a completely different qmake? I don't think that would be a good idea. It will do that too if it's in a separate build looking at a non-standard configuration path. I don't get what you mean with that. Er... convoluted way of saying that if you only have one Qt build visible from the wrapper, qmake -qt5 can mean exactly one Qt build. Therefore, by exclusion of any other alternatives, it's the most recent build available :-) In any case, -qt5 may not mean latest, but simply default 5.x version. The implementation will decide what that means. How is this any better then updating LSB/FHS with guidelines on how to properly install Qt on a Unix/Linux system? Is it not easier to simply say install to /usr/share/qt-5.0.0.0 with a symlink to /usr/share/qt5, and require that distro specific tools manage symlinks to qmake/etc in the path? Or even having /usr/share/qt in the path and simply manage a symlink to it? KISS is a very good principle, and I don't see it being applied in this discussion. Rather we are getting lots of if we do this we solve this, but then if we do that we solve that; and in all cases it is will cause headaches all around except for a few people. That's mostly what's going to happen on Windows anyway, isn't it? My concerns are about having -qt5 ignored for the real qmake on linux. On Windows and Mac the -qt option is useless anyhow (which makes it questionable to use it there IMO, so it makes it questionable to use it in the documentation that way too IMO) I think all this becomes much too confusing. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
On 10/23/12, d3fault d3faultdot...@gmail.com wrote: You're like the priests in the early days hiding information (the ability to read and write) and trying to convince us it's for our own good. Time will tell who is right. su time; echo d3fault is right; exit; That analogy fits better than I first realized. Since the ability to read [books] allows malicious individuals to make bombs, nobody should have the ability to read [books]. -Knars Loll, Thiago Macieira, et al Posts are forever, not just Christmas d3fault ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
How is this any better then updating LSB/FHS with guidelines on how to properly install Qt on a Unix/Linux system? Is it not easier to simply say install to /usr/share/qt-5.0.0.0 with a symlink to /usr/share/qt5, and require that distro specific tools manage symlinks to qmake/etc in the path? Or even having /usr/share/qt in the path and simply manage a symlink to it? DON'T propose one to install libraries to /usr/share - it is not /usr/lib! especially on multiarch/multilib. Konstantin 2012/10/23 BRM bm_witn...@yahoo.com: From: Thiago Macieira thiago.macie...@intel.com Sent: Tuesday, October 23, 2012 1:03 PM Subject: Re: [Development] New proposal for the tool naming On terça-feira, 23 de outubro de 2012 16.33.05, Ziller Eike wrote: So that if you happen to have a real qmake instead of the wrapper in the PATH on linux, you don't realize that when you are doing qmake -qt5 to force most current qt5 version (or whatever the semantics would be), you actually execute a completely different qmake? I don't think that would be a good idea. It will do that too if it's in a separate build looking at a non-standard configuration path. I don't get what you mean with that. Er... convoluted way of saying that if you only have one Qt build visible from the wrapper, qmake -qt5 can mean exactly one Qt build. Therefore, by exclusion of any other alternatives, it's the most recent build available :-) In any case, -qt5 may not mean latest, but simply default 5.x version. The implementation will decide what that means. How is this any better then updating LSB/FHS with guidelines on how to properly install Qt on a Unix/Linux system? Is it not easier to simply say install to /usr/share/qt-5.0.0.0 with a symlink to /usr/share/qt5, and require that distro specific tools manage symlinks to qmake/etc in the path? Or even having /usr/share/qt in the path and simply manage a symlink to it? KISS is a very good principle, and I don't see it being applied in this discussion. Rather we are getting lots of if we do this we solve this, but then if we do that we solve that; and in all cases it is will cause headaches all around except for a few people. That's mostly what's going to happen on Windows anyway, isn't it? My concerns are about having -qt5 ignored for the real qmake on linux. On Windows and Mac the -qt option is useless anyhow (which makes it questionable to use it there IMO, so it makes it questionable to use it in the documentation that way too IMO) I think all this becomes much too confusing. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? $0.02 Ben ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating Serializing Qt Data Types documentation
On Tuesday 23 October 2012 16:17:30 Mitch Curtis wrote: After https://codereview.qt-project.org/#change,37988, the Serializing Qt Data Types page lists the QDataStream version as 13. I thought it'd be a good idea to ask everyone who is interested to take a look and see if the descriptions of the data types serialised are still accurate. If they're not, please update the page (the path to which can be found in the aforementioned patch). Just pushed https://codereview.qt-project.org/#change,38021 to update types of math3d classes. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On terça-feira, 23 de outubro de 2012 10.42.58, BRM wrote: In any case, -qt5 may not mean latest, but simply default 5.x version. The implementation will decide what that means. How is this any better then updating LSB/FHS with guidelines on how to properly install Qt on a Unix/Linux system? Is it not easier to simply say install to /usr/share/qt-5.0.0.0 with a symlink to /usr/share/qt5, and require that distro specific tools manage symlinks to qmake/etc in the path? Or even having /usr/share/qt in the path and simply manage a symlink to it? First of all, because we won't be able to get LSB/FHS to update for us. It just won't happen. And even if we did get that, note that distributions are even more strict than LSB/FHS, since most of them don't use /opt either. So this solution is better than updating because it's achievable. Possible is better than impossible. Second, because updating LSB/FHS isn't enough either. The user still needs to find the Qt 5 qmake somewhere to get started. Updating the documentation to list the full path is worse than updating it to add a -qt5 argument. Managing a symlink in /usr/bin is not an acceptable solution because that requires administrator permissions and it breaks the ability to easily switch between Qt 4 and Qt 5. KISS is a very good principle, and I don't see it being applied in this discussion. Rather we are getting lots of if we do this we solve this, but then if we do that we solve that; and in all cases it is will cause headaches all around except for a few people. I think we are keeping it simple. The current proposal is the simplest that still works. If you can come up with something even simpler, I'll gladly accept it. The stuff you proposed before isn't acceptable because I shot holes through them. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? Drop it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On Tue, Oct 23, 2012 at 10:18:38AM -0700, Thiago Macieira wrote: On terça-feira, 23 de outubro de 2012 18.29.34, Oswald Buddenhagen wrote: We've been over this: because I'd rather do this right and once and for all. Who are the best people to make sure that all tools continue to work under those conditions? Upstream is. the thing is that this is a non-change. *nothing* needs to be changed in the sources - it's only a question of where the package manager is told to put the executable. i don't see why we should introduce any complexity upstream for a problem that is cleanly solved by downstream for decades. You do realise that there has been *no* clean solution developed downstream, right? Much less for decades. Renaming qmake to qmake-qt4 is not a clean solution. [...] this paragraph was about splitting out apps from qt's common bin dir (which would be isolated anyway). therefore the rest of your response is misapplied. i'm pretty sure that *some* build systems rely on moc being in the path. one could argue that they are broken - but then, it exactly fits the /usr/bin philosophy, so it's hard to blame them. We've been over this, again. If they rely on $PATH without user intervention, they are already broken, as /usr/bin/moc might be Qt 4's. they are not broken, because relying on a correctly set up $PATH is an entirely reasonable position. I beg to differ, again. That's the position we've been taking for the 15 years of the existence of moc and the 10 years of qmake, but we've not been listened to. We may think and we definitely have thought it was reasonable to ask. But history shows that we haven't been listened to. Therefore, it's not reasonable to *keep* asking. this paragraph was about released 3rd party apps, and therefore entirely out of our control. we can only make it worse for them. True, but unlike lupdate, the functionality, purpose and output do not change from version to version. The Qt 5 xmlpatterns cleanly replaces the old Qt 4 one. There's no need to duplicate. your idea doesn't work anyway. the distros won't have the users install the qt5 libraries just because the user requested an xmlpatterns package, when a qt4-based xmlpatterns can be had almost for free for those which already have qt4 libs installed. and some distros won't have two alternative xmlpatterns packages which provide the same binary - because of non-conflict policies. the bottom line is that there will be qt version bound sets of all tools and apps, and that they will have to meet the co-installability requirements. The difference is that xmlpatterns, like qdbus and the other applications, can be updated by the Debian alternatives mechanism. yes, debian. have you checked that this is true for all relevant downstreams? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
On 10/23/12, Donald Carr sirsp...@gmail.com wrote: life is clearly not a popularity contest for d3fault. rofl thank you for that compliment. better than Charley telling me I'm smart repeatedly -_- I agree completely!!! It's just that the recommended/officially-endorsed way of reporting security vulnerabilities is to the private mailing list. secur...@qt-project.org should be official/public, security-priv...@qt-project.org should be OFFERED, but not the 'official' way. The analyst who discovers the vuln can choose whatever he wants. He can even sell it to crackers... lol. qt-project.org/security/index.html should read something like this: If you discover a vulnerability, please report it to secur...@qt-project.org and we'll take care of the rest. You can of course join in on the discussion and suggest fixes etc, as Qt is a COLLABORATIVE PROJECT. If you think the vulnerability would cause harm being publicly disclosed, you can instead send it to security-priv...@qt-project.org --- but remember... just who are those people with access to that list, and can you trust them to not un/intentionally leak your vulnerability? Emphasis added. d3fault ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On Mon, Oct 22, 2012 at 01:46:09PM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 21.21.17, André Pönitz wrote: On Mon, Oct 22, 2012 at 09:08:38AM -0700, Thiago Macieira wrote: On segunda-feira, 22 de outubro de 2012 15.45.56, Oswald Buddenhagen wrote: On Fri, Oct 19, 2012 at 04:16:14PM -0700, Thiago Macieira wrote: Note: this applies to the *tools* only. The library naming and installation paths for plugins and QML files has remained uncontested so far, so we appear to have a consensus. only if you conveniently ignore my two (or three?) mails saying the exact opposite. the problem with renaming the libraries is the same as with tools: project files not based on qmake need to be adjusted. Indeed, but I contest that those changes are minor, expected and understandable. The vast majority of the users are probably using either qmake or cmake (99%?) and those are taken care of already. That would leave Visual Studio at less than 1%, which is certainly not in sync with any survey I've seen during the last ten years. I must confess I have no idea how many people are using Visual Studio today and I must also admit I have not a clue about how the add-in or qmake- generated .vcproj files work. I'll try to find a number tomorrow. Until then simply assume we are talking about not-to-modest two-digit percentages. Moreover, it is a reasonable assumption that only few Qt based Windows-only projects supporting VS use qmake at all, and that most non-trivial cross-platform Qt based projects supporting VS maintain a real .vcproj _in parallel_ to a .pro instead of re-creating it using qmake. In effect, we will be still be talking about a non-too-modest two-digit percentage of Qt users that do neither use qmake nor cmake. [...] I beg to differ. Let's take the example of a buildsystem that is trying to retain source compatibility (thus, we're excluding cmake and, for many things, qmake too [think of QT += widgets print-support]). We can group them in two buckets: A) those that run those tools without absolute paths B) those that run them with absolute paths How do they find the absolute path? The only answer is qmake -query QT_INSTALL_BINS. C) It's hard coded. Having company policies saying All sources have to be on a X:\Project 0815\Sources, and Q:\ is subst'ed to a place with a Qt installation we want you to use today is more common than either of us may wish for... You can't add a third option to a binary choice. Either the paths are absolute or they aren't, there's no other alternative. You are absolutely right. I bow to that impeccable line of argument. However, the mere mortal I am was targeting the The only answer is... part. Using absolute paths does not require running qmake -query QT_INSTALL_BINS. Semantics aside, your option C is part of Bucket B: a specific case of absolute paths where the contents of that path change over time. All the user needs is a Qt version that defaults to prefix Q:\. The only problem I see would be if the layout *under* Q:\ is different from version to version [...] It is not the only the layout, but also the exact name of the files. That is precisely one of the cases where any change in naming, including naming of the libraries, is a needless burden. Note, please, that producing a binary is only part of the development process. There is also deployment/packaging which a few build systems declare out of scope. So some projects _do_ have a couple of scripts on top. And some more _do_ use GUI based tools for deployment, with even less flexibility than scripts, and all will need adjustments as soon as any name changes. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
On 24/10/12 07:01, d3fault wrote: If you discover a vulnerability, please report it to secur...@qt-project.org and we'll take care of the rest. You can of course join in on the discussion and suggest fixes etc, as Qt is a COLLABORATIVE PROJECT. If you think the vulnerability would cause harm being publicly disclosed, you can instead send it to security-priv...@qt-project.org --- but remember... just who are those people with access to that list, and can you trust them to not un/intentionally leak your vulnerability? As has already been pointed out, you're confusing things by choosing to assign different names to things. We already have a public and a private list. We're not renaming things or creating new lists just to match the names you think we should have. If you want to report an issue to the Qt project so that the whole world knows about it too, use development@qt-project.org. If you want to report an issue to the Qt project but you think the world perhaps shouldn't know about it yet, use secur...@qt-project.org. When the people on that list think the world should know about the issue, they'll let development@qt-project.org know. If you don't like that other people choose to let the Qt project know of a security issue without informing you at the same time... you'll have to take that up with those people because they would use security-private@ over security@ if those were the names we had. -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On 24/10/12 04:33, Thiago Macieira wrote: I think we are keeping it simple. The current proposal is the simplest that still works. If you can come up with something even simpler, I'll gladly accept it. If the option is required in one platform and does not cause anything but a minor inconvenience on others, why not document it? So then will Qmake on Windows/Mac complain about the -qt5 argument? Or simply drop it? Drop it. I know I complained about renaming qmake but... it would be simpler to rename qmake to qmake5 than to have a 'special' qmake that may or may not be the qmake that's first in your PATH and that may or may not do something with a -qtx switch. So I'm going to remove my +1 for the 'special' qmake and instead suggest a much simpler solution. This is just for 'qmake' though, everything else... same as it was before. Solution: qmake renamed to qmake5 and lives with the other binaries in libexec/bin Create /usr/bin/qmake5 as a symlink to libexec/bin/qmake5 for Linux distro builds - triggered by some set of configure flags, NOT default behaviour for a source build Optional: Create libexec/bin/qmake as a symlink to qmake5 (for Windows... a .bat or .cmd may work, else a copy). The officially supported way to build thus becomes qmake5 and it is guaranteed to work no matter what platform you're on or how you've set your PATH. Yes, we have to update all the documentation. The optional symlink is for complainers like me, so we can continue to run qmake - but only if we set PATH correctly first. It'll also help with old instructions, scripts, etc. that would break if we just renamed qmake ;) -- Link ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Change Qt's Security Policy to Full Disclosure
On 10/23/12, Lincoln Ramsay a1291...@gmail.com wrote: We're not renaming things or creating new lists just to match the names you think we should have. *sigh*, I had a feeling someone would say something like that. The changes are trivial at a glance, yes ...but what the Qt Project officially endorses/recommends is the real change here. Right now, the Qt Project instructs analysts use security-through-obscurity when reporting vulnerabilities. If you find [...] a security issue, contact us at security at qt-project.org so we can deal with it ( http://lists.qt-project.org/pipermail/development/2012-October/006893.html ). You could change that /security/index.html suggestion to recommend the development list for public and keep security@ for the private list, that makes no difference. Semantics. As an aside, I think it would be better for security to go in it's own list... but that's just an organizational decision. List names are not very important at all, whereas the policy on where to report vulns is extremely important. d3fault ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On terça-feira, 23 de outubro de 2012 21.40.41, Oswald Buddenhagen wrote: The difference is that xmlpatterns, like qdbus and the other applications, can be updated by the Debian alternatives mechanism. yes, debian. have you checked that this is true for all relevant downstreams? The Debian alternatives mechanism gets that name because it came from Debian, not because it exists on Debian only. On OpenSUSE, it comes in a package called update-alternatives. On Fedora, for some reason, it's munged up with chkconfig, but it still exists. I remember it existed on Mandriva too when I used it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New proposal for the tool naming
On terça-feira, 23 de outubro de 2012 23.12.58, André Pönitz wrote: Moreover, it is a reasonable assumption that only few Qt based Windows-only projects supporting VS use qmake at all, and that most non-trivial cross-platform Qt based projects supporting VS maintain a real .vcproj in parallel to a .pro instead of re-creating it using qmake. Lars made that argument too when I talked to him. The two problems I see with that are: 1) every time you add a new header or source containing QObject class, you need to modify your non-qmake build settings to moc that file. My (biased) experience from the #qt channel and mailing lists is that people switch back to using qmake to generate the .vcproj after hitting this problem once or twice. I say biased because it's clearly so: people who know how to solve the problem don't come asking for help. The VSAddin case notwithstanding because I'm hoping that we can update it to find the proper moc in $QTDIR/lib/qt5/libexec instead of $QTDIR/bin. 2) we are renaming the libraries anyway. And we already *had* renamed the libraries on Windows when we changed from QtCore4 to QtCore5 (.dll, .lib). Two conclusions come from this: a) we should update VSAddin to know about Qt 5, since it clearly differs b) manual buildsystems will require manual changes anyway, so updating the path to moc is not too much to ask. Also, because of (b), the case of QTDIR=Q:\ that changes over time back and forth from Qt 4 to Qt 5 is not realistic. This case cannot exist for one buildsystem that does know about Qt 5 anyway. Either that's two buildsystems or it's one that knows about Qt 5. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
