From thiago.macieira at intel.com Mon Sep 1 04:20:18 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 31 Aug 2014 19:20:18 -0700 Subject: [Development] Updating the licence policy for Qt Project In-Reply-To: References: Message-ID: <1519544.iWk9rfg4lW@tjmaciei-mobl4> On Friday 22 August 2014 07:21:38 Knoll Lars wrote: > Hi, > > As you've seen in my blog post on Wednesday, Digia has decided to add I believe there are no more remaining objections from this plan. The only one was Ossi asking about the LGPLv3-only case, which has been addressed. Ossi also requested that we state a preference for which licence combination the project prefers. If we do that, it comes in addition to the acceptance of the licence changes. So I believe we should consider this an accepted decision of the Qt Project. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at digia.com Mon Sep 1 08:38:16 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Mon, 1 Sep 2014 06:38:16 +0000 Subject: [Development] Updating the licence policy for Qt Project In-Reply-To: <1519544.iWk9rfg4lW@tjmaciei-mobl4> References: <1519544.iWk9rfg4lW@tjmaciei-mobl4> Message-ID: On 01/09/14 04:20, "Thiago Macieira" wrote: >On Friday 22 August 2014 07:21:38 Knoll Lars wrote: >> Hi, >> >> As you've seen in my blog post on Wednesday, Digia has decided to add > >I believe there are no more remaining objections from this plan. The only >one >was Ossi asking about the LGPLv3-only case, which has been addressed. > >Ossi also requested that we state a preference for which licence >combination >the project prefers. If we do that, it comes in addition to the >acceptance of >the licence changes. > >So I believe we should consider this an accepted decision of the Qt >Project. Agreed. In terms of preference I think we should state that the license has to include LGPLv3/commercial. It should include GPLv2 if this doesn’t conflict with some other license used (ie. Apache 2.0). Cheers, Lars From thiago.macieira at intel.com Mon Sep 1 08:55:34 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 31 Aug 2014 23:55:34 -0700 Subject: [Development] Updating the licence policy for Qt Project In-Reply-To: References: <1519544.iWk9rfg4lW@tjmaciei-mobl4> Message-ID: <8025671.1GUb2vkEgn@tjmaciei-mobl4> On Monday 01 September 2014 06:38:16 Knoll Lars wrote: > In terms of preference I think we should state that the license has to > include LGPLv3/commercial. It should include GPLv2 if this doesn’t > conflict with some other license used (ie. Apache 2.0). The question at hand is only whether we state a preference between GPLv2 and LGPLv2.1, in addition to the mandatory options of LGPLv3 and commercial. I believe we should not state a preference. The author of the module requesting the Git repositories should simply declare what they want. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at digia.com Mon Sep 1 08:58:25 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Mon, 1 Sep 2014 06:58:25 +0000 Subject: [Development] Updating the licence policy for Qt Project In-Reply-To: <8025671.1GUb2vkEgn@tjmaciei-mobl4> References: <1519544.iWk9rfg4lW@tjmaciei-mobl4> <8025671.1GUb2vkEgn@tjmaciei-mobl4> Message-ID: On 01/09/14 08:55, "Thiago Macieira" wrote: >On Monday 01 September 2014 06:38:16 Knoll Lars wrote: >> In terms of preference I think we should state that the license has to >> include LGPLv3/commercial. It should include GPLv2 if this doesn’t >> conflict with some other license used (ie. Apache 2.0). > >The question at hand is only whether we state a preference between GPLv2 >and >LGPLv2.1, in addition to the mandatory options of LGPLv3 and commercial. > >I believe we should not state a preference. The author of the module >requesting the Git repositories should simply declare what they want. Yes, both are welcome in the Qt Project :) Cheers, Lars From oswald.buddenhagen at digia.com Mon Sep 1 10:03:58 2014 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Mon, 1 Sep 2014 10:03:58 +0200 Subject: [Development] Updating the licence policy for Qt Project In-Reply-To: <8025671.1GUb2vkEgn@tjmaciei-mobl4> References: <1519544.iWk9rfg4lW@tjmaciei-mobl4> <8025671.1GUb2vkEgn@tjmaciei-mobl4> Message-ID: <20140901080358.GA12336@knobble.it.local> On Sun, Aug 31, 2014 at 11:55:34PM -0700, Thiago Macieira wrote: > I believe we should not state a preference. The author of the module > requesting the Git repositories should simply declare what they want. > most people have no strong opinions on that matter (and some not even the necessary understanding to make an informed decision) and will simply do what the group prefers. stating that preference preemptively will save some unnecessary roundtrips. whatever ... From m.olbrich at pengutronix.de Mon Sep 1 10:52:21 2014 From: m.olbrich at pengutronix.de (Michael Olbrich) Date: Mon, 1 Sep 2014 10:52:21 +0200 Subject: [Development] QStorageInfo In-Reply-To: References: <2169920.1LVK95Dfv4@tjmaciei-mobl4> <53FFF8AB.2030406@gmail.com> <1796982.d2VqQVvmRl@tjmaciei-mobl4> <54005A07.4030102@familiesomers.nl> <08E770A5-1329-4A48-84EE-40777CB614EC@gmail.com> <98B226E3-2CC0-45C5-AFF0-57B795338137@digia.com> Message-ID: <20140901085221.GE12397@pengutronix.de> Hi, On Fri, Aug 29, 2014 at 06:05:30PM +0400, Иван Комиссаров wrote: > Thiago was against introducing a QStorageInfoPlugin. However, i thinkg we can > try to dopen a udisks library. But why not simply try to link to it on Linux? > Are there any linux versions that doesn't have udisks now? Yes. There are many embedded use-cases where Qt is used but udisks makes no sense at all and is not available. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | From florian.salomon at siemens.com Tue Sep 2 07:48:49 2014 From: florian.salomon at siemens.com (Salomon, Florian) Date: Tue, 2 Sep 2014 05:48:49 +0000 Subject: [Development] export gobal enums to QML Message-ID: Hi, i'd like to know, if there is any possibility to export global enums (defined in a separate header file) to QML? #include "errcodes.h" Class A : QObject { Q_OBJECT Q_ENUMS(eErrorIDs) public: enum globalErrCodes eErrorIDs; } Regrads Florian -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo at vikingsoft.eu Tue Sep 2 08:36:52 2014 From: bo at vikingsoft.eu (Bo Thorsen) Date: Tue, 02 Sep 2014 08:36:52 +0200 Subject: [Development] export gobal enums to QML In-Reply-To: References: Message-ID: <54056584.2040304@vikingsoft.eu> Den 02-09-2014 07:48, Salomon, Florian skrev: > Hi, > i’d like to know, if there is any possibility to export global enums > (defined in a separate header file) to QML? > #include “errcodes.h” > Class A : QObject > { > Q_OBJECT > Q_ENUMS(eErrorIDs) > public: > enum globalErrCodes eErrorIDs; > } Hi Florian, No, you have to declare the enums directly in the QObject derived class. The generated moc code won't work if you don't. Side note: If someone on this list is looking for a pet project, this might be a good candidate. I think it's the third time someone has asked this on devel or interest in the last couple of months. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From holger at freyther.de Mon Sep 1 23:19:55 2014 From: holger at freyther.de (Holger Hans Peter Freyther) Date: Mon, 1 Sep 2014 23:19:55 +0200 Subject: [Development] Access to Coverity Scan results In-Reply-To: <5403797D.9030206@kdab.com> References: <5403797D.9030206@kdab.com> Message-ID: <20140901211955.GU4032@xiaoyu.lan> On Sun, Aug 31, 2014 at 09:37:33PM +0200, Giuseppe D'Angelo wrote: > Howdy, Hi, > is there a formal procedure to request access to the Coverity Scan results > for Qt? I've a request there which has been pending for a while. (Obviously, > given the security-related nature of those results, it wouldn't surprise me > if there's some kind of explicit request to be made...) I don't think there is a process for it yet and as you indicate there are some reasons to not approve everone that applies. I think Thiago and Lars are admins of the coverity account and could delegate/grant further access. cheers holger PS: I think you want to join the "qt-project" and not qtbase/qtdeclarative as they are "legacy" (we don't get cross-module checks like this). From Shawn.Rutledge at digia.com Tue Sep 2 09:01:30 2014 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Tue, 2 Sep 2014 07:01:30 +0000 Subject: [Development] Direct-lookup translation, even for English (was Re: [Interest] get english translation) In-Reply-To: <4534776.Or6Dd8LZJR@tjmaciei-mobl4> References: <4534776.Or6Dd8LZJR@tjmaciei-mobl4> Message-ID: On 1 Sep 2014, at 8:32 PM, Thiago Macieira wrote: > On Monday 01 September 2014 12:50:23 Graham Labdon wrote: >> Hi >> My application is internationalized, however, in some circumstances I need >> the English version of the string no matter what translator is being used. >> Anyone have any suggestions on how to achieve this? > > You have the English text. The way to get the English text from that is to use > it as-is. > > Don't translate, don't transform it in any way. Some projects like to use "programmer shorthand" for strings and then leave the final text up to a different team. Such teams tend to be capricious and change the English text multiple times (PR and marketing reasons), so it's an advantage not to treat the English text as the key for looking up the translation. (And then the shorthand can be written in any language the programmer likes, too.) I had a previous job like that. They had their own cross-platform cross-toolkit translation system, so I wasn't allowed to use tr() at all, and they convinced me that their way was better. They wanted to have all the strings for all the languages inside the binary. And there was a utility to generate an enum for the shorthand strings. Imagine opening up Designer and creating a button, and setting its label to BUTTON_OK. Then you run uic. Then you post-process the generated header file and make it do something like tr(BUTTON_OK), which will use the enum to look up the actual string at runtime, in a fixed-length array in which all strings for a particular language are stored. - Since the header modification is part of the build process, it costs the developer no time at all if the translation team wants to change the English text. They do their work independently, and then the application is re-built. - At runtime, this kind of lookup is much more efficient than the usual Gnome and KDE ways of looking around the filesystem for separate translation files (but at the cost of bloating the binary somewhat). - It is clear to everyone when the translation mechanism is not working or there is an un-translated string: you see the enum shorthand strings instead of the correct strings - no need to wait for a non-English-speaking tester to discover it. - There will never be a user who cannot use the app because it wasn't installed correctly and therefore the translation file was not found: the strings are guaranteed to be present as long as someone did the translation work before it shipped. The current way of using separate translation files should be kept as a fallback mechanism though, so that people in countries which were neglected by the development team can still do their own translations. This is the good part of the KDE way, that the translation work can be distributed to lots of people around the world. But it's also possible that they could contribute their work back to the original git repo, so that some future build of the application will have those strings built-in. I think it's a worthwhile goal that at least commercial Linux binaries ought to be self-contained and portable, so that there is no installation process beyond putting the binary in some directory which is in your path. It wouldn't hurt if the free software community had the goal of zero-install binaries too. The strings could be packaged as compressed resources, so the total space consumed is less. And perhaps resources which are not needed for the current language could even be expunged from memory (at the cost that you then cannot switch languages dynamically). But even if it were not for the enum-lookup implementation that they insisted on, our assumption that English needs no translation does not fit the multi-team workflow. There is often an assumption that programmers cannot design UIs because they are not artistic people or because they don't have psychology degrees or haven't studied usability enough. This is why we have separate tools for UI designers to use. It's very similar to the way that some people assume that programmers cannot write good English either. Stereotypes in general are wrong, and offensive to people with multi-disciplinary abilities. Nevertheless we can probably agree that UI design and the wording of text are often subject to later revision; so it's useful not to choose a changing string as a lookup key, for the same reason that imperative code should not assume too much about the declarative structure of the UI. From Shawn.Rutledge at digia.com Tue Sep 2 09:09:27 2014 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Tue, 2 Sep 2014 07:09:27 +0000 Subject: [Development] export gobal enums to QML In-Reply-To: <54056584.2040304@vikingsoft.eu> References: <54056584.2040304@vikingsoft.eu> Message-ID: <66D5D2B5-B712-4CFB-8EE6-AD682A113E3E@digia.com> On 2 Sep 2014, at 8:36 AM, Bo Thorsen wrote: > Den 02-09-2014 07:48, Salomon, Florian skrev: >> Hi, >> i’d like to know, if there is any possibility to export global enums >> (defined in a separate header file) to QML? >> #include “errcodes.h” >> Class A : QObject >> { >> Q_OBJECT >> Q_ENUMS(eErrorIDs) >> public: >> enum globalErrCodes eErrorIDs; >> } > > Hi Florian, > > No, you have to declare the enums directly in the QObject derived class. > The generated moc code won't work if you don't. There's also Q_GADGET. In QtQuick.Dialogs it is used to export the StandardButton enum separately. (see qquickdialogassets_p.h) From Eike.Ziller at digia.com Tue Sep 2 10:31:36 2014 From: Eike.Ziller at digia.com (Ziller Eike) Date: Tue, 2 Sep 2014 08:31:36 +0000 Subject: [Development] Direct-lookup translation, even for English (was Re: [Interest] get english translation) In-Reply-To: References: <4534776.Or6Dd8LZJR@tjmaciei-mobl4> Message-ID: <9C9ACEAD-F0BD-477A-B82A-D1F00B9E8C9F@digia.com> On Sep 2, 2014, at 9:01 AM, Rutledge Shawn wrote: > > On 1 Sep 2014, at 8:32 PM, Thiago Macieira wrote: > >> On Monday 01 September 2014 12:50:23 Graham Labdon wrote: >>> Hi >>> My application is internationalized, however, in some circumstances I need >>> the English version of the string no matter what translator is being used. >>> Anyone have any suggestions on how to achieve this? >> >> You have the English text. The way to get the English text from that is to use >> it as-is. >> >> Don't translate, don't transform it in any way. > > Some projects like to use "programmer shorthand" for strings and then leave the final text up to a different team. Such teams tend to be capricious and change the English text multiple times (PR and marketing reasons), so it's an advantage not to treat the English text as the key for looking up the translation. (And then the shorthand can be written in any language the programmer likes, too.) If your english translation is done in a separate .qm file (i.e. you do not use the tr-keys for the english text), your application can create a separate QTranslator that you use to load the english translation separately. You just do NOT INSTALL that translator into your app, but instead use that translator directly yourself if you want to access a specific english translation, with englishTranslator.translate(context, text, ......). > I had a previous job like that. They had their own cross-platform cross-toolkit translation system, so I wasn't allowed to use tr() at all, and they convinced me that their way was better. They wanted to have all the strings for all the languages inside the binary. And there was a utility to generate an enum for the shorthand strings. Imagine opening up Designer and creating a button, and setting its label to BUTTON_OK. Then you run uic. Then you post-process the generated header file and make it do something like tr(BUTTON_OK), which will use the enum to look up the actual string at runtime, in a fixed-length array in which all strings for a particular language are stored. > > - Since the header modification is part of the build process, it costs the developer no time at all if the translation team wants to change the English text. They do their work independently, and then the application is re-built. Since the text that is put in tr() is just used as a fallback, there is nothing preventing anyone from providing a separately created english translation (or change individual texts if they are supposed to change). In “your” code that tries to load the correct translation for the current locale, you can fallback to loading this english translation instead of using the tr-key fallback. Of course you might end up with lots of strings in your application that are only used as a key. > - At runtime, this kind of lookup is much more efficient than the usual Gnome and KDE ways of looking around the filesystem for separate translation files (but at the cost of bloating the binary somewhat). I would have thought that it is possible to use qrc to add your .qm files to your binary if you really want? Since you define yourself in your app where to look for translations. > - It is clear to everyone when the translation mechanism is not working or there is an un-translated string: you see the enum shorthand strings instead of the correct strings - no need to wait for a non-English-speaking tester to discover it. Linguist keeps track of which strings actually have been translated in some language, so the check “do all strings have translations" is easily automated. I’d expect any translation tool to do that tracking ;). For the check if the translation is actually good/correct you need a native speaker of the corresponding language for testing anyhow in the end. > - There will never be a user who cannot use the app because it wasn't installed correctly and therefore the translation file was not found: the strings are guaranteed to be present as long as someone did the translation work before it shipped. > > The current way of using separate translation files should be kept as a fallback mechanism though, so that people in countries which were neglected by the development team can still do their own translations. This is the good part of the KDE way, that the translation work can be distributed to lots of people around the world. But it's also possible that they could contribute their work back to the original git repo, so that some future build of the application will have those strings built-in. > > I think it's a worthwhile goal that at least commercial Linux binaries ought to be self-contained and portable, so that there is no installation process beyond putting the binary in some directory which is in your path. It wouldn't hurt if the free software community had the goal of zero-install binaries too. The strings could be packaged as compressed resources, so the total space consumed is less. And perhaps resources which are not needed for the current language could even be expunged from memory (at the cost that you then cannot switch languages dynamically). > > But even if it were not for the enum-lookup implementation that they insisted on, our assumption that English needs no translation does not fit the multi-team workflow. There is often an assumption that programmers cannot design UIs because they are not artistic people or because they don't have psychology degrees or haven't studied usability enough. This is why we have separate tools for UI designers to use. It's very similar to the way that some people assume that programmers cannot write good English either. Stereotypes in general are wrong, and offensive to people with multi-disciplinary abilities. Nevertheless we can probably agree that UI design and the wording of text are often subject to later revision; > so it's useful not to choose a changing string as a lookup key, Actually I’m not so sure about that. If the english (or whatever default language) text changes, that might very well be a hint that all other translations should be adapted too. > for the same reason that imperative code should not assume too much about the declarative structure of the UI. -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Eike.Ziller at digia.com Tue Sep 2 10:59:46 2014 From: Eike.Ziller at digia.com (Ziller Eike) Date: Tue, 2 Sep 2014 08:59:46 +0000 Subject: [Development] Direct-lookup translation, even for English (was Re: [Interest] get english translation) In-Reply-To: <9C9ACEAD-F0BD-477A-B82A-D1F00B9E8C9F@digia.com> References: <4534776.Or6Dd8LZJR@tjmaciei-mobl4> <9C9ACEAD-F0BD-477A-B82A-D1F00B9E8C9F@digia.com> Message-ID: This was cross-posted :/ My answer will possibly not end up on the interest mailing list. On Sep 2, 2014, at 10:31 AM, Ziller Eike wrote: > > On Sep 2, 2014, at 9:01 AM, Rutledge Shawn wrote: > >> >> On 1 Sep 2014, at 8:32 PM, Thiago Macieira wrote: >> >>> On Monday 01 September 2014 12:50:23 Graham Labdon wrote: >>>> Hi >>>> My application is internationalized, however, in some circumstances I need >>>> the English version of the string no matter what translator is being used. >>>> Anyone have any suggestions on how to achieve this? >>> >>> You have the English text. The way to get the English text from that is to use >>> it as-is. >>> >>> Don't translate, don't transform it in any way. >> >> Some projects like to use "programmer shorthand" for strings and then leave the final text up to a different team. Such teams tend to be capricious and change the English text multiple times (PR and marketing reasons), so it's an advantage not to treat the English text as the key for looking up the translation. (And then the shorthand can be written in any language the programmer likes, too.) > > If your english translation is done in a separate .qm file (i.e. you do not use the tr-keys for the english text), your application can create a separate QTranslator that you use to load the english translation separately. You just do NOT INSTALL that translator into your app, but instead use that translator directly yourself if you want to access a specific english translation, with englishTranslator.translate(context, text, ......). > >> I had a previous job like that. They had their own cross-platform cross-toolkit translation system, so I wasn't allowed to use tr() at all, and they convinced me that their way was better. They wanted to have all the strings for all the languages inside the binary. And there was a utility to generate an enum for the shorthand strings. Imagine opening up Designer and creating a button, and setting its label to BUTTON_OK. Then you run uic. Then you post-process the generated header file and make it do something like tr(BUTTON_OK), which will use the enum to look up the actual string at runtime, in a fixed-length array in which all strings for a particular language are stored. >> >> - Since the header modification is part of the build process, it costs the developer no time at all if the translation team wants to change the English text. They do their work independently, and then the application is re-built. > > Since the text that is put in tr() is just used as a fallback, there is nothing preventing anyone from providing a separately created english translation (or change individual texts if they are supposed to change). In “your” code that tries to load the correct translation for the current locale, you can fallback to loading this english translation instead of using the tr-key fallback. Of course you might end up with lots of strings in your application that are only used as a key. > >> - At runtime, this kind of lookup is much more efficient than the usual Gnome and KDE ways of looking around the filesystem for separate translation files (but at the cost of bloating the binary somewhat). > > I would have thought that it is possible to use qrc to add your .qm files to your binary if you really want? Since you define yourself in your app where to look for translations. > >> - It is clear to everyone when the translation mechanism is not working or there is an un-translated string: you see the enum shorthand strings instead of the correct strings - no need to wait for a non-English-speaking tester to discover it. > > Linguist keeps track of which strings actually have been translated in some language, so the check “do all strings have translations" is easily automated. I’d expect any translation tool to do that tracking ;). For the check if the translation is actually good/correct you need a native speaker of the corresponding language for testing anyhow in the end. > >> - There will never be a user who cannot use the app because it wasn't installed correctly and therefore the translation file was not found: the strings are guaranteed to be present as long as someone did the translation work before it shipped. >> >> The current way of using separate translation files should be kept as a fallback mechanism though, so that people in countries which were neglected by the development team can still do their own translations. This is the good part of the KDE way, that the translation work can be distributed to lots of people around the world. But it's also possible that they could contribute their work back to the original git repo, so that some future build of the application will have those strings built-in. >> >> I think it's a worthwhile goal that at least commercial Linux binaries ought to be self-contained and portable, so that there is no installation process beyond putting the binary in some directory which is in your path. It wouldn't hurt if the free software community had the goal of zero-install binaries too. The strings could be packaged as compressed resources, so the total space consumed is less. And perhaps resources which are not needed for the current language could even be expunged from memory (at the cost that you then cannot switch languages dynamically). >> >> But even if it were not for the enum-lookup implementation that they insisted on, our assumption that English needs no translation does not fit the multi-team workflow. There is often an assumption that programmers cannot design UIs because they are not artistic people or because they don't have psychology degrees or haven't studied usability enough. This is why we have separate tools for UI designers to use. It's very similar to the way that some people assume that programmers cannot write good English either. Stereotypes in general are wrong, and offensive to people with multi-disciplinary abilities. Nevertheless we can probably agree that UI design and the wording of text are often subject to later revision; > >> so it's useful not to choose a changing string as a lookup key, > > Actually I’m not so sure about that. If the english (or whatever default language) text changes, that might very well be a hint that all other translations should be adapted too. > >> for the same reason that imperative code should not assume too much about the declarative structure of the UI. > > > -- > Eike Ziller, Senior Software Engineer - Digia, Qt > > Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Nancy.Zou at csr.com Tue Sep 2 13:18:19 2014 From: Nancy.Zou at csr.com (Nancy Zou) Date: Tue, 2 Sep 2014 11:18:19 +0000 Subject: [Development] why Qt app performance low on qpa eglfs or wayland Message-ID: <904253C43ED48C45ADF9CC50A210C7B302E057AE@SHAASIEXM01.ASIA.ROOT.PRI> Hi All I run qt example openglwindow on my embedded system. I find on qpa eglfs, it only have 35fps. On qpa wayland( compostitor Weston 1.5), it only have 13fps. If I run a same opengl demp directly, it can have about 70fps. When run Qt app, I find cpu and gpu loading is not very high. Why the fps is low. Which function consumed the system time? My Qt version is 5.3.0. Does anyone met the same problem or I should do some configuration? Best Regards Nancy Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc. New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jan-Arve.Saether at digia.com Tue Sep 2 13:56:21 2014 From: Jan-Arve.Saether at digia.com (Saether Jan-Arve) Date: Tue, 2 Sep 2014 11:56:21 +0000 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: References: <4534776.Or6Dd8LZJR@tjmaciei-mobl4> Message-ID: <66BFFE861C7DE34D9B0372D8EAAB18E201263969@IT-EXMB01-HKI.it.local> > But even if it were not for the enum-lookup implementation that they > insisted on, our assumption that English needs no translation does not > fit the multi-team workflow. Yes, we should not assume that English needs no translation. As a matter of fact I don't know where (or why) we assume that. We should assume that the "engineering english" ideally needs a english translation (but for convenience it can be omitted). Actually, some of the i18n features of Qt _requires_ you to provide an English translation. This is the case for the plural forms, where the engineer typically writes. tr("Found %n item(s)", 0, m_numberOfItemsFound); And Qt will pick the singular/plural translation (that came from the translation file) depending on the value of m_numberOfItemsFound. Jan Arve (I took the liberty to remove the CC to interest at qt-project.org) From mail at milianw.de Tue Sep 2 14:18:37 2014 From: mail at milianw.de (Milian Wolff) Date: Tue, 02 Sep 2014 14:18:37 +0200 Subject: [Development] why Qt app performance low on qpa eglfs or wayland In-Reply-To: <904253C43ED48C45ADF9CC50A210C7B302E057AE@SHAASIEXM01.ASIA.ROOT.PRI> References: <904253C43ED48C45ADF9CC50A210C7B302E057AE@SHAASIEXM01.ASIA.ROOT.PRI> Message-ID: <82923129.Eq3HiTl6cf@milian-kdab2> On Tuesday 02 September 2014 11:18:19 Nancy Zou wrote: > Hi All > > I run qt example openglwindow on my embedded system. I find on qpa eglfs, it > only have 35fps. On qpa wayland( compostitor Weston 1.5), it only have > 13fps. If I run a same opengl demp directly, it can have about 70fps. > When run Qt app, I find cpu and gpu loading is not very high. Why the fps is > low. Which function consumed the system time? My Qt version is 5.3.0. > Does anyone met the same problem or I should do some configuration? You should answer this question yourself and present the results to us. Only you have your specific software/hardware combination setup properly. Try Linux' `perf top` e.g. or run your application via `perf record --call-graph=dwarf yourapp`. Then do a `perf report` and take a look at the results. Remember to compile your application and all important dependencies (esp. Qt) in release mode with debug symbols, i.e. at least use the compile flags `-O2 -g`. Bye -- Milian Wolff mail at milianw.de http://milianw.de From thiago.macieira at intel.com Tue Sep 2 17:28:05 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 Sep 2014 08:28:05 -0700 Subject: [Development] Access to Coverity Scan results In-Reply-To: <20140901211955.GU4032@xiaoyu.lan> References: <5403797D.9030206@kdab.com> <20140901211955.GU4032@xiaoyu.lan> Message-ID: <24321523.51dExH8Jn5@tjmaciei-mobl4> On Monday 01 September 2014 23:19:55 Holger Hans Peter Freyther wrote: > On Sun, Aug 31, 2014 at 09:37:33PM +0200, Giuseppe D'Angelo wrote: > > Howdy, > > Hi, > > > is there a formal procedure to request access to the Coverity Scan results > > for Qt? I've a request there which has been pending for a while. > > (Obviously, given the security-related nature of those results, it > > wouldn't surprise me if there's some kind of explicit request to be > > made...) > > I don't think there is a process for it yet and as you indicate there > are some reasons to not approve everone that applies. I think Thiago and > Lars are admins of the coverity account and could delegate/grant further > access. I'm not an admin as far as I know. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From giuseppe.dangelo at kdab.com Tue Sep 2 17:42:44 2014 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 02 Sep 2014 17:42:44 +0200 Subject: [Development] Access to Coverity Scan results In-Reply-To: <20140901211955.GU4032@xiaoyu.lan> References: <5403797D.9030206@kdab.com> <20140901211955.GU4032@xiaoyu.lan> Message-ID: <5405E574.9090403@kdab.com> Hi, Il 01/09/2014 23:19, Holger Hans Peter Freyther ha scritto: > On Sun, Aug 31, 2014 at 09:37:33PM +0200, Giuseppe D'Angelo wrote: >> Howdy, > > Hi, > >> is there a formal procedure to request access to the Coverity Scan results >> for Qt? I've a request there which has been pending for a while. (Obviously, >> given the security-related nature of those results, it wouldn't surprise me >> if there's some kind of explicit request to be made...) > > I don't think there is a process for it yet and as you indicate there > are some reasons to not approve everone that applies. I think Thiago and > Lars are admins of the coverity account and could delegate/grant further > access. Yep, thanks. Lars approved my request. Cheers, -- Join us Oct 6-8 at BCC Berlin for Qt Developer Days 2014! Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, 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: 4048 bytes Desc: Firma crittografica S/MIME URL: From saiarcot895 at gmail.com Wed Sep 3 01:18:02 2014 From: saiarcot895 at gmail.com (Saikrishna Arcot) Date: Tue, 02 Sep 2014 19:18:02 -0400 Subject: [Development] Changing GLdouble typedef in src/opengl/qgl.h Message-ID: <5093738.YtUHEyZz76@saikrishna-hp> Hi, I was looking at trying to get some libraries and applications to compile in Ubuntu for armhf (which supports only OpenGL ES for performance reasons). When I was trying to get OpenSceneGraph to compile, I noticed that in Qt's src/opengl/qgl.h, GLdouble is aliased to GLfloat. OpenSceneGraph (and some other applications) expect GLdouble and GLfloat to be different things, and some applications typedef GLdouble to double in their own code. Is there a reason why GLdouble is typedefed to GLfloat? If this was changed to typedef to double instead, is there a risk of breaking something within Qt? -- Saikrishna Arcot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From gunnar.sletta at jolla.com Wed Sep 3 07:26:23 2014 From: gunnar.sletta at jolla.com (Gunnar Sletta) Date: Wed, 3 Sep 2014 05:26:23 +0000 Subject: [Development] Changing GLdouble typedef in src/opengl/qgl.h In-Reply-To: <5093738.YtUHEyZz76@saikrishna-hp> References: <5093738.YtUHEyZz76@saikrishna-hp> Message-ID: <8BE3CE73-4DE0-4881-BAED-F2E8BB4EE343@jollamobile.com> On 03 Sep 2014, at 01:18, Saikrishna Arcot wrote: > Hi, > > I was looking at trying to get some libraries and applications to compile in Ubuntu for armhf (which supports only OpenGL ES for performance reasons). When I was trying to get OpenSceneGraph to compile, I noticed that in Qt's src/opengl/qgl.h, GLdouble is aliased to GLfloat. OpenSceneGraph (and some other applications) expect GLdouble and GLfloat to be different things, and some applications typedef GLdouble to double in their own code. > > Is there a reason why GLdouble is typedefed to GLfloat? If this was changed to typedef to double instead, is there a risk of breaking something within Qt? There is nothing in stock ES that supports double precision floats without the use of extensions, so I suspect it was done to make the initial port easier... Anyway, you should use Qt 5 and QOpenGLContext (not QGLWidget / QGLContext) which doesn't have this define and which should be easier to integrate with OpenSceneGraph as you are better control of the GL context. cheers, Gunnar > > -- > Saikrishna Arcot_______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Jaroslaw.Kobus at digia.com Wed Sep 3 08:25:06 2014 From: Jaroslaw.Kobus at digia.com (Kobus Jaroslaw) Date: Wed, 3 Sep 2014 06:25:06 +0000 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <66BFFE861C7DE34D9B0372D8EAAB18E201263969@IT-EXMB01-HKI.it.local> References: <4534776.Or6Dd8LZJR@tjmaciei-mobl4> , <66BFFE861C7DE34D9B0372D8EAAB18E201263969@IT-EXMB01-HKI.it.local> Message-ID: <7B32F0A77F0A9D4A8ACDBDEB2909E78145DB31@IT-EXMB01-HKI.it.local> > Actually, some of the i18n features of Qt _requires_ you to provide an English translation. > This is the case for the plural forms, where the engineer typically writes. > tr("Found %n item(s)", 0, m_numberOfItemsFound); > And Qt will pick the singular/plural translation (that came from the translation file) > depending on the value of m_numberOfItemsFound. Can't we just provide some tr() overload, in which you could also specify plural and paucal forms in source code, next to the number? E.g. tr("Found %n item" /*singular*/, "Found %n items" /*paucal*/, "Found %n items" /*plural*/, m_numberOfItemsFound); In this way the English in the source code could be good enough. Jarek From andre at familiesomers.nl Wed Sep 3 09:15:26 2014 From: andre at familiesomers.nl (=?ISO-8859-1?Q?Andr=E9_Somers?=) Date: Wed, 03 Sep 2014 09:15:26 +0200 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <7B32F0A77F0A9D4A8ACDBDEB2909E78145DB31@IT-EXMB01-HKI.it.local> References: <4534776.Or6Dd8LZJR@tjmaciei-mobl4> , <66BFFE861C7DE34D9B0372D8EAAB18E201263969@IT-EXMB01-HKI.it.local> <7B32F0A77F0A9D4A8ACDBDEB2909E78145DB31@IT-EXMB01-HKI.it.local> Message-ID: <5406C00E.9060208@familiesomers.nl> Kobus Jaroslaw schreef op 3-9-2014 08:25: >> Actually, some of the i18n features of Qt _requires_ you to provide an English translation. >> This is the case for the plural forms, where the engineer typically writes. >> tr("Found %n item(s)", 0, m_numberOfItemsFound); >> And Qt will pick the singular/plural translation (that came from the translation file) >> depending on the value of m_numberOfItemsFound. > Can't we just provide some tr() overload, in which you could also specify plural and paucal forms in source code, next to the number? E.g. > > tr("Found %n item" /*singular*/, "Found %n items" /*paucal*/, "Found %n items" /*plural*/, m_numberOfItemsFound); > > In this way the English in the source code could be good enough. > I hope not. It's rather trival to do this using a translation file. A simple search in Linguist will find all these occurrences. If you really don't want to use that, you could also just provide two strings in code just for English (or whatever your base language is): if (m_numberOfItemsFound == 1) { .... tr("Found 1 item"); } else { .... tr("Found %n items", "", m_numberOfItemsFound); } André From Jan-Arve.Saether at digia.com Wed Sep 3 09:16:22 2014 From: Jan-Arve.Saether at digia.com (Saether Jan-Arve) Date: Wed, 3 Sep 2014 07:16:22 +0000 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <7B32F0A77F0A9D4A8ACDBDEB2909E78145DB31@IT-EXMB01-HKI.it.local> References: <4534776.Or6Dd8LZJR@tjmaciei-mobl4> , <66BFFE861C7DE34D9B0372D8EAAB18E201263969@IT-EXMB01-HKI.it.local> <7B32F0A77F0A9D4A8ACDBDEB2909E78145DB31@IT-EXMB01-HKI.it.local> Message-ID: <66BFFE861C7DE34D9B0372D8EAAB18E201268098@IT-EXMB01-HKI.it.local> I'm not sure I understand. English does not have paucal (but polish have :), so you would only need singular and plural for such an API. If this is the case, it would be limited to languages that have the same plural rules as English. We could do that, but I don't see the problem in providing the translation file. Shawn already mentioned many good reasons for why translating the "engineering English" to "end user English" (whatever that is) is a good thing. (Note - you don't need to provide translations for everything) Jan Arve > -----Original Message----- > From: Kobus Jaroslaw > Sent: 3. september 2014 08:25 > To: Saether Jan-Arve; Rutledge Shawn; Thiago Macieira > Cc: development at qt-project.org > Subject: RE: [Development] [Interest] Direct-lookup translation, even > for English (was Re: get english translation) >> Actually, some of the i18n features of Qt _requires_ you to provide an >> English translation. This is the case for the plural forms, where the >> engineer typically > writes. > >> tr("Found %n item(s)", 0, m_numberOfItemsFound); >> >> And Qt will pick the singular/plural translation (that came from the >> translation file) depending on the value of m_numberOfItemsFound. > > Can't we just provide some tr() overload, in which you could also > specify plural and paucal forms in source code, next to the number? E.g. > > tr("Found %n item" /*singular*/, "Found %n items" /*paucal*/, "Found > %n items" /*plural*/, m_numberOfItemsFound); > > In this way the English in the source code could be good enough. > > Jarek From saiarcot895 at gmail.com Wed Sep 3 13:54:14 2014 From: saiarcot895 at gmail.com (Saikrishna Arcot) Date: Wed, 03 Sep 2014 07:54:14 -0400 Subject: [Development] Changing GLdouble typedef in src/opengl/qgl.h In-Reply-To: <8BE3CE73-4DE0-4881-BAED-F2E8BB4EE343@jollamobile.com> References: <5093738.YtUHEyZz76@saikrishna-hp> <8BE3CE73-4DE0-4881-BAED-F2E8BB4EE343@jollamobile.com> Message-ID: <3588434.WmFFNRga7T@saikrishna-hp> I should have mentioned that these libraries are using Qt 4, and it would be non-trivial to change them to Qt 5 just for compilation purposes. I wasn't aware that doubles weren't supported on GLES. Based on that, and rereading the forum post here (http://forum.openscenegraph.org/viewtopic.php?t=11504[1]), it seems like there are two standards: 1. Accept doubles, use double for internal processing (if any), and cast it to float when calling the appropriate GLES function. 2. Accept and use only floats for both internal processing and calling GLES functions. I wonder which one might be better to follow. On Wednesday, September 03, 2014 05:26:23 Gunnar Sletta wrote: > > On 03 Sep 2014, at 01:18, Saikrishna Arcot wrote: > > > Hi, > > > > I was looking at trying to get some libraries and applications to compile in Ubuntu for armhf (which supports only OpenGL ES for performance reasons). When I was trying to get OpenSceneGraph to compile, I noticed that in Qt's src/opengl/qgl.h, GLdouble is aliased to GLfloat. OpenSceneGraph (and some other applications) expect GLdouble and GLfloat to be different things, and some applications typedef GLdouble to double in their own code. > > > > Is there a reason why GLdouble is typedefed to GLfloat? If this was changed to typedef to double instead, is there a risk of breaking something within Qt? > > There is nothing in stock ES that supports double precision floats without the use of extensions, so I suspect it was done to make the initial port easier... > > Anyway, you should use Qt 5 and QOpenGLContext (not QGLWidget / QGLContext) which doesn't have this define and which should be easier to integrate with OpenSceneGraph as you are better control of the GL context. > > cheers, > Gunnar > > > > -- Saikrishna Arcot -------- [1] http://forum.openscenegraph.org/viewtopic.php?t=11504 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Wed Sep 3 18:11:16 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 Sep 2014 09:11:16 -0700 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <66BFFE861C7DE34D9B0372D8EAAB18E201268098@IT-EXMB01-HKI.it.local> References: <7B32F0A77F0A9D4A8ACDBDEB2909E78145DB31@IT-EXMB01-HKI.it.local> <66BFFE861C7DE34D9B0372D8EAAB18E201268098@IT-EXMB01-HKI.it.local> Message-ID: <2394175.ZMiMW6UDsx@tjmaciei-mobl4> On Wednesday 03 September 2014 07:16:22 Saether Jan-Arve wrote: > We could do that, but I don't see the problem in providing the translation > file. Shawn already mentioned many good reasons for why translating the > "engineering English" to "end user English" (whatever that is) is a good > thing. (Note - you don't need to provide translations for everything) The problem is actually shipping and loading such a file. Imagine an application that is only run in English (no L10n) and for which the source code has proper, English messages. Will it occur to the developers that they have to provide the en_US translation file from Qt? No, it won't. We need to get rid of that file. PS: I can't find it. Shouldn't we have at least one in qttranslations? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Sep 3 18:13:15 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 Sep 2014 09:13:15 -0700 Subject: [Development] Changing GLdouble typedef in src/opengl/qgl.h In-Reply-To: <3588434.WmFFNRga7T@saikrishna-hp> References: <5093738.YtUHEyZz76@saikrishna-hp> <8BE3CE73-4DE0-4881-BAED-F2E8BB4EE343@jollamobile.com> <3588434.WmFFNRga7T@saikrishna-hp> Message-ID: <2233444.ngAtbdXITk@tjmaciei-mobl4> On Wednesday 03 September 2014 07:54:14 Saikrishna Arcot wrote: > I should have mentioned that these libraries are using Qt 4, and it would be > non-trivial to change them to Qt 5 just for compilation purposes. > > I wasn't aware that doubles weren't supported on GLES. Based on that, and > rereading the forum post here > (http://forum.openscenegraph.org/viewtopic.php?t=11504[1]), it seems like > there are two standards: > > 1. Accept doubles, use double for internal processing (if any), and cast it > to float when calling the appropriate GLES function. 2. Accept and use only > floats for both internal processing and calling GLES functions. > > I wonder which one might be better to follow. We can't / won't change QtOpenGL API any more, especially not in Qt 4. If you need to, please apply a workaround so your application builds. But from the point of view of the Qt Project, this problem is solved in Qt 5, with QtGui and the new OpenGL classes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kotov.valery at gmail.com Wed Sep 3 19:05:20 2014 From: kotov.valery at gmail.com (=?UTF-8?B?0JLQsNC70LXRgNC40Lkg0JrQvtGC0L7Qsg==?=) Date: Wed, 3 Sep 2014 20:05:20 +0300 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. Message-ID: Greetings everybody! I'm working on QTBUG-35892 ( https://bugreports.qt-project.org/browse/QTBUG-35892) feature request: adding support for HTTP OPTIONS method for QML XmlHttpRequest class. >From discussion with Richard Moore and Thiago Macieira I understood that 2 methods should be added to QNetworkAccessManager class: for "OPTIONS URL" and for "OPTIONS *" requests. In my understanding in should be something like the following: QNetworkReply *resourceOptions(const QNetworkRequest &request, QIODevice *data); QNetworkReply *resourceOptions(const QNetworkRequest &request, const QByteArray &data); QNetworkReply *commonOptions(const QNetworkRequest &request, const QIODevice *data); QNetworkReply *commonOptions(const QNetworkRequest &request, const QByteArray &data); We also should reject "OPTIONS *" request when HTTP proxy is in use. Unfortunately, I'm a little unsure what exactly should we do to reject the request. Should we check if HTTP proxy is in use inside commonOptions and return 0? Or should this check be performed later when we create http header (e.g. in QHttpProtocolHandler::sendRequest or QHttpNetworkRequestPrivate::header)? How "OPTIONS *" call should be represented in QML? Should it be something like this: var x = new XMLHttpRequest; x.open("OPTIONS", url); // for request with url var x = new XMLHttpRequest; x.open("OPTIONS *", url); // for request with asterisk Any suggestions are welcome. Thank you for your support! -- Sincerely yours, Valery -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Sep 3 19:10:29 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 Sep 2014 10:10:29 -0700 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: References: Message-ID: <12275658.hUTa4iZzJI@tjmaciei-mobl4> On Wednesday 03 September 2014 20:05:20 Валерий Котов wrote: > Greetings everybody! > > I'm working on QTBUG-35892 ( > https://bugreports.qt-project.org/browse/QTBUG-35892) feature request: > adding support for HTTP OPTIONS method for QML XmlHttpRequest class. > > >From discussion with Richard Moore and Thiago Macieira I understood that 2 > > methods should be added to QNetworkAccessManager class: for "OPTIONS URL" > and for "OPTIONS *" requests. > > In my understanding in should be something like the following: > QNetworkReply *resourceOptions(const QNetworkRequest &request, QIODevice > *data); > QNetworkReply *resourceOptions(const QNetworkRequest &request, const > QByteArray &data); > QNetworkReply *commonOptions(const QNetworkRequest &request, const QIODevice > *data); > QNetworkReply *commonOptions(const QNetworkRequest &request, const > QByteArray &data); Actually, I'm going back on what I had said. I think we can do sendCustomRequest for both types of requests. The difference would be that http://example.com sends OPTIONS * to example.com, but http://example.com/ sends OPTIONS / to example.com. > We also should reject "OPTIONS *" request when HTTP proxy is in use. > Unfortunately, I'm a little unsure what exactly should we do to reject the > request. > Should we check if HTTP proxy is in use inside commonOptions and return 0? No. > Or should this check be performed later when we create http header (e.g. in > QHttpProtocolHandler::sendRequest or QHttpNetworkRequestPrivate::header)? As soon as you realise a proxy is in use and this request can't work, cause the QNetworkReply to fail. > How "OPTIONS *" call should be represented in QML? Should it be something > like this: > var x = new XMLHttpRequest; > x.open("OPTIONS", url); // for request with url > var x = new XMLHttpRequest; > x.open("OPTIONS *", url); // for request with asterisk How is it represented in HTML5? Just do it the same way. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kotov.valery at gmail.com Wed Sep 3 19:31:04 2014 From: kotov.valery at gmail.com (=?UTF-8?B?0JLQsNC70LXRgNC40Lkg0JrQvtGC0L7Qsg==?=) Date: Wed, 3 Sep 2014 20:31:04 +0300 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: <12275658.hUTa4iZzJI@tjmaciei-mobl4> References: <12275658.hUTa4iZzJI@tjmaciei-mobl4> Message-ID: 2014-09-03 20:10 GMT+03:00 Thiago Macieira : On Wednesday 03 September 2014 20:05:20 Валерий Котов wrote: > >Greetings everybody! >> >> I'm working on QTBUG-35892 ( > >https://bugreports.qt-project.org/browse/QTBUG-35892) feature request: > >adding support for HTTP OPTIONS method for QML XmlHttpRequest class. >> > >From discussion with Richard Moore and Thiago Macieira I understood that 2 >> methods should be added to QNetworkAccessManager class: for "OPTIONS URL" >> and for "OPTIONS *" requests. >> >> In my understanding in should be something like the following: >> QNetworkReply *resourceOptions(const QNetworkRequest &request, QIODevice >> *data); >> QNetworkReply *resourceOptions(const QNetworkRequest &request, const >> QByteArray &data); >> QNetworkReply *commonOptions(const QNetworkRequest &request, const QIODevice >> *data); >> QNetworkReply *commonOptions(const QNetworkRequest &request, cons >> QByteArray &data); > Actually, I'm going back on what I had said. I think we can do > sendCustomRequest for both types of requests. The difference would be that > http://example.com sends OPTIONS * to example.com, but http://example.com/ > sends OPTIONS / to example.com. Ok. Does that mean that from qml call should be like the following? x.open("OPTIONS", "http://example.com/"); // for request with url x.open("OPTIONS", "http://example.com"); // for request with asterisk >> We also should reject "OPTIONS *" request when HTTP proxy is in use. >> Unfortunately, I'm a little unsure what exactly should we do to reject the >> request. >> Should we check if HTTP proxy is in use inside commonOptions and return 0? >No. >> Or should this check be performed later when we create http header (e.g. in >> QHttpProtocolHandler::sendRequest or QHttpNetworkRequestPrivate::header)? > As soon as you realise a proxy is in use and this request can't work, cause > the QNetworkReply to fail. Ok. Thank you. >> How "OPTIONS *" call should be represented in QML? Should it be something >> like this: >> var x = new XMLHttpRequest; >> x.open("OPTIONS", url); // for request with url >> var x = new XMLHttpRequest; >> x.open("OPTIONS *", url); // for request with asterisk > How is it represented in HTML5? > Just do it the same way. I'm a little unsure that I understood. Could you please clarify what did you mean by "represented in HTML5"? -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Sep 3 21:25:07 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 Sep 2014 12:25:07 -0700 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: References: <12275658.hUTa4iZzJI@tjmaciei-mobl4> Message-ID: <4328069.n2WERJZXVa@tjmaciei-mobl4> On Wednesday 03 September 2014 20:31:04 Валерий Котов wrote: > > Actually, I'm going back on what I had said. I think we can do > > sendCustomRequest for both types of requests. The difference would be that > > http://example.com sends OPTIONS * to example.com, but http://example.com/ > > sends OPTIONS / to example.com. > > Ok. Does that mean that from qml call should be like the following? > x.open("OPTIONS", "http://example.com/"); // for request with url > x.open("OPTIONS", "http://example.com"); // for request with asterisk You tell me. How does it work right now in QML for a GET? How does it work in HTML for a GET or for OPTIONS? > >> How "OPTIONS *" call should be represented in QML? Should it be something > >> like this: > >> var x = new XMLHttpRequest; > >> x.open("OPTIONS", url); // for request with url > >> var x = new XMLHttpRequest; > >> x.open("OPTIONS *", url); // for request with asterisk > > > > How is it represented in HTML5? > > Just do it the same way. > > I'm a little unsure that I understood. Could you please clarify what did > you mean by "represented in HTML5"? XMLHttpRequests have existed in JavaScript and HTML5 for years. How do they do this? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From fredrik at kde.org Wed Sep 3 22:20:34 2014 From: fredrik at kde.org (Fredrik =?iso-8859-1?q?H=F6glund?=) Date: Wed, 3 Sep 2014 22:20:34 +0200 Subject: [Development] Changing GLdouble typedef in src/opengl/qgl.h In-Reply-To: <2233444.ngAtbdXITk@tjmaciei-mobl4> References: <5093738.YtUHEyZz76@saikrishna-hp> <3588434.WmFFNRga7T@saikrishna-hp> <2233444.ngAtbdXITk@tjmaciei-mobl4> Message-ID: <201409032220.34561.fredrik@kde.org> On Wednesday 03 September 2014, Thiago Macieira wrote: > On Wednesday 03 September 2014 07:54:14 Saikrishna Arcot wrote: > > I should have mentioned that these libraries are using Qt 4, and it would be > > non-trivial to change them to Qt 5 just for compilation purposes. > > > > I wasn't aware that doubles weren't supported on GLES. Based on that, and > > rereading the forum post here > > (http://forum.openscenegraph.org/viewtopic.php?t=11504[1]), it seems like > > there are two standards: > > > > 1. Accept doubles, use double for internal processing (if any), and cast it > > to float when calling the appropriate GLES function. 2. Accept and use only > > floats for both internal processing and calling GLES functions. > > > > I wonder which one might be better to follow. > > We can't / won't change QtOpenGL API any more, especially not in Qt 4. > > If you need to, please apply a workaround so your application builds. But from > the point of view of the Qt Project, this problem is solved in Qt 5, with > QtGui and the new OpenGL classes. It is not solved in Qt 5. qopengl.h has the same typedef. Fredrik From thiago.macieira at intel.com Thu Sep 4 01:58:41 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 Sep 2014 16:58:41 -0700 Subject: [Development] iOS Qt 5.3 CI broken Message-ID: <1705208.4B9RfKUcQW@tjmaciei-mobl4> Could someone either fix it or disable iOS builds in the CI for 5.3? /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang -c -pipe -fvisibility=hidden -fpascal-strings -fmessage-length=0 -Wno- trigraphs -Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter -Wunused- variable -Wunused-value -Wno-shorten-64-to-32 -Wno-sign-conversion - fexceptions -fasm-blocks -Wno-missing-field-initializers -Wno-missing- prototypes -Wno-implicit-atomic-properties -Wformat -Wno-missing-braces -Wno- unused-function -Wno-unused-label -Wuninitialized -Wno-unknown-pragmas -Wno- shadow -Wno-four-char-constants -Wno-sign-compare -Wpointer-sign -Wno-newline- eof -Wdeprecated-declarations -Winvalid-offsetof -Wno-conversion -fvisibility- inlines-hidden -Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time- destructors -Wno-arc-abi -fobjc-nonfragile-abi -fobjc-legacy-dispatch -Wno- deprecated-implementations -Wprotocol -Wno-selector -Wno-strict-selector-match -Wno-undeclared-selector -arch i386 -O2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk -std=c++11 -stdlib=libc++ -mios-simulator-version-min=5.0 -fvisibility=hidden -fvisibility-inlines-hidden -Wall -W -DDARWIN_NO_CARBON -DQT_NO_PRINTER - DQT_NO_PRINTDIALOG -DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_EVDEV - DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG - DQT_STATICPLUGIN -DQT_PLUGIN -DQT_PLATFORMSUPPORT_LIB -DQT_GUI_LIB - DQT_CORE_LIB -I../../../../mkspecs/macx-ios-clang -I. - I/work/build/qt/qtbase/mkspecs/macx-ios-clang/ios -I../../../../include - I../../../../include/QtPlatformSupport - I../../../../include/QtPlatformSupport/5.3.3 - I../../../../include/QtPlatformSupport/5.3.3/QtPlatformSupport - I../../../../include/QtGui/5.3.3 -I../../../../include/QtGui/5.3.3/QtGui - I../../../../include/QtCore/5.3.3 -I../../../../include/QtCore/5.3.3/QtCore - I../../../../include/QtGui -I../../../../include/QtCore -I.moc qiosscreen.mm - o .obj/qiosscreen.o qiosscreen.mm:299:49: error: no member named 'MV_IOS_8_0' in 'QSysInfo' qiosscreen.mm:299:73: error: property 'nativeBounds' not found on object of type 'UIScreen *' -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jake.petroules at petroules.com Thu Sep 4 03:19:47 2014 From: jake.petroules at petroules.com (Jake Petroules) Date: Wed, 3 Sep 2014 21:19:47 -0400 Subject: [Development] iOS Qt 5.3 CI broken In-Reply-To: <1705208.4B9RfKUcQW@tjmaciei-mobl4> References: <1705208.4B9RfKUcQW@tjmaciei-mobl4> Message-ID: <0A8C6880-EFD6-449C-8998-8CD1E5E8C763@petroules.com> On 2014-09-03, at 07:58 PM, Thiago Macieira wrote: > Could someone either fix it or disable iOS builds in the CI for 5.3? > > /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang > -c -pipe -fvisibility=hidden -fpascal-strings -fmessage-length=0 -Wno- > trigraphs -Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter -Wunused- > variable -Wunused-value -Wno-shorten-64-to-32 -Wno-sign-conversion - > fexceptions -fasm-blocks -Wno-missing-field-initializers -Wno-missing- > prototypes -Wno-implicit-atomic-properties -Wformat -Wno-missing-braces -Wno- > unused-function -Wno-unused-label -Wuninitialized -Wno-unknown-pragmas -Wno- > shadow -Wno-four-char-constants -Wno-sign-compare -Wpointer-sign -Wno-newline- > eof -Wdeprecated-declarations -Winvalid-offsetof -Wno-conversion -fvisibility- > inlines-hidden -Wno-non-virtual-dtor -Wno-overloaded-virtual -Wno-exit-time- > destructors -Wno-arc-abi -fobjc-nonfragile-abi -fobjc-legacy-dispatch -Wno- > deprecated-implementations -Wprotocol -Wno-selector -Wno-strict-selector-match > -Wno-undeclared-selector -arch i386 -O2 -isysroot > /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator7.0.sdk > -std=c++11 -stdlib=libc++ -mios-simulator-version-min=5.0 -fvisibility=hidden > -fvisibility-inlines-hidden -Wall -W -DDARWIN_NO_CARBON -DQT_NO_PRINTER - > DQT_NO_PRINTDIALOG -DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_EVDEV - > DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG - > DQT_STATICPLUGIN -DQT_PLUGIN -DQT_PLATFORMSUPPORT_LIB -DQT_GUI_LIB - > DQT_CORE_LIB -I../../../../mkspecs/macx-ios-clang -I. - > I/work/build/qt/qtbase/mkspecs/macx-ios-clang/ios -I../../../../include - > I../../../../include/QtPlatformSupport - > I../../../../include/QtPlatformSupport/5.3.3 - > I../../../../include/QtPlatformSupport/5.3.3/QtPlatformSupport - > I../../../../include/QtGui/5.3.3 -I../../../../include/QtGui/5.3.3/QtGui - > I../../../../include/QtCore/5.3.3 -I../../../../include/QtCore/5.3.3/QtCore - > I../../../../include/QtGui -I../../../../include/QtCore -I.moc qiosscreen.mm - > o .obj/qiosscreen.o > qiosscreen.mm:299:49: error: no member named 'MV_IOS_8_0' in 'QSysInfo' > qiosscreen.mm:299:73: error: property 'nativeBounds' not found on object of > type 'UIScreen *' > > -- > 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 MV_IOS_8_0 was introduced in dev after 5.3 was branched (and thus isn't in 5.3), and new enum values cannot be added to 5.3.x. I've therefore "moved" the offending commit to dev. https://codereview.qt-project.org/#/c/93956/ (reverted offending commit in 5.3) https://codereview.qt-project.org/#/c/93957/ (cherry-picked offending commit to dev) -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation From Shawn.Rutledge at digia.com Thu Sep 4 07:24:38 2014 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Thu, 4 Sep 2014 05:24:38 +0000 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <2394175.ZMiMW6UDsx@tjmaciei-mobl4> References: <7B32F0A77F0A9D4A8ACDBDEB2909E78145DB31@IT-EXMB01-HKI.it.local> <66BFFE861C7DE34D9B0372D8EAAB18E201268098@IT-EXMB01-HKI.it.local> <2394175.ZMiMW6UDsx@tjmaciei-mobl4> Message-ID: Den 3 Sep 2014 kl. 6:11 PM skrev Thiago Macieira: > On Wednesday 03 September 2014 07:16:22 Saether Jan-Arve wrote: >> We could do that, but I don't see the problem in providing the translation >> file. Shawn already mentioned many good reasons for why translating the >> "engineering English" to "end user English" (whatever that is) is a good >> thing. (Note - you don't need to provide translations for everything) > > The problem is actually shipping and loading such a file. > > Imagine an application that is only run in English (no L10n) and for which the > source code has proper, English messages. Will it occur to the developers that > they have to provide the en_US translation file from Qt? It doesn't necessarily occur to an English speaker to identify translatable strings and wrap them in tr(), either. It is some work already to try to support localization, so we are talking about people who are aware enough to think about supporting it. But if we were using enum keys instead of string-string lookup, it would be more efficient and would also encourage separation of content from the means of displaying it. From thiago.macieira at intel.com Thu Sep 4 07:54:22 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 03 Sep 2014 22:54:22 -0700 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: References: <2394175.ZMiMW6UDsx@tjmaciei-mobl4> Message-ID: <1748792.x1vCzcm1xU@tjmaciei-mobl4> On Thursday 04 September 2014 05:24:38 Rutledge Shawn wrote: > It doesn't necessarily occur to an English speaker to identify translatable > strings and wrap them in tr(), either. It is some work already to try to > support localization, so we are talking about people who are aware enough > to think about supporting it. But if we were using enum keys instead of > string-string lookup, it would be more efficient and would also encourage > separation of content from the means of displaying it. Using identifiers is usually a bad idea. Every single internationalisation solution I've seen has migrated away from that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From gunnar at sletta.org Thu Sep 4 08:10:23 2014 From: gunnar at sletta.org (Gunnar Sletta) Date: Thu, 4 Sep 2014 08:10:23 +0200 Subject: [Development] Changing GLdouble typedef in src/opengl/qgl.h In-Reply-To: <201409032220.34561.fredrik@kde.org> References: <5093738.YtUHEyZz76@saikrishna-hp> <3588434.WmFFNRga7T@saikrishna-hp> <2233444.ngAtbdXITk@tjmaciei-mobl4> <201409032220.34561.fredrik@kde.org> Message-ID: On 03 Sep 2014, at 22:20, Fredrik Höglund wrote: > On Wednesday 03 September 2014, Thiago Macieira wrote: >> On Wednesday 03 September 2014 07:54:14 Saikrishna Arcot wrote: >>> I should have mentioned that these libraries are using Qt 4, and it would be >>> non-trivial to change them to Qt 5 just for compilation purposes. >>> >>> I wasn't aware that doubles weren't supported on GLES. Based on that, and >>> rereading the forum post here >>> (http://forum.openscenegraph.org/viewtopic.php?t=11504[1]), it seems like >>> there are two standards: >>> >>> 1. Accept doubles, use double for internal processing (if any), and cast it >>> to float when calling the appropriate GLES function. 2. Accept and use only >>> floats for both internal processing and calling GLES functions. >>> >>> I wonder which one might be better to follow. >> >> We can't / won't change QtOpenGL API any more, especially not in Qt 4. >> >> If you need to, please apply a workaround so your application builds. But from >> the point of view of the Qt Project, this problem is solved in Qt 5, with >> QtGui and the new OpenGL classes. > > It is not solved in Qt 5. qopengl.h has the same typedef. > > Fredrik yeah, I spoke too soon.. If we were to apply https://codereview.qt-project.org/#/c/93984/ it would be fixed though :) The change that introduced them was the S60 integration back in the Nokia days. I suspect it is due to make examples and stuff (which was mostly desktop 1.x at the time) compile, but there might be something else I'm not aware of. I did a test on linux configured with -opengl es2, including qtdeclarative, qtquickcontrols and qtmultimedia and it all still compiles. - Gunnar > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Lars.Knoll at digia.com Thu Sep 4 09:34:10 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Thu, 4 Sep 2014 07:34:10 +0000 Subject: [Development] iOS Qt 5.3 CI broken In-Reply-To: <0A8C6880-EFD6-449C-8998-8CD1E5E8C763@petroules.com> References: <1705208.4B9RfKUcQW@tjmaciei-mobl4> <0A8C6880-EFD6-449C-8998-8CD1E5E8C763@petroules.com> Message-ID: On 04/09/14 03:19, "Jake Petroules" wrote: >On 2014-09-03, at 07:58 PM, Thiago Macieira >wrote: > >> Could someone either fix it or disable iOS builds in the CI for 5.3? >> >> >>/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctool >>chain/usr/bin/clang >> -c -pipe -fvisibility=hidden -fpascal-strings -fmessage-length=0 -Wno- >> trigraphs -Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter >>-Wunused- >> variable -Wunused-value -Wno-shorten-64-to-32 -Wno-sign-conversion - >> fexceptions -fasm-blocks -Wno-missing-field-initializers -Wno-missing- >> prototypes -Wno-implicit-atomic-properties -Wformat -Wno-missing-braces >>-Wno- >> unused-function -Wno-unused-label -Wuninitialized -Wno-unknown-pragmas >>-Wno- >> shadow -Wno-four-char-constants -Wno-sign-compare -Wpointer-sign >>-Wno-newline- >> eof -Wdeprecated-declarations -Winvalid-offsetof -Wno-conversion >>-fvisibility- >> inlines-hidden -Wno-non-virtual-dtor -Wno-overloaded-virtual >>-Wno-exit-time- >> destructors -Wno-arc-abi -fobjc-nonfragile-abi -fobjc-legacy-dispatch >>-Wno- >> deprecated-implementations -Wprotocol -Wno-selector >>-Wno-strict-selector-match >> -Wno-undeclared-selector -arch i386 -O2 -isysroot >> >>/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.plat >>form/Developer/SDKs/iPhoneSimulator7.0.sdk >> -std=c++11 -stdlib=libc++ -mios-simulator-version-min=5.0 >>-fvisibility=hidden >> -fvisibility-inlines-hidden -Wall -W -DDARWIN_NO_CARBON -DQT_NO_PRINTER >>- >> DQT_NO_PRINTDIALOG -DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_EVDEV - >> DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE >>-DQT_NO_DEBUG - >> DQT_STATICPLUGIN -DQT_PLUGIN -DQT_PLATFORMSUPPORT_LIB -DQT_GUI_LIB - >> DQT_CORE_LIB -I../../../../mkspecs/macx-ios-clang -I. - >> I/work/build/qt/qtbase/mkspecs/macx-ios-clang/ios -I../../../../include >>- >> I../../../../include/QtPlatformSupport - >> I../../../../include/QtPlatformSupport/5.3.3 - >> I../../../../include/QtPlatformSupport/5.3.3/QtPlatformSupport - >> I../../../../include/QtGui/5.3.3 >>-I../../../../include/QtGui/5.3.3/QtGui - >> I../../../../include/QtCore/5.3.3 >>-I../../../../include/QtCore/5.3.3/QtCore - >> I../../../../include/QtGui -I../../../../include/QtCore -I.moc >>qiosscreen.mm - >> o .obj/qiosscreen.o >> qiosscreen.mm:299:49: error: no member named 'MV_IOS_8_0' in 'QSysInfo' >> qiosscreen.mm:299:73: error: property 'nativeBounds' not found on >>object of >> type 'UIScreen *' >> >> -- >> 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 > >MV_IOS_8_0 was introduced in dev after 5.3 was branched (and thus isn't >in 5.3), and new enum values cannot be added to 5.3.x. I've therefore >"moved" the offending commit to dev. > >https://codereview.qt-project.org/#/c/93956/ (reverted offending commit >in 5.3) >https://codereview.qt-project.org/#/c/93957/ (cherry-picked offending >commit to dev) Wouldn't 5.4 make more sense than dev? Cheers, Lars From Lars.Knoll at digia.com Thu Sep 4 09:50:52 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Thu, 4 Sep 2014 07:50:52 +0000 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <1748792.x1vCzcm1xU@tjmaciei-mobl4> References: <2394175.ZMiMW6UDsx@tjmaciei-mobl4> <1748792.x1vCzcm1xU@tjmaciei-mobl4> Message-ID: On 04/09/14 07:54, "Thiago Macieira" wrote: >On Thursday 04 September 2014 05:24:38 Rutledge Shawn wrote: >> It doesn't necessarily occur to an English speaker to identify >>translatable >> strings and wrap them in tr(), either. It is some work already to try >>to >> support localization, so we are talking about people who are aware >>enough >> to think about supporting it. But if we were using enum keys instead of >> string-string lookup, it would be more efficient and would also >>encourage >> separation of content from the means of displaying it. > >Using identifiers is usually a bad idea. Every single >internationalisation >solution I've seen has migrated away from that. Agree with Thiago. Identifiers are not something I want to encourage. The only reason we have some support for those in Qt is legacy. Cheers, Lars From rich at kde.org Thu Sep 4 10:45:54 2014 From: rich at kde.org (Richard Moore) Date: Thu, 4 Sep 2014 09:45:54 +0100 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: <4328069.n2WERJZXVa@tjmaciei-mobl4> References: <12275658.hUTa4iZzJI@tjmaciei-mobl4> <4328069.n2WERJZXVa@tjmaciei-mobl4> Message-ID: On 3 September 2014 20:25, Thiago Macieira wrote: > > > How is it represented in HTML5? > > > Just do it the same way. > > > > I'm a little unsure that I understood. Could you please clarify what did > > you mean by "represented in HTML5"? > > XMLHttpRequests have existed in JavaScript and HTML5 for years. How do > they do > this? > > I actually looked at the specs (both level 1 and level 2) the other day and OPTIONS * isn't mentioned at all. Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at carewolf.com Thu Sep 4 11:29:22 2014 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Thu, 4 Sep 2014 11:29:22 +0200 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: References: <4328069.n2WERJZXVa@tjmaciei-mobl4> Message-ID: <201409041129.23097.kde@carewolf.com> On Thursday 04 September 2014, Richard Moore wrote: > On 3 September 2014 20:25, Thiago Macieira > > wrote: > > > > How is it represented in HTML5? > > > > Just do it the same way. > > > > > > I'm a little unsure that I understood. Could you please clarify what > > > did you mean by "represented in HTML5"? > > > > XMLHttpRequests have existed in JavaScript and HTML5 for years. How do > > they do > > this? > > I actually looked at the specs (both level 1 and level 2) the other day and > OPTIONS * isn't mentioned at all. > At least in WebKit, it is an allowed method for open(), eg. xhr.open('OPTIONS',..) `Allan From rich at kde.org Thu Sep 4 11:44:37 2014 From: rich at kde.org (Richard Moore) Date: Thu, 4 Sep 2014 10:44:37 +0100 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: <201409041129.23097.kde@carewolf.com> References: <4328069.n2WERJZXVa@tjmaciei-mobl4> <201409041129.23097.kde@carewolf.com> Message-ID: On 4 September 2014 10:29, Allan Sandfeld Jensen wrote: > On Thursday 04 September 2014, Richard Moore wrote: > > On 3 September 2014 20:25, Thiago Macieira > > > > wrote: > > > > > How is it represented in HTML5? > > > > > Just do it the same way. > > > > > > > > I'm a little unsure that I understood. Could you please clarify what > > > > did you mean by "represented in HTML5"? > > > > > > XMLHttpRequests have existed in JavaScript and HTML5 for years. How do > > > they do > > > this? > > > > I actually looked at the specs (both level 1 and level 2) the other day > and > > OPTIONS * isn't mentioned at all. > > > At least in WebKit, it is an allowed method for open(), eg. > xhr.open('OPTIONS',..) > > Yeah, the spec mentions OPTIONS, just not the special case of sending an OPTIONS * request. Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From helmut.muelner at gmail.com Thu Sep 4 13:55:28 2014 From: helmut.muelner at gmail.com (=?iso-8859-1?Q?Helmut_M=FClner?=) Date: Thu, 4 Sep 2014 13:55:28 +0200 Subject: [Development] QTCREATORBUG-11516 and QTBUG-37119 Message-ID: <003901cfc837$1f9d6940$5ed83bc0$@gmail.com> For several months now it is not possible to evaluate Javascript expressions in the QML-Debugger component of QtCreator, so we are back to console.log() debugging. This issue was reported end of February and has a P2 priority. But it looks like there is no progress in this case. Could somebody look at this, please, please, PLEASE. I cannot stand console.log() any more. Best regards Helmut -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jan-Arve.Saether at digia.com Thu Sep 4 15:03:12 2014 From: Jan-Arve.Saether at digia.com (Saether Jan-Arve) Date: Thu, 4 Sep 2014 13:03:12 +0000 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <2394175.ZMiMW6UDsx@tjmaciei-mobl4> References: <7B32F0A77F0A9D4A8ACDBDEB2909E78145DB31@IT-EXMB01-HKI.it.local> <66BFFE861C7DE34D9B0372D8EAAB18E201268098@IT-EXMB01-HKI.it.local> <2394175.ZMiMW6UDsx@tjmaciei-mobl4> Message-ID: <66BFFE861C7DE34D9B0372D8EAAB18E20126E84C@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: 3. september 2014 18:11 > To: development at qt-project.org > Subject: Re: [Development] [Interest] Direct-lookup translation, even > for English (was Re: get english translation) > On Wednesday 03 September 2014 07:16:22 Saether Jan-Arve wrote: >> We could do that, but I don't see the problem in providing the >> translation file. Shawn already mentioned many good reasons for why >> translating the "engineering English" to "end user English" >> (whatever that is) is a good thing. (Note - you don't need to >> provide translations for everything) > > The problem is actually shipping and loading such a file. Somebody already suggested to embed it as a resource, isn't that good enough? > > Imagine an application that is only run in English (no L10n) and for > which the source code has proper, English messages. Will it occur to > the developers that they have to provide the en_US translation file > from Qt? > > No, it won't. We need to get rid of that file. If we get rid of it we have to provide an alternative way of providing those plural forms, preferably in some language-agnostic API (since Qt does not constrain you to write your source text in English). Unfortunately there are up to 6 different "plural forms" in some languages, and the rules to know which to pick differs greatly depending on the language. ..or alternatively we need to be clarify our documentation to explicitly mention that this plural-form-translation feature requires a translation to be installed, even in English. One only need to provide a translation file for the case you are describing if the application developer uses the plural translation feature. If that feature is not used, the translation file is not needed in your case. I assume if an application developer uses that feature, he should also have read its documentation. And if his plural translations doesn't work I would expect him to read that part again. And if he still doesn't manage to deploy the translation file after that, the user will still see "Found 1 item(s)" instead of "Found 1 item", which is not the end of the world, really. > > PS: I can't find it. Shouldn't we have at least one in qttranslations? Prior to this discussion I would say yes. Right now it depends on if we need to get rid of it ;-D Since I'm not yet convinced, I would still vote for adding it. Jan Arve From r9pbdtabzx at snkmail.com Thu Sep 4 15:19:52 2014 From: r9pbdtabzx at snkmail.com (John M. Dlugosz) Date: Thu, 04 Sep 2014 13:19:52 +0000 Subject: [Development] RCC XML and options Message-ID: <23222-1409836792-720240@sneakemail.com> I posted this on the Qt forum, but it was suggested that I bring it to the mailing list instead. The original post is at http://qt-project.org/forums/viewthread/46927 I read the documentation on the Resource Compiler (rcc), and my interest is in building existing projects using standard platform tools without qmake. That is, I’m adding logic to run rcc over a *.qrc file to produce a cpp file. First, I read about the -compress / -no-compress options. That is all or nothing for the entire translation unit. Is there an attribute in the XML (qrc) file to control this on a case-by-case basis? In particular, it’s counterproductive to try and compress a png file, but other kinds of resources might very well benefit from compression, and differing level for each. I could not find any additional documentation on the qrc xml file format, and only see the alias attribute. Are there others, such as compression? (Aside: what about different compression libraries? 7zip’s lzma appears to produce much smaller files than classic deflate.) The second issue concerns the -name option to rcc. Using a build tool as mentioned above, every *.qrc file needs to have its -name associated somehow. That would mean manually listing every such file individually and repeating the command with different parameters. That is in contrast to a rule that says “every *.qrc file produces a *.cpp file with a name derived from the input file”. It is not great to determine the -name from the input file too, as every subproject will want to have a file named simply resources.qrc and not some globally unique name. It would make sense to put the -name in the qrc file itself, rather than supplied separately to the rcc tool. This could simply be another attribute to the qresource element that serves the same function as the existing -name option. More extensible would be a new element that could contain more details for the generated code. Let me make sure I understand what that’s used for: The named function needs to be called at some point to make the resources available, but is otherwise not used, right? Different *.qrc files prepared by different developers in different parts of the code base (in the same resulting executable file) are distinguished by the ‘prefix’, right? If that’s right, couldn’t the generated code contain a dummy object using the “static constructor” technique to cause the registration function to be called sometime before main(), and not need an exposed name at all? (Update: it looks like a macro is generating a static object with a ctor, but it is still necessary to explicitly call the init function for it to work. So I don't see what's going on there exactly.) —John From renaud.guezennec at gmail.com Thu Sep 4 17:26:32 2014 From: renaud.guezennec at gmail.com (Renaud) Date: Thu, 4 Sep 2014 17:26:32 +0200 Subject: [Development] DockAreaWidget and QGLWidget update / repaint / paintEvent Message-ID: Hi All, I'm working on porting huge applications from Qt4(.7.2) to Qt5.(3.0). The applications use massively QGLWidget (and openGL). On Qt4, it works perfectly. On Qt5, I got some issues: 1/The applications have many mechanisms which start from MouseMoveEvent to updateGL() the QGLWidget (selection, rubber, translation, rotate, scale of 3D objects). On Qt5, we noticed slowness on this kind of user interaction. The mouseMoveEvent was linked to updateGL() calls. I changed them to update() calls and I fixed the problem. I can 't understand how it could work on Qt4. 2/ But, we still got issues about QDockWidget. When QDockWidget are floating and moving, they cause all OpenGL views to update. That send a lot of paint events which really slow down the application. There are two possibilities: The rendering is slower than before or Qt5 receives more events (MouseMouveEvent, QPaintEvent). How can I prevent the system to receive so many paintEvents while QDockWidget are moving above QGLWidget ? Thanks! From thiago.macieira at intel.com Thu Sep 4 18:26:38 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 Sep 2014 09:26:38 -0700 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <66BFFE861C7DE34D9B0372D8EAAB18E20126E84C@IT-EXMB01-HKI.it.local> References: <2394175.ZMiMW6UDsx@tjmaciei-mobl4> <66BFFE861C7DE34D9B0372D8EAAB18E20126E84C@IT-EXMB01-HKI.it.local> Message-ID: <2219726.v61byOGjAv@tjmaciei-mobl4> On Thursday 04 September 2014 13:03:12 Saether Jan-Arve wrote: > Somebody already suggested to embed it as a resource, isn't that good > enough? As long as we also load it by default. We cannot depend on users loading the translation file from the resource system. > > Imagine an application that is only run in English (no L10n) and for > > which the source code has proper, English messages. Will it occur to > > the developers that they have to provide the en_US translation file > > from Qt? > > > > No, it won't. We need to get rid of that file. > > If we get rid of it we have to provide an alternative way of providing those > plural forms, preferably in some language-agnostic API (since Qt does not > constrain you to write your source text in English). Unfortunately there > are up to 6 different "plural forms" in some languages, and the rules to > know which to pick differs greatly depending on the language. I'm saying we need a convenience for us, so we don't have to ship a translation file, and we write Qt source in English. This convenience could also be used by most software, since they are also written in English. If you write your language source in another language with different plural rules, you'll need to use the existing overload and provide a translation from your language back to your language again. > ..or alternatively we need to be clarify our documentation to explicitly > mention that this plural-form-translation feature requires a translation to > be installed, even in English. Which is what I don't want. This basically requires everyone to always load the Qt translation, even if their apps aren't l10n'ed. > One only need to provide a translation file for the case you are describing > if the application developer uses the plural translation feature. If that > feature is not used, the translation file is not needed in your case. I > assume if an application developer uses that feature, he should also have > read its documentation. And if his plural translations doesn't work I would > expect him to read that part again. And if he still doesn't manage to > deploy the translation file after that, the user will still see "Found 1 > item(s)" instead of "Found 1 item", which is not the end of the world, > really. Agreed. But I'm assuming from your previous message that we use the feature in Qt's own sources. Therefore, every single application uses the feature. > > PS: I can't find it. Shouldn't we have at least one in qttranslations? > > Prior to this discussion I would say yes. Right now it depends on if we need > to get rid of it ;-D Since I'm not yet convinced, I would still vote for > adding it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jake.petroules at petroules.com Thu Sep 4 18:31:59 2014 From: jake.petroules at petroules.com (Jake Petroules) Date: Thu, 4 Sep 2014 12:31:59 -0400 Subject: [Development] iOS Qt 5.3 CI broken In-Reply-To: References: <1705208.4B9RfKUcQW@tjmaciei-mobl4> <0A8C6880-EFD6-449C-8998-8CD1E5E8C763@petroules.com> Message-ID: <92C1E794-EE27-43BC-BF27-F5059F7B1480@petroules.com> On 2014-09-04, at 03:34 AM, Knoll Lars wrote: > > > On 04/09/14 03:19, "Jake Petroules" wrote: > >> On 2014-09-03, at 07:58 PM, Thiago Macieira >> wrote: >> >>> Could someone either fix it or disable iOS builds in the CI for 5.3? >>> >>> >>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctool >>> chain/usr/bin/clang >>> -c -pipe -fvisibility=hidden -fpascal-strings -fmessage-length=0 -Wno- >>> trigraphs -Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter >>> -Wunused- >>> variable -Wunused-value -Wno-shorten-64-to-32 -Wno-sign-conversion - >>> fexceptions -fasm-blocks -Wno-missing-field-initializers -Wno-missing- >>> prototypes -Wno-implicit-atomic-properties -Wformat -Wno-missing-braces >>> -Wno- >>> unused-function -Wno-unused-label -Wuninitialized -Wno-unknown-pragmas >>> -Wno- >>> shadow -Wno-four-char-constants -Wno-sign-compare -Wpointer-sign >>> -Wno-newline- >>> eof -Wdeprecated-declarations -Winvalid-offsetof -Wno-conversion >>> -fvisibility- >>> inlines-hidden -Wno-non-virtual-dtor -Wno-overloaded-virtual >>> -Wno-exit-time- >>> destructors -Wno-arc-abi -fobjc-nonfragile-abi -fobjc-legacy-dispatch >>> -Wno- >>> deprecated-implementations -Wprotocol -Wno-selector >>> -Wno-strict-selector-match >>> -Wno-undeclared-selector -arch i386 -O2 -isysroot >>> >>> /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.plat >>> form/Developer/SDKs/iPhoneSimulator7.0.sdk >>> -std=c++11 -stdlib=libc++ -mios-simulator-version-min=5.0 >>> -fvisibility=hidden >>> -fvisibility-inlines-hidden -Wall -W -DDARWIN_NO_CARBON -DQT_NO_PRINTER >>> - >>> DQT_NO_PRINTDIALOG -DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_EVDEV - >>> DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE >>> -DQT_NO_DEBUG - >>> DQT_STATICPLUGIN -DQT_PLUGIN -DQT_PLATFORMSUPPORT_LIB -DQT_GUI_LIB - >>> DQT_CORE_LIB -I../../../../mkspecs/macx-ios-clang -I. - >>> I/work/build/qt/qtbase/mkspecs/macx-ios-clang/ios -I../../../../include >>> - >>> I../../../../include/QtPlatformSupport - >>> I../../../../include/QtPlatformSupport/5.3.3 - >>> I../../../../include/QtPlatformSupport/5.3.3/QtPlatformSupport - >>> I../../../../include/QtGui/5.3.3 >>> -I../../../../include/QtGui/5.3.3/QtGui - >>> I../../../../include/QtCore/5.3.3 >>> -I../../../../include/QtCore/5.3.3/QtCore - >>> I../../../../include/QtGui -I../../../../include/QtCore -I.moc >>> qiosscreen.mm - >>> o .obj/qiosscreen.o >>> qiosscreen.mm:299:49: error: no member named 'MV_IOS_8_0' in 'QSysInfo' >>> qiosscreen.mm:299:73: error: property 'nativeBounds' not found on >>> object of >>> type 'UIScreen *' >>> >>> -- >>> 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 >> >> MV_IOS_8_0 was introduced in dev after 5.3 was branched (and thus isn't >> in 5.3), and new enum values cannot be added to 5.3.x. I've therefore >> "moved" the offending commit to dev. >> >> https://codereview.qt-project.org/#/c/93956/ (reverted offending commit >> in 5.3) >> https://codereview.qt-project.org/#/c/93957/ (cherry-picked offending >> commit to dev) > > Wouldn't 5.4 make more sense than dev? > > Cheers, > Lars > Yeah, mental mistake -- it's there now. -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation From apoenitz at t-online.de Thu Sep 4 20:03:24 2014 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 4 Sep 2014 20:03:24 +0200 Subject: [Development] RCC XML and options In-Reply-To: <23222-1409836792-720240@sneakemail.com> References: <23222-1409836792-720240@sneakemail.com> Message-ID: <20140904180324.GA6753@klara.mpi.htwm.de> On Thu, Sep 04, 2014 at 01:19:52PM +0000, John M. Dlugosz wrote: > I read the documentation on the Resource Compiler (rcc), and my interest > is in building existing projects using standard platform tools without > qmake. [Out of curiosity, what are the "standard platform tools" in this case?] > That is, I’m adding logic to run rcc over a *.qrc file to produce > a cpp file. > > First, I read about the -compress / -no-compress options. That is all or > nothing for the entire translation unit. Is there an attribute in the XML > (qrc) file to control this on a case-by-case basis? No, and that's intentional. The uncompression is done once for the whole data set (or not at all). That's faster and more compact then compressing files one-by-one. > In particular, it’s counterproductive to try and compress a png file, but > other kinds of resources might very well benefit from compression, and > differing level for each. Right. If you have such a case you can split your resources into two .qrc files and compress one, but not the other. > I could not find any additional documentation on the qrc xml file format, > and only see the alias attribute. Are there others, such as compression? No, the format is really that simple. > (Aside: what about different compression libraries? 7zip’s lzma appears > to produce much smaller files than classic deflate.) Such features comes at a price, e.g. run time, and code complexity. (Runtime-wise it's actually often faster to not compress at all) If you have a case where another compression algorithm would *really* make a difference you can always compress yourself using your favourite algorithm and then use rcc without compression. > The second issue concerns the -name option to rcc. Using a build tool as > mentioned above, every *.qrc file needs to have its -name associated > somehow. That would mean manually listing every such file individually > and repeating the command with different parameters. The canonical solution is to use different base names for different .qrc files, and have e.g. Makefile rules like %.cpp: %.qrc rcc -name $* -o $@ $< (or leave out the -name altogether in that case, or use a build system that sets up these rules for you). > That is in contrast > to a rule that says “every *.qrc file produces a *.cpp file with a name > derived from the input file”. It is not great to determine the -name from > the input file too, I don't see much difference in "making sure that different .qrc files have different 'name' attributes somewhere inside" vs "make sure that .qrc files have different base names" vs "make sure that different -name options are passed at rcc time". > as every subproject will want to have a file named > simply resources.qrc and not some globally unique name. You could be equally well establish a policy for your project that each subproject has a file called .qrc. > It would make sense to put the -name in the qrc file itself, rather than > supplied separately to the rcc tool. This could simply be another > attribute to the qresource element that serves the same function as the > existing -name option. That should be doable, even if I currently doubt it'd be worthwhile. Usually there are three approaches to get such things done: (1) file a festure request on bugreports.qt-project.org and hope someone implements it, (2) ask your Support contact to get this done for you, (3) contribute a patch via codereview.qt-projects.org. (Realistically, (1) is unrealistic in this particular case) > More extensible would be a new element that could > contain more details for the generated code. That's less likely to happen, but at least in theory there are the same three routes open. > Let me make sure I understand what that’s used for: The named function > needs to be called at some point to make the resources available, but is > otherwise not used, right? Different *.qrc files prepared by different > developers in different parts of the code base (in the same resulting > executable file) are distinguished by the ‘prefix’, right? > > If that’s right, couldn’t the generated code contain a dummy object using > the “static constructor” technique to cause the registration function to > be called sometime before main(), and not need an exposed name at all? That's already happening. Of course, the "static constructor" must be triggered _somehow_, e.g. from the dynamic loader. > (Update: it looks like a macro is generating a static object with a > ctor, but it is still necessary to explicitly call the init function for > it to work. Did you try and it didn't work without explicitly calling the setup function? How did you build that application? Andre' From andre at familiesomers.nl Thu Sep 4 20:31:49 2014 From: andre at familiesomers.nl (Andre Somers) Date: Thu, 04 Sep 2014 20:31:49 +0200 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <2219726.v61byOGjAv@tjmaciei-mobl4> References: <2394175.ZMiMW6UDsx@tjmaciei-mobl4> <66BFFE861C7DE34D9B0372D8EAAB18E20126E84C@IT-EXMB01-HKI.it.local> <2219726.v61byOGjAv@tjmaciei-mobl4> Message-ID: <5408B015.1060105@familiesomers.nl> On 4-9-2014 18:26, Thiago Macieira wrote: > On Thursday 04 September 2014 13:03:12 Saether Jan-Arve wrote: >> Somebody already suggested to embed it as a resource, isn't that good >> enough? > As long as we also load it by default. We cannot depend on users loading the > translation file from the resource system. Fine. Load it by default. > >>> Imagine an application that is only run in English (no L10n) and for >>> which the source code has proper, English messages. Will it occur to >>> the developers that they have to provide the en_US translation file >>> from Qt? >>> >>> No, it won't. We need to get rid of that file. >> If we get rid of it we have to provide an alternative way of providing those >> plural forms, preferably in some language-agnostic API (since Qt does not >> constrain you to write your source text in English). Unfortunately there >> are up to 6 different "plural forms" in some languages, and the rules to >> know which to pick differs greatly depending on the language. > I'm saying we need a convenience for us, so we don't have to ship a > translation file, and we write Qt source in English. This convenience could > also be used by most software, since they are also written in English. > > If you write your language source in another language with different plural > rules, you'll need to use the existing overload and provide a translation from > your language back to your language again. That sounds rather short-sighted to me. It means that an inconsistency is introduced for no good reason at all. If you want to have something that works for English only, it would be rather trivial to write a free function like this: QString singularOrPlural(QString singular, QString plural, int value) { if (value == 0 || qAbs(value) > 1) { return plural; } return singular; } There you go, there's your special tr version. To me, it sounds rather silly to abuse tr() to do something you explicitly say is meant for those *not* using i10n or i18n. I really see no need to litter Qt this way. Note that if you go ahead using the special tr function, you cannot simply translate anyway any more. The string and its arguments may be different than what you'd have if you wanted to take translation into account from the start. As Qt itself will have to deal with translations anyway, I also don't see a gain in Qt itself. >> ..or alternatively we need to be clarify our documentation to explicitly >> mention that this plural-form-translation feature requires a translation to >> be installed, even in English. > Which is what I don't want. This basically requires everyone to always load > the Qt translation, even if their apps aren't l10n'ed. So? If they forget, they'll end up with "1 file(s) found" instead of "1 file found" or "2 files found". Big deal. > >> One only need to provide a translation file for the case you are describing >> if the application developer uses the plural translation feature. If that >> feature is not used, the translation file is not needed in your case. I >> assume if an application developer uses that feature, he should also have >> read its documentation. And if his plural translations doesn't work I would >> expect him to read that part again. And if he still doesn't manage to >> deploy the translation file after that, the user will still see "Found 1 >> item(s)" instead of "Found 1 item", which is not the end of the world, >> really. > Agreed. > > But I'm assuming from your previous message that we use the feature in Qt's > own sources. Therefore, every single application uses the feature. A quick search for %n in the Qt .ts files would reveal that. I don't have them here, or I would take a peek. But even so: Qt could pre-load the Qt .qm file by default from an internal resource, and I guess that makes sense. There is no need for a special tr() version to do that. André From r9pbdtabzx at snkmail.com Thu Sep 4 20:46:04 2014 From: r9pbdtabzx at snkmail.com (John M. Dlugosz) Date: Thu, 04 Sep 2014 18:46:04 +0000 Subject: [Development] RCC XML and options Message-ID: <11468-1409856364-769348@sneakemail.com> On 9/4/2014 1:03 PM, André Pönitz apoenitz-at-t-online.de |Qt Dev mailing list/Qt| wrote: > [Out of curiosity, what are the "standard platform tools" in this case?] MSBuild. Runs from automated build server, testing server, as well as in the desktop IDE. >> Let me make sure I understand what that’s used for: The named function >> needs to be called at some point to make the resources available, but is >> otherwise not used, right? Different *.qrc files prepared by different >> developers in different parts of the code base (in the same resulting >> executable file) are distinguished by the ‘prefix’, right? >> >> If that’s right, couldn’t the generated code contain a dummy object using >> the “static constructor” technique to cause the registration function to >> be called sometime before main(), and not need an exposed name at all? > That's already happening. Of course, the "static constructor" must be > triggered _somehow_, e.g. from the dynamic loader. > >> (Update: it looks like a macro is generating a static object with a >> ctor, but it is still necessary to explicitly call the init function for >> it to work. > Did you try and it didn't work without explicitly calling the setup > function? How did you build that application? Yes. I took out the Q_INIT_RESOURCE line, and the icons were missing in the Qt-drawn window. With the generated resource cpp file in the main EXE (not in some loaded DLL), the static constructor is called before main(), with no worry about DLL loading. I'm familiar with such things and DLLs in general, though. My quick reading of the macros in the generated code is that a static ctor is being set up, calling the same function that Q_INIT_RESOURCE does; so the only reason for the latter is if the resource is needed for other static ctor functions earlier than its automatic time. It also seemed that the 'name' still needs to be unique since it's exposed even if it is going to be used automatically. I was surprised when it didn't work automatically. Thanks for your insight. —John From thiago.macieira at intel.com Thu Sep 4 20:59:05 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 Sep 2014 11:59:05 -0700 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <5408B015.1060105@familiesomers.nl> References: <2219726.v61byOGjAv@tjmaciei-mobl4> <5408B015.1060105@familiesomers.nl> Message-ID: <1891215.DKadfNqsyS@tjmaciei-mobl4> On Thursday 04 September 2014 20:31:49 Andre Somers wrote: > That sounds rather short-sighted to me. > It means that an inconsistency is introduced for no good reason at all. > If you want to have something that works for English only, it would be > rather trivial to write a free function like this: > > QString singularOrPlural(QString singular, QString plural, int value) { > if (value == 0 || qAbs(value) > 1) { > return plural; > } > return singular; > } > > There you go, there's your special tr version. This did not extract the string for translation. It needs to be something that does extract for translation and does translate to another language if a translator was loaded. > >> ..or alternatively we need to be clarify our documentation to explicitly > >> mention that this plural-form-translation feature requires a translation > >> to > >> be installed, even in English. > > > > Which is what I don't want. This basically requires everyone to always > > load > > the Qt translation, even if their apps aren't l10n'ed. > > So? If they forget, they'll end up with "1 file(s) found" instead of "1 > file found" or "2 files found". Big deal. So long as we actually write using the (s) plural. Which we sometimes don't: In designer: buddyeditor.cpp: undoStack()->beginMacro(tr("Remove %n buddies", 0, selectedConnections.size())); buddyeditor.cpp: undoStack()->beginMacro(tr("Add %n buddies", 0, count)); qdesigner_propertycommand.cpp: setText(QCoreApplication::translate("Command", "Changed '%1' of %n objects", "", count).arg(propertyName())); Source code bugs? Probably. > A quick search for %n in the Qt .ts files would reveal that. I don't > have them here, or I would take a peek. > But even so: Qt could pre-load the Qt .qm file by default from an > internal resource, and I guess that makes sense. There is no need for a > special tr() version to do that. Right, those are the two alternatives: preload a .qm or not require a .qm. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Thu Sep 4 22:11:31 2014 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 4 Sep 2014 22:11:31 +0200 Subject: [Development] RCC XML and options In-Reply-To: <11468-1409856364-769348@sneakemail.com> References: <11468-1409856364-769348@sneakemail.com> Message-ID: <20140904201131.GA12622@klara.mpi.htwm.de> On Thu, Sep 04, 2014 at 06:46:04PM +0000, John M. Dlugosz wrote: > > On 9/4/2014 1:03 PM, André Pönitz apoenitz-at-t-online.de |Qt Dev mailing list/Qt| wrote: > > [Out of curiosity, what are the "standard platform tools" in this case?] > MSBuild. Runs from automated build server, testing server, as well as in the desktop IDE. > >> Let me make sure I understand what that’s used for: The named function > >> needs to be called at some point to make the resources available, but is > >> otherwise not used, right? Different *.qrc files prepared by different > >> developers in different parts of the code base (in the same resulting > >> executable file) are distinguished by the ‘prefix’, right? > >> > >> If that’s right, couldn’t the generated code contain a dummy object using > >> the “static constructor” technique to cause the registration function to > >> be called sometime before main(), and not need an exposed name at all? > > That's already happening. Of course, the "static constructor" must be > > triggered _somehow_, e.g. from the dynamic loader. > > > >> (Update: it looks like a macro is generating a static object with a > >> ctor, but it is still necessary to explicitly call the init function for > >> it to work. > > Did you try and it didn't work without explicitly calling the setup > > function? How did you build that application? > Yes. I took out the Q_INIT_RESOURCE line, and the icons were missing in > the Qt-drawn window. There might be other reasons for missing images, like not suppported image formats (missing/not deployed plugins, ...) I would start with something harmless like a plain text file to make sure the resource setup works, and then go for images. Andre' From thiago.macieira at intel.com Thu Sep 4 22:45:21 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 04 Sep 2014 13:45:21 -0700 Subject: [Development] RCC XML and options In-Reply-To: <20140904180324.GA6753@klara.mpi.htwm.de> References: <23222-1409836792-720240@sneakemail.com> <20140904180324.GA6753@klara.mpi.htwm.de> Message-ID: <2010092.bAdBuYU6fb@tjmaciei-mobl4> On Thursday 04 September 2014 20:03:24 André Pönitz wrote: > > That is, I’m adding logic to run rcc over a *.qrc file to produce > > a cpp file. > > > > First, I read about the -compress / -no-compress options. That is all or > > nothing for the entire translation unit. Is there an attribute in the XML > > (qrc) file to control this on a case-by-case basis? > > No, and that's intentional. The uncompression is done once for the whole > data set (or not at all). That's faster and more compact then compressing > files one-by-one. It's the difference between a .tar.gz and a .zip file: the .zip file compresses each contained file individually, whereas .tar.gz comrpesses the tar stream. Tools like RAR have the feature too: they call it a "solid package". > > In particular, it’s counterproductive to try and compress a png file, but > > other kinds of resources might very well benefit from compression, and > > differing level for each. > > Right. If you have such a case you can split your resources into > two .qrc files and compress one, but not the other. Also remember there's a trade-off: uncompressed data is loaded into read-only, pure and sharable portions of the memory. They can be discarded if the system is under memory pressure and, quite often, aren't loaded at all until needed. If you compress, then the compressed data is read-only, pure and sharable. The result of the uncompression is left in read-write, impure and private memory segments. If the system is under memory pressure, this needs to be dumped to swap, instead of simply discarded. If you have a large file and you properly use QFile::map or QResource to read it, you may want to keep it uncompressed. > > (Aside: what about different compression libraries? 7zip’s lzma appears > > to produce much smaller files than classic deflate.) LZMA is also much slower to decompress, which can be a significant performance impact at runtime. > Such features comes at a price, e.g. run time, and code complexity. > (Runtime-wise it's actually often faster to not compress at all) > > If you have a case where another compression algorithm would *really* make > a difference you can always compress yourself using your favourite > algorithm and then use rcc without compression. Right. If your intention for resources is to ship files in an installer, then you should patiently compress to the maximum and show progress bars while you decompress and write to disk. That's outside of the scope of QtCore, but it might be something that KArchive could do for you. QtCore and QResource are meant for fast, stream reading. We need an algorithm that is really fast in decompression. > > Let me make sure I understand what that’s used for: The named function > > needs to be called at some point to make the resources available, but is > > otherwise not used, right? Different *.qrc files prepared by different > > developers in different parts of the code base (in the same resulting > > executable file) are distinguished by the ‘prefix’, right? > > > > If that’s right, couldn’t the generated code contain a dummy object using > > the “static constructor” technique to cause the registration function to > > be called sometime before main(), and not need an exposed name at all? > > That's already happening. Of course, the "static constructor" must be > triggered _somehow_, e.g. from the dynamic loader. The static constructor is triggered automatically by the dynamic loader. The big deal is to ensure that the whole .o file, including the constructor, gets linked into the application. When you're doing shared libraries, that's not a problem. When you're doing a static library, then something must require a symbol from the .o so that the linker will know to include it in the output. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Fri Sep 5 09:16:48 2014 From: andre at familiesomers.nl (=?ISO-8859-1?Q?Andr=E9_Somers?=) Date: Fri, 05 Sep 2014 09:16:48 +0200 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <1891215.DKadfNqsyS@tjmaciei-mobl4> References: <2219726.v61byOGjAv@tjmaciei-mobl4> <5408B015.1060105@familiesomers.nl> <1891215.DKadfNqsyS@tjmaciei-mobl4> Message-ID: <54096360.8060406@familiesomers.nl> Thiago Macieira schreef op 4-9-2014 20:59: > On Thursday 04 September 2014 20:31:49 Andre Somers wrote: >> That sounds rather short-sighted to me. >> It means that an inconsistency is introduced for no good reason at all. >> If you want to have something that works for English only, it would be >> rather trivial to write a free function like this: >> >> QString singularOrPlural(QString singular, QString plural, int value) { >> if (value == 0 || qAbs(value) > 1) { >> return plural; >> } >> return singular; >> } >> >> There you go, there's your special tr version. > This did not extract the string for translation. It needs to be something that > does extract for translation and does translate to another language if a > translator was loaded. I don't see how it properly could. Both strings would be specialized anyway for the singular and plural case. The singular version probably would not even have a placemarker for the number in it. How would that work in the translation? You could still use a translatable string for both alternatives, but I think that's completely missing the point. You either do localization, or you don't. This really sounds like a weird in-between, non-solution to me. > >>>> ..or alternatively we need to be clarify our documentation to explicitly >>>> mention that this plural-form-translation feature requires a translation >>>> to >>>> be installed, even in English. >>> Which is what I don't want. This basically requires everyone to always >>> load >>> the Qt translation, even if their apps aren't l10n'ed. >> So? If they forget, they'll end up with "1 file(s) found" instead of "1 >> file found" or "2 files found". Big deal. > So long as we actually write using the (s) plural. Which we sometimes don't: > > In designer: > buddyeditor.cpp: undoStack()->beginMacro(tr("Remove %n buddies", 0, > selectedConnections.size())); > buddyeditor.cpp: undoStack()->beginMacro(tr("Add %n buddies", 0, count)); > qdesigner_propertycommand.cpp: > setText(QCoreApplication::translate("Command", "Changed '%1' of %n objects", > "", count).arg(propertyName())); > > Source code bugs? Probably. Ok, so they might need to get fixed. Or not, as fixing these strings will break all existing real translations. >> A quick search for %n in the Qt .ts files would reveal that. I don't >> have them here, or I would take a peek. >> But even so: Qt could pre-load the Qt .qm file by default from an >> internal resource, and I guess that makes sense. There is no need for a >> special tr() version to do that. > Right, those are the two alternatives: preload a .qm or not require a .qm. > Note that these are not equal alternatives. Preloading a .qm will make Qt _itself_ use proper singular and plural forms. Using your special tr() overload would make not using a .qm file an option for users of Qt as well. IMO, pre-loading the qt_en_US.qm translation file makes sense, a special overload does not. André From Nancy.Zou at csr.com Fri Sep 5 10:39:08 2014 From: Nancy.Zou at csr.com (Nancy Zou) Date: Fri, 5 Sep 2014 08:39:08 +0000 Subject: [Development] why Qt app performance low on qpa eglfs or wayland In-Reply-To: <82923129.Eq3HiTl6cf@milian-kdab2> References: <904253C43ED48C45ADF9CC50A210C7B302E057AE@SHAASIEXM01.ASIA.ROOT.PRI> <82923129.Eq3HiTl6cf@milian-kdab2> Message-ID: <904253C43ED48C45ADF9CC50A210C7B302E05BB5@SHAASIEXM01.ASIA.ROOT.PRI> Hi Millan > You should answer this question yourself and present the results to us. Only you have your specific software/hardware combination setup properly. I suspect Qt wati for vsyc somewhere because the normal opengl example only cost 14ms (1 vsync) and Qt example openglwindow need 28 ms( just 2 vysnc) I think it's strange a simple opengl example run such low fps. My fb driver already wait for vsync once in eglSwapBuffers. So Qt don't need wait it. So I want to find out where qt hung. Whether Qt wait for some events somewhere? >Try Linux' `perf top` e.g. or run your application via `perf record --call-graph=dwarf yourapp`. Then do a `perf report` and take a look at the results. Remember to compile your application and all important dependencies (esp. Qt) in release mode with debug symbols, i.e. at least use the compile flags `-O2 -g`. I have done this in qmake. Thank you Best Regards Nancy Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc. New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com. From Jani.Heikkinen at digia.com Fri Sep 5 12:24:27 2014 From: Jani.Heikkinen at digia.com (Heikkinen Jani) Date: Fri, 5 Sep 2014 10:24:27 +0000 Subject: [Development] xcode in ci & packaging for Qt5.4.0 Message-ID: Hi all, QtWebEngine & QtCreator teams has proposed us to update used xcode in packaging & CI machines. At the moment 10.8 mac is using xcode 5.0.2 & 10.9 xcode 5.1.1 . Does someone know any issue why we shouldn't make that update? According to our CI guys there were some issues with xcode 5.1 & qt earlier but nowdays at least compiling qt with mac 10.9 & xcode 5.1 seems to work OK (in CI). autotest are at least partially insignificants at the moment in that confiquration... And could following be the rule of the thumb in the future: we always support only "latest available Xcode for OS X version" with Qt on OS X ? br, Jani From sean.harmer at kdab.com Fri Sep 5 13:08:43 2014 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 5 Sep 2014 12:08:43 +0100 Subject: [Development] why Qt app performance low on qpa eglfs or wayland In-Reply-To: <904253C43ED48C45ADF9CC50A210C7B302E05BB5@SHAASIEXM01.ASIA.ROOT.PRI> References: <904253C43ED48C45ADF9CC50A210C7B302E057AE@SHAASIEXM01.ASIA.ROOT.PRI> <82923129.Eq3HiTl6cf@milian-kdab2> <904253C43ED48C45ADF9CC50A210C7B302E05BB5@SHAASIEXM01.ASIA.ROOT.PRI> Message-ID: <8F579231-BC08-4215-B33B-C1FD93C0BFA6@kdab.com> On 5 Sep 2014, at 09:39, Nancy Zou wrote: > Hi Millan >> You should answer this question yourself and present the results to us. Only you have your specific software/hardware combination setup properly. > > I suspect Qt wati for vsyc somewhere because the normal opengl example only cost 14ms (1 vsync) and Qt example openglwindow need 28 ms( just 2 vysnc) > I think it's strange a simple opengl example run such low fps. > My fb driver already wait for vsync once in eglSwapBuffers. So Qt don't need wait it. So I want to find out where qt hung. Whether Qt wait for some events somewhere? Qt QPA plugins do the waiting precisely by calling eglSwapBuffers. You can control the swap interval by means of QSurfaceFormat::setSwapInterval(). Pass in a value of 0 to disable any sync, -1 to use adaptive sync (if your driver supports it), any other positive integer for that number of syncs. Also make sure the QPA has the correct refresh rate for your screen. Cheers, Sean > >> Try Linux' `perf top` e.g. or run your application via `perf record --call-graph=dwarf yourapp`. Then do a `perf report` and take a look at the results. Remember to compile your application and all important dependencies (esp. Qt) in release mode with debug symbols, i.e. at least use the compile flags `-O2 -g`. > > I have done this in qmake. > > > Thank you > > Best Regards > Nancy > > > Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom > More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc. > New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development 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 Jani.Heikkinen at digia.com Fri Sep 5 13:54:57 2014 From: Jani.Heikkinen at digia.com (Heikkinen Jani) Date: Fri, 5 Sep 2014 11:54:57 +0000 Subject: [Development] New Qt5.3.2 snapshot available Message-ID: Hi all, We have new Qt5.3.2 snapshot available via offline installers in: Linux: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-05_137/ Mac: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-05_115/ Windows: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-05_145/ Linux & mac is already there, windows is coming. Mirroring is also ongoing so something might be missing but all should be available later today. These aren't yet final Qt5.3.2 packages but really close so please test these & report result in https://wiki.it.local/display/QTCOM/Release+Testing Also if you find new blocker please inform me immediately & link it to https://bugreports.qt-project.org/browse/QTBUG-40712 We are targeting to release Qt5.3.2 16.9.2014 and so on final packages must be available during next week. Maintainers: Change files aren't OK yet, many are missing & some are empty! Please fix those ASAP! Br, Jani From Jani.Heikkinen at digia.com Fri Sep 5 14:07:55 2014 From: Jani.Heikkinen at digia.com (Heikkinen Jani) Date: Fri, 5 Sep 2014 12:07:55 +0000 Subject: [Development] New Qt5.3.2 snapshot available Message-ID: Sorry, wrong link in my previous mail. Use this one to report your testing result http://testresults.qt-project.org/forms/release-testing/index.pl br, Jani >>-----Original Message----- >>From: Heikkinen Jani >>Sent: 5. syyskuuta 2014 14:55 >>To: development at qt-project.org >>Subject: New Qt5.3.2 snapshot available >> >>Hi all, >> >>We have new Qt5.3.2 snapshot available via offline installers in: >> >>Linux: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09- >>05_137/ >>Mac: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09- >>05_115/ >>Windows: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014- >>09-05_145/ >> >>Linux & mac is already there, windows is coming. Mirroring is also ongoing >>so something might be missing but all should be available later today. >> >>These aren't yet final Qt5.3.2 packages but really close so please test these >>& report result in https://wiki.it.local/display/QTCOM/Release+Testing >>Also if you find new blocker please inform me immediately & link it to >>https://bugreports.qt-project.org/browse/QTBUG-40712 >> >>We are targeting to release Qt5.3.2 16.9.2014 and so on final packages >>must be available during next week. >> >>Maintainers: Change files aren't OK yet, many are missing & some are >>empty! Please fix those ASAP! >> >>Br, >>Jani From Jan-Arve.Saether at digia.com Fri Sep 5 16:41:40 2014 From: Jan-Arve.Saether at digia.com (Saether Jan-Arve) Date: Fri, 5 Sep 2014 14:41:40 +0000 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <5408B015.1060105@familiesomers.nl> References: <2394175.ZMiMW6UDsx@tjmaciei-mobl4> <66BFFE861C7DE34D9B0372D8EAAB18E20126E84C@IT-EXMB01-HKI.it.local> <2219726.v61byOGjAv@tjmaciei-mobl4> <5408B015.1060105@familiesomers.nl> Message-ID: <66BFFE861C7DE34D9B0372D8EAAB18E2012748A5@IT-EXMB01-HKI.it.local> > feature. > A quick search for %n in the Qt .ts files would reveal that. I don't > have them here, or I would take a peek. > But even so: Qt could pre-load the Qt .qm file by default from an > internal resource, and I guess that makes sense. There is no need for > a special tr() version to do that. > I would hardly say that Qt uses this feature: Q:\dev\qt-5.3\qttranslations\translations [5.3]> grep "numerus=.yes." *_de.ts | uniq -c 11 designer_de.ts: 8 linguist_de.ts: 1 qt_help_de.ts: 2 qtxmlpatterns_de.ts: Q:\dev\qt-5.3\qttranslations\translations [5.3]> So, it's will only affect applications due to QtHelp and QtXmlPatterns. These are the messages: qt_help_de.ts: %1 - %2 of %n Hits qtxmlpatterns_de.ts: %1 takes at most %n argument(s). %2 is therefore invalid. qtxmlpatterns_de.ts: %1 requires at least %n argument(s). %2 is therefore invalid. So, I think very few people are affected by this and I'm not sure fixing this is worth the effort. If we simply provide qt_US.ts, and the user uses windeployqt it will automatically be deployed in the same way as other .qm files, and it will just work (tm). Jan Arve From thiago.macieira at intel.com Fri Sep 5 21:51:39 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 05 Sep 2014 12:51:39 -0700 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <54096360.8060406@familiesomers.nl> References: <1891215.DKadfNqsyS@tjmaciei-mobl4> <54096360.8060406@familiesomers.nl> Message-ID: <1777477.Lb8So2YqSX@tjmaciei-mobl4> On Friday 05 September 2014 09:16:48 André Somers wrote: > > This did not extract the string for translation. It needs to be something > > that does extract for translation and does translate to another language > > if a translator was loaded. > > I don't see how it properly could. Both strings would be specialized > anyway for the singular and plural case. The singular version probably > would not even have a placemarker for the number in it. How would that > work in the translation? You could still use a translatable string for > both alternatives, but I think that's completely missing the point. You > either do localization, or you don't. This really sounds like a weird > in-between, non-solution to me. Fortunately for us, existing implementations have done this successfully for years and prove it's possible. https://techbase.kde.org/Development/Tutorials/Localization/i18n#Plurals -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Sep 5 21:55:02 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 05 Sep 2014 12:55:02 -0700 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <66BFFE861C7DE34D9B0372D8EAAB18E2012748A5@IT-EXMB01-HKI.it.local> References: <5408B015.1060105@familiesomers.nl> <66BFFE861C7DE34D9B0372D8EAAB18E2012748A5@IT-EXMB01-HKI.it.local> Message-ID: <1748872.MVNdIDCYcI@tjmaciei-mobl4> On Friday 05 September 2014 14:41:40 Saether Jan-Arve wrote: > If we simply provide qt_US.ts, and the user uses windeployqt it will > automatically be deployed in the same way as other .qm files, and it will > just work (tm). I insist that we choose one of two alternatives: 1) provide, deploy inside Qt and automatically load the .qm file for English 2) not require a .qm for *any* message in Qt Lars's email makes it clear he doesn't want a 2-form tr() overload. If we take that as guidance, #2 means stripping any message containing plurals from the Qt sources. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jake.petroules at petroules.com Sat Sep 6 00:54:10 2014 From: jake.petroules at petroules.com (Jake Petroules) Date: Fri, 5 Sep 2014 18:54:10 -0400 Subject: [Development] xcode in ci & packaging for Qt5.4.0 In-Reply-To: References: Message-ID: <6108AE93-BA52-4F2B-9440-B409B65DEA96@petroules.com> On 2014-09-05, at 06:24 AM, Heikkinen Jani wrote: > Hi all, > > QtWebEngine & QtCreator teams has proposed us to update used xcode in packaging & CI machines. At the moment 10.8 mac is using xcode 5.0.2 & 10.9 xcode 5.1.1 . Does someone know any issue why we shouldn't make that update? > According to our CI guys there were some issues with xcode 5.1 & qt earlier but nowdays at least compiling qt with mac 10.9 & xcode 5.1 seems to work OK (in CI). autotest are at least partially insignificants at the moment in that confiquration... > > And could following be the rule of the thumb in the future: > > we always support only "latest available Xcode for OS X version" with Qt on OS X ? > > br, > Jani > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development +1 from me. Apple drops support for older versions of their OSes and tools like hot potatoes and upgrade cycles and short and fast. In fact you're *required* to build with the latest Xcode at least for iOS App Store submissions (https://developer.apple.com/news/?id=04252014a) and I wouldn't be surprised if the same becomes true of OS X with its new pricing and annual release model. We should always have the latest versions of the OSes and Xcode in CI quickly after their release (which means Yosemite and Xcode 6 next month, likely). -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation From xbenlau at gmail.com Sat Sep 6 09:14:23 2014 From: xbenlau at gmail.com (Ben Lau) Date: Sat, 6 Sep 2014 15:14:23 +0800 Subject: [Development] Suggested method to distribute QML library Message-ID: hi all, I am developing a library with set of QML components . It will be shared on Github. I would expect people use it via `git submodule` instead of coping those QML files to their source tree and install to QML module path. As now the default project created by QT Creator uses resource file to manage QML files. I would like to provide a resource file to let user to include and get the library works. That should also simplify the software build and installation process. However, QT Creator can not recognise the import path with "qrc" schema. The syntax highlighting and auto completion do not work. For example, import "qrc:/mylib" MyLibComponent { } QT Creator will put a underline in "MyLibComponent" . But it could be compiled and executed. Any suggested method to solve this problem / distribute a QML library , so that user can bundle the library inside their app easily? Thank for any advise. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kotov.valery at gmail.com Sat Sep 6 13:19:13 2014 From: kotov.valery at gmail.com (=?UTF-8?B?0JLQsNC70LXRgNC40Lkg0JrQvtGC0L7Qsg==?=) Date: Sat, 6 Sep 2014 14:19:13 +0300 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: References: <4328069.n2WERJZXVa@tjmaciei-mobl4> <201409041129.23097.kde@carewolf.com> Message-ID: 2014-09-04 12:44 GMT+03:00 Richard Moore : > On 4 September 2014 10:29, Allan Sandfeld Jensen wrote: > >> On Thursday 04 September 2014, Richard Moore wrote: >> > On 3 September 2014 20:25, Thiago Macieira >> > >> > wrote: >> > > > > How is it represented in HTML5? >> > > > > Just do it the same way. >> > > > >> > > > I'm a little unsure that I understood. Could you please clarify what >> > > > did you mean by "represented in HTML5"? >> > > >> > > XMLHttpRequests have existed in JavaScript and HTML5 for years. How do >> > > they do >> > > this? >> > >> > I actually looked at the specs (both level 1 and level 2) the other day >> and >> > OPTIONS * isn't mentioned at all. >> > >> At least in WebKit, it is an allowed method for open(), eg. >> xhr.open('OPTIONS',..) >> >> > Yeah, the spec mentions OPTIONS, just not the special case of sending an > OPTIONS * request. > > Rich. > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > Thank you everybody for your responses! According to w3c XMLHttpRequest class does not support "OPTIONS *" request. Most likely it will not be supported soon. Please see mailing list thread by using the following link for more details: http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0457.html Do you mind to leave "OPTIONS *" request behind until it is available in w3c specification? There is one more thing. Should we care about cross-origin resource sharing protocol? If I got it right, XMLHttpeRequset should perform "OPTIONS" preflight request before real cors request. Please see links below for more details: http://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0 Does it make sense to have separate method for "OPTIONS" request in QNetworkAccessManager if it is the case (like for get or post)? -- Best regards, Valery -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.laine at m4x.org Sat Sep 6 19:03:07 2014 From: jeremy.laine at m4x.org (=?UTF-8?B?SmVyZW15IExhaW7DqQ==?=) Date: Sat, 06 Sep 2014 19:03:07 +0200 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: References: <4328069.n2WERJZXVa@tjmaciei-mobl4> <201409041129.23097.kde@carewolf.com> Message-ID: <540B3E4B.4050905@m4x.org> On 09/06/2014 01:19 PM, Валерий Котов wrote: > > There is one more thing. Should we care about cross-origin resource > sharing protocol? If I got it right, XMLHttpeRequset should perform > "OPTIONS" preflight request before real cors request. Please see links > below for more details: > http://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0 > Does it make sense to have separate method for "OPTIONS" request in > QNetworkAccessManager if it is the case (like for get or post)? > >From the docs: * QML's XMLHttpRequest does not enforce the same origin policy. => you don't care about cross origin requests, much less preflighting. Jeremy -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.narvaez at computer.org Sun Sep 7 00:41:13 2014 From: david.narvaez at computer.org (David Narvaez) Date: Sat, 6 Sep 2014 18:41:13 -0400 Subject: [Development] Qt::WA_PaintOnScreen Changes In-Reply-To: References: <1462085.IKelrBECYy@perth> <390F5BC42929B24288054D805FD5C3B91BB37667@IT-EXMB01-HKI.it.local> Message-ID: On Sat, Aug 23, 2014 at 12:40 PM, David Narvaez wrote: > I was ready to create my bug report with sample code etc, and came across > > https://bugreports.qt-project.org/browse/QTBUG-26358 > > which seems to be related because I was able to confirm paintEvent is > not called with this flag set. Could somebody take a quick look at > that report and tell me if I should add to that report or create a new > one? I am just wondering since the bug report is quite old. Ping? David E. Narvaez From kotov.valery at gmail.com Sun Sep 7 14:22:09 2014 From: kotov.valery at gmail.com (=?UTF-8?B?0JLQsNC70LXRgNC40Lkg0JrQvtGC0L7Qsg==?=) Date: Sun, 7 Sep 2014 15:22:09 +0300 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: <540B3E4B.4050905@m4x.org> References: <4328069.n2WERJZXVa@tjmaciei-mobl4> <201409041129.23097.kde@carewolf.com> <540B3E4B.4050905@m4x.org> Message-ID: 2014-09-06 20:03 GMT+03:00 Jeremy Lainé : > On 09/06/2014 01:19 PM, Валерий Котов wrote: > > There is one more thing. Should we care about cross-origin resource > sharing protocol? If I got it right, XMLHttpeRequset should perform > "OPTIONS" preflight request before real cors request. Please see links > below for more details: > http://www.w3.org/TR/cors/#cross-origin-request-with-preflight-0 > Does it make sense to have separate method for "OPTIONS" request in > QNetworkAccessManager if it is the case (like for get or post)? > > > From the docs: > > - QML's XMLHttpRequest > > does not enforce the same origin policy. > > => you don't care about cross origin requests, much less preflighting. > > Jeremy > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > Thank you for the answer. Do we need support for "OPTIONS *" http request in QNetworkAccessManager? If no, then patch "QNetworkAccessManager: Support for "OPTIONS" method for http request was added." for qtbase project (Change-Id: Iad281ed4c70696b9fb93211d31ad728c41147a6e) can be rejected. qtbase already has support for "OPTIONS" request (via sendCustomRequest). It is also covered with tests. If yes, how should it be performed? It is possible to send "OPTIONS" request by using sendCustomRequest. But how should user perform "OPTIONS *" request? Should it depend on url? Thank you! Valery -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun Sep 7 18:05:43 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 07 Sep 2014 09:05:43 -0700 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: References: <540B3E4B.4050905@m4x.org> Message-ID: <8760148.goYHNRIdUA@tjmaciei-mobl4> On Sunday 07 September 2014 15:22:09 Валерий Котов wrote: > If yes, how should it be performed? It is possible to send "OPTIONS" > request by using sendCustomRequest. But how should user perform "OPTIONS *" > request? Should it depend on url? I recommend you send OPTIONS * if the URL has no path. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Sep 7 20:13:59 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 07 Sep 2014 11:13:59 -0700 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: <8760148.goYHNRIdUA@tjmaciei-mobl4> References: <8760148.goYHNRIdUA@tjmaciei-mobl4> Message-ID: <108472005.pIvumiNAbW@tjmaciei-mobl4> On Sunday 07 September 2014 09:05:43 Thiago Macieira wrote: > On Sunday 07 September 2014 15:22:09 Валерий Котов wrote: > > If yes, how should it be performed? It is possible to send "OPTIONS" > > request by using sendCustomRequest. But how should user perform "OPTIONS > > *" > > request? Should it depend on url? > > I recommend you send OPTIONS * if the URL has no path. Or not... the problem is what will happen with proxies. I don't have a good proxy to test with. When I tried the Intel proxy with the OPTIONS command, it sent a GET command to the server. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Sep 7 20:16:50 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 07 Sep 2014 11:16:50 -0700 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: <108472005.pIvumiNAbW@tjmaciei-mobl4> References: <8760148.goYHNRIdUA@tjmaciei-mobl4> <108472005.pIvumiNAbW@tjmaciei-mobl4> Message-ID: <1647133.sfdM2NXZhC@tjmaciei-mobl4> On Sunday 07 September 2014 11:13:59 Thiago Macieira wrote: > On Sunday 07 September 2014 09:05:43 Thiago Macieira wrote: > > On Sunday 07 September 2014 15:22:09 Валерий Котов wrote: > > > If yes, how should it be performed? It is possible to send "OPTIONS" > > > request by using sendCustomRequest. But how should user perform "OPTIONS > > > *" > > > request? Should it depend on url? > > > > I recommend you send OPTIONS * if the URL has no path. > > Or not... the problem is what will happen with proxies. > > I don't have a good proxy to test with. When I tried the Intel proxy with > the OPTIONS command, it sent a GET command to the server. Oops, bad testing. It sent "OPTIONS /" to the server in both tests cases (with and without the slash). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From martin.leutelt at basyskom.com Mon Sep 8 09:20:32 2014 From: martin.leutelt at basyskom.com (Martin Leutelt) Date: Mon, 8 Sep 2014 09:20:32 +0200 Subject: [Development] Suggested method to distribute QML library In-Reply-To: Message-ID: <1411534352-14021@mx1.basyskom.com> Hi, take a look at how the qtquickcontrols plugin does it. It bundles the QML components in the plugin. With that approach you could:- provide a prebuilt plugin that users can bundle with their app- allow them to build your plugin library together with their code (and deploy the plugin to the default qml import pathor someplace else which would require adding a custom import path) That way your library can be imported by using a plugin import statement and QtCreator can resolve the typesby a provided .qmltypes file (when using the first approach) or by setting a QML_IMPORT_PATH in the .pro file of theapplication using your library (when going with the second approach). RegardsMartin Ben Lau , 9/6/2014 9:14 AM: hi all, I am developing a library with set of QML components . It will be shared on Github. I would expect people use it via `git submodule` instead of coping those QML files to their source tree and install to QML module path. As now the default project created by QT Creator uses resource file to manage QML files. I would like to provide a resource file to let user to include and get the library works. That should also simplify the software build and installation process. However, QT Creator can not recognise the import path with "qrc" schema. The syntax highlighting and auto completion do not work. For example,   import "qrc:/mylib"   MyLibComponent {  } QT Creator will put a underline in "MyLibComponent" . But it could be compiled and executed.  Any suggested method to solve this problem /  distribute a QML library , so that user can bundle the library inside their app easily? Thank for any advise. _______________________________________________ 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 Mon Sep 8 09:25:01 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Mon, 8 Sep 2014 07:25:01 +0000 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <1777477.Lb8So2YqSX@tjmaciei-mobl4> References: <1891215.DKadfNqsyS@tjmaciei-mobl4> <54096360.8060406@familiesomers.nl> <1777477.Lb8So2YqSX@tjmaciei-mobl4> Message-ID: On 05/09/14 21:51, "Thiago Macieira" wrote: >On Friday 05 September 2014 09:16:48 André Somers wrote: >> > This did not extract the string for translation. It needs to be >>something >> > that does extract for translation and does translate to another >>language >> > if a translator was loaded. >> >> I don't see how it properly could. Both strings would be specialized >> anyway for the singular and plural case. The singular version probably >> would not even have a placemarker for the number in it. How would that >> work in the translation? You could still use a translatable string for >> both alternatives, but I think that's completely missing the point. You >> either do localization, or you don't. This really sounds like a weird >> in-between, non-solution to me. > >Fortunately for us, existing implementations have done this successfully >for >years and prove it's possible. > >https://techbase.kde.org/Development/Tutorials/Localization/i18n#Plurals Yes, this works for KDE that has a policy that all source strings are in english. While we have the same policy for Qt itself, I don’t think we can require the same thing from our users. And then a two form API simply feels wrong. Now I would consider it a good thing if we had a better way of automatically loading all relevant translation files for an application. IMO this also requires a policy of how they get packaged during deployment. Cheers, Lars From Lars.Knoll at digia.com Mon Sep 8 09:27:06 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Mon, 8 Sep 2014 07:27:06 +0000 Subject: [Development] [Interest] Direct-lookup translation, even for English (was Re: get english translation) In-Reply-To: <1748872.MVNdIDCYcI@tjmaciei-mobl4> References: <5408B015.1060105@familiesomers.nl> <66BFFE861C7DE34D9B0372D8EAAB18E2012748A5@IT-EXMB01-HKI.it.local> <1748872.MVNdIDCYcI@tjmaciei-mobl4> Message-ID: On 05/09/14 21:55, "Thiago Macieira" wrote: >On Friday 05 September 2014 14:41:40 Saether Jan-Arve wrote: >> If we simply provide qt_US.ts, and the user uses windeployqt it will >> automatically be deployed in the same way as other .qm files, and it >>will >> just work (tm). > >I insist that we choose one of two alternatives: > >1) provide, deploy inside Qt and automatically load the .qm file for >English No, I think we should automatically load the best matching translation. Of course that can be (and often is) english. Cheers, Lars > >2) not require a .qm for *any* message in Qt > >Lars's email makes it clear he doesn't want a 2-form tr() overload. If we >take >that as guidance, #2 means stripping any message containing plurals from >the >Qt sources. > >-- >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 Jani.Heikkinen at digia.com Mon Sep 8 11:34:46 2014 From: Jani.Heikkinen at digia.com (Heikkinen Jani) Date: Mon, 8 Sep 2014 09:34:46 +0000 Subject: [Development] Qt 5.4 Alpha released Message-ID: Hi all! Qt 5.4 Alpha release is finally out, see http://blog.qt.digia.com/blog/2014/09/08/qt-5-4-alpha-available/ Alpha is source code delivery only. The plan forward is now to create a beta (including binary packages) during the next few weeks, see Qt 5.4 schedule from http://qt-project.org/wiki/Qt-5.4-release Big thanks for everyone who were involved to make this happen! Br, Jani From matthias.walter at neuf.fr Mon Sep 8 12:32:27 2014 From: matthias.walter at neuf.fr (Matthias WALTER) Date: Mon, 8 Sep 2014 12:32:27 +0200 Subject: [Development] QStorageInfo Message-ID: Hello, Today you released the Alpha of Qt 5.4. What is the official status of QStorageInfo "DriveType" ? Do you plan to add this feature in the beta and final release ? Thank you for your answer. Best regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at digia.com Mon Sep 8 13:19:59 2014 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Mon, 8 Sep 2014 13:19:59 +0200 Subject: [Development] Direct-lookup translation, even for English (was Re: [Interest] get english translation) In-Reply-To: References: <4534776.Or6Dd8LZJR@tjmaciei-mobl4> Message-ID: <20140908111959.GC9797@troll08.it.local> i hate to keep you all from wasting even more time, but ... http://doc.qt.digia.com/qt-5.1/qtcore/qtglobal.html#qtTrId https://qt-project.org/wiki/QtInternationalization#43b304ead4174986c238cb4e0c4d5cb0 and on auto-loading: https://bugreports.qt-project.org/browse/QTBUG-34942 (there was actually a lot of related discussion, but i can't find it, so maybe it was nokia-internal. i'll just refer to KComponentData instead now). On Tue, Sep 02, 2014 at 07:01:30AM +0000, Rutledge Shawn wrote: > On 1 Sep 2014, at 8:32 PM, Thiago Macieira wrote: > > On Monday 01 September 2014 12:50:23 Graham Labdon wrote: > >> Hi > >> My application is internationalized, however, in some circumstances I need > >> the English version of the string no matter what translator is being used. > >> Anyone have any suggestions on how to achieve this? > > > > You have the English text. The way to get the English text from that is to use > > it as-is. > > > > Don't translate, don't transform it in any way. > > Some projects like to use "programmer shorthand" for strings and then leave the final text up to a different team. Such teams tend to be capricious and change the English text multiple times (PR and marketing reasons), so it's an advantage not to treat the English text as the key for looking up the translation. (And then the shorthand can be written in any language the programmer likes, too.) > > I had a previous job like that. They had their own cross-platform cross-toolkit translation system, so I wasn't allowed to use tr() at all, and they convinced me that their way was better. They wanted to have all the strings for all the languages inside the binary. And there was a utility to generate an enum for the shorthand strings. Imagine opening up Designer and creating a button, and setting its label to BUTTON_OK. Then you run uic. Then you post-process the generated header file and make it do something like tr(BUTTON_OK), which will use the enum to look up the actual string at runtime, in a fixed-length array in which all strings for a particular language are stored. > > - Since the header modification is part of the build process, it costs the developer no time at all if the translation team wants to change the English text. They do their work independently, and then the application is re-built. > > - At runtime, this kind of lookup is much more efficient than the usual Gnome and KDE ways of looking around the filesystem for separate translation files (but at the cost of bloating the binary somewhat). > > - It is clear to everyone when the translation mechanism is not working or there is an un-translated string: you see the enum shorthand strings instead of the correct strings - no need to wait for a non-English-speaking tester to discover it. > > - There will never be a user who cannot use the app because it wasn't installed correctly and therefore the translation file was not found: the strings are guaranteed to be present as long as someone did the translation work before it shipped. > > The current way of using separate translation files should be kept as a fallback mechanism though, so that people in countries which were neglected by the development team can still do their own translations. This is the good part of the KDE way, that the translation work can be distributed to lots of people around the world. But it's also possible that they could contribute their work back to the original git repo, so that some future build of the application will have those strings built-in. > > I think it's a worthwhile goal that at least commercial Linux binaries ought to be self-contained and portable, so that there is no installation process beyond putting the binary in some directory which is in your path. It wouldn't hurt if the free software community had the goal of zero-install binaries too. The strings could be packaged as compressed resources, so the total space consumed is less. And perhaps resources which are not needed for the current language could even be expunged from memory (at the cost that you then cannot switch languages dynamically). > > But even if it were not for the enum-lookup implementation that they insisted on, our assumption that English needs no translation does not fit the multi-team workflow. There is often an assumption that programmers cannot design UIs because they are not artistic people or because they don't have psychology degrees or haven't studied usability enough. This is why we have separate tools for UI designers to use. It's very similar to the way that some people assume that programmers cannot write good English either. Stereotypes in general are wrong, and offensive to people with multi-disciplinary abilities. Nevertheless we can probably agree that UI design and the wording of text are often subject to later revision; so it's useful not to choose a changing string as a lookup key, for the same reason that imperative code should not assume too much about the declarative structure of the UI. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Mon Sep 8 18:26:07 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 08 Sep 2014 09:26:07 -0700 Subject: [Development] Direct-lookup translation, even for English (was Re: [Interest] get english translation) In-Reply-To: <20140908111959.GC9797@troll08.it.local> References: <20140908111959.GC9797@troll08.it.local> Message-ID: <1654942.hfZ3pSF8Or@tjmaciei-mobl4> On Monday 08 September 2014 13:19:59 Oswald Buddenhagen wrote: > i hate to keep you all from wasting even more time, but ... > > http://doc.qt.digia.com/qt-5.1/qtcore/qtglobal.html#qtTrId > https://qt-project.org/wiki/QtInternationalization#43b304ead4174986c238cb4e0 > c4d5cb0 IIRC, trId was something we fought hard against and it came as a requirement from Nokia (Symbian?) we couldn't dissuade against. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Sep 8 18:27:43 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 08 Sep 2014 09:27:43 -0700 Subject: [Development] QStorageInfo In-Reply-To: References: Message-ID: <2075540.Vp5O5eCx5e@tjmaciei-mobl4> On Monday 08 September 2014 12:32:27 Matthias WALTER wrote: > Hello, > > > > Today you released the Alpha of Qt 5.4. > > > > What is the official status of QStorageInfo "DriveType" ? > > > > Do you plan to add this feature in the beta and final release ? It hasn't been developed yet. If someone provides an implementation in the next week or so and it's small and simple enough, it can still be included in 5.4. Otherwise, it will have to be for 5.5. This would not be a break of feature freeze. QStorageInfo is a new class and I'd classify this as API review (critical functions missing), under the conditions I outlined above. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at digia.com Mon Sep 8 20:48:33 2014 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Mon, 8 Sep 2014 20:48:33 +0200 Subject: [Development] Direct-lookup translation, even for English (was Re: [Interest] get english translation) In-Reply-To: <1654942.hfZ3pSF8Or@tjmaciei-mobl4> References: <20140908111959.GC9797@troll08.it.local> <1654942.hfZ3pSF8Or@tjmaciei-mobl4> Message-ID: <20140908184833.GF9797@troll08.it.local> On Mon, Sep 08, 2014 at 09:26:07AM -0700, Thiago Macieira wrote: > On Monday 08 September 2014 13:19:59 Oswald Buddenhagen wrote: > > i hate to keep you all from wasting even more time, but ... > > > > http://doc.qt.digia.com/qt-5.1/qtcore/qtglobal.html#qtTrId > > https://qt-project.org/wiki/QtInternationalization#43b304ead4174986c238cb4e0 > > c4d5cb0 > > IIRC, trId was something we fought hard against and it came as a requirement > from Nokia (Symbian?) we couldn't dissuade against. > pretty much, yes. which makes this deja vu of a discussion even more ... amusing. From jianliang79 at gmail.com Tue Sep 9 07:31:27 2014 From: jianliang79 at gmail.com (Liang Jian) Date: Tue, 9 Sep 2014 13:31:27 +0800 Subject: [Development] Please take a look at QTBUG-41197 before releasing Qt5.3.2 Message-ID: https://bugreports.qt-project.org/browse/QTBUG-41197 This is a severe issue we recently found under androind. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rainer.keller at digia.com Tue Sep 9 09:33:22 2014 From: rainer.keller at digia.com (Rainer Keller) Date: Tue, 9 Sep 2014 09:33:22 +0200 Subject: [Development] QtSerialPort does not list on-board and USB devices at once Message-ID: <540EAD42.1070800@digia.com> Hi, I am using an i.MX6 device with on-board and USB serial ports. When udev is not available QtSerialPortInfo::availablePorts does not return a list containing both kind of devices. The function availablePortsBySysfs() does only add USB devices to the list because the device path does not contain "pnp", "platform", "usb" or "pci". Device path in this case is "/sys/devices/soc0/soc.1/2000000.aips-bus/2000000.spba-bus/2020000.serial/tty/ttymxc0". Afterwards the function availablePortsByFiltersOfDevices() is only called if the serial port list is still empty. If you have connected a USB serial port the list is not empty and thus the on-board ports are missing. How should I fix this? There are two options in my opinion: 1. Extend availablePortsBySysfs to also handle the on-board serial ports 2. Merge the lists returned by availablePortsByFiltersOfDevices and availablePortsBySysfs regardless if one of these is empty. Best Regards Rainer From rainer.keller at digia.com Tue Sep 9 09:34:18 2014 From: rainer.keller at digia.com (Rainer Keller) Date: Tue, 9 Sep 2014 09:34:18 +0200 Subject: [Development] QtSerialPort does not list on-board and USB devices at once Message-ID: <540EAD7A.7000504@digia.com> Hi, I am using an i.MX6 device with on-board and USB serial ports. When udev is not available QtSerialPortInfo::availablePorts does not return a list containing both kind of devices. The function availablePortsBySysfs() does only add USB devices to the list because the device path does not contain "pnp", "platform", "usb" or "pci". Device path in this case is "/sys/devices/soc0/soc.1/2000000.aips-bus/2000000.spba-bus/2020000.serial/tty/ttymxc0". Afterwards the function availablePortsByFiltersOfDevices() is only called if the serial port list is still empty. If you have connected a USB serial port the list is not empty and thus the on-board ports are missing. How should I fix this? There are two options in my opinion: 1. Extend availablePortsBySysfs to also handle the on-board serial ports 2. Merge the lists returned by availablePortsByFiltersOfDevices and availablePortsBySysfs regardless if one of these is empty. Best Regards Rainer From xbenlau at gmail.com Tue Sep 9 12:07:34 2014 From: xbenlau at gmail.com (Ben Lau) Date: Tue, 9 Sep 2014 18:07:34 +0800 Subject: [Development] Quick Android - QML Component Library for Android Message-ID: Hi , I would like to share my latest open source project here. It is called as Quick Android, a QML component library for Android. Project site: https://github.com/benlau/quickandroid Main Features: 1. Provides “DP” unit 2. Page transition management 3. Multiple type “Drawable” component 1. A single component that supports color , image , QML component , simulated nine patch image as input source 2. Auto scale image to fit current screen resolution 3. Derived StateListDrawable for animated drawable like button 4. Theme / Style Engine 5. Animation Management Although Qt 5.4 will provide Android theme and controls , I just can't wait for it. That is why I started this project. Features like Drawable and nine patch image support is duplicated , but the supported component list will be different. So this library should still be usable even Qt 5.4 come out. You may just think it as an add-on library and just pick the component suitable for you application. If you have any comment , feature request, merge request , please feel free to let me know. The project is unlicensed, you may just copy the needed component into your code. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kotov.valery at gmail.com Tue Sep 9 17:24:58 2014 From: kotov.valery at gmail.com (=?UTF-8?B?0JLQsNC70LXRgNC40Lkg0JrQvtGC0L7Qsg==?=) Date: Tue, 9 Sep 2014 18:24:58 +0300 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: <1647133.sfdM2NXZhC@tjmaciei-mobl4> References: <8760148.goYHNRIdUA@tjmaciei-mobl4> <108472005.pIvumiNAbW@tjmaciei-mobl4> <1647133.sfdM2NXZhC@tjmaciei-mobl4> Message-ID: 2014-09-07 21:16 GMT+03:00 Thiago Macieira : > On Sunday 07 September 2014 11:13:59 Thiago Macieira wrote: > > On Sunday 07 September 2014 09:05:43 Thiago Macieira wrote: > > > On Sunday 07 September 2014 15:22:09 Валерий Котов wrote: > > > > If yes, how should it be performed? It is possible to send "OPTIONS" > > > > request by using sendCustomRequest. But how should user perform > "OPTIONS > > > > *" > > > > request? Should it depend on url? > > > > > > I recommend you send OPTIONS * if the URL has no path. > > > > Or not... the problem is what will happen with proxies. > > > > I don't have a good proxy to test with. When I tried the Intel proxy with > > the OPTIONS command, it sent a GET command to the server. > > Oops, bad testing. It sent "OPTIONS /" to the server in both tests cases > (with > and without the slash). > > -- > 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 > I realize that we had this discussion before. But I have to ask. =) Does not it make sense to add method and type in Operations enum for options in case we need some special treatment for "OPTIONS" verb? -- Valery -------------- next part -------------- An HTML attachment was scrubbed... URL: From haithem.rahmani at gmail.com Wed Sep 10 11:03:48 2014 From: haithem.rahmani at gmail.com (haithem rahmani) Date: Wed, 10 Sep 2014 10:03:48 +0100 Subject: [Development] Qt 5.4 Alpha released Message-ID: Hi, Qt 5.4 Alpha release is finally out, see > http://blog.qt.digia.com/blog/2014/09/08/qt-5-4-alpha-available/ > > Alpha is source code delivery only. The plan forward is now to create a > beta (including binary packages) during the next few weeks, see Qt 5.4 > schedule from http://qt-project.org/wiki/Qt-5.4-release > > Big thanks for everyone who were involved to make this happen! > Great Job! I'm trying to build the qt-5.4.0 for embedded systems, it builds correctly except the QWebEngine that is throwing the following warning: *Project WARNING: QtWebEngine is not maintained for this platform/configuration and is therefore disabled.* So I’m wondering whether the QtWebEngine will be functional or not for embedded platforms in the qt-4.5.0, added to that will it be working with DirectFB QPA/plugin? *regards* *Haithem.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From hald at icandy.de Wed Sep 10 14:31:05 2014 From: hald at icandy.de (Cornelius Hald) Date: Wed, 10 Sep 2014 14:31:05 +0200 Subject: [Development] Memory/Resource leaks in Windows multimedia backend (WMF) In-Reply-To: <1407828783.3502.6.camel@localhost.localdomain> References: <1407828783.3502.6.camel@localhost.localdomain> Message-ID: <1410352265.4706.1.camel@localhost.localdomain> Could someone help review this patch in Gerrit. I think it only needs another +1 https://codereview.qt-project.org/#/c/94115/ Would be great to get that into Qt 5.3.2 which is due in about 6 days... Thanks! Conny On Tue, 2014-08-12 at 09:33 +0200, Cornelius Hald wrote: > Hi! > > Is there a Windows WMF wizard here, who could have a look at the > following bug: > > https://bugreports.qt-project.org/browse/QTBUG-32481 > > If was opened over a year ago and seems to be still valid on Qt 5.3.1. > This bug makes is very difficult to have long-running multimedia > applications. It would be great to get a fix in for Qt 5.3.2. And of > course I'd help testing patches :) > > > Thanks! > Conny > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From szehowe.koh at gmail.com Wed Sep 10 14:47:06 2014 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Wed, 10 Sep 2014 20:47:06 +0800 Subject: [Development] New documentation errors since Qt 5.3.1 Message-ID: Hi all, Using qdoc from Qt 5.4.0 Alpha1, I generated documentation from the "v5.4.0-alpha1" and "v5.3.1" git tags. Then, I diff'ed the qdoc outputs using QDocErrorTracker [1]. Below is a list of errors that are new in Qt 5.4.0 Alpha1. Could those with knowledge of the relevant areas please fix them if time permits? ===== qtbase.git ===== src/corelib/global/qnamespace.qdoc:1252 warning: Undocumented enum item 'Key_Find' in Qt::Key src/corelib/global/qnamespace.qdoc:1252 warning: Undocumented enum item 'Key_Open' in Qt::Key src/corelib/global/qnamespace.qdoc:1252 warning: Undocumented enum item 'Key_MicVolumeUp' in Qt::Key src/corelib/global/qnamespace.qdoc:1252 warning: Undocumented enum item 'Key_Redo' in Qt::Key src/corelib/global/qnamespace.qdoc:1252 warning: Undocumented enum item 'Key_Undo' in Qt::Key src/corelib/global/qnamespace.qdoc:1252 warning: Undocumented enum item 'Key_New' in Qt::Key src/corelib/global/qnamespace.qdoc:1252 warning: Undocumented enum item 'Key_MicVolumeDown' in Qt::Key src/corelib/global/qglobal.cpp:1106 warning: No such enum item 'MV_IOS_8_0' in QSysInfo::MacVersion src/corelib/kernel/qmath.qdoc:206 warning: No such parameter 'radians' in qNextPowerOfTwo() src/corelib/kernel/qmath.qdoc:206 warning: No such parameter 'value' in qRadiansToDegrees() ===== qtmacextras.git ===== src/macextras/qmactoolbar.mm:66 warning: Can't link to 'QWindow::attachToWindow' examples/macextras/embeddedqwindow/doc/src/qtmacextras-example-embeddedqwindow.qdoc:28 warning: Can't link to 'Qt for OS X' src/macextras/doc/src/qtmacextras-examples.qdoc:41 warning: Can't link to 'Qt for OS X' examples/macextras/macfunctions/doc/src/qtmacextras-example-macfunctions.qdoc:28 warning: Can't link to 'Qt for OS X' examples/macextras/macpasteboardmime/doc/src/qtmacextras-example-macpasteboardmime.qdoc:28 warning: Can't link to 'Qt for OS X' ===== qtdeclarative.git ===== src/qml/doc/src/qmlfunctions.qdoc:159 warning: Cannot find 'QQmlEgine' in '\relates' src/qml/doc/src/qmlfunctions.qdoc:181 warning: Cannot find 'QQmlEgine' in '\relates' src/imports/statemachine/finalstate.cpp:73 warning: Cannot find file to quote from: 'qml/statemachine/finalstate.qml' src/imports/statemachine/finalstate.cpp:73 warning: Unable to parse QML snippet: "Expected token `numeric literal'" at line 1, column 1 src/imports/statemachine/finalstate.cpp:73 warning: Unexpected '\snippet (//! [document])' src/imports/statemachine/signaltransition.cpp:227 warning: Cannot find file to quote from: 'qml/statemachine/signaltransition.qml' src/imports/statemachine/signaltransition.cpp:227 warning: Unable to parse QML snippet: "Expected token `numeric literal'" at line 1, column 1 src/imports/statemachine/signaltransition.cpp:227 warning: Unexpected '\snippet (//! [document])' src/imports/statemachine/signaltransition.cpp:239 warning: Cannot find file to quote from: 'qml/statemachine/signaltransitionsignal.qml' src/imports/statemachine/signaltransition.cpp:239 warning: Unable to parse QML snippet: "Expected token `numeric literal'" at line 1, column 1 src/imports/statemachine/signaltransition.cpp:239 warning: Unexpected '\snippet (//! [document])' src/imports/statemachine/signaltransition.cpp:253 warning: Cannot find file to quote from: 'qml/statemachine/guardcondition.qml' src/imports/statemachine/signaltransition.cpp:253 warning: Unable to parse QML snippet: "Expected token `numeric literal'" at line 1, column 1 src/imports/statemachine/signaltransition.cpp:253 warning: Unexpected '\snippet (//! [document])' src/imports/statemachine/statebase.cpp:136 warning: Cannot find file to quote from: 'qml/statemachine/basicstate.qml' src/imports/statemachine/statebase.cpp:136 warning: Unable to parse QML snippet: "Expected token `numeric literal'" at line 1, column 1 src/imports/statemachine/statebase.cpp:136 warning: Unexpected '\snippet (//! [document])' src/imports/statemachine/statebase.cpp:199 warning: Cannot find file to quote from: 'qml/statemachine/historystate.qml' src/imports/statemachine/statebase.cpp:199 warning: Unable to parse QML snippet: "Expected token `numeric literal'" at line 1, column 1 src/imports/statemachine/statebase.cpp:199 warning: Unexpected '\snippet (//! [document])' src/imports/statemachine/statemachine.cpp:117 warning: Cannot find file to quote from: 'qml/statemachine/simplestatemachine.qml' src/imports/statemachine/statemachine.cpp:117 warning: Unable to parse QML snippet: "Expected token `numeric literal'" at line 1, column 1 src/imports/statemachine/statemachine.cpp:117 warning: Unexpected '\snippet (//! [document])' src/imports/statemachine/timeouttransition.cpp:96 warning: Cannot find file to quote from: 'qml/statemachine/timeouttransition.qml' src/imports/statemachine/timeouttransition.cpp:96 warning: Unable to parse QML snippet: "Expected token `numeric literal'" at line 1, column 1 src/imports/statemachine/timeouttransition.cpp:96 warning: Unexpected '\snippet (//! [document])' src/quick/items/qquickwindow.cpp:3848 warning: Cannot find 'QQuickWindow::RenderJobSchedule' specified with '\enum' in any header file src/quick/util/qquickfontmetrics.cpp:320 warning: Invalid syntax in '\qmlmethod' src/quick/util/qquicktextmetrics.cpp:198 warning: QML property documented multiple times: 'real QtQuick::TextMetrics::width' src/quick/util/qquicktextmetrics.cpp:245 warning: Invalid syntax in '\qmlmethod' src/quick/items/qquickframebufferobject.cpp:283 warning: No documentation for 'QQuickFramebufferObject::isTextureProvider()' src/quick/items/qquickframebufferobject.cpp:301 warning: No documentation for 'QQuickFramebufferObject::releaseResources()' src/quick/items/qquickframebufferobject.cpp:288 warning: No documentation for 'QQuickFramebufferObject::textureProvider()' src/quick/items/qquickpainteditem.cpp:570 warning: No documentation for 'QQuickPaintedItem::isTextureProvider()' src/quick/items/qquickpainteditem.cpp:552 warning: No documentation for 'QQuickPaintedItem::releaseResources()' src/quick/items/qquickpainteditem.cpp:575 warning: No documentation for 'QQuickPaintedItem::textureProvider()' src/quick/items/qquickrendercontrol.cpp:144 warning: No documentation for 'QQuickRenderControl::QQuickRenderControl()' src/quick/items/qquickwindow.h:75 warning: No documentation for 'QQuickWindow::RenderStage' src/quick/items/qquickwindow.cpp:3908 warning: No documentation for 'QQuickWindow::qmlAttachedProperties()' examples/quick/demos/maroon/doc/src/maroon.qdoc:28 warning: Can't link to 'SoundEffect' examples/quick/demos/maroon/doc/src/maroon.qdoc:28 warning: Can't link to 'Qt Quick Particles' src/quick/util/qquicktextmetrics.cpp:120 warning: Can't link to 'elidedText' src/quick/util/qquicktextmetrics.cpp:149 warning: Can't link to 'elidedText' src/quick/util/qquickfontmetrics.cpp:268 warning: Can't link to 'height()' src/quick/util/qquickfontmetrics.cpp:337 warning: No documentation for 'FontMetrics::elidedText' src/quick/util/qquicktextmetrics.cpp:40 error: HTML file already exists; overwriting qtbase/doc/qtquick/qml-qtquick-textmetrics.html src/quick/util/qquicktextmetrics.cpp:40 error: HTML file already exists; overwriting qtbase/doc/qtquick/qml-qtquick-textmetrics-members.html ===== qtconnectivity.git ===== src/bluetooth/qlowenergyservice.cpp:300 warning: Can't link to 'createServiceObject()' ===== qtquickcontrols.git ===== src/controls/ToolButton.qml:79 warning: Unable to parse QML snippet: "Expected token `}'" at line 2, column 5 src/controls/doc/src/qtquickcontrols-examples.qdoc:127 warning: Unable to parse QML snippet: "Expected token `numeric literal'" at line 2, column 1 src/controls/doc/src/qtquickcontrols-examples.qdoc:189 warning: Command '\printuntil' failed at end of file 'calendar/src/sqleventmodel.cpp' src/dialogs/qquickdialog.cpp:296 warning: QML property documented multiple times: 'bool Dialog::visible' src/dialogs/qquickdialog.cpp:388 warning: Can't link to 'clickedButton' src/dialogs/qquickdialog.cpp:73 warning: Can't link to 'accept()' src/dialogs/qquickdialog.cpp:81 warning: Can't link to 'reject()' src/dialogs/qquickplatformfiledialog.cpp:44 warning: Can't link to 'QCoreApplication::applicationName' src/dialogs/qquickplatformfiledialog.cpp:44 warning: Can't link to 'QCoreApplication::organizationName' src/dialogs/qquickplatformfiledialog.cpp:44 warning: Can't link to 'QCoreApplication::organizationDomain' ===== qtmultimedia.git ===== src/imports/multimedia/qdeclarativecamera.cpp:923 warning: No QML property group command found; using \qmlpropertygroup QtMultimedia::Camera::metaData src/imports/multimedia/qdeclarativecamera.cpp:1000 warning: No QML property group command found; using \qmlpropertygroup QtMultimedia::Camera::viewfinder ===== qtdoc.git ===== doc/src/qmlapp/glossary.qdoc:28 warning: Can't link to 'qtquick-qmltypereference.html' doc/src/qmlapp/usecases/layouts.qdoc:27 warning: Can't link to 'qtquick-qmltypereference.html#positioning' ===== qtlocation.git ===== src/location/doc/src/examples/declarative-places.qdoc:28 warning: Can't link to 'GeoCircle' src/location/doc/src/qml-maps.qdoc:35 warning: Can't link to 'GeoCodeModel' Thanks, Sze-Howe [1] https://github.com/JKSH/QDocErrorTracker -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Sep 10 22:15:44 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Sep 2014 13:15:44 -0700 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: References: <1647133.sfdM2NXZhC@tjmaciei-mobl4> Message-ID: <4186810.OPd7p1Dhy6@tjmaciei-mobl4> On Tuesday 09 September 2014 18:24:58 Валерий Котов wrote: > I realize that we had this discussion before. But I have to ask. =) > Does not it make sense to add method and type in Operations enum for > options in case we need some special treatment for "OPTIONS" verb? Only if we have a method for it and we're not adding one. If it's just sendCustomVerb, then we don't need an enum entry. By the way, do you know of who would need OPTIONS *? What's the use-case, who would use it and how do they do it today? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Sep 10 22:17:20 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Sep 2014 13:17:20 -0700 Subject: [Development] Qt 5.4 Alpha released In-Reply-To: References: Message-ID: <14847813.jevkSNTYrS@tjmaciei-mobl4> On Wednesday 10 September 2014 10:03:48 haithem rahmani wrote: > So I’m wondering whether the QtWebEngine will be functional or not for > embedded platforms in the qt-4.5.0, added to that will it > be working with DirectFB QPA/plugin? It's unlikely it will work with DirectFB for now. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rich at kde.org Thu Sep 11 00:08:37 2014 From: rich at kde.org (Richard Moore) Date: Wed, 10 Sep 2014 23:08:37 +0100 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: <4186810.OPd7p1Dhy6@tjmaciei-mobl4> References: <1647133.sfdM2NXZhC@tjmaciei-mobl4> <4186810.OPd7p1Dhy6@tjmaciei-mobl4> Message-ID: On 10 September 2014 21:15, Thiago Macieira wrote: > On Tuesday 09 September 2014 18:24:58 Валерий Котов wrote: > > I realize that we had this discussion before. But I have to ask. =) > > Does not it make sense to add method and type in Operations enum for > > options in case we need some special treatment for "OPTIONS" verb? > > Only if we have a method for it and we're not adding one. If it's just > sendCustomVerb, then we don't need an enum entry. > > By the way, do you know of who would need OPTIONS *? What's the use-case, > who > would use it and how do they do it today? > > Given the previous discussions referenced from the working groups for xmlhttprequest I think it's pretty clear that we can forget about OPTIONS *. Just using a custom verb and implementing it in the xmlhttprequest implementation of qml seems like the way to go. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marco.Bubke at digia.com Thu Sep 11 13:23:16 2014 From: Marco.Bubke at digia.com (Bubke Marco) Date: Thu, 11 Sep 2014 11:23:16 +0000 Subject: [Development] Utf8 local aware compare Message-ID: Hi Okay, first the context. I want to write locale aware compare collations for a local database which is saving the text in UTF-8. So converting the text always with QString::fromUtf8 is a little bit expensive. Under Unix strcoll would work but for windows there is no UTF-8 collation. One idea around that problem is to convert per character to UTF-16 and than compare it. Is there some internal API where I could do the conversion per character(not per byte)? Anyway, best would be: QCollator::compare(const char *utf8String1, const char *utf8String2, size_t size1=-1, size_t size2=-1) const Thank you, Marco -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at digia.com Thu Sep 11 14:09:07 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Thu, 11 Sep 2014 12:09:07 +0000 Subject: [Development] Utf8 local aware compare Message-ID: Hi Marco, On 11/09/14 13:23, "Bubke Marco" wrote: >Okay, first the context. I want to write locale aware compare collations >for a local database which is saving the text in UTF-8. So converting the >text always with QString::fromUtf8 is a little bit expensive. Under Unix >strcoll would work but for windows there > is no UTF-8 collation. One idea around that problem is to convert per >character to UTF-16 and than compare it. Is there some internal API where >I could do the conversion per character(not per byte)? There’s no real way to do this. Collation needs to work on whole strings, and can’t compare byte by byte. And the platform APIs on Windows, Mac and ICU are all utf16 based. So the API below wouldn’t help as we’d still have to convert the string to utf16 before passing it into the platform APIs. Lars > > >Anyway, best would be: > >QCollator >::compare >(const char >*utf8String1, const char *utf8String2, > size_t size1=-1, size_t size2=-1) const > >Thank you, Marco > > > > From Marco.Bubke at digia.com Thu Sep 11 14:53:45 2014 From: Marco.Bubke at digia.com (Bubke Marco) Date: Thu, 11 Sep 2014 12:53:45 +0000 Subject: [Development] Utf8 local aware compare In-Reply-To: References: Message-ID: What about icu::Collator::compareUTF8() in ICU? http://userguide.icu-project.org/strings/utf-8: "ICU has some APIs dedicated for UTF-8. They tend to have been added for "worker functions" like comparing strings, to avoid the string conversion overhead, rather than for "builder functions" like factory methods and attribute setters. For example, icu::Collator::compareUTF8() compares two UTF-8 strings incrementally, without converting all of the two strings to UTF-16 if there is an early base letter difference." My understanding is that if your UTF-8 charakters are precomposed you can do it. ________________________________________ From: Knoll Lars Sent: Thursday, September 11, 2014 2:09 PM To: Bubke Marco; development at qt-project.org Subject: Re: [Development] Utf8 local aware compare Hi Marco, On 11/09/14 13:23, "Bubke Marco" wrote: >Okay, first the context. I want to write locale aware compare collations >for a local database which is saving the text in UTF-8. So converting the >text always with QString::fromUtf8 is a little bit expensive. Under Unix >strcoll would work but for windows there > is no UTF-8 collation. One idea around that problem is to convert per >character to UTF-16 and than compare it. Is there some internal API where >I could do the conversion per character(not per byte)? There’s no real way to do this. Collation needs to work on whole strings, and can’t compare byte by byte. And the platform APIs on Windows, Mac and ICU are all utf16 based. So the API below wouldn’t help as we’d still have to convert the string to utf16 before passing it into the platform APIs. Lars > > >Anyway, best would be: > >QCollator >::compare >(const char >*utf8String1, const char *utf8String2, > size_t size1=-1, size_t size2=-1) const > >Thank you, Marco > > > > From Jani.Heikkinen at digia.com Thu Sep 11 16:38:46 2014 From: Jani.Heikkinen at digia.com (Heikkinen Jani) Date: Thu, 11 Sep 2014 14:38:46 +0000 Subject: [Development] Qt5.3.2 final candidate packages available Message-ID: Hi all, Qt 5.3.2 final candidate packages are available here: Windows: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-11_150 Linux: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-11_141 Mac: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-11_119 Mirroring is ongoing and first packages are already there. Rest ones should be available within next few hours. We are targeting to release Qt5.3.2 (these packages) Tue 16th Sep if nothing serious found during testing. Please take a tour & check that everything is still working as expected and report your effort via http://testresults.qt-project.org/forms/release-testing/index.pl Br, Jani From oswald.buddenhagen at digia.com Thu Sep 11 16:59:56 2014 From: oswald.buddenhagen at digia.com (Oswald Buddenhagen) Date: Thu, 11 Sep 2014 16:59:56 +0200 Subject: [Development] [FYI] if you find diffing in gerrit slow ... Message-ID: <20140911145956.GA7724@troll08.it.local> ... then use chrome/chromium. because the slowness is coming from gerrit running massive amounts of js in your browser, and chrome is literally an order of magnitude faster at it than firefox (no clue about ie). if you already use it, well, tough luck. get a cryo-cooled cpu, or something. if you hate it (like i do), tough luck, too - it won't get better until we upgrade to gerrit 2.11 (presumably), which is more than half a year in the future. on the bright side, many of the smaller annoyances which resulted from the upgrade will be resolved somewhat soon. this, btw, also means that i'll be finally able to actually run the auto-abandoning of stale changes, so it would be a good idea to do another round of pings/cleanup/deferring yourself. From thiago.macieira at intel.com Thu Sep 11 17:10:15 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 Sep 2014 08:10:15 -0700 Subject: [Development] Utf8 local aware compare In-Reply-To: References: Message-ID: <1944472.hfiogXPAlZ@tjmaciei-mobl4> On Thursday 11 September 2014 12:53:45 Bubke Marco wrote: > What about icu::Collator::compareUTF8() in ICU? We can't use ICU's C++ API, since they don't promise stability. And we don't use ICU collation on all platforms. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From robert.loehning at digia.com Thu Sep 11 17:38:40 2014 From: robert.loehning at digia.com (=?windows-1252?Q?Robert_L=F6hning?=) Date: Thu, 11 Sep 2014 17:38:40 +0200 Subject: [Development] Qt5.3.2 final candidate packages available In-Reply-To: References: Message-ID: <5411C200.1030500@digia.com> Hi Jani, two of these links are dead for me. Could you please double-check them? Thanks, Robert Am 11.09.2014 um 16:38 schrieb Heikkinen Jani: > Hi all, > > Qt 5.3.2 final candidate packages are available here: > > Windows: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-11_150 > Linux: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-11_141 > Mac: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-11_119 > > Mirroring is ongoing and first packages are already there. Rest ones should be available within next few hours. > > We are targeting to release Qt5.3.2 (these packages) Tue 16th Sep if nothing serious found during testing. > Please take a tour & check that everything is still working as expected and report your effort via http://testresults.qt-project.org/forms/release-testing/index.pl > > Br, > Jani > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From robert.loehning at digia.com Thu Sep 11 18:10:29 2014 From: robert.loehning at digia.com (=?windows-1252?Q?Robert_L=F6hning?=) Date: Thu, 11 Sep 2014 18:10:29 +0200 Subject: [Development] Qt5.3.2 final candidate packages available In-Reply-To: References: Message-ID: <5411C975.3020009@digia.com> Hi Jani, the Installer for Linux claims to contain Qt Creator 3.2.0 (wrong) but it installs Qt Creator 3.2.1 (right). Might this be a showstopper? Best Regards, Robert Am 11.09.2014 um 16:38 schrieb Heikkinen Jani: > Hi all, > > Qt 5.3.2 final candidate packages are available here: > > Windows: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-11_150 > Linux: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-11_141 > Mac: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-11_119 > > Mirroring is ongoing and first packages are already there. Rest ones should be available within next few hours. > > We are targeting to release Qt5.3.2 (these packages) Tue 16th Sep if nothing serious found during testing. > Please take a tour & check that everything is still working as expected and report your effort via http://testresults.qt-project.org/forms/release-testing/index.pl > > Br, > Jani > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From robert.loehning at digia.com Thu Sep 11 18:11:15 2014 From: robert.loehning at digia.com (=?windows-1252?Q?Robert_L=F6hning?=) Date: Thu, 11 Sep 2014 18:11:15 +0200 Subject: [Development] Qt5.3.2 final candidate packages available In-Reply-To: <5411C975.3020009@digia.com> References: <5411C975.3020009@digia.com> Message-ID: <5411C9A3.3020105@digia.com> https://bugreports.qt-project.org/browse/QTBUG-41261 Am 11.09.2014 um 18:10 schrieb Robert Löhning: > Hi Jani, > > the Installer for Linux claims to contain Qt Creator 3.2.0 (wrong) but > it installs Qt Creator 3.2.1 (right). Might this be a showstopper? > > Best Regards, > Robert > > > Am 11.09.2014 um 16:38 schrieb Heikkinen Jani: >> Hi all, >> >> Qt 5.3.2 final candidate packages are available here: >> >> Windows: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-11_150 >> Linux: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-11_141 >> Mac: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-11_119 >> >> Mirroring is ongoing and first packages are already there. Rest ones should be available within next few hours. >> >> We are targeting to release Qt5.3.2 (these packages) Tue 16th Sep if nothing serious found during testing. >> Please take a tour & check that everything is still working as expected and report your effort via http://testresults.qt-project.org/forms/release-testing/index.pl >> >> Br, >> Jani >> _______________________________________________ >> 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 samuel.gaist at edeltech.ch Thu Sep 11 18:28:58 2014 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Thu, 11 Sep 2014 18:28:58 +0200 Subject: [Development] moc 4.8.6 & macros Message-ID: <569B2BFA-D09B-4380-8ED4-D115714A6A83@edeltech.ch> Hi, I've stumbled on https://bugreports.qt-project.org/browse/QTBUG-41190 which states that QtSerialPort cannot be built with Qt 4.8.6. From a quick look and build, it's the use of the QT_DEPRECATED_SINCE macro around the signals that makes moc miss them and thus the compilation fails. Is there something that can be done outside of moc to workaround the problem ? Or does moc need to be improved ? Thanks Samuel From thiago.macieira at intel.com Thu Sep 11 20:50:35 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 Sep 2014 11:50:35 -0700 Subject: [Development] moc 4.8.6 & macros In-Reply-To: <569B2BFA-D09B-4380-8ED4-D115714A6A83@edeltech.ch> References: <569B2BFA-D09B-4380-8ED4-D115714A6A83@edeltech.ch> Message-ID: <9101457.a9tkoRn56K@tjmaciei-mobl4> On Thursday 11 September 2014 18:28:58 Samuel Gaist wrote: > Hi, > > I've stumbled on https://bugreports.qt-project.org/browse/QTBUG-41190 which > states that QtSerialPort cannot be built with Qt 4.8.6. > >From a quick look and build, it's the use of the QT_DEPRECATED_SINCE macro > >around the signals that makes moc miss them and thus the compilation > >fails. > Is there something that can be done outside of moc to workaround the problem > ? Or does moc need to be improved ? NEVER #ifndef signals and slots, unless it's a simple #ifdef/#ifndef and the #define is present in the source file being processed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From samuel.gaist at edeltech.ch Thu Sep 11 21:44:15 2014 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Thu, 11 Sep 2014 21:44:15 +0200 Subject: [Development] moc 4.8.6 & macros In-Reply-To: <9101457.a9tkoRn56K@tjmaciei-mobl4> References: <569B2BFA-D09B-4380-8ED4-D115714A6A83@edeltech.ch> <9101457.a9tkoRn56K@tjmaciei-mobl4> Message-ID: On 11 sept. 2014, at 20:50, Thiago Macieira wrote: > On Thursday 11 September 2014 18:28:58 Samuel Gaist wrote: >> Hi, >> >> I've stumbled on https://bugreports.qt-project.org/browse/QTBUG-41190 which >> states that QtSerialPort cannot be built with Qt 4.8.6. >>> From a quick look and build, it's the use of the QT_DEPRECATED_SINCE macro >>> around the signals that makes moc miss them and thus the compilation >>> fails. >> Is there something that can be done outside of moc to workaround the problem >> ? Or does moc need to be improved ? > > NEVER #ifndef signals and slots, unless it's a simple #ifdef/#ifndef and the > #define is present in the source file being processed. > The thing is, it's not even a #ifdef, it's only a #if What would be the correct procedure to handle QT_DEPRECATED_SINCE ? Removing it from around the signal declaration would make the code a bit inconsistent. By the way, how is it handled in Qt 5 since building goes without any problem even with the macros around the signal ? From thiago.macieira at intel.com Thu Sep 11 21:49:48 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 Sep 2014 12:49:48 -0700 Subject: [Development] moc 4.8.6 & macros In-Reply-To: References: <569B2BFA-D09B-4380-8ED4-D115714A6A83@edeltech.ch> <9101457.a9tkoRn56K@tjmaciei-mobl4> Message-ID: <1567149.n7snu8CGW5@tjmaciei-mobl4> On Thursday 11 September 2014 21:44:15 Samuel Gaist wrote: > What would be the correct procedure to handle QT_DEPRECATED_SINCE ? Removing > it from around the signal declaration would make the code a bit > inconsistent. > > By the way, how is it handled in Qt 5 since building goes without any > problem even with the macros around the signal ? moc is smarter in Qt 5: it expands macros. But the recommendation stands: do not #if (of any kind) anything that isn't #defined in the same source, in a header next to the one being compiled, or passed as -D in the command-line. That means: don't hide signals and slots with #if, even for deprecation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From samuel.gaist at edeltech.ch Thu Sep 11 22:03:03 2014 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Thu, 11 Sep 2014 22:03:03 +0200 Subject: [Development] moc 4.8.6 & macros In-Reply-To: <1567149.n7snu8CGW5@tjmaciei-mobl4> References: <569B2BFA-D09B-4380-8ED4-D115714A6A83@edeltech.ch> <9101457.a9tkoRn56K@tjmaciei-mobl4> <1567149.n7snu8CGW5@tjmaciei-mobl4> Message-ID: On 11 sept. 2014, at 21:49, Thiago Macieira wrote: > On Thursday 11 September 2014 21:44:15 Samuel Gaist wrote: >> What would be the correct procedure to handle QT_DEPRECATED_SINCE ? Removing >> it from around the signal declaration would make the code a bit >> inconsistent. >> >> By the way, how is it handled in Qt 5 since building goes without any >> problem even with the macros around the signal ? > > moc is smarter in Qt 5: it expands macros. > > But the recommendation stands: do not #if (of any kind) anything that isn't > #defined in the same source, in a header next to the one being compiled, or > passed as -D in the command-line. > > That means: don't hide signals and slots with #if, even for deprecation. I thought I've read somewhere that moc got better at this job :-) It seems that the new moc doesn't use much of the Qt 5 only classes, would it be useful to backport it to Qt 4 to avoid having to "break" the code style for modules supporting both series ? From kotov.valery at gmail.com Fri Sep 12 00:19:30 2014 From: kotov.valery at gmail.com (Valery Kotov) Date: Fri, 12 Sep 2014 01:19:30 +0300 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: References: <1647133.sfdM2NXZhC@tjmaciei-mobl4> <4186810.OPd7p1Dhy6@tjmaciei-mobl4> Message-ID: Greetings everybody! Thank you for your responses. > Given the previous discussions referenced from the working groups for xmlhttprequest I think it's pretty clear that we can forget about OPTIONS *. Just using a > custom verb and implementing it in the xmlhttprequest implementation of qml seems like the way to go. Ok. Then https://codereview.qt-project.org/#/c/92664/ patch can be rejected. It does not contain valuable changes. "OPTIONS" is already supported by "sendCustomRequest" and covered with tests. Should I perform any actions to reject the patch? > By the way, do you know of who would need OPTIONS *? What's the use-case, who > would use it and how do they do it today? Unfortunately, I can't think of any specific use case except getting general server settings. For example (from specification), OPTIONS request can be used to test proxy for HTTP/1.1 conformance. Another use case for using "OPTIONS *": preflight request in case of using CORS. -- Sincerely yours, Valery Kotov -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Sep 12 00:48:16 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 Sep 2014 15:48:16 -0700 Subject: [Development] QTBUG-35892. QML XMLHttpRequest does not support the OPTIONS method. In-Reply-To: References: Message-ID: <2652976.3vldRKJaCB@tjmaciei-mobl4> On Friday 12 September 2014 01:19:30 Valery Kotov wrote: > Greetings everybody! Thank you for your responses. > > > Given the previous discussions referenced from the working groups for > > xmlhttprequest I think it's pretty clear that we can forget about OPTIONS > *. Just using a > > > custom verb and implementing it in the xmlhttprequest implementation of > > qml seems like the way to go. > Ok. Then https://codereview.qt-project.org/#/c/92664/ patch can be > rejected. It does not contain valuable changes. "OPTIONS" is already > supported by "sendCustomRequest" and covered with tests. Should I perform > any actions to reject the patch? Abandon it. > > By the way, do you know of who would need OPTIONS *? What's the use-case, > who > > would use it and how do they do it today? > > Unfortunately, I can't think of any specific use case except getting > general server settings. For example (from specification), OPTIONS request > can be used to test proxy for HTTP/1.1 conformance. Another use case for > using "OPTIONS *": preflight request in case of using CORS. Most proxies are HTTP/1.0... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Sep 12 00:49:50 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 Sep 2014 15:49:50 -0700 Subject: [Development] moc 4.8.6 & macros In-Reply-To: References: <569B2BFA-D09B-4380-8ED4-D115714A6A83@edeltech.ch> <1567149.n7snu8CGW5@tjmaciei-mobl4> Message-ID: <16214071.DxXmf7ZR4y@tjmaciei-mobl4> On Thursday 11 September 2014 22:03:03 Samuel Gaist wrote: > I thought I've read somewhere that moc got better at this job :-) > > It seems that the new moc doesn't use much of the Qt 5 only classes, would > it be useful to backport it to Qt 4 to avoid having to "break" the code > style for modules supporting both series ? Definitely not. Too intrusive a change. We did find breakage long after the change went in so we know for a fact that there's Qt 4 code that will start to silently fail. No, fix qtserialport and anywhere else that a signal or a slot got #ifndef'ed out. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jani.Heikkinen at digia.com Fri Sep 12 06:47:11 2014 From: Jani.Heikkinen at digia.com (Heikkinen Jani) Date: Fri, 12 Sep 2014 04:47:11 +0000 Subject: [Development] Qt5.3.2 final candidate packages available In-Reply-To: <5411C9A3.3020105@digia.com> References: <5411C975.3020009@digia.com> <5411C9A3.3020105@digia.com> Message-ID: <6d402762a9de494d8a80019b13ef8075@DB3PR02MB0569.eurprd02.prod.outlook.com> Arg, we will repackage the packages but no updates to qt content Br, Jani >>-----Original Message----- >>From: Loehning Robert >>Sent: 11. syyskuuta 2014 19:11 >>To: development at qt-project.org; Heikkinen Jani >>Subject: Re: [Development] Qt5.3.2 final candidate packages available >> >>https://bugreports.qt-project.org/browse/QTBUG-41261 >> >>Am 11.09.2014 um 18:10 schrieb Robert Löhning: >>> Hi Jani, >>> >>> the Installer for Linux claims to contain Qt Creator 3.2.0 (wrong) but >>> it installs Qt Creator 3.2.1 (right). Might this be a showstopper? >>> >>> Best Regards, >>> Robert >>> >>> >>> Am 11.09.2014 um 16:38 schrieb Heikkinen Jani: >>>> Hi all, >>>> >>>> Qt 5.3.2 final candidate packages are available here: >>>> >>>> Windows: http://download.qt- >>project.org/snapshots/qt/5.3/5.3.2/2014-09-11_150 >>>> Linux: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09- >>11_141 >>>> Mac: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09- >>11_119 >>>> >>>> Mirroring is ongoing and first packages are already there. Rest ones >>should be available within next few hours. >>>> >>>> We are targeting to release Qt5.3.2 (these packages) Tue 16th Sep if >>nothing serious found during testing. >>>> Please take a tour & check that everything is still working as expected >>and report your effort via http://testresults.qt-project.org/forms/release- >>testing/index.pl >>>> >>>> Br, >>>> Jani >>>> _______________________________________________ >>>> 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 samuel.gaist at edeltech.ch Fri Sep 12 09:14:14 2014 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Fri, 12 Sep 2014 09:14:14 +0200 Subject: [Development] Qt5.3.2 final candidate packages available In-Reply-To: <6d402762a9de494d8a80019b13ef8075@DB3PR02MB0569.eurprd02.prod.outlook.com> References: <5411C975.3020009@digia.com> <5411C9A3.3020105@digia.com> <6d402762a9de494d8a80019b13ef8075@DB3PR02MB0569.eurprd02.prod.outlook.com> Message-ID: <0A55DE0C-2ECF-4902-A7C3-21672AD77EAB@edeltech.ch> Hi, I don't think it qualifies as a showstopper but currently the build of QtSerialPort is broken for Qt 4. Since people could use the sources from the released packages to build that module it could create some mild grievance amongst our users. There's https://codereview.qt-project.org/#/c/94448/ <- Make the tests build https://codereview.qt-project.org/#/c/94451/ <- code/doc cleanup https://codereview.qt-project.org/#/c/94682/ <- Make the library build To fix the situation Best regards Samuel On 12 sept. 2014, at 06:47, Heikkinen Jani wrote: > Arg, we will repackage the packages but no updates to qt content > > Br, > Jani > >>> -----Original Message----- >>> From: Loehning Robert >>> Sent: 11. syyskuuta 2014 19:11 >>> To: development at qt-project.org; Heikkinen Jani >>> Subject: Re: [Development] Qt5.3.2 final candidate packages available >>> >>> https://bugreports.qt-project.org/browse/QTBUG-41261 >>> >>> Am 11.09.2014 um 18:10 schrieb Robert Löhning: >>>> Hi Jani, >>>> >>>> the Installer for Linux claims to contain Qt Creator 3.2.0 (wrong) but >>>> it installs Qt Creator 3.2.1 (right). Might this be a showstopper? >>>> >>>> Best Regards, >>>> Robert >>>> >>>> >>>> Am 11.09.2014 um 16:38 schrieb Heikkinen Jani: >>>>> Hi all, >>>>> >>>>> Qt 5.3.2 final candidate packages are available here: >>>>> >>>>> Windows: http://download.qt- >>> project.org/snapshots/qt/5.3/5.3.2/2014-09-11_150 >>>>> Linux: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09- >>> 11_141 >>>>> Mac: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09- >>> 11_119 >>>>> >>>>> Mirroring is ongoing and first packages are already there. Rest ones >>> should be available within next few hours. >>>>> >>>>> We are targeting to release Qt5.3.2 (these packages) Tue 16th Sep if >>> nothing serious found during testing. >>>>> Please take a tour & check that everything is still working as expected >>> and report your effort via http://testresults.qt-project.org/forms/release- >>> testing/index.pl >>>>> >>>>> Br, >>>>> Jani >>>>> _______________________________________________ >>>>> 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 olivier at woboq.com Fri Sep 12 11:14:59 2014 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 12 Sep 2014 11:14:59 +0200 Subject: [Development] moc 4.8.6 & macros In-Reply-To: References: <569B2BFA-D09B-4380-8ED4-D115714A6A83@edeltech.ch> <1567149.n7snu8CGW5@tjmaciei-mobl4> Message-ID: <2491015.1v2Rk5ZfCg@finn> On Thursday 11 September 2014 22:03:03 Samuel Gaist wrote: > On 11 sept. 2014, at 21:49, Thiago Macieira wrote: > > On Thursday 11 September 2014 21:44:15 Samuel Gaist wrote: > >> What would be the correct procedure to handle QT_DEPRECATED_SINCE ? > >> Removing it from around the signal declaration would make the code a bit > >> inconsistent. > >> > >> By the way, how is it handled in Qt 5 since building goes without any > >> problem even with the macros around the signal ? > > > > moc is smarter in Qt 5: it expands macros. > > > > But the recommendation stands: do not #if (of any kind) anything that > > isn't > > #defined in the same source, in a header next to the one being compiled, > > or > > passed as -D in the command-line. > > > > That means: don't hide signals and slots with #if, even for deprecation. > > I thought I've read somewhere that moc got better at this job :-) I would not be as strict as Thiago. In Qt5 it's fine to use the preprocessor as long as moc can see the defines (that is, if they don't rely on compiler built-in or need special include paths.) QT_DEPRECATED_SINCE should be fine. It is strange it does not work with Qt4. Are you sure that all the include paths are passed to moc? Otherwise, you will have to work around it somehow. try #if not QT_DEPRECATED_SINCE() #else Or some other trick with Q_MOC_RUN You can also use the QT_MOC_COMPAT macro in front of a declaration so QObject will throw a runtime warning when connecting to this signal. (in debug mode) > It seems that the new moc doesn't use much of the Qt 5 only classes, would > it be useful to backport it to Qt 4 to avoid having to "break" the code > style for modules supporting both series ? This is out of question. This is a behaviour change as Qt4 code relied on moc not expending the macro in some cases. (At some point it will be time to switch fully to Qt5 and drop Qt4 support) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From Jani.Heikkinen at digia.com Fri Sep 12 12:37:36 2014 From: Jani.Heikkinen at digia.com (Heikkinen Jani) Date: Fri, 12 Sep 2014 10:37:36 +0000 Subject: [Development] Qt5.3.2 final candidate packages available References: <5411C975.3020009@digia.com> <5411C9A3.3020105@digia.com> Message-ID: <2a15edbb740b46b69d66ae7c45b0fe32@DB3PR02MB0569.eurprd02.prod.outlook.com> Updated packages here (no changes to Qt content): Windows: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-12_151 Linux: Linux: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-12_143 Mac: http://master.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-12_120/ Src: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014-09-12_src/ (mirroring ongoing) Br, Jani >>-----Original Message----- >>From: Heikkinen Jani >>Sent: 12. syyskuuta 2014 7:47 >>To: Loehning Robert; development at qt-project.org >>Subject: RE: [Development] Qt5.3.2 final candidate packages available >> >>Arg, we will repackage the packages but no updates to qt content >> >>Br, >>Jani >> >>>>-----Original Message----- >>>>From: Loehning Robert >>>>Sent: 11. syyskuuta 2014 19:11 >>>>To: development at qt-project.org; Heikkinen Jani >>>>Subject: Re: [Development] Qt5.3.2 final candidate packages available >>>> >>>>https://bugreports.qt-project.org/browse/QTBUG-41261 >>>> >>>>Am 11.09.2014 um 18:10 schrieb Robert Löhning: >>>>> Hi Jani, >>>>> >>>>> the Installer for Linux claims to contain Qt Creator 3.2.0 (wrong) but >>>>> it installs Qt Creator 3.2.1 (right). Might this be a showstopper? >>>>> >>>>> Best Regards, >>>>> Robert >>>>> >>>>> >>>>> Am 11.09.2014 um 16:38 schrieb Heikkinen Jani: >>>>>> Hi all, >>>>>> >>>>>> Qt 5.3.2 final candidate packages are available here: >>>>>> >>>>>> Windows: http://download.qt- >>>>project.org/snapshots/qt/5.3/5.3.2/2014-09-11_150 >>>>>> Linux: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014- >>09- >>>>11_141 >>>>>> Mac: http://download.qt-project.org/snapshots/qt/5.3/5.3.2/2014- >>09- >>>>11_119 >>>>>> >>>>>> Mirroring is ongoing and first packages are already there. Rest ones >>>>should be available within next few hours. >>>>>> >>>>>> We are targeting to release Qt5.3.2 (these packages) Tue 16th Sep if >>>>nothing serious found during testing. >>>>>> Please take a tour & check that everything is still working as expected >>>>and report your effort via http://testresults.qt- >>project.org/forms/release- >>>>testing/index.pl >>>>>> >>>>>> Br, >>>>>> Jani >>>>>> _______________________________________________ >>>>>> 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 Akseli.Salovaara at digia.com Fri Sep 12 14:55:48 2014 From: Akseli.Salovaara at digia.com (Salovaara Akseli) Date: Fri, 12 Sep 2014 12:55:48 +0000 Subject: [Development] Nominating Antti Kokko and Heikki Halmet as approvers Message-ID: <8EE30B3F13F8C042BFFAD90938B94A6F4DC03D0A@IT-EXMB02-HKI.it.local> Hi, I'd like to nominate Antti Kokko and Heikki Halmet for approver status. They both are essential part of Qt release & CI teams and although only some of their contributions are visible in Gerrit Antti Kokko https://codereview.qt-project.org/#/q/owner:ankokko,n,z https://codereview.qt-project.org/#/q/reviewer:ankokko,n,z Heikki Halmet https://codereview.qt-project.org/#/q/owner:hehalmet,n,z https://codereview.qt-project.org/#/q/reviewer:hehalmet,n,z they are highly important to the project. They both know Qt Project process well and them being Approvers will also make it easier to get releases out in the future. Br, Akseli -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Sat Sep 13 20:59:22 2014 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 13 Sep 2014 22:59:22 +0400 Subject: [Development] [FYI] if you find diffing in gerrit slow ... In-Reply-To: <20140911145956.GA7724@troll08.it.local> References: <20140911145956.GA7724@troll08.it.local> Message-ID: <5053931410634762@web1o.yandex.ru> 11.09.2014, 19:00, "Oswald Buddenhagen" : > ... then use chrome/chromium. > because the slowness is coming from gerrit running massive amounts of js > in your browser, and chrome is literally an order of magnitude faster at > it than firefox (no clue about ie). > if you already use it, well, tough luck. get a cryo-cooled cpu, or > something. > if you hate it (like i do), tough luck, too - it won't get better until > we upgrade to gerrit 2.11 (presumably), which is more than half a year > in the future. Well, one can just turn off syntax highlighting to get rid of this issue. -- Regards, Konstantin From charleyb123 at gmail.com Sun Sep 14 18:43:07 2014 From: charleyb123 at gmail.com (charleyb123 .) Date: Sun, 14 Sep 2014 10:43:07 -0600 Subject: [Development] CppCon Just Ended (next year will be 20-25 Sep 2015) Message-ID: Just got back from CppCon (http://cppcon.org/), WOW what a great conference for C++. Apologies for cross-post qt-interest and qt-dev, but wanted to be sure both groups saw the announcement for next year (20-25 Sep-2015). WOW AGAIN for a great conference. Really heavy-hitters there, with information I don't know is available elsewhere. For example: *- Google C++ code base is 100 million lines, is managed as a single code base serving many projects, and they don't use exceptions in it anywhere. Techniques on managing code base are impressive. *- Similarly (from other presentations) lots of code bases don't/can't use exceptions, and this is not a, "solved problem" (especially for the game industry) *- Facebook (Andrei Alexandrescu) "cheats" with "stealing bits" from their implementation of a "shared-pointer" to "steal-bits" for the "object-count", with the understanding that the count rarely goes above "4". Correctness is sacrificed to increase performance 0.4%, which is a "huge win" for server load and electricity (saves $millions a month). "Leak, Log, and Leave" is what they do for the uncommon correctness failure-case. *- Empty constructors and empty destructors when "inlined" are not "free", and in large code bases can have significant cost. Optimizations are not intutive, and must be measured. (Facebook) *- Microsoft compiler team, library team, STL team was represented. Really fantastic talks, and these guys are smart. If you had any concerns about the toolchain, they are absolutely going in a clear and strong direction. (My biased recommendation for us is to move off our reference compiler of MSVC2008 to MSVC2013, and then move asap to the next compiler (probably released early next year) to make it our "reference-compiler" for an extended period of time (I am not concerned about "early adoption" on this next compiler, and I _do_ want the new language features). *- Lots of Clang goodness -- have a look at Clang Format and Clang MemorySanitizer. *- Great talks by Intel on concurrency/parallelism, interfacing with hardware, etc. Other HW vendors there too like IBM, panel discussions on issues, etc. It's increasingly obvious that C++ developers need to have greater understanding of hardware architectures to create well-engineered designs that take advantage of all the cores and caches. *- Tremendous consistency in low-level talks on coding to consider the instruction-cache, L1 and L2 caches, other memory issues related to performance. General/common knowledge: Let your data structures take advantage of understanding that fitting inside 64-byte units is a Big Win for cache optimization, consider data layout for word-alignment, and consider allowing array-processing of raw contiguous data. Also, using "std::vector<>" will never get you in trouble, many other "std::container<>" things can often get you in trouble. *- Game industry had strong presence, including a keynote by Mike Acton (InsomniacGames) on, "Data Oriented Design". GREAT example of engineering in the face of hardware constraints, seemed similar to an approach of "OO-using-C" (but using C++), talked about failed C++ design approaches for games. REALLY made a lot of the audience uncomfortable (you've got to watch the video when it posts -- it will become a classic, was really a "punch in the gut" for some people), but I thought it was one of the highlights of the week (there were so many), and he wasn't wrong. *- Some wickedly serious template metaprogramming techniques, including new ones now possible through C++14, including expressing previous meta-programming approaches with much greater elegance/readability and less work. IMHO there is a strong place for this, especially inside libraries. *- It is estimated 3-4M C++ developers exist in the world (Google has 4K C++ developers). Tech book sales were down 3% over the past year, but C++ book sales were up 4% (C++ is growing in adoption). *- C++ language standard is maturing in a non-trivial and deliberate way through the Standard C++ Foundation (http://isocpp.org/) , especially for more parallel/concurrent, and more intimate interface with hardware. It really is driven by the community -- you write a paper (proposal) so they can review it, and it may eventually get codified into the language or standard library. They are always looking for people to review or write papers, or work in any of the working groups. Anyone can attend, members can vote. Especially when compared with what other programming languages do for their standardization and evolution, the Standard C++ Foundation IMHO really represents a great place for the community to substantively address real-world issues (it is a tremendous asset to our community). This is just a subset, because I could not attend all talks. All talks were professionally recorded, and will be posted online (for free). Watch them. CLOSING REMARKS This was a "first-year" conference, and it was a huge success (about 600 people, it exceeded their goals). There is a strong possibility that it will double in size for next year, and they have a venue that can handle that. It was tough to get your talk accepted -- so many submissions, I'd guess the acceptance was 1:3 or 1:4 (not sure). There were many very high quality submissions that were rejected merely because the tracks were full. Qt was not really represented. That is understandable because there was SO MUCH other C++ there, and these dates were "in-conflict" with QtDevDays and KDE/Akademy, but I really think we need to, "come out in force" next year. We are a C++ library and framework, solving real problems in novel ways that will benefit this audience. That's not to say, of course, that attendees were unfamiliar with Qt. They know Qt, many of them ship Qt. We just didn't talk about Qt. I guess in that respect it was like "Fight Club". LAST STATEMENT Even though it was a, "first-year" conference, it is interesting to note that a "culture" is clearly starting to form. It was incredibly open, and collegiate, and supportive across the different industries and companies -- for newcomers and for experienced people (although it is most definitely a place where experienced people can finally discuss their advanced issues when they have nobody else at their company to help). These were incredibly smart people merely coming together to talk about problems and solutions and experiences in using and growing C++. I'm going back again next year (assuming their restraining order against me has expired by then). --charley -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at digia.com Mon Sep 15 08:46:07 2014 From: mitch.curtis at digia.com (Mitch Curtis) Date: Mon, 15 Sep 2014 08:46:07 +0200 Subject: [Development] Nominating Antti Kokko and Heikki Halmet as approvers In-Reply-To: <8EE30B3F13F8C042BFFAD90938B94A6F4DC03D0A@IT-EXMB02-HKI.it.local> References: <8EE30B3F13F8C042BFFAD90938B94A6F4DC03D0A@IT-EXMB02-HKI.it.local> Message-ID: <54168B2F.2010501@digia.com> On 12/09/14 14:55, Salovaara Akseli wrote: > > Hi, > > I’d like to nominate Antti Kokko and Heikki Halmet for approver status. > > They both are essential part of Qt release & CI teams and although > only some of their contributions are visible in Gerrit > > Antti Kokko > > https://codereview.qt-project.org/#/q/owner:ankokko,n,z > > https://codereview.qt-project.org/#/q/reviewer:ankokko,n,z > > Heikki Halmet > > https://codereview.qt-project.org/#/q/owner:hehalmet,n,z > > https://codereview.qt-project.org/#/q/reviewer:hehalmet,n,z > > they are highly important to the project. They both know Qt Project > process well and them being Approvers will also make it easier to get > releases out in the future. > > Br, > > Akseli > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at digia.com Mon Sep 15 16:28:48 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Mon, 15 Sep 2014 14:28:48 +0000 Subject: [Development] Nominating Antti Kokko and Heikki Halmet as approvers In-Reply-To: <54168B2F.2010501@digia.com> References: <8EE30B3F13F8C042BFFAD90938B94A6F4DC03D0A@IT-EXMB02-HKI.it.local> <54168B2F.2010501@digia.com> Message-ID: And another +1 from me. Cheers, Lars On 15/09/14 08:46, "Mitch Curtis" wrote: > >On 12/09/14 14:55, Salovaara Akseli wrote: > > >Hi, > >I’d like to nominate Antti Kokko and Heikki Halmet for approver status. > >They both are essential part of Qt release & CI teams and although only >some of their contributions are visible in Gerrit > >Antti Kokko >https://codereview.qt-project.org/#/q/owner:ankokko,n,z >https://codereview.qt-project.org/#/q/reviewer:ankokko,n,z > >Heikki Halmet >https://codereview.qt-project.org/#/q/owner:hehalmet,n,z >https://codereview.qt-project.org/#/q/reviewer:hehalmet,n,z > >they are highly important to the project. They both know Qt Project >process well and them being Approvers will also make it easier to get >releases out in the future. > >Br, >Akseli > > > > >_______________________________________________ >Development mailing list >Development at qt-project.orghttp://lists.qt-project.org/mailman/listinfo/dev >elopment > > >+1 From Heikki.Halmet at digia.com Tue Sep 16 08:44:41 2014 From: Heikki.Halmet at digia.com (Halmet Heikki) Date: Tue, 16 Sep 2014 06:44:41 +0000 Subject: [Development] RedHat GCC version Message-ID: Hi, I´m making new RedHat 6.5 template. Which GCC version we want to use in CI? Is it the latest one 4.9.1? Currently redhat repositories includes Devtoolset-3 which includes gcc 4.9.1. Br Heikki -------------- next part -------------- An HTML attachment was scrubbed... URL: From Topi.Reinio at digia.com Tue Sep 16 09:31:01 2014 From: Topi.Reinio at digia.com (Reinio Topi) Date: Tue, 16 Sep 2014 07:31:01 +0000 Subject: [Development] Nominating Venugopal Shivashankar and Nico Vertriest as approvers Message-ID: I'd like to nominate Venugopal Shivashankar and Nico Vertriest as approvers in the Qt Project. They are both documentation engineers and integral part of the of Qt documentation team. Venugopal Shivashankar: https://codereview.qt-project.org/#/q/owner:veshivas,n,z https://codereview.qt-project.org/#/q/reviewer:veshivas,n,z Nico Vertriest: https://codereview.qt-project.org/#/q/owner:vertries,n,z https://codereview.qt-project.org/#/q/reviewer:vertries,n,z Both Venu and Nico have been working on Qt for a long time (pre-Qt 5.0) already, contributing numerous improvements to Qt documentation. Many people rely on them for documentation and language reviews, and having them as approvers would speed up documentation work and ease the review-burden on other team members. -Topi -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.tvete at digia.com Tue Sep 16 10:34:02 2014 From: paul.tvete at digia.com (Paul Olav Tvete) Date: Tue, 16 Sep 2014 10:34:02 +0200 Subject: [Development] Nominating Venugopal Shivashankar and Nico Vertriest as approvers In-Reply-To: References: Message-ID: <1503351.b46Ts6slH5@dragaera> On Tuesday 16. September 2014 07.31.01 Reinio Topi wrote: > I'd like to nominate Venugopal Shivashankar and Nico Vertriest as approvers > in the Qt Project. +2 - Paul From Alexander.Blasche at digia.com Tue Sep 16 10:35:46 2014 From: Alexander.Blasche at digia.com (Blasche Alexander) Date: Tue, 16 Sep 2014 08:35:46 +0000 Subject: [Development] Jira bug cleanup Message-ID: Hi, One of the topics discussed during the last Qt contributor summit was the cleanup of our bug database. If you are interested in the outcomes check out: https://qt-project.org/groups/qt-contributors-summit-2014/wiki/Expiring_Bugs Finally I got some time to take care of the results. My plan is to perform these expiries on Friday this week. The first step will be the closure of all bugs (and only bugs) in the "Need more info" state which have not seen any activity for the last year. An appropriate comment will be added to each Jira bug explaining the action and advising people how to react to it depending on their circumstances. The second step is the transition of Unassigned bugs to the "Need more info" state if they have not seen any update during the last year. A comment will go along with the transition. You can avoid this happening to "your" important bugs by means of touching them. Also, feel free to revert some transitions as you may see fit in your work area. Going forward I will repeat this in regular intervals (3 months) and reduce the "no update received" timeout to six and later three month in the case of of tasks in the "Need more info" state. This should result in a eventual setup whereby Unassiged/reported bugs expire after 12 months and "Need more info" bugs expire after 3 months. If there are major objections to the proposed target for this week please raise them now. -- Alex From t.artikov at gmail.com Tue Sep 16 11:15:43 2014 From: t.artikov at gmail.com (=?UTF-8?B?0KLQuNC80YPRgCDQkNGA0YLQuNC60L7Qsg==?=) Date: Tue, 16 Sep 2014 16:15:43 +0700 Subject: [Development] Crash dump generation in QML application (on Windows). Message-ID: Hi, I'm trying to use crash dump generation in my QML application. To do that I set an exception handler(SetUnhandledExceptionFilter) at the application start up, and write a minidump file (MiniDumpWriteDump) in the exception handler. It works fine when a crash happens in main() function, but when a buggy function is called from QML the application just crashed without calling of my exception handler. Please see my test code: https://dl.dropboxusercontent.com/u/25159021/CrashReportTest.zip Any ideas how can I make it work? -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.hausmann at digia.com Tue Sep 16 11:48:40 2014 From: simon.hausmann at digia.com (Simon Hausmann) Date: Tue, 16 Sep 2014 11:48:40 +0200 Subject: [Development] RedHat GCC version In-Reply-To: References: Message-ID: <25222972.3IKNNJTlvB@rhea> On Tuesday 16. September 2014 06.44.41 Halmet Heikki wrote: > Hi, > > I´m making new RedHat 6.5 template. Which GCC version we want to use in CI? > Is it the latest one 4.9.1? Currently redhat repositories includes > Devtoolset-3 which includes gcc 4.9.1. A brief inquiry with commercial support suggests that there is a higher probability people using RHEL out of the box instead of customizing the compiler by installing packages on top. That makes me think we're probably better off building with the compiler that comes with the system, in order to build and test something that is closer to what people are using. Simon From longlongh4 at yahoo.com Mon Sep 15 18:35:05 2014 From: longlongh4 at yahoo.com (hailong geng) Date: Mon, 15 Sep 2014 09:35:05 -0700 Subject: [Development] Video element is broken with IOS Message-ID: <1410798905.27651.YahooMailNeo@web164903.mail.bf1.yahoo.com> As the attachment shows. I set a Video element filling the screen and start to play a video file. The yellow rectangle is in the center of the screen, the video surface is on the top-left of the screen instead of filling the screen. I think this is caused by wrong projection. I have downloaded the newest source code of multimedia, this bug still exists. May the author tell me, how can I fix it? Thank you very much : ) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: IMG_0002.PNG Type: image/png Size: 71570 bytes Desc: not available URL: From Lars.Knoll at digia.com Tue Sep 16 14:11:26 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Tue, 16 Sep 2014 12:11:26 +0000 Subject: [Development] New company name for Qt part of Digia and unified web site Message-ID: Hi everybody, I’m happy to tell you that we’re making significant progress towards the new unified web page that I’ve first been talking about at the contributor summit. We just launched the first stage of it on http://qt.io. For now qt.digia.com is going to redirect to it. I hope you will like the new web page. Please have a look and give us your feedback. In addition, we also now have a new company name for the Qt part of Digia. It’s simply ‘The Qt Company’. For more details check out my blog at http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-introduces-a-unifie d-website-and-20e25-monthly-indie-mobile-package/ and of course http://qt.io Moving forward, we would like to slowly move some more pieces that are now on qt-project.org over to qt.io. We don’t have concrete plans yet on when and what will move, but would probably want to start with simple things such as the documentation. Any feedback on this is of course also more than welcome. Cheers, Lars From christoph at maxiom.de Tue Sep 16 14:19:34 2014 From: christoph at maxiom.de (Christoph Feck) Date: Tue, 16 Sep 2014 14:19:34 +0200 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: References: Message-ID: <201409161419.34076.christoph@maxiom.de> On Tuesday 16 September 2014 14:11:26 Knoll Lars wrote: > In addition, we also now have a new company name for the Qt part of > Digia. It’s simply ‘The Qt Company’. How boring! But you can rename the company hundred times... For me, it will always be The Trolls™ ;) Christoph Feck (kdepepo) -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jani.Heikkinen at digia.com Tue Sep 16 14:29:55 2014 From: Jani.Heikkinen at digia.com (Heikkinen Jani) Date: Tue, 16 Sep 2014 12:29:55 +0000 Subject: [Development] Qt 5.3.2 & Qt Creator 3.2.1 released Message-ID: <0f1c72d1f1ea4ff094af88545de34eb4@DB3PR02MB0569.eurprd02.prod.outlook.com> Hi all, We are happy to announce that Qt 5.3.2 & Qt Creator 3.2.1 is released today, see http://blog.qt.digia.com/blog/2014/09/16/qt-5-3-2-released-with-qt-creator-3-2-1/ & http://blog.qt.digia.com/blog/2014/09/16/qt-creator-3-2-1-released/ Big thanks to everyone who have helped to make the releases happen! Br, Jani From thiago.macieira at intel.com Tue Sep 16 16:45:46 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 16 Sep 2014 07:45:46 -0700 Subject: [Development] Nominating Venugopal Shivashankar and Nico Vertriest as approvers In-Reply-To: <1503351.b46Ts6slH5@dragaera> References: <1503351.b46Ts6slH5@dragaera> Message-ID: <1488426.P3C858R1DL@tjmaciei-mobl4> On Tuesday 16 September 2014 10:34:02 Paul Olav Tvete wrote: > On Tuesday 16. September 2014 07.31.01 Reinio Topi wrote: > > I'd like to nominate Venugopal Shivashankar and Nico Vertriest as > > approvers > > in the Qt Project. > > +2 One for each? :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From markg85 at gmail.com Tue Sep 16 16:51:04 2014 From: markg85 at gmail.com (Mark Gaiser) Date: Tue, 16 Sep 2014 16:51:04 +0200 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: References: Message-ID: On Tue, Sep 16, 2014 at 2:11 PM, Knoll Lars wrote: > Hi everybody, > > I’m happy to tell you that we’re making significant progress towards the > new unified web page that I’ve first been talking about at the contributor > summit. We just launched the first stage of it on http://qt.io. For now > qt.digia.com is going to redirect to it. I hope you will like the new web > page. Please have a look and give us your feedback. > > In addition, we also now have a new company name for the Qt part of Digia. > It’s simply ‘The Qt Company’. > > For more details check out my blog at > http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-introduces-a-unifie > d-website-and-20e25-monthly-indie-mobile-package/ and of course > http://qt.io > > Moving forward, we would like to slowly move some more pieces that are now > on qt-project.org over to qt.io. We don’t have concrete plans yet on when > and what will move, but would probably want to start with simple things > such as the documentation. Any feedback on this is of course also more > than welcome. > > Cheers, > Lars > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development I like the site! It looks clear and to the point imho. But i kinda fail to see the point in having - yet another - domain for Qt. I mean, we've had: - Trolltech - qt.nokia... - qt.digia... - qt-project and now we have qt.io. Yes, it's a nice short domain, but having domain changes every few years or so isn't very good for the search results. From szehowe.koh at gmail.com Tue Sep 16 16:56:10 2014 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Tue, 16 Sep 2014 22:56:10 +0800 Subject: [Development] Nominating Venugopal Shivashankar and Nico Vertriest as approvers In-Reply-To: <1488426.P3C858R1DL@tjmaciei-mobl4> References: <1503351.b46Ts6slH5@dragaera> <1488426.P3C858R1DL@tjmaciei-mobl4> Message-ID: On 16 September 2014 22:45, Thiago Macieira wrote: > On Tuesday 16 September 2014 10:34:02 Paul Olav Tvete wrote: >> On Tuesday 16. September 2014 07.31.01 Reinio Topi wrote: >> > I'd like to nominate Venugopal Shivashankar and Nico Vertriest as >> > approvers >> > in the Qt Project. >> >> +2 > > One for each? :-) I've always assumed that they're already approvers! +1 +1 from me too Regards, Sze-Howe From thiago.macieira at intel.com Tue Sep 16 19:16:55 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 16 Sep 2014 10:16:55 -0700 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: References: Message-ID: <1659643.KunIK1mJNs@tjmaciei-mobl4> On Tuesday 16 September 2014 16:51:04 Mark Gaiser wrote: > But i kinda fail to see the point in having - yet another - domain for Qt. > I mean, we've had: > - Trolltech > - qt.nokia... > - qt.digia... > - qt-project > and now we have qt.io. Yes, it's a nice short domain, but having > domain changes every few years or so isn't very good for the search > results. qt-project.org will not disappear. Lars said that we'll move over slowly. Unlike previous times, we don't have to do an abrupt change, which is what hurts search results. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at digia.com Tue Sep 16 20:50:58 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Tue, 16 Sep 2014 18:50:58 +0000 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: References: Message-ID: On 16/09/14 16:51, "Mark Gaiser" wrote: >On Tue, Sep 16, 2014 at 2:11 PM, Knoll Lars wrote: >> Hi everybody, >> >> I’m happy to tell you that we’re making significant progress towards the >> new unified web page that I’ve first been talking about at the >>contributor >> summit. We just launched the first stage of it on http://qt.io. For now >> qt.digia.com is going to redirect to it. I hope you will like the new >>web >> page. Please have a look and give us your feedback. >> >> In addition, we also now have a new company name for the Qt part of >>Digia. >> It’s simply ‘The Qt Company’. >> >> For more details check out my blog at >> >>http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-introduces-a-unif >>ie >> d-website-and-20e25-monthly-indie-mobile-package/ and of course >> http://qt.io >> >> Moving forward, we would like to slowly move some more pieces that are >>now >> on qt-project.org over to qt.io. We don’t have concrete plans yet on >>when >> and what will move, but would probably want to start with simple things >> such as the documentation. Any feedback on this is of course also more >> than welcome. >> >> Cheers, >> Lars >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > >I like the site! It looks clear and to the point imho. > >But i kinda fail to see the point in having - yet another - domain for Qt. >I mean, we've had: >- Trolltech >- qt.nokia... >- qt.digia... >- qt-project >and now we have qt.io. Yes, it's a nice short domain, but having >domain changes every few years or so isn't very good for the search >results. I can assure you that worse search results is the last thing we want to get. We can do all changes incrementally, and ensure that search engines can follow. What hurt us most in the past was that similar content was distributed over several sites (like the Qt docs that were still on nokia.com for a long time). Worse, we couldn't do anything about the content on some of the other sites. Our goal here is to make sure we get to one authoritative place where you can find all relevant information. We can then add relevant redirects and other hints to make sure search engines will be able to follow nicely. Cheers, Lars From andre at familiesomers.nl Tue Sep 16 22:02:47 2014 From: andre at familiesomers.nl (Andre Somers) Date: Tue, 16 Sep 2014 22:02:47 +0200 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: References: Message-ID: <54189767.2000603@familiesomers.nl> On 16-9-2014 20:50, Knoll Lars wrote: > On 16/09/14 16:51, "Mark Gaiser" wrote: > >> On Tue, Sep 16, 2014 at 2:11 PM, Knoll Lars wrote: >>> Hi everybody, >>> >>> I’m happy to tell you that we’re making significant progress towards the >>> new unified web page that I’ve first been talking about at the >>> contributor >>> summit. We just launched the first stage of it on http://qt.io. For now >>> qt.digia.com is going to redirect to it. I hope you will like the new >>> web >>> page. Please have a look and give us your feedback. >>> >>> In addition, we also now have a new company name for the Qt part of >>> Digia. >>> It’s simply ‘The Qt Company’. >>> >>> For more details check out my blog at >>> >>> http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-introduces-a-unif >>> ie >>> d-website-and-20e25-monthly-indie-mobile-package/ and of course >>> http://qt.io >>> >>> Moving forward, we would like to slowly move some more pieces that are >>> now >>> on qt-project.org over to qt.io. We don’t have concrete plans yet on >>> when >>> and what will move, but would probably want to start with simple things >>> such as the documentation. Any feedback on this is of course also more >>> than welcome. >>> >>> Cheers, >>> Lars >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> I like the site! It looks clear and to the point imho. >> >> But i kinda fail to see the point in having - yet another - domain for Qt. >> I mean, we've had: >> - Trolltech >> - qt.nokia... >> - qt.digia... >> - qt-project >> and now we have qt.io. Yes, it's a nice short domain, but having >> domain changes every few years or so isn't very good for the search >> results. > I can assure you that worse search results is the last thing we want to > get. We can do all changes incrementally, and ensure that search engines > can follow. > > What hurt us most in the past was that similar content was distributed > over several sites (like the Qt docs that were still on nokia.com for a > long time). Worse, we couldn't do anything about the content on some of > the other sites. > > Our goal here is to make sure we get to one authoritative place where you > can find all relevant information. We can then add relevant redirects and > other hints to make sure search engines will be able to follow nicely. > What was wrong with qt-project in that respect? And what is the status of that site (and project) now then? It sounds a bit like the xkcd standards comic [1]: adding a new domain to unite all the information from the existing ones... André [1] http://xkcd.com/927/ From marc.mutz at kdab.com Tue Sep 16 22:10:47 2014 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 16 Sep 2014 22:10:47 +0200 Subject: [Development] RedHat GCC version In-Reply-To: References: Message-ID: <201409162210.47842.marc.mutz@kdab.com> On Tuesday 16 September 2014 08:44:41 Halmet Heikki wrote: > Hi, > > I´m making new RedHat 6.5 template. Which GCC version we want to use in CI? > Is it the latest one 4.9.1? Currently redhat repositories includes > Devtoolset-3 which includes gcc 4.9.1. https://codereview.qt-project.org/95038 https://bugs.freedesktop.org/show_bug.cgi?id=46147 The dbus headers are too old. They're not C++11-compatible. I used to patch them locally, but the patch is long since upstreamed. It's the usual string- literal adjacent to MACRO without intervening whitespace issue that we had to fix all over Qt, too. Thanks, Marc -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Marc Mutz | Senior 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 samuel.gaist at edeltech.ch Tue Sep 16 23:00:06 2014 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Tue, 16 Sep 2014 23:00:06 +0200 Subject: [Development] moc 4.8.6 & macros In-Reply-To: <2491015.1v2Rk5ZfCg@finn> References: <569B2BFA-D09B-4380-8ED4-D115714A6A83@edeltech.ch> <1567149.n7snu8CGW5@tjmaciei-mobl4> <2491015.1v2Rk5ZfCg@finn> Message-ID: On 12 sept. 2014, at 11:14, Olivier Goffart wrote: > On Thursday 11 September 2014 22:03:03 Samuel Gaist wrote: >> On 11 sept. 2014, at 21:49, Thiago Macieira > wrote: >>> On Thursday 11 September 2014 21:44:15 Samuel Gaist wrote: >>>> What would be the correct procedure to handle QT_DEPRECATED_SINCE ? >>>> Removing it from around the signal declaration would make the code a bit >>>> inconsistent. >>>> >>>> By the way, how is it handled in Qt 5 since building goes without any >>>> problem even with the macros around the signal ? >>> >>> moc is smarter in Qt 5: it expands macros. >>> >>> But the recommendation stands: do not #if (of any kind) anything that >>> isn't >>> #defined in the same source, in a header next to the one being compiled, >>> or >>> passed as -D in the command-line. >>> >>> That means: don't hide signals and slots with #if, even for deprecation. >> >> I thought I've read somewhere that moc got better at this job :-) > > I would not be as strict as Thiago. > In Qt5 it's fine to use the preprocessor as long as moc can see the defines > (that is, if they don't rely on compiler built-in or need special include > paths.) > QT_DEPRECATED_SINCE should be fine. > > It is strange it does not work with Qt4. Are you sure that all the include > paths are passed to moc? Good question, I'll have to check. If that where not the case, what should I write to give additional include paths to moc ? > Otherwise, you will have to work around it somehow. > try #if not QT_DEPRECATED_SINCE() #else > Or some other trick with Q_MOC_RUN I forgot about that one, might be a starting point > > You can also use the QT_MOC_COMPAT macro in front of a declaration so QObject > will throw a runtime warning when connecting to this signal. (in debug mode) Good to know > >> It seems that the new moc doesn't use much of the Qt 5 only classes, would >> it be useful to backport it to Qt 4 to avoid having to "break" the code >> style for modules supporting both series ? > > This is out of question. > This is a behaviour change as Qt4 code relied on moc not expending the macro > in some cases. > > (At some point it will be time to switch fully to Qt5 and drop Qt4 support) I agree, but there are still lots of people locked to Qt 4… There's even posts on the forum asking for Qt 3 From mandeepsandhu.chd at gmail.com Tue Sep 16 23:09:52 2014 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Tue, 16 Sep 2014 14:09:52 -0700 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <54189767.2000603@familiesomers.nl> References: <54189767.2000603@familiesomers.nl> Message-ID: > What was wrong with qt-project in that respect? And what is the status > of that site (and project) now then? > > It sounds a bit like the xkcd standards comic [1]: adding a new domain > to unite all the information from the existing ones... Lol. The elusive one-ring-to-rule-em-all! That xkcd is spot on here. -mandeep > > André > > [1] http://xkcd.com/927/ > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From ritt.ks at gmail.com Wed Sep 17 00:41:03 2014 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Wed, 17 Sep 2014 02:41:03 +0400 Subject: [Development] Jira bug cleanup In-Reply-To: References: Message-ID: Hi, How about task assigned to wrong persons (i.e. inactive people, people who are not a Nokia/Digia employee anymore, etc.)? Do we still have such ones? Regards, Konstantin 2014-09-16 12:35 GMT+04:00 Blasche Alexander : > Hi, > > One of the topics discussed during the last Qt contributor summit was the > cleanup of our bug database. If you are interested in the outcomes check > out: > > > https://qt-project.org/groups/qt-contributors-summit-2014/wiki/Expiring_Bugs > > Finally I got some time to take care of the results. My plan is to perform > these expiries on Friday this week. > > The first step will be the closure of all bugs (and only bugs) in the > "Need more info" state which have not seen any activity for the last year. > An appropriate comment will be added to each Jira bug explaining the action > and advising people how to react to it depending on their circumstances. > > The second step is the transition of Unassigned bugs to the "Need more > info" state if they have not seen any update during the last year. A > comment will go along with the transition. > > You can avoid this happening to "your" important bugs by means of touching > them. Also, feel free to revert some transitions as you may see fit in your > work area. > > Going forward I will repeat this in regular intervals (3 months) and > reduce the "no update received" timeout to six and later three month in the > case of of tasks in the "Need more info" state. This should result in a > eventual setup whereby Unassiged/reported bugs expire after 12 months and > "Need more info" bugs expire after 3 months. > > If there are major objections to the proposed target for this week please > raise them now. > -- > Alex > _______________________________________________ > 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 Heikki.Halmet at digia.com Wed Sep 17 07:47:28 2014 From: Heikki.Halmet at digia.com (Halmet Heikki) Date: Wed, 17 Sep 2014 05:47:28 +0000 Subject: [Development] RedHat GCC version In-Reply-To: <201409162210.47842.marc.mutz@kdab.com> References: <201409162210.47842.marc.mutz@kdab.com> Message-ID: <38734983880a48f1a5d0870b86055219@AM3PR02MB114.eurprd02.prod.outlook.com> Gcc is reverted to 4.4.7 for now. When we know which version we want to use we can update the dbus to newer version which is C++11-compatible. -Heikki -----Original Message----- From: marc at smtp1.digia.com [mailto:marc at smtp1.digia.com] On Behalf Of Marc Mutz Sent: 16. syyskuuta 2014 23:11 To: development at qt-project.org Cc: Halmet Heikki Subject: Re: [Development] RedHat GCC version On Tuesday 16 September 2014 08:44:41 Halmet Heikki wrote: > Hi, > > I´m making new RedHat 6.5 template. Which GCC version we want to use in CI? > Is it the latest one 4.9.1? Currently redhat repositories includes > Devtoolset-3 which includes gcc 4.9.1. https://codereview.qt-project.org/95038 https://bugs.freedesktop.org/show_bug.cgi?id=46147 The dbus headers are too old. They're not C++11-compatible. I used to patch them locally, but the patch is long since upstreamed. It's the usual string- literal adjacent to MACRO without intervening whitespace issue that we had to fix all over Qt, too. Thanks, Marc -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Marc Mutz | Senior 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 mitch.curtis at digia.com Wed Sep 17 08:29:59 2014 From: mitch.curtis at digia.com (Mitch Curtis) Date: Wed, 17 Sep 2014 08:29:59 +0200 Subject: [Development] Nominating Venugopal Shivashankar and Nico Vertriest as approvers In-Reply-To: References: Message-ID: <54192A67.7080205@digia.com> On 16/09/14 09:31, Reinio Topi wrote: > > I'd like to nominate Venugopal Shivashankar and Nico Vertriest as > approvers in > > the Qt Project. They are both documentation engineers and integral part of > > the of Qt documentation team. > > Venugopal Shivashankar: > > https://codereview.qt-project.org/#/q/owner:veshivas,n,z > > https://codereview.qt-project.org/#/q/reviewer:veshivas,n,z > > Nico Vertriest: > > https://codereview.qt-project.org/#/q/owner:vertries,n,z > > https://codereview.qt-project.org/#/q/reviewer:vertries,n,z > > Both Venu and Nico have been working on Qt for a long time (pre-Qt 5.0) > > already, contributing numerous improvements to Qt documentation. Many > people > > rely on them for documentation and language reviews, and having them as > > approvers would speed up documentation work and ease the review-burden on > > other team members. > > -Topi > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development +1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Sep 17 08:49:53 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 16 Sep 2014 23:49:53 -0700 Subject: [Development] RedHat GCC version In-Reply-To: <38734983880a48f1a5d0870b86055219@AM3PR02MB114.eurprd02.prod.outlook.com> References: <201409162210.47842.marc.mutz@kdab.com> <38734983880a48f1a5d0870b86055219@AM3PR02MB114.eurprd02.prod.outlook.com> Message-ID: <2248440.Ezkrb0DOhf@tjmaciei-mobl4> On Wednesday 17 September 2014 05:47:28 Halmet Heikki wrote: > Gcc is reverted to 4.4.7 for now. When we know which version we want to use > we can update the dbus to newer version which is C++11-compatible. D-Bus released two versions today: one in the 1.6 line and one in the 1.8 line. Get one of those. Anything else is now known to have security issues. Stop using them and upgrade to the latest. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Alexander.Blasche at digia.com Wed Sep 17 08:48:20 2014 From: Alexander.Blasche at digia.com (Blasche Alexander) Date: Wed, 17 Sep 2014 06:48:20 +0000 Subject: [Development] Jira bug cleanup In-Reply-To: References: Message-ID: > -----Original Message----- > From: Konstantin Ritt [mailto:ritt.ks at gmail.com] > Sent: Wednesday, 17 September 2014 0:41 > To: Blasche Alexander > Cc: interest at qt-project.org; development at qt-project.org > Subject: Re: [Development] Jira bug cleanup > > Hi, > > How about task assigned to wrong persons (i.e. inactive people, people who are > not a Nokia/Digia employee anymore, etc.)? Do we still have such ones? That's certainly a worthy goal but not in scope for this week. There is no way to actually filter by inactive assignees. I am only aware of the "inactive" flag in the user management interface and when trying to assign something to inactive users. I'll happily agree if somebody proves me otherwise. In any case because you cannot filter tasks by this flag such changes would have to be done on an individual base only. Therefore this is more like a long term task which I might pursue every now and then. -- Alex From thiago.macieira at intel.com Wed Sep 17 08:52:36 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 16 Sep 2014 23:52:36 -0700 Subject: [Development] moc 4.8.6 & macros In-Reply-To: References: <569B2BFA-D09B-4380-8ED4-D115714A6A83@edeltech.ch> <2491015.1v2Rk5ZfCg@finn> Message-ID: <4127272.dkxdXlvcy3@tjmaciei-mobl4> On Tuesday 16 September 2014 23:00:06 Samuel Gaist wrote: > Good question, I'll have to check. > If that where not the case, what should I write to give additional include > paths to moc ? Replace QT_DEPRECATED_SINCE with the actual contents of the macro. Also expand QT_VERSION_CHECK. Qt 4 moc does not expand macros. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From haithem.rahmani at gmail.com Wed Sep 17 08:53:26 2014 From: haithem.rahmani at gmail.com (haithem rahmani) Date: Wed, 17 Sep 2014 07:53:26 +0100 Subject: [Development] QtWebEngine is building all needed libs from sources. Message-ID: Hi, In the Qt-5.4.0-alpha release I noticed that QtWebEngine, is building all reuqired libs tools from sources even if those tools and libs are provided by the host. Won't this cause any issue with Qt being built with 'system' libs for example, freetype, sqlite, png, jpeg? Is there anyway to force QtWebEngine to use system libs? regards Haithem. -- *Never say that's "impossible", the word itself says "I'm Possible"* -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Wed Sep 17 08:55:18 2014 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 17 Sep 2014 08:55:18 +0200 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: References: Message-ID: <1449578.RE8A8tzjc1@finn> On Tuesday 16 September 2014 16:51:04 Mark Gaiser wrote: > I like the site! It looks clear and to the point imho. > > But i kinda fail to see the point in having - yet another - domain for Qt. > I mean, we've had: > - Trolltech > - qt.nokia... > - qt.digia... > - qt-project > and now we have qt.io. Yes, it's a nice short domain, but having > domain changes every few years or so isn't very good for the search > results. You forgot qtsoftware.com (for one year in 2008-2009) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From joerg.bornemann at digia.com Wed Sep 17 11:05:58 2014 From: joerg.bornemann at digia.com (Joerg Bornemann) Date: Wed, 17 Sep 2014 11:05:58 +0200 Subject: [Development] Requesting removal of qtjsondb Message-ID: <54194EF6.4080608@digia.com> The qtjsondb module is dead. It doesn't build since ages and has zero users. As civilized people we should bury our dead. Therefore I'd like to request the removal of qtjsondb from Qt's mother repository. Please raise any objections here or on codereview: https://codereview.qt-project.org/#/c/95086/ BR, Joerg From markg85 at gmail.com Wed Sep 17 11:13:41 2014 From: markg85 at gmail.com (Mark Gaiser) Date: Wed, 17 Sep 2014 11:13:41 +0200 Subject: [Development] Requesting removal of qtjsondb In-Reply-To: <54194EF6.4080608@digia.com> References: <54194EF6.4080608@digia.com> Message-ID: On Wed, Sep 17, 2014 at 11:05 AM, Joerg Bornemann wrote: > The qtjsondb module is dead. It doesn't build since ages and has zero > users. As civilized people we should bury our dead. > Therefore I'd like to request the removal of qtjsondb from Qt's mother > repository. > > Please raise any objections here or on codereview: > https://codereview.qt-project.org/#/c/95086/ It was one of the modules i was looking forward to while Qt 5.0 was in development. It seemed to be quite promising at the time. From joerg.bornemann at digia.com Wed Sep 17 11:18:18 2014 From: joerg.bornemann at digia.com (Joerg Bornemann) Date: Wed, 17 Sep 2014 11:18:18 +0200 Subject: [Development] Requesting removal of qtjsondb In-Reply-To: References: <54194EF6.4080608@digia.com> Message-ID: <541951DA.6010005@digia.com> On 17-Sep-14 11:13, Mark Gaiser wrote: > It was one of the modules i was looking forward to while Qt 5.0 was in > development. It seemed to be quite promising at the time. The alternative to removal is fixing. Are you stepping up? :) BR, Joerg From markg85 at gmail.com Wed Sep 17 11:21:08 2014 From: markg85 at gmail.com (Mark Gaiser) Date: Wed, 17 Sep 2014 11:21:08 +0200 Subject: [Development] Requesting removal of qtjsondb In-Reply-To: <541951DA.6010005@digia.com> References: <54194EF6.4080608@digia.com> <541951DA.6010005@digia.com> Message-ID: On Wed, Sep 17, 2014 at 11:18 AM, Joerg Bornemann wrote: > On 17-Sep-14 11:13, Mark Gaiser wrote: > >> It was one of the modules i was looking forward to while Qt 5.0 was in >> development. It seemed to be quite promising at the time. > > > The alternative to removal is fixing. Are you stepping up? :) No :) I don't even know if i would use it. It just "seemed" promising. From sbaiduzh at redhat.com Wed Sep 17 12:07:06 2014 From: sbaiduzh at redhat.com (Stanislav Baiduzhyi) Date: Wed, 17 Sep 2014 12:07:06 +0200 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <1449578.RE8A8tzjc1@finn> References: <1449578.RE8A8tzjc1@finn> Message-ID: <2292011.HlXZZsExRH@sbaiduzh-main.redhat> On Wednesday 17 September 2014 08:55:18 Olivier Goffart wrote: > On Tuesday 16 September 2014 16:51:04 Mark Gaiser wrote: > > I like the site! It looks clear and to the point imho. > > > > But i kinda fail to see the point in having - yet another - domain for Qt. > > I mean, we've had: > > - Trolltech > > - qt.nokia... > > - qt.digia... > > - qt-project > > and now we have qt.io. Yes, it's a nice short domain, but having > > domain changes every few years or so isn't very good for the search > > results. > > You forgot qtsoftware.com (for one year in 2008-2009) Right now I have the impression that qt-project.org is website for developers, while qt.io looks more like business card website. And I think keeping them separated like this is a good idea. But I don't know if that's intentional difference between those two or not. -- Regards, Stas From milian.wolff at kdab.com Wed Sep 17 12:38:20 2014 From: milian.wolff at kdab.com (Milian Wolff) Date: Wed, 17 Sep 2014 12:38:20 +0200 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: References: Message-ID: <3787917.uYe8fR1vhY@milian-kdab2> On Tuesday 16 September 2014 12:11:26 Knoll Lars wrote: > Hi everybody, > > I’m happy to tell you that we’re making significant progress towards the > new unified web page that I’ve first been talking about at the contributor > summit. We just launched the first stage of it on http://qt.io. For now > qt.digia.com is going to redirect to it. I hope you will like the new web > page. Please have a look and give us your feedback. > > In addition, we also now have a new company name for the Qt part of Digia. > It’s simply ‘The Qt Company’. > > For more details check out my blog at > http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-introduces-a-unifie > d-website-and-20e25-monthly-indie-mobile-package/ and of course > http://qt.io Hey Lars, I have a question/request/remark: Currently, on http://www.qt.io/download/, it says that the "community" license of Qt does not give users the "full rights to modify source codes". What you probably mean by that, is that while the FOSS licenses allow you to modify it, you are also required to contribute back. Anyhow, I think this wording is highly confusing and *at least* a popup with explanatory text should added. Or better yet, also add the green tickmark and mention that the contributions must be upstreamed. We all want contributions by FOSS users of Qt after all, no? Bye -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | milian.wolff 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 From andre at familiesomers.nl Wed Sep 17 13:29:50 2014 From: andre at familiesomers.nl (=?UTF-8?B?QW5kcsOpIFNvbWVycw==?=) Date: Wed, 17 Sep 2014 13:29:50 +0200 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <3787917.uYe8fR1vhY@milian-kdab2> References: <3787917.uYe8fR1vhY@milian-kdab2> Message-ID: <541970AE.6050903@familiesomers.nl> Milian Wolff schreef op 17-9-2014 12:38: > On Tuesday 16 September 2014 12:11:26 Knoll Lars wrote: >> Hi everybody, >> >> I’m happy to tell you that we’re making significant progress towards the >> new unified web page that I’ve first been talking about at the contributor >> summit. We just launched the first stage of it on http://qt.io. For now >> qt.digia.com is going to redirect to it. I hope you will like the new web >> page. Please have a look and give us your feedback. >> >> In addition, we also now have a new company name for the Qt part of Digia. >> It’s simply ‘The Qt Company’. >> >> For more details check out my blog at >> http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-introduces-a-unifie >> d-website-and-20e25-monthly-indie-mobile-package/ and of course >> http://qt.io > Hey Lars, > > I have a question/request/remark: Currently, on http://www.qt.io/download/, it > says that the "community" license of Qt does not give users the "full rights > to modify source codes". What you probably mean by that, is that while the > FOSS licenses allow you to modify it, you are also required to contribute > back. Anyhow, I think this wording is highly confusing and *at least* a popup > with explanatory text should added. Or better yet, also add the green tickmark > and mention that the contributions must be upstreamed. > > We all want contributions by FOSS users of Qt after all, no? > > Bye > That's also nonsense. The changes must be made public to those you have given a license to use your software, but that is not the same as having to upstream your changes back into the project directly. Sure, that would be the ideal model, but it is not always possible and, more to the point, is not what the license says. André From milian.wolff at kdab.com Wed Sep 17 13:46:50 2014 From: milian.wolff at kdab.com (Milian Wolff) Date: Wed, 17 Sep 2014 13:46:50 +0200 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <541970AE.6050903@familiesomers.nl> References: <3787917.uYe8fR1vhY@milian-kdab2> <541970AE.6050903@familiesomers.nl> Message-ID: <1585225.OTQJqPCDjK@milian-kdab2> On Wednesday 17 September 2014 13:29:50 André Somers wrote: > Milian Wolff schreef op 17-9-2014 12:38: > > On Tuesday 16 September 2014 12:11:26 Knoll Lars wrote: > >> Hi everybody, > >> > >> I’m happy to tell you that we’re making significant progress towards the > >> new unified web page that I’ve first been talking about at the > >> contributor > >> summit. We just launched the first stage of it on http://qt.io. For now > >> qt.digia.com is going to redirect to it. I hope you will like the new web > >> page. Please have a look and give us your feedback. > >> > >> In addition, we also now have a new company name for the Qt part of > >> Digia. > >> It’s simply ‘The Qt Company’. > >> > >> For more details check out my blog at > >> http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-introduces-a-unif > >> ie > >> d-website-and-20e25-monthly-indie-mobile-package/ and of course > >> http://qt.io > > > > Hey Lars, > > > > I have a question/request/remark: Currently, on > > http://www.qt.io/download/, it says that the "community" license of Qt > > does not give users the "full rights to modify source codes". What you > > probably mean by that, is that while the FOSS licenses allow you to > > modify it, you are also required to contribute back. Anyhow, I think this > > wording is highly confusing and *at least* a popup with explanatory text > > should added. Or better yet, also add the green tickmark and mention that > > the contributions must be upstreamed. > > > > We all want contributions by FOSS users of Qt after all, no? > > > > Bye > > That's also nonsense. The changes must be made public to those you have > given a license to use your software, but that is not the same as having > to upstream your changes back into the project directly. Sure, that > would be the ideal model, but it is not always possible and, more to the > point, is not what the license says. True. But do we agree that saying FOSS users don't have the "full rights to modify source codes" is wrong, or at least misleading? I guess so, considering you say "That's *also* nonsense" (emphasis mine). Bye -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | milian.wolff 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 From andre at familiesomers.nl Wed Sep 17 14:06:15 2014 From: andre at familiesomers.nl (=?UTF-8?B?QW5kcsOpIFNvbWVycw==?=) Date: Wed, 17 Sep 2014 14:06:15 +0200 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <1585225.OTQJqPCDjK@milian-kdab2> References: <3787917.uYe8fR1vhY@milian-kdab2> <541970AE.6050903@familiesomers.nl> <1585225.OTQJqPCDjK@milian-kdab2> Message-ID: <54197937.5010207@familiesomers.nl> Milian Wolff schreef op 17-9-2014 13:46: > True. But do we agree that saying FOSS users don't have the "full rights to > modify source codes" is wrong, or at least misleading? I guess so, considering > you say "That's*also* nonsense" (emphasis mine). Absolutely. FOSS users have, by definition, every right to modify the source code. So yes, the current qt.io site is very misleading there. They just don't have the right to publish closed source software based on those modified sources without releasing those modifications to their users (well, sort off. It is of course a bit more involved than that.) André -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Wed Sep 17 17:20:58 2014 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 17 Sep 2014 17:20:58 +0200 Subject: [Development] moc 4.8.6 & macros In-Reply-To: <4127272.dkxdXlvcy3@tjmaciei-mobl4> References: <569B2BFA-D09B-4380-8ED4-D115714A6A83@edeltech.ch> <4127272.dkxdXlvcy3@tjmaciei-mobl4> Message-ID: <1803471.AUq7agBjcT@finn> On Tuesday 16 September 2014 23:52:36 Thiago Macieira wrote: > On Tuesday 16 September 2014 23:00:06 Samuel Gaist wrote: > > Good question, I'll have to check. > > If that where not the case, what should I write to give additional include > > paths to moc ? > > Replace QT_DEPRECATED_SINCE with the actual contents of the macro. Also > expand QT_VERSION_CHECK. > > Qt 4 moc does not expand macros. Qt 4 moc does expand macros in #if directive. (and QT_DEPRECATED_SINCE is defined to 1 for Qt4 in qtserialportglobal.h) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From samuel.gaist at edeltech.ch Wed Sep 17 17:42:40 2014 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Wed, 17 Sep 2014 17:42:40 +0200 Subject: [Development] moc 4.8.6 & macros In-Reply-To: <1803471.AUq7agBjcT@finn> References: <569B2BFA-D09B-4380-8ED4-D115714A6A83@edeltech.ch> <4127272.dkxdXlvcy3@tjmaciei-mobl4> <1803471.AUq7agBjcT@finn> Message-ID: On 17 sept. 2014, at 17:20, Olivier Goffart wrote: > On Tuesday 16 September 2014 23:52:36 Thiago Macieira wrote: >> On Tuesday 16 September 2014 23:00:06 Samuel Gaist wrote: >>> Good question, I'll have to check. >>> If that where not the case, what should I write to give additional include >>> paths to moc ? >> >> Replace QT_DEPRECATED_SINCE with the actual contents of the macro. Also >> expand QT_VERSION_CHECK. >> >> Qt 4 moc does not expand macros. > > Qt 4 moc does expand macros in #if directive. > > (and QT_DEPRECATED_SINCE is defined to 1 for Qt4 in qtserialportglobal.h) > Indeed it's defined, but it looks like moc doesn't handle the case when the macro has one or more parameter(s) even if defined in the same file Samuel From thiago.macieira at intel.com Wed Sep 17 18:01:21 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Sep 2014 09:01:21 -0700 Subject: [Development] moc 4.8.6 & macros In-Reply-To: References: <569B2BFA-D09B-4380-8ED4-D115714A6A83@edeltech.ch> <1803471.AUq7agBjcT@finn> Message-ID: <2674017.B7qG9HZYut@tjmaciei-mobl4> On Wednesday 17 September 2014 17:42:40 Samuel Gaist wrote: > On 17 sept. 2014, at 17:20, Olivier Goffart wrote: > > On Tuesday 16 September 2014 23:52:36 Thiago Macieira wrote: > >> On Tuesday 16 September 2014 23:00:06 Samuel Gaist wrote: > >>> Good question, I'll have to check. > >>> If that where not the case, what should I write to give additional > >>> include > >>> paths to moc ? > >> > >> Replace QT_DEPRECATED_SINCE with the actual contents of the macro. Also > >> expand QT_VERSION_CHECK. > >> > >> Qt 4 moc does not expand macros. > > > > Qt 4 moc does expand macros in #if directive. > > > > (and QT_DEPRECATED_SINCE is defined to 1 for Qt4 in qtserialportglobal.h) > > Indeed it's defined, but it looks like moc doesn't handle the case when the > macro has one or more parameter(s) even if defined in the same file Right, so let me be clearer: moc in Qt 4 does not expand macro calls. $ cat foo.cpp #define FOO(x) x #if FOO(1) class Foo : public QObject { Q_OBJECT }; #endif $ moc -qt4.8 foo.cpp > /dev/null foo.cpp:0: Note: No relevant classes found. No output generated. $ moc -qt5 foo.cpp > /dev/null -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Sep 17 18:05:32 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Sep 2014 09:05:32 -0700 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <54197937.5010207@familiesomers.nl> References: <1585225.OTQJqPCDjK@milian-kdab2> <54197937.5010207@familiesomers.nl> Message-ID: <1507563.1g55NEj7Ob@tjmaciei-mobl4> On Wednesday 17 September 2014 14:06:15 André Somers wrote: > Absolutely. FOSS users have, by definition, every right to modify the > source code. So yes, the current qt.io site is very misleading there. > They just don't have the right to publish closed source software based > on those modified sources without releasing those modifications to their > users (well, sort off. It is of course a bit more involved than that.) That last sentence is true, but unrelated to making modifications. Every user of Qt under the LGPL must publish the version of Qt they used, REGARDLESS of whether they modified it or not. They have to publish it on their own servers. Pointing to qt-project.org or qt.io servers is not enough to fulfil the requirements of the licence. The licence requires that the distributor of the software (v2) or the "conveyor" of the software (v3) also offer the source of the library. It's the responsibility of that person and you cannot pass it along to someone else. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Wed Sep 17 20:00:28 2014 From: andre at familiesomers.nl (=?utf-8?Q?Andr=C3=A9_Somers?=) Date: Wed, 17 Sep 2014 20:00:28 +0200 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <1507563.1g55NEj7Ob@tjmaciei-mobl4> References: <1585225.OTQJqPCDjK@milian-kdab2> <54197937.5010207@familiesomers.nl> <1507563.1g55NEj7Ob@tjmaciei-mobl4> Message-ID: <6943D077-C403-446D-91CA-9C4DD9B7DDBB@familiesomers.nl> > Op 17 sep. 2014 om 18:05 heeft Thiago Macieira het volgende geschreven: > >> On Wednesday 17 September 2014 14:06:15 André Somers wrote: >> Absolutely. FOSS users have, by definition, every right to modify the >> source code. So yes, the current qt.io site is very misleading there. > >> They just don't have the right to publish closed source software based >> on those modified sources without releasing those modifications to their >> users (well, sort off. It is of course a bit more involved than that.) > > That last sentence is true, but unrelated to making modifications. Every user > of Qt under the LGPL must publish the version of Qt they used, REGARDLESS of > whether they modified it or not. They have to publish it on their own servers. > > Pointing to qt-project.org or qt.io servers is not enough to fulfil the > requirements of the licence. The licence requires that the distributor of the > software (v2) or the "conveyor" of the software (v3) also offer the source of > the library. It's the responsibility of that person and you cannot pass it > along to someone else. > Still not quite true, and besides the point too. We were talking about if the statement on Qt.io is true. It is not. I was not suggesting an alternative. Also note that there is no requirement to offer Qt on your own server. There are different ways to fulfill the requirement from the license, that is, _if_ somebody requests the sources at all to begin with. If we were to decide to send the customer that requests the Qt sources a DVD that contains them, that would be legal as far as I understand the license. The again, IANAL, and neither are you... André From kuba at mareimbrium.org Wed Sep 17 21:09:34 2014 From: kuba at mareimbrium.org (Kuba Ober) Date: Wed, 17 Sep 2014 15:09:34 -0400 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: References: Message-ID: <80C4B40F-40CE-4169-95A8-F239FE3A7C11@mareimbrium.org> On Sep 16, 2014, at 8:11 AM, Knoll Lars wrote: > Hi everybody, > > I’m happy to tell you that we’re making significant progress towards the > new unified web page that I’ve first been talking about at the contributor > summit. We just launched the first stage of it on http://qt.io. For now > qt.digia.com is going to redirect to it. I hope you will like the new web > page. Please have a look and give us your feedback. > > In addition, we also now have a new company name for the Qt part of Digia. > It’s simply ‘The Qt Company’. > > For more details check out my blog at > http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-introduces-a-unifie > d-website-and-20e25-monthly-indie-mobile-package/ and of course > http://qt.io > > Moving forward, we would like to slowly move some more pieces that are now > on qt-project.org over to qt.io. We don’t have concrete plans yet on when > and what will move, but would probably want to start with simple things > such as the documentation. Any feedback on this is of course also more > than welcome. My only worry is that it seems like an idle exercise. Why spend all this time doing something that, ultimately, serves no real purpose? Qt’s image ultimately depends on the quality of the code and the documentation that comes with it, not on the domain name nor the amount of flashy css/javascript that went into the site’s design. One of the reasons I loath to recommend to the management to go back to paying for Qt licenses is that we’d have been sponsoring what amounts to 2 or 3 major rebrandings and “revamps”, and it seems like throwing money down the drain. As a user, I want good code. The website, as far as I’m concerned, can be text-only. Any money that the owners of Qt spend for anything besides the code is, to us as the end users, *our* money burned for frivolities. Cheers, Kuba Ober From kuba at mareimbrium.org Wed Sep 17 21:11:59 2014 From: kuba at mareimbrium.org (Kuba Ober) Date: Wed, 17 Sep 2014 15:11:59 -0400 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <3787917.uYe8fR1vhY@milian-kdab2> References: <3787917.uYe8fR1vhY@milian-kdab2> Message-ID: <99B16DA4-FF74-4387-B686-CD5770B15A0C@mareimbrium.org> On Sep 17, 2014, at 6:38 AM, Milian Wolff wrote: > On Tuesday 16 September 2014 12:11:26 Knoll Lars wrote: >> Hi everybody, >> >> I’m happy to tell you that we’re making significant progress towards the >> new unified web page that I’ve first been talking about at the contributor >> summit. We just launched the first stage of it on http://qt.io. For now >> qt.digia.com is going to redirect to it. I hope you will like the new web >> page. Please have a look and give us your feedback. >> >> In addition, we also now have a new company name for the Qt part of Digia. >> It’s simply ‘The Qt Company’. >> >> For more details check out my blog at >> http://blog.qt.digia.com/blog/2014/09/16/the-qt-company-introduces-a-unifie >> d-website-and-20e25-monthly-indie-mobile-package/ and of course >> http://qt.io > > Hey Lars, > > I have a question/request/remark: Currently, on http://www.qt.io/download/, it > says that the "community" license of Qt does not give users the "full rights > to modify source codes". What you probably mean by that, is that while the > FOSS licenses allow you to modify it, you are also required to contribute > back. Anyhow, I think this wording is highly confusing and *at least* a popup > with explanatory text should added. Or better yet, also add the green tickmark > and mention that the contributions must be upstreamed. > > We all want contributions by FOSS users of Qt after all, no? I’d go further and cetegorically state that the qt.io site, as it currently stands, seems to be designed to spread licensing FUD and is intentionally deceptive. Cheers, Kuba Ober From kuba at mareimbrium.org Wed Sep 17 21:37:48 2014 From: kuba at mareimbrium.org (Kuba Ober) Date: Wed, 17 Sep 2014 15:37:48 -0400 Subject: [Development] www.qt.io/download-open-source is broken Message-ID: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> I’d like to personally scold whoever came up with the idea of starting the “default” download at www.qt.io/download-open-source. I, for one, never download the default installer since it was always subtly broken in one fashion or another, I always build from source. So now, the genius responsible for this is also responsible for wasting tons of bandwidth for useless downloads, and for wasting 20MB *repeatedly* off of my 1GB monthly mobile plan. Thank you very much (NOT). So much for the usability of the new site, and for wishing to explore it from a phone. The person responsible should be scolded until it sinks in. I’m not kidding. This is form over substance at its finest. I like modern designs, but they must be actually usable. qt.io right now is like a very well manicured pig (with apologies to bacon). Cheers, Kuba Ober From markg85 at gmail.com Wed Sep 17 21:55:53 2014 From: markg85 at gmail.com (Mark Gaiser) Date: Wed, 17 Sep 2014 21:55:53 +0200 Subject: [Development] www.qt.io/download-open-source is broken In-Reply-To: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> References: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> Message-ID: On Wed, Sep 17, 2014 at 9:37 PM, Kuba Ober wrote: > I’d like to personally scold whoever came up with the idea of starting the “default” download at www.qt.io/download-open-source. I, for one, never download the default installer since it was always subtly broken in one fashion or another, I always build from source. So now, the genius responsible for this is also responsible for wasting tons of bandwidth for useless downloads, and for wasting 20MB *repeatedly* off of my 1GB monthly mobile plan. Thank you very much (NOT). > > So much for the usability of the new site, and for wishing to explore it from a phone. The person responsible should be scolded until it sinks in. I’m not kidding. This is form over substance at its finest. I like modern designs, but they must be actually usable. qt.io right now is like a very well manicured pig (with apologies to bacon). Why so hostile? Please try to give constructive feedback to those making the site. From Lars.Knoll at digia.com Wed Sep 17 22:17:12 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Wed, 17 Sep 2014 20:17:12 +0000 Subject: [Development] www.qt.io/download-open-source is broken In-Reply-To: References: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> Message-ID: On 17/09/14 21:55, "Mark Gaiser" wrote: >On Wed, Sep 17, 2014 at 9:37 PM, Kuba Ober wrote: >> I’d like to personally scold whoever came up with the idea of starting >>the “default” download at www.qt.io/download-open-source. I, for one, >>never download the default installer since it was always subtly broken >>in one fashion or another, I always build from source. So now, the >>genius responsible for this is also responsible for wasting tons of >>bandwidth for useless downloads, and for wasting 20MB *repeatedly* off >>of my 1GB monthly mobile plan. Thank you very much (NOT). Well, most sites out there I know start a download automatically if you click on a download button (which you probably did from qt.io/download to get to the page you mentioned). >> So much for the usability of the new site, and for wishing to explore >>it from a phone. The person responsible should be scolded until it sinks >>in. I’m not kidding. This is form over substance at its finest. I like >>modern designs, but they must be actually usable. qt.io right now is >>like a very well manicured pig (with apologies to bacon). > >Why so hostile? >Please try to give constructive feedback to those making the site. Yes, please. The site is new, and there are bugs in there and things that are not perfect. We still have a long list of known issues that need to be sorted out. Still we feel that the site is now in a state that is is a clear improvement over the old qt.digia.com site. We launched it because of that and to be able to collect feedback from the community and our users. Cheers, Lars From Lars.Knoll at digia.com Wed Sep 17 22:19:27 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Wed, 17 Sep 2014 20:19:27 +0000 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <6943D077-C403-446D-91CA-9C4DD9B7DDBB@familiesomers.nl> References: <1585225.OTQJqPCDjK@milian-kdab2> <54197937.5010207@familiesomers.nl> <1507563.1g55NEj7Ob@tjmaciei-mobl4> <6943D077-C403-446D-91CA-9C4DD9B7DDBB@familiesomers.nl> Message-ID: On 17/09/14 20:00, "André Somers" wrote: >>Op 17 sep. 2014 om 18:05 heeft Thiago Macieira >> het volgende geschreven: >> >>> On Wednesday 17 September 2014 14:06:15 André Somers wrote: >>> Absolutely. FOSS users have, by definition, every right to modify the >>> source code. So yes, the current qt.io site is very misleading there. >> >>> They just don't have the right to publish closed source software based >>> on those modified sources without releasing those modifications to >>>their >>> users (well, sort off. It is of course a bit more involved than that.) >> >> That last sentence is true, but unrelated to making modifications. >>Every user >> of Qt under the LGPL must publish the version of Qt they used, >>REGARDLESS of >> whether they modified it or not. They have to publish it on their own >>servers. >> >> Pointing to qt-project.org or qt.io servers is not enough to fulfil the >> requirements of the licence. The licence requires that the distributor >>of the >> software (v2) or the "conveyor" of the software (v3) also offer the >>source of >> the library. It's the responsibility of that person and you cannot pass >>it >> along to someone else. >> > >Still not quite true, and besides the point too. We were talking about if >the statement on Qt.io is true. It is not. I was not suggesting an >alternative. Also note that there is no requirement to offer Qt on your >own server. There are different ways to fulfill the requirement from the >license, that is, _if_ somebody requests the sources at all to begin >with. If we were to decide to send the customer that requests the Qt >sources a DVD that contains them, that would be legal as far as I >understand the license. The again, IANAL, and neither are you... It's supposed to mean that you can modify Qt's source code without having to release the changes. I agree that the text is not clear enough and it should be somehow changed. Cheers, Lars From Lars.Knoll at digia.com Wed Sep 17 22:25:22 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Wed, 17 Sep 2014 20:25:22 +0000 Subject: [Development] www.qt.io/download-open-source is broken In-Reply-To: References: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> Message-ID: On 17/09/14 22:17, "Knoll Lars" wrote: >On 17/09/14 21:55, "Mark Gaiser" wrote: > >>On Wed, Sep 17, 2014 at 9:37 PM, Kuba Ober wrote: >>> I’d like to personally scold whoever came up with the idea of starting >>>the “default” download at www.qt.io/download-open-source. I, for one, >>>never download the default installer since it was always subtly broken >>>in one fashion or another, I always build from source. So now, the >>>genius responsible for this is also responsible for wasting tons of >>>bandwidth for useless downloads, and for wasting 20MB *repeatedly* off >>>of my 1GB monthly mobile plan. Thank you very much (NOT). > >Well, most sites out there I know start a download automatically if you >click on a download button (which you probably did from qt.io/download to >get to the page you mentioned). Adding to myself: But I agree that downloading to a phone doesn't make too much sense, and we should probably detect that you look at the site from a mobile device. That part sounds like a plain old bug. >>> So much for the usability of the new site, and for wishing to explore >>>it from a phone. The person responsible should be scolded until it sinks >>>in. I’m not kidding. This is form over substance at its finest. I like >>>modern designs, but they must be actually usable. qt.io right now is >>>like a very well manicured pig (with apologies to bacon). >> >>Why so hostile? >>Please try to give constructive feedback to those making the site. > >Yes, please. The site is new, and there are bugs in there and things that >are not perfect. We still have a long list of known issues that need to be >sorted out. Still we feel that the site is now in a state that is is a >clear improvement over the old qt.digia.com site. We launched it because >of that and to be able to collect feedback from the community and our >users. > >Cheers, >Lars > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed Sep 17 23:37:39 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Sep 2014 14:37:39 -0700 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: References: <6943D077-C403-446D-91CA-9C4DD9B7DDBB@familiesomers.nl> Message-ID: <2373137.qig7RtcK4H@tjmaciei-mobl4> On Wednesday 17 September 2014 20:19:27 Knoll Lars wrote: > It's supposed to mean that you can modify Qt's source code without having > to release the changes. I agree that the text is not clear enough and it > should be somehow changed. Right. The point isn't the "modify", it's the "release the sources". With the LGPL, you have to do that even if you don't modify. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Sep 17 23:39:27 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Sep 2014 14:39:27 -0700 Subject: [Development] www.qt.io/download-open-source is broken In-Reply-To: References: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> Message-ID: <2113986.F5x9ihdZKj@tjmaciei-mobl4> On Wednesday 17 September 2014 20:25:22 Knoll Lars wrote: > Adding to myself: But I agree that downloading to a phone doesn't make too > much sense, and we should probably detect that you look at the site from a > mobile device. That part sounds like a plain old bug. ugh... I hate those detections. Like Yahoo Finance deciding that my rekonq is a mobile browser and forcing me to the stripped down mobile site. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lorn.potter at gmail.com Thu Sep 18 02:13:47 2014 From: lorn.potter at gmail.com (Lorn Potter) Date: Thu, 18 Sep 2014 10:13:47 +1000 Subject: [Development] www.qt.io/download-open-source is broken In-Reply-To: References: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> Message-ID: <541A23BB.20006@gmail.com> On 18/09/14 06:25, Knoll Lars wrote: > On 17/09/14 22:17, "Knoll Lars" wrote: > > Adding to myself: But I agree that downloading to a phone doesn't make too > much sense, and we should probably detect that you look at the site from a > mobile device. That part sounds like a plain old bug. I know of crazy people that do just that willingly and compile on open source linux phones... :) I also hate the detection and web sites thinking they know what's best for me to see/view/experience. From lorn.potter at gmail.com Thu Sep 18 02:26:32 2014 From: lorn.potter at gmail.com (Lorn Potter) Date: Thu, 18 Sep 2014 10:26:32 +1000 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <80C4B40F-40CE-4169-95A8-F239FE3A7C11@mareimbrium.org> References: <80C4B40F-40CE-4169-95A8-F239FE3A7C11@mareimbrium.org> Message-ID: <541A26B8.7@gmail.com> On 18/09/14 05:09, Kuba Ober wrote: > One of the reasons I loath to recommend to the management to go back to paying for Qt licenses is that we’d have been sponsoring what amounts to 2 or 3 major rebrandings and “revamps”, and it seems like throwing money down the drain. As a user, I want good code. The website, as far as I’m concerned, can be text-only. Any money that the owners of Qt spend for anything besides the code is, to us as the end users,*our* money burned for frivolities. speak for yourself. I think it looks quite nice. They've done a good job making it look appealing and useful. While text only web site might be ok with you, managers or directors scoping out a dev framework for the first time might be wary about paying for something with a web site from 1980's Quality of code also runs to the web servers. I am a bit wary about dev apps/frameworks/tools whose web site looks like gak. From thiago.macieira at intel.com Thu Sep 18 02:43:03 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Sep 2014 17:43:03 -0700 Subject: [Development] www.qt.io/download-open-source is broken In-Reply-To: <541A23BB.20006@gmail.com> References: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> <541A23BB.20006@gmail.com> Message-ID: <6300837.SQkKd1cGHc@tjmaciei-mobl4> On Thursday 18 September 2014 10:13:47 Lorn Potter wrote: > I know of crazy people that do just that willingly and compile on open > source linux phones... There was that story of Aaron Seigo compiling Plasma Mobile on an N900. Took about a week. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sirspudd at gmail.com Thu Sep 18 05:36:13 2014 From: sirspudd at gmail.com (Donald Carr) Date: Wed, 17 Sep 2014 20:36:13 -0700 Subject: [Development] www.qt.io/download-open-source is broken In-Reply-To: <6300837.SQkKd1cGHc@tjmaciei-mobl4> References: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> <541A23BB.20006@gmail.com> <6300837.SQkKd1cGHc@tjmaciei-mobl4> Message-ID: >> I know of crazy people that do just that willingly and compile on open >> source linux phones... > > There was that story of Aaron Seigo compiling Plasma Mobile on an N900. Took > about a week. Which has the rare attribute of making scratchbox/Madde look comparatively handsome From Tero.Kojo at digia.com Thu Sep 18 08:06:58 2014 From: Tero.Kojo at digia.com (Kojo Tero) Date: Thu, 18 Sep 2014 06:06:58 +0000 Subject: [Development] www.qt.io/download-open-source is broken In-Reply-To: <2113986.F5x9ihdZKj@tjmaciei-mobl4> References: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> <2113986.F5x9ihdZKj@tjmaciei-mobl4> Message-ID: <1377cccb6fc8426580b08eae43522525@DB4PR02MB237.eurprd02.prod.outlook.com> > -----Original Message----- > From: development-bounces+tero.kojo=digia.com at qt-project.org > [mailto:development-bounces+tero.kojo=digia.com at qt-project.org] On > Behalf Of Thiago Macieira > Sent: 18. syyskuuta 2014 0:39 > To: development at qt-project.org > Subject: Re: [Development] www.qt.io/download-open-source is broken > > On Wednesday 17 September 2014 20:25:22 Knoll Lars wrote: > > Adding to myself: But I agree that downloading to a phone doesn't make > > too much sense, and we should probably detect that you look at the > > site from a mobile device. That part sounds like a plain old bug. > > ugh... I hate those detections. Like Yahoo Finance deciding that my rekonq is > a mobile browser and forcing me to the stripped down mobile site. The reason for the detection is simply to make the page less intimidating. I did the same thing for qt-project.org/download (identify your browser) and it cut the amount of "you have fifty links on the download page, which one should I click?"-questions from the second most asked support question to almost zero. Thus I told the web team to please do that for the new site too. Sure we get the occasional person who wants to download the mac version on their linux machine for some reason, but in my experience those people are very capable of doing that extra click to show all the options. As for starting the download on mobile automatically... yes, as Lars said, bug. Tero > -- > 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 bog_dan_ro at yahoo.com Thu Sep 18 08:08:51 2014 From: bog_dan_ro at yahoo.com (BogDan) Date: Wed, 17 Sep 2014 23:08:51 -0700 Subject: [Development] Qt 5.3.2 uploaded to Ministro testing repository Message-ID: <1411020531.68173.YahooMailNeo@web126101.mail.ne1.yahoo.com> Hello folks, I'd like to let you know that Qt 5.3.2 libs were uploaded to *testing* repository. In order to test the repo, please install and run "Ministro Configuration Tool"[1] and switch to testing repository. All *existing apps* should run *without any changes* (e.g. recompilation). As usually the libs will stay in this repository for at least one month. After this period if nobody reports *NO regression* we'll move them to *stable* (Ministro's default repository). Sadly qt 5.3.1 didn't end up in stable repository because it had regressions. Cheers, BogDan. [1] https://play.google.com/store/apps/details?id=org.kde.ministro.config or http://files.kde.org/necessitas/installer/release/MinistroConfigurationTool%20II.apk P.S. I just changed testing repos a few moments ago, so, please wait a few hours before you test, until all mirrors will be updated. From mikko.hurskainen at nomovok.com Thu Sep 18 08:56:47 2014 From: mikko.hurskainen at nomovok.com (Mikko Hurskainen) Date: Thu, 18 Sep 2014 14:56:47 +0800 Subject: [Development] OpenVG rendering backend to Qt Quick 2 Message-ID: <541A822F.9020002@nomovok.com> Hi, I am interested on working on Qt Quick 2 Scenegraph OpenVG rendering backend. Few embedded devices have both OpenVG and OpenGL accelerators available. There are few interesting use cases for embedded devices: * 2 display configurations, draw one with OpenVG and one with OpenGL * OpenVG consumes less power, draw some applications with OpenVG. For example more complex idle screen. * Composite both OpenVG and OpenGL renderings into same display. Idea here is that real-time critical items are rendered with OpenVG and non-critical stuff with OpenGL In Qt4 there was a OpenVG rendering backend, but that of course does not fit directly into Scenegraph. Also I found that there has been a plan for this kind of functionality in Qt Conference 2012, but I could not find any results. Is there some (even partial) results available somewhere ? How about technical feasibility. Scenegraph type rendering is in general doable with OpenVG. The backend would need re-implementation to use OpenVG primitives instead of OpenGL (ES). In general I think it should be doable. Any opinions or possible pitfalls ? With Best Regards, -- Mikko Hurskainen From Lars.Knoll at digia.com Thu Sep 18 09:07:44 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Thu, 18 Sep 2014 07:07:44 +0000 Subject: [Development] www.qt.io/download-open-source is broken In-Reply-To: <1377cccb6fc8426580b08eae43522525@DB4PR02MB237.eurprd02.prod.outlook.com> References: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> <2113986.F5x9ihdZKj@tjmaciei-mobl4> <1377cccb6fc8426580b08eae43522525@DB4PR02MB237.eurprd02.prod.outlook.com> Message-ID: On 18/09/14 08:06, "Kojo Tero" wrote: >> -----Original Message----- >> From: development-bounces+tero.kojo=digia.com at qt-project.org >> [mailto:development-bounces+tero.kojo=digia.com at qt-project.org] On >> Behalf Of Thiago Macieira >> Sent: 18. syyskuuta 2014 0:39 >> To: development at qt-project.org >> Subject: Re: [Development] www.qt.io/download-open-source is broken >> >> On Wednesday 17 September 2014 20:25:22 Knoll Lars wrote: >> > Adding to myself: But I agree that downloading to a phone doesn't make >> > too much sense, and we should probably detect that you look at the >> > site from a mobile device. That part sounds like a plain old bug. >> >> ugh... I hate those detections. Like Yahoo Finance deciding that my >>rekonq is >> a mobile browser and forcing me to the stripped down mobile site. > >The reason for the detection is simply to make the page less >intimidating. >I did the same thing for qt-project.org/download (identify your browser) >and it cut the amount of "you have fifty links on the download page, >which one should I click?"-questions from the second most asked support >question to almost zero. >Thus I told the web team to please do that for the new site too. > >Sure we get the occasional person who wants to download the mac version >on their linux machine for some reason, but in my experience those people >are very capable of doing that extra click to show all the options. > >As for starting the download on mobile automatically... yes, as Lars >said, bug. The platform detection is extremely useful to show the right package to download in the majority of cases. Before people (especially new users) where usually very confused as to which package to choose. The automatic download is a bit overdone currently, as it also downloads on back/forward navigations and doesn’t remember that the package has already been downloaded once. So we should consider whether that’s the best approach or whether an approach more similar to the old download page is better. It’s one more click, but then it’s very explicit, and people will get exactly the package they asked for. Cheers, Lars From goblincoding at gmail.com Thu Sep 18 09:40:50 2014 From: goblincoding at gmail.com (William Hallatt) Date: Thu, 18 Sep 2014 09:40:50 +0200 Subject: [Development] www.qt.io/download-open-source is broken In-Reply-To: References: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> <2113986.F5x9ihdZKj@tjmaciei-mobl4> <1377cccb6fc8426580b08eae43522525@DB4PR02MB237.eurprd02.prod.outlook.com> Message-ID: On 18 September 2014 09:07, Knoll Lars wrote: > The automatic download is a bit overdone currently, as it also downloads > on back/forward navigations and doesn’t remember that the package has > already been downloaded once. So we should consider whether that’s the > best approach or whether an approach more similar to the old download page > is better. It’s one more click, but then it’s very explicit, and people > will get exactly the package they asked for. Although one could probably argue that users should be paying attention to what they're doing, the "re-download" on navigation could potentially have a nasty side-effect. Many Qt users (myself included) live in countries where access to uncapped bandwidth is not a given and it could mean a nasty internet bill if you accidentally trigger an additional download that pushes you over your cap (e.g. many of my colleagues have 3 - 5 GB monthly caps so an extra ~700MB obviously makes a big difference). Perhaps just something to consider :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From macadder1 at gmail.com Thu Sep 18 10:03:47 2014 From: macadder1 at gmail.com (Jason McDonald) Date: Thu, 18 Sep 2014 18:03:47 +1000 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <80C4B40F-40CE-4169-95A8-F239FE3A7C11@mareimbrium.org> References: <80C4B40F-40CE-4169-95A8-F239FE3A7C11@mareimbrium.org> Message-ID: On Thu, Sep 18, 2014 at 5:09 AM, Kuba Ober wrote: > > My only worry is that it seems like an idle exercise. Why spend all this > time doing something that, ultimately, serves no real purpose? Qt’s image > ultimately depends on the quality of the code and the documentation that > comes with it, not on the domain name nor the amount of flashy > css/javascript that went into the site’s design. > For developers like you and I, that's mostly true. For the people in suits who might decide to invest millions of dollars/pounds/euros in building a big project with Qt, the "complete package" is important. Those folks want to see that Qt is a serious competitor in the commercial market, is professionally maintained and supported, is keeping up with evolving technology, has a thriving ecosystem, and that it is here to stay. Those folks are the source of a big chunk of the money that creates jobs for Qt application developers in their own companies and for Qt framework and tools developers in places like Digia. > One of the reasons I loath to recommend to the management to go back to > paying for Qt licenses is that we’d have been sponsoring what amounts to 2 > or 3 major rebrandings and “revamps”, and it seems like throwing money down > the drain. As a user, I want good code. The website, as far as I’m > concerned, can be text-only. Any money that the owners of Qt spend for > anything besides the code is, to us as the end users, *our* money burned > for frivolities. > If we want the Qt ecosystem to remain healthy and continue to grow, we need to make sure that there are as few things as possible that might discourage a potential new user from joining the ecosystem. Like it or not, first impressions are important, and the Qt website is the primary entry point for a lot of those folks in suits. How many times have you steered away from a product or company because its website seemed old, unmaintained, unprofessional, buggy, or hard to navigate? I've already done that twice just today. I think the new site looks good, and it's also rather pleasing to see the examples of where some of my past work has ended up. Even for someone who likes to focus on deep technical details, it's good to see the big picture once in a while. Cheers, -- Jason -------------- next part -------------- An HTML attachment was scrubbed... URL: From olszak.tomasz at gmail.com Thu Sep 18 11:34:46 2014 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Thu, 18 Sep 2014 11:34:46 +0200 Subject: [Development] QtWebEngine is building all needed libs from sources. In-Reply-To: References: Message-ID: 2014-09-17 8:53 GMT+02:00 haithem rahmani : > Hi, > > In the Qt-5.4.0-alpha release I noticed that QtWebEngine, is building all > reuqired libs tools > from sources even if those tools and libs are provided by the host. > IIRC it is not Qt part which builds dependencies but blink part (that's is done by default blink build recipes) Cheers, Tomasz From Jan-Arve.Saether at digia.com Thu Sep 18 11:44:27 2014 From: Jan-Arve.Saether at digia.com (Saether Jan-Arve) Date: Thu, 18 Sep 2014 09:44:27 +0000 Subject: [Development] Nominating Venugopal Shivashankar and Nico Vertriest as approvers In-Reply-To: References: Message-ID: <66BFFE861C7DE34D9B0372D8EAAB18E2012B90E8@IT-EXMB01-HKI.it.local> +2 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 Reinio Topi Sent: 16. september 2014 09:31 To: development at qt-project.org Subject: [Development] Nominating Venugopal Shivashankar and Nico Vertriest as approvers I'd like to nominate Venugopal Shivashankar and Nico Vertriest as approvers in the Qt Project. They are both documentation engineers and integral part of the of Qt documentation team. Venugopal Shivashankar: https://codereview.qt-project.org/#/q/owner:veshivas,n,z https://codereview.qt-project.org/#/q/reviewer:veshivas,n,z Nico Vertriest: https://codereview.qt-project.org/#/q/owner:vertries,n,z https://codereview.qt-project.org/#/q/reviewer:vertries,n,z Both Venu and Nico have been working on Qt for a long time (pre-Qt 5.0) already, contributing numerous improvements to Qt documentation. Many people rely on them for documentation and language reviews, and having them as approvers would speed up documentation work and ease the review-burden on other team members. -Topi -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.sasburg at gmail.com Thu Sep 18 01:32:08 2014 From: simon.sasburg at gmail.com (Simon Sasburg) Date: Thu, 18 Sep 2014 01:32:08 +0200 Subject: [Development] www.qt.io/download-open-source is broken In-Reply-To: References: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> Message-ID: > Well, most sites out there I know start a download automatically if you > click on a download button (which you probably did from qt.io/download to > get to the page you mentioned). Well the problem is from qt.io/download there is no choice/indication of what is going to be downloaded. And as far as i can see, the only way to any choice (download source package/get android package on windows/etc) is through a link to http://qt-project.org/downloads, which is on the page which autodownloads stuff based on the detected platform. Maybe i'm missing something, but it would be pretty annoying to be forced to download an online installer each time i want a source package... From xbenlau at gmail.com Thu Sep 18 12:31:13 2014 From: xbenlau at gmail.com (Ben Lau) Date: Thu, 18 Sep 2014 18:31:13 +0800 Subject: [Development] www.qt.io/download-open-source is broken In-Reply-To: References: <7E7CDDF5-0B88-4579-802E-853D8BBC8018@mareimbrium.org> Message-ID: On 18 September 2014 07:32, Simon Sasburg wrote: > > Well, most sites out there I know start a download automatically if you > > click on a download button (which you probably did from qt.io/download > to > > get to the page you mentioned). > Well the problem is from qt.io/download there is no choice/indication > of what is going to be downloaded. > And as far as i can see, the only way to any choice (download source > package/get android package on windows/etc) is through a link to > http://qt-project.org/downloads, which is on the page which > autodownloads stuff based on the detected platform. Maybe i'm missing > something, but it would be pretty annoying to be forced to download an > online installer each time i want a source package... > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > I have multiple development machines and the download speed can be very slow. So usually I prefer to get an offline version via another server using wget. Then copy to those machines. I will never choose the online installer and therefore I am very confused to find a correct download link in qt.io . Finally , I switch back to http://qt-project.org/downloads to get the right version I want. It will be great if qt.io also provide the links with all versions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at digia.com Thu Sep 18 12:51:22 2014 From: Kai.Koehne at digia.com (Koehne Kai) Date: Thu, 18 Sep 2014 10:51:22 +0000 Subject: [Development] QtWebEngine is building all needed libs from sources. In-Reply-To: References: Message-ID: <5B2736A3C8B75B4BB66BC58DC5E889B0AA6D9D@IT-EXMB01-HKI.it.local> > -----Original Message----- > From: development-bounces+kai.koehne=digia.com at qt-project.org > [mailto:development-bounces+kai.koehne=digia.com at qt-project.org] On > Behalf Of Tomasz Olszak > Sent: Thursday, September 18, 2014 11:35 AM > To: haithem rahmani > Cc: development at qt-project.org > Subject: Re: [Development] QtWebEngine is building all needed libs from > sources. > > 2014-09-17 8:53 GMT+02:00 haithem rahmani > : > > Hi, > > > > In the Qt-5.4.0-alpha release I noticed that QtWebEngine, is building > > all reuqired libs tools from sources even if those tools and libs are > > provided by the host. > > > IIRC it is not Qt part which builds dependencies but blink part (that's is done > by default blink build recipes) Also, 'all required libs' is not true. I just tried to compile qtwebengine the first time on an OpenSUSE box, and it was requiring a couple of dependencies we so far didn't have: dbus-1-devel libpulse-devel pciutils-devel mozilla-nss-devel libcap-devel alsa-devel Now not all of these libraries end up as hard runtime dependencies, it seems. But at least the libnss3 library isn't installed by default on most distributions. Can this somehow be worked around (e.g. by making libnss3 optional?) Regards Kai From bog_dan_ro at yahoo.com Thu Sep 18 13:31:20 2014 From: bog_dan_ro at yahoo.com (BogDan) Date: Thu, 18 Sep 2014 04:31:20 -0700 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <1507563.1g55NEj7Ob@tjmaciei-mobl4> References: <1585225.OTQJqPCDjK@milian-kdab2> <54197937.5010207@familiesomers.nl> <1507563.1g55NEj7Ob@tjmaciei-mobl4> Message-ID: <1411039880.71584.YahooMailNeo@web126106.mail.ne1.yahoo.com> ----- Original Message ----- From: Thiago Macieira On Wednesday 17 September 2014 14:06:15 André Somers wrote: > Absolutely. FOSS users have, by definition, every right to modify the > source code. So yes, the current qt.io site is very misleading there. > They just don't have the right to publish closed source software based > on those modified sources without releasing those modifications to their > users (well, sort off. It is of course a bit more involved than that.) That last sentence is true, but unrelated to making modifications. Every user of Qt under the LGPL must publish the version of Qt they used, REGARDLESS of whether they modified it or not. They have to publish it on their own servers. [..] Your sentence is correct as long as the user *ships* qt libs alongside his apps! If the application uses system libraries, then IMHO, is not his responsibility to provide the sources for Qt. Cheers, BogDan. From rawoul at gmail.com Thu Sep 18 14:24:57 2014 From: rawoul at gmail.com (Arnaud Vrac) Date: Thu, 18 Sep 2014 14:24:57 +0200 Subject: [Development] QtWebEngine is building all needed libs from sources. In-Reply-To: References: Message-ID: On Wed, Sep 17, 2014 at 8:53 AM, haithem rahmani wrote: > Hi, > > In the Qt-5.4.0-alpha release I noticed that QtWebEngine, is building all > reuqired libs tools > from sources even if those tools and libs are provided by the host. > > Won't this cause any issue with Qt being built with 'system' libs for > example, freetype, sqlite, png, jpeg? > > Is there anyway to force QtWebEngine to use system libs? > I haven't tested but there's a script in the chromium repository that patches the build recipes to use external libraries. You can find more details about this in qtwebengine/src/3rdparty/chromium/build/linux/unbundle/README. I'd be interested to know if you manage to build qtwebengine with this setup. -- Arnaud Vrac -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Sep 18 19:23:16 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 18 Sep 2014 10:23:16 -0700 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <1411039880.71584.YahooMailNeo@web126106.mail.ne1.yahoo.com> References: <1507563.1g55NEj7Ob@tjmaciei-mobl4> <1411039880.71584.YahooMailNeo@web126106.mail.ne1.yahoo.com> Message-ID: <83005449.ZnUumijBu7@tjmaciei-mobl4> On Thursday 18 September 2014 04:31:20 BogDan wrote: > Your sentence is correct as long as the user *ships* qt libs alongside his > apps! If the application uses system libraries, then IMHO, is not his > responsibility to provide the sources for Qt. Right. And when using Ministro, it's the Ministro packager's responsibility to provide the sources. We should make Ministro packages officially part of the Qt Project so that the official sources apply and we don't need to spply them elsewhere. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ono at java.pl Thu Sep 18 19:31:33 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 18 Sep 2014 19:31:33 +0200 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes Message-ID: Briefly - current Qt5 frameworks bundles structure is invalid & cannot be code signed anymore in 10.9.5 & 10.10. Also Please have a look at Apple's recent TN2206: https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205 And reference for proper bundle structure: https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html More details: (1) Qt Creator signature is rejected $ spctl -avv /Applications/Qt\ Creator.app /Applications/Qt Creator.app: rejected source=obsolete resource envelope origin=Developer ID Application: Digia Plc (2) bundles & Qt SDK built QtXXX.framework structure is invalid: Info.plist is expected to be in Resources/ not in Contents/. Resources/ must be present and need to be symlinked to bundle's root. PRESENT: QtCore.framework/ Contents/ Info.plist QtCore -> Versions/Current/QtCore Versions/ Current -> 5 5/ QtCore Causing: $ codesign --deep -f -s 'Developer ID' -vvv /tmp/QtCore.framework /tmp/QtCore.framework: unsealed contents present in the bundle root EXPECTED: QtCore.framework/ QtCore -> Versions/Current/QtCore Resources -> Versions/Current/Resources Versions/ Current -> 5 5/ QtCore Resources/ Info.plist Once bundle layout is changed as above then codesign succeeds. I think this deserves attention because it will likely cause all existing Qt apps to be rejected by Gatekeeper in 10.9.5 & 10.10. Regards, -- Adam From raul at metsma.ee Thu Sep 18 20:14:15 2014 From: raul at metsma.ee (Raul Metsma) Date: Thu, 18 Sep 2014 21:14:15 +0300 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: References: Message-ID: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> Reported already 24/Jan/14 QTBUG-36429 even mentioned in thread http://comments.gmane.org/gmane.comp.lib.qt.devel/17821 Raul On 18 Sep 2014, at 20:31, Adam Strzelecki wrote: > Briefly - current Qt5 frameworks bundles structure is invalid & cannot be code signed anymore in 10.9.5 & 10.10. Also > > Please have a look at Apple's recent TN2206: > > https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205 > > And reference for proper bundle structure: > > https://developer.apple.com/library/mac/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html > > More details: > > (1) Qt Creator signature is rejected > > $ spctl -avv /Applications/Qt\ Creator.app > /Applications/Qt Creator.app: rejected > source=obsolete resource envelope > origin=Developer ID Application: Digia Plc > > (2) bundles & Qt SDK built QtXXX.framework structure is invalid: Info.plist is expected to be in Resources/ not in Contents/. Resources/ must be present and need to be symlinked to bundle's root. > > PRESENT: > > QtCore.framework/ > Contents/ > Info.plist > QtCore -> Versions/Current/QtCore > Versions/ > Current -> 5 > 5/ > QtCore > > Causing: > $ codesign --deep -f -s 'Developer ID' -vvv /tmp/QtCore.framework > /tmp/QtCore.framework: unsealed contents present in the bundle root > > EXPECTED: > > QtCore.framework/ > QtCore -> Versions/Current/QtCore > Resources -> Versions/Current/Resources > Versions/ > Current -> 5 > 5/ > QtCore > Resources/ > Info.plist > > Once bundle layout is changed as above then codesign succeeds. > > I think this deserves attention because it will likely cause all existing Qt apps to be rejected by Gatekeeper in 10.9.5 & 10.10. > > Regards, > -- > Adam > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From ono at java.pl Thu Sep 18 20:32:14 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 18 Sep 2014 20:32:14 +0200 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> Message-ID: <88C827C7-6C4E-4B90-BF15-68AFA64C45EC@java.pl> Thanks a lot for pointing me to the bug report and original thread. Somehow it has hit me today once I've upgraded to 10.9.5 that brings stricter signing policy. --Adam From ono at java.pl Thu Sep 18 22:07:58 2014 From: ono at java.pl (Adam Strzelecki) Date: Thu, 18 Sep 2014 22:07:58 +0200 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> Message-ID: <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> > Reported already 24/Jan/14 QTBUG-36429 FYI more recent and prioritized bug report is QTBUG-38511 I think it deserves a lot of attention now since 10.9.5 is live. --Adam From jeremy.k.list at gmail.com Fri Sep 19 06:46:27 2014 From: jeremy.k.list at gmail.com (Jeremy) Date: Thu, 18 Sep 2014 21:46:27 -0700 Subject: [Development] Requesting removal of qtjsondb In-Reply-To: <54194EF6.4080608@digia.com> References: <54194EF6.4080608@digia.com> Message-ID: On 5September2014, at 02:05, Joerg Bornemann wrote: > The qtjsondb module is dead. It doesn't build since ages and has zero > users. As civilized people we should bury our dead. > Therefore I'd like to request the removal of qtjsondb from Qt's mother > repository. > > Please raise any objections here or on codereview: > https://codereview.qt-project.org/#/c/95086/ > Bury, or retire? I don’t see an issue with removing it from Qt 5. Is there a general plan for modules that exit from production-ready status? From thiago.macieira at intel.com Fri Sep 19 06:57:47 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 18 Sep 2014 21:57:47 -0700 Subject: [Development] Requesting removal of qtjsondb In-Reply-To: References: <54194EF6.4080608@digia.com> Message-ID: <3116877.SbL9j03dDi@tjmaciei-mobl4> On Thursday 18 September 2014 21:46:27 Jeremy wrote: > I don’t see an issue with removing it from Qt 5. Is there a general plan for > modules that exit from production-ready status? Modules that exit from production-ready status need to go through the deprecation ladder: first Done, then Deprecated (with possibly a replacement), and then finally Removed. The package should be made to compile with future versions of Qt. That's what we did for Qt Script Classic, Qt Assistant ADP, QHttp, QFtp, etc. However, let's be clear: QtJsondb never achieved "production-ready" status. It never left "pre-alpha" state and was never released. There's no one using it. Simply remove the link from qt5.git and leave the repo to rot. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bog_dan_ro at yahoo.com Fri Sep 19 09:11:29 2014 From: bog_dan_ro at yahoo.com (BogDan) Date: Fri, 19 Sep 2014 00:11:29 -0700 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <83005449.ZnUumijBu7@tjmaciei-mobl4> References: <1507563.1g55NEj7Ob@tjmaciei-mobl4> <1411039880.71584.YahooMailNeo@web126106.mail.ne1.yahoo.com> <83005449.ZnUumijBu7@tjmaciei-mobl4> Message-ID: <1411110689.28756.YahooMailNeo@web126105.mail.ne1.yahoo.com> > Your sentence is correct as long as the user *ships* qt libs alongside his > apps! If the application uses system libraries, then IMHO, is not his > responsibility to provide the sources for Qt. Right. And when using Ministro, it's the Ministro packager's responsibility to provide the sources. We should make Ministro packages officially part of the Qt Project so that the official sources apply and we don't need to spply them elsewhere. Well, I was referring to linux distributions :). But you're right Ministro is the same thing. Ministro packages *are* officially part of the Qt project! I'm doing this job manually because we didn't had time to integrate it with the release scripts (yet).But moving libs from *testing* to *stable* repository needs human touch, because we don't want to move them if they have regressions and they will break all existing apps out there :). Cheers, BogDan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Friedemann.Kleint at digia.com Fri Sep 19 10:31:51 2014 From: Friedemann.Kleint at digia.com (Friedemann Kleint) Date: Fri, 19 Sep 2014 10:31:51 +0200 Subject: [Development] Nominating Louai Al-Khanji as approver Message-ID: <541BE9F7.8090305@digia.com> Hi, I'd like to nominate Louai Al-Khanji as approver inthe Qt Project: https://codereview.qt-project.org/#/q/owner:louai.al-khanji,n,z https://codereview.qt-project.org/#/q/reviewer:louai.al-khanji,n,z He implemented the Windows Direct2D platform plugin (which works well beyond expectations) and has also done significant work in other areas (Qt3D, Wayland). Regards, Friedemann -- Friedemann Kleint Digia, Qt -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew.Knight at digia.com Fri Sep 19 10:42:42 2014 From: Andrew.Knight at digia.com (Knight Andrew) Date: Fri, 19 Sep 2014 08:42:42 +0000 Subject: [Development] Nominating Louai Al-Khanji as approver In-Reply-To: <541BE9F7.8090305@digia.com> References: <541BE9F7.8090305@digia.com> Message-ID: <89275824ad484859ad8b360acc461aeb@DB4PR02MB272.eurprd02.prod.outlook.com> > From: development-bounces+andrew.knight=digia.com at qt-project.org [mailto:development-bounces+andrew.knight=digia.com at qt-project.org] On Behalf Of Friedemann Kleint > Sent: 19 September 2014 11:32 > To: development at qt-project.org > Subject: [Development] Nominating Louai Al-Khanji as approver > > Hi, > I'd like to nominate Louai Al-Khanji as approver in the Qt Project: > https://codereview.qt-project.org/#/q/owner:louai.al-khanji,n,z > https://codereview.qt-project.org/#/q/reviewer:louai.al-khanji,n,z > He implemented the Windows Direct2D platform plugin (which works well beyond expectations) and has also done significant work in other areas (Qt3D, Wayland). > Regards, > Friedemann > -- > Friedemann Kleint > Digia, Qt +1 Having recently worked on a few issues in the direct2d plugin, I can affirm that it is well-organized and of high overall quality. Louai is actively involved in many other graphics-related areas in Qt and is active in IRC and on the mailing lists. I also know from his personal background that he has been working with Qt since “before the Nokia days”. His approvership would be a valuable asset to the Qt Project. -Andrew From coroberti at gmail.com Fri Sep 19 11:05:27 2014 From: coroberti at gmail.com (Robert Iakobashvili) Date: Fri, 19 Sep 2014 12:05:27 +0300 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> Message-ID: On Thu, Sep 18, 2014 at 11:07 PM, Adam Strzelecki wrote: >> Reported already 24/Jan/14 QTBUG-36429 > > FYI more recent and prioritized bug report is QTBUG-38511 > > I think it deserves a lot of attention now since 10.9.5 is live. > > --Adam Agree. The v2 signatures will be enforced starting from November 1 in the Store, and with 10.10 Gatekeeper deployment immediately, so that it looks like not too much time left to make the bundle structure to comply with expected by codesign for v2. I've voted for all the bugs above; could the priority of the issues to be increased? Thank you. Robert From Morten.Sorvig at digia.com Fri Sep 19 11:28:11 2014 From: Morten.Sorvig at digia.com (Sorvig Morten) Date: Fri, 19 Sep 2014 09:28:11 +0000 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> Message-ID: <277B9377-3A29-4180-8497-53B977A82A65@digia.com> > On 18 Sep 2014, at 22:07, Adam Strzelecki wrote: > >> Reported already 24/Jan/14 QTBUG-36429 > > FYI more recent and prioritized bug report is QTBUG-38511 > > I think it deserves a lot of attention now since 10.9.5 is live. This will indeed receive attention in the coming days. There are already some patches attached to the QTBUGs. I’ll post back here once we have a complete patch set ready. Target branches are Qt 5.3 and Qt 4.8. Morten From robertknight at gmail.com Fri Sep 19 12:48:27 2014 From: robertknight at gmail.com (Robert Knight) Date: Fri, 19 Sep 2014 11:48:27 +0100 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: <277B9377-3A29-4180-8497-53B977A82A65@digia.com> References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> Message-ID: For anyone who is using CMake to build DMG packages using Qt, we have a script to fix up the layout of Qt repos prior to building at https://github.com/Mendeley/Mac-OS-X-Bundle-Utilities This was targeted at Qt 4 but the Qt 5 bundles have the same structure and issues as far as I see. On 19 September 2014 10:28, Sorvig Morten wrote: > >> On 18 Sep 2014, at 22:07, Adam Strzelecki wrote: >> >>> Reported already 24/Jan/14 QTBUG-36429 >> >> FYI more recent and prioritized bug report is QTBUG-38511 >> >> I think it deserves a lot of attention now since 10.9.5 is live. > > This will indeed receive attention in the coming days. There are already some patches attached to the QTBUGs. I’ll post back here once we have a complete patch set ready. Target branches are Qt 5.3 and Qt 4.8. > > Morten > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From sean.harmer at kdab.com Fri Sep 19 12:58:32 2014 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 19 Sep 2014 11:58:32 +0100 Subject: [Development] Nominating Louai Al-Khanji as approver In-Reply-To: <541BE9F7.8090305@digia.com> References: <541BE9F7.8090305@digia.com> Message-ID: <13704458.CxG3G0CXcC@titan> On Friday 19 September 2014 10:31:51 Friedemann Kleint wrote: > Hi, > > I'd like to nominate Louai Al-Khanji as approver inthe Qt Project: +1 Cheers, Sean -- 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 raul at metsma.ee Fri Sep 19 13:15:09 2014 From: raul at metsma.ee (Raul Metsma) Date: Fri, 19 Sep 2014 14:15:09 +0300 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> Message-ID: <47FF2A53-55D0-44A0-9351-ADF862DECBAB@metsma.ee> Another issue with qt binaries cat ~/Qt/5.3/clang_64/lib/QtPrintSupport.framework/Contents/Info.plist CFBundlePackageType FMWK CFBundleShortVersionString 5.3 CFBundleGetInfoString Created by Qt/QMake CFBundleSignature ???? CFBundleExecutable QtPrintSupport_debug NOTE Please, do NOT change this file -- It was generated by Qt/QMake. codesigning complaining on this _debug reference CFBundleExecutable QtPrintSupport_debug Affected Qt 5.3.1 and 5.3.2, installed with online installer Raul On 19 Sep 2014, at 13:48, Robert Knight wrote: > For anyone who is using CMake to build DMG packages using Qt, we have > a script to fix up the layout of Qt repos prior to building at > https://github.com/Mendeley/Mac-OS-X-Bundle-Utilities > > This was targeted at Qt 4 but the Qt 5 bundles have the same structure > and issues as far as I see. > > On 19 September 2014 10:28, Sorvig Morten wrote: >> >>> On 18 Sep 2014, at 22:07, Adam Strzelecki wrote: >>> >>>> Reported already 24/Jan/14 QTBUG-36429 >>> >>> FYI more recent and prioritized bug report is QTBUG-38511 >>> >>> I think it deserves a lot of attention now since 10.9.5 is live. >> >> This will indeed receive attention in the coming days. There are already some patches attached to the QTBUGs. I’ll post back here once we have a complete patch set ready. Target branches are Qt 5.3 and Qt 4.8. >> >> Morten >> _______________________________________________ >> 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 bog_dan_ro at yahoo.com Fri Sep 19 14:37:42 2014 From: bog_dan_ro at yahoo.com (BogDan) Date: Fri, 19 Sep 2014 05:37:42 -0700 Subject: [Development] [QML] Singletons are deleted before the other objects Message-ID: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> Hello folks, Singletons registered using qmlRegisterSingletonType, are deleted *before* the other active objects. I consider it to be wrong because some of the active objects may still need to access the singletons in their destructor ... IMHO singletons should be the very last objects deleted (also in the reverse order). Is there any reason why they are deleted before the other active objects? Or this is just a bug? Cheers, BogDan. From Laszlo.Agocs at digia.com Fri Sep 19 15:48:23 2014 From: Laszlo.Agocs at digia.com (Agocs Laszlo) Date: Fri, 19 Sep 2014 13:48:23 +0000 Subject: [Development] Nominating Louai Al-Khanji as approver In-Reply-To: <13704458.CxG3G0CXcC@titan> References: <541BE9F7.8090305@digia.com>,<13704458.CxG3G0CXcC@titan> Message-ID: +1 Cheers, Laszlo ________________________________ From: Sean Harmer Sent: ‎9/‎19/‎2014 12:58 PM To: development at qt-project.org Subject: Re: [Development] Nominating Louai Al-Khanji as approver On Friday 19 September 2014 10:31:51 Friedemann Kleint wrote: > Hi, > > I'd like to nominate Louai Al-Khanji as approver inthe Qt Project: +1 Cheers, Sean -- 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 _______________________________________________ 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 szehowe.koh at gmail.com Fri Sep 19 15:53:32 2014 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Fri, 19 Sep 2014 21:53:32 +0800 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <541A26B8.7@gmail.com> References: <80C4B40F-40CE-4169-95A8-F239FE3A7C11@mareimbrium.org> <541A26B8.7@gmail.com> Message-ID: I enjoy the new look and the fluidity of the site. It conveys a sense of what developers can achieve graphically with the technology available in the Qt framework. One thing I feel that could be improved is http://www.qt.io/product/ -- it gives me the impression that Qt is a commercial-only product (the starting price is 20€/month). It doesn't even hint that a community version is available. On 18 September 2014 08:26, Lorn Potter wrote: > On 18/09/14 05:09, Kuba Ober wrote: >> One of the reasons I loath to recommend to the management to go back to paying for Qt licenses is that we’d have been sponsoring what amounts to 2 or 3 major rebrandings and “revamps”, and it seems like throwing money down the drain. As a user, I want good code. The website, as far as I’m concerned, can be text-only. Any money that the owners of Qt spend for anything besides the code is, to us as the end users,*our* money burned for frivolities. > > speak for yourself. > > I think it looks quite nice. They've done a good job making it look > appealing and useful. > > While text only web site might be ok with you, managers or directors > scoping out a dev framework for the first time might be wary about > paying for something with a web site from 1980's > > Quality of code also runs to the web servers. I am a bit wary about dev > apps/frameworks/tools whose web site looks like gak. +1 If you are already world-renowned, you could get away with a text only site (like Warren Buffett: http://www.berkshirehathaway.com/ ). However, if you are not yet world-renowned, taking this route would do no favours for your business -- it's akin to meeting potential corporate clients while dressed in an old T-shirt, shorts, and slippers. It's not frivolities; it's an investment. Regards, Sze-Howe From ono at java.pl Fri Sep 19 17:27:30 2014 From: ono at java.pl (Adam Strzelecki) Date: Fri, 19 Sep 2014 17:27:30 +0200 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: <47FF2A53-55D0-44A0-9351-ADF862DECBAB@metsma.ee> References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> <47FF2A53-55D0-44A0-9351-ADF862DECBAB@metsma.ee> Message-ID: <44A7E00B-7530-4273-9553-8D492A78A7A2@java.pl> > codesigning complaining on this _debug reference > CFBundleExecutable > QtPrintSupport_debug Shouldn't be debug another version within multiversioned bundle? E.g.: QtCore -> Versions/Current/QtCore Resources -> Versions/Current/Resources Versions/ Current -> 5 5/ QtCore Resources/ Info.plist 5-debug/ QtCore Resources/ Info.plist This would solve the solving issue. --Adam From jake.petroules at petroules.com Fri Sep 19 17:34:55 2014 From: jake.petroules at petroules.com (Jake Petroules) Date: Fri, 19 Sep 2014 11:34:55 -0400 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: <44A7E00B-7530-4273-9553-8D492A78A7A2@java.pl> References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> <47FF2A53-55D0-44A0-9351-ADF862DECBAB@metsma.ee> <44A7E00B-7530-4273-9553-8D492A78A7A2@java.pl> Message-ID: <7A276FB1-7B3F-4465-8543-73DBBFAA8521@petroules.com> On 2014-09-19, at 11:27 AM, Adam Strzelecki wrote: >> codesigning complaining on this _debug reference >> CFBundleExecutable >> QtPrintSupport_debug > > Shouldn't be debug another version within multiversioned bundle? E.g.: > > QtCore -> Versions/Current/QtCore > Resources -> Versions/Current/Resources > Versions/ > Current -> 5 > 5/ > QtCore > Resources/ > Info.plist > 5-debug/ > QtCore > Resources/ > Info.plist > > This would solve the solving issue. > > --Adam > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development No. _debug should simply never appear anywhere in the Info.plist. The bundle should be structured like so: QtCore.framework/ QtCore -> Versions/Current/QtCore QtCore_debug -> Versions/Current/QtCore_debug Resources -> Versions/Current/Resources Versions/ Current -> 5 5/ QtCore QtCore_debug _CodeSignature/ CodeResources Resources/ Info.plist ... And the Info.plist should *always* set CFBundleExecutable to QtCore. To use the debug version you set the DYLD_IMAGE_SUFFIX environment variable to _debug prior to execution. As far as I'm aware, we already do this correctly (aside from Info.plist being in the wrong place), and the only reason _debug is showing up in an Info.plist somewhere is probably due to some simple typo or omission. -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation From ono at java.pl Fri Sep 19 17:36:54 2014 From: ono at java.pl (Adam Strzelecki) Date: Fri, 19 Sep 2014 17:36:54 +0200 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: <7A276FB1-7B3F-4465-8543-73DBBFAA8521@petroules.com> References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> <47FF2A53-55D0-44A0-9351-ADF862DECBAB@metsma.ee> <44A7E00B-7530-4273-9553-8D492A78A7A2@java.pl> <7A276FB1-7B3F-4465-8543-73DBBFAA8521@petroules.com> Message-ID: <2C83876E-FEA5-483E-8DD6-D28136162396@java.pl> > As far as I'm aware, we already do this correctly (aside from Info.plist being in the wrong place), and the only reason _debug is showing up in an Info.plist somewhere is probably due to some simple typo or omission. You're right, thanks. --Adam From jeremy.k.list at gmail.com Fri Sep 19 22:48:37 2014 From: jeremy.k.list at gmail.com (Jeremy) Date: Fri, 19 Sep 2014 13:48:37 -0700 Subject: [Development] Requesting removal of qtjsondb In-Reply-To: <3116877.SbL9j03dDi@tjmaciei-mobl4> References: <54194EF6.4080608@digia.com> <3116877.SbL9j03dDi@tjmaciei-mobl4> Message-ID: <2CC6C86E-E201-4BB8-A90E-FAC12A0A4357@gmail.com> On 5September2014, at 21:57, Thiago Macieira wrote: > On Thursday 18 September 2014 21:46:27 Jeremy wrote: >> I don’t see an issue with removing it from Qt 5. Is there a general plan for >> modules that exit from production-ready status? > > Modules that exit from production-ready status need to go through the > deprecation ladder: first Done, then Deprecated (with possibly a replacement), > and then finally Removed. The package should be made to compile with future > versions of Qt. That's what we did for Qt Script Classic, Qt Assistant ADP, > QHttp, QFtp, etc. > > However, let's be clear: QtJsondb never achieved "production-ready" status. It > never left "pre-alpha" state and was never released. There's no one using it. > Simply remove the link from qt5.git and leave the repo to rot. > It’s the repo hosted on qt-project.org and clones such as qt.gitorious.org that I’m wondering about. Leaving qtjsondb at its current URL is not what I would expect for something that is not part of the Qt 5 bundle. Do we start a qt-abandoned tree? qtplayground is too optimistic. From robin+qt at viroteck.net Fri Sep 19 22:57:02 2014 From: robin+qt at viroteck.net (Robin Burchell) Date: Fri, 19 Sep 2014 22:57:02 +0200 Subject: [Development] Requesting removal of qtjsondb In-Reply-To: <2CC6C86E-E201-4BB8-A90E-FAC12A0A4357@gmail.com> References: <54194EF6.4080608@digia.com> <3116877.SbL9j03dDi@tjmaciei-mobl4> <2CC6C86E-E201-4BB8-A90E-FAC12A0A4357@gmail.com> Message-ID: On Fri, Sep 19, 2014 at 10:48 PM, Jeremy wrote: > It’s the repo hosted on qt-project.org and clones such as qt.gitorious.org that I’m wondering about. Leaving qtjsondb at its current URL is not what I would expect for something that is not part of the Qt 5 bundle. Do we start a qt-abandoned tree? qtplayground is too optimistic. We have plenty of other code in similar circumstances (qtwayland pre-5.4, qtpim, ...) that aren't released but may be Some Day (or might not, if nobody cares about them). I don't think the URL really says all that much about something necessarily, and moving things around is a hassle (technically and socially) I'd just leave it From sirspudd at gmail.com Sat Sep 20 01:39:58 2014 From: sirspudd at gmail.com (Donald Carr) Date: Fri, 19 Sep 2014 16:39:58 -0700 Subject: [Development] Requesting removal of qtjsondb In-Reply-To: References: <54194EF6.4080608@digia.com> <3116877.SbL9j03dDi@tjmaciei-mobl4> <2CC6C86E-E201-4BB8-A90E-FAC12A0A4357@gmail.com> Message-ID: RIP qtjsondb, takk for ingenting On Sep 19, 2014 1:58 PM, "Robin Burchell" wrote: > On Fri, Sep 19, 2014 at 10:48 PM, Jeremy wrote: > > It’s the repo hosted on qt-project.org and clones such as > qt.gitorious.org that I’m wondering about. Leaving qtjsondb at its > current URL is not what I would expect for something that is not part of > the Qt 5 bundle. Do we start a qt-abandoned tree? qtplayground is too > optimistic. > > We have plenty of other code in similar circumstances (qtwayland > pre-5.4, qtpim, ...) that aren't released but may be Some Day (or > might not, if nobody cares about them). > > I don't think the URL really says all that much about something > necessarily, and moving things around is a hassle (technically and > socially) > > I'd just leave it > _______________________________________________ > 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 Sun Sep 21 19:08:09 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 21 Sep 2014 10:08:09 -0700 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: References: <6943D077-C403-446D-91CA-9C4DD9B7DDBB@familiesomers.nl> Message-ID: <2077330.JPi0Jq9zTu@tjmaciei-mobl4> On Wednesday 17 September 2014 20:19:27 Knoll Lars wrote: > It's supposed to mean that you can modify Qt's source code without having > to release the changes. I agree that the text is not clear enough and it > should be somehow changed. Could you ask that be updated? Or use two different ways to indicate it. Put a yellow checkmark in the Open Source column, or a green with asterisk, and explain that you do have the right to the source code but you must make it available along with any changes you make. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Sep 21 20:11:44 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 21 Sep 2014 11:11:44 -0700 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <2077330.JPi0Jq9zTu@tjmaciei-mobl4> References: <2077330.JPi0Jq9zTu@tjmaciei-mobl4> Message-ID: <1735673.XjNiPhPNRJ@tjmaciei-mobl4> On Sunday 21 September 2014 10:08:09 Thiago Macieira wrote: > On Wednesday 17 September 2014 20:19:27 Knoll Lars wrote: > > It's supposed to mean that you can modify Qt's source code without having > > to release the changes. I agree that the text is not clear enough and it > > should be somehow changed. > > Could you ask that be updated? > > Or use two different ways to indicate it. Put a yellow checkmark in the Open > Source column, or a green with asterisk, and explain that you do have the > right to the source code but you must make it available along with any > changes you make. Another idea is to split it in two, keeping "rights to source code" green and add another line for "may keep Qt modifications private" in a new line. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chris.adams at qinetic.com.au Mon Sep 22 05:45:36 2014 From: chris.adams at qinetic.com.au (Chris Adams) Date: Mon, 22 Sep 2014 13:45:36 +1000 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> Message-ID: Hi, On Fri, Sep 19, 2014 at 10:37 PM, BogDan wrote: > Hello folks, > > Singletons registered using qmlRegisterSingletonType, are deleted > *before* > the other active objects. I consider it to be wrong because some of the > active > objects may still need to access the singletons in their destructor ... > > IMHO singletons should be the very last objects deleted (also in the > reverse > order). > I tend to agree that they should be deleted last. Enforcing deletion in the reverse order to how they were registered might impose some slight performance penalty at instantiation time, however, depending on how the deletion order is determined at cleanup time, since they are instantiated on demand (and hence possibly out-of-order). > > Is there any reason why they are deleted before the other active objects? > Or this is just a bug? > I don't believe that there is any particular reason for deleting them prior to other active objects, but perhaps Simon or Lars can correct me on this point. Nonetheless, I don't think that the current behaviour is a bug, per-se, as the destruction order was never documented or guaranteed, as far as I know. Cheers, Chris. > > Cheers, > BogDan. > > _______________________________________________ > 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 Mon Sep 22 08:27:36 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Mon, 22 Sep 2014 06:27:36 +0000 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> Message-ID: I tend to agree. Sounds like a bug to me. Cheers, Lars On 19/09/14 14:37, "BogDan" wrote: >Hello folks, > > Singletons registered using qmlRegisterSingletonType, are deleted >*before* >the other active objects. I consider it to be wrong because some of the >active >objects may still need to access the singletons in their destructor ... > >IMHO singletons should be the very last objects deleted (also in the >reverse >order). > >Is there any reason why they are deleted before the other active objects? >Or this is just a bug? > >Cheers, >BogDan. > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From Lars.Knoll at digia.com Mon Sep 22 08:33:08 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Mon, 22 Sep 2014 06:33:08 +0000 Subject: [Development] Requesting removal of qtjsondb In-Reply-To: References: <54194EF6.4080608@digia.com> <3116877.SbL9j03dDi@tjmaciei-mobl4> <2CC6C86E-E201-4BB8-A90E-FAC12A0A4357@gmail.com> Message-ID: Yes, that repo is dead, and I don’t see it coming alive again. Let’s remove it from qt5.git, mark the repo with an abandoned comment and maybe commit something into it’s top level directory stating the same. As far as I remember it’s not too much work to move it to a different location in gerrit. If that’s the case, I'd move it to some abandoned/dead tree. Cheers, Lars On 19/09/14 22:57, "Robin Burchell" wrote: >On Fri, Sep 19, 2014 at 10:48 PM, Jeremy wrote: >> It’s the repo hosted on qt-project.org and clones such as >>qt.gitorious.org that I’m wondering about. Leaving qtjsondb at its >>current URL is not what I would expect for something that is not part of >>the Qt 5 bundle. Do we start a qt-abandoned tree? qtplayground is too >>optimistic. > >We have plenty of other code in similar circumstances (qtwayland >pre-5.4, qtpim, ...) that aren't released but may be Some Day (or >might not, if nobody cares about them). > >I don't think the URL really says all that much about something >necessarily, and moving things around is a hassle (technically and >socially) > >I'd just leave it >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at digia.com Mon Sep 22 08:33:39 2014 From: Simon.Hausmann at digia.com (Hausmann Simon) Date: Mon, 22 Sep 2014 06:33:39 +0000 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com>, Message-ID: <20140922063338.5431432.80402.2080@digia.com> Hi, In gener‎al I agree with Chris. However I'm a little puzzled that this is happening. If you take a look at the QQmlEngine destructor you can see that singletons are deleted last. So I'm wondering what is happening in your app Bogdan. Can you create a minimal test case? Thanks, Simon Fra: Chris Adams Sendt: 05:45 mandag 22. september 2014 Til: BogDan Kopi: Qt Development Group Emne: Re: [Development] [QML] Singletons are deleted before the other objects Hi, On Fri, Sep 19, 2014 at 10:37 PM, BogDan > wrote: Hello folks, Singletons registered using qmlRegisterSingletonType, are deleted *before* the other active objects. I consider it to be wrong because some of the active objects may still need to access the singletons in their destructor ... IMHO singletons should be the very last objects deleted (also in the reverse order). I tend to agree that they should be deleted last. Enforcing deletion in the reverse order to how they were registered might impose some slight performance penalty at instantiation time, however, depending on how the deletion order is determined at cleanup time, since they are instantiated on demand (and hence possibly out-of-order). Is there any reason why they are deleted before the other active objects? Or this is just a bug? I don't believe that there is any particular reason for deleting them prior to other active objects, but perhaps Simon or Lars can correct me on this point. Nonetheless, I don't think that the current behaviour is a bug, per-se, as the destruction order was never documented or guaranteed, as far as I know. Cheers, Chris. Cheers, BogDan. _______________________________________________ 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 Shawn.Rutledge at digia.com Mon Sep 22 10:05:15 2014 From: Shawn.Rutledge at digia.com (Rutledge Shawn) Date: Mon, 22 Sep 2014 08:05:15 +0000 Subject: [Development] Nominating Venugopal Shivashankar and Nico Vertriest as approvers In-Reply-To: References: Message-ID: <6B9AE133-428B-4E95-9AF2-6EDF4F107A05@digia.com> Den 16 Sep 2014 kl. 9:31 AM skrev Reinio Topi: I'd like to nominate Venugopal Shivashankar and Nico Vertriest as approvers in the Qt Project. They are both documentation engineers and integral part of the of Qt documentation team. Venugopal Shivashankar: https://codereview.qt-project.org/#/q/owner:veshivas,n,z https://codereview.qt-project.org/#/q/reviewer:veshivas,n,z Nico Vertriest: https://codereview.qt-project.org/#/q/owner:vertries,n,z https://codereview.qt-project.org/#/q/reviewer:vertries,n,z Both Venu and Nico have been working on Qt for a long time (pre-Qt 5.0) already, contributing numerous improvements to Qt documentation. Many people rely on them for documentation and language reviews, and having them as approvers would speed up documentation work and ease the review-burden on other team members. -Topi +2 for both -------------- next part -------------- An HTML attachment was scrubbed... URL: From bog_dan_ro at yahoo.com Mon Sep 22 10:19:17 2014 From: bog_dan_ro at yahoo.com (BogDan) Date: Mon, 22 Sep 2014 01:19:17 -0700 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: <20140922063338.5431432.80402.2080@digia.com> References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com>, <20140922063338.5431432.80402.2080@digia.com> Message-ID: <1411373957.78525.YahooMailNeo@web126101.mail.ne1.yahoo.com> Hi Simon, I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 branch (sha1 f9ee33f96), is a little bit old, but I bet nobody fixed it. The same problem is in previous releases. So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 The other active objects are deleted in MemoryManager::sweep(*true*) which is called by MemoryManager::~MemoryManager() which is called by ExecutionEngine::~ExecutionEngine() which is called by QV8Engine::~QV8Engine() which is called by QJSEngine::~QJSEngine() which is called *after* QQmlEngine::~QQmlEngine() Check the call-stack: 0 MyObject::~MyObject myobject.cpp 44 0x7fffd141eb4b 1 MyObject::~MyObject myobject.cpp 46 0x7fffd141ec8a 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter qv4qobjectwrapper.cpp 1018 0x7ffff5f79ee1 f9ee33f96f9ee33f96 3 (anonymous namespace)::QObjectDeleter::~QObjectDeleter qv4qobjectwrapper.cpp 1021 0x7ffff5f79f2e 4 QV4::MemoryManager::sweep qv4mm.cpp 377 0x7ffff5efd080 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x7ffff5efda18 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 0x7ffff5ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 0x7ffff606b7f2 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7ffff606b87e 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x7ffff5e64b1e 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x7ffff5fb0b5d 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x7ffff5fb0b8c 12 QObjectPrivate::deleteChildren qobject.cpp 1943 0x7ffff599efd0 13 QObject::~QObject qobject.cpp 1034 0x7ffff599d760 14 QWindow::~QWindow qwindow.cpp 210 0x7ffff63f5bdc 15 QQuickWindow::~QQuickWindow qquickwindow.cpp 1099 0x7ffff6bc0353 16 QQuickView::~QQuickView qquickview.cpp 220 0x7ffff6c9fe35 17 main main.cpp 12 0x4021fb IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved after/in MemoryManager::~MemoryManager ... Cheers, BogDan. ________________________________ From: Hausmann Simon To: Chris Adams ; BogDan Cc: Qt Development Group Sent: Monday, September 22, 2014 9:33 AM Subject: SV: [Development] [QML] Singletons are deleted before the other objects Hi, In gener‎al I agree with Chris. However I'm a little puzzled that this is happening. If you take a look at the QQmlEngine destructor you can see that singletons are deleted last. So I'm wondering what is happening in your app Bogdan. Can you create a minimal test case? Thanks, Simon Fra: Chris Adams Sendt: 05:45 mandag 22. september 2014 Til: BogDan Kopi: Qt Development Group Emne: Re: [Development] [QML] Singletons are deleted before the other objects Hi, On Fri, Sep 19, 2014 at 10:37 PM, BogDan wrote: Hello folks, > > Singletons registered using qmlRegisterSingletonType, are deleted *before* >the other active objects. I consider it to be wrong because some of the active >objects may still need to access the singletons in their destructor ... > >IMHO singletons should be the very last objects deleted (also in the reverse >order). > I tend to agree that they should be deleted last. Enforcing deletion in the reverse order to how they were registered might impose some slight performance penalty at instantiation time, however, depending on how the deletion order is determined at cleanup time, since they are instantiated on demand (and hence possibly out-of-order). >Is there any reason why they are deleted before the other active objects? >Or this is just a bug? > I don't believe that there is any particular reason for deleting them prior to other active objects, but perhaps Simon or Lars can correct me on this point. Nonetheless, I don't think that the current behaviour is a bug, per-se, as the destruction order was never documented or guaranteed, as far as I know. Cheers, Chris. >Cheers, >BogDan. > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development > From simon.hausmann at digia.com Mon Sep 22 10:26:08 2014 From: simon.hausmann at digia.com (Simon Hausmann) Date: Mon, 22 Sep 2014 10:26:08 +0200 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: <1411373957.78525.YahooMailNeo@web126101.mail.ne1.yahoo.com> References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> <20140922063338.5431432.80402.2080@digia.com> <1411373957.78525.YahooMailNeo@web126101.mail.ne1.yahoo.com> Message-ID: <4797183.QimFkKXsFi@rhea> On Monday 22. September 2014 01.19.17 BogDan wrote: > Hi Simon, > > I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 > branch (sha1 f9ee33f96), is a little bit old, but I bet nobody > fixed it. The same problem is in previous releases. > > So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 > The other active objects are deleted in MemoryManager::sweep(*true*) > which is called by MemoryManager::~MemoryManager() > which is called by ExecutionEngine::~ExecutionEngine() > which is called by QV8Engine::~QV8Engine() > which is called by QJSEngine::~QJSEngine() > which is called *after* QQmlEngine::~QQmlEngine() > > Check the call-stack: > 0 MyObject::~MyObject myobject.cpp 44 0x7fffd141eb4b > 1 MyObject::~MyObject myobject.cpp 46 0x7fffd141ec8a > 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter > qv4qobjectwrapper.cpp 1018 0x7ffff5f79ee1 f9ee33f96f9ee33f96 3 > (anonymous namespace)::QObjectDeleter::~QObjectDeleter > qv4qobjectwrapper.cpp 1021 0x7ffff5f79f2e 4 > QV4::MemoryManager::sweep qv4mm.cpp 377 0x7ffff5efd080 > 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x7ffff5efda18 > 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 > 0x7ffff5ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 > 0x7ffff606b7f2 > 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7ffff606b87e > 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x7ffff5e64b1e > 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x7ffff5fb0b5d > 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x7ffff5fb0b8c > 12 QObjectPrivate::deleteChildren qobject.cpp 1943 0x7ffff599efd0 > 13 QObject::~QObject qobject.cpp 1034 0x7ffff599d760 > 14 QWindow::~QWindow qwindow.cpp 210 0x7ffff63f5bdc > 15 QQuickWindow::~QQuickWindow qquickwindow.cpp 1099 0x7ffff6bc0353 > 16 QQuickView::~QQuickView qquickview.cpp 220 0x7ffff6c9fe35 > 17 main main.cpp 12 0x4021fb > > IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved > after/in MemoryManager::~MemoryManager ... Ahh, so what you're talking about are the _JavaScript_ wrappers for the singletons, not the singleton objects themselves. That explains the confusion. Yes, due to the inheritance the final garbage collection runs as the very last step - and it has to, conceptually. I'm wondering: What code do you have running at that point that gets still called? Is it code in C++ destructors? Simon From bog_dan_ro at yahoo.com Mon Sep 22 10:33:14 2014 From: bog_dan_ro at yahoo.com (BogDan) Date: Mon, 22 Sep 2014 01:33:14 -0700 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: <4797183.QimFkKXsFi@rhea> References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> <20140922063338.5431432.80402.2080@digia.com> <1411373957.78525.YahooMailNeo@web126101.mail.ne1.yahoo.com> <4797183.QimFkKXsFi@rhea> Message-ID: <1411374794.47139.YahooMailNeo@web126103.mail.ne1.yahoo.com> On Monday 22. September 2014 01.19.17 BogDan wrote: > Hi Simon, > > I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 > branch (sha1 f9ee33f96), is a little bit old, but I bet nobody > fixed it. The same problem is in previous releases. > > So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 > The other active objects are deleted in MemoryManager::sweep(*true*) > which is called by MemoryManager::~MemoryManager() > which is called by ExecutionEngine::~ExecutionEngine() > which is called by QV8Engine::~QV8Engine() > which is called by QJSEngine::~QJSEngine() > which is called *after* QQmlEngine::~QQmlEngine() > > Check the call-stack: > 0 MyObject::~MyObject myobject.cpp 44 0x7fffd141eb4b > 1 MyObject::~MyObject myobject.cpp 46 0x7fffd141ec8a > 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter > qv4qobjectwrapper.cpp 1018 0x7ffff5f79ee1 f9ee33f96f9ee33f96 3 > (anonymous namespace)::QObjectDeleter::~QObjectDeleter > qv4qobjectwrapper.cpp 1021 0x7ffff5f79f2e 4 > QV4::MemoryManager::sweep qv4mm.cpp 377 0x7ffff5efd080 > 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x7ffff5efda18 > 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 > 0x7ffff5ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 > 0x7ffff606b7f2 > 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7ffff606b87e > 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x7ffff5e64b1e > 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x7ffff5fb0b5d > 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x7ffff5fb0b8c > 12 QObjectPrivate::deleteChildren qobject.cpp 1943 0x7ffff599efd0 > 13 QObject::~QObject qobject.cpp 1034 0x7ffff599d760 > 14 QWindow::~QWindow qwindow.cpp 210 0x7ffff63f5bdc > 15 QQuickWindow::~QQuickWindow qquickwindow.cpp 1099 0x7ffff6bc0353 > 16 QQuickView::~QQuickView qquickview.cpp 220 0x7ffff6c9fe35 > 17 main main.cpp 12 0x4021fb > > IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved > after/in MemoryManager::~MemoryManager ... Ahh, so what you're talking about are the _JavaScript_ wrappers for the singletons, not the singleton objects themselves. That explains the confusion. Yes, due to the inheritance the final garbage collection runs as the very last step - and it has to, conceptually. I'm wondering: What code do you have running at that point that gets still called? Is it code in C++ destructors? Yes, the code from their destructors needs the singletons objects which are not available anymore. Cheers, BogDan. From simon.hausmann at digia.com Mon Sep 22 10:56:58 2014 From: simon.hausmann at digia.com (Simon Hausmann) Date: Mon, 22 Sep 2014 10:56:58 +0200 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: <1411374794.47139.YahooMailNeo@web126103.mail.ne1.yahoo.com> References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> <4797183.QimFkKXsFi@rhea> <1411374794.47139.YahooMailNeo@web126103.mail.ne1.yahoo.com> Message-ID: <1691425.eGisNBzUG3@rhea> On Monday 22. September 2014 01.33.14 BogDan wrote: > On Monday 22. September 2014 01.19.17 BogDan wrote: > > Hi Simon, > > > > I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 > > branch (sha1 f9ee33f96), is a little bit old, but I bet nobody > > fixed it. The same problem is in previous releases. > > > > So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 > > The other active objects are deleted in MemoryManager::sweep(*true*) > > which is called by MemoryManager::~MemoryManager() > > which is called by ExecutionEngine::~ExecutionEngine() > > which is called by QV8Engine::~QV8Engine() > > which is called by QJSEngine::~QJSEngine() > > which is called *after* QQmlEngine::~QQmlEngine() > > > > Check the call-stack: > > 0 MyObject::~MyObject myobject.cpp 44 0x7fffd141eb4b > > 1 MyObject::~MyObject myobject.cpp 46 0x7fffd141ec8a > > 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > qv4qobjectwrapper.cpp 1018 0x7ffff5f79ee1 f9ee33f96f9ee33f96 3 > > (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > qv4qobjectwrapper.cpp 1021 0x7ffff5f79f2e 4 > > QV4::MemoryManager::sweep qv4mm.cpp 377 0x7ffff5efd080 > > 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x7ffff5efda18 > > 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 > > 0x7ffff5ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 > > 0x7ffff606b7f2 > > 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7ffff606b87e > > 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x7ffff5e64b1e > > 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x7ffff5fb0b5d > > 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x7ffff5fb0b8c > > 12 QObjectPrivate::deleteChildren qobject.cpp 1943 0x7ffff599efd0 > > 13 QObject::~QObject qobject.cpp 1034 0x7ffff599d760 > > 14 QWindow::~QWindow qwindow.cpp 210 0x7ffff63f5bdc > > 15 QQuickWindow::~QQuickWindow qquickwindow.cpp 1099 0x7ffff6bc0353 > > 16 QQuickView::~QQuickView qquickview.cpp 220 0x7ffff6c9fe35 > > 17 main main.cpp 12 0x4021fb > > > > IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved > > after/in MemoryManager::~MemoryManager ... > > Ahh, so what you're talking about are the _JavaScript_ wrappers for the > singletons, not the singleton objects themselves. That explains the > confusion. > > Yes, due to the inheritance the final garbage collection runs as the very > last step - and it has to, conceptually. I'm wondering: What code do you > have running at that point that gets still called? Is it code in C++ > destructors? > > > > > > > Yes, the code from their destructors needs the singletons objects which are > not available anymore. When are those destructors called? We need a little bit more information here, because it isn't obvious how to solve this. There's naturally a pool of objects around that haven't been garbage collected. On engine shutdown the garbage collector sweeps them all, and there's naturally no way to define an order of destruction if you think of such an environment. Simon From bog_dan_ro at yahoo.com Mon Sep 22 11:28:06 2014 From: bog_dan_ro at yahoo.com (BogDan) Date: Mon, 22 Sep 2014 02:28:06 -0700 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: <1691425.eGisNBzUG3@rhea> References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> <4797183.QimFkKXsFi@rhea> <1411374794.47139.YahooMailNeo@web126103.mail.ne1.yahoo.com> <1691425.eGisNBzUG3@rhea> Message-ID: <1411378086.34723.YahooMailNeo@web126105.mail.ne1.yahoo.com> ----- Original Message ----- From: Simon Hausmann To: BogDan Cc: Chris Adams ; Qt Development Group Sent: Monday, September 22, 2014 11:56 AM Subject: Re: SV: [Development] [QML] Singletons are deleted before the other objects On Monday 22. September 2014 01.33.14 BogDan wrote: > On Monday 22. September 2014 01.19.17 BogDan wrote: > > Hi Simon, > > > > I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 > > branch (sha1 f9ee33f96), is a little bit old, but I bet nobody > > fixed it. The same problem is in previous releases. > > > > So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 > > The other active objects are deleted in MemoryManager::sweep(*true*) > > which is called by MemoryManager::~MemoryManager() > > which is called by ExecutionEngine::~ExecutionEngine() > > which is called by QV8Engine::~QV8Engine() > > which is called by QJSEngine::~QJSEngine() > > which is called *after* QQmlEngine::~QQmlEngine() > > > > Check the call-stack: > > 0 MyObject::~MyObject myobject.cpp 44 0x7fffd141eb4b > > 1 MyObject::~MyObject myobject.cpp 46 0x7fffd141ec8a > > 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > qv4qobjectwrapper.cpp 1018 0x7ffff5f79ee1 f9ee33f96f9ee33f96 3 > > (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > qv4qobjectwrapper.cpp 1021 0x7ffff5f79f2e 4 > > QV4::MemoryManager::sweep qv4mm.cpp 377 0x7ffff5efd080 > > 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x7ffff5efda18 > > 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 > > 0x7ffff5ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 > > 0x7ffff606b7f2 > > 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7ffff606b87e > > 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x7ffff5e64b1e > > 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x7ffff5fb0b5d > > 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x7ffff5fb0b8c > > 12 QObjectPrivate::deleteChildren qobject.cpp 1943 0x7ffff599efd0 > > 13 QObject::~QObject qobject.cpp 1034 0x7ffff599d760 > > 14 QWindow::~QWindow qwindow.cpp 210 0x7ffff63f5bdc > > 15 QQuickWindow::~QQuickWindow qquickwindow.cpp 1099 0x7ffff6bc0353 > > 16 QQuickView::~QQuickView qquickview.cpp 220 0x7ffff6c9fe35 > > 17 main main.cpp 12 0x4021fb > > > > IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved > > after/in MemoryManager::~MemoryManager ... > > Ahh, so what you're talking about are the _JavaScript_ wrappers for the > singletons, not the singleton objects themselves. That explains the > confusion. > > Yes, due to the inheritance the final garbage collection runs as the very > last step - and it has to, conceptually. I'm wondering: What code do you > have running at that point that gets still called? Is it code in C++ > destructors? > > > > > > > Yes, the code from their destructors needs the singletons objects which are > not available anymore. When are those destructors called? We need a little bit more information here, because it isn't obvious how to solve this. There's naturally a pool of objects around that haven't been garbage collected. On engine shutdown the garbage collector sweeps them all, and there's naturally no way to define an order of destruction if you think of such an environment. I know that there is a pool of active objects, what I think is wrong is to delete the register singletons before you delete these objects. The active objects destructors are called by MemoryManager::sweep. These objects register themselves in the singleton object when they are created and they must unregister themselves in the destructor when they are deleted. But as you seen the singletons are deleted before, so there is no way to properly unregister themselves! This is why I believe that the singletons must be the very last objects that are deleted (just like in any other languages). So, my proposal is to move the singletons deletion from QmlEngine::~QQmlEngine():910 to another place which is called after MemoryManager::sweep(*true*) is doing its job. I'd like to mention one more thing, the singletons and the other objects are register in a standalone plugin. Please let me know if you need more info. Cheers, BogDan. From Morten.Sorvig at digia.com Mon Sep 22 11:56:47 2014 From: Morten.Sorvig at digia.com (Sorvig Morten) Date: Mon, 22 Sep 2014 09:56:47 +0000 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: <7A276FB1-7B3F-4465-8543-73DBBFAA8521@petroules.com> References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> <47FF2A53-55D0-44A0-9351-ADF862DECBAB@metsma.ee> <44A7E00B-7530-4273-9553-8D492A78A7A2@java.pl> <7A276FB1-7B3F-4465-8543-73DBBFAA8521@petroules.com> Message-ID: <8C5854CE-DEEE-4DBB-BFB1-F4F62DB33E14@digia.com> > > And the Info.plist should *always* set CFBundleExecutable to QtCore. To use the debug version you set the DYLD_IMAGE_SUFFIX environment variable to _debug prior to execution. A minor case: What would you do for debug-only builds? > > As far as I'm aware, we already do this correctly (aside from Info.plist being in the wrong place), and the only reason _debug is showing up in an Info.plist somewhere is probably due to some simple typo or omission. Looks like it comes from the @EXECUTABLE@ -> var(“QMAKE_ORIG_TARGET”) substitution in unixmake2.cpp. I think the release build is racing the debug build, causing “_debug" to appear in some frameworks. So for a release+debug build we have two options: 1) Use the release Info.plist. (the current suggested approach) 2) Make sure they are identical. Morten From Morten.Sorvig at digia.com Mon Sep 22 12:03:54 2014 From: Morten.Sorvig at digia.com (Sorvig Morten) Date: Mon, 22 Sep 2014 10:03:54 +0000 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: <277B9377-3A29-4180-8497-53B977A82A65@digia.com> References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> Message-ID: > On 19 Sep 2014, at 11:28, Sorvig Morten wrote: > > This will indeed receive attention in the coming days. There are already some patches attached to the QTBUGs. I’ll post back here once we have a complete patch set ready. Target branches are Qt 5.3 and Qt 4.8. I’m using QTBUG-32896 as a metabug to track the effort. Here’s the current patch set (5.3): qmake - framework bundle hierarchy (QTBUG-32895): https://codereview.qt-project.org/95454 qmake - “_debug" in CFBundleExecutable (QTBUG-32894): https://codereview.qt-project.org/95455 qmake - add CFBundleVersion: https://codereview.qt-project.org/95456 macdeployqt - “Current” version symlinks: https://codereview.qt-project.org/#/c/95442/ Are these patches sufficient? If not, what’s missing? Morten From ono at java.pl Mon Sep 22 12:12:57 2014 From: ono at java.pl (Adam Strzelecki) Date: Mon, 22 Sep 2014 12:12:57 +0200 Subject: [Development] New company name for Qt part of Digia and unified web site In-Reply-To: <1735673.XjNiPhPNRJ@tjmaciei-mobl4> References: <2077330.JPi0Jq9zTu@tjmaciei-mobl4> <1735673.XjNiPhPNRJ@tjmaciei-mobl4> Message-ID: <2DFC029A-F694-4EC6-A41A-297B4176CFB3@java.pl> Overall the new website looks very modern and nice. Here's feedback of mine on new website: (1) Top menu bar does not have LCD sub pixel rendering on Safari OSX which makes it look jaggy (2) Opensource download button looks like disabled, any reason for that? (3) This greening green login panel looks really weird (4) On mobile layout is a mess Regards --Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-1.png Type: image/png Size: 13422 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-2.png Type: image/png Size: 20381 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: PastedGraphic-3.png Type: image/png Size: 8100 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: iOS Simulator Screen Shot 22 wrz 2014, 12.10.43.png Type: image/png Size: 101040 bytes Desc: not available URL: From ono at java.pl Mon Sep 22 12:33:17 2014 From: ono at java.pl (Adam Strzelecki) Date: Mon, 22 Sep 2014 12:33:17 +0200 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> Message-ID: <79A55E2D-3278-41F5-9180-345A3DDDEECA@java.pl> > qmake - framework bundle hierarchy (QTBUG-32895): https://codereview.qt-project.org/95454 > qmake - “_debug" in CFBundleExecutable (QTBUG-32894): https://codereview.qt-project.org/95455 > qmake - add CFBundleVersion: https://codereview.qt-project.org/95456 > macdeployqt - “Current” version symlinks: https://codereview.qt-project.org/#/c/95442/ > > Are these patches sufficient? If not, what’s missing? Almost. The only problem not addressed yet is .prl (i.e. QtCore.framework/QtCore.prl) file inside the bundle root. It has to be either moved one level up or into Resources/. Otherwise codesign won't work on built frameworks. Of course I am aware that macdepoyqt (probably) strips out this file, but if someone has some kind of custom deployment step then .prl file may cause trouble for him as codesign just bails out with "unsealed contents present in the root directory of an embedded framework" without exactly telling what's going on. --Adam From net147 at gmail.com Mon Sep 22 16:04:23 2014 From: net147 at gmail.com (Jonathan Liu) Date: Tue, 23 Sep 2014 00:04:23 +1000 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> Message-ID: <54202C67.2090903@gmail.com> On 19/09/2014 10:37 PM, BogDan wrote: > Hello folks, > > Singletons registered using qmlRegisterSingletonType, are deleted *before* > the other active objects. I consider it to be wrong because some of the active > objects may still need to access the singletons in their destructor ... > > IMHO singletons should be the very last objects deleted (also in the reverse > order). > > Is there any reason why they are deleted before the other active objects? > Or this is just a bug? > > Cheers, > BogDan. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Would this also be related to https://bugreports.qt-project.org/browse/QTBUG-38422? Regards, Jonathan From jake.petroules at petroules.com Mon Sep 22 19:37:13 2014 From: jake.petroules at petroules.com (Jake Petroules) Date: Mon, 22 Sep 2014 13:37:13 -0400 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: <8C5854CE-DEEE-4DBB-BFB1-F4F62DB33E14@digia.com> References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> <47FF2A53-55D0-44A0-9351-ADF862DECBAB@metsma.ee> <44A7E00B-7530-4273-9553-8D492A78A7A2@java.pl> <7A276FB1-7B3F-4465-8543-73DBBFAA8521@petroules.com> <8C5854CE-DEEE-4DBB-BFB1-F4F62DB33E14@digia.com> Message-ID: On 2014-09-22, at 05:56 AM, Sorvig Morten wrote: >> >> And the Info.plist should *always* set CFBundleExecutable to QtCore. To use the debug version you set the DYLD_IMAGE_SUFFIX environment variable to _debug prior to execution. > > A minor case: What would you do for debug-only builds? You don't do that. :) But I'd give the same answer - set DYLD_IMAGE_SUFFIX. You can add it to LSEnvironment in your application's Info.plist for Finder launches as well. >> >> As far as I'm aware, we already do this correctly (aside from Info.plist being in the wrong place), and the only reason _debug is showing up in an Info.plist somewhere is probably due to some simple typo or omission. > > Looks like it comes from the @EXECUTABLE@ -> var(“QMAKE_ORIG_TARGET”) substitution in unixmake2.cpp. > > I think the release build is racing the debug build, causing “_debug" to appear in some frameworks. So for a release+debug build we have two options: > 1) Use the release Info.plist. (the current suggested approach) > 2) Make sure they are identical. What you've done on Gerrit (approach 1, essentially) is correct. > Morten > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation From jake.petroules at petroules.com Mon Sep 22 19:39:47 2014 From: jake.petroules at petroules.com (Jake Petroules) Date: Mon, 22 Sep 2014 13:39:47 -0400 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: <79A55E2D-3278-41F5-9180-345A3DDDEECA@java.pl> References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> <79A55E2D-3278-41F5-9180-345A3DDDEECA@java.pl> Message-ID: On 2014-09-22, at 06:33 AM, Adam Strzelecki wrote: >> qmake - framework bundle hierarchy (QTBUG-32895): https://codereview.qt-project.org/95454 >> qmake - “_debug" in CFBundleExecutable (QTBUG-32894): https://codereview.qt-project.org/95455 >> qmake - add CFBundleVersion: https://codereview.qt-project.org/95456 >> macdeployqt - “Current” version symlinks: https://codereview.qt-project.org/#/c/95442/ >> >> Are these patches sufficient? If not, what’s missing? > > Almost. > > The only problem not addressed yet is .prl (i.e. QtCore.framework/QtCore.prl) file inside the bundle root. It has to be either moved one level up or into Resources/. Otherwise codesign won't work on built frameworks. > > Of course I am aware that macdepoyqt (probably) strips out this file, but if someone has some kind of custom deployment step then .prl file may cause trouble for him as codesign just bails out with "unsealed contents present in the root directory of an embedded framework" without exactly telling what's going on. Good catch. Simple answer: is there ANY reason at all to deploy .prl files? If so, place them in Resources. If not, don't put them anywhere in the framework bundles (instead, $QT_INSTALL_LIBS/lib). > --Adam > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation From gunnar at sletta.org Tue Sep 23 09:09:37 2014 From: gunnar at sletta.org (Gunnar Sletta) Date: Tue, 23 Sep 2014 09:09:37 +0200 Subject: [Development] OpenVG rendering backend to Qt Quick 2 In-Reply-To: <541A822F.9020002@nomovok.com> References: <541A822F.9020002@nomovok.com> Message-ID: On 18 Sep 2014, at 08:56, Mikko Hurskainen wrote: > Hi, > > I am interested on working on Qt Quick 2 Scenegraph OpenVG rendering > backend. Few embedded devices have both OpenVG and OpenGL accelerators > available. > > There are few interesting use cases for embedded devices: > * 2 display configurations, draw one with OpenVG and one with OpenGL > * OpenVG consumes less power, draw some applications with OpenVG. For > example more complex idle screen. > * Composite both OpenVG and OpenGL renderings into same display. Idea > here is that real-time critical items are rendered with OpenVG and > non-critical stuff with OpenGL > > In Qt4 there was a OpenVG rendering backend, but that of course does not > fit directly into Scenegraph. Also I found that there has been a plan > for this kind of functionality in Qt Conference 2012, but I could not > find any results. Is there some (even partial) results available somewhere ? Afraid not, the OpenVG based scene graph didn't go anywhere. > How about technical feasibility. It isn't set up for it. It is supposed to be OpenGL based. There is an adaptation layer in there which you could hook into to try to replace the implementations of the default items. That layer also has the option of plugging in a different renderer which you would need to traverse the scene graph to do the actual rendering. You would also have to replace the render loop as this also assumes the presence of an OpenGL context. There has been some work ongoing lately to make plugging in an alternate backend easier though, partially based on some talks at QtCS earlier this year about making the scene graph available for non-GL chipsets. > Scenegraph type rendering is in general > doable with OpenVG. The backend would need re-implementation to use > OpenVG primitives instead of OpenGL (ES). In general I think it should > be doable. Any opinions or possible pitfalls ? Parts of the public API dictate OpenGL, like the material API and the GeometryNode, so anything using that API wouldn't be supportable. Particles would probably not work and ShaderEffect would naturally not be possible. > > With Best Regards, > -- Mikko Hurskainen > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development cheers, Gunnar www.sletta.org From ymarcov at gmail.com Sat Sep 20 11:41:07 2014 From: ymarcov at gmail.com (Yam Marcovic) Date: Sat, 20 Sep 2014 12:41:07 +0300 Subject: [Development] Contribution proposal: Dispatcher class Message-ID: Hello, In my company, we started getting all tangled up with loads of signals and slots for many components. We also have a habit of renaming things as time goes by, and that can also pose a bit of a problem when dealing with signals & slots, meta object based invocations, etc. So, since our compiler supports the relevant features of C++11, I've made this class, called Dispatcher, which allowed us to develop multi-threaded apps much more easily. Instead of defining many signals and slots, you simply make your component extend QObject, and then, since you can use it with Qt's multi-threading framework, you can use it with the dispatcher. Here's the link to my repository on GitHub. It also gives a small usage example. https://github.com/ymarcov/qtdispatcher Note that I've striven to make it as correct as possible. E.g. if the return value is a reference, then you really get that reference, not a copy of it, and same with pointers. Or if it's by value, and the returned object has a move constructor, then it will be used. Stuff like that. It's been working very well for quite some time now in my workplace, and used in quite critical areas of the code with much success. Please let me know if you think this could help the Qt project as a built-in class. With best wishes, Yam Marcovic -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tero.Kojo at digia.com Tue Sep 23 13:19:04 2014 From: Tero.Kojo at digia.com (Kojo Tero) Date: Tue, 23 Sep 2014 11:19:04 +0000 Subject: [Development] Qt Champions nominations Message-ID: <21e7b04aefe34865aa7a4d59c90fddb5@DB4PR02MB237.eurprd02.prod.outlook.com> Hello, As part of the Qt Champions program ( http://qt-project.org/champion ), we are looking for nominations to the title of Qt Champion for the ongoing year. Right now we are looking especially for code contributors. So please take a few minutes to think who earns the title of Qt Champion, and nominate them. You can make nominations on the Qt-project wiki at http://qt-project.org/wiki/QtChampions Same login as for bugs and gerrit. If editing the wiki is too complicated, feel free to mail nominations to me, I'll make sure they go on the list. The nominations are meant for people who are not paid as their main task to work on Qt, however some of the people who do get paid to work on the project do so above and beyond the normal limits of their day jobs (coding all day and helping newcomers in their free time, for example). Feel free to nominate these people as Champions too. Thank you, Tero Qt Online Community Manager, Digia -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morten.Sorvig at digia.com Tue Sep 23 14:29:17 2014 From: Morten.Sorvig at digia.com (Sorvig Morten) Date: Tue, 23 Sep 2014 12:29:17 +0000 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> Message-ID: <1A220DD3-4E85-47DF-9192-5658B73B1000@digia.com> > On 22 Sep 2014, at 12:03, Sorvig Morten wrote: > > >> On 19 Sep 2014, at 11:28, Sorvig Morten wrote: >> >> This will indeed receive attention in the coming days. There are already some patches attached to the QTBUGs. I’ll post back here once we have a complete patch set ready. Target branches are Qt 5.3 and Qt 4.8. > > I’m using QTBUG-32896 as a metabug to track the effort. Backports to Qt 4.8: https://codereview.qt-project.org/95572 https://codereview.qt-project.org/95573 https://codereview.qt-project.org/95574 https://codereview.qt-project.org/95575 https://codereview.qt-project.org/95576 Morten From MVanBergen at ompartners.com Tue Sep 23 15:20:22 2014 From: MVanBergen at ompartners.com (Marijke Van Bergen) Date: Tue, 23 Sep 2014 13:20:22 +0000 Subject: [Development] Qt Location module Message-ID: <355E1125C328B745A41A2FE4B3B6164D9D9CD7AE@OMHQMBX01.domain.ompartners.com> Hi, What is the current status of the QtLocation module? Currently we are developing a desktop application on Qt 4.8 which uses maps based on QtMobility. We would like to upgrade our application to Qt 5.x, but we are waiting for the QtLocation module to be released. Kind regards, Marijke Van Bergen Marijke Van Bergen Software Development Manager mvanbergen at ompartners.com OM Partners Koralenhoeve 23 2160 Wommelgem Belgium Phone: +32 3 650 22 11, Fax: +32 3 650 22 90 Direct: +32 3 650 23 42 , Mobile: +32 473 95 28 16 http://www.ompartners.com IMPORTANT NOTICE The information in this e-mail and any attachments is intended for the addressee only. The contents do not represent the opinion of OM Partners n.v. or any of its affiliates except to the extent that it relates to their official business. If you receive this in error, please contact the sender and delete the material from any computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kate.alhola at gmail.com Tue Sep 23 21:01:06 2014 From: kate.alhola at gmail.com (Kate Alhola) Date: Tue, 23 Sep 2014 22:01:06 +0300 Subject: [Development] Qt Location module In-Reply-To: <355E1125C328B745A41A2FE4B3B6164D9D9CD7AE@OMHQMBX01.domain.ompartners.com> References: <355E1125C328B745A41A2FE4B3B6164D9D9CD7AE@OMHQMBX01.domain.ompartners.com> Message-ID: I can't say behalf of Qt Project what is the status maps but I am in very similar situation. We make app for IOS and Android that uses map. We started from Qt4.8 but moved soon Qt5 mostly because Android and IOS were much better supported. Qt5 Location Maps has all it's API changed and there is no C++ API and we were using QtQuick1 with mobile components so we ended to port Qt4.8 maps component to Qt5. Next step to us is to move QtQuick2 and new map component. The map component for QtQuick2 is part or qtlocation sources but to be enabled it requires to fetch qt3d from git, compile and install and then compiling qtlocation again and you get maps. For desktop the maps compiles and installs without problems but for Android and IOS small tweaking is required. Kate On Tue, Sep 23, 2014 at 4:20 PM, Marijke Van Bergen < MVanBergen at ompartners.com> wrote: > Hi, > > What is the current status of the QtLocation module? Currently we are > developing a desktop application on Qt 4.8 which uses maps based on > QtMobility. We would like to upgrade our application to Qt 5.x, but we are > waiting for the QtLocation module to be released. > > Kind regards, > Marijke Van Bergen > > > > Marijke Van Bergen > Software Development Manager > > mvanbergen at ompartners.com > > OM Partners > Koralenhoeve 23 > 2160 Wommelgem > Belgium > > Phone: +32 3 650 22 11, Fax: +32 3 650 22 90 > Direct: +32 3 650 23 42 , Mobile: +32 473 95 28 16 > > http://www.ompartners.com > > > > IMPORTANT NOTICE > The information in this e-mail and any attachments is intended for the > addressee only. The contents do not represent the opinion of OM Partners > n.v. or any of its affiliates except to the extent that it relates to their > official business. If you receive this in error, please contact the sender > and delete the material from any computer. > > > > > _______________________________________________ > 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 lorn.potter at gmail.com Wed Sep 24 03:02:26 2014 From: lorn.potter at gmail.com (Lorn Potter) Date: Wed, 24 Sep 2014 11:02:26 +1000 Subject: [Development] call for comments/review QSystemInfo::NetworkInfo API Message-ID: <38AA6A7C-D932-4F23-8A1E-2A6823CE3291@gmail.com> Hi *, While looking into a bug https://bugreports.qt-project.org/browse/QTBUG-41283 It reminded me that I am not happy with NetworkInfo since it got ported from QtMobility to Qt 5. *Note* QSystemInfo is not officially supported API. Since I am maintainer for it and it's not "released", I am going to change it. For one, I really wish the whole QtSystemInfo code were a separate module and not lumped in with two other completely unrelated modules - publish & subscribe and serviceframework. If anyone wants to help review/revise this API, take a look (or any other QtSystemInfo API's) https://qt.gitorious.org/qt/qtsystems/source/aa651c73bf7bc57c1b6b1bfcfa9afe901884a102:src/systeminfo/qnetworkinfo.h comments/suggestions welcome. From chris.adams at qinetic.com.au Wed Sep 24 03:51:10 2014 From: chris.adams at qinetic.com.au (Chris Adams) Date: Wed, 24 Sep 2014 11:51:10 +1000 Subject: [Development] Contribution proposal: Dispatcher class In-Reply-To: References: Message-ID: Hello Yam, I can think of a couple of places in code I've written where that would be very useful, personally. However, when I looked at the repo I couldn't see any license information, and I'm wondering what license you're planning on releasing it under. Cheers, Chris. https://www.qinetic.com.au/ - Qt And QML User Experience Specialists On Sat, Sep 20, 2014 at 7:41 PM, Yam Marcovic wrote: > Hello, > > In my company, we started getting all tangled up with loads of signals and > slots for many components. We also have a habit of renaming things as time > goes by, and that can also pose a bit of a problem when dealing with > signals & slots, meta object based invocations, etc. > > So, since our compiler supports the relevant features of C++11, I've made > this class, called Dispatcher, which allowed us to develop multi-threaded > apps much more easily. Instead of defining many signals and slots, you > simply make your component extend QObject, and then, since you can use it > with Qt's multi-threading framework, you can use it with the dispatcher. > > Here's the link to my repository on GitHub. It also gives a small usage > example. > > https://github.com/ymarcov/qtdispatcher > > Note that I've striven to make it as correct as possible. E.g. if the > return value is a reference, then you really get that reference, not a copy > of it, and same with pointers. Or if it's by value, and the returned object > has a move constructor, then it will be used. Stuff like that. It's been > working very well for quite some time now in my workplace, and used in > quite critical areas of the code with much success. > > Please let me know if you think this could help the Qt project as a > built-in class. > > With best wishes, > Yam Marcovic > > _______________________________________________ > 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 chris.adams at qinetic.com.au Wed Sep 24 03:57:43 2014 From: chris.adams at qinetic.com.au (Chris Adams) Date: Wed, 24 Sep 2014 11:57:43 +1000 Subject: [Development] Qt Location module In-Reply-To: <355E1125C328B745A41A2FE4B3B6164D9D9CD7AE@OMHQMBX01.domain.ompartners.com> References: <355E1125C328B745A41A2FE4B3B6164D9D9CD7AE@OMHQMBX01.domain.ompartners.com> Message-ID: Hi, My understanding is that the QtLocation module from QtMobility got split into separate modules: QtPositioning and QtLocation (although they're located within the same source repo in qt5 still, if memory serves). Aaron McCarthy has been actively maintaining the QtPositioning module, but QtLocation still needs some work until it can be released, from what I understand. Obviously, the more people who are able to contribute to the effort, the quicker that can happen :-) Aaron is on holiday at the moment, but no doubt he'll respond to this thread shortly. Cheers, Chris. http://www.qinetic.com.au/ - Qt And QML User Experience Specialists On Tue, Sep 23, 2014 at 11:20 PM, Marijke Van Bergen < MVanBergen at ompartners.com> wrote: > Hi, > > What is the current status of the QtLocation module? Currently we are > developing a desktop application on Qt 4.8 which uses maps based on > QtMobility. We would like to upgrade our application to Qt 5.x, but we are > waiting for the QtLocation module to be released. > > Kind regards, > Marijke Van Bergen > > > > Marijke Van Bergen > Software Development Manager > > mvanbergen at ompartners.com > > OM Partners > Koralenhoeve 23 > 2160 Wommelgem > Belgium > > Phone: +32 3 650 22 11, Fax: +32 3 650 22 90 > Direct: +32 3 650 23 42 , Mobile: +32 473 95 28 16 > > http://www.ompartners.com > > > > IMPORTANT NOTICE > The information in this e-mail and any attachments is intended for the > addressee only. The contents do not represent the opinion of OM Partners > n.v. or any of its affiliates except to the extent that it relates to their > official business. If you receive this in error, please contact the sender > and delete the material from any computer. > > > > > _______________________________________________ > 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 chris.adams at qinetic.com.au Wed Sep 24 04:03:19 2014 From: chris.adams at qinetic.com.au (Chris Adams) Date: Wed, 24 Sep 2014 12:03:19 +1000 Subject: [Development] call for comments/review QSystemInfo::NetworkInfo API In-Reply-To: <38AA6A7C-D932-4F23-8A1E-2A6823CE3291@gmail.com> References: <38AA6A7C-D932-4F23-8A1E-2A6823CE3291@gmail.com> Message-ID: Hi Lorn, In regards to the publish/subscribe and serviceframework bits, I wonder what the plan is with those. How much overlap between them and Replicant is there? Perhaps Brett could quickly sum up the differences between the pub/sub module and the Replicant framework, and whether Replicant offers serviceframework-like functionality also? I would assume that if there was significant overlap, we would definitely be better off removing QSystemInfo from that repo, as QSystemInfo is much more widely used and obviously still relevant, while the other two perhaps are less utilised in industry - but that's just my opinion. With regards to the changes to the NetworkInfo API, I'm sure Aaron McCarthy would be interested in those. He's on holiday right now but hopefully he'll get a chance to look at those soon. Cheers, Chris. http://www.qinetic.com.au/ - Qt And QML User Experience Specialists On Wed, Sep 24, 2014 at 11:02 AM, Lorn Potter wrote: > Hi *, > > While looking into a bug > https://bugreports.qt-project.org/browse/QTBUG-41283 > > It reminded me that I am not happy with NetworkInfo since it got ported > from QtMobility to Qt 5. > > > *Note* QSystemInfo is not officially supported API. > > Since I am maintainer for it and it's not "released", I am going to change > it. > > For one, I really wish the whole QtSystemInfo code were a separate module > and not lumped in with two other completely unrelated modules - publish & > subscribe and serviceframework. > > > If anyone wants to help review/revise this API, take a look (or any other > QtSystemInfo API's) > > > https://qt.gitorious.org/qt/qtsystems/source/aa651c73bf7bc57c1b6b1bfcfa9afe901884a102:src/systeminfo/qnetworkinfo.h > > comments/suggestions welcome. > > > > _______________________________________________ > 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.hausmann at digia.com Wed Sep 24 07:57:07 2014 From: simon.hausmann at digia.com (Simon Hausmann) Date: Wed, 24 Sep 2014 07:57:07 +0200 Subject: [Development] call for comments/review QSystemInfo::NetworkInfo API In-Reply-To: <38AA6A7C-D932-4F23-8A1E-2A6823CE3291@gmail.com> References: <38AA6A7C-D932-4F23-8A1E-2A6823CE3291@gmail.com> Message-ID: <6569370.kE86OlZ1LH@angrybird> On Wednesday, September 24, 2014 11:02:26 AM Lorn Potter wrote: > Hi *, > > While looking into a bug > https://bugreports.qt-project.org/browse/QTBUG-41283 > > It reminded me that I am not happy with NetworkInfo since it got ported from > QtMobility to Qt 5. > > > *Note* QSystemInfo is not officially supported API. > > Since I am maintainer for it and it's not "released", I am going to change > it. > > For one, I really wish the whole QtSystemInfo code were a separate module > and not lumped in with two other completely unrelated modules - publish & > subscribe and serviceframework. > > > If anyone wants to help review/revise this API, take a look (or any other > QtSystemInfo API's) > > https://qt.gitorious.org/qt/qtsystems/source/aa651c73bf7bc57c1b6b1bfcfa9afe9 > 01884a102:src/systeminfo/qnetworkinfo.h > > comments/suggestions welcome. I wonder if the"int interface" indexed API is tedious to use. Say you do manage to get a QNetworkInterface object from QtNetwork, then before you can call for example QString imsi(int interface) const; you have to retrieve the index() from the network interface first. It feels like a very procedural API. Half of the "getters" would IMO be a nicer fit if they were part of the QNetworkInterface API. Then they would make for a really nice property based API - and we just may have to delegate some functionality into plugins implementation wise? When it comes to the notification signals I also wonder if it would be better to have a QNetworkInterfaceMonitor alike class in QtNetwork that supplies the notifications (for an interface mask perhaps). >From a 10000 feet Qt as a product point of view, it's not evident why this API belongs into a separate module instead of simply into the Qt network module. Simon From ymarcov at gmail.com Wed Sep 24 09:24:49 2014 From: ymarcov at gmail.com (Yam Marcovic) Date: Wed, 24 Sep 2014 10:24:49 +0300 Subject: [Development] Contribution proposal: Dispatcher class In-Reply-To: References: Message-ID: I don't care so much about that. I just think it'd be nice as part of the Qt core library. So I'm open for suggestions. :) However, I will say I don't want to force people to give their sources away if they use it. So a license along the lines of 'this license is here for formal purposes; but feel free to do anything you want with this,' is good enough as far as I'm concerned. On Sep 24, 2014 4:51 AM, "Chris Adams" wrote: > Hello Yam, > > I can think of a couple of places in code I've written where that would be > very useful, personally. > However, when I looked at the repo I couldn't see any license information, > and I'm wondering what license you're planning on releasing it under. > > Cheers, > Chris. > > > https://www.qinetic.com.au/ - Qt And QML User Experience Specialists > > On Sat, Sep 20, 2014 at 7:41 PM, Yam Marcovic wrote: > >> Hello, >> >> In my company, we started getting all tangled up with loads of signals >> and slots for many components. We also have a habit of renaming things as >> time goes by, and that can also pose a bit of a problem when dealing with >> signals & slots, meta object based invocations, etc. >> >> So, since our compiler supports the relevant features of C++11, I've made >> this class, called Dispatcher, which allowed us to develop multi-threaded >> apps much more easily. Instead of defining many signals and slots, you >> simply make your component extend QObject, and then, since you can use it >> with Qt's multi-threading framework, you can use it with the dispatcher. >> >> Here's the link to my repository on GitHub. It also gives a small usage >> example. >> >> https://github.com/ymarcov/qtdispatcher >> >> Note that I've striven to make it as correct as possible. E.g. if the >> return value is a reference, then you really get that reference, not a copy >> of it, and same with pointers. Or if it's by value, and the returned object >> has a move constructor, then it will be used. Stuff like that. It's been >> working very well for quite some time now in my workplace, and used in >> quite critical areas of the code with much success. >> >> Please let me know if you think this could help the Qt project as a >> built-in class. >> >> With best wishes, >> Yam Marcovic >> >> _______________________________________________ >> 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 Alexander.Blasche at digia.com Wed Sep 24 09:29:24 2014 From: Alexander.Blasche at digia.com (Blasche Alexander) Date: Wed, 24 Sep 2014 07:29:24 +0000 Subject: [Development] Qt Location module In-Reply-To: References: <355E1125C328B745A41A2FE4B3B6164D9D9CD7AE@OMHQMBX01.domain.ompartners.com> Message-ID: > -----Original Message----- > From: development-bounces+alexander.blasche=digia.com at qt-project.org > On Behalf Of Kate Alhola > The map component for QtQuick2 is part or qtlocation sources but to > be enabled it requires to fetch qt3d from git, compile and install and then > compiling qtlocation again and you get maps. For desktop the maps compiles and > installs without problems but for Android and IOS small tweaking is required. The Qt3D dependency was removed in the 5.4 branch. > On Behalf Of Chris Adams > My understanding is that the QtLocation module from QtMobility got split into > separate modules: QtPositioning and QtLocation (although they're located within > the same source repo in qt5 still, if memory serves). Same repo, two modules, QtPositioning has been released and is supported, QtLocation hasn't been released. > Aaron McCarthy has been actively maintaining the QtPositioning module, but > QtLocation still needs some work until it can be released, from what I understand. > Obviously, the more people who are able to contribute to the effort, the quicker > that can happen :-) Aaron is on holiday at the moment, but no doubt he'll > respond to this thread shortly. Indeed. The main problem is time/manpower. -- Alex From Alexander.Blasche at digia.com Wed Sep 24 09:52:40 2014 From: Alexander.Blasche at digia.com (Blasche Alexander) Date: Wed, 24 Sep 2014 07:52:40 +0000 Subject: [Development] call for comments/review QSystemInfo::NetworkInfo API In-Reply-To: <6569370.kE86OlZ1LH@angrybird> References: <38AA6A7C-D932-4F23-8A1E-2A6823CE3291@gmail.com> <6569370.kE86OlZ1LH@angrybird> Message-ID: > >From a 10000 feet Qt as a product point of view, it's not evident why this API > belongs into a separate module instead of simply into the Qt network module. That's a historical reason and Qt's inability to accept such a contribution at the time when such changes were needed. This doesn't mean those reasons weren't valid at the time. In some cases it is desirable to have QML interfaces for those classes and when you move those classes into qtbase the dependencies are not correct. I guess one could add them to qtdeclarative as well. After all the same has happened for other qtbase classes too. On the positive side there are quite a few cases in more recent Qt history where such moves did happen. The QStorageInfo is an excellent example. The QtSystemInfo class with the same name is pretty much obsolete now. As more such moves happen I am sure that the content in QSystemInfo diminishes further. I would encourage Lorn to consider a merge the network related QNetworkInfo API's into QtNetwork. > In regards to the publish/subscribe and serviceframework bits, I wonder what > the plan is with those. How much overlap between them and Replicant is there? Potentially there is a significant overlap. The principle is the same and no there are no immediate plans for them. It's no different than the jsondb repo except that the principle applications are probably somewhat more in demand than jsondb. I wish a day had more than 24hrs .... -- Alex From nospam at vuorela.dk Wed Sep 24 11:34:05 2014 From: nospam at vuorela.dk (Sune Vuorela) Date: Wed, 24 Sep 2014 09:34:05 +0000 (UTC) Subject: [Development] Contribution proposal: Dispatcher class References: Message-ID: On 2014-09-24, Yam Marcovic wrote: > However, I will say I don't want to force people to give their sources away > if they use it. > > So a license along the lines of 'this license is here for formal purposes; > but feel free to do anything you want with this,' is good enough as far as > I'm concerned. I think the formal way of expressing this is either the MIT, 2 or 3-clause BSD licenses. http://opensource.org/licenses/BSD-3-Clause http://opensource.org/licenses/BSD-2-Clause http://opensource.org/licenses/mit-license.html /Sune From lorn.potter at gmail.com Wed Sep 24 12:08:28 2014 From: lorn.potter at gmail.com (Lorn Potter) Date: Wed, 24 Sep 2014 20:08:28 +1000 Subject: [Development] call for comments/review QSystemInfo::NetworkInfo API In-Reply-To: <6569370.kE86OlZ1LH@angrybird> References: <38AA6A7C-D932-4F23-8A1E-2A6823CE3291@gmail.com> <6569370.kE86OlZ1LH@angrybird> Message-ID: <9D099610-0AD3-44A3-A527-63065020193F@gmail.com> On 24 Sep 2014, at 3:57 pm, Simon Hausmann wrote: > > I wonder if the"int interface" indexed API is tedious to use. Say you do > manage to get a QNetworkInterface object from QtNetwork, then before you can > call for example > > QString imsi(int interface) const; > > you have to retrieve the index() from the network interface first. It feels > like a very procedural API. Yes, it is tedious and a bit odd to me, and is one thing I do not like about it. A lot of those don't have anything to do with any particular network interface. It wasn't this way in QtMobility, I wasn't on the team that ported this to Qt 5, so I am not sure of the reasoning of it. > Half of the "getters" would IMO be a nicer fit if they were part of the > QNetworkInterface API. Then they would make for a really nice property based > API - and we just may have to delegate some functionality into plugins > implementation wise? > > When it comes to the notification signals I also wonder if it would be better > to have a QNetworkInterfaceMonitor alike class in QtNetwork that supplies the > notifications (for an interface mask perhaps). > > > From a 10000 feet Qt as a product point of view, it's not evident why this API > belongs into a separate module instead of simply into the Qt network module. I agree. From Jani.Heikkinen at digia.com Wed Sep 24 13:53:18 2014 From: Jani.Heikkinen at digia.com (Heikkinen Jani) Date: Wed, 24 Sep 2014 11:53:18 +0000 Subject: [Development] Qt 5.4 beta snapshot available Message-ID: Hi all, First Qt5.4 beta snapshot packages available here Windows: http://download.qt-project.org/snapshots/qt/5.4/5.4.0-beta/2014-09-24_20/ Linux: http://download.qt-project.org/snapshots/qt/5.4/5.4.0-beta/2014-09-24_24/ Unfortunately there is still issues with mac packages & so on those are missing :( Please check these packages and verify everything needed is in & works as expected. Qt 5.4 beta release is planned to happen during next week so please link all beta blocker issues in the metabug: https://bugreports.qt-project.org/browse/QTBUG-41077 Br, Jani From sierdzio at gmail.com Wed Sep 24 14:04:56 2014 From: sierdzio at gmail.com (Tomasz Siekierda) Date: Wed, 24 Sep 2014 14:04:56 +0200 Subject: [Development] Contribution proposal: Dispatcher class In-Reply-To: References: Message-ID: On 24 September 2014 11:34, Sune Vuorela wrote: > On 2014-09-24, Yam Marcovic wrote: >> However, I will say I don't want to force people to give their sources away >> if they use it. >> >> So a license along the lines of 'this license is here for formal purposes; >> but feel free to do anything you want with this,' is good enough as far as >> I'm concerned. > > I think the formal way of expressing this is either the MIT, 2 or > 3-clause BSD licenses. > > http://opensource.org/licenses/BSD-3-Clause > http://opensource.org/licenses/BSD-2-Clause > http://opensource.org/licenses/mit-license.html > > /Sune This is probably the simplest you can go: WTFPL http://www.wtfpl.net/about/ From ip.alexander.ilyin at gmail.com Wed Sep 24 16:17:34 2014 From: ip.alexander.ilyin at gmail.com (Alexander Ilyin) Date: Wed, 24 Sep 2014 14:17:34 +0000 (UTC) Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> <1A220DD3-4E85-47DF-9192-5658B73B1000@digia.com> Message-ID: Sorvig Morten digia.com> writes: > > > > On 22 Sep 2014, at 12:03, Sorvig Morten digia.com> wrote: > > > > > >> On 19 Sep 2014, at 11:28, Sorvig Morten digia.com> wrote: > >> > >> This will indeed receive attention in the coming days. There are already some patches attached to the > QTBUGs. I’ll post back here once we have a complete patch set ready. Target branches are Qt 5.3 and Qt 4.8. > > > > I’m using QTBUG-32896 as a metabug to track the effort. > > Backports to Qt 4.8: > > https://codereview.qt-project.org/95572 > https://codereview.qt-project.org/95573 > https://codereview.qt-project.org/95574 > https://codereview.qt-project.org/95575 > https://codereview.qt-project.org/95576 > > Morten > _______________________________________________ > Development mailing list > Development qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > Dear colleagues, I see that you are trying to fix the problem with signing Qt apps for Mac OS X 10.9.5 and 10.10. I have faced the problem with signing my app on Mac OS X 10.9.5, Qt 4.8.6 (LGPL). I have read about wrong Qt frameworks structure and absent info.plist files after macdeployqt. To localize the problem, I have created the simple Qt app using QtCore and QtGui, and tried different methods suggested in forums (after running macdeployqt). The 1st method is to copy info.plist files from Qt location to the Resources folders in s-test.app/Contents/Frameworks/Qt*.framework/ (this folders are empty after macdeployqt); sign dylibs, frameworks, app - each call with --deep option. CODESIGN IS OK, BUT "spctl -a -t exec -vv" REJECTED THE APP ("obsolete resource envelope"). The 2nd method is to move Resources folders from s-test.app/Contents/Frameworks/Qt*.framework/ to s-test.app/Contents/Frameworks/Qt*.framework/Versions/4/, copy info.plist files from Qt location to these Resources folders, create symlinks "Current", "Resources", "Qt*"; sign dylibs, frameworks, app - each call with --deep option. CODESIGN FAILED WITH MESSAGE "unsealed contents present in the root directory of an embedded framework In subcomponent: /Developer/res-plan/bin/s-test.app/Contents/Frameworks/QtCore.framework" (Please look at the listing below) I also tried codesign without --depp - no success. Could you give me simple instruction - how to fix the problem manually and sign the app to be accepted by OS X 10.9.5 and later? Or I have to wait for an update of Qt 4.8? Thank you in advance, Alexander Ilyin METHOD 1 (without fixing Frameworks structure, like in deploy.txt from https://bugreports.qt-project.org/browse/QTBUG-38511) ---------------------------------------------------------------------------- 1) cp /Library/Frameworks/QtCore.framework/Contents/Info.plist s-test.app/Contents/Frameworks/QtCore.framework/Resources/ cp /Library/Frameworks/QtGui.framework/Contents/Info.plist s-test.app/Contents/Frameworks/QtGui.framework/Resources/ 2) find s-test.app/Contents -name *.dylib | xargs -I $ codesign -vvvv --force --verify --deep --verbose --sign "Developer ID Application: Alexander Ilyin" $ find s-test.app/Contents -name Qt* -type f | xargs -I $ codesign -vvvv --force --verify --deep --verbose --sign "Developer ID Application: Alexander Ilyin" $ codesign -vvvv --force --verify --deep --verbose --sign "Developer ID Application: Alexander Ilyin" s-test.app RESULT - CODESIGN IS OK, BUT "spctl -a -t exec -vv" REJECTED THE APP: ... s-test.app/Contents/Frameworks/QtCore.framework/Versions/4/QtCore: signed Mach-O thin (x86_64) [QtCore] s-test.app/Contents/Frameworks/QtGui.framework/Versions/4/QtGui: signed Mach-O thin (x86_64) [QtGui] s-test.app: signed bundle with Mach-O thin (x86_64) [com.yourcompany.s-test] $ spctl -a -t exec -vv s-test.app s-test.app: rejected source=obsolete resource envelope $ codesign --verify --deep --verbose=3 s-test.app --prepared:/Developer/res-plan/bin/s-test.app/Contents/Framework /QtCore.framework --validated:/Developer/res-plan/bin/s-test.app/Contents/Frameworks /QtCore.framework s-test.app: embedded framework contains modified or invalid version In subcomponent: /Developer/res-plan/bin/s-test.app/Contents/Frameworks/QtCore.framework METHOD 2 (with fixing Frameworks structure) ---------------------------------------------------------------------------- 1) mv /Developer/res-plan/bin/s-test.app/Contents/Frameworks /QtCore.framework/Resources s-test.app/Contents/Frameworks/QtCore.framework/Versions/4/ cp /Library/Frameworks/QtCore.framework/Contents/Info.plist s-test.app/Contents/Frameworks/QtCore.framework/Versions/4/Resources/ ln -s /Developer/res-plan/bin/s-test.app/Contents/Frameworks/QtCore.framework /Versions/4/ s-test.app/Contents/Frameworks/QtCore.framework/Versions/Current ln -s /Developer/res-plan/bin/s-test.app/Contents/Frameworks/QtCore.framework /Versions/Current/Resources/ s-test.app/Contents/Frameworks/QtCore.framework/Resources ln -s /Developer/res-plan/bin/s-test.app/Contents/Frameworks/QtCore.framework /Versions/Current/QtCore s-test.app/Contents/Frameworks/QtCore.framework/QtCore ... (similar 5 instructions for QtGui) 2) find s-test.app/Contents -name *.dylib | xargs -I $ codesign -vvvv --force --verify --deep --verbose --sign "Developer ID Application: Alexander Ilyin" $ find s-test.app/Contents -name Qt* -type f | xargs -I $ codesign -vvvv --force --verify --deep --verbose --sign "Developer ID Application: Alexander Ilyin" $ codesign -vvvv --force --verify --deep --verbose --sign "Developer ID Application: Alexander Ilyin" s-test.app RESULT - CODESIGN FAILED : $ sh sign.sh ... (dylibs OK) s-test.app/Contents/Frameworks/QtCore.framework/Versions/4/QtCore: signed bundle with Mach-O thin (x86_64) [4] s-test.app/Contents/Frameworks/QtGui.framework/Versions/4/QtGui: signed Mach-O thin (x86_64) [QtGui] s-test.app: unsealed contents present in the root directory of an embedded framework In subcomponent: /Developer/res-plan/bin/s-test.app/Contents/Frameworks/QtCore.framework ---------------------------------------------------------------------------- From thiago.macieira at intel.com Wed Sep 24 17:15:45 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 Sep 2014 08:15:45 -0700 Subject: [Development] call for comments/review QSystemInfo::NetworkInfo API In-Reply-To: <9D099610-0AD3-44A3-A527-63065020193F@gmail.com> References: <38AA6A7C-D932-4F23-8A1E-2A6823CE3291@gmail.com> <6569370.kE86OlZ1LH@angrybird> <9D099610-0AD3-44A3-A527-63065020193F@gmail.com> Message-ID: <3224627.iC1uHBUHO7@tjmaciei-mobl4> On Wednesday 24 September 2014 20:08:28 Lorn Potter wrote: > > you have to retrieve the index() from the network interface first. It > > feels like a very procedural API. > > Yes, it is tedious and a bit odd to me, and is one thing I do not like about > it. A lot of those don't have anything to do with any particular network > interface. Probably for the reason Alex brought up: QML. It's easier to deal with integer indexes in QML than a QNetworkInterface object. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From simon.hausmann at digia.com Wed Sep 24 17:37:51 2014 From: simon.hausmann at digia.com (Simon Hausmann) Date: Wed, 24 Sep 2014 17:37:51 +0200 Subject: [Development] call for comments/review QSystemInfo::NetworkInfo API In-Reply-To: <3224627.iC1uHBUHO7@tjmaciei-mobl4> References: <38AA6A7C-D932-4F23-8A1E-2A6823CE3291@gmail.com> <9D099610-0AD3-44A3-A527-63065020193F@gmail.com> <3224627.iC1uHBUHO7@tjmaciei-mobl4> Message-ID: <3092120.iMJOqgdjSP@angrybird> On Wednesday, September 24, 2014 08:15:45 AM Thiago Macieira wrote: > On Wednesday 24 September 2014 20:08:28 Lorn Potter wrote: > > > you have to retrieve the index() from the network interface first. It > > > feels like a very procedural API. > > > > Yes, it is tedious and a bit odd to me, and is one thing I do not like > > about it. A lot of those don't have anything to do with any particular > > network interface. > > Probably for the reason Alex brought up: QML. It's easier to deal with > integer indexes in QML than a QNetworkInterface object. Why is that? Besides that it's possible to make a QObject wrapper, I'd think QNetworkInterface would be a candidate for Olivier's Q_GADGET work :) Simon From jeisecke at saltation.de Wed Sep 24 19:02:32 2014 From: jeisecke at saltation.de (Nils Jeisecke) Date: Wed, 24 Sep 2014 19:02:32 +0200 Subject: [Development] Qml/JS QVariantMap conversion problem Message-ID: Hi! While porting to Qt5 I've stumbled over a very strange problem. QVariantMap objects mutate when transported from C++ via Qml back to C++. QVariant as constructed on the C++ side: QVariant(QVariantMap, QMap(("x", QVariant(QStringList, ("a", "b")) ) ) ) QVariant when gone through Qml and handled back to C++: QVariant(QVariantMap, QMap(("x", QVariant(QVariantMap, QMap(("0", QVariant(QString, "a") ) ( "1" , QVariant(QString, "b") ) ) ) ) ) ) So what used to be a QStringList now is a QMap? This is: a) not the behavior of Qt4/QtQuick 1 b) pretty weird This does not happen if a QVariant directly wrapping a QStringList is used, only when a QVariantMap is involved. Testcase: --main.cpp-- #include #include #include #include class Dummy : public QObject { Q_OBJECT public: Dummy(QObject *parent = 0) : QObject(parent) {} Q_INVOKABLE void setMap(const QVariant &map) { qDebug() << "setMap" << map; } Q_INVOKABLE QVariant buildMap() const { QVariantMap map; map["x"] = QStringList() << "a" << "b"; qDebug() << "buildMap" << QVariant(map); return map; } }; int main(int argc, char *argv[]) { QApplication app(argc, argv); QQmlApplicationEngine engine; engine.load(QUrl(QStringLiteral("qrc:/main.qml"))); Dummy *dummy = new Dummy; engine.rootContext()->setContextProperty("dummy", dummy); return app.exec(); } #include "main.moc" --main.qml-- import QtQuick 2.3 import QtQuick.Controls 1.2 ApplicationWindow { visible: true width: 640 height: 480 Button { text: "Mutate!" onClicked: dummy.setMap(dummy.buildMap()); } } -------------------- Any ideas? Thanks, Nils From jake.petroules at petroules.com Wed Sep 24 21:33:06 2014 From: jake.petroules at petroules.com (Jake Petroules) Date: Wed, 24 Sep 2014 15:33:06 -0400 Subject: [Development] Qt 5.4 beta snapshot available In-Reply-To: References: Message-ID: On 2014-09-24, at 07:53 AM, Heikkinen Jani wrote: > Hi all, > > First Qt5.4 beta snapshot packages available here > > Windows: http://download.qt-project.org/snapshots/qt/5.4/5.4.0-beta/2014-09-24_20/ > Linux: http://download.qt-project.org/snapshots/qt/5.4/5.4.0-beta/2014-09-24_24/ > > Unfortunately there is still issues with mac packages & so on those are missing :( > > Please check these packages and verify everything needed is in & works as expected. > > Qt 5.4 beta release is planned to happen during next week so please link all beta blocker issues in the metabug: https://bugreports.qt-project.org/browse/QTBUG-41077 > > Br, > Jani > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Are we really still distributing separate OpenGL and ANGLE builds for Windows for the 5.4 release? I'd hoped to see -opengl dynamic builds only... -- Jake Petroules - jake.petroules at petroules.com Chief Technology Officer - Petroules Corporation From missdeer at gmail.com Thu Sep 25 02:59:51 2014 From: missdeer at gmail.com (Yang Fan) Date: Thu, 25 Sep 2014 08:59:51 +0800 Subject: [Development] Qt 5.4 beta snapshot available In-Reply-To: References: Message-ID: 5.4 beta is coming, how fast! On Wed, Sep 24, 2014 at 7:53 PM, Heikkinen Jani wrote: > Hi all, > > First Qt5.4 beta snapshot packages available here > > Windows: > http://download.qt-project.org/snapshots/qt/5.4/5.4.0-beta/2014-09-24_20/ > Linux: > http://download.qt-project.org/snapshots/qt/5.4/5.4.0-beta/2014-09-24_24/ > > Unfortunately there is still issues with mac packages & so on those are > missing :( > > Please check these packages and verify everything needed is in & works as > expected. > > Qt 5.4 beta release is planned to happen during next week so please link > all beta blocker issues in the metabug: > https://bugreports.qt-project.org/browse/QTBUG-41077 > > Br, > Jani > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Regards, Fan Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From ff.pptux+qt at gmail.com Thu Sep 25 03:47:06 2014 From: ff.pptux+qt at gmail.com (F) Date: Thu, 25 Sep 2014 09:47:06 +0800 Subject: [Development] Qt 5.4 beta snapshot available In-Reply-To: References: Message-ID: Problems with MinGW build? On 24 September 2014 19:53, Heikkinen Jani wrote: > Hi all, > > First Qt5.4 beta snapshot packages available here > > Windows: > http://download.qt-project.org/snapshots/qt/5.4/5.4.0-beta/2014-09-24_20/ > Linux: > http://download.qt-project.org/snapshots/qt/5.4/5.4.0-beta/2014-09-24_24/ > > Unfortunately there is still issues with mac packages & so on those are > missing :( > > Please check these packages and verify everything needed is in & works as > expected. > > Qt 5.4 beta release is planned to happen during next week so please link > all beta blocker issues in the metabug: > https://bugreports.qt-project.org/browse/QTBUG-41077 > > Br, > Jani > > _______________________________________________ > 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.hausmann at digia.com Thu Sep 25 07:34:28 2014 From: simon.hausmann at digia.com (Simon Hausmann) Date: Thu, 25 Sep 2014 07:34:28 +0200 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: <1411378086.34723.YahooMailNeo@web126105.mail.ne1.yahoo.com> References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> <1691425.eGisNBzUG3@rhea> <1411378086.34723.YahooMailNeo@web126105.mail.ne1.yahoo.com> Message-ID: <1590984.Ktr0Ibkj0x@angrybird> On Monday, September 22, 2014 02:28:06 AM BogDan wrote: > ----- Original Message ----- > From: Simon Hausmann > To: BogDan > Cc: Chris Adams ; Qt Development Group > Sent: Monday, September 22, 2014 11:56 AM > Subject: Re: SV: [Development] [QML] Singletons are deleted before the > other objects > On Monday 22. September 2014 01.33.14 BogDan wrote: > > On Monday 22. September 2014 01.19.17 BogDan wrote: > > > Hi Simon, > > > > > > I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 > > > branch (sha1 f9ee33f96), is a little bit old, but I bet nobody > > > fixed it. The same problem is in previous releases. > > > > > > So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 > > > The other active objects are deleted in MemoryManager::sweep(*true*) > > > which is called by MemoryManager::~MemoryManager() > > > which is called by ExecutionEngine::~ExecutionEngine() > > > which is called by QV8Engine::~QV8Engine() > > > which is called by QJSEngine::~QJSEngine() > > > which is called *after* QQmlEngine::~QQmlEngine() > > > > > > Check the call-stack: > > > 0 MyObject::~MyObject myobject.cpp 44 0x7fffd141eb4b > > > 1 MyObject::~MyObject myobject.cpp 46 0x7fffd141ec8a > > > 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > > qv4qobjectwrapper.cpp 1018 0x7ffff5f79ee1 f9ee33f96f9ee33f96 3 > > > (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > > qv4qobjectwrapper.cpp 1021 0x7ffff5f79f2e 4 > > > QV4::MemoryManager::sweep qv4mm.cpp 377 0x7ffff5efd080 > > > 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x7ffff5efda18 > > > 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 > > > 0x7ffff5ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 > > > 0x7ffff606b7f2 > > > 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7ffff606b87e > > > 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x7ffff5e64b1e > > > 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x7ffff5fb0b5d > > > 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x7ffff5fb0b8c > > > 12 QObjectPrivate::deleteChildren qobject.cpp 1943 0x7ffff599efd0 > > > 13 QObject::~QObject qobject.cpp 1034 0x7ffff599d760 > > > 14 QWindow::~QWindow qwindow.cpp 210 0x7ffff63f5bdc > > > 15 QQuickWindow::~QQuickWindow qquickwindow.cpp 1099 > > > 0x7ffff6bc0353 > > > 16 QQuickView::~QQuickView qquickview.cpp 220 0x7ffff6c9fe35 > > > 17 main main.cpp 12 0x4021fb > > > > > > IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved > > > after/in MemoryManager::~MemoryManager ... > > > > Ahh, so what you're talking about are the _JavaScript_ wrappers for the > > singletons, not the singleton objects themselves. That explains the > > confusion. > > > > Yes, due to the inheritance the final garbage collection runs as the very > > last step - and it has to, conceptually. I'm wondering: What code do you > > have running at that point that gets still called? Is it code in C++ > > destructors? > > > > > > > > > > > > > > Yes, the code from their destructors needs the singletons objects which > > are > > not available anymore. > > When are those destructors called? > > We need a little bit more information here, because it isn't obvious how to > solve this. There's naturally a pool of objects around that haven't been > garbage collected. On engine shutdown the garbage collector sweeps them all, > and there's naturally no way to define an order of destruction if you think > of such an environment. > > > > > > I know that there is a pool of active objects, what I think is wrong is to > delete the register singletons before you delete these objects. > > > The active objects destructors are called by MemoryManager::sweep. > These objects register themselves in the singleton object when they are > created and they must unregister themselves in the destructor when they > are deleted. But as you seen the singletons are deleted before, so there is > no way to properly unregister themselves! This is why I believe that the > singletons must be the very last objects that are deleted (just like in > any other languages). > > So, my proposal is to move the singletons deletion from > QmlEngine::~QQmlEngine():910 to another place which is called after > MemoryManager::sweep(*true*) is doing its job. > > I'd like to mention one more thing, the singletons and the other objects > are register in a standalone plugin. > > Please let me know if you need more info. I think I see what you mean now. The main issue I have with this is that it would break singletons written in QML. Just like C++ they may also have their Component.onDestruction handlers, and those would naturally not be callable anymore after such a move. Not calling those anymore would be a change in behavior. I'm not convinced that this is a change for the better TBH. Of course we could try to delete first the QML singletons, then the rest of the JavaScript world and then finally the C++ singletons. But you have to admit, that starting to feel like a bunch of hacks. Instead of relying on an order of destruction, why not reference your C++ object with a weak pointer? Simon From simon.hausmann at digia.com Thu Sep 25 07:55:50 2014 From: simon.hausmann at digia.com (Simon Hausmann) Date: Thu, 25 Sep 2014 07:55:50 +0200 Subject: [Development] Qml/JS QVariantMap conversion problem In-Reply-To: References: Message-ID: <8176947.az8NLE7Zlb@angrybird> On Wednesday, September 24, 2014 07:02:32 PM Nils Jeisecke wrote: > Hi! > > While porting to Qt5 I've stumbled over a very strange problem. > > QVariantMap objects mutate when transported from C++ via Qml back to C++. > > QVariant as constructed on the C++ side: > QVariant(QVariantMap, QMap(("x", QVariant(QStringList, ("a", "b")) ) ) ) > > QVariant when gone through Qml and handled back to C++: > QVariant(QVariantMap, QMap(("x", QVariant(QVariantMap, QMap(("0", > QVariant(QString, "a") ) ( "1" , QVariant(QString, "b") ) ) ) ) ) ) > > So what used to be a QStringList now is a QMap? > > This is: > a) not the behavior of Qt4/QtQuick 1 > b) pretty weird > > This does not happen if a QVariant directly wrapping a QStringList is > used, only when a QVariantMap is involved. > > Testcase: > > --main.cpp-- > > #include > #include > #include > #include > > class Dummy : public QObject > { > Q_OBJECT > public: > Dummy(QObject *parent = 0) : QObject(parent) {} > > Q_INVOKABLE void setMap(const QVariant &map) { > qDebug() << "setMap" << map; > } > > Q_INVOKABLE QVariant buildMap() const { > QVariantMap map; > map["x"] = QStringList() << "a" << "b"; > qDebug() << "buildMap" << QVariant(map); > return map; > } > }; > > int main(int argc, char *argv[]) > { > QApplication app(argc, argv); > QQmlApplicationEngine engine; > > engine.load(QUrl(QStringLiteral("qrc:/main.qml"))); > > Dummy *dummy = new Dummy; > engine.rootContext()->setContextProperty("dummy", dummy); > > return app.exec(); > } > #include "main.moc" > > --main.qml-- > > import QtQuick 2.3 > import QtQuick.Controls 1.2 > > ApplicationWindow { > visible: true > width: 640 > height: 480 > > Button { > text: "Mutate!" > onClicked: dummy.setMap(dummy.buildMap()); > } > } > > -------------------- > > Any ideas? Yeah, the variant conversions were iffy. When you put a QVariantMap or QVariantList into QML, we'll try to convert it to a JavaScript object. So a map["x"] = QStringList() << "a" << "b" becomes map = { x: [ "a", "b" ] } So I think that part is fine. The conversion back is something that's been lossy in the past, like in your case and many other reported bugs. We've changed this in Qt 5.4 slightly: When converting a JavaScript object back to a QVariant, we won't try to "destroy" it but instead we'll give you a QVariant that holds a (strong) reference to the JavaScript object, it'll be a QJSValue in a QVariant. Note how somebody could call setMap with the return value of buildMap() but also with a JS object literal: setMap( { x: ["a", "b" ] }) So in Qt 5.4 you'll get a QVariant with a QJSValue inside, and if you extract that and _explicitly_ convert it to a QVariant, then you'll get what you expect: QVariant(QVariantMap, QMap(("x", QVariant(QStringList, ("a", "b")) ) ) ) You can do the conversion like this: QVariant map = ... if (map.userType() == qMetaTypeId()) map = qvariant_cast(map).toVariant(); Hope this helps, Simon From bog_dan_ro at yahoo.com Thu Sep 25 08:10:01 2014 From: bog_dan_ro at yahoo.com (BogDan) Date: Wed, 24 Sep 2014 23:10:01 -0700 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: <1590984.Ktr0Ibkj0x@angrybird> References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> <1691425.eGisNBzUG3@rhea> <1411378086.34723.YahooMailNeo@web126105.mail.ne1.yahoo.com> <1590984.Ktr0Ibkj0x@angrybird> Message-ID: <1411625401.39563.YahooMailNeo@web126105.mail.ne1.yahoo.com> ----- Original Message ----- From: Simon Hausmann To: BogDan Cc: Chris Adams ; Qt Development Group Sent: Thursday, September 25, 2014 8:34 AM Subject: Re: SV: [Development] [QML] Singletons are deleted before the other objects On Monday, September 22, 2014 02:28:06 AM BogDan wrote: > ----- Original Message ----- > From: Simon Hausmann > To: BogDan > Cc: Chris Adams ; Qt Development Group > Sent: Monday, September 22, 2014 11:56 AM > Subject: Re: SV: [Development] [QML] Singletons are deleted before the > other objects > On Monday 22. September 2014 01.33.14 BogDan wrote: > > On Monday 22. September 2014 01.19.17 BogDan wrote: > > > Hi Simon, > > > > > > I took a look and I'm pretty sure I'm right ;-). BTW I'm using 5.4 > > > branch (sha1 f9ee33f96), is a little bit old, but I bet nobody > > > fixed it. The same problem is in previous releases. > > > > > > So, the singletons are deleted in QQmlEngine::~QQmlEngine():910 > > > The other active objects are deleted in MemoryManager::sweep(*true*) > > > which is called by MemoryManager::~MemoryManager() > > > which is called by ExecutionEngine::~ExecutionEngine() > > > which is called by QV8Engine::~QV8Engine() > > > which is called by QJSEngine::~QJSEngine() > > > which is called *after* QQmlEngine::~QQmlEngine() > > > > > > Check the call-stack: > > > 0 MyObject::~MyObject myobject.cpp 44 0x7fffd141eb4b > > > 1 MyObject::~MyObject myobject.cpp 46 0x7fffd141ec8a > > > 2 (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > > qv4qobjectwrapper.cpp 1018 0x7ffff5f79ee1 f9ee33f96f9ee33f96 3 > > > (anonymous namespace)::QObjectDeleter::~QObjectDeleter > > > qv4qobjectwrapper.cpp 1021 0x7ffff5f79f2e 4 > > > QV4::MemoryManager::sweep qv4mm.cpp 377 0x7ffff5efd080 > > > 5 QV4::MemoryManager::~MemoryManager qv4mm.cpp 515 0x7ffff5efda18 > > > 6 QV4::ExecutionEngine::~ExecutionEngine qv4engine.cpp 421 > > > 0x7ffff5ee4f54 7 QV8Engine::~QV8Engine qv8engine.cpp 116 > > > 0x7ffff606b7f2 > > > 8 QV8Engine::~QV8Engine qv8engine.cpp 117 0x7ffff606b87e > > > 9 QJSEngine::~QJSEngine qjsengine.cpp 203 0x7ffff5e64b1e > > > 10 QQmlEngine::~QQmlEngine qqmlengine.cpp 893 0x7ffff5fb0b5d > > > 11 QQmlEngine::~QQmlEngine qqmlengine.cpp 916 0x7ffff5fb0b8c > > > 12 QObjectPrivate::deleteChildren qobject.cpp 1943 0x7ffff599efd0 > > > 13 QObject::~QObject qobject.cpp 1034 0x7ffff599d760 > > > 14 QWindow::~QWindow qwindow.cpp 210 0x7ffff63f5bdc > > > 15 QQuickWindow::~QQuickWindow qquickwindow.cpp 1099 > > > 0x7ffff6bc0353 > > > 16 QQuickView::~QQuickView qquickview.cpp 220 0x7ffff6c9fe35 > > > 17 main main.cpp 12 0x4021fb > > > > > > IMHO the sequence from QQmlEngine::~QQmlEngine():910 should be moved > > > after/in MemoryManager::~MemoryManager ... > > > > Ahh, so what you're talking about are the _JavaScript_ wrappers for the > > singletons, not the singleton objects themselves. That explains the > > confusion. > > > > Yes, due to the inheritance the final garbage collection runs as the very > > last step - and it has to, conceptually. I'm wondering: What code do you > > have running at that point that gets still called? Is it code in C++ > > destructors? > > > > > > > > > > > > > > Yes, the code from their destructors needs the singletons objects which > > are > > not available anymore. > > When are those destructors called? > > We need a little bit more information here, because it isn't obvious how to > solve this. There's naturally a pool of objects around that haven't been > garbage collected. On engine shutdown the garbage collector sweeps them all, > and there's naturally no way to define an order of destruction if you think > of such an environment. > > > > > > I know that there is a pool of active objects, what I think is wrong is to > delete the register singletons before you delete these objects. > > > The active objects destructors are called by MemoryManager::sweep. > These objects register themselves in the singleton object when they are > created and they must unregister themselves in the destructor when they > are deleted. But as you seen the singletons are deleted before, so there is > no way to properly unregister themselves! This is why I believe that the > singletons must be the very last objects that are deleted (just like in > any other languages). > > So, my proposal is to move the singletons deletion from > QmlEngine::~QQmlEngine():910 to another place which is called after > MemoryManager::sweep(*true*) is doing its job. > > I'd like to mention one more thing, the singletons and the other objects > are register in a standalone plugin. > > Please let me know if you need more info. I think I see what you mean now. The main issue I have with this is that it would break singletons written in QML. Just like C++ they may also have their Component.onDestruction handlers, and those would naturally not be callable anymore after such a move. Not calling those anymore would be a change in behavior. I'm not convinced that this is a change for the better TBH. Of course we could try to delete first the QML singletons, then the rest of the JavaScript world and then finally the C++ singletons. But you have to admit, that starting to feel like a bunch of hacks. Instead of relying on an order of destruction, why not reference your C++ object with a weak pointer? Hi, Do we all agree that the singletons, by definition, must be available to any object at any time until the end of the application? IMHO deleting first the QML singletons then the rest of the Active objects is also wrong, because some of the active objects might need these singletons. I think the right way is to delete all the active objects first, then QML singletons, try delete again all the active objects (supposing that the QML singletons will create new objects in Component.onDestruction), then at the very end, all the C++ singletons. IMHO this is the right way to do it, and is not a hack at all. Doing something right, even if it's harder, is not a hack ... I don't see how using a weak pointer will fix the problem, who will delete the singleton object in the end? IMHO this is a hack! I can't reference it for every object that depends on it, because, BTW, there are cases when the VM doesn't delete all the objects! Yes it has lots of memleaks at the end! Cheers, BogDan. From Morten.Sorvig at digia.com Thu Sep 25 09:19:27 2014 From: Morten.Sorvig at digia.com (Sorvig Morten) Date: Thu, 25 Sep 2014 07:19:27 +0000 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> <1A220DD3-4E85-47DF-9192-5658B73B1000@digia.com> Message-ID: <81539A6A-1E84-4DEC-9EAE-350437EA033B@digia.com> > On 24 Sep 2014, at 16:17, Alexander Ilyin wrote: > > CODESIGN FAILED WITH MESSAGE "unsealed contents present in the root > directory of an embedded framework In subcomponent: > /Developer/res-plan/bin/s-test.app/Contents/Frameworks/QtCore.framework" > (Please look at the listing below) > > I also tried codesign without --depp - no success. > > Could you give me simple instruction - how to fix the problem manually > and sign the app to be accepted by OS X 10.9.5 and later? > Or I have to wait for an update of Qt 4.8? Is there a “QtCore.prl” at the root of the framework? If so then remove it. Morten From ip.alexander.ilyin at gmail.com Thu Sep 25 09:41:39 2014 From: ip.alexander.ilyin at gmail.com (Alexander Ilyin) Date: Thu, 25 Sep 2014 07:41:39 +0000 (UTC) Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> <1A220DD3-4E85-47DF-9192-5658B73B1000@digia.com> <81539A6A-1E84-4DEC-9EAE-350437EA033B@digia.com> Message-ID: Sorvig Morten digia.com> writes: > > Is there a “QtCore.prl” at the root of the framework? If so then remove it. > > Morten > > > _______________________________________________ > Development mailing list > Development qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > Hi Morten, There is no QtCore.prl in the framework. From jeisecke at saltation.de Thu Sep 25 09:44:51 2014 From: jeisecke at saltation.de (Nils Jeisecke) Date: Thu, 25 Sep 2014 09:44:51 +0200 Subject: [Development] Qml/JS QVariantMap conversion problem In-Reply-To: <8176947.az8NLE7Zlb@angrybird> References: <8176947.az8NLE7Zlb@angrybird> Message-ID: Hi Simon, thank you very much for the explanation. No need for bug hunting then. On Thu, Sep 25, 2014 at 7:55 AM, Simon Hausmann wrote: > We've changed this in Qt 5.4 slightly: When > converting a JavaScript object back to a QVariant, we won't try to "destroy" > it but instead we'll give you a QVariant that holds a (strong) reference to > the JavaScript object, it'll be a QJSValue in a QVariant. Note how somebody > could call setMap with the return value of buildMap() but also with a JS > object literal: setMap( { x: ["a", "b" ] }) > > QVariant(QVariantMap, QMap(("x", QVariant(QStringList, ("a", "b")) ) ) ) > > You can do the conversion like this: > > QVariant map = ... > if (map.userType() == qMetaTypeId()) > map = qvariant_cast(map).toVariant(); I think this should be added to the documentation. Maybe here: http://doc-snapshot.qt-project.org/qt5-5.4/qtqml-cppintegration-data.html. I'd give it a try if this is the right place. This is very important to know especially if you use Qml only as glue to directly bind C++ objects properties. I wasn't aware that this also involves two (in this use case unwanted) conversions (C++ -> JS -> C++). Nils From simon.hausmann at digia.com Thu Sep 25 09:48:13 2014 From: simon.hausmann at digia.com (Simon Hausmann) Date: Thu, 25 Sep 2014 09:48:13 +0200 Subject: [Development] Qml/JS QVariantMap conversion problem In-Reply-To: References: <8176947.az8NLE7Zlb@angrybird> Message-ID: <2022856.AGLp98Xlhv@rhea> On Thursday 25. September 2014 09.44.51 Nils Jeisecke wrote: > Hi Simon, > > thank you very much for the explanation. No need for bug hunting then. > > On Thu, Sep 25, 2014 at 7:55 AM, Simon Hausmann > > wrote: > > We've changed this in Qt 5.4 slightly: When > > converting a JavaScript object back to a QVariant, we won't try to > > "destroy" it but instead we'll give you a QVariant that holds a (strong) > > reference to the JavaScript object, it'll be a QJSValue in a QVariant. > > Note how somebody could call setMap with the return value of buildMap() > > but also with a JS object literal: setMap( { x: ["a", "b" ] }) > > > > QVariant(QVariantMap, QMap(("x", QVariant(QStringList, ("a", "b")) ) ) > > ) > > > > You can do the conversion like this: > > QVariant map = ... > > if (map.userType() == qMetaTypeId()) > > > > map = qvariant_cast(map).toVariant(); > > I think this should be added to the documentation. Maybe here: > http://doc-snapshot.qt-project.org/qt5-5.4/qtqml-cppintegration-data.html. > I'd give it a try if this is the right place. Yes, that looks like the right place. Simon From Lars.Knoll at digia.com Thu Sep 25 12:17:25 2014 From: Lars.Knoll at digia.com (Knoll Lars) Date: Thu, 25 Sep 2014 10:17:25 +0000 Subject: [Development] Platform maintainers Message-ID: Hi, There are currently a few empty spots in our maintainer list, and I’d like to fill them again and make that list more complete before we have 5.4 out. To start with, I’d like to pick up a topic that had been discussed in the past without reaching a conclusion. It is about having platform maintainers. We currently have a lot of maintainers for different subsystems in Qt, but nobody with a clear formal responsibility of ensuring that Qt runs well on a certain platform/operating system. I think we should change that as Qt does contain sizeable pieces of platform dependent code in Qt. In the QPA plugins and the platform dependent implementations in qtbase. In styles and backends for things such as sensors. We can also clearly see that not everybody can test on all platforms, and we need to have a point of contact when it comes to helping getting things working on a specific platform. To make it explicit, I’d like to propose the following people as Maintainers for different platforms: Windows: Friedemann WinRT: Andrew Knight OS X: Morten Linux (X11): Jørgen Lind Linux (Wayland): Already covered by Andy Nichols iOS: Tor Arne Android: Bogdan Windows CE: Björn Breitmeyer QNX is open for the moment, I’d love to hear proposals. Most of the people above have been acting as a platform maintainer in practice, so this is mostly about formalising the responsibility and giving them proper recognition. Cheers, Lars From robertknight at gmail.com Thu Sep 25 12:33:44 2014 From: robertknight at gmail.com (Robert Knight) Date: Thu, 25 Sep 2014 11:33:44 +0100 Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes In-Reply-To: References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> <1A220DD3-4E85-47DF-9192-5658B73B1000@digia.com> <81539A6A-1E84-4DEC-9EAE-350437EA033B@digia.com> Message-ID: Hi Alexander, See the 'fixup_framework_bundle' function in https://github.com/Mendeley/Mac-OS-X-Bundle-Utilities/blob/master/hdiutil-codesign.rb for code which can fix a Qt bundle. In short: - There should be no files in the root of the 'Qt.framework' directory other than a 'Versions' directory, a symlink called 'QtModuleName' which points to 'Versions//QtModuleName' and a symlink called 'Resources' which points to 'Versions//Resources' - There should be an Info.plist file in 'Versions//Resources'. This should be moved from Contents/Info.plist if found there. Regards, Rob. On 25 September 2014 08:41, Alexander Ilyin wrote: > Sorvig Morten digia.com> writes: > >> >> Is there a “QtCore.prl” at the root of the framework? If so then remove it. >> >> Morten >> >> >> _______________________________________________ >> Development mailing list >> Development qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > Hi Morten, > There is no QtCore.prl in the framework. > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From daniel.teske at digia.com Thu Sep 25 12:47:03 2014 From: daniel.teske at digia.com (Daniel Teske) Date: Thu, 25 Sep 2014 12:47:03 +0200 Subject: [Development] Platform maintainers In-Reply-To: References: Message-ID: <1575973.ezQ9lca0b1@marvin> > To make it explicit, I’d like to propose the following people as > Maintainers for different platforms: > > Android: Bogdan +1 daniel From ip.alexander.ilyin at gmail.com Thu Sep 25 13:07:06 2014 From: ip.alexander.ilyin at gmail.com (Alexander Ilyin) Date: Thu, 25 Sep 2014 11:07:06 +0000 (UTC) Subject: [Development] Important OSX 10.9.5 & 10.10 codesign changes References: <48B84BD5-7566-4E87-8605-76F9C871E3A5@metsma.ee> <868D95B1-942C-4C3A-BB3D-AF9F7C166930@java.pl> <277B9377-3A29-4180-8497-53B977A82A65@digia.com> <1A220DD3-4E85-47DF-9192-5658B73B1000@digia.com> <81539A6A-1E84-4DEC-9EAE-350437EA033B@digia.com> Message-ID: Robert Knight gmail.com> writes: > > Hi Alexander, > > See the 'fixup_framework_bundle' function in > https://github.com/Mendeley/Mac-OS-X-Bundle-Utilities/blob/master/ hdiutil-codesign.rb > for code which can fix a Qt bundle. > > In short: > - There should be no files in the root of the > 'Qt.framework' directory other than a 'Versions' > directory, a symlink called 'QtModuleName' which points to > 'Versions//QtModuleName' and a symlink called 'Resources' > which points to 'Versions//Resources' > - There should be an Info.plist file in > 'Versions//Resources'. This should be moved from > Contents/Info.plist if found there. > > Regards, > Rob. > > On 25 September 2014 08:41, Alexander Ilyin > gmail.com> wrote: > > Sorvig Morten digia.com> writes: > > > >> > >> Is there a “QtCore.prl” at the root of the framework? If so then remove it. > >> > >> Morten > >> > >> > >> _______________________________________________ > >> Development mailing list > >> Development qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > >> > > > > Hi Morten, > > There is no QtCore.prl in the framework. > > Hi Rob, Thank you for the answer. I have the following structure (which seems me right after reading https://developer.apple.com/library/mac/documentation/MacOSX/ Conceptual/BPFrameworks/Concepts/FrameworkAnatomy.html): QtCore.framework/ QtCore -> Versions/Current/QtCore Resources -> Versions/Current/Resources Versions/ 4/ QtCore Resources/ Info.plist Current -> 4 From ymarcov at gmail.com Thu Sep 25 13:14:07 2014 From: ymarcov at gmail.com (Yam Marcovic) Date: Thu, 25 Sep 2014 14:14:07 +0300 Subject: [Development] Contribution proposal: Dispatcher class In-Reply-To: References: Message-ID: But say, if I want to submit this as part of QtCore, doesn't that package use one consistent license which I'll have to use? On Sep 24, 2014 3:05 PM, "Tomasz Siekierda" wrote: > On 24 September 2014 11:34, Sune Vuorela wrote: > > On 2014-09-24, Yam Marcovic wrote: > >> However, I will say I don't want to force people to give their sources > away > >> if they use it. > >> > >> So a license along the lines of 'this license is here for formal > purposes; > >> but feel free to do anything you want with this,' is good enough as far > as > >> I'm concerned. > > > > I think the formal way of expressing this is either the MIT, 2 or > > 3-clause BSD licenses. > > > > http://opensource.org/licenses/BSD-3-Clause > > http://opensource.org/licenses/BSD-2-Clause > > http://opensource.org/licenses/mit-license.html > > > > /Sune > > This is probably the simplest you can go: WTFPL > http://www.wtfpl.net/about/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Thu Sep 25 14:14:58 2014 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 25 Sep 2014 14:14:58 +0200 Subject: [Development] Contribution proposal: Dispatcher class In-Reply-To: References: Message-ID: <94137259.4qBT9io4hv@finn> On Saturday 20 September 2014 12:41:07 Yam Marcovic wrote: > Hello, > > In my company, we started getting all tangled up with loads of signals and > slots for many components. We also have a habit of renaming things as time > goes by, and that can also pose a bit of a problem when dealing with > signals & slots, meta object based invocations, etc. > > So, since our compiler supports the relevant features of C++11, I've made > this class, called Dispatcher, which allowed us to develop multi-threaded > apps much more easily. Instead of defining many signals and slots, you > simply make your component extend QObject, and then, since you can use it > with Qt's multi-threading framework, you can use it with the dispatcher. > > Here's the link to my repository on GitHub. It also gives a small usage > example. > > https://github.com/ymarcov/qtdispatcher > > Note that I've striven to make it as correct as possible. E.g. if the > return value is a reference, then you really get that reference, not a copy > of it, and same with pointers. Or if it's by value, and the returned object > has a move constructor, then it will be used. Stuff like that. It's been > working very well for quite some time now in my workplace, and used in > quite critical areas of the code with much success. > > Please let me know if you think this could help the Qt project as a > built-in class. > > With best wishes, > Yam Marcovic Hi, I think if this feature would be added to QtCore, it should be by extending QMetaObject::invoke to work with functors. By using Qt::BlockingQueuedConnection that would be very similar to what you have done. Regards, -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From bjornpiltz at gmail.com Thu Sep 25 14:45:03 2014 From: bjornpiltz at gmail.com (=?UTF-8?B?QmrDtnJuIFBpbHR6?=) Date: Thu, 25 Sep 2014 14:45:03 +0200 Subject: [Development] Contribution proposal: Dispatcher class In-Reply-To: <94137259.4qBT9io4hv@finn> References: <94137259.4qBT9io4hv@finn> Message-ID: So let's all upvote https://bugreports.qt-project.org/browse/QTBUG-37253. BTW, the way you've implemented the Dispatcher constructor is off. You can't give it a parent from another thread. You should use QObject::moveToThread() instead. Björn 2014-09-25 14:14 GMT+02:00 Olivier Goffart : > On Saturday 20 September 2014 12:41:07 Yam Marcovic wrote: > > Hello, > > > > In my company, we started getting all tangled up with loads of signals > and > > slots for many components. We also have a habit of renaming things as > time > > goes by, and that can also pose a bit of a problem when dealing with > > signals & slots, meta object based invocations, etc. > > > > So, since our compiler supports the relevant features of C++11, I've made > > this class, called Dispatcher, which allowed us to develop multi-threaded > > apps much more easily. Instead of defining many signals and slots, you > > simply make your component extend QObject, and then, since you can use it > > with Qt's multi-threading framework, you can use it with the dispatcher. > > > > Here's the link to my repository on GitHub. It also gives a small usage > > example. > > > > https://github.com/ymarcov/qtdispatcher > > > > Note that I've striven to make it as correct as possible. E.g. if the > > return value is a reference, then you really get that reference, not a > copy > > of it, and same with pointers. Or if it's by value, and the returned > object > > has a move constructor, then it will be used. Stuff like that. It's been > > working very well for quite some time now in my workplace, and used in > > quite critical areas of the code with much success. > > > > Please let me know if you think this could help the Qt project as a > > built-in class. > > > > With best wishes, > > Yam Marcovic > > Hi, > > I think if this feature would be added to QtCore, it should be by extending > QMetaObject::invoke to work with functors. > By using Qt::BlockingQueuedConnection that would be very similar to what > you > have done. > > Regards, > -- > Olivier > > Woboq - Qt services and support - http://woboq.com - http://code.woboq.org > > _______________________________________________ > 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.hartmetz at kdab.com Thu Sep 25 15:12:01 2014 From: andreas.hartmetz at kdab.com (Andreas Hartmetz) Date: Thu, 25 Sep 2014 15:12:01 +0200 Subject: [Development] Making FreeType and platform-independent HarfBuzz-NG available on all platforms Message-ID: <7801883.9loyKkBCiR@z25> Hello, we have a customer who is interested (among possibly other font rendering improvements) in using the same high-quality font stack on all platforms, for which HarfBuzz-NG / FreeType is the obvious candidate. I wonder if patches to do that would be accepted. It seems fairly uncontroversial to me, but you never know. Note that, while FreeType is already available on Windows, it needs a lot of polishing to look as good as on Linux. It seems like rasterization is done by FreeType in that FreeType/Windows case, but for shaping HarfBuzz uses input (basically glyph bounding boxes) from Windows API, which causes things like cut-off glyphs because the two APIs don't quite agree about the metrics. Some additional CI capacity might be required to test it on OSX - there is a bit of a conflict insofar that it's easier to make it a compile- time option: on OSX things are curently pretty hard-wired to CoreText, including in HarfBuzz-NG itself, but that requires far more CPU power to test due to the need to compile another configuration. Does anyone have any ideas for solving this? Cheers, Andreas -- Andreas Hartmetz | andreas.hartmetz 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4785 bytes Desc: not available URL: From ymarcov at gmail.com Thu Sep 25 15:55:24 2014 From: ymarcov at gmail.com (Yam Marcovic) Date: Thu, 25 Sep 2014 16:55:24 +0300 Subject: [Development] Contribution proposal: Dispatcher class In-Reply-To: <94137259.4qBT9io4hv@finn> References: <94137259.4qBT9io4hv@finn> Message-ID: Technically it sounds good to me. But would it be consistent with the responsibility of QMetaObject? It doesn't use any metadata from the object passed, unlike the other overloads. On Sep 25, 2014 3:14 PM, "Olivier Goffart" wrote: > On Saturday 20 September 2014 12:41:07 Yam Marcovic wrote: > > Hello, > > > > In my company, we started getting all tangled up with loads of signals > and > > slots for many components. We also have a habit of renaming things as > time > > goes by, and that can also pose a bit of a problem when dealing with > > signals & slots, meta object based invocations, etc. > > > > So, since our compiler supports the relevant features of C++11, I've made > > this class, called Dispatcher, which allowed us to develop multi-threaded > > apps much more easily. Instead of defining many signals and slots, you > > simply make your component extend QObject, and then, since you can use it > > with Qt's multi-threading framework, you can use it with the dispatcher. > > > > Here's the link to my repository on GitHub. It also gives a small usage > > example. > > > > https://github.com/ymarcov/qtdispatcher > > > > Note that I've striven to make it as correct as possible. E.g. if the > > return value is a reference, then you really get that reference, not a > copy > > of it, and same with pointers. Or if it's by value, and the returned > object > > has a move constructor, then it will be used. Stuff like that. It's been > > working very well for quite some time now in my workplace, and used in > > quite critical areas of the code with much success. > > > > Please let me know if you think this could help the Qt project as a > > built-in class. > > > > With best wishes, > > Yam Marcovic > > Hi, > > I think if this feature would be added to QtCore, it should be by extending > QMetaObject::invoke to work with functors. > By using Qt::BlockingQueuedConnection that would be very similar to what > you > have done. > > Regards, > -- > Olivier > > Woboq - Qt services and support - http://woboq.com - http://code.woboq.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ritt.ks at gmail.com Thu Sep 25 16:00:15 2014 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Thu, 25 Sep 2014 18:00:15 +0400 Subject: [Development] Making FreeType and platform-independent HarfBuzz-NG available on all platforms In-Reply-To: <7801883.9loyKkBCiR@z25> References: <7801883.9loyKkBCiR@z25> Message-ID: Hi, 2014-09-25 17:12 GMT+04:00 Andreas Hartmetz : > Hello, > > we have a customer who is interested (among possibly other font > rendering improvements) in using the same high-quality font stack on all > platforms, for which HarfBuzz-NG / FreeType is the obvious candidate. I > wonder if patches to do that would be accepted. It seems fairly > uncontroversial to me, but you never know. Of course. Feel free to add me to the reviewers list. > Note that, while FreeType is already available on Windows, it needs a > lot of polishing to look as good as on Linux. It seems like > rasterization is done by FreeType in that FreeType/Windows case, but for > shaping HarfBuzz uses input (basically glyph bounding boxes) from > Windows API, which causes things like cut-off glyphs because the two > APIs don't quite agree about the metrics. That's probably the main reason why we don't use FT on all platforms by default. > Some additional CI capacity might be required to test it on OSX - there > is a bit of a conflict insofar that it's easier to make it a compile- > time option: on OSX things are curently pretty hard-wired to CoreText, > including in HarfBuzz-NG itself, but that requires far more CPU power to > test due to the need to compile another configuration. Does anyone have > any ideas for solving this? > > Cheers, > Andreas > > -- > Andreas Hartmetz | andreas.hartmetz 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 > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > Regards, Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From private at bernhard-lindner.de Thu Sep 25 16:07:17 2014 From: private at bernhard-lindner.de (private at bernhard-lindner.de) Date: Thu, 25 Sep 2014 14:07:17 +0000 Subject: [Development] Contribution proposal: Dispatcher class In-Reply-To: <94137259.4qBT9io4hv@finn> References: <94137259.4qBT9io4hv@finn> Message-ID: <20140925140717.Horde.JjABT9zOf3vnMfPa95Asjw1@sam.ourport.de> > I think if this feature would be added to QtCore, it should be by extending > QMetaObject::invoke to work with functors. > By using Qt::BlockingQueuedConnection that would be very similar to what you > have done. I reported this before in Qt issue tracker. I would really like to see this implemented. -- Regards Bernhard Lindner From thiago.macieira at intel.com Thu Sep 25 18:26:29 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 Sep 2014 09:26:29 -0700 Subject: [Development] Platform maintainers In-Reply-To: References: Message-ID: <15019545.iRDbyiQlQL@tjmaciei-mobl4> On Thursday 25 September 2014 10:17:25 Knoll Lars wrote: > Windows: Friedemann > WinRT: Andrew Knight > OS X: Morten > Linux (X11): Jørgen Lind > Linux (Wayland): Already covered by Andy Nichols > iOS: Tor Arne > Android: Bogdan > Windows CE: Björn Breitmeyer > > QNX is open for the moment, I’d love to hear proposals. > > Most of the people above have been acting as a platform maintainer in > practice, so this is mostly about formalising the responsibility and > giving them proper recognition. Agreed, most of them are already acting as Maintainers anyway, which is the usual requirement for them to become Maintainers anyway. At the very least, I can directly confirm Friedemann, Andrew, Tor Arne, Bogdan and Björn have done that work, as I've sent a few patches their way for those platforms and they were readily acted on. Moreover, I know Morten, Jørgen and Andy personally, and a quick git log shows they've been active. (Wayland being the easiest, since it's a separate repo: of the last 200 commits, 140 were reviewed by Andy) Therefore, I give my Maintainer +1 on all nominations. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Thu Sep 25 19:52:29 2014 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 25 Sep 2014 14:52:29 -0300 Subject: [Development] Making FreeType and platform-independent HarfBuzz-NG available on all platforms In-Reply-To: <7801883.9loyKkBCiR@z25> References: <7801883.9loyKkBCiR@z25> Message-ID: <4526499.0GY38VdVcj@tonks> On Thursday 25 September 2014 15:12:01 Andreas Hartmetz wrote: > Hello, > > we have a customer who is interested (among possibly other font > rendering improvements) in using the same high-quality font stack on all > platforms, for which HarfBuzz-NG / FreeType is the obvious candidate. I > wonder if patches to do that would be accepted. It seems fairly > uncontroversial to me, but you never know. FWIW we in Debian have been building Qt5 against system's harfbuzz-ng since quite some time. A few bug appeared (in webkit iirc) but where promptly fixed by the relevant maintainers. So I think it's simply straightforward to do. -- Evite los parámetros estáticos. Si son inevitables, haga que el emisor y el receptor negocien un valor. Andrew S. Tanenbaum, de su libro "Computer Networks" Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From tcanabrava at kde.org Thu Sep 25 21:33:12 2014 From: tcanabrava at kde.org (Tomaz Canabrava) Date: Thu, 25 Sep 2014 16:33:12 -0300 Subject: [Development] Start of a refactor of the QSettings class based on QJson Message-ID: Long that that I have send this e-mail already, but better late than never. In the Qt Develompent Summit I raised my hand to get one dirty thing done: The Settings. After a good while with negative time ( Real Work, KDE, Subsurface, and other personal stuff ) I have finally had the time to start. For now, I'v implemented two things: Parsing from .ini to QJson Saving from QJson to .ini Why .ini instead of json, since I'm doing a conversion and I coul'd simply store the json file? .ini is better to humanreadability. thiago asked me to do from ini to qjson Issues: After a Json tree is constructed, it's hard to modify it's contents: QJsonObject rootConfig; rootConfig.insert("group1", QJsonObject()); rootConfig.insert("group2", QJsonObject()); QJsonObject group1 = rootConfig.vaule("group1").toObject(); group1.insert("key1", 1); rootConfig.insert("group1", group1); since I need to take the value, modify it, insert it back nested groups are a pain to use, because I would have to chain the removal / addtion of the parent group untill I hit the rootGroup. what I plan to do, besides that: - changed the config file from outside of the app, the app should reload it's settings. - compile-time check of typos in keys based on a schema ( and not runtime. ) Help is appreciated, and comments welcome. the *temporary* repo with the *temporary and somewhat broken* code: github.com:tcanabrava/QConfigNG -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy.k.list at gmail.com Thu Sep 25 23:51:05 2014 From: jeremy.k.list at gmail.com (Jeremy) Date: Thu, 25 Sep 2014 14:51:05 -0700 Subject: [Development] Start of a refactor of the QSettings class based on QJson In-Reply-To: References: Message-ID: On 5September2014, at 12:33, Tomaz Canabrava wrote: > Long that that I have send this e-mail already, but better late than never. > In the Qt Develompent Summit I raised my hand to get one dirty thing done: > > The Settings. > The general idea appeals to me. > After a good while with negative time ( Real Work, KDE, Subsurface, and other personal stuff ) I have finally had the time to start. > > For now, I'v implemented two things: > > Parsing from .ini to QJson > Saving from QJson to .ini > > Why .ini instead of json, since I'm doing a conversion and I coul'd simply store the json file? > > .ini is better to humanreadability. > thiago asked me to do from ini to qjson Binary compatibility requires that QSettings for 5.x continue to handle .ini files for all existing functions. Adding json for 5.5 should be fine. > > Issues: > > After a Json tree is constructed, it's hard to modify it's contents: > > QJsonObject rootConfig; > rootConfig.insert("group1", QJsonObject()); > rootConfig.insert("group2", QJsonObject()); > > QJsonObject group1 = rootConfig.vaule("group1").toObject(); > group1.insert("key1", 1); > rootConfig.insert("group1", group1); > > since I need to take the value, modify it, insert it back nested groups are a pain to use, > because I would have to chain the removal / addtion of the parent group untill I hit the rootGroup. > QJsonDocument doc = QJsonDocument::fromJson("{ \"name\": \"object\"}"); QJsonObject obj = doc.object(); QJsonValueRef ref = obj["name”]; ref = "object2”; doc.setObject(obj); > what I plan to do, besides that: > - changed the config file from outside of the app, the app should reload it's settings. What’s the intended change detection mechanism? If it’s a file change, there’s the issue of incomplete updates to handle. I suppose it could ignore anything other than an valid JSON, empty files, and deleted files under the theory that edits of a single entry are less likely to produce valid interim results. Will changes be announced at the document level, or more fine grained? I think anything beyond the document level is asking for trouble. > - compile-time check of typos in keys based on a schema ( and not runtime. ) > > Help is appreciated, and comments welcome. > > the *temporary* repo with the *temporary and somewhat broken* code: > github.com:tcanabrava/QConfigNG > From thiago.macieira at intel.com Fri Sep 26 00:31:11 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 Sep 2014 15:31:11 -0700 Subject: [Development] Start of a refactor of the QSettings class based on QJson In-Reply-To: References: Message-ID: <2685671.53b59zMXma@tjmaciei-mobl4> On Thursday 25 September 2014 16:33:12 Tomaz Canabrava wrote: > Long that that I have send this e-mail already, but better late than never. > In the Qt Develompent Summit I raised my hand to get one dirty thing done: > > The Settings. > > After a good while with negative time ( Real Work, KDE, Subsurface, and > other personal stuff ) I have finally had the time to start. > > For now, I'v implemented two things: > > Parsing from .ini to QJson > Saving from QJson to .ini > > Why .ini instead of json, since I'm doing a conversion and I coul'd simply > store the json file? > > .ini is better to humanreadability. > thiago asked me to do from ini to qjson Tomaz forgot a bit of the rationale for this. We want to have our cake and eat it too: we want both the ability to edit config files by hand and the speed of QJsonDocument. So we have a bunch of INI- style files that cascade their settings like the XDG Desktop file format, hopefully, are backwards compatible with QSettings, and can be edit by hand. Upon reading them, we save a cache of the settings in a binary JSON format. That file is not hand-editable and we should not have to write a tool to manipulate it. The file needs to contain the names of the source INI files it is a cache of and their timestamps, so that hand editing of the sources invalidates the cache. It means, however, that saving the settings saves at least two files and cannot be done atomically. That's where QLockFile should come in handy. > After a Json tree is constructed, it's hard to modify it's contents: > > QJsonObject rootConfig; > rootConfig.insert("group1", QJsonObject()); > rootConfig.insert("group2", QJsonObject()); > > QJsonObject group1 = rootConfig.vaule("group1").toObject(); > group1.insert("key1", 1); > rootConfig.insert("group1", group1); > > since I need to take the value, modify it, insert it back nested groups are > a pain to use, > because I would have to chain the removal / addtion of the parent group > untill I hit the rootGroup. Tomaz is planning to use the JSON classes as in-memory storage too, which may or may not be the best solution. I can think of three possibilities: 1) use QJsonDocument & family all the way, which means figuring out a solution to the above problem 2) use QJsonDocument only to read the on-disk cache, then keep an in-memory cache using a different storage mechanism (probably based on QVariantHash). 3) use a hybrid approach: use QJsonDocument for reading the cache and keep *that* cache in memory, but keep modifications separate, sync'ing the two storages only at the time the file actually gets saved. I think we will probably need #3 anyway so that we don't write *all* value entries to the the human-readable INI, only those that were modified from the original. > what I plan to do, besides that: > - changed the config file from outside of the app, the app should reload > it's settings. Separate class, but yes, this is needed for GNOME- and OS X-style configuration mechanisms where changes are applied immediately upon change in the UI and propagate to all applications. I'm not sure we should Qt hide this on a platform config, but it's something we should think about. > - compile-time check of typos in keys based on a schema ( and not runtime. ) Leave schema for a second version and focus on getting the storage right first. > the *temporary* repo with the *temporary and somewhat broken* code: > github.com:tcanabrava/QConfigNG https://github.com/tcanabrava/QConfigNG We can't it access via SSH because we're not you. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Eike.Ziller at digia.com Fri Sep 26 08:32:58 2014 From: Eike.Ziller at digia.com (Ziller Eike) Date: Fri, 26 Sep 2014 06:32:58 +0000 Subject: [Development] Contribution proposal: Dispatcher class In-Reply-To: <20140925140717.Horde.JjABT9zOf3vnMfPa95Asjw1@sam.ourport.de> References: <94137259.4qBT9io4hv@finn> <20140925140717.Horde.JjABT9zOf3vnMfPa95Asjw1@sam.ourport.de> Message-ID: <15954BEC-8192-4701-875F-9FF63FD6EDC8@digia.com> On Sep 25, 2014, at 4:07 PM, wrote: > >> I think if this feature would be added to QtCore, it should be by extending >> QMetaObject::invoke to work with functors. >> By using Qt::BlockingQueuedConnection that would be very similar to what you >> have done. > > I reported this before in Qt issue tracker. I would really like to see > this implemented. > (ftr: https://bugreports.qt-project.org/browse/QTBUG-37253) -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From michael.cherkasov at gmail.com Thu Sep 25 14:47:43 2014 From: michael.cherkasov at gmail.com (Michael Cherkasov) Date: Thu, 25 Sep 2014 16:47:43 +0400 Subject: [Development] puppet as configurator for test farm Message-ID: Hi all, I just faced with task that I think you already resolved. I need to configure a farm of test machines(linux, windows, macosx, solaris) for testing. To prevent false test failure I need to turnoff screensavers, autoupdates, install fake printers and so on. I believe you already has this infrastructure, so could you please share you knowledge about this? What tools do you use? May you have bunch of scripts to simplify machine configuration? or may be you use centralized configuration like puppet? I'll really appreciate if you shed light on this questions. Thanks, Mikhail. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.hausmann at digia.com Fri Sep 26 10:17:57 2014 From: simon.hausmann at digia.com (Simon Hausmann) Date: Fri, 26 Sep 2014 10:17:57 +0200 Subject: [Development] puppet as configurator for test farm In-Reply-To: References: Message-ID: <5721444.zBRJngWNe4@rhea> On Thursday 25. September 2014 16.47.43 Michael Cherkasov wrote: > Hi all, > > I just faced with task that I think you already resolved. I need to > configure > a farm of test machines(linux, windows, macosx, solaris) for testing. > To prevent false test failure I need to turnoff screensavers, autoupdates, > install fake printers and so on. > I believe you already has this infrastructure, so could you please share > you > knowledge about this? > What tools do you use? > May you have bunch of scripts to simplify machine configuration? > or may be you use centralized configuration like puppet? > > I'll really appreciate if you shed light on this questions. You can find some of that in the qtqa/sysadmin repository in Gerrit, however unfortunately this infrastructure isn't maintained and in sync with the actual test machines. A fair bit of work is done by hand on those. However on the upside I've started work on packer templates and provisioning (based on chef) for a new machine setup and once that becomes production quality I'd like to share it in the Qt project. Simon From giuliocamuffo at gmail.com Fri Sep 26 12:33:55 2014 From: giuliocamuffo at gmail.com (Giulio Camuffo) Date: Fri, 26 Sep 2014 13:33:55 +0300 Subject: [Development] Platform maintainers In-Reply-To: <15019545.iRDbyiQlQL@tjmaciei-mobl4> References: <15019545.iRDbyiQlQL@tjmaciei-mobl4> Message-ID: 2014-09-25 19:26 GMT+03:00 Thiago Macieira : > On Thursday 25 September 2014 10:17:25 Knoll Lars wrote: >> Windows: Friedemann >> WinRT: Andrew Knight >> OS X: Morten >> Linux (X11): Jørgen Lind >> Linux (Wayland): Already covered by Andy Nichols >> iOS: Tor Arne >> Android: Bogdan >> Windows CE: Björn Breitmeyer >> >> QNX is open for the moment, I’d love to hear proposals. >> >> Most of the people above have been acting as a platform maintainer in >> practice, so this is mostly about formalising the responsibility and >> giving them proper recognition. > > Agreed, most of them are already acting as Maintainers anyway, which is the > usual requirement for them to become Maintainers anyway. At the very least, I > can directly confirm Friedemann, Andrew, Tor Arne, Bogdan and Björn have done > that work, as I've sent a few patches their way for those platforms and they > were readily acted on. Moreover, I know Morten, Jørgen and Andy personally, > and a quick git log shows they've been active. (Wayland being the easiest, > since it's a separate repo: of the last 200 commits, 140 were reviewed by > Andy) Uhm, how did you get that number? A "git log -n 200 |grep Andy|wc -l" says 5 to me, four Reviewed-by and one Author, the last one being on February 11. I don't want to be dismissive of the work he has done on qtwayland, but he hasn't been working on it for many months, and on and off for even more. Jørgen or Laszlo would be a better fit, imho. -- Giulio > > Therefore, I give my Maintainer +1 on all nominations. > > -- > 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 gunnar.sletta at jolla.com Fri Sep 26 12:54:11 2014 From: gunnar.sletta at jolla.com (Gunnar Sletta) Date: Fri, 26 Sep 2014 10:54:11 +0000 Subject: [Development] Platform maintainers In-Reply-To: References: <15019545.iRDbyiQlQL@tjmaciei-mobl4> Message-ID: <47C12FB7-08EA-47C7-A6F9-F3D69E4BB4BD@jollamobile.com> On 26 Sep 2014, at 12:33, Giulio Camuffo wrote: > 2014-09-25 19:26 GMT+03:00 Thiago Macieira : >> On Thursday 25 September 2014 10:17:25 Knoll Lars wrote: >>> Windows: Friedemann >>> WinRT: Andrew Knight >>> OS X: Morten >>> Linux (X11): Jørgen Lind >>> Linux (Wayland): Already covered by Andy Nichols >>> iOS: Tor Arne >>> Android: Bogdan >>> Windows CE: Björn Breitmeyer >>> >>> QNX is open for the moment, I’d love to hear proposals. >>> >>> Most of the people above have been acting as a platform maintainer in >>> practice, so this is mostly about formalising the responsibility and >>> giving them proper recognition. >> >> Agreed, most of them are already acting as Maintainers anyway, which is the >> usual requirement for them to become Maintainers anyway. At the very least, I >> can directly confirm Friedemann, Andrew, Tor Arne, Bogdan and Björn have done >> that work, as I've sent a few patches their way for those platforms and they >> were readily acted on. Moreover, I know Morten, Jørgen and Andy personally, >> and a quick git log shows they've been active. (Wayland being the easiest, >> since it's a separate repo: of the last 200 commits, 140 were reviewed by >> Andy) > > Uhm, how did you get that number? A "git log -n 200 |grep Andy|wc -l" > says 5 to me, four Reviewed-by and one Author, the last one being on > February 11. > I don't want to be dismissive of the work he has done on qtwayland, > but he hasn't been working on it for many months, and on and off for > even more. Jørgen or Laszlo would be a better fit, imho. > Another candidate would be yourself, Giulio :) Giulio has been doing a lot of the heavy work there in the last few months and he is also quite active in both the wayland community as well as the qtwayland community. He has my vote. > > -- > Giulio > >> >> Therefore, I give my Maintainer +1 on all nominations. >> >> -- >> 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 tor.arne.vestbo at digia.com Fri Sep 26 13:53:19 2014 From: tor.arne.vestbo at digia.com (=?ISO-8859-1?Q?Tor_Arne_Vestb=F8?=) Date: Fri, 26 Sep 2014 13:53:19 +0200 Subject: [Development] Start of a refactor of the QSettings class based on QJson In-Reply-To: <2685671.53b59zMXma@tjmaciei-mobl4> References: <2685671.53b59zMXma@tjmaciei-mobl4> Message-ID: <542553AF.50403@digia.com> On 26/09/14 00:31, Thiago Macieira wrote: >> since I need to take the value, modify it, insert it back nested groups are >> a pain to use, >> because I would have to chain the removal / addtion of the parent group >> untill I hit the rootGroup. This is a general issue with QtJson (and Qt), we don't seem to have an easy-to-modify structure for data like this (as far as I can tell). Wish I could do: rootConfig["foo"] = 1; rootConfig["bar"]["baz"] = 5; QJsonObject biz = rootConfig["biz"]; biz["buz"] = 6; etc. tor arne From Jani.Heikkinen at digia.com Fri Sep 26 13:57:20 2014 From: Jani.Heikkinen at digia.com (Heikkinen Jani) Date: Fri, 26 Sep 2014 11:57:20 +0000 Subject: [Development] Qt 5.4 beta snapshot available Message-ID: <1ab7cae4618b493a9bbcdf636ed4a976@DB3PR02MB0569.eurprd02.prod.outlook.com> Hi all! New snapshot available here: Windows: http://download.qt-project.org/snapshots/qt/5.4/5.4.0-beta/2014-09-26_23/ Linux: http://download.qt-project.org/snapshots/qt/5.4/5.4.0-beta/2014-09-26_28/ Unfortunately mac packages are still missing :( Qt5 changes in this snapshot: https://codereview.qt-project.org/#/c/95726/ Patch Set 2: * qtbase 0c307f4...8f25196 (33): > Polish the mdi example. > Generate Show/Hide events for widgets when minimized state changes. > remove special handling for the "Deployment Files" filter > refactor VCXProjectWriter::outputFileConfig > uncopy & -pastify code > Expose QSqlDriverPrivate dbmsType in public QSqlDriver api > Ensure a window with no stays on top flag is not staying on top > Handle InsetDrawable. > Update license headers and add new license files > iOS: Dont update screen properties for statusbar frame while rotating > iOS: Reflect changes in statusbar height as QScreen availableGeometry > iOS: Fix touch point translation when root view controller is offset > iOS: Simplify QWindow/UIView geometry mapping > iOS: Ensure root view controller always matches size of containing window > iOS: Move top level window management out of QIOSScreen to QIOSDesktopManagerView > iOS: Calculate screen (available) geometry using [UIView convertRect] > iOS: Update screen properties more consistently > iOS: Scroll root view when keyboard is visible using sublayerTransform > Make QScreenPrivate constructor a bit clearer > Windows: devicePixelRatio aware QWindowsTheme::standardPixmap > Doc: Fixed autolink errors qtbase/kernel > Doc: corrected autolink errors qtbase/corelib/tools > Abstract proxy model: Add missing delegation of supportedDragActions > Change fallback OpenGL library name > Fix misleading documentation > QXmlSimpleReader shall handle external entity reference file over 1k > Merge "Merge remote-tracking branch origin/5.3 into 5.4" into refs/staging/5.4 > Windows: fix obvious mistyping in getSysColor > Vista style: Scale hardcoded values in menu drawing code. > Fix QPixelFormat values > Add * as a valid token to our blacklisting > Doc: correction return statement QSqlDatabase QSqlTableModel::database() > Fix doc typo with Q_FORWARD_DECLARE_MUTABLE_CF_TYPE. * qtdeclarative d0138bb...40f76f9 (7): > QDSM: Nested statemachines are supported > move QQuickWindowAttached to QQuickWindowQmlImpl > Fix cleanup of non-threaded render loops. > Cleanup: Simplify CompiledData::Unit structure to always include the string table at the end > Allow multiple cached qml unit registration functions > Fix disappearing slider during size/orientation change > Doc: apply title case to all section1 titles * qtdoc bc87679...28618df (3): > Doc: Suggest an alternative to connections with default params > Doc: Added link to QtEndian page from Core Internals page. > Update software fallback GL name * qtmultimedia f788f8e...c1c205b (3): > Android: fix QMediaPlayers state and mediaStatus signals. > WMF: fix crash on media player destruction. > WMF: fix video rendering with ANGLE. * qtquickcontrols 094528f...1a1a19f (1): > EditMenu: let menu property be a component to lazy load it * qttools a8fd7c7...49e7591 (3): > Zoom the documentation according to the system DPI by default > Qt Designer: Fix range check of double properties. > qdbusviewer: Extract MainWindow class * qtwebengine a193b3b...f3500da (3): > Skip tst_QWebEngineFrame::setUrlWithFragment API test > Remove unneeded QWP_PATH environment variable for quick tests. > Fix issues on HiDPI displays * qtwebkit d34ae1d...f69ddfa (2): > Incorrect behavior on emscripten-compiled cube2hash > Avoid crashing when QtQuick destroys our SG node and GL context https://codereview.qt-project.org/#/c/95608/ Patch Set 1: * qtbase 7b7ad02...0c307f4 (27): > Accessibility OS X: Fix image role > direct2d: Fix font size when display scaling is in use > QVersionNumber: correctly fail for numerically very large segments > QCommonStyle: remove references to QStyleOptionFrameV > QStyleSheetStyle: remove references to QStyleOptionFrameV > winrt: fix compiler warning on Windows Phone > emulate mouse move in default implementation of QPlatformCursor::setPos > Fix compilation of ANGLE for XP > iOS: Add missing LSRequiresIPhoneOS field to Info.plist > iOS: Implement support for native menus > Fix warning about sign change (ICC) > Initialize certain Qt environment variables in testcases > Unify the environment variables used for console logging > Fix the number of empty lines between warnings at the end of configure > Add unit tests for cleaning up nested functions > QRegion: Reorganise members to reduce padding in EdgeTableEntry > Fix MSVC source code encoding warnings in tst_qtjson. > Fix QAbstractSocket::readData() behavior on buffered socket > Fix the drawing of elided text in QHeaderView. > Blacklist constantly failing test cases on OS X > xcb: support Wacom touch devices; distinguish from tablets > Fix too fast zooming in QTextEdit with smooth scrolling events > QCalendarWidget: fix a bug when parsing date/time formats > QCalendarWidget: move all helper classes into the unnamed namespace > QCalendarWidget: move QCalendarTextNavigator into qcalendarwidget.cpp > Fix spin box with fine grained wheel events > Use NonPremultipliedImageSrc shader when painting non-premuled images * qtdeclarative a76985e...d0138bb (2): > Updated the example to accept input on Android > Recreate the fbo on screen change in QQuickWidget when needed * qtquickcontrols 215ca36...094528f (4): > Gallery: use new menu API for TextArea > EditMenu: add base implementation for desktop > Add EditMenu to input controls > Merge "Merge remote-tracking branch origin/5.3 into 5.4" into refs/staging/5.4 * qtwebengine 1cbb91b...a193b3b (2): > Fix an assertion in web_content_delegates_qt.cpp > Remove unneded OS_CHROMEOS define >>-----Original Message----- >>From: Heikkinen Jani >>Sent: 24. syyskuuta 2014 14:53 >>To: development at qt-project.org >>Subject: Qt 5.4 beta snapshot available >> >>Hi all, >> >>First Qt5.4 beta snapshot packages available here >> >>Windows: http://download.qt-project.org/snapshots/qt/5.4/5.4.0- >>beta/2014-09-24_20/ >>Linux: http://download.qt-project.org/snapshots/qt/5.4/5.4.0-beta/2014- >>09-24_24/ >> >>Unfortunately there is still issues with mac packages & so on those are >>missing :( >> >>Please check these packages and verify everything needed is in & works as >>expected. >> >>Qt 5.4 beta release is planned to happen during next week so please link all >>beta blocker issues in the metabug: https://bugreports.qt- >>project.org/browse/QTBUG-41077 >> >>Br, >>Jani From vminenko at blackberry.com Fri Sep 26 14:04:54 2014 From: vminenko at blackberry.com (Vladimir Minenko) Date: Fri, 26 Sep 2014 12:04:54 +0000 Subject: [Development] Platform maintainers Message-ID: On 25.09.14 12:17, "Knoll Lars" wrote: >QNX is open for the moment, I’d love to hear proposals. I propose Bernd Weimer for this role. Bernd has a long-term experience working with Qt in general and was developing many core elements of the current QPA for QNX. I know only very few other persons who know this code at a comparable level and/or worked on it that much. https://codereview.qt-project.org/#/q/owner:bweimer,n,z — Vladimir From helmut.muelner at gmail.com Fri Sep 26 14:43:18 2014 From: helmut.muelner at gmail.com (=?iso-8859-1?Q?Helmut_M=FClner?=) Date: Fri, 26 Sep 2014 14:43:18 +0200 Subject: [Development] Problem with QML Context2D Message-ID: <003b01cfd987$74094290$5c1bc7b0$@gmail.com> I am developing a mixed C++/QML application using qt-opensource-windows-x86-msvc2012_opengl-5.3.2 (and 5.4.0-beta). The QML GUI contains a zoomable Canvas item embedded in a ScrollView. Zooming the Canvas changes its size, and after experiencing some strange crashes of the application during zooming, I researched the reason for the crash and found out that it crashed in QImage::detach(): void QImage::detach() {     if (d) {         if (d->is_cached && d->ref.load() == 1)             QImagePixmapCleanupHooks::executeImageHooks(cacheKey());         if (d->ref.load() != 1 || d->ro_data)             *this = copy(); -->         ++d->detach_no;     } } ... because copy() failed (because malloc failed) and d was 0 and led to a null pointer access. This is a bug in QImage that should be fixed. The reason for the failure lies in QQuickContext2DTexture which has the QImage members m_image and m_displayImage with the size of the Canvas item. If the user zooms in and out a lot those members a recreated a lot with changing sizes which leads to cathastrophic memory fragmentation and finally to a malloc failure. The only (hacky) solution I could find so far is to use a big fixed size (maximum) Canvas and fake the logical size for the ScrollView. Any other ideas or some fix for QQuickContext2DImageTexture? From Laszlo.Agocs at digia.com Fri Sep 26 15:03:51 2014 From: Laszlo.Agocs at digia.com (Agocs Laszlo) Date: Fri, 26 Sep 2014 13:03:51 +0000 Subject: [Development] Platform maintainers In-Reply-To: References: <15019545.iRDbyiQlQL@tjmaciei-mobl4>, Message-ID: With all the embedded and graphics stuff on my plate QtWayland would be too much at this stage, I think. Jørgen would be an excellent candidate indeed, given that he is the original maintainer anyhow. Cheers, Laszlo ________________________________________ From: development-bounces+laszlo.agocs=digia.com at qt-project.org [development-bounces+laszlo.agocs=digia.com at qt-project.org] on behalf of Giulio Camuffo [giuliocamuffo at gmail.com] Sent: Friday, September 26, 2014 12:33 PM To: Thiago Macieira Cc: development at qt-project.org Subject: Re: [Development] Platform maintainers 2014-09-25 19:26 GMT+03:00 Thiago Macieira : > On Thursday 25 September 2014 10:17:25 Knoll Lars wrote: >> Windows: Friedemann >> WinRT: Andrew Knight >> OS X: Morten >> Linux (X11): Jørgen Lind >> Linux (Wayland): Already covered by Andy Nichols >> iOS: Tor Arne >> Android: Bogdan >> Windows CE: Björn Breitmeyer >> >> QNX is open for the moment, I’d love to hear proposals. >> >> Most of the people above have been acting as a platform maintainer in >> practice, so this is mostly about formalising the responsibility and >> giving them proper recognition. > > Agreed, most of them are already acting as Maintainers anyway, which is the > usual requirement for them to become Maintainers anyway. At the very least, I > can directly confirm Friedemann, Andrew, Tor Arne, Bogdan and Björn have done > that work, as I've sent a few patches their way for those platforms and they > were readily acted on. Moreover, I know Morten, Jørgen and Andy personally, > and a quick git log shows they've been active. (Wayland being the easiest, > since it's a separate repo: of the last 200 commits, 140 were reviewed by > Andy) Uhm, how did you get that number? A "git log -n 200 |grep Andy|wc -l" says 5 to me, four Reviewed-by and one Author, the last one being on February 11. I don't want to be dismissive of the work he has done on qtwayland, but he hasn't been working on it for many months, and on and off for even more. Jørgen or Laszlo would be a better fit, imho. -- Giulio From thiago.macieira at intel.com Fri Sep 26 16:34:54 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Sep 2014 07:34:54 -0700 Subject: [Development] Platform maintainers In-Reply-To: References: <15019545.iRDbyiQlQL@tjmaciei-mobl4> Message-ID: <2190608.nE3H3ilDQD@tjmaciei-mobl4> On Friday 26 September 2014 13:33:55 Giulio Camuffo wrote: > Uhm, how did you get that number? A "git log -n 200 |grep Andy|wc -l" > says 5 to me, four Reviewed-by and one Author, the last one being on > February 11. > I don't want to be dismissive of the work he has done on qtwayland, > but he hasn't been working on it for many months, and on and off for > even more. Jørgen or Laszlo would be a better fit, imho. I ran this: $ git log origin/5.4~200..origin/5.4 | grep Reviewed-by | sort | uniq -c 32 Reviewed-by: Andrew Knight 140 Reviewed-by: Andy Nichols 1 Reviewed-by: Elvis Lee 1 Reviewed-by: Frederik Gladhorn 3 Reviewed-by: Giulio Camuffo 50 Reviewed-by: Giulio Camuffo 2 Reviewed-by: Gunnar Sletta 34 Reviewed-by: Gunnar Sletta 1 Reviewed-by: Gunnar Sletta 36 Reviewed-by: Jan Arne Petersen 1 Reviewed-by: Jędrzej Nowacki 2 Reviewed-by: Joerg Bornemann 109 Reviewed-by: Jørgen Lind 8 Reviewed-by: Jørgen Lind 89 Reviewed-by: Laszlo Agocs 1 Reviewed-by: Laszlo Papp 1 Reviewed-by: Lubomir Rintel 1 Reviewed-by: Michael Brasser 2 Reviewed-by: Mikko Levonmaa 6 Reviewed-by: Oswald Buddenhagen 7 Reviewed-by: Paul Olav Tvete 2 Reviewed-by: Philippe Coval 18 Reviewed-by: Pier Luigi Fiorini 26 Reviewed-by: Robin Burchell 30 Reviewed-by: Robin Burchell 17 Reviewed-by: Samuel Rødal 3 Reviewed-by: Sergio Ahumada 5 Reviewed-by: Shawn Rutledge 1 Reviewed-by: Simo Fält 2 Reviewed-by: Thiago Macieira 1 Reviewed-by: Tor Arne Vestbø 1 Reviewed-by: Vesa Halttunen 1 Reviewed-by: Yen-Chin Lee Problem: origin/5.4~200..origin/5.4 contains more than 200 commits due to merging. That's actually 491. I didn't notice this problem because the number of reviews per person were all less than 200. Bad coincidence. If I restrict to actually 200 commits, here's the result: $ git log -n200 origin/5.4 | grep Reviewed-by | sort | uniq -c 4 Reviewed-by: Andrew Knight 4 Reviewed-by: Andy Nichols 1 Reviewed-by: Frederik Gladhorn 1 Reviewed-by: Giulio Camuffo 50 Reviewed-by: Giulio Camuffo 34 Reviewed-by: Gunnar Sletta 1 Reviewed-by: Gunnar Sletta 2 Reviewed-by: Jan Arne Petersen 22 Reviewed-by: Jørgen Lind 48 Reviewed-by: Laszlo Agocs 1 Reviewed-by: Michael Brasser 2 Reviewed-by: Mikko Levonmaa 1 Reviewed-by: Oswald Buddenhagen 2 Reviewed-by: Philippe Coval 6 Reviewed-by: Pier Luigi Fiorini 26 Reviewed-by: Robin Burchell 25 Reviewed-by: Robin Burchell 1 Reviewed-by: Sergio Ahumada 5 Reviewed-by: Shawn Rutledge 1 Reviewed-by: Thiago Macieira 1 Reviewed-by: Vesa Halttunen 1 Reviewed-by: Yen-Chin Lee And you're right, the last time Andy reviewed anything in qtwayland was February/2014. So, Andy, are you coming back? Or do you want to step down for someone else? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Andy.Nichols at digia.com Fri Sep 26 17:17:22 2014 From: Andy.Nichols at digia.com (Nichols Andy) Date: Fri, 26 Sep 2014 15:17:22 +0000 Subject: [Development] Platform maintainers In-Reply-To: <2190608.nE3H3ilDQD@tjmaciei-mobl4> References: <15019545.iRDbyiQlQL@tjmaciei-mobl4> <2190608.nE3H3ilDQD@tjmaciei-mobl4> Message-ID: <14AC8EE3-B8CB-4FF3-A9DE-916B183670A6@digia.com> Hi everyone, > And you're right, the last time Andy reviewed anything in qtwayland was > February/2014. > This sounds much more in line with reality. > So, Andy, are you coming back? Or do you want to step down for someone else? It is true that I have not had much time to devote to QtWayland this year, and while I can see the possibility of returning to working with QtWayland, it will not be to the same extent as before. I would be comfortable stepping down to let someone who has shown they do have the time needed to devote to QtWayland. My suggestions for replacement would be either Giulio Camuffo who as been main driver for the QtWayland project this year, or Jorgen Lind who was the previous QtWayland maintainer and who still has a deep interest in the project. Regards, Andy Nichols From robin+qt at viroteck.net Fri Sep 26 18:01:55 2014 From: robin+qt at viroteck.net (Robin Burchell) Date: Fri, 26 Sep 2014 18:01:55 +0200 Subject: [Development] Platform maintainers In-Reply-To: <14AC8EE3-B8CB-4FF3-A9DE-916B183670A6@digia.com> References: <15019545.iRDbyiQlQL@tjmaciei-mobl4> <2190608.nE3H3ilDQD@tjmaciei-mobl4> <14AC8EE3-B8CB-4FF3-A9DE-916B183670A6@digia.com> Message-ID: On Fri, Sep 26, 2014 at 5:17 PM, Nichols Andy wrote: > My suggestions for replacement would be either Giulio Camuffo who as been main driver for the QtWayland project this year, or Jorgen Lind who was the previous QtWayland maintainer and who still has a deep interest in the project. +1 to either, but I have to say I'd lean towards a +2 for Giulio simply because he is more focused on Wayland, whereas Jørgen has many other things on his plate already (from what I've seen going around in Gerrit). Giulio has an extensive knowledge base in the area, and has proven a real asset in the time he's been working actively on QtWayland & QtCompositor. (No offence intended to Jørgen if my understanding of the situation is incorrect!) From samuel.gaist at edeltech.ch Sun Sep 28 01:02:11 2014 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Sun, 28 Sep 2014 01:02:11 +0200 Subject: [Development] QUrl setPath Qt4 vs Qt5 Message-ID: Hi, Following a post on the forum, I've checked and there's been a behavior change in QUrl's setPath between Qt 4 and Qt 5 that is not mentioned in the "C++ API changes" chapter. If I understood correctly: QUrl example1("http://www.example.com"); example1.setPath("pub/something"); makes example1 invalid in Qt 5 due to the fact that "pub/something" is a relative path (following QUrl documentation and test) but in Qt 4 the result is "http://www.example.com/pub/something". Should it be considered bug in Qt 4 that needs fixing ? However fixing it might break existing application that could be relying on that behavior. In this case, simply add the API break in Qt 5's documentation ? Samuel From thiago.macieira at intel.com Sun Sep 28 03:26:32 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 27 Sep 2014 18:26:32 -0700 Subject: [Development] QUrl setPath Qt4 vs Qt5 In-Reply-To: References: Message-ID: <3038109.vP0dINqgI3@tjmaciei-mobl4> On Sunday 28 September 2014 01:02:11 Samuel Gaist wrote: > Hi, > > Following a post on the forum, I've checked and there's been a behavior > change in QUrl's setPath between Qt 4 and Qt 5 that is not mentioned in the > "C++ API changes" chapter. > > If I understood correctly: > > QUrl example1("http://www.example.com"); > example1.setPath("pub/something"); > > makes example1 invalid in Qt 5 due to the fact that "pub/something" is a > relative path (following QUrl documentation and test) but in Qt 4 the > result is "http://www.example.com/pub/something". > > Should it be considered bug in Qt 4 that needs fixing ? However fixing it > might break existing application that could be relying on that behavior. In > this case, simply add the API break in Qt 5's documentation ? Yes, it's a bug in Qt 4, bug I won't fix it because it's not that important and would require a major change. QUrl in Qt 4 has quite a few known issues with encoding and decoding of delimiters too. And its QString constructor is a completely flawed design and should never be used. QUrl changed considerably in Qt 5 to comply better with the URL specifications and with brokenness out there. If we add anything to the documentation, it would be the previous sentence, with no extra details. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From samuel.gaist at edeltech.ch Sun Sep 28 09:52:07 2014 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Sun, 28 Sep 2014 09:52:07 +0200 Subject: [Development] QUrl setPath Qt4 vs Qt5 In-Reply-To: <3038109.vP0dINqgI3@tjmaciei-mobl4> References: <3038109.vP0dINqgI3@tjmaciei-mobl4> Message-ID: > On 28 sept. 2014, at 03:26, Thiago Macieira wrote: > >> On Sunday 28 September 2014 01:02:11 Samuel Gaist wrote: >> Hi, >> >> Following a post on the forum, I've checked and there's been a behavior >> change in QUrl's setPath between Qt 4 and Qt 5 that is not mentioned in the >> "C++ API changes" chapter. >> >> If I understood correctly: >> >> QUrl example1("http://www.example.com"); >> example1.setPath("pub/something"); >> >> makes example1 invalid in Qt 5 due to the fact that "pub/something" is a >> relative path (following QUrl documentation and test) but in Qt 4 the >> result is "http://www.example.com/pub/something". >> >> Should it be considered bug in Qt 4 that needs fixing ? However fixing it >> might break existing application that could be relying on that behavior. In >> this case, simply add the API break in Qt 5's documentation ? > > Yes, it's a bug in Qt 4, bug I won't fix it because it's not that important and > would require a major change. > > QUrl in Qt 4 has quite a few known issues with encoding and decoding of > delimiters too. And its QString constructor is a completely flawed design and > should never be used. > > QUrl changed considerably in Qt 5 to comply better with the URL specifications > and with brokenness out there. If we add anything to the documentation, it > would be the previous sentence, with no extra details. I remember now following a discussion about that matter some time ago. Fine for me. I'll update the API change doc to include that so future users won't be surprised. Samuel From paullemire at hotmail.com Sun Sep 28 15:17:34 2014 From: paullemire at hotmail.com (Paul Lemire) Date: Sun, 28 Sep 2014 15:17:34 +0200 Subject: [Development] Copying QJSValue arrays Message-ID: Hi guys, We're working on being able to set GLSL uniform arrays from QML. Basically what we have is a QParameter QObject exposed to QML as Parameter. It contains a QString name property and a QVariant value property. Here's how it can be used for scalar types. Parameter { name : "uniformName"; value : 1.0; } What we want is to send a copy of value to our backend renderer, so that we won't have any problem with threading. For scalar types, the copy is done implicitly. For array types, we'd like to be able to do something like that: property var myArray : [1.0, 1.0, 1.0] Parameter { name : "uniformArray"; value : myArray } However in that case, value is a QJSValue containing a JS Array object. We need a way to be able to copy that object. The tricky part there is that we can't check the QVariant to to see if it contains a QJSValue directly as we don't want to introduce a dependency to the QML module. We're thinking of maybe introducing a Qt.array helper function that would return us a copy of the array directly or retrieve a QVector. If you've got ideas around that issue, please step in. Thanks, Paul Lemire -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eike.Ziller at digia.com Mon Sep 29 09:08:53 2014 From: Eike.Ziller at digia.com (Ziller Eike) Date: Mon, 29 Sep 2014 07:08:53 +0000 Subject: [Development] QUrl setPath Qt4 vs Qt5 In-Reply-To: References: <3038109.vP0dINqgI3@tjmaciei-mobl4> Message-ID: <53BA152D-51DA-454A-AF18-31776251DC41@digia.com> Just for completeness ;) https://bugreports.qt-project.org/browse/QTBUG-27728 On Sep 28, 2014, at 9:52 AM, Samuel Gaist wrote: > >> On 28 sept. 2014, at 03:26, Thiago Macieira wrote: >> >>> On Sunday 28 September 2014 01:02:11 Samuel Gaist wrote: >>> Hi, >>> >>> Following a post on the forum, I've checked and there's been a behavior >>> change in QUrl's setPath between Qt 4 and Qt 5 that is not mentioned in the >>> "C++ API changes" chapter. >>> >>> If I understood correctly: >>> >>> QUrl example1("http://www.example.com"); >>> example1.setPath("pub/something"); >>> >>> makes example1 invalid in Qt 5 due to the fact that "pub/something" is a >>> relative path (following QUrl documentation and test) but in Qt 4 the >>> result is "http://www.example.com/pub/something". >>> >>> Should it be considered bug in Qt 4 that needs fixing ? However fixing it >>> might break existing application that could be relying on that behavior. In >>> this case, simply add the API break in Qt 5's documentation ? >> >> Yes, it's a bug in Qt 4, bug I won't fix it because it's not that important and >> would require a major change. >> >> QUrl in Qt 4 has quite a few known issues with encoding and decoding of >> delimiters too. And its QString constructor is a completely flawed design and >> should never be used. >> >> QUrl changed considerably in Qt 5 to comply better with the URL specifications >> and with brokenness out there. If we add anything to the documentation, it >> would be the previous sentence, with no extra details. > > I remember now following a discussion about that matter some time ago. > > Fine for me. I'll update the API change doc to include that so future users won't be surprised. > > Samuel > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From samuel.gaist at edeltech.ch Mon Sep 29 09:13:50 2014 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Mon, 29 Sep 2014 09:13:50 +0200 Subject: [Development] QUrl setPath Qt4 vs Qt5 In-Reply-To: <53BA152D-51DA-454A-AF18-31776251DC41@digia.com> References: <3038109.vP0dINqgI3@tjmaciei-mobl4> <53BA152D-51DA-454A-AF18-31776251DC41@digia.com> Message-ID: <77E8262F-AAE9-43CA-99B1-63AFAF13BEDD@edeltech.ch> On 29 sept. 2014, at 09:08, Ziller Eike wrote: > Just for completeness ;) > > https://bugreports.qt-project.org/browse/QTBUG-27728 > Thanks :) Since it's a documentation update and 5.4 is not officially out, should I target 5.3 ? > > On Sep 28, 2014, at 9:52 AM, Samuel Gaist wrote: > >> >>> On 28 sept. 2014, at 03:26, Thiago Macieira wrote: >>> >>>> On Sunday 28 September 2014 01:02:11 Samuel Gaist wrote: >>>> Hi, >>>> >>>> Following a post on the forum, I've checked and there's been a behavior >>>> change in QUrl's setPath between Qt 4 and Qt 5 that is not mentioned in the >>>> "C++ API changes" chapter. >>>> >>>> If I understood correctly: >>>> >>>> QUrl example1("http://www.example.com"); >>>> example1.setPath("pub/something"); >>>> >>>> makes example1 invalid in Qt 5 due to the fact that "pub/something" is a >>>> relative path (following QUrl documentation and test) but in Qt 4 the >>>> result is "http://www.example.com/pub/something". >>>> >>>> Should it be considered bug in Qt 4 that needs fixing ? However fixing it >>>> might break existing application that could be relying on that behavior. In >>>> this case, simply add the API break in Qt 5's documentation ? >>> >>> Yes, it's a bug in Qt 4, bug I won't fix it because it's not that important and >>> would require a major change. >>> >>> QUrl in Qt 4 has quite a few known issues with encoding and decoding of >>> delimiters too. And its QString constructor is a completely flawed design and >>> should never be used. >>> >>> QUrl changed considerably in Qt 5 to comply better with the URL specifications >>> and with brokenness out there. If we add anything to the documentation, it >>> would be the previous sentence, with no extra details. >> >> I remember now following a discussion about that matter some time ago. >> >> Fine for me. I'll update the API change doc to include that so future users won't be surprised. >> >> Samuel >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Eike Ziller, Senior Software Engineer - Digia, Qt > > Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > > From simon.hausmann at digia.com Mon Sep 29 09:20:00 2014 From: simon.hausmann at digia.com (Simon Hausmann) Date: Mon, 29 Sep 2014 09:20:00 +0200 Subject: [Development] Copying QJSValue arrays In-Reply-To: References: Message-ID: <3098538.7FpicBVYRl@rhea> On Sunday 28. September 2014 15.17.34 Paul Lemire wrote: > Hi guys, > > > > > We're working on being able to set GLSL uniform arrays from QML. > > Basically what we have is a QParameter QObject exposed to QML as Parameter. > > > > > It contains a QString name property and a QVariant value property. > > > > > Here's how it can be used for scalar types. > > > > > Parameter { name : "uniformName"; value : 1.0; } > > > > > What we want is to send a copy of value to our backend renderer, so that we > won't have any problem with threading. For scalar types, the copy is done > implicitly. > > > > > For array types, we'd like to be able to do something like that: > > > > > property var myArray : [1.0, 1.0, 1.0] > > Parameter { name : "uniformArray"; value : myArray } > > > > > However in that case, value is a QJSValue containing a JS Array object. > > We need a way to be able to copy that object. > > The tricky part there is that we can't check the QVariant to to see if it > contains a QJSValue directly as we don't want to introduce a dependency to > the QML module. > > > > > We're thinking of maybe introducing a Qt.array helper function that would > return us a copy of the array directly or retrieve a QVector. > > > > > If you've got ideas around that issue, please step in. If you don't want to depend on QtQml (which seems odd for a library that offers Qml bindings), then what you could do is utilize the conversion functions. So after checking your QVariant for all other types you're interested in supporting, you can try canConvert() and afterwards convert to that. This will trigger a registered conversion function that will convert the JavaScript array object, that the QJSValue wraps, into a QVariant list that is not dependent on the JS engine anymore. A QJSValue wrapped in a QVariant is (through QVariant) API always convertible to a QVariantList and a QVariantMap - it's a shortcut to writing qvariant_cast(variant).toVariant().value(); without using QJSValue. Due to the custom conversion functions being unconditional you can however not distinguish between a regular JavaScript object or an array. Therefore if the property contains an object the conversion to an array will cause a loss of data. If you don't want to loose any data, you're going to have to support the types the QVariant can contain, and that includes direct support for QJSValue. Simon From gorthauer87 at yandex.ru Mon Sep 29 09:29:46 2014 From: gorthauer87 at yandex.ru (gorthauer87 at yandex.ru) Date: Mon, 29 Sep 2014 07:29:46 +0000 Subject: [Development] =?utf-8?q?clang-analyzer_and_qbs_projects?= Message-ID: <20140929113124.VNiWobrQ@smtp1o.mail.yandex.net> Is there any way to analyze qbs projects with clang-analyzer? Отправлено с Почта Windows -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.kandeler at digia.com Mon Sep 29 09:59:30 2014 From: christian.kandeler at digia.com (Christian Kandeler) Date: Mon, 29 Sep 2014 09:59:30 +0200 Subject: [Development] clang-analyzer and qbs projects In-Reply-To: <20140929113124.VNiWobrQ@smtp1o.mail.yandex.net> References: <20140929113124.VNiWobrQ@smtp1o.mail.yandex.net> Message-ID: <54291162.3020603@digia.com> On 09/29/2014 09:29 AM, gorthauer87 at yandex.ru wrote: > Is there any way to analyze qbs projects with clang-analyzer? A cursory glance at how clang-analyzer works suggests it should be enough to set cpp.compilerPath to the location of the "c++-analyzer" tool (for C++ projects) and make sure the right compiler is found via PATH. Christian From sean.harmer at kdab.com Mon Sep 29 10:13:43 2014 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 29 Sep 2014 09:13:43 +0100 Subject: [Development] Copying QJSValue arrays In-Reply-To: <3098538.7FpicBVYRl@rhea> References: <3098538.7FpicBVYRl@rhea> Message-ID: <3693056.ODaB7Rt7sr@cartman> Hi Simon, On Monday 29 Sep 2014 09:20:00 Simon Hausmann wrote: > On Sunday 28. September 2014 15.17.34 Paul Lemire wrote: > > We're working on being able to set GLSL uniform arrays from QML. > > > > Basically what we have is a QParameter QObject exposed to QML as > > Parameter. > > > > It contains a QString name property and a QVariant value property. > > > > Here's how it can be used for scalar types. > > > > Parameter { name : "uniformName"; value : 1.0; } > > > > What we want is to send a copy of value to our backend renderer, so that > > we > > won't have any problem with threading. For scalar types, the copy is done > > implicitly. > > > > For array types, we'd like to be able to do something like that: > > > > property var myArray : [1.0, 1.0, 1.0] > > > > Parameter { name : "uniformArray"; value : myArray } > > > > However in that case, value is a QJSValue containing a JS Array object. > > > > We need a way to be able to copy that object. > > > > The tricky part there is that we can't check the QVariant to to see if it > > contains a QJSValue directly as we don't want to introduce a dependency to > > the QML module. > > > > We're thinking of maybe introducing a Qt.array helper function that would > > return us a copy of the array directly or retrieve a QVector. > > > > If you've got ideas around that issue, please step in. > > If you don't want to depend on QtQml (which seems odd for a library that > offers Qml bindings), then what you could do is utilize the conversion > functions. Yeah it sounds odd. The reason is that we hope to offer both C++ and QML apis for Qt3D where the plain C++ interface doesn't depend upon QtQml. > So after checking your QVariant for all other types you're > interested in supporting, you can try > > canConvert() > > and afterwards convert to that. This will trigger a registered conversion > function that will convert the JavaScript array object, that the QJSValue > wraps, into a QVariant list that is not dependent on the JS engine anymore. > > A QJSValue wrapped in a QVariant is (through QVariant) API always > convertible to a QVariantList and a QVariantMap - it's a shortcut to > writing > > qvariant_cast(variant).toVariant().value(); > > without using QJSValue. Due to the custom conversion functions being > unconditional you can however not distinguish between a regular JavaScript > object or an array. Therefore if the property contains an object the > conversion to an array will cause a loss of data. > > If you don't want to loose any data, you're going to have to support the > types the QVariant can contain, and that includes direct support for > QJSValue. Right. We're also considering having the property setter function call a helper virtual which in C++ lib does nothing but in the QML dependent lib takes care of extracting and copying the data. Thank you for your ideas. Sean From simon.hausmann at digia.com Mon Sep 29 10:15:45 2014 From: simon.hausmann at digia.com (Simon Hausmann) Date: Mon, 29 Sep 2014 10:15:45 +0200 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: <1411625401.39563.YahooMailNeo@web126105.mail.ne1.yahoo.com> References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> <1590984.Ktr0Ibkj0x@angrybird> <1411625401.39563.YahooMailNeo@web126105.mail.ne1.yahoo.com> Message-ID: <12414803.cGIGLTKakn@rhea> On Wednesday 24. September 2014 23.10.01 BogDan wrote: [...] > Hi, > > Do we all agree that the singletons, by definition, must be available to > any object at any time until the end of the application? Yes, with emphasis on "until". Note that we are now talking about the "end of the application" situation, so our agreement ends right there ;-). We are talking about the time the QQmlEngine destructor is executed, which from a QML engine perspective is the "end of the application" point of time. What happens during that period of time is just as "fishy" as when tearing down a C++ application: The order of destruction for global objects between several compilation units is undefined. In C++ you cannot rely on it (I think you can rely on the order within a unit), so you prepare yourself with levels of indirection and/or weak references. Right now the order of destruction in the QML engine is defined like this (by the existence of one implementation only): 1) Singletons are deleted first 2) The remaining JavaScript objects are deleted at random We can't change (2) really and we can't swap step 1 and 2 because it breaks for singletons that _are_ JavaScript objects. (to be continued further down) > IMHO deleting first the QML singletons then the rest of the Active objects > is also wrong, because some of the active objects might need these > singletons. > > I think the right way is to delete all the active objects first, then QML > singletons, try delete again all the active objects (supposing that the QML > singletons will create new objects in Component.onDestruction), then at the > very end, all the C++ singletons. IMHO this is the right way to do it, and > is not a hack at all. Doing something right, even if it's harder, is not a > hack ... And I feel that this is trying to solve a problem at the wrong level, hence me calling it a hack. No doubt we have many hacks in place, but they come at a cost of maintenance and complexity an already complex shutdown procedure. (/me points to qdeclarativeelement_destructor :) . So if we wanted to add this complexity, then I think it needs a better justification. I'm afraid I don't see that yet. At run-time you can rely on the life time of singletons. When the application is being shut down and you rely on a specific order of destruction, then I think you have to take care of it in your application. (And we may be missing tools to achieve that) Note that this is separate from the order of destruction "between" singletons - here it might makes sense to implement destruction in reversal to construction, although construction is non-deterministic from the framework's point of view. > I don't see how using a weak pointer will fix the problem, who will delete > the singleton object in the end? As we have established earlier, the singleton _does_ get deleted by the engine. The subject of this email thread gives it away :). Hmm, I apologize, I may have misunderstood or rather misinterpreted an earlier statement of yours about what's happening. I understood "active objects may still need to access the singletons in their destructor" as pointer based access and I (perhaps mistakenly?) concluded that you're experiencing crashes from users of the singleton _to_ the singleton due to dangling pointers. If that's not the case, could you elaborate a bit on what kind of access this is? >>> I can't reference it > for every object that depends on it, because, BTW, there are cases when > the VM doesn't delete all the objects! Yes it has lots of memleaks at the > end! What are you trying to say here? Is throwing mud supposed to motivate and convince me? :( If there are memory leaks, then I think we agree that those should be fixed. In this email thread we are talking about semantics during engine shutdown. At this point it's your word against mine :). You can try to convince me to invest time to implement the behavior you'd like. You can try to implement it yourself and convince me or some other approver to approve the change. Or you can try to convince somebody else to implement the change. Simon From porten at froglogic.com Mon Sep 29 16:16:05 2014 From: porten at froglogic.com (Harri Porten) Date: Mon, 29 Sep 2014 16:16:05 +0200 (CEST) Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: <12414803.cGIGLTKakn@rhea> References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> <1590984.Ktr0Ibkj0x@angrybird> <1411625401.39563.YahooMailNeo@web126105.mail.ne1.yahoo.com> <12414803.cGIGLTKakn@rhea> Message-ID: On Mon, 29 Sep 2014, Simon Hausmann wrote: > Yes, with emphasis on "until". Note that we are now talking about the "end of > the application" situation, so our agreement ends right there ;-). We are > talking about the time the QQmlEngine destructor is executed, which from a QML > engine perspective is the "end of the application" point of time. What happens > during that period of time is just as "fishy" as when tearing down a C++ > application: The order of destruction for global objects between several > compilation units is undefined. In C++ you cannot rely on it (I think you can > rely on the order within a unit), so you prepare yourself with levels of > indirection and/or weak references. I was thinking the same for a long time. Until I discovered (the hard way) a that at least one aspect of the C++ behavior is standardized: the order of destruction is guaranteed to be the reverse of the construction (see [basic.start.term]). I ran into this because of a singleton being encapsuled within a function using a 'static' object. The crashes upon application exit seemed arbitrary at first but turned out to be well-defined :) Which deletion order is the best for QML... maybe it can't be changed anymore. I'd just generally vouch for a *defined* order (even if problematic) rather than an undefined one. Harri. From simon.hausmann at digia.com Mon Sep 29 17:09:19 2014 From: simon.hausmann at digia.com (Simon Hausmann) Date: Mon, 29 Sep 2014 17:09:19 +0200 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> <12414803.cGIGLTKakn@rhea> Message-ID: <1577163.GmxN67URuz@angrybird> On Monday, September 29, 2014 04:16:05 PM Harri Porten wrote: > On Mon, 29 Sep 2014, Simon Hausmann wrote: > > Yes, with emphasis on "until". Note that we are now talking about the "end > > of the application" situation, so our agreement ends right there ;-). We > > are talking about the time the QQmlEngine destructor is executed, which > > from a QML engine perspective is the "end of the application" point of > > time. What happens during that period of time is just as "fishy" as when > > tearing down a C++ application: The order of destruction for global > > objects between several compilation units is undefined. In C++ you cannot > > rely on it (I think you can rely on the order within a unit), so you > > prepare yourself with levels of indirection and/or weak references. > > I was thinking the same for a long time. Until I discovered (the hard way) > a that at least one aspect of the C++ behavior is standardized: the order > of destruction is guaranteed to be the reverse of the construction (see > [basic.start.term]). > > I ran into this because of a singleton being encapsuled within a function > using a 'static' object. The crashes upon application exit seemed > arbitrary at first but turned out to be well-defined :) > > Which deletion order is the best for QML... maybe it can't be changed > anymore. I'd just generally vouch for a *defined* order (even if > problematic) rather than an undefined one. Right, that makes sense. In C++ the problem stems from the diversity of compilers, which we (unfortunately :) don't have with Qml. There is only one implementation and it defines the behavior. The question is how much we want to change the behavior. We could implement a reverse order destruction, if somebody makes a good case for it. Simon From jorgen.lind at digia.com Mon Sep 29 18:22:22 2014 From: jorgen.lind at digia.com (Jorgen Lind) Date: Mon, 29 Sep 2014 18:22:22 +0200 Subject: [Development] Platform maintainers In-Reply-To: References: <14AC8EE3-B8CB-4FF3-A9DE-916B183670A6@digia.com> Message-ID: <1727838.v3M14mWDQ6@perth> Hi, On Friday 26 September 2014 18:01:55 Robin Burchell wrote: > On Fri, Sep 26, 2014 at 5:17 PM, Nichols Andy wrote: > > My suggestions for replacement would be either Giulio Camuffo who as been main driver for the QtWayland project this year, or Jorgen Lind who was the previous QtWayland maintainer and who still has a deep interest in the project. > > +1 to either, but I have to say I'd lean towards a +2 for Giulio > simply because he is more focused on Wayland, whereas Jørgen has many > other things on his plate already (from what I've seen going around in > Gerrit). > > Giulio has an extensive knowledge base in the area, and has proven a > real asset in the time he's been working actively on QtWayland & > QtCompositor. > > (No offence intended to Jørgen if my understanding of the situation is > incorrect!) Non taken :) Giulio has driven much of the QtWayland development for 3/4 of a year now, and I think he is a good fit for as the maintainer. I can be the maintainer if he does not want it, as I intend to pick up QtWayland development again. Jørgen From thiago.macieira at intel.com Mon Sep 29 21:49:57 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Sep 2014 12:49:57 -0700 Subject: [Development] Platform maintainers In-Reply-To: <1727838.v3M14mWDQ6@perth> References: <1727838.v3M14mWDQ6@perth> Message-ID: <3859813.8dSNlf41Do@tjmaciei-mobl4> On Monday 29 September 2014 18:22:22 Jorgen Lind wrote: > Giulio has driven much of the QtWayland development for 3/4 of a year now, > and I think he is a good fit for as the maintainer. > > I can be the maintainer if he does not want it, as I intend to pick up > QtWayland development again. Given that, I hereby nominate Giulio Camuffo as the qtwayland maintainer. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bog_dan_ro at yahoo.com Tue Sep 30 09:47:15 2014 From: bog_dan_ro at yahoo.com (BogDan) Date: Tue, 30 Sep 2014 00:47:15 -0700 Subject: [Development] [QML] Singletons are deleted before the other objects In-Reply-To: <12414803.cGIGLTKakn@rhea> References: <1411130262.4366.YahooMailNeo@web126104.mail.ne1.yahoo.com> <1590984.Ktr0Ibkj0x@angrybird> <1411625401.39563.YahooMailNeo@web126105.mail.ne1.yahoo.com> <12414803.cGIGLTKakn@rhea> Message-ID: <1412063235.45883.YahooMailNeo@web126104.mail.ne1.yahoo.com> [..] > > IMHO deleting first the QML singletons then the rest of the Active > > objects > > > > is also wrong, because some of the active objects might need these > > singletons. > > > > I think the right way is to delete all the active objects first, then QML > > > > singletons, try delete again all the active objects (supposing that the > > QML > > singletons will create new objects in Component.onDestruction), then at > > the > > very end, all the C++ singletons. IMHO this is the right way to do it, and > > is not a hack at all. Doing something right, even if it's harder, is not a > > hack ... > > And I feel that this is trying to solve a problem at the wrong level, hence > me calling it a hack. No doubt we have many hacks in place, but they come > at a cost of maintenance and complexity an already complex shutdown > procedure. (/me points to qdeclarativeelement_destructor :) . So if we > wanted to add this complexity, then I think it needs a better > justification. I'm afraid I don't see that yet. > I don't see a better justification than the fact that this is the right way to do it .... > At run-time you can rely on the life time of singletons. When the > application is being shut down and you rely on a specific order of > destruction, then I think you have to take care of it in your application. > (And we may be missing tools to achieve that) I can't do it in my application, I'm trying to create a standalone QML *plugin* and I have no control when it's created/destroyed. [..] > > > I don't see how using a weak pointer will fix the problem, who will > > delete > > > > the singleton object in the end? > > As we have established earlier, the singleton _does_ get deleted by the > engine. The subject of this email thread gives it away :). > > Hmm, I apologize, I may have misunderstood or rather misinterpreted an > earlier statement of yours about what's happening. I understood "active > objects may still need to access the singletons in their destructor" as > pointer based access and I (perhaps mistakenly?) concluded that you're > experiencing crashes from users of the singleton _to_ the singleton due to > dangling pointers. If that's not the case, could you elaborate a bit on > what kind of access this is? Yes, that is the case and I still fail see how a weak pointer will help me to fix the problem... I'm using the the singleton as a central manager for file handles, memory allocators and many other resources. When a new object is created it uses this singleton to create and access its resources and when is destroyed it needs to use the same singleton to save some data, but the singleton it's not there anymore so it can't save its state and release its resources. Of course this is my use case, but you'll find many other use cases when a singletons must be the very last object that needs to be deleted. E.g. a Settings singleton which the active object needs it to save their states... > >>> I can't reference it > > > > for every object that depends on it, because, BTW, there are cases when > > the VM doesn't delete all the objects! Yes it has lots of memleaks at the > > end! > > What are you trying to say here? Is throwing mud supposed to motivate and > convince me? :( > No, not at all! I'm sorry if you see it that way ... I just tried to explain why your proposed workaround doesn't work... [..] > > At this point it's your word against mine :). You can try to convince me to > invest time to implement the behavior you'd like. You can try to implement > it yourself and convince me or some other approver to approve the change. > Or you can try to convince somebody else to implement the change. If you check the thread from the beginning you'll see that I'm not the only one who thinks that the current behavior is wrong. IMHO your approach is wrong, we all agreed that the current singletons behavior is not ok, but you still want use cases in order convince you that it needs to be fixed :). It is impossible for me (and for everybody else) to give you all the possible use cases out there when the singletons must be deleted last... IMHO you should ask yourself if there is any use case when the singleton should be deleted first ;-)... I think it will much faster to implement it myself :), if nobody wants to approve it, then I'll just keep for myself ;-)... Cheers, BogDan. From ddomenichelli at drdanz.it Tue Sep 30 12:22:26 2014 From: ddomenichelli at drdanz.it (Daniele E. Domenichelli) Date: Tue, 30 Sep 2014 12:22:26 +0200 Subject: [Development] QtDBus Improvements Message-ID: <542A8462.7060603@drdanz.it> Hello all, At Qt Contributors Summit 2013 in Bilbao we discussed some improvement to QtDBus: http://qt-project.org/groups/qt-contributors-summit-2013/wiki/QtDBus_CS I offered to help, but unfortunately I had some important family issues and I couldn't find the time to work on it, since then. Anyway from now on I should have some free time to work on Qt (not much, but better than nothing). Therefore I'm now renewing my offer. So, are these improvements still in the plan for QtDBus? Has anyone else been working on them? Where can I start? Cheers, Daniele From thiago.macieira at intel.com Tue Sep 30 13:49:21 2014 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Sep 2014 04:49:21 -0700 Subject: [Development] QtDBus Improvements In-Reply-To: <542A8462.7060603@drdanz.it> References: <542A8462.7060603@drdanz.it> Message-ID: <6391327.EaPgxzAF74@tjmaciei-mobl4> On Tuesday 30 September 2014 12:22:26 Daniele E. Domenichelli wrote: > Hello all, > > > At Qt Contributors Summit 2013 in Bilbao we discussed some improvement > to QtDBus: > > http://qt-project.org/groups/qt-contributors-summit-2013/wiki/QtDBus_CS > > I offered to help, but unfortunately I had some important family issues > and I couldn't find the time to work on it, since then. Anyway from now > on I should have some free time to work on Qt (not much, but better than > nothing). Therefore I'm now renewing my offer. > > So, are these improvements still in the plan for QtDBus? Has anyone else > been working on them? Where can I start? Hi Daniele Yes, those are still the targets and so far no work has happened. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From szehowe.koh at gmail.com Tue Sep 30 14:46:42 2014 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Tue, 30 Sep 2014 20:46:42 +0800 Subject: [Development] Proposal: Rename Qt WebSockets QML import Message-ID: Hi all, To bring the WebSocket QML import name in line with other modules (e.g. "QtWebEngine 1.0", "QtQuick 2.x", "QtWebKit 3.x", "QtSensors 5.x"), I propose changing the import: - From "import Qt.WebSockets 1.0" - To "import QtWebSockets 1.1" (no dot between "Qt" and "WebSockets") Ideally, the old import name + version number would still be available for compatibility, while newer versions would use the new name. Is this supported? What does everyone think? Regards, Sze-Howe From matnares at gmail.com Tue Sep 30 14:55:11 2014 From: matnares at gmail.com (=?UTF-8?B?TWF0w61hcyBOw6lzdG9yIEFyZXM=?=) Date: Tue, 30 Sep 2014 09:55:11 -0300 Subject: [Development] ListView + TextEdit tricky behavior Message-ID: Hi everyone! I'm developing an app with Qt, and I'm having some issues. I don't get a proper answer from the forums yet. So I ask it here, sorry if it is not the correct place. The problem description is on this post: http://qt-project.org/forums/viewthread/47948/ And a video of the symptom here: https://www.youtube.com/watch?v=1sHKnNZLzhs Thanks In Advance -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alexander.Blasche at digia.com Tue Sep 30 14:56:38 2014 From: Alexander.Blasche at digia.com (Blasche Alexander) Date: Tue, 30 Sep 2014 12:56:38 +0000 Subject: [Development] Proposal: Rename Qt WebSockets QML import In-Reply-To: References: 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-project.org] > On Behalf Of Sze Howe Koh > To bring the WebSocket QML import name in line with other modules > (e.g. "QtWebEngine 1.0", "QtQuick 2.x", "QtWebKit 3.x", "QtSensors > 5.x"), I propose changing the import: > > - From "import Qt.WebSockets 1.0" > - To "import QtWebSockets 1.1" (no dot between "Qt" and "WebSockets") I was considering to do the same a couple of days ago when I fixed the docs for it. If/when you do this please don't forgot to update the docs too. However why bumping the version? It would be just a rename while retaining the old name. If you must bump it it should rather be a bump it to 5.x. This forest of versions is just confusion without no purpose. > Ideally, the old import name + version number would still be available > for compatibility, while newer versions would use the new name. Is > this supported? Yes this can be done. It's just a matter of testing for both strings in the plug-ins type registrations. > What does everyone think? +10 ;) From kreios4004 at gmail.com Tue Sep 30 15:09:04 2014 From: kreios4004 at gmail.com (Keith Gardner) Date: Tue, 30 Sep 2014 08:09:04 -0500 Subject: [Development] ListView + TextEdit tricky behavior In-Reply-To: References: Message-ID: On Tue, Sep 30, 2014 at 7:55 AM, Matías Néstor Ares wrote: > Hi everyone! > I'm developing an app with Qt, and I'm having some issues. > I don't get a proper answer from the forums yet. > So I ask it here, sorry if it is not the correct place. > > The problem description is on this post: > http://qt-project.org/forums/viewthread/47948/ > And a video of the symptom here: > https://www.youtube.com/watch?v=1sHKnNZLzhs > > Thanks In Advance > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > Matias, I think the problem is that you are expecting your items to retail the typed text instead of your model. I think the ListView destroys delegates that are not within the view. Since your model is not retaining the typed text, this would explain why it is going away. I modified your delegate to show that this is the problem. delegate: Item { width: 100 height: 40 Component.onDestruction: { console.debug("Item destroyed") } Rectangle { width: 100 height: 40 color: colorCode TextEdit { font.pointSize: 23 anchors.fill: parent font.bold: true anchors.verticalCenter: parent.verticalCenter } } } Keith -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at digia.com Tue Sep 30 15:35:43 2014 From: mitch.curtis at digia.com (Mitch Curtis) Date: Tue, 30 Sep 2014 15:35:43 +0200 Subject: [Development] ListView + TextEdit tricky behavior In-Reply-To: References: Message-ID: <542AB1AF.7020105@digia.com> On 30/09/14 14:55, Matías Néstor Ares wrote: > Hi everyone! > I'm developing an app with Qt, and I'm having some issues. > I don't get a proper answer from the forums yet. > So I ask it here, sorry if it is not the correct place. > > The problem description is on this post: > http://qt-project.org/forums/viewthread/47948/ > And a video of the symptom here: > https://www.youtube.com/watch?v=1sHKnNZLzhs > > Thanks In Advance > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development A hacky solution is below. It's just to point out that the state (text input) should be stored outside the delegates, as people are mentioning - in this case, it's stored in textArray. import QtQuick 2.2 import QtQuick.Controls 1.2 ApplicationWindow { id: applicationWindow1 visible: true width: 200 height: 200 title: qsTr("TextEdit on ListView Test") property var textArray: { var a = []; for (var i = 0; i < listView1.count; ++i) { a[i] = ""; } a; } ListView { id: listView1 x: 286 width: 110 boundsBehavior: Flickable.StopAtBounds anchors.horizontalCenter: parent.horizontalCenter anchors.bottomMargin: 0 anchors.topMargin: 0 anchors.bottom: parent.bottom anchors.top: parent.top clip: true model: ListModel { ListElement { name: "Grey" colorCode: "grey" text: "" } ListElement { name: "Red" colorCode: "red" text: "" } ListElement { name: "Blue" colorCode: "blue" text: "" } ListElement { name: "Green" colorCode: "green" text: "" } ListElement { name: "Grey" colorCode: "grey" text: "" } ListElement { name: "Red" colorCode: "red" text: "" } ListElement { name: "Blue" colorCode: "blue" text: "" } ListElement { name: "Green" colorCode: "green" text: "" } ListElement { name: "Grey" colorCode: "grey" text: "" } ListElement { name: "Green" colorCode: "green" text: "" } ListElement { name: "Grey" colorCode: "grey" text: "" } ListElement { name: "Green" colorCode: "green" text: "" } ListElement { name: "Grey" colorCode: "grey" text: "" } ListElement { name: "Green" colorCode: "green" text: "" } ListElement { name: "Grey" colorCode: "grey" text: "" } ListElement { name: "Green" colorCode: "green" text: "" } ListElement { name: "Grey" colorCode: "grey" text: "" } ListElement { name: "Green" colorCode: "green" text: "" } ListElement { name: "Grey" colorCode: "grey" text: "" } ListElement { name: "Green" colorCode: "green" text: "" } ListElement { name: "Grey" colorCode: "grey" text: "" } } delegate: Item { width: 100 height: 40 Rectangle { width: 100 height: 40 color: colorCode TextEdit { id: textEdit font.pointSize: 23 anchors.fill: parent text: textArray[index] onTextChanged: textArray[index] = textEdit.text font.bold: true anchors.verticalCenter: parent.verticalCenter } } } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at digia.com Tue Sep 30 15:40:02 2014 From: mitch.curtis at digia.com (Mitch Curtis) Date: Tue, 30 Sep 2014 15:40:02 +0200 Subject: [Development] ListView + TextEdit tricky behavior In-Reply-To: <542AB1AF.7020105@digia.com> References: <542AB1AF.7020105@digia.com> Message-ID: <542AB2B2.6050008@digia.com> On 30/09/14 15:35, Mitch Curtis wrote: > > On 30/09/14 14:55, Matías Néstor Ares wrote: >> Hi everyone! >> I'm developing an app with Qt, and I'm having some issues. >> I don't get a proper answer from the forums yet. >> So I ask it here, sorry if it is not the correct place. >> >> The problem description is on this post: >> http://qt-project.org/forums/viewthread/47948/ >> And a video of the symptom here: >> https://www.youtube.com/watch?v=1sHKnNZLzhs >> >> Thanks In Advance >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > A hacky solution is below. It's just to point out that the state (text > input) should be stored outside the delegates, as people are > mentioning - in this case, it's stored in textArray. > > [snip] A slightly neater but still hacky example: import QtQuick 2.2 import QtQuick.Controls 1.2 ApplicationWindow { id: applicationWindow1 visible: true width: 200 height: 200 title: qsTr("TextEdit on ListView Test") property var textArray: { var a = []; for (var i = 0; i < listView1.count; ++i) { a[i] = ""; } a; } ListView { id: listView1 x: 286 width: 110 boundsBehavior: Flickable.StopAtBounds anchors.horizontalCenter: parent.horizontalCenter anchors.bottomMargin: 0 anchors.topMargin: 0 anchors.bottom: parent.bottom anchors.top: parent.top clip: true model: ListModel { Component.onCompleted: { for (var i = 0; i < 10; ++i) { append({name: "Grey", colorCode: "grey"}); append({name: "Red", colorCode: "red"}); } } } delegate: Item { width: 100 height: 40 Rectangle { width: 100 height: 40 color: colorCode TextEdit { id: textEdit font.pointSize: 23 anchors.fill: parent text: index < textArray.length ? textArray[index] : "" onTextChanged: textArray[index] = textEdit.text font.bold: true anchors.verticalCenter: parent.verticalCenter } } } } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From kreios4004 at gmail.com Tue Sep 30 15:39:48 2014 From: kreios4004 at gmail.com (Keith Gardner) Date: Tue, 30 Sep 2014 08:39:48 -0500 Subject: [Development] ListView + TextEdit tricky behavior In-Reply-To: <542AB1AF.7020105@digia.com> References: <542AB1AF.7020105@digia.com> Message-ID: On Tue, Sep 30, 2014 at 8:35 AM, Mitch Curtis wrote: > > On 30/09/14 14:55, Matías Néstor Ares wrote: > > Hi everyone! > I'm developing an app with Qt, and I'm having some issues. > I don't get a proper answer from the forums yet. > So I ask it here, sorry if it is not the correct place. > > The problem description is on this post: > http://qt-project.org/forums/viewthread/47948/ > And a video of the symptom here: > https://www.youtube.com/watch?v=1sHKnNZLzhs > > Thanks In Advance > > > _______________________________________________ > Development mailing listDevelopment at qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development > > > A hacky solution is below. It's just to point out that the state (text > input) should be stored outside the delegates, as people are mentioning - > in this case, it's stored in textArray. > > > delegate: Item { > width: 100 > height: 40 > Rectangle { > width: 100 > height: 40 > color: colorCode > TextEdit { > id: textEdit > font.pointSize: 23 > anchors.fill: parent > text: textArray[index] > onTextChanged: textArray[index] = textEdit.text > > font.bold: true > anchors.verticalCenter: parent.verticalCenter > } > } > } > } > } > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > For the TextEdit, the item should just load and store directly to/from the model, no array needed. TextEdit { id: textEdit font.pointSize: 23 anchors.fill: parent text: model.modelData.text onTextChanged: model.modelData.text = text font.bold: true anchors.verticalCenter: parent.verticalCenter } -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.m.winklmeier at gmail.com Tue Sep 30 17:20:18 2014 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Tue, 30 Sep 2014 17:20:18 +0200 Subject: [Development] QtDBus Improvements In-Reply-To: <6391327.EaPgxzAF74@tjmaciei-mobl4> References: <542A8462.7060603@drdanz.it> <6391327.EaPgxzAF74@tjmaciei-mobl4> Message-ID: <542ACA32.3060805@gmail.com> On 09/30/2014 01:49 PM, Thiago Macieira wrote: > On Tuesday 30 September 2014 12:22:26 Daniele E. Domenichelli wrote: >> So, are these improvements still in the plan for QtDBus? Has anyone else >> been working on them? Where can I start? > > Hi Daniele > > Yes, those are still the targets and so far no work has happened. > Hi there, as I'm using DBus on several platforms (Linux, Mac and also Win) I'm eager to get these improvements done. Especially DBus per default in Windows installers would be very nice. Therefore I'm happy to help and contribute, if there is a concrete task to do. I would especially be interested to be work on DBus across machines in the network (also called remote DBus). I understood it could be possible via a ssl socket. From matnares at gmail.com Tue Sep 30 20:44:28 2014 From: matnares at gmail.com (=?UTF-8?B?TWF0w61hcyBOw6lzdG9yIEFyZXM=?=) Date: Tue, 30 Sep 2014 15:44:28 -0300 Subject: [Development] ListView + TextEdit tricky behavior In-Reply-To: References: <542AB1AF.7020105@digia.com> Message-ID: Thank you Both, Very usefull, I'm now working with the data stored on the model. Best Regards 2014-09-30 10:39 GMT-03:00 Keith Gardner : > > > On Tue, Sep 30, 2014 at 8:35 AM, Mitch Curtis > wrote: > >> >> On 30/09/14 14:55, Matías Néstor Ares wrote: >> >> Hi everyone! >> I'm developing an app with Qt, and I'm having some issues. >> I don't get a proper answer from the forums yet. >> So I ask it here, sorry if it is not the correct place. >> >> The problem description is on this post: >> http://qt-project.org/forums/viewthread/47948/ >> And a video of the symptom here: >> https://www.youtube.com/watch?v=1sHKnNZLzhs >> >> Thanks In Advance >> >> >> _______________________________________________ >> Development mailing listDevelopment at qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development >> >> >> A hacky solution is below. It's just to point out that the state (text >> input) should be stored outside the delegates, as people are mentioning - >> in this case, it's stored in textArray. >> >> >> delegate: Item { >> width: 100 >> height: 40 >> Rectangle { >> width: 100 >> height: 40 >> color: colorCode >> TextEdit { >> id: textEdit >> font.pointSize: 23 >> anchors.fill: parent >> text: textArray[index] >> > > onTextChanged: textArray[index] = textEdit.text >> > > >> font.bold: true >> anchors.verticalCenter: parent.verticalCenter >> } >> } >> } >> } >> } >> >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> > For the TextEdit, the item should just load and store directly to/from the > model, no array needed. > TextEdit { > id: textEdit > font.pointSize: 23 > anchors.fill: parent > text: model.modelData.text > onTextChanged: model.modelData.text = text > font.bold: true > anchors.verticalCenter: parent.verticalCenter > } > -------------- next part -------------- An HTML attachment was scrubbed... URL: