From Jani.Heikkinen at digia.com Mon Jul 1 07:20:10 2013 From: Jani.Heikkinen at digia.com (Heikkinen Jani) Date: Mon, 1 Jul 2013 05:20:10 +0000 Subject: [Development] Qt5.1 new snapshot In-Reply-To: <87B846C5-FA88-43FE-B390-3307816AEB9E@digia.com> References: <3813837.P9Vnxi6l90@tjmaciei-mobl2> <1B00CEBCD57FD445BD8228C9300DAE294D84081D@IT-EXMB02-HKI.it.local>, <1683992.KHzJEmdqHl@tjmaciei-mobl2> <87B846C5-FA88-43FE-B390-3307816AEB9E@digia.com> Message-ID: Hi! The problem was that we were not able to build QtCreator with the latest changes in the Mac environment and that's why we cannot create all packages for RC2. After a short study it comes clear that this problem affects to all applications using private headers. We find fix for this issue really soon and after discussion in the Digia release team & management we made decision to postpone the RC2 one day again because of that build issue. Unfortunately there isn't bug report for this build break at all; Everyone were focused to solve it. But this change fixes the issue: https://codereview.qt-project.org/#change,60080 We get few other changes( listed in the original mail) in as well. Those was agreed to be in Final so actually it is better to get those already in RC2 (but of course those weren't blocking the release). Br, Jani -----Original Message----- From: development-bounces+jani.heikkinen=digia.com at qt-project.org [mailto:development-bounces+jani.heikkinen=digia.com at qt-project.org] On Behalf Of Hirvonen Olli Sent: 29. kesäkuuta 2013 12:28 To: Thiago Macieira Cc: development at qt-project.org; releasing at qt-project.org Subject: Re: [Development] Qt5.1 new snapshot RC2 is now out. Sorry about delay. There were some blockers. Now everything is fixed. Details from Jani Heikkinen on Monday. "Thiago Macieira" kirjoitti 29.6.2013 kello 1.20: > On sexta-feira, 28 de junho de 2013 18.53.52, Turunen Tuukka wrote: >>> What prevented the RC2? >> >> There were a few issues that were found so late that it was not possible to >> get the fixes into today's packages any more. If all goes well they are in >> the packages tomorrow morning. It would not have made sense to release RC2 >> with those items - especially as all these were easy to fix. Details can be >> seen from codereview - submodule update with these fixes is running now. I >> hope we get a very good RC2 and can proceed soon to final based on it >> (perhaps even without any changes, of with a very, very small amount on >> modifications). > > Hmm... something is off here. The last release team meeting said "release RC2 > on Wednesday if sanity checking passes". You're telling me something different > now: there were changes that didn't make it in, by Friday. > > Were those changes P0 or P1? If there were no P0 or P1 fixes, RC2 should have > been released. > > Someone made a decision to not release today. I'd like to know the details. > What changes are those? Why are they showstoppers? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Tuukka.Turunen at digia.com Mon Jul 1 07:43:20 2013 From: Tuukka.Turunen at digia.com (Turunen Tuukka) Date: Mon, 1 Jul 2013 05:43:20 +0000 Subject: [Development] Qt5.1 new snapshot In-Reply-To: Message-ID: Hi, I have seen very little reports in the mailing lists for testing RC2 packages. Please take it for a spin and fill the report. As Jani said, it is a good candidate to be the final 5.1.0 - we should now test it and see if things are properly fixed. I hope we are able to release 5.1.0 soon. There will always be things to fix, and there is a large amount of fixes waiting in stable already (for 5.1.1). For our users the key thing is all the improvements there are in 5.1 compared to our previous release. Many are eagerly waiting to have it. Yours, -- Tuukka Turunen Director, R&D Digia, Qt Address: Piippukatu 11, 40100 Jyväskylä, FINLAND Email: tuukka.turunen at digia.com Mobile: + 358 40 7655 800 Qt Website: http://qt.digia.com Qt Blog: http://blog.qt.digia.com Qt Project: http://www.qt-project.org ------------------------------------------------------------------ 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. ------------------------------------------------------------------ On 1.7.2013 8.20, "Heikkinen Jani" wrote: >Hi! > >The problem was that we were not able to build QtCreator with the latest >changes in the Mac environment and that's why we cannot create all >packages for RC2. After a short study it comes clear that this problem >affects to all applications using private headers. We find fix for this >issue really soon and after discussion in the Digia release team & >management we made decision to postpone the RC2 one day again because of >that build issue. Unfortunately there isn't bug report for this build >break at all; Everyone were focused to solve it. But this change fixes >the issue: https://codereview.qt-project.org/#change,60080 > >We get few other changes( listed in the original mail) in as well. Those >was agreed to be in Final so actually it is better to get those already >in RC2 (but of course those weren't blocking the release). > >Br, >Jani > > > >-----Original Message----- >From: development-bounces+jani.heikkinen=digia.com at qt-project.org >[mailto:development-bounces+jani.heikkinen=digia.com at qt-project.org] On >Behalf Of Hirvonen Olli >Sent: 29. kesäkuuta 2013 12:28 >To: Thiago Macieira >Cc: development at qt-project.org; releasing at qt-project.org >Subject: Re: [Development] Qt5.1 new snapshot > >RC2 is now out. Sorry about delay. There were some blockers. Now >everything is fixed. Details from Jani Heikkinen on Monday. > >"Thiago Macieira" kirjoitti 29.6.2013 kello >1.20: > >> On sexta-feira, 28 de junho de 2013 18.53.52, Turunen Tuukka wrote: >>>> What prevented the RC2? >>> >>> There were a few issues that were found so late that it was not >>>possible to >>> get the fixes into today's packages any more. If all goes well they >>>are in >>> the packages tomorrow morning. It would not have made sense to release >>>RC2 >>> with those items - especially as all these were easy to fix. Details >>>can be >>> seen from codereview - submodule update with these fixes is running >>>now. I >>> hope we get a very good RC2 and can proceed soon to final based on it >>> (perhaps even without any changes, of with a very, very small amount on >>> modifications). >> >> Hmm... something is off here. The last release team meeting said >>"release RC2 >> on Wednesday if sanity checking passes". You're telling me something >>different >> now: there were changes that didn't make it in, by Friday. >> >> Were those changes P0 or P1? If there were no P0 or P1 fixes, RC2 >>should have >> been released. >> >> Someone made a decision to not release today. I'd like to know the >>details. >> What changes are those? Why are they showstoppers? >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From Friedemann.Kleint at digia.com Mon Jul 1 09:44:51 2013 From: Friedemann.Kleint at digia.com (Friedemann Kleint) Date: Mon, 1 Jul 2013 09:44:51 +0200 Subject: [Development] Handling specific platform events in Qt In-Reply-To: References: <51CD6436.5030000@digia.com> Message-ID: <51D13373.9020708@digia.com> Hi, So question are: > 1. Where should I put the code which will handle receiving events from Tizen and propagate them to Qt? That sounds like QXcbIntegration ..is there an #ifdef for Tizen? >2. Where should I put code which will handle RESUME (in our case not Qt::ApplicationSuspended) event: There is already a similar thing, bool QStyleHints::setFocusOnTouchRelease() added by 438211ec627073817fcaf6d3a07b76f2aa5d90e0 (dev) for iOS, Android. The style hint is returned by QPlatformIntegration. If it turns out that there are more such hints are required to fine-tune Qt's behavior on mobile devices, an enumeration could be introduced for this? Regards, Friedemann -- Friedemann Kleint Digia, Qt From olszak.tomasz at gmail.com Mon Jul 1 10:02:43 2013 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Mon, 1 Jul 2013 10:02:43 +0200 Subject: [Development] Handling specific platform events in Qt In-Reply-To: <51D13373.9020708@digia.com> References: <51CD6436.5030000@digia.com> <51D13373.9020708@digia.com> Message-ID: 2013/7/1 Friedemann Kleint > Hi, > > So question are: > > > 1. Where should I put the code which will handle receiving events > from Tizen and propagate them to Qt? > > That sounds like QXcbIntegration ..is there an #ifdef for Tizen? > > >2. Where should I put code which will handle RESUME (in our case not > Qt::ApplicationSuspended) event: > > There is already a similar thing, bool > QStyleHints::setFocusOnTouchRelease() added by > 438211ec627073817fcaf6d3a07b76f2aa5d90e0 (dev) for iOS, Android. > The style hint is returned by QPlatformIntegration. If it turns out > that there are more such hints are required to fine-tune Qt's behavior > on mobile devices, an enumeration could be introduced for this? > > Regards, > Friedemann > > -- > Friedemann Kleint > Digia, Qt > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > Hi I have implemented initial version this weekend. I think that regarding Tizen it can't be resolved with styleHints. When app goes background it can be raise to foreground only when we again click app icon or choose is from task manager. There is no gestures. I would like to kindly ask for review this WIP change: https://codereview.qt-project.org/#change,60169 Who else besides you and Alan can I add as reviewers? -- regards / pozdrawiam, Tomasz Olszak Qt for Tizen | http://qt-project.org/wiki/Tizen Qt Certified Developer | http://qt-project.org http://linkedin.com/in/tolszak -------------- next part -------------- An HTML attachment was scrubbed... URL: From Carlos.Gomez at hcl.com Mon Jul 1 10:21:12 2013 From: Carlos.Gomez at hcl.com (Carlos Gomez, HCL America) Date: Mon, 1 Jul 2013 01:21:12 -0700 Subject: [Development] State of (old?) Qt 5.0 in Tizen IVI 1.0 ... Message-ID: <0A1EAF95665C44418A21392D8868D73702ED61F93F@GEO-HCLT-USEVS3.GEO.CORP.HCL.IN> Hello - This is NOT in relation to current development with regard to Qt for Tizen. In December 2012, in Tizen IVI 1.0, these Qt packages were present in the Tizen git repo : https://review.tizen.org/git/ : profile/ivi/bluetooth-qt profile/ivi/connman-qt profile/ivi/ofono-qt profile/ivi/qtbase profile/ivi/qtdeclarative profile/ivi/qtjsbackend profile/ivi/qtwayland profile/ivi/qtxmlpatterns Questions regarding the history of this port : 1: How stable was this port into Tizen IVI 1.0? 2: Was this a "Wayland only" port? 3: How complete was this port? I ask because I *think* I see evidence that QtQuick 1.0 support was not included. Thank you for your time, Carlos Gomez ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- From Yoann.Lopes at digia.com Mon Jul 1 10:26:43 2013 From: Yoann.Lopes at digia.com (Lopes Yoann) Date: Mon, 1 Jul 2013 08:26:43 +0000 Subject: [Development] Multimedia :video : loop, in out property In-Reply-To: References: <51CFF8B4.8000808@familiesomers.nl> Message-ID: Hi, Good suggestion, I created a task for this: https://bugreports.qt-project.org/browse/QTBUG-32129 Yoann Lopes Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com On Jun 30, 2013, at 5:01 PM, qtnext wrote: yes I know.... but you have far from a seamless loop ... and it should be so easy to do that on a low level side .. 2013/6/30 Andre Somers > Op 30-6-2013 10:46, qtnext schreef: > Hi, > > I have just test the last multimedia parts : it rocks now ! playback > seems to works, camera is working on desktop mac, ... but there is a > very important missing property : there is no way to smoothly loop a > media : it's important for digital signage but also it can be very > usefull on qml to have a dynamic background. The only way to do that > is to check when the media comes to the end and restart the media, in > this case the loop is not good, it's a too high level way to do that, > and I am sure that on most backend it's easy to do on the low level > backend. Is it possible to add theses properties to the multimedia : > isLoopable, loop property and perhaps in/out property to allow a > playback on a range ? > > Using the C++ API at least, you can use the QMediaPlaylist class to achieve this. Just make a list of one, and set the playbackmode to Loop. I don't know if you can do something similar in QML though. André _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From joerg.bornemann at digia.com Mon Jul 1 11:48:36 2013 From: joerg.bornemann at digia.com (Joerg Bornemann) Date: Mon, 1 Jul 2013 11:48:36 +0200 Subject: [Development] Some information about qt-labs projects from gitorious and gerrit In-Reply-To: References: Message-ID: <51D15074.8050104@digia.com> On 30/06/2013 15:50, Liang Qi wrote: > | * | * | jom | Active? last update 5 months ago | It serves its purpose. No big bugfixes or features planned. AKA "done". Cheers, Joerg -- Joerg Bornemann Digia, Qt http://qt.digia.com/ From Marco.Bubke at digia.com Mon Jul 1 11:56:41 2013 From: Marco.Bubke at digia.com (Bubke Marco) Date: Mon, 1 Jul 2013 09:56:41 +0000 Subject: [Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders In-Reply-To: References: <98F45B99-00A4-49A9-814B-C7CD57398390@digia.com>, Message-ID: Alan Alpert: The items-in-a-scene is an implementation detail (albeit one of the biggest ones), but if you can provide a better implementation for the existing APIs then that would be ideal. If not, we need to start considering trade-offs instead, and maybe these other use-cases are not as important as the application running with high performance on-device. The initial usecases were not MDI, and were not even multi-window. We aren't going to throw in extra abstraction layers for a "potential future". It's much better to maintain flexibility to be able to add abstractions later on, even though abstractions are easiest to implement at the start. One of the hopes for the QML-only API of QtQuick is that we are only restricted by QML versioning (separate from Qt versioning), and this gives us more flexibility. If we implement it new I would opt for a approach where a item would have something like a property isApplicationWindow. This item would be than wrapped in a Window. I think MDI would be possible too with this approach. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tor.arne.vestbo at digia.com Mon Jul 1 12:41:08 2013 From: tor.arne.vestbo at digia.com (=?ISO-8859-1?Q?Tor_Arne_Vestb=F8?=) Date: Mon, 1 Jul 2013 12:41:08 +0200 Subject: [Development] Handling specific platform events in Qt In-Reply-To: References: <51CD6436.5030000@digia.com> Message-ID: <51D15CC4.4030104@digia.com> On 6/28/13 18:59 , Alan Alpert wrote: > This should be accessible via Qt.application.active (false if > paused/minimized or otherwise not visible). Qt.application.active binds to a window having keyboard activation, AFAIK, which may or may not correspond to also being visible/in front, and vice versa. That's why the application state property was added, but that's not exposed to QML yet. Richard knows the details. tor arne From Jani.Heikkinen at digia.com Mon Jul 1 13:18:12 2013 From: Jani.Heikkinen at digia.com (Heikkinen Jani) Date: Mon, 1 Jul 2013 11:18:12 +0000 Subject: [Development] Qt 5.1.0 rc2 is out In-Reply-To: <9B4D1DADF5006F4DB6666312421B98E50101130F@IT-EXMB01-HKI.it.local> References: <9B4D1DADF5006F4DB6666312421B98E50101130F@IT-EXMB01-HKI.it.local> Message-ID: Hi all! I really hope you could test this Qt5.1 RC2 as soon as possible and verify that your changes are in and working OK. Our target is to use this RC2 as a final if no new P0 issues found during testing. We will do final release as soon as possible so please verify all your P0 issues are fixed in these packages. There are few approved items in the release branch which aren't in RC2 but we hope those could be postponed to Qt5.1.1 and we don't need to update packages because of those. Those changes are: qtbase https://codereview.qt-project.org/60120 https://codereview.qt-project.org/60119 https://codereview.qt-project.org/59239 qtdeclarative https://codereview.qt-project.org/59964 https://codereview.qt-project.org/59963 qtsensors https://codereview.qt-project.org/60179 There was also wrong link to blockers in the Sergio's mail. There is list of issues seen as a blocker for the final release: https://bugreports.qt-project.org/browse/QTBUG-31856 At the moment all items are fixed. Let's hope we don't find any new and we can make official Qt5.1 release really soon! Br, Jani -----Original Message----- From: development-bounces+jani.heikkinen=digia.com at qt-project.org [mailto:development-bounces+jani.heikkinen=digia.com at qt-project.org] On Behalf Of Ahumada Sergio Sent: 29. kesäkuuta 2013 12:05 To: development Cc: releasing at qt-project.org Subject: [Development] Qt 5.1.0 rc2 is out Hi, We have now released Qt 5.1.0 rc2. Packages are available from http://download.qt-project.org/development_releases/qt/5.1/5.1.0-rc2/ All blockers for final should be fixed in this version so if no new blocker issues are found we should be able to release the final really soon. As agreed in the release team meeting, there is no blog post for RC2, it is announced for the development community only. Big thanks to everyone involved! Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From g.scheikl at avibit.com Mon Jul 1 13:18:26 2013 From: g.scheikl at avibit.com (Gerhard Scheikl) Date: Mon, 01 Jul 2013 13:18:26 +0200 Subject: [Development] Qt 5.1.0 rc2 is out In-Reply-To: <9B4D1DADF5006F4DB6666312421B98E50101130F@IT-EXMB01-HKI.it.local> Message-ID: <31925114.6iVtKzrqqL@pc12.avibit.com> > All blockers for final should be fixed in this version > so if no new blocker > issues are found we should be able to release the final really soon. Hi! This one should definitely be a blocker: http://bugreports.qt-project.org/browse/QTBUG-31576 Best regards, Gerhard Scheikl From Tuukka.Turunen at digia.com Mon Jul 1 13:24:54 2013 From: Tuukka.Turunen at digia.com (Turunen Tuukka) Date: Mon, 1 Jul 2013 11:24:54 +0000 Subject: [Development] Qt 5.1.0 rc2 is out In-Reply-To: <31925114.6iVtKzrqqL@pc12.avibit.com> Message-ID: On 1.7.2013 14.18, "Gerhard Scheikl" wrote: > >> All blockers for final should be fixed in this version >> so if no new >>blocker >> issues are found we should be able to release the final really soon. > >Hi! > >This one should definitely be a blocker: >http://bugreports.qt-project.org/browse/QTBUG-31576 That one is marked as P1 and there seems to be a workaround, so for me it should not be a blocker to release Qt 5.1.0. Yours, Tuukka From g.scheikl at avibit.com Mon Jul 1 13:32:23 2013 From: g.scheikl at avibit.com (Gerhard Scheikl) Date: Mon, 01 Jul 2013 13:32:23 +0200 Subject: [Development] Qt 5.1.0 rc2 is out In-Reply-To: References: Message-ID: <3400100.p1g7dfqxFM@pc12.avibit.com> On Monday 01 July 2013 11:24:54 Turunen Tuukka wrote: > That one is marked as P1 and there seems to be a workaround, so for me it > should not be a blocker to release Qt 5.1.0. > > Yours, > > Tuukka The "workaround" is porting the whole code to QtQuick2. In our case that's just not possible at the moment. Binding properties is a very basic feature. It worked well with Qt4 and should still be working using Qt5. It should be fixed before releasing the next version of Qt5. Best Regards, Gerhard From paul.tvete at digia.com Mon Jul 1 13:59:15 2013 From: paul.tvete at digia.com (Paul Olav Tvete) Date: Mon, 1 Jul 2013 13:59:15 +0200 Subject: [Development] Qt 5.1.0 rc2 is out In-Reply-To: <3400100.p1g7dfqxFM@pc12.avibit.com> References: <3400100.p1g7dfqxFM@pc12.avibit.com> Message-ID: <2780500.sgWNVDgEi8@neverwhere> On Monday 01 July 2013 13:32:23 Gerhard Scheikl wrote: > Binding properties is a very basic feature. > It worked well with Qt4 and should still be working using Qt5. > > It should be fixed before releasing the next version of Qt5. This does indeed look like a nasty bug. However, it has been present in several versions of Qt already, and it has only recently been reported. This means that Qt 5.1.0 will still be useful to a large number of people even with this bug. As far as I can see, there is no fix proposed for this bug, and according to the bugtracker, no-one is even working on it. Stopping the release process at this point (a couple of days before the release) for an indeterminate time, possibly postponing the release until September, seems disproportionate. There will be a 5.1.1 release in not too long, and if there is a fix by that time it will be included in that release. - Paul From Lars.Knoll at digia.com Mon Jul 1 14:12:49 2013 From: Lars.Knoll at digia.com (Knoll Lars) Date: Mon, 1 Jul 2013 12:12:49 +0000 Subject: [Development] Qt 5.1.0 rc2 is out In-Reply-To: <2780500.sgWNVDgEi8@neverwhere> Message-ID: On 7/1/13 1:59 PM, "Paul Olav Tvete" wrote: >On Monday 01 July 2013 13:32:23 Gerhard Scheikl wrote: >> Binding properties is a very basic feature. >> It worked well with Qt4 and should still be working using Qt5. >> >> It should be fixed before releasing the next version of Qt5. > >This does indeed look like a nasty bug. However, it has been present in >several versions of Qt already, and it has only recently been reported. >This >means that Qt 5.1.0 will still be useful to a large number of people even >with >this bug. > >As far as I can see, there is no fix proposed for this bug, and according >to >the bugtracker, no-one is even working on it. Stopping the release >process at >this point (a couple of days before the release) for an indeterminate >time, >possibly postponing the release until September, seems disproportionate. > >There will be a 5.1.1 release in not too long, and if there is a fix by >that >time it will be included in that release. As unfortunate as the bug is I have to agree with Paul. But we should try to find a fix asap for it. Please make it a blocker for 5.1.1. Lars From stephen.kelly at kdab.com Mon Jul 1 14:23:04 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Mon, 01 Jul 2013 14:23:04 +0200 Subject: [Development] Qt 5.1.0 rc2 is out In-Reply-To: <9B4D1DADF5006F4DB6666312421B98E50101130F@IT-EXMB01-HKI.it.local> References: <9B4D1DADF5006F4DB6666312421B98E50101130F@IT-EXMB01-HKI.it.local> Message-ID: <5323353.ycHjUWkQHt@hal> On Saturday, June 29, 2013 09:04:51 Ahumada Sergio wrote: > Hi, > > We have now released Qt 5.1.0 rc2. > > Packages are available from > http://download.qt-project.org/development_releases/qt/5.1/5.1.0-rc2/ I don't have a mac to hand today to test this or provide the missing information, but this one, from the description, could be a blocker: https://bugreports.qt-project.org/browse/QTBUG-32134 If the missing information is provided, it would make the cmake files entirely unusable on Mac. Feel free to confirm or deny if you have access to a Mac. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From stephen.kelly at kdab.com Mon Jul 1 14:36:33 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Mon, 01 Jul 2013 14:36:33 +0200 Subject: [Development] [Releasing] Qt 5.1.0 rc2 is out In-Reply-To: <5323353.ycHjUWkQHt@hal> References: <9B4D1DADF5006F4DB6666312421B98E50101130F@IT-EXMB01-HKI.it.local> <5323353.ycHjUWkQHt@hal> Message-ID: <1710199.qYY7MGklOR@hal> On Monday, July 01, 2013 14:23:04 Stephen Kelly wrote: > On Saturday, June 29, 2013 09:04:51 Ahumada Sergio wrote: > > Hi, > > > > We have now released Qt 5.1.0 rc2. > > > > Packages are available from > > http://download.qt-project.org/development_releases/qt/5.1/5.1.0-rc2/ > > I don't have a mac to hand today to test this or provide the missing > information, but this one, from the description, could be a blocker: > > https://bugreports.qt-project.org/browse/QTBUG-32134 > > If the missing information is provided, it would make the cmake files > entirely unusable on Mac. Feel free to confirm or deny if you have access > to a Mac. Through a colleage testing and talking to ossi on IRC, this is confirmed, and I'm working on a patch. Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From Tuukka.Turunen at digia.com Mon Jul 1 14:48:52 2013 From: Tuukka.Turunen at digia.com (Turunen Tuukka) Date: Mon, 1 Jul 2013 12:48:52 +0000 Subject: [Development] [Releasing] Qt 5.1.0 rc2 is out In-Reply-To: <1710199.qYY7MGklOR@hal> Message-ID: On 1.7.2013 15.36, "Stephen Kelly" wrote: >On Monday, July 01, 2013 14:23:04 Stephen Kelly wrote: >> On Saturday, June 29, 2013 09:04:51 Ahumada Sergio wrote: >> > Hi, >> > >> > We have now released Qt 5.1.0 rc2. >> > >> > Packages are available from >> > http://download.qt-project.org/development_releases/qt/5.1/5.1.0-rc2/ >> >> I don't have a mac to hand today to test this or provide the missing >> information, but this one, from the description, could be a blocker: >> >> https://bugreports.qt-project.org/browse/QTBUG-32134 >> >> If the missing information is provided, it would make the cmake files >> entirely unusable on Mac. Feel free to confirm or deny if you have >>access >> to a Mac. > >Through a colleage testing and talking to ossi on IRC, this is confirmed, >and >I'm working on a patch. Good that you are fixing this. We also need to determine if this is a blocker for Qt 5.1.0 or not. The official way to build is using qmake and make. If we want to keep cmake as an option, there should be more automated testing of it so that it is not all the time breaking and causing problems for releasing. Yours, Tuukka From stephen.kelly at kdab.com Mon Jul 1 15:02:00 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Mon, 01 Jul 2013 15:02 +0200 Subject: [Development] [Releasing] Qt 5.1.0 rc2 is out In-Reply-To: References: Message-ID: <3784380.zYnKQqmdn1@hal> On Monday, July 01, 2013 12:48:52 Turunen Tuukka wrote: > there should be more > automated testing of it so that it is not all the time breaking and > causing problems for releasing. Yes, I agree. https://bugreports.qt-project.org/browse/QTBUG-27315 You wrote that that bug is in progress. Do you have anything to report? Beyond that, I'll see what I can do to make changes in Qt which cause breakage to do so at CI time. Regarding the 'all the time breaking' phrase, I want to point out that many of the times reports mention errors from cmake, they are real problems in Qt which are being found and reported by cmake, but not caused by the cmake files. A recent example of that is https://codereview.qt-project.org/#change,59906 but it is of course not the only example. Such problems would not occur if there was any progress on https://bugreports.qt-project.org/browse/QTBUG-27315 Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From Tuukka.Turunen at digia.com Mon Jul 1 15:10:31 2013 From: Tuukka.Turunen at digia.com (Turunen Tuukka) Date: Mon, 1 Jul 2013 13:10:31 +0000 Subject: [Development] [Releasing] Qt 5.1.0 rc2 is out In-Reply-To: <3784380.zYnKQqmdn1@hal> Message-ID: On 1.7.2013 16.02, "Stephen Kelly" wrote: >On Monday, July 01, 2013 12:48:52 Turunen Tuukka wrote: >> there should be more >> automated testing of it so that it is not all the time breaking and >> causing problems for releasing. > >Yes, I agree. > > https://bugreports.qt-project.org/browse/QTBUG-27315 > >You wrote that that bug is in progress. Do you have anything to report? I updated the bug report. Progress of this has been slower than I expected, but some things have been done already, so it is progressing. > >Beyond that, I'll see what I can do to make changes in Qt which cause >breakage >to do so at CI time. Great. > >Regarding the 'all the time breaking' phrase, I want to point out that >many of >the times reports mention errors from cmake, they are real problems in Qt >which are being found and reported by cmake, but not caused by the cmake >files. A recent example of that is > > https://codereview.qt-project.org/#change,59906 > >but it is of course not the only example. > >Such problems would not occur if there was any progress on > > https://bugreports.qt-project.org/browse/QTBUG-27315 True. Yours, Tuukka > >Thanks, > >-- >Stephen Kelly | Software Engineer >KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com >www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 >KDAB - Qt Experts - Platform-Independent Software Solutions From stephen.kelly at kdab.com Mon Jul 1 15:31:06 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Mon, 01 Jul 2013 15:31:06 +0200 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: References: Message-ID: <11162927.8vSKeZ4urK@hal> On Monday, July 01, 2013 12:48:52 Turunen Tuukka wrote: > The official way [for third parties] to build is using qmake and make. Given that I am officially maintaining the cmake files for third parties to use in my Qt Project role, what exactly makes that unofficial? Does anyone else in the Qt Project agree with Tuukka? Lars, any opinion? Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From Tuukka.Turunen at digia.com Mon Jul 1 15:38:32 2013 From: Tuukka.Turunen at digia.com (Turunen Tuukka) Date: Mon, 1 Jul 2013 13:38:32 +0000 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: <11162927.8vSKeZ4urK@hal> Message-ID: On 1.7.2013 16.31, "Stephen Kelly" wrote: >On Monday, July 01, 2013 12:48:52 Turunen Tuukka wrote: >> The official way [for third parties] to build is using qmake and make. > >Given that I am officially maintaining the cmake files for third parties >to >use in my Qt Project role, what exactly makes that unofficial? > >Does anyone else in the Qt Project agree with Tuukka? Lars, any opinion? Let me rephrase, 'the primary way to build is using qmake and make'. I apologize for bad wording. My 1st point is that we should have good level of automated and manual testing for things we want to have working in all releases. It is very bad when things are found last minute, possibly causing a full testing cycle to be restarted. It is very costly, and also means good development time is wasted when we need to again start packaging, testing etc activities. My 2nd point is that in some case we may end up not having something working if problems are found late, and that something is not primary use case. For the cmake problem, hopefully a fix is available soon so that we can discuss what would it mean if it is taken into 5.1.0 - and at least it will be there in Qt 5.1.1. Yours, Tuukka From sergio.ahumada at digia.com Mon Jul 1 15:41:17 2013 From: sergio.ahumada at digia.com (Sergio Ahumada) Date: Mon, 1 Jul 2013 15:41:17 +0200 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: <11162927.8vSKeZ4urK@hal> References: <11162927.8vSKeZ4urK@hal> Message-ID: <51D186FD.1030506@digia.com> On 07/01/2013 03:31 PM, Stephen Kelly wrote: > On Monday, July 01, 2013 12:48:52 Turunen Tuukka wrote: >> The official way [for third parties] to build is using qmake and make. > > Given that I am officially maintaining the cmake files for third parties to > use in my Qt Project role, what exactly makes that unofficial? What makes it official ? Has this been discussed ? I do agree with you that cmake has caught some problems and that you have put lots of effort in maintaining it, but I am not quite sure that's enough to make it official. If we want to make it official (and blocking in CI and stopping a release), then it should be publicly discussed IMHO. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt From jpnurmi at digia.com Mon Jul 1 16:04:38 2013 From: jpnurmi at digia.com (Nurmi J-P) Date: Mon, 1 Jul 2013 14:04:38 +0000 Subject: [Development] PROPOSAL: merge #qt-qml and #qt-components to #qt-quick In-Reply-To: References: <77CBF859-2E2C-434C-AD7D-41E01B6F0616@digia.com> Message-ID: <21B12E67-E779-4F2A-8BDD-74D90F74CB56@digia.com> Hi again, A new #qt-quick channel was established a couple of weeks ago, and the users of the former #qt-components were redirected to #qt-quick. Now that the dust has settled, I'd like to propose taking the next step - to merge #qt-qml to #qt-quick. Users are increasingly confused by the separation between the two channels, and the questions seem to be pretty mixed too. Therefore I'm still voting for having a single #qt-quick channel for Qt Quick and QML users. Time will tell whether development discussions should be kept there or not. -- J-P Nurmi On Jun 11, 2013, at 7:11 PM, Alan Alpert <416365416c at gmail.com> wrote: > I like the idea. For the average user, I definitely think #qt-quick is > a better name. It has a much clearer association, due to users > importing QtQuick and QtQuick.Controls in every file. And non-quick > QML users won't get lost as badly (I once saw a Cascades user in > #qt-qml, and no-one could help him :( . #qt-qnx is a better channel > for Cascades-QML - now that QBS is 1.0.0 we don't want QBS users to > get lost either). > > I would like to have a separate #qt-qml channel for the language > issues (which are more working on the language than working with > anyways), but that's not realistic because users can't always tell the > difference. So maybe once the new #qt-quick channel is fully > established and #qt-qml is empty, we can reclaim it. Or the > language/engine development channel can have a more technical name to > hide it from the average user. That second channel is less important, > so it can wait for a later discussion, and QML language development > chat can always go to #qt-labs until then. > > -- > Alan Alpert > >> On Jun 11, 2013, at 2:15 PM, Laszlo Papp wrote: >> >>> Why not #qt-qml for the merged channel? I use the term "QML" more than "QtQuick" in this context. >>> >>> I agree about having one channel though. >>> >>> >>> On Tue, Jun 11, 2013 at 3:04 PM, Nurmi J-P wrote: >>> Hi all, >>> >>> I'd like to propose merging the current #qt-qml and #qt-components IRC channels to a single channel called #qt-quick. >>> >>> Reasons: >>> - the #qt-components name is outdated now that we have QtQuick Controls >>> - most users don't understand the distinction between QML, QtQuick and QtQuick Controls. >>> >>> I believe this would make it easier for new users to find the correct channel. We would also setup automatic redirects from the old channels so the naming would be more or less transparent to the current users. Thoughts? >>> >>> -- >>> J-P Nurmi >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development From tor.arne.vestbo at digia.com Mon Jul 1 16:10:40 2013 From: tor.arne.vestbo at digia.com (=?ISO-8859-1?Q?Tor_Arne_Vestb=F8?=) Date: Mon, 1 Jul 2013 16:10:40 +0200 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: <51D186FD.1030506@digia.com> References: <11162927.8vSKeZ4urK@hal> <51D186FD.1030506@digia.com> Message-ID: <51D18DE0.5070709@digia.com> On 7/1/13 15:41 , Sergio Ahumada wrote: > On 07/01/2013 03:31 PM, Stephen Kelly wrote: >> On Monday, July 01, 2013 12:48:52 Turunen Tuukka wrote: >>> The official way [for third parties] to build is using qmake and make. >> >> Given that I am officially maintaining the cmake files for third parties to >> use in my Qt Project role, what exactly makes that unofficial? > > What makes it official ? Has this been discussed ? > > I do agree with you that cmake has caught some problems and that you > have put lots of effort in maintaining it, but I am not quite sure > that's enough to make it official. > > If we want to make it official (and blocking in CI and stopping a > release), then it should be publicly discussed IMHO. There is also the question of platform support. Is cmake as relevant on Windows or OSX as it is on Linux? More so? tor arne From olszak.tomasz at gmail.com Mon Jul 1 16:14:16 2013 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Mon, 1 Jul 2013 16:14:16 +0200 Subject: [Development] Checking out Qt 5.0.2 sources Message-ID: Hi, Current release branch contains 5.1 version. I can't build it on mipsel(some errors with PCRE) architecture and currently don't have time to investigate it. I know that it worked with 5.0. Is there a way to get Qt 5.0.2 sources in one command? There is no 5.0.2 tag in qt/qt5 repository. Would it be enough If I manually check out all submodules to 5.0.2 tag? Or maybe lack o this tag is a bug... regards Tomasz Olszak -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Jul 1 07:42:55 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 30 Jun 2013 22:42:55 -0700 Subject: [Development] Qt5.1 new snapshot In-Reply-To: References: <87B846C5-FA88-43FE-B390-3307816AEB9E@digia.com> Message-ID: <1481897.4M2U6KdAhV@tjmaciei-mobl2> On segunda-feira, 1 de julho de 2013 05.20.10, Heikkinen Jani wrote: > The problem was that we were not able to build QtCreator with the latest > changes in the Mac environment and that's why we cannot create all packages > for RC2. After a short study it comes clear that this problem affects to > all applications using private headers. We find fix for this issue really > soon and after discussion in the Digia release team & management we made > decision to postpone the RC2 one day again because of that build > issue. Unfortunately there isn't bug report for this build break at all; > Everyone were focused to solve it. But this change fixes the issue: > https://codereview.qt-project.org/#change,60080 Thanks for the explanation. So it's as I feared: late changes to the buildsystem breaking the build. Everyone, please pay attention to the mail I sent about the release branch. We have to avoid those things. Next time, please post an email whenever there's a deviation from the agreed plan from the RT meeting. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Mon Jul 1 17:34:35 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 01 Jul 2013 08:34:35 -0700 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: <51D186FD.1030506@digia.com> References: <11162927.8vSKeZ4urK@hal> <51D186FD.1030506@digia.com> Message-ID: <2212912.dYLGM2pAiE@tjmaciei-mobl2> On segunda-feira, 1 de julho de 2013 15.41.17, Sergio Ahumada wrote: > What makes it official ? Has this been discussed ? We're shipping the files, which makes them official. If someone is using cmake, our files are the official way of building their applications for Qt 5. However, the recommended way in our documentation and examples to build Qt 5 applications remains qmake. Can we please start working on changing that? I guess it's a (hot?) topic for QtCS... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Mon Jul 1 17:42:32 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 01 Jul 2013 08:42:32 -0700 Subject: [Development] State of (old?) Qt 5.0 in Tizen IVI 1.0 ... In-Reply-To: <0A1EAF95665C44418A21392D8868D73702ED61F93F@GEO-HCLT-USEVS3.GEO.CORP.HCL.IN> References: <0A1EAF95665C44418A21392D8868D73702ED61F93F@GEO-HCLT-USEVS3.GEO.CORP.HCL.IN> Message-ID: <1628566.jQR0IDN2nG@tjmaciei-mobl2> On segunda-feira, 1 de julho de 2013 01.21.12, Carlos Gomez, HCL America wrote: > 1: How stable was this port into Tizen IVI 1.0? Unknown. Some applications ran, but I also had bug reports of things not working, like missing files when loading QML applications. > 2: Was this a "Wayland only" port? Yes. > 3: How complete was this port? I ask because I *think* I see evidence that > QtQuick 1.0 support was not included. It included only the packages you saw, and qtxmlpatterns was included only because of a dependency from qtdeclarative. The port existed in IVI because of the migration from MeeGo IVI, which included lots of QML applications and many OEMs in the segment preferred Qt. After those applications were ported to EFL and the OEMs got convinced to move on, the port was no longer needed and was dropped. I tried to maintain it for 2 months, but I failed to get things to build for me and I don't understand how Tizen's OBS / GBS works well enough. All tasks assigned to me are now closed as "won't fix" / "out of scope". In any case, Tizen 1.0 is done anyway. If you want Qt on Tizen, please watch the efforts from Tomasz Olszak, which runs on Tizen 2.1 (mobile and IVI) and should work on the upcoming 2.2 release. I'm working with them so that Qt is brought back into Tizen for 3.0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Mon Jul 1 17:44:39 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 01 Jul 2013 08:44:39 -0700 Subject: [Development] Checking out Qt 5.0.2 sources In-Reply-To: References: Message-ID: <5753802.QUpHyJpAp7@tjmaciei-mobl2> On segunda-feira, 1 de julho de 2013 16.14.16, Tomasz Olszak wrote: > Hi, > > Current release branch contains 5.1 version. > I can't build it on mipsel(some errors with PCRE) architecture and > currently don't have time to investigate it. I know that it worked with 5.0. > > Is there a way to get Qt 5.0.2 sources in one command? > There is no 5.0.2 tag in qt/qt5 repository. The tag is in the qt/qtsdk repository. Consider qt/qtsdk as a branch of qt/qt5. You can fetch all the tags into one repo: thiago at tjmaciei-mobl2 ~/src/qt/qt5 (sdk u+1) $ git tag qt-v5.0.0-alpha1 v5.0.0 v5.0.0-beta1 v5.0.0-beta2 v5.0.0-rc1 v5.0.0-rc2 v5.0.1 v5.0.1-rc1 v5.0.1-rc2 v5.0.2 v5.0.2-rc1 v5.1.0-alpha1 v5.1.0-beta1 v5.1.0-rc1 v5.1.0-rc1-packaging v5.1.0-rc2-packaging > Would it be enough If I manually check out all submodules to 5.0.2 tag? Yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From san at sansano.inf.utfsm.cl Mon Jul 1 18:18:20 2013 From: san at sansano.inf.utfsm.cl (Sergio Ahumada) Date: Mon, 01 Jul 2013 18:18:20 +0200 Subject: [Development] Checking out Qt 5.0.2 sources In-Reply-To: References: Message-ID: <51D1ABCC.8030706@sansano.inf.utfsm.cl> Hi, On 07/01/2013 04:14 PM, Tomasz Olszak wrote: > Hi, > > Current release branch contains 5.1 version. > I can't build it on mipsel(some errors with PCRE) architecture and > currently don't have time to investigate it. I know that it worked with 5.0. The released source code is available in http://download.qt-project.org/official_releases/qt/5.0/5.0.2/ > Is there a way to get Qt 5.0.2 sources in one command? > There is no 5.0.2 tag in qt/qt5 repository. You can find the v5.0.2 tag from http://qt.gitorious.org/qtsdk/qtsdk Or you could use http://qt.gitorious.org/qt/qt5 and do "git reset --hard 3f9837797d4fc5226d4f6063ee6a52b349521155", that should be the same combination of sha1s than in qtsdk but without the tag. > Would it be enough If I manually check out all submodules to 5.0.2 tag? You might need to do some magic because of the qtwebkit-examples-and-demos.git -> qtwebkit-examples.git rename. > Or maybe lack o this tag is a bug... > > regards > Tomasz Olszak Cheers, -- Sergio Ahumada san at sansano.inf.utfsm.cl From 416365416c at gmail.com Mon Jul 1 18:46:13 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Mon, 1 Jul 2013 09:46:13 -0700 Subject: [Development] PROPOSAL: merge #qt-qml and #qt-components to #qt-quick In-Reply-To: <21B12E67-E779-4F2A-8BDD-74D90F74CB56@digia.com> References: <77CBF859-2E2C-434C-AD7D-41E01B6F0616@digia.com> <21B12E67-E779-4F2A-8BDD-74D90F74CB56@digia.com> Message-ID: On Mon, Jul 1, 2013 at 7:04 AM, Nurmi J-P wrote: > Hi again, > > A new #qt-quick channel was established a couple of weeks ago, and the users of the former #qt-components were redirected to #qt-quick. Now that the dust has settled, I'd like to propose taking the next step - to merge #qt-qml to #qt-quick. > > Users are increasingly confused by the separation between the two channels, and the questions seem to be pretty mixed too. Therefore I'm still voting for having a single #qt-quick channel for Qt Quick and QML users. Time will tell whether development discussions should be kept there or not. > I'm okay with that. If we want to reclaim #qt-qml for development we can do it after all the users have switched over. Currently they just have inexplicable overlap, so one channel would be an improvement. -- Alan Alpert From thiago.macieira at intel.com Mon Jul 1 19:31:00 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 01 Jul 2013 10:31 -0700 Subject: [Development] Checking out Qt 5.0.2 sources In-Reply-To: <51D1ABCC.8030706@sansano.inf.utfsm.cl> References: <51D1ABCC.8030706@sansano.inf.utfsm.cl> Message-ID: <9355859.dhdDZOaBMn@tjmaciei-mobl2> On segunda-feira, 1 de julho de 2013 18.18.20, Sergio Ahumada wrote: > You can find the v5.0.2 tag from http://qt.gitorious.org/qtsdk/qtsdk > > Or you could use http://qt.gitorious.org/qt/qt5 and do "git reset --hard > 3f9837797d4fc5226d4f6063ee6a52b349521155", that should be the same > combination of sha1s than in qtsdk but without the tag. That reset command won't work unless you first fetch the qtsdk repository, in which case you'll get the tag too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From san at sansano.inf.utfsm.cl Mon Jul 1 19:46:51 2013 From: san at sansano.inf.utfsm.cl (Sergio Ahumada) Date: Mon, 01 Jul 2013 19:46:51 +0200 Subject: [Development] Checking out Qt 5.0.2 sources In-Reply-To: <9355859.dhdDZOaBMn@tjmaciei-mobl2> References: <51D1ABCC.8030706@sansano.inf.utfsm.cl> <9355859.dhdDZOaBMn@tjmaciei-mobl2> Message-ID: <51D1C08B.2070103@sansano.inf.utfsm.cl> On 07/01/2013 07:31 PM, Thiago Macieira wrote: > On segunda-feira, 1 de julho de 2013 18.18.20, Sergio Ahumada wrote: >> You can find the v5.0.2 tag from http://qt.gitorious.org/qtsdk/qtsdk >> >> Or you could use http://qt.gitorious.org/qt/qt5 and do "git reset --hard >> 3f9837797d4fc5226d4f6063ee6a52b349521155", that should be the same >> combination of sha1s than in qtsdk but without the tag. > > That reset command won't work unless you first fetch the qtsdk repository, in > which case you'll get the tag too. > That sha is not part of the qtsdk repository. It worked for me locally without fetching qtsdk, what am I am missing here ? -- Sergio Ahumada san at sansano.inf.utfsm.cl From thiago.macieira at intel.com Mon Jul 1 20:13:40 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 01 Jul 2013 11:13:40 -0700 Subject: [Development] Checking out Qt 5.0.2 sources In-Reply-To: <51D1C08B.2070103@sansano.inf.utfsm.cl> References: <9355859.dhdDZOaBMn@tjmaciei-mobl2> <51D1C08B.2070103@sansano.inf.utfsm.cl> Message-ID: <2523390.7vKv977uIe@tjmaciei-mobl2> On segunda-feira, 1 de julho de 2013 19.46.51, Sergio Ahumada wrote: > On 07/01/2013 07:31 PM, Thiago Macieira wrote: > > On segunda-feira, 1 de julho de 2013 18.18.20, Sergio Ahumada wrote: > >> You can find the v5.0.2 tag from http://qt.gitorious.org/qtsdk/qtsdk > >> > >> Or you could use http://qt.gitorious.org/qt/qt5 and do "git reset --hard > >> 3f9837797d4fc5226d4f6063ee6a52b349521155", that should be the same > >> combination of sha1s than in qtsdk but without the tag. > > > > That reset command won't work unless you first fetch the qtsdk repository, > > in which case you'll get the tag too. > > That sha is not part of the qtsdk repository. > > It worked for me locally without fetching qtsdk, what am I am missing here ? A good whack on my head... I tested if the commit was part of the branch I had currently checked out. It wasn't. Except I have the sdk/master commit checked out. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From tpham3783 at gmail.com Mon Jul 1 20:45:38 2013 From: tpham3783 at gmail.com (Toan Pham) Date: Mon, 1 Jul 2013 14:45:38 -0400 Subject: [Development] Checking out Qt 5.0.2 sources In-Reply-To: References: Message-ID: Tomasz, I want to warn you that I had to apply about 7 different patches on top of qt-5.0.2 in order to build the library from source with html5 video/audio. I feel like qt-5.0.2 is not a good development package to build from source, qt-5.1.0 is much more stable. You'll be better off fixing bugs in qt 5.1.0. -toan On Mon, Jul 1, 2013 at 10:14 AM, Tomasz Olszak wrote: > Hi, > > Current release branch contains 5.1 version. > I can't build it on mipsel(some errors with PCRE) architecture and > currently don't have time to investigate it. I know that it worked with 5.0. > > Is there a way to get Qt 5.0.2 sources in one command? > There is no 5.0.2 tag in qt/qt5 repository. > > Would it be enough If I manually check out all submodules to 5.0.2 tag? > > Or maybe lack o this tag is a bug... > > regards > Tomasz Olszak > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangelog at gmail.com Mon Jul 1 20:48:30 2013 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Mon, 1 Jul 2013 20:48:30 +0200 Subject: [Development] Checking out Qt 5.0.2 sources In-Reply-To: References: Message-ID: On 1 July 2013 16:14, Tomasz Olszak wrote: > I can't build it on mipsel(some errors with PCRE) architecture and currently > don't have time to investigate it. And, by any chance, do you have the error messages you got when building on mipsel? -- Giuseppe D'Angelo From olszak.tomasz at gmail.com Mon Jul 1 21:32:41 2013 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Mon, 1 Jul 2013 19:32:41 +0000 Subject: [Development] Checking out Qt 5.0.2 sources In-Reply-To: References: Message-ID: 2013/7/1 Giuseppe D'Angelo > On 1 July 2013 16:14, Tomasz Olszak wrote: > > I can't build it on mipsel(some errors with PCRE) architecture and > currently > > don't have time to investigate it. > > And, by any chance, do you have the error messages you got when > building on mipsel? > > -- > Giuseppe D'Angelo > Build targets are customized for different defines. Currently it doesn't build for one of them. So it is not only mipsel related but rather DEFINES/QMAKE_CLFLAGS related. Now I am not able to paste error, I will investigate it tomorrow and send an update. However in my opinion using older Qt version than current one should be a little bot more systemized. I asked about it few months ago in http://lists.qt-project.org/pipermail/development/2013-March/010438.html when I analysed qt-project workflow for adopting it in different project and noticed that this case was not covered. regards Tomasz Olszak -------------- next part -------------- An HTML attachment was scrubbed... URL: From casimiro.listas at gmail.com Mon Jul 1 22:11:13 2013 From: casimiro.listas at gmail.com (Caio Casimiro) Date: Mon, 1 Jul 2013 17:11:13 -0300 Subject: [Development] gstreamer 1.0 support on Qt 5.0.1 Message-ID: Hello all, I have seen on the page with the new features for Qt 5.1.0 that gstreamer 1.0 will be supported on Qt Webkit: http://qt-project.org/wiki/New-Features-in-Qt-5.1 I would like to know if there will be support for gstreamer 1.0 on Qt Multimedia as well. Best regards, Casimiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From 416365416c at gmail.com Mon Jul 1 22:16:37 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Mon, 1 Jul 2013 13:16:37 -0700 Subject: [Development] Handling specific platform events in Qt In-Reply-To: <51D15CC4.4030104@digia.com> References: <51CD6436.5030000@digia.com> <51D15CC4.4030104@digia.com> Message-ID: On Mon, Jul 1, 2013 at 3:41 AM, Tor Arne Vestbø wrote: > On 6/28/13 18:59 , Alan Alpert wrote: >> >> This should be accessible via Qt.application.active (false if >> paused/minimized or otherwise not visible). > > > Qt.application.active binds to a window having keyboard activation, AFAIK, > which may or may not correspond to also being visible/in front, and vice > versa. I don't think so. There's a Window.active property for that, and since we're supporting multi-window Qt.application.active should be referring to global application state. -- Alan Alpert From olszak.tomasz at gmail.com Mon Jul 1 22:29:05 2013 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Mon, 1 Jul 2013 20:29:05 +0000 Subject: [Development] Handling specific platform events in Qt In-Reply-To: References: <51CD6436.5030000@digia.com> <51D15CC4.4030104@digia.com> Message-ID: 2013/7/1 Alan Alpert <416365416c at gmail.com> > On Mon, Jul 1, 2013 at 3:41 AM, Tor Arne Vestbø > wrote: > > On 6/28/13 18:59 , Alan Alpert wrote: > >> > >> This should be accessible via Qt.application.active (false if > >> paused/minimized or otherwise not visible). > > > > > > Qt.application.active binds to a window having keyboard activation, > AFAIK, > > which may or may not correspond to also being visible/in front, and vice > > versa. > > I don't think so. There's a Window.active property for that, and since > we're supporting multi-window Qt.application.active should be > referring to global application state. > > -- > Alan Alpert > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > And currently it is enough for Tizen. However if we consider case in which ApplicationInactive and ApplicationSuspended should be handled differently on QML side then we can't resolve it with current solution. -- regards / pozdrawiam, Tomasz Olszak -------------- next part -------------- An HTML attachment was scrubbed... URL: From michal.lazo at mdragon.org Tue Jul 2 08:20:36 2013 From: michal.lazo at mdragon.org (Michal Lazo) Date: Tue, 2 Jul 2013 08:20:36 +0200 Subject: [Development] gstreamer 1.0 support on Qt 5.0.1 In-Reply-To: References: Message-ID: http://qt-project.org/forums/viewthread/21995 On Mon, Jul 1, 2013 at 10:11 PM, Caio Casimiro wrote: > Hello all, > > I have seen on the page with the new features for Qt 5.1.0 that gstreamer > 1.0 will be supported on Qt Webkit: > http://qt-project.org/wiki/New-Features-in-Qt-5.1 > > I would like to know if there will be support for gstreamer 1.0 on Qt > Multimedia as well. > > Best regards, > Casimiro > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- Best Regards Michal Lazo Senior developer manager mdragon.org Slovakia -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hanne.Linaae at digia.com Tue Jul 2 09:25:34 2013 From: Hanne.Linaae at digia.com (Linaae Hanne) Date: Tue, 2 Jul 2013 07:25:34 +0000 Subject: [Development] New features in Qt 5.1 In-Reply-To: <515AAE5C.7030405@digia.com> References: <515AAE5C.7030405@digia.com> Message-ID: <52C96968-6569-41DB-8455-B4E992767AFA@digia.com> Hi, Since the Qt 5.1 release is getting close, it would be great if all involved can take the time *today* to go through this wiki page again, and make sure it is up to date. http://qt-project.org/wiki/New-Features-in-Qt-5.1 Thanks, Hanne ---- Hanne Linaae Digia, Qt On Apr 2, 2013, at 12:09 PM, Sergio Ahumada wrote: > Hi, > > Since we are doing some preparations for Qt 5.1 release, it would be > nice to have some work done in advance, so we've created a wiki page > that we would like to use to gather all the new features in Qt 5.1 > > So, if you have added a new feature, please feel free to fill up the > wiki page and/or fix it if you find errors. > > http://qt-project.org/wiki/New-Features-in-Qt-5.1 > > Cheers, > -- > Sergio Ahumada > Release Engineer - Digia, Qt > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Gunnar.Sletta at digia.com Tue Jul 2 09:46:16 2013 From: Gunnar.Sletta at digia.com (Sletta Gunnar) Date: Tue, 2 Jul 2013 07:46:16 +0000 Subject: [Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders In-Reply-To: References: <98F45B99-00A4-49A9-814B-C7CD57398390@digia.com>, Message-ID: <8B3D8EDA-0284-4B6B-A2D5-952406E06D57@digia.com> The ApplicationWindow encapsulates a completely different concept compared to normal items and trying to treat them as the same in the design tool makes very little sense. The ApplicationWindow floats stand alone in the windowing system, it may have menu bar, status bar and toolbar, all of which require dedicated support from the designer to be designable. And the code generated does not go into a QQuickView, but needs to be created as via QQmlComponent::create() as it creates the window itself. If we want that and if there is time and resources to do it is a different topic. I think we can live without it, at least for while. cheers, Gunnar On Jul 1, 2013, at 11:56 AM, Bubke Marco wrote: > > Alan Alpert: > The items-in-a-scene is an implementation detail (albeit one of the > biggest ones), but if you can provide a better implementation for the > existing APIs then that would be ideal. If not, we need to start > considering trade-offs instead, and maybe these other use-cases are > not as important as the application running with high performance > on-device. The initial usecases were not MDI, and were not even > multi-window. We aren't going to throw in extra abstraction layers for > a "potential future". It's much better to maintain flexibility to be > able to add abstractions later on, even though abstractions are > easiest to implement at the start. One of the hopes for the QML-only > API of QtQuick is that we are only restricted by QML versioning > (separate from Qt versioning), and this gives us more flexibility. > > If we implement it new I would opt for a approach where a item would have something like a property isApplicationWindow. This item would be than wrapped in a Window. I think MDI would be possible too with this approach. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Thomas.Hartmann at digia.com Tue Jul 2 10:26:24 2013 From: Thomas.Hartmann at digia.com (Thomas Hartmann) Date: Tue, 2 Jul 2013 10:26:24 +0200 Subject: [Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders In-Reply-To: <8B3D8EDA-0284-4B6B-A2D5-952406E06D57@digia.com> References: <98F45B99-00A4-49A9-814B-C7CD57398390@digia.com>, <8B3D8EDA-0284-4B6B-A2D5-952406E06D57@digia.com> Message-ID: <51D28EB0.9070502@digia.com> Hi, the "problem" is that the ApplicationWindow/Window contains a contentItem and redirects the default property to this contentItem. This means Window looks and behaves like an Item when it comes to adding children and even anchoring. Therefore we have to treat it like an item for most cases like reparenting or anchoring, but not in all cases like states or deeper in the stack: painting. We have to live with the current solution anyway, but there would have been alternatives like: ApplicationWindowItem { applicationWindow.menuBar: Menu { } applicationWindow.statusBar: StatusBar { } applicationWindow.toolBar: ToolBar { } } In this case from the C++ side not too much would change, but the ContentItem would own the Window. There is still a one to one relationship from the ContentItem to the Window and there would be litte difference between ApplicationWindowItem and our current ApplicationWindow other then the fact that ApplicationWindowItem really is the contentItem not just redirects its default property. Note that ApplicationWindowItem would support states out of the box. If you look at it from a prototype based inheritance view it might get clearer. When using prototype based inheritance an x is an y if it behaves like an y (No static class hierarchies). In the ApplicationWindow case it behaves like an y in many cases, because of the default property redirected to an Item. Actually if treated as a fixed/static root item it behaves in all cases like an Item, except when it comes to states. Therefore I think it would have made sense to turn ApplicationWindow into a full blown y/Item (Than cannot be the child of another Item, though). This is the pure QML view. I do understand that from the C++ perspective Window is quite special, because it holds its own QtQuickView. From the tooling perspective this means that we have to deal with ApplicationWindow/Window in many places since it behaves like a normal root Item and can be the target of anchors, while there is always a level of indirection to the contentItem. In the case that the contentItem would have been explicit: ApplicationWindow { menuBar: Menu { } statusBar: StatusBar { } toolBar: ToolBar { } contentItem: Item { } } we could at least "skip/ignore" the ApplicationWindow for all code that handles anchors, transformations etc, because we are only interested in the contentItem. Kind Regards, Thomas Hartmann Am 02/07/2013 09:46, schrieb Sletta Gunnar: > The ApplicationWindow encapsulates a completely different concept compared to normal items and trying to treat them as the same in the design tool makes very little sense. > > The ApplicationWindow floats stand alone in the windowing system, it may have menu bar, status bar and toolbar, all of which require dedicated support from the designer to be designable. And the code generated does not go into a QQuickView, but needs to be created as via QQmlComponent::create() as it creates the window itself. > > If we want that and if there is time and resources to do it is a different topic. I think we can live without it, at least for while. > > cheers, > Gunnar > > On Jul 1, 2013, at 11:56 AM, Bubke Marco wrote: > >> >> Alan Alpert: >> The items-in-a-scene is an implementation detail (albeit one of the >> biggest ones), but if you can provide a better implementation for the >> existing APIs then that would be ideal. If not, we need to start >> considering trade-offs instead, and maybe these other use-cases are >> not as important as the application running with high performance >> on-device. The initial usecases were not MDI, and were not even >> multi-window. We aren't going to throw in extra abstraction layers for >> a "potential future". It's much better to maintain flexibility to be >> able to add abstractions later on, even though abstractions are >> easiest to implement at the start. One of the hopes for the QML-only >> API of QtQuick is that we are only restricted by QML versioning >> (separate from Qt versioning), and this gives us more flexibility. >> >> If we implement it new I would opt for a approach where a item would have something like a property isApplicationWindow. This item would be than wrapped in a Window. I think MDI would be possible too with this approach. >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Thomas Hartmann Software Engineer Nokia, Qt Development Frameworks Digia Germany GmbH Rudower Chausse 13, 12489 D-Berlin Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B, Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Email: thomas.hartmann at digia.com Digia Germany is a group company of Digia Plc, Valimotie 21, FI-00380 Helsinki Finland Visit us at: www.digia.com ------------------------------------------------------------------ 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 Germany GmbH and Digia Plc do not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. From Simon.Hausmann at digia.com Tue Jul 2 10:59:53 2013 From: Simon.Hausmann at digia.com (Hausmann Simon) Date: Tue, 2 Jul 2013 08:59:53 +0000 Subject: [Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders In-Reply-To: <51D28EB0.9070502@digia.com> References: <98F45B99-00A4-49A9-814B-C7CD57398390@digia.com>, <8B3D8EDA-0284-4B6B-A2D5-952406E06D57@digia.com>, <51D28EB0.9070502@digia.com> Message-ID: <9160F3295FA8E24781968BBD40362991AF2269@IT-EXMB01-HKI.it.local> Hi, I think API wise it was the right decision to make the content item the default property, because unlike the menubar or the toolbar it is not optional. And therefore every user of ApplicationWindow would have to specify it every time, which is pretty annoying. The lack of default items is what annoys me the most about for example the Qt 4 based cascades API, it requires writing what feels redundant QML code. Simon ________________________________________ From: development-bounces+simon.hausmann=digia.com at qt-project.org [development-bounces+simon.hausmann=digia.com at qt-project.org] on behalf of Thomas Hartmann [Thomas.Hartmann at digia.com] Sent: Tuesday, July 02, 2013 10:26 To: development at qt-project.org Subject: Re: [Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders Hi, the "problem" is that the ApplicationWindow/Window contains a contentItem and redirects the default property to this contentItem. This means Window looks and behaves like an Item when it comes to adding children and even anchoring. Therefore we have to treat it like an item for most cases like reparenting or anchoring, but not in all cases like states or deeper in the stack: painting. We have to live with the current solution anyway, but there would have been alternatives like: ApplicationWindowItem { applicationWindow.menuBar: Menu { } applicationWindow.statusBar: StatusBar { } applicationWindow.toolBar: ToolBar { } } In this case from the C++ side not too much would change, but the ContentItem would own the Window. There is still a one to one relationship from the ContentItem to the Window and there would be litte difference between ApplicationWindowItem and our current ApplicationWindow other then the fact that ApplicationWindowItem really is the contentItem not just redirects its default property. Note that ApplicationWindowItem would support states out of the box. If you look at it from a prototype based inheritance view it might get clearer. When using prototype based inheritance an x is an y if it behaves like an y (No static class hierarchies). In the ApplicationWindow case it behaves like an y in many cases, because of the default property redirected to an Item. Actually if treated as a fixed/static root item it behaves in all cases like an Item, except when it comes to states. Therefore I think it would have made sense to turn ApplicationWindow into a full blown y/Item (Than cannot be the child of another Item, though). This is the pure QML view. I do understand that from the C++ perspective Window is quite special, because it holds its own QtQuickView. From the tooling perspective this means that we have to deal with ApplicationWindow/Window in many places since it behaves like a normal root Item and can be the target of anchors, while there is always a level of indirection to the contentItem. In the case that the contentItem would have been explicit: ApplicationWindow { menuBar: Menu { } statusBar: StatusBar { } toolBar: ToolBar { } contentItem: Item { } } we could at least "skip/ignore" the ApplicationWindow for all code that handles anchors, transformations etc, because we are only interested in the contentItem. Kind Regards, Thomas Hartmann Am 02/07/2013 09:46, schrieb Sletta Gunnar: > The ApplicationWindow encapsulates a completely different concept compared to normal items and trying to treat them as the same in the design tool makes very little sense. > > The ApplicationWindow floats stand alone in the windowing system, it may have menu bar, status bar and toolbar, all of which require dedicated support from the designer to be designable. And the code generated does not go into a QQuickView, but needs to be created as via QQmlComponent::create() as it creates the window itself. > > If we want that and if there is time and resources to do it is a different topic. I think we can live without it, at least for while. > > cheers, > Gunnar > > On Jul 1, 2013, at 11:56 AM, Bubke Marco wrote: > >> >> Alan Alpert: >> The items-in-a-scene is an implementation detail (albeit one of the >> biggest ones), but if you can provide a better implementation for the >> existing APIs then that would be ideal. If not, we need to start >> considering trade-offs instead, and maybe these other use-cases are >> not as important as the application running with high performance >> on-device. The initial usecases were not MDI, and were not even >> multi-window. We aren't going to throw in extra abstraction layers for >> a "potential future". It's much better to maintain flexibility to be >> able to add abstractions later on, even though abstractions are >> easiest to implement at the start. One of the hopes for the QML-only >> API of QtQuick is that we are only restricted by QML versioning >> (separate from Qt versioning), and this gives us more flexibility. >> >> If we implement it new I would opt for a approach where a item would have something like a property isApplicationWindow. This item would be than wrapped in a Window. I think MDI would be possible too with this approach. >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Thomas Hartmann Software Engineer Nokia, Qt Development Frameworks Digia Germany GmbH Rudower Chausse 13, 12489 D-Berlin Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B, Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Email: thomas.hartmann at digia.com Digia Germany is a group company of Digia Plc, Valimotie 21, FI-00380 Helsinki Finland Visit us at: www.digia.com ------------------------------------------------------------------ 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 Germany GmbH and Digia Plc do not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From announce at qt-project.org Tue Jul 2 11:09:09 2013 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Tue, 2 Jul 2013 09:09:09 +0000 Subject: [Development] [Announce] Qt 4.8.5 released Message-ID: <8EE30B3F13F8C042BFFAD90938B94A6F4D920457@IT-EXMB02-HKI.it.local> We are happy to announce that Qt 4.8.5 is released today. Blog post: http://blog.qt.digia.com/blog/2013/07/02/qt-4-8-5-released/ Download: http://qt-project.org/downloads/ for the open source and http://qt.digia.com/Log-in-Customer-Portal/ for Qt Enterprise. -- Akseli Salovaara Digia, Qt _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From Marco.Bubke at digia.com Tue Jul 2 11:42:10 2013 From: Marco.Bubke at digia.com (Bubke Marco) Date: Tue, 2 Jul 2013 09:42:10 +0000 Subject: [Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders In-Reply-To: <8B3D8EDA-0284-4B6B-A2D5-952406E06D57@digia.com> References: <98F45B99-00A4-49A9-814B-C7CD57398390@digia.com>, , <8B3D8EDA-0284-4B6B-A2D5-952406E06D57@digia.com> Message-ID: Hi Gunnar Gunnar Sletta: The ApplicationWindow encapsulates a completely different concept compared to normal items and trying to treat them as the same in the design tool makes very little sense. Is sense, logic not very context depend? I think our argument network, which is designer centric, is different from yours, which is run time centric. Like I have written ApplicationWindow is a hybrid of a window and a item but it is not a item in the sense of duck typing. It is different and that is hurting us. And for the menus you don't need a WYSIWYG editor. The ApplicationWindow floats stand alone in the windowing system, it may have menu bar, status bar and toolbar, all of which require dedicated support from the designer to be designable. And the code generated does not go into a QQuickView, but needs to be created as via QQmlComponent::create() as it creates the window itself. Actually what is the advantage to have the menu bar, status bar and toolbar designable? And we do not create the items from text because we need more control over them. I don't want to argument about that again and again. ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Tue Jul 2 12:51:52 2013 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 02 Jul 2013 12:51:52 +0200 Subject: [Development] Moc with clang. Message-ID: <3539784.nK4Z8kfYf4@gargamel> Hi, For those who do not read planetqt.org, I would like to mention here that I have experimented to re-implement the moc (MetaObject Compiler) using liblang as a parser. The blog post say it all: http://woboq.com/blog/moc-with-clang.html It is really promising. But I don't think it can replace moc because having a dependency on libclang is probably not something we want to have in Qt. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From tor.arne.vestbo at digia.com Tue Jul 2 13:17:42 2013 From: tor.arne.vestbo at digia.com (=?ISO-8859-1?Q?Tor_Arne_Vestb=F8?=) Date: Tue, 2 Jul 2013 13:17:42 +0200 Subject: [Development] Moc with clang. In-Reply-To: <3539784.nK4Z8kfYf4@gargamel> References: <3539784.nK4Z8kfYf4@gargamel> Message-ID: <51D2B6D6.3080003@digia.com> This is awesome! :) On 7/2/13 12:51 , Olivier Goffart wrote: > Hi, > > For those who do not read planetqt.org, I would like to mention here that I > have experimented to re-implement the moc (MetaObject Compiler) using liblang > as a parser. > > The blog post say it all: http://woboq.com/blog/moc-with-clang.html > > It is really promising. But I don't think it can replace moc because having a > dependency on libclang is probably not something we want to have in Qt. > From olszak.tomasz at gmail.com Tue Jul 2 14:11:14 2013 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Tue, 2 Jul 2013 14:11:14 +0200 Subject: [Development] Checking out Qt 5.0.2 sources In-Reply-To: References: Message-ID: 2013/7/1 Tomasz Olszak > > > 2013/7/1 Giuseppe D'Angelo > >> On 1 July 2013 16:14, Tomasz Olszak wrote: >> > I can't build it on mipsel(some errors with PCRE) architecture and >> currently >> > don't have time to investigate it. >> >> And, by any chance, do you have the error messages you got when >> building on mipsel? >> >> -- >> Giuseppe D'Angelo >> > > Build targets are customized for different defines. Currently it doesn't > build for one of them. So it is not only mipsel related but rather > DEFINES/QMAKE_CLFLAGS related. > Now I am not able to paste error, I will investigate it tomorrow and send > an update. > > However in my opinion using older Qt version than current one should be a > little bot more systemized. I asked about it few months ago in > http://lists.qt-project.org/pipermail/development/2013-March/010438.html when > I analysed qt-project workflow for adopting it in different project and > noticed that this case was not covered. > > regards > Tomasz Olszak > So tried once again with 5.1. Problem was related to -std=c99 flag: zak/workspace/rootfs/BCM97356/include -I/home/user/workspace/rootfs/BCM97356/usr/include -I. -o .obj/release-shared/pcre16_jit_compile.o /home/user/workspace/qt5Release/qtbase/src/3rdparty/pcre/pcre16_jit_compile.c In file included from /home/user/workspace/qt5Release/qtbase/src/3rdparty/pcre/sljit/sljitLir.c:1339:0, from /home/user/workspace/qt5Release/qtbase/src/3rdparty/pcre/pcre_jit_compile.c:62, from /home/user/workspace/qt5Release/qtbase/src/3rdparty/pcre/pcre16_jit_compile.c:43: /home/user/workspace/qt5Release/qtbase/src/3rdparty/pcre/sljit/sljitNativeMIPS_common.c: In function 'sljit_cache_flush': /home/user/workspace/qt5Release/qtbase/src/3rdparty/pcre/sljit/sljitNativeMIPS_common.c:293:2: warning: implicit declaration of function '__clear_cache' In file included from /home/user/workspace/qt5Release/qtbase/src/3rdparty/pcre/sljit/sljitLir.c:1339:0, from /home/user/workspace/qt5Release/qtbase/src/3rdparty/pcre/pcre_jit_compile.c:62, from /home/user/workspace/qt5Release/qtbase/src/3rdparty/pcre/pcre16_jit_compile.c:43: /home/user/workspace/qt5Release/qtbase/src/3rdparty/pcre/sljit/sljitNativeMIPS_common.c: In function 'sljit_is_fpu_available': /home/user/workspace/qt5Release/qtbase/src/3rdparty/pcre/sljit/sljitNativeMIPS_common.c:1123:2: warning: implicit declaration of function 'asm' /home/user/workspace/qt5Release/qtbase/src/3rdparty/pcre/sljit/sljitNativeMIPS_common.c:1123:21: error: expected ')' before ':' token make[3]: *** [.obj/release-shared/pcre16_jit_compile.o] Błąd 1 I added QMAKE_CFLAGS+= -std=gnu99 (for using asm function in PCRE) QMAKE_CXXFLAGS += -std=c++98 and it now compiles. As an excuse I would like to inform that sysroot I am working with is VERY inconsistent... forget about adding /include /usr/include /lib /usr/lib There are tens of different paths and defines. So I built some examplary appllication with platform makefile based build system and copied includepaths, defines and compiler flags from make VERBOSE=1 command to qmake.conf. It compiled. In the end however I have encounter: https://bugreports.qt-project.org/browse/QTBUG-31817#comment-208125 I made some investigation and currently qtjsbackend is broken on mips architecture. v8 need to be updated(see my comment in mentioned task). -- regards / pozdrawiam, Tomasz Olszak Qt for Tizen | http://qt-project.org/wiki/Tizen Qt Certified Developer | http://qt-project.org http://linkedin.com/in/tolszak -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpapp at kde.org Tue Jul 2 14:35:19 2013 From: lpapp at kde.org (Laszlo Papp) Date: Tue, 2 Jul 2013 12:35:19 +0000 Subject: [Development] [request] Creation a new QtSerialPort component into a Qt bug tracker In-Reply-To: References: <201306261259.22940.daniel.teske@digia.com> Message-ID: Unfortunately, I have no access rights to edit "Serial Port" related bugs. Would it be possible to fix that? On Wed, Jun 26, 2013 at 11:18 AM, Laszlo Papp wrote: > Many thanks. :) > > > On Wed, Jun 26, 2013 at 2:05 PM, Knoll Lars wrote: > >> On 26.06.13 12:59, "Daniel Teske" wrote: >> >> >On Wednesday 26 Jun 2013 09:04:26 Knoll Lars wrote: >> >> I can do that, but I can unfortunately not migrate the open bugs to the >> >>new >> >> component (as I can't migrate across Jira projects). You'd have to >> >>create >> >> a new report for each of the open bugs in the Jira Qt project. If >> you're >> >> ok with that I'll remove the serial port component in the playground >> >> project. >> >Actually that's easy to do with jira so I just moved all 31 bug reports >> >to the >> >new component. >> >> Didn't find that. You'll need to show me the trick at some point :) >> >> Anyway, I now deleted the old serial port component in playground. >> >> Cheers, >> Lars >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at digia.com Tue Jul 2 14:44:56 2013 From: Lars.Knoll at digia.com (Knoll Lars) Date: Tue, 2 Jul 2013 12:44:56 +0000 Subject: [Development] [request] Creation a new QtSerialPort component into a Qt bug tracker In-Reply-To: Message-ID: Should be fixed now. Cheers, Lars On 7/2/13 2:35 PM, "Laszlo Papp" wrote: >Unfortunately, I have no access rights to edit "Serial Port" related >bugs. Would it be possible to fix that? > > > >On Wed, Jun 26, 2013 at 11:18 AM, Laszlo Papp wrote: > >Many thanks. :) > > >On Wed, Jun 26, 2013 at 2:05 PM, Knoll Lars wrote: > >On 26.06.13 12:59, "Daniel Teske" wrote: > >>On Wednesday 26 Jun 2013 09:04:26 Knoll Lars wrote: >>> I can do that, but I can unfortunately not migrate the open bugs to the >>>new >>> component (as I can't migrate across Jira projects). You'd have to >>>create >>> a new report for each of the open bugs in the Jira Qt project. If >>>you're >>> ok with that I'll remove the serial port component in the playground >>> project. >>Actually that's easy to do with jira so I just moved all 31 bug reports >>to the >>new component. > > >Didn't find that. You'll need to show me the trick at some point :) > >Anyway, I now deleted the old serial port component in playground. > >Cheers, >Lars > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development > > > > > > > > > > > > > > From lpapp at kde.org Tue Jul 2 15:04:35 2013 From: lpapp at kde.org (Laszlo Papp) Date: Tue, 2 Jul 2013 13:04:35 +0000 Subject: [Development] Moc with clang. In-Reply-To: <3539784.nK4Z8kfYf4@gargamel> References: <3539784.nK4Z8kfYf4@gargamel> Message-ID: On Tue, Jul 2, 2013 at 10:51 AM, Olivier Goffart wrote: > Hi, > > For those who do not read planetqt.org, I would like to mention here that > I > have experimented to re-implement the moc (MetaObject Compiler) using > liblang > as a parser. > > The blog post say it all: http://woboq.com/blog/moc-with-clang.html > I have to admit, even though I read this back then, you have interesting experiments published on your blog. This is not the first one. I recall the C++ way of property binding. It is nice to read these. :-) It is really promising. But I don't think it can replace moc because having > a > dependency on libclang is probably not something we want to have in Qt. So, it could not be even optional because clang is not mature enough on Windows, and in other scenarios or there is any other reason? Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpapp at kde.org Tue Jul 2 15:05:17 2013 From: lpapp at kde.org (Laszlo Papp) Date: Tue, 2 Jul 2013 13:05:17 +0000 Subject: [Development] [request] Creation a new QtSerialPort component into a Qt bug tracker In-Reply-To: References: Message-ID: Thanks again! On Tue, Jul 2, 2013 at 12:44 PM, Knoll Lars wrote: > Should be fixed now. > > Cheers, > Lars > > On 7/2/13 2:35 PM, "Laszlo Papp" wrote: > > >Unfortunately, I have no access rights to edit "Serial Port" related > >bugs. Would it be possible to fix that? > > > > > > > >On Wed, Jun 26, 2013 at 11:18 AM, Laszlo Papp wrote: > > > >Many thanks. :) > > > > > >On Wed, Jun 26, 2013 at 2:05 PM, Knoll Lars wrote: > > > >On 26.06.13 12:59, "Daniel Teske" wrote: > > > >>On Wednesday 26 Jun 2013 09:04:26 Knoll Lars wrote: > >>> I can do that, but I can unfortunately not migrate the open bugs to the > >>>new > >>> component (as I can't migrate across Jira projects). You'd have to > >>>create > >>> a new report for each of the open bugs in the Jira Qt project. If > >>>you're > >>> ok with that I'll remove the serial port component in the playground > >>> project. > >>Actually that's easy to do with jira so I just moved all 31 bug reports > >>to the > >>new component. > > > > > >Didn't find that. You'll need to show me the trick at some point :) > > > >Anyway, I now deleted the old serial port component in playground. > > > >Cheers, > >Lars > > > >_______________________________________________ > >Development mailing list > >Development at qt-project.org > >http://lists.qt-project.org/mailman/listinfo/development > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Jul 2 17:14:56 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 Jul 2013 08:14:56 -0700 Subject: [Development] Checking out Qt 5.0.2 sources In-Reply-To: References: Message-ID: <1900239.NtIvzURIpi@tjmaciei-mobl2> On terça-feira, 2 de julho de 2013 14.11.14, Tomasz Olszak wrote: > warning: implicit declaration of function 'asm' It should be __asm__ Anyway, I don't think we pass a -std=c99 flag to the compiler. That doesn't appear anywhere in my sources. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Tue Jul 2 17:15:41 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 Jul 2013 08:15:41 -0700 Subject: [Development] Checking out Qt 5.0.2 sources In-Reply-To: References: Message-ID: <2075197.A3bcdUTWPg@tjmaciei-mobl2> On terça-feira, 2 de julho de 2013 14.11.14, Tomasz Olszak wrote: > In the end however I have encounter: > https://bugreports.qt-project.org/browse/QTBUG-31817#comment-208125 > > I made some investigation and currently qtjsbackend is broken on mips > architecture. v8 need to be updated(see my comment in mentioned task). Forget V8 and focus on making sure that the new V4VM engine works. That is, you should be trying dev of qtdeclarative, not stable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From annulen at yandex.ru Tue Jul 2 17:24:35 2013 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 02 Jul 2013 19:24:35 +0400 Subject: [Development] Moc with clang. In-Reply-To: References: <3539784.nK4Z8kfYf4@gargamel> Message-ID: <22971372778675@web6d.yandex.ru> 02.07.2013, 17:04, "Laszlo Papp" : > On Tue, Jul 2, 2013 at 10:51 AM, Olivier Goffart wrote: >> Hi, >> >> For those who do not read planetqt.org, I would like to mention here that I >> have experimented to re-implement the moc (MetaObject Compiler) using liblang >> as a parser. >> >> The blog post say it all:  http://woboq.com/blog/moc-with-clang.html > > I have to admit, even though I read this back then, you have interesting experiments published on your blog. This is not the first one. I recall the C++ way of property binding. It is nice to read these. :-) > >> It is really promising. But I don't think it can replace moc because having a >> dependency on libclang is probably not something we want to have in Qt. > > So, it could not be even optional because clang is not mature enough on Windows, and in other scenarios or there is any other reason? Clang is quite mature on Windows, at least when used as C++ parser. -- Regards, Konstantin From lpapp at kde.org Tue Jul 2 18:05:33 2013 From: lpapp at kde.org (Laszlo Papp) Date: Tue, 2 Jul 2013 16:05:33 +0000 Subject: [Development] Moc with clang. In-Reply-To: <22971372778675@web6d.yandex.ru> References: <3539784.nK4Z8kfYf4@gargamel> <22971372778675@web6d.yandex.ru> Message-ID: On Tue, Jul 2, 2013 at 3:24 PM, Konstantin Tokarev wrote: > > So, it could not be even optional because clang is not mature enough on > Windows, and in other scenarios or there is any other reason? > > Clang is quite mature on Windows, at least when used as C++ parser. > Why I thought that was because I do not see pre-built Windows clang binaries for the latest version, and even before that, it had been marked as "Experimental". Not sure about 64 bit, debug, openmp (few projects still use that, yeah), other scenarios, et cetera. Perhaps, if you build it yourself, it might work, but still. :-) Cheers, Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From cmeyer1969+qt at gmail.com Tue Jul 2 23:45:43 2013 From: cmeyer1969+qt at gmail.com (Chris Meyer) Date: Tue, 2 Jul 2013 14:45:43 -0700 Subject: [Development] QWidget::createWindowContainer and keyboard focus issues Message-ID: I've been doing testing with Qt 5.1.0rc2. My application mixes QWidgets and Qml. I've been using QWidget::createWindowContainer which I don't think it's ready for release. I've encountered numerous keyboard focus issues that make QWidget::createWindowContainer difficult to use and I haven't been able to find workarounds. Particularly, on Mac, switching to another application and back causes the embedded Qml widget to lose focus and there doesn't seem to be a way to get it back. (QTBUG-32175). On Windows, the QApplication::activeWindow() returns NULL if the embedded Qml widget has focus (QTBUG-32177) and QMenu shortcuts don't work if Qml has focus (QTBUG-32180). There are several other bugs reported by others that are similar in seriousness and nature to these. Finally, a general comment on the design of QWidget::createWindowContainer: Since it is a factory, there is no way to override or extend the behavior of the widget it returns. That's annoying when encountering bugs like the ones above. Why a factory method here instead of an extendable / overridable class? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpapp at kde.org Wed Jul 3 12:12:48 2013 From: lpapp at kde.org (Laszlo Papp) Date: Wed, 3 Jul 2013 10:12:48 +0000 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: <51D18DE0.5070709@digia.com> References: <11162927.8vSKeZ4urK@hal> <51D186FD.1030506@digia.com> <51D18DE0.5070709@digia.com> Message-ID: On Mon, Jul 1, 2013 at 2:10 PM, Tor Arne Vestbø wrote: > There is also the question of platform support. Is cmake as relevant on > Windows or OSX as it is on Linux? More so? > Not sure what exactly you mean by relevant, but cmake is a *cross*-*platform *, open-source build system. It has been used on Windows and OS X extensively out there for a while. Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From tor.arne.vestbo at digia.com Wed Jul 3 12:28:58 2013 From: tor.arne.vestbo at digia.com (=?ISO-8859-1?Q?Tor_Arne_Vestb=F8?=) Date: Wed, 3 Jul 2013 12:28:58 +0200 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: References: <11162927.8vSKeZ4urK@hal> <51D186FD.1030506@digia.com> <51D18DE0.5070709@digia.com> Message-ID: <51D3FCEA.5060103@digia.com> On 7/3/13 12:12 , Laszlo Papp wrote: > On Mon, Jul 1, 2013 at 2:10 PM, Tor Arne Vestbø > > wrote: > > There is also the question of platform support. Is cmake as relevant on > Windows or OSX as it is on Linux? More so? > > > Not sure what exactly you mean by relevant, but cmake is a > /cross/-/platform/, open-source build system. It has been used on > Windows and OS X extensively out there for a while. Relevant for Qt. What percentage of Qt developers develop on Windows? Out of those, what percentage use cmake over qmake? At some point the cost of maintaining (blocking CI integration e.g.) a build system (or any feature) that has a low relevance on a given platform becomes higher than the benefit. tor arne From lpapp at kde.org Wed Jul 3 13:04:08 2013 From: lpapp at kde.org (Laszlo Papp) Date: Wed, 3 Jul 2013 11:04:08 +0000 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: <51D3FCEA.5060103@digia.com> References: <11162927.8vSKeZ4urK@hal> <51D186FD.1030506@digia.com> <51D18DE0.5070709@digia.com> <51D3FCEA.5060103@digia.com> Message-ID: On Wed, Jul 3, 2013 at 10:28 AM, Tor Arne Vestbø wrote: > On 7/3/13 12:12 , Laszlo Papp wrote: > >> On Mon, Jul 1, 2013 at 2:10 PM, Tor Arne Vestbø >> >> >> wrote: >> >> There is also the question of platform support. Is cmake as relevant >> on >> Windows or OSX as it is on Linux? More so? >> >> >> Not sure what exactly you mean by relevant, but cmake is a >> /cross/-/platform/, open-source build system. It has been used on >> >> Windows and OS X extensively out there for a while. >> > > Relevant for Qt. > > What percentage of Qt developers develop on Windows? > Out of those, what percentage use cmake over qmake? > > At some point the cost of maintaining (blocking CI integration e.g.) a > build system (or any feature) that has a low relevance on a given platform > becomes higher than the benefit. > > tor arne > Still not exactly sure what you mean by "Qt developers". People working on or with Qt? :) I can mention a few projects working _with_ Qt and for whom, Stephen's work might be appealing: 1) KDE Windows. As you may already know, KDE is a relatively large project around Qt. 2) I had several Windows clients as well using Qt in their projects while using cmake. 3) Quassel is also using cmake for instance if I recall correctly. 4) I came across a lot of mobile application developers in the Harmattan, Blackberry, and so forth communities who were using cmake, and then later they ported their applications to desktop as well, including Windows. 5) There are tons of C++ software projects out there, who have been using cmake, and will probably utilize Qt more and more. 6) etc. There is a fairly large portion in my humble, but a bit biased opinion. :-) Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mingw.android at gmail.com Wed Jul 3 13:07:40 2013 From: mingw.android at gmail.com (Ray Donnelly) Date: Wed, 3 Jul 2013 12:07:40 +0100 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: <51D3FCEA.5060103@digia.com> References: <11162927.8vSKeZ4urK@hal> <51D186FD.1030506@digia.com> <51D18DE0.5070709@digia.com> <51D3FCEA.5060103@digia.com> Message-ID: > Relevant for Qt Since Qt is an application framework, I think relevant for Qt implies "relevant for Qt and any project that uses it". IMHO the goal should be to fully support build systems to the extent they work on each platform or dropping that build system. CI'ing weird corner-case builds is important as they tend to catch more issues than vanilla builds do (and that most developers also likely run); ideally you'd have full coverage. On Wed, Jul 3, 2013 at 11:28 AM, Tor Arne Vestbø wrote: > On 7/3/13 12:12 , Laszlo Papp wrote: > > On Mon, Jul 1, 2013 at 2:10 PM, Tor Arne Vestbø > > > wrote: > > > > There is also the question of platform support. Is cmake as relevant > on > > Windows or OSX as it is on Linux? More so? > > > > > > Not sure what exactly you mean by relevant, but cmake is a > > /cross/-/platform/, open-source build system. It has been used on > > Windows and OS X extensively out there for a while. > > Relevant for Qt. > > What percentage of Qt developers develop on Windows? > Out of those, what percentage use cmake over qmake? > > At some point the cost of maintaining (blocking CI integration e.g.) a > build system (or any feature) that has a low relevance on a given > platform becomes higher than the benefit. > > tor arne > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tr3w at freemail.hu Wed Jul 3 13:12:02 2013 From: tr3w at freemail.hu (Tr3wory) Date: Wed, 3 Jul 2013 13:12:02 +0200 Subject: [Development] Moc with clang. In-Reply-To: References: <3539784.nK4Z8kfYf4@gargamel> <22971372778675@web6d.yandex.ru> Message-ID: Maturity of clang on windows is a little complicated: First you can use 2 ABI: gcc/mingw or msvc. As far as I know the first is kind of working while the second has serious issues. Also the libc++ std library implementation has issues on windows, while the libstdc++ (from mingw 4.8) works. But this is about the clang used as a full compiler. If you use only the libclang as a c++ parser, then it's as good as everywhere else. And the moc-ng used as a drop in replacement of moc use only this. (Using as a clang plugin is a different story.) tr3w On Tue, Jul 2, 2013 at 6:05 PM, Laszlo Papp wrote: > On Tue, Jul 2, 2013 at 3:24 PM, Konstantin Tokarev > wrote: >> >> > So, it could not be even optional because clang is not mature enough on >> > Windows, and in other scenarios or there is any other reason? >> >> Clang is quite mature on Windows, at least when used as C++ parser. > > > Why I thought that was because I do not see pre-built Windows clang binaries > for the latest version, and even before that, it had been marked as > "Experimental". Not sure about 64 bit, debug, openmp (few projects still use > that, yeah), other scenarios, et cetera. > > Perhaps, if you build it yourself, it might work, but still. :-) > > Cheers, > Laszlo > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From pgquiles at elpauer.org Wed Jul 3 13:17:12 2013 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Wed, 3 Jul 2013 13:17:12 +0200 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: <51D3FCEA.5060103@digia.com> References: <11162927.8vSKeZ4urK@hal> <51D186FD.1030506@digia.com> <51D18DE0.5070709@digia.com> <51D3FCEA.5060103@digia.com> Message-ID: On Wed, Jul 3, 2013 at 12:28 PM, Tor Arne Vestbø wrote: What percentage of Qt developers develop on Windows? > Significant. Even when developing only for Windows, using Qt over Visual C++ makes worlds of difference. And it's not only Windows, it's also the cross-build features CMake provides (still not up to autotools but getting closer) Out of those, what percentage use cmake over qmake? > Any project which depends on pre-built third-party libraries is better off with CMake over QMake thanks to features such as find_package. If the project is cross-platform, more so. In fact, even if the third-party libraries are not pre-built but will be built as part of the project you are working on, CMake provides ExternalProject which makes it easy to automatically download (optional) and build those third-parties. I don't know whether qbs is making any progress in regards to find_package or ExternalProject but for us those features have become ESSENTIAL in a build system for any non-toy application. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpapp at kde.org Wed Jul 3 13:31:41 2013 From: lpapp at kde.org (Laszlo Papp) Date: Wed, 3 Jul 2013 11:31:41 +0000 Subject: [Development] Moc with clang. In-Reply-To: References: <3539784.nK4Z8kfYf4@gargamel> <22971372778675@web6d.yandex.ru> Message-ID: It is really strange then they do not provide "mature" installers for the mature parts. On Wed, Jul 3, 2013 at 11:12 AM, Tr3wory wrote: > Maturity of clang on windows is a little complicated: > First you can use 2 ABI: gcc/mingw or msvc. > As far as I know the first is kind of working while the second has > serious issues. > > Also the libc++ std library implementation has issues on windows, > while the libstdc++ (from mingw 4.8) works. > > But this is about the clang used as a full compiler. > > If you use only the libclang as a c++ parser, then it's as good as > everywhere else. And the moc-ng used as a drop in replacement of moc > use only this. (Using as a clang plugin is a different story.) > > tr3w > > On Tue, Jul 2, 2013 at 6:05 PM, Laszlo Papp wrote: > > On Tue, Jul 2, 2013 at 3:24 PM, Konstantin Tokarev > > wrote: > >> > >> > So, it could not be even optional because clang is not mature enough > on > >> > Windows, and in other scenarios or there is any other reason? > >> > >> Clang is quite mature on Windows, at least when used as C++ parser. > > > > > > Why I thought that was because I do not see pre-built Windows clang > binaries > > for the latest version, and even before that, it had been marked as > > "Experimental". Not sure about 64 bit, debug, openmp (few projects still > use > > that, yeah), other scenarios, et cetera. > > > > Perhaps, if you build it yourself, it might work, but still. :-) > > > > Cheers, > > Laszlo > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joerg.bornemann at digia.com Wed Jul 3 13:32:24 2013 From: joerg.bornemann at digia.com (Joerg Bornemann) Date: Wed, 3 Jul 2013 13:32:24 +0200 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: References: <11162927.8vSKeZ4urK@hal> <51D186FD.1030506@digia.com> <51D18DE0.5070709@digia.com> <51D3FCEA.5060103@digia.com> Message-ID: <51D40BC8.6090004@digia.com> On 03/07/2013 13:17, Pau Garcia i Quiles wrote: > I don't know whether qbs is making any progress in regards to > find_package or ExternalProject but for us those features have become > ESSENTIAL in a build system for any non-toy application. Cmake's find_package feature is similar to qbs' module system. ExternalProject features like downloading sources or checking out from repos are not supported yet. BR, Joerg -- Joerg Bornemann Digia, Qt http://qt.digia.com/ From mingw.android at gmail.com Wed Jul 3 13:53:46 2013 From: mingw.android at gmail.com (Ray Donnelly) Date: Wed, 3 Jul 2013 12:53:46 +0100 Subject: [Development] Moc with clang. In-Reply-To: References: <3539784.nK4Z8kfYf4@gargamel> <22971372778675@web6d.yandex.ru> Message-ID: If a project releases binary packages for a given OS, but they aren't able to make binaries for the latest version and if the latest release for that OS is marked experimental, then that fits my definition of "not mature". Also, not having 64bit doesn't point to much maturity (nor does forcing fixed installation paths on any system - last time I checked clang was like this). On Wed, Jul 3, 2013 at 12:31 PM, Laszlo Papp wrote: > It is really strange then they do not provide "mature" installers for the > mature parts. > > > On Wed, Jul 3, 2013 at 11:12 AM, Tr3wory wrote: > >> Maturity of clang on windows is a little complicated: >> First you can use 2 ABI: gcc/mingw or msvc. >> As far as I know the first is kind of working while the second has >> serious issues. >> >> Also the libc++ std library implementation has issues on windows, >> while the libstdc++ (from mingw 4.8) works. >> >> But this is about the clang used as a full compiler. >> >> If you use only the libclang as a c++ parser, then it's as good as >> everywhere else. And the moc-ng used as a drop in replacement of moc >> use only this. (Using as a clang plugin is a different story.) >> >> tr3w >> >> On Tue, Jul 2, 2013 at 6:05 PM, Laszlo Papp wrote: >> > On Tue, Jul 2, 2013 at 3:24 PM, Konstantin Tokarev >> > wrote: >> >> >> >> > So, it could not be even optional because clang is not mature enough >> on >> >> > Windows, and in other scenarios or there is any other reason? >> >> >> >> Clang is quite mature on Windows, at least when used as C++ parser. >> > >> > >> > Why I thought that was because I do not see pre-built Windows clang >> binaries >> > for the latest version, and even before that, it had been marked as >> > "Experimental". Not sure about 64 bit, debug, openmp (few projects >> still use >> > that, yeah), other scenarios, et cetera. >> > >> > Perhaps, if you build it yourself, it might work, but still. :-) >> > >> > Cheers, >> > Laszlo >> > >> > _______________________________________________ >> > Development mailing list >> > Development at qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/development >> > >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From announce at qt-project.org Wed Jul 3 14:29:44 2013 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 3 Jul 2013 12:29:44 +0000 Subject: [Development] [Announce] Qt 5.1 released Message-ID: Hi, I'm happy to announce that Qt 5.1 has been released. For more details have a look at the Qt 5.1 landing page and my blog post: http://qt-project.org/qt5/qt51 http://blog.qt.digia.com/blog/2013/07/03/qt-5-1-released/ Thanks go to everybody who has helped make the release happen! Cheers, Lars _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From yves.bailly at sescoi.fr Wed Jul 3 14:51:19 2013 From: yves.bailly at sescoi.fr (Yves Bailly) Date: Wed, 03 Jul 2013 14:51:19 +0200 Subject: [Development] [Announce] Qt 5.1 released In-Reply-To: References: Message-ID: <51D41E47.5040701@sescoi.fr> Hello, Le 03/07/2013 14:29, List for announcements regarding Qt releases and development a écrit : > I'm happy to announce that Qt 5.1 has been released. First of all, congratulations and a great thank for all this wonderful work. > For more details have a look at the Qt 5.1 landing page and my blog post: > > http://qt-project.org/qt5/qt51 > http://blog.qt.digia.com/blog/2013/07/03/qt-5-1-released/ Reading the section "New reference installers" and the download links from http://qt-project.org/downloads, it seems there's no MSVC2012 32bits OpenGL binaries available. Are there any plans to provide them in the future? Best regards, -- /- Yves Bailly - Software developer -\ \- Sescoi R&D - http://www.sescoi.fr -/ "The possible is done. The impossible is being done. For miracles, thanks to allow a little delay." From Lars.Knoll at digia.com Wed Jul 3 16:04:15 2013 From: Lars.Knoll at digia.com (Knoll Lars) Date: Wed, 3 Jul 2013 14:04:15 +0000 Subject: [Development] Checking out Qt 5.0.2 sources In-Reply-To: <2075197.A3bcdUTWPg@tjmaciei-mobl2> Message-ID: On 02.07.13 17:15, "Thiago Macieira" wrote: >On terça-feira, 2 de julho de 2013 14.11.14, Tomasz Olszak wrote: >> In the end however I have encounter: >> https://bugreports.qt-project.org/browse/QTBUG-31817#comment-208125 >> >> I made some investigation and currently qtjsbackend is broken on mips >> architecture. v8 need to be updated(see my comment in mentioned task). > >Forget V8 and focus on making sure that the new V4VM engine works. That >is, >you should be trying dev of qtdeclarative, not stable. Actually dev doesn't (yet) have v4vm and still relies on v8. We're getting very close to merging, but aren't quite there yet. If you want to try the new QML engine using v4vm, checkout the wip/v4 branch in qtdeclararative. Cheers, Lars From olszak.tomasz at gmail.com Wed Jul 3 16:21:27 2013 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Wed, 3 Jul 2013 16:21:27 +0200 Subject: [Development] Checking out Qt 5.0.2 sources In-Reply-To: References: <2075197.A3bcdUTWPg@tjmaciei-mobl2> Message-ID: 2013/7/3 Knoll Lars > On 02.07.13 17:15, "Thiago Macieira" wrote: > > >On terça-feira, 2 de julho de 2013 14.11.14, Tomasz Olszak wrote: > >> In the end however I have encounter: > >> https://bugreports.qt-project.org/browse/QTBUG-31817#comment-208125 > >> > >> I made some investigation and currently qtjsbackend is broken on mips > >> architecture. v8 need to be updated(see my comment in mentioned task). > > > >Forget V8 and focus on making sure that the new V4VM engine works. That > >is, > >you should be trying dev of qtdeclarative, not stable. > > Actually dev doesn't (yet) have v4vm and still relies on v8. We're getting > very close to merging, but aren't quite there yet. If you want to try the > new QML engine using v4vm, checkout the wip/v4 branch in qtdeclararative. > > Cheers, > Lars > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > I will definitely try v4 out. However currently there is no possibility of using QtQuick 2.1 on mips architecture and if V8 will not be updated then one should wait until 5.2. I doubt that he will use v4 even after merging it to dev or stable in release version of his apps. -- regards / pozdrawiam, Tomasz Olszak -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Jul 3 17:46:09 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 Jul 2013 08:46:09 -0700 Subject: [Development] Moc with clang. In-Reply-To: References: <3539784.nK4Z8kfYf4@gargamel> Message-ID: <47341734.5YRvrRDHbz@tjmaciei-mobl2> On quarta-feira, 3 de julho de 2013 13.12.02, Tr3wory wrote: > Also the libc++ std library implementation has issues on windows, libc++ isn't meant to work outside of OS X. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Wed Jul 3 18:00:25 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 Jul 2013 09:00:25 -0700 Subject: [Development] Fwd: Icon-theme-spec update for scaled icons Message-ID: <1614754.5fJBUz9aBY@tjmaciei-mobl2> Have we implemented hidpi for QIcon::fromTheme? If so, does it match the proposal? If not, would this proposal work? ---------- Forwarded message ---------- Subject: Icon-theme-spec update for scaled icons Date: terça-feira, 2 de julho de 2013, 15.51.46 From: Alexander Larsson Para: xdg at lists.freedesktop.org I've been working on adding support for HiDPI screens. Part of it has landed in wayland already, some is work-in-progress in Gtk+. Generally how this work is that on very high resolution monitors we "scale" the UI so that code works in the old "low dpi" pixels, but we then render it with a scaling factor. For icons we can't just scale as that would not look very nice, so instead we need to supply alternative higher resolution data. Things kind of work already, like you can pick 96x96 icons when rendering 48x48 icons at scale 2. However, in many cases the larger icons have a lot more detail that don't really look very well when rendering at the higher scale. For instance some sort icons have text in them which is very hard to read, or borders become really thin. So, attached to the mail is a patch to the icon theme spec that adds a "Scale" property to the icon directories. With this one could have icons for size "48" in both scale 1 and 2. ----------------------------------------- -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-icon-theme-spec-Add-icon-scale-support.patch Type: text/x-patch Size: 11089 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From mingw.android at gmail.com Wed Jul 3 18:03:11 2013 From: mingw.android at gmail.com (Ray Donnelly) Date: Wed, 3 Jul 2013 17:03:11 +0100 Subject: [Development] Moc with clang. In-Reply-To: <47341734.5YRvrRDHbz@tjmaciei-mobl2> References: <3539784.nK4Z8kfYf4@gargamel> <47341734.5YRvrRDHbz@tjmaciei-mobl2> Message-ID: Someone should tell Google who have recently ported it to Android. On Wed, Jul 3, 2013 at 4:46 PM, Thiago Macieira wrote: > On quarta-feira, 3 de julho de 2013 13.12.02, Tr3wory wrote: > > Also the libc++ std library implementation has issues on windows, > > libc++ isn't meant to work outside of OS X. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tr3w at freemail.hu Wed Jul 3 18:05:30 2013 From: tr3w at freemail.hu (Tr3wory) Date: Wed, 3 Jul 2013 18:05:30 +0200 Subject: [Development] Moc with clang. In-Reply-To: <47341734.5YRvrRDHbz@tjmaciei-mobl2> References: <3539784.nK4Z8kfYf4@gargamel> <47341734.5YRvrRDHbz@tjmaciei-mobl2> Message-ID: http://libcxx.llvm.org: "Current Status [...] Ports to other platforms are underway. Here are recent test results for Windows and Linux." Probably it's not top priority but it's not out of scope. tr3w On Wed, Jul 3, 2013 at 5:46 PM, Thiago Macieira wrote: > On quarta-feira, 3 de julho de 2013 13.12.02, Tr3wory wrote: >> Also the libc++ std library implementation has issues on windows, > > libc++ isn't meant to work outside of OS X. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From 416365416c at gmail.com Wed Jul 3 21:29:51 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 3 Jul 2013 12:29:51 -0700 Subject: [Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders In-Reply-To: References: <98F45B99-00A4-49A9-814B-C7CD57398390@digia.com> <8B3D8EDA-0284-4B6B-A2D5-952406E06D57@digia.com> Message-ID: On Tue, Jul 2, 2013 at 2:42 AM, Bubke Marco wrote: > Hi Gunnar > > >> Gunnar Sletta: >> >> The ApplicationWindow encapsulates a completely different concept compared >> to normal items and trying to treat them as the same in the design tool >> makes very little sense. > > Is sense, logic not very context depend? I think our argument network, which > is designer centric, is different from yours, which is run time centric. > Like I have written ApplicationWindow is a hybrid of a window and a item but > it is not a item in the sense of duck typing. It is different and that is > hurting us. And for the menus you don't need a WYSIWYG editor. The thing is that we have a lot of lofty goals we're trying to accomplish here, one of which is to guide the designer-centric viewpoint to match the run-time-centric view. If they diverge then we run into all sorts of problems, tooling may be the one we're looking at now but performance was the original inspiration. Window {} is not supposed to be thought of as an Item, even in the designer-centric viewpoint, and if we fumbled that then we should try to fix it. One complication is that we're trying to reuse Item concepts to make Window easier to use, which may have only exacerbated the understanding problem. >> The ApplicationWindow floats stand alone in the windowing system, it may >> have menu bar, status bar and toolbar, all of which require dedicated >> support from the designer to be designable. And the code generated does not >> go into a QQuickView, but needs to be created as via QQmlComponent::create() >> as it creates the window itself. > > Actually what is the advantage to have the menu bar, status bar and toolbar > designable? And we do not create the items from text because we need more > control over them. I don't want to argument about that again and > again. ;-) > I think by designable this just means feature parity with the old Qt Designer. Since Qt Quick came at UIs from a different angle we can already do tons of stuff designer could not, but we're still catching up with what it could do. -- Alan Alpert From 416365416c at gmail.com Wed Jul 3 21:47:35 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 3 Jul 2013 12:47:35 -0700 Subject: [Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders In-Reply-To: <51D28EB0.9070502@digia.com> References: <98F45B99-00A4-49A9-814B-C7CD57398390@digia.com> <8B3D8EDA-0284-4B6B-A2D5-952406E06D57@digia.com> <51D28EB0.9070502@digia.com> Message-ID: On Tue, Jul 2, 2013 at 1:26 AM, Thomas Hartmann wrote: > Hi, > > the "problem" is that the ApplicationWindow/Window contains a > contentItem and redirects the default property to this contentItem. > > This means Window looks and behaves like an Item when it comes to adding > children and even anchoring. Therefore we have to treat it like an item > for most cases like reparenting or anchoring, but not in all cases like > states or deeper in the stack: painting. > > We have to live with the current solution anyway, but there would have > been alternatives like: > > ApplicationWindowItem { > applicationWindow.menuBar: Menu { > } > > applicationWindow.statusBar: StatusBar { > } > > applicationWindow.toolBar: ToolBar { > } > } > > In this case from the C++ side not too much would change, but the > ContentItem would own the Window. There is still a one to one > relationship from the ContentItem to the Window and there would be litte > difference between ApplicationWindowItem and our current > ApplicationWindow other then the fact that ApplicationWindowItem really > is the contentItem not just redirects its default property. > Note that ApplicationWindowItem would support states out of the box. > > If you look at it from a prototype based inheritance view it might get > clearer. When using prototype based inheritance an x is an y if it > behaves like an y (No static class hierarchies). > > In the ApplicationWindow case it behaves like an y in many cases, > because of the default property redirected to an Item. Actually if > treated as a fixed/static root item it behaves in all cases like an > Item, except when it comes to states. Therefore I think it would have > made sense to turn ApplicationWindow into a full blown y/Item > (Than cannot be the child of another Item, though). We could add a "states" convenience property with ease. Would that be sufficient to make it a "y" in this explanation? states/transitions have nothing actually to do with Item, we just added those properties onto Item for convenience. So if it's common enough that people want to define states/transitions on a window then I see no issue with adding additional convenience. It's just a thin wrapper around the StateGroup type anyways. We do want to provide extreme convenience, like the default properties which Simon likes so much :) . ApplicationWindow is going to be a fixed root item in terms of how it's used. Most users are going to use ApplicationWindow, not Window (which is not always a fixed root item, but perhaps could be treated as such in the design mode?), so that's the case we need to fix. > This is the pure QML view. I do understand that from the C++ perspective > Window is quite special, because it holds its own QtQuickView. > > From the tooling perspective this means that we have to deal with > ApplicationWindow/Window in many places since it behaves like a normal > root Item and can be the target of anchors, while there is always a > level of indirection to the contentItem. > > In the case that the contentItem would have been explicit: > > ApplicationWindow { > menuBar: Menu { > } > > statusBar: StatusBar { > } > > toolBar: ToolBar { > } > > contentItem: Item { > } > } > > we could at least "skip/ignore" the ApplicationWindow for all code that > handles anchors, transformations etc, because we are only interested in > the contentItem. We have this same "half-hidden-content-item-redirection" in Flickable, the only difference is that Flickable is actually an Item as well. How do we solve this for anchors/transformations inside a Flickable onto the "parent"? -- Alan Alpert From jpnurmi at digia.com Wed Jul 3 21:53:33 2013 From: jpnurmi at digia.com (Nurmi J-P) Date: Wed, 3 Jul 2013 19:53:33 +0000 Subject: [Development] PROPOSAL: merge #qt-qml and #qt-components to #qt-quick In-Reply-To: References: <77CBF859-2E2C-434C-AD7D-41E01B6F0616@digia.com> <21B12E67-E779-4F2A-8BDD-74D90F74CB56@digia.com> Message-ID: On Jul 1, 2013, at 6:46 PM, Alan Alpert <416365416c at gmail.com> wrote: > On Mon, Jul 1, 2013 at 7:04 AM, Nurmi J-P wrote: >> Hi again, >> >> A new #qt-quick channel was established a couple of weeks ago, and the users of the former #qt-components were redirected to #qt-quick. Now that the dust has settled, I'd like to propose taking the next step - to merge #qt-qml to #qt-quick. >> >> Users are increasingly confused by the separation between the two channels, and the questions seem to be pretty mixed too. Therefore I'm still voting for having a single #qt-quick channel for Qt Quick and QML users. Time will tell whether development discussions should be kept there or not. >> > > I'm okay with that. If we want to reclaim #qt-qml for development we > can do it after all the users have switched over. Currently they just > have inexplicable overlap, so one channel would be an improvement. > > -- > Alan Alpert Not all users follow the mailing lists, so I've also asked from people hanging on #qt-qml. The feedback for this idea of merging with #qt-quick has been very positive. Unless someone comes up with reasonable objections, we will turn on the redirect on Monday 8th July that is one week from the proposal e-mail quoted above. -- J-P Nurmi From 416365416c at gmail.com Thu Jul 4 02:40:37 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 3 Jul 2013 17:40:37 -0700 Subject: [Development] Qt 5.2 In-Reply-To: References: Message-ID: On Tue, Jun 25, 2013 at 5:38 AM, Knoll Lars wrote: > Hi everybody, > > With Qt 5.1 is now almost done, this is probably a good time to start > thinking about Qt 5.2. There's a few things I'd like us to focus on for > 5.2, but before we get to the content let's have a short look at the time > schedule. > > Our goal should be to release 5.2 in November, so we have a bit of slack > before christmas. Unfortunately we'll also need some time to still do > feature development, so the proposal would be to aim for releasing the > alpha end of September. > > Functionality wise, I can see a couple of areas that will be worked on for > 5.2. I expect a lot of the discussions around 5.2 will happen at the > contributor summit, but here's anyway a list of things I'm already seeing: > > * new Qml engine > > See also Simon's mail from a few days ago. We're already pretty close to > merging this back into the dev branch. CI has been enabled on the v4 > branch yesterday and the final problems are being fixed. Simon or myself > will send a separate mail about it once we are ready to merge back. > > * Full Android and iOS support > > Both are expected to be fully working with 5.2. > > * Qt Quick Controls > > Add support for touch based devices > > * Add some of the former mobility modules back into the list of supported > modules > > Alex Blasche has been trying to get an overview over these modules, and is > working on prioritising things together with the people interested in > them. The exact scope of what we're aiming for here will most likely be > finalise during QtCS > > * Qt 3D > > Are we going to get this one ready in time for 5.2? > > * Qt Mac Extras and Qt Win Extras > > I hope we'll be able to add these modules to 5.2 as well. > > In addition, there's most likely a huge list of smaller features that are > being planned by different people for 5.2. It would be good if everybody > speaks up and tells us what they are planning for 5.2, so we can have a > rough overview over what's coming. > At QtCS I hope to corner a QtCore reviewer for the file selectors, and then I can integrate them into the QML engine. This is intended to work along with a new QML singleton API added to the language, with the same features as the existing singleton types you can define in C++. There are also some areas of QtQuick configuration such as flickable behavior and drag/click delays which I plan to make customizable per platform. Hopefully in a better route than custom defines in the mkspec. The qml runtime binary also is nearly done, it only just missed the boat for 5.1, so that should make it into 5.2. > Finally, I'd like to discuss deprecation of two modules for 5.2: Qt Quick > 1 and Qt OpenGL. The reason for deprecating these is that they offer older > versions of functionality/APIs and we have replacement APIs that are for > the most part better then what's being offered by these modules. In > addition, we don't have anybody actively working on these modules and > maintaining them. > > Qt Quick 1 has been superseded by Qt Quick 2 and is currently not being > maintained by anybody. The best choice is in my opinion to start > deprecating the module and focus our efforts and time on Qt Quick 2. It's already in a "done" state and only there to facilitate porting. We already had the discussion about some people still wanting a raster item set, but even for those people the correct solution would be to add a raster item set on top of QtQml. The existence of the QML1 engine in QtQuick1 guarantees that it's purely Qt4Support. So from my perspective, it was already deprecated. -- Alan Alpert From Thomas.Hartmann at digia.com Thu Jul 4 09:32:28 2013 From: Thomas.Hartmann at digia.com (Thomas Hartmann) Date: Thu, 4 Jul 2013 09:32:28 +0200 Subject: [Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders In-Reply-To: References: <98F45B99-00A4-49A9-814B-C7CD57398390@digia.com> <8B3D8EDA-0284-4B6B-A2D5-952406E06D57@digia.com> <51D28EB0.9070502@digia.com> Message-ID: <51D5250C.6000001@digia.com> Hi, > We could add a "states" convenience property with ease. Would that be > sufficient to make it a "y" in this explanation? I think this is a good idea. For the designer we could just work around it by creating a StateGroup, but I think adding a states and transitions property to ApplicationWindow makes the API more consistent. We should ask for other opinions, though. > states/transitions have nothing actually to do with Item, we just > added those properties onto Item for convenience. So if it's common > enough that people want to define states/transitions on a window then > I see no issue with adding additional convenience. It's just a thin > wrapper around the StateGroup type anyways. We do want to provide > extreme convenience, like the default properties which Simon likes so > much :) . Yes. The concept of default properties is very powerful and adds a lot of convenience. But it is also tricky sometimes, because the parent in the text QML tree is not the parent in the actual SceneGraph/Item tree any more. > ApplicationWindow is going to be a fixed root item in terms of how > it's used. Most users are going to use ApplicationWindow, not Window > (which is not always a fixed root item, but perhaps could be treated > as such in the design mode?), so that's the case we need to fix. This is what we actually do. ApplicationWindow/Window can be the root item, but nothing else in the design mode. > We have this same "half-hidden-content-item-redirection" in Flickable, > the only difference is that Flickable is actually an Item as well. How > do we solve this for anchors/transformations inside a Flickable onto > the "parent"? We track these cases by running the parent chain until we find the "actual" Item (in this case Flickable). We also do take care of transformations. There is one big issue, though. To avoid usability issues/flickering we have to know the transformation beforehand. This means we have to know the transformation before we actually reparent the item. The current solution is that we "advise" components to have a contentItem for these cases. Then we can check the transformation to the contentItem beforehand. This is how it is done for GroupBox. If there is a transformation and no contentItem is defined items will "jump" when reparented. In the near future I will collect these kind of requirements of components for the designer. Actually I only know of one other issue. Components often assume that some properties are fixed after component complete is called. While for applications this assumption is usually valid it breaks in the designer. In a way both these problems were also relevant in the widget case and are not QML specific. The widget designer also has to know about "non standard ways" to add child widgets like addWidget() and widgets also have to gracefully handle use cases which are only relevant for the designer. QWidget was lacking component complete though and the imperative C++ API implies that also normal users set properties in an unexpected order and such. While I think component complete is necessary (I even requested it back when I started to try QML), I would prefer if in the future it is used for real special cases and for all the standard cases we would rely on signal compression in the engine. About the default property alias to a contentItem, I would like to see a standard pattern, so we do not haven to tool dozens of exceptions. Hinting the content item by exposing it as either "contentItem" or "__contentItem" is a good start. Kind Regards, Thomas Hartmann From define-true-false at yandex.com Thu Jul 4 11:55:11 2013 From: define-true-false at yandex.com (Ivan Vizir) Date: Thu, 04 Jul 2013 12:55:11 +0300 Subject: [Development] QQuickPixmap and Quick plugins. Message-ID: <1244901372931711@web29f.yandex.ru> Hi, While developing QML Items for Qt Windows Extras I was faced with the task of using a URL-type properties which gave rise to some questions. First off all — is it ok to use QQuickPixmap, which is private API, in a plugin? Second one — if the answer to first question is no, which is the correct way to handle URLs to load data (for QIcons, for example) from resources (qrc:///…), network and file system? Thanks. From markg85 at gmail.com Thu Jul 4 13:37:58 2013 From: markg85 at gmail.com (Mark) Date: Thu, 4 Jul 2013 13:37:58 +0200 Subject: [Development] QQuickPixmap and Quick plugins. In-Reply-To: <1244901372931711@web29f.yandex.ru> References: <1244901372931711@web29f.yandex.ru> Message-ID: On Thu, Jul 4, 2013 at 11:55 AM, Ivan Vizir wrote: > Hi, > > While developing QML Items for Qt Windows Extras I was faced with the task of using a URL-type properties which gave rise to some questions. > > First off all — is it ok to use QQuickPixmap, which is private API, in a plugin? Don't know, can't tell. > > Second one — if the answer to first question is no, which is the correct way to handle URLs to load data (for QIcons, for example) from resources (qrc:///…), network and file system? The "right" way to expose your custom images in any way you want is by using [1]. If i'm wrong i hope someone will correct me on this :) As far as i know, this is the recommended way to do it. [1] http://qt-project.org/doc/qt-5.1/qtquick/qquickimageprovider.html > > Thanks. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jpnurmi at digia.com Thu Jul 4 14:53:50 2013 From: jpnurmi at digia.com (Nurmi J-P) Date: Thu, 4 Jul 2013 12:53:50 +0000 Subject: [Development] Settings API for QML In-Reply-To: <4739AA4F-5268-4ADB-926F-4752EB39DDE1@digia.com> References: <50C75B8F.8050008@familiesomers.nl> <96526296-78E7-47B1-AB1F-64807B79466A@digia.com> <1843006.POohb1FX8h@rhea> <66BFFE861C7DE34D9B0372D8EAAB18E2A2DAD7@IT-EXMB01-HKI.it.local> <4BA188C112EE2C49AACEB40BB06DF7D73B2624@IT-EXMB01-HKI.it.local> <51C4C48D.8010405@gmail.com>, <4739AA4F-5268-4ADB-926F-4752EB39DDE1@digia.com> Message-ID: On Jun 22, 2013, at 12:16 PM, Nurmi J-P wrote: > > On Jun 22, 2013, at 9:02 AM, Hausmann Simon wrote: > >> You're right, the language extension can be totally separate from settings at the moment. It makes indeed most sense to land things in pieces like you proposed. >> >> Simon >> >> Alan Alpert <416365416c at gmail.com> wrote: >> >> >> On Fri, Jun 21, 2013 at 2:24 PM, Jeremy Katz wrote: >>> On 06/21/2013 09:58 AM, Hausmann Simon wrote: >>>> Hi, >>>> >>>> I like this, but as a next step I think it would be good to get rid of the manual JS code for saving. >>>> >>>> What about a general syntax of annotating properties? Then settings could be implemented on top by introspecting for properties annotated with settings tags and then save/restore then. >> >> My biggest concern about that approach right now is the scope of the >> change. We can't back out language features as easily as we can a >> module. >> >> I'd approve adding a Qt.labs.settings element, with the API specified >> by JP, because it gives us what we need and is the most easily >> changeable. If we get to annotating properties, we drop the >> Qt.labs.settings element (after a period of deprecation). We can play >> around with the backend so long as the QML API works, because while a >> consistent and reliable on disk format is important for a complete >> API, for a labs module I'm happy with just the QML API while we figure >> out other implementation details. >> >> The need for this feature seems great enough that people are willing >> to sacrifice some of the important details in order to get the basic >> functionality available to QML now (5.2). >> >>> I feel like discussion of what this is for has taken a secondary >>> position to syntax and implementation details. >> >> I feel that the "why" discussion was already solved. The "how" is >> coming up again because it's the sticking point. Here's my >> understanding of what's needed: >> >>> * Is access limited to the application, shared (system wide or multiple >>> scopes?), or both? >> >> Application (although in a more usable format than QtQuick.LocalStorage) >> >>> * If shared, does an application receive notification of external >>> updates? >>> >>> * If shared, does an application have control over when changes are >>> propagated? >>> >>> * Is this targeting a designated storage format, or system (plugin?) >>> implementation defined? >> >> No. The storage format is one of the biggest sticking points because >> QSettings has no friends anymore. But that's not really useful for the >> usecase (given that it is not intended for shared settings). >> >>> * Is the storage meant to be usable by non-Qt applications? >>> >>> * Is the storage hierarchical? >>> >>> >>> To some degree, all of these have been discussed. Have any conclusions >>> been reached, or are we waiting for a decision by implementation? >> >> There are unanswered questions about the implementation, but usually >> having something that works trumps those whether we're waiting or not >> ;). >> > > > As Alan clarified, the proposal is to provide a stopgap solution via the labs module. > > I think we all agree that it's currently unnecessarily tedious for QML application developers to bake their own persistent settings solutions. Personally I've done it so far in quite a few QML apps using either QSettings in C++ or LocalStorage in QML. > > While QSettings has its flaws and limitations, it can handle the main use case (simple persistent settings backend without notifications, bells and whistles) just fine. IMHO it's a matter of documenting the limitations and stating clearly that it's not a full-blown publish and subscribe system. Furthermore, keeping the API minimal and QSettings-agnostic might even make it possible to port it over to the mighty new settings system once someone implements it. :) > > -- > J-P Nurmi > Hi, By using property aliases the syntax becomes actually quite neat: import QtQuick.Window 2.1 import Qt.labs.settings 1.0 Window { id: window width: 800 height: 600 Settings { category: "window" property alias x: window.x property alias y: window.y property alias width: window.width property alias height: window.height } } Fully declarative, and it just... works. Props to Jens for the awesome idea! :) The initial values can be specified (width, height) or left out (x, y). Settings will be automatically stored when the values change (done lazily, a batch of resize/move events in the above example triggers only one change to QSettings). Now I'd like to invite interested parties to review https://codereview.qt-project.org/#change,59149. -- J-P Nurmi From robin+qt at viroteck.net Thu Jul 4 15:34:38 2013 From: robin+qt at viroteck.net (Robin Burchell) Date: Thu, 4 Jul 2013 15:34:38 +0200 Subject: [Development] Reenabling builds of kmap2qmap (for evdevkeyboard) Message-ID: Hi, a5b2aa0ae8f9fc5b73f0c3f3f01a5c1f1d8119ed in qttools removed the build of kmap2qmap entirely. While I agree with the premise (that 'embedded' isn't really a seperate target in Qt anymore), I don't agree with the outcome (that kmap2qmap now requires custom building) given that qmap files are still required in evdevkeyboard. Does anyone have a really strong feeling about keeping it not built by default? Or can I just unconditionally add it to src.pro? It shouldn't result in any noticable increase in build time, as it's a quite self-contained thing. BR, Robin From yves.bailly at sescoi.fr Thu Jul 4 16:05:50 2013 From: yves.bailly at sescoi.fr (Yves Bailly) Date: Thu, 04 Jul 2013 16:05:50 +0200 Subject: [Development] [Announce] Qt 5.1 released In-Reply-To: References: Message-ID: <51D5813E.3050302@sescoi.fr> Hello, (re-sending as it seems the previous has not passed through) Le 03/07/2013 14:29, List for announcements regarding Qt releases and development a écrit : > I'm happy to announce that Qt 5.1 has been released. First of all, congratulations and a great thank for all this wonderful work. > For more details have a look at the Qt 5.1 landing page and my blog post: > > http://qt-project.org/qt5/qt51 > http://blog.qt.digia.com/blog/2013/07/03/qt-5-1-released/ Reading the section "New reference installers" and the download links from http://qt-project.org/downloads, it seems there's no MSVC2012 32bits OpenGL binaries available, but only ANGLE-based binaries. Are there any plans to provide them in the future? Best regards, -- /- Yves Bailly - Software developer -\ \- Sescoi R&D - http://www.sescoi.fr -/ "The possible is done. The impossible is being done. For miracles, thanks to allow a little delay." From markg85 at gmail.com Thu Jul 4 16:17:10 2013 From: markg85 at gmail.com (Mark) Date: Thu, 4 Jul 2013 16:17:10 +0200 Subject: [Development] [Interest] [Announce] Qt 5.1 released In-Reply-To: <51D5813E.3050302@sescoi.fr> References: <51D5813E.3050302@sescoi.fr> Message-ID: On Thu, Jul 4, 2013 at 4:05 PM, Yves Bailly wrote: > Hello, > > (re-sending as it seems the previous has not passed through) > > Le 03/07/2013 14:29, List for announcements regarding Qt releases and development a écrit : >> I'm happy to announce that Qt 5.1 has been released. > > First of all, congratulations and a great thank for all this wonderful work. > >> For more details have a look at the Qt 5.1 landing page and my blog post: >> >> http://qt-project.org/qt5/qt51 >> http://blog.qt.digia.com/blog/2013/07/03/qt-5-1-released/ > > Reading the section "New reference installers" and the download links from > http://qt-project.org/downloads, it seems there's no MSVC2012 32bits OpenGL > binaries available, but only ANGLE-based binaries. > > Are there any plans to provide them in the future? That's probably a typo in the download page since the actual download link does contain opengl in it [1]. [1] http://download.qt-project.org/official_releases/qt/5.1/5.1.0/qt-windows-opensource-5.1.0-mingw48_opengl-x86-offline.exe > > Best regards, > > -- > /- Yves Bailly - Software developer -\ > \- Sescoi R&D - http://www.sescoi.fr -/ > "The possible is done. The impossible is being done. For miracles, > thanks to allow a little delay." > _______________________________________________ > Interest mailing list > Interest at qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest From yves.bailly at sescoi.fr Thu Jul 4 16:26:37 2013 From: yves.bailly at sescoi.fr (Yves Bailly) Date: Thu, 04 Jul 2013 16:26:37 +0200 Subject: [Development] [Interest] [Announce] Qt 5.1 released In-Reply-To: References: <51D5813E.3050302@sescoi.fr> Message-ID: <51D5861D.5090504@sescoi.fr> Le 04/07/2013 16:17, Mark a écrit : > On Thu, Jul 4, 2013 at 4:05 PM, Yves Bailly wrote: > [...] >> Reading the section "New reference installers" and the download links from >> http://qt-project.org/downloads, it seems there's no MSVC2012 32bits OpenGL >> binaries available, but only ANGLE-based binaries. >> >> Are there any plans to provide them in the future? > > That's probably a typo in the download page since the actual download > link does contain opengl in it [1]. > > [1] http://download.qt-project.org/official_releases/qt/5.1/5.1.0/qt-windows-opensource-5.1.0-mingw48_opengl-x86-offline.exe However the link you provide used MinGW, not MSVC2012... -- /- Yves Bailly - Software developer -\ \- Sescoi R&D - http://www.sescoi.fr -/ "The possible is done. The impossible is being done. For miracles, thanks to allow a little delay." From markg85 at gmail.com Thu Jul 4 16:34:54 2013 From: markg85 at gmail.com (Mark) Date: Thu, 4 Jul 2013 16:34:54 +0200 Subject: [Development] [Interest] [Announce] Qt 5.1 released In-Reply-To: <51D5861D.5090504@sescoi.fr> References: <51D5813E.3050302@sescoi.fr> <51D5861D.5090504@sescoi.fr> Message-ID: On Thu, Jul 4, 2013 at 4:26 PM, Yves Bailly wrote: > Le 04/07/2013 16:17, Mark a écrit : >> On Thu, Jul 4, 2013 at 4:05 PM, Yves Bailly wrote: >> [...] >>> Reading the section "New reference installers" and the download links from >>> http://qt-project.org/downloads, it seems there's no MSVC2012 32bits OpenGL >>> binaries available, but only ANGLE-based binaries. >>> >>> Are there any plans to provide them in the future? >> >> That's probably a typo in the download page since the actual download >> link does contain opengl in it [1]. >> >> [1] http://download.qt-project.org/official_releases/qt/5.1/5.1.0/qt-windows-opensource-5.1.0-mingw48_opengl-x86-offline.exe > > However the link you provide used MinGW, not MSVC2012... Oops :p Guess i found a typo then ;) From 416365416c at gmail.com Thu Jul 4 20:26:26 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 4 Jul 2013 11:26:26 -0700 Subject: [Development] QQuickPixmap and Quick plugins. In-Reply-To: References: <1244901372931711@web29f.yandex.ru> Message-ID: On Thu, Jul 4, 2013 at 4:37 AM, Mark wrote: > On Thu, Jul 4, 2013 at 11:55 AM, Ivan Vizir > wrote: >> Hi, >> >> While developing QML Items for Qt Windows Extras I was faced with the task of using a URL-type properties which gave rise to some questions. >> >> First off all — is it ok to use QQuickPixmap, which is private API, in a plugin? There is actually a bit of a known issue. QQuickImageProvider is the correct way to bring custom image data to an image, but if you're rendering a custom item which wants to use image providers you can't currently because QQuickPixmap is private (and so you should not use it). I'm considering making it public because it's essential for this usecase. > > Don't know, can't tell. >> >> Second one — if the answer to first question is no, which is the correct way to handle URLs to load data (for QIcons, for example) from resources (qrc:///…), network and file system? > > The "right" way to expose your custom images in any way you want is by > using [1]. > If i'm wrong i hope someone will correct me on this :) As far as i > know, this is the recommended way to do it. > > [1] http://qt-project.org/doc/qt-5.1/qtquick/qquickimageprovider.html If you instead meant that you've gotten a URL from QML and need to load it, in a network transparent way, what we usually do is check the scheme for file: or qrc:. If it's either of those we load it directly with QFile, otherwise we use the http://qt-project.org/doc/qt-5.1/qtqml/qqmlengine.html#networkAccessManager function to get a QNetworkAccessManager which can be used to fetch data from network sources as well as custom URLs. Except image providers... -- Alan Alpert From szehowe.koh at gmail.com Fri Jul 5 03:06:29 2013 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Fri, 5 Jul 2013 09:06:29 +0800 Subject: [Development] [Interest] [Announce] Qt 5.1 released In-Reply-To: References: <51D5813E.3050302@sescoi.fr> <51D5861D.5090504@sescoi.fr> Message-ID: Good find, Mark. Forwarding the typo to the Web mailing list. The MinGW package is labelled "Qt 5.1.0 for Windows 32-bit (MinGW 4.8, 666 MB)", but the filename is qt-windows-opensource-5.1.0-mingw48_opengl-x86-offline.exe -- one of them is wrong. On a related note, would it be helpful for newcomers if ANGLE-based packages to explicitly labelled as such? After all, ANGLE is the odd one out -- everything else uses OpenGL. Qt 5.1.0 for Windows 32-bit (MinGW 4.8, ANGLE, xxx MB) Qt 5.1.0 for Windows 32-bit (MinGW 4.8, OpenGL, xxx MB) Regards, Sze-Howe On 4 July 2013 22:34, Mark wrote: > > >> That's probably a typo in the download page since the actual download > >> link does contain opengl in it [1]. > >> > >> [1] http://download.qt-project.org/official_releases/qt/5.1/5.1.0/qt-windows-opensource-5.1.0-mingw48_opengl-x86-offline.exe [...] > Guess i found a typo then ;) From jake.petroules at petroules.com Fri Jul 5 04:52:54 2013 From: jake.petroules at petroules.com (Jake Thomas Petroules) Date: Thu, 4 Jul 2013 22:52:54 -0400 Subject: [Development] [Interest] [Announce] Qt 5.1 released In-Reply-To: References: <51D5813E.3050302@sescoi.fr> <51D5861D.5090504@sescoi.fr> Message-ID: Personally I still think it would be far more logical to delegate the ANGLE vs OpenGL decision to runtime, by including plugins for both backends with all Windows distributions. Having different packages seems to confuse a lot of Qt developers and complicates deployment matters, whereas a plugin based approach would solve these issues and also give end users the option to try a different graphics backend if the current one isn't working out for them. Many game engines do this, so why shouldn't Qt also be able to? -- Jake Petroules Chief Technology Officer Petroules Corporation · www.petroules.com Email: jake.petroules at petroules.com On Jul 4, 2013, at 9:06 PM, Sze Howe Koh wrote: > Good find, Mark. Forwarding the typo to the Web mailing list. > > The MinGW package is labelled "Qt 5.1.0 for Windows 32-bit (MinGW 4.8, > 666 MB)", but the filename is > qt-windows-opensource-5.1.0-mingw48_opengl-x86-offline.exe -- one of > them is wrong. > > On a related note, would it be helpful for newcomers if ANGLE-based > packages to explicitly labelled as such? After all, ANGLE is the odd > one out -- everything else uses OpenGL. > > Qt 5.1.0 for Windows 32-bit (MinGW 4.8, ANGLE, xxx MB) > Qt 5.1.0 for Windows 32-bit (MinGW 4.8, OpenGL, xxx MB) > > > Regards, > Sze-Howe > > On 4 July 2013 22:34, Mark wrote: >> >>>> That's probably a typo in the download page since the actual download >>>> link does contain opengl in it [1]. >>>> >>>> [1] http://download.qt-project.org/official_releases/qt/5.1/5.1.0/qt-windows-opensource-5.1.0-mingw48_opengl-x86-offline.exe > > [...] > >> Guess i found a typo then ;) > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From yves.bailly at sescoi.fr Fri Jul 5 08:03:27 2013 From: yves.bailly at sescoi.fr (Yves Bailly) Date: Fri, 05 Jul 2013 08:03:27 +0200 Subject: [Development] [Interest] [Announce] Qt 5.1 released In-Reply-To: References: <51D5813E.3050302@sescoi.fr> <51D5861D.5090504@sescoi.fr> Message-ID: <51D661AF.5010107@sescoi.fr> Le 04/07/2013 16:34, Mark a écrit : > On Thu, Jul 4, 2013 at 4:26 PM, Yves Bailly wrote: >> Le 04/07/2013 16:17, Mark a écrit : >>> On Thu, Jul 4, 2013 at 4:05 PM, Yves Bailly wrote: >>> [...] >>>> Reading the section "New reference installers" and the download links from >>>> http://qt-project.org/downloads, it seems there's no MSVC2012 32bits OpenGL >>>> binaries available, but only ANGLE-based binaries. >>>> >>>> Are there any plans to provide them in the future? >>> >>> That's probably a typo in the download page since the actual download >>> link does contain opengl in it [1]. >>> >>> [1] http://download.qt-project.org/official_releases/qt/5.1/5.1.0/qt-windows-opensource-5.1.0-mingw48_opengl-x86-offline.exe >> >> However the link you provide used MinGW, not MSVC2012... > > Oops :p > Guess i found a typo then ;) Well maybe there's a typo, but that still doesn't answer my initial question: are there any plans to provide 32bits OpenGL for MSVC2012? :-) If not, I'm ready to consider creating the installer myself and upload it somewhere, if someone can point me on a description of the procedure applied to other "official" binaries. Regards, -- /- Yves Bailly - Software developer -\ \- Sescoi R&D - http://www.sescoi.fr -/ "The possible is done. The impossible is being done. For miracles, thanks to allow a little delay." From Jani.Heikkinen at digia.com Fri Jul 5 08:16:28 2013 From: Jani.Heikkinen at digia.com (Heikkinen Jani) Date: Fri, 5 Jul 2013 06:16:28 +0000 Subject: [Development] [Announce] Qt 5.1 released In-Reply-To: <51D5813E.3050302@sescoi.fr> References: <51D5813E.3050302@sescoi.fr> Message-ID: Hi, At the moment we don't have plans to add new reference installers. Br, Jani -----Original Message----- From: development-bounces+jani.heikkinen=digia.com at qt-project.org [mailto:development-bounces+jani.heikkinen=digia.com at qt-project.org] On Behalf Of Yves Bailly Sent: 4. heinäkuuta 2013 17:06 To: development at qt-project.org; interest at qt-project.org Subject: Re: [Development] [Announce] Qt 5.1 released Hello, (re-sending as it seems the previous has not passed through) Le 03/07/2013 14:29, List for announcements regarding Qt releases and development a écrit : > I'm happy to announce that Qt 5.1 has been released. First of all, congratulations and a great thank for all this wonderful work. > For more details have a look at the Qt 5.1 landing page and my blog post: > > http://qt-project.org/qt5/qt51 > http://blog.qt.digia.com/blog/2013/07/03/qt-5-1-released/ Reading the section "New reference installers" and the download links from http://qt-project.org/downloads, it seems there's no MSVC2012 32bits OpenGL binaries available, but only ANGLE-based binaries. Are there any plans to provide them in the future? Best regards, -- /- Yves Bailly - Software developer -\ \- Sescoi R&D - http://www.sescoi.fr -/ "The possible is done. The impossible is being done. For miracles, thanks to allow a little delay." _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Kai.Koehne at digia.com Fri Jul 5 08:49:51 2013 From: Kai.Koehne at digia.com (Koehne Kai) Date: Fri, 5 Jul 2013 06:49:51 +0000 Subject: [Development] [Interest] [Announce] Qt 5.1 released In-Reply-To: References: <51D5813E.3050302@sescoi.fr> <51D5861D.5090504@sescoi.fr> Message-ID: <5B2736A3C8B75B4BB66BC58DC5E889B08DBF3C@IT-EXMB01-HKI.it.local> > -----Original Message----- > From: interest-bounces+kai.koehne=digia.com at qt-project.org > [mailto:interest-bounces+kai.koehne=digia.com at qt-project.org] On Behalf Of > Sze Howe Koh > Sent: Friday, July 05, 2013 3:06 AM > To: Mark; web at qt-project.org > Cc: development at qt-project.org; interest at qt-project.org > Subject: Re: [Interest] [Development] [Announce] Qt 5.1 released > > Good find, Mark. Forwarding the typo to the Web mailing list. > > The MinGW package is labelled "Qt 5.1.0 for Windows 32-bit (MinGW 4.8, > 666 MB)", but the filename is > qt-windows-opensource-5.1.0-mingw48_opengl-x86-offline.exe -- one of > them is wrong. The web page is inaccurate, it should be Qt 5.1.0 for Windows 32-bit (MinGW 4.8, OpenGL, 666 MB). Regards Kai From hald at icandy.de Fri Jul 5 11:13:19 2013 From: hald at icandy.de (Cornelius Hald) Date: Fri, 05 Jul 2013 11:13:19 +0200 Subject: [Development] QQuickTextDocument and changing internal state of QTextDocument Message-ID: <1373015600.20069.2.camel@orko> Hi, I've asked this before on the "interest" list, but got now response. Maybe this here is the better place to ask... I'm very happy to see that it is finally possible to get the QTextDocument of a QtQuick TextEdit element. Unfortunately the documentation for QQuickTextDocument states the following: ------ You are not allowed to modify the document, [...] Warning: The QTextDocument provided is used internally by QtQuick elements to provide text manipulation primitives. You are not allowed to perform any modification of the internal state of the QTextDocument. If you do, the element in question may stop functioning or crash. ------ Does anyone knows what exactly that means? I've written a small sample that edits the document, for example by removing characters. So far nothing has crashed yet. // Seems to work fine... QTextCursor c(m_document); c.movePosition(QTextCursor::StartOfBlock); c.movePosition(QTextCursor::Right, QTextCursor::KeepAnchor, 2); c.removeSelectedText(); Since I'm thinking about doing an editor on top of QtQuick 2.1, I'd be happy to first know the exact limitations of this approach. Thanks! Conny From stephen.kelly at kdab.com Fri Jul 5 12:06:30 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Fri, 05 Jul 2013 12:06:30 +0200 Subject: [Development] Qt CI improvements In-Reply-To: References: Message-ID: <4815738.3f1LVuHkri@hal> On Wednesday, June 26, 2013 14:23:33 Sarajärvi Tony wrote: > Hi all! > > Our IT has planned a few improvements to our CI. You might be glad to hear > about these. These changes are addressing random failures in autotests we > have experiencing. Please let us know if you have any concerns regarding > these. These changes will come only after 5.1, so that we don't break > anything that at least works somehow currently. I also want to extend my thanks for these improvements. I have at times been quite vocal in calling for improvements, and these along with the increases in communicating ongoing work on particular problems are well appreciated. Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4842 bytes Desc: not available URL: From stephen.kelly at kdab.com Fri Jul 5 12:49:18 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Fri, 05 Jul 2013 12:49:18 +0200 Subject: [Development] Introducing QtMetrics In-Reply-To: References: Message-ID: <4113544.V44dM97O41@hal> On Tuesday, June 04, 2013 10:13:16 Sarajärvi Tony wrote: > Hi > > We are ready to launch our QtMetrics page for the public now. > > The main page can be found here: > http://testresults.qt-project.org/qtmetrics/index.php Thanks for this! I've tried it out and I noticed that there is a lot of noise from obsolete configurations. For example, after the page loaded, I selected the cmake test from the third drop-down. That lists some significant failures, however, all failures are in obsolete master branches. The color-coded table below also contains similiar noisy lines of obsolete master branches, and of repos which are not part of Qt 5 (eg QtJsonDb). Can all this stuff be filtered out or removed somehow? Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From Tony.Sarajarvi at digia.com Fri Jul 5 12:59:26 2013 From: Tony.Sarajarvi at digia.com (=?iso-8859-1?Q?Saraj=E4rvi_Tony?=) Date: Fri, 5 Jul 2013 10:59:26 +0000 Subject: [Development] Introducing QtMetrics In-Reply-To: <4113544.V44dM97O41@hal> References: <4113544.V44dM97O41@hal> Message-ID: Hi If I recall I already limited the amount of logs to be scanned so that the scanner only scanned logs dated after Feb 1st 2013. Also every entry in the database is date-stamped, so I can remove old entries from time to time. However, I don't personally know which branches are obsolete, so I'm only playing with dates. If we look at all the logs in testresults.qt-project.org/ci, those are periodically cleaned by someone of us. Cleaned means that all old logs since some date are archived. You also have the possibility to filter accordingly to time, but I'm unsure if that fulfills your needs in this case. Then a bit off topic. The Qt Metrics page lists the build status and test status accordingly to the state of the test set (tst_xxxxx). This however might not be precise enough. If we go and make the whole test set insignificant, we remove several good cases at the same time. I already improved the log scanner, and I have another database already existing, where I store this data per test case, not test set. No GUI is available for that however, and could take a while until someone has time to change or add this on top of Qt Metrics. I manually gathered this piece of information based on this new information: http://qt-project.org/wiki/CI_Failing_Tests The page was not mine, but I added that new latest information there. It also has interesting information regarding Flaky cases. With that amount of flaky cases that are re-run to get them passing, I'm wondering how much time would be saved per build, if these tests wouldn't have to be re-run to get them passing ;) -Tony > -----Original Message----- > From: Stephen Kelly [mailto:stephen.kelly at kdab.com] > Sent: 5. heinäkuuta 2013 13:49 > To: development at qt-project.org; Sarajärvi Tony > Subject: Re: [Development] Introducing QtMetrics > > On Tuesday, June 04, 2013 10:13:16 Sarajärvi Tony wrote: > > Hi > > > > We are ready to launch our QtMetrics page for the public now. > > > > The main page can be found here: > > http://testresults.qt-project.org/qtmetrics/index.php > > Thanks for this! > > I've tried it out and I noticed that there is a lot of noise from obsolete > configurations. For example, after the page loaded, I selected the cmake test > from the third drop-down. That lists some significant failures, however, all > failures are in obsolete master branches. > > The color-coded table below also contains similiar noisy lines of obsolete > master branches, and of repos which are not part of Qt 5 (eg QtJsonDb). > > Can all this stuff be filtered out or removed somehow? > > Thanks, > > -- > Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com > > Stephen Kelly | 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 From stephen.kelly at kdab.com Fri Jul 5 14:16:51 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Fri, 05 Jul 2013 14:16:51 +0200 Subject: [Development] Introducing QtMetrics In-Reply-To: References: <4113544.V44dM97O41@hal> Message-ID: <4053286.iM57xEVgsG@hal> On Friday, July 05, 2013 10:59:26 you wrote: > Hi > > If I recall I already limited the amount of logs to be scanned so that the > scanner only scanned logs dated after Feb 1st 2013. Also every entry in the > database is date-stamped, so I can remove old entries from time to time. > However, I don't personally know which branches are obsolete, so I'm only > playing with dates. The main rule of thumb is that if a repo has dev/stable/release branches, then its master branch is obsolete and can be removed. If you can remove those noisy parts, I can probably spot other cases which are not covered by the rule-of-thumb. > You also have the possibility to filter accordingly to time, but I'm unsure > if that fulfills your needs in this case. I tried that, but it does not really filter out noise. The same rows are present in the result, but with grey text instead of links. Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From sergio.ahumada at digia.com Fri Jul 5 14:28:12 2013 From: sergio.ahumada at digia.com (Sergio Ahumada) Date: Fri, 5 Jul 2013 14:28:12 +0200 Subject: [Development] [Interest] [Announce] Qt 5.1 released In-Reply-To: <5B2736A3C8B75B4BB66BC58DC5E889B08DBF3C@IT-EXMB01-HKI.it.local> References: <51D5813E.3050302@sescoi.fr> <51D5861D.5090504@sescoi.fr> <5B2736A3C8B75B4BB66BC58DC5E889B08DBF3C@IT-EXMB01-HKI.it.local> Message-ID: <51D6BBDC.2070602@digia.com> Hi, On 07/05/2013 08:49 AM, Koehne Kai wrote: >> >> Good find, Mark. Forwarding the typo to the Web mailing list. >> >> The MinGW package is labelled "Qt 5.1.0 for Windows 32-bit (MinGW 4.8, >> 666 MB)", but the filename is >> qt-windows-opensource-5.1.0-mingw48_opengl-x86-offline.exe -- one of >> them is wrong. > > The web page is inaccurate, it should be Qt 5.1.0 for Windows 32-bit (MinGW 4.8, OpenGL, 666 MB). > > Regards > > Kai Should be fixed now. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt From 416365416c at gmail.com Fri Jul 5 19:52:08 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Fri, 5 Jul 2013 10:52:08 -0700 Subject: [Development] Qml/Quick Designe Decision Wiki or how to avoid generating work for other stakeholders In-Reply-To: <51D5250C.6000001@digia.com> References: <98F45B99-00A4-49A9-814B-C7CD57398390@digia.com> <8B3D8EDA-0284-4B6B-A2D5-952406E06D57@digia.com> <51D28EB0.9070502@digia.com> <51D5250C.6000001@digia.com> Message-ID: On Thu, Jul 4, 2013 at 12:32 AM, Thomas Hartmann wrote: > Hi, > > >> We could add a "states" convenience property with ease. Would that be >> sufficient to make it a "y" in this explanation? > > > I think this is a good idea. For the designer we could just work around it > by creating a StateGroup, but I think adding a states and transitions > property to ApplicationWindow makes the API more consistent. > We should ask for other opinions, though. > > >> states/transitions have nothing actually to do with Item, we just >> added those properties onto Item for convenience. So if it's common >> enough that people want to define states/transitions on a window then >> I see no issue with adding additional convenience. It's just a thin >> wrapper around the StateGroup type anyways. We do want to provide >> extreme convenience, like the default properties which Simon likes so >> much :) . > > > Yes. The concept of default properties is very powerful and adds a lot of > convenience. But it is also tricky sometimes, because the parent in the text > QML tree is not the parent in the actual SceneGraph/Item tree any more. > > >> ApplicationWindow is going to be a fixed root item in terms of how >> it's used. Most users are going to use ApplicationWindow, not Window >> (which is not always a fixed root item, but perhaps could be treated >> as such in the design mode?), so that's the case we need to fix. > > > This is what we actually do. ApplicationWindow/Window can be the root item, > but nothing else in the design mode. > > >> We have this same "half-hidden-content-item-redirection" in Flickable, >> the only difference is that Flickable is actually an Item as well. How >> do we solve this for anchors/transformations inside a Flickable onto >> the "parent"? > > > We track these cases by running the parent chain until we find the "actual" > Item (in this case Flickable). We also do take care of transformations. > > There is one big issue, though. To avoid usability issues/flickering > we have to know the transformation beforehand. This means we have to know > the transformation before we actually reparent the item. > The current solution is that we "advise" components to have a contentItem > for these cases. Then we can check the transformation to the contentItem > beforehand. > This is how it is done for GroupBox. If there is a transformation and no > contentItem is defined items will "jump" when reparented. > > In the near future I will collect these kind of requirements of components > for the designer. Actually I only know of one other issue. Components often > assume that some properties are fixed after component complete is called. > While for applications this assumption is usually valid it breaks in the > designer. > > In a way both these problems were also relevant in the widget case and are > not QML specific. The widget designer also has to know about "non standard > ways" to add child widgets like addWidget() and widgets also have to > gracefully handle use cases which are only relevant for the designer. > QWidget was lacking component complete though and the imperative C++ API > implies that also normal users set properties in an unexpected order and > such. > While I think component complete is necessary (I even requested it back when > I started to try QML), I would prefer if in the future it is used for real > special cases and for all the standard cases we would rely on signal > compression in the engine. > > About the default property alias to a contentItem, I would like to see a > standard pattern, so we do not haven to tool dozens of exceptions. > Hinting the content item by exposing it as either "contentItem" or > "__contentItem" is a good start. We've already started the "contentItem" pattern, and while one may prefer the property to be private it's exposed because you do run into issues in special cases where you need that access. So keeping to the "contentItem" pattern sounds good for the future. I'll put that on the wiki page. Great feedback Thomas, thanks! -- Alan Alpert From thiago.macieira at intel.com Sun Jul 7 08:02:28 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 06 Jul 2013 23:02:28 -0700 Subject: [Development] Header diff for QtCore In-Reply-To: <1f4a33$7ogn1q@AZSMGA002.ch.intel.com> References: <1f4a33$7ogn1q@AZSMGA002.ch.intel.com> Message-ID: <1540500.neNtWiyJ52@tjmaciei-mobl2> On quarta-feira, 26 de junho de 2013 13.49.36, Thiago Macieira wrote: > + bool open(OpenMode mode = ReadWrite) Q_DECL_OVERRIDE; This has just been confirmed as to cause a binary compatibility issue. The rule for overriding virtuals is that it's ok, provided the old implementation (namely, QIODevice::open) is still called. That's exactly what happens if you compile Qt Creator with Qt 5.0 and run it with 5.1. Utils::QtcProcess's vtable contains QIODevice::open, so it's like it overrode and used the old implementation. The solution, as I see it, is to modify QProcess::start() to not depend on QIODevice::open. Note: this problem also applies to QLocalSocket. QAbstractSocket is not affected because https://codereview.qt-project.org/43286 did not integrate. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Sun Jul 7 08:15:12 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 06 Jul 2013 23:15:12 -0700 Subject: [Development] Header diff for QtCore In-Reply-To: <1540500.neNtWiyJ52@tjmaciei-mobl2> References: <1f4a33$7ogn1q@AZSMGA002.ch.intel.com> <1540500.neNtWiyJ52@tjmaciei-mobl2> Message-ID: <13686290.h2fD4Mrqm4@tjmaciei-mobl2> On sábado, 6 de julho de 2013 23.02.28, Thiago Macieira wrote: > On quarta-feira, 26 de junho de 2013 13.49.36, Thiago Macieira wrote: > > + bool open(OpenMode mode = ReadWrite) Q_DECL_OVERRIDE; > > This has just been confirmed as to cause a binary compatibility issue. > > The rule for overriding virtuals is that it's ok, provided the old > implementation (namely, QIODevice::open) is still called. That's exactly > what happens if you compile Qt Creator with Qt 5.0 and run it with 5.1. > Utils::QtcProcess's vtable contains QIODevice::open, so it's like it > overrode and used the old implementation. For the interested, the full details are on QTBUG-32284. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From ynonperek at gmail.com Sun Jul 7 20:13:08 2013 From: ynonperek at gmail.com (Ynon Perek) Date: Sun, 7 Jul 2013 21:13:08 +0300 Subject: [Development] Compiling Qt5 from Sources In-Reply-To: <82E1B2E6B4F545E0881604087897E54F@gmail.com> References: <82E1B2E6B4F545E0881604087897E54F@gmail.com> Message-ID: Hello all, Cross posting from [interest] after no replies, and hoping someone here might know the answer. In addition, some more details. The configure line I used is: configure -I C:\icu\include -I c:\OpenSSL-Win32\include -opensource -openssl-linked -debug-and-release -platform win32-msvc2012 -icu -no-vcproj -nomake examples -nomake tests -L C:\icu\lib -L c:\OpenSSL-Win32\lib After a successful compilation, my debug build works OK but using the release build my webkit throws strange JavaScript errors (for example refuses to load jQuery). Same code works very well with the libraries provided on qt-project.org My question - where can I find the configure or build settings (versions of ICU etc.) used to build the binaries on the website ? Thanks In Advance, Ynon > Hello all, > > I'm trying to compile Qt5 under Windows 7 (32bit) with MSVC 2012. > > Whatever I try, I get either compilation errors or worse it compiles but apps built against the result present strange behaviour (random bugs and crashes). > > I found the binaries distributed on qt-project site very helpful and work well. > > Perhaps anyone here knows the configure line and machine settings used to build them ? > > Thanks In Advance, > Ynon Perek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From san at sansano.inf.utfsm.cl Sun Jul 7 20:47:02 2013 From: san at sansano.inf.utfsm.cl (Sergio Ahumada) Date: Sun, 07 Jul 2013 20:47:02 +0200 Subject: [Development] Compiling Qt5 from Sources In-Reply-To: References: <82E1B2E6B4F545E0881604087897E54F@gmail.com> Message-ID: <51D9B7A6.30307@sansano.inf.utfsm.cl> Hi, On 07/07/2013 08:13 PM, Ynon Perek wrote: > My question - where can I find the configure or build settings (versions > of ICU etc.) used to build the binaries on the website ? > The configure line can be found here: https://qt.gitorious.org/qtsdk/qtsdk/blobs/master/release-tools/bld_config/configure_win_opensource and other artefacts can be found here: https://qt.gitorious.org/qtsdk/qtsdk/blobs/master/release-tools/configurations/windows/x86-qt510-msvc2012_32-conf Cheers, -- Sergio Ahumada san at sansano.inf.utfsm.cl From Richard.Gustavsen at digia.com Mon Jul 8 14:04:05 2013 From: Richard.Gustavsen at digia.com (Gustavsen Richard) Date: Mon, 8 Jul 2013 12:04:05 +0000 Subject: [Development] Handling specific platform events in Qt In-Reply-To: References: <51CD6436.5030000@digia.com> <51D15CC4.4030104@digia.com>, Message-ID: ________________________________________ Fra: Alan Alpert [416365416c at gmail.com] Sendt: 1. juli 2013 22:16 To: Vestbo Tor Arne Cc: development; Gustavsen Richard Emne: Re: Handling specific platform events in Qt On Mon, Jul 1, 2013 at 3:41 AM, Tor Arne Vestbø wrote: > On 6/28/13 18:59 , Alan Alpert wrote: >> >> This should be accessible via Qt.application.active (false if >> paused/minimized or otherwise not visible). > > > Qt.application.active binds to a window having keyboard activation, AFAIK, > which may or may not correspond to also being visible/in front, and vice > versa. > I don't think so. There's a Window.active property for that, and since we're supporting multi-window Qt.application.active should be referring to global application state. QWindow::isActive() basically returns if it the window has keyboard focus or not. And QEvent::ApplicationDeactivate is posted by QGuiApplication when no window no longer has keyboard focus. And likewise, a QEvent::ApplicationActivate is posted when at least one window gains focus again. This coupling of window focus and application activation is not sufficient on mobile platforms, since a window in that environment should only have keyboard focus (with blinking cursors etc) when the virtual keyboard is actually showing. But at the same, the application should not be considered deactivated just because the main window is not active (that is, the virtual keyboard is closed). That, and the fact that we need more than active/inactive to describe the state of an application on mobile platforms, led to the implementation of Qt::ApplicationState. Currently, the only way to get the application state is to listen for QApplicationStateChangeEvents sent to QGuiApplication. We plan to add a QGuiApplication::applicationState(), and a corresponding QML API for Qt-5.2 as well. In the meantime, since the application state logic also sends out the deprecated QEvent::ApplicationActivate events, you can listen to changes to Qt.application.active as well. -Richard From sergio.ahumada at digia.com Mon Jul 8 14:25:12 2013 From: sergio.ahumada at digia.com (Sergio Ahumada) Date: Mon, 8 Jul 2013 14:25:12 +0200 Subject: [Development] Gerrit Update deployed Message-ID: <51DAAFA8.7020301@digia.com> Hi, Today we have deployed two fixes for Gerrit. These changes should not affect anybody's workflow since they are meant to improve the interaction with the CI system. Here's some info if you are curious about them: https://codereview.qt-project.org/54969 https://bugreports.qt-project.org/browse/QTQAINFRA-509 https://codereview.qt-project.org/54827 https://bugreports.qt-project.org/browse/QTQAINFRA-568 Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt From jpnurmi at digia.com Mon Jul 8 15:45:21 2013 From: jpnurmi at digia.com (Nurmi J-P) Date: Mon, 8 Jul 2013 13:45:21 +0000 Subject: [Development] PROPOSAL: merge #qt-qml and #qt-components to #qt-quick In-Reply-To: References: <77CBF859-2E2C-434C-AD7D-41E01B6F0616@digia.com> <21B12E67-E779-4F2A-8BDD-74D90F74CB56@digia.com> Message-ID: On Jul 3, 2013, at 9:53 PM, Nurmi J-P wrote: > On Jul 1, 2013, at 6:46 PM, Alan Alpert <416365416c at gmail.com> wrote: > >> On Mon, Jul 1, 2013 at 7:04 AM, Nurmi J-P wrote: >>> Hi again, >>> >>> A new #qt-quick channel was established a couple of weeks ago, and the users of the former #qt-components were redirected to #qt-quick. Now that the dust has settled, I'd like to propose taking the next step - to merge #qt-qml to #qt-quick. >>> >>> Users are increasingly confused by the separation between the two channels, and the questions seem to be pretty mixed too. Therefore I'm still voting for having a single #qt-quick channel for Qt Quick and QML users. Time will tell whether development discussions should be kept there or not. >>> >> >> I'm okay with that. If we want to reclaim #qt-qml for development we >> can do it after all the users have switched over. Currently they just >> have inexplicable overlap, so one channel would be an improvement. >> >> -- >> Alan Alpert > > > Not all users follow the mailing lists, so I've also asked from people hanging on #qt-qml. The feedback for this idea of merging with #qt-quick has been very positive. Unless someone comes up with reasonable objections, we will turn on the redirect on Monday 8th July that is one week from the proposal e-mail quoted above. > > -- > J-P Nurmi > FYI, I've turned on the redirect. See You on #qt-quick! :) -- J-P Nurmi From staniek at kde.org Mon Jul 8 22:30:41 2013 From: staniek at kde.org (Jaroslaw Staniek) Date: Mon, 8 Jul 2013 22:30:41 +0200 Subject: [Development] Qt Joins Tizen Store Ecosystem Message-ID: Dear All, Qt Joins Tizen Store Ecosystem. You can now publish your Qt applications for smartphones: http://qtfortizen.blogspot.com/2013/07/qt-joins-tizen-store-ecosystem.html -- regards / pozdrawiam, Jaroslaw Staniek Kexi & Calligra & KDE | http://calligra.org/kexi | http://kde.org Qt for Tizen | http://qt-project.org/wiki/Tizen Qt Certified Specialist | http://www.linkedin.com/in/jstaniek From thiago.macieira at intel.com Mon Jul 8 23:55:53 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 08 Jul 2013 14:55:53 -0700 Subject: [Development] Header diff for QtCore In-Reply-To: <13686290.h2fD4Mrqm4@tjmaciei-mobl2> References: <1f4a33$7ogn1q@AZSMGA002.ch.intel.com> <1540500.neNtWiyJ52@tjmaciei-mobl2> <13686290.h2fD4Mrqm4@tjmaciei-mobl2> Message-ID: <2661808.tM1qhbTDTM@tjmaciei-mobl2> On sábado, 6 de julho de 2013 23.15.12, Thiago Macieira wrote: > On sábado, 6 de julho de 2013 23.02.28, Thiago Macieira wrote: > > On quarta-feira, 26 de junho de 2013 13.49.36, Thiago Macieira wrote: > > > + bool open(OpenMode mode = ReadWrite) Q_DECL_OVERRIDE; > > > > This has just been confirmed as to cause a binary compatibility issue. > > > > The rule for overriding virtuals is that it's ok, provided the old > > implementation (namely, QIODevice::open) is still called. That's exactly > > what happens if you compile Qt Creator with Qt 5.0 and run it with 5.1. > > Utils::QtcProcess's vtable contains QIODevice::open, so it's like it > > overrode and used the old implementation. > > For the interested, the full details are on QTBUG-32284. Fix is https://codereview.qt-project.org/60643 Speedy review is appreciated. This is affecting packages that are out there already. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From ecisp.wangshuo at gmail.com Tue Jul 9 03:55:45 2013 From: ecisp.wangshuo at gmail.com (Shuo Wang) Date: Tue, 9 Jul 2013 09:55:45 +0800 Subject: [Development] Some Questions about QTableWidget Message-ID: Hi, I want to use QTableWidget to create an application such as the *WPS Excel.*Now I have implemented some functions,but I have some questions: 1.How to set the *color/style/weight *of the selection cells' gridline(not all the cells)? 2.How to change the *text direction* of one cell? 3.How to set the *alignment *of the image adding to a cell? 4.How to *insert a image into a merged cell*? Also, I have known that the *wps office* using the Qt, and I am very interesting to know *which technique it uses* and *how*? Best Wishes wangshuo UESTC ECISP -------------- next part -------------- An HTML attachment was scrubbed... URL: From charles at mazymind.com Tue Jul 9 05:40:43 2013 From: charles at mazymind.com (Charles Yin) Date: Tue, 9 Jul 2013 13:40:43 +1000 Subject: [Development] Some Questions about QTableWidget In-Reply-To: References: Message-ID: Hi, > 1.How to set the color/style/weight of the selection cells' gridline(not all the cells)? Each cell in QTableWidget is a QWidget* ( http://qt-project.org/doc/qt-4.8/qtablewidget.html#cellWidget), see QWidget docs (http://qt-project.org/doc/qt-4.8/qwidget.html) for help about these topics, such as ( http://qt-project.org/doc/qt-4.8/qwidget.html#widget-style-sheets). > 2.How to change the text direction of one cell? http://qt-project.org/doc/qt-4.8/qtablewidgetitem.html#setTextAlignment > 3.How to set the alignment of the image adding to a cell? You mean http://qt-project.org/doc/qt-4.8/qtablewidgetitem.html#icon ? > 4.How to insert a image into a merged cell? http://qt-project.org/forums/viewthread/4994 > Also, I have known that the wps office using the Qt, and I am very interesting to know which technique it uses and how? As far as I know, WPS Office is not an open source software, you probably better ask this question in their support forum http://bbs.wps.cn/ ? Cheers Charles 2013/7/9 Shuo Wang > Hi, > > I want to use QTableWidget to create an application such as the *WPS > Excel.*Now I have implemented some functions,but I have some questions: > > 1.How to set the *color/style/weight *of the selection cells' > gridline(not all the cells)? > 2.How to change the *text direction* of one cell? > 3.How to set the *alignment *of the image adding to a cell? > 4.How to *insert a image into a merged cell*? > > Also, I have known that the *wps office* using the Qt, and I am > very interesting to know *which technique it uses* and *how*? > > Best Wishes > wangshuo > > UESTC ECISP > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- -- Yunqiao (Charles) Yin -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.lees at codan.com.au Tue Jul 9 06:57:26 2013 From: simon.lees at codan.com.au (Simon Lees) Date: Tue, 9 Jul 2013 14:27:26 +0930 Subject: [Development] Android missing SONAME in lib's causes issues with cmake In-Reply-To: References: Message-ID: <51DB9836.8020705@codan.com.au> Hi All, I have been trying to build our Medium to Large project using cmake for android as we already use cmake. I have hit a issue in that rather specifying NEEDED in the library i build as a relative path it specifies it as a full path. objdump -x libMyLib.so | grep "NEEDED" returns NEEDED /opt/Qt5.1.0/5.1.0/lib/libQt5Widgets.so.5.1.0 NEEDED /opt/Qt5.1.0/5.1.0/lib/llibQt5Gui.so.5.1.0 NEEDED /opt/Qt5.1.0/5.1.0/lib/llibQt5Core.so.5.1.0 NEEDED libm.so NEEDED libc.so NEEDED libdl.so instead of NEEDED libQt5Widgets.so NEEDED llibQt5Gui.so NEEDED llibQt5Core NEEDED libm.so NEEDED libc.so NEEDED libdl.so I asked about this on #cmake and someone said the most probable reason was that the Qt libraries don't contain SONAME. objdump -x libQt5Widgets.so | grep "SONAME" returns nothing. My first question is how do i build the android libraries with a SONAME so that i can check if that fixes it, secondly if there is a good reason not to have SONAME in libraries on android, how can the cmake files shipped with Qt work correctly for android? I have not had huge amounts of experience with qmake and cmake but i have tried fixing this issue for a couple of days. If anyone can point me in the right direction it would be much appreciated, Cheers Simon From charles at mazymind.com Tue Jul 9 07:33:58 2013 From: charles at mazymind.com (Charles Yin) Date: Tue, 9 Jul 2013 15:33:58 +1000 Subject: [Development] Android missing SONAME in lib's causes issues with cmake In-Reply-To: <51DB9836.8020705@codan.com.au> References: <51DB9836.8020705@codan.com.au> Message-ID: CMake automatically adds rpaths to all targets, which you are linking with target_link_libraries(). To switch it off there is CMAKE_SKIP_RPATH option. See http://www.cmake.org/Wiki/CMake_RPATH_handling for more details. 2013/7/9 Simon Lees > Hi All, > I have been trying to build our Medium to Large project using cmake for > android as we already use cmake. I have hit a issue in that rather > specifying NEEDED in the library i build as a relative path it specifies > it as a full path. > objdump -x libMyLib.so | grep "NEEDED" returns > NEEDED /opt/Qt5.1.0/5.1.0/lib/libQt5Widgets.so.5.1.0 > NEEDED /opt/Qt5.1.0/5.1.0/lib/llibQt5Gui.so.5.1.0 > NEEDED /opt/Qt5.1.0/5.1.0/lib/llibQt5Core.so.5.1.0 > NEEDED libm.so > NEEDED libc.so > NEEDED libdl.so > > instead of > NEEDED libQt5Widgets.so > NEEDED llibQt5Gui.so > NEEDED llibQt5Core > NEEDED libm.so > NEEDED libc.so > NEEDED libdl.so > > > I asked about this on #cmake and someone said the most probable reason > was that the Qt libraries don't contain SONAME. objdump -x > libQt5Widgets.so | grep "SONAME" returns nothing. > > My first question is how do i build the android libraries with a SONAME > so that i can check if that fixes it, secondly if there is a good reason > not to have SONAME in libraries on android, how can the cmake files > shipped with Qt work correctly for android? I have not had huge amounts > of experience with qmake and cmake but i have tried fixing this issue > for a couple of days. > > If anyone can point me in the right direction it would be much appreciated, > > Cheers > > Simon > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- -- Yunqiao (Charles) Yin -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.lees at codan.com.au Tue Jul 9 08:36:13 2013 From: simon.lees at codan.com.au (Simon Lees) Date: Tue, 9 Jul 2013 16:06:13 +0930 Subject: [Development] Android missing SONAME in lib's causes issues with cmake In-Reply-To: References: <51DB9836.8020705@codan.com.au> Message-ID: <51DBAF5D.2000403@codan.com.au> On 07/09/2013 03:03 PM, Charles Yin wrote: > > CMake automatically adds rpaths to all targets, which you are linking > with target_link_libraries(). > > To switch it off there is |CMAKE_SKIP_RPATH| option. > > See http://www.cmake.org/Wiki/CMake_RPATH_handling for more details. > > I just tried set (CMAKE_SKIP_RPATH TRUE) again, it has no effect. > > > 2013/7/9 Simon Lees > > > Hi All, > I have been trying to build our Medium to Large project using > cmake for > android as we already use cmake. I have hit a issue in that rather > specifying NEEDED in the library i build as a relative path it > specifies > it as a full path. > objdump -x libMyLib.so | grep "NEEDED" returns > NEEDED /opt/Qt5.1.0/5.1.0/lib/libQt5Widgets.so.5.1.0 > NEEDED /opt/Qt5.1.0/5.1.0/lib/llibQt5Gui.so.5.1.0 > NEEDED /opt/Qt5.1.0/5.1.0/lib/llibQt5Core.so.5.1.0 > NEEDED libm.so > NEEDED libc.so > NEEDED libdl.so > > instead of > NEEDED libQt5Widgets.so > NEEDED llibQt5Gui.so > NEEDED llibQt5Core > NEEDED libm.so > NEEDED libc.so > NEEDED libdl.so > > > I asked about this on #cmake and someone said the most probable reason > was that the Qt libraries don't contain SONAME. objdump -x > libQt5Widgets.so | grep "SONAME" returns nothing. > > My first question is how do i build the android libraries with a > SONAME > so that i can check if that fixes it, secondly if there is a good > reason > not to have SONAME in libraries on android, how can the cmake files > shipped with Qt work correctly for android? I have not had huge > amounts > of experience with qmake and cmake but i have tried fixing this issue > for a couple of days. > > If anyone can point me in the right direction it would be much > appreciated, > > Cheers > > Simon > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > > -- > -- > Yunqiao (Charles) Yin -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre.bergner.0 at googlemail.com Tue Jul 9 09:11:00 2013 From: andre.bergner.0 at googlemail.com (=?ISO-8859-1?Q?Dr=2E_Andr=E9_Bergner?=) Date: Tue, 9 Jul 2013 09:11:00 +0200 Subject: [Development] Fwd: ShaderEffect on animated custom OpenGL QQuickItem is not animated. In-Reply-To: References: Message-ID: Hi Qt-devs, I have problems applying a ShaderEffect to a custom QQuickItem drawing raw OpenGL directives. I have a little QML script as test case, which I copied from here: http://qt-project.org/doc/qt-5.0/qtgraphicaleffects/qml-qtgraphicaleffects1-gaussianblur.html I replaced the image of that example with my custom QQuickItem drawing raw OpenGL. This custom item I created following this example: http://doc-snapshot.qt-project.org/qt5-stable/qtquick/scenegraph-textureinsgnode-fboinsgrenderer-cpp.html I.e., I subclassed QQuickItem. Within updatePaintNode I generate a new QSGSimpleTextureNode having a FBO as texture. On the QQuickWindow::beforeRendering signal I draw my OpenGL stuff into that FBO. My custom OpenGLItem has some property exposed to QML and is animated using a Timer within the QML script. Now, my problem is that while the Blur is inactive my custom OpenGL code is nicely drawn into the item and animated properly. When I switch on the shader the shader is computed only once and stays then static. The animation -- even though still rendered into the FBO -- is not picked up by the ShaderEffect item. The only way to trigger an update of the shader. This will generate a new QSGSimpleTextureNode with a fresh FBO. When I test the Blur with a small animated Rectangle put inside another Rectangle this animation is visible within the blur. What do I need to add to my custom QQuickItem in order to signal changes and trigger redraws of dependent items such as that blur? I could not find any apportierte signal. What else do I miss? Thanks a lot in advance, André -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Tue Jul 9 10:32:19 2013 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 09 Jul 2013 10:32:19 +0200 Subject: [Development] Android missing SONAME in lib's causes issues with cmake References: <51DB9836.8020705@codan.com.au> Message-ID: On Tuesday, July 09, 2013 14:27:26 Simon Lees wrote: > Hi All, > I have been trying to build our Medium to Large project using cmake for > android as we already use cmake. I have hit a issue in that rather > specifying NEEDED in the library i build as a relative path it specifies > it as a full path. > objdump -x libMyLib.so | grep "NEEDED" returns > NEEDED /opt/Qt5.1.0/5.1.0/lib/libQt5Widgets.so.5.1.0 > NEEDED /opt/Qt5.1.0/5.1.0/lib/llibQt5Gui.so.5.1.0 > NEEDED /opt/Qt5.1.0/5.1.0/lib/llibQt5Core.so.5.1.0 > NEEDED libm.so > NEEDED libc.so > NEEDED libdl.so > > instead of > NEEDED libQt5Widgets.so > NEEDED llibQt5Gui.so > NEEDED llibQt5Core > NEEDED libm.so > NEEDED libc.so > NEEDED libdl.so I built Qt for android and used the toolchain at http://code.opencv.org/projects/opencv/repository/revisions/master/changes/android/android.toolchain.cmake and confirmed this. I don't know what causes it. I think it's a cmake issue, rather than a Qt issue. Forwarding to the cmake list http://thread.gmane.org/gmane.comp.lib.qt.devel/11790 Thanks, Steve. From stephen.kelly at kdab.com Tue Jul 9 10:40:46 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Tue, 09 Jul 2013 10:40:46 +0200 Subject: [Development] Android missing SONAME in lib's causes issues with cmake In-Reply-To: References: <51DB9836.8020705@codan.com.au> Message-ID: <3272483.flUE5jMXzs@hal> On Tuesday, July 09, 2013 10:32:19 Stephen Kelly wrote: > and confirmed this. I don't know what causes it. I think it's a cmake > issue, rather than a Qt issue. Sorry, I read your mail more closely, and I think you're right about the problem being that the Qt binaries do not have SONAME set. Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From rafael.roquetto at kdab.com Tue Jul 9 14:12:11 2013 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Tue, 9 Jul 2013 09:12:11 -0300 Subject: [Development] Android missing SONAME in lib's causes issues with cmake In-Reply-To: <3272483.flUE5jMXzs@hal> References: <51DB9836.8020705@codan.com.au> <3272483.flUE5jMXzs@hal> Message-ID: <20130709121201.GA6253@polaris> On Tue, Jul 09, 2013 at 10:40:46AM +0200, Stephen Kelly wrote: > On Tuesday, July 09, 2013 10:32:19 Stephen Kelly wrote: > > and confirmed this. I don't know what causes it. I think it's a cmake > > issue, rather than a Qt issue. > > Sorry, I read your mail more closely, and I think you're right about the > problem being that the Qt binaries do not have SONAME set. I had exactly the same issue when trying to build some cmake project for Qt on BB10. Turns out that the BB10 linker was not automatically setting SONAME on the generated shared libs. Passing -soname to the compiler driver explicitly via CMAKE_SHARED_LIBRARY_SONAME_C_FLAG addressed the problem. By taking a quick look at the Android toolchain file, I haven't found anything like that, so maybe it is something worth a shot? Thanks, Rafael -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions Join us in October at Qt Developer Days 2013! - https://devdays.kdab.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4861 bytes Desc: not available URL: From thiago.macieira at intel.com Wed Jul 10 00:05:30 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 09 Jul 2013 15:05:30 -0700 Subject: [Development] Qt 4 version bump: 4.8.6 Message-ID: <57251190.2QQuXbbV3Y@tjmaciei-mobl2> This is the friendly reminder that the Qt 4.8 branch is now bumping the version number. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From markg85 at gmail.com Wed Jul 10 09:41:59 2013 From: markg85 at gmail.com (Mark) Date: Wed, 10 Jul 2013 09:41:59 +0200 Subject: [Development] Differences: QDesktopServices vs QStandardPaths In-Reply-To: <51CA0B50.6050609@psychogeeks.com> References: <51CA0B50.6050609@psychogeeks.com> Message-ID: On Tue, Jun 25, 2013 at 11:27 PM, Chris W wrote: > Hello, > > Were the following differences between the paths returned by Qt 4.8 > QDesktopServices and 5.1 QStandardPaths intentional or bug-worthy? (They > are annoying either way) > > #include > #include > int main(int argc, char **argv) > { > QCoreApplication app(argc, argv); > app.setOrganizationName("ExampleOrg"); > app.setOrganizationDomain("example.com.au"); > app.setApplicationName("ExampleApp"); > #if QT_VERSION >= QT_VERSION_CHECK(5,0,0) > QStringList paths = > QStandardPaths::standardLocations(QStandardPaths::DataLocation); > #else > QString paths = > QDesktopServices::storageLocation(QDesktopServices::DataLocation); > #endif > qDebug() << qVersion() << paths; > return 0; > } > > Outputs under different Qt versions on 64-bit Linux: > 4.8.4 "/home/chrisw/.local/share/data/ExampleOrg/ExampleApp" > 5.1.0 ("/home/chrisw/.local/share/ExampleOrg/ExampleApp", > "/usr/share/ExampleOrg/ExampleApp", > "/usr/local/share/ExampleOrg/ExampleApp", > "/usr/share/ExampleOrg/ExampleApp") > > Note the extra “data” directory in the Qt4 path vs. the first directory > in Qt5. XDG_DATA_HOME is not set. > > This means ported Qt4-based code, when built with Qt5, looks in the > wrong location for data that was previously installed/generated in the > Qt4 DataLocation on deployed machines. As sierdzio points out here > (http://qt-project.org/forums/viewthread/29223/) this is strictly > neither a regression in QDesktopServices nor a bug in QStandardPaths. > Aligning it now would be a regression in Qt5. > > Unless there's something I am missing, I will work around it by moving > the data using an installer script, using the deprecated function in > QDesktopServices, or coding alternate paths into the > application startup. > > -- > Chris Williams > > Life would be much easier if I had the source code. Anon. > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Since you haven't received a single reply yet, adding David Faure (the author of this class) in the CC. I recommend making a bug report: bugreports.qt-project.org From faure at kde.org Wed Jul 10 10:11:48 2013 From: faure at kde.org (David Faure) Date: Wed, 10 Jul 2013 10:11:48 +0200 Subject: [Development] Differences: QDesktopServices vs QStandardPaths In-Reply-To: References: <51CA0B50.6050609@psychogeeks.com> Message-ID: <2764664.rzOnMvWrko@asterix> Le mercredi 10 juillet 2013 09:41:59 Mark a écrit : > On Tue, Jun 25, 2013 at 11:27 PM, Chris W > > wrote: > > Hello, > > > > Were the following differences between the paths returned by Qt 4.8 > > QDesktopServices and 5.1 QStandardPaths intentional or bug-worthy? (They > > are annoying either way) The removal of "data/" was intentional, because it prevented accessing other things under local/share. It was a hardcoded subdir that had no reason to be there (check local/share, the xdg standard is to put stuff directly in there, not in a data subdir). However I didn't anticipate the migration problem, indeed. At this point changing the behavior of QStandardPaths::DataLocation would surely create even more trouble, so instead I can offer a QStandardPaths::Qt4DataLocation which would have the "data", for easier migration from Qt4. How does this sound? > > #if QT_VERSION >= QT_VERSION_CHECK(5,0,0) > > QStringList paths = > > QStandardPaths::standardLocations(QStandardPaths::DataLocation); writableLocation() is a more direct equivalent of QDesktopServices::storageLocation btw. > > #else > > QString paths = > > QDesktopServices::storageLocation(QDesktopServices::DataLocation); Mark wrote: > Since you haven't received a single reply yet, adding David Faure (the > author of this class) in the CC. Yes, thanks. I get too much email to be able to monitor the development at qt list :( > I recommend making a bug report: bugreports.qt-project.org Yes. -- David Faure, faure at kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 From faure at kde.org Wed Jul 10 10:57:39 2013 From: faure at kde.org (David Faure) Date: Wed, 10 Jul 2013 10:57:39 +0200 Subject: [Development] Differences: QDesktopServices vs QStandardPaths In-Reply-To: References: <51CA0B50.6050609@psychogeeks.com> Message-ID: <1440644.5SYFteLhJl@asterix> Le mercredi 10 juillet 2013 09:41:59 Mark a écrit : > > QString paths = > > QDesktopServices::storageLocation(QDesktopServices::DataLocation); After reading the forum post, I have a more complete answer; posting here for posterity. If your Qt4 code does the above, in Qt5 you can either: * move the data once and for all (from data/org/app to org/app) * keep using the deprecated QDesktopServices::DataLocation * port to this instead: QStandardPaths::writableLocation(GenericDataLocation) + “data/org/app”. The latter is the future-proof way of accessing that (old) data/org/app directory under local/share, for people who don't want to move it. Please confirm that this solution works for you, and I'll add porting documentation to QDesktopServices about this solution. I withdraw my suggestion of a Qt4DataLocation because this is basically what QDesktopServices::DataLocation is. IOW, the compat code already exists, it's exactly there in QDesktopServices -- and there is another difference than the "data" subdir, it's what happens when the applicationName isn't set, in Qt4 it was empty, in Qt5 it comes from the executable name. -- David Faure, faure at kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 From amogh.kudari5 at gmail.com Wed Jul 10 13:27:59 2013 From: amogh.kudari5 at gmail.com (Amogh Kudari) Date: Wed, 10 Jul 2013 16:57:59 +0530 Subject: [Development] Linking release build of webkit with debug build of Qt Message-ID: Hi All, I have qt built for windows in debug mode without webkit. I wanted to build webkit as a separate component. Now I am building webkit but in release mode.I am using build-webkit script to build webkit with the following options "perl build-webkit --qt --release --only-webkit". I am facing 2 issues here *1.* LINK : fatal error LNK1181: cannot open input file '*pthreadVC2*.lib' I am unable to find this lib in my system. Should I download it from somewhere or will Qt provide any supporting libs for windows pthreads... I did not get much help in net.... *and* *2.* LINK : fatal error LNK1181: cannot open input file 'C:\Admin\qt\lib\* QtGui4*.lib' I am having *QtGuid4*.dll in qt\lib\ folder as I have already built qt in debug mode.So is there any configuration that has to be done to link release build of webkit with qt built in debug mode. Please help.... Thanks and Regards, Amogh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert.astals at canonical.com Wed Jul 10 15:09:41 2013 From: albert.astals at canonical.com (Albert Astals Cid) Date: Wed, 10 Jul 2013 15:09:41 +0200 Subject: [Development] Dropping the variadic version of QSKIP Message-ID: <1808810.QGRtp28M1N@xps> Hi all, in 14cd2678396ed1450a72aeffa99c1504743ea415 a variadic version of QSKIP was added so that the old Qt4 version of QSKIP(statement, mode) would compile on C++11 enabled compilers silently ignoring the mode. This has a down side, it is causing that code like QSKIP("HOLA"); gives warning: ISO C99 requires rest arguments to be used [enabled by default] when compiled with -pedantic and C++11 Furthermore, things like QSKIP("HOLA", SkipSingle); don't compile anymore because moc complains main.cpp:11: Error: Macro argument mismatch. So it doesn't seem it makes much sense to keep the variadic version of QSKIP to enable the compatibility with the old Qt4 syntax if moc is not accepting it anymore. Would you guys accept a patch that drops the variadic version of QSKIP? Cheers, Albert From z0idberg at gmx.de Wed Jul 10 15:49:30 2013 From: z0idberg at gmx.de (Hans Schmidt) Date: Wed, 10 Jul 2013 15:49:30 +0200 Subject: [Development] Qt Linguist - Some requests Message-ID: <51DD666A.50602@gmx.de> Hello, I tried to translate an application with Qt Linguist. While doing this, I noticed the following things: 1. I had to install the complete Qt framework. It would be much better if there were a stand alone installer, which ONLY installs the Qt Linguist. I guess most translators are not developers and therefore may not need the entire Qt framework. This is also addressed in this forum entry: http://qt-project.org/forums/viewthread/17054. This is especially a nuisance if you have a slower Internet connection and have to download a larger installation file. 2. Currently, only the source strings are shown in a tabular view. If you want to compare several previously made translations, it is not possible. Also, if you want to proofread already translated string, you have to select every single string. This is really uncomfortable. It would be much better if both the source string as well as the translated string are shown in a tabular view, so that you can check and compare with a quick glance. 3. Qt Linguist shows every space with a small dot. Although this certainly has its uses, it is sometimes quite distracting. Also, if you want to check if there is a hyphen (-) between two words, it is hard to tell the difference between a space and a hyphen. It would be better if this annotation could be disabled. For warnings, it were better if Qt Linguist would warn against multiple spaces following. 4. Please support smart quotes. Although this is not a problem for me, many translators do not employ smart quotes (e.g. “...” in English, „...“ in German, «...» in French), because they are usually not present on the keyboard. It would be better if Qt Linguist would automatically insert them. 5. It would be good if there were a list for “related strings”, e.g. where the same word is also used in other strings. For example, if you have a certain phrase or word often used in many strings, it would be good if Qt Linguist automatically showed a list with other strings where the phrase occurs, so that you can create a coherent translation. 6. The search function should have the option to search for complete words. If you want to search for one word, which is also contained in other words, it will give too many results (e.g., I looked for “sie” (=“she”, wanted to translate it to “Sie”=“you”), but also got “Aktualisierung“. Also, if searched, the word should be highlighted in the result. Search and replace does not seem to work in the existing translation. This is especially necessary if you want to correct an existing translation It would be good if some of these issues could be addressed. Currently, I find Qt Linguist really hard to use in a more complex setting. Especially issues 1 and 2 are quite important, in my opinion. Or is there a better alternative to Qt Linguist? Thanks, Hans Schmidt From oswald.buddenhagen at digia.com Wed Jul 10 16:14:28 2013 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Wed, 10 Jul 2013 16:14:28 +0200 Subject: [Development] Qt Linguist - Some requests In-Reply-To: <51DD666A.50602@gmx.de> References: <51DD666A.50602@gmx.de> Message-ID: <20130710141428.GA26945@troll08.it.local> On Wed, Jul 10, 2013 at 03:49:30PM +0200, Hans Schmidt wrote: > I tried to translate an application with Qt Linguist. While doing this, > I noticed the following things: [...] > > It would be good if some of these issues could be addressed. > the correct venue to make such requests is bugreports.qt-project.org. there you'll notice that most of these issues are already reported in some way. however, it's unlikely that anything will actually happen, as nobody in the community has currently allocated any resources to the development of linguist. you may change that by contracting digia or somebody else. > Or is there a better alternative to Qt Linguist? > you may try kde's lokalize (not sure it groks .ts files nowadays. use lconvert if it doesn't). From Gunnar.Sletta at digia.com Wed Jul 10 16:14:09 2013 From: Gunnar.Sletta at digia.com (Sletta Gunnar) Date: Wed, 10 Jul 2013 14:14:09 +0000 Subject: [Development] Fwd: ShaderEffect on animated custom OpenGL QQuickItem is not animated. In-Reply-To: References: , Message-ID: <1ED64457-4DDC-4C8F-A464-4286D12122A0@digia.com> On 9. juli 2013, at 09:11, "Dr. André Bergner" > wrote: Hi Qt-devs, I have problems applying a ShaderEffect to a custom QQuickItem drawing raw OpenGL directives. I have a little QML script as test case, which I copied from here: http://qt-project.org/doc/qt-5.0/qtgraphicaleffects/qml-qtgraphicaleffects1-gaussianblur.html I replaced the image of that example with my custom QQuickItem drawing raw OpenGL. This custom item I created following this example: http://doc-snapshot.qt-project.org/qt5-stable/qtquick/scenegraph-textureinsgnode-fboinsgrenderer-cpp.html I.e., I subclassed QQuickItem. Within updatePaintNode I generate a new QSGSimpleTextureNode having a FBO as texture. On the QQuickWindow::beforeRendering signal I draw my OpenGL stuff into that FBO. My custom OpenGLItem has some property exposed to QML and is animated using a Timer within the QML script. Now, my problem is that while the Blur is inactive my custom OpenGL code is nicely drawn into the item and animated properly. When I switch on the shader the shader is computed only once and stays then static. The animation -- even though still rendered into the FBO -- is not picked up by the ShaderEffect item. The only way to trigger an update of the shader. This will generate a new QSGSimpleTextureNode with a fresh FBO. When I test the Blur with a small animated Rectangle put inside another Rectangle this animation is visible within the blur. What do I need to add to my custom QQuickItem in order to signal changes and trigger redraws of dependent items such as that blur? I could not find any apportierte signal. What else do I miss? Try calling QSGNode::markDirty(QSGNode::DirtyMaterial) on the node after changing the FBO. The example should strictly speaking also be doing this... However, if you intend to use the texture as input to a ShaderEffect, you might want to consider implenementing the QQuickItem::textureProvider() function to save the extra FBO. Cheers, Gunnar Thanks a lot in advance, André _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Jul 10 18:46:48 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Jul 2013 09:46:48 -0700 Subject: [Development] Dropping the variadic version of QSKIP In-Reply-To: <1808810.QGRtp28M1N@xps> References: <1808810.QGRtp28M1N@xps> Message-ID: <1723620.HIe2avZIlz@tjmaciei-mobl2> On quarta-feira, 10 de julho de 2013 15.09.41, Albert Astals Cid wrote: > Hi all, in 14cd2678396ed1450a72aeffa99c1504743ea415 a variadic version of > QSKIP was added so that the old Qt4 version of > QSKIP(statement, mode) > would compile on C++11 enabled compilers silently ignoring the mode. > > This has a down side, it is causing that code like > QSKIP("HOLA"); > gives > warning: ISO C99 requires rest arguments to be used [enabled by default] > when compiled with -pedantic and C++11 > > Furthermore, things like > QSKIP("HOLA", SkipSingle); > don't compile anymore because moc complains > main.cpp:11: Error: Macro argument mismatch. > > So it doesn't seem it makes much sense to keep the variadic version of QSKIP > to enable the compatibility with the old Qt4 syntax if moc is not accepting > it anymore. > > Would you guys accept a patch that drops the variadic version of QSKIP? Well, there is a moc bug in the parsing of variadic macros, evidently. Is there any way we can use the rest arguments without making them take effect? Such as by making a string out of them that doesn't get used anywhere: #define QSKIP(x, ...) { static const char _[] = #__VA_ARGS__; } \ [existing code] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From olivier at woboq.com Wed Jul 10 19:43:09 2013 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 10 Jul 2013 19:43:09 +0200 Subject: [Development] Dropping the variadic version of QSKIP In-Reply-To: <1723620.HIe2avZIlz@tjmaciei-mobl2> References: <1808810.QGRtp28M1N@xps> <1723620.HIe2avZIlz@tjmaciei-mobl2> Message-ID: <1695257.kB7LA5vZ7R@gargamel> On Wednesday 10 July 2013 09:46:48 Thiago Macieira wrote: > On quarta-feira, 10 de julho de 2013 15.09.41, Albert Astals Cid wrote: > > Hi all, in 14cd2678396ed1450a72aeffa99c1504743ea415 a variadic version of > > QSKIP was added so that the old Qt4 version of > > > > QSKIP(statement, mode) > > > > would compile on C++11 enabled compilers silently ignoring the mode. > > > > This has a down side, it is causing that code like > > > > QSKIP("HOLA"); > > > > gives > > > > warning: ISO C99 requires rest arguments to be used [enabled by default] > > > > when compiled with -pedantic and C++11 > > > > Furthermore, things like > > > > QSKIP("HOLA", SkipSingle); > > > > don't compile anymore because moc complains > > > > main.cpp:11: Error: Macro argument mismatch. > > > > So it doesn't seem it makes much sense to keep the variadic version of > > QSKIP to enable the compatibility with the old Qt4 syntax if moc is not > > accepting it anymore. > > > > Would you guys accept a patch that drops the variadic version of QSKIP? > > Well, there is a moc bug in the parsing of variadic macros, evidently. There is no bug. The QSKIP is defined depending on Q_COMPILER_VARIADIC_MACROS which itslef is defined depending on a builtin gcc macro wich is not given to moc. So moc beleive QSKIP only take one argument. The solution would be to add a || defined (Q_MOC_RUN) Arguably, moc could perhaps be more error tollerent in this case. > Is there any way we can use the rest arguments without making them take > effect? Such as by making a string out of them that doesn't get used > anywhere: > > #define QSKIP(x, ...) > { static const char _[] = #__VA_ARGS__; } \ > [existing code] That's not the problem. GCC's warning message is not obtimal. clang is (as usual :-p) better: warning: must specify at least one argument for '...' parameter of variadic macro [-Wgnu] In other words: the problem is that one call QSKIP with only one argument instead of at least 2. maybe something like: #define QSKIP(...) QSKIP2(__VA_ARGS__ , _) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From chrisw.qtdevel at psychogeeks.com Thu Jul 11 00:06:05 2013 From: chrisw.qtdevel at psychogeeks.com (Chris W) Date: Thu, 11 Jul 2013 08:06:05 +1000 Subject: [Development] Differences: QDesktopServices vs QStandardPaths In-Reply-To: <1440644.5SYFteLhJl@asterix> References: <51CA0B50.6050609@psychogeeks.com> <1440644.5SYFteLhJl@asterix> Message-ID: <51DDDACD.9010709@psychogeeks.com> On 10/07/13 18:57, David Faure wrote: > Le mercredi 10 juillet 2013 09:41:59 Mark a écrit : >>> QString paths = >>> QDesktopServices::storageLocation(QDesktopServices::DataLocation); > After reading the forum post, I have a more complete answer; posting here for > posterity. > If your Qt4 code does the above, in Qt5 you can either: > * move the data once and for all (from data/org/app to org/app) > * keep using the deprecated QDesktopServices::DataLocation > * port to this instead: > QStandardPaths::writableLocation(GenericDataLocation) + “data/org/app”. > > The latter is the future-proof way of accessing that (old) data/org/app > directory under local/share, for people who don't want to move it. This is more-or-less what to allow my Qt5 version to move the pre-existing Qt4 folder to the new location. > Please confirm that this solution works for you, and I'll add porting > documentation to QDesktopServices about this solution. This is good. A note in the docs regarding the extra "data" folder and alternatives for getting at it would be excellent. > I withdraw my suggestion of a Qt4DataLocation because this is basically what > QDesktopServices::DataLocation is. IOW, the compat code already exists, it's > exactly there in QDesktopServices -- and there is another difference than the > "data" subdir, it's what happens when the applicationName isn't set, in Qt4 it > was empty, in Qt5 it comes from the executable name. I agree, this was messy and, as you say, the deprecated code is still available (for those who can work out how to un-hide it). Thanks for your time. Regards, Chris From vincentb1981 at gmail.com Thu Jul 11 00:10:07 2013 From: vincentb1981 at gmail.com (Vincent) Date: Thu, 11 Jul 2013 00:10:07 +0200 Subject: [Development] Qt Linguist - Some requests In-Reply-To: <20130710141428.GA26945@troll08.it.local> References: <51DD666A.50602@gmx.de> <20130710141428.GA26945@troll08.it.local> Message-ID: Le mercredi 10 juillet 2013, Oswald Buddenhagen a écrit : > On Wed, Jul 10, 2013 at 03:49:30PM +0200, Hans Schmidt wrote: > > I tried to translate an application with Qt Linguist. While doing this, > > I noticed the following things: [...] > > > > It would be good if some of these issues could be addressed. > > > the correct venue to make such requests is bugreports.qt-project.org. > there you'll notice that most of these issues are already reported in > some way. > however, it's unlikely that anything will actually happen, as nobody in > the community has currently allocated any resources to the development > of linguist. you may change that by contracting digia or somebody else. > > Does it mean Linguist is not the correct/recommended tool for translating Qt applications? > > Or is there a better alternative to Qt Linguist? > > > you may try kde's lokalize (not sure it groks .ts files nowadays. use > lconvert if it doesn't). > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.lees at codan.com.au Thu Jul 11 03:01:30 2013 From: simon.lees at codan.com.au (Simon Lees) Date: Thu, 11 Jul 2013 10:31:30 +0930 Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: References: Message-ID: <51DE03EA.2090808@codan.com.au> On 07/10/2013 07:30 PM, development-request at qt-project.org wrote: > Date: Tue, 9 Jul 2013 09:12:11 -0300 > From: Rafael Roquetto > Subject: Re: [Development] Android missing SONAME in lib's causes > issues with cmake > To: Stephen Kelly > Cc: development at qt-project.org > Message-ID: <20130709121201.GA6253 at polaris> > Content-Type: text/plain; charset="iso-8859-1" > > On Tue, Jul 09, 2013 at 10:40:46AM +0200, Stephen Kelly wrote: >> On Tuesday, July 09, 2013 10:32:19 Stephen Kelly wrote: >>> and confirmed this. I don't know what causes it. I think it's a cmake >>> issue, rather than a Qt issue. >> Sorry, I read your mail more closely, and I think you're right about the >> problem being that the Qt binaries do not have SONAME set. > I had exactly the same issue when trying to build some cmake project > for Qt on BB10. Turns out that the BB10 linker was not automatically setting > SONAME on the generated shared libs. Passing -soname to the compiler driver > explicitly via CMAKE_SHARED_LIBRARY_SONAME_C_FLAG addressed the problem. By > taking a quick look at the Android toolchain file, I haven't found anything > like that, so maybe it is something worth a shot? > > Thanks, > Rafael Hi, I have tried adding set (CMAKE_SHARED_LIBRARY_SONAME_C_FLAG "${CMAKE_SHARED_LIBRARY_SONAME_C_FLAG} -soname") and alternatively set (CMAKE_SHARED_LIBRARY_SONAME_C_FLAG "-soname") To both my CMakeLists.txt and the toolchain file (One at a time) Neither have helped, is this what you meant? If it is can you send me a copy of your config files so i can look for differences. I am using the android toolchain file from the same location as Stephen. Can anyone point me in the right direction to building Qt with a SONAME in android, my knowledge of Qt's build system is even more limited then my knowledge of cmake. PS sorry if i break email threading, i am only subscribed to the Digest for this list Simon From Shawn.Rutledge at digia.com Thu Jul 11 07:56:35 2013 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Thu, 11 Jul 2013 05:56:35 +0000 Subject: [Development] Qt Linguist - Some requests In-Reply-To: References: <51DD666A.50602@gmx.de> <20130710141428.GA26945@troll08.it.local> Message-ID: <2DD2A229-7DC3-4A34-8477-A64F9D1ED307@digia.com> On 11 Jul 2013, at 12:10 AM, Vincent wrote: > Le mercredi 10 juillet 2013, Oswald Buddenhagen a écrit : > On Wed, Jul 10, 2013 at 03:49:30PM +0200, Hans Schmidt wrote: > > I tried to translate an application with Qt Linguist. While doing this, > > I noticed the following things: [...] > > > > It would be good if some of these issues could be addressed. > > > the correct venue to make such requests is bugreports.qt-project.org. > there you'll notice that most of these issues are already reported in > some way. > however, it's unlikely that anything will actually happen, as nobody in > the community has currently allocated any resources to the development > of linguist. you may change that by contracting digia or somebody else. > > Does it mean Linguist is not the correct/recommended tool for translating Qt applications? That was surely a pessimistic view. There's nothing stopping anyone from fixing problems or adding features one-by-one (except for the matter of getting around to it ;-) and some of the suggestions don't sound very hard to implement either. It's also a good idea to keep writing bugs/suggestions, or update them when they were written against older Qt versions but still apply to the current one. From Jan-Arve.Saether at digia.com Thu Jul 11 10:12:16 2013 From: Jan-Arve.Saether at digia.com (Saether Jan-Arve) Date: Thu, 11 Jul 2013 08:12:16 +0000 Subject: [Development] Linking release build of webkit with debug build of Qt In-Reply-To: References: Message-ID: <66BFFE861C7DE34D9B0372D8EAAB18E2BAB40D@IT-EXMB01-HKI.it.local> You shouldn't mix debug and release libraries. It will most likely cause your application to malfunction. If you need webkit in release mode you should also build the rest of Qt in release mode. Jan Arve From: development-bounces+jan-arve.saether=digia.com at qt-project.org [mailto:development-bounces+jan-arve.saether=digia.com at qt-project.org] On Behalf Of Amogh Kudari Sent: 10. juli 2013 13:28 To: development at qt-project.org Subject: [Development] Linking release build of webkit with debug build of Qt Hi All, I have qt built for windows in debug mode without webkit. I wanted to build webkit as a separate component. Now I am building webkit but in release mode.I am using build-webkit script to build webkit with the following options "perl build-webkit --qt --release --only-webkit". I am facing 2 issues here 1. LINK : fatal error LNK1181: cannot open input file 'pthreadVC2.lib' I am unable to find this lib in my system. Should I download it from somewhere or will Qt provide any supporting libs for windows pthreads... I did not get much help in net.... and 2. LINK : fatal error LNK1181: cannot open input file 'C:\Admin\qt\lib\QtGui4.lib' I am having QtGuid4.dll in qt\lib\ folder as I have already built qt in debug mode.So is there any configuration that has to be done to link release build of webkit with qt built in debug mode. Please help.... Thanks and Regards, Amogh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.hausmann at digia.com Thu Jul 11 11:22:43 2013 From: simon.hausmann at digia.com (Simon Hausmann) Date: Thu, 11 Jul 2013 11:22:43 +0200 Subject: [Development] Linking release build of webkit with debug build of Qt In-Reply-To: <66BFFE861C7DE34D9B0372D8EAAB18E2BAB40D@IT-EXMB01-HKI.it.local> References: <66BFFE861C7DE34D9B0372D8EAAB18E2BAB40D@IT-EXMB01-HKI.it.local> Message-ID: <4105357.Z2iesPruLg@rhea> On Thursday 11. July 2013 08.12.16 Saether Jan-Arve wrote: > You shouldn't mix debug and release libraries. It will most likely cause > your application to malfunction. > > If you need webkit in release mode you should also build the rest of Qt in > release mode. In addition to what Jan-Arve said: The pthreads dependency of QtWebKit is removed in Qt 5 and webkit trunk. I don't remember exactly, but I think we also had a patch in Qt 4's WebKit to eliminate it. Simon > From: development-bounces+jan-arve.saether=digia.com at qt-project.org > [mailto:development-bounces+jan-arve.saether=digia.com at qt-project.org] On > Behalf Of Amogh Kudari Sent: 10. juli 2013 13:28 > To: development at qt-project.org > Subject: [Development] Linking release build of webkit with debug build of > Qt > > > > Hi All, > > I have qt built for windows in debug mode without webkit. I > wanted to build webkit as a separate component. Now I am building webkit > but in release mode.I am using build-webkit script to build webkit with the > following options "perl build-webkit --qt --release --only-webkit". I am > facing 2 issues here > > 1. LINK : fatal error LNK1181: cannot open input file 'pthreadVC2.lib' > I am unable to find this lib in my system. Should I download it from > somewhere or will Qt provide any supporting libs for windows pthreads... I > did not get much help in net.... > > and > > 2. LINK : fatal error LNK1181: cannot open input file > 'C:\Admin\qt\lib\QtGui4.lib' I am having QtGuid4.dll in qt\lib\ folder as I > have already built qt in debug mode.So is there any configuration that has > to be done to link release build of webkit with qt built in debug mode. > > Please help.... > > Thanks and Regards, > Amogh. From announce at qt-project.org Thu Jul 11 12:37:46 2013 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 11 Jul 2013 10:37:46 +0000 Subject: [Development] [Announce] Qt Creator 2.8.0 released Message-ID: We proudly announce the release of Qt Creator 2.8.0. Blog: http://blog.qt.digia.com/blog/2013/07/11/qt-creator-2-8-0-released Download: http://download.qt-project.org/official_releases/qtcreator/2.8/2.8.0/ -- Eike Ziller Senior Software Engineer Digia Germany GmbH Rudower Chaussee 13, D-12489 Berlin Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B, Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From faure at kde.org Thu Jul 11 13:41:45 2013 From: faure at kde.org (David Faure) Date: Thu, 11 Jul 2013 13:41:45 +0200 Subject: [Development] Differences: QDesktopServices vs QStandardPaths In-Reply-To: <51DDDACD.9010709@psychogeeks.com> References: <51CA0B50.6050609@psychogeeks.com> <1440644.5SYFteLhJl@asterix> <51DDDACD.9010709@psychogeeks.com> Message-ID: <3068808.7dtH15jVQn@asterix> Le jeudi 11 juillet 2013 08:06:05 Chris W a écrit : > On 10/07/13 18:57, David Faure wrote: > > Le mercredi 10 juillet 2013 09:41:59 Mark a écrit : > >>> QString paths = > >>> QDesktopServices::storageLocation(QDesktopServices::DataLocation); > > > > After reading the forum post, I have a more complete answer; posting here > > for posterity. > > If your Qt4 code does the above, in Qt5 you can either: > > * move the data once and for all (from data/org/app to org/app) > > * keep using the deprecated QDesktopServices::DataLocation > > * port to this instead: > > QStandardPaths::writableLocation(GenericDataLocation) + “data/org/app”. > > > > The latter is the future-proof way of accessing that (old) data/org/app > > directory under local/share, for people who don't want to move it. > > This is more-or-less what to allow my Qt5 version to move the > pre-existing Qt4 folder to the new location. Ah, good point. > > Please confirm that this solution works for you, and I'll add porting > > documentation to QDesktopServices about this solution. > > This is good. A note in the docs regarding the extra "data" folder and > alternatives for getting at it would be excellent. https://codereview.qt-project.org/60900 -- David Faure, faure at kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 From rafael.roquetto at kdab.com Thu Jul 11 14:14:39 2013 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Thu, 11 Jul 2013 09:14:39 -0300 Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <51DE03EA.2090808@codan.com.au> References: <51DE03EA.2090808@codan.com.au> Message-ID: <20130711121438.GA929@polaris> On Thu, Jul 11, 2013 at 10:31:30AM +0930, Simon Lees wrote: > Hi, > > I have tried adding > set (CMAKE_SHARED_LIBRARY_SONAME_C_FLAG > "${CMAKE_SHARED_LIBRARY_SONAME_C_FLAG} -soname") > and alternatively > set (CMAKE_SHARED_LIBRARY_SONAME_C_FLAG "-soname") > To both my CMakeLists.txt and the toolchain file (One at a time) Neither > have helped, is this what you meant? If it is can you send me a copy of > your config files so i can look for differences. I am using the android > toolchain file from the same location as Stephen. You can take a look at /usr/share/cmake-2.8/Modules/Platform/QNX.cmake for instance, to see whatis being passed to the QNX compiler. It may be that your problem has a different cause. One thing you could do is try to build the library manually, replicating the compiler/linker line cmake uses, and tweak it to see if this is really the compiler that is not adding SONAME to the libs. Just an idea. -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions Join us in October at Qt Developer Days 2013! - https://devdays.kdab.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4861 bytes Desc: not available URL: From rafael.roquetto at kdab.com Thu Jul 11 14:41:13 2013 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Thu, 11 Jul 2013 09:41:13 -0300 Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <20130711121438.GA929@polaris> References: <51DE03EA.2090808@codan.com.au> <20130711121438.GA929@polaris> Message-ID: <20130711124109.GA2406@polaris> On Thu, Jul 11, 2013 at 09:14:39AM -0300, Rafael Roquetto wrote: > On Thu, Jul 11, 2013 at 10:31:30AM +0930, Simon Lees wrote: > > Hi, > > > > I have tried adding > > set (CMAKE_SHARED_LIBRARY_SONAME_C_FLAG > > "${CMAKE_SHARED_LIBRARY_SONAME_C_FLAG} -soname") > > and alternatively > > set (CMAKE_SHARED_LIBRARY_SONAME_C_FLAG "-soname") > > To both my CMakeLists.txt and the toolchain file (One at a time) Neither > > have helped, is this what you meant? If it is can you send me a copy of > > your config files so i can look for differences. I am using the android > > toolchain file from the same location as Stephen. > > You can take a look at /usr/share/cmake-2.8/Modules/Platform/QNX.cmake for > instance, to see whatis being passed to the QNX compiler. It may be that your > problem has a different cause. One thing you could do is try to build the > library manually, replicating the compiler/linker line cmake uses, and tweak > it to see if this is really the compiler that is not adding SONAME to the > libs. Just an idea. Sorry, I seem to have misunderstood the issue. I thought the problem was that some libs that were being built against Qt libs were not carrying SONAME, not Qt binaries themselves. If Qt binaries aren't carrying SONAME, then it has nothing to do with CMake, but with the way Qt for Android is being built. I still think either the wrong flags are being passed to the compiler driver or that it has to do with your Android toolchain configuration. Check how Qt is being built, what's being passed to the compilers, the android mkspecs, etc... Rafael -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions Join us in October at Qt Developer Days 2013! - https://devdays.kdab.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4861 bytes Desc: not available URL: From simon.lees at codan.com.au Fri Jul 12 03:54:07 2013 From: simon.lees at codan.com.au (Simon Lees) Date: Fri, 12 Jul 2013 11:24:07 +0930 Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <20130711124109.GA2406@polaris> References: <51DE03EA.2090808@codan.com.au> <20130711121438.GA929@polaris> <20130711124109.GA2406@polaris> Message-ID: <51DF61BF.5040304@codan.com.au> On 07/11/2013 10:11 PM, Rafael Roquetto wrote: > On Thu, Jul 11, 2013 at 09:14:39AM -0300, Rafael Roquetto wrote: >> On Thu, Jul 11, 2013 at 10:31:30AM +0930, Simon Lees wrote: >>> Hi, >>> >>> I have tried adding >>> set (CMAKE_SHARED_LIBRARY_SONAME_C_FLAG >>> "${CMAKE_SHARED_LIBRARY_SONAME_C_FLAG} -soname") >>> and alternatively >>> set (CMAKE_SHARED_LIBRARY_SONAME_C_FLAG "-soname") >>> To both my CMakeLists.txt and the toolchain file (One at a time) Neither >>> have helped, is this what you meant? If it is can you send me a copy of >>> your config files so i can look for differences. I am using the android >>> toolchain file from the same location as Stephen. >> You can take a look at /usr/share/cmake-2.8/Modules/Platform/QNX.cmake for >> instance, to see whatis being passed to the QNX compiler. It may be that your >> problem has a different cause. One thing you could do is try to build the >> library manually, replicating the compiler/linker line cmake uses, and tweak >> it to see if this is really the compiler that is not adding SONAME to the >> libs. Just an idea. > Sorry, I seem to have misunderstood the issue. I thought the problem was that > some libs that were being built against Qt libs were not carrying SONAME, not > Qt binaries themselves. If Qt binaries aren't carrying SONAME, then it has > nothing to do with CMake, but with the way Qt for Android is being built. I > still think either the wrong flags are being passed to the compiler driver or > that it has to do with your Android toolchain configuration. Check how Qt is > being built, what's being passed to the compilers, the android mkspecs, etc... > > Rafael > I had a play with the android mkspecs the other day, but didn't get anywhere. This is probably due to my very limited understanding of the Qt build system, i'll have another play today if anyone has suggestions i'd love to here them, i'm also sitting around on irc as Simotek-Work Cheers Simon From fricker at froglogic.com Fri Jul 12 10:37:52 2013 From: fricker at froglogic.com (=?ISO-8859-1?Q?S=E9bastien_Fricker?=) Date: Fri, 12 Jul 2013 10:37:52 +0200 Subject: [Development] Qt Base code coverage statistics are now computed on Ubuntu 11.04 Message-ID: <51DFC060.3070809@froglogic.com> Hi, The test environment has changed and is now based on Ubuntu 11.04. The Puppet environment for a Qt CI test server is installed. This permits to support tests which are using OpenGL, Dbus, network infrastructures, .... This permits to reach 5% more code coverage in comparison to the previous environment (which skipped a lot of failed tests). The code coverage report can be consulted here: http://download.froglogic.com/public/qt5-squishcoco-report/ Sébastien -------------- next part -------------- An HTML attachment was scrubbed... URL: From olszak.tomasz at gmail.com Fri Jul 12 11:27:16 2013 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Fri, 12 Jul 2013 11:27:16 +0200 Subject: [Development] SCIM support as platform input context Message-ID: Hi, Do you know anything about SCIM[1] support in Qt (e.g. as platform input context plugin). 1. http://www.scim-im.org/ -- regards / pozdrawiam, Tomasz Olszak Qt for Tizen | http://qt-project.org/wiki/Tizen Qt Certified Developer | http://qt-project.org http://linkedin.com/in/tolszak -------------- next part -------------- An HTML attachment was scrubbed... URL: From ritt.ks at gmail.com Fri Jul 12 11:37:09 2013 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Fri, 12 Jul 2013 12:37:09 +0300 Subject: [Development] SCIM support as platform input context In-Reply-To: References: Message-ID: http://www.scim-im.org/projects/scim_qtimm Regards, Konstantin 2013/7/12 Tomasz Olszak : > Hi, > > Do you know anything about SCIM[1] support in Qt (e.g. as platform input > context plugin). > > 1. http://www.scim-im.org/ > -- > regards / pozdrawiam, Tomasz Olszak > Qt for Tizen | http://qt-project.org/wiki/Tizen > Qt Certified Developer | http://qt-project.org > http://linkedin.com/in/tolszak > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From sergio.ahumada at digia.com Mon Jul 15 10:53:02 2013 From: sergio.ahumada at digia.com (Sergio Ahumada) Date: Mon, 15 Jul 2013 10:53:02 +0200 Subject: [Development] HEADS UP: Qt 5.1.1 - merge stable into release Message-ID: <51E3B86E.40706@digia.com> Hi, We are about to start the "Qt 5.1.1" release, which means that: - We plan to do a fast-forward merge from 'stable' into 'release' branch on Jul 22th. - After Jul 22th any changes that are required for 5.1.1 need to be pushed to the 'release' branch. So if your changes are not in by that day, please wait until the merge is done and re-target them to the 'release' branch. The repositories that will be part of the Qt 5.1.1 release merge are: - qtactiveqt - qtbase - qtdeclarative - qtdoc - qtgraphicaleffects - qtimageformats - qtjsbackend - qtmultimedia - qtquick1 - qtquickcontrols - qtscript - qtsensors - qtserialport - qtsvg - qttools - qttranslations - qtwebkit - qtwebkit-examples - qtxmlpatterns - qtx11extras ps: you can already find some snapshots for 5.1.1 under http://download.qt-project.org/snapshots/qt/5.1/5.1.1-rc1/backups/ Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt From g.scheikl at avibit.com Mon Jul 15 15:24:04 2013 From: g.scheikl at avibit.com (Gerhard Scheikl) Date: Mon, 15 Jul 2013 15:24:04 +0200 Subject: [Development] Qt 5.1.0 rc2 is out In-Reply-To: References: Message-ID: <1646693.TFbZ3ga1Hf@pc12.avibit.com> > https://bugreports.qt-project.org/browse/QTBUG-31576 On Monday 01 July 2013 12:12:49 Knoll Lars wrote: > As unfortunate as the bug is I have to agree with Paul. But we should try > to find a fix asap for it. Please make it a blocker for 5.1.1. Seems like that did not happen. Is there any chance that this bug gets fixed soon? We would really need a solution for this problem. Best Regards Gerhard Scheikl From yves.bailly at sescoi.fr Tue Jul 16 09:39:52 2013 From: yves.bailly at sescoi.fr (Yves Bailly) Date: Tue, 16 Jul 2013 09:39:52 +0200 Subject: [Development] Creating an offline installer Message-ID: <51E4F8C8.6030707@sescoi.fr> Greetings all, I'm trying to create an installer so that others can use pre-build binaries for Qt 5.1, compiled using MSVC 2012 32bits OpenGL - as there are no "official" installer available from the website. For this purpose I'm trying to use the tools from https://qt.gitorious.org/qtsdk/qtsdk/trees/master/release-tools, carefully following the informations in the README file. However when running the command: python create_installer.py -f win_x86_32_msvc2012_opengl_offline --offline --devmode ...I'm stuck with an error I can't get around: ================================================== = Install Installer Framework tools ================================================== Traceback (most recent call last): File "create_installer.py", line 1181, in main() File "create_installer.py", line 150, in main create_installer() File "create_installer.py", line 1159, in create_installer install_ifw_tools() File "create_installer.py", line 915, in install_ifw_tools INSTALLER_FRAMEWORK_PRODUCT_KEY_CHECKER_BRANCH TypeError: __init__() takes exactly 10 arguments (9 given) Any hint about what might cause this error? Thanks in advance, -- /- Yves Bailly - Software developer -\ \- Sescoi R&D - http://www.sescoi.fr -/ "The possible is done. The impossible is being done. For miracles, thanks to allow a little delay." From sergio.ahumada at digia.com Tue Jul 16 10:50:14 2013 From: sergio.ahumada at digia.com (Sergio Ahumada) Date: Tue, 16 Jul 2013 10:50:14 +0200 Subject: [Development] Creating an offline installer In-Reply-To: <51E4F8C8.6030707@sescoi.fr> References: <51E4F8C8.6030707@sescoi.fr> Message-ID: <51E50946.6000904@digia.com> On 07/16/2013 09:39 AM, Yves Bailly wrote: > > Greetings all, > > I'm trying to create an installer so that others can use pre-build binaries > for Qt 5.1, compiled using MSVC 2012 32bits OpenGL - as there are no "official" > installer available from the website. > > For this purpose I'm trying to use the tools from > https://qt.gitorious.org/qtsdk/qtsdk/trees/master/release-tools, carefully > following the informations in the README file. > > However when running the command: > python create_installer.py -f win_x86_32_msvc2012_opengl_offline --offline --devmode > ...I'm stuck with an error I can't get around: > ================================================== > = Install Installer Framework tools > ================================================== > Traceback (most recent call last): > File "create_installer.py", line 1181, in > main() > File "create_installer.py", line 150, in main > create_installer() > File "create_installer.py", line 1159, in create_installer > install_ifw_tools() > File "create_installer.py", line 915, in install_ifw_tools > INSTALLER_FRAMEWORK_PRODUCT_KEY_CHECKER_BRANCH > TypeError: __init__() takes exactly 10 arguments (9 given) > > Any hint about what might cause this error? > > Thanks in advance, > Hi, You could try this patch https://codereview.qt-project.org/61092 Also, I'd say the README file is pretty out-of-date, so if you find errors you could maybe provide some fixes in Gerrit. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt From thiago.macieira at intel.com Tue Jul 16 12:22:55 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 16 Jul 2013 12:22:55 +0200 Subject: [Development] Changelogs for Qt 5.1.x and 5.2 Message-ID: <10577726.kxE7y6OR7V@tjmaciei-mobl2> Hello At the Qt Contributor Summit, we're proposing the following: 1) commits with changes worthy of being mentioned in the release's ChangeLog will have a note in the *commit* *message* not in a Git note not in JIRA 2) however automated we make the changelog creation, it will still require a human to re-read the text and prettify. Hopefully, a native speaker. 3) the format for the changelog is: a) auto-guess module from the paths changed [ChangeLog] Here is my slightly verbose text explaining that I've done something awesome and should tell people about it. b) explicit heading in the changelog: [ChangeLog][Important Behavior Changes] Here I am telling you that I changed something in QUrl that you should be aware of, but is for the greater good. [ChangeLog][QtCore][QUrl / QUrlQuery] Blah blah blah I am volunteering to write a (Perl) script to read all commit messages in a release and produce an update to the changelog. The script will also extract the the Task-number from the commit (if there's any) and add to the text. If there are no objections, I'll update the commit template in qtbase. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From Shawn.Rutledge at digia.com Tue Jul 16 12:44:22 2013 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Tue, 16 Jul 2013 10:44:22 +0000 Subject: [Development] Changelogs for Qt 5.1.x and 5.2 In-Reply-To: <10577726.kxE7y6OR7V@tjmaciei-mobl2> References: <10577726.kxE7y6OR7V@tjmaciei-mobl2> Message-ID: <2145B589-256B-4EA2-B511-FA89B498606C@digia.com> On 16 Jul 2013, at 12:22 PM, Thiago Macieira wrote: > 3) the format for the changelog is: > > a) auto-guess module from the paths changed > [ChangeLog] Here is my slightly verbose text explaining that I've done > something awesome and should tell people about it. Did you mean Change-log: blah blah to match the existing Change-Id:, Task-number:, etc.? > > b) explicit heading in the changelog: > [ChangeLog][Important Behavior Changes] Here I am telling you that I changed > something in QUrl that you should be aware of, but is for the greater good. > > [ChangeLog][QtCore][QUrl / QUrlQuery] Blah blah blah > > I am volunteering to write a (Perl) script to read all commit messages in a > release and produce an update to the changelog. The script will also extract > the the Task-number from the commit (if there's any) and add to the text. > > If there are no objections, I'll update the commit template in qtbase. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Jul 16 13:06:09 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 16 Jul 2013 13:06:09 +0200 Subject: [Development] Changelogs for Qt 5.1.x and 5.2 In-Reply-To: <2145B589-256B-4EA2-B511-FA89B498606C@digia.com> References: <10577726.kxE7y6OR7V@tjmaciei-mobl2> <2145B589-256B-4EA2-B511-FA89B498606C@digia.com> Message-ID: <3303623.NVueA9tLqp@tjmaciei-mobl2> On terça-feira, 16 de julho de 2013 10.44.22, Rutledge Shawn wrote: > On 16 Jul 2013, at 12:22 PM, Thiago Macieira wrote: > > 3) the format for the changelog is: > > > > a) auto-guess module from the paths changed > > [ChangeLog] Here is my slightly verbose text explaining that I've done > > something awesome and should tell people about it. > > Did you mean > Change-log: blah blah > > to match the existing Change-Id:, Task-number:, etc.? No. It's intentionally different so it does not match those. It might be more than one line, so it needs to be a full paragraph. If you use colons, the gerrit hook to add the Change-Id will add it in the same paragraph. We don't want that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From mitch.curtis at digia.com Tue Jul 16 14:40:25 2013 From: mitch.curtis at digia.com (Mitch Curtis) Date: Tue, 16 Jul 2013 14:40:25 +0200 Subject: [Development] Changelogs for Qt 5.1.x and 5.2 In-Reply-To: <3303623.NVueA9tLqp@tjmaciei-mobl2> References: <10577726.kxE7y6OR7V@tjmaciei-mobl2> <2145B589-256B-4EA2-B511-FA89B498606C@digia.com> <3303623.NVueA9tLqp@tjmaciei-mobl2> Message-ID: <51E53F39.5000004@digia.com> On 07/16/2013 01:06 PM, Thiago Macieira wrote: > On terça-feira, 16 de julho de 2013 10.44.22, Rutledge Shawn wrote: >> On 16 Jul 2013, at 12:22 PM, Thiago Macieira wrote: >>> 3) the format for the changelog is: >>> >>> a) auto-guess module from the paths changed >>> [ChangeLog] Here is my slightly verbose text explaining that I've done >>> something awesome and should tell people about it. >> >> Did you mean >> Change-log: blah blah >> >> to match the existing Change-Id:, Task-number:, etc.? > > No. It's intentionally different so it does not match those. It might be more > than one line, so it needs to be a full paragraph. If you use colons, the > gerrit hook to add the Change-Id will add it in the same paragraph. We don't > want that. What would a full, compliant commit message look like (without the [ChangeLog] notation)? From yves.bailly at sescoi.fr Tue Jul 16 15:06:43 2013 From: yves.bailly at sescoi.fr (Yves Bailly) Date: Tue, 16 Jul 2013 15:06:43 +0200 Subject: [Development] Creating an offline installer In-Reply-To: <51E50946.6000904@digia.com> References: <51E4F8C8.6030707@sescoi.fr> <51E50946.6000904@digia.com> Message-ID: <51E54563.2020202@sescoi.fr> Le 16/07/2013 10:50, Sergio Ahumada a écrit : > On 07/16/2013 09:39 AM, Yves Bailly wrote: >> [...] >> INSTALLER_FRAMEWORK_PRODUCT_KEY_CHECKER_BRANCH >> TypeError: __init__() takes exactly 10 arguments (9 given) > > Hi, > > You could try this patch https://codereview.qt-project.org/61092 > > Also, I'd say the README file is pretty out-of-date, so if you find > errors you could maybe provide some fixes in Gerrit. Thanks for your input... now I'm experiencing troubles when it tries to "git clone" the installer framework, firewall problem... If the README is out-of-date, I would loooove for a step-by-step tutorial :-) I'm just trying something pretty basic, just provide an installer for Qt's binaries, with the needed path patching - because compiled Qt is not relocatable, did someone already said it's a real pain? ;-) Having hard-coded paths in Qt's binaries is a REAL pain. Just in case nobody already said it. Thanks anyway, hours after hours I'm getting closer... -- /- Yves Bailly - Software developer -\ \- Sescoi R&D - http://www.sescoi.fr -/ "The possible is done. The impossible is being done. For miracles, thanks to allow a little delay." From sergio.ahumada at digia.com Tue Jul 16 15:21:42 2013 From: sergio.ahumada at digia.com (Sergio Ahumada) Date: Tue, 16 Jul 2013 15:21:42 +0200 Subject: [Development] Creating an offline installer In-Reply-To: <51E54563.2020202@sescoi.fr> References: <51E4F8C8.6030707@sescoi.fr> <51E50946.6000904@digia.com> <51E54563.2020202@sescoi.fr> Message-ID: <51E548E6.6060001@digia.com> On 07/16/2013 03:06 PM, Yves Bailly wrote: > Le 16/07/2013 10:50, Sergio Ahumada a écrit : >> On 07/16/2013 09:39 AM, Yves Bailly wrote: >>> [...] >>> INSTALLER_FRAMEWORK_PRODUCT_KEY_CHECKER_BRANCH >>> TypeError: __init__() takes exactly 10 arguments (9 given) >> >> Hi, >> >> You could try this patch https://codereview.qt-project.org/61092 >> >> Also, I'd say the README file is pretty out-of-date, so if you find >> errors you could maybe provide some fixes in Gerrit. > > Thanks for your input... now I'm experiencing troubles when it tries to > "git clone" the installer framework, firewall problem... > > If the README is out-of-date, I would loooove for a step-by-step tutorial :-) > I'm just trying something pretty basic, just provide an installer for > Qt's binaries, with the needed path patching - because compiled Qt is not > relocatable, did someone already said it's a real pain? ;-) > > Having hard-coded paths in Qt's binaries is a REAL pain. Just in case nobody > already said it. > > Thanks anyway, hours after hours I'm getting closer... > Hi, There is an attempt to create a python script to handle all the needed steps at https://codereview.qt-project.org/54538 You could also try http://qt-project.org/wiki/Building-Qt-Package Both are pretty much work in progress though. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt From yves.bailly at sescoi.fr Tue Jul 16 15:45:27 2013 From: yves.bailly at sescoi.fr (Yves Bailly) Date: Tue, 16 Jul 2013 15:45:27 +0200 Subject: [Development] Creating an offline installer In-Reply-To: <51E548E6.6060001@digia.com> References: <51E4F8C8.6030707@sescoi.fr> <51E50946.6000904@digia.com> <51E54563.2020202@sescoi.fr> <51E548E6.6060001@digia.com> Message-ID: <51E54E77.9000806@sescoi.fr> Le 16/07/2013 15:21, Sergio Ahumada a écrit : > On 07/16/2013 03:06 PM, Yves Bailly wrote: >> Le 16/07/2013 10:50, Sergio Ahumada a écrit : >>> On 07/16/2013 09:39 AM, Yves Bailly wrote: >>>> [...] >> >> Having hard-coded paths in Qt's binaries is a REAL pain. Just in case nobody >> already said it. >> >> Thanks anyway, hours after hours I'm getting closer... >> > There is an attempt to create a python script to handle all the needed > steps at https://codereview.qt-project.org/54538 > > You could also try http://qt-project.org/wiki/Building-Qt-Package > > Both are pretty much work in progress though. Will have a look at them, thanks. Another option would be to provide "official" 32bits MSVC2012 OpenGL binaries... ;-) Regards, -- /- Yves Bailly - Software developer -\ \- Sescoi R&D - http://www.sescoi.fr -/ "The possible is done. The impossible is being done. For miracles, thanks to allow a little delay." From Jerome.Pasion at digia.com Tue Jul 16 16:38:19 2013 From: Jerome.Pasion at digia.com (Pasion Jerome) Date: Tue, 16 Jul 2013 14:38:19 +0000 Subject: [Development] Qt CS 2013 Documentation Session Message-ID: Hello all, Posting this in the development mailing list to get more feedback. Topics: -General introduction and "how documentation works" -Publishing new projects and setting up new module documentation -Content and usability -Documentation creation workflow (sensitive to the release schedule and modules' progress) Some ideas, wishes, and proposals brought up in the session: -Keep DITA XML output because Blackberry documentation needs it -Keep QDoc because of the QML support and the amount of documentation to convert to be done -Host .qch files at the doc-snapshot.qt-project.org site (or elsewhere) for people to download -Readability and information flow needs to be consistent - Links in the pages can go to the overview, C++ page, QML page, or elsewhere, which is confusing. - Maybe combine pages into one long page? - Explain the use of the landing pages and API pages and the use of the visible text. (Clicking a link may take you to unexpected page) - Maybe have the commit template or CI warn about the use of links - Jerome: the usage of links is hard to enforce but it is possible to catch them during the review time. - The use of module name is not clear to developers or authors. For example, "Qt QML" and "QtQml" are different pages and developers may not know the difference. (could be an autolink issue) -Can we get the doc sanity bot to check the other repositories? - We can host the QDoc warnings online too -Keep the important information in the reference, not wikis or forums. Some links: Session wiki: http://qt-project.org/groups/qt-contributors-summit-2013/wiki/Documentation-Content-and-Structure Documentation wiki: http://qt-project.org/wiki/Category:Developing_Qt::Documentation Cheers, Jerome P. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Jul 16 17:55:47 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 16 Jul 2013 17:55:47 +0200 Subject: [Development] Changelogs for Qt 5.1.x and 5.2 In-Reply-To: <51E53F39.5000004@digia.com> References: <10577726.kxE7y6OR7V@tjmaciei-mobl2> <3303623.NVueA9tLqp@tjmaciei-mobl2> <51E53F39.5000004@digia.com> Message-ID: <12614139.WXW4t4Kr3v@tjmaciei-mobl2> On terça-feira, 16 de julho de 2013 14.40.25, Mitch Curtis wrote: > > No. It's intentionally different so it does not match those. It might be > > more than one line, so it needs to be a full paragraph. If you use > > colons, the gerrit hook to add the Change-Id will add it in the same > > paragraph. We don't want that. > > What would a full, compliant commit message look like (without the > [ChangeLog] notation)? Remove fully-decoded QUrl user info and authority sections Those sections contain more than one components of a URL, separated by delimiters. For that reason, QUrl::FullyDecoded and QUrl::DecodedMode do not make sense, since they would cause the returned value to be ambiguous and/or fail to parse again. In fact, there was a comment in the test saying "look how it becomes ambiguous". Those modes are already forbidden in the setters and getters of the full URL (setUrl(), url(), toString() and toEncoded()). [ChangeLog][Important Behavior Changes][QUrl and QUrlQuery] QUrl no longer supports QUrl::FullyDecoded mode in authority() and userInfo(), nor QUrl::DecodedMode in setAuthority() and setUserInfo(). Change-Id: I538f7981a9f5a09f07d3879d31ccf6f0c8bfd940 See: https://codereview.qt-project.org/60266 https://codereview.qt-project.org/60425 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From simon.lees at codan.com.au Wed Jul 17 06:31:07 2013 From: simon.lees at codan.com.au (Simon Lees) Date: Wed, 17 Jul 2013 14:01:07 +0930 Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <51DF61BF.5040304@codan.com.au> References: <51DE03EA.2090808@codan.com.au> <20130711121438.GA929@polaris> <20130711124109.GA2406@polaris> <51DF61BF.5040304@codan.com.au> Message-ID: <51E61E0B.4050105@codan.com.au> On 07/12/2013 11:24 AM, Simon Lees wrote: > On 07/11/2013 10:11 PM, Rafael Roquetto wrote: >> On Thu, Jul 11, 2013 at 09:14:39AM -0300, Rafael Roquetto wrote: >>> On Thu, Jul 11, 2013 at 10:31:30AM +0930, Simon Lees wrote: >>>> Hi, >>>> >>>> I have tried adding >>>> set (CMAKE_SHARED_LIBRARY_SONAME_C_FLAG >>>> "${CMAKE_SHARED_LIBRARY_SONAME_C_FLAG} -soname") >>>> and alternatively >>>> set (CMAKE_SHARED_LIBRARY_SONAME_C_FLAG "-soname") >>>> To both my CMakeLists.txt and the toolchain file (One at a time) Neither >>>> have helped, is this what you meant? If it is can you send me a copy of >>>> your config files so i can look for differences. I am using the android >>>> toolchain file from the same location as Stephen. >>> > I had a play with the android mkspecs the other day, but didn't get > anywhere. This is probably due to my very limited understanding of the > Qt build system, i'll have another play today if anyone has suggestions > i'd love to here them, i'm also sitting around on irc as Simotek-Work > > Cheers > > Simon > . > Hi All, i have come up with a solution that works, it's by no means great and i am wondering if anyone can give us some improvements. Firstly i added the following two lines to the android mkspecs QMAKE_LFLAGS_SONAME = -Wl,-soname= QMAKE_LFLAGS_RPATH = -Wl,-rpath=/system/lib this embeds SONAME libQt5x.so.5 into the Qt Libraries and NEEDED libQt5Core.so.5 this is a good start as it removes the fixed path from the needed line. It still causes issues on android however, as it tries to load libQt5Core.so.5 etc that does not exist. I was unable to find a nice way to work around this and i would appreciate help if anyone can provide it. The process i ended up taking was to modify the makefiles so that they contained in the LFLAGS '-soname=libQt5x.so' instead of '-soname=libQt5x.so.5' . To do this first i created the make files by configuring then running 'make qmake_all' after that i ran the following command in the top level dir to modify all the makefiles. find . -name "Makefile" -exec perl -pe "if (m/^LFLAG/) { s/.so.5/.so/; }" -F -i '{}' \; i then ran 'make' to build all the Qt libraries. When i use cmake to build a application against these libraries i end up with NEEDED libQt5Core.so in my shared library which works fine on android. Cheers, Simon From miaoyuwf at 163.com Wed Jul 17 08:09:01 2013 From: miaoyuwf at 163.com (miaoyuwf) Date: Wed, 17 Jul 2013 14:09:01 +0800 Subject: [Development] How to change the bit order of the data writen into the framebuffer by Qt Message-ID: <201307171409007811761@163.com> hi, I have got a special used:my system is 4bit color depths,so I config the Qt depths 4. But the data in the frame buffer is like this: pix1(4bit),pix2(4bit),pix3(4bit),pix4(4bit),…………., pix1(4bit) and pix2(4bit) are put together into one byte , and pix1(4bit) take the high 4 bit position , pix2(4bit) take the low 4 bit position , so was pix3 and pixel4 , pixel5 and pixel6 ………………. . actually , I need the data order like this : pix2(4bit),pix1(4bit),pix4(4bit),pix3(4bit),………… , pix1(4bit) and pix2(4bit) are put together into one byte , and pix2(4bit) take the high 4 bit position , pix1(4bit) take the low 4 bit position , so was pix4 and pixel3 , pixel6 and pixel5 ………………. . Is there a good way to deal with it ? Thanks & Regards, **************************************************************************** Miao yu Mobile: +86-15951652750 Mail: miaoyuwf at 163.com ***************************************************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From yves.bailly at sescoi.fr Wed Jul 17 08:27:30 2013 From: yves.bailly at sescoi.fr (Yves Bailly) Date: Wed, 17 Jul 2013 08:27:30 +0200 Subject: [Development] Creating an offline installer In-Reply-To: <51E548E6.6060001@digia.com> References: <51E4F8C8.6030707@sescoi.fr> <51E50946.6000904@digia.com> <51E54563.2020202@sescoi.fr> <51E548E6.6060001@digia.com> Message-ID: <51E63952.8030906@sescoi.fr> Le 16/07/2013 15:21, Sergio Ahumada a écrit : > On 07/16/2013 03:06 PM, Yves Bailly wrote: >> Le 16/07/2013 10:50, Sergio Ahumada a écrit : >>> On 07/16/2013 09:39 AM, Yves Bailly wrote: >>>> [...] >>>> INSTALLER_FRAMEWORK_PRODUCT_KEY_CHECKER_BRANCH >>>> TypeError: __init__() takes exactly 10 arguments (9 given) >>> >>> Hi, >>> >>> You could try this patch https://codereview.qt-project.org/61092 >>> >>> Also, I'd say the README file is pretty out-of-date, so if you find >>> errors you could maybe provide some fixes in Gerrit. >> >> Thanks for your input... now I'm experiencing troubles when it tries to >> "git clone" the installer framework, firewall problem... > > There is an attempt to create a python script to handle all the needed > steps at https://codereview.qt-project.org/54538 > > You could also try http://qt-project.org/wiki/Building-Qt-Package > > Both are pretty much work in progress though. Hello, it's me again trying to create an offline installer... Now I'm having trouble with tar: Executing: [tar -xzf D:\qt\release-tools\qt_4.8.4_ifw_prepared.tar.gz] Execution path: [D:\qt\release-tools\qt-src] Abort on fail: [True] tar (child): Cannot execute remote shell: No such file or directory tar (child): D\:\\qt\\release-tools\\qt_4.8.4_ifw_prepared.tar.gz: Cannot open: I/O error tar (child): Error is not recoverable: exiting now It seems the "tar" command which is used comes from my Git installation, but it seems it doesn't work - usual mess with (back)slashes probably. Is there a "recommended" tar I should use? Should I install MSYS, Cygwin, or whatever? Thanks again for your help. -- /- Yves Bailly - Software developer -\ \- Sescoi R&D - http://www.sescoi.fr -/ "The possible is done. The impossible is being done. For miracles, thanks to allow a little delay." From andreas.holzammer at kdab.com Wed Jul 17 08:54:09 2013 From: andreas.holzammer at kdab.com (Andreas Holzammer) Date: Wed, 17 Jul 2013 08:54:09 +0200 Subject: [Development] Creating an offline installer In-Reply-To: <51E63952.8030906@sescoi.fr> References: <51E4F8C8.6030707@sescoi.fr> <51E50946.6000904@digia.com> <51E54563.2020202@sescoi.fr> <51E548E6.6060001@digia.com> <51E63952.8030906@sescoi.fr> Message-ID: <51E63F91.7030506@kdab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, this is broken at the moment. It was changed from Qt 4.8.0 which had a bug in language support to Qt 4.8.4 But then it was also changed from 7z to tar gz, which is not very well supported in Windows. Also another slide glitch went in with this change. the Qt 4.8.0 was patched to link against the static c++ runtime. But yeah apparently thats not the case anymore with the Qt 4.8.4 package. Please deflate the archive to \release-tools\qt-src and patch accordingly to http://qt.gitorious.org/installer-framework/installer-framework/blobs/master/INSTALL Then you can call the script with --incremental and he should just go forward. Hope this helps Andy Am 17.07.2013 08:27, schrieb Yves Bailly: > Le 16/07/2013 15:21, Sergio Ahumada a écrit : >> On 07/16/2013 03:06 PM, Yves Bailly wrote: >>> Le 16/07/2013 10:50, Sergio Ahumada a écrit : >>>> On 07/16/2013 09:39 AM, Yves Bailly wrote: >>>>> [...] INSTALLER_FRAMEWORK_PRODUCT_KEY_CHECKER_BRANCH >>>>> TypeError: __init__() takes exactly 10 arguments (9 given) >>>> >>>> Hi, >>>> >>>> You could try this patch >>>> https://codereview.qt-project.org/61092 >>>> >>>> Also, I'd say the README file is pretty out-of-date, so if >>>> you find errors you could maybe provide some fixes in >>>> Gerrit. >>> >>> Thanks for your input... now I'm experiencing troubles when it >>> tries to "git clone" the installer framework, firewall >>> problem... >> >> There is an attempt to create a python script to handle all the >> needed steps at https://codereview.qt-project.org/54538 >> >> You could also try >> http://qt-project.org/wiki/Building-Qt-Package >> >> Both are pretty much work in progress though. > > Hello, it's me again trying to create an offline installer... > > Now I'm having trouble with tar: Executing: [tar -xzf > D:\qt\release-tools\qt_4.8.4_ifw_prepared.tar.gz] Execution path: > [D:\qt\release-tools\qt-src] Abort on fail: [True] tar (child): > Cannot execute remote shell: No such file or directory tar (child): > D\:\\qt\\release-tools\\qt_4.8.4_ifw_prepared.tar.gz: Cannot open: > I/O error tar (child): Error is not recoverable: exiting now > > It seems the "tar" command which is used comes from my Git > installation, but it seems it doesn't work - usual mess with > (back)slashes probably. Is there a "recommended" tar I should use? > Should I install MSYS, Cygwin, or whatever? > > Thanks again for your help. > - -- Join us in October at Qt Developer Days 2013! - https://devdays.kdab.com Andreas Holzammer | andreas.holzammer at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5j+RAAoJEPj+uOw7/REi1D4P/0wZtq9MZKT0oH1qFi7zDJfO kb/m1cfsjIeOKPQsqGaENnKISA1N+05LAWtGdjf56qG7Bd/MIB4NSTfEu4pevpWO H/jzFjzEX1unz+L3gMMxBjAsCKB3OcqZA7JOkfydvEYWcgMd4Q/Bw4nRdkOSMLTE FiGvPlyAf8ex7+awjA66kPoXgVVMq7uDgzeLdqxgViNBIChwoAudKyUi4JBnrm2B 9GEIuEIsM3Y9CUFQDO1s/kCIA7vc/Z2Qfevv/CFYYXjeYyh3vgFurAMznsaXBHBg iPk09r31LSFgUEc3j20JTo8mcNqdFJ/BeM5cu1eTICjdgGe35M344wiTAGMZnbo3 bbmB3pNBHzJpPM8J+CM3d+U6XtsKx7dF9HLy7P5tcauL7Io24popDPVkM+vwOAjw oRpGW1f3j5VSy2NxS3lznL5Dpd70M6Piz+pOjqf+huG7d+trseuDv6aHs9rZQOKr mGunBaCTknydQxEKL1LXH3tExa4d2wVjRNoCT5MaWYu1ImiaFxnXH2/rtU5gjc77 czK2/LBVt7REDJE+7DFNq+LK4n/tn8b0OQ4kyEw1Now/w5sBeLAN3+RWo2YxlSfM 59xIGVZWZ4IRxuowREYY/2ioft+OjJ7m9rElQJveBIasWHGaE1O1iO7zrW20/oy1 hLjYtaZFMR0f41R5ax/g =1s+Y -----END PGP SIGNATURE----- From yves.bailly at sescoi.fr Wed Jul 17 09:07:38 2013 From: yves.bailly at sescoi.fr (Yves Bailly) Date: Wed, 17 Jul 2013 09:07:38 +0200 Subject: [Development] Creating an offline installer In-Reply-To: <51E63F91.7030506@kdab.com> References: <51E4F8C8.6030707@sescoi.fr> <51E50946.6000904@digia.com> <51E54563.2020202@sescoi.fr> <51E548E6.6060001@digia.com> <51E63952.8030906@sescoi.fr> <51E63F91.7030506@kdab.com> Message-ID: <51E642BA.9040709@sescoi.fr> Hello Andreas, Le 17/07/2013 08:54, Andreas Holzammer a écrit : > -----BEGIN PGP SIGNED MESSAGE----- > this is broken at the moment. It was changed from Qt 4.8.0 which had a > bug in language support to Qt 4.8.4 But then it was also changed from > 7z to tar gz, which is not very well supported in Windows. Also > another slide glitch went in with this change. the Qt 4.8.0 was > patched to link against the static c++ runtime. But yeah apparently > thats not the case anymore with the Qt 4.8.4 package. Please deflate > the archive to \release-tools\qt-src and patch accordingly to ...stripping the top-level directory... ;-) > http://qt.gitorious.org/installer-framework/installer-framework/blobs/master/INSTALL Something is strange in this file. It says: "- add 'embed_manifest_dll embed_manifest_exe' to CONFIG line" ...but looking at the "diff" given below, I see: -CONFIG += qt warn_on release incremental flat link_prl precompile_header autogen_precompile_source copy_dir_files debug_and_release debug_and_release_target embed_manifest_dll embed_manifest_exe +CONFIG += qt warn_on release incremental flat link_prl precompile_header autogen_precompile_source copy_dir_files debug_and_release debug_and_release_target ...where it seems the options "embed_manifest_dll embed_manifest_exe" have been *removed*, not added. Trusting the diff I'm removing them, after all manifests are useless in a static build. > Then you can call the script with --incremental and he should just go > forward. Nope... now it complains it can't find qmake: ----------------------------------------- INCREMENTAL_MODE D:\qt\release-tools\ifw-bld -------------------------------------------------------------------- Building Installer Framework *** Unable to find qmake, aborting! qmake: D:\qt\release-tools\qt-bld\bin\qmake.exe I'll try to build manually and copy files where needed. > Hope this helps It does :-) Thanks for your help. > > Am 17.07.2013 08:27, schrieb Yves Bailly: >> Le 16/07/2013 15:21, Sergio Ahumada a écrit : >>> On 07/16/2013 03:06 PM, Yves Bailly wrote: >>>> Le 16/07/2013 10:50, Sergio Ahumada a écrit : >>>>> On 07/16/2013 09:39 AM, Yves Bailly wrote: >>>>>> [...] INSTALLER_FRAMEWORK_PRODUCT_KEY_CHECKER_BRANCH >>>>>> TypeError: __init__() takes exactly 10 arguments (9 given) >>>>> >>>>> Hi, >>>>> >>>>> You could try this patch >>>>> https://codereview.qt-project.org/61092 >>>>> >>>>> Also, I'd say the README file is pretty out-of-date, so if >>>>> you find errors you could maybe provide some fixes in >>>>> Gerrit. >>>> >>>> Thanks for your input... now I'm experiencing troubles when it >>>> tries to "git clone" the installer framework, firewall >>>> problem... >>> >>> There is an attempt to create a python script to handle all the >>> needed steps at https://codereview.qt-project.org/54538 >>> >>> You could also try >>> http://qt-project.org/wiki/Building-Qt-Package >>> >>> Both are pretty much work in progress though. >> >> Hello, it's me again trying to create an offline installer... >> >> Now I'm having trouble with tar: Executing: [tar -xzf >> D:\qt\release-tools\qt_4.8.4_ifw_prepared.tar.gz] Execution path: >> [...] -- /- Yves Bailly - Software developer -\ \- Sescoi R&D - http://www.sescoi.fr -/ "The possible is done. The impossible is being done. For miracles, thanks to allow a little delay." From andreas.holzammer at kdab.com Wed Jul 17 09:19:43 2013 From: andreas.holzammer at kdab.com (Andreas Holzammer) Date: Wed, 17 Jul 2013 09:19:43 +0200 Subject: [Development] Creating an offline installer In-Reply-To: <51E642BA.9040709@sescoi.fr> References: <51E4F8C8.6030707@sescoi.fr> <51E50946.6000904@digia.com> <51E54563.2020202@sescoi.fr> <51E548E6.6060001@digia.com> <51E63952.8030906@sescoi.fr> <51E63F91.7030506@kdab.com> <51E642BA.9040709@sescoi.fr> Message-ID: <51E6458F.9080309@kdab.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 17.07.2013 09:07, schrieb Yves Bailly: > Hello Andreas, > > Le 17/07/2013 08:54, Andreas Holzammer a écrit : >> -----BEGIN PGP SIGNED MESSAGE----- this is broken at the moment. >> It was changed from Qt 4.8.0 which had a bug in language support >> to Qt 4.8.4 But then it was also changed from 7z to tar gz, which >> is not very well supported in Windows. Also another slide glitch >> went in with this change. the Qt 4.8.0 was patched to link >> against the static c++ runtime. But yeah apparently thats not the >> case anymore with the Qt 4.8.4 package. Please deflate the >> archive to \release-tools\qt-src and patch accordingly to > > ...stripping the top-level directory... ;-) > >> http://qt.gitorious.org/installer-framework/installer-framework/blobs/master/INSTALL > >> > Something is strange in this file. It says: "- add > 'embed_manifest_dll embed_manifest_exe' to CONFIG line" > > ...but looking at the "diff" given below, I see: > > -CONFIG += qt warn_on release incremental flat > link_prl precompile_header autogen_precompile_source copy_dir_files > debug_and_release debug_and_release_target embed_manifest_dll > embed_manifest_exe > > +CONFIG += qt warn_on release incremental flat > link_prl precompile_header autogen_precompile_source copy_dir_files > debug_and_release debug_and_release_target Hmm this needs no change. But this is the important part: - -QMAKE_CFLAGS_RELEASE = -O2 -MD - -QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO += -O2 -MD -Zi - -QMAKE_CFLAGS_DEBUG = -Zi -MDd +QMAKE_CFLAGS_RELEASE = -O2 -MT +QMAKE_CFLAGS_RELEASE_WITH_DEBUGINFO += -O2 -MT -Zi +QMAKE_CFLAGS_DEBUG = -Zi -MTd > > > ...where it seems the options "embed_manifest_dll > embed_manifest_exe" have been *removed*, not added. Trusting the > diff I'm removing them, after all manifests are useless in a static > build. > >> Then you can call the script with --incremental and he should >> just go forward. > > Nope... now it complains it can't find qmake: Hm did you remove the directory D:\qt\release-tools\ifw-bld ? hope then it works. Andy > ----------------------------------------- INCREMENTAL_MODE > D:\qt\release-tools\ifw-bld > -------------------------------------------------------------------- > > Building Installer Framework > *** Unable to find qmake, aborting! qmake: > D:\qt\release-tools\qt-bld\bin\qmake.exe > > I'll try to build manually and copy files where needed. > >> Hope this helps > > It does :-) Thanks for your help. > > > >> >> Am 17.07.2013 08:27, schrieb Yves Bailly: >>> Le 16/07/2013 15:21, Sergio Ahumada a écrit : >>>> On 07/16/2013 03:06 PM, Yves Bailly wrote: >>>>> Le 16/07/2013 10:50, Sergio Ahumada a écrit : >>>>>> On 07/16/2013 09:39 AM, Yves Bailly wrote: >>>>>>> [...] INSTALLER_FRAMEWORK_PRODUCT_KEY_CHECKER_BRANCH >>>>>>> TypeError: __init__() takes exactly 10 arguments (9 >>>>>>> given) >>>>>> >>>>>> Hi, >>>>>> >>>>>> You could try this patch >>>>>> https://codereview.qt-project.org/61092 >>>>>> >>>>>> Also, I'd say the README file is pretty out-of-date, so >>>>>> if you find errors you could maybe provide some fixes in >>>>>> Gerrit. >>>>> >>>>> Thanks for your input... now I'm experiencing troubles when >>>>> it tries to "git clone" the installer framework, firewall >>>>> problem... >>>> >>>> There is an attempt to create a python script to handle all >>>> the needed steps at https://codereview.qt-project.org/54538 >>>> >>>> You could also try >>>> http://qt-project.org/wiki/Building-Qt-Package >>>> >>>> Both are pretty much work in progress though. >>> >>> Hello, it's me again trying to create an offline installer... >>> >>> Now I'm having trouble with tar: Executing: [tar -xzf >>> D:\qt\release-tools\qt_4.8.4_ifw_prepared.tar.gz] Execution >>> path: [...] > - -- Join us in October at Qt Developer Days 2013! - https://devdays.kdab.com Andreas Holzammer | andreas.holzammer at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR5kWOAAoJEPj+uOw7/REiUCsP+wTivJX0+PM46hroHifn3Ff2 KorGAmaRyBx1FiaEp6pFAxJqX1gA0gPw2Ra04X49DmU4Vd7JQxB/y1GKkdcBuPni +ugsG56Cfy/wKiXUkRNWLKfAW10HuVp/Wu1V1Z4TBA9dEOSG9V/wUsYIN7Txr0HE q1xl2Wdg0XSjnCOSLR7kElaKj4H7ya56Yz9WSHwtNUAwQNUogEeCOf+jPiEglglg z9dppOVPWUal2pvd+CPapZwkGkeqOVMHjMNxNiDSGpcmwL0AQN3maGOsospzWoLr s5sv3hVcNtmbrJjgUTJolIxDkM5EJB/RGadZFM+uNV3Bh1OwG8Q0gtzQSRPoEQea 6itk1fxvYtISH6goIJYnMlQXqHhwfW18/ncADKOPq3mNn1rAPvyMpEtce5TT0+XX ZSFiwp6w/liE69mXRwTpi/XCNZZCjc7HykDYlWWt63q7Wn8PvnuKCIHzRcaGrH1E kSTUGVZGtnyBu6dOIDmEkYx2nZeKnUKOcxgUYFWpiTiryrnRJeG3qDsggWu/K6hD NobrnT+1D/uyKiN4serU+yEuOqQMeHxfSpJ8zXXVxlQ3Zn9z8QcWRkoxxb9FyXdY +Y41FuhI5yRNr/ybIFoRuCxfZpJUayqXWG2wRzqbw7r4e70tWiS0/hZsXBTeVHrY mNfKybBL+s/NMTBwMr6W =t5kb -----END PGP SIGNATURE----- From oswald.buddenhagen at digia.com Wed Jul 17 09:34:04 2013 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Wed, 17 Jul 2013 09:34:04 +0200 Subject: [Development] Changelogs for Qt 5.1.x and 5.2 In-Reply-To: <10577726.kxE7y6OR7V@tjmaciei-mobl2> References: <10577726.kxE7y6OR7V@tjmaciei-mobl2> Message-ID: <20130717073404.GA20224@troll08.it.local> On Tue, Jul 16, 2013 at 12:22:55PM +0200, Thiago Macieira wrote: > 3) the format for the changelog is: > > a) auto-guess module from the paths changed > [ChangeLog] Here is my slightly verbose text explaining that I've done > something awesome and should tell people about it. > so be it. fwiw, it might be possible to use syncqt output (or code) to do (much of) the inferring. > b) explicit heading in the changelog: > [ChangeLog] > [Important Behavior Changes] > this is overly verbose. also, people already manage to "misspell" ChangeLog in every imaginable way. it must be something short and memorable - maybe "[!]" or something like that. > [ChangeLog][QtCore][QUrl / QUrlQuery] Blah blah blah > adding additional "untagged" information is a recipe for chaos. you should make it as terse and formal as reasonable. then i can trim the sanity bot to identify changelog entries and moan about (likely) mistakes. From yves.bailly at sescoi.fr Wed Jul 17 09:38:29 2013 From: yves.bailly at sescoi.fr (Yves Bailly) Date: Wed, 17 Jul 2013 09:38:29 +0200 Subject: [Development] Creating an offline installer In-Reply-To: <51E6458F.9080309@kdab.com> References: <51E4F8C8.6030707@sescoi.fr> <51E50946.6000904@digia.com> <51E54563.2020202@sescoi.fr> <51E548E6.6060001@digia.com> <51E63952.8030906@sescoi.fr> <51E63F91.7030506@kdab.com> <51E642BA.9040709@sescoi.fr> <51E6458F.9080309@kdab.com> Message-ID: <51E649F5.3000002@sescoi.fr> Le 17/07/2013 09:19, Andreas Holzammer a écrit : > -----BEGIN PGP SIGNED MESSAGE----->>> Then you can call the script with --incremental and he should >>> just go forward. >> Nope... now it complains it can't find qmake: > Hm did you remove the directory D:\qt\release-tools\ifw-bld ? > hope then it works. Removed the folder, but still the same complain about missing qmake. Nevermind, compiling "manually" then I'll move the files where needed... -- /- Yves Bailly - Software developer -\ \- Sescoi R&D - http://www.sescoi.fr -/ "The possible is done. The impossible is being done. For miracles, thanks to allow a little delay." From oswald.buddenhagen at digia.com Wed Jul 17 09:51:11 2013 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Wed, 17 Jul 2013 09:51:11 +0200 Subject: [Development] Qt CS 2013 Documentation Session In-Reply-To: References: Message-ID: <20130717075111.GB20224@troll08.it.local> On Tue, Jul 16, 2013 at 02:38:19PM +0000, Pasion Jerome wrote: > Some ideas, wishes, and proposals brought up in the session: > a recurring topic is translatability of the documentation. this encompasses extraction (paragraph-wise, though further segmentation into sentences may be advantageous as well) and back-merging of translated strings (either into a separate document (in particular when apidocs are being translated), or an "on-the-fly" integration, where qdoc takes the original sources and a translation (.ts) file, and directly outputs translated html). qdoc (just like doxygen) is a rather terrible format in this regard - one needs to do quite some semantic processing of the markup before it's clear what a "paragraph" actually is. therefore it's likely that the string extraction/replacement needs to be a special mode of qdoc itself. From yves.bailly at sescoi.fr Wed Jul 17 10:41:23 2013 From: yves.bailly at sescoi.fr (Yves Bailly) Date: Wed, 17 Jul 2013 10:41:23 +0200 Subject: [Development] Creating an offline installer In-Reply-To: <51E649F5.3000002@sescoi.fr> References: <51E4F8C8.6030707@sescoi.fr> <51E50946.6000904@digia.com> <51E54563.2020202@sescoi.fr> <51E548E6.6060001@digia.com> <51E63952.8030906@sescoi.fr> <51E63F91.7030506@kdab.com> <51E642BA.9040709@sescoi.fr> <51E6458F.9080309@kdab.com> <51E649F5.3000002@sescoi.fr> Message-ID: <51E658B3.4060300@sescoi.fr> Le 17/07/2013 09:38, Yves Bailly a écrit : > Le 17/07/2013 09:19, Andreas Holzammer a écrit : >> -----BEGIN PGP SIGNED MESSAGE----->>> Then you can call the script with --incremental and he should >>>> just go forward. >>> Nope... now it complains it can't find qmake: >> Hm did you remove the directory D:\qt\release-tools\ifw-bld ? >> hope then it works. > > Removed the folder, but still the same complain about missing qmake. Nevermind, compiling > "manually" then I'll move the files where needed... So here where I am now. I build the downloaded Qt 4.8.4 "manually" in release-tools/qt-src, using the configure recommended in http://qt.gitorious.org/installer-framework/installer-framework/blobs/master/INSTALL. Then I copied everything from release-tools/qt-src to release-tools/qt-bld, so that the "create_installer.py" script can find the needed "qmake.exe" - I know, copying everything is most probably overkill, but at least it's simple and easy. Restarting the script, it choked on being unable to open a file for writing: configurations\sescoi_qt5\qt.desktop.511.msvc2012_32\meta ##### get components data ##### 0: adding to qt.desktop.511.msvc2012_32 0: -create Error-Exception: "Cannot open file D:\qt\release-tools\pkg\qt.desktop.511.msvc2012_32\data for writing: Access denied." caught exception: Cannot open file D:\qt\release-tools\pkg\qt.desktop.511.msvc2012_32\data for writing: Access denied. But it's a directory, not a file... maybe some system lock remaining somewhere, I'm on Windows after all. Relaunching the script, fixed a few things here and there in config files, finally I get an off-line installer... which has a size of 12MB, impressive given the size of my binaries archive, which is actually 191MB... seems I created an empty installer. I'll continue trying to get something usable, but I'm getting close to give up. All that work so that others can use the binaries I compiled on my machine, it begins to be quite expensive. I've promoted Qt for years, but I'm having hard times here. -- /- Yves Bailly - Software developer -\ \- Sescoi R&D - http://www.sescoi.fr -/ "The possible is done. The impossible is being done. For miracles, thanks to allow a little delay." From cavendish.qi at gmail.com Wed Jul 17 11:05:48 2013 From: cavendish.qi at gmail.com (Liang Qi) Date: Wed, 17 Jul 2013 11:05:48 +0200 Subject: [Development] Qt CS 2013 Documentation Session In-Reply-To: <20130717075111.GB20224@troll08.it.local> References: <20130717075111.GB20224@troll08.it.local> Message-ID: On 17 July 2013 09:51, Oswald Buddenhagen wrote: > > On Tue, Jul 16, 2013 at 02:38:19PM +0000, Pasion Jerome wrote: > > Some ideas, wishes, and proposals brought up in the session: > > > a recurring topic is translatability of the documentation. > > this encompasses extraction (paragraph-wise, though further segmentation > into sentences may be advantageous as well) and back-merging of > translated strings (either into a separate document (in particular when > apidocs are being translated), or an "on-the-fly" integration, where > qdoc takes the original sources and a translation (.ts) file, and > directly outputs translated html). > > qdoc (just like doxygen) is a rather terrible format in this regard - > one needs to do quite some semantic processing of the markup before it's > clear what a "paragraph" actually is. therefore it's likely that the > string extraction/replacement needs to be a special mode of qdoc itself. > n Qt 4, we support the separate .qdoc files way for translations, please check zh_CN and ja_JP folders in https://github.com/qtproject/qt/tree/4.8/doc/src . And we still missing support for the docs in source code, task as https://bugreports.qt-project.org/browse/QTBUG-12919 Maybe the original .qdoc + .ts solution is also ok, but we can imagine what should be done when .qdoc was updated and .ts not, how to sync them? Is it easy to be fixed in some way? Then I still prefer the separate doc files solution, but we could add a tag for the translation, mention the original doc's information, like sha1 and etc. Regards, Liang -- http://www.qiliang.net From oswald.buddenhagen at digia.com Wed Jul 17 12:49:08 2013 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Wed, 17 Jul 2013 12:49:08 +0200 Subject: [Development] Qt CS 2013 Documentation Session In-Reply-To: References: <20130717075111.GB20224@troll08.it.local> Message-ID: <20130717104908.GC20224@troll08.it.local> On Wed, Jul 17, 2013 at 11:05:48AM +0200, Liang Qi wrote: > On 17 July 2013 09:51, Oswald Buddenhagen wrote: > > a recurring topic is translatability of the documentation. > > > in Qt 4, we support the separate .qdoc files way for translations, > please check zh_CN and ja_JP folders > i'm well aware of these files. they are the problem, not the solution. From simon.hausmann at digia.com Wed Jul 17 16:22:08 2013 From: simon.hausmann at digia.com (Simon Hausmann) Date: Wed, 17 Jul 2013 16:22:08 +0200 Subject: [Development] Introducing QtMetrics In-Reply-To: References: Message-ID: <1531303.92G9VBh3rC@rhea> On Tuesday 4. June 2013 10.13.16 Sarajärvi Tony wrote: > Hi > > We are ready to launch our QtMetrics page for the public now. Great stuff! [...] > Note 2: The data you see is currently manually kept up to date about once a > day. This will be changed as soon as we have time to implement an automated > function for this that triggers after a build. For me this one is going to be the game changer :). I've used the dashboard in the past weeks to tyr to get a better overview of the test failures of a topic branch, and the infrequent updates are what makes it a bit harder to work with. I hope you'll find time soon to implement automatic frequent updates of the database :) The only other thing that comes to my mind that would be nice to improve is the lack of a state changes in the UI being reflected in the URL, making it impossible for example to copy & paste the url to somebody to show them the current "state". Simon From dangelog at gmail.com Wed Jul 17 21:45:11 2013 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Wed, 17 Jul 2013 21:45:11 +0200 Subject: [Development] Changelogs for Qt 5.1.x and 5.2 In-Reply-To: <12614139.WXW4t4Kr3v@tjmaciei-mobl2> References: <10577726.kxE7y6OR7V@tjmaciei-mobl2> <3303623.NVueA9tLqp@tjmaciei-mobl2> <51E53F39.5000004@digia.com> <12614139.WXW4t4Kr3v@tjmaciei-mobl2> Message-ID: On 16 July 2013 17:55, Thiago Macieira wrote: > > [ChangeLog][Important Behavior Changes][QUrl and QUrlQuery] QUrl no > longer supports QUrl::FullyDecoded mode in authority() and userInfo(), > nor QUrl::DecodedMode in setAuthority() and setUserInfo(). I 100% agree with having the changelog entry in the commit message, but I fear the complexity there. We should try to work towards error-proof entries -- I fear that too many people will mispell "Important Behavior Changes" or similar, causing frustation when the sanity bots complains. Can we devise something simpler? Can we also put in our policies an example of how a changelog file is structured, and what are the right tags to use to add an entry to a given section? -- Giuseppe D'Angelo From thiago.macieira at intel.com Thu Jul 18 02:34:56 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Jul 2013 19:34:56 -0500 Subject: [Development] Changelogs for Qt 5.1.x and 5.2 In-Reply-To: References: <10577726.kxE7y6OR7V@tjmaciei-mobl2> <12614139.WXW4t4Kr3v@tjmaciei-mobl2> Message-ID: <2021469.XXFTCBHLfg@tjmaciei-mobl2> On quarta-feira, 17 de julho de 2013 21.45.11, Giuseppe D'Angelo wrote: > I 100% agree with having the changelog entry in the commit message, > but I fear the complexity there. We should try to work towards > error-proof entries -- I fear that too many people will mispell > "Important Behavior Changes" or similar, causing frustation when the > sanity bots complains. I don't see that a problem. I can do a case-insensitive comparison when grouping and the changelog is meant to be proof-read by a human anyway. Also, don't forget we have a Rohanbot that is doing spellchecking. > Can we devise something simpler? Can we also put in our policies an > example of how a changelog file is structured, and what are the right > tags to use to add an entry to a given section? "Use the tags that appear in the changelog file" -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From lpapp at kde.org Thu Jul 18 11:08:36 2013 From: lpapp at kde.org (Laszlo Papp) Date: Thu, 18 Jul 2013 10:08:36 +0100 Subject: [Development] Qt CS 2013 Documentation Session In-Reply-To: References: Message-ID: Thank you for the notes! On Tue, Jul 16, 2013 at 3:38 PM, Pasion Jerome wrote: > - Links in the pages can go to the overview, C++ page, QML page, or > elsewhere, which is confusing. > DoxyQML was shortly mentioned as the Plasma Active QML components is using that. After a bit of discussion with the maintainer of that project before yesterday, my impression is that it is more like an adapter between C++ (what doxygen expects) and the QML end user interface. So, it feels like a nice workaround rather than an optimal design. That is what one can achieve with the doxygen filters and own tokenizer as far as I understand. Here you can find an example how C++'ish it looks like instead of more native: http://api.kde.org/4.x-api/kde-runtime-apidocs/plasma/declarativeimports/plasmacomponents/html/index.html Cheers, Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From 416365416c at gmail.com Thu Jul 18 12:10:31 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 18 Jul 2013 03:10:31 -0700 Subject: [Development] QtQuick ML Message-ID: With the Qt CS sessions now over, I'd be happy to send a summary of the QtQuick sessions to the ML. But we're looking at half a dozen emails here, so I'd first like to know if we've come to a decision on whether to have a separate qt-quick at qt-project.org ML? It's the same concept as the #qt-quick IRC channel, including that we have a very weak developers/users split with QtQuick (because QtQuick.Controls uses QtQuick uses QtQml - same as many users who may also use QtQuick.Controls). Any objections? If people are still objecting to this idea, I'll just use [QtQuick] in the subject to this ML as a half-way measure. It's just going to be a little harder for people to set their email filters on. -- Alan Alpert From rich at kde.org Thu Jul 18 14:18:32 2013 From: rich at kde.org (Richard Moore) Date: Thu, 18 Jul 2013 13:18:32 +0100 Subject: [Development] Changelogs for Qt 5.1.x and 5.2 In-Reply-To: <2021469.XXFTCBHLfg@tjmaciei-mobl2> References: <10577726.kxE7y6OR7V@tjmaciei-mobl2> <12614139.WXW4t4Kr3v@tjmaciei-mobl2> <2021469.XXFTCBHLfg@tjmaciei-mobl2> Message-ID: On 18 July 2013 01:34, Thiago Macieira wrote: > On quarta-feira, 17 de julho de 2013 21.45.11, Giuseppe D'Angelo wrote: >> Can we devise something simpler? Can we also put in our policies an >> example of how a changelog file is structured, and what are the right >> tags to use to add an entry to a given section? > > "Use the tags that appear in the changelog file" They should be listed in the commit log template to make it easy for people to just copy them. Rich. From oswald.buddenhagen at digia.com Thu Jul 18 15:07:27 2013 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Thu, 18 Jul 2013 15:07:27 +0200 Subject: [Development] QtQuick ML In-Reply-To: References: Message-ID: <20130718130727.GA931@troll08.it.local> On Thu, Jul 18, 2013 at 03:10:31AM -0700, Alan Alpert wrote: > I'd first like to know if we've come to a decision on > whether to have a separate qt-quick at qt-project.org ML? > i wonder how many more times you want to re-iterate this? do you have any *new* arguments in favor of this fragmentation? From 416365416c at gmail.com Thu Jul 18 15:18:43 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 18 Jul 2013 06:18:43 -0700 Subject: [Development] QtQuick ML In-Reply-To: <20130718130727.GA931@troll08.it.local> References: <20130718130727.GA931@troll08.it.local> Message-ID: On Thu, Jul 18, 2013 at 6:07 AM, Oswald Buddenhagen wrote: > On Thu, Jul 18, 2013 at 03:10:31AM -0700, Alan Alpert wrote: >> I'd first like to know if we've come to a decision on >> whether to have a separate qt-quick at qt-project.org ML? >> > i wonder how many more times you want to re-iterate this? do you have > any *new* arguments in favor of this fragmentation? You're right. Nothing has changed in the last month since this was proposed and no-one objected. I'd like to resubmit my question as: Can the mailing list administrator please create the qt-quick at qt-project.org ML? -- Alan Alpert From oswald.buddenhagen at digia.com Thu Jul 18 15:44:07 2013 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Thu, 18 Jul 2013 15:44:07 +0200 Subject: [Development] QtQuick ML In-Reply-To: References: <20130718130727.GA931@troll08.it.local> Message-ID: <20130718134407.GB931@troll08.it.local> On Thu, Jul 18, 2013 at 06:18:43AM -0700, Alan Alpert wrote: > On Thu, Jul 18, 2013 at 6:07 AM, Oswald Buddenhagen > wrote: > > On Thu, Jul 18, 2013 at 03:10:31AM -0700, Alan Alpert wrote: > >> I'd first like to know if we've come to a decision on > >> whether to have a separate qt-quick at qt-project.org ML? > >> > > i wonder how many more times you want to re-iterate this? do you have > > any *new* arguments in favor of this fragmentation? > > You're right. Nothing has changed in the last month since this was > proposed and no-one objected. > nice try. http://lists.qt-project.org/pipermail/development/2012-December/008376.html From 416365416c at gmail.com Thu Jul 18 15:51:08 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 18 Jul 2013 06:51:08 -0700 Subject: [Development] QtQuick ML In-Reply-To: <20130718134407.GB931@troll08.it.local> References: <20130718130727.GA931@troll08.it.local> <20130718134407.GB931@troll08.it.local> Message-ID: On Thu, Jul 18, 2013 at 6:44 AM, Oswald Buddenhagen wrote: > On Thu, Jul 18, 2013 at 06:18:43AM -0700, Alan Alpert wrote: >> On Thu, Jul 18, 2013 at 6:07 AM, Oswald Buddenhagen >> wrote: >> > On Thu, Jul 18, 2013 at 03:10:31AM -0700, Alan Alpert wrote: >> >> I'd first like to know if we've come to a decision on >> >> whether to have a separate qt-quick at qt-project.org ML? >> >> >> > i wonder how many more times you want to re-iterate this? do you have >> > any *new* arguments in favor of this fragmentation? >> >> You're right. Nothing has changed in the last month since this was >> proposed and no-one objected. >> > nice try. > http://lists.qt-project.org/pipermail/development/2012-December/008376.html Wrong, I'm referring to this: http://lists.qt-project.org/pipermail/qt-components/2013-June/000304.html You probably didn't see it because you're not interested in QtQuick so don't subscribe to all the QtQuick MLs. But we've had the QtQuick.Controls discussions there for months with no complaint, so the model seems to work fine. -- Alan Alpert From 416365416c at gmail.com Thu Jul 18 16:04:08 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 18 Jul 2013 07:04:08 -0700 Subject: [Development] QtQuick ML In-Reply-To: References: <20130718130727.GA931@troll08.it.local> <20130718134407.GB931@troll08.it.local> Message-ID: On Thu, Jul 18, 2013 at 6:51 AM, Alan Alpert <416365416c at gmail.com> wrote: > On Thu, Jul 18, 2013 at 6:44 AM, Oswald Buddenhagen > wrote: >> On Thu, Jul 18, 2013 at 06:18:43AM -0700, Alan Alpert wrote: >>> On Thu, Jul 18, 2013 at 6:07 AM, Oswald Buddenhagen >>> wrote: >>> > On Thu, Jul 18, 2013 at 03:10:31AM -0700, Alan Alpert wrote: >>> >> I'd first like to know if we've come to a decision on >>> >> whether to have a separate qt-quick at qt-project.org ML? >>> >> >>> > i wonder how many more times you want to re-iterate this? do you have >>> > any *new* arguments in favor of this fragmentation? >>> >>> You're right. Nothing has changed in the last month since this was >>> proposed and no-one objected. >>> >> nice try. >> http://lists.qt-project.org/pipermail/development/2012-December/008376.html > > Wrong, I'm referring to this: > http://lists.qt-project.org/pipermail/qt-components/2013-June/000304.html I just noticed this thread could be confusing for some, so I'd like to clarify: The initial email (today) contained arguments straight from the Qt-Components list discussion. So those were new to this list (not in the december thread) but unchanged from a month ago on the components list. Those not keen on trying to weave in the threads across both lists should just reply to the initial email and forget the rest... -- Alan Alpert From oswald.buddenhagen at digia.com Thu Jul 18 16:08:35 2013 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Thu, 18 Jul 2013 16:08:35 +0200 Subject: [Development] QtQuick ML In-Reply-To: References: <20130718130727.GA931@troll08.it.local> <20130718134407.GB931@troll08.it.local> Message-ID: <20130718140834.GA8301@troll08.it.local> On Thu, Jul 18, 2013 at 06:51:08AM -0700, Alan Alpert wrote: > On Thu, Jul 18, 2013 at 6:44 AM, Oswald Buddenhagen wrote: > > On Thu, Jul 18, 2013 at 06:18:43AM -0700, Alan Alpert wrote: > >> On Thu, Jul 18, 2013 at 6:07 AM, Oswald Buddenhagen wrote: > >> > On Thu, Jul 18, 2013 at 03:10:31AM -0700, Alan Alpert wrote: > >> >> I'd first like to know if we've come to a decision on > >> >> whether to have a separate qt-quick at qt-project.org ML? > >> >> > >> > i wonder how many more times you want to re-iterate this? do you have > >> > any *new* arguments in favor of this fragmentation? > >> > >> You're right. Nothing has changed in the last month since this was > >> proposed and no-one objected. > >> > > nice try. > > http://lists.qt-project.org/pipermail/development/2012-December/008376.html > > Wrong, I'm referring to this: > http://lists.qt-project.org/pipermail/qt-components/2013-June/000304.html > > You probably didn't see it because you're not interested in QtQuick so > don't subscribe to all the QtQuick MLs. > i did not not see it - rather, like everyone else, i simply ignored it with the thought "won't these guys ever stop beating that dead horse?". the components list is a relic from the times before the technology was at the core of qt's future. it should be dissolved asap, not be taken as a justification for further fragmentation. From 416365416c at gmail.com Thu Jul 18 16:18:18 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 18 Jul 2013 07:18:18 -0700 Subject: [Development] QtQuick ML In-Reply-To: <20130718140834.GA8301@troll08.it.local> References: <20130718130727.GA931@troll08.it.local> <20130718134407.GB931@troll08.it.local> <20130718140834.GA8301@troll08.it.local> Message-ID: On Thu, Jul 18, 2013 at 7:08 AM, Oswald Buddenhagen wrote: > On Thu, Jul 18, 2013 at 06:51:08AM -0700, Alan Alpert wrote: >> On Thu, Jul 18, 2013 at 6:44 AM, Oswald Buddenhagen wrote: >> > On Thu, Jul 18, 2013 at 06:18:43AM -0700, Alan Alpert wrote: >> >> On Thu, Jul 18, 2013 at 6:07 AM, Oswald Buddenhagen wrote: >> >> > On Thu, Jul 18, 2013 at 03:10:31AM -0700, Alan Alpert wrote: >> >> >> I'd first like to know if we've come to a decision on >> >> >> whether to have a separate qt-quick at qt-project.org ML? >> >> >> >> >> > i wonder how many more times you want to re-iterate this? do you have >> >> > any *new* arguments in favor of this fragmentation? >> >> >> >> You're right. Nothing has changed in the last month since this was >> >> proposed and no-one objected. >> >> >> > nice try. >> > http://lists.qt-project.org/pipermail/development/2012-December/008376.html >> >> Wrong, I'm referring to this: >> http://lists.qt-project.org/pipermail/qt-components/2013-June/000304.html >> >> You probably didn't see it because you're not interested in QtQuick so >> don't subscribe to all the QtQuick MLs. >> > i did not not see it - rather, like everyone else, i simply ignored it > with the thought "won't these guys ever stop beating that dead horse?". > > the components list is a relic from the times before the technology was > at the core of qt's future. it should be dissolved asap, not be taken as > a justification for further fragmentation. People who use the list want it upgraded, and you both want it dead *and* insist on ignoring it? You haven't even addressed any of the arguments, which are the same as the ones you (implicitly) agreed with about the IRC channels. The best interpretation I can get of your wishes, from all these terse and "poetically worded" emails, is that you don't really care what happens but agree in principle. Anyone else with a +1? -- Alan Alpert From lpapp at kde.org Thu Jul 18 16:31:33 2013 From: lpapp at kde.org (Laszlo Papp) Date: Thu, 18 Jul 2013 15:31:33 +0100 Subject: [Development] QtQuick ML In-Reply-To: References: <20130718130727.GA931@troll08.it.local> <20130718134407.GB931@troll08.it.local> <20130718140834.GA8301@troll08.it.local> Message-ID: On Thu, Jul 18, 2013 at 3:18 PM, Alan Alpert <416365416c at gmail.com> wrote: > You haven't even addressed any of the arguments, which are the same as > the ones you (implicitly) agreed with about the IRC channels. > Alan, it is not the same, for me, at least. I have always considered the qml/quick irc channel as a place for user support. I think there should be a clear separation between user support and actual development discussion about future direction and so forth. As for user questions, there is already the interest mailing list, and for development... wasn't it okay when you sent a set of emails in here last time in a similar scenario and there was a significant amount of feedback? Could you please elaborate on what went wrong with that? Cheers, Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at digia.com Thu Jul 18 16:44:11 2013 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Thu, 18 Jul 2013 16:44:11 +0200 Subject: [Development] QtQuick ML In-Reply-To: References: <20130718130727.GA931@troll08.it.local> <20130718134407.GB931@troll08.it.local> <20130718140834.GA8301@troll08.it.local> Message-ID: <20130718144411.GB8301@troll08.it.local> On Thu, Jul 18, 2013 at 07:18:18AM -0700, Alan Alpert wrote: > On Thu, Jul 18, 2013 at 7:08 AM, Oswald Buddenhagen wrote: > > i did not not see it - rather, like everyone else, i simply ignored it > > with the thought "won't these guys ever stop beating that dead horse?". > > > > the components list is a relic from the times before the technology was > > at the core of qt's future. it should be dissolved asap, not be taken as > > a justification for further fragmentation. > > People who use the list want it upgraded, > merging into development@ would be *quite* an "upgrade", and would conform with prior consensus on virtually the same question. > and you both want it dead *and* insist on ignoring it? > that's how most people react to what they perceive as trolling. > You haven't even addressed any of the arguments, which are the same as > the ones you (implicitly) agreed with about the IRC channels. > i don't consider the "irc situation" relevant to this discussion. irc "lives" a lot faster and can be a lot more confusing/distracting than a mailing list. so if you want a unified user/developer channel separate from the main channels, you can do that. not that your users will care about this artificial split from #qt in the longer run, but it's your call ... > The best interpretation I can get of your wishes, from all these terse > and "poetically worded" emails, is that you don't really care what > happens but agree in principle. Anyone else with a +1? > you really have a talent for intentionally finding the most backwards interpretation of everything ... no, i *don't* agree with your plan. at all. From 416365416c at gmail.com Thu Jul 18 16:46:30 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 18 Jul 2013 07:46:30 -0700 Subject: [Development] QtQuick ML In-Reply-To: References: <20130718130727.GA931@troll08.it.local> <20130718134407.GB931@troll08.it.local> <20130718140834.GA8301@troll08.it.local> Message-ID: On Thu, Jul 18, 2013 at 7:31 AM, Laszlo Papp wrote: > On Thu, Jul 18, 2013 at 3:18 PM, Alan Alpert <416365416c at gmail.com> wrote: >> >> You haven't even addressed any of the arguments, which are the same as >> >> the ones you (implicitly) agreed with about the IRC channels. > > > Alan, it is not the same, for me, at least. I have always considered the > qml/quick irc channel as a place for user support. I think there should be a > clear separation between user support and actual development discussion > about future direction and so forth. It was not explicitly mentioned in the #qt-quick IRC discussion, and I thought it was, so I apologize for skipping over that. The original #qt-components channel was started for actual development discussion, not user support, for coordination of the developers of different component sets. However, it was also often used by the components developers to ask QtQuick questions when doing their implementation. Those questions often straddled the line between development and user support. When the #qt-quick channel merged #qt-components and #qt-qml (the latter of which was already a combined user/developer channel, but only during AEST ;) ) it seemed clear to me that it would lead to a combined user/developer channel. This would allow discussions there based on topic without wondering about an unclear user/developer split, largely because QtQuick.Controls developers are QtQuick users. When this was touched on in the other thread, I believe the point was that QtQml discussions, which are separate from QtQuick discussions, would take place in the existing Qt channels (#qt-labs and #qt, although realistically most will be in #qt-v4vm for the short term future). > As for user questions, there is already the interest mailing list, and for > development... wasn't it okay when you sent a set of emails in here last > time in a similar scenario and there was a significant amount of feedback? > Could you please elaborate on what went wrong with that? The feedback last time was mixed, though primarily against. Nothing went wrong there, we followed that feedback at the time. My experience after trying it is that it has not been effective, as many people interested in QtQuick are still not on the general development mailing list and so it is a poor vehicle for reaching interested parties. I have often resorted to mailing the interested people directly in order to get their feedback. Now something has changed. We now have QtQuick.Controls, QtQuick.Layouts, and QtQuick.Styles so that "components" is no longer a clear name for those areas. The discussion on the components ML seemed to suggest either a QtQuick ML which covers all QtQuick (but not QtQml), or a QtQuickControls ML. Since the QtQuick ML would affect some users of this ML, I am asking whether it would be acceptable (the alternative being a QtQuickControls list being created, with more limited scope, as per the discussion on that thread). -- Alan Alpert From lpapp at kde.org Thu Jul 18 17:02:20 2013 From: lpapp at kde.org (Laszlo Papp) Date: Thu, 18 Jul 2013 16:02:20 +0100 Subject: [Development] QtQuick ML In-Reply-To: References: <20130718130727.GA931@troll08.it.local> <20130718134407.GB931@troll08.it.local> <20130718140834.GA8301@troll08.it.local> Message-ID: On Thu, Jul 18, 2013 at 3:46 PM, Alan Alpert <416365416c at gmail.com> wrote: > > As for user questions, there is already the interest mailing list, and > for > > development... wasn't it okay when you sent a set of emails in here last > > time in a similar scenario and there was a significant amount of > feedback? > > Could you please elaborate on what went wrong with that? > > The feedback last time was mixed, though primarily against. > I mean, you sent several emails to development@ about quick/qml topics to be discussed, like settings api, etc. You had received a bunch of feedback. Cheers, Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From 416365416c at gmail.com Thu Jul 18 17:07:02 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 18 Jul 2013 08:07:02 -0700 Subject: [Development] QtQuick ML In-Reply-To: References: <20130718130727.GA931@troll08.it.local> <20130718134407.GB931@troll08.it.local> <20130718140834.GA8301@troll08.it.local> Message-ID: On Thu, Jul 18, 2013 at 8:02 AM, Laszlo Papp wrote: > On Thu, Jul 18, 2013 at 3:46 PM, Alan Alpert <416365416c at gmail.com> wrote: >> >> > As for user questions, there is already the interest mailing list, and >> > for >> > development... wasn't it okay when you sent a set of emails in here last >> > time in a similar scenario and there was a significant amount of >> > feedback? >> > Could you please elaborate on what went wrong with that? >> >> The feedback last time was mixed, though primarily against. > > > I mean, you sent several emails to development@ about quick/qml topics to be > discussed, like settings api, etc. You had received a bunch of feedback. There were some specific KDE people then whom I had been talking to at DevDays who did not participate through the development ML on those topics, despite being interested in previous conversations. After having more excellent discussions with many of the same KDE people at Akademy this week, I would like to make QtQuick development more accessible to them. -- Alan Alpert From 416365416c at gmail.com Thu Jul 18 17:30:21 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 18 Jul 2013 08:30:21 -0700 Subject: [Development] QtQuick ML In-Reply-To: References: <20130718130727.GA931@troll08.it.local> <20130718134407.GB931@troll08.it.local> <20130718140834.GA8301@troll08.it.local> Message-ID: CC'ing a couple of said people with their permission (because they're obviously not monitoring the development list...). They're still welcome to tell me that a separate QtQuick list is not worthwhile, or that a [QtQuick] tag would be enough. -- Alan Alpert On Thu, Jul 18, 2013 at 8:07 AM, Alan Alpert <416365416c at gmail.com> wrote: > On Thu, Jul 18, 2013 at 8:02 AM, Laszlo Papp wrote: >> On Thu, Jul 18, 2013 at 3:46 PM, Alan Alpert <416365416c at gmail.com> wrote: >>> >>> > As for user questions, there is already the interest mailing list, and >>> > for >>> > development... wasn't it okay when you sent a set of emails in here last >>> > time in a similar scenario and there was a significant amount of >>> > feedback? >>> > Could you please elaborate on what went wrong with that? >>> >>> The feedback last time was mixed, though primarily against. >> >> >> I mean, you sent several emails to development@ about quick/qml topics to be >> discussed, like settings api, etc. You had received a bunch of feedback. > > There were some specific KDE people then whom I had been talking to at > DevDays who did not participate through the development ML on those > topics, despite being interested in previous conversations. After > having more excellent discussions with many of the same KDE people at > Akademy this week, I would like to make QtQuick development more > accessible to them. > > -- > Alan Alpert From thiago.macieira at intel.com Thu Jul 18 20:00:29 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 18 Jul 2013 11:00:29 -0700 Subject: [Development] Changelogs for Qt 5.1.x and 5.2 In-Reply-To: References: <10577726.kxE7y6OR7V@tjmaciei-mobl2> <2021469.XXFTCBHLfg@tjmaciei-mobl2> Message-ID: <3109917.UbVZqOI56u@tjmaciei-mobl2> On quinta-feira, 18 de julho de 2013 13.18.32, Richard Moore wrote: > On 18 July 2013 01:34, Thiago Macieira wrote: > > On quarta-feira, 17 de julho de 2013 21.45.11, Giuseppe D'Angelo wrote: > >> Can we devise something simpler? Can we also put in our policies an > >> example of how a changelog file is structured, and what are the right > >> tags to use to add an entry to a given section? > > > > "Use the tags that appear in the changelog file" > > They should be listed in the commit log template to make it easy for > people to just copy them. Good idea, that's easy to do. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Thu Jul 18 20:08:40 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 18 Jul 2013 11:08:40 -0700 Subject: [Development] QtQuick ML In-Reply-To: References: Message-ID: <19100646.N4lqmLA3J4@tjmaciei-mobl2> On quinta-feira, 18 de julho de 2013 08.07.02, Alan Alpert wrote: > There were some specific KDE people then whom I had been talking to at > DevDays who did not participate through the development ML on those > topics, despite being interested in previous conversations. After > having more excellent discussions with many of the same KDE people at > Akademy this week, I would like to make QtQuick development more > accessible to them. I did hear from a couple of people that the traffic in the Dev mailing list is quite high already. That would be a reason to split. Do people agree it's high? Right now, we have a 350 emails / month average for the past 3 months (11-12 emails a day). For comparison, in the same period, kde-core-devel averaged 460 emails / month (15-16 per day), my Gerrit inbox is at 1200 emails/month (40 a day) and my Intel professional inbox has 646 in the last 30 days only. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From mail at milianw.de Thu Jul 18 22:58:50 2013 From: mail at milianw.de (Milian Wolff) Date: Thu, 18 Jul 2013 22:58:50 +0200 Subject: [Development] GDB python pretty printers for common Qt classes Message-ID: <20825071.fu8Ir1fRJk@minime> Hey all! KDevelop is since some time relying on python pretty printers to stringify common Qt container classes when using GDB [1]. They work nicely in any GDB console, as long as you compile your app with -O0 -g -fno-inline. If you don't do that, the existing pretty printers will start to fail. To improve that situation, I would like to start rewriting the pretty printers and rely more on the actual internal Qt implementation. Since this might change between versions, I would very much welcome if we could get these pretty printers into Qt itself. Note that while the existing code we wrote is mostly for Qt4, afaik it also works relatively OK for Qt5 already. I think getting it upstream for Qt5 only would be good. Feedback? And, if this is accepted - where should such files reside? Should they accompany each Qt module? Or should there be a central pretty printer file? What classes should be pretty-printable? [1]: https://projects.kde.org/projects/extragear/kdevelop/kdevelop/repository/revisions/master/entry/debuggers/gdb/printers/qt4.py -- Milian Wolff mail at milianw.de http://milianw.de -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From lpapp at kde.org Fri Jul 19 03:42:32 2013 From: lpapp at kde.org (Laszlo Papp) Date: Fri, 19 Jul 2013 02:42:32 +0100 Subject: [Development] QtQuick ML In-Reply-To: <19100646.N4lqmLA3J4@tjmaciei-mobl2> References: <19100646.N4lqmLA3J4@tjmaciei-mobl2> Message-ID: On Thu, Jul 18, 2013 at 7:08 PM, Thiago Macieira wrote: > On quinta-feira, 18 de julho de 2013 08.07.02, Alan Alpert wrote: > > There were some specific KDE people then whom I had been talking to at > > DevDays who did not participate through the development ML on those > > topics, despite being interested in previous conversations. After > > having more excellent discussions with many of the same KDE people at > > Akademy this week, I would like to make QtQuick development more > > accessible to them. > > I did hear from a couple of people that the traffic in the Dev mailing > list is > quite high already. That would be a reason to split. > Sure, and you will also hear many people against splitting mailing lists. > Do people agree it's high? Right now, we have a 350 emails / month average > for > the past 3 months (11-12 emails a day). > I do not see 11-12 emails a day. How did you get that? Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Jul 19 04:13:00 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 18 Jul 2013 19:13 -0700 Subject: [Development] QtQuick ML In-Reply-To: References: <19100646.N4lqmLA3J4@tjmaciei-mobl2> Message-ID: <1580087.CnIPX7Q0zK@tjmaciei-mobl2> On sexta-feira, 19 de julho de 2013 02.42.32, Laszlo Papp wrote: > > Do people agree it's high? Right now, we have a 350 emails / month average > > for > > the past 3 months (11-12 emails a day). > > I do not see 11-12 emails a day. How did you get that? My KMail is configured for expiring dev emails after 90 days (the oldest email in the folder is from April 22). There are 1050 emails right now. 1050 / 90 = 11.6667 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From lpapp at kde.org Fri Jul 19 07:15:36 2013 From: lpapp at kde.org (Laszlo Papp) Date: Fri, 19 Jul 2013 06:15:36 +0100 Subject: [Development] QtQuick ML In-Reply-To: <1580087.CnIPX7Q0zK@tjmaciei-mobl2> References: <19100646.N4lqmLA3J4@tjmaciei-mobl2> <1580087.CnIPX7Q0zK@tjmaciei-mobl2> Message-ID: On Fri, Jul 19, 2013 at 3:13 AM, Thiago Macieira wrote: > My KMail is configured for expiring dev emails after 90 days (the oldest > email > in the folder is from April 22). There are 1050 emails right now. > > 1050 / 90 = 11.6667 > Ah, ok. I only checked the thread numbers apparently as the gmail webinterface does not extract them. It was too late for me last night. :-) Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From sierdzio at gmail.com Fri Jul 19 08:48:56 2013 From: sierdzio at gmail.com (Tomasz Siekierda) Date: Fri, 19 Jul 2013 08:48:56 +0200 Subject: [Development] QtQuick ML Message-ID: Don't know if my voice counts much, but I would prefer a single list (development) to rule them all. I can (and do) simply ignore topics that are not interesting for me, but I value highly the fact that I can get so much information about what is going on inside Qt from a single source. Cheers, sierdzio From oswald.buddenhagen at digia.com Fri Jul 19 10:37:57 2013 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Fri, 19 Jul 2013 10:37:57 +0200 Subject: [Development] QtQuick ML In-Reply-To: <19100646.N4lqmLA3J4@tjmaciei-mobl2> References: <19100646.N4lqmLA3J4@tjmaciei-mobl2> Message-ID: <20130719083757.GA18185@troll08.it.local> On Thu, Jul 18, 2013 at 11:08:40AM -0700, Thiago Macieira wrote: > I did hear from a couple of people that the traffic in the Dev mailing list is > quite high already. That would be a reason to split. > > Do people agree it's high? Right now, we have a 350 emails / month average for > the past 3 months (11-12 emails a day). > by my standards, that's ridiculously low. it takes a few seconds to skip over the uninteresting mails, and i'm a *slow* reader. a big part of why the traffic is so low here is that a lot of the focused discussion happens in gerrit, and some in jira. therefore i consider any "fanning out" of qt/ subprojects counterproductive at this point. From lorn.potter at gmail.com Fri Jul 19 10:41:44 2013 From: lorn.potter at gmail.com (Lorn Potter) Date: Fri, 19 Jul 2013 18:41:44 +1000 Subject: [Development] QtQuick ML In-Reply-To: <19100646.N4lqmLA3J4@tjmaciei-mobl2> References: <19100646.N4lqmLA3J4@tjmaciei-mobl2> Message-ID: <1373B2CD-BAC6-4F95-AD1D-0864CBBD62BB@gmail.com> On 19/07/2013, at 4:08 AM, Thiago Macieira wrote: > On quinta-feira, 18 de julho de 2013 08.07.02, Alan Alpert wrote: >> There were some specific KDE people then whom I had been talking to at >> DevDays who did not participate through the development ML on those >> topics, despite being interested in previous conversations. After >> having more excellent discussions with many of the same KDE people at >> Akademy this week, I would like to make QtQuick development more >> accessible to them. > > I did hear from a couple of people that the traffic in the Dev mailing list is > quite high already. That would be a reason to split. > > Do people agree it's high? Right now, we have a 350 emails / month average for > the past 3 months (11-12 emails a day). > > For comparison, in the same period, kde-core-devel averaged 460 emails / month > (15-16 per day), my Gerrit inbox is at 1200 emails/month (40 a day) and my > Intel professional inbox has 646 in the last 30 days only. In my experience, I don't think it's that busy of a mailing list. Although I can see the good reasons for both arguments, I don't think it's volume warrants a split off of qml/quick/components. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Lorn Potter QtSensors/QtSensorGestures/QtSystemInfo llornkcor technologies / Jolla Mobile From amogh.kudari5 at gmail.com Fri Jul 19 11:26:40 2013 From: amogh.kudari5 at gmail.com (Amogh Kudari) Date: Fri, 19 Jul 2013 14:56:40 +0530 Subject: [Development] Getting error while building QtWebkit Message-ID: Hi All, While building webkit (qtwebkit-4.8.4) from build-webkit script, I am getting the following error JSWorkerContextCustom.cpp ..\..\..\..\Source\WebCore\bindings\js\JSWorkerContextCustom.cpp(99) : error C2039: 'webSocket' : is not a member of 'WebCore::JSWorkerContext' generated\JSWorkerContext.h(33) : see declaration of 'WebCore::JSWorkerContext' ..\..\..\..\Source\WebCore\bindings\js\JSWorkerContextCustom.cpp(100) : error C2270: 'webSocket' : modifiers not allowed on nonmember functions ..\..\..\..\Source\WebCore\bindings\js\JSWorkerContextCustom.cpp(101) : error C2673: 'WebCore::webSocket' : global functions do not have 'this' pointers I think this is because of the auto generated headers does not contain any declaration for websockets. How do I solve this ... Please suggest. Thanks and Regards, Amogh. -------------- next part -------------- An HTML attachment was scrubbed... URL: From justin at affinix.com Fri Jul 19 22:35:09 2013 From: justin at affinix.com (Justin Karneges) Date: Fri, 19 Jul 2013 13:35:09 -0700 Subject: [Development] HTTP persistent connection race condition Message-ID: <51E9A2FD.60301@affinix.com> Hi, QNetworkAccessManager supports persistent connections, and I am observing a behavior today where some requests by my application are failing if enough time passes between requests. I cannot say if this a bug in Qt yet (it could very well be in my server-side code), but I am wondering if Qt addresses the possibility of sending to a dead persistent connection, or the possibility of a persistent connection being closed by the server the moment a request is sent out? Thanks, Justin From thiago.macieira at intel.com Fri Jul 19 23:10:02 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 19 Jul 2013 14:10:02 -0700 Subject: [Development] HTTP persistent connection race condition In-Reply-To: <51E9A2FD.60301@affinix.com> References: <51E9A2FD.60301@affinix.com> Message-ID: <15994801.hSybjoIP3S@tjmaciei-mobl2> On sexta-feira, 19 de julho de 2013 13.35.09, Justin Karneges wrote: > Hi, > > QNetworkAccessManager supports persistent connections, and I am > observing a behavior today where some requests by my application are > failing if enough time passes between requests. I cannot say if this a > bug in Qt yet (it could very well be in my server-side code), but I am > wondering if Qt addresses the possibility of sending to a dead > persistent connection, or the possibility of a persistent connection > being closed by the server the moment a request is sent out? It's possible that the connection is torn down without QTcpSocket noticing (that is, stateful L3 router). It's also possible that the connection is torn down by the server at the same time that we try to use it again. QNAM should detect that and it should retry automatically. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From ynonperek at gmail.com Sat Jul 20 16:59:39 2013 From: ynonperek at gmail.com (ynon perek) Date: Sat, 20 Jul 2013 17:59:39 +0300 Subject: [Development] Problem compiling Qt on a Mac Message-ID: Hi All, I'm trying to compile Qt5.1 on my mac and failing on the avfoundation camera plugin. Here's the error I got: avfimagecapturecontrol.mm: In function ‘void __capture_block_invoke_1(void*, opaqueCMSampleBuffer*, NSError*)’: avfimagecapturecontrol.mm:121: error: ‘QStringList AVFImageCaptureControl::messageParts’ is not a static member of ‘class AVFImageCaptureControl’ avfimagecapturecontrol.mm:122: error: ‘messageParts’ was not declared in this scope avfimagecapturecontrol.mm:126: error: ‘QString AVFImageCaptureControl::errorMessage’ is not a static member of ‘class AVFImageCaptureControl’ avfimagecapturecontrol.mm:127: error: ‘errorMessage’ was not declared in this scope avfimagecapturecontrol.mm:132: error: ‘errorMessage’ was not declared in this scope avfimagecapturecontrol.mm:140: error: ‘NSData* AVFImageCaptureControl::nsJpgData’ is not a static member of ‘class AVFImageCaptureControl’ avfimagecapturecontrol.mm:141: error: ‘QByteArray AVFImageCaptureControl::jpgData’ is not a static member of ‘class AVFImageCaptureControl’ avfimagecapturecontrol.mm:141: error: ‘nsJpgData’ was not declared in this scope avfimagecapturecontrol.mm:145: error: ‘QBuffer AVFImageCaptureControl::buffer’ is not a static member of ‘class AVFImageCaptureControl’ avfimagecapturecontrol.mm:145: error: ‘jpgData’ was not declared in this scope avfimagecapturecontrol.mm:146: error: ‘QImageReader AVFImageCaptureControl::imageReader’ is not a static member of ‘class AVFImageCaptureControl’ avfimagecapturecontrol.mm:146: error: ‘buffer’ was not declared in this scope avfimagecapturecontrol.mm:147: error: ‘QSize AVFImageCaptureControl::imgSize’ is not a static member of ‘class AVFImageCaptureControl’ avfimagecapturecontrol.mm:147: error: ‘imageReader’ was not declared in this scope avfimagecapturecontrol.mm:148: error: ‘int AVFImageCaptureControl::downScaleSteps’ is not a static member of ‘class AVFImageCaptureControl’ avfimagecapturecontrol.mm:149: error: ‘imgSize’ was not declared in this scope avfimagecapturecontrol.mm:149: error: ‘downScaleSteps’ was not declared in this scope avfimagecapturecontrol.mm:155: error: ‘imgSize’ was not declared in this scope avfimagecapturecontrol.mm:156: error: ‘QImage AVFImageCaptureControl::snapPreview’ is not a static member of ‘class AVFImageCaptureControl’ avfimagecapturecontrol.mm:160: error: ‘snapPreview’ was not declared in this scope avfimagecapturecontrol.mm:165: error: ‘QFile AVFImageCaptureControl::f’ is not a static member of ‘class AVFImageCaptureControl’ avfimagecapturecontrol.mm:166: error: ‘f’ was not declared in this scope avfimagecapturecontrol.mm:167: error: ‘jpgData’ was not declared in this scope avfimagecapturecontrol.mm:178: error: ‘QString AVFImageCaptureControl::errorMessage’ is not a static member of ‘class AVFImageCaptureControl’ avfimagecapturecontrol.mm:182: error: ‘errorMessage’ was not declared in this scope make[6]: *** [.obj/release-shared/avfimagecapturecontrol.o] Error 1 Taking a quick look I didn't find the #include in the file (or any of the included). Ideas what I did wrong ? Thanks In Advance, Ynon -- כותב הרצאות ? מדבר מול קהל ? הבלוג שלי לומד לדברכתוב במיוחד בשבילך. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sat Jul 20 17:58:47 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 20 Jul 2013 08:58:47 -0700 Subject: [Development] Problem compiling Qt on a Mac In-Reply-To: References: Message-ID: <1624231.6DBj3sugr0@tjmaciei-mobl2> On sábado, 20 de julho de 2013 17.59.39, ynon perek wrote: > avfimagecapturecontrol.mm: In function ‘void > __capture_block_invoke_1(void*, opaqueCMSampleBuffer*, NSError*)’: > avfimagecapturecontrol.mm:121: error: ‘QStringList > AVFImageCaptureControl::messageParts’ is not a static member of ‘class > AVFImageCaptureControl’ [snip] > Taking a quick look I didn't find the #include in the > file (or any of the included). Ideas what I did wrong ? It looks like a parsing error from the compiler. QStringList messageParts is supposed to be declared on the stack of the capture block. It's not static. Can you try another compiler? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From samuel.gaist at edeltech.ch Sun Jul 21 00:21:01 2013 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Sun, 21 Jul 2013 00:21:01 +0200 Subject: [Development] Qt 5 QSessionManager Message-ID: <87A14056-6B67-4DD3-86D5-8B3B3D772AE6@edeltech.ch> Hi, After starting the implementation of a basic session management for OS X in Qt 4, I wanted to port it to Qt 5 and I have hit a wall. In Qt 4 the various functions of QSessionManager where implemented in several places (originally qapplication_XXX.cpp files and qcocoaapplicationdelegate_mac.mm for my patch) using #if defined to avoid multiple function definitions. Re-using the same principle in Qt 5 would break the idea of platform plugins so I thought about moving the creation of the QSessionManager from QGuiApplicationPrivate to QPlatformIntegration and provide a subclass of QSessionManager for OS X (the other platform if possible following later). Now there's the wall: all functions from QSessionManager are non virtual (even the destructor) and it has no d pointer, so subclassing it will prove to be complicated. If I have understood correctly the rules for keeping binary compatibility (from the kde techbase entry) it is forbidden to change a function from non-virtual to virtual (please correct me if I'm wrong), in that case would the Q_GLOBAL_STATIC QHash technique be the way to go ? From mail at milianw.de Sun Jul 21 23:43:03 2013 From: mail at milianw.de (Milian Wolff) Date: Sun, 21 Jul 2013 23:43:03 +0200 Subject: [Development] Q_OBJECT_CHECK / Q_OBJECT triggers warning in clang: explicitly assigning a variable of type 'int' to itself [-Wself-assign] Message-ID: <5243215.DdQ7xmWqzQ@minime> Hey all, compiling with clang and ccache I get this warning for everytime it encounters a Q_OBJECT: warning: explicitly assigning a variable of type 'int' to itself [-Wself- assign] This is due to the Q_OBJECT_CHECK definition of -- Milian Wolff mail at milianw.de http://milianw.de From mail at milianw.de Sun Jul 21 23:44:41 2013 From: mail at milianw.de (Milian Wolff) Date: Sun, 21 Jul 2013 23:44:41 +0200 Subject: [Development] Q_OBJECT_CHECK / Q_OBJECT triggers warning in clang: explicitly assigning a variable of type 'int' to itself [-Wself-assign] In-Reply-To: <5243215.DdQ7xmWqzQ@minime> References: <5243215.DdQ7xmWqzQ@minime> Message-ID: <2947779.NPtk0jzY6h@minime> On Sunday 21 July 2013 23:43:03 Milian Wolff wrote: > Hey all, > > compiling with clang and ccache I get this warning for everytime it > encounters a Q_OBJECT: > > warning: explicitly assigning a variable of type 'int' to itself [-Wself- > assign] > > This is due to the Q_OBJECT_CHECK definition of sorry - hit sent too early. The definition of said macro is: #define Q_OBJECT_CHECK \ template inline void qt_check_for_QOBJECT_macro(const T &_q_argument) const \ { int i = qYouForgotTheQ_OBJECT_Macro(this, &_q_argument); i = i; } see the "i = i". Is that just to ensure it's not marked as unused? Could something be done about it? Maybe the (void) i "trick" that Q_UNUSED applies? Cheers -- Milian Wolff mail at milianw.de http://milianw.de From lpapp at kde.org Sun Jul 21 23:55:18 2013 From: lpapp at kde.org (Laszlo Papp) Date: Sun, 21 Jul 2013 22:55:18 +0100 Subject: [Development] Q_OBJECT_CHECK / Q_OBJECT triggers warning in clang: explicitly assigning a variable of type 'int' to itself [-Wself-assign] In-Reply-To: <2947779.NPtk0jzY6h@minime> References: <5243215.DdQ7xmWqzQ@minime> <2947779.NPtk0jzY6h@minime> Message-ID: On Sun, Jul 21, 2013 at 10:44 PM, Milian Wolff wrote: > #define Q_OBJECT_CHECK \ > template inline void qt_check_for_QOBJECT_macro(const T > &_q_argument) const \ > { int i = qYouForgotTheQ_OBJECT_Macro(this, &_q_argument); i = i; } > > see the "i = i". Is that just to ensure it's not marked as unused? Could > something be done about it? Maybe the (void) i "trick" that Q_UNUSED > applies? > Probably not. It might make more sense to cherry-pick this back to Qt4 instead: https://codereview.qt-project.org/#change,4960 Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mardy at users.sourceforge.net Mon Jul 22 10:25:03 2013 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Mon, 22 Jul 2013 11:25:03 +0300 Subject: [Development] Qt 5 QSessionManager In-Reply-To: <87A14056-6B67-4DD3-86D5-8B3B3D772AE6@edeltech.ch> References: <87A14056-6B67-4DD3-86D5-8B3B3D772AE6@edeltech.ch> Message-ID: <51ECEC5F.30006@users.sourceforge.net> On 07/21/2013 01:21 AM, Samuel Gaist wrote: [...] > Now there's the wall: all functions from QSessionManager are > non virtual (even the destructor) and it has no d pointer, so > subclassing it will prove to be complicated. Not really: the destructor is virtual, because the class inherits from QObject, whose destructor is virtual. Also, there is a d pointer, the one from QObject: QObject provides a constructor which takes a QObjectPrivate class. You can subclass QObjectPrivate, add your members, and then pass your QObjectPrivate subclass to the QObject constructor when you initialize it. > If I have understood correctly the rules for keeping binary > compatibility (from the kde techbase entry) it is forbidden to change > a function from non-virtual to virtual (please correct me if I'm > wrong), in that case would the Q_GLOBAL_STATIC QHash technique be the > way to go ? Given the above, I don't think you need to go for any of this. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! From Jan-Arve.Saether at digia.com Mon Jul 22 10:28:20 2013 From: Jan-Arve.Saether at digia.com (Saether Jan-Arve) Date: Mon, 22 Jul 2013 08:28:20 +0000 Subject: [Development] Qt Base code coverage statistics are now computed on Ubuntu 11.04 In-Reply-To: <51DFC060.3070809@froglogic.com> References: <51DFC060.3070809@froglogic.com> Message-ID: <66BFFE861C7DE34D9B0372D8EAAB18E2BBEDD9@IT-EXMB01-HKI.it.local> I was looking at the bottom of the list and found for instance qgraphicsanchorlayout.cpp to be down there. It seems to be skipped because you haven't configured Qt as a developer-build. If possible, you should do add "-developer-build" to the configure line. Jan Arve From: development-bounces+jan-arve.saether=digia.com at qt-project.org [mailto:development-bounces+jan-arve.saether=digia.com at qt-project.org] On Behalf Of Sébastien Fricker Sent: 12. juli 2013 10:38 To: development at qt-project.org Subject: [Development] Qt Base code coverage statistics are now computed on Ubuntu 11.04 Hi, The test environment has changed and is now based on Ubuntu 11.04. The Puppet environment for a Qt CI test server is installed. This permits to support tests which are using OpenGL, Dbus, network infrastructures, .... This permits to reach 5% more code coverage in comparison to the previous environment (which skipped a lot of failed tests). The code coverage report can be consulted here: http://download.froglogic.com/public/qt5-squishcoco-report/ Sébastien -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sergio.Ahumada at digia.com Mon Jul 22 10:42:05 2013 From: Sergio.Ahumada at digia.com (Ahumada Sergio) Date: Mon, 22 Jul 2013 08:42:05 +0000 Subject: [Development] HEADS UP: Qt 5.1.1 - merge stable into release In-Reply-To: <51E3B86E.40706@digia.com> References: <51E3B86E.40706@digia.com> Message-ID: <9B4D1DADF5006F4DB6666312421B98E50103A38B@IT-EXMB01-HKI.it.local> On 07/15/2013 10:53 AM, Sergio Ahumada wrote:> Hi, > > We are about to start the "Qt 5.1.1" release, which means that: > > - We plan to do a fast-forward merge from 'stable' into 'release' branch > on Jul 22th. > > - After Jul 22th any changes that are required for 5.1.1 need to be > pushed to the 'release' branch. So if your changes are not in by that > day, please wait until the merge is done and re-target them to the > 'release' branch. > > The repositories that will be part of the Qt 5.1.1 release merge are: > > - qtactiveqt > - qtbase > - qtdeclarative > - qtdoc > - qtgraphicaleffects > - qtimageformats > - qtjsbackend > - qtmultimedia > - qtquick1 > - qtquickcontrols > - qtscript > - qtsensors > - qtserialport > - qtsvg > - qttools > - qttranslations > - qtwebkit > - qtwebkit-examples > - qtxmlpatterns > - qtx11extras > > ps: you can already find some snapshots for 5.1.1 under > http://download.qt-project.org/snapshots/qt/5.1/5.1.1-rc1/backups/ > > Cheers, > Hi, The merge from 'stable' to 'release' is happening now as we speak. The plan is the following: - We will block the "Merge Patch Set X to Staging" button for all the repositories listed above (for the 'stable' branch only). - We will wait for changes still under test until they are all merged and/or back to Review in Progress. - We will proceed with the merge for all the repositories listed above. - We will leave the "Merge Patch Set X to Staging" blocked for around two days, to avoid that changes get merged to the wrong branch and need to be cherry-picked. If your changes didn't make it and they are meant for Qt 5.1.1 please re-target them to the 'release' branch after the merges are done. New changes fixing P0 or P1 can be pushed directly to the 'release' branch after the merges are done. Cheers, -- Sergio Ahumada san at sansano.inf.utfsm.cl From stephen.kelly at kdab.com Mon Jul 22 11:23:42 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Mon, 22 Jul 2013 11:23:42 +0200 Subject: [Development] Qt CS 2013 Itemview session report Message-ID: <2166290.5UOnALszWS@hal> Hi there, I hosted a session about the state of the itemmodels and itemviews in Qt. I mentioned what has been going on in the latest releases and work that's being done by others (Thanks Thorbjørn :) ). We discussed the use of the QAbstractItemModel API with asynchronously updated data. For example, the setData method must be implemented to return a bool, which appears to mean that the update must be done synchronously. The reality is that the return value is only relevant to handling of events with delegates. That could maybe be documented better. Models can still be implemented in an async way by starting a job and returning immediately, then emitting dataChanged when the job is done. We also discussed briefly the idea of treating a model implementation as read- only (because it is not as type-safe as the actual data as it uses QVariant), and having a separate API for updates which is typesafe. We also discussed the issue of QML integration with regard to the above points, and with regard to tree processing in QtQuick. The solution for that is not necessarily attempting a functionally verbatim QTreeView implementation using QML API, but there may be better options. Some research is needed there. Alan Alpert hosted a separate follow-up session on itemview implementation in QML, but I was not able to attend. Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4842 bytes Desc: not available URL: From stephen.kelly at kdab.com Mon Jul 22 11:24:05 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Mon, 22 Jul 2013 11:24:05 +0200 Subject: [Development] Qt CS 2013 CMake session report Message-ID: <2257232.XtGoRC8iN3@hal> Hi there, I hosted a session about CMake+Qt in Bilbao last week to gather feedback from those using it, gather feature requests and outline future plans: http://qt-project.org/groups/qt-contributors-summit-2013/wiki/CMake-files-feedback-requests The situation is generally very good for third parties, with new CMake features in new releases making things easier to use. Future work will focus on the developer story. I'll be working on improving the Creator integration in general aiming for feature parity with the capabilities of Creator with other buildsystems (qmake, qbs). My intention that migration to cmake makes more sense for third parties than to qbs when the 'time to migrate away from qmake' message comes down. Additionally, I'll be working on a cpack generator for BB10, and a volunteer (Kare Sars, I think) said he'd work on a generator for android packages. Exposing CPack features through creator is also a goal. Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4842 bytes Desc: not available URL: From stephen.kelly at kdab.com Mon Jul 22 13:14:18 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Mon, 22 Jul 2013 13:14:18 +0200 Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <51E61E0B.4050105@codan.com.au> References: <51DF61BF.5040304@codan.com.au> <51E61E0B.4050105@codan.com.au> Message-ID: <2171360.MuxoQFPleD@hal> On Wednesday, July 17, 2013 14:01:07 Simon Lees wrote: > this embeds SONAME libQt5x.so.5 into the Qt Libraries and NEEDED > libQt5Core.so.5 this is a good start as it removes the fixed path from > the needed line. It still causes issues on android however, as it tries > to load libQt5Core.so.5 etc that does not exist. I just submitted https://codereview.qt-project.org/#change,61330 and then re- read this. Does this mean that my patch is wrong? Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From olivier at woboq.com Mon Jul 22 13:11:58 2013 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 22 Jul 2013 13:11:58 +0200 Subject: [Development] Dropping the variadic version of QSKIP In-Reply-To: <1695257.kB7LA5vZ7R@gargamel> References: <1808810.QGRtp28M1N@xps> <1723620.HIe2avZIlz@tjmaciei-mobl2> <1695257.kB7LA5vZ7R@gargamel> Message-ID: <3249913.cbfFiDno6c@gargamel> On Wednesday 10 July 2013 19:43:09 Olivier Goffart wrote: > On Wednesday 10 July 2013 09:46:48 Thiago Macieira wrote: > > Well, there is a moc bug in the parsing of variadic macros, evidently. > > There is no bug. > > The QSKIP is defined depending on Q_COMPILER_VARIADIC_MACROS which itslef is > defined depending on a builtin gcc macro wich is not given to moc. So moc > beleive QSKIP only take one argument. > The solution would be to add a || defined (Q_MOC_RUN) > > Arguably, moc could perhaps be more error tollerent in this case. Here is a patch which would make moc print a warning instead of an error: https://codereview.qt-project.org/61329 -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From vminenko at blackberry.com Mon Jul 22 13:17:59 2013 From: vminenko at blackberry.com (Vladimir Minenko) Date: Mon, 22 Jul 2013 11:17:59 +0000 Subject: [Development] A component for BlackBerry 10 under "Qt Ports" Message-ID: <04DC2592A1CEA64085311474D88DD4993EE15681@XMB104BRU.rim.net> Hi, while attending QtCS, Alex Blasche pointed to me to his comment on https://bugreports.qt-project.org/browse/QTJIRA-192 which also refers to a related discussion on this list: http://lists.qt-project.org/pipermail/development/2013-June/011215.html The situation on BB10 is very much different compared to Tizen and is closer to Android or iOS ports which have components for ports. Can we please add a component for Qt on BB10 in "Qt Ports"? Thanks! -- Vladimir --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. From markus at woboq.com Mon Jul 22 14:23:51 2013 From: markus at woboq.com (Markus Goetz) Date: Mon, 22 Jul 2013 14:23:51 +0200 Subject: [Development] HTTP persistent connection race condition In-Reply-To: <15994801.hSybjoIP3S@tjmaciei-mobl2> References: <51E9A2FD.60301@affinix.com> <15994801.hSybjoIP3S@tjmaciei-mobl2> Message-ID: <51ED2457.4060501@woboq.com> On 19.07.13 23:10, Thiago Macieira wrote: > On sexta-feira, 19 de julho de 2013 13.35.09, Justin Karneges wrote: >> Hi, >> >> QNetworkAccessManager supports persistent connections, and I am >> observing a behavior today where some requests by my application are >> failing if enough time passes between requests. I cannot say if this a >> bug in Qt yet (it could very well be in my server-side code), but I am >> wondering if Qt addresses the possibility of sending to a dead >> persistent connection, or the possibility of a persistent connection >> being closed by the server the moment a request is sent out? > It's possible that the connection is torn down without QTcpSocket noticing > (that is, stateful L3 router). It's also possible that the connection is torn > down by the server at the same time that we try to use it again. > > QNAM should detect that and it should retry automatically. > Is your request a POST/PUT request? What error do you get? From schumann at fnal.gov Mon Jul 22 19:35:24 2013 From: schumann at fnal.gov (Carl Schumann) Date: Mon, 22 Jul 2013 12:35:24 -0500 Subject: [Development] QSpinBox 1 up/down click changes value by 2 steps Message-ID: <51ED6D5C.4070903@fnal.gov> Hi, I am having some problem with my use of Qt's QSpinBox. In my application QSpinBox 1 up/down click changes the boxes value by 2 steps. (There are two separate valueChanged signals each by one step.) The issue appears to be related to the amount of time taken by a slot attached to the valueChanged signal. I have attached the small amount of source code needed to reproduce the issue, which is based on an example in the Qt 4 2nd Edition textbook. I am experiencing this bug with Qt 4.8.4. I don't have access to Qt 5 because of incompatibilities with our Linux distribution. I did try it on Qt 4.5.0 and got 3 steps for each click. I am not sure what expectations are put on slot code. Are slots expected to meet time constraints? If no, have I found a bug Qt? Sincerely, Carl Schumann -------------- next part -------------- #include #include #include #include #include "Model.h" int main(int argc, char *argv[]) { QApplication app(argc, argv); QWidget *window = new QWidget; window->setWindowTitle("Enter Your Age"); QSpinBox *spinBox = new QSpinBox; QSlider *slider = new QSlider(Qt::Horizontal); spinBox->setRange(0, 130); slider->setRange(0, 130); QObject::connect(spinBox, SIGNAL(valueChanged(int)), slider, SLOT(setValue(int))); QObject::connect(slider, SIGNAL(valueChanged(int)), spinBox, SLOT(setValue(int))); spinBox->setValue(35); QHBoxLayout *layout = new QHBoxLayout; layout->addWidget(spinBox); layout->addWidget(slider); window->setLayout(layout); Model model( spinBox->value() ); QObject::connect(spinBox, SIGNAL(valueChanged(int)), &model, SLOT(setAge(int))); window->show(); return app.exec(); } -------------- next part -------------- #include #include #include "Model.h" Model::Model( int age_arg ) : age( age_arg ) { } void Model::setAge( int age_arg ) { std::cout << "Age from " << this->age; sleep( 1 ); // Simulate a model that as bit of work to do to update itself this->age = age_arg; std::cout << " to " << this->age << std::endl; } -------------- next part -------------- #ifndef MODEL_H #define MODEL_H #include class Model : public QObject { Q_OBJECT public: Model( int age ); public Q_SLOTS: void setAge( int age ); private: int age; }; #endif From Sergio.Ahumada at digia.com Mon Jul 22 19:43:47 2013 From: Sergio.Ahumada at digia.com (Ahumada Sergio) Date: Mon, 22 Jul 2013 17:43:47 +0000 Subject: [Development] A component for BlackBerry 10 under "Qt Ports" In-Reply-To: <04DC2592A1CEA64085311474D88DD4993EE15681@XMB104BRU.rim.net> References: <04DC2592A1CEA64085311474D88DD4993EE15681@XMB104BRU.rim.net> Message-ID: <9B4D1DADF5006F4DB6666312421B98E50103AB15@IT-EXMB01-HKI.it.local> Hi, Since I created the other two (Android and iOS) and I haven't seen any objections yet, I have then created https://bugreports.qt-project.org/browse/QTBUG/component/20329 Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ________________________________________ From: development-bounces+sergio.ahumada=digia.com at qt-project.org [development-bounces+sergio.ahumada=digia.com at qt-project.org] on behalf of Vladimir Minenko [vminenko at blackberry.com] Sent: Monday, July 22, 2013 13:17 To: development at qt-project.org Subject: [Development] A component for BlackBerry 10 under "Qt Ports" Hi, while attending QtCS, Alex Blasche pointed to me to his comment on https://bugreports.qt-project.org/browse/QTJIRA-192 which also refers to a related discussion on this list: http://lists.qt-project.org/pipermail/development/2013-June/011215.html The situation on BB10 is very much different compared to Tizen and is closer to Android or iOS ports which have components for ports. Can we please add a component for Qt on BB10 in "Qt Ports"? Thanks! -- Vladimir --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Sergio.Ahumada at digia.com Mon Jul 22 22:17:59 2013 From: Sergio.Ahumada at digia.com (Ahumada Sergio) Date: Mon, 22 Jul 2013 20:17:59 +0000 Subject: [Development] HEADS UP: Qt 5.1.1 - merge stable into release In-Reply-To: <9B4D1DADF5006F4DB6666312421B98E50103A38B@IT-EXMB01-HKI.it.local> References: <51E3B86E.40706@digia.com>, <9B4D1DADF5006F4DB6666312421B98E50103A38B@IT-EXMB01-HKI.it.local> Message-ID: <9B4D1DADF5006F4DB6666312421B98E50103ABBD@IT-EXMB01-HKI.it.local> > > Hi, > > The merge from 'stable' to 'release' is happening now as we speak. > > The plan is the following: > > - We will block the "Merge Patch Set X to Staging" button for all the repositories listed above (for the 'stable' branch only). > - We will wait for changes still under test until they are all merged and/or back to Review in Progress. > - We will proceed with the merge for all the repositories listed above. > - We will leave the "Merge Patch Set X to Staging" blocked for around two days, to avoid that changes get merged to the wrong branch and need to be cherry-picked. > > If your changes didn't make it and they are meant for Qt 5.1.1 please re-target them to the 'release' branch after the merges are done. > > New changes fixing P0 or P1 can be pushed directly to the 'release' branch after the merges are done. > > Cheers, > Hi, All merges are now done, so changes required for Qt 5.1.1 need to be pushed to the 'release' branch from now on. Changes in the 'release' branch need to be reviewed as usual, but only the release team can stage them. Changes in the current 'stable' branch will be part of a potential Qt 5.1.2 or a Qt 5.2.0 release. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt From thiago.macieira at intel.com Mon Jul 22 22:49:30 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 22 Jul 2013 13:49:30 -0700 Subject: [Development] HEADS UP: Qt 5.1.1 - merge stable into release In-Reply-To: <9B4D1DADF5006F4DB6666312421B98E50103ABBD@IT-EXMB01-HKI.it.local> References: <51E3B86E.40706@digia.com> <9B4D1DADF5006F4DB6666312421B98E50103A38B@IT-EXMB01-HKI.it.local> <9B4D1DADF5006F4DB6666312421B98E50103ABBD@IT-EXMB01-HKI.it.local> Message-ID: <3285420.HE56d0WJqV@tjmaciei-mobl2> On segunda-feira, 22 de julho de 2013 20.17.59, Ahumada Sergio wrote: > All merges are now done, so changes required for Qt 5.1.1 need to be pushed > to the 'release' branch from now on. Please note that the release branch policy is in effect: - EVERY change to the release branch must have a Task-number field - the linked task must be P0, P1 or an important P2 - "important" is subjective. It's the submitter's and the reviewer's call, but be prepared to defend your reasoning -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From samuel.gaist at edeltech.ch Mon Jul 22 22:55:45 2013 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Mon, 22 Jul 2013 22:55:45 +0200 Subject: [Development] Qt 5 QSessionManager In-Reply-To: <51ECEC5F.30006@users.sourceforge.net> References: <87A14056-6B67-4DD3-86D5-8B3B3D772AE6@edeltech.ch> <51ECEC5F.30006@users.sourceforge.net> Message-ID: On 22 juil. 2013, at 10:25, Alberto Mardegan wrote: > On 07/21/2013 01:21 AM, Samuel Gaist wrote: > [...] >> Now there's the wall: all functions from QSessionManager are >> non virtual (even the destructor) and it has no d pointer, so >> subclassing it will prove to be complicated. > > Not really: the destructor is virtual, because the class inherits from > QObject, whose destructor is virtual. > Also, there is a d pointer, the one from QObject: QObject provides a > constructor which takes a QObjectPrivate class. You can subclass > QObjectPrivate, add your members, and then pass your QObjectPrivate > subclass to the QObject constructor when you initialize it. > >> If I have understood correctly the rules for keeping binary >> compatibility (from the kde techbase entry) it is forbidden to change >> a function from non-virtual to virtual (please correct me if I'm >> wrong), in that case would the Q_GLOBAL_STATIC QHash technique be the >> way to go ? > > Given the above, I don't think you need to go for any of this. > > Ciao, > Alberto > > -- > http://blog.mardy.it <- geek in un lingua international! But since both constructor and destructor are private, AFAIK, I can't just subclass it. Only a friend object or a class function can create a QSessionManager. Currently, I don't see any way to specialize QSessionManager in a platform independent no binary breaking way (thinking QPA). The only alternative that comes to my mind at this time would be to use platform #ifdefs in qsessionmanager.cpp and modify QSessionManagerPrivate to contain what would be needed. But it doesn't feel right to me. Any idea or suggestion ? From david.faure at kdab.com Mon Jul 22 23:07:23 2013 From: david.faure at kdab.com (David Faure) Date: Mon, 22 Jul 2013 23:07:23 +0200 Subject: [Development] Qt 5 QSessionManager In-Reply-To: References: <87A14056-6B67-4DD3-86D5-8B3B3D772AE6@edeltech.ch> <51ECEC5F.30006@users.sourceforge.net> Message-ID: <3363757.ibj9NzLr3u@asterix> On Monday 22 July 2013 22:55:45 Samuel Gaist wrote: > On 22 juil. 2013, at 10:25, Alberto Mardegan wrote: > > On 07/21/2013 01:21 AM, Samuel Gaist wrote: > > [...] > > > >> Now there's the wall: all functions from QSessionManager are > >> non virtual (even the destructor) and it has no d pointer, so > >> subclassing it will prove to be complicated. > > > > Not really: the destructor is virtual, because the class inherits from > > QObject, whose destructor is virtual. > > Also, there is a d pointer, the one from QObject: QObject provides a > > constructor which takes a QObjectPrivate class. You can subclass > > QObjectPrivate, add your members, and then pass your QObjectPrivate > > subclass to the QObject constructor when you initialize it. > > > > But since both constructor and destructor are private, AFAIK, I can't just > subclass it. Only a friend object or a class function can create a > QSessionManager. > > Currently, I don't see any way to specialize QSessionManager in a platform > independent no binary breaking way (thinking QPA). > > The only alternative that comes to my mind at this time would be to use > platform #ifdefs in qsessionmanager.cpp and modify QSessionManagerPrivate > to contain what would be needed. But it doesn't feel right to me. > > Any idea or suggestion ? I think you should create a new QPA base class with virtuals and just let the public QSessionManager forward calls to that class. And then QPA plugins can reimplement the virtuals from the internal QPA base class. -- David Faure | david.faure at kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From david.faure at kdab.com Mon Jul 22 23:22:08 2013 From: david.faure at kdab.com (David Faure) Date: Mon, 22 Jul 2013 23:22:08 +0200 Subject: [Development] GDB python pretty printers for common Qt classes In-Reply-To: <20825071.fu8Ir1fRJk@minime> References: <20825071.fu8Ir1fRJk@minime> Message-ID: <1612141.bsmXxlIqZu@asterix> On Thursday 18 July 2013 22:58:50 Milian Wolff wrote: > Hey all! > > KDevelop is since some time relying on python pretty printers to stringify > common Qt container classes when using GDB [1]. They work nicely in any GDB > console, as long as you compile your app with -O0 -g -fno-inline. If you > don't do that, the existing pretty printers will start to fail. To improve > that situation, I would like to start rewriting the pretty printers and > rely more on the actual internal Qt implementation. Nice. > Since this might change between versions, I would very much welcome if we > could get these pretty printers into Qt itself. Note that while the existing > code we wrote is mostly for Qt4, afaik it also works relatively OK for Qt5 > already. Yes, I use them almost every day. > I think getting it upstream for Qt5 only would be good. Hell yes :-) > Feedback? And, if this is accepted - where should such files reside? Should > they accompany each Qt module? Or should there be a central pretty printer > file? Currently it's all about types from qtbase, isn't it? So it would be a file installed by qtbase. (If there's more, I'd say that each module should have its own file). > What classes should be pretty-printable? QString is the most important one by far. Collection classes come next. PS: of course, make sure they work from a core dump too - i.e. without a process. -- David Faure | david.faure at kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From samuel.gaist at edeltech.ch Mon Jul 22 23:19:00 2013 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Mon, 22 Jul 2013 23:19:00 +0200 Subject: [Development] Qt 5 QSessionManager In-Reply-To: <3363757.ibj9NzLr3u@asterix> References: <87A14056-6B67-4DD3-86D5-8B3B3D772AE6@edeltech.ch> <51ECEC5F.30006@users.sourceforge.net> <3363757.ibj9NzLr3u@asterix> Message-ID: <7F5F9384-4D05-4CB2-8632-57111F218438@edeltech.ch> On 22 juil. 2013, at 23:07, David Faure wrote: > On Monday 22 July 2013 22:55:45 Samuel Gaist wrote: >> On 22 juil. 2013, at 10:25, Alberto Mardegan wrote: >>> On 07/21/2013 01:21 AM, Samuel Gaist wrote: >>> [...] >>> >>>> Now there's the wall: all functions from QSessionManager are >>>> non virtual (even the destructor) and it has no d pointer, so >>>> subclassing it will prove to be complicated. >>> >>> Not really: the destructor is virtual, because the class inherits from >>> QObject, whose destructor is virtual. >>> Also, there is a d pointer, the one from QObject: QObject provides a >>> constructor which takes a QObjectPrivate class. You can subclass >>> QObjectPrivate, add your members, and then pass your QObjectPrivate >>> subclass to the QObject constructor when you initialize it. >>> >> >> But since both constructor and destructor are private, AFAIK, I can't just >> subclass it. Only a friend object or a class function can create a >> QSessionManager. >> >> Currently, I don't see any way to specialize QSessionManager in a platform >> independent no binary breaking way (thinking QPA). >> >> The only alternative that comes to my mind at this time would be to use >> platform #ifdefs in qsessionmanager.cpp and modify QSessionManagerPrivate >> to contain what would be needed. But it doesn't feel right to me. >> >> Any idea or suggestion ? > > I think you should create a new QPA base class with virtuals and just let the > public QSessionManager forward calls to that class. > > And then QPA plugins can reimplement the virtuals from the internal QPA base > class. > Very good ! Something like a QPlatformSessionManager returned by the QPluginIntegration ? It would essentially replace the current content of QSessionManagerPrivate with functions. Am I following you right ? Should there be an abstract for this class with a default implementation (i.e QDefaultPlatformSessionManager) ? Or having the base class would be enough ? From david.faure at kdab.com Mon Jul 22 23:35:11 2013 From: david.faure at kdab.com (David Faure) Date: Mon, 22 Jul 2013 23:35:11 +0200 Subject: [Development] Qt 5 QSessionManager In-Reply-To: <7F5F9384-4D05-4CB2-8632-57111F218438@edeltech.ch> References: <87A14056-6B67-4DD3-86D5-8B3B3D772AE6@edeltech.ch> <3363757.ibj9NzLr3u@asterix> <7F5F9384-4D05-4CB2-8632-57111F218438@edeltech.ch> Message-ID: <1510221.jHscAGkzr9@asterix> On Monday 22 July 2013 23:19:00 Samuel Gaist wrote: > Very good ! > > Something like a QPlatformSessionManager returned by the QPluginIntegration? I assume you mean QPlatformIntegration. Then yes. > It would essentially replace the current content of QSessionManagerPrivate > with functions. Yes, for the benefit of the public methods that will have to call these. Plus other virtual methods for the currently-unimplemented methods (e.g. isPhase2() and others). > Should there be an abstract for this class with a default implementation > (i.e QDefaultPlatformSessionManager) ? Or having the base class would be > enough ? The base class can take care of the trivial getters/setters you mentionned (e.g. restartCommand/setRestartCommand). In addition it could have empty implementations of the other virtuals (e.g. isPhase2), for platforms that don't really support session management. Hmm, well, the alternative is to just not instanciate a subclass, i.e. handling the case of NULL in QSessionManager (you'll have to do that anyway, to avoid having to implement session management in all platforms). -- David Faure | david.faure at kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From samuel.gaist at edeltech.ch Mon Jul 22 23:51:23 2013 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Mon, 22 Jul 2013 23:51:23 +0200 Subject: [Development] Qt 5 QSessionManager In-Reply-To: <1510221.jHscAGkzr9@asterix> References: <87A14056-6B67-4DD3-86D5-8B3B3D772AE6@edeltech.ch> <3363757.ibj9NzLr3u@asterix> <7F5F9384-4D05-4CB2-8632-57111F218438@edeltech.ch> <1510221.jHscAGkzr9@asterix> Message-ID: On 22 juil. 2013, at 23:35, David Faure wrote: > On Monday 22 July 2013 23:19:00 Samuel Gaist wrote: >> Very good ! >> >> Something like a QPlatformSessionManager returned by the QPluginIntegration? > > I assume you mean QPlatformIntegration. Then yes. You're right >> It would essentially replace the current content of QSessionManagerPrivate >> with functions. > > Yes, for the benefit of the public methods that will have to call these. > Plus other virtual methods for the currently-unimplemented methods (e.g. > isPhase2() and others). > >> Should there be an abstract for this class with a default implementation >> (i.e QDefaultPlatformSessionManager) ? Or having the base class would be >> enough ? > > The base class can take care of the trivial getters/setters you mentionned > (e.g. restartCommand/setRestartCommand). > > In addition it could have empty implementations of the other virtuals (e.g. > isPhase2), for platforms that don't really support session management. Hmm, > well, the alternative is to just not instanciate a subclass, i.e. handling the > case of NULL in QSessionManager (you'll have to do that anyway, to avoid > having to implement session management in all platforms). > Ok then, I think I have the base to start. Should I open a bug report/feature request before for it or can I just start the implementation ? From simon.lees at codan.com.au Tue Jul 23 02:50:02 2013 From: simon.lees at codan.com.au (Simon Lees) Date: Tue, 23 Jul 2013 10:20:02 +0930 Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <2171360.MuxoQFPleD@hal> References: <51DF61BF.5040304@codan.com.au> <51E61E0B.4050105@codan.com.au> <2171360.MuxoQFPleD@hal> Message-ID: <51EDD33A.2080603@codan.com.au> On 07/22/2013 08:44 PM, Stephen Kelly wrote: > On Wednesday, July 17, 2013 14:01:07 Simon Lees wrote: >> this embeds SONAME libQt5x.so.5 into the Qt Libraries and NEEDED >> libQt5Core.so.5 this is a good start as it removes the fixed path from >> the needed line. It still causes issues on android however, as it tries >> to load libQt5Core.so.5 etc that does not exist. > I just submitted https://codereview.qt-project.org/#change,61330 and then re- > read this. > > Does this mean that my patch is wrong? > > Thanks, > Hi, I set the following /"/QMAKE_LFLAGS_SONAME = -Wl,-soname=" i am unsure if this is functionally equivalent to my change, hopefully i will get a chance to try it later today. This provides a improvement for me but it is not a complete solution, on android we load libQt5xxx.so my solution as it was still tried to load libQt5xxx.so.5 which doesn't exist as libraries are not symlinked on android like they are on Linux and only libQt5xxx.so is present. If there is a way to tell cmake to specify NEEDED as libQt5xxx.so instead of libQt5xxx.so.5 in a CMakeLists.txt or in the toolchain files then a solution that achieves the same result as mine is correct. I didn't spend a great deal of time working on a solution for this second part, the one or two things i tried, mainly removing version numbers in the cmake toolchain files didn't help so i went back and wrote a script that modified the make files to have -soname=libQt5xxx.so instead of -soname=libQt5xxx.so.5 which does work without changes to cmake, i just couldn't figure out how to make the Qt configure scripts generate this. I will test your change in the next day or two but i suspect it won't be a complete fix. Cheers, Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.kelly at kdab.com Tue Jul 23 06:56:38 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Tue, 23 Jul 2013 06:56:38 +0200 Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <51EDD33A.2080603@codan.com.au> References: <2171360.MuxoQFPleD@hal> <51EDD33A.2080603@codan.com.au> Message-ID: <4082192.eQr6N3KKOd@hal> On Tuesday, July 23, 2013 10:20:02 Simon Lees wrote: > This provides a improvement for me but it is not a complete solution, on > android we load libQt5xxx.so my solution as it was still tried to load > libQt5xxx.so.5 which doesn't exist as libraries are not symlinked on > android like they are on Linux and only libQt5xxx.so is present. Then perhaps this is the reason that the variable is simply cleared on Android. qmake should probably generate the SONAME without the version on android? Ossi, is that possible? Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From lykurg at gmail.com Tue Jul 23 07:25:30 2013 From: lykurg at gmail.com (Lorenz Haas) Date: Tue, 23 Jul 2013 07:25:30 +0200 Subject: [Development] QSpinBox 1 up/down click changes value by 2 steps In-Reply-To: <51ED6D5C.4070903@fnal.gov> References: <51ED6D5C.4070903@fnal.gov> Message-ID: <51EE13CA.4030301@gmail.com> Hi, for me it all looks like a bug. Have you filed a bug repost (bugreports.qt-project.org)? Funny part is when you donwstip it to minimal #include #include #include class SomeObject : public QObject { Q_OBJECT public Q_SLOTS: void someSlot(int) { sleep(1); // Simulate a model that as bit of work to do to update itself } }; int main(int argc, char *argv[]) { QApplication app(argc, argv); QSpinBox spinBox; spinBox.setValue(35); spinBox.show(); SomeObject o; QObject::connect(&spinBox, SIGNAL(valueChanged(int)), &o, SLOT(someSlot(int))); return app.exec(); } #include "main.moc" the fist click works like expected, all following in/decreases the value by two. Best, Lorenz Am 22.07.2013 19:35, schrieb Carl Schumann: > Hi, > > I am having some problem with my use of Qt's QSpinBox. In my > application QSpinBox 1 up/down click changes the boxes value by 2 > steps. (There are two separate valueChanged signals each by one > step.) The issue appears to be related to the amount of time taken by > a slot attached to the valueChanged signal. I have attached the > small amount of source code needed to reproduce the issue, which is > based on an example in the Qt 4 2nd Edition textbook. I am > experiencing this bug with Qt 4.8.4. I don't have access to Qt 5 > because of incompatibilities with our Linux distribution. I did try it > on Qt 4.5.0 and got 3 steps for each click. > > I am not sure what expectations are put on slot code. Are slots > expected to meet time constraints? If no, have I found a bug Qt? > > Sincerely, > Carl Schumann > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From Shawn.Rutledge at digia.com Tue Jul 23 07:41:40 2013 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Tue, 23 Jul 2013 05:41:40 +0000 Subject: [Development] API review for FolderListModel In-Reply-To: References: Message-ID: <75ECBEBD-7629-4E93-A446-1656A162B0B4@digia.com> On 26 Jun 2013, at 7:41 PM, Alan Alpert wrote: > On Wed, Jun 26, 2013 at 6:27 AM, Rutledge Shawn > wrote: >> I just wrote up this task >> >> https://bugreports.qt-project.org/browse/QTBUG-32039 >> >> because while implementing the QML FileDialog I ran into some issues; those are the ones I can remember, at least. If anyone has noticed any further annoyances in the FolderListModel API, please feel free to add to that list. > > The API review should happen on the ML, not in a JIRA task. Or are you > wanting to collect issues and opinions for a review "later"? Because > otherwise we could just start it right here, right now... > > PS: Should this be on the proposed new QtQuick mailing list? I kind of > like the idea of having the API reviews on a shared user/developer ML > to get some direct user input. So what is the process for actually starting the API review on the list then? I suggest we should start it so that FolderListModel can possibly become a supported API in 5.2. I've added a couple of links to patches in the works for QTBUG-32039. From dmitry.ashkadov at gmail.com Tue Jul 23 08:27:10 2013 From: dmitry.ashkadov at gmail.com (Dmitry Ashkadov) Date: Tue, 23 Jul 2013 10:27:10 +0400 Subject: [Development] CMake problem Message-ID: <51EE223E.1050404@gmail.com> Hello! I've found that next CMake script doesn't work as expected: > cmake_minimum_required(VERSION 2.8.9) > > find_package(Qt5 5.1.0 REQUIRED COMPONENTS Core LinguistTools) > > add_custom_target(lupdate COMMAND "${Qt5_LUPDATE_EXECUTABLE}" -version) If a "libdir" option of configure script is set to be not a subdirectory of PREFIX (a path, specified with option "-prefix") then command "make lupdate" will cause errors. For example, for prefix == /usr/lib64/qt5 and libdir == /usr/lib64: > $ make lupdate > make[3]: /usr/lib64/cmake/Qt5LinguistTools/bin/lupdate: Command not found > make[3]: *** [CMakeFiles/lupdate] Error 127 > make[2]: *** [CMakeFiles/lupdate.dir/all] Error 2 > make[1]: *** [CMakeFiles/lupdate.dir/rule] Error 2 > make: *** [lupdate] Error 2 It seems like qmake project file assumes that libdir must be a subdirectory of prefix and generates wrong CMake config file. This problem makes macro add_translations() causing errors. Thank you! From david.faure at kdab.com Tue Jul 23 09:59:40 2013 From: david.faure at kdab.com (David Faure) Date: Tue, 23 Jul 2013 09:59:40 +0200 Subject: [Development] Qt 5 QSessionManager In-Reply-To: References: <87A14056-6B67-4DD3-86D5-8B3B3D772AE6@edeltech.ch> <1510221.jHscAGkzr9@asterix> Message-ID: <18594630.5EGAlibTmW@asterix> On Monday 22 July 2013 23:51:23 Samuel Gaist wrote: > Should I open a bug report/feature request before for it or can I just start > the implementation ? This is part of QTBUG-28228. -- David Faure | david.faure at kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From stephen.kelly at kdab.com Tue Jul 23 10:37:16 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Tue, 23 Jul 2013 10:37:16 +0200 Subject: [Development] CMake problem In-Reply-To: <51EE223E.1050404@gmail.com> References: <51EE223E.1050404@gmail.com> Message-ID: <1492633.DoOfFo7deQ@hal> On Tuesday, July 23, 2013 10:27:10 Dmitry Ashkadov wrote: > If a "libdir" option of configure script is set to be not a subdirectory > of PREFIX (a path, specified with option "-prefix") then command "make > lupdate" will cause errors. I filed https://bugreports.qt-project.org/browse/QTBUG-32570 and pushed a few patches: https://codereview.qt-project.org/#dashboard,1000592 Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dmitry.ashkadov at gmail.com Tue Jul 23 10:42:03 2013 From: dmitry.ashkadov at gmail.com (Dmitry Ashkadov) Date: Tue, 23 Jul 2013 12:42:03 +0400 Subject: [Development] One more possible CMake related problem Message-ID: <51EE41DB.7010805@gmail.com> Hello! Here is a piece of code of qtbase/mkspecs/features/data/cmake/Qt5BasicConfig.cmake.in : > !!IF isEmpty(CMAKE_DLL_DIR_IS_ABSOLUTE) > set(imported_location > \"${_qt5$${CMAKE_MODULE_NAME}_install_prefix}/$${CMAKE_DLL_DIR}${LIB_LOCATION}\") > !!ELSE > set(imported_location \"IMPORTED_LOCATION_${Configuration}\" > \"$${CMAKE_DLL_DIR}${LIB_LOCATION}\") > !!ENDIF > _qt5_$${CMAKE_MODULE_NAME}_check_file_exists(${imported_location}) > set_target_properties(Qt5::$${CMAKE_MODULE_NAME} PROPERTIES > \"IMPORTED_LINK_INTERFACE_LIBRARIES_${Configuration}\" > \"${_Qt5$${CMAKE_MODULE_NAME}_LIB_DEPENDENCIES}\" > \"IMPORTED_LOCATION_${Configuration}\" ${imported_location} > !!IF !isEmpty(CMAKE_LIB_SONAME) > \"IMPORTED_SONAME_${Configuration}\" \"$${CMAKE_LIB_SONAME}\" > !!ENDIF > ) if isEmpty(CMAKE_DLL_DIR_IS_ABSOLUTE) is false then imported_location will contain something like IMPORTED_LOCATION_Debug or IMPORTED_LOCATION_Release, so, the following _qt5_$${CMAKE_MODULE_NAME}_check_file_exists(${imported_location}) will check for an existence of file having name "IMPORTED_LOCATION_*" and then fail. It seems like there is a mistake. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.kelly at kdab.com Tue Jul 23 11:37:19 2013 From: stephen.kelly at kdab.com (Stephen Kelly) Date: Tue, 23 Jul 2013 11:37:19 +0200 Subject: [Development] One more possible CMake related problem In-Reply-To: <51EE41DB.7010805@gmail.com> References: <51EE41DB.7010805@gmail.com> Message-ID: <11652310.VgMWP5OyOE@hal> On Tuesday, July 23, 2013 12:42:03 Dmitry Ashkadov wrote: > > if isEmpty(CMAKE_DLL_DIR_IS_ABSOLUTE) is false then imported_location > will contain something like IMPORTED_LOCATION_Debug or > IMPORTED_LOCATION_Release Good catch! Fixed with https://codereview.qt-project.org/#change,61428 Thanks, -- Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com Stephen Kelly | 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From sergio.ahumada at digia.com Tue Jul 23 11:39:26 2013 From: sergio.ahumada at digia.com (Sergio Ahumada) Date: Tue, 23 Jul 2013 11:39:26 +0200 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: <2212912.dYLGM2pAiE@tjmaciei-mobl2> References: <11162927.8vSKeZ4urK@hal> <51D186FD.1030506@digia.com> <2212912.dYLGM2pAiE@tjmaciei-mobl2> Message-ID: <51EE4F4E.9030508@digia.com> On 07/01/2013 05:34 PM, Thiago Macieira wrote: > On segunda-feira, 1 de julho de 2013 15.41.17, Sergio Ahumada wrote: >> What makes it official ? Has this been discussed ? > > We're shipping the files, which makes them official. If someone is using cmake, > our files are the official way of building their applications for Qt 5. > > However, the recommended way in our documentation and examples to build Qt 5 > applications remains qmake. > > Can we please start working on changing that? I guess it's a (hot?) topic for > QtCS... > Hi, Going back to the original question now that the QtCS has passed. - Is cmake officially supported by the Qt Project ? - Should cmake changes go to the 'release' branch for Qt 5.1.1 ? - Was this even discussed during the QtCS ? I have no strong feelings about cmake, just want to know whether a decision was made or not. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt From Martin.Kroell at ehrhardt-partner.com Tue Jul 23 11:44:50 2013 From: Martin.Kroell at ehrhardt-partner.com (Martin.Kroell at ehrhardt-partner.com) Date: Tue, 23 Jul 2013 11:44:50 +0200 Subject: [Development] Qt Location vs. Qt Mobility Message-ID: Hi, I'm confused about Qt Location and Qt Mobility. Currently I use the location module of Qt Mobility 1.2.0 to display maps with Qt 4.8. But now there is the Qt module "Location". In the Git repository, there are both, the Qt module and the Qt Mobility module. What is what? Is the Qt Mobility for Qt4 and Qt Location (without Mobility) for Qt 5? What's about the bug tracker, is Qt Mobility obsolete? Best regards Martin Kröll From Alexander.Blasche at digia.com Tue Jul 23 12:33:22 2013 From: Alexander.Blasche at digia.com (Blasche Alexander) Date: Tue, 23 Jul 2013 10:33:22 +0000 Subject: [Development] Qt Location vs. Qt Mobility In-Reply-To: References: Message-ID: Hi Martin, > -----Original Message----- > From: development-bounces+alexander.blasche=digia.com at qt-project.org > [mailto:development-bounces+alexander.blasche=digia.com at qt- > project.org] On Behalf Of Martin.Kroell at ehrhardt-partner.com > Hi, > I'm confused about Qt Location and Qt Mobility. Currently I use the > location module of Qt Mobility 1.2.0 to display maps with Qt 4.8. But now > there is the Qt module "Location". > In the Git repository, there are both, the Qt module and the Qt Mobility > module. What is what? Is the Qt Mobility for Qt4 and Qt Location (without > Mobility) for Qt 5? QtMobility as such was discontinued when its API's were added to Qt5. Indeed QtMobility supports Qt4 only and I believe the last officially tested version was based on Qt 4.7. There are some users of Qt Mobility who are still patching the libraries. Hence it actually works with Qt4.8 as well. The way forward is the Qt Location module which is a port of the Qt Mobility Location library. Note that there are API changes between the two lines. > What's about the bug tracker, is Qt Mobility obsolete? Yes it is. As mentioned above, the community seems to still patch some aspects of QtMobility but it doesn't change the fact that it is end of line. The same pretty much applies to the QtMobility Jira project. There should be a component inside the Qt project for each former QtMobility API. Those refer to the new Qt 5 modules. -- Alex From jedrzej.nowacki at digia.com Tue Jul 23 13:25:44 2013 From: jedrzej.nowacki at digia.com (Jedrzej Nowacki) Date: Tue, 23 Jul 2013 13:25:44 +0200 Subject: [Development] Bug management and jira workflow Message-ID: <201307231325.44951.jedrzej.nowacki@digia.com> Hi, At the Qt Contributor Summit, we had a really good discussion about bugs and jira, here is the summary: - We have untriaged bugs, we may not be able to triage them all, but we should keep it’s count as low as possible. - We agreed on “triaging” definition. Triaging consist of: - checking if a bug report is sensible. It means the reported issue is not a result of a user mistake, use of undefined behavior etc. - checking if a bug report is not missing an important data, so it would be possible to reproduce it in future - setting a priority - optionally the bug report may be verified. It it is reproduced then it should be accept which means moved to open state Rationale: It looks like the most common behavior of people triaging bugs. - Who can prioritize bugs? - whoever ask - we will create a special group in jira - approvers should be in the group by default Rationale: We do not have man power and we need help. We do not expect anyone to destroy our precious bugs reports or play “ping pong” with a priority. - What does it mean “fixed version” in bug report - we do not fill it until an issue is really fixed, which means merged - we do not want to use the field for estimation - we know that it can be filled automatically, it would be nice to implement that. - Jira workflow was designed for much bigger team, that includes QA department, it should be simplify - We decided that “in progress” state means that someone started work on a bug or it have a fix which is not merged yet. Time statistics doesn’t show anything, anyway. - Resolved, Verified and Closed should be merged to a single state. Nobody is going through Resloved bugs to verify them. - It would be nice to have a transition from Open to Closed state Cheers, Jędrek From oswald.buddenhagen at digia.com Tue Jul 23 13:57:26 2013 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Tue, 23 Jul 2013 13:57:26 +0200 Subject: [Development] Bug management and jira workflow In-Reply-To: <201307231325.44951.jedrzej.nowacki@digia.com> References: <201307231325.44951.jedrzej.nowacki@digia.com> Message-ID: <20130723115726.GA26177@troll08.it.local> On Tue, Jul 23, 2013 at 01:25:44PM +0200, Jedrzej Nowacki wrote: > At the Qt Contributor Summit, we had a really good discussion about bugs and > jira, here is the summary: > - We agreed on “triaging” definition. Triaging consist of: > - checking if a bug report is sensible. It means the reported issue is not > a result of a user mistake, use of undefined behavior etc. > for build-related problems that sounds a lot easier than it actually is. not saying that the process is not applicable, but i really could use some qualified help. > - Who can prioritize bugs? > - whoever ask > - we will create a special group in jira > we already have it (Triagers) ... it's just not "wired" yet. we have some more groups which are kinda redundant or plain weird: Developers vs. OGApprovers (the latter seems pointless; the former is a default group, if i got it right). Qt - ?!? then there is a whole bunch of company-related groups. i don't think they have much value at this point. just clear them out? lastly, there is a lot of component-related groups. do we consider these having any value? > - What does it mean “fixed version” in bug report > - we do not fill it until an issue is really fixed, which means merged > - we do not want to use the field for estimation > i'm not sure i like that. i thoroughly dislike the idea of the "release blocker meta-tasks". this is exactly what a prospective fix version plus the right filter would do. that of course implies that the field must be used exclusively as a deadline designation, not an expession of wishful thinking. > - Jira workflow was designed for much bigger team, that includes QA > department, it should be simplify > - Resolved, Verified and Closed should be merged to a single state. Nobody > is going through Resloved bugs to verify them. > i was considering slashing only Verified, but ran into awkwardness while pondering state transitions, so i guess i agree with this radical cure. From mitch.curtis at digia.com Tue Jul 23 14:03:48 2013 From: mitch.curtis at digia.com (Mitch Curtis) Date: Tue, 23 Jul 2013 14:03:48 +0200 Subject: [Development] Bug management and jira workflow In-Reply-To: <201307231325.44951.jedrzej.nowacki@digia.com> References: <201307231325.44951.jedrzej.nowacki@digia.com> Message-ID: <51EE7124.2030506@digia.com> It's good that this stuff is being discussed. :) On 07/23/2013 01:25 PM, Jedrzej Nowacki wrote: > > - Who can prioritize bugs? > - whoever ask > - we will create a special group in jira > - approvers should be in the group by default > Rationale: We do not have man power and we need help. We do not expect > anyone to destroy our precious bugs reports or play “ping pong” with a > priority. However, I think that very few people will click the little "?" help icon when assigning a priority to a bug they're creating. The reason I say this is that most of the bugs created go without any markup (which means code turns into a mess, text dumps aren't wrapped within a scroll area, etc.), the help for which is available through that same "?" icon. On the other hand, I doubt many users would be interested in requesting these rights (and very few - hopefully none - of those would misuse it), so it probably won't be an issue. Regardless, if we're making changes to Jira, we could add a line of red text under the priority field that shows up when a high priority is selected, to inform the user that the priority they've selected has certain criteria that the bug has to meet. From lpapp at kde.org Tue Jul 23 14:18:20 2013 From: lpapp at kde.org (Laszlo Papp) Date: Tue, 23 Jul 2013 13:18:20 +0100 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: <51EE4F4E.9030508@digia.com> References: <11162927.8vSKeZ4urK@hal> <51D186FD.1030506@digia.com> <2212912.dYLGM2pAiE@tjmaciei-mobl2> <51EE4F4E.9030508@digia.com> Message-ID: On Tue, Jul 23, 2013 at 10:39 AM, Sergio Ahumada wrote: > - Should cmake changes go to the 'release' branch for Qt 5.1.1 ? > Yes, please. > - Was this even discussed during the QtCS ? > It would have been nice if a few Digia people had attended to the session. Cheers, Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jedrzej.nowacki at digia.com Tue Jul 23 14:35:49 2013 From: jedrzej.nowacki at digia.com (Jedrzej Nowacki) Date: Tue, 23 Jul 2013 14:35:49 +0200 Subject: [Development] Bug management and jira workflow In-Reply-To: <20130723115726.GA26177@troll08.it.local> References: <201307231325.44951.jedrzej.nowacki@digia.com> <20130723115726.GA26177@troll08.it.local> Message-ID: <201307231435.49479.jedrzej.nowacki@digia.com> On Tuesday 23. July 2013 13.57.26 Oswald Buddenhagen wrote: > On Tue, Jul 23, 2013 at 01:25:44PM +0200, Jedrzej Nowacki wrote: > > At the Qt Contributor Summit, we had a really good discussion about > > bugs and > > > > jira, here is the summary: > > - We agreed on “triaging” definition. Triaging consist of: > > - checking if a bug report is sensible. It means the reported issue > > is not > > > > a result of a user mistake, use of undefined behavior etc. > > for build-related problems that sounds a lot easier than it actually is. > not saying that the process is not applicable, but i really could use > some qualified help. Sure, the idea was to make the process significantly lighter then fixing the bug. > > - Who can prioritize bugs? > > > > - whoever ask > > - we will create a special group in jira > > we already have it (Triagers) ... it's just not "wired" yet. Good, who can "wire" the group? > we have some more groups which are kinda redundant or plain weird: > Developers vs. OGApprovers (the latter seems pointless; the former is a > default group, if i got it right). > Qt - ?!? > then there is a whole bunch of company-related groups. i don't think > they have much value at this point. just clear them out? > lastly, there is a lot of component-related groups. do we consider > these having any value? We haven't discussed that. From my point of view the old groups may be removed. > > - What does it mean “fixed version” in bug report > > > > - we do not fill it until an issue is really fixed, which means > > merged - we do not want to use the field for estimation > > i'm not sure i like that. i thoroughly dislike the idea of the "release > blocker meta-tasks". this is exactly what a prospective fix version plus > the right filter would do. that of course implies that the field must be > used exclusively as a deadline designation, not an expession of wishful > thinking. Yes, we were discussing which definition we should pick. We decided that not using the field for estimation is better from a random user point of view, that could check which Qt version is actually fixed, without cloning the repository. It doesn't create a wish list either. It seems to be also aligned with idea of time based releases, that changes are released, only if they were merged before a certain date. > > - Jira workflow was designed for much bigger team, that includes QA > > > > department, it should be simplify > > > > - Resolved, Verified and Closed should be merged to a single state. > > Nobody > > > > is going through Resloved bugs to verify them. > > i was considering slashing only Verified, but ran into awkwardness while > pondering state transitions, so i guess i agree with this radical cure. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From olivier at woboq.com Tue Jul 23 15:09:20 2013 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 23 Jul 2013 15:09:20 +0200 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: References: <51EE4F4E.9030508@digia.com> Message-ID: <8834850.1baQR66NqF@gargamel> On Tuesday 23 July 2013 13:18:20 Laszlo Papp wrote: > On Tue, Jul 23, 2013 at 10:39 AM, Sergio Ahumada > > wrote: > > - Should cmake changes go to the 'release' branch for Qt 5.1.1 ? > > Yes, please. No. Unless they fix critical regressions of course. Normal rules for the 'release' branck apply here. a change to the cmake files is no different from a change to QPushButton or to the qmake files. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From frederik.gladhorn at digia.com Tue Jul 23 15:11:14 2013 From: frederik.gladhorn at digia.com (Frederik Gladhorn) Date: Tue, 23 Jul 2013 15:11:14 +0200 Subject: [Development] Nominating Kevin Ottens as Approver Message-ID: <10047846.3fY7jupRTn@varney> Hi, I would like to nominate Kevin Ottens as approver for the Qt Project. Kevin has been working on KDE for a long time and has lately worked hard to get more patches into Qt especially as part of KDE Frameworks 5. You can find him on IRC as "ervin" and he works at KDAB. His dashboard: https://codereview.qt-project.org/#dashboard,1001931 https://codereview.qt-project.org/#q,owner:Kevin%252BOttens,n,z His list of reviews: https://codereview.qt-project.org/#q,reviewer:Kevin%252BOttens,n,z -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com From olivier at woboq.com Tue Jul 23 15:19:27 2013 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 23 Jul 2013 15:19:27 +0200 Subject: [Development] Nominating Kevin Ottens as Approver In-Reply-To: <10047846.3fY7jupRTn@varney> References: <10047846.3fY7jupRTn@varney> Message-ID: <458218597.yHpGkGlC0G@gargamel> On Tuesday 23 July 2013 15:11:14 Frederik Gladhorn wrote: > Hi, > > I would like to nominate Kevin Ottens as approver for the Qt Project. +1 From Alexander.Blasche at digia.com Tue Jul 23 15:21:05 2013 From: Alexander.Blasche at digia.com (Blasche Alexander) Date: Tue, 23 Jul 2013 13:21:05 +0000 Subject: [Development] Bug management and jira workflow In-Reply-To: <201307231435.49479.jedrzej.nowacki@digia.com> References: <201307231325.44951.jedrzej.nowacki@digia.com> <20130723115726.GA26177@troll08.it.local> <201307231435.49479.jedrzej.nowacki@digia.com> Message-ID: > -----Original Message----- > From: development-bounces+alexander.blasche=digia.com at qt-project.org > > > - Who can prioritize bugs? > > > > > > - whoever ask > > > - we will create a special group in jira > > > > we already have it (Triagers) ... it's just not "wired" yet. > Good, who can "wire" the group? Why do we need yet another group? Any approver can do that already. Or what am I missing? > > we have some more groups which are kinda redundant or plain weird: > > Developers vs. OGApprovers (the latter seems pointless; the former is a > > default group, if i got it right). > > Qt - ?!? > > then there is a whole bunch of company-related groups. i don't think > > they have much value at this point. just clear them out? > > lastly, there is a lot of component-related groups. do we consider > > these having any value? They don't have much value. Unfortunately cleaning them out is a major pain as they have references to Permission, Notification and security schemes and here we are not even talking about all the custom filters. > > > - What does it mean “fixed version” in bug report > > > > > > - we do not fill it until an issue is really fixed, which means > > > merged - we do not want to use the field for estimation > > > > i'm not sure i like that. i thoroughly dislike the idea of the "release > > blocker meta-tasks". this is exactly what a prospective fix version plus > > the right filter would do. that of course implies that the field must be > > used exclusively as a deadline designation, not an expession of wishful > > thinking. > Yes, we were discussing which definition we should pick. We decided that > not > using the field for estimation is better from a random user point of view, that > could check which Qt version is actually fixed, without cloning the repository. > It doesn't create a wish list either. It seems to be also aligned with idea of > time based releases, that changes are released, only if they were merged > before a certain date. I can see where there might be a confusion. However if I have a choice between the double loading of the Fix for Version and a release blocker task then I vote for the FixFor version field. The release blocker task doesn't even come close to a replacement. One of the most common filters is "What's unresolved and assigned to me for the next release?". Fix for is exactly what you need in this case. Also, as long as the task is not closed it can never be mistaken for a "really fixed" case anyway. A somewhat better method would be to Split the FixFor field into two fields (e.g. PlannedFor vs FixedIn). But even if we assume that FixFor really means released in version x.y.z, who is going to set it? You cannot set the field until very late in the process. That's exactly what you would do during the Verified->Closed transition (BTW the transition is called "Release") and the most likely candidate would be the release team. However this collides with the desire to merge the Resolved/Verified/Closed states because nobody transitions the verified tasks to closed. To me this sounds like the same problem. Nobody wants to clean the tasks right before the release. On the other hand you can actually use the Verified to Closed transition to disambiguate the meaning of FixFor. If it is not closed then it always means that the field is an estimation. If it is closed then it's either part of a release line or it was rejected/invalid/ignored (which means FixFor is invalid anyway). It does imply some issue massaging shortly before the release though. -- Alex From frederik.gladhorn at digia.com Tue Jul 23 15:21:55 2013 From: frederik.gladhorn at digia.com (Frederik Gladhorn) Date: Tue, 23 Jul 2013 15:21:55 +0200 Subject: [Development] Bug management and jira workflow In-Reply-To: <51EE7124.2030506@digia.com> References: <201307231325.44951.jedrzej.nowacki@digia.com> <51EE7124.2030506@digia.com> Message-ID: <2531935.VoZvZA8GHF@varney> Tirsdag 23. juli 2013 14.03.48 skrev Mitch Curtis: > It's good that this stuff is being discussed. :) > > On 07/23/2013 01:25 PM, Jedrzej Nowacki wrote: > > - Who can prioritize bugs? > > > > - whoever ask > > - we will create a special group in jira > > - approvers should be in the group by default > > > > Rationale: We do not have man power and we need help. We do not expect > > > > anyone to destroy our precious bugs reports or play “ping pong” with a > > priority. > > However, I think that very few people will click the little "?" help > icon when assigning a priority to a bug they're creating. The reason I > say this is that most of the bugs created go without any markup (which > means code turns into a mess, text dumps aren't wrapped within a scroll > area, etc.), the help for which is available through that same "?" icon. > On the other hand, I doubt many users would be interested in requesting > these rights (and very few - hopefully none - of those would misuse it), > so it probably won't be an issue. We discussed about the dangers as well. Maybe it makes sense to elaborate a little. Abuse means you lose you rights. Someone will notice quite quickly. We expect good judgement from everyone here. Of course there will be corner cases, but that's already the case, so the issue of "what's the right priority" stays unchanged. The hope is that we can do "bug triaging days" on a regular basis involving everyone interested. For the Oslo (and lately Berlin) office it has worked to spend Tuesdays to work with incomming bugs (see definition of "triaged bugs" in the first mail). The main goal is to identify real release blockers that need to be fixed quickly. > > Regardless, if we're making changes to Jira, we could add a line of red > text under the priority field that shows up when a high priority is > selected, to inform the user that the priority they've selected has > certain criteria that the bug has to meet. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com From rafael.roquetto at kdab.com Tue Jul 23 15:25:38 2013 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Tue, 23 Jul 2013 10:25:38 -0300 Subject: [Development] Nominating Kevin Ottens as Approver In-Reply-To: <10047846.3fY7jupRTn@varney> References: <10047846.3fY7jupRTn@varney> Message-ID: <20130723132538.GB1092@polaris> +1 Kevin is one of the most focused and pragmatic people I have worked with. On Tue, Jul 23, 2013 at 03:11:14PM +0200, Frederik Gladhorn wrote: > Hi, > > I would like to nominate Kevin Ottens as approver for the Qt Project. > > Kevin has been working on KDE for a long time and has lately worked hard to > get more patches into Qt especially as part of KDE Frameworks 5. > > You can find him on IRC as "ervin" and he works at KDAB. > > His dashboard: > https://codereview.qt-project.org/#dashboard,1001931 > https://codereview.qt-project.org/#q,owner:Kevin%252BOttens,n,z > > His list of reviews: > https://codereview.qt-project.org/#q,reviewer:Kevin%252BOttens,n,z > > > -- > Best regards, > Frederik Gladhorn > Senior Software Engineer - Digia, Qt > Visit us on: http://qt.digia.com > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions Join us in October at Qt Developer Days 2013! - https://devdays.kdab.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4861 bytes Desc: not available URL: From olivier at woboq.com Tue Jul 23 15:27:01 2013 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 23 Jul 2013 15:27:01 +0200 Subject: [Development] Bug management and jira workflow In-Reply-To: <51EE7124.2030506@digia.com> References: <201307231325.44951.jedrzej.nowacki@digia.com> <51EE7124.2030506@digia.com> Message-ID: <1554127.L4VNrstyJV@gargamel> On Tuesday 23 July 2013 14:03:48 Mitch Curtis wrote: > [...] most of the bugs created go without any markup (which > means code turns into a mess, text dumps aren't wrapped within a scroll > area, etc.), the help for which is available through that same "?" icon. Which is why I would like that jira display the comment in monospace with line break on by default. I reported an issue about that at the very beginning, but nothing was done. https://bugreports.qt-project.org/browse/QTJIRA-88 > [...] > Regardless, if we're making changes to Jira, we could add a line of red > text under the priority field that shows up when a high priority is > selected, to inform the user that the priority they've selected has > certain criteria that the bug has to meet. I beleive that the ones that are going to request it will have read the wiki about or jira workflow and then will know that. It's not so easy to change JIRA and I don't think it's worth it. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From lpapp at kde.org Tue Jul 23 15:35:13 2013 From: lpapp at kde.org (Laszlo Papp) Date: Tue, 23 Jul 2013 14:35:13 +0100 Subject: [Development] Qt Project 'official way' and maintenance? (Was: Qt 5.1.0 rc2 is out) In-Reply-To: <8834850.1baQR66NqF@gargamel> References: <51EE4F4E.9030508@digia.com> <8834850.1baQR66NqF@gargamel> Message-ID: On Tue, Jul 23, 2013 at 2:09 PM, Olivier Goffart wrote: > On Tuesday 23 July 2013 13:18:20 Laszlo Papp wrote: > > On Tue, Jul 23, 2013 at 10:39 AM, Sergio Ahumada > > > > wrote: > > > - Should cmake changes go to the 'release' branch for Qt 5.1.1 ? > > > > Yes, please. > > No. > > Unless they fix critical regressions of course. Normal rules for the > 'release' > branck apply here. a change to the cmake files is no different from a > change to > QPushButton or to the qmake files. I agree, and that is why I think cmake should not be discriminated negatively with P0/P1 bug reports and fixes. That is what I mean by "Yes". Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From joerg.bornemann at digia.com Tue Jul 23 15:37:07 2013 From: joerg.bornemann at digia.com (Joerg Bornemann) Date: Tue, 23 Jul 2013 15:37:07 +0200 Subject: [Development] Bug management and jira workflow In-Reply-To: References: <201307231325.44951.jedrzej.nowacki@digia.com> <20130723115726.GA26177@troll08.it.local> <201307231435.49479.jedrzej.nowacki@digia.com> Message-ID: <51EE8703.9010504@digia.com> On 23/07/2013 15:21, Blasche Alexander wrote: > I can see where there might be a confusion. However if I have a choice between the double loading of the Fix for Version and a release blocker task then I vote for the FixFor version field. The release blocker task doesn't even come close to a replacement. One of the most common filters is "What's unresolved and assigned to me for the next release?". Fix for is exactly what you need in this case. Also, as long as the task is not closed it can never be mistaken for a "really fixed" case anyway. > A somewhat better method would be to Split the FixFor field into two fields (e.g. PlannedFor vs FixedIn). I'm also using the FixFor field for scheduling the issues assigned to me. IMO the blocker meta-tasks can be replaced by consequently using the FixedFor field, because there already is a logical split: FixFor in unresolved issues == PlannedFor FixFor in resolved issued == FixedIn Cheers, Joerg -- Joerg Bornemann Digia, Qt http://qt.digia.com/ From olivier at woboq.com Tue Jul 23 15:38:40 2013 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 23 Jul 2013 15:38:40 +0200 Subject: [Development] Bug management and jira workflow In-Reply-To: References: <201307231325.44951.jedrzej.nowacki@digia.com> <201307231435.49479.jedrzej.nowacki@digia.com> Message-ID: <2147962.1nTc4imZ6e@gargamel> On Tuesday 23 July 2013 13:21:05 Blasche Alexander wrote: > > -----Original Message----- > > From: development-bounces+alexander.blasche=digia.com at qt-project.org > > > > > > - Who can prioritize bugs? > > > > - whoever ask > > > > - we will create a special group in jira > > > > > > we already have it (Triagers) ... it's just not "wired" yet. > > > > Good, who can "wire" the group? > > Why do we need yet another group? Any approver can do that already. Or what > am I missing? Approver is a level above. We beleive there is a difference between being able to push code to the repository, and set the priority or the assignee to a bug report. Almost everybody should be able to do the later. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From shane.kearns at accenture.com Tue Jul 23 16:44:01 2013 From: shane.kearns at accenture.com (shane.kearns at accenture.com) Date: Tue, 23 Jul 2013 14:44:01 +0000 Subject: [Development] GDB python pretty printers for common Qt classes In-Reply-To: <1612141.bsmXxlIqZu@asterix> References: <20825071.fu8Ir1fRJk@minime> <1612141.bsmXxlIqZu@asterix> Message-ID: <7163F5DC5711224C8D28FF8936EA845A41FF9B@048-CH1MPN1-054.048d.mgd.msft.net> > > I think getting it upstream for Qt5 only would be good. > > Hell yes :-) > This is a very good idea. > > What classes should be pretty-printable? > > QString is the most important one by far. > Collection classes come next. The internal format of QString & QByteArray changed between Qt 4 and Qt 5, for supporting QStringLiteral. So those most likely need some changes. I'd also suggest QUrl, as a commonly used 'string-like' class. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com From thiago.macieira at intel.com Tue Jul 23 16:54:16 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 23 Jul 2013 07:54:16 -0700 Subject: [Development] Nominating Kevin Ottens as Approver In-Reply-To: <10047846.3fY7jupRTn@varney> References: <10047846.3fY7jupRTn@varney> Message-ID: <1692803.1AUD6uzqHl@tjmaciei-mobl2> On terça-feira, 23 de julho de 2013 15.11.14, Frederik Gladhorn wrote: > Hi, > > I would like to nominate Kevin Ottens as approver for the Qt Project. > > Kevin has been working on KDE for a long time and has lately worked hard to > get more patches into Qt especially as part of KDE Frameworks 5. > > You can find him on IRC as "ervin" and he works at KDAB. > > His dashboard: > https://codereview.qt-project.org/#dashboard,1001931 > https://codereview.qt-project.org/#q,owner:Kevin%252BOttens,n,z > > His list of reviews: > https://codereview.qt-project.org/#q,reviewer:Kevin%252BOttens,n,z +1 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From kevin.ottens at kdab.com Tue Jul 23 17:31:46 2013 From: kevin.ottens at kdab.com (Kevin Ottens) Date: Tue, 23 Jul 2013 17:31:46 +0200 Subject: [Development] Nominating Kevin Ottens as Approver In-Reply-To: <10047846.3fY7jupRTn@varney> References: <10047846.3fY7jupRTn@varney> Message-ID: <171836450.RsX0BGqMAY@wintermute> Hello, On Tuesday 23 July 2013 15:11:14 Frederik Gladhorn wrote: > I would like to nominate Kevin Ottens as approver for the Qt Project. > > Kevin has been working on KDE for a long time and has lately worked hard to > get more patches into Qt especially as part of KDE Frameworks 5. Thanks for the nomination! Also thanks to the ones who expressed support so far, it is appreciated. Regards. -- Dr. Kevin Ottens | kevin.ottens at kdab.com | Software Craftsman KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4835 bytes Desc: not available URL: From bm_witness at yahoo.com Tue Jul 23 19:23:32 2013 From: bm_witness at yahoo.com (BRM) Date: Tue, 23 Jul 2013 10:23:32 -0700 (PDT) Subject: [Development] GDB python pretty printers for common Qt classes In-Reply-To: <7163F5DC5711224C8D28FF8936EA845A41FF9B@048-CH1MPN1-054.048d.mgd.msft.net> References: <20825071.fu8Ir1fRJk@minime> <1612141.bsmXxlIqZu@asterix> <7163F5DC5711224C8D28FF8936EA845A41FF9B@048-CH1MPN1-054.048d.mgd.msft.net> Message-ID: <1374600212.11464.YahooMailNeo@web126205.mail.ne1.yahoo.com> > From: "shane.kearns at accenture.com" >To: david.faure at kdab.com; development at qt-project.org >Sent: Tuesday, July 23, 2013 10:44 AM >Subject: Re: [Development] GDB python pretty printers for common Qt classes >> > I think getting it upstream for Qt5 only would be good. >> Hell yes :-) >This is a very good idea. Yes. Having something directly from Qt Project would be best. >> > What classes should be pretty-printable? >> QString is the most important one by far. >> Collection classes come next. >The internal format of QString & QByteArray changed between Qt 4 and Qt 5, >for supporting QStringLiteral. So those most likely need some changes. > >I'd also suggest QUrl, as a commonly used 'string-like' class. I'd suggest QByteArray be in there too; may be even QVariant. $0.02 Ben From tobias.hunger at gmail.com Tue Jul 23 19:27:55 2013 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Tue, 23 Jul 2013 19:27:55 +0200 Subject: [Development] GDB python pretty printers for common Qt classes In-Reply-To: <1374600212.11464.YahooMailNeo@web126205.mail.ne1.yahoo.com> References: <20825071.fu8Ir1fRJk@minime> <1612141.bsmXxlIqZu@asterix> <7163F5DC5711224C8D28FF8936EA845A41FF9B@048-CH1MPN1-054.048d.mgd.msft.net> <1374600212.11464.YahooMailNeo@web126205.mail.ne1.yahoo.com> Message-ID: There are pretty printers for most commonly used Qt types in Qt Creator. Can those be used? Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpapp at kde.org Tue Jul 23 19:40:21 2013 From: lpapp at kde.org (Laszlo Papp) Date: Tue, 23 Jul 2013 18:40:21 +0100 Subject: [Development] GDB python pretty printers for common Qt classes In-Reply-To: References: <20825071.fu8Ir1fRJk@minime> <1612141.bsmXxlIqZu@asterix> <7163F5DC5711224C8D28FF8936EA845A41FF9B@048-CH1MPN1-054.048d.mgd.msft.net> <1374600212.11464.YahooMailNeo@web126205.mail.ne1.yahoo.com> Message-ID: On Tue, Jul 23, 2013 at 6:27 PM, Tobias Hunger wrote: > There are pretty printers for most commonly used Qt types in Qt Creator. > Can those be used? > Link? Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From bm_witness at yahoo.com Tue Jul 23 19:41:02 2013 From: bm_witness at yahoo.com (BRM) Date: Tue, 23 Jul 2013 10:41:02 -0700 (PDT) Subject: [Development] GDB python pretty printers for common Qt classes In-Reply-To: References: <20825071.fu8Ir1fRJk@minime> <1612141.bsmXxlIqZu@asterix> <7163F5DC5711224C8D28FF8936EA845A41FF9B@048-CH1MPN1-054.048d.mgd.msft.net> <1374600212.11464.YahooMailNeo@web126205.mail.ne1.yahoo.com> Message-ID: <1374601262.29437.YahooMailNeo@web126205.mail.ne1.yahoo.com> > From: Tobias Hunger >To: BRM >Cc: development at qt-project.org; David Faure >Sent: Tuesday, July 23, 2013 1:27 PM >Subject: Re: [Development] GDB python pretty printers for common Qt classes >There are pretty printers for most commonly used Qt types in Qt Creator. Can those be used? They may have been mentioned before in the discussion - I seem to remember this one from some months back too, though I don't remember the end of that discussion...off hand, my guess is most likely yes - but I think the issue is they need to come with the Qt libraries instead of Qt Creator as not everyone uses or installs Qt Creator. Ben From thiago.macieira at intel.com Tue Jul 23 19:42:38 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 23 Jul 2013 10:42:38 -0700 Subject: [Development] GDB python pretty printers for common Qt classes In-Reply-To: References: <20825071.fu8Ir1fRJk@minime> <1374600212.11464.YahooMailNeo@web126205.mail.ne1.yahoo.com> Message-ID: <5202111.BRSpzJZ1Wk@tjmaciei-mobl2> On terça-feira, 23 de julho de 2013 19.27.55, Tobias Hunger wrote: > There are pretty printers for most commonly used Qt types in Qt Creator. > Can those be used? Those aren't "pretty" printers. Those are machine-readable dumpers of the types. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From david.faure at kdab.com Tue Jul 23 19:50:37 2013 From: david.faure at kdab.com (David Faure) Date: Tue, 23 Jul 2013 19:50:37 +0200 Subject: [Development] GDB python pretty printers for common Qt classes In-Reply-To: <1374601262.29437.YahooMailNeo@web126205.mail.ne1.yahoo.com> References: <20825071.fu8Ir1fRJk@minime> <1374601262.29437.YahooMailNeo@web126205.mail.ne1.yahoo.com> Message-ID: <1531622.SapAeiuik8@asterix> On Tuesday 23 July 2013 10:41:02 BRM wrote: > > From: Tobias Hunger > > > >To: BRM > >Cc: development at qt-project.org; David Faure > >Sent: Tuesday, July 23, 2013 1:27 PM > >Subject: Re: [Development] GDB python pretty printers for common Qt classes > >There are pretty printers for most commonly used Qt types in Qt Creator. > >Can those be used? > They may have been mentioned before in the discussion - I seem to remember > this one from some months back too, though I don't remember the end of that > discussion...off hand, my guess is most likely yes - but I think the issue > is they need to come with the Qt libraries instead of Qt Creator as not > everyone uses or installs Qt Creator. I'm pretty sure they output stuff in a format that is meant for Qt Creator, not for being readable by humans. -- David Faure | david.faure at kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From cmeyer1969+qt at gmail.com Tue Jul 23 21:16:57 2013 From: cmeyer1969+qt at gmail.com (Chris Meyer) Date: Tue, 23 Jul 2013 12:16:57 -0700 Subject: [Development] QtQuick External Drag Drop Partial Patch -- Help Requested Message-ID: I've been working on adding support for external drag and drop to QtQuick. I've created a patch which addresses the basic needs and have used the resulting capabilities in my non-trivial application to implement drag and drop between a QtQuick view and a widget. I'll need help on one particular feature: generating an image of the QtQuick item being dragged. Right now it doesn't use any image -- so dragging works, but the image is just a small gray rectangle. In addition, I need feedback on a design choice. I decided to not create a QtQuick MimeData item; but instead add accessor methods directly to DropEvent. This seems reasonable, but a future MimeData object could be re-used if we implement a similar Cut / Copy / Paste functionality. Any thoughts? Finally, I'll need some procedural help to make sure the patch is suitable to be added for Qt 5.2 -- specifically to make sure I get examples, tests, and documentation correct. Is there someone who has commit access who can help me through this patch? Here is the bug report: https://bugreports.qt-project.org/browse/QTBUG-27498 Here is the current code in my patch: https://codereview.qt-project.org/61017 It's not complete, but I'm willing to finish it off (with the help from above). I think this would make a useful addition to Qt 5.2. -------------- next part -------------- An HTML attachment was scrubbed... URL: From samuel.gaist at edeltech.ch Tue Jul 23 23:55:24 2013 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Tue, 23 Jul 2013 23:55:24 +0200 Subject: [Development] Qt 5 QSessionManager In-Reply-To: <18594630.5EGAlibTmW@asterix> References: <87A14056-6B67-4DD3-86D5-8B3B3D772AE6@edeltech.ch> <1510221.jHscAGkzr9@asterix> <18594630.5EGAlibTmW@asterix> Message-ID: On 23 juil. 2013, at 09:59, David Faure wrote: > On Monday 22 July 2013 23:51:23 Samuel Gaist wrote: >> Should I open a bug report/feature request before for it or can I just start >> the implementation ? > > This is part of QTBUG-28228. Thank you What copyright should I put on the new files ? The Digia notice like in QSessionManager ? From thiago.macieira at intel.com Wed Jul 24 01:46:54 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 23 Jul 2013 16:46:54 -0700 Subject: [Development] Qt 5 QSessionManager In-Reply-To: References: <87A14056-6B67-4DD3-86D5-8B3B3D772AE6@edeltech.ch> <18594630.5EGAlibTmW@asterix> Message-ID: <1611441.0qF9JF21Cm@tjmaciei-mobl2> On terça-feira, 23 de julho de 2013 23.55.24, Samuel Gaist wrote: > On 23 juil. 2013, at 09:59, David Faure wrote: > > On Monday 22 July 2013 23:51:23 Samuel Gaist wrote: > >> Should I open a bug report/feature request before for it or can I just > >> start the implementation ? > > > > This is part of QTBUG-28228. > > Thank you > > What copyright should I put on the new files ? The Digia notice like in > QSessionManager ? No, put yours. If you develop it, you keep the copyright. If you copy considerable code from existing files in Qt, then copy the copyright too (in addition to adding yours). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From chgans at gna.org Wed Jul 24 02:54:16 2013 From: chgans at gna.org (Christian Gagneraud) Date: Wed, 24 Jul 2013 12:54:16 +1200 Subject: [Development] Nominating Kevin Ottens as Approver In-Reply-To: <10047846.3fY7jupRTn@varney> References: <10047846.3fY7jupRTn@varney> Message-ID: <51EF25B8.8000004@gna.org> On 24/07/13 01:11, Frederik Gladhorn wrote: > Hi, > > I would like to nominate Kevin Ottens as approver for the Qt Project. > > Kevin has been working on KDE for a long time and has lately worked hard to > get more patches into Qt especially as part of KDE Frameworks 5. > > You can find him on IRC as "ervin" and he works at KDAB. > > His dashboard: > https://codereview.qt-project.org/#dashboard,1001931 > https://codereview.qt-project.org/#q,owner:Kevin%252BOttens,n,z > > His list of reviews: > https://codereview.qt-project.org/#q,reviewer:Kevin%252BOttens,n,z +1 Go Kevin! > > From sergio.ahumada at digia.com Wed Jul 24 10:33:48 2013 From: sergio.ahumada at digia.com (Sergio Ahumada) Date: Wed, 24 Jul 2013 10:33:48 +0200 Subject: [Development] Bumping Qt 5 version in 'stable' branch to 5.1.2 Message-ID: <51EF916C.2060400@digia.com> Hi, The first change is https://codereview.qt-project.org/61431 and it's already merged. This also means that the 'stable' branch is open again for staging. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt From Shawn.Rutledge at digia.com Wed Jul 24 10:36:19 2013 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Wed, 24 Jul 2013 08:36:19 +0000 Subject: [Development] QtQuick External Drag Drop Partial Patch -- Help Requested In-Reply-To: References: Message-ID: <25BC70CE-7B95-465E-8202-1CC8E4F9A7AC@digia.com> On 23 Jul 2013, at 9:16 PM, Chris Meyer wrote: > I've been working on adding support for external drag and drop to QtQuick. I've created a patch which addresses the basic needs and have used the resulting capabilities in my non-trivial application to implement drag and drop between a QtQuick view and a widget. > > I'll need help on one particular feature: generating an image of the QtQuick item being dragged. Right now it doesn't use any image -- so dragging works, but the image is just a small gray rectangle. > > In addition, I need feedback on a design choice. I decided to not create a QtQuick MimeData item; but instead add accessor methods directly to DropEvent. This seems reasonable, but a future MimeData object could be re-used if we implement a similar Cut / Copy / Paste functionality. Any thoughts? > > Finally, I'll need some procedural help to make sure the patch is suitable to be added for Qt 5.2 -- specifically to make sure I get examples, tests, and documentation correct. > > Is there someone who has commit access who can help me through this patch? > > Here is the bug report: > https://bugreports.qt-project.org/browse/QTBUG-27498 > > Here is the current code in my patch: > https://codereview.qt-project.org/61017 > > It's not complete, but I'm willing to finish it off (with the help from above). I think this would make a useful addition to Qt 5.2. Yes I will try to help you because it was on my wish list to try to get DnD done for 5.2 if I could find the time, so now you are saving me some work. ;-) For me it's a bit confusing to have both the Drag attached property and the DragEvent; AFAICT they are similar except that Drag is for the source and DragEvent is for the destination, right? Maybe it could have been the same type of object on both ends. But since that API is there, we have to keep supporting it anyway, so probably it's good that this patch is going the direction of being similar whether the dragging is being done within the same application or from an external one. Maybe it would be nice if when receiving a drop, the data being transferred could be handled the same as an ordinary JS object. Otherwise the reason for all the properties you're adding to QQuickDropEvent is partially to access data from certain keys (text, color, html) and partially to access data of certain types (URLs), right? It adds convenience for the common use cases. But DnD implementations are usually supposed to be generic, able to carry data of not-yet-invented types. And QVariantMap could handle just about anything. Then when you receive the drop you could iterate the keys, or look for specific keys, and also ask what is the type of each value, depending on how you want to write your application. http://qt-project.org/doc/qt-5.1/qtqml/qtqml-cppintegration-data.html#qvariantlist-and-qvariantmap-to-javascript-array-and-object I'm not sure about this startExternal function either, because it's procedural rather than declarative. If you would normally call it whenever your mouse cursor is about to leave the window, maybe we could do that automatically. Or did you expect to call it in some other context? Did you write a suitable example yet? Otherwise maybe I need to write a quickie file manager/viewer or something like that. I don't know about the drag image yet, but I imagine we can find a way. Anyway we can continue the discussion on codereview too. From david.faure at kdab.com Wed Jul 24 12:14:36 2013 From: david.faure at kdab.com (David Faure) Date: Wed, 24 Jul 2013 12:14:36 +0200 Subject: [Development] Qt 5 QSessionManager In-Reply-To: References: <87A14056-6B67-4DD3-86D5-8B3B3D772AE6@edeltech.ch> <18594630.5EGAlibTmW@asterix> Message-ID: <16783566.J3vvDIkjU7@asterix> On Tuesday 23 July 2013 23:55:24 Samuel Gaist wrote: > On 23 juil. 2013, at 09:59, David Faure wrote: > > On Monday 22 July 2013 23:51:23 Samuel Gaist wrote: > >> Should I open a bug report/feature request before for it or can I just > >> start the implementation ? > > > > This is part of QTBUG-28228. > > Thank you > > What copyright should I put on the new files ? The Digia notice like in > QSessionManager ? It depends. If the code is yours, then your own copyright. If the code is moved from elsewhere, then keep the Digia copyright. If it's both, then put both. -- David Faure | david.faure at kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From shane.kearns at accenture.com Wed Jul 24 12:41:34 2013 From: shane.kearns at accenture.com (shane.kearns at accenture.com) Date: Wed, 24 Jul 2013 10:41:34 +0000 Subject: [Development] GDB python pretty printers for common Qt classes In-Reply-To: <1374600212.11464.YahooMailNeo@web126205.mail.ne1.yahoo.com> References: <20825071.fu8Ir1fRJk@minime> <1612141.bsmXxlIqZu@asterix> <7163F5DC5711224C8D28FF8936EA845A41FF9B@048-CH1MPN1-054.048d.mgd.msft.net> <1374600212.11464.YahooMailNeo@web126205.mail.ne1.yahoo.com> Message-ID: <7163F5DC5711224C8D28FF8936EA845A4292D0@048-CH1MPN1-053.048d.mgd.msft.net> > I'd suggest QByteArray be in there too; may be even QVariant. > Both good ideas. QByteArray may contain: - text, encoded in any format - binary data - binary data that contains text This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. ______________________________________________________________________________________ www.accenture.com From cmeyer1969+qt at gmail.com Wed Jul 24 17:25:43 2013 From: cmeyer1969+qt at gmail.com (Chris Meyer) Date: Wed, 24 Jul 2013 08:25:43 -0700 Subject: [Development] QtQuick External Drag Drop Partial Patch -- Help Requested In-Reply-To: <25BC70CE-7B95-465E-8202-1CC8E4F9A7AC@digia.com> References: <25BC70CE-7B95-465E-8202-1CC8E4F9A7AC@digia.com> Message-ID: On Wed, Jul 24, 2013 at 1:36 AM, Rutledge Shawn wrote: > > On 23 Jul 2013, at 9:16 PM, Chris Meyer wrote: > > > I've been working on adding support for external drag and drop to > QtQuick. I've created a patch which addresses the basic needs and have used > the resulting capabilities in my non-trivial application to implement drag > and drop between a QtQuick view and a widget. > > > > I'll need help on one particular feature: generating an image of the > QtQuick item being dragged. Right now it doesn't use any image -- so > dragging works, but the image is just a small gray rectangle. > > > > In addition, I need feedback on a design choice. I decided to not create > a QtQuick MimeData item; but instead add accessor methods directly to > DropEvent. This seems reasonable, but a future MimeData object could be > re-used if we implement a similar Cut / Copy / Paste functionality. Any > thoughts? > > > > Finally, I'll need some procedural help to make sure the patch is > suitable to be added for Qt 5.2 -- specifically to make sure I get > examples, tests, and documentation correct. > > > > Is there someone who has commit access who can help me through this > patch? > > > > Here is the bug report: > > https://bugreports.qt-project.org/browse/QTBUG-27498 > > > > Here is the current code in my patch: > > https://codereview.qt-project.org/61017 > > > > It's not complete, but I'm willing to finish it off (with the help from > above). I think this would make a useful addition to Qt 5.2. > > Yes I will try to help you because it was on my wish list to try to get > DnD done for 5.2 if I could find the time, so now you are saving me some > work. ;-) > > For me it's a bit confusing to have both the Drag attached property and > the DragEvent; AFAICT they are similar except that Drag is for the source > and DragEvent is for the destination, right? Maybe it could have been the > same type of object on both ends. But since that API is there, we have to > keep supporting it anyway, so probably it's good that this patch is going > the direction of being similar whether the dragging is being done within > the same application or from an external one. > > Maybe it would be nice if when receiving a drop, the data being > transferred could be handled the same as an ordinary JS object. Otherwise > the reason for all the properties you're adding to QQuickDropEvent is > partially to access data from certain keys (text, color, html) and > partially to access data of certain types (URLs), right? It adds > convenience for the common use cases. But DnD implementations are usually > supposed to be generic, able to carry data of not-yet-invented types. And > QVariantMap could handle just about anything. Then when you receive the > drop you could iterate the keys, or look for specific keys, and also ask > what is the type of each value, depending on how you want to write your > application. > > > http://qt-project.org/doc/qt-5.1/qtqml/qtqml-cppintegration-data.html#qvariantlist-and-qvariantmap-to-javascript-array-and-object > > I'm not sure about this startExternal function either, because it's > procedural rather than declarative. If you would normally call it whenever > your mouse cursor is about to leave the window, maybe we could do that > automatically. Or did you expect to call it in some other context? > > Did you write a suitable example yet? Otherwise maybe I need to write a > quickie file manager/viewer or something like that. > > I don't know about the drag image yet, but I imagine we can find a way. > > Anyway we can continue the discussion on codereview too. > > Thanks for getting back to me. Regarding the confusion between Drag and DragEvent: I didn't want to change the architecture too much. It is also confusing that QtQuick DragEvent is a combination of QDragEvent and QDropEvent. Regarding a JS object representing the MimeData directly: To construct that object, we must extract all the data from QMimeData, which can be large. Providing accessor methods allows the user to only extract what they need. Also, I'm not sure how we will handle binary data in JS. Regarding the startExternal(...) function: I was thinking of providing an 'dragType' property which could automatically trigger an external drag. We would need an associated 'dragAction' property too. Do we need to differentiate between internal and external drags? Then the internal/simpler/smoother version can be used until the user drags too far out of the way, after which external drag can be used. Maybe we only need the external drag technique, but that might affect backwards compatibility. It looks like the original DnD implementation (internal only) was done for a very specific use case. I have sample code I can provide. I'll get it ready. Ultimately something like a file manager would be a great example. I'll post these comments on the codereview too. -------------- next part -------------- An HTML attachment was scrubbed... URL: From 416365416c at gmail.com Wed Jul 24 17:31:23 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 24 Jul 2013 08:31:23 -0700 Subject: [Development] API review for FolderListModel In-Reply-To: <75ECBEBD-7629-4E93-A446-1656A162B0B4@digia.com> References: <75ECBEBD-7629-4E93-A446-1656A162B0B4@digia.com> Message-ID: On Mon, Jul 22, 2013 at 10:41 PM, Rutledge Shawn wrote: > > On 26 Jun 2013, at 7:41 PM, Alan Alpert wrote: > >> On Wed, Jun 26, 2013 at 6:27 AM, Rutledge Shawn >> wrote: >>> I just wrote up this task >>> >>> https://bugreports.qt-project.org/browse/QTBUG-32039 >>> >>> because while implementing the QML FileDialog I ran into some issues; those are the ones I can remember, at least. If anyone has noticed any further annoyances in the FolderListModel API, please feel free to add to that list. >> >> The API review should happen on the ML, not in a JIRA task. Or are you >> wanting to collect issues and opinions for a review "later"? Because >> otherwise we could just start it right here, right now... >> >> PS: Should this be on the proposed new QtQuick mailing list? I kind of >> like the idea of having the API reviews on a shared user/developer ML >> to get some direct user input. > > So what is the process for actually starting the API review on the list then? I suggest we should start it so that FolderListModel can possibly become a supported API in 5.2. The process is to start an API review on the list. I recommend you list the existing public API, the intended usecase(s) of the type, and any known issues or unresolved questions. -- Alan Alpert From 416365416c at gmail.com Wed Jul 24 17:36:39 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 24 Jul 2013 08:36:39 -0700 Subject: [Development] QtQuick External Drag Drop Partial Patch -- Help Requested In-Reply-To: References: <25BC70CE-7B95-465E-8202-1CC8E4F9A7AC@digia.com> Message-ID: On Wed, Jul 24, 2013 at 8:25 AM, Chris Meyer wrote: > On Wed, Jul 24, 2013 at 1:36 AM, Rutledge Shawn > wrote: >> >> >> On 23 Jul 2013, at 9:16 PM, Chris Meyer wrote: >> >> > I've been working on adding support for external drag and drop to >> > QtQuick. I've created a patch which addresses the basic needs and have used >> > the resulting capabilities in my non-trivial application to implement drag >> > and drop between a QtQuick view and a widget. >> > >> > I'll need help on one particular feature: generating an image of the >> > QtQuick item being dragged. Right now it doesn't use any image -- so >> > dragging works, but the image is just a small gray rectangle. >> > >> > In addition, I need feedback on a design choice. I decided to not create >> > a QtQuick MimeData item; but instead add accessor methods directly to >> > DropEvent. This seems reasonable, but a future MimeData object could be >> > re-used if we implement a similar Cut / Copy / Paste functionality. Any >> > thoughts? >> > >> > Finally, I'll need some procedural help to make sure the patch is >> > suitable to be added for Qt 5.2 -- specifically to make sure I get examples, >> > tests, and documentation correct. >> > >> > Is there someone who has commit access who can help me through this >> > patch? >> > >> > Here is the bug report: >> > https://bugreports.qt-project.org/browse/QTBUG-27498 >> > >> > Here is the current code in my patch: >> > https://codereview.qt-project.org/61017 >> > >> > It's not complete, but I'm willing to finish it off (with the help from >> > above). I think this would make a useful addition to Qt 5.2. >> >> Yes I will try to help you because it was on my wish list to try to get >> DnD done for 5.2 if I could find the time, so now you are saving me some >> work. ;-) >> >> For me it's a bit confusing to have both the Drag attached property and >> the DragEvent; AFAICT they are similar except that Drag is for the source >> and DragEvent is for the destination, right? Maybe it could have been the >> same type of object on both ends. But since that API is there, we have to >> keep supporting it anyway, so probably it's good that this patch is going >> the direction of being similar whether the dragging is being done within the >> same application or from an external one. >> >> Maybe it would be nice if when receiving a drop, the data being >> transferred could be handled the same as an ordinary JS object. Otherwise >> the reason for all the properties you're adding to QQuickDropEvent is >> partially to access data from certain keys (text, color, html) and partially >> to access data of certain types (URLs), right? It adds convenience for the >> common use cases. But DnD implementations are usually supposed to be >> generic, able to carry data of not-yet-invented types. And QVariantMap >> could handle just about anything. Then when you receive the drop you could >> iterate the keys, or look for specific keys, and also ask what is the type >> of each value, depending on how you want to write your application. >> >> >> http://qt-project.org/doc/qt-5.1/qtqml/qtqml-cppintegration-data.html#qvariantlist-and-qvariantmap-to-javascript-array-and-object >> >> I'm not sure about this startExternal function either, because it's >> procedural rather than declarative. If you would normally call it whenever >> your mouse cursor is about to leave the window, maybe we could do that >> automatically. Or did you expect to call it in some other context? >> >> Did you write a suitable example yet? Otherwise maybe I need to write a >> quickie file manager/viewer or something like that. >> >> I don't know about the drag image yet, but I imagine we can find a way. >> >> Anyway we can continue the discussion on codereview too. >> > > Thanks for getting back to me. > > Regarding the confusion between Drag and DragEvent: I didn't want to change > the architecture too much. It is also confusing that QtQuick DragEvent is a > combination of QDragEvent and QDropEvent. > > Regarding a JS object representing the MimeData directly: To construct that > object, we must extract all the data from QMimeData, which can be large. > Providing accessor methods allows the user to only extract what they need. > Also, I'm not sure how we will handle binary data in JS. I think a good compromise would be to provide accessor methods or a simple JS object for the common stuff, and one of those access methods is the QMimeData pointer. You can't handle binary data in JS, but if we expose a QMimeData* then you can pass that into/from the C++ side of your application to handle the advanced cases. > Regarding the startExternal(...) function: I was thinking of providing an > 'dragType' property which could automatically trigger an external drag. We > would need an associated 'dragAction' property too. > > Do we need to differentiate between internal and external drags? Then the > internal/simpler/smoother version can be used until the user drags too far > out of the way, after which external drag can be used. Maybe we only need > the external drag technique, but that might affect backwards compatibility. > It looks like the original DnD implementation (internal only) was done for a > very specific use case. Correct. It would be better not to have the internal/external drag distinction in the end (so long as internal drags are still simple). Although we do need backwards compatibility, you can mark methods as deprecated if a new implementation gives it a better replacement. An important part of removing that distinction would be automatically starting 'external' drags, i.e. getting rid of the startExternal function call in the common case. -- Alan Alpert From 416365416c at gmail.com Wed Jul 24 17:41:15 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 24 Jul 2013 08:41:15 -0700 Subject: [Development] QtQuick ML Message-ID: Since I can't seem to get them to speak up, I guess they don't care that much after all. I'll withdraw the suggestion again. See you in six months :P -- Alan Alpert On Fri, Jul 19, 2013 at 1:41 AM, Lorn Potter wrote: > > On 19/07/2013, at 4:08 AM, Thiago Macieira wrote: > >> On quinta-feira, 18 de julho de 2013 08.07.02, Alan Alpert wrote: >>> There were some specific KDE people then whom I had been talking to at >>> DevDays who did not participate through the development ML on those >>> topics, despite being interested in previous conversations. After >>> having more excellent discussions with many of the same KDE people at >>> Akademy this week, I would like to make QtQuick development more >>> accessible to them. >> >> I did hear from a couple of people that the traffic in the Dev mailing list is >> quite high already. That would be a reason to split. >> >> Do people agree it's high? Right now, we have a 350 emails / month average for >> the past 3 months (11-12 emails a day). >> >> For comparison, in the same period, kde-core-devel averaged 460 emails / month >> (15-16 per day), my Gerrit inbox is at 1200 emails/month (40 a day) and my >> Intel professional inbox has 646 in the last 30 days only. > > > In my experience, I don't think it's that busy of a mailing list. > Although I can see the good reasons for both arguments, I don't think it's volume warrants a split off of qml/quick/components. > > >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > Lorn Potter > QtSensors/QtSensorGestures/QtSystemInfo > llornkcor technologies / Jolla Mobile > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From 416365416c at gmail.com Wed Jul 24 17:43:54 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 24 Jul 2013 08:43:54 -0700 Subject: [Development] [QtQuick] Adaptable UI Sessions from Qt CS Message-ID: General agreement was had on the three main parts of an adaptable UI 1. assets:// . A new assets directory will be added to QStandardPaths and assets:// will point to that, except on Android. On Android assets will be Android assets. QRC is still recommended for cross-platform deployment, but when you want them deployed as separate files assets:// will be a cross-platform way to achieve that. Like qrc:///, there will be special handling by QFile. 2. File Selectors. Primarily for use in QML, they are a standard mechanism for how to subsitute different files under different circumstances. The selectors available by default will be platform, and form factor or input selectors if we can reliably figure them out in time. Those selectors may not make the initial release. Generic ways of setting selectors will, so that individual platforms can set their own selectors (they tend to have much greater knowledge about both how the device is used and what selectors are appropriate). This way you can have +blackberry/settings.js +android/settings.js instead of necessarily juggling qrc files. During the QtCS discussions it was determined that dynamically swapping at runtime will not be initially supported. Selectors are only applied when QML files are loaded. File selectors are not a built-in feature of the language. They will be enabled by default on QQmlApplicationEngine through the new QQmlAbstractUrlInterceptor functionality. Singleton types are being added as a built-in feature of the language, they will allow a better means of specifying selected contents compared to "settings.js". I aim to be implementing all of this by 5.2, as much of the work was already done for 5.1 already. See https://codereview.qt-project.org/#change,48334 , which has the discussed functionality plus an attempt at adding form factor selectors. Those will probably be dropped soon unless anyone has a better idea on how to implement it. 3. Bindings. Screen attached object has resolution, for example, and for repsonding to runtime changes across continuous variables, like window size, screen size and resolution, you should bind to appropriate values. This is similar to the Ubuntu grid unit concept, and works well in conjunction with layouts. Also touched on was that some platform settings, like doubleClickInterval and pressAndHoldDelay, should be added to the Qt.application object. Ideally this would involve moving them down to QGuiApplication from QApplication. -- Alan Alpert From 416365416c at gmail.com Wed Jul 24 17:45:17 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 24 Jul 2013 08:45:17 -0700 Subject: [Development] [QtQuick] Mouse/Touch handling from Qt CS Message-ID: Qt CS had a discussion on how to handle mouse and touch event conflicts in QtQuick going forwards. An interesting idea came up that the existing model might be salvageable if we fix multi-cursor support. Some investigation will occur to see whether having multiple mouse grabs automatically solves the multitouch problems the current model has with converting touch events to mouse events. Also necessary is some sort of grab stack so that when a multi-finger gesture moves the mouse events to a different item, the grab for single fingers can return to where it was should the other fingers lift. If this approach works, then we'll have multi-touch and multi-cursor support without having to redesign the pointer interaction model in QtQuick. Otherwise we'll just have to implement separate touch and mouse handlers in all QtQuick items until we come up with a better idea. -- Alan Alpert From 416365416c at gmail.com Wed Jul 24 17:45:50 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 24 Jul 2013 08:45:50 -0700 Subject: [Development] [QtQuick] Views Version 2 from Qt CS Message-ID: There's a rough outline of how we want views to look in QtQuick, because the current ListView is unmaintainable and not extensible. See http://qt-project.org/groups/qt-contributors-summit-2013/wiki/Qt-Quick-views-version-2 for details. Unfortunately, while everyone needs it, no-one has time. If anyone wants the most interesting research project in the whole Qt project... it's up for grabs! -- Alan Alpert From 416365416c at gmail.com Wed Jul 24 17:46:21 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 24 Jul 2013 08:46:21 -0700 Subject: [Development] QML Language Development from Qt CS Message-ID: Going forwards the QML language is not fixed, and once the mighty V4 switch takes place it should be easier than ever to improve! The decision was that the QML language version is linked to the Qt Version (C++ lib QtQml version), and follows the same compatibility rules. So we can't break plugin compatibity again until Qt 6. QML applications will need to depend on a minimum version of Qt (or qml runtime), same as C++ applications. Short term plans including adding the 'pragma' keyword, and a 'pragma singleton' directive. The pragma keyword will be valid only in the preamble, and the singleton directive will mark that file as a composite singleton type. It will behave the same way as a C++ QJSValue/QObject singleton type does currently. I'll try to find someone in Blackberry to help me implement this. Longer term plans involve adding enums, const properties and group properties, rough syntax described but not finalized http://qt-project.org/groups/qt-contributors-summit-2013/wiki/Evolution-of-the-QML-language . There is no ETA on those changes, so if you're really keen on seeing them I'm happy to review patches. Also covered was that QtQml is the 90% replacement for QtScript. QtQml with QJSValue and QJSEngine, not just QQmlEngine, is what will be provided for application scripting (even non-GUI scripting) going forwards. So keep in mind that its mandate covers more than just QtQuick and GUI declarations. -- Alan Alpert From 416365416c at gmail.com Wed Jul 24 17:47:15 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 24 Jul 2013 08:47:15 -0700 Subject: [Development] QQmlAbstractUrlInterceptor (Import control from Qt CS) Message-ID: Discussed at Qt CS as the mechanism for both file selectors and providing import control was a new QQmlAbstractUrlInterceptor class. You can provide a subclass of this to the QML engine to intercept all local file and QRC access, when combined with a custom QNetworkAccessManager the application has full control over all file and network access attempted by the engine. It slipped into 5.1 as private API for advanced prototyping purposes, you can already find it in the qtdeclarative repository. The plan is to make it public API in 5.2 to fulfill the aforementioned needs. Please have a look and provide any feedback, including other possible usecases, before the 5.2 merge. -- Alan Alpert From frederik.gladhorn at digia.com Wed Jul 24 18:15:47 2013 From: frederik.gladhorn at digia.com (Frederik Gladhorn) Date: Wed, 24 Jul 2013 18:15:47 +0200 Subject: [Development] [QtQuick] Mouse/Touch handling from Qt CS In-Reply-To: References: Message-ID: <105765394.26blyJSifY@varney> Hi, thanks for bringing this up on the mailing list Alan :) Onsdag 24. juli 2013 08.45.17 skrev Alan Alpert: > Qt CS had a discussion on how to handle mouse and touch event > conflicts in QtQuick going forwards. > > An interesting idea came up that the existing model might be > salvageable if we fix multi-cursor support. Some investigation will > occur to see whether having multiple mouse grabs automatically solves > the multitouch problems the current model has with converting touch > events to mouse events. Also necessary is some sort of grab stack so > that when a multi-finger gesture moves the mouse events to a different > item, the grab for single fingers can return to where it was should > the other fingers lift. > > If this approach works, then we'll have multi-touch and multi-cursor > support without having to redesign the pointer interaction model in > QtQuick. Otherwise we'll just have to implement separate touch and > mouse handlers in all QtQuick items until we come up with a better > idea. My notes are on the wiki for the session: http://qt-project.org/groups/qt-contributors-summit-2013/wiki/QtQuick_TouchMouse I hope that we get most of the issues fixed for 5.2 actually. Let's see how far we get. > -- > Alan Alpert > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com From oneorjuan at gmail.com Wed Jul 24 20:32:26 2013 From: oneorjuan at gmail.com (Juan Navarro) Date: Wed, 24 Jul 2013 20:32:26 +0200 Subject: [Development] Implementation of qFuzzyCompare and zero values Message-ID: Hello all, I’m using qFuzzyCompare(a, b) in order to handle all floating point comparisons, but it has severe limitations when a or b may be zero. Somewhere in the docs it is recommended to add +1 to the values, but this is not a really useful suggestion because some of the values might be -1.0, resulting in 0.0 after the addition. So in each file which needs to perform floating point comparisons, I always end up using this or something similar to this macro: #include // qMax, qMin, qFuzzyCompare #define qFuzzyCompare(a, b) (qFuzzyIsNull(a) && qFuzzyIsNull(b)) || qFuzzyCompare((a), (b)) But instead of ad-hoc workarounds, IMHO this caveat should be fixed straight in the implementation of the qFuzzyCompare() function. A really old bug report already exists: QTBUG-16819 [bugreports.qt-project.org] it is open but it seems that discussion ended on 2011 for some reason. Could anyone add a bit more on this subject? -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Jul 25 01:19:50 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 Jul 2013 16:19:50 -0700 Subject: [Development] Implementation of qFuzzyCompare and zero values In-Reply-To: References: Message-ID: <1500948.kBgSGPP8J3@tjmaciei-mobl2> On quarta-feira, 24 de julho de 2013 20:32:26, Juan Navarro wrote: > Hello all, > > I’m using qFuzzyCompare(a, b) in order to handle all floating point > comparisons, but it has severe limitations when a or b may be zero. > > Somewhere in the docs it is recommended to add +1 to the values, but this > is not a really useful suggestion because some of the values might be -1.0, > resulting in 0.0 after the addition. You have to somehow tell qFuzzyCompare about the magnitude of your comparison. An error of 1000000 is acceptable when your numbers are in the order of 1e12. > But instead of ad-hoc workarounds, IMHO this caveat should be fixed > straight in the implementation of the qFuzzyCompare() function. A really > old bug report already exists: QTBUG-16819 [bugreports.qt-project.org] it > is open but it seems that discussion ended on 2011 for some reason. Can't do and won't do that. qFuzzyCompare is meant for non-zero numbers. We don't want to add the overhead of zero comparisons when the numbers in question can't be null. I've now just closed the bug report as "out of scope" (not a bug). > Could anyone add a bit more on this subject? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From achartier at fastmail.fm Thu Jul 25 02:12:50 2013 From: achartier at fastmail.fm (achartier at fastmail.fm) Date: Wed, 24 Jul 2013 17:12:50 -0700 Subject: [Development] Qt online installer "source code": where is it? In-Reply-To: References: Message-ID: <1374711170.23359.9223372036856767609.6C3998CF@webmail.messagingengine.com> Hi, I am not sure if this is the right mailing list to ask but I thought I'd ask anyway. >From my understanding, the Qt online installer is implemented using the Qt Installer Framework. I am currently working on making an installer for one of my projects using the Qt Installer Framework and am interested in looking at the "source code" of the Qt online installer to understand how Digia has configured Qt's online installer. I realize there is the Qt Online Installer source code on Gitorious at http://qt.gitorious.org/installer-framework, however this is the source code for the Qt Installer Framework itself; I am instead interested in the configuration for Qt's online installer so I can learn from a real working example. I have searched online for this but cannot find it. Is the configuration for Qt's online installer available publicly somewhere? If not, it would be great if it was, as it would serve as a great example of how to make use of the Qt Installer Framework. Any help is much appreciated. Thanks! From thiago.macieira at intel.com Thu Jul 25 05:37:14 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 Jul 2013 20:37:14 -0700 Subject: [Development] Qt online installer "source code": where is it? In-Reply-To: <1374711170.23359.9223372036856767609.6C3998CF@webmail.messagingengine.com> References: <1374711170.23359.9223372036856767609.6C3998CF@webmail.messagingengine.com> Message-ID: <3438991.hAqi643eNS@tjmaciei-mobl2> On quarta-feira, 24 de julho de 2013 17:12:50, achartier at fastmail.fm wrote: > Hi, > > I am not sure if this is the right mailing list to ask but I thought I'd > ask anyway. > > >From my understanding, the Qt online installer is implemented using the > > Qt Installer Framework. I am currently working on making an installer > for one of my projects using the Qt Installer Framework and am > interested in looking at the "source code" of the Qt online installer to > understand how Digia has configured Qt's online installer. I realize > there is the Qt Online Installer source code on Gitorious at > http://qt.gitorious.org/installer-framework, however this is the source > code for the Qt Installer Framework itself; I am instead interested in > the configuration for Qt's online installer so I can learn from a real > working example. > > I have searched online for this but cannot find it. Is the configuration > for Qt's online installer available publicly somewhere? If not, it would > be great if it was, as it would serve as a great example of how to make > use of the Qt Installer Framework. > > Any help is much appreciated. I believe you'll find it in the qtsdk.git repository, in the repotools/configurations subdir. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From andre at familiesomers.nl Thu Jul 25 07:34:19 2013 From: andre at familiesomers.nl (=?windows-1252?Q?Andr=E9_Somers?=) Date: Thu, 25 Jul 2013 07:34:19 +0200 Subject: [Development] Implementation of qFuzzyCompare and zero values In-Reply-To: <1500948.kBgSGPP8J3@tjmaciei-mobl2> References: <1500948.kBgSGPP8J3@tjmaciei-mobl2> Message-ID: <51F0B8DB.7040507@familiesomers.nl> Op 25-7-2013 1:19, Thiago Macieira schreef: > On quarta-feira, 24 de julho de 2013 20:32:26, Juan Navarro wrote: >> Hello all, >> >> I’m using qFuzzyCompare(a, b) in order to handle all floating point >> comparisons, but it has severe limitations when a or b may be zero. >> >> Somewhere in the docs it is recommended to add +1 to the values, but this >> is not a really useful suggestion because some of the values might be -1.0, >> resulting in 0.0 after the addition. > You have to somehow tell qFuzzyCompare about the magnitude of your comparison. > An error of 1000000 is acceptable when your numbers are in the order of 1e12. > >> But instead of ad-hoc workarounds, IMHO this caveat should be fixed >> straight in the implementation of the qFuzzyCompare() function. A really >> old bug report already exists: QTBUG-16819 [bugreports.qt-project.org] it >> is open but it seems that discussion ended on 2011 for some reason. > Can't do and won't do that. qFuzzyCompare is meant for non-zero numbers. We > don't want to add the overhead of zero comparisons when the numbers in > question can't be null. > > I've now just closed the bug report as "out of scope" (not a bug). Would it be an option to _add_ a qFuzzyCompareMightBeNull or something like that then for cases like Juan describes where you don't know if one of the two values might be zero or not? There is no reason to change the behaviour of the current function (as said in the bug report: it may break or slow down other peoples code doing that), but that does not hold adding a new function *defined* to do this, right? André -- You like Qt? I am looking for collegues to join me at i-Optics! From thiago.macieira at intel.com Thu Jul 25 09:01:53 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 Jul 2013 00:01:53 -0700 Subject: [Development] Implementation of qFuzzyCompare and zero values In-Reply-To: <51F0B8DB.7040507@familiesomers.nl> References: <1500948.kBgSGPP8J3@tjmaciei-mobl2> <51F0B8DB.7040507@familiesomers.nl> Message-ID: <1606308.vCyzZRCPom@tjmaciei-mobl2> On quinta-feira, 25 de julho de 2013 07:34:19, André Somers wrote: > Would it be an option to _add_ a qFuzzyCompareMightBeNull or something > like that then for cases like Juan describes where you don't know if one > of the two values might be zero or not? There is no reason to change the > behaviour of the current function (as said in the bug report: it may > break or slow down other peoples code doing that), but that does not > hold adding a new function *defined* to do this, right? So, we should add qFuzzyIsNullOrCompare for people who won't do qFuzzyIsNull || qFuzzyCompare? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From andre at familiesomers.nl Thu Jul 25 09:17:36 2013 From: andre at familiesomers.nl (=?ISO-8859-1?Q?Andr=E9_Somers?=) Date: Thu, 25 Jul 2013 09:17:36 +0200 Subject: [Development] Implementation of qFuzzyCompare and zero values In-Reply-To: <1606308.vCyzZRCPom@tjmaciei-mobl2> References: <1500948.kBgSGPP8J3@tjmaciei-mobl2> <51F0B8DB.7040507@familiesomers.nl> <1606308.vCyzZRCPom@tjmaciei-mobl2> Message-ID: <51F0D110.90702@familiesomers.nl> Op 25-7-2013 9:01, Thiago Macieira schreef: > On quinta-feira, 25 de julho de 2013 07:34:19, André Somers wrote: >> Would it be an option to _add_ a qFuzzyCompareMightBeNull or something >> like that then for cases like Juan describes where you don't know if one >> of the two values might be zero or not? There is no reason to change the >> behaviour of the current function (as said in the bug report: it may >> break or slow down other peoples code doing that), but that does not >> hold adding a new function *defined* to do this, right? > So, we should add qFuzzyIsNullOrCompare for people who won't do qFuzzyIsNull > || qFuzzyCompare? No, for those who think it is a hassle to write [1] static inline bool qFuzzyComparePossibleNulls(double p1, double p2) { if (qFuzzyIsNull(p1)) { return qFuzzyIsNull(p2); } else if (qFuzzyIsNull(p2)) { return false; } else { return qFuzzyCompare(p1, p2); } } or some inline equivalent of that everywhere they just want to compare two doubles they don't know the values of and that might thus be 0. Note that either of the two doubles may be 0, not just the first as you seem to imply. André [1] taken from http://paste.kde.org/4511/ referenced in the bugreport mentioned earlier -- You like Qt? I am looking for collegues to join me at i-Optics! From Shawn.Rutledge at digia.com Thu Jul 25 09:37:31 2013 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Thu, 25 Jul 2013 07:37:31 +0000 Subject: [Development] [QtQuick] Views Version 2 from Qt CS; animated layout In-Reply-To: References: Message-ID: On 24 Jul 2013, at 5:45 PM, Alan Alpert wrote: > There's a rough outline of how we want views to look in QtQuick, > because the current ListView is unmaintainable and not extensible. See > http://qt-project.org/groups/qt-contributors-summit-2013/wiki/Qt-Quick-views-version-2 > for details. It was already obvious for a long time that instantiation, layout and flicking behavior ought to have been separated from the beginning. (At least Flickable is inherited, so hopefully we don't have to do a lot extra to get the touch events working in the views.) Yesterday we were talking more about animating transitions between layouts. I think we might be able to get there by giving a layout manager a list of items to manage (not necessarily a public property), and adding a layout: property to Item. So if you declare Rectangle { Repeater { id: peter anchors.fill: parent layout: FlowLayout { anchors.fill: peter; spacing: … } model: … Rectangle { … } } } then the Repeater will give the FlowLayout the repeater's children as its list of items to manage. Later you could assign a different layout, and when the property changes it will give the items to the second layout to manage. The delegate Rectangle could have its own state transitions or Behavior on x and y or something like that to animate from its position as determined by the first layout to its position determined by the second. That part needs more thought. The layout must have correct geometry, but it doesn't have to get it from its parent. The layout would not be required to be in the item containment hierarchy. Yet the app author can still easily see which items have which layouts, because of the layout: declaration. The current way is that the items must be children of the layout, so you can't switch layouts without reparenting all of the items. That way could continue to work for the simple use case: if the layout has children then it will assign them to its own list of items-to-manage. The QQuickLayoutAttached will have to continue to be universal, having properties that apply to any kind of layout. But it would be useful to have a mechanism to change the properties depending on which layout is applied, so e.g. if you switch a device from portrait to landscape, the layout can change, and the items can also change their preferred width/height etc. Yesterday I began to write a file manager to test the DnD behavior, and was thinking about how one fundamental usability feature which has been present in the Mac finder from the beginning (and missing from many other file managers) is that in the icon view you can rearrange the icons however you want, and the OS will remember those positions. (Spatial memory might help you to organize sub-parts of a project or something like that.) They are not forced to sit on a grid all the time, and yet there is a handy "cleanup" command which will arrange them to a grid on-demand. (In OS X it's been extended to have Cleanup by Name etc, which basically sorts the items at the same time, and you can also toggle "Arrange by name" etc. to keep the sorted and grid-aligned all the time.) So generalizing this idea provides some further motivation to have switchable layout managers (including switching to no layout at all), and animated position movements. Since I cannot do that yet, in my file manager I cannot use layouts; I can set the position of each icon in component.onCompleted, and the user is free to drag the icons around afterwards. The Cleanup command would have to be implemented in Javascript. (Fortunately a flow layout is easy to implement.) The file manager, along with many other types of "infinite canvas" drawing and diagramming applications, need 2-dimensional panning functionality, so the Flickable seems a natural fit. And many of those could benefit from dynamically creating and destroying delegates too, to save memory when there are a lot of objects in the model, because the Flickable could manage a really large area. So the instantiation needs to support creating and destroying delegates in both dimensions (whereas ListView, GridView and PathView only create at one end and destroy at the other, depending on the single direction of movement). Under Controller you have viewport and reaction to input, but Flickable takes care of those. Do you think there's anything wrong with that? And then there is the selection model. So far it has been enough in such cases for each item to have its own MouseArea and to remember its own selection state, but it would be nice to have a means to implement a lasso tool, and a means of maintaining a list of selections, although it's possible to iterate all the children and find the ones that are selected, and it's also possible to maintain a separate list in JS. The Instantiator name is already taken, but was it designed to be used for views? Come to think of it, the trouble with Repeater has always been that it's in the containment hierarchy, but it's an interloper. It's similar to how the layout has a behavioral role, and therefore should not be required to be in the containment hierarchy. If you want to make a component which is something like a ListView, but you want to customize it by rebuilding it from scratch, then you might use a Repeater to instantiate the rows in the list. You will soon run into the trouble that each item's parent is the Repeater, not the list component which you were trying to create. This must be fixed. So hopefully the "new view" will make the Repeater obsolete, and we need to start upholding the design pattern that the parent of a delegate or inner component should always be the useful parent component (the one the user is trying to create), not the layout or the repeater. So most of these interchangeable components should be properties. You could do something like this: Viewport { id: vp View { id: view model: ... delegate: Rectangle { id: del MouseArea { anchors.fill: parent onClicked: view.selection.toggle(del) drag.target: del } } instantiator: ... layout: FlowLayout { anchors.fill: parent; spacing ? } controllers: [ MultipleSelectionArea { anchors.fill: view target: view.selection } FlickArea { anchors.fill: vp target: vp } ] } } • Every child of the view can see that its parent is the view itself: no interlopers (such as layout or repeater) • The view does NOT contain children other than the ones the user wants to see; so if you iterate the children you won't have to check the type of each • There can be multiple controllers, to handle as many behaviors as we like • A Flickable has two roles: it's a viewport, which is why it is normally the view's parent, and it also does the flicking. This can be split up further as shown, but I'm not sure we gain much from writing the extra declarations. The View could just have a Flickable as its parent. But splitting it up like this makes the design principle more consistent: the view hierarchy resembles the scene graph, while the behaviors are implemented by independent controllers which are NOT in the view hierarchy. The same logic could be extended to the MouseArea: if every Item had a controllers list (or if we had a habit of hiding controllers in the data property), we could say that a controller is never a visual child of an item. • MultipleSelectionArea would handle mouse and touch events which fall on any of the items in its target list, so dragging one drags them all. If you drag somewhere else on its parent, then it would lasso-select items from the target. • The MultipleSelectionArea could handle slow drags, and the FlickArea could handle quick drags. They could have minimum/maximumVelocity properties. Or the MultipleSelectionArea's lasso behavior could be configured to handle mouse events only, not touch events. I don't think the "controller" can be just one thing, because there can be a lot of separate behaviors, done with separate gestures: flicking/panning, lasso selection, drawing new items, dragging individual items, dragging multiple selections, etc. From lpapp at kde.org Thu Jul 25 09:47:21 2013 From: lpapp at kde.org (Laszlo Papp) Date: Thu, 25 Jul 2013 08:47:21 +0100 Subject: [Development] Implementation of qFuzzyCompare and zero values In-Reply-To: <51F0B8DB.7040507@familiesomers.nl> References: <1500948.kBgSGPP8J3@tjmaciei-mobl2> <51F0B8DB.7040507@familiesomers.nl> Message-ID: On Thu, Jul 25, 2013 at 6:34 AM, André Somers wrote: > Would it be an option to _add_ a qFuzzyCompareMightBeNull or something > like that then for cases like Juan describes where you don't know if one > of the two values might be zero or not? There is no reason to change the > behaviour of the current function (as said in the bug report: it may > break or slow down other peoples code doing that), but that does not > hold adding a new function *defined* to do this, right? That was also my thought after reading Thiago's email. It would not bloat the library after all as it is just a small function. I think the bugreport should be reopened accordingly, and then fixed unless there are good reasons against it. Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at digia.com Thu Jul 25 10:14:25 2013 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Thu, 25 Jul 2013 08:14:25 +0000 Subject: [Development] [QtQuick] Mouse/Touch handling from Qt CS In-Reply-To: References: Message-ID: <8D46B42E-44BA-4B91-A9F7-31E4733115F8@digia.com> On 24 Jul 2013, at 5:45 PM, Alan Alpert wrote: > Qt CS had a discussion on how to handle mouse and touch event > conflicts in QtQuick going forwards. > > An interesting idea came up that the existing model might be > salvageable if we fix multi-cursor support. I suggested that idea 2 years ago, but I was told authoritatively at that time that realistically, Qt will never support multiple cursors, because the idea of a single cursor, single grab, single focus, etc. is so pervasive in Qt. Another thing is that doing a pinch gesture with 2 mice, or 2 hands on a touch screen, is not the common use case, and multi-user applications will need to distinguish the users. The ideal touch hardware would be able to treat separate hands as separate users, so that the software could handle multiple separate gestures at the same time. Therefore it's an oversimplification to say that one mouse cursor is the same thing as one touch point, although we might get away with it in single-user applications. I also don't like the fact that events take such a circuitous path: the OS event is morphed into a QPA event and queued; then it's morphed into a classic Qt event and queued again; then it's morphed into a Qt Quick event and the hierarchy traversal finally begins, to find the right item in the scene. If it's a touch event, then for each item in the scene, it might have to get converted to an item-specific synthetic mouse event (that part is my doing though). It's amazing that we can get real-time dragging performance at all, with so much overhead. (And graphics view has a similar parallel event path of its own.) Given that every OS has an event queue already, I wonder why we even need multiple queues of our own; why don't we just ask QPA to fetch the next event from the OS queue, and convert it just once into a single cross-platform event type? I suppose mainly it's so that Qt can inject its own events into the stream, although a timeline of "our stuff" interleaved with "their stuff" could have been implemented without requiring a common event type. And why does QtQuick really need its own separate event types? Just because of binary compatibility guarantees, we can't change the old event types? Or because of the chance that if we did it wrong, all the widgets would need work? But we could have planned to change this in time for 5.0, to have one event type for every layer. Now that is past, but we could still plan to reunify the events for Qt 6. If not, it would still be nice if QtQuick could short-circuit some of the event delivery path. I've been wondering if it could interface directly to QPA. Probably it would have profound effects on our chances of properly nesting QtQuick and widgets in the same application. (Which is problematic anyhow, due to the fact that OpenGL rendering always requires its own window.) But it would also provide a chance to handle multiple cursors in QtQuick only, without making incompatible changes in all the other layers. Ironically it was pointed out again after Doug Englebart's recent passing that from the beginning, he assumed that a multi-user multi-tasking computer would of course require multiple mice, so that each user can interact with objects on the screen independently. 45 years later, we still haven't gotten around to treating that as the mainstream use case. It could be one of the last reasons left to use a desktop or large-screen computer. From mardy at users.sourceforge.net Thu Jul 25 11:25:13 2013 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Thu, 25 Jul 2013 12:25:13 +0300 Subject: [Development] QQmlAbstractUrlInterceptor (Import control from Qt CS) In-Reply-To: References: Message-ID: <51F0EEF9.8070300@users.sourceforge.net> On 07/24/2013 06:47 PM, Alan Alpert wrote: > Discussed at Qt CS as the mechanism for both file selectors and > providing import control was a new QQmlAbstractUrlInterceptor class. > You can provide a subclass of this to the QML engine to intercept all > local file and QRC access, when combined with a custom > QNetworkAccessManager the application has full control over all file > and network access attempted by the engine. Would it make sense to have it in QCoreApplication instead of just QQmlEngine? I guess it could be useful also to non QML apps. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! From Marco.Bubke at digia.com Thu Jul 25 11:36:33 2013 From: Marco.Bubke at digia.com (Bubke Marco) Date: Thu, 25 Jul 2013 09:36:33 +0000 Subject: [Development] FW: Proposal for RFC like feature process In-Reply-To: References: Message-ID: Hi There are now many new feature proposals popping up on the mailing list. Sometime there is a link to a wiki page, JIRA etc.. You can easily get lost. The result are more hard designable (we working on the qml designer) features and Qml has more than enough already. So I propose something like the PEPs of Python: http://www.python.org/dev/peps/pep-0001/ It is working very well for them. Lets call it Qt Enhancement Proposal(QEP). In short you publish a QEP on the wiki and add it to the QEP list so everybody can find it. There will be a discussion about it on the mailing list. The arguments will be compressed in the QEP and then there will be a decision. The QEP will stay so if somebody come up again he can be pointed to the QEP. This worked very well for Python and so far I know most other languages(and many projects) have simular process. Yes it sound like more work but I think in the end it is less. Regards, Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jan-Arve.Saether at digia.com Thu Jul 25 12:05:50 2013 From: Jan-Arve.Saether at digia.com (Saether Jan-Arve) Date: Thu, 25 Jul 2013 10:05:50 +0000 Subject: [Development] Implementation of qFuzzyCompare and zero values In-Reply-To: References: <1500948.kBgSGPP8J3@tjmaciei-mobl2> <51F0B8DB.7040507@familiesomers.nl> Message-ID: <66BFFE861C7DE34D9B0372D8EAAB18E2BC4B00@IT-EXMB01-HKI.it.local> Instead of qFuzzyCompareMightBeNull, why can't we have a function that returns the number of representable numbers between two floats? boost has a similar function, math::float_distance(a, b) Qt style API could then be something like: unsigned qFloatDistance(float a, float b); You can then compare two floats like this: if (qFloatDistance(a,b) < 4) { // precise enough } This could be implemented the same way as explained in the link Samuel gave. (http://www.cygnus-software.com/papers/comparingfloats/Comparing%20floating%20point%20numbers.htm#_Toc135149455) Jan Arve From: development-bounces+jan-arve.saether=digia.com at qt-project.org [mailto:development-bounces+jan-arve.saether=digia.com at qt-project.org] On Behalf Of Laszlo Papp Sent: 25. juli 2013 09:47 To: André Somers Cc: development at qt-project.org Subject: Re: [Development] Implementation of qFuzzyCompare and zero values On Thu, Jul 25, 2013 at 6:34 AM, André Somers > wrote: Would it be an option to _add_ a qFuzzyCompareMightBeNull or something like that then for cases like Juan describes where you don't know if one of the two values might be zero or not? There is no reason to change the behaviour of the current function (as said in the bug report: it may break or slow down other peoples code doing that), but that does not hold adding a new function *defined* to do this, right? That was also my thought after reading Thiago's email. It would not bloat the library after all as it is just a small function. I think the bugreport should be reopened accordingly, and then fixed unless there are good reasons against it. Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From bog_dan_ro at yahoo.com Thu Jul 25 16:37:57 2013 From: bog_dan_ro at yahoo.com (BogDan) Date: Thu, 25 Jul 2013 07:37:57 -0700 (PDT) Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <4082192.eQr6N3KKOd@hal> References: <2171360.MuxoQFPleD@hal> <51EDD33A.2080603@codan.com.au> <4082192.eQr6N3KKOd@hal> Message-ID: <1374763077.64179.YahooMailNeo@web126102.mail.ne1.yahoo.com> >>  This provides a improvement for me but it is not a complete solution, on  >>  android we load libQt5xxx.so my solution as it was still tried to load >>  libQt5xxx.so.5 which doesn't exist as libraries are not symlinked on >>  android like they are on Linux and only libQt5xxx.so is present. > > Then perhaps this is the reason that the variable is simply cleared on > Android. qmake should probably generate the SONAME without the version on > android? > > Ossi, is that possible? > > Thanks, > Hello, If you are going to roll it back https://codereview.qt-project.org/#change,61330 a few things will stop to work immediately:  - android qt creator plugin.  - no qt apps will be movable to sdcard (most of the sdcards are fat formated, and it can not have symlinks).  - Ministro needs lots of changes to support symlinks, this is the reason why I choose not to use SONAME. There are two ways to have a Qt application on Android, one is to use Ministro to get the libs, and the second one is to bundle Qt libs into the APK. For none of them you don't need to use SONAME. Personally, I see no reason why should SONAME be used for Android ... Thanks, BogDan. P.S. Sorry for slow reply, I didn't see the message until now. From thiago.macieira at intel.com Thu Jul 25 17:23:17 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 Jul 2013 08:23:17 -0700 Subject: [Development] QQmlAbstractUrlInterceptor (Import control from Qt CS) In-Reply-To: <51F0EEF9.8070300@users.sourceforge.net> References: <51F0EEF9.8070300@users.sourceforge.net> Message-ID: <1405005.JGJdDdkSUK@tjmaciei-mobl2> On quinta-feira, 25 de julho de 2013 12:25:13, Alberto Mardegan wrote: > On 07/24/2013 06:47 PM, Alan Alpert wrote: > > Discussed at Qt CS as the mechanism for both file selectors and > > providing import control was a new QQmlAbstractUrlInterceptor class. > > You can provide a subclass of this to the QML engine to intercept all > > local file and QRC access, when combined with a custom > > QNetworkAccessManager the application has full control over all file > > and network access attempted by the engine. > > Would it make sense to have it in QCoreApplication instead of just > QQmlEngine? > I guess it could be useful also to non QML apps. We already have such a task. It's called "global QNetworkAccessManager", but unfortunately it's blocked on making QNAM thread-safe first. For such a global thing to exist at the non-graphical level, it needs to be thread-safe. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Thu Jul 25 17:26:21 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 Jul 2013 08:26:21 -0700 Subject: [Development] Implementation of qFuzzyCompare and zero values In-Reply-To: <51F0D110.90702@familiesomers.nl> References: <1606308.vCyzZRCPom@tjmaciei-mobl2> <51F0D110.90702@familiesomers.nl> Message-ID: <1835204.24oqL4WXeT@tjmaciei-mobl2> On quinta-feira, 25 de julho de 2013 09:17:36, André Somers wrote: > static inline bool qFuzzyComparePossibleNulls(double p1, double p2) > { > if (qFuzzyIsNull(p1)) { > return qFuzzyIsNull(p2); > } else if (qFuzzyIsNull(p2)) { > return false; > } else { > return qFuzzyCompare(p1, p2); > } > } if ((qFuzzyIsNull(p1) && qFuzzyIsNull(p2)) || qFuzzyCompare(p1, p2)) If p1 is zero, qFuzzyCompare(p1, p2) will return false unless p2 is also zero. But, no, I think we need something like what Jan-Arve is suggesting. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Thu Jul 25 17:28:14 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 Jul 2013 08:28:14 -0700 Subject: [Development] FW: Proposal for RFC like feature process In-Reply-To: References: Message-ID: <3275435.4ETGm8tvq9@tjmaciei-mobl2> On quinta-feira, 25 de julho de 2013 09:36:33, Bubke Marco wrote: > Hi > > There are now many new feature proposals popping up on the mailing list. > Sometime there is a link to a wiki page, JIRA etc.. You can easily get > lost. The result are more hard designable (we working on the qml designer) > features and Qml has more than enough already. So I propose something like > the PEPs of Python: http://www.python.org/dev/peps/pep-0001/ It is working > very well for them. > > Lets call it Qt Enhancement Proposal(QEP). > > In short you publish a QEP on the wiki and add it to the QEP list so > everybody can find it. There will be a discussion about it on the mailing > list. The arguments will be compressed in the QEP and then there will be a > decision. The QEP will stay so if somebody come up again he can be pointed > to the QEP. How is a QEP different than a suggestion in JIRA? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From 416365416c at gmail.com Thu Jul 25 17:42:01 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 25 Jul 2013 08:42:01 -0700 Subject: [Development] FW: Proposal for RFC like feature process In-Reply-To: References: Message-ID: On Thu, Jul 25, 2013 at 2:36 AM, Bubke Marco wrote: > > Hi > > There are now many new feature proposals popping up on the mailing list. > Sometime there is a link to a wiki page, JIRA etc.. You can easily get lost. > The result are more hard designable (we working on the qml designer) > features and Qml has more than enough already. So I propose something like > the PEPs of Python: http://www.python.org/dev/peps/pep-0001/ It is working > very well for them. > > Lets call it Qt Enhancement Proposal(QEP). > > In short you publish a QEP on the wiki and add it to the QEP list so > everybody can find it. There will be a discussion about it on the mailing > list. The arguments will be compressed in the QEP and then there will be a > decision. The QEP will stay so if somebody come up again he can be pointed > to the QEP. > > This worked very well for Python and so far I know most other languages(and > many projects) have simular process. > > Yes it sound like more work but I think in the end it is less. > How much more work it is, and the utility, depends on what exactly goes in the wiki. With this vague level of specification, I also cannot see the difference between this an a JIRA suggestion. Could you create a QEP-0001 both defining and exemplifying the concept? -- Alan Alpert From 416365416c at gmail.com Thu Jul 25 17:51:36 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 25 Jul 2013 08:51:36 -0700 Subject: [Development] QQmlAbstractUrlInterceptor (Import control from Qt CS) In-Reply-To: <51F0EEF9.8070300@users.sourceforge.net> References: <51F0EEF9.8070300@users.sourceforge.net> Message-ID: On Thu, Jul 25, 2013 at 2:25 AM, Alberto Mardegan wrote: > On 07/24/2013 06:47 PM, Alan Alpert wrote: >> Discussed at Qt CS as the mechanism for both file selectors and >> providing import control was a new QQmlAbstractUrlInterceptor class. >> You can provide a subclass of this to the QML engine to intercept all >> local file and QRC access, when combined with a custom >> QNetworkAccessManager the application has full control over all file >> and network access attempted by the engine. > > Would it make sense to have it in QCoreApplication instead of just > QQmlEngine? No, The point of QQmlAbstractUrlInterceptor is primarily to intercept URLs on the 'fast track' in the QML engine, because we keep a distinction between 'local files that can be accessed synchronously' and 'non-local files which cannot'. Without this internal distinction, QNetworkAccessManager can be used to intercept and redirect everything. It used to be that the QQmlEngine docs said to set a custom QNetworkAccessmanager for intercepting file access, but this had three important drawbacks 1) You have to use a custom URL everywhere 2) You take the slow path when you don't actually need to 3) You can't affect local module imports, like QtQuick. I don't think that QCoreApplication does very much direct file access internally, unlike the QQmlEngine. I don't see this generalizing to "all file access within the application", because it only applies to file accesses being taken by mechanisms outside your control (if you want to intercept a URL for QFile()... you just give it a different path). The only other such big semi-opaque file accessor I can think of would be webkit, but it's probably happy with just the custom QNAM. -- Alan Alpert From 416365416c at gmail.com Thu Jul 25 18:06:47 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 25 Jul 2013 09:06:47 -0700 Subject: [Development] [QtQuick] Mouse/Touch handling from Qt CS In-Reply-To: <8D46B42E-44BA-4B91-A9F7-31E4733115F8@digia.com> References: <8D46B42E-44BA-4B91-A9F7-31E4733115F8@digia.com> Message-ID: On Thu, Jul 25, 2013 at 1:14 AM, Rutledge Shawn wrote: > > On 24 Jul 2013, at 5:45 PM, Alan Alpert wrote: > >> Qt CS had a discussion on how to handle mouse and touch event >> conflicts in QtQuick going forwards. >> >> An interesting idea came up that the existing model might be >> salvageable if we fix multi-cursor support. > > I suggested that idea 2 years ago, but I was told authoritatively at that time that realistically, Qt will never support multiple cursors, because the idea of a single cursor, single grab, single focus, etc. is so pervasive in Qt. Two years ago, was capacitive multi-touch an essential feature for UIs? Or was it still just emerging as a dominant UI paradigm? It will be easier to fix in QtQuick than in Widgets. Hopefully. Realistically, we probably don't have the capacity to fix it in widgets anyways. If it is indeed too hard to fix, then we'll just implement mouse and touch handling for now and we'll continue researching the ultimate solution for Qt 6 ( or QtQuick 3 ). > Another thing is that doing a pinch gesture with 2 mice, or 2 hands on a touch screen, is not the common use case, and multi-user applications will need to distinguish the users. The ideal touch hardware would be able to treat separate hands as separate users, so that the software could handle multiple separate gestures at the same time. Therefore it's an oversimplification to say that one mouse cursor is the same thing as one touch point, although we might get away with it in single-user applications. Single-user applications are the dominant form right now, I'm okay with focusing on them. > I also don't like the fact that events take such a circuitous path: the OS event is morphed into a QPA event and queued; then it's morphed into a classic Qt event and queued again; then it's morphed into a Qt Quick event and the hierarchy traversal finally begins, to find the right item in the scene. If it's a touch event, then for each item in the scene, it might have to get converted to an item-specific synthetic mouse event (that part is my doing though). It's amazing that we can get real-time dragging performance at all, with so much overhead. (And graphics view has a similar parallel event path of its own.) Given that every OS has an event queue already, I wonder why we even need multiple queues of our own; why don't we just ask QPA to fetch the next event from the OS queue, and convert it just once into a single cross-platform event type? I suppose mainly it's so that Qt can inject its own events into the stream, although a timeline of "our stuff" interleaved with "their stuff" could have been implemented without requiring a common event type. And why does QtQuick really need its own separate event types? Just because of binary compatibility guarantees, we can't change the old event types? Or because of the chance that if we did it wrong, all the widgets would need work? But we could have planned to change this in time for 5.0, to have one event type for every layer. Now that is past, but we could still plan to reunify the events for Qt 6. Sounds good. Add a TODO Qt 6 somewhere. > If not, it would still be nice if QtQuick could short-circuit some of the event delivery path. I've been wondering if it could interface directly to QPA. Probably it would have profound effects on our chances of properly nesting QtQuick and widgets in the same application. (Which is problematic anyhow, due to the fact that OpenGL rendering always requires its own window.) But it would also provide a chance to handle multiple cursors in QtQuick only, without making incompatible changes in all the other layers. I'd have to see a prototype to understand how that would help... > Ironically it was pointed out again after Doug Englebart's recent passing that from the beginning, he assumed that a multi-user multi-tasking computer would of course require multiple mice, so that each user can interact with objects on the screen independently. 45 years later, we still haven't gotten around to treating that as the mainstream use case. It could be one of the last reasons left to use a desktop or large-screen computer. Most people seem to have discarded the idea as impractical approx. 45 years ago. Without a screen the size of a house (which we only just now have with 4K Projectors), you get in each others way and there isn't even the physical volume of fingers to help stop that. But my point is that it's more important for Qt to support the interaction paradigms that are established in the market, like single cursor and capacitive multi-touch, than speculative or unpopular models. Those are just a bonus. -- Alan Alpert From 416365416c at gmail.com Thu Jul 25 18:31:50 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 25 Jul 2013 09:31:50 -0700 Subject: [Development] [QtQuick] Views Version 2 from Qt CS; animated layout In-Reply-To: References: Message-ID: On Thu, Jul 25, 2013 at 12:37 AM, Rutledge Shawn wrote: > > On 24 Jul 2013, at 5:45 PM, Alan Alpert wrote: > >> There's a rough outline of how we want views to look in QtQuick, >> because the current ListView is unmaintainable and not extensible. See >> http://qt-project.org/groups/qt-contributors-summit-2013/wiki/Qt-Quick-views-version-2 >> for details. > > It was already obvious for a long time that instantiation, layout and flicking behavior ought to have been separated from the beginning. (At least Flickable is inherited, so hopefully we don't have to do a lot extra to get the touch events working in the views.) > > Yesterday we were talking more about animating transitions between layouts. I think we might be able to get there by giving a layout manager a list of items to manage (not necessarily a public property), and adding a layout: property to Item. So if you declare > > Rectangle { > Repeater { > id: peter > anchors.fill: parent > layout: FlowLayout { anchors.fill: peter; spacing: … } > model: … > Rectangle { … } > } > } > > then the Repeater will give the FlowLayout the repeater's children as its list of items to manage. Later you could assign a different layout, and when the property changes it will give the items to the second layout to manage. The delegate Rectangle could have its own state transitions or Behavior on x and y or something like that to animate from its position as determined by the first layout to its position determined by the second. That part needs more thought. Have you considered using the Positioner layouts for inspiration? They have a similar set of add/move/remove transitions to the view classes, and you don't need a special "positioner" property on Item to make use of them. Just reparenting items to a different positioner and using an add transition is enough for an animated change. > The layout must have correct geometry, but it doesn't have to get it from its parent. The layout would not be required to be in the item containment hierarchy. Yet the app author can still easily see which items have which layouts, because of the layout: declaration. Except that Layouts are not on Items, conceptually layouts are just item group in the hierarchy. This seems like a much more confusing approach to me (although that could just be because your example doesn't work - Repeaters have no children). Also QtQuick can't depend on QtQuick.Layouts, so there's a technical and conceptual problem from that too. > The current way is that the items must be children of the layout, so you can't switch layouts without reparenting all of the items. That way could continue to work for the simple use case: if the layout has children then it will assign them to its own list of items-to-manage. Sounds like all you need is a convenient reparentAll() mechanism. Does a binding on the children: property work? > The QQuickLayoutAttached will have to continue to be universal, having properties that apply to any kind of layout. But it would be useful to have a mechanism to change the properties depending on which layout is applied, so e.g. if you switch a device from portrait to landscape, the layout can change, and the items can also change their preferred width/height etc. > > Yesterday I began to write a file manager to test the DnD behavior, and was thinking about how one fundamental usability feature which has been present in the Mac finder from the beginning (and missing from many other file managers) is that in the icon view you can rearrange the icons however you want, and the OS will remember those positions. (Spatial memory might help you to organize sub-parts of a project or something like that.) They are not forced to sit on a grid all the time, and yet there is a handy "cleanup" command which will arrange them to a grid on-demand. (In OS X it's been extended to have Cleanup by Name etc, which basically sorts the items at the same time, and you can also toggle "Arrange by name" etc. to keep the sorted and grid-aligned all the time.) So generalizing this idea provides some further motivation to have switchable layout managers (including switching to no layout at all), and animated position movements. Since I cannot do that yet, in my file manager I cannot use layouts; I can set the position of each icon in component.onCompleted, and the user is free to drag the icons around afterwards. The Cleanup command would have to be implemented in Javascript. (Fortunately a flow layout is easy to implement.) > > The file manager, along with many other types of "infinite canvas" drawing and diagramming applications, need 2-dimensional panning functionality, so the Flickable seems a natural fit. And many of those could benefit from dynamically creating and destroying delegates too, to save memory when there are a lot of objects in the model, because the Flickable could manage a really large area. So the instantiation needs to support creating and destroying delegates in both dimensions (whereas ListView, GridView and PathView only create at one end and destroy at the other, depending on the single direction of movement). Yes, you'd also need 2D creation for TableView and GenuineGridView (as opposed to list view with grid layout, which is a more accurate depiction of the current GridView). > Under Controller you have viewport and reaction to input, but Flickable takes care of those. Do you think there's anything wrong with that? And then there is the selection model. So far it has been enough in such cases for each item to have its own MouseArea and to remember its own selection state, but it would be nice to have a means to implement a lasso tool, and a means of maintaining a list of selections, although it's possible to iterate all the children and find the ones that are selected, and it's also possible to maintain a separate list in JS. Delegates remembering their own selection state means that you lose selection state the moment the item goes offscreen. So that's unacceptable in a lot of cases. Selection is also about more than just click-to-select, some usecases require selection to be managed or controlled externally, which is where having a separate selection model that can also be interacted with in C++ (like the existing selection models) are ideal. But this is another area where it should be modular, so that for the bevy of simple usecases you can just do the MouseArea thing and not pay the cost for coordinating with a separate selection model. > The Instantiator name is already taken, but was it designed to be used for views? It could be extended. We need to define the needs of an "Instantiator" in this context better before we can know whether that fits the design or not. > Come to think of it, the trouble with Repeater has always been that it's in the containment hierarchy, but it's an interloper. It's similar to how the layout has a behavioral role, and therefore should not be required to be in the containment hierarchy. If you want to make a component which is something like a ListView, but you want to customize it by rebuilding it from scratch, then you might use a Repeater to instantiate the rows in the list. You will soon run into the trouble that each item's parent is the Repeater, not the list component which you were trying to create. This must be fixed. Already done. Since time immemorial, Repeater re-parents everything it creates to be a child of the Repeater's parent. Instantiator is even more generic, it doesn't enforce any parenting and just creates stuff. >So hopefully the "new view" will make the Repeater obsolete, and we need to start upholding the design pattern that the parent of a delegate or inner component should always be the useful parent component (the one the user is trying to create), not the layout or the repeater. So most of these interchangeable components should be properties. You could do something like this: > > Viewport { > id: vp > View { > id: view > model: ... > delegate: Rectangle { > id: del > MouseArea { > anchors.fill: parent > onClicked: view.selection.toggle(del) > drag.target: del > } > } > instantiator: ... > layout: FlowLayout { anchors.fill: parent; spacing ? } > controllers: [ > MultipleSelectionArea { > anchors.fill: view > target: view.selection > } > FlickArea { > anchors.fill: vp > target: vp > } > ] > } > } > > • Every child of the view can see that its parent is the view itself: no interlopers (such as layout or repeater) > > • The view does NOT contain children other than the ones the user wants to see; so if you iterate the children you won't have to check the type of each This example does not actually include QQuickItem children at all (except that View is a child of the Viewport), making it hard to see either point. Any Item level parent relationship is being done custom by the View type, or not. > • There can be multiple controllers, to handle as many behaviors as we like How do they interact? Like if I specify two FlickAreas with different sizes? > • A Flickable has two roles: it's a viewport, which is why it is normally the view's parent, and it also does the flicking. This can be split up further as shown, but I'm not sure we gain much from writing the extra declarations. The View could just have a Flickable as its parent. But splitting it up like this makes the design principle more consistent: the view hierarchy resembles the scene graph, while the behaviors are implemented by independent controllers which are NOT in the view hierarchy. The same logic could be extended to the MouseArea: if every Item had a controllers list (or if we had a habit of hiding controllers in the data property), we could say that a controller is never a visual child of an item. What about interaction items, like MouseArea and MultiPointTouchArea, which need to be in the visual hierarchy? It seems like a pointless complication to me that "every Item" can take on certain interaction behaviors by specifying controllers on it. It's much simpler to have those behaviors as separate items, which conceptually simplifies Item while also allowing the user greater manual control over the interaction of multiple 'controllers'. > • MultipleSelectionArea would handle mouse and touch events which fall on any of the items in its target list, so dragging one drags them all. If you drag somewhere else on its parent, then it would lasso-select items from the target. > > • The MultipleSelectionArea could handle slow drags, and the FlickArea could handle quick drags. They could have minimum/maximumVelocity properties. Or the MultipleSelectionArea's lasso behavior could be configured to handle mouse events only, not touch events. How do they communicate? They don't even have a reference to each other, is View managing all this? In which case "View" is the real controller, and the controllers property is just a list of behaviors for this controller to have. > I don't think the "controller" can be just one thing, because there can be a lot of separate behaviors, done with separate gestures: flicking/panning, lasso selection, drawing new items, dragging individual items, dragging multiple selections, etc. > The problem with splitting them up like this has always been about how the communication is managed between components without unacceptable overhead. The biggest example being how the Instantiator, Layout and ViewPort need to work together to determine which items are on screen and need delegates. Might even need to also communicate with the controller to preload incoming items while scrolling. If everything goes through the View, like it seems to in your example, then it's still a big monolithic class that knows everything and we've just added more customizability to it (which might be enough, I don't know). -- Alan Alpert From jfaust at suitabletech.com Thu Jul 25 18:34:54 2013 From: jfaust at suitabletech.com (Josh Faust) Date: Thu, 25 Jul 2013 10:34:54 -0600 Subject: [Development] Qml: fast-path loading of custom URLs Message-ID: > It used to be that the QQmlEngine docs said to set a custom > QNetworkAccessmanager for intercepting file access, but this had three > important drawbacks > 1) You have to use a custom URL everywhere > 2) You take the slow path when you don't actually need to > Is there any plan for allowing the fast path through custom URLs? We have an internal system similar to qrc, which we currently have to use QNAM to access. One possibility is to allow custom handlers for qrc paths, e.g.: QResource::registerHandler("my_custom_root_directory", my_handler); We could then use QQmlAbstractUrlInterceptor to translate custom URLs into qrc paths. This is a bit roundabout, but would also allow things like path-based imports to work. Alternatively, being able to mark a NetworkReply as immediately finished would get most of the way there. This would require changes in a lot of loading paths that use the URL to determine if the file is local or remote. Has something like QResource::registerHandler() been considered in the past? Are there any drawbacks to that approach? Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From njeisecke at saltation.de Thu Jul 25 19:41:22 2013 From: njeisecke at saltation.de (Nils Jeisecke) Date: Thu, 25 Jul 2013 19:41:22 +0200 Subject: [Development] OSX CMake broken in 5.1.1 In-Reply-To: <2054791.Bg9StSXMzj@hal> References: <2054791.Bg9StSXMzj@hal> Message-ID: Hi! I still have this problem. qtbase is at cb6fec851507e9e2a53e8b4b7d70e7e4ac165348. This is my (out of source) configure line. ../../qt5/onfigure -opensource -nomake tests On Sun, Jun 16, 2013 at 11:35 AM, Stephen Kelly wrote: > On Friday, June 07, 2013 14:18:49 Daiwei Li wrote: >> I recently my version of Qt to 5.1.1 and it seems to have broken CMake on >> OSX. I get the following error message: > > The workaround for this issue has been merged to the qtbase stable branch. > Feel free to update to that and re-test. > > Thanks! > > -- > Stephen Kelly | 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 > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Dipl. Inform. Nils Jeisecke fon: +49 (0) 521 - 329647-12 fax: +49 (0) 521 - 329647-40 email: jeisecke at saltation.de --------------- saltation GmbH & Co. KG | Niederwall 43 | 33602 Bielefeld Sitz Bielefeld | Amtsgericht Bielefeld HRA 15344 Persönlich haftende Gesellschafterin: saltation Beteiligungs-GmbH | Niederwall 43 | 33602 Bielefeld Sitz Bielefeld | Amtsgericht Bielefeld HRB 39339 Geschäftsführer: Daniel Brün --------------- From njeisecke at saltation.de Thu Jul 25 19:47:10 2013 From: njeisecke at saltation.de (Nils Jeisecke) Date: Thu, 25 Jul 2013 19:47:10 +0200 Subject: [Development] OSX CMake broken in 5.1.1 In-Reply-To: <2054791.Bg9StSXMzj@hal> References: <2054791.Bg9StSXMzj@hal> Message-ID: Hi! Sorry for my previous mail, I hit the send button too early :-( On Sun, Jun 16, 2013 at 11:35 AM, Stephen Kelly wrote: > On Friday, June 07, 2013 14:18:49 Daiwei Li wrote: >> I recently my version of Qt to 5.1.1 and it seems to have broken CMake on >> OSX. I get the following error message: > > The workaround for this issue has been merged to the qtbase stable branch. > Feel free to update to that and re-test. I still have this problem. qtbase is at cb6fec851507e9e2a53e8b4b7d70e7e4ac165348. This is my (out of source) configure line. ../../qt5/onfigure -opensource -nomake tests make make install This gives me a framework installation in /usr/local/Qt-5.1.1 My CMakeLists.txt --- cmake_minimum_required(VERSION 2.8.11) project(testproject) # Find includes in corresponding build directories set(CMAKE_INCLUDE_CURRENT_DIR ON) # Instruct CMake to run moc automatically when needed. set(CMAKE_AUTOMOC ON) # Find the QtWidgets library find_package(Qt5Widgets) # Tell CMake to create the helloworld executable add_executable(helloworld WIN32 main.cpp) # Use the Widgets module from Qt 5. target_link_libraries(helloworld Qt5::Widgets) --- Now a minimal testcase produces the following result: --- cmake -DCMAKE_PREFIX_PATH=/usr/local/Qt-5.1.1 .. CMake Error at /usr/local/Qt-5.1.1/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake:15 (message): The imported target "Qt5::Widgets" references the file "/usr/local/Qt-5.1.1/include/QtWidgets" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/local/Qt-5.1.1/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake" but not all the files it references. Call Stack (most recent call first): /usr/local/Qt-5.1.1/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake:50 (_qt5_Widgets_check_file_exists) CMakeLists.txt:11 (find_package) --- What's wrong with my setup? Nils From 416365416c at gmail.com Thu Jul 25 20:19:25 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 25 Jul 2013 11:19:25 -0700 Subject: [Development] Qml: fast-path loading of custom URLs In-Reply-To: References: Message-ID: On Thu, Jul 25, 2013 at 9:34 AM, Josh Faust wrote: > >> It used to be that the QQmlEngine docs said to set a custom >> QNetworkAccessmanager for intercepting file access, but this had three >> important drawbacks >> 1) You have to use a custom URL everywhere >> 2) You take the slow path when you don't actually need to > > > Is there any plan for allowing the fast path through custom URLs? We have an > internal system similar to qrc, which we currently have to use QNAM to > access. > > One possibility is to allow custom handlers for qrc paths, e.g.: > QResource::registerHandler("my_custom_root_directory", my_handler); > > We could then use QQmlAbstractUrlInterceptor to translate custom URLs into > qrc paths. This is a bit roundabout, but would also allow things like > path-based imports to work. Yes, this should work. In the end you need to return a file or qrc (or bundle) path so that it's something which the engine knows how to synchronously load, but QQmlAbstractUrlInterceptor does cover all URLs not just strictly fast path ones. > Alternatively, being able to mark a NetworkReply as immediately finished > would get most of the way there. This would require changes in a lot of > loading paths that use the URL to determine if the file is local or remote. We have that, in that you can mark a reply as finished immediately and then it will continue to load it synchronously. But that's still taking a slightly slower path and counts as a remote resource (which restricts the behavior slightly, such as requiring qmldir files and restricting plugin loading). > Has something like QResource::registerHandler() been considered in the past? > Are there any drawbacks to that approach? I haven't considered that approach, and don't know much about it (or its drawbacks). -- Alan Alpert From achartier at fastmail.fm Thu Jul 25 20:36:51 2013 From: achartier at fastmail.fm (achartier at fastmail.fm) Date: Thu, 25 Jul 2013 11:36:51 -0700 Subject: [Development] Qt online installer "source code": where is it? In-Reply-To: References: Message-ID: <1374777411.31587.9223372036857084053.4D05B7D6@webmail.messagingengine.com> Perfect! Thank you very much Thiago. From jfaust at suitabletech.com Thu Jul 25 21:28:49 2013 From: jfaust at suitabletech.com (Josh Faust) Date: Thu, 25 Jul 2013 13:28:49 -0600 Subject: [Development] Qml: fast-path loading of custom URLs In-Reply-To: References: Message-ID: > We have that, in that you can mark a reply as finished immediately and > then it will continue to load it synchronously. But that's still > taking a slightly slower path and counts as a remote resource (which > restricts the behavior slightly, such as requiring qmldir files and > restricting plugin loading). > Interesting, somehow I missed setFinished(). I'll have to experiment with how much of a difference that makes. > > > Has something like QResource::registerHandler() been considered in the > past? > > Are there any drawbacks to that approach? > > I haven't considered that approach, and don't know much about it (or > its drawbacks). > Mostly wondering if it's been discussed and discarded in the past for any reason. I've filed a suggestion as QTBUG-32636, and if I can get some free time may have a go at implementing it. Thanks Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.t.rutledge at gmail.com Thu Jul 25 21:49:50 2013 From: shawn.t.rutledge at gmail.com (Shawn Rutledge) Date: Thu, 25 Jul 2013 21:49:50 +0200 Subject: [Development] [QtQuick] Views Version 2 from Qt CS; animated layout In-Reply-To: References: Message-ID: On 25 July 2013 18:31, Alan Alpert <416365416c at gmail.com> wrote: > On Thu, Jul 25, 2013 at 12:37 AM, Rutledge Shawn > wrote: >> >> On 24 Jul 2013, at 5:45 PM, Alan Alpert wrote: >> ... > Have you considered using the Positioner layouts for inspiration? They > have a similar set of add/move/remove transitions to the view classes, > and you don't need a special "positioner" property on Item to make use > of them. Just reparenting items to a different positioner and using an > add transition is enough for an animated change. But reparenting is cumbersome: it typically needs to be done via a for loop in JS, and takes time to run. So it seems easier to assign a new layout somewhere. The loop to "take over" the layout management of all the items will be in C++ at least. When you are building a reusable container component of some sort, the layout is sometimes just an implementation detail that you would prefer to hide. But you can't, if every item that you add to the container is actually added to the layout inside the container instead; then the items' parents are not the container, even though the application author declared them that way. Next thing you know, you have to tell application authors that they can't trust the parent property, and should refer to the container by ID. Or else you have to give up on layout classes and write the layout logic in JS just to flatten the containment hierarchy. For me this points to the conclusion that layout should be a plug-in behavior rather than trying to be the container. > Repeaters have no children OK you're right; I've forgotten some details since the last time the problem I'm thinking of came up. Maybe the problem was that there was a container component written with the expectation that items would be directly added to it, but the user put a Repeater inside instead. The container had a loop to iterate its children, and then it had to have an extra test to ignore the repeater (the abnormal child). The automatic reparenting is still arguably unintuitive. > Also QtQuick can't depend > on QtQuick.Layouts, so there's a technical and conceptual problem from > that too. That's not a real obstacle though; I can think of more than one way to solve it. >> The current way is that the items must be children of the layout, so you can't switch layouts without reparenting all of the items. That way could continue to work for the simple use case: if the layout has children then it will assign them to its own list of items-to-manage. > > Sounds like all you need is a convenient reparentAll() mechanism. It would still be a procedural hackaround. The more we stick to "what you declare is what you get", the easier it is for designer tools and such. > Does a binding on the children: property work? A binding to a list, so you can swap them? > Delegates remembering their own selection state means that you lose > selection state the moment the item goes offscreen. So that's > unacceptable in a lot of cases. Selection is also about more than just > click-to-select, some usecases require selection to be managed or > controlled externally, which is where having a separate selection > model that can also be interacted with in C++ (like the existing > selection models) are ideal. I agree. >> Viewport { >> id: vp >> View { >> id: view >> model: ... >> delegate: Rectangle { >> id: del >> MouseArea { >> anchors.fill: parent >> onClicked: view.selection.toggle(del) >> drag.target: del >> } >> } >> instantiator: ... >> layout: FlowLayout { anchors.fill: parent; spacing ? } >> controllers: [ >> MultipleSelectionArea { >> anchors.fill: view >> target: view.selection >> } >> FlickArea { >> anchors.fill: vp >> target: vp >> } >> ] >> } >> } >> >> • Every child of the view can see that its parent is the view itself: no interlopers (such as layout or repeater) >> >> • The view does NOT contain children other than the ones the user wants to see; so if you iterate the children you won't have to check the type of each > > This example does not actually include QQuickItem children at all > (except that View is a child of the Viewport), making it hard to see > either point. Any Item level parent relationship is being done custom > by the View type, or not. The delegates are not children of the View? If that was a ListView, they would be. >> • There can be multiple controllers, to handle as many behaviors as we like > > How do they interact? Like if I specify two FlickAreas with different sizes? If you mean that there are ways to shoot yourself in the foot, yeah probably. If you mean to divide up an item into regions using multiple FlickAreas, then the events should be delivered to the right instance based on location. >> • A Flickable has two roles: it's a viewport, which is why it is normally the view's parent, and it also does the flicking. This can be split up further as shown, but I'm not sure we gain much from writing the extra declarations. The View could just have a Flickable as its parent. But splitting it up like this makes the design principle more consistent: the view hierarchy resembles the scene graph, while the behaviors are implemented by independent controllers which are NOT in the view hierarchy. The same logic could be extended to the MouseArea: if every Item had a controllers list (or if we had a habit of hiding controllers in the data property), we could say that a controller is never a visual child of an item. > > What about interaction items, like MouseArea and MultiPointTouchArea, > which need to be in the visual hierarchy? It seems like a pointless > complication to me that "every Item" can take on certain interaction > behaviors by specifying controllers on it. It's much simpler to have > those behaviors as separate items, which conceptually simplifies Item > while also allowing the user greater manual control over the > interaction of multiple 'controllers'. Nesting Areas is a trial-and-error affair though. The photosurface example happens to work: you can drag items via the MouseArea and also do pinch zooming and rotation via the PinchArea; but if you nest the PinchArea and MouseArea the other way, it doesn't work anymore; or if you stack them in either order it doesn't work. I wouldn't be surprised if the present arrangement stopped working or became cumbersome to keep working at some point. The example exists so that we can remember which way is the one that happens to work, but it's not a good example of how to make declarations in such a way that you will intuitively understand why it works. >> • MultipleSelectionArea would handle mouse and touch events which fall on any of the items in its target list, so dragging one drags them all. If you drag somewhere else on its parent, then it would lasso-select items from the target. >> >> • The MultipleSelectionArea could handle slow drags, and the FlickArea could handle quick drags. They could have minimum/maximumVelocity properties. Or the MultipleSelectionArea's lasso behavior could be configured to handle mouse events only, not touch events. > > How do they communicate? They don't even have a reference to each other, Events get delivered recursively anyway, so if one area rejects an event based on velocity or some other property that is out of range, the other area will get a shot at handling it. But the list could be treated as an order of precedence. (And I'm not sure that's intuitive enough, either.) The list of controllers is just a brainstorm, but I think it will be limiting to say that there is only one controller per View. > The problem with splitting them up like this has always been about how > the communication is managed between components without unacceptable > overhead. The biggest example being how the Instantiator, Layout and > ViewPort need to work together to determine which items are on screen > and need delegates. Might even need to also communicate with the > controller to preload incoming items while scrolling. If everything > goes through the View, like it seems to in your example, then it's > still a big monolithic class that knows everything and we've just > added more customizability to it (which might be enough, I don't > know). Well what architecture did you have in mind? I wasn't able to be at QtCS, so sorry if it's asking for too much repetition. I agree that decoupling is good. From shawn.t.rutledge at gmail.com Thu Jul 25 22:23:13 2013 From: shawn.t.rutledge at gmail.com (Shawn Rutledge) Date: Thu, 25 Jul 2013 22:23:13 +0200 Subject: [Development] [QtQuick] Mouse/Touch handling from Qt CS In-Reply-To: References: <8D46B42E-44BA-4B91-A9F7-31E4733115F8@digia.com> Message-ID: On 25 July 2013 18:06, Alan Alpert <416365416c at gmail.com> wrote: > On Thu, Jul 25, 2013 at 1:14 AM, Rutledge Shawn > wrote: >> >> On 24 Jul 2013, at 5:45 PM, Alan Alpert wrote: >> >>> Qt CS had a discussion on how to handle mouse and touch event >>> conflicts in QtQuick going forwards. >>> >>> An interesting idea came up that the existing model might be >>> salvageable if we fix multi-cursor support. >> >> I suggested that idea 2 years ago, but I was told authoritatively at that time that realistically, Qt will never support multiple cursors, because the idea of a single cursor, single grab, single focus, etc. is so pervasive in Qt. > > Two years ago, was capacitive multi-touch an essential feature for > UIs? Yes, it became an essential feature for mobile device UIs suddenly in 2007. But the point is not whether or not to have multi-touch, but whether we can pretend that multi-touch and multi-mouse are the same thing. I don't think we can because 1) it's the hard way to get there, due to Qt legacy 2) the use cases aren't really the same 3) multiple mice implies multiple users, multiple active windows, multiple focus, etc. > It will be easier to fix in QtQuick than in Widgets. Hopefully. > Realistically, we probably don't have the capacity to fix it in > widgets anyways. If it is indeed too hard to fix, then we'll just > implement mouse and touch handling for now and we'll continue > researching the ultimate solution for Qt 6 ( or QtQuick 3 ). I expect that's how it will turn out. >> If not, it would still be nice if QtQuick could short-circuit some of the event delivery path. I've been wondering if it could interface directly to QPA. Probably it would have profound effects on our chances of properly nesting QtQuick and widgets in the same application. (Which is problematic anyhow, due to the fact that OpenGL rendering always requires its own window.) But it would also provide a chance to handle multiple cursors in QtQuick only, without making incompatible changes in all the other layers. > > I'd have to see a prototype to understand how that would help... Me too. ;-) If everyone thinks it's a hopeless idea, then I suppose it's not worth trying. But I think it would be a nice optimization to cut down on the number of layers, event type conversions and queueing involved. > Most people seem to have discarded the idea as impractical approx. 45 > years ago. Without a screen the size of a house The size of a table or some part of a wall is big enough to start. It's been possible to buy such a thing for a long time already. Game consoles have always been multi-user, they just don't usually use conventional pointing devices. > (which we only just now have with 4K Projectors), you get in each others way and there > isn't even the physical volume of fingers to help stop that. Hardware limitations tend to get solved eventually. I think bigger screens are inevitable; next, multi-user applications might start to become more common. So we would do well to preemptively start removing obstacles ahead of time, even if it doesn't seem urgent. From 416365416c at gmail.com Thu Jul 25 23:51:30 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 25 Jul 2013 14:51:30 -0700 Subject: [Development] [QtQuick] Views Version 2 from Qt CS; animated layout In-Reply-To: References: Message-ID: On Thu, Jul 25, 2013 at 12:49 PM, Shawn Rutledge wrote: > On 25 July 2013 18:31, Alan Alpert <416365416c at gmail.com> wrote: >> On Thu, Jul 25, 2013 at 12:37 AM, Rutledge Shawn >> wrote: >>> >>> On 24 Jul 2013, at 5:45 PM, Alan Alpert wrote: >>> > ... >> Have you considered using the Positioner layouts for inspiration? They >> have a similar set of add/move/remove transitions to the view classes, >> and you don't need a special "positioner" property on Item to make use >> of them. Just reparenting items to a different positioner and using an >> add transition is enough for an animated change. > > But reparenting is cumbersome: it typically needs to be done via a for > loop in JS, and takes time to run. So it seems easier to assign a new > layout somewhere. The loop to "take over" the layout management of > all the items will be in C++ at least. > > When you are building a reusable container component of some sort, the > layout is sometimes just an implementation detail that you would > prefer to hide. But you can't, if every item that you add to the > container is actually added to the layout inside the container > instead; then the items' parents are not the container, even though > the application author declared them that way. Next thing you know, > you have to tell application authors that they can't trust the parent > property, and should refer to the container by ID. Or else you have > to give up on layout classes and write the layout logic in JS just to > flatten the containment hierarchy. For me this points to the > conclusion that layout should be a plug-in behavior rather than trying > to be the container. If you make the layout logic implicit, then you're just telling applications authors that they can't use anchors in case it gets laid out. We have the semi-hidden item pattern for flickable already, and it's better than making the x/y/anchors unusable. It's the same with putting the layout logic in JS, you're taking total control over the positioning of the items and ignoring anything that the developer has set - which is just one reason why I'd argue you should never write the layout logic in JS. Remember that this is a scripting language for pixel-perfect UIs. It's more important to have more insight and control over the pixel positioning of items than it is to have proper component encapsulation (the two are usually at odds). >> Repeaters have no children > > OK you're right; I've forgotten some details since the last time the > problem I'm thinking of came up. Maybe the problem was that there was > a container component written with the expectation that items would be > directly added to it, but the user put a Repeater inside instead. The > container had a loop to iterate its children, and then it had to have > an extra test to ignore the repeater (the abnormal child). If you're iterating over children then you're doing something wrong already. But I think there's a way to iterate over the generated items instead of the children of the Item it gets reparented into, which will always have to ignore other possible children if you're only interested in the generated items. > The automatic reparenting is still arguably unintuitive. It's the Qt Magic Language, lots of crazy stuff happens behind the scenes ;) . This leads to lots of cases where there's this arguably more/less intuitive way of doing things, but once you learn it then it's (usually) really efficient. >> Also QtQuick can't depend >> on QtQuick.Layouts, so there's a technical and conceptual problem from >> that too. > > That's not a real obstacle though; I can think of more than one way to solve it. I can't. Can you elaborate on at least one way to add a Layout type property to QtQuick without any knowledge of QtQuick.Layouts? Without moving Layouts into QtQuick of course. > >>> The current way is that the items must be children of the layout, so you can't switch layouts without reparenting all of the items. That way could continue to work for the simple use case: if the layout has children then it will assign them to its own list of items-to-manage. >> >> Sounds like all you need is a convenient reparentAll() mechanism. > > It would still be a procedural hackaround. The more we stick to "what > you declare is what you get", the easier it is for designer tools and > such. Depends on whether the reparent all mechanism is procedural. The below list binding approach should be fine. >> Does a binding on the children: property work? > > A binding to a list, so you can swap them? Yes. I don't know if that currently works, but it should. >> Delegates remembering their own selection state means that you lose >> selection state the moment the item goes offscreen. So that's >> unacceptable in a lot of cases. Selection is also about more than just >> click-to-select, some usecases require selection to be managed or >> controlled externally, which is where having a separate selection >> model that can also be interacted with in C++ (like the existing >> selection models) are ideal. > > I agree. > >>> Viewport { >>> id: vp >>> View { >>> id: view >>> model: ... >>> delegate: Rectangle { >>> id: del >>> MouseArea { >>> anchors.fill: parent >>> onClicked: view.selection.toggle(del) >>> drag.target: del >>> } >>> } >>> instantiator: ... >>> layout: FlowLayout { anchors.fill: parent; spacing ? } >>> controllers: [ >>> MultipleSelectionArea { >>> anchors.fill: view >>> target: view.selection >>> } >>> FlickArea { >>> anchors.fill: vp >>> target: vp >>> } >>> ] >>> } >>> } >>> >>> • Every child of the view can see that its parent is the view itself: no interlopers (such as layout or repeater) >>> >>> • The view does NOT contain children other than the ones the user wants to see; so if you iterate the children you won't have to check the type of each >> >> This example does not actually include QQuickItem children at all >> (except that View is a child of the Viewport), making it hard to see >> either point. Any Item level parent relationship is being done custom >> by the View type, or not. > > The delegates are not children of the View? If that was a ListView, > they would be. It's not explicit in the QML. If it was a ListView, the delegates would be children of the contentItem, not of the ListView directly. You *could* do the same thing with all the other items, my point is that it's entirely implicit behavior in the implementation of View{} and thus any "children organization" sort of problems are already entirely in our control. >>> • There can be multiple controllers, to handle as many behaviors as we like >> >> How do they interact? Like if I specify two FlickAreas with different sizes? > > If you mean that there are ways to shoot yourself in the foot, yeah > probably. If you mean to divide up an item into regions using > multiple FlickAreas, then the events should be delivered to the right > instance based on location. > >>> • A Flickable has two roles: it's a viewport, which is why it is normally the view's parent, and it also does the flicking. This can be split up further as shown, but I'm not sure we gain much from writing the extra declarations. The View could just have a Flickable as its parent. But splitting it up like this makes the design principle more consistent: the view hierarchy resembles the scene graph, while the behaviors are implemented by independent controllers which are NOT in the view hierarchy. The same logic could be extended to the MouseArea: if every Item had a controllers list (or if we had a habit of hiding controllers in the data property), we could say that a controller is never a visual child of an item. >> >> What about interaction items, like MouseArea and MultiPointTouchArea, >> which need to be in the visual hierarchy? It seems like a pointless >> complication to me that "every Item" can take on certain interaction >> behaviors by specifying controllers on it. It's much simpler to have >> those behaviors as separate items, which conceptually simplifies Item >> while also allowing the user greater manual control over the >> interaction of multiple 'controllers'. > > Nesting Areas is a trial-and-error affair though. The photosurface > example happens to work: you can drag items via the MouseArea and also > do pinch zooming and rotation via the PinchArea; but if you nest the > PinchArea and MouseArea the other way, it doesn't work anymore; or if > you stack them in either order it doesn't work. I wouldn't be > surprised if the present arrangement stopped working or became > cumbersome to keep working at some point. The example exists so that > we can remember which way is the one that happens to work, but it's > not a good example of how to make declarations in such a way that you > will intuitively understand why it works. Interactions between complex elements is always going to be a bit of trial-and-error, which is why I like having the elements exposed in a more direct fashion. This allows the app developer to do extensive trial-and-error until it works for them, as opposed to having it buried in a list where you feel stuck after you tried swapping the order. > >>> • MultipleSelectionArea would handle mouse and touch events which fall on any of the items in its target list, so dragging one drags them all. If you drag somewhere else on its parent, then it would lasso-select items from the target. >>> >>> • The MultipleSelectionArea could handle slow drags, and the FlickArea could handle quick drags. They could have minimum/maximumVelocity properties. Or the MultipleSelectionArea's lasso behavior could be configured to handle mouse events only, not touch events. >> >> How do they communicate? They don't even have a reference to each other, > > Events get delivered recursively anyway, so if one area rejects an > event based on velocity or some other property that is out of range, > the other area will get a shot at handling it. But the list could be > treated as an order of precedence. (And I'm not sure that's intuitive > enough, either.) The list of controllers is just a brainstorm, but I > think it will be limiting to say that there is only one controller per > View. Depends how you define "controller" and "view", both things we're trying to define. If is isn't going to be arguably a controller in the classic Model-View-Controller paradigm, I'd prefer a different term to avoid confusion. In the sketchy diagram I had, it was actually supposed to be that kind of controller, if only because MVC is further along in design than our current Views 2 ideas. >> The problem with splitting them up like this has always been about how >> the communication is managed between components without unacceptable >> overhead. The biggest example being how the Instantiator, Layout and >> ViewPort need to work together to determine which items are on screen >> and need delegates. Might even need to also communicate with the >> controller to preload incoming items while scrolling. If everything >> goes through the View, like it seems to in your example, then it's >> still a big monolithic class that knows everything and we've just >> added more customizability to it (which might be enough, I don't >> know). > > Well what architecture did you have in mind? I wasn't able to be at > QtCS, so sorry if it's asking for too much repetition. I agree that > decoupling is good. My point, and this was the same point made at QtCS, is that I don't know what architecture is needed for this. I was so excited to see your mockup, until I realized it's does not appear to be solving this problem. Further research is required. -- Alan Alpert From 416365416c at gmail.com Thu Jul 25 23:55:15 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Thu, 25 Jul 2013 14:55:15 -0700 Subject: [Development] [QtQuick] Mouse/Touch handling from Qt CS In-Reply-To: References: <8D46B42E-44BA-4B91-A9F7-31E4733115F8@digia.com> Message-ID: On Thu, Jul 25, 2013 at 1:23 PM, Shawn Rutledge wrote: > On 25 July 2013 18:06, Alan Alpert <416365416c at gmail.com> wrote: >> On Thu, Jul 25, 2013 at 1:14 AM, Rutledge Shawn >> wrote: >>> >>> On 24 Jul 2013, at 5:45 PM, Alan Alpert wrote: >>> >>>> Qt CS had a discussion on how to handle mouse and touch event >>>> conflicts in QtQuick going forwards. >>>> >>>> An interesting idea came up that the existing model might be >>>> salvageable if we fix multi-cursor support. >>> >>> I suggested that idea 2 years ago, but I was told authoritatively at that time that realistically, Qt will never support multiple cursors, because the idea of a single cursor, single grab, single focus, etc. is so pervasive in Qt. >> >> Two years ago, was capacitive multi-touch an essential feature for >> UIs? > > Yes, it became an essential feature for mobile device UIs suddenly in > 2007. But the point is not whether or not to have multi-touch, but > whether we can pretend that multi-touch and multi-mouse are the same > thing. I don't think we can because > 1) it's the hard way to get there, due to Qt legacy If you know an easy way then you need to tell me now ;) > 2) the use cases aren't really the same > 3) multiple mice implies multiple users, multiple active windows, > multiple focus, etc. Multi-touch is heading in that direction too. Even with a single user, tablets are already at the point where you can have multiple windows on screen at once and so multiple active windows with focus is plausible right now. -- Alan Alpert From simon.lees at codan.com.au Fri Jul 26 04:05:06 2013 From: simon.lees at codan.com.au (Simon Lees) Date: Fri, 26 Jul 2013 11:35:06 +0930 Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <1374763077.64179.YahooMailNeo@web126102.mail.ne1.yahoo.com> References: <2171360.MuxoQFPleD@hal> <51EDD33A.2080603@codan.com.au> <4082192.eQr6N3KKOd@hal> <1374763077.64179.YahooMailNeo@web126102.mail.ne1.yahoo.com> Message-ID: <51F1D952.7010401@codan.com.au> On 07/26/2013 12:07 AM, BogDan wrote: >>> This provides a improvement for me but it is not a complete solution, on >>> android we load libQt5xxx.so my solution as it was still tried to load >>> libQt5xxx.so.5 which doesn't exist as libraries are not symlinked on >>> android like they are on Linux and only libQt5xxx.so is present. >> Then perhaps this is the reason that the variable is simply cleared on >> Android. qmake should probably generate the SONAME without the version on >> android? >> >> Ossi, is that possible? >> >> Thanks, >> > Hello, > > If you are going to roll it back https://codereview.qt-project.org/#change,61330 > a few things will stop to work immediately: > - android qt creator plugin. > - no qt apps will be movable to sdcard (most of the sdcards are fat formated, and it can not have symlinks). > - Ministro needs lots of changes to support symlinks, this is the reason why I choose not to use SONAME. > > There are two ways to have a Qt application on Android, one is to use Ministro to get the libs, and the second one is to bundle Qt libs into the APK. For none of them you don't need to use SONAME. > Personally, I see no reason why should SONAME be used for Android ... > > Thanks, > BogDan. > > P.S. Sorry for slow reply, I didn't see the message until now. > . > Hi, The only reason for it is to fix cmake building. From my testing yes using the normal method to set the SONAME to be libQt5Core.so.5 does break everything but manually setting the SONAME to be libQt5Core.so works, at least for me this is because the java wrapper has already loaded libQt5.core.so before my shared library is loaded and as they have the same name the library is not re loaded. The only other solution is to patch cmake so it doesn't require a SONAME or so that a SONAME can be manually provided. Cheers Simon From oneorjuan at gmail.com Fri Jul 26 10:53:19 2013 From: oneorjuan at gmail.com (Juan Navarro) Date: Fri, 26 Jul 2013 10:53:19 +0200 Subject: [Development] Implementation of qFuzzyCompare and zero values In-Reply-To: <1835204.24oqL4WXeT@tjmaciei-mobl2> References: <1606308.vCyzZRCPom@tjmaciei-mobl2> <51F0D110.90702@familiesomers.nl> <1835204.24oqL4WXeT@tjmaciei-mobl2> Message-ID: On Thu, Jul 25, 2013 at 5:26 PM, Thiago Macieira wrote: > > if ((qFuzzyIsNull(p1) && qFuzzyIsNull(p2)) || qFuzzyCompare(p1, p2)) > > That's exactly like the macro with which I end up "convering" the current Qt implementation. On your first reply, you also said that On Thu, Jul 25, 2013 at 1:19 AM, Thiago Macieira wrote: > > You have to somehow tell qFuzzyCompare about the magnitude of your > comparison. > An error of 1000000 is acceptable when your numbers are in the order of > 1e12. > > ... > > Can't do and won't do that. qFuzzyCompare is meant for non-zero numbers. We > don't want to add the overhead of zero comparisons when the numbers in > question can't be null. > > In my opinion, if a function requires the user to provide a magnitude value (for whatever reason), then that value should be explicitly given in an additional parameter, not implicitly given as an added value to the already given parameters... I think that's a very bad design decision, which finds it's own limitations very fast with the example I gave in the first mail: working with magnitudes of 1e12, I cannot just call qFuzzyCompare(a + 1e12, b + 1e12), because a or b might be -1e12! On the other hand, explicitly not supporting zero values seems to me like a rather arbitrary imposition for a function which compares values. There are so many possible scenarios in which to compare 2 floating-point numbers in which one or both might be "human zero". Temperatures, speeds, weights, coordinates, time-travelling, you name it! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jan.faroe at gmail.com Fri Jul 26 11:01:00 2013 From: jan.faroe at gmail.com (=?windows-1252?Q?Jan_Far=F8?=) Date: Fri, 26 Jul 2013 16:01:00 +0700 Subject: [Development] Puzzled by desktop development priorities, Mac OS specifically Message-ID: Hi all, I posted this on qt-project forums (http://qt-project.org/forums/viewthread/29888/), and was told this mailing list was a better audience. About 2 weeks ago I tried to post the same post as an anonymous user, but it has not yet been handled, hence I decided to become a member of the list. I am in the final stages of rewriting a somehow complex (at least for me) application to Qt from Java Swing. The time has come to focus on UI details, and this is where Qt gives me grey hairs. I started out developing in Qt 4.8, and experienced several issues that didn’t work on the Mac (From the top of my head: Overlays on video widgets), or just looked plain wrong in Mac OS context (For example: Table rows with alternate row colors does not extend to the bottom if only containing a few rows; list view items does not scroll properly if setting an item widget). Hoping that Qt5 would solve some of these problems (apart from reaping benefit from the great added features like JSON and serial device support), I have patiently waited for Qt5 to evolve from beta to 5.1 at the current point. Still, I’m seeing the same issues. Still. On top of that, classes like QtSingleApplication are not yet there. The unified toolbar on the Mac is gone, externalized to qtmacextras, which is still not ready. Compiling the latest version is not possible because of errors. Bottom line is that creating a professionally looking/behaving application on the Mac is not yet possible with Qt 5.1, and not with Qt 4.8 either if requiring certain features – unless you know how to fix the underlying problems, and I certainly don’t. What I struggle to understand is the strategic choices being made by the team responsible. Now, I am in general very happy about Qt, and I am admiring the effort that is being done. I understand that creating a cross platform framework is an incredibly complex task, even more so on the UI side. But – seeing versions for iOS and Android being rolled out, seeing funky demos that obviously takes time and effort to develop (the “Live widgets in Castle Wolfenstein” demo comes to mind), I strongly feel that the development priorities are not balanced – especially having in mind that the project is commercially backed. I do understand that the competition on the mobile market is fierce, and that strategically it’s crucial to roll out support for the mobile platforms as fast as possible. But please, please please… don’t forget the desktop platforms – and don’t forget the Mac. Consolidate the existing platforms, then expand. That would be my strategy; but who am I to say that. Sorry about the rant – however, I doub’t I’m the only one experiencing these frustrations. Is there any timeline of the completion of qtmacextras and QtSingleApplication? Kind regards, Jan Faroe From Jan-Arve.Saether at digia.com Fri Jul 26 12:26:09 2013 From: Jan-Arve.Saether at digia.com (Saether Jan-Arve) Date: Fri, 26 Jul 2013 10:26:09 +0000 Subject: [Development] Implementation of qFuzzyCompare and zero values In-Reply-To: <1835204.24oqL4WXeT@tjmaciei-mobl2> References: <1606308.vCyzZRCPom@tjmaciei-mobl2> <51F0D110.90702@familiesomers.nl> <1835204.24oqL4WXeT@tjmaciei-mobl2> Message-ID: <66BFFE861C7DE34D9B0372D8EAAB18E2BC6281@IT-EXMB01-HKI.it.local> > -----Original Message----- > From: development-bounces+jan-arve.saether=digia.com at qt-project.org > [mailto:development-bounces+jan-arve.saether=digia.com at qt-project.org] > On Behalf Of Thiago Macieira > Sent: 25. juli 2013 17:26 > To: development at qt-project.org > Subject: Re: [Development] Implementation of qFuzzyCompare and zero > values On quinta-feira, 25 de julho de 2013 09:17:36, André Somers > wrote: >> static inline bool qFuzzyComparePossibleNulls(double p1, double p2) { >> if (qFuzzyIsNull(p1)) { >> return qFuzzyIsNull(p2); } else if (qFuzzyIsNull(p2)) { return >> false; } else { return qFuzzyCompare(p1, p2); >> } >> } > > if ((qFuzzyIsNull(p1) && qFuzzyIsNull(p2)) || qFuzzyCompare(p1, p2)) > > If p1 is zero, qFuzzyCompare(p1, p2) will return false unless p2 is > also zero. > > But, no, I think we need something like what Jan-Arve is suggesting. > There is a JIRA suggestion now: https://bugreports.qt-project.org/browse/QTBUG-32632 However, a problem with the return value is that it's not very intuitive to know what distance you want to accept as close enough. I guess we can recommend to test for a value that more or less matches qFuzzyCompare, since it seems to be acceptable for most people. Jan Arve From andre at familiesomers.nl Fri Jul 26 14:32:50 2013 From: andre at familiesomers.nl (=?ISO-8859-1?Q?Andr=E9_Somers?=) Date: Fri, 26 Jul 2013 14:32:50 +0200 Subject: [Development] [QtQuick] Mouse/Touch handling from Qt CS In-Reply-To: References: <8D46B42E-44BA-4B91-A9F7-31E4733115F8@digia.com> Message-ID: <51F26C72.7030303@familiesomers.nl> Op 25-7-2013 18:06, Alan Alpert schreef: >> Ironically it was pointed out again after Doug Englebart's recent passing that from the beginning, he assumed that a multi-user multi-tasking computer would of course require multiple mice, so that each user can interact with objects on the screen independently. 45 years later, we still haven't gotten around to treating that as the mainstream use case. It could be one of the last reasons left to use a desktop or large-screen computer. > Most people seem to have discarded the idea as impractical approx. 45 > years ago. Without a screen the size of a house (which we only just > now have with 4K Projectors), you get in each others way and there > isn't even the physical volume of fingers to help stop that. But my > point is that it's more important for Qt to support the interaction > paradigms that are established in the market, like single cursor and > capacitive multi-touch, than speculative or unpopular models. Those > are just a bonus. > This [1] is a video that shows a research project at Adobe together with a large technology magazine. Unfortunately, the narration is in Dutch, but even if you don't understand that language, the interactions with the UI might give you some idea of when and how multi-user interactions within the same application may be useful. Sure, this is not the main use case yet, but also consider developments like the Surface tables where interaction with multiple users at the same time becomes more and more a realistic option. If even two years ago we'all did not think multitouch a critical feature and realize in what world we live now, then perhaps we should not underestimate the importance of these developments. How can Qt stay relevant if it only begins development of features when they are already mainstream elsewhere? André [1] http://tweakers.net/video/7982/van-de-polder-naar-de-valley-interfaces-ontwerpen-bij-adobe.html -- You like Qt? I am looking for collegues to join me at i-Optics! From Gabriel.deDietrich at digia.com Fri Jul 26 15:24:36 2013 From: Gabriel.deDietrich at digia.com (deDietrich Gabriel) Date: Fri, 26 Jul 2013 13:24:36 +0000 Subject: [Development] QtCS Mac session report Message-ID: <2BEECC92-4C8E-478E-BFCF-EC18E816700C@digia.com> [Sending to the right development mailing list] Hi all, Here come the notes from the Mac session at QtCS. Sorry for being late. This is a copy-paste of http://qt-project.org/groups/qt-contributors-summit-2013/wiki/Qt_Mac_Planning __________________________________________________________________________________________ Minutes from Qt Mac Planning Discussion Qt Contributors’ Summit, June 16, 2013 @ 15.00 Gabriel went through list of outstanding tasks for Mac extras. Action: Make sure that all of them are Jira tasks. (most are) • Accessibility: Crash when resize window, but will anyway not be officially supported until 5.2 • App Store: Problems with having ICU and WebKit Extras: • Embedding NSViews works for simple cases only (not for ScrollView) • Unified ToolBar • use cocoa toolbar: difficult because have to put openGL on top of native toolbar Touch and Gestures • Add scroll bounce – should it be default? probably not for widgets since it is not there now, but can be default for the Qt Quick Controls. Do it “right” for Qt Quick Controls, and then see if want to use the same for Widgets. Extend API to support Qt Quick (QWindow or QQuickView, TBD) – James take a look at how to do it NSView wrapper • NSView in QWindows (main use case is for search fields and buttons) • QMacStyle: Based on Carbon HiTheme • Use NSCell? instead – a bit hackish. • New event dispatcher for Mac. WIP. • Want to merge with the iOS event dispatcher moving on. Deployment: • Should put primary headers directly into the Frameworks. Have been some discussions on the mailing list, but no conclusion. We think it should be described: File a bug. Mac X 10.6 – when to deprecate? • could stop supporting gcc, and clang only • many use it still • might be that it would be helpful when starting to support 10.9 • C++11 not supported in 10.6 • Should deprecate for 5.3, and start warn people with 5.2 release. • Could mean that keep the 10.6 code in a separate QPA plug-in. 10.9 • qtbase works except for plugin • a few crashes related to font selection • should be OK for supporting in Qt 5.2 __________________________________________________________________________________________ Best regards, Dr. Gabriel de Dietrich Senior Software Engineer qt.digia.com From thiago.macieira at intel.com Fri Jul 26 17:39:55 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Jul 2013 08:39:55 -0700 Subject: [Development] Implementation of qFuzzyCompare and zero values In-Reply-To: References: <1835204.24oqL4WXeT@tjmaciei-mobl2> Message-ID: <2259741.4XB83jQ1Gf@tjmaciei-mobl2> On sexta-feira, 26 de julho de 2013 10:53:19, Juan Navarro wrote: > In my opinion, if a function requires the user to provide a magnitude value > (for whatever reason), then that value should be explicitly given in an > additional parameter, not implicitly given as an added value to the already > given parameters... I think that's a very bad design decision, which finds > it's own limitations very fast with the example I gave in the first mail: > working with magnitudes of 1e12, I cannot just call qFuzzyCompare(a + 1e12, > b + 1e12), because a or b might be -1e12! Well, if you want to add a qFuzzyCompare overload with three parameters and deprecate (by documentation only, no Q_DECL_DEPRECATED) the current one, be my guest. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From bog_dan_ro at yahoo.com Fri Jul 26 18:59:06 2013 From: bog_dan_ro at yahoo.com (BogDan) Date: Fri, 26 Jul 2013 09:59:06 -0700 (PDT) Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <51F1D952.7010401@codan.com.au> References: <2171360.MuxoQFPleD@hal> <51EDD33A.2080603@codan.com.au> <4082192.eQr6N3KKOd@hal> <1374763077.64179.YahooMailNeo@web126102.mail.ne1.yahoo.com> <51F1D952.7010401@codan.com.au> Message-ID: <1374857946.9808.YahooMailNeo@web126106.mail.ne1.yahoo.com> >>>>     This provides a improvement for me but it is not a complete > solution, on >>>>     android we load libQt5xxx.so my solution as it was still tried > to load >>>>     libQt5xxx.so.5 which doesn't exist as libraries are not > symlinked on >>>>     android like they are on Linux and only libQt5xxx.so is present. >>> Then perhaps this is the reason that the variable is simply cleared on >>> Android. qmake should probably generate the SONAME without the version > on >>> android? >>> >>> Ossi, is that possible? >>> >>> Thanks, >>> >> Hello, >> >> If you are going to roll it back > https://codereview.qt-project.org/#change,61330 >> a few things will stop to work immediately: >>   - android qt creator plugin. >>   - no qt apps will be movable to sdcard (most of the sdcards are fat > formated, and it can not have symlinks). >>   - Ministro needs lots of changes to support symlinks, this is the reason > why I choose not to use SONAME. >> >> There are two ways to have a Qt application on Android, one is to use > Ministro to get the libs, and the second one is to bundle Qt libs into the APK. > For none of them you don't need to use SONAME. >> Personally, I see no reason why should SONAME be used for Android ... >> >> Thanks, >> BogDan. >> >> P.S. Sorry for slow reply, I didn't see the message until now. >> . >> > Hi, > The only reason for it is to fix cmake building. From my testing yes > using the normal method to set the SONAME to be libQt5Core.so.5 does > break everything but manually setting the SONAME to be libQt5Core.so > works, at least for me this is because the java wrapper has already > loaded libQt5.core.so before my shared library is loaded and as they > have the same name the library is not re loaded. > > The only other solution is to patch cmake so it doesn't require a SONAME > or so that a SONAME can be manually provided. > > Cheers > > Simon > In this case I'll keep my -1 for that patch :) Can't cmake scripts be changed to work with SONAME set to libQt5XXXXX.so ? Cheers, BogDan. From sean.harmer at kdab.com Fri Jul 26 19:31:04 2013 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 26 Jul 2013 18:31:04 +0100 Subject: [Development] Nominating Kevin Ottens as Approver In-Reply-To: <10047846.3fY7jupRTn@varney> References: <10047846.3fY7jupRTn@varney> Message-ID: <51F2B258.9050600@kdab.com> On 23/07/2013 14:11, Frederik Gladhorn wrote: > Hi, > > I would like to nominate Kevin Ottens as approver for the Qt Project. > > Kevin has been working on KDE for a long time and has lately worked hard to > get more patches into Qt especially as part of KDE Frameworks 5. > > You can find him on IRC as "ervin" and he works at KDAB. > > His dashboard: > https://codereview.qt-project.org/#dashboard,1001931 > https://codereview.qt-project.org/#q,owner:Kevin%252BOttens,n,z > > His list of reviews: > https://codereview.qt-project.org/#q,reviewer:Kevin%252BOttens,n,z > > +1 Sean (disclaimer: I work for KDAB too) -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions From thiago.macieira at intel.com Fri Jul 26 20:12:14 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Jul 2013 11:12:14 -0700 Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <1374857946.9808.YahooMailNeo@web126106.mail.ne1.yahoo.com> References: <51F1D952.7010401@codan.com.au> <1374857946.9808.YahooMailNeo@web126106.mail.ne1.yahoo.com> Message-ID: <2661491.1IhcOHBTmk@tjmaciei-mobl2> On sexta-feira, 26 de julho de 2013 09:59:06, BogDan wrote: > In this case I'll keep my -1 for that patch > Can't cmake scripts be changed to work with SONAME set to > libQt5XXXXX.so ? Why don't we do on Android what we do everywhere else? soname: libQt5XXXX.so.5 actual file: libQt5XXXX.so.5 No need to ship the symlink in .apk. It's only necessary in the SDK / sysroot. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From jlayt at kde.org Fri Jul 26 20:33:40 2013 From: jlayt at kde.org (John Layt) Date: Fri, 26 Jul 2013 19:33:40 +0100 Subject: [Development] QtCS - ICU and Localization session Message-ID: Hi, A QtCS session was held to discuss the situation with ICU. No conclusions were made as time ran out, but research tasks were set to narrow the options. Meeting minutes and detailed notes on my research can be found at http://qt-project.org/groups/qt-contributors-summit-2013/wiki/Qt_ICU. What follows is a rather long summary of my thoughts. QDateTime and QTimeZone were also unable to be discussed, a separate email will follow about those. tl;dr: ICU or equivalent native api is available on all platforms, except for Win32, which could be abstracted in a new set of wrapper classes providing a new advanced locale api. A minimum legacy level of support common to all platforms would still be publicly provided by QLocale, including the new calendar and time zone features, using the ICU abstraction layer where available, or a new Win32 backend, to replace the existing locale database and code. The old database could still be available for embedded if required. A build script could be provided to simplify building a minimal required ICU for Win32 apps. I'm working on proof-of-concept code for this and will post code in 2-3 weeks. The original idea was to use ICU on all platforms to have a single locale backend and to remove all the Qt locale data and code, system locale code, and code conversion tables, saving 1-2MB from QtCore and a lot of code maintenance. The primary motivation was to enable advanced features such as calendar systems, time zones and collation without coding them ourselves or shipping the extra 2-6 MB of translations and data required. The real world makes this very hard to do. Problems with ICU itself * ICU does not read the host system data or the user custom settings so a system locale backend is still required * No BC guarantee on C++ api so restricted to using C api which lacks some required features ICU Platform Support * ICU supports all platforms, but not all platforms support ICU at a system-install level, requiring some devs to ship their own copy. * Linux and QNX always have a system library that can always be used. * OSX and iOS have a system library but no headers and linking is banned from the app store. The native api is a thin wrapper around ICU and functionally equvalent. * Windows does not have ICU and the native Win32 api cannot match ICU functionality, but can provide full current QLocale functionality including custom locales and some new functionality such as calendar systems and time zones. * WinRT does not have ICU but the native api is functionally equivalent to ICU as it uses the same data source * Android has ICU4J but not ICU4C by default, although it is 'supported'. The ICU4J data file is a different format and not easily shared with ICU4C. Only native api is POSIX or JNI. A system ICU4C may be added in next version. * Tizen has a system library but no headers and linking is banned from the app store. Native api is not yet known. Not considered for now. ICU Data Size * Current binary download from ICU is 11 MB compressed / 27 MB on disk which is too much for many Windows/iOS/Android devs to distribute * ICU can be shrunk by adding local make files, but knowing which ones to add and how is poorly documented * Data is 80% of ICU, of which 27% is code conversion tables, 27% translations, 10% Collation Rules, 5% Locale formats, and 31% required data * The most common code conversions including UNICODE are done algorithmically, or with small tables, most large tables are EBCDIC or East-Asian, an expert needs to review what we really need * ICU translations support +/-300 language variants which most apps will not need, much of this data is unnecessary and can be disabled while still shipping the full set of locale formats * Build switches reduce the library size if features are not required, but the savings are not significant * A typical custom build for all features but only a dozen supported European languages might be 6 MB compresssed / 12 MB on disk QtWebKit * Hard dependency on ICU for localization, code conversion tables, text boundary analysis, etc * WebKit has an abstraction api for host system localization but no-one uses it, only ICU backend implemented * Only way to remove ICU dependency is to write our own backend which is a lot of work. A primary motivation to move away from WebKit is to avoid maintaining our own backends * Chromium always builds and ships their own copy of ICU on all platforms In summary: Linux, QNX, Mac, iOS, WinRT and Android (assuming JNI is performant enough) all provide *system* level ICU or native ICU-equivalent implementations that can be abstracted in a new locale api, only Win32 does not. Even then, any Win32 app needing QtWebKit will also have ICU availble. It seems perverse to restrict all other platforms from accessing what their native api provides simply because Win32 has some limitations. At the very least, we could be using this abstraction layer as the QLocale backend for system and custom locales where available, saving shipping the current database ourselves on most platforms. After looking more at the Win32 api, I think I can use it to provide not just the system locale but also the custom locales for all existing QLocale features and for the required new features such as calendar systems and time zones. Collation I still need to investigate. This would allow us to replace the existing Qt backend on Windows as well. We could effectively have a compile-time choice of 4 backends for QLocale: ICU-equivalent, Win32, old Qt database, and C. I also think it should be straightforward to add a buildscript to 3rdparty that simplifies building a minimal required ICU for those Win32 apps that want it, i.e. read a config file for language translations required, read the Qt config flags for features required, download the source, create the required make files, then configure and build. This solution makes QLocale the "legacy" locale api which we guarantee to apps is available and fully-functional on all platforms, which should be all most apps will need, and provide a new advanced api for those apps that need it. We would then have the choice of either only exporting the new classes on ICU-equivalent platorms, or always exporting it but with reduced functionality on Win32. This really is the main contentious point and I'd like people's opinions on it: * Having platform-dependent api is not very desirable, but here it is mitigated by being entire classes rather than methods, and only on Win32 where shared Qt installs are uncommon. * Having a partly functional api could lead to bad user experiences, but there is a precedent for this with QCollator which needs ICU to actually do anything, on Mac/Win32 it does nothing. It's safer. * We could wait and see exactly what Win32 cannot provide before deciding I know there was some opposition to having new locale classes, but there's a number of good reasons to not add large chunks of new api to QLocale: * QLocale already has a fairly big api which has grown organically so is somewhat inconsistent with itself, adding a lot more api that works differently will just add to the confusion * The monolithic design is at odds with the native api for Mac, ICU, WinRT, .Net, Java and others where separate classes for number formatters, date formatters, collators and calendars are the norm and so familiar to devs. * Mapping the separate ICU and Mac classes to QLocale will be messy enough, it is a lot easer and cleaner to have wrapper classes abstracting and managing each formatter, and we might as well make those classes public * It makes it clear that the new locale stuff may work differently to the old api, e.g. date format codes, default settings, etc I've started work on refactoring QLocale and my existing ICU api code to try make this work and should have a working proof-of-concept in a couple of weeks. At the very least, even without making the new classes public this should result in a cleaner QLocale, an ICU backend for use on Linux and QNX, improved Mac and Win32 support and smaller library size on most platforms. Thoughts? John. From lpapp at kde.org Fri Jul 26 20:35:14 2013 From: lpapp at kde.org (Laszlo Papp) Date: Fri, 26 Jul 2013 19:35:14 +0100 Subject: [Development] Bug management and jira workflow In-Reply-To: <201307231325.44951.jedrzej.nowacki@digia.com> References: <201307231325.44951.jedrzej.nowacki@digia.com> Message-ID: Nice session. Unfortunately, I was attending to something else in parallel. Have you discussed the "triage bugs" documentation to be written in there? As for me, that seems to have been a long standing issue on the contribution wiki page: http://qt-project.org/contribute Just happened to me today that I was trying to help someone to close a bug as fixed after a request on IRC, but I was being unsure what the best workflow for that. This is just a practical example. On Tue, Jul 23, 2013 at 12:25 PM, Jedrzej Nowacki wrote: > Hi, > > > At the Qt Contributor Summit, we had a really good discussion about bugs > and > jira, here is the summary: > > > - We have untriaged bugs, we may not be able to triage them all, but we > should keep it’s count as low as possible. > > - We agreed on “triaging” definition. Triaging consist of: > - checking if a bug report is sensible. It means the reported issue is > not > a result of a user mistake, use of undefined behavior etc. > - checking if a bug report is not missing an important data, so it > would > be possible to reproduce it in future > - setting a priority > - optionally the bug report may be verified. It it is reproduced then > it > should be accept which means moved to open state > Rationale: It looks like the most common behavior of people triaging > bugs. > > - Who can prioritize bugs? > - whoever ask > - we will create a special group in jira > - approvers should be in the group by default > Rationale: We do not have man power and we need help. We do not expect > anyone to destroy our precious bugs reports or play “ping pong” with a > priority. > > - What does it mean “fixed version” in bug report > - we do not fill it until an issue is really fixed, which means merged > - we do not want to use the field for estimation > - we know that it can be filled automatically, it would be nice to > implement that. > > - Jira workflow was designed for much bigger team, that includes QA > department, it should be simplify > - We decided that “in progress” state means that someone started work > on a > bug or it have a fix which is not merged yet. Time statistics doesn’t show > anything, anyway. > - Resolved, Verified and Closed should be merged to a single state. > Nobody > is going through Resloved bugs to verify them. > - It would be nice to have a transition from Open to Closed state > > > Cheers, > Jędrek > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bog_dan_ro at yahoo.com Fri Jul 26 21:10:59 2013 From: bog_dan_ro at yahoo.com (BogDan) Date: Fri, 26 Jul 2013 12:10:59 -0700 (PDT) Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <2661491.1IhcOHBTmk@tjmaciei-mobl2> References: <51F1D952.7010401@codan.com.au> <1374857946.9808.YahooMailNeo@web126106.mail.ne1.yahoo.com> <2661491.1IhcOHBTmk@tjmaciei-mobl2> Message-ID: <1374865859.88029.YahooMailNeo@web126104.mail.ne1.yahoo.com> >> In this case I'll keep my -1 for that patch >> Can't cmake scripts be changed to work with SONAME set to >> libQt5XXXXX.so ? > > Why don't we do on Android what we do everywhere else? > >     soname: libQt5XXXX.so.5 >     actual file: libQt5XXXX.so.5 > > No need to ship the symlink in .apk. It's only necessary in the SDK / > sysroot. > Because a few things will still stop to work (e.g. qtc android plugin) :) . Also AFAIK everywhere else libQt5XXXX.so.5 is a symlink to libQt5XXXX.so.5.major which is a symlink to libQt5XXXX.so.5.major.minor . If you don't plan to ship libQt5XXXX.so.5.major.minor and we don't use symlinks, then personally I don't see any reason to add an extra .5 to the end of the file name as long as the file name already contains a 5 ... Anyway if I'm the only one that is against this patch I'll change my score to 0 (or +x). But before that I'd like to see at least qtc android plugin working properly with this patch. Cheers, BogDan. From thiago.macieira at intel.com Fri Jul 26 21:23:43 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Jul 2013 12:23:43 -0700 Subject: [Development] QtCS - ICU and Localization session In-Reply-To: References: Message-ID: <1388137.CDGnYbBQ3E@tjmaciei-mobl2> On sexta-feira, 26 de julho de 2013 19:33:40, John Layt wrote: > I've started work on refactoring QLocale and my existing ICU api code > to try make this work and should have a working proof-of-concept in a > couple of weeks. At the very least, even without making the new > classes public this should result in a cleaner QLocale, an ICU backend > for use on Linux and QNX, improved Mac and Win32 support and smaller > library size on most platforms. > > Thoughts? Thanks for the braindump and analysis, John. It's appreciated. I find myself agreeing with almost everything you said. The one thing I disagree with is maintaining our old database in Qt. Past experience teaches us that anything but the default build will bitrot and will be hard to maintain. It hasn't been one year that we started using ICU instead of iconv and the iconv code already has shown build issues every now and then -- and no one knows whether iconv on Windows is supposed to work. So I would request that we seriously consider deprecating and later dropping completely our own database. I would put the implementation on two levels: 1) baseline and mandatory: system/user config backends: POSIX, Win32, OS X, BB services, whatever Android uses (the first four are already present, the POSIX one needs work) 2) database support (optional) backends: ICU, OS X's ICU wrapper, Win32, ICU4J via JNI The first level is the implementation that gives the application access to the user's current locale settings. For the overwhelming majority of applications, that's actually quite acceptable: users don't often run applications in different languages than their OS, or parts of the application. In turn, it takes the burden off the backends for the second level. If the ICU4J backend (for example) is missing or slow, it won't be a big deal. That would leave us with the task of implementing a very good "system/user config" module. That would also mean bringing the iconv converter back to working condition. The one problem I see is QCollator. I don't see the baseline implementation providing enough data for us to implement said class. I'll be happy to be proven wrong, though. But if I'm right, my suggestion is to remove this class from QtCore -- it's still private and not used anywhere. We can provide it elsewhere and make the ICU dependency explicit there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Fri Jul 26 21:26:16 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Jul 2013 12:26:16 -0700 Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <1374865859.88029.YahooMailNeo@web126104.mail.ne1.yahoo.com> References: <2661491.1IhcOHBTmk@tjmaciei-mobl2> <1374865859.88029.YahooMailNeo@web126104.mail.ne1.yahoo.com> Message-ID: <1619673.m5XrdFK8Do@tjmaciei-mobl2> On sexta-feira, 26 de julho de 2013 12:10:59, BogDan wrote: > >> In this case I'll keep my -1 for that patch > >> > >> Can't cmake scripts be changed to work with SONAME set to > >> libQt5XXXXX.so ? > > > > Why don't we do on Android what we do everywhere else? > > > > soname: libQt5XXXX.so.5 > > actual file: libQt5XXXX.so.5 > > > > No need to ship the symlink in .apk. It's only necessary in the SDK / > > sysroot. > > Because a few things will still stop to work (e.g. qtc android plugin) :) . A Qt Creator plugin is not an argument, since we can fix the plugin :-) > Also AFAIK everywhere else libQt5XXXX.so.5 is a symlink > to libQt5XXXX.so.5.major which is a symlink to libQt5XXXX.so.5.major.minor > . If you don't plan to ship libQt5XXXX.so.5.major.minor and we don't use > symlinks, then personally I don't see any reason to add an extra .5 to the > end of the file name as long as the file name already contains a 5 ... Right. libQt5XXXX.so.5 -> libQt5XXXX.so.5.x.y. Is there a restriction in shipping the symlinks in .apk? Anyway, the advantage is that we don't have to fix qmake and cmake and everything else that assume that there is a soname, and computes that soname. Instead of making Android different and then adding more conditionals, we should make Android more similar. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From jlayt at kde.org Fri Jul 26 22:26:04 2013 From: jlayt at kde.org (John Layt) Date: Fri, 26 Jul 2013 21:26:04 +0100 Subject: [Development] QtCS - QDateTime changes Message-ID: Hi, As was unable to be discussed at QtCS due to running out of time, I've gotten back on to my QTimeZone changes, but taking a slightly different approach to getting them integrated for 5.2. The QTimeZone class itself works fine, the issue I hit before 5.1 was getting QDateTime to properly deal with the daylight saving transitions, a problem common with the existing Qt::LocalTime implementation. Rather than try deal with the two issues in parallel I've decided to fix QDateTime first, then integrate QTimeZone. I've also decided to start pushing smaller commits to make it easier for people to review what I'm doing :-) The result should be that the QTimeZone integration step requires fewer changes to QDateTime itself. My plan looks something like: * Push existing OffsetFromUTC and date formatter fixes * Make the required changes to fix Qt::LocalTime at the daylight time transitions * Integrate the existing QTimeZone implementation The big problems come from the required changes to fix Qt::LocalTime at the transitions. There are two issues here: * Transition from standard to daylight leaves a 1 hour 'hole', i.e. going forward from 2am to 3am means 2:30am doesn't exist * Transition from daylight to standard repeats a 1 hour period, i.e. going back from 3am to 2am means 2:30am occurs twice Currently Qt::LocalTime ignores both problems and pretends they don't exist. The missing hour is treated as a valid time, and the second occurrence can only be set or read using the actual MSecsSinceEpoch value. We need to change to the correct behaviour for both these situations. Current QDateTime behaviour: * QDateTime uses a lazy initialization that accepts any date, time and spec, validity is only checked when used * When called QDateTime::isValid() does not take the time zone into account, it only checks if QDate and QTime are individually valid, i.e. it doesn't check if the time falls in the 'hole' * Date-only math functions (add day/month/year) are passed straight to QDate, i.e. validity check and maths applied is on date only and doesn’t consider time and time zone, i.e. if the result falls into the hole or is first or second occurrence. * Time math functions work correctly by checking QDateTime::isValid() first and then converting to UTC to calculate To fix the 'hole' problem we have to ensure validity is checked properly every time: * QDateTime::isValid() must check if valid in tz, i.e. call mktime the first time called then cache result in QDateTimePrivate::Spec * All date-only maths needs to be converted to UTC first then converted back, same as for time maths, but this will be a behaviour change To fix the occurrence problem will require new api to allow it to be set and read, which was previously designed for QTimeZone. Issues with mktime having different behaviour on different platforms will make the implementation rather tricky. Linux assumes an ambiguous time is the first occurrence, Windows assumes it is the second occurrence, and Mac assumes first occurrence for about the first 40 minutes and second occurrence for the last 20 minutes (probably a bug). It has been discussed to re-write QDateTime to internally store as an absolute msecs since epoch which would inherently fix these issues and greatly simplify the maths and conversion code, but this would radically change the behaviour of QDateTime which currently treats the ymd/hms values as “fixed” and the time spec is used to interpret that value. This would mostly affect the default Qt::LocalTime spec where the system time zone can change underneath QDateTime causing the absolute UTC value to change. There is also the behaviour that you can store an invalid date but valid time in QDateTime, and later fix the date to be valid. Considerable special case code could be required to keep consistent with the current behaviour. Other likely effects would be: * Creation would be slower as has to validate and convert first * Accessing date() and time(), probably the most commonly used functions e.g. to get day() or hour(), would be slower, but we want to deprecate these anyway and use QCalendarSystem instead which would probably work faster with it * Maths and conversion functions would be faster and simpler and more accurate * Would only need a qint64 instead of a qint64 and a qint32 so saving memory * Would reduce the historic supported date range, but QDateTime is only promised to be useful from 1970 onwards anyway For now I will stick with cleaning up the current QDateTime code and only consider the re-write scenario if that doesn't work. With regards to the ICU situation, QTimeZone already has an ICU backend, but also system backends for Mac, Win32, and the standard tz file. Currently it only uses ICU if QT_USE_ICU is set and it is not on UNIX, but this can change as I'm considering a QT_USE_ICU_TZ option. In fact it provides the model for how the planned new locale classes will work. Cheers! John. From thiago.macieira at intel.com Fri Jul 26 22:37:01 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Jul 2013 13:37:01 -0700 Subject: [Development] QtCS - QtCore discussion Message-ID: <1760330.4B6h5S9QeF@tjmaciei-mobl2> Notes are at http://qt-project.org/groups/qt-contributors-summit-2013/wiki/QtCore_CS_2013 This is a summary of the important topics. For more info, please refer to the wiki. - QFileSelector: I asked Alan to finish discussing it during Akademy with the KDE / Plasma folks, then submit for 5.2. I will review for syntactic correctness, but the API will be up to Alan. - kernel: need to finish converting QMetaType from the "static" API to the "staticless" API, to remove code duplication due to template bloat. - kernel: would be nice to research what we'd need from the C++ language to make this work better, and submit to the standards committee. - kernel: generalise the connection API. Main use-case: QTimer::singleShot. - exception-safety: we discussed a bit and we ended up concluding that: => we will roll back exception safety support in all of Qt <= that is, we will stop promising any level of exception safety, even in the tools classes. - calendaring, timezone, unicode and ICU: please see John's post. - threading: we need to improve the API. We have some contributions from Jabot pending. We discussed that we need to document what our currently-recommended solutions are, so we find out what we're bad at, and then design an API to solve those needs. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Fri Jul 26 22:39:14 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Jul 2013 13:39:14 -0700 Subject: [Development] QtCS - QtDBus discussion Message-ID: <6676314.eEVX7OCQ0t@tjmaciei-mobl2> This is a simple copy & paste from the wiki page, since the topic is fairly short. See http://qt-project.org/groups/qt-contributors-summit-2013/wiki/QtDBus_CS h1. QtDBus module discussions at Qt Contributor Summit 2013 Topics for discussion: * Rewriting the engine: ** Dropping the libdbus-1 dependency ** Moving the connection handling to a dedicated thread ** Adding support for kdbus * kdbus overview Discussion: # Take ahartmetz's marshaller/demarshaller and put on top of QtDBus & libdbus-1 # Moving the handling to a thread # Handling our own socket #* Remember the specifics about sockets on Windows # Adding kdbus compatibility * Generator in QtDBus generates synchronous property get and set ** QtDBus should discourage sync calls more ** For properties, we could add new API that is async (returns QDBusPendingReply and QDBusPendingReply) * There is no error-checking in qdbus_cast (from variants) ** No way to distinguish a T() returned from qdbus_cast() as empty or as error * Parse documentation annotations and generate documentation in the Interface and Adaptors? * Investigate the type system used by Telepathy * Update documentation about supporting multiple platforms (specifically, Windows) ** Right now, it says it's Unix-only ** Would be nice to have better tutorials too -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From nicolas.alvarez at gmail.com Fri Jul 26 23:19:26 2013 From: nicolas.alvarez at gmail.com (=?UTF-8?Q?Nicol=C3=A1s_Alvarez?=) Date: Fri, 26 Jul 2013 18:19:26 -0300 Subject: [Development] Is Xlib a hard requirement for Qt5 xcb? Message-ID: Hi everyone, I attempted to build Qt5 and KF5 in a minimal system, only installing dependencies when configure/cmake asks for them, in order to find bugs (such as missing dependency checks) in the build system. I was successful, in the sense that I found missing checks :) I'm configuring Qt with the options suggested in the KF5 wiki: ./configure -prefix $PWD/qtbase -opensource -developer-build -nomake tests -nomake examples -dbus -no-separate-debug-info -xcb -qpa xcb -no-gtkstyle -no-pch My minimal system does not have X11 development files (such as Xlib.h), but it does have XCB stuff. Compilation fails with: make[2]: Entering directory `/home/nicolas/src/qt5/qtbase/src/widgets' util/qsystemtrayicon_x11.cpp:60:22: fatal error: X11/Xlib.h: No such file or directory make[2]: Leaving directory `/home/nicolas/src/qt5/qtbase/src/widgets' make[5]: Entering directory `/home/nicolas/src/qt5/qtbase/src/plugins/platforms/xcb' qxcbmime.cpp:49:23: fatal error: X11/Xutil.h: No such file or directory qxcbcursor.cpp:52:28: fatal error: X11/cursorfont.h: No such file or directory qxcbxsettings.cpp:46:36: fatal error: X11/extensions/XIproto.h: No such file or directory make[5]: Leaving directory `/home/nicolas/src/qt5/qtbase/src/plugins/platforms/xcb' The question is: is Qt5/XCB *supposed* to work without Xlib? I got the feeling that there was some attempt to make it work, since some code is protected with #ifdef XCB_USE_XLIB checks (though perhaps that define is for something else?). If supposed to work, then it's currently broken and likely needs some more ifdefs. If not supposed to work, then the configure script should abort Xlib isn't present while configuring for XCB. I'm interested in fixing it either way, but I can't take the decision of what's supported :) -- Nicolás From olivier at woboq.com Fri Jul 26 23:48:47 2013 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 26 Jul 2013 23:48:47 +0200 Subject: [Development] QtCS - QObject discussion Message-ID: <11956916.eUnHlRGgNd@gargamel> This is a summary of what's written there: https://qt-project.org/groups/qt-contributors-summit-2013/wiki/QObject - As it was decided in the QtCore discussion, new features may require C++11 - We want to add an overload of QObject::connect that takes both a pointer to a "receiver" and a simple functor (as opposed to a pointer to member function) Use case is to have automatic disconnection of connections to lambda functions, and also be able to use thread affinity and QueuedConnection. Dario Freddi said he will have a look. - We discussed ways to extent the QTimer::singleShot or such function that take a slot as a char*. One could either implement a QSlot<> class: void QTimer::singleShot(int timeout, QSlot slot); Or, alternatively, we add two templates overload, with some helper code in the QtPrivate namespace to make the implementation easy. - We talked about QMetaObject::invokeMethod. t would be nice to add: void QMetaObject::queuedInvoke(QObject, Ret(T::*)(Args…), Args…) Ret QMetaObject::blockingQueuedInvoke(QObject, Ret(T::*)(Args…), Args…) - Support in moc for templated QObject: We need to investigate what are the use cases to see what kind of features we want to support or not. (Not to open too many cans of worms) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From frederik.gladhorn at digia.com Sat Jul 27 10:24:48 2013 From: frederik.gladhorn at digia.com (Frederik Gladhorn) Date: Sat, 27 Jul 2013 10:24:48 +0200 Subject: [Development] QtCS Mac session report In-Reply-To: <2BEECC92-4C8E-478E-BFCF-EC18E816700C@digia.com> References: <2BEECC92-4C8E-478E-BFCF-EC18E816700C@digia.com> Message-ID: <1924044.kAk3SUtRmG@varney> Fredag 26. juli 2013 13.24.36 skrev deDietrich Gabriel: > [Sending to the right development mailing list] > > Hi all, > > Here come the notes from the Mac session at QtCS. Sorry for being late. This > is a copy-paste of > http://qt-project.org/groups/qt-contributors-summit-2013/wiki/Qt_Mac_Planni > ng > ___________________________________________________________________________ > _______________ > > Minutes from Qt Mac Planning Discussion > > Qt Contributors’ Summit, June 16, 2013 @ 15.00 > > Gabriel went through list of outstanding tasks for Mac extras. > Action: Make sure that all of them are Jira tasks. (most are) > > • Accessibility: Crash when resize window, but will anyway not be > officially supported until 5.2 I'd like to have more info here, where's the bug report? -- Best regards, Frederik Gladhorn Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com From andre at familiesomers.nl Sat Jul 27 11:36:56 2013 From: andre at familiesomers.nl (Andre Somers) Date: Sat, 27 Jul 2013 11:36:56 +0200 Subject: [Development] API for multiple (but variable number of) return arguments Message-ID: <51F394B8.6030006@familiesomers.nl> Hi, It has been quite awhile, but I'd like to finally pick up QTimeSpan again and this time really get it into Qt. The idea of this class is that it represents a duration of time, optionally anchored to a point in time, and can output and parse this data to and from strings in different formats, including using 'natural' units like years or months for long time spans. One of the thing I'd like to do is shrink and simplify the API before submitting it. It is not the idea of QTimeSpan in itself that I'd like to discuss, but one API issue I'm currently looking at. For the sake of discussion, let's assume that we have the following already: namespace Qt { enum TimeSpanUnit { Years = 0x01, Months = 0x02, Weeks = 0x04, Days = 0x08, Hours = 0x10, Minutes = 0x20, Seconds = 0x40, MilliSeconds = 0x80 }; Q_DECLARE_FLAGS(TimeSpanFormat, TimeSpanUnit); }; In order to get a time span in the units that you'd like to use, you need a function that can somehow return the values for all these units at the same time, because in order to calculate the number of days, you also need to know if the user also requested the number of weeks (compare "23 days" with "3 weeks, 2 days"). Ideally, there would be a return value as well to indicate success or failure, because time spans without an anchor date cannot be expressed as months or years. There are several ways to write a (member) function to do this. This is what I came up with so far: 1) pointers to ints bool getUnits(int* years, int* monts = 0, int* weeks = 0, int* days = 0, int* hours = 0, int* minutes = 0, int* seconds = 0, int* milliSeconds = 0); Every argument may be 0, in which case this unit is considered as not-used. This works (I have this in the current version of QTimeSpan), but it is not a very nice API to work with. If you're interested in minutes and seconds, you end up with a call like this: int minutes, seconds; if (getUnits(0,0,0,0,0, &minutes, &seconds)) { ...} 2) returning a map QMap getUnits(Qt::TimeSpanFormat); In this case, the units to use are encoded in a single flag, and the result is a single data structure. I guess the easiest way to return failure is to return an empty map. The equivalent call from the first option would look like: int minutes, seconds; QMap result = getUnits(Qt::Minutes | Qt::Seconds); if (!result.isEmpty()) { minutes = result.value(Qt::Minutes); seconds = result.value(Qt::Seconds); }; In my opinion, not all that great either, but better than 1). It may be a benefit to have the results in a data structure that's easy to pass along in one go, but if you don't want that, getting them out is a bit of a hassle perhaps. 3) QString::arg like API An interesting option is to do something like this: int minutes, seconds; if ( getUnits().unit(Qt::Minutes, minutes).unit(Qt::Seconds, seconds) ) { //blah }; Downside is that it allows specifying the same unit multiple times. That does not need to be a real problem (simply return the same value more than once), but it may look weird. Also, this API is implementation wise quite a bit more complex than the previous options. The resulting code is more verbose than option 1, but much easier to read. 4) separate requests Another option is not return all relevant units in one go, but to use multiple function calls: int getUnit(Qt::TimeSpanFormat format, Qt::TimeSpanUnit unit); Failure would return -1. The example would yield: Qt::TimeSpanFormat format = Qt::Minutes | Qt::Seconds; int minutes = getUnit(format, Qt::Minutes); int seconds = getUnit(format, Qt::Seconds); if (minutes >= 0 && seconds >=0) { //blah } Downside is that in order to make this efficient, you'd need to cache the result, otherwise you have to reconstruct it for every call with the same format. Personally, I don't like having to make multiple function calls to retrieve parts of the same answer. Also, there are opportunities for errors here, such as asking for units that are not in the format. I guess there are more options, but these four are the more serious candidates I could come up with. Did I overlook a good candidate? Where are other examples in the Qt API where there were similar needs, so I can look if their patterns may apply here? Anyway, I am looking for feedback. Say that this will be included in Qt some day, what is the most Qt-like API in your opinion? André From contact at philipashmore.com Sat Jul 27 14:05:12 2013 From: contact at philipashmore.com (Philip Ashmore) Date: Sat, 27 Jul 2013 13:05:12 +0100 Subject: [Development] API for multiple (but variable number of) return arguments In-Reply-To: <51F394B8.6030006@familiesomers.nl> References: <51F394B8.6030006@familiesomers.nl> Message-ID: <51F3B778.6060104@philipashmore.com> Hi there. On 27/07/13 10:36, Andre Somers wrote: > Hi, > > It has been quite awhile, but I'd like to finally pick up QTimeSpan > again and this time really get it into Qt. The idea of this class is > that it represents a duration of time, optionally anchored to a point in > time, and can output and parse this data to and from strings in > different formats, including using 'natural' units like years or months > for long time spans. One of the thing I'd like to do is shrink and > simplify the API before submitting it. > > It is not the idea of QTimeSpan in itself that I'd like to discuss, but > one API issue I'm currently looking at. > > For the sake of discussion, let's assume that we have the following already: > namespace Qt { > enum TimeSpanUnit { > Years = 0x01, > Months = 0x02, > Weeks = 0x04, > Days = 0x08, > Hours = 0x10, > Minutes = 0x20, > Seconds = 0x40, > MilliSeconds = 0x80 > }; > Q_DECLARE_FLAGS(TimeSpanFormat, TimeSpanUnit); > }; > > In order to get a time span in the units that you'd like to use, you > need a function that can somehow return the values for all these units > at the same time, because in order to calculate the number of days, you > also need to know if the user also requested the number of weeks > (compare "23 days" with "3 weeks, 2 days"). Ideally, there would be a > return value as well to indicate success or failure, because time spans > without an anchor date cannot be expressed as months or years. > > There are several ways to write a (member) function to do this. This is > what I came up with so far: > > 1) pointers to ints > bool getUnits(int* years, int* monts = 0, int* weeks = 0, int* days = 0, > int* hours = 0, int* minutes = 0, int* seconds = 0, int* milliSeconds = 0); You could wrap this into a struct: struct TimeSpanResult { int m_years, m_months, m_weeks, m_days, m_hours, m_minutes, m_seconds, m_milliseconds; }; and return it from the call: TimeSpanResult getUnitsTimeSpan(Qt:Minutes | Qt:Seconds); I just used a different name as the return type can't be overloaded. TimeSpanResult getUnitsTimeSpan(int flags) { TimeSpanResult res; getUnits((flags & Qt:Years) ? & res.m_years : (int *)0, (flags & Qt:Years) ? & res.m_months : (int *)0, ... return res; } I've left out error checking for clarity. > > > Every argument may be 0, in which case this unit is considered as > not-used. This works (I have this in the current version of QTimeSpan), > but it is not a very nice API to work with. If you're interested in > minutes and seconds, you end up with a call like this: > > int minutes, seconds; > if (getUnits(0,0,0,0,0, &minutes, &seconds)) > { ...} > > 2) returning a map > QMap getUnits(Qt::TimeSpanFormat); > > In this case, the units to use are encoded in a single flag, and the > result is a single data structure. I guess the easiest way to return > failure is to return an empty map. The equivalent call from the first > option would look like: > > int minutes, seconds; > QMap result = getUnits(Qt::Minutes | Qt::Seconds); > if (!result.isEmpty()) { > minutes = result.value(Qt::Minutes); > seconds = result.value(Qt::Seconds); > }; > > In my opinion, not all that great either, but better than 1). It may be > a benefit to have the results in a data structure that's easy to pass > along in one go, but if you don't want that, getting them out is a bit > of a hassle perhaps. > > 3) QString::arg like API > An interesting option is to do something like this: > > int minutes, seconds; > if ( getUnits().unit(Qt::Minutes, minutes).unit(Qt::Seconds, seconds) ) { > //blah > }; > > Downside is that it allows specifying the same unit multiple times. That > does not need to be a real problem (simply return the same value more > than once), but it may look weird. Also, this API is implementation wise > quite a bit more complex than the previous options. The resulting code > is more verbose than option 1, but much easier to read. > > 4) separate requests > Another option is not return all relevant units in one go, but to use > multiple function calls: > int getUnit(Qt::TimeSpanFormat format, Qt::TimeSpanUnit unit); > > Failure would return -1. The example would yield: > > Qt::TimeSpanFormat format = Qt::Minutes | Qt::Seconds; > int minutes = getUnit(format, Qt::Minutes); > int seconds = getUnit(format, Qt::Seconds); > if (minutes >= 0 && seconds >=0) { > //blah > } > > Downside is that in order to make this efficient, you'd need to cache > the result, otherwise you have to reconstruct it for every call with the > same format. Personally, I don't like having to make multiple function > calls to retrieve parts of the same answer. Also, there are > opportunities for errors here, such as asking for units that are not in > the format. > > I guess there are more options, but these four are the more serious > candidates I could come up with. Did I overlook a good candidate? Where > are other examples in the Qt API where there were similar needs, so I > can look if their patterns may apply here? > > Anyway, I am looking for feedback. Say that this will be included in Qt > some day, what is the most Qt-like API in your opinion? > > André > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Regards, Philip Ashmore From andre at familiesomers.nl Sat Jul 27 14:55:55 2013 From: andre at familiesomers.nl (Andre Somers) Date: Sat, 27 Jul 2013 14:55:55 +0200 Subject: [Development] API for multiple (but variable number of) return arguments In-Reply-To: <51F3B778.6060104@philipashmore.com> References: <51F394B8.6030006@familiesomers.nl> <51F3B778.6060104@philipashmore.com> Message-ID: <51F3C35B.3050800@familiesomers.nl> Hi, Op 27-7-2013 14:05, Philip Ashmore schreef: > Hi there. > > On 27/07/13 10:36, Andre Somers wrote: >> 1) pointers to ints >> bool getUnits(int* years, int* monts = 0, int* weeks = 0, int* days = 0, >> int* hours = 0, int* minutes = 0, int* seconds = 0, int* milliSeconds = 0); > You could wrap this into a struct: > struct TimeSpanResult { > int m_years, m_months, m_weeks, m_days, m_hours, m_minutes, > m_seconds, m_milliseconds; > }; > > and return it from the call: > TimeSpanResult getUnitsTimeSpan(Qt:Minutes | Qt:Seconds); > > I just used a different name as the return type can't be overloaded. > > > TimeSpanResult getUnitsTimeSpan(int flags) > { > TimeSpanResult res; > getUnits((flags & Qt:Years) ? & res.m_years : (int *)0, (flags & > Qt:Years) ? & res.m_months : (int *)0, ... > return res; > } > I've left out error checking for clarity. Thanks for your suggestion. It is almost the same as option 2, only you replaced the map with a purpose-made struct. I think that indeed that might be beneficial to do. Note that the different name is not needed; I'd like to only expose *one* API for this, and not multiple different ones. If I'd choose your suggestion, there would be no name clashes with other functions doing the same thing. In this case, there would be no clash either, as the arguments are different as well as the return type. André From contact at philipashmore.com Sat Jul 27 23:28:25 2013 From: contact at philipashmore.com (Philip Ashmore) Date: Sat, 27 Jul 2013 22:28:25 +0100 Subject: [Development] API for multiple (but variable number of) return arguments In-Reply-To: <51F3C35B.3050800@familiesomers.nl> References: <51F394B8.6030006@familiesomers.nl> <51F3B778.6060104@philipashmore.com> <51F3C35B.3050800@familiesomers.nl> Message-ID: <51F43B79.8010108@philipashmore.com> On 27/07/13 13:55, Andre Somers wrote: > Hi, > > Op 27-7-2013 14:05, Philip Ashmore schreef: >> Hi there. >> >> On 27/07/13 10:36, Andre Somers wrote: >>> 1) pointers to ints >>> bool getUnits(int* years, int* monts = 0, int* weeks = 0, int* days = 0, >>> int* hours = 0, int* minutes = 0, int* seconds = 0, int* milliSeconds = 0); >> You could wrap this into a struct: >> struct TimeSpanResult { >> int m_years, m_months, m_weeks, m_days, m_hours, m_minutes, >> m_seconds, m_milliseconds; >> }; >> >> and return it from the call: >> TimeSpanResult getUnitsTimeSpan(Qt:Minutes | Qt:Seconds); >> >> I just used a different name as the return type can't be overloaded. >> >> >> TimeSpanResult getUnitsTimeSpan(int flags) >> { >> TimeSpanResult res; >> getUnits((flags & Qt:Years) ? & res.m_years : (int *)0, (flags & >> Qt:Years) ? & res.m_months : (int *)0, ... >> return res; >> } >> I've left out error checking for clarity. > Thanks for your suggestion. It is almost the same as option 2, only you > replaced the map with a purpose-made struct. I think that indeed that > might be beneficial to do. > > Note that the different name is not needed; I'd like to only expose > *one* API for this, and not multiple different ones. If I'd choose your > suggestion, there would be no name clashes with other functions doing > the same thing. In this case, there would be no clash either, as the > arguments are different as well as the return type. Sorry for mylack of clarity. I'm not developing Qt code at the minute and forgot about the Qt way of passing flags. The clash is with QMap getUnits(Qt::TimeSpanFormat); QTimeSpanResult getUnits(Qt::TimeSpanFormat); would clash. Also, the proposal I'm making is an inline wrapper for option 1, so the compiler would eliminate the wrapper completely. > > > André > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Philip From szehowe.koh at gmail.com Sun Jul 28 06:10:35 2013 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Sun, 28 Jul 2013 12:10:35 +0800 Subject: [Development] API for multiple (but variable number of) return arguments In-Reply-To: <51F394B8.6030006@familiesomers.nl> References: <51F394B8.6030006@familiesomers.nl> Message-ID: On 27 July 2013 17:36, Andre Somers wrote: > 1) pointers to ints > bool getUnits(int* years, int* monts = 0, int* weeks = 0, int* days = 0, > int* hours = 0, int* minutes = 0, int* seconds = 0, int* milliSeconds = 0); > > Every argument may be 0, in which case this unit is considered as > not-used. This works (I have this in the current version of QTimeSpan), > but it is not a very nice API to work with. If you're interested in > minutes and seconds, you end up with a call like this: > > int minutes, seconds; > if (getUnits(0,0,0,0,0, &minutes, &seconds)) > { ...} Agree that it's not very nice. I'd imagine that in many cases, the developer is only interested in the minority of the units. > 2) returning a map > QMap getUnits(Qt::TimeSpanFormat); > In my opinion, not all that great either, but better than 1). It may be > a benefit to have the results in a data structure that's easy to pass > along in one go, but if you don't want that, getting them out is a bit > of a hassle perhaps. I prefer this over (1), and I can see benefits of having a structure to pass around. If you take this route, I'd vote for a higher-level structure than a simple map -- Let users call isValid() to check for data integrity, and query the format that was used to generate this structure. > 3) QString::arg like API > An interesting option is to do something like this: > > int minutes, seconds; > if ( getUnits().unit(Qt::Minutes, minutes).unit(Qt::Seconds, seconds) ) { > //blah > }; > > Downside is that it allows specifying the same unit multiple times. That > does not need to be a real problem (simply return the same value more > than once), but it may look weird. Also, this API is implementation wise > quite a bit more complex than the previous options. The resulting code > is more verbose than option 1, but much easier to read. IMHO, (2) and (4) look "much easier to read" :) (Having said that, I usually prefer concatenation to QString::args()) By the way, I'm not sure about calling the function "unit()". To me, it suggests returning a Qt::TimeSpanUnit rather than a number. > 4) separate requests > Another option is not return all relevant units in one go, but to use > multiple function calls: > int getUnit(Qt::TimeSpanFormat format, Qt::TimeSpanUnit unit); > > Failure would return -1. If you don't plan to support negative time spans, then returning -1 would be a great way to indicate errors for different APIs. > The example would yield: > > Qt::TimeSpanFormat format = Qt::Minutes | Qt::Seconds; > int minutes = getUnit(format, Qt::Minutes); > int seconds = getUnit(format, Qt::Seconds); > if (minutes >= 0 && seconds >=0) { > //blah > } > > Downside is that in order to make this efficient, you'd need to cache > the result, otherwise you have to reconstruct it for every call with the > same format. See below. > Personally, I don't like having to make multiple function > calls to retrieve parts of the same answer. Also, there are > opportunities for errors here, such as asking for units that are not in > the format. (2) also requires "multiple calls" to extract the numeric values from the map. The only difference is that (2) makes multiple calls on the processed result, (4) makes multiple calls on the original data. For (2), if timeSpan.getUnits(format).value(Qt::Months) returns 0, is it because the period is less than a month, or because I didn't ask for months in the format? In any case, I think the Qt-ish way IS to use different calls to get/set different things, instead of compressing everything into one line in the style of (1). See "The Convenience Trap" at http://qt-project.org/wiki/API-Design-Principles > I guess there are more options, but these four are the more serious > candidates I could come up with. Did I overlook a good candidate? Where > are other examples in the Qt API where there were similar needs, so I > can look if their patterns may apply here? For format-setting, QAudioInput's constructor takes a format to determine how it packages incoming data. For error reporting, many Qt functions return -1 to indicate an error. If you want to support negative spans, there's QString::toInt(bool *ok) which reports errors through an input pointer. In general, there are high-level convenience classes/functions for many things. What do you think of combining elements of these? QTimeSpan timeSpan(...); QTimeSpanDetails det = timeSpan.getDetails(Qt::Minutes|Qt::Seconds); if (!det.isValid()) complain(); Qt::TimeSpanFormat fmt = det.format(); int mins = det.value(Qt::Minutes); int secs1 = det.value(Qt::Seconds); // Convenience functions int secs2 = det.seconds(); int secs3 = det[Qt::Seconds]; int days = det.days(); if (mins == -1 || secs1 == -1 || secs2 == -1 || secs3 == -1) complain(); if (days != -1) complain(); This takes care of the caching problem -- each representation is fixed-format after construction. Regards, Sze-Howe From andre at familiesomers.nl Sun Jul 28 09:46:56 2013 From: andre at familiesomers.nl (Andre Somers) Date: Sun, 28 Jul 2013 09:46:56 +0200 Subject: [Development] API for multiple (but variable number of) return arguments In-Reply-To: <51F43B79.8010108@philipashmore.com> References: <51F394B8.6030006@familiesomers.nl> <51F3B778.6060104@philipashmore.com> <51F3C35B.3050800@familiesomers.nl> <51F43B79.8010108@philipashmore.com> Message-ID: <51F4CC70.20003@familiesomers.nl> Op 27-7-2013 23:28, Philip Ashmore schreef: > On 27/07/13 13:55, Andre Somers wrote: >> Hi, >> >> Op 27-7-2013 14:05, Philip Ashmore schreef: >>> Hi there. >>> >>> On 27/07/13 10:36, Andre Somers wrote: >>>> 1) pointers to ints >>>> bool getUnits(int* years, int* monts = 0, int* weeks = 0, int* days = 0, >>>> int* hours = 0, int* minutes = 0, int* seconds = 0, int* milliSeconds = 0); >>> You could wrap this into a struct: >>> struct TimeSpanResult { >>> int m_years, m_months, m_weeks, m_days, m_hours, m_minutes, >>> m_seconds, m_milliseconds; >>> }; >>> >>> and return it from the call: >>> TimeSpanResult getUnitsTimeSpan(Qt:Minutes | Qt:Seconds); >>> >>> I just used a different name as the return type can't be overloaded. >>> >>> >>> TimeSpanResult getUnitsTimeSpan(int flags) >>> { >>> TimeSpanResult res; >>> getUnits((flags & Qt:Years) ? & res.m_years : (int *)0, (flags & >>> Qt:Years) ? & res.m_months : (int *)0, ... >>> return res; >>> } >>> I've left out error checking for clarity. >> Thanks for your suggestion. It is almost the same as option 2, only you >> replaced the map with a purpose-made struct. I think that indeed that >> might be beneficial to do. >> >> Note that the different name is not needed; I'd like to only expose >> *one* API for this, and not multiple different ones. If I'd choose your >> suggestion, there would be no name clashes with other functions doing >> the same thing. In this case, there would be no clash either, as the >> arguments are different as well as the return type. > Sorry for mylack of clarity. Thanks for your clarification. > I'm not developing Qt code at the minute and forgot about the Qt way of > passing flags. > The clash is with > QMap getUnits(Qt::TimeSpanFormat); > > QTimeSpanResult getUnits(Qt::TimeSpanFormat); > would clash. Ah, right. But as I said: if I'd choose your suggestion, then the version returning a QMap would not be there at all. So, no clashes. The exact naming of the function is not set in stone either. > Also, the proposal I'm making is an inline wrapper for option 1, so the > compiler would eliminate the wrapper completely. That might be a solution, but I'm not sure if that is the most efficient way to do it. I don't think that the int* version is going to be significantly more efficient than a direct implementation of the chosen version. Thank you for your inputs though! André From andre at familiesomers.nl Sun Jul 28 09:47:34 2013 From: andre at familiesomers.nl (Andre Somers) Date: Sun, 28 Jul 2013 09:47:34 +0200 Subject: [Development] API for multiple (but variable number of) return arguments In-Reply-To: References: <51F394B8.6030006@familiesomers.nl> Message-ID: <51F4CC96.6000009@familiesomers.nl> Hi Sze-Howe, Thank you very much for your input. Op 28-7-2013 6:10, Sze Howe Koh schreef: > On 27 July 2013 17:36, Andre Somers wrote: >> 1) pointers to ints > Agree that it's not very nice. I'd imagine that in many cases, the > developer is only interested in the minority of the units. > > >> 2) returning a map >> QMap getUnits(Qt::TimeSpanFormat); > > >> In my opinion, not all that great either, but better than 1). It may be >> a benefit to have the results in a data structure that's easy to pass >> along in one go, but if you don't want that, getting them out is a bit >> of a hassle perhaps. > I prefer this over (1), and I can see benefits of having a structure > to pass around. If you take this route, I'd vote for a higher-level > structure than a simple map -- Let users call isValid() to check for > data integrity, and query the format that was used to generate this > structure. Yes, I agree, that might be the best route to go. > > >> 3) QString::arg like API >> An interesting option is to do something like this: >> >> int minutes, seconds; >> if ( getUnits().unit(Qt::Minutes, minutes).unit(Qt::Seconds, seconds) ) { >> //blah >> }; >> >> Downside is that it allows specifying the same unit multiple times. That >> does not need to be a real problem (simply return the same value more >> than once), but it may look weird. Also, this API is implementation wise >> quite a bit more complex than the previous options. The resulting code >> is more verbose than option 1, but much easier to read. > IMHO, (2) and (4) look "much easier to read" :) (Having said that, I > usually prefer concatenation to QString::args()) I usually don't, and actually like this chaining style where it makes sense. But I'm not saying that this is a good candidate for that :-) > By the way, I'm not sure about calling the function "unit()". To me, > it suggests returning a Qt::TimeSpanUnit rather than a number. Absolutely. Naming is not fixed anywhere. >> 4) separate requests >> Another option is not return all relevant units in one go, but to use >> multiple function calls: >> int getUnit(Qt::TimeSpanFormat format, Qt::TimeSpanUnit unit); >> >> Failure would return -1. > If you don't plan to support negative time spans, then returning -1 > would be a great way to indicate errors for different APIs. Actually, negative spans do exist, so using negative return values to indicate failure is a no-go. >> The example would yield: >> >> Qt::TimeSpanFormat format = Qt::Minutes | Qt::Seconds; >> int minutes = getUnit(format, Qt::Minutes); >> int seconds = getUnit(format, Qt::Seconds); >> if (minutes >= 0 && seconds >=0) { >> //blah >> } >> >> Downside is that in order to make this efficient, you'd need to cache >> the result, otherwise you have to reconstruct it for every call with the >> same format. > See below. > > >> Personally, I don't like having to make multiple function >> calls to retrieve parts of the same answer. Also, there are >> opportunities for errors here, such as asking for units that are not in >> the format. > (2) also requires "multiple calls" to extract the numeric values from > the map. The only difference is that (2) makes multiple calls on the > processed result, (4) makes multiple calls on the original data. For me, that is a big difference actually... > For > (2), if timeSpan.getUnits(format).value(Qt::Months) returns 0, is it > because the period is less than a month, or because I didn't ask for > months in the format? Well, in my original version of 2) using the Map, you could of course use ::contains(Qt::Month) for that. I think that when using a purpose-made data structure for this, it probably should support that kind of query API as well. I'm a bit afraid that this simple value container grows to have quite a big API itself if I'm not careful... > > In any case, I think the Qt-ish way IS to use different calls to > get/set different things, instead of compressing everything into one > line in the style of (1). See "The Convenience Trap" at > http://qt-project.org/wiki/API-Design-Principles I'm aware of that paper, but I don't think it (or at least this part of it) applies here. That part of the document is more about setter API's than about getting a set of parts of the same value out of a function call. The point is, that the units are not different things. They all represent exactly the same: an amount of time, but so in different magnitudes. It is not the case that a period of time really consists of days and hours and minutes, but it can be expressed that way. It can also be expressed using different units (representing different magnitudes). The combination of units (magnitudes) you wish to use has a direct impact on the returned values for each of these units. For instance, say that you don't want to use hours, then you might get a result of 236 minutes. If you would have used hours, then 59 would have been the maximum number of minutes that would have been returned. > > >> I guess there are more options, but these four are the more serious >> candidates I could come up with. Did I overlook a good candidate? Where >> are other examples in the Qt API where there were similar needs, so I >> can look if their patterns may apply here? > For format-setting, QAudioInput's constructor takes a format to > determine how it packages incoming data. > > For error reporting, many Qt functions return -1 to indicate an error. > If you want to support negative spans, there's QString::toInt(bool > *ok) which reports errors through an input pointer. I guess that if the function is going to return a custom data type, that data type might as well include an isValid() method of its own to signal an error condition. As in your example below. > > In general, there are high-level convenience classes/functions for many things. > > What do you think of combining elements of these? > > QTimeSpan timeSpan(...); > QTimeSpanDetails det = timeSpan.getDetails(Qt::Minutes|Qt::Seconds); > > if (!det.isValid()) > complain(); > > Qt::TimeSpanFormat fmt = det.format(); > > int mins = det.value(Qt::Minutes); > int secs1 = det.value(Qt::Seconds); > > // Convenience functions > int secs2 = det.seconds(); > int secs3 = det[Qt::Seconds]; > int days = det.days(); > > if (mins == -1 || secs1 == -1 || secs2 == -1 || secs3 == -1) > complain(); > if (days != -1) > complain(); > > This takes care of the caching problem -- each representation is > fixed-format after construction. I think I'll go for something like this, though I'll start with a version without all the convenience functions. I was trying to trim the API I already had on QTimeSpan, and moving it to QTimeSpanDetails isn't much of a solution for that :-) They can always be added later if there is a need for it. I am not sure about the name either; I'll think about that for a bit. It's the idea that counts though, and it seems like the idea is sound. Thanks, André From guillaume.belz at free.fr Sun Jul 28 15:05:57 2013 From: guillaume.belz at free.fr (guillaume.belz at free.fr) Date: Sun, 28 Jul 2013 15:05:57 +0200 (CEST) Subject: [Development] [QML] Positioner and Qt Quick Layout In-Reply-To: <1370026849.45654633.1375016297619.JavaMail.root@zimbra61-e11.priv.proxad.net> Message-ID: <746018294.45664073.1375016757155.JavaMail.root@zimbra61-e11.priv.proxad.net> Hi, When testing Qt Quick Layout, I see it's not possible to get index from Positioner in layouts. This code works: import QtQuick 2.0 Grid { rows : 3; columns : 3 spacing : 4 Repeater { model : 9 Rectangle { width : 50; height : 50 color : "lightgreen" Text { anchors.centerIn : parent font.pointSize : 14 text : parent .Positioner.index } } } } But not this code: import QtQuick 2.0 import QtQuick.Layouts 1.0 GridLayout { rows : 3; columns : 3 Repeater { model : 9 Rectangle { width : 50; height : 50 color : "lightgreen" Text { anchors.centerIn : parent font.pointSize : 14 text : parent .Positioner.index } } } } Bug ou feature ? ( I did not find any entry in bugreport) Thanks Guillaume Belz -------------- next part -------------- An HTML attachment was scrubbed... URL: From markg85 at gmail.com Sun Jul 28 18:46:42 2013 From: markg85 at gmail.com (Mark) Date: Sun, 28 Jul 2013 18:46:42 +0200 Subject: [Development] [QML] Positioner and Qt Quick Layout In-Reply-To: <746018294.45664073.1375016757155.JavaMail.root@zimbra61-e11.priv.proxad.net> References: <1370026849.45654633.1375016297619.JavaMail.root@zimbra61-e11.priv.proxad.net> <746018294.45664073.1375016757155.JavaMail.root@zimbra61-e11.priv.proxad.net> Message-ID: On Sun, Jul 28, 2013 at 3:05 PM, wrote: > Hi, > When testing Qt Quick Layout, I see it's not possible to get index from > Positioner in layouts. > This code works: > > import QtQuick 2.0 > > > Grid { > > rows: 3; columns: 3 > > spacing: 4 > > Repeater { > > model: 9 > > Rectangle { > > width: 50; height: 50 > > color: "lightgreen" > > Text { > > anchors.centerIn: parent > > font.pointSize: 14 > > text: parent.Positioner.index > > } > > } > > } > > } > > > But not this code: > > > import QtQuick 2.0 > > import QtQuick.Layouts 1.0 > > GridLayout { > > rows: 3; columns: 3 > > Repeater { > > model: 9 > > Rectangle { > > width: 50; height: 50 > > color: "lightgreen" > > Text { > > anchors.centerIn: parent > > font.pointSize: 14 > > text: parent.Positioner.index > > } > > } > > } > > } > > Bug ou feature ? (I did not find any entry in bugreport) > > Thanks > > Guillaume Belz > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > I didn't know anything about a "Positioner" so that's certainly interesting to see! However, what you do as: "parent.Positioner.index" is what i do as just "index" so you might have better luck trying that one. From mbroadst at gmail.com Sun Jul 28 19:51:13 2013 From: mbroadst at gmail.com (Matt Broadstone) Date: Sun, 28 Jul 2013 13:51:13 -0400 Subject: [Development] QScopedPointer and QObjects Message-ID: Hey all, I've found more often than I'd like in my unit tests I'm writing a custom deleter for QObjects when using a QScopedPointer. Something to the effect of: struct QObjectDeleter { static inline void cleanup(QObject *pointer) { if (pointer) pointer->deleteLater(); } }; and then: QScopedPointer object; Is there a reason this wasn't added for convenience? Or, would there be interest in me submitting a patch to include this in a later version of Qt? We should even be able to fix this seamlessly with templates unless I'm mistaken. Regards, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Sun Jul 28 20:00:00 2013 From: andre at familiesomers.nl (Andre Somers) Date: Sun, 28 Jul 2013 20:00:00 +0200 Subject: [Development] QtCS - QObject discussion In-Reply-To: <11956916.eUnHlRGgNd@gargamel> References: <11956916.eUnHlRGgNd@gargamel> Message-ID: <51F55C20.3090403@familiesomers.nl> Op 26-7-2013 23:48, Olivier Goffart schreef: > This is a summary of what's written there: > https://qt-project.org/groups/qt-contributors-summit-2013/wiki/QObject > > - As it was decided in the QtCore discussion, new features may require C++11 > > - We want to add an overload of QObject::connect that takes both a pointer to > a "receiver" and a simple functor (as opposed to a pointer to member function) > Use case is to have automatic disconnection of connections to lambda > functions, and also be able to use thread affinity and QueuedConnection. > Dario Freddi said he will have a look. Would it be feasible to be able to connect directly to QObject or QObject subclasses that are stored in a shared pointer, scoped pointer or QPointer? It is just sugar of course, but it would be neat if I don't need the .data() anymore on these for connect statements... André From thiago.macieira at intel.com Sun Jul 28 21:18:15 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 28 Jul 2013 12:18:15 -0700 Subject: [Development] QScopedPointer and QObjects In-Reply-To: References: Message-ID: <2972029.uSFgCCiMVb@tjmaciei-mobl2> On domingo, 28 de julho de 2013 13:51:13, Matt Broadstone wrote: > Is there a reason this wasn't added for convenience? Or, would there be > interest in me submitting a patch to include this in a later version of Qt? > We should even be able to fix this seamlessly with templates unless I'm > mistaken. Go ahead and submit the deleter class. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From mail at milianw.de Sun Jul 28 22:48:45 2013 From: mail at milianw.de (Milian Wolff) Date: Sun, 28 Jul 2013 22:48:45 +0200 Subject: [Development] QScopedPointer and QObjects In-Reply-To: <2972029.uSFgCCiMVb@tjmaciei-mobl2> References: <2972029.uSFgCCiMVb@tjmaciei-mobl2> Message-ID: <2033739.ksHknhqyDC@minime> On Sunday 28 July 2013 12:18:15 Thiago Macieira wrote: > On domingo, 28 de julho de 2013 13:51:13, Matt Broadstone wrote: > > Is there a reason this wasn't added for convenience? Or, would there be > > interest in me submitting a patch to include this in a later version of > > Qt? > > We should even be able to fix this seamlessly with templates unless I'm > > mistaken. > > Go ahead and submit the deleter class. But don't make it mandatory for QObject (which is how I understood your "fix this seamlessly with templates"). You usually don't have to delete QObject's with deleteLater afaik. Bye -- Milian Wolff mail at milianw.de http://milianw.de From thiago.macieira at intel.com Sun Jul 28 23:47:34 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 28 Jul 2013 14:47:34 -0700 Subject: [Development] QScopedPointer and QObjects In-Reply-To: <2033739.ksHknhqyDC@minime> References: <2972029.uSFgCCiMVb@tjmaciei-mobl2> <2033739.ksHknhqyDC@minime> Message-ID: <4339874.Yy6niPp9N3@tjmaciei-mobl2> On domingo, 28 de julho de 2013 22:48:45, Milian Wolff wrote: > On Sunday 28 July 2013 12:18:15 Thiago Macieira wrote: > > On domingo, 28 de julho de 2013 13:51:13, Matt Broadstone wrote: > > > Is there a reason this wasn't added for convenience? Or, would there be > > > interest in me submitting a patch to include this in a later version of > > > Qt? > > > We should even be able to fix this seamlessly with templates unless I'm > > > mistaken. > > > > Go ahead and submit the deleter class. > > But don't make it mandatory for QObject (which is how I understood your "fix > this seamlessly with templates"). You usually don't have to delete > QObject's with deleteLater afaik. Right. Submit *just* the new class and document it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From simon.lees at codan.com.au Mon Jul 29 01:46:23 2013 From: simon.lees at codan.com.au (Simon Lees) Date: Mon, 29 Jul 2013 09:16:23 +0930 Subject: [Development] Android missing SONAME in lib's causes In-Reply-To: <1374857946.9808.YahooMailNeo@web126106.mail.ne1.yahoo.com> References: <2171360.MuxoQFPleD@hal> <51EDD33A.2080603@codan.com.au> <4082192.eQr6N3KKOd@hal> <1374763077.64179.YahooMailNeo@web126102.mail.ne1.yahoo.com> <51F1D952.7010401@codan.com.au> <1374857946.9808.YahooMailNeo@web126106.mail.ne1.yahoo.com> Message-ID: <51F5AD4F.9090600@codan.com.au> On 07/27/2013 02:29 AM, BogDan wrote: > >>>>> This provides a improvement for me but it is not a complete >> solution, on >>>>> android we load libQt5xxx.so my solution as it was still tried >> to load >>>>> libQt5xxx.so.5 which doesn't exist as libraries are not >> symlinked on >>>>> android like they are on Linux and only libQt5xxx.so is present. >>>> Then perhaps this is the reason that the variable is simply cleared on >>>> Android. qmake should probably generate the SONAME without the version >> on >>>> android? >>>> >>>> Ossi, is that possible? >>>> >>>> Thanks, >>>> >>> Hello, >>> >>> If you are going to roll it back >> https://codereview.qt-project.org/#change,61330 >>> a few things will stop to work immediately: >>> - android qt creator plugin. >>> - no qt apps will be movable to sdcard (most of the sdcards are fat >> formated, and it can not have symlinks). >>> - Ministro needs lots of changes to support symlinks, this is the reason >> why I choose not to use SONAME. >>> There are two ways to have a Qt application on Android, one is to use >> Ministro to get the libs, and the second one is to bundle Qt libs into the APK. >> For none of them you don't need to use SONAME. >>> Personally, I see no reason why should SONAME be used for Android ... >>> >>> Thanks, >>> BogDan. >>> >>> P.S. Sorry for slow reply, I didn't see the message until now. >>> . >>> >> Hi, >> The only reason for it is to fix cmake building. From my testing yes >> using the normal method to set the SONAME to be libQt5Core.so.5 does >> break everything but manually setting the SONAME to be libQt5Core.so >> works, at least for me this is because the java wrapper has already >> loaded libQt5.core.so before my shared library is loaded and as they >> have the same name the library is not re loaded. >> >> The only other solution is to patch cmake so it doesn't require a SONAME >> or so that a SONAME can be manually provided. >> >> Cheers >> >> Simon >> > In this case I'll keep my -1 for that patch :) > Can't cmake scripts be changed to work with SONAME set to > libQt5XXXXX.so ? > > Cheers, > BogDan. > . > Hi All, I know the discussion has moved on from here but just to clarify, cmake works fine with libQt5xxx.so its just not possible to generate libraries with that using Qt's configure and qmake (well i'm not smart enough to). Cheers Simon From Jan-Arve.Saether at digia.com Mon Jul 29 08:19:25 2013 From: Jan-Arve.Saether at digia.com (Saether Jan-Arve) Date: Mon, 29 Jul 2013 06:19:25 +0000 Subject: [Development] [QML] Positioner and Qt Quick Layout In-Reply-To: <746018294.45664073.1375016757155.JavaMail.root@zimbra61-e11.priv.proxad.net> References: <1370026849.45654633.1375016297619.JavaMail.root@zimbra61-e11.priv.proxad.net> <746018294.45664073.1375016757155.JavaMail.root@zimbra61-e11.priv.proxad.net> Message-ID: <66BFFE861C7DE34D9B0372D8EAAB18E2BCB301@IT-EXMB01-HKI.it.local> It's not a bug. GridLayout is not a Positioner, so it does not provide such functionality (however, it could). In this specific case you might be able to use the index from the Repeater in your case. If that's not sufficient, feel free to file a suggestion at bugreports.qt-project.org. Jan Arve From: development-bounces+jan-arve.saether=digia.com at qt-project.org [mailto:development-bounces+jan-arve.saether=digia.com at qt-project.org] On Behalf Of guillaume.belz at free.fr Sent: 28. juli 2013 15:06 To: development at qt-project.org Subject: [Development] [QML] Positioner and Qt Quick Layout Hi, When testing Qt Quick Layout, I see it's not possible to get index from Positioner in layouts. This code works: import QtQuick 2.0 Grid { rows: 3; columns: 3 spacing: 4 Repeater { model: 9 Rectangle { width: 50; height: 50 color: "lightgreen" Text { anchors.centerIn: parent font.pointSize: 14 text: parent.Positioner.index } } } } But not this code: import QtQuick 2.0 import QtQuick.Layouts 1.0 GridLayout { rows: 3; columns: 3 Repeater { model: 9 Rectangle { width: 50; height: 50 color: "lightgreen" Text { anchors.centerIn: parent font.pointSize: 14 text: parent.Positioner.index } } } } Bug ou feature ? (I did not find any entry in bugreport) Thanks Guillaume Belz -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at digia.com Mon Jul 29 09:49:41 2013 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Mon, 29 Jul 2013 07:49:41 +0000 Subject: [Development] Is Xlib a hard requirement for Qt5 xcb? In-Reply-To: References: Message-ID: <6F64F665-46E3-4825-AEFF-6ED128E32832@digia.com> On 26 Jul 2013, at 11:19 PM, Nicolás Alvarez wrote: > Hi everyone, > > I attempted to build Qt5 and KF5 in a minimal system, only installing > dependencies when configure/cmake asks for them, in order to find bugs > (such as missing dependency checks) in the build system. I was > successful, in the sense that I found missing checks :) > > I'm configuring Qt with the options suggested in the KF5 wiki: > ./configure -prefix $PWD/qtbase -opensource -developer-build > -nomake tests -nomake examples -dbus -no-separate-debug-info -xcb -qpa > xcb -no-gtkstyle -no-pch > > My minimal system does not have X11 development files (such as > Xlib.h), but it does have XCB stuff. > > Compilation fails with: > make[2]: Entering directory `/home/nicolas/src/qt5/qtbase/src/widgets' > util/qsystemtrayicon_x11.cpp:60:22: fatal error: X11/Xlib.h: No such > file or directory > make[2]: Leaving directory `/home/nicolas/src/qt5/qtbase/src/widgets' > > make[5]: Entering directory > `/home/nicolas/src/qt5/qtbase/src/plugins/platforms/xcb' > qxcbmime.cpp:49:23: fatal error: X11/Xutil.h: No such file or directory > qxcbcursor.cpp:52:28: fatal error: X11/cursorfont.h: No such file or directory > qxcbxsettings.cpp:46:36: fatal error: X11/extensions/XIproto.h: No > such file or directory > make[5]: Leaving directory > `/home/nicolas/src/qt5/qtbase/src/plugins/platforms/xcb' > > The question is: is Qt5/XCB *supposed* to work without Xlib? I got the > feeling that there was some attempt to make it work, since some code > is protected with #ifdef XCB_USE_XLIB checks (though perhaps that > define is for something else?). If supposed to work, then it's > currently broken and likely needs some more ifdefs. If not supposed to > work, then the configure script should abort Xlib isn't present while > configuring for XCB. I'm interested in fixing it either way, but I > can't take the decision of what's supported :) Do you have an opinion on why we should put a stronger emphasis on using xcb only? The reasons I can think of are 1) not loading xlib will save a little memory and load time 2) maybe it will perform better because xcb is so low-level that no functions have built-in wait-for-reply functionality; so if you write the code in a pipelined fashion as much as possible, it will spend less time waiting for replies 3) theoretically, new features are supposed to be added to xcb first but the downsides I can think of are 1) xcb is such a low-level API that the code is tedious to write and maintain; it's no fun replacing convenient one-line function calls and having to think about all possible timings simultaneously: the usual question being, when is the latest that I can receive a reply to a particular request, so I can get as much else done as possible while waiting for it? 2) in fact, new features don't always get added to xcb first. When I wrote the XInput 2.2 support for touchscreens, xcb didn't have it. I guess I need to check again whether it does now. It should theoretically be easy for me to write the patch to add that to xcb, and I was thinking of doing that, but didn't get around to it yet. xcb is maintained by a small band of volunteers, so there's no reason to say for sure that new features get added there first; just that it was the intention. So I'm not convinced the advantages are so strong to prioritize this very much. Considering that there are some ifdefs, it makes sense to complete them so that it can build without xlib. Then maybe it makes sense to do that kind of build on CI to ensure that it continues to work. But it's also likely right now that there will be too many features missing to be practical anyhow. I thought the plan was to gradually rewrite the xlib dependent parts so that eventually we only need xcb, but that's tedious work so I'm not sure how long it will take to get rid of every last dependency. From joerg.bornemann at digia.com Mon Jul 29 10:29:38 2013 From: joerg.bornemann at digia.com (Joerg Bornemann) Date: Mon, 29 Jul 2013 10:29:38 +0200 Subject: [Development] QtCS - qbs session Message-ID: <51F627F2.2060505@digia.com> Hi, This is a little write-up about the qbs session at the Qt CS. Most participants haven't seen qbs project files yet, so we had a little introductory session with some example projects. While discussing the examples different topics came up: Building Qt There's QBS-70 to track the changes necessary to adapt Qt's modular build system and replace syncqt and configure. Bootstrapping Current dependencies: QtCore, QtConcurrent, QtScript (the QtConcurrent dependency is gone by now). QtScript could maybe replaced by v4m. Qt bootstrap libs do not support qobjects or qtconcurrent. Maybe replace bootstrap lib altogether with a static build? In any case, it's not rocket science. Ideas for language Why isn’t e.g. cpp dependency built in / depends on file suffix? This would allow a product to depend e.g. on variable file list. Does qbs right now support the generation of an unknown number of files out of one file (and process these further)? No, not yet. This problem is similar to moc support which is currently hard-wired into qbs. Is qbs any more toolable than qmake, if you allow arbitrary JS in properties? Common use cases are easily toolable, complicated parts must be edited manually. -- Joerg Bornemann Digia, Qt http://qt.digia.com/ From mardy at users.sourceforge.net Mon Jul 29 10:56:34 2013 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Mon, 29 Jul 2013 11:56:34 +0300 Subject: [Development] QtCS - QtDBus discussion In-Reply-To: <6676314.eEVX7OCQ0t@tjmaciei-mobl2> References: <6676314.eEVX7OCQ0t@tjmaciei-mobl2> Message-ID: <51F62E42.601@users.sourceforge.net> Hi, I'd like to ask some more info about this since I was not there: On 07/26/2013 11:39 PM, Thiago Macieira wrote: > This is a simple copy & paste from the wiki page, since the topic is fairly > short. See http://qt-project.org/groups/qt-contributors-summit-2013/wiki/QtDBus_CS > > h1. QtDBus module discussions at Qt Contributor Summit 2013 > > Topics for discussion: > * Rewriting the engine: > ** Dropping the libdbus-1 dependency [...] > Discussion: > # Take ahartmetz's marshaller/demarshaller and put on top of QtDBus & > libdbus-1 This line and the one from the topic seem to be conflicting: will libdbus-1 be dropped or not? Will we use some other library or will the whole stuff be natively implemented in Qt? Do you have any links for ahartmetz's marshaller? Ciao, Alberto From james.turner at kdab.com Mon Jul 29 12:49:19 2013 From: james.turner at kdab.com (James Turner) Date: Mon, 29 Jul 2013 11:49:19 +0100 Subject: [Development] QtCS Mac session report In-Reply-To: <1924044.kAk3SUtRmG@varney> References: <2BEECC92-4C8E-478E-BFCF-EC18E816700C@digia.com> <1924044.kAk3SUtRmG@varney> Message-ID: <23244964-F3F9-441D-97FB-40E29CF8CA8E@kdab.com> On 27 Jul 2013, at 09:24, Frederik Gladhorn wrote: > I'd like to have more info here, where's the bug report? https://bugreports.qt-project.org/browse/QTBUG-31956 James -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at digia.com Mon Jul 29 13:01:11 2013 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Mon, 29 Jul 2013 11:01:11 +0000 Subject: [Development] Puzzled by desktop development priorities, Mac OS specifically In-Reply-To: References: Message-ID: <7776D006-2CE3-47B4-A7DF-CDD1D6631642@digia.com> On 26 Jul 2013, at 11:01 AM, Jan Farø wrote: > Hi all, > > I posted this on qt-project forums (http://qt-project.org/forums/viewthread/29888/), and was told this mailing list was a better audience. About 2 weeks ago I tried to post the same post as an anonymous user, but it has not yet been handled, hence I decided to become a member of the list. > > I am in the final stages of rewriting a somehow complex (at least for me) application to Qt from Java Swing. The time has come to focus on UI details, and this is where Qt gives me grey hairs. I started out developing in Qt 4.8, and experienced several issues that didn’t work on the Mac (From the top of my head: Overlays on video widgets), or just looked plain wrong in Mac OS context (For example: Table rows with alternate row colors does not extend to the bottom if only containing a few rows; list view items does not scroll properly if setting an item widget). > > Hoping that Qt5 would solve some of these problems (apart from reaping benefit from the great added features like JSON and serial device support), I have patiently waited for Qt5 to evolve from beta to 5.1 at the current point. Still, I’m seeing the same issues. Still. On top of that, classes like QtSingleApplication are not yet there. The unified toolbar on the Mac is gone, externalized to qtmacextras, which is still not ready. Compiling the latest version is not possible because of errors. > > Bottom line is that creating a professionally looking/behaving application on the Mac is not yet possible with Qt 5.1, and not with Qt 4.8 either if requiring certain features – unless you know how to fix the underlying problems, and I certainly don’t. I'm sorry that we have been slow to fix certain issues. Please make sure that your pet peeves all have Jira bugs, and then when you write an email like this, you can name specific bugs, tell us why they are important for you and ask for them to be prioritized. But I see from the forum post that you listed https://bugreports.qt-project.org/browse/QTBUG-27043 Is that 4.x only or do you still have the problem in 5.x? https://bugreports.qt-project.org/browse/QTBUG-2876 same question https://bugreports.qt-project.org/browse/QTBUG-30248 You are asking for a new feature on QTableView, and got a reply that exposing QTableViewPrivate::drawCell() as a virtual method in the public QTableView API would break binary compatibility. It sounds like a good idea conceptually to have separate vertical and horizontal lines though. QtQuick should already give you better opportunities to customize the appearance of a table; does the QtQuick Controls table give you enough features for your application? http://doc-snapshot.qt-project.org/qt5-stable/qtquickcontrols/qml-qtquick-controls1-tableview.html Yes qtmacextras is not done yet, and the unified toolbar will be especially nice to have. It builds with the current git dev branch, but not with release or stable branches (5.1.x). It could be ready to ship with 5.2 if we spend enough time on it before then (I'm not sure if that's been promised previously), so depending on your own schedule, maybe you can develop with dev branch for now and plan to ship after 5.2? Anyway AFAIK it's certain that we will not add a module in the 5.1 series. I don't know of any plan about QtSingleApplication; it was never a mainstream Qt feature. If the user purposely starts two instances of your application, is that really so bad? I would think the main thing would be to make sure that when the user opens another document from Finder, it opens in any existing instance if there is one, assuming your app handles multiple documents. We have not forgotten the Mac; several of us are spending a large percentage of our time on it. Progress gets a little slower during the summer when people tend to take vacations though. And our priority is 5.x, so only the worst 4.8 bugs are getting fixed, in practice. But bugfix patches are welcome as long as they don't break compatibility. From olivier at woboq.com Mon Jul 29 13:17:22 2013 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 29 Jul 2013 13:17:22 +0200 Subject: [Development] QtCS - QObject discussion In-Reply-To: <51F55C20.3090403@familiesomers.nl> References: <11956916.eUnHlRGgNd@gargamel> <51F55C20.3090403@familiesomers.nl> Message-ID: <1524288.2oboCyU3HW@gargamel> On Sunday 28 July 2013 20:00:00 Andre Somers wrote: > Op 26-7-2013 23:48, Olivier Goffart schreef: > > This is a summary of what's written there: > > https://qt-project.org/groups/qt-contributors-summit-2013/wiki/QObject > > > > - As it was decided in the QtCore discussion, new features may require > > C++11 > > > > - We want to add an overload of QObject::connect that takes both a pointer > > to a "receiver" and a simple functor (as opposed to a pointer to member > > function) Use case is to have automatic disconnection of connections to > > lambda functions, and also be able to use thread affinity and > > QueuedConnection. Dario Freddi said he will have a look. > > Would it be feasible to be able to connect directly to QObject or > QObject subclasses that are stored in a shared pointer, scoped pointer > or QPointer? It is just sugar of course, but it would be neat if I don't > need the .data() anymore on these for connect statements... For QPointer, it should already work because QPointer has a operator T*. QSharedPointer and QScopedPointer do not have operator T*. Apparently, this is intentional. I do not beleive we should add this convinience in QObject::connect. Or why not in every places that takes pointer? Why would QObject::connect be any special in that respect? I'd personnally rather add the operator T* convinience to the QScopedPointer and QSharedPointer. I know the reasons it is not there, but i am not convinced they are worth the inconvenience: http://herbsutter.com/2012/06/21/reader-qa-why-dont-modern-smart-pointers-implicitly-convert-to/ -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From samuel.gaist at edeltech.ch Mon Jul 29 13:46:20 2013 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Mon, 29 Jul 2013 13:46:20 +0200 Subject: [Development] Puzzled by desktop development priorities, Mac OS specifically In-Reply-To: <7776D006-2CE3-47B4-A7DF-CDD1D6631642@digia.com> References: <7776D006-2CE3-47B4-A7DF-CDD1D6631642@digia.com> Message-ID: On 29 juil. 2013, at 13:01, Rutledge Shawn wrote: > > On 26 Jul 2013, at 11:01 AM, Jan Farø wrote: > >> Hi all, >> >> I posted this on qt-project forums (http://qt-project.org/forums/viewthread/29888/), and was told this mailing list was a better audience. About 2 weeks ago I tried to post the same post as an anonymous user, but it has not yet been handled, hence I decided to become a member of the list. >> >> I am in the final stages of rewriting a somehow complex (at least for me) application to Qt from Java Swing. The time has come to focus on UI details, and this is where Qt gives me grey hairs. I started out developing in Qt 4.8, and experienced several issues that didn’t work on the Mac (From the top of my head: Overlays on video widgets), or just looked plain wrong in Mac OS context (For example: Table rows with alternate row colors does not extend to the bottom if only containing a few rows; list view items does not scroll properly if setting an item widget). >> >> Hoping that Qt5 would solve some of these problems (apart from reaping benefit from the great added features like JSON and serial device support), I have patiently waited for Qt5 to evolve from beta to 5.1 at the current point. Still, I’m seeing the same issues. Still. On top of that, classes like QtSingleApplication are not yet there. The unified toolbar on the Mac is gone, externalized to qtmacextras, which is still not ready. Compiling the latest version is not possible because of errors. >> >> Bottom line is that creating a professionally looking/behaving application on the Mac is not yet possible with Qt 5.1, and not with Qt 4.8 either if requiring certain features – unless you know how to fix the underlying problems, and I certainly don’t. > > I'm sorry that we have been slow to fix certain issues. Please make sure that your pet peeves all have Jira bugs, and then when you write an email like this, you can name specific bugs, tell us why they are important for you and ask for them to be prioritized. But I see from the forum post that you listed > > https://bugreports.qt-project.org/browse/QTBUG-27043 > > Is that 4.x only or do you still have the problem in 5.x? > If I may: I have tested the bug with Qt 5 stable and it's all good. So it's only a 4.x matter, I have submitted a patch using the code from the bug report (after testing it), you can find it at https://codereview.qt-project.org/#change,61023 > https://bugreports.qt-project.org/browse/QTBUG-2876 > > same question > > https://bugreports.qt-project.org/browse/QTBUG-30248 > > You are asking for a new feature on QTableView, and got a reply that exposing QTableViewPrivate::drawCell() as a virtual method in the public QTableView API would break binary compatibility. It sounds like a good idea conceptually to have separate vertical and horizontal lines though. QtQuick should already give you better opportunities to customize the appearance of a table; does the QtQuick Controls table give you enough features for your application? > > http://doc-snapshot.qt-project.org/qt5-stable/qtquickcontrols/qml-qtquick-controls1-tableview.html > > Yes qtmacextras is not done yet, and the unified toolbar will be especially nice to have. It builds with the current git dev branch, but not with release or stable branches (5.1.x). It could be ready to ship with 5.2 if we spend enough time on it before then (I'm not sure if that's been promised previously), so depending on your own schedule, maybe you can develop with dev branch for now and plan to ship after 5.2? Anyway AFAIK it's certain that we will not add a module in the 5.1 series. > > I don't know of any plan about QtSingleApplication; it was never a mainstream Qt feature. If the user purposely starts two instances of your application, is that really so bad? I would think the main thing would be to make sure that when the user opens another document from Finder, it opens in any existing instance if there is one, assuming your app handles multiple documents. I have one use case here where I need to ensure that only one instance of my application runs (hardware access, processing "power") otherwise I would have to implement some form of locking on different platforms and QtSingleApplication offers a good alternative for that. > We have not forgotten the Mac; several of us are spending a large percentage of our time on it. Progress gets a little slower during the summer when people tend to take vacations though. And our priority is 5.x, so only the worst 4.8 bugs are getting fixed, in practice. But bugfix patches are welcome as long as they don't break compatibility. > I'd be happy to help if I can. Currently I have more interest in the 4.8 series since our main softwares runs also on OS X and need some not yet released features, but I try to provide fixes equally for both series. From andre at familiesomers.nl Mon Jul 29 14:00:05 2013 From: andre at familiesomers.nl (=?ISO-8859-1?Q?Andr=E9_Somers?=) Date: Mon, 29 Jul 2013 14:00:05 +0200 Subject: [Development] QtCS - QObject discussion In-Reply-To: <1524288.2oboCyU3HW@gargamel> References: <11956916.eUnHlRGgNd@gargamel> <51F55C20.3090403@familiesomers.nl> <1524288.2oboCyU3HW@gargamel> Message-ID: <51F65945.7080304@familiesomers.nl> Op 29-7-2013 13:17, Olivier Goffart schreef: > On Sunday 28 July 2013 20:00:00 Andre Somers wrote: >> Op 26-7-2013 23:48, Olivier Goffart schreef: >>> This is a summary of what's written there: >>> https://qt-project.org/groups/qt-contributors-summit-2013/wiki/QObject >>> >>> - As it was decided in the QtCore discussion, new features may require >>> C++11 >>> >>> - We want to add an overload of QObject::connect that takes both a pointer >>> to a "receiver" and a simple functor (as opposed to a pointer to member >>> function) Use case is to have automatic disconnection of connections to >>> lambda functions, and also be able to use thread affinity and >>> QueuedConnection. Dario Freddi said he will have a look. >> Would it be feasible to be able to connect directly to QObject or >> QObject subclasses that are stored in a shared pointer, scoped pointer >> or QPointer? It is just sugar of course, but it would be neat if I don't >> need the .data() anymore on these for connect statements... > For QPointer, it should already work because QPointer has a operator T*. > QSharedPointer and QScopedPointer do not have operator T*. Apparently, this is > intentional. > > I do not beleive we should add this convinience in QObject::connect. Or why > not in every places that takes pointer? Why would QObject::connect be any > special in that respect? Good point. I'm not sure if how many API's there are in Qt that take raw pointers to QObjects outside of constructors, but my feeling is that there are problably too many to justify a break in consistence here. Also, fixing other points will result in API bloat all over Qt. That is definiately not worth the benefit. > I'd personnally rather add the operator T* convinience to the QScopedPointer > and QSharedPointer. I know the reasons it is not there, but i am not > convinced they are worth the inconvenience: > http://herbsutter.com/2012/06/21/reader-qa-why-dont-modern-smart-pointers-implicitly-convert-to/ That would solve it, but I am not convinced either way. I am also not convinced that not having to use .data() is worth the risk introducing operator T*. At the very least the delete should then be disabled as well. André -- You like Qt? I am looking for collegues to join me at i-Optics! From Yoann.Lopes at digia.com Mon Jul 29 14:25:01 2013 From: Yoann.Lopes at digia.com (Lopes Yoann) Date: Mon, 29 Jul 2013 12:25:01 +0000 Subject: [Development] QtCS - QtMultimedia discussion Message-ID: <76A66FD6-4F49-45D7-AF2C-34617F3D7E50@digia.com> Hi, Here is a summary of the discussion about Qt Multimedia. For more information, please see the wiki page at http://qt-project.org/wiki/Qt_Multimedia - The overall quality of the module should be improved. This means better documentation, fixing and re-enabling some auto-tests, adding missing QML APIs, and improving consistency across backends. There is also work to do in JIRA to sort out old tasks (close or update), and create new ones. - The GStreamer backend should be ported to GStreamer 1.0. - Windows Media Foundation backend: add camera support, make it compilable with MinGW. - DirectShow backend: could be available together with the WMF plugin in order to provide better codec support on Windows. - QuickTime 7 backend (MacOS) can be deprecated in 5.2. - QML VideoOutput fullscreen property (backends often have optimizations for fullscreen video rendering) - New APIs (see wiki for details) - A single cross-platform backend could be used everywhere to improve consistency across platforms and reduce code maintenance. The backend could be GStreamer or libVLC. We didn't have much time to talk about this, any thoughts? Yoann Lopes Senior Software Engineer - Digia, Qt Visit us on: http://qt.digia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From frankie83 at gmail.com Mon Jul 29 14:35:02 2013 From: frankie83 at gmail.com (Frankie) Date: Mon, 29 Jul 2013 15:35:02 +0300 Subject: [Development] Qt 5.1.0 Download Option for windows 32-bit + VS2012 + OpenGL? Message-ID: The current download options of pre-built binaries do not include this specific configuration (windows 32-bit + VS2012 + OpenGL) and it's the specific one I use. I saw another question about in on the forum and the recommendation was to ask here. Is there any chance of adding this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpapp at kde.org Mon Jul 29 15:08:47 2013 From: lpapp at kde.org (Laszlo Papp) Date: Mon, 29 Jul 2013 14:08:47 +0100 Subject: [Development] [Interest] [Announce] Qt 5.1 released In-Reply-To: References: <51D5813E.3050302@sescoi.fr> <51D5861D.5090504@sescoi.fr> Message-ID: On Fri, Jul 5, 2013 at 3:52 AM, Jake Thomas Petroules < jake.petroules at petroules.com> wrote: > Personally I still think it would be far more logical to delegate the > ANGLE vs OpenGL decision to runtime, by including plugins for both backends > with all Windows distributions. > > Having different packages seems to confuse a lot of Qt developers and > complicates deployment matters, whereas a plugin based approach would solve > these issues and also give end users the option to try a different graphics > backend if the current one isn't working out for them. Many game engines do > this, so why shouldn't Qt also be able to? > Good question. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at digia.com Mon Jul 29 15:21:14 2013 From: Simon.Hausmann at digia.com (Hausmann Simon) Date: Mon, 29 Jul 2013 13:21:14 +0000 Subject: [Development] [Interest] [Announce] Qt 5.1 released In-Reply-To: References: <51D5813E.3050302@sescoi.fr> <51D5861D.5090504@sescoi.fr> , Message-ID: It is indeed a logical thing to try to delegate this to a run-time decision. Unlike games however we that way always export an API (OpenGL) to the app, so it's a little bit more complicated. A run-time (or rather start-up) switch would be nice to have, but somebody would have to do the non-trivial work. Apparently nobody has found this urgent enough yet to begin :) Simon Laszlo Papp wrote: On Fri, Jul 5, 2013 at 3:52 AM, Jake Thomas Petroules > wrote: Personally I still think it would be far more logical to delegate the ANGLE vs OpenGL decision to runtime, by including plugins for both backends with all Windows distributions. Having different packages seems to confuse a lot of Qt developers and complicates deployment matters, whereas a plugin based approach would solve these issues and also give end users the option to try a different graphics backend if the current one isn't working out for them. Many game engines do this, so why shouldn't Qt also be able to? Good question. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Jul 29 17:22:38 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Jul 2013 08:22:38 -0700 Subject: [Development] QtCS - QtDBus discussion In-Reply-To: <51F62E42.601@users.sourceforge.net> References: <6676314.eEVX7OCQ0t@tjmaciei-mobl2> <51F62E42.601@users.sourceforge.net> Message-ID: <10264208.Yd9WpzHTWB@tjmaciei-mobl2> On segunda-feira, 29 de julho de 2013 11:56:34, Alberto Mardegan wrote: > Hi, > I'd like to ask some more info about this since I was not there: > > On 07/26/2013 11:39 PM, Thiago Macieira wrote: > > This is a simple copy & paste from the wiki page, since the topic is > > fairly > > short. See > > http://qt-project.org/groups/qt-contributors-summit-2013/wiki/QtDBus_CS > > > > h1. QtDBus module discussions at Qt Contributor Summit 2013 > > > > Topics for discussion: > > * Rewriting the engine: > > ** Dropping the libdbus-1 dependency > > [...] > > > Discussion: > > # Take ahartmetz's marshaller/demarshaller and put on top of QtDBus & > > libdbus-1 > > This line and the one from the topic seem to be conflicting: will > libdbus-1 be dropped or not? > Will we use some other library or will the whole stuff be natively > implemented in Qt? Hi Alberto The idea is that this is one step in moving away from the dbus-1 dependency. That library does mainly two things for us: marshalling of messages and connection management. Since dbus-1 has had for years an API to insert a pre- marshalled message on the connection, we thought that we could do the port in two steps by replacing the marshalling code first. The idea is to have this code inside src/dbus, completely native. Once that is done and working, we go to step 2 and replace the socket management, dropping the dependency. > Do you have any links for ahartmetz's marshaller? Not yet. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Mon Jul 29 17:24:39 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Jul 2013 08:24:39 -0700 Subject: [Development] QtCS - QObject discussion In-Reply-To: <51F65945.7080304@familiesomers.nl> References: <11956916.eUnHlRGgNd@gargamel> <1524288.2oboCyU3HW@gargamel> <51F65945.7080304@familiesomers.nl> Message-ID: <1650997.V7Rd5IEoYr@tjmaciei-mobl2> On segunda-feira, 29 de julho de 2013 14:00:05, André Somers wrote: > > http://herbsutter.com/2012/06/21/reader-qa-why-dont-modern-smart-pointers-> > implicitly-convert-to/ > That would solve it, but I am not convinced either way. I am also not > convinced that not having to use .data() is worth the risk introducing > operator T*. At the very least the delete should then be disabled as well. There's no way to disable delete, aside from removing operator T*. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From faure at kde.org Mon Jul 29 19:35:14 2013 From: faure at kde.org (David Faure) Date: Mon, 29 Jul 2013 19:35:14 +0200 Subject: [Development] QtCS - QtDBus discussion In-Reply-To: <10264208.Yd9WpzHTWB@tjmaciei-mobl2> References: <6676314.eEVX7OCQ0t@tjmaciei-mobl2> <51F62E42.601@users.sourceforge.net> <10264208.Yd9WpzHTWB@tjmaciei-mobl2> Message-ID: <1474513.de8sRi6Gan@asterix> On Monday 29 July 2013 08:22:38 Thiago Macieira wrote: > On segunda-feira, 29 de julho de 2013 11:56:34, Alberto Mardegan wrote: > > Do you have any links for ahartmetz's marshaller? > > Not yet. AFAIK they're part of the great dbus GUI monitor that he wrote at git://anongit.kde.org/scratch/ahartmetz/d-sel.git (Note that the GUI monitor, dselrig, is only built if you install libtinyxml2, by hand on most distros). -- David Faure, faure at kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 From rdohm321 at gmail.com Mon Jul 29 19:34:18 2013 From: rdohm321 at gmail.com (Randolph D.) Date: Mon, 29 Jul 2013 19:34:18 +0200 Subject: [Development] Secure QT Messenger Message-ID: Hi, I know it´s about Qt. But it´s about Qt. See the Qt covering a secure Instant Messenger with strong multi-encryption of libgcrypt. http://goldbug.sourceforge.net/ In case you develop as well messaging apps, it might be of interest. Thanks Regards Randolph -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.faure at kdab.com Mon Jul 29 20:38:38 2013 From: david.faure at kdab.com (David Faure) Date: Mon, 29 Jul 2013 20:38:38 +0200 Subject: [Development] QCommandLineParser Message-ID: <2855890.qWvjrbRLAr@asterix> QCommandLineParser, which I intend to get into Qt 5.2, could use some more reviewing, and especially a +2 at some point :-) https://codereview.qt-project.org/58979 is the all-in-one commit for easier review. It includes https://codereview.qt-project.org/61746 which is specifically about the 3 parsing modes for "-abc" (option collapsing, implicitly long, or compiler mode). Discussion ongoing about Windows, maybe we don't need "/a" support at all, just "-"/"--" everywhere? On top of this, I ported some tools to it : https://codereview.qt-project.org/61079 ports uic. https://codereview.qt-project.org/61660 ports moc (which was the cause for the "compiler mode" in 61746). I also ported all of KDE Frameworks 5's executables. >From my point of view it's all ready to go in, as soon as the discussion in 61746 is resolved. There's one issue though, which Oswald raised: what if we want to use the parser for the internal parsing in qapp (which means QCoreApplication+QGuiApplication+QApplication)? This was initially my idea, but I discarded it because translations are not typically set up when entering the qapp constructors, apps typically do this later, and QCommandLineParser::addOption requires translated strings (I'm very much opposed to using QT_TRANSLATE_NOOP everywhere for this, after the KCmdLineArgs experience). So my idea was simply to have a --help-qt option which would delegate to qapp the adding of options for documentation purposes only, and not touching the builtin parsing at all. Now Oswald suggests that apps *could* set up QLocale and QTranslator before instanciating qapp, and therefore qapp could create a QCommandLineParser instance and feed its options into it, and use it for parsing. Not sure how much this can really work, Thiago always says Qt APIs shouldn't be used before the QCoreApp ctor (e.g. no local8Bit etc.). So it sounds a bit too experimental to me. This would also need some way to not pollute the main -- help output though, i.e. marking these options as belonging to --help-qt. Overall I'm afraid that this makes things more complex and more intrusive. API wise we'd have to reintroduce some QCoreApplication::commandLineParser() accessor so that the application adds its own options to the same parser. Which means it can't be done later, because it would mean porting every main() function from creating its own parser to reusing the one from qcoreapp. So after more thinking, here's my suggestion: * we keep the idea that every main() creates a parser on the stack. The current change request can go in (after more reviewing). * later if we want to use QCommandLineParser for the builtin qapp options, qcoreapp would create its own *separate* instance, and register it internally in qcoreapp (not public, unlike the previous idea). And the magic is that every parser instance would have a --help-qt option, which delegates to the qcoreapp-owned instance to print out the builtin options. So, this needs no new API either to mark these options as the ones for --help- qt, they are already separated in a different internal-only parser, not mixed with the application options. By the time we want to create a command-line parser internally in QCoreApp, we can sort out the translation setup -- possibly like in KDE where the translators got automatically loaded from standard paths, which means tr() can be used inside the qapp constructors. -- David Faure | david.faure at kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From andre at familiesomers.nl Mon Jul 29 21:26:59 2013 From: andre at familiesomers.nl (Andre Somers) Date: Mon, 29 Jul 2013 21:26:59 +0200 Subject: [Development] QtCS - QObject discussion In-Reply-To: <1650997.V7Rd5IEoYr@tjmaciei-mobl2> References: <11956916.eUnHlRGgNd@gargamel> <1524288.2oboCyU3HW@gargamel> <51F65945.7080304@familiesomers.nl> <1650997.V7Rd5IEoYr@tjmaciei-mobl2> Message-ID: <51F6C203.6010906@familiesomers.nl> Op 29-7-2013 17:24, Thiago Macieira schreef: > On segunda-feira, 29 de julho de 2013 14:00:05, André Somers wrote: >>> http://herbsutter.com/2012/06/21/reader-qa-why-dont-modern-smart-pointers-> > implicitly-convert-to/ >> That would solve it, but I am not convinced either way. I am also not >> convinced that not having to use .data() is worth the risk introducing >> operator T*. At the very least the delete should then be disabled as well. > There's no way to disable delete, aside from removing operator T*. There are some tricks against that. Andrei Alexandrescu describes one, if I'm not mistaken. I don't have the book next to me at this moment though. I think this stackoverflow post is inspired on that work: http://stackoverflow.com/questions/3312031/c-smart-pointer-template-that-auto-converts-to-bare-pointer-but-cant-be-exp/3312507#3312507 André From thiago.macieira at intel.com Mon Jul 29 22:40:53 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Jul 2013 13:40:53 -0700 Subject: [Development] QCommandLineParser In-Reply-To: <2855890.qWvjrbRLAr@asterix> References: <2855890.qWvjrbRLAr@asterix> Message-ID: <8873992.jRXHcz8HVE@tjmaciei-mobl2> On segunda-feira, 29 de julho de 2013 20:38:38, David Faure wrote: > Now Oswald suggests that apps *could* set up QLocale and QTranslator before > instanciating qapp, and therefore qapp could create a QCommandLineParser > instance and feed its options into it, and use it for parsing. Not sure how > much this can really work, Thiago always says Qt APIs shouldn't be used > before the QCoreApp ctor (e.g. no local8Bit etc.). So it sounds a bit too > experimental to me. Correct. QLocale sets itself up, which is not a problem. QTranslator takes filenames as parameters. That requires the locale 8-bit codec to be working. That *only* works after QCoreApplication has been instantiated. So I'm against using QTranslator before QCoreApplication. We should not recommend any mainstream API to be used before QCoreApplication. The creation of the application object should generally be the first thing in the main function. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Mon Jul 29 22:46:46 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Jul 2013 13:46:46 -0700 Subject: [Development] QCommandLineParser In-Reply-To: <2855890.qWvjrbRLAr@asterix> References: <2855890.qWvjrbRLAr@asterix> Message-ID: <1536927.Mg7syuaVU9@tjmaciei-mobl2> On segunda-feira, 29 de julho de 2013 20:38:38, David Faure wrote: > * later if we want to use QCommandLineParser for the builtin qapp options, > qcoreapp would create its own *separate* instance, and register it > internally in qcoreapp (not public, unlike the previous idea). And the > magic is that every parser instance would have a --help-qt option, which > delegates to the qcoreapp-owned instance to print out the builtin options. > So, this needs no new API either to mark these options as the ones for > --help- qt, they are already separated in a different internal-only parser, > not mixed with the application options. > > By the time we want to create a command-line parser internally in QCoreApp, > we can sort out the translation setup -- possibly like in KDE where the > translators got automatically loaded from standard paths, which means tr() > can be used inside the qapp constructors. I like this idea. The internal parser does not need to handle any help options, it might be at most used to simplify the handling of arguments that we already do have anyway. If a help output is required, it should come from the main application's parsing. In other words: we don't have --help-qt now and I don't see any point in adding one in the internal parser. That said, it might be a good idea to move some of the "Qt" options to the main help output where they are useful, like -geometry, keeping hidden only the really obscure ones that most people won't ever need. Also, I'd rather we didn't call them "Qt options", but simply something like "system options". The fact that Qt handles them is irrelevant. PS: the -plugin option has to go. Its name is too generic. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From nicolas.alvarez at gmail.com Mon Jul 29 22:50:35 2013 From: nicolas.alvarez at gmail.com (=?UTF-8?Q?Nicol=C3=A1s_Alvarez?=) Date: Mon, 29 Jul 2013 17:50:35 -0300 Subject: [Development] Is Xlib a hard requirement for Qt5 xcb? In-Reply-To: References: Message-ID: 2013/7/26 Nicolás Alvarez : > Hi everyone, > > I attempted to build Qt5 and KF5 in a minimal system, only installing > dependencies when configure/cmake asks for them, in order to find bugs > (such as missing dependency checks) in the build system. I was > successful, in the sense that I found missing checks :) > > I'm configuring Qt with the options suggested in the KF5 wiki: > ./configure -prefix $PWD/qtbase -opensource -developer-build > -nomake tests -nomake examples -dbus -no-separate-debug-info -xcb -qpa > xcb -no-gtkstyle -no-pch > > My minimal system does not have X11 development files (such as > Xlib.h), but it does have XCB stuff. > > Compilation fails with: > make[2]: Entering directory `/home/nicolas/src/qt5/qtbase/src/widgets' > util/qsystemtrayicon_x11.cpp:60:22: fatal error: X11/Xlib.h: No such > file or directory > make[2]: Leaving directory `/home/nicolas/src/qt5/qtbase/src/widgets' > > make[5]: Entering directory > `/home/nicolas/src/qt5/qtbase/src/plugins/platforms/xcb' > qxcbmime.cpp:49:23: fatal error: X11/Xutil.h: No such file or directory > qxcbcursor.cpp:52:28: fatal error: X11/cursorfont.h: No such file or directory > qxcbxsettings.cpp:46:36: fatal error: X11/extensions/XIproto.h: No > such file or directory > make[5]: Leaving directory > `/home/nicolas/src/qt5/qtbase/src/plugins/platforms/xcb' > > > The question is: is Qt5/XCB *supposed* to work without Xlib? I got the > feeling that there was some attempt to make it work, since some code > is protected with #ifdef XCB_USE_XLIB checks (though perhaps that > define is for something else?). If supposed to work, then it's > currently broken and likely needs some more ifdefs. If not supposed to > work, then the configure script should abort Xlib isn't present while > configuring for XCB. I'm interested in fixing it either way, but I > can't take the decision of what's supported :) I discussed the issue with Richard Moore on IRC: there's a bunch of stuff in the xcb plugin that requires xlib right now for example the system tray support i kind of started addressing that one https://codereview.qt-project.org/#change,48972 but i'm sure there are others i think i use xlib in qtx11extras too since i need to offer a Display my opinion is that the xcb port is still incomplete and should be regarded as xlib/xcb at the moment the configure script should reflect that so xlib should be required? yes the aim should be to remove the requirement though okay so, looking at the script... currently it always checks for X11 presence, and adds 'xlib' to QT_CONFIG on pass, does nothing on fail is there any platform/qpa/configuration/thing other than XCB where you'd want to check for and "enable" xlib support? not afaik ok, then my initial thought would be to move the test inside if [ "$CFG_XCB" != "no" ] and abort on test fail seems reasonable to me I'm working on a proper patch for this. -- Nicolás From robin+qt at viroteck.net Mon Jul 29 23:01:08 2013 From: robin+qt at viroteck.net (Robin Burchell) Date: Mon, 29 Jul 2013 23:01:08 +0200 Subject: [Development] QCommandLineParser In-Reply-To: <1536927.Mg7syuaVU9@tjmaciei-mobl2> References: <2855890.qWvjrbRLAr@asterix> <1536927.Mg7syuaVU9@tjmaciei-mobl2> Message-ID: On Mon, Jul 29, 2013 at 10:46 PM, Thiago Macieira wrote: > PS: the -plugin option has to go. Its name is too generic. I argued for that, and -platform to be 'namespaced' a long long time ago[1]. The idea was shot down, and while I wasn't exactly thrilled, I'd disagree with changing it now. Scripts, software, and whole distributions (speaking from personal experience) are making use of that argument in a lot of places. If you change it, a lot of things will break, and people will be unhappy. [1]: https://codereview.qt-project.org/#change,26325 BR, Robin From thiago.macieira at intel.com Tue Jul 30 03:10:34 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Jul 2013 18:10:34 -0700 Subject: [Development] QPA platform and plugin selection (was: QCommandLineParser) In-Reply-To: References: <2855890.qWvjrbRLAr@asterix> <1536927.Mg7syuaVU9@tjmaciei-mobl2> Message-ID: <1506719.yDtfEGp244@tjmaciei-mobl2> On segunda-feira, 29 de julho de 2013 23:01:08, Robin Burchell wrote: > On Mon, Jul 29, 2013 at 10:46 PM, Thiago Macieira > > wrote: > > PS: the -plugin option has to go. Its name is too generic. > > I argued for that, and -platform to be 'namespaced' a long long time > ago[1]. The idea was shot down, and while I wasn't exactly thrilled, > I'd disagree with changing it now. Scripts, software, and whole > distributions (speaking from personal experience) are making use of > that argument in a lot of places. If you change it, a lot of things > will break, and people will be unhappy. > > [1]: https://codereview.qt-project.org/#change,26325 Those things should be handled in the environment. Command-line use of - platform and -plugin are *ONLY* for software developers to test things out. Here's why: suppose I am on my traditional X11-based Linux desktop and start a Wayland compositor (e.g., Weston) and want to test a Qt Gui application, which spawns a second application from inside (QProcess proc; proc.start("app- helper");). If I do: ./appname -platform wayland The parent application will show on Wayland, but the child application will will show on X, since it has no command-line arguments telling it to use Wayland. If I do: QT_QPA_PLATFORM=wayland ./appname Then both the parent and child applications will show on Wayland. Now, since both forms are equally easy for a developer to type, I'd argue we should deprecate and remove the command-line options in future versions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From Friedemann.Kleint at digia.com Tue Jul 30 08:31:55 2013 From: Friedemann.Kleint at digia.com (Friedemann Kleint) Date: Tue, 30 Jul 2013 08:31:55 +0200 Subject: [Development] Is Xlib a hard requirement for Qt5 xcb? In-Reply-To: References: Message-ID: <51F75DDB.4090908@digia.com> Hi, i kind of started addressing that one https://codereview.qt-project.org/#change,48972 but i'm sure there are others For the system tray, I have been working on https://codereview.qt-project.org/#change,61046 which would remove QtWidget's dependency on Xlib. Very ideally, the system tray would be completely implemented within the platform plugin, but that is not possible since it needs menus and tooltip handling. Regards, Friedemann -- Friedemann Kleint Digia, Qt From thiago.macieira at intel.com Tue Jul 30 09:17:30 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Jul 2013 00:17:30 -0700 Subject: [Development] Is Xlib a hard requirement for Qt5 xcb? In-Reply-To: <51F75DDB.4090908@digia.com> References: <51F75DDB.4090908@digia.com> Message-ID: <8490878.Ku4GAiqPp8@tjmaciei-mobl2> On terça-feira, 30 de julho de 2013 08:31:55, Friedemann Kleint wrote: > Hi, > > i kind of started addressing that one > https://codereview.qt-project.org/#change,48972 but i'm sure there are > others > > For the system tray, I have been working on > https://codereview.qt-project.org/#change,61046 which would remove > QtWidget's dependency on Xlib. > Very ideally, the system tray would be completely implemented within the > platform plugin, but that is not possible since it needs menus and > tooltip handling. Drop the old protocol and implement only the new D-Bus-based status notifier protocol. The tooltips and menus are drawn by the systray host application. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From oswald.buddenhagen at digia.com Tue Jul 30 10:14:33 2013 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Tue, 30 Jul 2013 10:14:33 +0200 Subject: [Development] Is Xlib a hard requirement for Qt5 xcb? In-Reply-To: <8490878.Ku4GAiqPp8@tjmaciei-mobl2> References: <51F75DDB.4090908@digia.com> <8490878.Ku4GAiqPp8@tjmaciei-mobl2> Message-ID: <20130730081433.GA27251@troll08.it.local> On Tue, Jul 30, 2013 at 12:17:30AM -0700, Thiago Macieira wrote: > On terça-feira, 30 de julho de 2013 08:31:55, Friedemann Kleint wrote: > > For the system tray, I have been working on > > https://codereview.qt-project.org/#change,61046 which would remove > > QtWidget's dependency on Xlib. > > Very ideally, the system tray would be completely implemented within the > > platform plugin, but that is not possible since it needs menus and > > tooltip handling. > > Drop the old protocol and implement only the new D-Bus-based status notifier > protocol. > you are being a tad optimistic here ... qt isn't exactly in a position to dictate the platform to the end users of qt-based applications. the timeframe for universal adoption of the new system tray protocol is 5-10 more years. not to mention that i (and probably some others as well) think it is inherently broken to detach the systray's protocol layer from the windowing system ... From oswald.buddenhagen at digia.com Tue Jul 30 10:30:41 2013 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Tue, 30 Jul 2013 10:30:41 +0200 Subject: [Development] QCommandLineParser In-Reply-To: <2855890.qWvjrbRLAr@asterix> References: <2855890.qWvjrbRLAr@asterix> Message-ID: <20130730083041.GB27251@troll08.it.local> On Mon, Jul 29, 2013 at 08:38:38PM +0200, David Faure wrote: > So after more thinking, here's my suggestion: > * we keep the idea that every main() creates a parser on the stack. The > current change request can go in (after more reviewing). > * later if we want to use QCommandLineParser for the builtin qapp options, > qcoreapp would create its own *separate* instance, > note that i already commented on that, too. the problem with any kind of separate parser is that if two independent parsers try to process the same command line, you are bound for anomalies, specifically one parser interpreting as options what the other parser would see as arguments to other options. the cleanest solution would be entirely discarding the qapp-internal parsing and having the user-supplied parser explicitly fed into qapp (fwiw, that's what app developers want anyway. i have already fed fake command lines to qapp just to make it happy). however, due to the instantiation order constraints that would mean delaying the cmdline-dependent setup in qapp, which is said to be tricky ... From simon.hausmann at digia.com Tue Jul 30 11:49:35 2013 From: simon.hausmann at digia.com (Simon Hausmann) Date: Tue, 30 Jul 2013 11:49:35 +0200 Subject: [Development] API for multiple (but variable number of) return arguments In-Reply-To: <51F394B8.6030006@familiesomers.nl> References: <51F394B8.6030006@familiesomers.nl> Message-ID: <2845187.SVq4ITjxpn@rhea> On Saturday 27. July 2013 11.36.56 Andre Somers wrote: > Hi, > > It has been quite awhile, but I'd like to finally pick up QTimeSpan > again and this time really get it into Qt. The idea of this class is > that it represents a duration of time, optionally anchored to a point in > time, and can output and parse this data to and from strings in > different formats, including using 'natural' units like years or months > for long time spans. One of the thing I'd like to do is shrink and > simplify the API before submitting it. > > It is not the idea of QTimeSpan in itself that I'd like to discuss, but > one API issue I'm currently looking at. > > For the sake of discussion, let's assume that we have the following already: > namespace Qt { > enum TimeSpanUnit { > Years = 0x01, > Months = 0x02, > Weeks = 0x04, > Days = 0x08, > Hours = 0x10, > Minutes = 0x20, > Seconds = 0x40, > MilliSeconds = 0x80 > }; > Q_DECLARE_FLAGS(TimeSpanFormat, TimeSpanUnit); > }; > > In order to get a time span in the units that you'd like to use, you > need a function that can somehow return the values for all these units > at the same time, because in order to calculate the number of days, you > also need to know if the user also requested the number of weeks > (compare "23 days" with "3 weeks, 2 days"). Ideally, there would be a > return value as well to indicate success or failure, because time spans > without an anchor date cannot be expressed as months or years. > > There are several ways to write a (member) function to do this. This is > what I came up with so far: > > 1) pointers to ints > bool getUnits(int* years, int* monts = 0, int* weeks = 0, int* days = 0, > int* hours = 0, int* minutes = 0, int* seconds = 0, int* milliSeconds = 0); > > Every argument may be 0, in which case this unit is considered as > not-used. This works (I have this in the current version of QTimeSpan), > but it is not a very nice API to work with. If you're interested in > minutes and seconds, you end up with a call like this: > > int minutes, seconds; > if (getUnits(0,0,0,0,0, &minutes, &seconds)) > { ...} > > 2) returning a map > QMap getUnits(Qt::TimeSpanFormat); > > In this case, the units to use are encoded in a single flag, and the > result is a single data structure. I guess the easiest way to return > failure is to return an empty map. The equivalent call from the first > option would look like: > > int minutes, seconds; > QMap result = getUnits(Qt::Minutes | Qt::Seconds); > if (!result.isEmpty()) { > minutes = result.value(Qt::Minutes); > seconds = result.value(Qt::Seconds); > }; > > In my opinion, not all that great either, but better than 1). It may be > a benefit to have the results in a data structure that's easy to pass > along in one go, but if you don't want that, getting them out is a bit > of a hassle perhaps. > > 3) QString::arg like API > An interesting option is to do something like this: > > int minutes, seconds; > if ( getUnits().unit(Qt::Minutes, minutes).unit(Qt::Seconds, seconds) ) { > //blah > }; > > Downside is that it allows specifying the same unit multiple times. That > does not need to be a real problem (simply return the same value more > than once), but it may look weird. Also, this API is implementation wise > quite a bit more complex than the previous options. The resulting code > is more verbose than option 1, but much easier to read. > > 4) separate requests > Another option is not return all relevant units in one go, but to use > multiple function calls: > int getUnit(Qt::TimeSpanFormat format, Qt::TimeSpanUnit unit); > > Failure would return -1. The example would yield: > > Qt::TimeSpanFormat format = Qt::Minutes | Qt::Seconds; > int minutes = getUnit(format, Qt::Minutes); > int seconds = getUnit(format, Qt::Seconds); > if (minutes >= 0 && seconds >=0) { > //blah > } > > Downside is that in order to make this efficient, you'd need to cache > the result, otherwise you have to reconstruct it for every call with the > same format. Personally, I don't like having to make multiple function > calls to retrieve parts of the same answer. Also, there are > opportunities for errors here, such as asking for units that are not in > the format. > > I guess there are more options, but these four are the more serious > candidates I could come up with. Did I overlook a good candidate? Where > are other examples in the Qt API where there were similar needs, so I > can look if their patterns may apply here? > > Anyway, I am looking for feedback. Say that this will be included in Qt > some day, what is the most Qt-like API in your opinion? My favourite among those options is basically number 4. A property based API with as many getters are needed. It creates readable code, the implementation can take care of making things fast (caching) and it maps perfectly to JavaScript as well. There is also the option of an API similar to QURL where the getter takes a parameter that describes how the returned value should be formatted, but that unfortunately doesn't really map to property "intense" languages like QML/JS. Simon From Jan-Arve.Saether at digia.com Tue Jul 30 12:21:11 2013 From: Jan-Arve.Saether at digia.com (Saether Jan-Arve) Date: Tue, 30 Jul 2013 10:21:11 +0000 Subject: [Development] QCommandLineParser In-Reply-To: <2855890.qWvjrbRLAr@asterix> References: <2855890.qWvjrbRLAr@asterix> Message-ID: <66BFFE861C7DE34D9B0372D8EAAB18E2BCD272@IT-EXMB01-HKI.it.local> Hi. Although this is not necessary for 5.2, I have two feature requests: 1. Have support for "response files", (or @option-file as the moc patch calls it). People shouldn't have to implement that for every tool that needs it, and all Qt based apps that needs response files should use_the_same_syntax. 2. Standardize value lists so that they work across shells I.e. this doesn't work in all shells: ./init-repository --module-subset=qtbase,qtsvg Problem is that comma is an argument separator in MS Powershell, the result is that Powershell will effectively call the process with two arguments: ./init-repository --module-subset=qtbase qtsvg It would be great if QCommandLineParser could help people not to shoot themselves in the foot if they want to accept a list of values. Jan-Arve > -----Original Message----- > From: development-bounces+jan-arve.saether=digia.com at qt-project.org > [mailto:development-bounces+jan-arve.saether=digia.com at qt-project.org] > On Behalf Of David Faure > Sent: 29. juli 2013 20:39 > To: development at qt-project.org > Subject: [Development] QCommandLineParser > QCommandLineParser, which I intend to get into Qt 5.2, could use some > more reviewing, and especially a +2 at some point :-) > > https://codereview.qt-project.org/58979 is the all-in-one commit for > easier review. > > It includes https://codereview.qt-project.org/61746 which is > specifically about the 3 parsing modes for "-abc" (option collapsing, > implicitly long, or compiler mode). Discussion ongoing about Windows, > maybe we don't need "/a" > support at all, just "-"/"--" everywhere? > > On top of this, I ported some tools to it : > > https://codereview.qt-project.org/61079 ports uic. > > https://codereview.qt-project.org/61660 ports moc (which was the cause > for the "compiler mode" in 61746). > > I also ported all of KDE Frameworks 5's executables. > >> From my point of view it's all ready to go in, as soon as the >> discussion in > 61746 is resolved. > > There's one issue though, which Oswald raised: what if we want to use > the parser for the internal parsing in qapp (which means > QCoreApplication+QGuiApplication+QApplication)? This was initially my > idea, but I discarded it because translations are not typically set up > when entering the qapp constructors, apps typically do this later, and > QCommandLineParser::addOption requires translated strings (I'm very much > opposed to using QT_TRANSLATE_NOOP everywhere for this, after the > KCmdLineArgs experience). > > So my idea was simply to have a --help-qt option which would delegate to > qapp the adding of options for documentation purposes only, and not > touching the builtin parsing at all. Now Oswald suggests that apps > *could* set up QLocale and QTranslator before instanciating qapp, and > therefore qapp could create a QCommandLineParser instance and feed its > options into it, and use it for parsing. Not sure how much this can > really work, Thiago always says Qt APIs shouldn't be used before the > QCoreApp ctor (e.g. no local8Bit etc.). So it sounds a bit too > experimental to me. This would also need some way to not pollute the > main -- help output though, i.e. marking these options as belonging to > --help-qt. Overall I'm afraid that this makes things more complex and > more intrusive. API wise we'd have to reintroduce some > QCoreApplication::commandLineParser() accessor so that the application > adds its own options to the same parser. Which means it can't be done > later, because it would mean porting every main() function from creating > its own parser to reusing the one from qcoreapp. > > So after more thinking, here's my suggestion: > * we keep the idea that every main() creates a parser on the stack. > The current change request can go in (after more reviewing). > * later if we want to use QCommandLineParser for the builtin qapp > options, qcoreapp would create its own *separate* instance, and > register it internally in qcoreapp (not public, unlike the previous > idea). And the magic is that every parser instance would have a > --help- qt option, which delegates to the qcoreapp-owned instance to > print out the builtin options. > So, this needs no new API either to mark these options as the ones for > --help- qt, they are already separated in a different internal-only > parser, not mixed with the application options. > > By the time we want to create a command-line parser internally in > QCoreApp, we can sort out the translation setup -- possibly like in > KDE where the translators got automatically loaded from standard > paths, which means tr() can be used inside the qapp constructors. > From Rafal.Motyka at digia.com Tue Jul 30 12:40:38 2013 From: Rafal.Motyka at digia.com (Motyka Rafal) Date: Tue, 30 Jul 2013 10:40:38 +0000 Subject: [Development] Bug management and jira workflow In-Reply-To: <201307231325.44951.jedrzej.nowacki@digia.com> References: <201307231325.44951.jedrzej.nowacki@digia.com> Message-ID: Hello, This clarification was needed: " - What does it mean “fixed version” in bug report - we do not fill it until an issue is really fixed, which means merged - we do not want to use the field for estimation" Otherwise, having a field with two different meanings (like ‘fixed in’ and ‘planned to be fixed in’) would lead to confusion. Thanks! Regards, /Rafal Rafal Motyka Quality Assurance Digia, Qt Email: rafal.motyka at 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. ----------------------------------------------------------------- -----Original Message----- From: development-bounces+rafal.motyka=digia.com at qt-project.org [mailto:development-bounces+rafal.motyka=digia.com at qt-project.org] On Behalf Of Jedrzej Nowacki Sent: 23. juli 2013 13:26 To: development at qt-project.org Subject: [Development] Bug management and jira workflow Hi, At the Qt Contributor Summit, we had a really good discussion about bugs and jira, here is the summary: - We have untriaged bugs, we may not be able to triage them all, but we should keep it’s count as low as possible. - We agreed on “triaging” definition. Triaging consist of: - checking if a bug report is sensible. It means the reported issue is not a result of a user mistake, use of undefined behavior etc. - checking if a bug report is not missing an important data, so it would be possible to reproduce it in future - setting a priority - optionally the bug report may be verified. It it is reproduced then it should be accept which means moved to open state Rationale: It looks like the most common behavior of people triaging bugs. - Who can prioritize bugs? - whoever ask - we will create a special group in jira - approvers should be in the group by default Rationale: We do not have man power and we need help. We do not expect anyone to destroy our precious bugs reports or play “ping pong” with a priority. - What does it mean “fixed version” in bug report - we do not fill it until an issue is really fixed, which means merged - we do not want to use the field for estimation - we know that it can be filled automatically, it would be nice to implement that. - Jira workflow was designed for much bigger team, that includes QA department, it should be simplify - We decided that “in progress” state means that someone started work on a bug or it have a fix which is not merged yet. Time statistics doesn’t show anything, anyway. - Resolved, Verified and Closed should be merged to a single state. Nobody is going through Resloved bugs to verify them. - It would be nice to have a transition from Open to Closed state Cheers, Jędrek _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at hanssen.name Tue Jul 30 12:54:28 2013 From: andreas at hanssen.name (Andreas Aardal Hanssen) Date: Tue, 30 Jul 2013 12:54:28 +0200 Subject: [Development] QCommandLineParser In-Reply-To: <66BFFE861C7DE34D9B0372D8EAAB18E2BCD272@IT-EXMB01-HKI.it.local> References: <2855890.qWvjrbRLAr@asterix> <66BFFE861C7DE34D9B0372D8EAAB18E2BCD272@IT-EXMB01-HKI.it.local> Message-ID: I can't help getting the feeling that the community is about to make the same mistake again regarding command line parsing in Qt. My $0.02 is to make something that's ridiculously simple, or cancel the whole project. We already have other options for complex cases. Qt apps traditionally don't take complex arguments and they really shouldn't. Simple -foo blah is enough, and it works the same way on all platforms. Please don't overengineer this parser. Don't make platform specifics like '/' on Windows and '--foo=blah' on Unix. Remember that most folks just make a for loop to check arguments, i.e., if (arguments.at(i) == "-fullscreen") { fullScreen = true; }. The Qt API must be simpler than this, and it's really hard to get there if this class is to support all kinds of crap. Gad'dam.. ;-) Andreas... 2013/7/30 Saether Jan-Arve > Hi. > Although this is not necessary for 5.2, I have two feature requests: > > > 1. Have support for "response files", (or @option-file as the moc patch > calls it). > > People shouldn't have to implement that for every tool that needs it, and > all Qt based apps that needs response files should use_the_same_syntax. > > > > 2. Standardize value lists so that they work across shells > > I.e. this doesn't work in all shells: > > ./init-repository --module-subset=qtbase,qtsvg > > Problem is that comma is an argument separator in MS Powershell, the > result is that Powershell will effectively call the process with two > arguments: > > ./init-repository --module-subset=qtbase qtsvg > > It would be great if QCommandLineParser could help people not to shoot > themselves in the foot if they want to accept a list of values. > > > Jan-Arve > > > -----Original Message----- > > From: development-bounces+jan-arve.saether=digia.com at qt-project.org > > [mailto:development-bounces+jan-arve.saether=digia.com at qt-project.org] > > On Behalf Of David Faure > > Sent: 29. juli 2013 20:39 > > To: development at qt-project.org > > Subject: [Development] QCommandLineParser > > QCommandLineParser, which I intend to get into Qt 5.2, could use some > > more reviewing, and especially a +2 at some point :-) > > > > https://codereview.qt-project.org/58979 is the all-in-one commit for > > easier review. > > > > It includes https://codereview.qt-project.org/61746 which is > > specifically about the 3 parsing modes for "-abc" (option collapsing, > > implicitly long, or compiler mode). Discussion ongoing about Windows, > > maybe we don't need "/a" > > support at all, just "-"/"--" everywhere? > > > > On top of this, I ported some tools to it : > > > > https://codereview.qt-project.org/61079 ports uic. > > > > https://codereview.qt-project.org/61660 ports moc (which was the cause > > for the "compiler mode" in 61746). > > > > I also ported all of KDE Frameworks 5's executables. > > > >> From my point of view it's all ready to go in, as soon as the > >> discussion in > > 61746 is resolved. > > > > There's one issue though, which Oswald raised: what if we want to use > > the parser for the internal parsing in qapp (which means > > QCoreApplication+QGuiApplication+QApplication)? This was initially my > > idea, but I discarded it because translations are not typically set up > > when entering the qapp constructors, apps typically do this later, and > > QCommandLineParser::addOption requires translated strings (I'm very much > > opposed to using QT_TRANSLATE_NOOP everywhere for this, after the > > KCmdLineArgs experience). > > > > So my idea was simply to have a --help-qt option which would delegate to > > qapp the adding of options for documentation purposes only, and not > > touching the builtin parsing at all. Now Oswald suggests that apps > > *could* set up QLocale and QTranslator before instanciating qapp, and > > therefore qapp could create a QCommandLineParser instance and feed its > > options into it, and use it for parsing. Not sure how much this can > > really work, Thiago always says Qt APIs shouldn't be used before the > > QCoreApp ctor (e.g. no local8Bit etc.). So it sounds a bit too > > experimental to me. This would also need some way to not pollute the > > main -- help output though, i.e. marking these options as belonging to > > --help-qt. Overall I'm afraid that this makes things more complex and > > more intrusive. API wise we'd have to reintroduce some > > QCoreApplication::commandLineParser() accessor so that the application > > adds its own options to the same parser. Which means it can't be done > > later, because it would mean porting every main() function from creating > > its own parser to reusing the one from qcoreapp. > > > > So after more thinking, here's my suggestion: > > * we keep the idea that every main() creates a parser on the stack. > > The current change request can go in (after more reviewing). > > * later if we want to use QCommandLineParser for the builtin qapp > > options, qcoreapp would create its own *separate* instance, and > > register it internally in qcoreapp (not public, unlike the previous > > idea). And the magic is that every parser instance would have a > > --help- qt option, which delegates to the qcoreapp-owned instance to > > print out the builtin options. > > So, this needs no new API either to mark these options as the ones for > > --help- qt, they are already separated in a different internal-only > > parser, not mixed with the application options. > > > > By the time we want to create a command-line parser internally in > > QCoreApp, we can sort out the translation setup -- possibly like in > > KDE where the translators got automatically loaded from standard > > paths, which means tr() can be used inside the qapp constructors. > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Andreas Aardal Hanssen -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexander.Blasche at digia.com Tue Jul 30 13:00:22 2013 From: Alexander.Blasche at digia.com (Blasche Alexander) Date: Tue, 30 Jul 2013 11:00:22 +0000 Subject: [Development] Bug management and jira workflow In-Reply-To: References: <201307231325.44951.jedrzej.nowacki@digia.com> Message-ID: Now I am confused. We don’t want to use “Fixed Version” for estimation. At the same time you say having two different fields is confusing. How do I set an estimation value? There must be a way to specify the estimation/target. Please don’t offer the Meta task for release x.y option or just a comment. A filter must be able to find the tasks planned for release x.y . -- Alex From: development-bounces+alexander.blasche=digia.com at qt-project.org [mailto:development-bounces+alexander.blasche=digia.com at qt-project.org] On Behalf Of Motyka Rafal Sent: Tuesday, 30 July 2013 12:41 To: Nowacki Jedrzej; development at qt-project.org Subject: Re: [Development] Bug management and jira workflow Hello, This clarification was needed: " - What does it mean “fixed version” in bug report - we do not fill it until an issue is really fixed, which means merged - we do not want to use the field for estimation" Otherwise, having a field with two different meanings (like ‘fixed in’ and ‘planned to be fixed in’) would lead to confusion. Thanks! Regards, /Rafal Rafal Motyka Quality Assurance Digia, Qt Email: rafal.motyka at 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. ----------------------------------------------------------------- -----Original Message----- From: development-bounces+rafal.motyka=digia.com at qt-project.org [mailto:development-bounces+rafal.motyka=digia.com at qt-project.org] On Behalf Of Jedrzej Nowacki Sent: 23. juli 2013 13:26 To: development at qt-project.org Subject: [Development] Bug management and jira workflow Hi, At the Qt Contributor Summit, we had a really good discussion about bugs and jira, here is the summary: - We have untriaged bugs, we may not be able to triage them all, but we should keep it’s count as low as possible. - We agreed on “triaging” definition. Triaging consist of: - checking if a bug report is sensible. It means the reported issue is not a result of a user mistake, use of undefined behavior etc. - checking if a bug report is not missing an important data, so it would be possible to reproduce it in future - setting a priority - optionally the bug report may be verified. It it is reproduced then it should be accept which means moved to open state Rationale: It looks like the most common behavior of people triaging bugs. - Who can prioritize bugs? - whoever ask - we will create a special group in jira - approvers should be in the group by default Rationale: We do not have man power and we need help. We do not expect anyone to destroy our precious bugs reports or play “ping pong” with a priority. - What does it mean “fixed version” in bug report - we do not fill it until an issue is really fixed, which means merged - we do not want to use the field for estimation - we know that it can be filled automatically, it would be nice to implement that. - Jira workflow was designed for much bigger team, that includes QA department, it should be simplify - We decided that “in progress” state means that someone started work on a bug or it have a fix which is not merged yet. Time statistics doesn’t show anything, anyway. - Resolved, Verified and Closed should be merged to a single state. Nobody is going through Resloved bugs to verify them. - It would be nice to have a transition from Open to Closed state Cheers, Jędrek _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorgen.lind at gmail.com Tue Jul 30 13:21:08 2013 From: jorgen.lind at gmail.com (=?UTF-8?B?SsO4cmdlbiBMaW5k?=) Date: Tue, 30 Jul 2013 13:21:08 +0200 Subject: [Development] Is Xlib a hard requirement for Qt5 xcb? In-Reply-To: References: Message-ID: >From what I can remember, the xlib dependency was introduced into the xcb backend because glx requires it, as it needs the xlib display. Since most people want to use glx then it has become a defacto dependency. Then it would seem that porting old functionality to the xcb backend has been simplified by having the xlib dependency. I don't think its a big problem to have the dependency there, but we should also keep in mind that it should be a long term goal not to have the dependency. Jørgen On 26 July 2013 23:19, Nicolás Alvarez wrote: > Hi everyone, > > I attempted to build Qt5 and KF5 in a minimal system, only installing > dependencies when configure/cmake asks for them, in order to find bugs > (such as missing dependency checks) in the build system. I was > successful, in the sense that I found missing checks :) > > I'm configuring Qt with the options suggested in the KF5 wiki: > ./configure -prefix $PWD/qtbase -opensource -developer-build > -nomake tests -nomake examples -dbus -no-separate-debug-info -xcb -qpa > xcb -no-gtkstyle -no-pch > > My minimal system does not have X11 development files (such as > Xlib.h), but it does have XCB stuff. > > Compilation fails with: > make[2]: Entering directory `/home/nicolas/src/qt5/qtbase/src/widgets' > util/qsystemtrayicon_x11.cpp:60:22: fatal error: X11/Xlib.h: No such > file or directory > make[2]: Leaving directory `/home/nicolas/src/qt5/qtbase/src/widgets' > > make[5]: Entering directory > `/home/nicolas/src/qt5/qtbase/src/plugins/platforms/xcb' > qxcbmime.cpp:49:23: fatal error: X11/Xutil.h: No such file or directory > qxcbcursor.cpp:52:28: fatal error: X11/cursorfont.h: No such file or directory > qxcbxsettings.cpp:46:36: fatal error: X11/extensions/XIproto.h: No > such file or directory > make[5]: Leaving directory > `/home/nicolas/src/qt5/qtbase/src/plugins/platforms/xcb' > > > The question is: is Qt5/XCB *supposed* to work without Xlib? I got the > feeling that there was some attempt to make it work, since some code > is protected with #ifdef XCB_USE_XLIB checks (though perhaps that > define is for something else?). If supposed to work, then it's > currently broken and likely needs some more ifdefs. If not supposed to > work, then the configure script should abort Xlib isn't present while > configuring for XCB. I'm interested in fixing it either way, but I > can't take the decision of what's supported :) > > -- > Nicolás > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Shawn.Rutledge at digia.com Tue Jul 30 13:43:10 2013 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Tue, 30 Jul 2013 11:43:10 +0000 Subject: [Development] Is Xlib a hard requirement for Qt5 xcb? In-Reply-To: References: Message-ID: <110B496E-4229-4825-AA29-F9F1BDD55B66@digia.com> On 30 Jul 2013, at 1:21 PM, Jørgen Lind wrote: > From what I can remember, the xlib dependency was introduced into the > xcb backend because glx requires it, as it needs the xlib display. > Since most people want to use glx then it has become a defacto > dependency. Then it would seem that porting old functionality to the > xcb backend has been simplified by having the xlib dependency. If it's only glx, then maybe the goal should be that xlib shouldn't be necessary when using EGL, or no OpenGL at all (in which case you could still have widgets anyway), right? From Andy.Shaw at digia.com Tue Jul 30 13:47:13 2013 From: Andy.Shaw at digia.com (Shaw Andy) Date: Tue, 30 Jul 2013 11:47:13 +0000 Subject: [Development] Is Xlib a hard requirement for Qt5 xcb? In-Reply-To: <110B496E-4229-4825-AA29-F9F1BDD55B66@digia.com> References: <110B496E-4229-4825-AA29-F9F1BDD55B66@digia.com> Message-ID: <390F5BC42929B24288054D805FD5C3B91B983DED@IT-EXMB01-HKI.it.local> > On 30 Jul 2013, at 1:21 PM, Jørgen Lind wrote: > > > From what I can remember, the xlib dependency was introduced into the > > xcb backend because glx requires it, as it needs the xlib display. > > Since most people want to use glx then it has become a defacto > > dependency. Then it would seem that porting old functionality to the > > xcb backend has been simplified by having the xlib dependency. > > If it's only glx, then maybe the goal should be that xlib shouldn't be necessary > when using EGL, or no OpenGL at all (in which case you could still have > widgets anyway), right? That would be good if we could do that, then it may be possible to get static builds "working" further on Linux. Currently the fact that xcb depends on EGL is making it difficult. Andy From Lars.Knoll at digia.com Tue Jul 30 14:09:14 2013 From: Lars.Knoll at digia.com (Knoll Lars) Date: Tue, 30 Jul 2013 12:09:14 +0000 Subject: [Development] Nominating Kevin Ottens as Approver In-Reply-To: <51F2B258.9050600@kdab.com> Message-ID: On 26.07.13 19:31, "Sean Harmer" wrote: >On 23/07/2013 14:11, Frederik Gladhorn wrote: >> Hi, >> >> I would like to nominate Kevin Ottens as approver for the Qt Project. >> >> Kevin has been working on KDE for a long time and has lately worked >>hard to >> get more patches into Qt especially as part of KDE Frameworks 5. >> >> You can find him on IRC as "ervin" and he works at KDAB. >> >> His dashboard: >> https://codereview.qt-project.org/#dashboard,1001931 >> https://codereview.qt-project.org/#q,owner:Kevin%252BOttens,n,z >> >> His list of reviews: >> https://codereview.qt-project.org/#q,reviewer:Kevin%252BOttens,n,z >> >> >+1 Another +1 :) Cheers, Lars From oswald.buddenhagen at digia.com Tue Jul 30 14:14:56 2013 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Tue, 30 Jul 2013 14:14:56 +0200 Subject: [Development] Bug management and jira workflow In-Reply-To: References: <201307231325.44951.jedrzej.nowacki@digia.com> Message-ID: <20130730121456.GA13428@troll08.it.local> On Tue, Jul 30, 2013 at 11:00:22AM +0000, Blasche Alexander wrote: > Now I am confused. We don’t want to use “Fixed Version” for estimation. At the same time you say having two different fields is confusing. > > How do I set an estimation value? There must be a way to specify the estimation/target. Please don’t offer the Meta task for release x.y option or just a comment. A filter must be able to find the tasks planned for release x.y . > deadline != estimation From david.faure at kdab.com Tue Jul 30 14:35:39 2013 From: david.faure at kdab.com (David Faure) Date: Tue, 30 Jul 2013 14:35:39 +0200 Subject: [Development] QCommandLineParser In-Reply-To: <20130730083041.GB27251@troll08.it.local> References: <2855890.qWvjrbRLAr@asterix> <20130730083041.GB27251@troll08.it.local> Message-ID: <4450816.6R7a77xjzv@asterix> On Tuesday 30 July 2013 10:30:41 Oswald Buddenhagen wrote: > On Mon, Jul 29, 2013 at 08:38:38PM +0200, David Faure wrote: > > So after more thinking, here's my suggestion: > > * we keep the idea that every main() creates a parser on the stack. The > > current change request can go in (after more reviewing). > > * later if we want to use QCommandLineParser for the builtin qapp options, > > qcoreapp would create its own *separate* instance, > > note that i already commented on that, too. > the problem with any kind of separate parser is that if two independent > parsers try to process the same command line, you are bound for > anomalies, specifically one parser interpreting as options what the > other parser would see as arguments to other options. This is already the case though. The builtin parsing in qapp can't know that some arguments are in fact option values from the app's point of view. So yeah, app -title -reverse is broken already if the app defines (later) that -title takes a value, and would remain broken (qapp will activate reverse mode). We can't do much about that, can we (given the constraints of qcoreapp running before the options from main are added)? It's really corner case IMHO. Option values starting with a '-' are really uncommon. > the cleanest solution would be entirely discarding the qapp-internal > parsing and having the user-supplied parser explicitly fed into qapp > (fwiw, that's what app developers want anyway. i have already fed fake > command lines to qapp just to make it happy). > however, due to the instantiation order constraints that would mean > delaying the cmdline-dependent setup in qapp, which is said to be tricky > ... Exactly. So I don't consider this an option. Cleanest doesn't always agree with history. -- David Faure | david.faure at kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From bm_witness at yahoo.com Tue Jul 30 15:28:04 2013 From: bm_witness at yahoo.com (BRM) Date: Tue, 30 Jul 2013 06:28:04 -0700 (PDT) Subject: [Development] QCommandLineParser In-Reply-To: <66BFFE861C7DE34D9B0372D8EAAB18E2BCD272@IT-EXMB01-HKI.it.local> References: <2855890.qWvjrbRLAr@asterix> <66BFFE861C7DE34D9B0372D8EAAB18E2BCD272@IT-EXMB01-HKI.it.local> Message-ID: <1375190884.61903.YahooMailNeo@web126203.mail.ne1.yahoo.com> > From: Saether Jan-Arve >To: David Faure ; "development at qt-project.org" >Sent: Tuesday, July 30, 2013 6:21 AM >Subject: Re: [Development] QCommandLineParser >2. Standardize value lists so that they work across shells >I.e. this doesn't work in all shells: > >./init-repository --module-subset=qtbase,qtsvg > >Problem is that comma is an argument separator in MS Powershell, the result is that Powershell will effectively call the process with two arguments: >  >./init-repository --module-subset=qtbase qtsvg > >It would be great if QCommandLineParser could help people not to shoot themselves in the foot if they want to accept a list of values. I doubt that is doable as there are far too many shells out there that have all kinds of different behavior. I would suggest, rather, that you simply note that the correct method for that shell would be to do the following instead: ./init-repository --module-subset="qtbase,qtsvg" Or simply do not use that shell. $0.02 Ben From Shawn.Rutledge at digia.com Tue Jul 30 15:56:11 2013 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Tue, 30 Jul 2013 13:56:11 +0000 Subject: [Development] QCommandLineParser In-Reply-To: <1375190884.61903.YahooMailNeo@web126203.mail.ne1.yahoo.com> References: <2855890.qWvjrbRLAr@asterix> <66BFFE861C7DE34D9B0372D8EAAB18E2BCD272@IT-EXMB01-HKI.it.local> <1375190884.61903.YahooMailNeo@web126203.mail.ne1.yahoo.com> Message-ID: On 30 Jul 2013, at 3:28 PM, BRM wrote: >> From: Saether Jan-Arve > >> To: David Faure ; "development at qt-project.org" >> Sent: Tuesday, July 30, 2013 6:21 AM >> Subject: Re: [Development] QCommandLineParser >> 2. Standardize value lists so that they work across shells >> I.e. this doesn't work in all shells: >> >> ./init-repository --module-subset=qtbase,qtsvg >> >> Problem is that comma is an argument separator in MS Powershell, the result is that Powershell will effectively call the process with two arguments: >> >> ./init-repository --module-subset=qtbase qtsvg >> >> It would be great if QCommandLineParser could help people not to shoot themselves in the foot if they want to accept a list of values. > > > I doubt that is doable as there are far too many shells out there that have all kinds of different behavior. Like what? There are two nonstandard shells on Windows, but aren't all the Unix/Linux/OSX shells are similar enough for this purpose? What is a good syntax for list of values which does work with Powershell? From thiago.macieira at intel.com Tue Jul 30 17:33:48 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Jul 2013 08:33:48 -0700 Subject: [Development] Bug management and jira workflow In-Reply-To: References: <201307231325.44951.jedrzej.nowacki@digia.com> Message-ID: <3222788.r8GBFcPkYb@tjmaciei-mobl2> On terça-feira, 30 de julho de 2013 11:00:22, Blasche Alexander wrote: > How do I set an estimation value? There must be a way to specify the > estimation/target. Please don’t offer the Meta task for release x.y option > or just a comment. A filter must be able to find the tasks planned for > release x.y . The idea from the people in the discussion was that we shouldn't estimate. We're very bad at it. Instead of estimating, I'd go for some generic names that match the branches: any release any minor (feature) release any major release This is not estimation, it's just information about which type of release can contain the change. And those won't require jolly-bumping of versions after a release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Tue Jul 30 17:37:41 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Jul 2013 08:37:41 -0700 Subject: [Development] Is Xlib a hard requirement for Qt5 xcb? In-Reply-To: <20130730081433.GA27251@troll08.it.local> References: <8490878.Ku4GAiqPp8@tjmaciei-mobl2> <20130730081433.GA27251@troll08.it.local> Message-ID: <1788155.xjGyIjxB8T@tjmaciei-mobl2> On terça-feira, 30 de julho de 2013 10:14:33, Oswald Buddenhagen wrote: > On Tue, Jul 30, 2013 at 12:17:30AM -0700, Thiago Macieira wrote: > > On terça-feira, 30 de julho de 2013 08:31:55, Friedemann Kleint wrote: > > > For the system tray, I have been working on > > > https://codereview.qt-project.org/#change,61046 which would remove > > > QtWidget's dependency on Xlib. > > > Very ideally, the system tray would be completely implemented within the > > > platform plugin, but that is not possible since it needs menus and > > > tooltip handling. > > > > Drop the old protocol and implement only the new D-Bus-based status > > notifier protocol. > > you are being a tad optimistic here ... qt isn't exactly in a position > to dictate the platform to the end users of qt-based applications. the > timeframe for universal adoption of the new system tray protocol is 5-10 > more years. Right. But we hope that X will be falling into irrelevance by then :-) > not to mention that i (and probably some others as well) > think it is inherently broken to detach the systray's protocol layer > from the windowing system ... I even agree. But that is not relevant. The protocol exists and we should support it, however broken it is (because the older protocol is broken in other and more serious ways). Anyway, whoever is fixing the systray issue should figure an API for the platform plugin that works with both the current classes and a future QML- and QWindow-based implementation. So the plugin shouldn't draw menus and tooltips, but it should provide information necessary for the lib to implement them. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From 416365416c at gmail.com Wed Jul 31 02:45:20 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Tue, 30 Jul 2013 17:45:20 -0700 Subject: [Development] QStandardPath search paths Message-ID: I was just adding the cross-platform asset directory as a search path (https://codereview.qt-project.org/#change,61859 , with functionality as discussed as part of adaptable UI) and the question arose: Why aren't all (or at least some) standard paths available as search paths? Self documenting examples of what this would look like: QFile ("tmp:/tmpfile"); QFile ("appData:dataFile"); QQmlApplicationEngine("assets:/main.qml"); It would be a nice developer convenience, and easy for me to implement along with asset:. But it's not needed in the same way that asset: is, which is so that you can write asset: paths outside of #ifdef Q_OS_ANDROID blocks. Does anyone have an opinion on whether I should or should not add all the other QStandardPaths along with assets? -- Alan Alpert From Shawn.Rutledge at digia.com Wed Jul 31 08:34:19 2013 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Wed, 31 Jul 2013 06:34:19 +0000 Subject: [Development] QStandardPath search paths In-Reply-To: References: Message-ID: On 31 Jul 2013, at 2:45 AM, Alan Alpert wrote: > I was just adding the cross-platform asset directory as a search path > (https://codereview.qt-project.org/#change,61859 , with functionality > as discussed as part of adaptable UI) and the question arose: Why > aren't all (or at least some) standard paths available as search > paths? > > Self documenting examples of what this would look like: > QFile ("tmp:/tmpfile"); > QFile ("appData:dataFile"); > QQmlApplicationEngine("assets:/main.qml"); > > It would be a nice developer convenience, and easy for me to implement > along with asset:. But it's not needed in the same way that asset: is, > which is so that you can write asset: paths outside of #ifdef > Q_OS_ANDROID blocks. > > Does anyone have an opinion on whether I should or should not add all > the other QStandardPaths along with assets? Disclaimer: I haven't used QStandardPaths before, so am just reading the docs... If the point is to make it easier in QML, I think exposing a QStandardPaths API would be more useful in other contexts (e.g. I need it anyway to make a better file dialog ;-) and less opaque. In C++ maybe the existing API is good enough? But one wrinkle is that QStandardPaths::standardLocations returns a list, thus the need for QStandardPaths::locate apparently. Is that what the "convenience" would actually do, as opposed to concatenating the suffix with the first location from the list and taking no responsibility for whether the file exists or not? These prefixes could be thought of as URI schemes, right? so I have another gut feeling that adding several more new ones at the same time is not to be done lightly. Usually schemes are added for completely different mechanisms to access data, whereas these locations can all be converted to file:// URLs, at least on today's operating systems. So where and how do you think it would be appropriate to expose QStandardPaths to QtQuick? standardLocations, writableLocation and displayName will be especially useful to the file dialog, whereas locate and locateAll will probably be useful to many types of applications. Do you think we need to invent a file reading/writing API first, and then StandardPaths would just be a sub-feature of that? From pierluigi.fiorini at gmail.com Wed Jul 31 08:38:54 2013 From: pierluigi.fiorini at gmail.com (Pier Luigi) Date: Wed, 31 Jul 2013 08:38:54 +0200 Subject: [Development] Settings API for QML In-Reply-To: <4739AA4F-5268-4ADB-926F-4752EB39DDE1@digia.com> References: <50C75B8F.8050008@familiesomers.nl> <96526296-78E7-47B1-AB1F-64807B79466A@digia.com> <1843006.POohb1FX8h@rhea> <66BFFE861C7DE34D9B0372D8EAAB18E2A2DAD7@IT-EXMB01-HKI.it.local> <4BA188C112EE2C49AACEB40BB06DF7D73B2624@IT-EXMB01-HKI.it.local> <51C4C48D.8010405@gmail.com> <4739AA4F-5268-4ADB-926F-4752EB39DDE1@digia.com> Message-ID: 2013/6/22 Nurmi J-P : > > As Alan clarified, the proposal is to provide a stopgap solution via the labs module. > > I think we all agree that it's currently unnecessarily tedious for QML application developers to bake their own persistent settings solutions. Personally I've done it so far in quite a few QML apps using either QSettings in C++ or LocalStorage in QML. > > While QSettings has its flaws and limitations, it can handle the main use case (simple persistent settings backend without notifications, bells and whistles) just fine. IMHO it's a matter of documenting the limitations and stating clearly that it's not a full-blown publish and subscribe system. Furthermore, keeping the API minimal and QSettings-agnostic might even make it possible to port it over to the mighty new settings system once someone implements it. :) Here's my implementation which I started last year and finally managed to move into its own repo: https://github.com/hawaii-desktop/qtconfiguration It's still primitive but it's aimed at providing persistent storage and notifications for both C++ and QML. A JSON file would contain settings schema definition, here's a couple of examples: https://github.com/hawaii-desktop/shell/blob/master/data/settings/org.hawaii.greenisland.json https://github.com/hawaii-desktop/vibe/blob/master/data/settings/org.hawaii.desktop.json.in There's certainly a lot of prior art for settings, and I was inspired by GSettings. The QConfiguration class doesn't do much at the moment, it's just a dumb frontend to QSettings that checks whether a key exists in the schema and the value() method gets a default value from the schema when there's no value. The settings file is reread when it changes. Ideally the backend should be a plugin. There's no need to do yet another storage format for settings, we could use dconf on Linux, registry on Windows and plists on MacOS. Maybe QConfiguration could read the schema definition and dynamically alter the meta object creating read/write properties if it's possible. That should be compatible with Qt.labs.settings except you don't define properties through QML anymore. Schema definitions might also be versioned and an automated tool could migrate settings stored in an older version to the newer version. I plan to do some cleanup and implement a dconf backend soon. If you think that the QConfiguration approach is fine maybe we can put it in the Playground. -- Out of the box experience http://www.maui-project.org/ From Alexander.Blasche at digia.com Wed Jul 31 10:31:23 2013 From: Alexander.Blasche at digia.com (Blasche Alexander) Date: Wed, 31 Jul 2013 08:31:23 +0000 Subject: [Development] Bug management and jira workflow In-Reply-To: <3222788.r8GBFcPkYb@tjmaciei-mobl2> References: <201307231325.44951.jedrzej.nowacki@digia.com> <3222788.r8GBFcPkYb@tjmaciei-mobl2> Message-ID: -- Alex > -----Original Message----- > From: development-bounces+alexander.blasche=digia.com at qt-project.org > [mailto:development-bounces+alexander.blasche=digia.com at qt- > On terça-feira, 30 de julho de 2013 11:00:22, Blasche Alexander wrote: > > How do I set an estimation value? There must be a way to specify the > > estimation/target. Please don’t offer the Meta task for release x.y option > > or just a comment. A filter must be able to find the tasks planned for > > release x.y . > > The idea from the people in the discussion was that we shouldn't estimate. > We're very bad at it. > > Instead of estimating, I'd go for some generic names that match the > branches: > any release > any minor (feature) release > any major release > > This is not estimation, it's just information about which type of release can > contain the change. And those won't require jolly-bumping of versions after > a > release. Hm this doesn't help me since I have tasks which I want to achieve for the next release (e.g. 5.2) and some which I want for "any minor release" thereafter. It is merely a todo list for myself. If it is about the bumping then I am happy to bump my own tasks but I need to maintain the list for the next minor release. As long as it is not closed it is not 100% sure anyway. Why don't we accept that any "fix in" for a non-closed task is a bad estimate. No guarantee. Then we don't have any problems here. -- Alex From Gunnar.Sletta at digia.com Wed Jul 31 10:33:16 2013 From: Gunnar.Sletta at digia.com (Sletta Gunnar) Date: Wed, 31 Jul 2013 08:33:16 +0000 Subject: [Development] QtSC: Scene Graph discussion Message-ID: <77D24260-1697-4EB5-B94E-E3BF2274905C@digia.com> We went through a couple of topics and I try to summarise and make tasks for most of it. Render thread animations: https://bugreports.qt-project.org/browse/QTBUG-32703 Integration with native rendering, aka raw OpenGL for instance as a result of QQuickWindow::beforeRendering(). Document which state scenegraph exists in and make a function to reset the GL state afterwards. https://bugreports.qt-project.org/browse/QTBUG-32700 A request was made for running the scene graph in "slave mode", aka let for instance Ogre3D be the one owning the GL context and driving the render loop and let the QML scene be drawn on demand. -> This is doable already by implementing a custom renderloop using the private scene graph backend API (customcontext in ssh://codereview.qt-project.org:29418/playground/scenegraph.git). No public API planned at this time. Antialiasing: The Qt Quick items are currently antialiased by adding vertices along the edges and fading the opacity to 0. This gives nice results and always works, but OpenGL can do multisample based antialiasing which is a lot faster and which still gives decent results. Multisampling typically comes at a higher memory cost, several popular embedded chips (iPhone's SGX, for instance) can do 4x multisampling with minimal performance impact and no memory overhead. Using multisampling also has the added benefit that rectangles and opaque images are treated as opaque when they are rendered which enables better batching and reordering of the GL commands, further improving performance. Conclusion was to make this configurable: https://bugreports.qt-project.org/browse/QTBUG-32699 The scene graph renderer needs to start using Vertex Array Objects when mixed with raw GL using the OpenGL 3+ core profiles. Sean has promised a patch: https://bugreports.qt-project.org/browse/QTBUG-32050 The question was asked about how to add custom OpenGL into the scene graph scene. Though this is possible using private API, it is highly discouraged and will NEVER be public API. I plan on removing that feature all together at some point. It breaks batching and reordering can cost quite a bit in terms of buffer clearing and state restoration in the middle of rendering. The solution is to render UNDER the scene graph, OVER the scene graph or into a FramebufferObject if you want to be inside the scene graph. I've been experimenting with a new renderer which takes the batching ideas from the overlaprenderer, front-to-back rendering of the default renderer and caching in VBOs between frames when possible. For ideal usecases, we're looking at 10-1000x improvement, CPU-side. It's looking good and might be a good place to include the Vertex Array Objects as it should also benefit from them. https://bugreports.qt-project.org/browse/QTBUG-32695 and https://bugreports.qt-project.org/browse/QTBUG-32697 Stand alone module. Though the scene graph is public API inside Qt Quick, the question has been raised in the past if it makes sense to make it possible to build it into a separate module. Not an officially supported module, but just possible. We concluded that it doesn't really make sense. cheers, Gunnar From phartmann at blackberry.com Wed Jul 31 13:26:52 2013 From: phartmann at blackberry.com (Peter Hartmann) Date: Wed, 31 Jul 2013 13:26:52 +0200 Subject: [Development] Setting a Minimum Support OpenSSL Version In-Reply-To: References: Message-ID: <51F8F47C.9040006@blackberry.com> On 04/16/2013 01:19 PM, Richard Moore wrote: > 2) We could say 1.0.0 is the minimum. *bump* So is everybody fine with this? Also, does somebody from the release team know whether Windows / Linux packages are built with version 1.0.*? If yes, we could go ahead and change e.g. http://qt-project.org/doc/qt-4.8/requirements.html or http://qt-project.org/doc/qt-4.8/supported-platforms.html, saying OpenSSL 1.* is officially supported, and patches for 0.9.8* are accepted or so. I think we should not hold on to 0.9.* forever though, because when version 1.1.0 comes along (no idea when that will be) we will have to deal with binary compatibility breakages again, and handling 3 different interfaces will be quite a bit of work. Peter --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. From albert.astals at canonical.com Wed Jul 31 13:34:46 2013 From: albert.astals at canonical.com (Albert Astals Cid) Date: Wed, 31 Jul 2013 13:34:46 +0200 Subject: [Development] [QML] Making tryCompare accept a message Message-ID: <15116043.WlWebms9nj@xps> Hi, when using the QML TestLib the compare function has a message parameter \qmlmethod TestCase::compare(actual, expected, message = "") Fails the current test case if \a actual is not the same as \a expected, and displays the optional \a message. We have found the need for tryCompare to have also the message parameter since at the moment is not there \qmlmethod TestCase::tryCompare(obj, property, expected, timeout = 5000) So I was wondering if we should introduce a new function like \qmlmethod TestCase::tryCompareWithMessage(obj, property, expected, message = "", timeout = 5000) or if we could use javascript trickery to just change the existing tryCompare function to \qmlmethod TestCase::tryCompare(obj, property, expected, message = "", timeout = 5000) and then in the code do (note code is untested but something like that should be possible) if (typeof(message) == "number") { // The 4th parameter used to be timeout timeout = msg message = undefined } i.e. use Javascript type magic to still let people pass the timeout as fourth parameter to keep compatibility with the old signature. Personally i favour this second option but if you prefer the first one that's fine too. Cheers, Albert From pditchev at gmail.com Wed Jul 31 18:02:11 2013 From: pditchev at gmail.com (Petko Ditchev) Date: Wed, 31 Jul 2013 19:02:11 +0300 Subject: [Development] QAction shortcut policy Message-ID: <51F93503.5050308@gmail.com> Hello , first post , so I'm sorry in advance if I'm in the wrong place . In short : I built my app in 4.8.3 and just built the source with the Qt 5.0.2 library (and then with Qt5.1) . The 5.0.2 build had non-functional one letter shortcuts , when the keyboard layout (Cyrillic) was other than english (the CTRL+X and other shortcuts with modifiers worked) . The 5.1 build did not take any shortcuts with letters while the Cyrillic layout was on . Btw: I can't copy/paste/whatever in the current QtCreator with the Cyrillic keyboard , so that confirms it . I'm on Ubuntu 13.10 with GNOME , updated today. I'm writing to ask if this behaviour is intended , and if so - how can it be bypassed , because it's a big problem . My app is for making notes (so it should be language indifferent) and constantly changing the keyboard layout to use the shortcuts is not an option. Best regards ! Petko From Simon.Hausmann at digia.com Wed Jul 31 18:33:31 2013 From: Simon.Hausmann at digia.com (Hausmann Simon) Date: Wed, 31 Jul 2013 16:33:31 +0000 Subject: [Development] QStandardPath search paths In-Reply-To: Message-ID: <20130731163331.4821120.12715.48375@digia.com> Sounds like a good idea to me. The two features (QStandardPaths and search dirs in QFile/QDir) were developed separately (the former after the latter). If we are serious about promotional the search paths then this is probably the way to go :) I wonder what Filesystem folks think about it (especially Andreas, who was around when I added the search dirs with Girish) Simon Fra: Alan Alpert Sendt: 02:45 onsdag 31. juli 2013 Til: development Emne: [Development] QStandardPath search paths I was just adding the cross-platform asset directory as a search path (https://codereview.qt-project.org/#change,61859 , with functionality as discussed as part of adaptable UI) and the question arose: Why aren't all (or at least some) standard paths available as search paths? Self documenting examples of what this would look like: QFile ("tmp:/tmpfile"); QFile ("appData:dataFile"); QQmlApplicationEngine("assets:/main.qml"); It would be a nice developer convenience, and easy for me to implement along with asset:. But it's not needed in the same way that asset: is, which is so that you can write asset: paths outside of #ifdef Q_OS_ANDROID blocks. Does anyone have an opinion on whether I should or should not add all the other QStandardPaths along with assets? -- Alan Alpert _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From 416365416c at gmail.com Wed Jul 31 18:48:00 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 31 Jul 2013 09:48:00 -0700 Subject: [Development] QStandardPath search paths In-Reply-To: References: Message-ID: On Tue, Jul 30, 2013 at 11:34 PM, Rutledge Shawn wrote: > > On 31 Jul 2013, at 2:45 AM, Alan Alpert wrote: > >> I was just adding the cross-platform asset directory as a search path >> (https://codereview.qt-project.org/#change,61859 , with functionality >> as discussed as part of adaptable UI) and the question arose: Why >> aren't all (or at least some) standard paths available as search >> paths? >> >> Self documenting examples of what this would look like: >> QFile ("tmp:/tmpfile"); >> QFile ("appData:dataFile"); >> QQmlApplicationEngine("assets:/main.qml"); >> >> It would be a nice developer convenience, and easy for me to implement >> along with asset:. But it's not needed in the same way that asset: is, >> which is so that you can write asset: paths outside of #ifdef >> Q_OS_ANDROID blocks. >> >> Does anyone have an opinion on whether I should or should not add all >> the other QStandardPaths along with assets? > > Disclaimer: I haven't used QStandardPaths before, so am just reading the docs... > > If the point is to make it easier in QML, Nope. This is just something I ran into in QtCore and is intended for C++ Qt users. > I think exposing a QStandardPaths API would be more useful in other contexts (e.g. I need it anyway to make a better file dialog ;-) and less opaque. In C++ maybe the existing API is good enough? But one wrinkle is that QStandardPaths::standardLocations returns a list, thus the need for QStandardPaths::locate apparently. Is that what the "convenience" would actually do, as opposed to concatenating the suffix with the first location from the list and taking no responsibility for whether the file exists or not? > > These prefixes could be thought of as URI schemes, right? so I have another gut feeling that adding several more new ones at the same time is not to be done lightly. Usually schemes are added for completely different mechanisms to access data, whereas these locations can all be converted to file:// URLs, at least on today's operating systems. That's the difference between search paths and URL schemes - search paths are a convenience for file paths but always the "file" scheme. Ergo can be taken a little more lightly than a full URL scheme handler. > So where and how do you think it would be appropriate to expose QStandardPaths to QtQuick? standardLocations, writableLocation and displayName will be especially useful to the file dialog, whereas locate and locateAll will probably be useful to many types of applications. Do you think we need to invent a file reading/writing API first, and then StandardPaths would just be a sub-feature of that? Pretty much. At the very least, StandardPaths are not going to be a useful API when XmlHttpRequest is our only mechanism for loading files from QML :P. First we need to answer the question of "what can you usefully do with file in QML?", because most file use is imperative data processing and we want to encourage that it is done in C++. But that's a different discussion, which is larger and much farther ahead in the future. -- Alan Alpert From 416365416c at gmail.com Wed Jul 31 18:50:36 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 31 Jul 2013 09:50:36 -0700 Subject: [Development] [QML] Making tryCompare accept a message In-Reply-To: <15116043.WlWebms9nj@xps> References: <15116043.WlWebms9nj@xps> Message-ID: On Wed, Jul 31, 2013 at 4:34 AM, Albert Astals Cid wrote: > Hi, when using the QML TestLib the compare function has a message parameter > > \qmlmethod TestCase::compare(actual, expected, message = "") > > Fails the current test case if \a actual is not the same as > \a expected, and displays the optional \a message. > > We have found the need for tryCompare to have also the message parameter since > at the moment is not there > > \qmlmethod TestCase::tryCompare(obj, property, expected, timeout = 5000) > > So I was wondering if we should introduce a new function like > > \qmlmethod TestCase::tryCompareWithMessage(obj, property, expected, > message = "", timeout = 5000) > > or if we could use javascript trickery to just change the existing tryCompare > function to > > \qmlmethod TestCase::tryCompare(obj, property, expected, message = "", > timeout = 5000) > > and then in the code do (note code is untested but something like that should > be possible) > > if (typeof(message) == "number") { > // The 4th parameter used to be timeout > timeout = msg > message = undefined > } > > i.e. use Javascript type magic to still let people pass the timeout as fourth > parameter to keep compatibility with the old signature. > > Personally i favour this second option but if you prefer the first one that's > fine too. What's the problem with the third option? \qmlmethod TestCase::tryCompare(obj, property, expected, timeout = 5000, message = "") Yes, you'll need to specify a timeout sometimes when you don't want to, but there's a similar problem if you put message first. -- Alan Alpert From Gatis.Paeglis at digia.com Wed Jul 31 19:23:43 2013 From: Gatis.Paeglis at digia.com (Paeglis Gatis) Date: Wed, 31 Jul 2013 17:23:43 +0000 Subject: [Development] QAction shortcut policy In-Reply-To: <51F93503.5050308@gmail.com> References: <51F93503.5050308@gmail.com> Message-ID: <4F17F1CB014D404BB810E3EF279396DDC15FEF@IT-EXMB01-HKI.it.local> Could be that you are looking for: https://bugreports.qt-project.org/browse/QTBUG-32274 ________________________________________ From: development-bounces+gatis.paeglis=digia.com at qt-project.org [development-bounces+gatis.paeglis=digia.com at qt-project.org] on behalf of Petko Ditchev [pditchev at gmail.com] Sent: Wednesday, July 31, 2013 6:02 PM To: development at qt-project.org Subject: [Development] QAction shortcut policy Hello , first post , so I'm sorry in advance if I'm in the wrong place . In short : I built my app in 4.8.3 and just built the source with the Qt 5.0.2 library (and then with Qt5.1) . The 5.0.2 build had non-functional one letter shortcuts , when the keyboard layout (Cyrillic) was other than english (the CTRL+X and other shortcuts with modifiers worked) . The 5.1 build did not take any shortcuts with letters while the Cyrillic layout was on . Btw: I can't copy/paste/whatever in the current QtCreator with the Cyrillic keyboard , so that confirms it . I'm on Ubuntu 13.10 with GNOME , updated today. I'm writing to ask if this behaviour is intended , and if so - how can it be bypassed , because it's a big problem . My app is for making notes (so it should be language indifferent) and constantly changing the keyboard layout to use the shortcuts is not an option. Best regards ! Petko _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed Jul 31 19:48:16 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 31 Jul 2013 10:48:16 -0700 Subject: [Development] Settings API for QML In-Reply-To: References: <4739AA4F-5268-4ADB-926F-4752EB39DDE1@digia.com> Message-ID: <1828742.9ECJvZ3T4H@tjmaciei-mobl2> On quarta-feira, 31 de julho de 2013 08:38:54, Pier Luigi wrote: > Here's my implementation which I started last year and finally managed > to move into its own repo: > > https://github.com/hawaii-desktop/qtconfiguration Thanks! > It's still primitive but it's aimed at providing persistent storage > and notifications for both C++ and QML. > > A JSON file would contain settings schema definition, here's a couple > of examples: Uh... what's a schema file and why is it necessary? > https://github.com/hawaii-desktop/shell/blob/master/data/settings/org.hawaii > .greenisland.json > https://github.com/hawaii-desktop/vibe/blob/master/data/settings/org.hawaii > .desktop.json.in Hmm.. those look like input for a settings control module. That's not necessary in QtCore. I think it would be nice to have that as a separate module in Qt, which could replace KDE's KControl Module (KCM) support. But schemas mustn't be required for storing settings. > The QConfiguration class doesn't do much at the moment, it's just a > dumb frontend to QSettings that checks whether a key exists in the > schema and the value() method gets a default value from the schema > when there's no value. Why does it need to check the schema? If the value exists in the config file, then it exists. If it doesn't exist in the config file, the default is provided in the API call. > Ideally the backend should be a plugin. Yeah. On the other hand, I'm a bit skeptical about functionality requiring plugins in QtCore. At the very least, the dumbest backend should be built-in, not a plugin. > There's no need to do yet another storage format for settings, we > could use dconf on Linux, registry on Windows and plists on MacOS. dconf cannot be the only option. We need a dumb and human-readable backend inside QtCore. As a maintainer, my guideline is INI format. > If you think that the QConfiguration approach is fine maybe we can put > it in the Playground. That we can do. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Wed Jul 31 19:55:02 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 31 Jul 2013 10:55:02 -0700 Subject: [Development] QStandardPath search paths In-Reply-To: <20130731163331.4821120.12715.48375@digia.com> References: <20130731163331.4821120.12715.48375@digia.com> Message-ID: <1639208.vnc6BOJaEQ@tjmaciei-mobl2> On quarta-feira, 31 de julho de 2013 16:33:31, Hausmann Simon wrote: > I wonder what Filesystem folks think about it (especially Andreas, who was > around when I added the search dirs with Girish) My opinion is that the search path feature is at the wrong level of abstraction. It's also a potential security issue, since filename handling might not catch the opening of files outside the specified user parameters. It makes the determination of whether a given file path is absolute or not ambiguous. Those problems are shared by the file engines. Which we've fortunately got rid of for Qt 5. In my opinion, the *correct* way of searching for a file is QStandardPaths::locate. If you need to determine whether the file should be opened or not, the API can return you an absolute file name, which you can manipulate. This level of feature should be present on a VFS layer, above QFile and QDir. So I'd like us to decide first: either we deprecate the search path functionality completely, or we accept them and use them. If we accept them for use, then I'm ok with adding the QStandardPaths there. Collisions with what users may have added are not important. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Wed Jul 31 19:56:46 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 31 Jul 2013 10:56:46 -0700 Subject: [Development] QtSC: Scene Graph discussion In-Reply-To: <77D24260-1697-4EB5-B94E-E3BF2274905C@digia.com> References: <77D24260-1697-4EB5-B94E-E3BF2274905C@digia.com> Message-ID: <4381238.EI60fVvNlI@tjmaciei-mobl2> On quarta-feira, 31 de julho de 2013 08:33:16, Sletta Gunnar wrote: > Stand alone module. Though the scene graph is public API inside Qt Quick, > the question has been raised in the past if it makes sense to make it > possible to build it into a separate module. Not an officially supported > module, but just possible. We concluded that it doesn't really make sense. And not technically possible without BC break. See the Qt 4 moving of the QXmlStream* classes from QtXml to QtCore for reference. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From 416365416c at gmail.com Wed Jul 31 20:05:56 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 31 Jul 2013 11:05:56 -0700 Subject: [Development] QStandardPath search paths In-Reply-To: <1639208.vnc6BOJaEQ@tjmaciei-mobl2> References: <20130731163331.4821120.12715.48375@digia.com> <1639208.vnc6BOJaEQ@tjmaciei-mobl2> Message-ID: On Wed, Jul 31, 2013 at 10:55 AM, Thiago Macieira wrote: > On quarta-feira, 31 de julho de 2013 16:33:31, Hausmann Simon wrote: >> I wonder what Filesystem folks think about it (especially Andreas, who was >> around when I added the search dirs with Girish) > > My opinion is that the search path feature is at the wrong level of > abstraction. It's also a potential security issue, since filename handling > might not catch the opening of files outside the specified user parameters. It > makes the determination of whether a given file path is absolute or not > ambiguous. > > Those problems are shared by the file engines. Which we've fortunately got rid > of for Qt 5. > > In my opinion, the *correct* way of searching for a file is > QStandardPaths::locate. If you need to determine whether the file should be > opened or not, the API can return you an absolute file name, which you can > manipulate. The problem with using QStandardPaths::locate is that we're trying to turn this function: https://qt.gitorious.org/qt-creator/qt-creator/blobs/master/share/qtcreator/templates/qtquick2app/qtquick2applicationviewer/qtquick2applicationviewer.cpp#line58 , including the 20 lines in adjust path, into a single line so that you can write a cross-platform application with Qt without needing a fat template. Search paths make "asset:/main.qml" work on all platforms. I don't see how QStandardPaths::locate would work here other than #ifndef Q_OS_ANDROID QStandardPaths::locate(AssetPath, "main.qml"); #else "asset:/main.qml"; #endif -- Alan Alpert From thiago.macieira at intel.com Wed Jul 31 20:13:28 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 31 Jul 2013 11:13:28 -0700 Subject: [Development] QStandardPath search paths In-Reply-To: References: <20130731163331.4821120.12715.48375@digia.com> <1639208.vnc6BOJaEQ@tjmaciei-mobl2> Message-ID: <2834035.QJl8nR0SGb@tjmaciei-mobl2> On quarta-feira, 31 de julho de 2013 11:05:56, Alan Alpert wrote: > Search paths make "asset:/main.qml" work on all platforms. I don't see > how QStandardPaths::locate would work here other than > > #ifndef Q_OS_ANDROID > QStandardPaths::locate(AssetPath, "main.qml"); > #else > "asset:/main.qml"; > #endif Why can't QStandardPaths::locate return "asset:/main.qml" ? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From 416365416c at gmail.com Wed Jul 31 20:18:38 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 31 Jul 2013 11:18:38 -0700 Subject: [Development] QStandardPath search paths In-Reply-To: <2834035.QJl8nR0SGb@tjmaciei-mobl2> References: <20130731163331.4821120.12715.48375@digia.com> <1639208.vnc6BOJaEQ@tjmaciei-mobl2> <2834035.QJl8nR0SGb@tjmaciei-mobl2> Message-ID: On Wed, Jul 31, 2013 at 11:13 AM, Thiago Macieira wrote: > On quarta-feira, 31 de julho de 2013 11:05:56, Alan Alpert wrote: >> Search paths make "asset:/main.qml" work on all platforms. I don't see >> how QStandardPaths::locate would work here other than >> >> #ifndef Q_OS_ANDROID >> QStandardPaths::locate(AssetPath, "main.qml"); >> #else >> "asset:/main.qml"; >> #endif > > Why can't QStandardPaths::locate return "asset:/main.qml" ? Because it's not a proper filepath. Or does not not matter so long as we maintain the VFS characteristics which allow QFile/QDir to pretend it is? -- Alan Alpert From thiago.macieira at intel.com Wed Jul 31 20:23:47 2013 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 31 Jul 2013 11:23:47 -0700 Subject: [Development] QStandardPath search paths In-Reply-To: References: <20130731163331.4821120.12715.48375@digia.com> <2834035.QJl8nR0SGb@tjmaciei-mobl2> Message-ID: <45926614.RWYFElPXa8@tjmaciei-mobl2> On quarta-feira, 31 de julho de 2013 11:18:38, Alan Alpert wrote: > On Wed, Jul 31, 2013 at 11:13 AM, Thiago Macieira > > wrote: > > On quarta-feira, 31 de julho de 2013 11:05:56, Alan Alpert wrote: > >> Search paths make "asset:/main.qml" work on all platforms. I don't see > >> how QStandardPaths::locate would work here other than > >> > >> #ifndef Q_OS_ANDROID > >> QStandardPaths::locate(AssetPath, "main.qml"); > >> #else > >> "asset:/main.qml"; > >> #endif > > > > Why can't QStandardPaths::locate return "asset:/main.qml" ? > > Because it's not a proper filepath. Or does not not matter so long as > we maintain the VFS characteristics which allow QFile/QDir to pretend > it is? It's a file engine. File engines are bad. No one disputes that (yet we added another one). If QFile can open it, what's wrong with returning it, though? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 190 bytes Desc: This is a digitally signed message part. URL: From 416365416c at gmail.com Wed Jul 31 20:48:29 2013 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 31 Jul 2013 11:48:29 -0700 Subject: [Development] QStandardPath search paths In-Reply-To: <45926614.RWYFElPXa8@tjmaciei-mobl2> References: <20130731163331.4821120.12715.48375@digia.com> <2834035.QJl8nR0SGb@tjmaciei-mobl2> <45926614.RWYFElPXa8@tjmaciei-mobl2> Message-ID: On Wed, Jul 31, 2013 at 11:23 AM, Thiago Macieira wrote: > On quarta-feira, 31 de julho de 2013 11:18:38, Alan Alpert wrote: >> On Wed, Jul 31, 2013 at 11:13 AM, Thiago Macieira >> >> wrote: >> > On quarta-feira, 31 de julho de 2013 11:05:56, Alan Alpert wrote: >> >> Search paths make "asset:/main.qml" work on all platforms. I don't see >> >> how QStandardPaths::locate would work here other than >> >> >> >> #ifndef Q_OS_ANDROID >> >> QStandardPaths::locate(AssetPath, "main.qml"); >> >> #else >> >> "asset:/main.qml"; >> >> #endif >> > >> > Why can't QStandardPaths::locate return "asset:/main.qml" ? >> >> Because it's not a proper filepath. Or does not not matter so long as >> we maintain the VFS characteristics which allow QFile/QDir to pretend >> it is? > > It's a file engine. File engines are bad. No one disputes that (yet we added > another one). > > If QFile can open it, what's wrong with returning it, though? I suppose that would work then. The goal is just that there's one line for asset loading which does not need #ifdefs cross-platform, sounds like we could make that work... until we kill off file engines of course :P . -- Alan Alpert From jan.faroe at gmail.com Fri Jul 12 14:47:50 2013 From: jan.faroe at gmail.com (=?windows-1252?Q?Jan_Far=F8?=) Date: Fri, 12 Jul 2013 12:47:50 -0000 Subject: [Development] Puzzled by desktop development priorities, Mac OS specifically [Warning: Rant] Message-ID: Hi all, this is basically a copy of a post I made on http://qt-project.org/forums, and I was encouraged to post it here as well as to increase the probability of targeting the right audience - you developers. I have been lurking in the forums for a while, but due to the frustrations I’m having with the state of Qt for Mac OS, I decided to sign up in order to vent those frustratations (and questions) in a place where it actually might help. I am in the final stages of rewriting a somehow complex (at least for me) application to Qt from Java Swing. The time has come to focus on UI details, and this is where Qt gives me grey hairs. I started out developing in Qt 4.8, and experienced several issues that didn’t work on the Mac (From the top of my head: Overlays on video widgets), or just looked plain wrong in Mac OS context (For example: Table rows with alternate row colors does not extend to the bottom if only containing a few rows; list view items does not scroll properly if setting an item widget). Hoping that Qt5 would solve some of these problems (apart from reaping benefit from the great added features like JSON and serial device support), I have patiently waited for Qt5 to evolve from beta to 5.1 at the current point. Still, I’m seeing the same issues. Still. On top of that, classes like QtSingleApplication are not yet there. The unified toolbar on the Mac is gone, externalized to qtmacextras, which is still not ready. Compiling the latest version is not possible because of errors. Bottom line is that creating a professionally looking/behaving application on the Mac is not yet possible with Qt 5.1, and not with Qt 4.8 either if requiring certain features – unless you know how to fix the underlying problems, and I certainly don’t. What I struggle to understand is the strategic choices being made by the team responsible. Now, I am in general very happy about Qt, and I am admiring the effort that is being done. I understand that creating a cross platform framework is an incredibly complex task, even more so on the UI side. But – seeing versions for iOS and Android being rolled out, seeing funky demos that obviously takes time and effort to develop (the “Live widgets in Castle Wolfenstein” demo comes to mind), I strongly feel that the development priorities are not balanced – especially having in mind that the project is commercially backed. I do understand that the competition on the mobile market is fierce, and that strategically it’s crucial to roll out support for the mobile platforms as fast as possible. But please, please please… don’t forget the desktop platforms – and don’t forget the Mac. Consolidate the existing platforms, then expand. That would be my strategy; but who am I to say that. Sorry about the rant – however, I doubt I’m the only one experiencing these frustrations. Is there any timeline of the completion of qtmacextras and QtSingleApplication? Kind regards, Jan Faroe From jiajun2009 at gmail.com Tue Jul 16 13:01:11 2013 From: jiajun2009 at gmail.com (JaiJun Li) Date: Tue, 16 Jul 2013 11:01:11 -0000 Subject: [Development] QT5.x resource usage Message-ID: After transforming a gui project created and finished in QT4.8 to QT5.1, I found the CPU load is up to 100% in Task Manger, and RAM consumption is also much heavier. Please notice the parameters under no operation conditions: 4.8 CPU load is 0%, RAM consumption is 20M 5.1 CPU load is always in 25+% (4 cores), RAM consumption is 100+M Obviously, it continually refreshes UI in QT5.1. By analyzing UI and adding file one by one, I did find some of UI with circle animations cause high CPU load. But after I blocked these animations, the CPU load went up as the number of UI increased, and RAM consumption grew at the rate of dozens of hundreds of KB per second as well. Using QML Analyzer, it showed the refresh of animation timer in Painting occupy the system resource. And under no operation the refresh ratio also goes up to approximate 100 fps. At this time, no visual circle animation exists on UI. Even though I deleted circle animation it did not help. I guess the cause would be other one-time animations, because these animations may were not terminated correctly and were constantly sending refresh signals. Since the QT5.X occupies much system resource when running, so I am not able to transform the project and have to use QT4.8. I wonder whether someone else has this problem, or who could help me figure out it, even just give some comments? Thanks. I love you all. Thanks, Fields. -------------- next part -------------- An HTML attachment was scrubbed... URL: From opax.gm at gmail.com Fri Jul 19 01:59:08 2013 From: opax.gm at gmail.com (Ahcene) Date: Thu, 18 Jul 2013 23:59:08 -0000 Subject: [Development] Error while installing Qt for Tizen Message-ID: Hello everybody, I try to install Qt for Tizen but I have an issue. It doesn't finish. I am on Ubuntu 13.04 I have downloaded qt-tizen-1.0-alpha2.tar.gzand qt-tizen-integration-1.0-alpha2.tar.gz I want to use it with the emulator the command is sudo MAKE_THREADS=2 ./downloadAndBuildAll.sh $USER here is the error [in french] /usr/bin/ld: ne peut trouver /lib/libc.so.6 à l'intérieur de /usr/bin/ld: ne peut trouver /usr/lib/libc_nonshared.a à l'intérieur de collect2: erreur: ld a retourné 1 code d'état d'exécution make: *** [opengles2] Erreur 1 OpenGL ES 2.x disabled. The OpenGL ES 2.0 functionality test failed! You might need to modify the include and library search paths by editing QMAKE_INCDIR_OPENGL_ES2, QMAKE_LIBDIR_OPENGL_ES2 and QMAKE_LIBS_OPENGL_ES2 in [PATH]/Tizen/qt-tizen-1.0-alpha2/emulator/qt5.gitorious/qtbase/mkspecs/devices/linux-g++-tizen-emulator. could someone help me please? Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: