Re: [Development] Qt for iOS - iOSStyle
On Mar 11, 2013, at 12:41 PM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: By the way, I don't know if you saw my comments on your Qt for iOS Preview blog post, but... You stated that because there is no HITheme-like API on iOS, that creating QiOSStyle would be not possible. However, we can render any UIView into a buffer using [UIView drawInRect:] which we should utilize to provide as much support for native styling as that allows us to. This is not a replacement for a styling API. What you are proposing is equivalent to creating a native IOS widget behind the scenes and taking screenshots of it. It is a hack and it can only work for a few cases. It barely works for buttons (but not segmented ones or tabs) provided you hard code text margins which could change at any point in the future. It will not give you mouseover/hover states without faking input events. And it completely falls apart when you try to render something slightly complex like a slider, unless you update the position of the native handle and re-grab it on each frame. Jens claimed on the blog that the native look and feel matters less in the mobile world because each app is fullscreen. I agree that it matters less, but I disagree that it matters little enough for us to ignore it. I'd much rather use real iOS-looking controls than simply slap on Fusion. Apple users are commonly noted to be extremely particular about very small UI defects. If we spend the time to go oh, the text alignment in QLineEdit is one pixel too low on OS X, and actually take the time to fix it, iOS should be no different. What I was replying to was your following statement on Mortens blog: Without the ability to draw native controls, developing user interfaces in Qt becomes useless except for games with totally custom UI. Which I simply can not leave uncommented. I _never_ said style does not matter and I certainly never implied that it was something we should ignore. What I did say was It is not as bad as you make it out to be. So... why can't we use [UIView drawInRect:]? Qt 5 uses the same approach with NSScroller on OS X for drawing the Lion/ML scrollbars (10c6f015f45092040c281bb90a65179f598a00b1). Native styling is important wherever you are. Not everything is a fancy web app or fancy QML game with custom graphics. Although I've not tested it extensively, Qt seems to have a completely functional style implementation for Android that look like native controls for the theme my phone uses, and the themes that other phones use, on those phones. We wouldn't want Qt/Android apps to look the same on every device, or like something else. Have you actually seen a real-world QWidget based example compiled android that truly looks and feels native? I am genuinely curious about how far this style will get you and I haven't found anything resembling even a screen shot on Google. Add this to the fact that Android actually has a public styling API and Apple does not. My point is that if we already know that we cannot give it a 100% native interface using QStyle, it is not worth creating a half baked one using lots of time, hacks and resources. Using Fusion style with some transient scroll bar and retina fixes will make it nearly trivial to port existing QWidget apps and layouts to IOS with a minimum of effort. The developers that do not want to invest time into making a proper touch based QML interface are not likely to care much about the look of their sliders and even if they do, adding a few IOS-style buttons into the mix is not going to make that desktop app suddenly look native. I find it more likely that it will enter the infamous uncanny valley and generate pointless bug reports against their apps. For Qt Quick, the situation is different. You can already make your app look as native on IOS as you want to. Just download one of the many photoshop UI kits and ship your app with those pixmaps. That is what a large part of the IOS developers are already doing and one of the reasons Apple is so conservative about changing it's look and feel. Apple has not cared about their apps looking native for a long time. Have you seen their Newsstand, Calendar, Notes,, Clock, Photo Booth, Reminders, Game Center and Calendar Apps? If you haven't I suggest you look them up. There is hardly a single native control to spot anywhere. Many of the best known apps on IOS actually try hard to look _different_ in order to differentiate themselves from the 500 million apps already out there. Native look and feel is _not_ a silver bullet that makes an IOS app a success on the store. It might not even be beneficial if the alternative looks better. While I hope we would be able to ship a style for Qt Quick Controls that look like IOS, I am intrigued by the idea of creating a good looking cross platform design language for mobile Qt apps that look good on more than one platform and doesn't
[Development] CI was not working properly from last Thursday until yesterday 11.3.
Hi We had problems with Linuces and perhaps Macs since last Thursday up until yesterday (11.mar) noon. Puppet runs got stuck and took up all of the free CPU power. Puppet was fixed, but the situation got fixed only after each server re-ran Puppet AND rebooted so that the Puppet's that were stuck got killed. Now, if your build happened to run on such a server, it's possible that timeouts in test cases occurred, since Puppet pulled all the resources of the server. The problem has been fixed and I recommend running a re-run now on odd builds from that problematic period. Regards, -Tony Tony Sarajärvi Senior Software Designer Digia, Qt Digia Plc Elektroniikkatie 10 FI-90590 Oulu Email: tony.saraja...@digia.commailto:tony.saraja...@digia.com Mobile: +358 050 482 1416 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qtcommercialhttp://www.facebook.com/qtcommercial Qt Twitter: www.twitter.com/qtcommercialhttp://www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. -- ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] White space / coding style patches welcome?
On Tue, Mar 12, 2013 at 04:35:59AM +0100, Axel Waggershauser wrote:
So to fix whitespace (according to
http://qt-project.org/wiki/Qt_Coding_Style) one has to come up with
whitespace-only patches. I have a couple of questions regarding those:
1. Is something like the above patch welcome at all?
the recent consensus seems to be: yes.
2. Who would be interested/responsible for reviewing such boring patches?
me, when i'm bored.
3. How to best split up patches from that category? e.g. fixing all
if(...){ - if (...) { occurrences in qtbase would be a rather
large patch (I have it half done)
a) split that up based on manageable subdirectories?
yes, and that only for easy recovery from merge conflicts (which you
will get quite some of in highly active areas). other than that, make it
one huge whitespace cleanup change: remove trailing whitespace, expand
tabs (which for fun have inconsistent expectations regarding their
size), fix indentation, fix mixplaced line breaks (the brace re-wrapping
falls into this category), add missing spaces, etc.
somebody attempted this just a few days ago, but gave up when the scope
of the undertaking became clear. i can't find the change now ...
b) only do it in files where it is used inconsistently / where the
wrong occurrences are the minority?
no, do it consistently - to have a good example everywhere, and no
excuses for messing up. then we can make the automatic checking
stricter, too (which lars said was a precondition for even bothering
with a cleanup to start with).
4. Given that such whitespace-only patches don't change the semantic
of the code, is pushing to stable the correct approach? (I read that
one is supposed to pick the 'most stable branch that is still
applicable' because 'up-merging' is easy but backporting is evil.)
do it for dev. it's going to be merged into stable RSN anyway. if you
don't make the deadline, you can still re-target for stable (it would be
stupid not to do that, as then forward-merging would become hell).
have fun ^^
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
On Tue, Mar 12, 2013 at 07:56:33AM +, Bache-Wiig Jens wrote: On Mar 11, 2013, at 12:41 PM, Jake Thomas Petroules jake.petrou...@petroules.com wrote: By the way, I don't know if you saw my comments on your Qt for iOS Preview blog post, but... You stated that because there is no HITheme-like API on iOS, that creating QiOSStyle would be not possible. However, we can render any UIView into a buffer using [UIView drawInRect:] which we should utilize to provide as much support for native styling as that allows us to. This is not a replacement for a styling API. What you are proposing is equivalent to creating a native IOS widget behind the scenes and taking screenshots of it. It is a hack and it can only work for a few cases. It barely works for buttons (but not segmented ones or tabs) provided you hard code text margins which could change at any point in the future. It will not give you mouseover/hover states without faking input events. And it completely falls apart when you try to render something slightly complex like a slider, unless you update the position of the native handle and re-grab it on each frame. I must disagree on this one. If you consider installing event handlers within the style, and and frame-by-frame updating hacks, then yes, it is a hack. But that's what we have for now, unfortunately. Jens claimed on the blog that the native look and feel matters less in the mobile world because each app is fullscreen. I agree that it matters less, but I disagree that it matters little enough for us to ignore it. I'd much rather use real iOS-looking controls than simply slap on Fusion. Apple users are commonly noted to be extremely particular about very small UI defects. If we spend the time to go oh, the text alignment in QLineEdit is one pixel too low on OS X, and actually take the time to fix it, iOS should be no different. What I was replying to was your following statement on Mortens blog: Without the ability to draw native controls, developing user interfaces in Qt becomes useless except for games with totally custom UI. Which I simply can not leave uncommented. I _never_ said style does not matter and I certainly never implied that it was something we should ignore. What I did say was It is not as bad as you make it out to be. So... why can't we use [UIView drawInRect:]? Qt 5 uses the same approach with NSScroller on OS X for drawing the Lion/ML scrollbars (10c6f015f45092040c281bb90a65179f598a00b1). Native styling is important wherever you are. Not everything is a fancy web app or fancy QML game with custom graphics. Although I've not tested it extensively, Qt seems to have a completely functional style implementation for Android that look like native controls for the theme my phone uses, and the themes that other phones use, on those phones. We wouldn't want Qt/Android apps to look the same on every device, or like something else. Have you actually seen a real-world QWidget based example compiled android that truly looks and feels native? I am genuinely curious about how far this style will get you and I haven't found anything resembling even a screen shot on Google. Add this to the fact that Android actually has a public styling API and Apple does not. My point is that if we already know that we cannot give it a 100% native interface using QStyle, it is not worth creating a half baked one using lots of time, hacks and resources. Using Fusion style with some transient scroll bar and retina fixes will make it nearly trivial to port existing QWidget apps and layouts to IOS with a minimum of effort. The developers that do not want to invest time into making a proper touch based QML interface are not likely to care much about the look of their sliders and even if they do, adding a few IOS-style buttons into the mix is not going to make that desktop app suddenly look native. I find it more likely that it will enter the infamous uncanny valley and generate pointless bug reports against their apps. Do we already know we cannot give it a 100% native look? I don't, and while I am not saying we can, I would believe it is possible. Another option is using a pixmap based style, or a mix of both. Well in the end, it will be a pixmap based style anyway, except that if necessary, instead of rendering stuff on the fly, we could use pre-loaded pixmaps together whenever it makes sense. For Qt Quick, the situation is different. You can already make your app look as native on IOS as you want to. Just download one of the many photoshop UI kits and ship your app with those pixmaps. That is what a large part of the IOS developers are already doing and one of the reasons Apple is so conservative about changing it's look and feel. Apple has not cared about their apps looking native for a long time. Have you seen their Newsstand, Calendar, Notes,,
Re: [Development] Qt for iOS - iOSStyle
I agree 100% with Jens. That is all. tor arne On 3/12/13 8:56 , Bache-Wiig Jens wrote: [snip] ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] White space / coding style patches welcome?
3. How to best split up patches from that category? e.g. fixing all
if(...){ - if (...) { occurrences in qtbase would be a rather
large patch (I have it half done)
a) split that up based on manageable subdirectories?
yes, and that only for easy recovery from merge conflicts (which you
will get quite some of in highly active areas). other than that, make it
one huge whitespace cleanup change: remove trailing whitespace, expand
tabs (which for fun have inconsistent expectations regarding their
size), fix indentation, fix mixplaced line breaks (the brace re-wrapping
falls into this category), add missing spaces, etc.
I thought fixing everything at once everywhere is obviously a bad idea:
* merge conflicts until the end of time
* too much burden to come up with and also to review the patch
Especially the combination is problematic: a huge patch will only be
looked at when someone is 'really bored', because it takes such an
effort, the longer the patch lays around, the more likely a merge
conflict.
Hence, splitting it up is inevitable. I thought of two split up strategies:
a) split up by the 'type' of style problem (like the above mentioned change)
b) split up by file/directory and try to fix every 'type' at once
I thought splitting by type first and potentially by directory second
if it is too big still, would be best because it reduces the burden on
the reviewer: only one type of change should be easier to skim over
and might actually be checked by some ad-hock script if that was
necessary. Or does the automatic check for white-space only changes
make it secure enough so it can basically be waved through without
having to look at each hunk?
somebody attempted this just a few days ago, but gave up when the scope
of the undertaking became clear. i can't find the change now ...
I don't think the requirement to only accept a patch if it fixes
'every' whitespace problem in one go would be reasonable as it would
result in exactly this situation: too much work to do/review it all at
once so one gives up.
Therefore I propose to accept fixes, even if they don't fix every
issue (either in type of file space) at once: better improve something
step by step, than nothing at all.
b) only do it in files where it is used inconsistently / where the
wrong occurrences are the minority?
no, do it consistently - to have a good example everywhere, and no
excuses for messing up. then we can make the automatic checking
stricter, too (which lars said was a precondition for even bothering
with a cleanup to start with).
As a final goal, it should obviously be consistent everywhere but I
thought it makes sense to make a difference between files where there
are some random style issues here and there (most of the code) and
files that are written pretty consistently but according to a
different style guide (like the qmake generator stuff). The latter
might probably be best fixed in an 'all types at once but on a
file/directory basis' approach, so each patch would increase the
'local' consistency and be an improvement even if I or someone else
would loose interest at some point in their white space cleaning
spree.
To summarize my suggestion:
* accept partly style fixes (in either type or file space)
* accept them on an a timely manner to make it feasible at all with
regards to merge conflicts
* intentionally ignore stuff in src/3rdparty
I might even be interested in looking into the automatic style check
issue, but can't promise anything.
have fun ^^
Thanks ;) Depending on your feedback, I'll give it a try. ;)
- Axel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] RecordingSupport feature for QMediaPlayer
Hi, there is any way to add recording support to QMediaPlayer?, I was reading
the code of qmediaplayer.cpp from Qt5 sources and realize that there's not
support:
QMediaServiceProvider *provider =
QMediaServiceProvider::defaultServiceProvider();
if (flags) {
QMediaServiceProviderHint::Features features = 0;
if (flags QMediaPlayer::LowLatency)
features |= QMediaServiceProviderHint::LowLatencyPlayback;
if (flags QMediaPlayer::StreamPlayback)
features |= QMediaServiceProviderHint::StreamPlayback;
if (flags QMediaPlayer::VideoSurface)
features |= QMediaServiceProviderHint::VideoSurface;
return provider-requestService(Q_MEDIASERVICE_MEDIAPLAYER,
QMediaServiceProviderHint(features));
} else
return provider-requestService(Q_MEDIASERVICE_MEDIAPLAYER);
it would be interesting if we could record a media loaded by a QMediaPlayer
like QCamera does, allowing to transcode a loca video, saving a streaming and
so forth.___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] White space / coding style patches welcome?
Axel sayeth: snip, whitespace-only changes for consistency to coding standard +1 YAY, Axel! This is a personal wish by me -- consistency. Including for whitespace. I find it astounding the legacy-code-bases that essentially decide that they cannot be improved -- no such patches are welcome -- because it would require work, add merge conflicts, etc. While those are real issues, the result suggests the project *must* go stale, and become increasingly annoying/inconsistent. I work in such systems. And, that makes me sad. Oswald respondeth: snip, patch welcome, should be consistent, probably should be done periodically, and for incremental parts of the code base as they can be addressed Seems like a sensible response. Axel: snip, To summarize my suggestion: * accept partly style fixes (in either type or file space) * accept them on an a timely manner to make it feasible at all with regards to merge conflicts * intentionally ignore stuff in src/3rdparty I might even be interested in looking into the automatic style check issue, but can't promise anything. Sounds good. Long-term, the automatic-style-check thing (e.g., scripts to reformat upon check-in) would be ideal, but I realize that can be tricky. It makes sense that we would eventually get the whitespace-formatting into the tool-chain workflow, though. I like where the CI-system and review-process is going, and it seems like this is merely an extension of that. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Touch not working with QtQuick1 (event handling issue in QGraphicsView)
On Mar 11, 2013, at 2:44 PM, Frank Osterfeld frank.osterf...@kdab.com wrote: Hi, I see two ways to fix it, one is a one-liner, one's more work: * Don't silently accept touch events if no item is waiting for them. Ignoring the events triggers the touch-mouse fallback. That's the approach the attached patch takes and seems to work fine (tested with the QQ1 hello world example). * Make QQ1 items accept touch events and do the touch to mouse mapping internally Do you see issues with the first approach? I don't see why TouchMove and TouchEnd should be accepted if not handled, but TouchBegin is ignored if not handled. Hi, see https://codereview.qt-project.org/#change,48865 for further discussion. I think the simple approach makes sense, as long as we keep it in mind for if/when we get gestures working again. We can then revisit it and implement a different solution if needed. I've also had problems getting TouchBegin translated in the Qt Quick iOS demo we have. Is everything working flawlessly for you with the patch? Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] White space / coding style patches welcome?
On Tue, Mar 12, 2013 at 01:34:54PM +0100, Axel Waggershauser wrote: I thought splitting by type first and potentially by directory second if it is too big still, would be best because it reduces the burden on the reviewer: only one type of change should be easier to skim over the downside of doing it by type is producing a lot of history noise - commits you need to skip over when you are researching history. if the burden on the reviewer is too big, then you didn't split it up according to directories/modules sufficiently well. i did this exercise a few years ago already (just to have it discarded), and the outcome wasn't *that* huge (though there were some problem areas, like qtmultimedia and qt3support). somebody attempted this just a few days ago, but gave up when the scope of the undertaking became clear. i can't find the change now ... I don't think the requirement to only accept a patch if it fixes 'every' whitespace problem in one go would be reasonable as it would result in exactly this situation: too much work to do/review it all at once so one gives up. ok, let's modify the requirement: you don't need to set out to fix every problem. but in the lines you touch because of fixing specific problems, i want to see the remaining issues fixed as well. specifically, i want trailing whitespace and tabs/indentation fixed. the issue you started with is kinda optional for me. spaces around binary operators are kinda secondary, too. i don't even know how big the problem is. b) only do it in files where it is used inconsistently / where the wrong occurrences are the minority? no, do it consistently - to have a good example everywhere, and no excuses for messing up. then we can make the automatic checking stricter, too (which lars said was a precondition for even bothering with a cleanup to start with). As a final goal, it should obviously be consistent everywhere but I thought it makes sense to make a difference between files where there are some random style issues here and there (most of the code) and files that are written pretty consistently but according to a different style guide (like the qmake generator stuff). there are a few projects which have vastly different style (qlalr) or should be excluded out of principle (anything 3rdparty). i wouldn't make an exception for anything else, including the qmake generators (they are seeing incremental coding style cleanups anyway). if you have specific projects in mind, we can discuss. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [QA] Suggestion -- Bug Reports' Assignment
Hello, I want to express another suggestions for bug management: - A newly opened bug report shouldn't be automatically assigned to anyone. - Logged-in users should be able to assign bug reports to themselves. Assigned = 'someone works or is going to work on the item' Unassigned = 'nobody works on the item' Please feel free to comment on this. If there are no serious objections, this change will be introduced soon. The impact of the change will be evaluated. Best regards, /Rafal Rafal Motyka QE Engineer Digia, Qt Email: rafal.mot...@digia.commailto:forename.surn...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qt Qt Twitter: www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. - ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Copyright changes
On 03/03/2013 01:23 AM, Rohan McGovern wrote: On Sat, Mar 2, 2013 at 3:34 PM, Laszlo Papp lp...@kde.org wrote: I will take you meant QT_MODULE_TO_TEST=qtdeclarative qtqa/tests/prebuild/license/tst_licenses.pl Yeah, I used this script earlier, but I did not know it is already integrated into the CI. Couldn't this be integrated into a bot rather than CI? It would be nice to know even before pressing the staging button. It does not seem to run long either. Sure, there is a long standing task for that, https://bugreports.qt-project.org/browse/QTQAINFRA-309 . It just waits for somebody to do the work. The current sanity bot has all checks implemented in a couple of big loops and is not designed to call out to separate scripts, so this task may include some refactoring of the sanity bot. I did a simple bot based on the doc bot to check the licenses in Gerrit. it was a work in progress .. but it might help if somebody wants to do it properly https://codereview.qt-project.org/35648 Since Oswald wants this integrated with the sanity bot, then maybe the task can be re-opened and assigned to him. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [QA] Suggestion -- Access in JIRA
Hello, After a few discussions, I want to suggest that we could make JIRA more accessible so that every logged-in user should have rights to: - create, - edit, - resolve, - verify, - and re-open bug reports. Please feel free to comment on this. If there are no serious objections, this change will be introduced soon. The impact of the change will be evaluated. Best regards, /Rafal Rafal Motyka QE Engineer Digia, Qt Email: rafal.mot...@digia.commailto:forename.surn...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qt Qt Twitter: www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. - ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] [QA] Suggestion -- Setting Up the Priority in JIRA
Hello, I want to suggest another change for JIRA: - A Reporter should be able to set the Priority starting from the Create Issue window. - Guidelines for setting Priority should be provided (already working today). Please feel free to comment on this. If there are no serious objections, this change will be introduced soon. The impact of the change will be evaluated. Best regards, /Rafal Rafal Motyka QE Engineer Digia, Qt Email: rafal.mot...@digia.commailto:forename.surn...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qt Qt Twitter: www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. - ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QA] Suggestion -- Bug Reports' Assignment
I would expect that the workflow is that if a report is set to be In progress then this is the indication that someone is actually working on the report, if we start using the assigner for this indication then it sounds like it will complicate matters even further. Also, if a P1 is created and it is unassigned, who is responsible for ensuring that gets picked up and processed? Andy From: development-bounces+andy.shaw=digia@qt-project.org [mailto:development-bounces+andy.shaw=digia@qt-project.org] On Behalf Of Motyka Rafal Sent: 12. mars 2013 14:28 To: development@qt-project.org Subject: [Development] [QA] Suggestion -- Bug Reports' Assignment Hello, I want to express another suggestions for bug management: - A newly opened bug report shouldn't be automatically assigned to anyone. - Logged-in users should be able to assign bug reports to themselves. Assigned = 'someone works or is going to work on the item' Unassigned = 'nobody works on the item' Please feel free to comment on this. If there are no serious objections, this change will be introduced soon. The impact of the change will be evaluated. Best regards, /Rafal Rafal Motyka QE Engineer Digia, Qt Email: rafal.mot...@digia.commailto:forename.surn...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qthttp://www.facebook.com/qt Qt Twitter: www.twitter.com/qtcommercialhttp://www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. - ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Nominating Iikka Eklund as approver
On 01/24/2013 08:49 AM, Jenssen Tim wrote: Another big +2 Von: Sergio Ahumada mailto:sergio.ahum...@digia.com Gesendet: 23.01.2013 14:27 An: development@qt-project.org mailto:development@qt-project.org Betreff: [Development] Nominating Iikka Eklund as approver Hi, I would like to nominate Iikka to be an approver in the Qt project. Iikka is one of the key persons responsible for all the releases made by Digia in the past and now together with the Qt Project. This includes both Qt 4.x and Qt 5.x releases in both the commercial and opensource versions. Here's Iikka's gerrit information: https://codereview.qt-project.org/#dashboard,1001454 https://codereview.qt-project.org/#q,owner:iikka.eklund,n,z Would anyone like to second this nomination? Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt It's been more than 15 work days. Congratulations Iikka! -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] White space / coding style patches welcome?
On Tue, Mar 12, 2013 at 2:11 PM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: On Tue, Mar 12, 2013 at 01:34:54PM +0100, Axel Waggershauser wrote: I thought splitting by type first and potentially by directory second if it is too big still, would be best because it reduces the burden on the reviewer: only one type of change should be easier to skim over the downside of doing it by type is producing a lot of history noise - commits you need to skip over when you are researching history. Point taken. if the burden on the reviewer is too big, then you didn't split it up according to directories/modules sufficiently well. What would be a sensible patch-size? Is there some reasonable maximum number of lines/hunks? i did this exercise a few years ago already (just to have it discarded), and the outcome wasn't *that* huge (though there were some problem areas, like qtmultimedia and qt3support). You mean, you prepared clean up patches and they were abandoned or their effect vanished over time due to missing online checks? ok, let's modify the requirement: you don't need to set out to fix every problem. but in the lines you touch because of fixing specific problems, i want to see the remaining issues fixed as well. specifically, i want trailing whitespace and tabs/indentation fixed. the issue you started with is kinda optional for me. Ack. spaces around binary operators are kinda secondary, too. i don't even know how big the problem is. Well, it was totally random but I liked that it was kind of a minor issue resulting in a still smallish patch, perfect for a test balloon. And that patch actually fixes all switch statements in qtbase. Two thoughts/directions regarding support for automatic (sanity-check like) tests: 1) 'simple' line-by-line checks running directly on the diff: That should be rather easy to add as a more or less ad-hock string-procssing check that looks for specific coding style problems on a line-by-line basis in the diff, e.g. detecting classics like for( ... ) or even more obvious tabs and trailing whitespace issues. Something like that could be integrated anytime without having a complete conformant code base. But it will easily reach it's limits like checking a multi-line-statement and not having any clue whatsoever about the context (complaints about random text in comments, maybe macro foo, etc.) It will obviously be able to only address a subset of what is talked about in http://qt-project.org/wiki/Qt_Coding_Style but maybe a substantial portion and that without too much effort. 2) proper c++ parser based checks that require the patch to be applied to the code to even run: I don't know about the gerrit sanity checking infrastructure but can imagine that would require a substantial change and it would also not work without having a fixed source base first. But obviously be able to do proper checks of any valid c++ code (I hereby presume there is some fancy tool in the context of libclang available...). I'd be inclined to look into option 1 rather than 2 as this seems to be more manageable within a decent amount of time. - Axel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Touch not working with QtQuick1 (event handling issue in QGraphicsView)
On Mar 12, 2013, at 2:01 PM, Sorvig Morten wrote: On Mar 11, 2013, at 2:44 PM, Frank Osterfeld frank.osterf...@kdab.com wrote: Hi, I see two ways to fix it, one is a one-liner, one's more work: * Don't silently accept touch events if no item is waiting for them. Ignoring the events triggers the touch-mouse fallback. That's the approach the attached patch takes and seems to work fine (tested with the QQ1 hello world example). * Make QQ1 items accept touch events and do the touch to mouse mapping internally Do you see issues with the first approach? I don't see why TouchMove and TouchEnd should be accepted if not handled, but TouchBegin is ignored if not handled. Hi, see https://codereview.qt-project.org/#change,48865 for further discussion. I think the simple approach makes sense, as long as we keep it in mind for if/when we get gestures working again. We can then revisit it and implement a different solution if needed. I've also had problems getting TouchBegin translated in the Qt Quick iOS demo we have. Is everything working flawlessly for you with the patch? I tested with simple Hello-World style examples containing mouse areas reacting to onClicked. Do you have anything else I should test specifically? -- Frank Osterfeld | frank.osterf...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Copyright changes
On 03/01/2013 10:28 AM, Hirvonen Olli wrote: Hi all, We would appreciate Your help in one quite trivial task. With a joint effort together it also should be reasonable small task for individual developer. Digia acquired all Nokia's Qt copyrights last year. We have already changed the copyrights in main branches. All non-Nokia copyrights remain unchanged. [snip] 3.There are repositories where copyright is right, but LGPL_EXCEPTION.txt is Nokia version. Examples: installer-framework\installer-framework playground\qtserialport qt-labs\messagingframework qt-labs\qtest-qml qt-mobility\qt-mobility can you provide the LGPL_EXCEPTION.txt file as well or can we just use https://qt.gitorious.org/qt/qtbase/blobs/stable/LGPL_EXCEPTION.txt as a template ? what about https://qt.gitorious.org/qt/qtbase/blobs/stable/LICENSE.PREVIEW.COMMERCIAL ? should be change as well or is not needed ? Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Please Help Update Sanity Test Guidelines
On Wednesday, March 06, 2013 09:43:12 Motyka Rafal wrote: Hello, This is a request for help to update/correct the new Sanity Test Guidelines page. Please feel free to change the page: http://qt-project.org/wiki/Sanity-Test-Guidelines It's meant to be used for Qt releases as help for manual sanity testing (broad, not deep). Any help will be highly appreciated. I've added some scripts to run the cmake tests manually too after installing the packages. I haven't yet written one for the mac, so if someone has easy access to a mac to do that, that would be cool. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions 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] ChangeLogs
On 02/06/2013 07:25 PM, Olivier Goffart wrote: On Thursday 31 January 2013 07:50:32 Koehne Kai wrote: -Original Message- From: development-bounces+kai.koehne=digia@qt-project.org [mailto:development-bounces+kai.koehne=digia@qt-project.org] On Behalf Of Matt Williams Sent: Tuesday, January 29, 2013 11:14 AM To: development Subject: Re: [Development] ChangeLogs On 29 January 2013 00:31, Alan Alpert 4163654...@gmail.com wrote: On Mon, Jan 28, 2013 at 4:21 AM, Jason McDonald macadd...@gmail.com wrote: 4. Let's try to make the job of our maintainers that little bit easier by writing good commit summaries and diligently reviewing the commit summaries of our peers. +1, but I think the tool is a more realistic way of making the task easier for the maintainers. Within KDE we use a tool called Enzyme (http://enzyme-project.org/) which allows you to go through all the commits, marking certain ones as interesting in a collaborative way. It might not have _all_ the feature needed but it would probably help along the way. It's open-source so we could always tweak it as needed. I'm all for a tool making things easier for the one writing the actual ChangeLog file. But I think it's somewhat orthogonal to the question whether the original author of a fix should write a ChangeLog line somewhere, too . So, did we come to any conclusion regarding adding a ChangeLog: entry to commits? IMO it's worth a try. I'd say yes, Put a Changelog: entry somewhere with some text that will be processed manually by the release manager to fill the changelog. (The release manager can grep for it, and that will ease his task a lot to have already ready made sentence) [ The ones who are concerned about a bit of reddundancy in the commit message should as well leave the commit empty since it is already redundent with the diff itself :-) ] Hi, Since it doesn't seem to be a final decision/consensus about this, I will just create empty changes files for 5.0.2 and Maintainers will have to fill them up. ps1: any idea about the git merge-driver suggestion and/or the (qml based?) UI tool suggestion ? ps2: I only found https://codereview.qt-project.org/47802 using the ChangeLog entry Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] White space / coding style patches welcome?
On Tue, Mar 12, 2013 at 03:14:43PM +0100, Axel Waggershauser wrote: On Tue, Mar 12, 2013 at 2:11 PM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: if the burden on the reviewer is too big, then you didn't split it up according to directories/modules sufficiently well. What would be a sensible patch-size? Is there some reasonable maximum number of lines/hunks? try to go by subdirectories of src/ and tools/ first. if the result looks utterly unreasonable (more than maybe two thousand lines according to git diffstat), consider further splitting up. and vice-versa if you get some very small diffs. i did this exercise a few years ago already (just to have it discarded), and the outcome wasn't *that* huge (though there were some problem areas, like qtmultimedia and qt3support). You mean, you prepared clean up patches and they were abandoned or their effect vanished over time due to missing online checks? it went to the trash because the idea was not liked back then. the winds appear to have changed meanwhile. 1) 'simple' line-by-line checks running directly on the diff: qt/qtrepotools/git-hooks/sanitize-commit 2) proper c++ parser based checks that require the patch to be applied to the code to even run: this would equate a reliable automatic source reformatter. i've yet to see one. ^^ I don't know about the gerrit sanity checking infrastructure but can imagine that would require a substantial change it would be entirely different from the sanity bot, yes. but we already have the doc bot that does something similar. and it would also not work without having a fixed source base first. the full results could be filtered with the diff lines, so even an unclean baseline would produce very few false positives. But obviously be able to do proper checks of any valid c++ code to reliably parse c++, you need contextual information. that means that you need a complete build system. iow, you need to compile the whole thing, and have the style checking be done as a side effect. (I hereby presume there is some fancy tool in the context of libclang available...). if not: have fun. ^^ ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QA] Suggestion -- Setting Up the Priority in JIRA
On Tue, Mar 12, 2013 at 01:28:37PM +, Motyka Rafal wrote: Hello, I want to suggest another change for JIRA: - A Reporter should be able to set the Priority starting from the Create Issue window. i don't think so. seriously, everyone thinks that their issue is the most important one. consequently, only the assignee and authorized users (at least members of a yet-to-be-determined triagers group) should be able to set the priority. of course this can be circumvented if everyone is able to assign a bug to himself, but it's still a mental barrier. on a related note, the jira setup should gain fields that support a User Pain based priorization process. (idea extensively discussed internally a few years ago). we might want to be more lenient about the permissions of these fields. - Guidelines for setting Priority should be provided (already working today). Please feel free to comment on this. If there are no serious objections, this change will be introduced soon. The impact of the change will be evaluated. Best regards, /Rafal Rafal Motyka QE Engineer Digia, Qt Email: rafal.mot...@digia.commailto:forename.surn...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qt Qt Twitter: www.twitter.com/qtcommercial -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. - ___ 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] [QA] Suggestion -- Setting Up the Priority in JIRA
On terça-feira, 12 de março de 2013 13.28.37, Motyka Rafal wrote: Hello, I want to suggest another change for JIRA: - A Reporter should be able to set the Priority starting from the Create Issue window. - Guidelines for setting Priority should be provided (already working today). Please feel free to comment on this. If there are no serious objections, this change will be introduced soon. The impact of the change will be evaluated. I disagree. The priority should be set by the triager, the person who can make a dispassionate, objective assessment of the bug's priority. The bug reporter is way too involved to make that assessment. -- 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] [QA] Suggestion -- Bug Reports' Assignment
On terça-feira, 12 de março de 2013 13.41.33, Shaw Andy wrote: I would expect that the workflow is that if a report is set to be In progress then this is the indication that someone is actually working on the report, if we start using the assigner for this indication then it sounds like it will complicate matters even further. Also, if a P1 is created and it is unassigned, who is responsible for ensuring that gets picked up and processed? Assigned means that someone is responsible for the bug. In progress means that someone is working on the bug. A bug might be assigned for other reasons than fixing it, like triaging, writing a testcase, etc. To be honest, I don't care if a bug is auto-assigned upon creation or not. All bugs need to be triaged, so whichever workflow we decide on must support that. Right now, as maintainer for QtCore, I either triage myself the bugs I receive (including the ones I have watches upon) or I assign to someone to give me input. And we need to do it consistently: either all bugs are auto-assigned upon creation or they're not. Right now, there are several components that have a default assignee and several that don't. For example, most of the Core: Event system bugs that I receive and reassign to GUI: Window management become Unassigned. -- 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] White space / coding style patches welcome?
2013/3/12 Oswald Buddenhagen oswald.buddenha...@digia.com: somebody attempted this just a few days ago, but gave up when the scope of the undertaking became clear. i can't find the change now ... https://codereview.qt-project.org/#change,48150 I indeed gave up, or at least I was trying to think of a good solution for the tab replacement issue. Doing it by hand is at least extremely boring. It need indeed more work that a simple regexp, as we want to keep a specific alignment in some places. Also your comment was not motivating :) The first patch set that remove just the trailing spaces is okay, the others are just crap. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt for iOS - iOSStyle
I'm already working on some preliminary testing for QIosStyle. I don't know how long it'll be before I have something on Gerrit but it will come. -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petrou...@petroules.com On Mar 12, 2013, at 7:52 AM, Sorvig Morten morten.sor...@digia.com wrote: Another good example of iOS app that does not quite follow the native UI is LinkedIn. I really like it, and I agree with you when you say some design alternatives can actually look even better than the stock native style based ones. But I am assuming this is not the point in this discussion - the point is: is it possible to implement a QStyle based iOS style? I would go for yes. Now, is there enough manpower and does it make sense? I don't know, then it's up to whoever will (not) be doing it. There might be a dozens of reasons not to go down that road - complexity, lack of manpower or whatever may turn up. But assuming it will look half baked and place that as a main reason makes me scratch my head. Complexity, maintenance burden and lack of manpower are the main reasons against, yes. And I think Jens summed up the technical issues well. The way to prove us wrong is of course to step up and implement (and maintain) such a style. Morten ___ 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] What do you know about Qt::Device/IoHandle?
2013/3/12 Sergey Belyashov sergey.belyas...@gmail.com: Laszlo is not primary maintainer. But Denis is. Laszlo is most active developer. Our policy is to accept features if only all 3 maintainers accepts it. I an Denis can accept your change. If you persuade Laszlo to accept patch then it will be merged. Thanks for clearing that up for me. 2013/3/11 Laszlo Papp lp...@kde.org: 2) I did not try to say, it has to be added to QtCore. All I said, it needs some more time to investigate about the proper API and considering that this feature has not been added to QExtSerialPort and so forth for more than eight years, I think it is not the most important thing to get done now for the release. QextSerialPort does not need handle() so badly because QextSerialPort does not force exclusive mode (TIOCEXCL) like QSerialPort does. The feature freeze was announced for the middle March, and I have concerns that I cannot finish the investigation I wished to do for this (i.e. even just for being able to review properly). Hence, I was trying to suggest to postpone the feature to 5.2. The idea is that, I personally do not wish to have an API added in a rush. We still have a room for the existing features to get up to the quality before adding further ones for this release. The best feature the API could have is the ability to add any feature you want by accessing the file descriptor. What about making the typedef QSerialPort::Handle private? If it was private, handle() could return a QSerialPort::Handle in Qt 5.1 and then you could change handle() to return whatever you want in Qt 5.2 without breaking source or binary compatibility. No one could complain. If you still disagree, what other option are you trying to investigate? Thiago made it pretty clear that you can't have a one-size-fits-all typedef for serial port, parallel port, bluetooth, and USB handles. By the way, though I'd love to see handle() in Qt 5.1, if you agree on a patch that fixes this problem and promise to commit it in Qt 5.2 I would be satisfied. -Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] White space / coding style patches welcome?
On Tue, Mar 12, 2013 at 5:32 PM, Oswald Buddenhagen oswald.buddenha...@digia.com wrote: it went to the trash because the idea was not liked back then. the winds appear to have changed meanwhile. That is a pitty. Given, that I already spent a bunch of hours looking into this, I hope you are right (about the winds of change ;)) 1) 'simple' line-by-line checks running directly on the diff: qt/qtrepotools/git-hooks/sanitize-commit Very interesting. So what I had in mind is basically done already. I found the following checks in sanitize-commit: * Trailing whitespace * Leading or mixed tabs * CRLF line endings * Flow control keywords must be followed by a single space I'd say in terms of Lars's worries about having automatic checks in place before attacking whitespace issues, there should not be any objection against fixing at least those 4 issues immediately. One might ask, though, if it would be a good idea to actually enforce the checks instead of merely letting the Sanity Bot warn about them? Just to handle the 3rdparty and autogenerated code? Or maybe to account for the very last line of the coding style wiki: Feel free to break a rule if it makes your code look bad.? I had a look at the statistics (ignoring both 3rdparty and auto generated files): about 2k lines in qtbase suffer from trailing whitespace and about 3k from leading tabs (of which more than 1k are from two files in tests/auto alone). Interestingly, the overlap of those two issues is about 10 lines only. Given that the trailing ws issue is very easily fixed by a one-liner as Corentin has used and that the overlap with the tab issue is so small, I suggest to fix all those 2k lines of trailing whitespace adding the couple tab-fixes manually, so the sanity bot is happy, and commit that in one go. Then in a second step deal with tabs and maybe other ws issues, that require manual intervention in smaller chunks. I'll also look into meaningful additional checks to be added to sanitize-commit. 2) proper c++ parser based checks that require the patch to be applied to the code to even run: to reliably parse c++, you need contextual information. that means that you need a complete build system. iow, you need to compile the whole thing, and have the style checking be done as a side effect. (I hereby presume there is some fancy tool in the context of libclang available...). if not: have fun. ^^ There is project called clang-format, which seems to be going to be part of clang 3.3: http://clang.llvm.org/docs/ClangFormat.html. There is a design doc available with a nice 'competition' line-up at the end, too: https://docs.google.com/document/d/1gpckL2U_6QuU9YW2L1ABsc4Fcogn5UngKk7fE5dDOoA/edit But I don't intend to dig a lot deeper on that front, given that the easy approach (sanitize-commit) turned out to be even easier than anticipated. - Axel ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
