Re: [Development] [Releasing] Qt 4.8.1 release during week 11/2012
On 5.3.2012 18.21, Oswald Buddenhagen oswald.buddenha...@nokia.com wrote: On Mon, Mar 05, 2012 at 03:24:04PM +, ext Salovaara Akseli wrote: At the moment we are following content of http://qt.gitorious.org/qt/qt/commits/4.8 branch on our internal repository. We would like to provide Qt 4.8.1 branch on Gitorious\Gerrit in order to enable you more visibility for the progress content. Could Gitorious\Gerrit administrators enable such branch and later tag final 4.8.1 release? i understand that this is the commercial qt release with additional patches not sanctioned by the qt project (yet). i can only repeat my offer from the last time: we create a 4.8.1-digia branch you can push your stuff into and put a v4.8.1-digia tag on. No, this is intended to be the open-source 4.8.1 release by the Qt Project. For us it is fine if someone else does the releases, but since about no-one seems to care making patch release out of 4.8 we have stepped up and offered to create the releases. For Qt Commercial viewpoint it is easier for us to base our releases on patch releases from Qt Project. It gets hard eventually if we would continue releasing commercial only patch releases on top of 4.8.0. And I am sure there are also open-source users who wish to get patch releases for 4.8. Yes, there is already some amount of patches out after the proposed 4.8.1. From our viewpoint they should go into 4.8.2. If needed, of course we can rebase 4.8.1 and redo the testing, but it is already a release with a large number of fixes. It is the decision of the Qt Project what we want to do about releases. I would like to have 4.8.1 released, and Digia is ready to help also with the subsequent releases. If others are also interested in making the releases, great. you still have all rights necessary to push refs/heads/4.7-digia and refs/tags/v4.7.5-digia if you finally decide to actually do so. i suggest you do that and then we see about 4.8. i'm on irc if you have questions about the execution. Regarding 4.7.5 we have created the open-source installers ages ago, but since there is no place for Qt Project to distribute the releases at the moment, they are not out. We wanted that the installers and code for 4.7.5 are released at the same time, but since there did not seem to be interest in the community to do that, we have not been pushing. Source code of 4.7.5 open-source is available at https://qt.gitorious.org/qt/digia-qt/commits/4.7.5 - and we do have the open-source installers ready if those are needed. There just needs to be a location where these can be placed. I can understand the lack of interest for 4.7.5, but 4.8.1 is a different case. It gets really ugly if Qt Project does not make any patch releases out of 4.8. Yours, Tuukka ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] cast ... increases required alignment of target type [-Werror=cast-align]
On 03/14/2012 11:32 PM, Rohan McGovern wrote: That is exactly what's done for ARM, it should be fine to do it for MIPS too. http://codereview.qt-project.org/20033 does this. thanks rohan! PS: I have not tried building Qt for SH4 but I assume we run into similar issues there. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Kurt Korbatits for approver
On 03/15/2012 05:59 AM, ext jason.mcdon...@nokia.com wrote: All, I'd like to nominate Kurt Korbatits for approver status. Kurt worked on Qtopia, Qt and Qt Mobility from 2005 to 2010 and rejoined Nokia's Brisbane team in late 2011. Since then he has been working on improving the state of Qt's autotests with a particular focus on getting the tests working for embedded and shadow builds and has achieved significant improvements in test results for these. Kurt's past experience with Qt also gives him specialized knowledge of multimedia, performance and building embedded systems using Qt. Cheers, -- Jason Seconded ! Lots of fixes/contributions in both qtbase and qtdeclarative. -- Sergio Ahumada ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Breaking up QtPlatformSupport
On Wed, Mar 14, 2012 at 11:07:56AM +1000, ext Lincoln Ramsay wrote: On 03/12/2012 11:56 PM, ext Thiago Macieira wrote: qmake does not add a dependency on the .a file, so the other target doesn't get relinked. Qtopia had a large number of .a files and this hit us hard so we devised a workaround. i find this all quite academical. qmake is known to have utterly broken dependencies, and creating specific workarounds only creates a false feeling of safety. the universal workaround is configuring ccache and cleaning every time. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] need to handle touch events rather than depending on mouse event synthesis
On 03/15/2012 04:15 AM, Jones Martin (Nokia-MP/Brisbane) wrote: Sure, if you don't touch the flag you don't break anything, but as soon as someone uses the flag somewhere in a hierarchy of interactive Items you're going to have problems. It's too late for 5.0. We are already having problems, since this event propagation is broken. Currently, we are having to create our own SingleTouchArea to avoid touchs being propagated to underneath MultiPointTouchAreas, because even though the MouseArea 'handles' touch events, through synthesized mouse events, it will not prevent the original touch event passing through it. The z-order matters here and on touch devices this behavior is not acceptable. If we don't fix this know, it will bring much more problems in the future. If someone change this flag, he knows exactly what he is doing and should know the outcome. Br, Adriano ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] need to handle touch events rather than depending on mouse event synthesis
Torsdag 1. mars 2012 19.48.15 skrev ext Alan Alpert:
Perhaps we could just add an enum to MouseArea? EventType { MouseEvents,
TouchEvents, MouseAndTouchEvents (default) }. That allow you more
fine-grained control, with identical default behavior that doesn't require
event synthesis that messes with other elements. Not to mention that the
common case is you don't care what pointy thing they used to say 'do
that',
there are devices with both mouse and touch and often the app really
doesn't care which it was.
I agree. I think this is the best solution given the deadline.
It will not break any apps and we can get rid of this event synthesis for
good. Is there anybody already working on this fix?
Br,
Adriano
Yes, so far I just got the MouseArea to handle the touch events. Now I need
to disable all the other places where synthesis is done, and do lots of
testing. And then I can see about that enum property.
--
MVH, Shawn Rutledge ❖ ecloud on IRC
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On Monday 12 March 2012 20:06:22 marius.storm-ol...@nokia.com wrote: a) The parser is too trivial and doesn't handle the normal levels of complexity of command line arguments out there. (tar, find, zip, and standard Qt (built-in) arguments anyone?) Who needs to reimplement tar, zip, or find in Qt? These programs have a weird notion of command-line argument handling, but I don't see the need for Qt to provide this. If it had something much more standard, it would already be useful for 99%, no, 100%, of the Qt applications out there. b) The parser is too complex, where it doesn't live up to the simplicity expected from Qt API and usage. It's not such an insurmountable task. After all, libc has getopt, Qt has many complex things, surely Qt can implement some sort of getopt without resulting in too complex code. c) The parser only focuses on the standard for a single platform. (Linux users will not go for Windows style /? options, and Windows users won't accept --help Linux options, etc) Right, that one is true of KDE's KCmdLineArgs (which I want to see disappear due to bad API and not great implementation). It knows -s and --long. But surely supporting /s on Windows where -s would work on Linux is trivial. The problems with writing a parser like this is to make it general enough to support most of the Qt users, to justify it being part of the core set of modules. If it doesn't, it probably shouldn't be in QtBase, and as such should be a separate Addon, IMO. I don't agree. We've had something in KDE for 10 years, and not general enough (for any app-specific needs) has not really been an issue. The issue is the API (static array full of QT_TR_NOOP equivalents) and the implementation (much more C than C++). Anyways, something to keep in mind when working on your implementation. It's a can of worms with a lot of bikeshedding ;) Yes, this has been said a few times already. However I don't think this is enough of an argument for not doing anything about this in Qt (I know for a fact that your email discouraged Laszlo of even trying). If the message, upfront, is you won't be able to get this into Qt, then a natural reaction is to just say OK, then I give up, we'll do something KDE- specific instead. But this goes against my main goal of removing the distinction between a KDE app and a Qt app as much as possible. I see no reason why command-line argument parsing can't be provided by Qt. It's not as complex as you say, all kde apps do fine with the features listed at http://api.kde.org/4.x-api/kdelibs- apidocs/kdecore/html/classKCmdLineOptions.html#ac3064e6ec33f92a4a6d17eb8ff766034 You're right, tar couldn't use this. But then again, tar is not a Qt application, and will probably never be. And for a new program, there's always the option of *choosing* a set of command-line options that is actually doable with the existing Qt class, rather than going for something as funky as tar xvf. Look at GNU getopt: same issue, it can't be used by tar. So what? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Sponsored by Nokia to work on KDE, incl. KDE Frameworks 5 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
Any simple standard cli args parser included with Qt would be overwhelmingly better than none at all even if it's just -s shortops (/s for win) and worry about --longopts and tar-like variations for Qt6+. The simpler the better as long as it's universally available in qtcore, if possible, sooner than later. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] cast ... increases required alignment of target type [-Werror=cast-align]
Thiago: -Werror should never be enabled on non-developer builds. Why not? Is the plan to ship code that contains warnings?* This is the sort of thing that destroyed Symbian. When I last counted, the Symbian build routinely produced more than 7,000 warnings. No one at Nokia besides myself seemed to have any concern about this nor any real idea what any of those warnings represented. And when I started tracking them down, I was able to prove that at least a few of those warnings (30 or so, IIRC) were genuine coding failures and at least a handful of those were the root cause of bugs that were *ALREADY* in the bug tracking system. Think of that: If some software engineer had only taken the time to fix that (e.g.) Variable used before being initialized warning, some set of users in the field wouldn't be having their Symbian phones routinely crashing! But amid 7,000+ warnings, what's one more, ehh? ;-) All code should build warning free, at least until the customer introduces changes. And then, the fact that the warning count went from *0* to n will probably tip the user off that they just did something wrong, whereas a change from 7,397 to 7,398 will probably go unnoticed, just like it always did at Nokia. Atlant * Yes, I understand that in a configurable build, eliminating all warnings from all configurations is hard work. But that's why we get paid the big bucks/Euros/Kroner/etc. -Original Message- From: development-bounces+aschmidt=dekaresearch@qt-project.org [mailto:development-bounces+aschmidt=dekaresearch@qt-project.org] On Behalf Of Thiago Macieira Sent: Wednesday, March 14, 2012 18:15 To: development@qt-project.org Subject: Re: [Development] cast ... increases required alignment of target type [-Werror=cast-align] On quarta-feira, 14 de março de 2012 21.37.23, lars.kn...@nokia.com wrote: Possible options: a.) fix the underlying warning (probably very tough for alpha one) b.) remove -Wcast-align from the headersclean.pri for the alpha one? c.) don't mind that qtbase does not compile for MIPS in the alpha d.) ??? I'd go for (b), but if possible only for MIPS. Note that most users do not build the tests. So the build will not stop for them. -Werror should never be enabled on non-developer builds. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
-Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of ext Hugo Parente Lima Sent: Thursday, March 15, 2012 12:16 PM To: development@qt-project.org Cc: Mark Constable Subject: Re: [Development] Qt Playground - Command Line Parser experiment On Thursday 15 March 2012 07:29:23 Mark Constable wrote: Any simple standard cli args parser included with Qt would be overwhelmingly better than none at all even if it's just -s shortops (/s for win) and worry about --longopts and tar-like variations for Qt6+. The simpler the better as long as it's universally available in qtcore, if possible, sooner than later. Hmmm... ok, let's go again... should I elaborate this: https://github.com/hugopl/qcmdlineparser (g...@github.com:hugopl/qcmdlineparser.git) or just git push origin :master and forget about? Some usage examples can be found on the small unit test: https://github.com/hugopl/qcmdlineparser/blob/master/qcmdlineparsertes t.cpp I only checked the tests file, but it seems like you're going for the GNU style where options following '-' are always one character letters.The Qt tools itself do not follow this style, e.g. qmake -project, not qmake --project, or qmake -p :) To use the parser also internally , it should IMO also support a style where '-help' is one valid argument. Just my 2 cents Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] cast ... increases required alignment of target type [-Werror=cast-align]
On Thu, Mar 15, 2012 at 12:20 PM, Atlant Schmidt aschm...@dekaresearch.com wrote: Thiago: -Werror should never be enabled on non-developer builds. Why not? Is the plan to ship code that contains warnings?* Because those non-developers aren't developing Qt, and may not have the capability to fix warnings, if they arise. They just want to build Qt and use it. Developer builds are another matter entirely, and I don't think anyone would honestly be against an attempt to enable -Werror, though it's a big job. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] cast ... increases required alignment of target type [-Werror=cast-align]
Robin: Because those non-developers aren't developing Qt, and may not have the capability to fix warnings, if they arise. They just want to build Qt and use it. So you don't want their bug reports when their particular configuration (that the Qt developers may not have tested) doesn't work without producing warnings? Atlant -Original Message- From: ro...@viroteck.net [mailto:ro...@viroteck.net] On Behalf Of Robin Burchell Sent: Thursday, March 15, 2012 07:36 To: Atlant Schmidt Cc: Thiago Macieira; development@qt-project.org Subject: Re: [Development] cast ... increases required alignment of target type [-Werror=cast-align] On Thu, Mar 15, 2012 at 12:20 PM, Atlant Schmidt aschm...@dekaresearch.com wrote: Thiago: -Werror should never be enabled on non-developer builds. Why not? Is the plan to ship code that contains warnings?* Because those non-developers aren't developing Qt, and may not have the capability to fix warnings, if they arise. They just want to build Qt and use it. Developer builds are another matter entirely, and I don't think anyone would honestly be against an attempt to enable -Werror, though it's a big job. Click https://www.mailcontrol.com/sr/lh1Nv5z4bnHTndxI!oX7UsdpzMR7Bo2KKNS9DqhBQIz1lKII56rKFTGW0a7+3ezIdfwN1IpAz7f55a0nEA+RCg== to report this email as spam. This e-mail and the information, including any attachments, it contains are intended to be a confidential communication only to the person or entity to whom it is addressed and may contain information that is privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and destroy the original message. Thank you. Please consider the environment before printing this email. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
I would like an argument parser in Qt, and I'd like it to be in qtbase. The reason for qtbase is so that our own tools and manual tests can use it. Manual tests outside of qtbase are normally GUI based. I think this is something that can go into a minor 5.x release. About windows: Tools that use / for arguments also accept - (except the built in shell commands) The / can be used for both short and long arguments (e.g. nmake /nologo vs nmake /kc vs nmake /k /c) Arguments may be case insensitive The command line is pretty much only used by technical people (buried 3 levels deep in the app menu), who would probably accept unix style args. If we want to support windows style: Use Qt::CaseInsensitive to opt in to case insensitive args Print a qWarning if the arguments could be ambiguous (assuming the API declares the possible arguments up front like perl's GetOpt::Long) Allow opt out from short argument compression (i.e. /xzf would only be considered as a synonym for --xzf and not for -x -z -f if the opt out is applied) -Original Message- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Mark Constable Sent: 15 March 2012 10:29 To: development@qt-project.org Subject: Re: [Development] Qt Playground - Command Line Parser experiment Any simple standard cli args parser included with Qt would be overwhelmingly better than none at all even if it's just -s shortops (/s for win) and worry about --longopts and tar-like variations for Qt6+. The simpler the better as long as it's universally available in qtcore, if possible, sooner than later. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On 15/03/2012 04:53, ext David Faure wrote: On Monday 12 March 2012 20:06:22 marius.storm-ol...@nokia.com wrote: Anyways, something to keep in mind when working on your implementation. It's a can of worms with a lot of bikeshedding ;) Yes, this has been said a few times already. However I don't think this is enough of an argument for not doing anything about this in Qt (I know for a fact that your email discouraged Laszlo of even trying). If the message, upfront, is you won't be able to get this into Qt, then a natural reaction is to just say OK, then I give up, we'll do something KDE- specific instead. But this goes against my main goal of removing the distinction between a KDE app and a Qt app as much as possible. I'm sorry if it discouraged Laszlo from trying to embark on this project. Nowhere in my email did I say that it couldn't or shouldn't be done, nor that it wouldn't be accepted in Qt. My arguments underlined why this task/project is _special_, and why I believe that it would fit better as a separate AddOn repo, than a feature branch to qtbase. I think development and adoption would happen more quickly if the project has its own AddOn. Also, with an AddOn it doesn't matter much what other people say. If you don't want it/agree with it etc, then you simply don't include it. I see no reason why command-line argument parsing can't be provided by Qt. It's not as complex as you say, all kde apps do fine with the features listed at http://api.kde.org/4.x-api/kdelibs- apidocs/kdecore/html/classKCmdLineOptions.html#ac3064e6ec33f92a4a6d17eb8ff766034 I'm not saying that it cannot be provided for Qt. I'm saying there are many opinions on how an argument parser should work, so do it in an Addon first. Then it doesn't matter so much if not everyone agrees. It might be harder if you don't get broad agreement when working on a feature branch of QtBase (say if Lars or Thiago say no), then you cannot merge and the work is in limbo. And nothing says we cannot pull it from the Addon into QtBase at a later point in time. You're right, tar couldn't use this. But then again, tar is not a Qt application, and will probably never be. And for a new program, there's always the option of *choosing* a set of command-line options that is actually doable with the existing Qt class, rather than going for something as funky as tar xvf. Look at GNU getopt: same issue, it can't be used by tar. So what? The applications I mentioned are bastards when it comes to commands/actions/options, and I mentioned them on purpose to facilitate discussion. They don't represent valid use-cases, but rather indicate the extremes. It's a balancing act though, to figure out which features to support, and which ones to ignore to capture the 90% without getting too complex. For example: * Do short options only accept single letter, or can they have more? -E for preprocessing in GCC, /E or /EP with MSVC -reverse for Qt apps * Will 'single dash' long options be allowed? -traditional-cpp in gcc -style=foo for Qt apps * Will short option clustering be allowed? What if short options support more than one letter? * What if the clustering of some short options match another single short option, or a long option if single dash long options are allowed? * Do you allow for turning on/off boolean values with preceeding +/-? MSVC uses trailing '-' to turn off options, like /GR- to turn off RTTI * Do you use space, '=', ':' or nothing as a option/value separator? -ofilename -output filename -output:filename -output=filename There's lots of nuances to evaluate. You could say lets just support getopt, but then you're likely falling into the unix-world-only trap. But I guess, so what? ;) -- .marius PS. To sum up, do it as an addon, not as a feature branch, and _not_ don't do it. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
I only checked the tests file, but it seems like you're going for the GNU style where options following '-' are always one character letters.The Qt tools itself do not follow this style, e.g. qmake -project, not qmake --project, or qmake -p :) To use the parser also internally , it should IMO also support a style where '-help' is one valid argument. That was my worry previously as well. Would it be possible to refactor -foobar to --foobar for Qt5 (not using single dash for long options) ? Otherwise, as far as I see, we lose the short options which is something that the users would like to see. We are beyond the feature freeze, thus it probably needs special acceptance in case yes. If it does not happen, I am unsure whether it can be done before Qt6 that way. Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On Thursday 15 March 2012 08:26:14 kai.koe...@nokia.com wrote: -Original Message- From: development-bounces+kai.koehne=nokia@qt-project.org [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On Behalf Of ext Hugo Parente Lima Sent: Thursday, March 15, 2012 12:16 PM To: development@qt-project.org Cc: Mark Constable Subject: Re: [Development] Qt Playground - Command Line Parser experiment On Thursday 15 March 2012 07:29:23 Mark Constable wrote: Any simple standard cli args parser included with Qt would be overwhelmingly better than none at all even if it's just -s shortops (/s for win) and worry about --longopts and tar-like variations for Qt6+. The simpler the better as long as it's universally available in qtcore, if possible, sooner than later. Hmmm... ok, let's go again... should I elaborate this: https://github.com/hugopl/qcmdlineparser (g...@github.com:hugopl/qcmdlineparser.git) or just git push origin :master and forget about? Some usage examples can be found on the small unit test: https://github.com/hugopl/qcmdlineparser/blob/master/qcmdlineparsertes t.cpp I only checked the tests file, but it seems like you're going for the GNU style where options following '-' are always one character letters.The Qt tools itself do not follow this style, e.g. qmake -project, not qmake --project, or qmake -p :) To use the parser also internally , it should IMO also support a style where '-help' is one valid argument. It already accepts and there are tests for it, the default auto-help adds a --help and -h, but can easily add a -help too. The translation of - into / on Windows isn't done but is easy to do. Just my 2 cents Kai -- Hugo Parente Lima INdT - Instituto Nokia de Tecnologia signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On Thursday 15 March 2012 09:23:27 marius.storm-ol...@nokia.com wrote: On 15/03/2012 04:53, ext David Faure wrote: On Monday 12 March 2012 20:06:22 marius.storm-ol...@nokia.com wrote: Anyways, something to keep in mind when working on your implementation. It's a can of worms with a lot of bikeshedding ;) Yes, this has been said a few times already. However I don't think this is enough of an argument for not doing anything about this in Qt (I know for a fact that your email discouraged Laszlo of even trying). If the message, upfront, is you won't be able to get this into Qt, then a natural reaction is to just say OK, then I give up, we'll do something KDE- specific instead. But this goes against my main goal of removing the distinction between a KDE app and a Qt app as much as possible. I'm sorry if it discouraged Laszlo from trying to embark on this project. Nowhere in my email did I say that it couldn't or shouldn't be done, nor that it wouldn't be accepted in Qt. My arguments underlined why this task/project is _special_, and why I believe that it would fit better as a separate AddOn repo, than a feature branch to qtbase. I think development and adoption would happen more quickly if the project has its own AddOn. Also, with an AddOn it doesn't matter much what other people say. If you don't want it/agree with it etc, then you simply don't include it. I see no reason why command-line argument parsing can't be provided by Qt. It's not as complex as you say, all kde apps do fine with the features listed at http://api.kde.org/4.x-api/kdelibs- apidocs/kdecore/html/classKCmdLineOptions.html#ac3064e6ec33f92a4a6d17eb8f f766034 I'm not saying that it cannot be provided for Qt. I'm saying there are many opinions on how an argument parser should work, so do it in an Addon first. Then it doesn't matter so much if not everyone agrees. It might be harder if you don't get broad agreement when working on a feature branch of QtBase (say if Lars or Thiago say no), then you cannot merge and the work is in limbo. And nothing says we cannot pull it from the Addon into QtBase at a later point in time. You're right, tar couldn't use this. But then again, tar is not a Qt application, and will probably never be. And for a new program, there's always the option of *choosing* a set of command-line options that is actually doable with the existing Qt class, rather than going for something as funky as tar xvf. Look at GNU getopt: same issue, it can't be used by tar. So what? The applications I mentioned are bastards when it comes to commands/actions/options, and I mentioned them on purpose to facilitate discussion. They don't represent valid use-cases, but rather indicate the extremes. It's a balancing act though, to figure out which features to support, and which ones to ignore to capture the 90% without getting too complex. Answering according to what I implemented 2 months ago and is on github: For example: * Do short options only accept single letter, or can they have more? -E for preprocessing in GCC, /E or /EP with MSVC -reverse for Qt apps You must have a clear definition of what is a short option then, if you mean options that doesn't require a value, ok, it's supported. sorry if I didn't get what you meant. * Will 'single dash' long options be allowed? -traditional-cpp in gcc -style=foo for Qt apps Yes, it is. * Will short option clustering be allowed? What if short options support more than one letter? Option clustering is allowed. If the short option has more than one letter it isn't short. * What if the clustering of some short options match another single short option, or a long option if single dash long options are allowed? IMHO it's a programmer failure to support: -a, -b and -ab IIRC in my implementation the class tell the user used all options. * Do you allow for turning on/off boolean values with preceeding +/-? MSVC uses trailing '-' to turn off options, like /GR- to turn off RTTI Isn't implemented, but it easy to do, anyway I don't know other application besides cl.exe that users this pattern. * Do you use space, '=', ':' or nothing as a option/value separator? -ofilename -output filename -output:filename -output=filename The current implementation accepts space or = as separator, add support for other separators should not be a hard task. There's lots of nuances to evaluate. You could say lets just support getopt, but then you're likely falling into the unix-world-only trap. But I guess, so what? ;) Yes, there are, IMO we just need good defaults and some flexibility without complicating the API for ultra-corner cases. -- Hugo Parente Lima INdT - Instituto Nokia de Tecnologia signature.asc Description: This is a digitally signed message part. ___ Development mailing list
Re: [Development] Qt Playground - Command Line Parser experiment
On Thu, Mar 15, 2012 at 12:23:27PM +, Marius Storm-Olsen wrote: I'm not saying that it cannot be provided for Qt. I'm saying there are many opinions on how an argument parser should work, so do it in an Addon first. Then it doesn't matter so much if not everyone agrees. It might be harder if you don't get broad agreement when working on a feature branch of QtBase (say if Lars or Thiago say no), then you cannot merge and the work is in limbo. And nothing says we cannot pull it from the Addon into QtBase at a later point in time. i'd consider making it an addon a fallback in case it gets rejected for qtbase, not the default choice to get it started. repo management is virtually non-existent in gerrit, so i'd prefer not to add more noise to the project overview. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [Announce] Qt Creator 2.5.0-beta released
We are happy to announce the Qt Creator 2.5.0 beta release. This is a preview of the new minor version of Qt Creator, including bugs fixes as well as a bunch of new features. Blog post: http://labs.qt.nokia.com/2012/03/15/qt-creator-2-5-beta/ Download page: http://qt-project.org/wiki/Qt_Creator_Releases Thanks a lot for all the contributions and feedback, thanks to all people who made this happen! The Qt Creator Team -- Eike Ziller Principal Software Engineer Nokia, Qt Development Frameworks Nokia gate5 GmbH Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B Umsatzsteueridentifikationsnummer: DE 812 845 193 Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori ___ Announce mailing list annou...@qt-project.org http://lists.qt-project.org/mailman/listinfo/announce ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Undeprecating QPointer
On sexta-feira, 2 de março de 2012 10.27.56, Thiago Macieira wrote: Hello QPointer was ported to a QWeakPointer backend and deprecated early in Qt 5 history. However, QPointer is used throughout our code and, I can expect, in user code too. Replacing it with QWeakPointer is just monkey work, adding .data() everywhere and buying us no better safety (because no one will bother to verify that the pointer could be got at that point). After the port to QWeakPointer, QPointer is no longer slow either. I'd like to suggest we un-deprecate it and bring it back to full status. At the same time, I'd like to suggest we discourage using QWeakPointer for tracking QObjects, instead leaving it to its original purpose of being the weak reference counterpart to QSharedPointer. No one has objected. Can someone remove the deprecation marks in QPointer, please? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
Hey, Upon agreement with QtCore maintainer Thiago, a cli_parser branch has been created for QtBase, with Submit rights for Laszlo and anyone added to his Gerrit group CLI Parser. Yeah, I will put some code in there soon from this KDE Scratch repository: http://quickgit.kde.org/index.php?p=scratch%2Flpapp%2Fcommandlineparser.gita=commith=f76147f9bcaaaefaf25543ab30bf668183a9ecaa Hugo, I skimmed through your code which has similar ideas for the option and parser. That is good. :) It would be nice to join the forces and work together on this as you mentioned previously. I can add you to the group, if that is okay for you ? Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On Thursday 15 March 2012 15:38:39 Laszlo Papp wrote: Hey, Upon agreement with QtCore maintainer Thiago, a cli_parser branch has been created for QtBase, with Submit rights for Laszlo and anyone added to his Gerrit group CLI Parser. Yeah, I will put some code in there soon from this KDE Scratch repository: http://quickgit.kde.org/index.php?p=scratch%2Flpapp%2Fcommandlineparser.git a=commith=f76147f9bcaaaefaf25543ab30bf668183a9ecaa Hugo, I skimmed through your code which has similar ideas for the option and parser. That is good. :) It would be nice to join the forces and work together on this as you mentioned previously. I can add you to the group, if that is okay for you ? Yes, do it, hugopl on gerrit =] Best Regards, Laszlo Papp ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Hugo Parente Lima INdT - Instituto Nokia de Tecnologia signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
On quinta-feira, 15 de março de 2012 15.00.19, Hugo Parente Lima wrote: Also, how about support for multiple values for an option, separated by ','? gcc -Wl,--defsym,__stack_limit=0x7ffe' Probably an ultra-corner case? I believe this is, as you said, a ultra corner case. but it's not too hard to implement, I just don't know if is worth to implement this. We'd probably implement this as either: -Wl=value or -Wvalue And then parse the l as linker flags and then break the commas as different options. -- 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] Undeprecating QPointer
On 3/15/12 8:13 PM, ext Robin Burchell robin...@viroteck.net wrote: 2012/3/15 Thiago Macieira thiago.macie...@intel.com: No one has objected. Can someone remove the deprecation marks in QPointer, please? Pushed to http://codereview.qt-project.org/#change,20203 :-) And staged :) Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Q_GLOBAL_STATIC_WITH_INITIALIZER is harmful: please stop using it!eom
-- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Intel Sweden AB - Registration Number: 556189-6027 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] UiHelpers: status update from the playground
Hi, A few weeks ago we requested a playground repository to do experiments with the non-widgets classes that are now in QtWidgets, but are useful for application development using QtQuick2. More details in this thread: http://lists.qt-project.org/pipermail/development/2012-February/002150.html We have just pushed the first results to the playground repo: The classes moved out of QtWidgets up to now are: - QUndoStack, QUndoCommand, QUndoGroup - QFileSystemModel - QStandardItemModel - QAction This initial set is composed by classes we gathered in discussions that happened in this mailing list. Probably some of them will be considered useless and removed in the future. We did not want to introduce conflicts with the original Qt classes. First we created another namespace, then later we decided to rename the classes itself to avoid conflicts, e.g. when installing header files. The prefix Ui is not definitive, as example of the module name that might change if this project succeed and become an add-on. In the TODO list, there are some code/comment cleanups needed. Also, there is wip about how to make these classes QML friendly. A wiki page was created to organize the information about this playground project: http://qt-project.org/wiki/Qt5UiHelpers Feedback is appreciated Cheers Anselmo -- Anselmo L. S. Melo openBossa / INdT http://www.indt.org signature.asc Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
