Re: [Development] Some QIcon::fromTheme() enhancements
On Friday 23 August 2013 07:50:56 Olivier Goffart wrote: On Thursday 22 August 2013 22:18:54 Antti Kaijanmäki wrote: On 22.08.2013 21:51, Thiago Macieira wrote: On quinta-feira, 22 de agosto de 2013 21:26:15, Antti Kaijanmäki wrote: I have patches (linked in the bug) to amend this, and I would like to get some feedback on them. Hello Antti If you can, please upload the patches to codereview.qt-project.org. It's easier to discuss them there. Either I was not clear enough or I have misunderstood something, but the links to the patches in codereview.qt-project.org are in that bug report. :) Thanks for the patch, I will have a look. However, the patches do not fix a regression, neither a P1 bug, so they should go to the 'dev' branch instead of the 'stable' branch. This is weird https://codereview.qt-project.org/#change,63593 approved by you is linked to a P3 https://codereview.qt-project.org/#change,63496 is also linked to a P3 https://codereview.qt-project.org/#change,63535 is also linked to a P3 https://codereview.qt-project.org/#change,63413 is linked to a P2 https://codereview.qt-project.org/#change,63595 is not linked to any bug https://codereview.qt-project.org/#change,62408 is also not linked to any bug https://codereview.qt-project.org/#change,62948 is linked to a bug without categorization Also i don't understand that P1 rule for stable, what's the rationale to not fixing bugs in stable? That's what stable branch is for, no? I could understand P1 rule for release, but for stable, what if i fix a small bug (which I understand won't be categorized as P1), why should people wait for the fix of that small bug for Qt 5.2 instead of 5.1.x? Cheers, Albert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some QIcon::fromTheme() enhancements
On Friday 23. August 2013 09.24.54 Albert Astals Cid wrote: On Friday 23 August 2013 07:50:56 Olivier Goffart wrote: On Thursday 22 August 2013 22:18:54 Antti Kaijanmäki wrote: On 22.08.2013 21:51, Thiago Macieira wrote: On quinta-feira, 22 de agosto de 2013 21:26:15, Antti Kaijanmäki wrote: I have patches (linked in the bug) to amend this, and I would like to get some feedback on them. Hello Antti If you can, please upload the patches to codereview.qt-project.org. It's easier to discuss them there. Either I was not clear enough or I have misunderstood something, but the links to the patches in codereview.qt-project.org are in that bug report. :) Thanks for the patch, I will have a look. However, the patches do not fix a regression, neither a P1 bug, so they should go to the 'dev' branch instead of the 'stable' branch. This is weird https://codereview.qt-project.org/#change,63593 approved by you is linked to a P3 https://codereview.qt-project.org/#change,63496 is also linked to a P3 https://codereview.qt-project.org/#change,63535 is also linked to a P3 https://codereview.qt-project.org/#change,63413 is linked to a P2 https://codereview.qt-project.org/#change,63595 is not linked to any bug https://codereview.qt-project.org/#change,62408 is also not linked to any bug https://codereview.qt-project.org/#change,62948 is linked to a bug without categorization Seriously? Three of those are documentation fixes (so P1 or not doesn't make sense). Incorrect device pixel ratio can cause severe misrendering on retina displays, so I'd say it's pretty easy to argue that it should be fixed in patch release. The second last is a build issue that Olivier had nothing to do with and that in Joerg's opinion was important enough to fix in the next patch release. The QString fix you could argue fixes data corruption. And I think similarly it's easy to talk about the pop-up location fix. Instead of trying to attack other changes or Olivier's judgement as approver, I think it would be much better to explain why it is important that the icon fixes should go into a patch release. Make a good case for the patch, respond with arguments. And if you don't succeed in convincing Olivier, then there are other approvers that might be willing to review this. (I can think of one off the top of my head) FWIW I personally think the icon theme fixes are worth it, but I'm not the one who should be making that case. Simon Also i don't understand that P1 rule for stable, what's the rationale to not fixing bugs in stable? That's what stable branch is for, no? I could understand P1 rule for release, but for stable, what if i fix a small bug (which I understand won't be categorized as P1), why should people wait for the fix of that small bug for Qt 5.2 instead of 5.1.x? Cheers, Albert ___ 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] Some QIcon::fromTheme() enhancements
On 23 August 2013 09:24, Albert Astals Cid albert.ast...@canonical.com wrote: Also i don't understand that P1 rule for stable, what's the rationale to not fixing bugs in stable? That's what stable branch is for, no? I could understand P1 rule for release, but for stable, what if i fix a small bug (which I understand won't be categorized as P1), why should people wait for the fix of that small bug for Qt 5.2 instead of 5.1.x? The priority of a bug doesn't matter too much. A typo in the docs (and you linked to some) can be a P5, and still, the right branch to fix it is stable. The important bit here is that it's a behaviour change, and they *usually* belong to dev, not stable. However, it's a behaviour change that brings that method closer to what the related specification mandates, and doesn't require a massive code overhaul. So I'm keen to say that indeed the patch belong to stable. (I'm not a maintainer in that area, though.) Please don't bash each other, let's just discuss it by bringing proper arguments. Thanks, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some QIcon::fromTheme() enhancements
On Friday 23 August 2013 09:48:26 Simon Hausmann wrote: On Friday 23. August 2013 09.24.54 Albert Astals Cid wrote: On Friday 23 August 2013 07:50:56 Olivier Goffart wrote: On Thursday 22 August 2013 22:18:54 Antti Kaijanmäki wrote: On 22.08.2013 21:51, Thiago Macieira wrote: On quinta-feira, 22 de agosto de 2013 21:26:15, Antti Kaijanmäki wrote: I have patches (linked in the bug) to amend this, and I would like to get some feedback on them. Hello Antti If you can, please upload the patches to codereview.qt-project.org. It's easier to discuss them there. Either I was not clear enough or I have misunderstood something, but the links to the patches in codereview.qt-project.org are in that bug report. :) Thanks for the patch, I will have a look. However, the patches do not fix a regression, neither a P1 bug, so they should go to the 'dev' branch instead of the 'stable' branch. This is weird https://codereview.qt-project.org/#change,63593 approved by you is linked to a P3 https://codereview.qt-project.org/#change,63496 is also linked to a P3 https://codereview.qt-project.org/#change,63535 is also linked to a P3 https://codereview.qt-project.org/#change,63413 is linked to a P2 https://codereview.qt-project.org/#change,63595 is not linked to any bug https://codereview.qt-project.org/#change,62408 is also not linked to any bug https://codereview.qt-project.org/#change,62948 is linked to a bug without categorization Seriously? Three of those are documentation fixes (so P1 or not doesn't make sense). Incorrect device pixel ratio can cause severe misrendering on retina displays, so I'd say it's pretty easy to argue that it should be fixed in patch release. The second last is a build issue that Olivier had nothing to do with and that in Joerg's opinion was important enough to fix in the next patch release. The QString fix you could argue fixes data corruption. And I think similarly it's easy to talk about the pop-up location fix. Instead of trying to attack other changes or Olivier's judgement as approver, I think it would be much better to explain why it is important that the icon fixes should go into a patch release. Honestly, I don't have any stake at the icon fixes, I don't even know if they are right, don't assume I'm here because of my @canonical.com address i share with Antti. Make a good case for the patch, respond with arguments. And if you don't succeed in convincing Olivier, then there are other approvers that might be willing to review this. (I can think of one off the top of my head) Please let's not resort to stop attacking people as a way to stop people disagreeing. I'm just wondering why he writes only P1 for stable when it's clear this rule is not being applied by just reading the first page of https://codereview.qt-project.org/#q,status:open+project:qt/qtbase+branch:stable,n,z I don't mind if he says These are new features so they need to go into dev, but I'm sorry this is not a P1 so can't go into stable does not sound to me as a valid reason. To me something either it is a bug and has to be fixed ASAP or it is a feature and can wait. Of course I'm new here so if we have a policy on why we delay fixing bugs I'd be happy to be pointed to it. Cheers, Albert FWIW I personally think the icon theme fixes are worth it, but I'm not the one who should be making that case. Simon Also i don't understand that P1 rule for stable, what's the rationale to not fixing bugs in stable? That's what stable branch is for, no? I could understand P1 rule for release, but for stable, what if i fix a small bug (which I understand won't be categorized as P1), why should people wait for the fix of that small bug for Qt 5.2 instead of 5.1.x? Cheers, Albert ___ 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] Some QIcon::fromTheme() enhancements
On Friday 23. August 2013 10.04.35 Albert Astals Cid wrote: On Friday 23 August 2013 09:48:26 Simon Hausmann wrote: On Friday 23. August 2013 09.24.54 Albert Astals Cid wrote: On Friday 23 August 2013 07:50:56 Olivier Goffart wrote: On Thursday 22 August 2013 22:18:54 Antti Kaijanmäki wrote: On 22.08.2013 21:51, Thiago Macieira wrote: On quinta-feira, 22 de agosto de 2013 21:26:15, Antti Kaijanmäki wrote: I have patches (linked in the bug) to amend this, and I would like to get some feedback on them. Hello Antti If you can, please upload the patches to codereview.qt-project.org. It's easier to discuss them there. Either I was not clear enough or I have misunderstood something, but the links to the patches in codereview.qt-project.org are in that bug report. :) Thanks for the patch, I will have a look. However, the patches do not fix a regression, neither a P1 bug, so they should go to the 'dev' branch instead of the 'stable' branch. This is weird https://codereview.qt-project.org/#change,63593 approved by you is linked to a P3 https://codereview.qt-project.org/#change,63496 is also linked to a P3 https://codereview.qt-project.org/#change,63535 is also linked to a P3 https://codereview.qt-project.org/#change,63413 is linked to a P2 https://codereview.qt-project.org/#change,63595 is not linked to any bug https://codereview.qt-project.org/#change,62408 is also not linked to any bug https://codereview.qt-project.org/#change,62948 is linked to a bug without categorization Seriously? Three of those are documentation fixes (so P1 or not doesn't make sense). Incorrect device pixel ratio can cause severe misrendering on retina displays, so I'd say it's pretty easy to argue that it should be fixed in patch release. The second last is a build issue that Olivier had nothing to do with and that in Joerg's opinion was important enough to fix in the next patch release. The QString fix you could argue fixes data corruption. And I think similarly it's easy to talk about the pop-up location fix. Instead of trying to attack other changes or Olivier's judgement as approver, I think it would be much better to explain why it is important that the icon fixes should go into a patch release. Honestly, I don't have any stake at the icon fixes, I don't even know if they are right, don't assume I'm here because of my @canonical.com address i share with Antti. Ok, I won't make that assumption :) Make a good case for the patch, respond with arguments. And if you don't succeed in convincing Olivier, then there are other approvers that might be willing to review this. (I can think of one off the top of my head) Please let's not resort to stop attacking people as a way to stop people disagreeing. I'm just wondering why he writes only P1 for stable when it's clear this rule is not being applied by just reading the first page of https://codereview.qt-project.org/#q,status:open+project:qt/qtbase+branch:st able,n,z I don't mind if he says These are new features so they need to go into dev, but I'm sorry this is not a P1 so can't go into stable does not sound to me as a valid reason. To me something either it is a bug and has to be fixed ASAP or it is a feature and can wait. Of course I'm new here so if we have a policy on why we delay fixing bugs I'd be happy to be pointed to it. I think the main reason for being hesitant with fixing a certain bug in stable is the risk it introduces to cause other bigger behavioural changes or regressions themselves. It is indeed a question of severity, not every bug affects the same amount of users, not every bug causes the same amount of damage. In Qt we made that mistake a few times as well. Do you remember the numerous patch releases in the earlier Qt 4 days? Sometimes we were quite relaxed about putting bugfixes into a patch release just to find that it caused a regression itself and we needed another patch release as follow up to fix regressions in a patch release (urgh). That's one of the reasons I can think of why people tend to be a bit more hesitant and not put every bug fix straight into a patch release. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some QIcon::fromTheme() enhancements
On Friday 23 August 2013 09:24:54 Albert Astals Cid wrote: On Friday 23 August 2013 07:50:56 Olivier Goffart wrote: On Thursday 22 August 2013 22:18:54 Antti Kaijanmäki wrote: On 22.08.2013 21:51, Thiago Macieira wrote: On quinta-feira, 22 de agosto de 2013 21:26:15, Antti Kaijanmäki wrote: I have patches (linked in the bug) to amend this, and I would like to get some feedback on them. Hello Antti If you can, please upload the patches to codereview.qt-project.org. It's easier to discuss them there. Either I was not clear enough or I have misunderstood something, but the links to the patches in codereview.qt-project.org are in that bug report. :) Thanks for the patch, I will have a look. However, the patches do not fix a regression, neither a P1 bug, so they should go to the 'dev' branch instead of the 'stable' branch. This is weird I should have perhaps said critical issue. Please have a look at the criteria there: http://qt-project.org/wiki/Branch-Guidelines#4d553711002d5cb36d93954a352efa8e https://codereview.qt-project.org/#change,63593 approved by you is linked to a P3 That one is a critical bug. Reserve should not shrink another QString object. Any code that use reserve with a copy of a string is potentially affected. In my opinion, the bug should have been prioritized P1. https://codereview.qt-project.org/#change,63496 is also linked to a P3 https://codereview.qt-project.org/#change,63535 is also linked to a P3 Documentations changes should go in stable https://codereview.qt-project.org/#change,63413 is linked to a P2 I would probably have put this one in dev. This might fit in the bug in new feature. Or P2 to get Qt5 mature https://codereview.qt-project.org/#change,63595 is not linked to any bug Doc change. https://codereview.qt-project.org/#change,62408 is also not linked to any bug https://codereview.qt-project.org/#change,62948 is linked to a bug without categorization I know nothing about these path, perhaps it should have been in dev, perhaps they were good reason to put it there. In general, I find too many patches goes in the wrong branch. But that's not a justification to put a patch in the wrong branch. Also i don't understand that P1 rule for stable, what's the rationale to not fixing bugs in stable? That's what stable branch is for, no? Stable means it does not change much. Each change, no matter how small, has the potential to break things. In order to ensure that Qt x.y.(z+1) is better than Qt x.y.z, we need to have some sort of restrictions on what changes applies. I could understand P1 rule for release, but for stable, what if i fix a small bug (which I understand won't be categorized as P1), why should people wait for the fix of that small bug for Qt 5.2 instead of 5.1.x? The bug was already there since the beginning of the feature in Qt 4.7. They already had to wait so many years, they can wait a few moth more. However, a regression in Qt 5.1.2 would be much more damageable. Maybe there is a broken small .xpm in one style that makes an otherwise good png in another theme not taken. Maybe this happens to be a huge performance bottleneck with some setup, maybe there is a bug in XPM parsing. Or any other problem we don't think about now. You would have to have good arguments that this bug is urgent enough. Following a specification is important of course, but it is only some details about it and it does not seem an urgent issue to me. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some QIcon::fromTheme() enhancements
On Friday 23 August 2013 10:24:01 Simon Hausmann wrote: On Friday 23. August 2013 10.04.35 Albert Astals Cid wrote: On Friday 23 August 2013 09:48:26 Simon Hausmann wrote: On Friday 23. August 2013 09.24.54 Albert Astals Cid wrote: On Friday 23 August 2013 07:50:56 Olivier Goffart wrote: On Thursday 22 August 2013 22:18:54 Antti Kaijanmäki wrote: On 22.08.2013 21:51, Thiago Macieira wrote: On quinta-feira, 22 de agosto de 2013 21:26:15, Antti Kaijanmäki wrote: I have patches (linked in the bug) to amend this, and I would like to get some feedback on them. Hello Antti If you can, please upload the patches to codereview.qt-project.org. It's easier to discuss them there. Either I was not clear enough or I have misunderstood something, but the links to the patches in codereview.qt-project.org are in that bug report. :) Thanks for the patch, I will have a look. However, the patches do not fix a regression, neither a P1 bug, so they should go to the 'dev' branch instead of the 'stable' branch. This is weird https://codereview.qt-project.org/#change,63593 approved by you is linked to a P3 https://codereview.qt-project.org/#change,63496 is also linked to a P3 https://codereview.qt-project.org/#change,63535 is also linked to a P3 https://codereview.qt-project.org/#change,63413 is linked to a P2 https://codereview.qt-project.org/#change,63595 is not linked to any bug https://codereview.qt-project.org/#change,62408 is also not linked to any bug https://codereview.qt-project.org/#change,62948 is linked to a bug without categorization Seriously? Three of those are documentation fixes (so P1 or not doesn't make sense). Incorrect device pixel ratio can cause severe misrendering on retina displays, so I'd say it's pretty easy to argue that it should be fixed in patch release. The second last is a build issue that Olivier had nothing to do with and that in Joerg's opinion was important enough to fix in the next patch release. The QString fix you could argue fixes data corruption. And I think similarly it's easy to talk about the pop-up location fix. Instead of trying to attack other changes or Olivier's judgement as approver, I think it would be much better to explain why it is important that the icon fixes should go into a patch release. Honestly, I don't have any stake at the icon fixes, I don't even know if they are right, don't assume I'm here because of my @canonical.com address i share with Antti. Ok, I won't make that assumption :) Make a good case for the patch, respond with arguments. And if you don't succeed in convincing Olivier, then there are other approvers that might be willing to review this. (I can think of one off the top of my head) Please let's not resort to stop attacking people as a way to stop people disagreeing. I'm just wondering why he writes only P1 for stable when it's clear this rule is not being applied by just reading the first page of https://codereview.qt-project.org/#q,status:open+project:qt/qtbase+branch: st able,n,z I don't mind if he says These are new features so they need to go into dev, but I'm sorry this is not a P1 so can't go into stable does not sound to me as a valid reason. To me something either it is a bug and has to be fixed ASAP or it is a feature and can wait. Of course I'm new here so if we have a policy on why we delay fixing bugs I'd be happy to be pointed to it. I think the main reason for being hesitant with fixing a certain bug in stable is the risk it introduces to cause other bigger behavioural changes or regressions themselves. It is indeed a question of severity, not every bug affects the same amount of users, not every bug causes the same amount of damage. In Qt we made that mistake a few times as well. Do you remember the numerous patch releases in the earlier Qt 4 days? Sometimes we were quite relaxed about putting bugfixes into a patch release just to find that it caused a regression itself and we needed another patch release as follow up to fix regressions in a patch release (urgh). That's one of the reasons I can think of why people tend to be a bit more hesitant and not put every bug fix straight into a patch release. Sorry but this touches too much inner stuff, let's delay it a bit so we have more time/people to test/review it. That's also a very valid reason for me to put stuff into dev. I was only saying that I found the only P1 in stable reason a not so good reason given the track record of stuff that ends up in stable. Cheers, Albert Simon ___ Development mailing list
[Development] Pending Jira changes
Hi, I looked into the desired workflow changes for Jira (as discussed on this list) and am doing some general cleanups which I would like to bring up at this point. The more invasive bulk changes will happen on Monday while others have already happened. Please note that this may temporarily reduce the responsiveness of the system. 1.) I merged the Resolved, Closed and Verified states into a single state and added a shortcut from Open to Closed. I also took the liberty of renaming some of the transitions based on perceived usability and partly due to system requirements. The new workflow is as follows: https://bugreports.qt-project.org/plugins/servlet/workflow/thumbnail/getThumbnail?workflowName=Qt%20Bug%20Tracking%20v2.0stepId=8width=fullheight=full Every Suggestion, Bug and Task issue will get this update. Any issue that is currently Resolved, Verified or Closed will be transitioned to the Closed state. If you have any concerns about the modified workflow please raise them now. 2.) The QTJIRA project had a very inappropriate workflow and permission set. It was updated to carry the new Qt Bug workflow already. From now on it has the same setup as every other project. The only difference is that the project will not carry the OG Approvers group. Practically this means that you can expect the project permissions to behave such as if you don't have approver rights (if you have them). The project is again actively managed by jira admins now. Please use it if required. 3.) We had a lot of dead projects in Jira. While no project was deleted they have been put into storage. Some projects will no longer be visible and others will be read-only. The assumption is that we may still want to refer to the read-only projects later on whereas the invisible ones are truly dead. This affects the following projects: Read-Only: - Qt on Raspberry Pi - Qt Quick Components - Qt Solutions - Qt Webkit - Qt Mobility Invisible - Nokia Qt SDK - Qt Jambi - Qt Modularization Please raise your voice if you think one of those categories is inappropriate for those projects. Planned changes: As I have time during the next couple weeks I will further cleanup some of the undesirable artifacts in the system. This includes the removal of workflow/issue differences between for example the QtCreator and Qt project (the Qt project being the desired target) , remove and consolidate issue types and cleanup of old Nokia groups and roles. Also, I would like to know whether anybody still uses Greenhopper. Without further comments I'll assume that Greenhopper is no longer required and we may remove it in the future. Thank you for your understanding and feedback. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending Jira changes
On 08/23/2013 10:36 AM, Blasche Alexander wrote: 2.) The QTJIRA project had a very inappropriate workflow and permission set. It was updated to carry the new Qt Bug workflow already. From now on it has the same setup as every other project. The only difference is that the project will not carry the OG Approvers group. Practically this means that you can expect the project permissions to behave such as if you don't have approver rights (if you have them). The project is again actively managed by jira admins now. Please use it if required. so who are the JIRA admins ? where is this documented ? -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some QIcon::fromTheme() enhancements
On Aug 23, 2013, at 10:32 AM, Olivier Goffart oliv...@woboq.com wrote: https://codereview.qt-project.org/#change,62948 is linked to a bug without categorization This one went to stable because - crash/infinite loop fix - trivial patch for a corner case - fix for new functionality. I don't think we've covered the last point in this discussion: The bar for patching stable should be lower for fixes to new code. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] One qmake and cross compilation for different targets
2013/8/23 Oswald Buddenhagen oswald.buddenha...@digia.com On Thu, Aug 22, 2013 at 08:39:15PM +, Tomasz Olszak wrote: Let's Suppose that we have 2 different targets (ARM,MIPS) and we want develop on Windows, Mac and linux 64/32 bit. If I am provider of Qt cross compiled binaries for ARM and MIPS then in the end I can't provide complete development toolchain because I don't know which host OS will be used for crosscompilation. So either I will cross compile Qt NxM (where N number of hosts, M number of targets) times or suggest developers to built Qt on their own. Is there a way to extract data from Qt libraries (ARM, MIPS) and build corresponding host's qmake, moc etc. for these targets? the blackberries asked me the same question a few days ago ... If it was on ML, I didn't spot it then - sorry. unfortunately there is no clean way to avoid the NxM compilations; the qmake instance is too tightly coupled to the qt build (it's also the actual identifier of a particular qt as far as qtcreator is concerned). you can try some trickery to avoid the redundancy behind the scenes: - compile all builds for one target with the same -prefix but different -hostprefix'es - hard-link the binaries in the -hostbindir's for the same host systems but different -prefixes. note: you must put a qt.conf in each -hostbindir to override qmake's built-in idea of which qt build it belongs to. so it's mostly an installation/packaging challenge. you can do many of the actual compilations selectively per directory once you have figured out which targets you need. I don't know if I put things clearly. I don't know qmake. moc, rcc internals but I do know that they are tightly dependent on Qt version. How hard could it be to: 1. Prepare some metadata+mksecs with Qt targets binaries maybe in some dev tools package. (maybe this metadata is only qtbase/configure internal args, output of tests and so on) 2. prepare qmake, moc, rcc source packages. 3. Build host dev tools for crosscompilation from these src qmake, moc and rcc packages and metadata. I would like to pass only hostrefix, crosscompiler and sysroot path for configure. Rest info will be taken from mentioned metadata. This process can be automated with QtCreator plugin. Is it possible? If yes how hard is that? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending Jira changes
I looked into the desired workflow changes for Jira (as discussed on this list) and am doing some general cleanups which I would like to bring up at this point. The more invasive bulk changes will happen on Monday while others have already happened. Please note that this may temporarily reduce the responsiveness of the system. 1.) I merged the Resolved, Closed and Verified states into a single state and added a shortcut from Open to Closed. I also took the liberty of renaming some of the transitions based on perceived usability and partly due to system requirements. The new workflow is as follows: https://bugreports.qt- project.org/plugins/servlet/workflow/thumbnail/getThumbnail?workflowNa me=Qt%20Bug%20Tracking%20v2.0stepId=8width=fullheight=full Every Suggestion, Bug and Task issue will get this update. Any issue that is currently Resolved, Verified or Closed will be transitioned to the Closed state. If you have any concerns about the modified workflow please raise them now. 2.) The QTJIRA project had a very inappropriate workflow and permission set. It was updated to carry the new Qt Bug workflow already. From now on it has the same setup as every other project. The only difference is that the project will not carry the OG Approvers group. Practically this means that you can expect the project permissions to behave such as if you don't have approver rights (if you have them). The project is again actively managed by jira admins now. Please use it if required. 3.) We had a lot of dead projects in Jira. While no project was deleted they have been put into storage. Some projects will no longer be visible and others will be read-only. The assumption is that we may still want to refer to the read-only projects later on whereas the invisible ones are truly dead. This affects the following projects: Read-Only: - Qt on Raspberry Pi - Qt Quick Components - Qt Solutions - Qt Webkit - Qt Mobility Qt Solutions isn't strictly speaking dead, there are still some components worked on, could this be made read-write again? :) Andy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Pending Jira changes
On 08/23/2013 10:36 AM, Blasche Alexander wrote: Hi, I looked into the desired workflow changes for Jira (as discussed on this list) and am doing some general cleanups which I would like to bring up at this point. The more invasive bulk changes will happen on Monday while others have already happened. Please note that this may temporarily reduce the responsiveness of the system. 1.) I merged the Resolved, Closed and Verified states into a single state and added a shortcut from Open to Closed. I also took the liberty of renaming some of the transitions based on perceived usability and partly due to system requirements. The new workflow is as follows: https://bugreports.qt-project.org/plugins/servlet/workflow/thumbnail/getThumbnail?workflowName=Qt%20Bug%20Tracking%20v2.0stepId=8width=fullheight=full Every Suggestion, Bug and Task issue will get this update. Any issue that is currently Resolved, Verified or Closed will be transitioned to the Closed state. If you have any concerns about the modified workflow please raise them now. 2.) The QTJIRA project had a very inappropriate workflow and permission set. It was updated to carry the new Qt Bug workflow already. From now on it has the same setup as every other project. The only difference is that the project will not carry the OG Approvers group. Practically this means that you can expect the project permissions to behave such as if you don't have approver rights (if you have them). The project is again actively managed by jira admins now. Please use it if required. 3.) We had a lot of dead projects in Jira. While no project was deleted they have been put into storage. Some projects will no longer be visible and others will be read-only. The assumption is that we may still want to refer to the read-only projects later on whereas the invisible ones are truly dead. This affects the following projects: Read-Only: - Qt on Raspberry Pi - Qt Quick Components - Qt Solutions - Qt Webkit - Qt Mobility Invisible - Nokia Qt SDK - Qt Jambi - Qt Modularization Please raise your voice if you think one of those categories is inappropriate for those projects. Planned changes: As I have time during the next couple weeks I will further cleanup some of the undesirable artifacts in the system. This includes the removal of workflow/issue differences between for example the QtCreator and Qt project (the Qt project being the desired target) , remove and consolidate issue types and cleanup of old Nokia groups and roles. Also, I would like to know whether anybody still uses Greenhopper. Without further comments I'll assume that Greenhopper is no longer required and we may remove it in the future. Thank you for your understanding and feedback. -- Alex Thanks! :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] One qmake and cross compilation for different targets
On Fri, Aug 23, 2013 at 11:40:55AM +0200, Tomasz Olszak wrote: 2013/8/23 Oswald Buddenhagen oswald.buddenha...@digia.com the blackberries asked me the same question a few days ago ... If it was on ML, I didn't spot it then - sorry. it was private, otherwise my whole reply would have been a link. it was merely meant to illustrate that this is a common problem. I don't know if I put things clearly. I don't know qmake. moc, rcc internals but I do know that they are tightly dependent on Qt version. How hard could it be to: 1. Prepare some metadata+mksecs with Qt targets binaries maybe in some dev tools package. (maybe this metadata is only qtbase/configure internal args, output of tests and so on) 2. prepare qmake, moc, rcc source packages. 3. Build host dev tools for crosscompilation from these src qmake, moc and rcc packages and metadata. I would like to pass only hostrefix, crosscompiler and sysroot path for configure. Rest info will be taken from mentioned metadata. This process can be automated with QtCreator plugin. Is it possible? If yes how hard is that? to summarize: ?!?!? if you want hacks, just follow the instructions i gave you. but what you really want is dropping the host tool build from the x-build and using a pre-built host build of qt instead. that is easy to build into configure, but hard to make useful, because the tools were never designed to work with a foreign qt build. e.g., lupdate and lrelease call the qmake in their own binary dir to find out about their qt build, and of course qmake is bound to the build. within the build, configure-generated files are freely mixed with static files (both c++ headers and qmake pri files). it's a total mess. i'm planning to untangle this *somehow* for 5.3 (hopefully), but don't expect any related activity before that. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] One qmake and cross compilation for different targets
On sexta-feira, 23 de agosto de 2013 13:09:50, Oswald Buddenhagen wrote: but what you really want is dropping the host tool build from the x-build and using a pre-built host build of qt instead. that is easy to build into configure, but hard to make useful, because the tools were never designed to work with a foreign qt build. e.g., lupdate and lrelease call the qmake in their own binary dir to find out about their qt build, and of course qmake is bound to the build. within the build, configure-generated files are freely mixed with static files (both c++ headers and qmake pri files). it's a total mess. i'm planning to untangle this *somehow* for 5.3 (hopefully), but don't expect any related activity before that. Also note that the tools themselves are not backwards compatible. After it's compiled, the meta object retain compatibility, but that's not the case for the compilation itself: you can't mix a moc from Qt 5.1 with a qobjectdefs.h from Qt 5.2, for example. (you can today, but there's no guarantee we won't change the meta object versions again) -- 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] Tracing Qt
On 23/08/13 12:59, Blasche Alexander wrote:
Hi Robin,
I am not sure whether you are aware of
http://qt.gitorious.org/qtplayground/qlogger
It is pretty much what you describe. It was even close to a merge into qtcore
already (only rejected due to feature freeze). It gives you a complete API
including ways to integrate with qDebug/qWarning, runtime activation, little
to no overhead when deactivated and there was reasonably broad agreement
already. Also see:
http://lists.qt-project.org/pipermail/development/2012-December/008886.html
If you have spare cycles to actually make this happen I would propose you
start with a 95% done system rather than new.
--
Alex
For a tracing system to be useful and stand a chance of being adopted by
the libraries used by Qt as well as Qt itself, it shouldn't be part of Qt.
My humble attempt is available as part of v3c:
http://sourceforge.net/projects/v3c/
It has commits going back to 2011 but I deleted the earlier ones so it's
even older.
You can control tracing at compile time, link time and runtime.
You can cache trace output and only dump it if it's noteworthy, e.g. if
something went wrong or a corner case is hit.
This uses a stringstream to cache the trace output.
This will be available in the next version - the one I'm using with my
projects now (the version in SourceForge has the TraceCache macro but I
never got around to using/testing it until recently).
Some examples:
void fn(int a, int x)
{
TraceWrap(__PRETTY_FUNCTION__ a: a);
trace the value of x is x '.' endl;
}
It has a pluggable architecture, but the main application decides if
trace output goes to cout, cerr or a file or nowhere.
It doesn't have module-level trace control but that could be added.
Regards,
Philip Ashmore
From: development-bounces+alexander.blasche=digia@qt-project.org
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf of
Robin Burchell [robin...@viroteck.net]
Sent: Friday, August 23, 2013 13:20
To: development@qt-project.org
Cc: Poenitz Andre
Subject: [Development] Tracing Qt
Hi,
(apologies in advance for the wall of text)
It's inevitable when working with Qt that sooner or later, you
probably have a desire to work on tracing Qt - or at least part of it.
Qt Creator's QML profiler is one such very prominent example of an
area where this may be useful, but there are many others: usually
sprinkled around Qt hidden behind various defines, environment
variables, and other hard-to-find places. This makes digging into a
problem somewhat hard, unless you are (or can be handheld by) a Qt
expert when you start digging.
It's also a bit of a problem in that each of these methods uses
different ways to communicate information, meaning it is difficult to
write tooling to inspect this data and visualise it. We also miss out
on tracing in a number of areas that *could* potentially be valuable,
such as touch event processing, the event loop, the sky's the limit.
Thanks to Carsten and Andre for their input in hashing the details of
this proposal out.
Proposal
Let's look at unifying tracing inside Qt. Let's add code to Qt itself
to enable easy introspection of what exactly is going on.
When looking at tracing, it can be boiled down into two levels - an
area (which may be a feature being inspected, or a subsystem - for
instance, QML performance, vsync timestamps, ...) containing events,
so from this, we can gather that we need a way to categorise logging
by area, and the capability to switch logging on by area.
An area should be associated with a simple numeric identifier to avoid
expensive code when manipulating events, but there will be some form
of name = id mapping (for the environment variable below, for
instance).
Suggested area-based API:
enum TraceArea {
TraceAreaDrawing (drawing event, frame event)
... other areas as required
TraceAreaUser = 1000 // held for possible future expansion into
allowing dynamic area registration
}
QT_ENABLE_TRACE=inputevents,frameevents,magicalmonkeyevents
rationale: providing system-wide defaults enables tracing of
system-wide behaviour is very useful. Being able to inspect exactly
what an entire set of Qt-based applications are doing while a user is
interacting with it would be a useful thing.
enable_trace(TraceArea area)
disable_trace(TraceArea area)
rationale: a developer may want to turn tracing of an individual area
on/off at runtime, as they start something they are particularly
interested in tracing. This has some inspiration in
CALLGRIND_START_INSTRUMENTATION/CALLGRIND_STOP_INSTRUMENTATION also.
Along with this user-facing API, we also need some mechanism to enable
different applications of the tracing data (for instance, the QML
profiler from Creator, Android's systrace
https://developer.android.com/tools/help/systrace.html, plain console
Re: [Development] Tracing Qt
On 24/08/13 00:24, Philip Ashmore wrote:
On 23/08/13 12:59, Blasche Alexander wrote:
Hi Robin,
I am not sure whether you are aware of
http://qt.gitorious.org/qtplayground/qlogger
It is pretty much what you describe. It was even close to a merge into
qtcore already (only rejected due to feature freeze). It gives you a
complete API including ways to integrate with qDebug/qWarning, runtime
activation, little to no overhead when deactivated and there was reasonably
broad agreement already. Also see:
http://lists.qt-project.org/pipermail/development/2012-December/008886.html
If you have spare cycles to actually make this happen I would propose you
start with a 95% done system rather than new.
--
Alex
For a tracing system to be useful and stand a chance of being adopted by
the libraries used by Qt as well as Qt itself, it shouldn't be part of Qt.
My humble attempt is available as part of v3c:
http://sourceforge.net/projects/v3c/
It has commits going back to 2011 but I deleted the earlier ones so it's
even older.
You can control tracing at compile time, link time and runtime.
You can cache trace output and only dump it if it's noteworthy, e.g. if
something went wrong or a corner case is hit.
This uses a stringstream to cache the trace output.
This will be available in the next version - the one I'm using with my
projects now (the version in SourceForge has the TraceCache macro but I
never got around to using/testing it until recently).
Some examples:
void fn(int a, int x)
{
TraceWrap(__PRETTY_FUNCTION__ a: a);
trace the value of x is x '.' endl;
}
It has a pluggable architecture, but the main application decides if
trace output goes to cout, cerr or a file or nowhere.
It doesn't have module-level trace control but that could be added.
I forgot to mention I've also got v3c-qt:
http://sourceforge.net/projects/v3c-qt/
There's an examples tar-ball there that shows how to integrate tracing
into some demo Qt Applications.
My projects use the automake make make check make distcheck
make install commands, as well as make debian/ make ubuntu.
For iterative development I really like make -j9.
Oh and you can configure build targets, the defaults are debug and
release.
The point of proposing a tracing system/library that's not part of Qt is
that it can be adopted by non-Qt libraries which Qt might eventually use.
Regards,
Philip Ashmore
From: development-bounces+alexander.blasche=digia@qt-project.org
[development-bounces+alexander.blasche=digia@qt-project.org] on behalf
of Robin Burchell [robin...@viroteck.net]
Sent: Friday, August 23, 2013 13:20
To: development@qt-project.org
Cc: Poenitz Andre
Subject: [Development] Tracing Qt
Hi,
(apologies in advance for the wall of text)
It's inevitable when working with Qt that sooner or later, you
probably have a desire to work on tracing Qt - or at least part of it.
Qt Creator's QML profiler is one such very prominent example of an
area where this may be useful, but there are many others: usually
sprinkled around Qt hidden behind various defines, environment
variables, and other hard-to-find places. This makes digging into a
problem somewhat hard, unless you are (or can be handheld by) a Qt
expert when you start digging.
It's also a bit of a problem in that each of these methods uses
different ways to communicate information, meaning it is difficult to
write tooling to inspect this data and visualise it. We also miss out
on tracing in a number of areas that *could* potentially be valuable,
such as touch event processing, the event loop, the sky's the limit.
Thanks to Carsten and Andre for their input in hashing the details of
this proposal out.
Proposal
Let's look at unifying tracing inside Qt. Let's add code to Qt itself
to enable easy introspection of what exactly is going on.
When looking at tracing, it can be boiled down into two levels - an
area (which may be a feature being inspected, or a subsystem - for
instance, QML performance, vsync timestamps, ...) containing events,
so from this, we can gather that we need a way to categorise logging
by area, and the capability to switch logging on by area.
An area should be associated with a simple numeric identifier to avoid
expensive code when manipulating events, but there will be some form
of name = id mapping (for the environment variable below, for
instance).
Suggested area-based API:
enum TraceArea {
TraceAreaDrawing (drawing event, frame event)
... other areas as required
TraceAreaUser = 1000 // held for possible future expansion into
allowing dynamic area registration
}
QT_ENABLE_TRACE=inputevents,frameevents,magicalmonkeyevents
rationale: providing system-wide defaults enables tracing of
system-wide behaviour is very useful. Being able to inspect exactly
what an entire set of Qt-based applications are
