From marc.mutz at kdab.com Mon Feb 1 11:08:54 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 1 Feb 2016 11:08:54 +0100 Subject: [Development] RFC: lambda or lambda return from lambda? Message-ID: <201602011108.54803.marc.mutz@kdab.com> Hi, We're seeing increasing use of lambdas in dev, and I'm a bit unhappy about the result. E.g. (not picking on Anton here, I have done the same before): auto firstEqualsName = [&name](const QPair &header) { return qstricmp(name.constData(), header.first) == 0; }; fields.erase(std::remove_if(fields.begin(), fields.end(), firstEqualsName), fields.end()); This is one way to write a unary predicate. But it hides the fact that the predicate depends on the parameter 'name' (an argument to the function this lambda is defined in). With classical function objects, one would have written - at the call site: fields.erase(std::remove_if(fields.begin(), fields.end(), FirstEquals(name)), fields.end()); See the difference? Now, we don't want to go back and write function objects for one-time use, but it would be nice to have this explicit syntax, would it not? One way to have this with lambdas is to write a lambda that returns a lambda. We can do this, because auto return type deduction works for lambdas already in C++11, unlike for normal functions. With this, the above would become (hold tight): auto firstEquals = [](const auto &name) { return [&name](auto header) { return qstricmp(header.first, name) == 0; }; } where I used auto and dropped the const-& argument passing only for exposition, to get it onto a single line. fields.erase(std::remove_if(fields.begin(), fields.end(), firstEquals(name)), fields.end()); So, where to put the ugliness: on the definition of the lambda, or the call site? (Note that "if you use this lambda more than once, then X" is not a good answer, because you shouldn't use lambdas more than once. But with the lambda- returning-lambda, you could actually reuse them: // at global scope: auto firstEquals = [](const auto &name) { return [&name](auto header) { return qstricmp(header.first, name) == 0; }; } // use in several functions - always the same type Whereas without the outer lambda, each use would create a new type, and potentially duplicate code (same problem as QStringLiteral, and the same soultion, really: wrap them in a function, except for lambdas, because of the unnameable return type, we need to use another lambda instead of a classical function). So, which one to use? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From jedrzej.nowacki at theqtcompany.com Mon Feb 1 10:18:25 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 1 Feb 2016 10:18:25 +0100 Subject: [Development] RFC: lambda or lambda return from lambda? In-Reply-To: <201602011108.54803.marc.mutz@kdab.com> References: <201602011108.54803.marc.mutz@kdab.com> Message-ID: <22038065.qFJLBAWTq4@42> On Monday 01 of February 2016 11:08:54 Marc Mutz wrote: > Hi, > > We're seeing increasing use of lambdas in dev, and I'm a bit unhappy about > the result. > > E.g. (not picking on Anton here, I have done the same before): > > auto firstEqualsName = [&name](const QPair &header) > { > return qstricmp(name.constData(), header.first) == 0; > }; > fields.erase(std::remove_if(fields.begin(), fields.end(), > firstEqualsName), > fields.end()); > > This is one way to write a unary predicate. But it hides the fact that the > predicate depends on the parameter 'name' (an argument to the function this > lambda is defined in). > > With classical function objects, one would have written - at the call site: > > fields.erase(std::remove_if(fields.begin(), fields.end(), > FirstEquals(name)), > fields.end()); > > See the difference? > > Now, we don't want to go back and write function objects for one-time use, > but it would be nice to have this explicit syntax, would it not? > > One way to have this with lambdas is to write a lambda that returns a > lambda. We can do this, because auto return type deduction works for > lambdas already in C++11, unlike for normal functions. With this, the above > would become (hold tight): > > auto firstEquals = [](const auto &name) { > return [&name](auto header) { return qstricmp(header.first, name) == 0; > }; } > > where I used auto and dropped the const-& argument passing only for > exposition, to get it onto a single line. > > fields.erase(std::remove_if(fields.begin(), fields.end(), > firstEquals(name)), > fields.end()); > > So, where to put the ugliness: on the definition of the lambda, or the call > site? (Note that "if you use this lambda more than once, then X" is not a > good answer, because you shouldn't use lambdas more than once. But with the > lambda- returning-lambda, you could actually reuse them: > > // at global scope: > > auto firstEquals = [](const auto &name) { > return [&name](auto header) { return qstricmp(header.first, name) == 0; > }; } > > // use in several functions - always the same type > > Whereas without the outer lambda, each use would create a new type, and > potentially duplicate code (same problem as QStringLiteral, and the same > soultion, really: wrap them in a function, except for lambdas, because of > the unnameable return type, we need to use another lambda instead of a > classical function). > > So, which one to use? > > Thanks, > Marc Hi, I would just inline the lambda inside remove_if. That way "name" would be explicit in place in which it is used and you could avoid 2nd lambda. So it would look like that: fields.erase(std::remove_if(fields.begin(), fields.end(), [&name](const QPair &header) { return qstricmp(name.constData(), header.first) == 0; }), fields.end()); // I hope that formating is still ok, and the code is not wrapped. For a bigger code we would actually require named functions. What do you think? Cheers, Jędrek From christian.kandeler at theqtcompany.com Mon Feb 1 10:23:34 2016 From: christian.kandeler at theqtcompany.com (Christian Kandeler) Date: Mon, 1 Feb 2016 10:23:34 +0100 Subject: [Development] RFC: lambda or lambda return from lambda? In-Reply-To: <201602011108.54803.marc.mutz@kdab.com> References: <201602011108.54803.marc.mutz@kdab.com> Message-ID: <56AF2416.30209@theqtcompany.com> On 02/01/2016 11:08 AM, Marc Mutz wrote: > We're seeing increasing use of lambdas in dev, and I'm a bit unhappy about the > result. > > E.g. (not picking on Anton here, I have done the same before): > > auto firstEqualsName = [&name](const QPair &header) > { > return qstricmp(name.constData(), header.first) == 0; > }; > fields.erase(std::remove_if(fields.begin(), fields.end(), > firstEqualsName), > fields.end()); > > This is one way to write a unary predicate. But it hides the fact that the > predicate depends on the parameter 'name' (an argument to the function this > lambda is defined in). > > With classical function objects, one would have written - at the call site: > > fields.erase(std::remove_if(fields.begin(), fields.end(), > FirstEquals(name)), > fields.end()); > > See the difference? Yes, but it is offset by another difference: As opposed to the function object, the lambda is defined right above the call site (or at least very close to it), so you can easily see that it captures an additional variable. I therefore think that this is not a problem. Christian From marc.mutz at kdab.com Mon Feb 1 15:10:01 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 1 Feb 2016 15:10:01 +0100 Subject: [Development] RFC: lambda or lambda return from lambda? In-Reply-To: <56AF2416.30209@theqtcompany.com> References: <201602011108.54803.marc.mutz@kdab.com> <56AF2416.30209@theqtcompany.com> Message-ID: <201602011510.01089.marc.mutz@kdab.com> On Monday 01 February 2016 10:23:34 Christian Kandeler wrote: > On 02/01/2016 11:08 AM, Marc Mutz wrote: > > We're seeing increasing use of lambdas in dev, and I'm a bit unhappy > > about the result. > > > > E.g. (not picking on Anton here, I have done the same before): > > auto firstEqualsName = [&name](const QPair > > &header) { > > > > return qstricmp(name.constData(), header.first) == 0; > > > > }; > > fields.erase(std::remove_if(fields.begin(), fields.end(), > > > > firstEqualsName), > > > > fields.end()); > > > > This is one way to write a unary predicate. But it hides the fact that > > the predicate depends on the parameter 'name' (an argument to the > > function this lambda is defined in). > > > > With classical function objects, one would have written - at the call site: > > fields.erase(std::remove_if(fields.begin(), fields.end(), > > > > FirstEquals(name)), > > > > fields.end()); > > > > See the difference? > > Yes, but it is offset by another difference: As opposed to the function > object, the lambda is defined right above the call site (or at least > very close to it), so you can easily see that it captures an additional > variable. > I therefore think that this is not a problem. The point of giving names to things (variable, functions, classes) in programming is so you don't need to look at the implementation all the time to see what it's doing. You only need to look when you want to see _how_ it's doing what it does. So if you think that this is not a problem, then it's not a problem for you, either, if local variables are named only a, b, c, ... And I disagree. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Mon Feb 1 15:16:33 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 1 Feb 2016 15:16:33 +0100 Subject: [Development] RFC: lambda or lambda return from lambda? In-Reply-To: <22038065.qFJLBAWTq4@42> References: <201602011108.54803.marc.mutz@kdab.com> <22038065.qFJLBAWTq4@42> Message-ID: <201602011516.33182.marc.mutz@kdab.com> On Monday 01 February 2016 10:18:25 Jędrzej Nowacki wrote: > So it would look like that: > > fields.erase(std::remove_if(fields.begin(), > fields.end(), > [&name](const QPair > &header) > { > return qstricmp(name.constData(), > header.first) == 0; > }), > fields.end()); > > // I hope that formating is still ok, and the code is not wrapped. > I am a great fanboy of algorithms and the STL, as should be clear by now :) But I find the inlined lambda worse than an explicit loop. This is write-only code, imo. Esp. since we can't (yet) use auto in the parameter list, but even then, I'd always give a lambda a name (cf. my mail in response to Christian). > For a bigger code we would actually require named functions. What do you > think? Named functions have two problems: a) that many compilers don't inline the code. So at a minimum, you'd write a forwarding lambda, or the function would be an auto variable holding a stateless lambda (the difference between the two is almost non-existent, anyway). And b) that they cannot carry state. Lambdas can. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From christian.kandeler at theqtcompany.com Mon Feb 1 14:16:57 2016 From: christian.kandeler at theqtcompany.com (Christian Kandeler) Date: Mon, 1 Feb 2016 14:16:57 +0100 Subject: [Development] RFC: lambda or lambda return from lambda? In-Reply-To: <201602011510.01089.marc.mutz@kdab.com> References: <201602011108.54803.marc.mutz@kdab.com> <56AF2416.30209@theqtcompany.com> <201602011510.01089.marc.mutz@kdab.com> Message-ID: <56AF5AC9.1080003@theqtcompany.com> On 02/01/2016 03:10 PM, Marc Mutz wrote: > The point of giving names to things (variable, functions, classes) in > programming is so you don't need to look at the implementation all the time to > see what it's doing. You only need to look when you want to see _how_ it's > doing what it does. > > So if you think that this is not a problem, then it's not a problem for you, > either, if local variables are named only a, b, c, ... Depending on the context, yes. For instance, I have never written this: for (int thisIsACounterThatIsUsedForIteration = 0; thisIsACounterThatIsUsedForIteration < arrayLen; ++thisIsACounterThatIsUsedForIteration) { ... } Instead, I simply use the name "i". Inacceptable? Christian From marc.mutz at kdab.com Mon Feb 1 15:37:15 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 1 Feb 2016 15:37:15 +0100 Subject: [Development] RFC: lambda or lambda return from lambda? In-Reply-To: <56AF5AC9.1080003@theqtcompany.com> References: <201602011108.54803.marc.mutz@kdab.com> <201602011510.01089.marc.mutz@kdab.com> <56AF5AC9.1080003@theqtcompany.com> Message-ID: <201602011537.15123.marc.mutz@kdab.com> On Monday 01 February 2016 14:16:57 Christian Kandeler wrote: > On 02/01/2016 03:10 PM, Marc Mutz wrote: > > The point of giving names to things (variable, functions, classes) in > > programming is so you don't need to look at the implementation all the > > time to see what it's doing. You only need to look when you want to see > > _how_ it's doing what it does. > > > > So if you think that this is not a problem, then it's not a problem for > > you, either, if local variables are named only a, b, c, ... > > Depending on the context, yes. For instance, I have never written this: > for (int thisIsACounterThatIsUsedForIteration = 0; > thisIsACounterThatIsUsedForIteration < arrayLen; > ++thisIsACounterThatIsUsedForIteration) { ... } > > Instead, I simply use the name "i". Inacceptable? No, perfectly ok. But only because by unwrit convention indexed for-loops use 'i', 'j', ... as the index variable, and iterator-based for-loops use 'it' as the iterator variable. As soon as you name an iterator 'i', say, it ceases to be acceptable. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From sergio.martins at kdab.com Mon Feb 1 13:34:05 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Mon, 01 Feb 2016 13:34:05 +0100 Subject: [Development] RFC: lambda or lambda return from lambda? In-Reply-To: <201602011108.54803.marc.mutz@kdab.com> References: <201602011108.54803.marc.mutz@kdab.com> Message-ID: <41557197.4l9Xc1GA8i@desktop-ga45d22> On Monday, February 01, 2016 11:08:54 AM Marc Mutz wrote: > Hi, > > We're seeing increasing use of lambdas in dev, and I'm a bit unhappy about > the result. > > E.g. (not picking on Anton here, I have done the same before): > > auto firstEqualsName = [&name](const QPair &header) > { > return qstricmp(name.constData(), header.first) == 0; > }; > fields.erase(std::remove_if(fields.begin(), fields.end(), > firstEqualsName), > fields.end()); > > This is one way to write a unary predicate. But it hides the fact that the > predicate depends on the parameter 'name' (an argument to the function this > lambda is defined in). > > With classical function objects, one would have written - at the call site: > > fields.erase(std::remove_if(fields.begin(), fields.end(), > FirstEquals(name)), > fields.end()); > > See the difference? > > Now, we don't want to go back and write function objects for one-time use, > but it would be nice to have this explicit syntax, would it not? > > One way to have this with lambdas is to write a lambda that returns a > lambda. We can do this, because auto return type deduction works for > lambdas already in C++11, unlike for normal functions. With this, the above > would become (hold tight): > > auto firstEquals = [](const auto &name) { > return [&name](auto header) { return qstricmp(header.first, name) == 0; > }; } > > where I used auto and dropped the const-& argument passing only for > exposition, to get it onto a single line. > > fields.erase(std::remove_if(fields.begin(), fields.end(), > firstEquals(name)), > fields.end()); > > So, where to put the ugliness: on the definition of the lambda, or the call > site? (Note that "if you use this lambda more than once, then X" is not a > good answer, because you shouldn't use lambdas more than once. But with the > lambda- returning-lambda, you could actually reuse them: > > // at global scope: > > auto firstEquals = [](const auto &name) { > return [&name](auto header) { return qstricmp(header.first, name) == 0; > }; } > > // use in several functions - always the same type > > Whereas without the outer lambda, each use would create a new type, and > potentially duplicate code (same problem as QStringLiteral, and the same > soultion, really: wrap them in a function, except for lambdas, because of > the unnameable return type, we need to use another lambda instead of a > classical function). I would write: removeIfFirstEquals(fields, name): because: 1) I could read it in English instead of very verbose C++ 2) I would not need to read the implementation And for the implementation.. it doesn't matter, it's a named function, only does one small thing and does it good. About the inlining, which compilers don't and does it make a difference ? A function call should negligible compared to erase + remove_if Regards, -- Sérgio Martins | sergio.martins at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From andre at familiesomers.nl Mon Feb 1 14:43:08 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Mon, 1 Feb 2016 14:43:08 +0100 Subject: [Development] RFC: lambda or lambda return from lambda? In-Reply-To: <201602011516.33182.marc.mutz@kdab.com> References: <201602011108.54803.marc.mutz@kdab.com> <22038065.qFJLBAWTq4@42> <201602011516.33182.marc.mutz@kdab.com> Message-ID: <56AF60EC.3090700@familiesomers.nl> Op 01/02/2016 om 15:16 schreef Marc Mutz: > On Monday 01 February 2016 10:18:25 Jędrzej Nowacki wrote: >> So it would look like that: >> >> fields.erase(std::remove_if(fields.begin(), >> fields.end(), >> [&name](const QPair >> &header) >> { >> return qstricmp(name.constData(), >> header.first) == 0; >> }), >> fields.end()); >> >> // I hope that formating is still ok, and the code is not wrapped. >> > I am a great fanboy of algorithms and the STL, as should be clear by now :) > > But I find the inlined lambda worse than an explicit loop. This is write-only > code, imo. Esp. since we can't (yet) use auto in the parameter list, but even > then, I'd always give a lambda a name (cf. my mail in response to Christian). While I applaud the naming of things, especiallly things non-trivial, I don't agree that an inlined lambda equates to write-only code. It can be, but doesn't need to be. The lambda-to-return a lambda looks more write-only than an inlined lambda does, IMHO. While self-documenting code is great, I don't think it should come at the price of outlandish constructs like lambdas-returning-lambdas. It cleans up the code at the place you call the code, I give you that, but it makes the lambda definition itself too complicated. I prefer a comment if you think that documenting what is captured at the call site is needed. auto firstEqualsName = [&name](const QPair &header) { return qstricmp(name.constData(), header.first) == 0; }; fields.erase(std::remove_if(fields.begin(), fields.end(), firstEqualsName /*captures &name*/), fields.end()); Though for this particular construct, I certainly prefer a special function. The erase + remove_if, both using the same end iterator always annoys me. So something like: removeWhereFirstEquals(container c, const QByteArray& name); André From kevin.kofler at chello.at Mon Feb 1 14:52:19 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 01 Feb 2016 14:52:19 +0100 Subject: [Development] RFC: lambda or lambda return from lambda? References: <201602011108.54803.marc.mutz@kdab.com> <22038065.qFJLBAWTq4@42> <201602011516.33182.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > But I find the inlined lambda worse than an explicit loop. This is > write-only code, imo. Esp. since we can't (yet) use auto in the parameter > list, but even then, I'd always give a lambda a name (cf. my mail in > response to Christian). But writing it inline and without a name is the whole point of a lambda. If you're giving it a name anyway, you may as well declare a named functor class. > Named functions have two problems: a) that many compilers don't inline the > code. So at a minimum, you'd write a forwarding lambda, or the function > would be an auto variable holding a stateless lambda (the difference > between the two is almost non-existent, anyway). And b) that they cannot > carry state. Lambdas can. Named functor classes can, too. And I actually like Sergio Martins's solution best: Write a removeIfFirstEquals(fields, name) wrapper that hides the lambda entirely. There, you can also inline the lambda because the name of the containing function (removeIfFirstEquals) makes it very clear what the lambda does. And the calling code does not have to care how the "if first equals" test is actually implemented. Kevin Kofler From kevin.kofler at chello.at Mon Feb 1 15:26:57 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 01 Feb 2016 15:26:57 +0100 Subject: [Development] 5.7 feature freeze References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> Message-ID: Knoll Lars wrote: > we’re slightly past the originally planned date for the feature freeze, > for various reasons (new stuff being open sourced, license change and > being late with 5.6). But I believe most things should be in place now to > do the feature freeze for 5.7 next Monday. What sense does it make to feature-freeze 5.7 before 5.6 is even out yet? Distributions out there are still shipping (at best) 5.5 (which is still the latest stable release series you have to offer), and all new features (except the 3 you listed) are already being pushed back to 5.8, i.e., 3 branches later than what is actually shipped. This means any improvements you make take really long to get to your users. Kevin Kofler From thiago.macieira at intel.com Mon Feb 1 17:06:51 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 01 Feb 2016 08:06:51 -0800 Subject: [Development] RFC: lambda or lambda return from lambda? In-Reply-To: <201602011108.54803.marc.mutz@kdab.com> References: <201602011108.54803.marc.mutz@kdab.com> Message-ID: <1723313.Wqb3VE2a6U@tjmaciei-mobl4> On Monday 01 February 2016 11:08:54 Marc Mutz wrote: > One way to have this with lambdas is to write a lambda that returns a > lambda. We can do this, because auto return type deduction works for > lambdas already in C++11, unlike for normal functions. With this, the above > would become (hold tight): > > auto firstEquals = [](const auto &name) { Does parameter auto detection work in C++11? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Mon Feb 1 18:21:42 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 1 Feb 2016 18:21:42 +0100 Subject: [Development] RFC: lambda or lambda return from lambda? In-Reply-To: <1723313.Wqb3VE2a6U@tjmaciei-mobl4> References: <201602011108.54803.marc.mutz@kdab.com> <1723313.Wqb3VE2a6U@tjmaciei-mobl4> Message-ID: <201602011821.42863.marc.mutz@kdab.com> On Monday 01 February 2016 17:06:51 Thiago Macieira wrote: > On Monday 01 February 2016 11:08:54 Marc Mutz wrote: > > One way to have this with lambdas is to write a lambda that returns a > > lambda. We can do this, because auto return type deduction works for > > lambdas already in C++11, unlike for normal functions. With this, the > > above > > > > would become (hold tight): > > > > auto firstEquals = [](const auto &name) { > > Does parameter auto detection work in C++11? No, but you snipped the part of the mail where I explained that I used auto only to fit it to a single line. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Mon Feb 1 18:37:32 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 1 Feb 2016 18:37:32 +0100 Subject: [Development] RFC: lambda or lambda return from lambda? In-Reply-To: <41557197.4l9Xc1GA8i@desktop-ga45d22> References: <201602011108.54803.marc.mutz@kdab.com> <41557197.4l9Xc1GA8i@desktop-ga45d22> Message-ID: <201602011837.32867.marc.mutz@kdab.com> On Monday 01 February 2016 13:34:05 Sergio Martins wrote: > I would write: > > removeIfFirstEquals(fields, name): because: > > 1) I could read it in English instead of very verbose C++ > 2) I would not need to read the implementation I tend to agree, but it only shifts the issue down one level of abstraction. And removeIfFirstEquals() isn't exactly clear, either. fields.removeIfFirstEquals(name) would be. Maybe when C++ lifts the distinction between a.f(b) and f(a, b)... It also doesn't help when you need to reuse the lambda, e.g. when sorting a range by some predicate and then merging the range into an existing one. > And for the implementation.. it doesn't matter, it's a named function, > only does one small thing and does it good. > > About the inlining, which compilers don't and does it make a difference ? Almost none do, unless they use/you switch on whole-program-optimisation. > A function call should negligible compared to erase + remove_if It's not just a function call, it's a function call though a function pointer. Costs like a virtual function call and turns C++ std::sort into C's qsort. http://stackoverflow.com/questions/4708105/performance-of-qsort-vs-stdsort Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From olivier at woboq.com Mon Feb 1 18:53:18 2016 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 01 Feb 2016 18:53:18 +0100 Subject: [Development] 5.7 feature freeze In-Reply-To: References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> Message-ID: <2272616.YTbEx6bI1J@finn> On Montag, 1. Februar 2016 15:26:57 CET Kevin Kofler wrote: > Knoll Lars wrote: > > we’re slightly past the originally planned date for the feature freeze, > > for various reasons (new stuff being open sourced, license change and > > being late with 5.6). But I believe most things should be in place now to > > do the feature freeze for 5.7 next Monday. > > What sense does it make to feature-freeze 5.7 before 5.6 is even out yet? It means we don't delay the release of 5.7 too much even tough 5.6 was delayed. 5.7 already contains all the features developed since the 5.6 feature freeze which was long ago. > Distributions out there are still shipping (at best) 5.5 (which is still the > latest stable release series you have to offer), and all new features > (except the 3 you listed) are already being pushed back to 5.8, i.e., 3 > branches later than what is actually shipped. This is irrelevant > This means any improvements you make take really long to get to your users. It would take longer without the feature freeze. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Mon Feb 1 19:10:07 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 01 Feb 2016 10:10:07 -0800 Subject: [Development] 5.7 feature freeze In-Reply-To: <2272616.YTbEx6bI1J@finn> References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> <2272616.YTbEx6bI1J@finn> Message-ID: <3824229.rxj83apCVF@tjmaciei-mobl4> On Monday 01 February 2016 18:53:18 Olivier Goffart wrote: > > What sense does it make to feature-freeze 5.7 before 5.6 is even out yet? > > It means we don't delay the release of 5.7 too much even tough 5.6 was > delayed. 5.7 already contains all the features developed since the 5.6 > feature freeze which was long ago. We do need that 5.7 branch now, though. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jedrzej.nowacki at theqtcompany.com Tue Feb 2 09:24:22 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Tue, 2 Feb 2016 09:24:22 +0100 Subject: [Development] RFC: lambda or lambda return from lambda? In-Reply-To: <201602011516.33182.marc.mutz@kdab.com> References: <201602011108.54803.marc.mutz@kdab.com> <22038065.qFJLBAWTq4@42> <201602011516.33182.marc.mutz@kdab.com> Message-ID: <1728208.AKGlkRUmu1@42> On Monday 01 of February 2016 15:16:33 you wrote: > I am a great fanboy of algorithms and the STL, as should be clear by now You are excused ;-) But seriously I do not think there is anything wrong about it, STL is a bit obscure, but fast and sometimes a code needs to be fast. > But I find the inlined lambda worse than an explicit loop. This is > write-only code, imo. Esp. since we can't (yet) use auto in the parameter > list, but even then, I'd always give a lambda a name (cf. my mail in > response to Christian). Hmmm, In my opinion you do not like the most cool feature of lambdas :-) Each time I was forced to define a functor somewhere, in a completely different place then my code lived, I was sad and jealous of python lambda syntax. I value a code that can be read from top to down without major jumps. Naming lambdas causes my eyes to jump ("so for each element it calls a function FooBar... Ah which does that") and it also suggests that the lambda will be re-used ("ok, so now remember FooBar, as it will be used again..."). I would much prefer a simple inline comment before sequence of std::remove_if std::erase and others then named lambda. Anyway I guess we are again hitting a "C++11 syntax that we were not used to" issue. So please do not create any policy about that, at least not for now. Btw. when you are taking an address of a function you force a compiler to de- inline the function, I hope such de-optimization doesn't happen while naming lambdas. > > For a bigger code we would actually require named functions. What do you > > think? > > Named functions have two problems: a) that many compilers don't inline the > code. So at a minimum, you'd write a forwarding lambda, or the function > would be an auto variable holding a stateless lambda (the difference > between the two is almost non-existent, anyway). And b) that they cannot > carry state. Lambdas can. Sorry I used wrong wording, by named function I meant, assigned lambda, a functor or a declared function. In general a callable with a name, defined in a different place then used. A propos inline'ing of functions, have you tried anonymous namespaces? That should help. At least once I forced gcc to inline the code... Cheers, Jędrek From ruslan_baratov at yahoo.com Tue Feb 2 13:28:58 2016 From: ruslan_baratov at yahoo.com (Ruslan Baratov) Date: Tue, 2 Feb 2016 19:28:58 +0700 Subject: [Development] QCameraViewfinderSettingsControl2 for Android Message-ID: <56B0A10A.4000709@yahoo.com> Hi, I'm planning to try to implement QCameraViewfinderSettingsControl2 for Android and want to check that nobody has some related work-in-progress patches already. So from my understanding most of the work already done in qtmultimedia/src/plugins/android/src/wrapper/jni/androidcamera.cpp, like getSupportedPreviewSizes or setPreviewSize and only wrapper with QCameraViewfinderSettingsControl2 API need to be introduced, right? Any hints/implementation directions welcome. Thanks, Ruslo From jani.heikkinen at theqtcompany.com Tue Feb 2 13:51:29 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Tue, 2 Feb 2016 12:51:29 +0000 Subject: [Development] HEADS UP: Qt 5.6.0 branching ongoing In-Reply-To: References: , Message-ID: Hi, Final downmerge is now done and branching is complete. From now on '5.6' is for Qt 5.6.1 and '5.6.0' for Qt 5.6.0. Staging in '5.6.0' is restricted and we in the release team will stage needed changes in '5.6.0' from now on. We will check approved changes automatically so no need for any special actions from you; just take care that your changes will be approved. And please remember: We will take in only really important changes so please don't add any nice-to-haves in '5.6.0' anymore! If we can live with issue in Qt 5.6.0 then please use '5.6' instead. And as usual please send re-targeting request to Ossi if there is some change open in '5.6' and which must be in Qt 5.6.0 br, Jani ________________________________________ Lähettäjä: Heikkinen Jani Lähetetty: 25. tammikuuta 2016 13:39 Vastaanottaja: development at qt-project.org Kopio: releasing at qt-project.org Aihe: HEADS UP: Qt 5.6.0 branching ongoing ‘5.6.0’ branch is now available, please start using it for the changes targeted to Qt5.6.0 release. We will merge ‘5.6’ branch to ‘5.6.0’ Monday 1st February so there should be enough time to finalize ongoing changes in ‘5.6’ and start using '5.6.0'. All new changes for Qt5.6.0 should be done in ‘5.6.0’ branch from now on. Target is to release Qt5.6.0 RC quite soon so please make sure all blockers will be fixed as soon as possible. Blocker list here: https://bugreports.qt.io/issues/?filter=17225 Please make sure all Qt 5.6.0 blockers are found from blocker list (== set 5.6.0 RC as fix version(s)): We should fix all blockers before RC & minimize changes between RC and final. And please remember: Do not add any 'nice to have' -changes in anymore (P0 & P1 bug fixes mostly, in some special cases p2 fixes might be ok as well). Best regards, Jani Heikkinen Release Manager | The Qt Company The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland Email: jani.heikkinen at theqtcompany.com | Mobile: + 358 50 48 73 735 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject Facebook: www.facebook.com/qt From rpzrpzrpz at gmail.com Tue Feb 2 15:37:14 2016 From: rpzrpzrpz at gmail.com (mark diener) Date: Tue, 2 Feb 2016 08:37:14 -0600 Subject: [Development] HEADS UP: Qt 5.6.0 branching ongoing In-Reply-To: References: Message-ID: Jani: I submitted a message a week ago about the blocker list criterion and could not find a QT FAQ on what are the critierion. For example: https://bugreports.qt.io/browse/QTBUG-50374 is NOT a blocker for 5.6.0 RC. It is P2: Important. Likely I am missing something about how the blocker list is constructed and interpreted. But should 5.6.0 release with QTBUG-50374 still present, Qt is effectively saying, we have cut back support for IOS. And that would be big news. Please educate me. md On Tue, Feb 2, 2016 at 6:51 AM, Heikkinen Jani wrote: > Hi, > > Final downmerge is now done and branching is complete. From now on '5.6' is for Qt 5.6.1 and '5.6.0' for Qt 5.6.0. Staging in '5.6.0' is restricted and we in the release team will stage needed changes in '5.6.0' from now on. We will check approved changes automatically so no need for any special actions from you; just take care that your changes will be approved. > > And please remember: We will take in only really important changes so please don't add any nice-to-haves in '5.6.0' anymore! If we can live with issue in Qt 5.6.0 then please use '5.6' instead. > > And as usual please send re-targeting request to Ossi if there is some change open in '5.6' and which must be in Qt 5.6.0 > > br, > Jani > > ________________________________________ > Lähettäjä: Heikkinen Jani > Lähetetty: 25. tammikuuta 2016 13:39 > Vastaanottaja: development at qt-project.org > Kopio: releasing at qt-project.org > Aihe: HEADS UP: Qt 5.6.0 branching ongoing > > ‘5.6.0’ branch is now available, please start using it for the changes targeted to Qt5.6.0 release. > > We will merge ‘5.6’ branch to ‘5.6.0’ Monday 1st February so there should be enough time to finalize ongoing changes in ‘5.6’ and start using '5.6.0'. All new changes for Qt5.6.0 should be done in ‘5.6.0’ branch from now on. > > Target is to release Qt5.6.0 RC quite soon so please make sure all blockers will be fixed as soon as possible. Blocker list here: https://bugreports.qt.io/issues/?filter=17225 > Please make sure all Qt 5.6.0 blockers are found from blocker list (== set 5.6.0 RC as fix version(s)): We should fix all blockers before RC & minimize changes between RC and final. > > And please remember: Do not add any 'nice to have' -changes in anymore (P0 & P1 bug fixes mostly, in some special cases p2 fixes might be ok as well). > > Best regards, > Jani Heikkinen > Release Manager | The Qt Company > > The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland > Email: jani.heikkinen at theqtcompany.com | Mobile: + 358 50 48 73 735 > www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject Facebook: www.facebook.com/qt > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From cavendish.qi at gmail.com Tue Feb 2 16:20:12 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Tue, 2 Feb 2016 16:20:12 +0100 Subject: [Development] A simple analysis of apps using qtbase's private headers In-Reply-To: <1642473.UpOgiBYOUB@luna> References: <1642473.UpOgiBYOUB@luna> Message-ID: On 22 January 2016 at 04:15, Lisandro Damián Nicanor Pérez < perezmeyer at gmail.com> wrote: > The following three have something in common: they are all apps coded for > Chinese people. I've been told that they need QPA's private stuff in order > to > have proper input systems, but I haven't checked. > > * fcitx-qt5 1.0.5 > * gcin 2.8.4 > * hime 0.9.10 > Above three are not applications, they must be input context plugin of Qt, just like ibus in https://github.com/qtproject/qtbase/tree/5.5/src/plugins/platforminputcontexts/ibus . Normally every input method software could/should have one of this kind of plugin for Qt 5, so there is no question when they use private headers. Regards, Liang -- http://www.qiliang.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From nospam at vuorela.dk Tue Feb 2 19:34:16 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Tue, 2 Feb 2016 18:34:16 +0000 (UTC) Subject: [Development] A simple analysis of apps using qtbase's private headers References: <1642473.UpOgiBYOUB@luna> Message-ID: On 2016-02-02, Liang Qi wrote: > Above three are not applications, they must be input context plugin of Qt, > just like ibus in > https://github.com/qtproject/qtbase/tree/5.5/src/plugins/platforminputconte= > xts/ibus > . Normally every input method software could/should have one of this kind > of plugin for Qt 5, so there is no question when they use private headers. There is two ways to fix the usage of private headers in external things. 1) is to stop using them 2) is to promote more private api to public api. I do think that one should consider it for the bits needed to make input methods. Really. Public private api is bad. It should really not exist. It harms our "We promise source and binary compatibility" promises, because it is full of 'except ...' . We should head towards not have any public private api. /Sune From jani.heikkinen at theqtcompany.com Wed Feb 3 09:19:43 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Wed, 3 Feb 2016 08:19:43 +0000 Subject: [Development] HEADS UP: Qt 5.6.0 branching ongoing In-Reply-To: References: Message-ID: Hi, Sorry that I missed your question. We haven't created exact criteria for the blocker and I think we cannot even do it. But basic rule is that all bad regressions from previous release are blockers as well as critical bugs in new features (which are preventing users to use new feature). All P1 issues aren't a blocker but on the other hand we can see some p2 to be a blocker (but you can argue if priority is correct in those cases). New release shouldn't be worse that previous one. Everyone can propose error to be a blocker and I + module maintainer will make the decision if that is the case or not. And of course we will accept some errors easier in the blocker list if there is long time for the release and when release is nearing we will be tighter all the time. And you must remember that even if critical/important error isn't in the blocker list is should be fixed. But we won't delay the release because of that kind of issues. What comes to that one error: for me it seems it isn't a blocker; it has been there already in 5.5.1 but it would be really good to get it fixed Br, jani >>-----Original Message----- >>From: mark diener [mailto:rpzrpzrpz at gmail.com] >>Sent: 2. helmikuuta 2016 16:37 >>To: Heikkinen Jani >>Cc: development at qt-project.org >>Subject: Re: [Development] HEADS UP: Qt 5.6.0 branching ongoing >> >>Jani: >> >>I submitted a message a week ago about the blocker list criterion and >>could not find a QT FAQ on what are the critierion. >> >>For example: https://bugreports.qt.io/browse/QTBUG-50374 is NOT a >>blocker for 5.6.0 RC. >> >>It is P2: Important. >> >>Likely I am missing something about how the blocker list is >>constructed and interpreted. >> >>But should 5.6.0 release with QTBUG-50374 still present, Qt is >>effectively saying, we have cut back support for IOS. >> >>And that would be big news. >> >>Please educate me. >> >>md >> >>On Tue, Feb 2, 2016 at 6:51 AM, Heikkinen Jani >> wrote: >>> Hi, >>> >>> Final downmerge is now done and branching is complete. From now on '5.6' is >>for Qt 5.6.1 and '5.6.0' for Qt 5.6.0. Staging in '5.6.0' is restricted and we in the >>release team will stage needed changes in '5.6.0' from now on. We will check >>approved changes automatically so no need for any special actions from you; >>just take care that your changes will be approved. >>> >>> And please remember: We will take in only really important changes so please >>don't add any nice-to-haves in '5.6.0' anymore! If we can live with issue in Qt >>5.6.0 then please use '5.6' instead. >>> >>> And as usual please send re-targeting request to Ossi if there is some change >>open in '5.6' and which must be in Qt 5.6.0 >>> >>> br, >>> Jani >>> >>> ________________________________________ >>> Lähettäjä: Heikkinen Jani >>> Lähetetty: 25. tammikuuta 2016 13:39 >>> Vastaanottaja: development at qt-project.org >>> Kopio: releasing at qt-project.org >>> Aihe: HEADS UP: Qt 5.6.0 branching ongoing >>> >>> ‘5.6.0’ branch is now available, please start using it for the changes targeted >>to Qt5.6.0 release. >>> >>> We will merge ‘5.6’ branch to ‘5.6.0’ Monday 1st February so there should be >>enough time to finalize ongoing changes in ‘5.6’ and start using '5.6.0'. All new >>changes for Qt5.6.0 should be done in ‘5.6.0’ branch from now on. >>> >>> Target is to release Qt5.6.0 RC quite soon so please make sure all blockers will >>be fixed as soon as possible. Blocker list here: >>https://bugreports.qt.io/issues/?filter=17225 >>> Please make sure all Qt 5.6.0 blockers are found from blocker list (== set 5.6.0 >>RC as fix version(s)): We should fix all blockers before RC & minimize changes >>between RC and final. >>> >>> And please remember: Do not add any 'nice to have' -changes in anymore (P0 >>& P1 bug fixes mostly, in some special cases p2 fixes might be ok as well). >>> >>> Best regards, >>> Jani Heikkinen >>> Release Manager | The Qt Company >>> >>> The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland >>> Email: jani.heikkinen at theqtcompany.com | Mobile: + 358 50 48 73 735 >>> www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, >>@Qtproject Facebook: www.facebook.com/qt >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development From Eskil.Abrahamsen-Blomfeldt at theqtcompany.com Wed Feb 3 10:49:47 2016 From: Eskil.Abrahamsen-Blomfeldt at theqtcompany.com (Abrahamsen-Blomfeldt Eskil) Date: Wed, 3 Feb 2016 09:49:47 +0000 Subject: [Development] HEADS UP: Qt 5.6.0 branching ongoing In-Reply-To: References: , Message-ID: Hi, As Jani explained in another mail, the fact that something does not block a release does not mean it's considered unimportant. We want to be as close as possible to a time-based release schedule, which means that if a new release does not regress and is an improvement to most users, it's better to get it out than to delay for everyone in order to get a bug fix in. As for priorities: P0 is for bugs that prevent further development of Qt and that need to be fixed right away. P1 is for crashes, regressions, security issues, memory corruption, bad drawing bugs, some build issues, etc. The highest priority we have for issues that do not fall into these categories is P2, so I think that's the appropriate priority for the bug in question since it's an inconvenience that you cannot debug on the simulator using Qt Creator. If you disagree with the priority set, you can discuss it with the assignee in the comment field of the bug report and explain why you believe the bug is more critical. It happens that the bug triaging team or assignee has underestimated a bug, so it's important to get input from the people affected by it. It's also possible to vote for bugs. That will usually be taken into account when people prioritize what they work on, since it's an indication of the number of users affected by the bug. -- Eskil ________________________________________ From: Development on behalf of mark diener Sent: Tuesday, February 2, 2016 3:37 PM To: Heikkinen Jani Cc: development at qt-project.org Subject: Re: [Development] HEADS UP: Qt 5.6.0 branching ongoing Jani: I submitted a message a week ago about the blocker list criterion and could not find a QT FAQ on what are the critierion. For example: https://bugreports.qt.io/browse/QTBUG-50374 is NOT a blocker for 5.6.0 RC. It is P2: Important. Likely I am missing something about how the blocker list is constructed and interpreted. But should 5.6.0 release with QTBUG-50374 still present, Qt is effectively saying, we have cut back support for IOS. And that would be big news. Please educate me. md On Tue, Feb 2, 2016 at 6:51 AM, Heikkinen Jani wrote: > Hi, > > Final downmerge is now done and branching is complete. From now on '5.6' is for Qt 5.6.1 and '5.6.0' for Qt 5.6.0. Staging in '5.6.0' is restricted and we in the release team will stage needed changes in '5.6.0' from now on. We will check approved changes automatically so no need for any special actions from you; just take care that your changes will be approved. > > And please remember: We will take in only really important changes so please don't add any nice-to-haves in '5.6.0' anymore! If we can live with issue in Qt 5.6.0 then please use '5.6' instead. > > And as usual please send re-targeting request to Ossi if there is some change open in '5.6' and which must be in Qt 5.6.0 > > br, > Jani > > ________________________________________ > Lähettäjä: Heikkinen Jani > Lähetetty: 25. tammikuuta 2016 13:39 > Vastaanottaja: development at qt-project.org > Kopio: releasing at qt-project.org > Aihe: HEADS UP: Qt 5.6.0 branching ongoing > > ‘5.6.0’ branch is now available, please start using it for the changes targeted to Qt5.6.0 release. > > We will merge ‘5.6’ branch to ‘5.6.0’ Monday 1st February so there should be enough time to finalize ongoing changes in ‘5.6’ and start using '5.6.0'. All new changes for Qt5.6.0 should be done in ‘5.6.0’ branch from now on. > > Target is to release Qt5.6.0 RC quite soon so please make sure all blockers will be fixed as soon as possible. Blocker list here: https://bugreports.qt.io/issues/?filter=17225 > Please make sure all Qt 5.6.0 blockers are found from blocker list (== set 5.6.0 RC as fix version(s)): We should fix all blockers before RC & minimize changes between RC and final. > > And please remember: Do not add any 'nice to have' -changes in anymore (P0 & P1 bug fixes mostly, in some special cases p2 fixes might be ok as well). > > Best regards, > Jani Heikkinen > Release Manager | The Qt Company > > The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland > Email: jani.heikkinen at theqtcompany.com | Mobile: + 358 50 48 73 735 > www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject Facebook: www.facebook.com/qt > > _______________________________________________ > 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 boris at codesynthesis.com Wed Feb 3 15:51:14 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed, 3 Feb 2016 16:51:14 +0200 Subject: [Development] [ANN] build2 - C++ build toolchain Message-ID: Hi, build2 is an open source, cross-platform toolchain for building and packaging C++ code. It includes a build system, package manager, and repository web interface. We've also started cppget.org, a public repository of open source C++ packages (where we hope to see Qt one day). This is the first alpha release and currently it is more of a technology preview rather than anything that is ready for production. We have tested this version on various Linux'es, Mac OS, and FreeBSD. There is no Windows support yet (but cross-compilation is supported). The project's page is: https://build2.org For those who need to see examples right away, here is the introduction: https://build2.org/build2-toolchain/doc/build2-toolchain-intro.xhtml Enjoy, Boris From ekke at ekkes-corner.org Fri Feb 5 13:27:02 2016 From: ekke at ekkes-corner.org (ekke) Date: Fri, 5 Feb 2016 13:27:02 +0100 Subject: [Development] Qt.labs controls problem Message-ID: <56B49516.2060502@ekkes-corner.org> Hi, just started Qt development and installed Qt 5.6 beta for Android and iOS All went well and I'm able to deploy sample apps to my (Android) BlackBerry PRIV :) The slider also works well: switching between virtual and hardware keyboard works as expected Most samples are looking ugly because of High DPI - but that's the reason why I waited for Qt 5.6 Beta to start Qt development for mobile ;-) I want to use High DPI support, the labs controls and Material Design. As a first step I followed the instructions here: https://doc-snapshots.qt.io/qt5-5.6/qtlabscontrols-gettingstarted.html and copied the content to main.cpp and main.qml unfortunately it fails: |W/libtest_q2_controls.so(15994): (null):0 ((null)): QQmlApplicationEngine failed to load component W/libtest_q2_controls.so(15994): (null):0 ((null)): file:///data/data/org.qtproject.example.test_q2_controls/files/main.qml:-1 File not found | also in design mode Qt.quick 2.6 isn't available am I missing anything ? thanks for any hints. (see also my entry in forum: https://forum.qt.io/topic/63824/unsupported-qt-quick-version-main-qml-not-found ) -- ekke (ekkehard gentz) independent software architect international development mobile apps for BlackBerry 10 workshops - trainings - bootcamps *BlackBerry Elite Developer BlackBerry Platinum Enterprise Partner* max-josefs-platz 30, D-83022 rosenheim, germany mailto:ekke at ekkes-corner.org blog: http://ekkes-corner.org apps and more: http://appbus.org twitter: @ekkescorner skype: ekkes-corner LinkedIn: http://linkedin.com/in/ekkehard/ Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekke at ekkes-corner.org Fri Feb 5 13:36:40 2016 From: ekke at ekkes-corner.org (ekke) Date: Fri, 5 Feb 2016 13:36:40 +0100 Subject: [Development] Qt.labs controls problem In-Reply-To: <56B49516.2060502@ekkes-corner.org> References: <56B49516.2060502@ekkes-corner.org> Message-ID: <56B49758.1040605@ekkes-corner.org> just got the answer in forum. had to change the path to main.qml: |QQmlApplicationEngine engine; engine.load(QUrl(QStringLiteral("qrc:/main.qml")));| now it works and I can go on :) ekke Am 05.02.16 um 13:27 schrieb ekke: > Hi, > > just started Qt development and installed Qt 5.6 beta for Android and iOS > All went well and I'm able to deploy sample apps to my (Android) > BlackBerry PRIV :) > > The slider also works well: switching between virtual and hardware > keyboard works as expected > > Most samples are looking ugly because of High DPI - but that's the > reason why I waited for Qt 5.6 Beta to start Qt development for mobile ;-) > I want to use High DPI support, the labs controls and Material Design. > > As a first step I followed the instructions here: > https://doc-snapshots.qt.io/qt5-5.6/qtlabscontrols-gettingstarted.html > and copied the content to main.cpp and main.qml > > unfortunately it fails: > |W/libtest_q2_controls.so(15994): (null):0 ((null)): > QQmlApplicationEngine failed to load component > W/libtest_q2_controls.so(15994): (null):0 ((null)): > file:///data/data/org.qtproject.example.test_q2_controls/files/main.qml:-1 > File not found | > also in design mode Qt.quick 2.6 isn't available > > am I missing anything ? > > thanks for any hints. > > (see also my entry in forum: > https://forum.qt.io/topic/63824/unsupported-qt-quick-version-main-qml-not-found > ) > -- > > ekke (ekkehard gentz) > > independent software architect > international development mobile apps for BlackBerry 10 > workshops - trainings - bootcamps > > *BlackBerry Elite Developer > BlackBerry Platinum Enterprise Partner* > > max-josefs-platz 30, D-83022 rosenheim, germany > mailto:ekke at ekkes-corner.org > blog: http://ekkes-corner.org > apps and more: http://appbus.org > > twitter: @ekkescorner > skype: ekkes-corner > LinkedIn: http://linkedin.com/in/ekkehard/ > Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490 > > > > _______________________________________________ > 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 andrewponomarenko at yandex.ru Fri Feb 5 14:34:19 2016 From: andrewponomarenko at yandex.ru (Ponomarenko Andrey) Date: Fri, 05 Feb 2016 16:34:19 +0300 Subject: [Development] API/ABI changes report Message-ID: <2945201454679259@web22o.yandex.ru> Hello, I've started to maintain API/ABI changes report for the Qt library here: http://abi-laboratory.pro/tracker/timeline/qt/ It took about two weeks to build and perform analysis for ~50 versions of the library from 4.0 up to 5.6.0-beta and finally I can share the report with the community. Hope the report will help Linux maintainers of the library to be aware of ABI structure changes and added/removed binary symbols. I understand that the report contains several false positives and definitely some false negatives. Also it says nothing about behavioral ABI changes. But it still can be used as a first approximation. Please let me know if some information in the report is incorrect/missed or you see some obvious false positives/negatives. I'll try to improve basic analysis tools. Thank you. From dmitry.volosnykh at gmail.com Fri Feb 5 14:54:02 2016 From: dmitry.volosnykh at gmail.com (Dmitry Volosnykh) Date: Fri, 05 Feb 2016 13:54:02 +0000 Subject: [Development] API/ABI changes report In-Reply-To: <2945201454679259@web22o.yandex.ru> References: <2945201454679259@web22o.yandex.ru> Message-ID: Excelent job, Andrey! On Fri, Feb 5, 2016 at 4:34 PM Ponomarenko Andrey < andrewponomarenko at yandex.ru> wrote: > Hello, > > I've started to maintain API/ABI changes report for the Qt library here: > http://abi-laboratory.pro/tracker/timeline/qt/ > > It took about two weeks to build and perform analysis for ~50 versions of > the library from 4.0 up to 5.6.0-beta and finally I can share the report > with the community. Hope the report will help Linux maintainers of the > library to be aware of ABI structure changes and added/removed binary > symbols. > > I understand that the report contains several false positives and > definitely some false negatives. Also it says nothing about behavioral ABI > changes. But it still can be used as a first approximation. > > Please let me know if some information in the report is incorrect/missed > or you see some obvious false positives/negatives. I'll try to improve > basic analysis tools. > > Thank you. > _______________________________________________ > 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 Fri Feb 5 17:58:15 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 05 Feb 2016 08:58:15 -0800 Subject: [Development] API/ABI changes report In-Reply-To: <2945201454679259@web22o.yandex.ru> References: <2945201454679259@web22o.yandex.ru> Message-ID: <2274263.zrLsn6XqlA@tjmaciei-mobl4> On sexta-feira, 5 de fevereiro de 2016 16:34:19 PST Ponomarenko Andrey wrote: > Hello, > > I've started to maintain API/ABI changes report for the Qt library here: > http://abi-laboratory.pro/tracker/timeline/qt/ Hello Andrey Thank you for the service. Looking at the only release we have any control over right now: 5.6. * Qt3D: major changes, definitely not binary compatible. Was the release in 5.5 properly marked as "technical preview, no ABI promise"? * QtCore: false positive, sendEvent() is still there. * QtGui: - QPixmapCache::allPixmaps(): innocent, was not public API, but you could get to it. - qt_sendShortcutOverrideEvent: affects QtTest binary compatibility - qt_handleMouseEvent: ditto - QWindowSystemInterface: binary incompatible (class is \ingroup qpa, but not in a _qpa.h header, therefore it's public API) => is anyone reading the header diff for QtGui? * QtNetwork: false positive * QtQuick: - DesignerSupport: previously exported, undocumented class that wasn't in a _p.h header and did not even have a Q prefix. We can safely assume this was a major mistake in releasing and is now corrected. - events & accessibility: false positive * QtWaylandClient: - events: false positive - qt_extended_output: was public and should not have been removed. The same change also changed values of enums in other public classes (like QWaylandCompositor). => is anyone reading the header diff for QtWaylandClient? * QtWidgets: - accessibility: false positive -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sean.harmer at kdab.com Fri Feb 5 18:09:17 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 05 Feb 2016 17:09:17 +0000 Subject: [Development] API/ABI changes report In-Reply-To: <2274263.zrLsn6XqlA@tjmaciei-mobl4> References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> Message-ID: <1825950.BmjBhSzXfk@cartman> On Friday 05 Feb 2016 08:58:15 Thiago Macieira wrote: > On sexta-feira, 5 de fevereiro de 2016 16:34:19 PST Ponomarenko Andrey wrote: > > Hello, > > > > I've started to maintain API/ABI changes report for the Qt library here: > > http://abi-laboratory.pro/tracker/timeline/qt/ > > Hello Andrey > > Thank you for the service. > > Looking at the only release we have any control over right now: 5.6. > > * Qt3D: major changes, definitely not binary compatible. Was the release in > 5.5 properly marked as "technical preview, no ABI promise"? Yes. Still a a tech preview in 5.6 too so can be safely ignored for now. Sean > > * QtCore: false positive, sendEvent() is still there. > > * QtGui: > - QPixmapCache::allPixmaps(): innocent, was not public API, but you could > get to it. > - qt_sendShortcutOverrideEvent: affects QtTest binary compatibility > - qt_handleMouseEvent: ditto > - QWindowSystemInterface: binary incompatible (class is \ingroup qpa, but > not in a _qpa.h header, therefore it's public API) > > => is anyone reading the header diff for QtGui? > > * QtNetwork: false positive > > * QtQuick: > - DesignerSupport: previously exported, undocumented class that wasn't in a > _p.h header and did not even have a Q prefix. We can safely assume this was > a major mistake in releasing and is now corrected. > - events & accessibility: false positive > > * QtWaylandClient: > - events: false positive > - qt_extended_output: was public and should not have been removed. The same > change also changed values of enums in other public classes > (like QWaylandCompositor). > > => is anyone reading the header diff for QtWaylandClient? > > * QtWidgets: > - accessibility: false positive -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From robin+qt at viroteck.net Fri Feb 5 18:45:21 2016 From: robin+qt at viroteck.net (Robin Burchell) Date: Fri, 05 Feb 2016 18:45:21 +0100 Subject: [Development] API/ABI changes report In-Reply-To: <2274263.zrLsn6XqlA@tjmaciei-mobl4> References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> Message-ID: <1454694321.1586689.513145330.5E2964D4@webmail.messagingengine.com> On Fri, Feb 5, 2016, at 05:58 PM, Thiago Macieira wrote: > - QWindowSystemInterface: binary incompatible (class is \ingroup qpa, > but not > in a _qpa.h header, therefore it's public API) I don't agree with this. None of the QPA files have a _qpa.h extension (and haven't since 2012 -- see qtbase/037238022f3a91a5619709b2c7cf4b38cd4d294b), all of them clearly carry a warning "header", and all of them are put in include/qpa/ (see sync.profile), so they are not public. > * QtWaylandClient: > - events: false positive > - qt_extended_output: was public and should not have been removed. The > same > change also changed values of enums in other public classes > (like QWaylandCompositor). QtWaylandClient is not a public module. It's the platform plugin for Wayland. There isn't yet any API that is public (and not preview-level) in QtWayland. From porten at froglogic.com Fri Feb 5 21:07:29 2016 From: porten at froglogic.com (Harri Porten) Date: Fri, 5 Feb 2016 21:07:29 +0100 (CET) Subject: [Development] API/ABI changes report In-Reply-To: <2274263.zrLsn6XqlA@tjmaciei-mobl4> References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> Message-ID: On Fri, 5 Feb 2016, Thiago Macieira wrote: > * QtGui: > - QPixmapCache::allPixmaps(): innocent, was not public API, but you could get > to it. > - qt_sendShortcutOverrideEvent: affects QtTest binary compatibility Our product (and its users) were bitten by this as well. As the function wasn't documented we took the blame on us. Renamings of quasi-public functions are something that can be avoided however :) Thanks to Andrey from me as well, Harri. From thiago.macieira at intel.com Fri Feb 5 22:42:34 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 05 Feb 2016 13:42:34 -0800 Subject: [Development] API/ABI changes report In-Reply-To: References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> Message-ID: <12643672.8Qc2TuIcpj@tjmaciei-mobl4> On sexta-feira, 5 de fevereiro de 2016 21:07:29 PST Harri Porten wrote: > On Fri, 5 Feb 2016, Thiago Macieira wrote: > > * QtGui: > > - QPixmapCache::allPixmaps(): innocent, was not public API, but you could > > get> > > to it. > > > > - qt_sendShortcutOverrideEvent: affects QtTest binary compatibility > > Our product (and its users) were bitten by this as well. As the function > wasn't documented we took the blame on us. Renamings of quasi-public > functions are something that can be avoided however :) > > Thanks to Andrey from me as well, QtTest is special case library, for which binary compatibility isn't always guaranteed. I personally think that we should guarantee it as much as we can, since it allows us to run tests compiled with one Qt against another, to check for regressions. I did that VERY often in my days at Trolltech. In this case, the symbol isn't in QtTest, but in QtGui. It's technically a private symbol, but it was used from inline functions from QtTest. Therefore I would really prefer for the symbol to be brought back. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Feb 5 22:47:54 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 05 Feb 2016 13:47:54 -0800 Subject: [Development] API/ABI changes report In-Reply-To: <2274263.zrLsn6XqlA@tjmaciei-mobl4> References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> Message-ID: <1780946.VELqlXRGuA@tjmaciei-mobl4> On sexta-feira, 5 de fevereiro de 2016 08:58:15 PST Thiago Macieira wrote: > - QWindowSystemInterface: binary incompatible (class is \ingroup qpa, but > not in a _qpa.h header, therefore it's public API) > > => is anyone reading the header diff for QtGui? This happened *after* the header diff. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andrewponomarenko at yandex.ru Sat Feb 6 13:11:14 2016 From: andrewponomarenko at yandex.ru (Ponomarenko Andrey) Date: Sat, 06 Feb 2016 15:11:14 +0300 Subject: [Development] API/ABI changes report In-Reply-To: <2274263.zrLsn6XqlA@tjmaciei-mobl4> References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> Message-ID: <6456351454760674@web15m.yandex.ru> 05.02.2016, 19:58, "Thiago Macieira" : > On sexta-feira, 5 de fevereiro de 2016 16:34:19 PST Ponomarenko Andrey wrote: >>  Hello, >> >>  I've started to maintain API/ABI changes report for the Qt library here: >>  http://abi-laboratory.pro/tracker/timeline/qt/ > > Hello Andrey > > Thank you for the service. > > Looking at the only release we have any control over right now: 5.6. > > * Qt3D: major changes, definitely not binary compatible. Was the release in 5.5 > properly marked as "technical preview, no ABI promise"? > > * QtCore: false positive, sendEvent() is still there. > > * QtGui: >  - QPixmapCache::allPixmaps(): innocent, was not public API, but you could get >    to it. >  - qt_sendShortcutOverrideEvent: affects QtTest binary compatibility >  - qt_handleMouseEvent: ditto >  - QWindowSystemInterface: binary incompatible (class is \ingroup qpa, but not >    in a _qpa.h header, therefore it's public API) > >         => is anyone reading the header diff for QtGui? > > * QtNetwork: false positive > > * QtQuick: >  - DesignerSupport: previously exported, undocumented class that wasn't in a >    _p.h header and did not even have a Q prefix. We can safely assume this was >    a major mistake in releasing and is now corrected. >  - events & accessibility: false positive > > * QtWaylandClient: >  - events: false positive >  - qt_extended_output: was public and should not have been removed. The same >    change also changed values of enums in other public classes >    (like QWaylandCompositor). > >         => is anyone reading the header diff for QtWaylandClient? > > * QtWidgets: >  - accessibility: false positive > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > Hello Thiago, Thank you for the detailed review. This helps me a lot to improve the report and open-source tools used (https://github.com/lvc). From jani.heikkinen at theqtcompany.com Mon Feb 8 13:55:42 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Mon, 8 Feb 2016 12:55:42 +0000 Subject: [Development] Qt 5.7 new features: MAINTAINERS, your input needed! Message-ID: Hi all, Feature Freeze has been in effect a week but new features page(https://wiki.qt.io/New_Features_in_Qt_5.7) needs still some updates. Maintainers: please add missing items there as soon as possible, it would be really good to have this "ready" before Alpha release br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederik.gladhorn at theqtcompany.com Mon Feb 8 14:03:26 2016 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Mon, 8 Feb 2016 14:03:26 +0100 Subject: [Development] Closing the 5.5 branch Message-ID: <2672846.XtEjAFYt09@frederik-thinkcentre-m93p> Hi all, due to the strain that we put on the VMs that are supposed to get the releases out and do the testing, we decided to "shut down" the CI for Qt 5.5 branches. This means literally that we shut down the VMs but we'll keep them around in case we ever need to make a 5.5 release. The goal is to free capacity to let us finally get 5.6 and just after 5.7 out of the door. Cheers, Frederik From tor.arne.vestbo at theqtcompany.com Mon Feb 8 14:58:24 2016 From: tor.arne.vestbo at theqtcompany.com (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Mon, 8 Feb 2016 14:58:24 +0100 Subject: [Development] API/ABI changes report In-Reply-To: <12643672.8Qc2TuIcpj@tjmaciei-mobl4> References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> <12643672.8Qc2TuIcpj@tjmaciei-mobl4> Message-ID: <56B89F00.8050708@theqtcompany.com> This was fixed already in https://codereview.qt-project.org/#/c/147988/ tor arne On 05/02/16 22:42, Thiago Macieira wrote: > On sexta-feira, 5 de fevereiro de 2016 21:07:29 PST Harri Porten wrote: >> On Fri, 5 Feb 2016, Thiago Macieira wrote: >>> * QtGui: >>> - QPixmapCache::allPixmaps(): innocent, was not public API, but you could >>> get> >>> to it. >>> >>> - qt_sendShortcutOverrideEvent: affects QtTest binary compatibility >> >> Our product (and its users) were bitten by this as well. As the function >> wasn't documented we took the blame on us. Renamings of quasi-public >> functions are something that can be avoided however :) >> >> Thanks to Andrey from me as well, > > QtTest is special case library, for which binary compatibility isn't always > guaranteed. I personally think that we should guarantee it as much as we can, > since it allows us to run tests compiled with one Qt against another, to check > for regressions. I did that VERY often in my days at Trolltech. > > In this case, the symbol isn't in QtTest, but in QtGui. It's technically a > private symbol, but it was used from inline functions from QtTest. > > Therefore I would really prefer for the symbol to be brought back. > From alexander.blasche at theqtcompany.com Mon Feb 8 15:18:54 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Mon, 8 Feb 2016 14:18:54 +0000 Subject: [Development] Approver status for Michal Klocek Message-ID: Hello, I would like to nominate Michal Klocek for Approver status in the Qt Project. Throughout the last year he has been working on QtLocation and QtWebEngine: https://codereview.qt-project.org/#/q/owner:michal.klocek,n,z -- Alex From jturcotte at woboq.com Mon Feb 8 15:25:22 2016 From: jturcotte at woboq.com (Jocelyn Turcotte) Date: Mon, 8 Feb 2016 15:25:22 +0100 Subject: [Development] Approver status for Michal Klocek In-Reply-To: References: Message-ID: <1B7D73F8-4F2B-4153-AB7F-B2AFBE82619A@woboq.com> +1 > On 08 Feb 2016, at 15:18, Blasche Alexander wrote: > > Hello, > > I would like to nominate Michal Klocek for Approver status in the Qt Project. Throughout the last year he has been working on QtLocation and QtWebEngine: > > https://codereview.qt-project.org/#/q/owner:michal.klocek,n,z > > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From michael.bruning at theqtcompany.com Mon Feb 8 15:26:18 2016 From: michael.bruning at theqtcompany.com (=?UTF-8?Q?Michael_Br=c3=bcning?=) Date: Mon, 8 Feb 2016 15:26:18 +0100 Subject: [Development] Approver status for Michal Klocek In-Reply-To: References: Message-ID: <56B8A58A.6060809@theqtcompany.com> +1 On 02/08/2016 03:18 PM, Blasche Alexander wrote: > Hello, > > I would like to nominate Michal Klocek for Approver status in the Qt Project. Throughout the last year he has been working on QtLocation and QtWebEngine: > > https://codereview.qt-project.org/#/q/owner:michal.klocek,n,z > > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From laszlo.agocs at theqtcompany.com Mon Feb 8 15:46:54 2016 From: laszlo.agocs at theqtcompany.com (Agocs Laszlo) Date: Mon, 8 Feb 2016 14:46:54 +0000 Subject: [Development] Approver status for Michal Klocek In-Reply-To: <56B8A58A.6060809@theqtcompany.com> References: , <56B8A58A.6060809@theqtcompany.com> Message-ID: +1. Good job on Qt Location! Laszlo ________________________________________ From: Development on behalf of Michael Brüning Sent: Monday, February 8, 2016 3:26 PM To: development at qt-project.org Subject: Re: [Development] Approver status for Michal Klocek +1 On 02/08/2016 03:18 PM, Blasche Alexander wrote: > Hello, > > I would like to nominate Michal Klocek for Approver status in the Qt Project. Throughout the last year he has been working on QtLocation and QtWebEngine: > > https://codereview.qt-project.org/#/q/owner:michal.klocek,n,z > > -- > Alex > _______________________________________________ > 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 krnekit at gmail.com Tue Feb 9 19:00:15 2016 From: krnekit at gmail.com (Nikita Krupenko) Date: Tue, 9 Feb 2016 20:00:15 +0200 Subject: [Development] Closing the 5.5 branch In-Reply-To: <2672846.XtEjAFYt09@frederik-thinkcentre-m93p> References: <2672846.XtEjAFYt09@frederik-thinkcentre-m93p> Message-ID: 2016-02-08 15:03 GMT+02:00 Frederik Gladhorn : > Hi all, > > due to the strain that we put on the VMs that are supposed to get the releases > out and do the testing, we decided to "shut down" the CI for Qt 5.5 branches. > This means literally that we shut down the VMs but we'll keep them around in > case we ever need to make a 5.5 release. > The goal is to free capacity to let us finally get 5.6 and just after 5.7 out > of the door. If I have change on 5.5 branch, that is waiting for review, should I ask to retarget it to 5.6? Or there will be one more merge 5.5 -> 5.6? From thiago.macieira at intel.com Wed Feb 10 00:15:24 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 09 Feb 2016 15:15:24 -0800 Subject: [Development] API/ABI changes report In-Reply-To: <2274263.zrLsn6XqlA@tjmaciei-mobl4> References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> Message-ID: <2171188.3zZrGkK9se@tjmaciei-mobl4> On sexta-feira, 5 de fevereiro de 2016 08:58:15 PST Thiago Macieira wrote: > * Qt3D: major changes, definitely not binary compatible. Was the release in > 5.5 properly marked as "technical preview, no ABI promise"? Someone familiar with Qt3D please confirm that Qt 5.5 was released with no ABI promise. > * QtGui: > - qt_sendShortcutOverrideEvent: affects QtTest binary compatibility > - qt_handleMouseEvent: ditto > - QWindowSystemInterface: binary incompatible (class is \ingroup qpa, but > not in a _qpa.h header, therefore it's public API) P1 task created: QTBUG-51015 > * QtWaylandClient: > - qt_extended_output: was public and should not have been removed. The same > change also changed values of enums in other public classes > (like QWaylandCompositor). > > => is anyone reading the header diff for QtWaylandClient? Upon further inspection, there's no issue here. The enum change was not in QtWaylandClient and the variable qt_extended_output was only declared in private headers. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From dangelog at gmail.com Wed Feb 10 00:25:31 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Wed, 10 Feb 2016 00:25:31 +0100 Subject: [Development] API/ABI changes report In-Reply-To: <2171188.3zZrGkK9se@tjmaciei-mobl4> References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> <2171188.3zZrGkK9se@tjmaciei-mobl4> Message-ID: On Wed, Feb 10, 2016 at 12:15 AM, Thiago Macieira wrote: > > Someone familiar with Qt3D please confirm that Qt 5.5 was released with no ABI > promise. In 5.5 and 5.6 Qt3D is a technical preview, and therefore with no API/ABI compatibility promises. Cheers, -- Giuseppe D'Angelo From thiago.macieira at intel.com Wed Feb 10 01:57:22 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 09 Feb 2016 16:57:22 -0800 Subject: [Development] API/ABI changes report In-Reply-To: <2171188.3zZrGkK9se@tjmaciei-mobl4> References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> <2171188.3zZrGkK9se@tjmaciei-mobl4> Message-ID: <11587643.Vxn3g4v6mZ@tjmaciei-mobl4> On terça-feira, 9 de fevereiro de 2016 15:15:24 PST Thiago Macieira wrote: > > * QtGui: > > - qt_sendShortcutOverrideEvent: affects QtTest binary compatibility > > - qt_handleMouseEvent: ditto > > - QWindowSystemInterface: binary incompatible (class is \ingroup qpa, but > > > > not in a _qpa.h header, therefore it's public API) > > P1 task created: QTBUG-51015 Thanks to Robin for notifying me that I hadn't received some emails on this thread. As you can see from my email above, I had no idea that the _qpa.h headers had been renamed. After looking into the problem, it seems indeed that qwindowsysteminterface.h is not a public header, so there's no BC issue. I've closed the task. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alexander.blasche at theqtcompany.com Wed Feb 10 07:38:41 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Wed, 10 Feb 2016 06:38:41 +0000 Subject: [Development] Closing the 5.5 branch In-Reply-To: References: <2672846.XtEjAFYt09@frederik-thinkcentre-m93p> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On Behalf > Of Nikita Krupenko > 2016-02-08 15:03 GMT+02:00 Frederik Gladhorn > : > > Hi all, > > > > due to the strain that we put on the VMs that are supposed to get the releases > > out and do the testing, we decided to "shut down" the CI for Qt 5.5 branches. > > This means literally that we shut down the VMs but we'll keep them around in > > case we ever need to make a 5.5 release. > > The goal is to free capacity to let us finally get 5.6 and just after 5.7 out > > of the door. > > If I have change on 5.5 branch, that is waiting for review, should I > ask to retarget it to 5.6? That's the correct course of action. > Or there will be one more merge 5.5 -> 5.6? This question is irrelevant since the branch is closed. Only already committed patched would be covered with merges and you cannot commit anything anymore. -- Alex From tor.arne.vestbo at theqtcompany.com Wed Feb 10 12:00:00 2016 From: tor.arne.vestbo at theqtcompany.com (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Wed, 10 Feb 2016 12:00:00 +0100 Subject: [Development] HEADS UP: OSX build requirements for 5.7 Message-ID: <56BB1830.30500@theqtcompany.com> Hey guys! To clear up some resources in our CI system we're moving to the following build process: - Build Qt on the latest OS X with the latest Xcode against the latest SDK available. - Test that build by running the auto-tests on each of the supported deployment targets, down to the minimum deployment target we support (which for the time being is 10.7). This means that we can save build time by not building Qt on those lower OS X versions, just running the tests there. It also means we can start removing SDK ifdefs in our code, since Qt should always be built against the latest available SDK. This is the approach recommended by Apple, and the one we've been applying to the iOS port in the past. Does anyone see any issues with this going forward? Tor Arne From coroberti at gmail.com Wed Feb 10 12:14:14 2016 From: coroberti at gmail.com (Robert Iakobashvili) Date: Wed, 10 Feb 2016 13:14:14 +0200 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: <56BB1830.30500@theqtcompany.com> References: <56BB1830.30500@theqtcompany.com> Message-ID: On Wed, Feb 10, 2016 at 1:00 PM, Tor Arne Vestbø wrote: > Hey guys! > > To clear up some resources in our CI system we're moving to the following > build process: > > - Build Qt on the latest OS X with the latest Xcode against the latest SDK > available. > - Test that build by running the auto-tests on each of the supported > deployment targets, down to the minimum deployment target we support (which > for the time being is 10.7). > > This means that we can save build time by not building Qt on those lower OS > X versions, just running the tests there. It also means we can start > removing SDK ifdefs in our code, since Qt should always be built against the > latest available SDK. > > This is the approach recommended by Apple, and the one we've been applying > to the iOS port in the past. > > Does anyone see any issues with this going forward? > > Tor Arne > _______________________________________________ Dear Tor Arne, Apple has a traditional October-November mess after releasing new versions with issues, bugs, patches that goes normally up to end-of year. So, it could be that practically makes sense to keep in autumn a previous version as well at least for a transition period of several months. Kind regards, Robert From tor.arne.vestbo at theqtcompany.com Wed Feb 10 12:36:25 2016 From: tor.arne.vestbo at theqtcompany.com (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Wed, 10 Feb 2016 12:36:25 +0100 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: References: <56BB1830.30500@theqtcompany.com> Message-ID: <56BB20B9.6060607@theqtcompany.com> On 10/02/16 12:14, Robert Iakobashvili wrote: > Apple has a traditional October-November mess after releasing > new versions with issues, bugs, patches that goes normally up to end-of year. > > So, it could be that practically makes sense to keep > in autumn a previous version as well at least for a transition period > of several months. You're talking about newly released OS X versions? Even if we delay the upgrade of OS X version on the build machine, the last two OS X versions usually support the latest available SDK, which we should always use. tor arne From thiago.macieira at intel.com Wed Feb 10 17:06:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Feb 2016 08:06:55 -0800 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: <56BB1830.30500@theqtcompany.com> References: <56BB1830.30500@theqtcompany.com> Message-ID: <1837015.2tL8bV86hx@tjmaciei-mobl4> On quarta-feira, 10 de fevereiro de 2016 12:00:00 PST Tor Arne Vestbø wrote: > Does anyone see any issues with this going forward? We need to be sure Qt compiles with the latest Xcode available on each of the OS X versions that Qt can be developed on. Since 10.8→10.11 updating is free, the only extra test is 10.7. The latest Xcode that can be installed on 10.7 is Xcode 5.1, so it's important we keep building with that. Note that we don't have to build *on* 10.7 to be sure that Xcode 5.1 works. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tor.arne.vestbo at theqtcompany.com Wed Feb 10 17:11:38 2016 From: tor.arne.vestbo at theqtcompany.com (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Wed, 10 Feb 2016 17:11:38 +0100 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: <1837015.2tL8bV86hx@tjmaciei-mobl4> References: <56BB1830.30500@theqtcompany.com> <1837015.2tL8bV86hx@tjmaciei-mobl4> Message-ID: <56BB613A.1020408@theqtcompany.com> On 10/02/16 17:06, Thiago Macieira wrote: > On quarta-feira, 10 de fevereiro de 2016 12:00:00 PST Tor Arne Vestbø wrote: >> Does anyone see any issues with this going forward? > > We need to be sure Qt compiles with the latest Xcode available on each of the > OS X versions that Qt can be developed on. Since 10.8→10.11 updating is free, > the only extra test is 10.7. The latest Xcode that can be installed on 10.7 > is Xcode 5.1, so it's important we keep building with that. > > Note that we don't have to build *on* 10.7 to be sure that Xcode 5.1 works. Then we should drop 10.7 as a supported development platform (not deployment platform), so that we can require the latest Xcode and latest SDK (available for 10.10 and 10.11). tor arne From thiago.macieira at intel.com Wed Feb 10 18:16:39 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Feb 2016 09:16:39 -0800 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: <56BB613A.1020408@theqtcompany.com> References: <56BB1830.30500@theqtcompany.com> <1837015.2tL8bV86hx@tjmaciei-mobl4> <56BB613A.1020408@theqtcompany.com> Message-ID: <4055726.JQV7M0uOjm@tjmaciei-mobl4> On quarta-feira, 10 de fevereiro de 2016 17:11:38 PST Tor Arne Vestbø wrote: > On 10/02/16 17:06, Thiago Macieira wrote: > > On quarta-feira, 10 de fevereiro de 2016 12:00:00 PST Tor Arne Vestbø wrote: > >> Does anyone see any issues with this going forward? > > > > We need to be sure Qt compiles with the latest Xcode available on each of > > the OS X versions that Qt can be developed on. Since 10.8→10.11 updating > > is free, the only extra test is 10.7. The latest Xcode that can be > > installed on 10.7 is Xcode 5.1, so it's important we keep building with > > that. > > > > Note that we don't have to build *on* 10.7 to be sure that Xcode 5.1 > > works. > > Then we should drop 10.7 as a supported development platform (not > deployment platform), so that we can require the latest Xcode and latest > SDK (available for 10.10 and 10.11). I'm ok with that, but it would have been nice to know before we worked around a series of issues with the compiler that comes with that Xcode... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at theqtcompany.com Wed Feb 10 18:36:11 2016 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Wed, 10 Feb 2016 17:36:11 +0000 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: <56BB613A.1020408@theqtcompany.com> References: <56BB1830.30500@theqtcompany.com> <1837015.2tL8bV86hx@tjmaciei-mobl4> <56BB613A.1020408@theqtcompany.com> Message-ID: <8FBD138E-A645-4A8A-96BF-C1E3F81E4328@theqtcompany.com> On Feb 10, 2016, at 8:11 AM, Tor Arne Vestbø > wrote: On 10/02/16 17:06, Thiago Macieira wrote: On quarta-feira, 10 de fevereiro de 2016 12:00:00 PST Tor Arne Vestbø wrote: Does anyone see any issues with this going forward? We need to be sure Qt compiles with the latest Xcode available on each of the OS X versions that Qt can be developed on. Since 10.8→10.11 updating is free, the only extra test is 10.7. The latest Xcode that can be installed on 10.7 is Xcode 5.1, so it's important we keep building with that. Pretty sure the App Store on my 10.7 VM prompts me to upgrade to 10.11 for free as well. I'm on the train without my VM SSD so I can't check right now. Note that we don't have to build *on* 10.7 to be sure that Xcode 5.1 works. Then we should drop 10.7 as a supported development platform (not deployment platform), so that we can require the latest Xcode and latest SDK (available for 10.10 and 10.11). tor arne _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at klingt.org Wed Feb 10 19:02:27 2016 From: tim at klingt.org (Tim Blechmann) Date: Thu, 11 Feb 2016 02:02:27 +0800 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: <1837015.2tL8bV86hx@tjmaciei-mobl4> References: <56BB1830.30500@theqtcompany.com> <1837015.2tL8bV86hx@tjmaciei-mobl4> Message-ID: >> Does anyone see any issues with this going forward? > > We need to be sure Qt compiles with the latest Xcode available on each of the > OS X versions that Qt can be developed on. Since 10.8→10.11 updating is free, > the only extra test is 10.7. we have seen funny toolchain bugs, with 10.10 sdk and 10.8 deployment target on 10.8, where std::exceptions could not be caught ... compiling against 10.8 sdk solved that issue. so an xcode/sdk update is not necessarily a no-brainer and there might be a benefit to still compile with different xcode versions against different sdks. otoh, ccache is an amazing way to reduce CI load :) cheers, tim From thiago.macieira at intel.com Wed Feb 10 19:27:04 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Feb 2016 10:27:04 -0800 Subject: [Development] Qt::CaseInsensitive comparison is not the same as toLower() comparison Message-ID: <4859225.ahGp9Rcj76@tjmaciei-mobl4> Hi all (especially Konstantin!) When reviewing a change, I noticed that QString::startsWith with CaseInsensitive compares things like this: if (foldCase(data[i]) != foldCase((ushort)latin[i])) return false; with foldCase() being convertCase_helper(ch), whereas toLower() uses QUnicodeTables::LowercaseTraits. There's a slight but important difference in a few character pairs see below. The code has been like that since forever. So I have to ask: => Is this intended? If you write code like: qDebug() << a.startsWith(b, Qt::CaseInsensitive) << (a.toLower() == b.toLower()); You'll get a different result for the following pairs (for example, see util/ unicode/data/CaseFolding.txt for more): µ U+00B5 MICRO SIGN μ U+03BC GREEK SMALL LETTER MU s U+0073 LATIN SMALL LETTER S ſ U+017F LATIN SMALL LETTER LONG S And then there are the differences between toUpper and toLower. The following pairs compare false with toLower(), compare true with toUpper(), currently compare false with CaseInsensitive/toCaseFolded() but *should* compare true[1]: ß U+00DF LATIN SMALL LETTER SHARP S ẞ U+1E9E LATIN CAPITAL LETTER SHARP S SS ʼn U+0149 LATIN SMALL LETTER N PRECEDED BY APOSTROPHE ʼN ff U+FB00 LATIN SMALL LIGATURE FF FF [1] CaseFolding.txt says: # The data supports both implementations that require simple case foldings # (where string lengths don't change), and implementations that allow full case folding # (where string lengths may grow). Note that where they can be supported, the # full case foldings are superior: for example, they allow "MASSE" and "Maße" to match. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Feb 10 19:31:43 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Feb 2016 10:31:43 -0800 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: References: <56BB1830.30500@theqtcompany.com> <1837015.2tL8bV86hx@tjmaciei-mobl4> Message-ID: <4659079.st41LRaXTV@tjmaciei-mobl4> On quinta-feira, 11 de fevereiro de 2016 02:02:27 PST Tim Blechmann wrote: > we have seen funny toolchain bugs, with 10.10 sdk and 10.8 deployment > target on 10.8, where std::exceptions could not be caught ... compiling > against 10.8 sdk solved that issue. Regardless of whether that is a valid approach or not, the fact that people are doing that poses a problem for us. If we write code against the latest toolchain, it may not compile against older ones people might be using. That can be because we used new features that aren't present in older ones, even if properly runtime checked. Another problem is that the compilers in the old toolchains are older, with older libc++ and with bugs that we aren't testing for. If we're going to upgrade our Xcode in all our builds, I would advise we also make it mandatory for everyone else too. Check during configure against the minimum SDK version, that being the *current* at the time of release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tim at klingt.org Wed Feb 10 20:04:52 2016 From: tim at klingt.org (Tim Blechmann) Date: Thu, 11 Feb 2016 03:04:52 +0800 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: <4659079.st41LRaXTV@tjmaciei-mobl4> References: <56BB1830.30500@theqtcompany.com> <1837015.2tL8bV86hx@tjmaciei-mobl4> <4659079.st41LRaXTV@tjmaciei-mobl4> Message-ID: >> we have seen funny toolchain bugs, with 10.10 sdk and 10.8 deployment >> target on 10.8, where std::exceptions could not be caught ... compiling >> against 10.8 sdk solved that issue. > > Regardless of whether that is a valid approach or not, the fact that people > are doing that poses a problem for us. If we write code against the latest > toolchain, it may not compile against older ones people might be using. this implies bumping the minimum requirements. for some use cases this might be acceptable, for others it isn't. > That can be because we used new features that aren't present in older ones, > even if properly runtime checked. > > Another problem is that the compilers in the old toolchains are older, with > older libc++ and with bugs that we aren't testing for. ... or newer toolchains can introduce regressions ... > If we're going to upgrade our Xcode in all our builds, I would advise we also > make it mandatory for everyone else too. Check during configure against the > minimum SDK version, that being the *current* at the time of release. so what happens when you are hit by a toolchain regression? i'm not voting for having code compiling with gcc-4.2 or any of the llvm-gcc flavors which were around during that time. however qt is a framework and it should support more than one toolchain so that people who are hit by toolchain bugs still have an alternative ... cheers, tim From annulen at yandex.ru Wed Feb 10 20:14:19 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 10 Feb 2016 22:14:19 +0300 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: References: <56BB1830.30500@theqtcompany.com> <1837015.2tL8bV86hx@tjmaciei-mobl4> <4659079.st41LRaXTV@tjmaciei-mobl4> Message-ID: <514701455131659@web14m.yandex.ru> 10.02.2016, 22:05, "Tim Blechmann" : >>>   we have seen funny toolchain bugs, with 10.10 sdk and 10.8 deployment >>>   target on 10.8, where std::exceptions could not be caught ... compiling >>>   against 10.8 sdk solved that issue. >> >>   Regardless of whether that is a valid approach or not, the fact that people >>   are doing that poses a problem for us. If we write code against the latest >>   toolchain, it may not compile against older ones people might be using. > >  this implies bumping the minimum requirements. for some use cases this >  might be acceptable, for others it isn't. > >>   That can be because we used new features that aren't present in older ones, >>   even if properly runtime checked. >> >>   Another problem is that the compilers in the old toolchains are older, with >>   older libc++ and with bugs that we aren't testing for. > >  ... or newer toolchains can introduce regressions ... > >>   If we're going to upgrade our Xcode in all our builds, I would advise we also >>   make it mandatory for everyone else too. Check during configure against the >>   minimum SDK version, that being the *current* at the time of release. > >  so what happens when you are hit by a toolchain regression? i'm not >  voting for having code compiling with gcc-4.2 or any of the llvm-gcc >  flavors which were around during that time. however qt is a framework >  and it should support more than one toolchain so that people who are hit >  by toolchain bugs still have an alternative ... I can imagine the next solution: additionally run CI using open source Clang, corresponding to minimum Xcode version you are going to support. -- Regards, Konstantin From Lars.Knoll at theqtcompany.com Wed Feb 10 20:46:49 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 10 Feb 2016 19:46:49 +0000 Subject: [Development] Qt::CaseInsensitive comparison is not the same as toLower() comparison In-Reply-To: <4859225.ahGp9Rcj76@tjmaciei-mobl4> References: <4859225.ahGp9Rcj76@tjmaciei-mobl4> Message-ID: <05D81450-9EF3-4972-A24B-9F14498DE658@theqtcompany.com> Hi Thiago, On 10/02/16 19:27, "Development on behalf of Thiago Macieira" wrote: >Hi all > >(especially Konstantin!) > >When reviewing a change, I noticed that QString::startsWith with >CaseInsensitive compares things like this: > > if (foldCase(data[i]) != foldCase((ushort)latin[i])) > return false; > >with foldCase() being convertCase_helper(ch), >whereas toLower() uses QUnicodeTables::LowercaseTraits. > >There's a slight but important difference in a few character pairs see below. >The code has been like that since forever. So I have to ask: > > => Is this intended? Yes, CaseInsensitive comparisons should compare case folded strings. And you're right, in some cases that is something else than comparing the lower cased versions of both strings. > >If you write code like: > > qDebug() << a.startsWith(b, Qt::CaseInsensitive) > << (a.toLower() == b.toLower()); > >You'll get a different result for the following pairs (for example, see util/ >unicode/data/CaseFolding.txt for more): > >µ U+00B5 MICRO SIGN >μ U+03BC GREEK SMALL LETTER MU > >s U+0073 LATIN SMALL LETTER S >ſ U+017F LATIN SMALL LETTER LONG S > >And then there are the differences between toUpper and toLower. The following >pairs compare false with toLower(), compare true with toUpper(), currently >compare false with CaseInsensitive/toCaseFolded() but *should* compare >true[1]: They should only compare true with full case folding rules. This is something we have so far not implemented in Qt; as you noted below we're still using simple case folding rules. This is actually somewhat similar to the case of comparing strings in different normalisation forms (composed vs decomposed), something we also don't do out of the box (ie. 'Ä' doesn't compare true with the combination of 'A' with the diacritical mark for umlaut. At some point it would probably be nice to implement support for comparing these correctly. This does however have a performance impact and many use cases might not want this comparison by default. Cheers, Lars > >ß U+00DF LATIN SMALL LETTER SHARP S >ẞ U+1E9E LATIN CAPITAL LETTER SHARP S >SS > >ʼn U+0149 LATIN SMALL LETTER N PRECEDED BY APOSTROPHE >ʼN > >ff U+FB00 LATIN SMALL LIGATURE FF >FF > >[1] CaseFolding.txt says: ># The data supports both implementations that require simple case foldings ># (where string lengths don't change), and implementations that allow full >case folding ># (where string lengths may grow). Note that where they can be supported, the ># full case foldings are superior: for example, they allow "MASSE" and "Maße" >to match. > >-- >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 ritt.ks at gmail.com Wed Feb 10 22:05:28 2016 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Thu, 11 Feb 2016 01:05:28 +0400 Subject: [Development] Qt::CaseInsensitive comparison is not the same as toLower() comparison In-Reply-To: <05D81450-9EF3-4972-A24B-9F14498DE658@theqtcompany.com> References: <4859225.ahGp9Rcj76@tjmaciei-mobl4> <05D81450-9EF3-4972-A24B-9F14498DE658@theqtcompany.com> Message-ID: 2016-02-10 23:46 GMT+04:00 Knoll Lars : > Hi Thiago, > > On 10/02/16 19:27, "Development on behalf of Thiago Macieira" < > development-bounces at qt-project.org on behalf of thiago.macieira at intel.com> > wrote: > > > > > > >Hi all > > > >(especially Konstantin!) > > > >When reviewing a change, I noticed that QString::startsWith with > >CaseInsensitive compares things like this: > > > > if (foldCase(data[i]) != foldCase((ushort)latin[i])) > > return false; > > > >with foldCase() being > convertCase_helper(ch), > >whereas toLower() uses QUnicodeTables::LowercaseTraits. > > > >There's a slight but important difference in a few character pairs see > below. > >The code has been like that since forever. So I have to ask: > > > > => Is this intended? > > Yes, CaseInsensitive comparisons should compare case folded strings. And > you're right, in some cases that is something else than comparing the lower > cased versions of both strings. > > > >If you write code like: > > > > qDebug() << a.startsWith(b, Qt::CaseInsensitive) > > << (a.toLower() == b.toLower()); > > > >You'll get a different result for the following pairs (for example, see > util/ > >unicode/data/CaseFolding.txt for more): > > > >µ U+00B5 MICRO SIGN > >μ U+03BC GREEK SMALL LETTER MU > > > >s U+0073 LATIN SMALL LETTER S > >ſ U+017F LATIN SMALL LETTER LONG S > > > >And then there are the differences between toUpper and toLower. The > following > >pairs compare false with toLower(), compare true with toUpper(), currently > >compare false with CaseInsensitive/toCaseFolded() but *should* compare > >true[1]: > > They should only compare true with full case folding rules. This is > something we have so far not implemented in Qt; as you noted below we're > still using simple case folding rules. > > This is actually somewhat similar to the case of comparing strings in > different normalisation forms (composed vs decomposed), something we also > don't do out of the box (ie. 'Ä' doesn't compare true with the combination > of 'A' with the diacritical mark for umlaut. > > At some point it would probably be nice to implement support for comparing > these correctly. This does however have a performance impact and many use > cases might not want this comparison by default. > Right, we still don't have "full" case folding support in Qt; but even if we did, it requires a locale (or at least language) to be passed as a comparison context, which means we'll have to review our string comparison API -- so maybe Qt6? w3c says: If your application or specification needs to consider case folding, here are some general recommendations to follow: 1. *Consider Unicode Normalization* in addition to case folding. If you mean to find text that is semantically equal, you may need to normalize the text beyond just case folding it. Note that Unicode Normalization does *not* include case folding: these are separate operations. 2. *Always use the language (locale) when case folding.* Some languages have specific case folding idiosyncrasies. In particular, if you do not pass the language or locale to your case folding routine, you may get a default locale which might be Turkish (for example). 1. *Specify US English or "empty" (root) locale if you need consistent (internal, not for presentation) comparisons* If your comparison should be the same regardless of language or locale, always pass the US English or empty (root, C, POSIX, null) locale to your case-folding function. This does not disable caseless comparison or case folding. It merely limits the effects to a well-known set of rules. 2. *Use case-less compare functions if provided* If your application is comparing internal values for equality (as opposed to sorting lists or comparing values linguistically), you should use a consistent caseless compare function. For example, Java's java.lang.String class provides an equalsIgnoreCase function that is more convenient than using toLowerCase(#locale)... which provides consistent results across languages, although not consistent with the rules for any given language. 3. *For presentation, normalize case in a language sensitive manner* The rules that one language uses for case will not necessarily match those used by another language. For example, the French novel by Marcel Proust *À la recherche du temps perdu* contains only the single, introductory capital letter, whereas the English title uses "titlecase": *In Search of Lost Time*. Code that assumes one form of capitalization is appropriate for another language may cause problems. In Qt, we usually don't have to do 1 ourselves as we put this responsibility to the calling side; that saying, we always assume both texts are in normalized form (usually composed). 2 relates to the "full" case folding -- clearly describes *why* it needs a context. IIRC, it is similar to QLocale::toLower(). And we have even more powerful (but less cheap) QCollator & Co. 3 is out of scope; our title casing algorithm doesn't respect the locale (actually, I doubt any one ever uses our title casing algorithm, so probably it is a dead weight). Regards, Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Feb 10 22:07:47 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Feb 2016 13:07:47 -0800 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: References: <56BB1830.30500@theqtcompany.com> <4659079.st41LRaXTV@tjmaciei-mobl4> Message-ID: <3854221.cPhh7UbdD4@tjmaciei-mobl4> On quinta-feira, 11 de fevereiro de 2016 03:04:52 PST Tim Blechmann wrote: > > Regardless of whether that is a valid approach or not, the fact that > > people > > are doing that poses a problem for us. If we write code against the latest > > toolchain, it may not compile against older ones people might be using. > > this implies bumping the minimum requirements. for some use cases this > might be acceptable, for others it isn't. According to Apple, it is... > > That can be because we used new features that aren't present in older > > ones, > > even if properly runtime checked. > > > > Another problem is that the compilers in the old toolchains are older, > > with > > older libc++ and with bugs that we aren't testing for. > > ... or newer toolchains can introduce regressions ... But we usually detect those and work around them. It's bad, but better than the alternative: when we don't detect an issue because we're not testing that toolchain. > > If we're going to upgrade our Xcode in all our builds, I would advise we > > also make it mandatory for everyone else too. Check during configure > > against the minimum SDK version, that being the *current* at the time of > > release. > > so what happens when you are hit by a toolchain regression? i'm not > voting for having code compiling with gcc-4.2 or any of the llvm-gcc > flavors which were around during that time. however qt is a framework > and it should support more than one toolchain so that people who are hit > by toolchain bugs still have an alternative ... Put up with it and complain to Apple? :-/ Seriously, this guidance is coming from your OS and toolchain vendor. If you don't like it, you should consider another vendor. They're not going to change their practices if people keep putting up with them. To be clear, I'm not in favour of dropping support for older toolchains. I'd rather we kept testing them, to reasonable amounts (we can't test every Xcode release on every OS X host). I'd rather Qt shielded people from bad practices from vendors. But as often happens whenever a topic like this comes up: there's a resource constraint. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Feb 10 22:09:10 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Feb 2016 13:09:10 -0800 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: <514701455131659@web14m.yandex.ru> References: <56BB1830.30500@theqtcompany.com> <514701455131659@web14m.yandex.ru> Message-ID: <1569643.d7qFRXgsks@tjmaciei-mobl4> On quarta-feira, 10 de fevereiro de 2016 22:14:19 PST Konstantin Tokarev wrote: > I can imagine the next solution: additionally run CI using open source > Clang, corresponding to minimum Xcode version you are going to support. Open Source Clang is not supported and may not even compile the sources. Apple is known to patch Clang heavily, including to ignore full-blown syntax errors in their headers (instead of fixing the headers). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Feb 10 22:36:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Feb 2016 13:36:01 -0800 Subject: [Development] Qt::CaseInsensitive comparison is not the same as toLower() comparison In-Reply-To: <05D81450-9EF3-4972-A24B-9F14498DE658@theqtcompany.com> References: <4859225.ahGp9Rcj76@tjmaciei-mobl4> <05D81450-9EF3-4972-A24B-9F14498DE658@theqtcompany.com> Message-ID: <3385510.Y49EMkGpce@tjmaciei-mobl4> On quarta-feira, 10 de fevereiro de 2016 19:46:49 PST Knoll Lars wrote: > They should only compare true with full case folding rules. This is > something we have so far not implemented in Qt; as you noted below we're > still using simple case folding rules. > > This is actually somewhat similar to the case of comparing strings in > different normalisation forms (composed vs decomposed), something we also > don't do out of the box (ie. 'Ä' doesn't compare true with the combination > of 'A' with the diacritical mark for umlaut. > > At some point it would probably be nice to implement support for comparing > these correctly. This does however have a performance impact and many use > cases might not want this comparison by default. I would say this requires more items in Qt::CaseSensitivity (or a new enum). CaseSensitive => no case folding, no normalisation CaseSensitiveNormalized => no case folding, but normalised CaseInsensitive => case-folded, no normalisation CaseInsensitiveNormalized => both We may need a comparison that uses lowercasing and/or uppercasing instead of case-folding for contexts where that is important. I'm thinking specifically of security issues in networking, due to how certain protocols may interpret certain characters. One particular case that comes to mind are case insensitive filesystems. What "insensitiveness" do they use? Even if we ignore the Turkic I and ligatures like ß and ff, we still have "simple" cases like mu and micron: on both Windows and OS X, I can create both files. $ touch $'\u03bc'.txt $'\u00b5'.txt $ ls ?.txt µ.txt μ.txt This leads to security vulnerabilities like: QString filename = QString::fromUtf8(socket.readAll()); if (filename.compare("µ.txt", Qt::CaseInsensitive) == 0) { QFile f(filename); if (f.open(QIODevice::ReadOnly)) { socket.write(f.readAll()); return true; } } return false; [Why would you compare µ case insensitively? Because it wasn't the µ I was concerned about, but the ".txt" part!] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ritt.ks at gmail.com Thu Feb 11 00:00:02 2016 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Thu, 11 Feb 2016 03:00:02 +0400 Subject: [Development] Qt::CaseInsensitive comparison is not the same as toLower() comparison In-Reply-To: <3385510.Y49EMkGpce@tjmaciei-mobl4> References: <4859225.ahGp9Rcj76@tjmaciei-mobl4> <05D81450-9EF3-4972-A24B-9F14498DE658@theqtcompany.com> <3385510.Y49EMkGpce@tjmaciei-mobl4> Message-ID: 2016-02-11 1:36 GMT+04:00 Thiago Macieira : > On quarta-feira, 10 de fevereiro de 2016 19:46:49 PST Knoll Lars wrote: > > They should only compare true with full case folding rules. This is > > something we have so far not implemented in Qt; as you noted below we're > > still using simple case folding rules. > > > > This is actually somewhat similar to the case of comparing strings in > > different normalisation forms (composed vs decomposed), something we also > > don't do out of the box (ie. 'Ä' doesn't compare true with the > combination > > of 'A' with the diacritical mark for umlaut. > > > > At some point it would probably be nice to implement support for > comparing > > these correctly. This does however have a performance impact and many use > > cases might not want this comparison by default. > > I would say this requires more items in Qt::CaseSensitivity (or a new > enum). > > CaseSensitive => no case folding, no > normalisation > CaseSensitiveNormalized => no case folding, but normalised > CaseInsensitive => case-folded, no > normalisation > CaseInsensitiveNormalized => both > Normalized how? C, D, KC, KD ? > We may need a comparison that uses lowercasing and/or uppercasing instead > of > case-folding for contexts where that is important. I'm thinking > specifically of > security issues in networking, due to how certain protocols may interpret > certain characters. > > One particular case that comes to mind are case insensitive filesystems. > What > "insensitiveness" do they use? Even if we ignore the Turkic I and ligatures > like ß and ff, we still have "simple" cases like mu and micron: on both > Windows > and OS X, I can create both files. > > $ touch $'\u03bc'.txt $'\u00b5'.txt > $ ls ?.txt > µ.txt μ.txt > > This leads to security vulnerabilities like: > > QString filename = QString::fromUtf8(socket.readAll()); > if (filename.compare("µ.txt", Qt::CaseInsensitive) == 0) { > QFile f(filename); > if (f.open(QIODevice::ReadOnly)) { > socket.write(f.readAll()); > return true; > } > } > return false; > > [Why would you compare µ case insensitively? Because it wasn't the µ I was > concerned about, but the ".txt" part!] > Quite synthetic use case as to me. Anyways, QUrl has no such issue. Regards, Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Feb 11 00:47:32 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Feb 2016 15:47:32 -0800 Subject: [Development] Qt::CaseInsensitive comparison is not the same as toLower() comparison In-Reply-To: References: <4859225.ahGp9Rcj76@tjmaciei-mobl4> <3385510.Y49EMkGpce@tjmaciei-mobl4> Message-ID: <5414347.z4aLEiMS3S@tjmaciei-mobl4> On quinta-feira, 11 de fevereiro de 2016 03:00:02 PST Konstantin Ritt wrote: > > CaseSensitive => no case folding, no > > normalisation > > CaseSensitiveNormalized => no case folding, but normalised > > CaseInsensitive => case-folded, no > > normalisation > > CaseInsensitiveNormalized => both > > Normalized how? C, D, KC, KD ? The choice is between K and non-K. Most likely, non-K. How it's implemented (towards C or towards D) is irrelevant. > > $ touch $'\u03bc'.txt $'\u00b5'.txt > > $ ls ?.txt > > µ.txt μ.txt > > > > This leads to security vulnerabilities like: > > QString filename = QString::fromUtf8(socket.readAll()); > > if (filename.compare("µ.txt", Qt::CaseInsensitive) == 0) { > > QFile f(filename); > > if (f.open(QIODevice::ReadOnly)) { > > socket.write(f.readAll()); > > return true; > > } > > } > > return false; > > > > [Why would you compare µ case insensitively? Because it wasn't the µ I was > > concerned about, but the ".txt" part!] > > Quite synthetic use case as to me. As security issues often look like before they actually happen. Who would have guessed the circumstances of the original TOCTOU attack (flood the Linux kernel with enough data to cause cached data to be dropped)? For a concrete case (not security): an IRC client was made to join a channel with ı in the name, but then due to bugs in the client, it joined two or more (uppercase leads to I, lowercase leads to i, uppercasing again leads to İ). This actually happened. > Anyways, QUrl has no such issue. URLs are case-sensitive, except for two portions: a) scheme, which is limited to A-Z anyway b) hostnames, for which there are very specific and explicit rules about case- folding (case-folding and NFKC according to Unicode 3.2, no other) But that is exactly the issue: if URLs are case-sensitive and the file system isn't, then is /%C2%B5.txt the same as /%CE%BC.txt? According to QUrl, they aren't, but according to QString::compare with Qt::CaseInsensitive, they are. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ariel at edis.mx Thu Feb 11 02:13:45 2016 From: ariel at edis.mx (Ariel Molina) Date: Wed, 10 Feb 2016 19:13:45 -0600 Subject: [Development] Extending touch semantic information and Qt backends Message-ID: Hi, Research is strong on natural user interfaces, and now market is stronger than ever and growing. I was working on the TUIO QPA and found a couple of bugs, which I already pushed patches [1] [2] which I hope make it to 5.6.x. OTOH, to further enhance touch interfaces I want to bring the discussion about multiple touch layers, person-tagged touches, identified touches with area&rotation information and objects with unique marker identification. - Multiple touch devs/layers and Person tagged touches. Can be easily added by extending QWindowSystemInterface::TouchPoint with a device identification, like device(). This will also work for TUIO. - Area & rotation. There is TouchPoint::area() and ::pressure() but currently there is no support for ::angle(). Angle can be zero when not supported. - Unique identification. On research and advanced interactive surfaces the usage of "markers" [3] is quite common. This is just a code extracted either visually or by other mechanisms which is passed along the touch information. I conjunction with area, rotation and uuid this paves the way for very rich interaction. I would like to know your thoughts about this topics, specially to know if it would be acceptable for me to submit patches enhancing those areas (and to whom add for review). I'd love to see marker uuid and angle() support at least. Ariel EDIS Interactive (desert on IRC) [1] https://codereview.qt-project.org/#/c/148914/ [2] https://codereview.qt-project.org/#/c/148924/ [3] https://www.youtube.com/watch?v=jtjNU0Fs3og -- Ariel Molina R. http://edis.mx -------------- next part -------------- An HTML attachment was scrubbed... URL: From tim at klingt.org Thu Feb 11 06:33:48 2016 From: tim at klingt.org (Tim Blechmann) Date: Thu, 11 Feb 2016 13:33:48 +0800 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: <3854221.cPhh7UbdD4@tjmaciei-mobl4> References: <56BB1830.30500@theqtcompany.com> <4659079.st41LRaXTV@tjmaciei-mobl4> <3854221.cPhh7UbdD4@tjmaciei-mobl4> Message-ID: >> ... or newer toolchains can introduce regressions ... > > But we usually detect those and work around them. qt is a framework, toolchain bugs may pop up in user code ... From thiago.macieira at intel.com Thu Feb 11 06:44:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Feb 2016 21:44:01 -0800 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: References: <56BB1830.30500@theqtcompany.com> <3854221.cPhh7UbdD4@tjmaciei-mobl4> Message-ID: <1488863.CWx3g7kTVe@tjmaciei-mobl4> On quinta-feira, 11 de fevereiro de 2016 13:33:48 PST Tim Blechmann wrote: > >> ... or newer toolchains can introduce regressions ... > > > > But we usually detect those and work around them. > > qt is a framework, toolchain bugs may pop up in user code ... Indeed, like your example about std::exception. But from experience, we find more issues in the toolchains caused by Qt itself than our users do. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Eike.Ziller at theqtcompany.com Thu Feb 11 09:34:15 2016 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Thu, 11 Feb 2016 08:34:15 +0000 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: <4659079.st41LRaXTV@tjmaciei-mobl4> References: <56BB1830.30500@theqtcompany.com> <1837015.2tL8bV86hx@tjmaciei-mobl4> <4659079.st41LRaXTV@tjmaciei-mobl4> Message-ID: > On Feb 10, 2016, at 6:36 PM, Petroules Jake wrote: > > >> On Feb 10, 2016, at 8:11 AM, Tor Arne Vestbø wrote: >> >> On 10/02/16 17:06, Thiago Macieira wrote: >>> On quarta-feira, 10 de fevereiro de 2016 12:00:00 PST Tor Arne Vestbø wrote: >>>> Does anyone see any issues with this going forward? >>> >>> We need to be sure Qt compiles with the latest Xcode available on each of the >>> OS X versions that Qt can be developed on. Since 10.8→10.11 updating is free, >>> the only extra test is 10.7. The latest Xcode that can be installed on 10.7 >>> is Xcode 5.1, so it's important we keep building with that. > > Pretty sure the App Store on my 10.7 VM prompts me to upgrade to 10.11 for free as well. I'm on the train without my VM SSD so I can't check right now. > While I think that the whole App Store argument is a valid one for iOS, I think the situation on OS X is very different - The App Store is by far not the only software distribution mechanism on OS X - There is a market of applications that even cannot be distributed through the App Store - It seems that developers even move away from distributing through the App Store on OS X because of various reasons (long review process, no payed updates, etc) > On Feb 10, 2016, at 7:31 PM, Thiago Macieira wrote: > > On quinta-feira, 11 de fevereiro de 2016 02:02:27 PST Tim Blechmann wrote: >> we have seen funny toolchain bugs, with 10.10 sdk and 10.8 deployment >> target on 10.8, where std::exceptions could not be caught ... compiling >> against 10.8 sdk solved that issue. > > Regardless of whether that is a valid approach or not, the fact that people > are doing that poses a problem for us. If we write code against the latest > toolchain, it may not compile against older ones people might be using. > > That can be because we used new features that aren't present in older ones, > even if properly runtime checked. > > Another problem is that the compilers in the old toolchains are older, with > older libc++ and with bugs that we aren't testing for. > > If we're going to upgrade our Xcode in all our builds, I would advise we also > make it mandatory for everyone else too. Check during configure against the > minimum SDK version, that being the *current* at the time of release. We also do not prevent compilation on , even though that is certainly not CI tested. Br, Eike -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company 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 ritt.ks at gmail.com Thu Feb 11 10:26:50 2016 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Thu, 11 Feb 2016 13:26:50 +0400 Subject: [Development] Qt::CaseInsensitive comparison is not the same as toLower() comparison In-Reply-To: <5414347.z4aLEiMS3S@tjmaciei-mobl4> References: <4859225.ahGp9Rcj76@tjmaciei-mobl4> <3385510.Y49EMkGpce@tjmaciei-mobl4> <5414347.z4aLEiMS3S@tjmaciei-mobl4> Message-ID: 2016-02-11 3:47 GMT+04:00 Thiago Macieira : > On quinta-feira, 11 de fevereiro de 2016 03:00:02 PST Konstantin Ritt > wrote: > > > CaseSensitive => no case folding, no > > > normalisation > > > CaseSensitiveNormalized => no case folding, but normalised > > > CaseInsensitive => case-folded, no > > > normalisation > > > CaseInsensitiveNormalized => both > > > > Normalized how? C, D, KC, KD ? > > The choice is between K and non-K. Most likely, non-K. > > How it's implemented (towards C or towards D) is irrelevant. > > > > $ touch $'\u03bc'.txt $'\u00b5'.txt > > > $ ls ?.txt > > > µ.txt μ.txt > > > > > > This leads to security vulnerabilities like: > > > QString filename = QString::fromUtf8(socket.readAll()); > > > if (filename.compare("µ.txt", Qt::CaseInsensitive) == 0) { > > > QFile f(filename); > > > if (f.open(QIODevice::ReadOnly)) { > > > socket.write(f.readAll()); > > > return true; > > > } > > > } > > > return false; > > > > > > [Why would you compare µ case insensitively? Because it wasn't the µ I > was > > > concerned about, but the ".txt" part!] > > > > Quite synthetic use case as to me. > > As security issues often look like before they actually happen. Who would > have > guessed the circumstances of the original TOCTOU attack (flood the Linux > kernel > with enough data to cause cached data to be dropped)? > > For a concrete case (not security): an IRC client was made to join a > channel > with ı in the name, but then due to bugs in the client, it joined two or > more > (uppercase leads to I, lowercase leads to i, uppercasing again leads to İ). > This actually happened. > > > Anyways, QUrl has no such issue. > > URLs are case-sensitive, except for two portions: > > a) scheme, which is limited to A-Z anyway > b) hostnames, for which there are very specific and explicit rules about > case- > folding (case-folding and NFKC according to Unicode 3.2, no other) > > But that is exactly the issue: if URLs are case-sensitive and the file > system > isn't, then is /%C2%B5.txt the same as /%CE%BC.txt? According to QUrl, they > aren't, but according to QString::compare with Qt::CaseInsensitive, they > are. > BTW, *_wcsicmp* compares strings by simply converting them to their lowercase forms. So what you suggest? Changing Qt::CaseInsensitive string comparison to not use casefolding and introduce more option(s) for case-folded and normalized case-folded comparison? Albeit that'll be a behavioral change, I think I'm ok with that. Regards, Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.volkov at rusbitech.ru Thu Feb 11 11:35:18 2016 From: a.volkov at rusbitech.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCS0L7Qu9C60L7Qsg==?=) Date: Thu, 11 Feb 2016 13:35:18 +0300 Subject: [Development] Extending touch semantic information and Qt backends In-Reply-To: References: Message-ID: <56BC63E6.6080307@rusbitech.ru> Hi, Ariel. 11.02.2016 04:13, Ariel Molina пишет: > - Multiple touch devs/layers and Person tagged touches. Can be easily > added by extending QWindowSystemInterface::TouchPoint with a device > identification, like device(). This will also work for TUIO. There is QTouchEvent::device(). Isn't it enough? > - Area & rotation. There is TouchPoint::area() and ::pressure() but > currently there is no support for ::angle(). Angle can be zero when > not supported. Angle is not enough, because for compatibility with older apps TouchPoint::rect() should be as close as possible to the rotated rect. See https://codereview.qt-project.org/#/c/114238/ In other words it should be a projection of the rotated rect, so you should introduce a separate method to get the rotated rect. > - Unique identification. On research and advanced interactive surfaces > the usage of "markers" [3] is quite common. This is just a code > extracted either visually or by other mechanisms which is passed along > the touch information. I conjunction with area, rotation and uuid this > paves the way for very rich interaction. How does it differ from TouchPoint::id()? BR, Alexander. From Shawn.Rutledge at theqtcompany.com Thu Feb 11 13:06:31 2016 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Thu, 11 Feb 2016 12:06:31 +0000 Subject: [Development] Extending touch semantic information and Qt backends In-Reply-To: References: Message-ID: <1B2957B7-67BD-4056-97FF-EE876C9B8120@digia.com> > On 11 Feb 2016, at 02:13, Ariel Molina wrote: > > Hi, > > Research is strong on natural user interfaces, and now market is stronger than ever and growing. I was working on the TUIO QPA and found a couple of bugs, which I already pushed patches [1] [2] which I hope make it to 5.6.x. > > OTOH, to further enhance touch interfaces I want to bring the discussion about multiple touch layers, person-tagged touches, identified touches with area&rotation information and objects with unique marker identification. > > - Multiple touch devs/layers and Person tagged touches. Can be easily added by extending QWindowSystemInterface::TouchPoint with a device identification, like device(). This will also work for TUIO. > - Area & rotation. There is TouchPoint::area() and ::pressure() but currently there is no support for ::angle(). Angle can be zero when not supported. > - Unique identification. On research and advanced interactive surfaces the usage of "markers" [3] is quite common. This is just a code extracted either visually or by other mechanisms which is passed along the touch information. I conjunction with area, rotation and uuid this paves the way for very rich interaction. > > I would like to know your thoughts about this topics, specially to know if it would be acceptable for me to submit patches enhancing those areas (and to whom add for review). I'd love to see marker uuid and angle() support at least. I’m interested. But I will warn you that my attempts to make MouseArea and Flickable handle touch events directly have run into issues with the complexity of handling two completely independent event types with similar-but-different code, backwards compatibility, getting reviews on the patches, getting tests to continue passing, etc. They handle only mouse events, which are synthesized on a touchscreen; changing MouseArea to handle touch is too hard; and that makes it too hard to change Flickable, because so many applications have MouseAreas in delegates in ListViews. So, in existing releases of QtQuick, only PinchArea and MultiPointTouchArea handle touch events directly. Maybe you are thinking of enhancing MPTA and its TouchPoints? That’s probably doable, but do you think that API is useful enough for your applications? If not, what kind of API would you rather have? Now the plan is to write a new set of event handlers which are lighter-weight: not Items themselves but declared inside any Item (inspired by the Keys attached property, but not quite the same). There can potentially be lots of types of handlers, and even several handler instances inside one Item when necessary; some will be hardware-agnostic “gesture” recognizers (e.g. TapHandler and PinchHandler) while others will be hardware-specific. So maybe we can come up with a good way to handle markers within that framework, although I don’t have access to a fancy touch table which supports them (but have a capacitive touchscreen). And yes the multi-user scenarios are interesting too. I figured the new QQuickPointerEvent can have some sort of ID for user or “seat", whichever makes most sense. Do you think it should simply be a numeric ID? Likewise I don’t have a touchscreen which supports rotation, but have a Wacom tablet which does. QQuickPointerEvent has a rotation property, on the assumption that it will become more common (but I can only test it with the tablet for now). What do you mean about layers? The PointerEvent/PointerHandler patches have been mostly waiting for me to get back to them since last summer, but I plan to get back to them soon. https://codereview.qt-project.org/#/c/123122/ is currently the ‘tip’, and you can follow dependencies backwards from there. The plan is to put them into a branch soon so that it’s easier to follow progress. Then we’ll see if it gets done in time for 5.8. So far only the simplest Handlers work, others have issues remaining, and some aren’t written yet. From Shawn.Rutledge at theqtcompany.com Thu Feb 11 13:31:44 2016 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Thu, 11 Feb 2016 12:31:44 +0000 Subject: [Development] Extending touch semantic information and Qt backends In-Reply-To: <56BC63E6.6080307@rusbitech.ru> References: <56BC63E6.6080307@rusbitech.ru> Message-ID: > On 11 Feb 2016, at 11:35, Александр Волков wrote: > Angle is not enough, because for compatibility with older apps TouchPoint::rect() should be as close as possible to the rotated rect. > See https://codereview.qt-project.org/#/c/114238/ > In other words it should be a projection of the rotated rect, so you should introduce a separate method to get the rotated rect. TUIO models the touchpoint as a rotated ellipse though, right? http://www.tuio.org/?specification And I think that’s nice, for finger touchpoints at least (although markers could be any shape). It can be assumed to be the ellipse inscribed in a rect; but I don’t think for the next-gen API that it makes sense to change the dimensions just because it’s rotated, because that makes it hard to visualize the ellipse, and hard to turn the size of the contact patch into a pressure (if you have hardware which gives you the contact patch but not the pressure). Typical capacitive touchscreens (or window-system APIs) don’t provide the contact patch either, do they? I’m not sure why it’s not more common. From tor.arne.vestbo at theqtcompany.com Thu Feb 11 14:04:56 2016 From: tor.arne.vestbo at theqtcompany.com (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Thu, 11 Feb 2016 14:04:56 +0100 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: <3854221.cPhh7UbdD4@tjmaciei-mobl4> References: <56BB1830.30500@theqtcompany.com> <4659079.st41LRaXTV@tjmaciei-mobl4> <3854221.cPhh7UbdD4@tjmaciei-mobl4> Message-ID: <56BC86F8.5020806@theqtcompany.com> On 10/02/16 22:07, Thiago Macieira wrote: >>> If we're going to upgrade our Xcode in all our builds, I would advise we >>> also make it mandatory for everyone else too. Check during configure >>> against the minimum SDK version, that being the *current* at the time of >>> release. Yes, absolutely. > To be clear, I'm not in favour of dropping support for older toolchains. I'd > rather we kept testing them, to reasonable amounts (we can't test every Xcode > release on every OS X host). I'd rather Qt shielded people from bad practices > from vendors. > > But as often happens whenever a topic like this comes up: there's a resource > constraint. Exactly. Ideally we'd apply the process outlined in the OP for every single supported build platform, ie. build on 10.(7|8|9|10|11) and test on 10.7->10.11, but being resource constrained, both in manpower and CI resources, we can only afford to build on a single version, the latest. Note that this should make it easier to follow SDK/toolchain updates from Apple when they come out in beta, so that we can catch those toolchain issues _before_ they get released. tor arne From andrewponomarenko at yandex.ru Thu Feb 11 14:46:52 2016 From: andrewponomarenko at yandex.ru (Ponomarenko Andrey) Date: Thu, 11 Feb 2016 16:46:52 +0300 Subject: [Development] API/ABI changes report In-Reply-To: <2274263.zrLsn6XqlA@tjmaciei-mobl4> References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> Message-ID: <1603831455198412@web30o.yandex.ru> 05.02.2016, 19:58, "Thiago Macieira": > On sexta-feira, 5 de fevereiro de 2016 16:34:19 PST Ponomarenko Andrey wrote: >>  Hello, >> >>  I've started to maintain API/ABI changes report for the Qt library here: >>  http://abi-laboratory.pro/tracker/timeline/qt/ > > Hello Andrey > > Thank you for the service. > > Looking at the only release we have any control over right now: 5.6. > > * Qt3D: major changes, definitely not binary compatible. Was the release in 5.5 > properly marked as "technical preview, no ABI promise"? > > * QtCore: false positive, sendEvent() is still there. > > * QtGui: >  - QPixmapCache::allPixmaps(): innocent, was not public API, but you could get >    to it. >  - qt_sendShortcutOverrideEvent: affects QtTest binary compatibility >  - qt_handleMouseEvent: ditto >  - QWindowSystemInterface: binary incompatible (class is \ingroup qpa, but not >    in a _qpa.h header, therefore it's public API) > >         => is anyone reading the header diff for QtGui? > > * QtNetwork: false positive > > * QtQuick: >  - DesignerSupport: previously exported, undocumented class that wasn't in a >    _p.h header and did not even have a Q prefix. We can safely assume this was >    a major mistake in releasing and is now corrected. >  - events & accessibility: false positive > > * QtWaylandClient: >  - events: false positive >  - qt_extended_output: was public and should not have been removed. The same >    change also changed values of enums in other public classes >    (like QWaylandCompositor). > >         => is anyone reading the header diff for QtWaylandClient? > > * QtWidgets: >  - accessibility: false positive Hello Thiago, I've removed most of the false positives mentioned in the review from the report: http://abi-laboratory.pro/tracker/timeline/qt/ There are several remaining issues in the report. So I have some questions: - Is class QPlatformScreen private and all related changes should be removed from the report? (http://abi-laboratory.pro/tracker/compat_report/qt/5.5.1/5.6.0-beta/8f965/abi_compat_report.html) - Should I hide DesignerSupport class changes? (http://abi-laboratory.pro/tracker/compat_report/qt/5.5.1/5.6.0-beta/7404d/abi_compat_report.html) - Whats about xdg_* changes in the libQt5WaylandClient.so? (http://abi-laboratory.pro/tracker/compat_report/qt/5.5.1/5.6.0-beta/59c65/abi_compat_report.html) Thank you. From edward.welbourne at theqtcompany.com Thu Feb 11 15:05:22 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 11 Feb 2016 14:05:22 +0000 Subject: [Development] Extending touch semantic information and Qt backends In-Reply-To: References: <56BC63E6.6080307@rusbitech.ru>, Message-ID: Very much a digression but ... > TUIO models the touchpoint as a rotated ellipse though, right? [snip > URL] And I think that’s nice, for finger touchpoints at least > (although markers could be any shape). It can be assumed to be the > ellipse inscribed in a rect Traditional graphics always thinks in terms of *coordinate-aligned* rectangles, characterised by a width and height with respect to a single fixed coordinate system. This works fine for the classical (vertical rectangular) screen and even for most modern tablets, where "rotation" may be supported but only in multiples of a quarter turn. However, once you get to the kind of "touch surface as table" that the reactable video illustrated - a horizontal round table, no less - there ceases being any naturality to any one choice of coordinate alignment. It's then necessary to support all orientations equally well, without privileging one of them. In such a context, either an ellipse or a rectangle can be reduced to a centre-point, a semi-major axial vector (orienting it) and a semi-minor axis length (at right angles). Naturally, we can equivalently scale the axes by two to drop the semi-s. There's then an obvious correspondence between a rectangle and an ellipse via matching characterisation in these terms. Which you think of that set of parameters as representing is then somewhat arbitrary. The area of contact between a finger and a flat surface is closer to elliptical than to rectangular; but there's a stronger reason to prefer an ellipse. Now, I know nothing of the implementation details of touch screens: but have to guess that the actual raw data of an object pressing on a screen is a noisy mess of pressure signals from nearby sensors. The natural way to process that noisy mess shall be statistically and the natural statistical trickery to use for it is going to give you a mean (vector) and variance (matrix). The former is your centre-point; the latter is (necessarily, from how it'll be computed from raw data) a symmetric positive-definite quadratic form, a.k.a. a metric, which shall be diagonalised by some specific choice of coordinates - characterised by two perpendicular vectors, one of which we get to construe as semi-major axial vector, with the other telling us the semi-minor axis length. All of this would still be true for markers of stranger shapes, thanks to the noisy mess of physcal sensor data. So I'm not surprised to hear that a touchpoint ends up represented by these three data - centre, major axial vector, minor axis length - or some geometrical entity equivalent to them. While these data can indeed be understood equally as characterising a rectangle or an ellipse, coming via a metric makes the ellipse (the "unit circle" of the distance associated with the metric) the more natural form. When major and minor axes are close to equal in length, the ellipse strongly de-emphasises its incidental orientation, becoming completely orientation-agnostic when we get to major = minor, the circle. In contrast, a rectangle retains its sense of orientation all the way to that degenerate case, where the square still has a definite orientation, albeit modulo quarter turns. We need an orientation in our representation, to support the case where the axial lengths are significantly different, but we need to think of that orientation as only relevant in so far as the axial lengths *are* significantly different. Data derived from a metric in the form of centre, major axial vector and minor axial size are thus more naturally thought of as describing an ellipse. So let me encourage you to think in terms of ellipses in this modern era, as the more natural reading of "centre, major axial vector, minor axial size" data, rather than in terms of the rectangles you grew up with - they are an artefact of upright rectangular screens. The tactile UI folk rightly prefer a well-rounded future, Eddy. From thiago.macieira at intel.com Thu Feb 11 17:10:44 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 Feb 2016 08:10:44 -0800 Subject: [Development] API/ABI changes report In-Reply-To: <1603831455198412@web30o.yandex.ru> References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> <1603831455198412@web30o.yandex.ru> Message-ID: <1717011.eDQn0EExJk@tjmaciei-mobl4> On quinta-feira, 11 de fevereiro de 2016 16:46:52 PST Ponomarenko Andrey wrote: > I've removed most of the false positives mentioned in the review from the > report: http://abi-laboratory.pro/tracker/timeline/qt/ Thanks Andrey! > > There are several remaining issues in the report. So I have some questions: > > - Is class QPlatformScreen private and all related changes should be removed > from the report? > (http://abi-laboratory.pro/tracker/compat_report/qt/5.5.1/5.6.0-beta/8f965/ > abi_compat_report.html) Yes, that's a private class (QPlatform* is QPA, like QWindowSystem*). > - Should I hide DesignerSupport class changes? > (http://abi-laboratory.pro/tracker/compat_report/qt/5.5.1/5.6.0-beta/7404d/ > abi_compat_report.html) Yes, please. This was a mistake to make public. > - Whats about xdg_* changes in the libQt5WaylandClient.so? > (http://abi-laboratory.pro/tracker/compat_report/qt/5.5.1/5.6.0-beta/59c65/ > abi_compat_report.html) False positive too (private class). Note that this makes your reports only talk about public ABI compatibility. Anyone who used the private API will notice that it's not compatible. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Feb 11 17:11:40 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 Feb 2016 08:11:40 -0800 Subject: [Development] Qt::CaseInsensitive comparison is not the same as toLower() comparison In-Reply-To: References: <4859225.ahGp9Rcj76@tjmaciei-mobl4> <5414347.z4aLEiMS3S@tjmaciei-mobl4> Message-ID: <28009661.df5ZABdFrr@tjmaciei-mobl4> On quinta-feira, 11 de fevereiro de 2016 13:26:50 PST Konstantin Ritt wrote: > BTW, *_wcsicmp* compares strings by simply converting them to their > lowercase forms. > So what you suggest? Changing Qt::CaseInsensitive string comparison to not > use casefolding and introduce more option(s) for case-folded and normalized > case-folded comparison? > > Albeit that'll be a behavioral change, I think I'm ok with that. That's not what I was thinking, but it's also possible. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at theqtcompany.com Thu Feb 11 18:04:14 2016 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Thu, 11 Feb 2016 17:04:14 +0000 Subject: [Development] HEADS UP: OSX build requirements for 5.7 In-Reply-To: <56BC86F8.5020806@theqtcompany.com> References: <56BB1830.30500@theqtcompany.com> <4659079.st41LRaXTV@tjmaciei-mobl4> <3854221.cPhh7UbdD4@tjmaciei-mobl4> <56BC86F8.5020806@theqtcompany.com> Message-ID: <62A129E8-311C-4F02-ABFB-A7BFA6E740CF@theqtcompany.com> Another advantage for end users is that they are guaranteed to get the latest platform features supported by that version of Qt if their OS version also supports them. For example, if Qt is built with the 10.11 SDK and therefore provides a fast WKWebView implementation, users running on 10.11 will always get it, as opposed to Qt being built with the 10.9 SDK where users will get the slow WebView implementation instead, despite the current OS supporting WKWebView, since it wasn't compiled in to begin with. On Feb 11, 2016, at 5:04 AM, Tor Arne Vestbø > wrote: On 10/02/16 22:07, Thiago Macieira wrote: If we're going to upgrade our Xcode in all our builds, I would advise we also make it mandatory for everyone else too. Check during configure against the minimum SDK version, that being the *current* at the time of release. Yes, absolutely. To be clear, I'm not in favour of dropping support for older toolchains. I'd rather we kept testing them, to reasonable amounts (we can't test every Xcode release on every OS X host). I'd rather Qt shielded people from bad practices from vendors. But as often happens whenever a topic like this comes up: there's a resource constraint. Exactly. Ideally we'd apply the process outlined in the OP for every single supported build platform, ie. build on 10.(7|8|9|10|11) and test on 10.7->10.11, but being resource constrained, both in manpower and CI resources, we can only afford to build on a single version, the latest. Note that this should make it easier to follow SDK/toolchain updates from Apple when they come out in beta, so that we can catch those toolchain issues _before_ they get released. tor arne _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From ariel at edis.mx Thu Feb 11 18:49:16 2016 From: ariel at edis.mx (Ariel Molina) Date: Thu, 11 Feb 2016 11:49:16 -0600 Subject: [Development] Extending touch semantic information and Qt backends In-Reply-To: <56BC63E6.6080307@rusbitech.ru> References: <56BC63E6.6080307@rusbitech.ru> Message-ID: > > >> There is QTouchEvent::device(). Isn't it enough? > > > - Area & rotation. There is TouchPoint::area() and ::pressure() but >> currently there is no support for ::angle(). Angle can be zero when not >> supported. >> > Angle is not enough, because for compatibility with older apps > TouchPoint::rect() should be as close as possible to the rotated rect. > See https://codereview.qt-project.org/#/c/114238/ > In other words it should be a projection of the rotated rect, so you > should introduce a separate method to get the rotated rect. > I see the patch refers to a fix making it rotate to the closest angle. Then there is the blob definition from http://tuio.org/?specification (scroll to the bottom), by using the diagram on the bottom of that page, you mean TouchPoint::blob() and TouchPoint::blobAngle() might be more appropriate? > > - Unique identification. On research and advanced interactive surfaces the >> usage of "markers" [3] is quite common. This is just a code extracted >> either visually or by other mechanisms which is passed along the touch >> information. I conjunction with area, rotation and uuid this paves the way >> for very rich interaction. >> > How does it differ from TouchPoint::id()? > AFAIK ::id() is a temporary ID for unique identification of current live touchpoints. This means the same object/finger gets different id() every time it is released and come to touch again. Im talking about marked objects such as the used in Samsung SUR40 (Microsoft Pixelsense), Fidtrack, Reactivision [1][2] and several others including magnetic object detection[3] where devices can uniquely identify objects, their position and rotation. Ariel [1] Fiducials and finger touchs. http://reactivision.sourceforge.net/images/reactivision01.png [2] https://www.youtube.com/watch?v=Mgy1S8qymx0 [3] https://www.youtube.com/watch?v=qlr-15Oto6s -- Ariel Molina R. Oficina: +52 (222) 3723196 Movil: +521 2226 758874 http://edis.mx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ariel at edis.mx Thu Feb 11 19:09:32 2016 From: ariel at edis.mx (Ariel Molina) Date: Thu, 11 Feb 2016 12:09:32 -0600 Subject: [Development] Extending touch semantic information and Qt backends In-Reply-To: <1B2957B7-67BD-4056-97FF-EE876C9B8120@digia.com> References: <1B2957B7-67BD-4056-97FF-EE876C9B8120@digia.com> Message-ID: > > I’m interested. But I will warn you that my attempts to make MouseArea > and Flickable handle touch events directly have run into issues with the > complexity of handling two completely independent event types with > similar-but-different code, backwards compatibility, getting reviews on the > patches, getting tests to continue passing, etc. They handle only mouse > events, which are synthesized on a touchscreen; changing MouseArea to > handle touch is too hard; and that makes it too hard to change Flickable, > because so many applications have MouseAreas in delegates in ListViews. > Ideally I won't be touching any existing code, just adding more semantic information to current code, things such as rotation, deviceID and marker ID's are easy to add, but shape information and others are not that easy. > > So, in existing releases of QtQuick, only PinchArea and > MultiPointTouchArea handle touch events directly. Maybe you are thinking > of enhancing MPTA and its TouchPoints? That’s probably doable, but do you > think that API is useful enough for your applications? If not, what kind > of API would you rather have? > I found the MultiPointTouchArea to be very limited, for example now the code suggests to name every TouchPoint in order to use them ( http://doc.qt.io/qt-5/qml-qtquick-multipointtoucharea.html#touchPoints-prop) . Better will be to allow it to be inserted as a model into a Repeater. How about supporting something like this? MultitouchArea{ id: mtArea } Repeater{ model: mtArea.touchpoints delegate: Rectangle{ x: touchX y: touchX width: blob.width height: blob.height rotation: blob.angle opacity: pressure } } The main limitation there seems to be the limited information TouchPoint offers. With some refactoring to MultiTouchPointArea it can be done. > > Now the plan is to write a new set of event handlers which are > lighter-weight: not Items themselves but declared inside any Item (inspired > by the Keys attached property, but not quite the same). There can > potentially be lots of types of handlers, and even several handler > instances inside one Item when necessary; some will be hardware-agnostic > “gesture” recognizers (e.g. TapHandler and PinchHandler) while others will > be hardware-specific. The event managing is a ver good idea, but the real limitations are on the information TouchPoints provide. > So maybe we can come up with a good way to handle markers within that > framework, although I don’t have access to a fancy touch table which > supports them (but have a capacitive touchscreen). And yes the multi-user > scenarios are interesting too. I figured the new QQuickPointerEvent can > have some sort of ID for user or “seat", whichever makes most sense. Do > you think it should simply be a numeric ID? > There are several variants of fiducial markers, see for example the list at http://www.tuio.org/?tuio20 where they list fidtrack, touchatag, QR Codes, EAN barcodes, two variants of Microsoft, and even color tags covering from binary trees, to strings, hex codes and raw bytes. So a QString should accomodate all variants. > > Likewise I don’t have a touchscreen which supports rotation, but have a > Wacom tablet which does. QQuickPointerEvent has a rotation property, on > the assumption that it will become more common (but I can only test it with > the tablet for now). > > What do you mean about layers? > Several users interacting on the same space from different perspectives, either bilateral screens (they are already being used), or screens where some touchevents come from remote places/users. By identification of the source it can be easily supported and by ignoring source the layers just become a single touchscreen so current apps are not affected. -- Ariel Molina R. Oficina: +52 (222) 3723196 Movil: +521 2226 758874 http://edis.mx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ariel at edis.mx Thu Feb 11 19:16:38 2016 From: ariel at edis.mx (Ariel Molina) Date: Thu, 11 Feb 2016 12:16:38 -0600 Subject: [Development] Extending touch semantic information and Qt backends In-Reply-To: References: <56BC63E6.6080307@rusbitech.ru> Message-ID: On Thu, Feb 11, 2016 at 6:31 AM, Rutledge Shawn < Shawn.Rutledge at theqtcompany.com> wrote: > > > On 11 Feb 2016, at 11:35, Александр Волков > wrote: > > Angle is not enough, because for compatibility with older apps > TouchPoint::rect() should be as close as possible to the rotated rect. > > See https://codereview.qt-project.org/#/c/114238/ > > In other words it should be a projection of the rotated rect, so you > should introduce a separate method to get the rotated rect. > ::blob() and ::blobAngle() ? > TUIO models the touchpoint as a rotated ellipse though, right? > http://www.tuio.org/?specification And I think that’s nice, for finger > touchpoints at least (although markers could be any shape). It can be > assumed to be the ellipse inscribed in a rect; but I don’t think for the > next-gen API that it makes sense to change the dimensions just because it’s > rotated, because that makes it hard to visualize the ellipse, and hard to > turn the size of the contact patch into a pressure (if you have hardware > which gives you the contact patch but not the pressure). > > Typical capacitive touchscreens (or window-system APIs) don’t provide the > contact patch either, do they? I’m not sure why it’s not more common. > I think they will become more common as the haptic interaction grows. Apple, for example is now supporting haptic pressure sensors (do they detect shape?) and also the Apple-led reborn of pen computing will forcibly need shape/rotation recognition, see palm rejection: https://vine.co/v/etUgZKl0laX > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Ariel Molina R. http://edis.mx -------------- next part -------------- An HTML attachment was scrubbed... URL: From ariel at edis.mx Thu Feb 11 19:33:10 2016 From: ariel at edis.mx (Ariel Molina) Date: Thu, 11 Feb 2016 12:33:10 -0600 Subject: [Development] Extending touch semantic information and Qt backends In-Reply-To: References: <56BC63E6.6080307@rusbitech.ru> Message-ID: Edward, I strongly agree with your analysis. Any generalized touch (marker, finger, pen) has a general elliptic shape defined by a rectangle, when a device does not support that info, touches are just degenerate squares 0 by 0 and zero area. But richer devices might provide blob rect and blob angle, blob unique ID *and* the type of blob: Touch, PenTouch, Blob either uniquely identified or not (and the source of them if we can dream that far). Thinking like this we can easily support Normal Fingertouches (non universally identified Touch with only temporary ID, -null blob area, zero angle or pressure if not supported-), Makers can be blobs with an ID, area and angle; palms, hands, a cup of coffee and others are just unidentified blobs on devices that can recognize them (SUR40?, current optical trackers and future new devices). Please correct me, but I see this as paving future support for those recent haptic devices such as Apple Pen, Wacoms (and Im sure Google has something in the works for Android). Ariel On Thu, Feb 11, 2016 at 8:05 AM, Welbourne Edward < edward.welbourne at theqtcompany.com> wrote: > Very much a digression but ... > > > TUIO models the touchpoint as a rotated ellipse though, right? [snip > > URL] And I think that’s nice, for finger touchpoints at least > > (although markers could be any shape). It can be assumed to be the > > ellipse inscribed in a rect > > Traditional graphics always thinks in terms of *coordinate-aligned* > rectangles, characterised by a width and height with respect to a single > fixed coordinate system. This works fine for the classical (vertical > rectangular) screen and even for most modern tablets, where "rotation" > may be supported but only in multiples of a quarter turn. However, once > you get to the kind of "touch surface as table" that the reactable video > illustrated - a horizontal round table, no less - there ceases being any > naturality to any one choice of coordinate alignment. It's then > necessary to support all orientations equally well, without privileging > one of them. > > In such a context, either an ellipse or a rectangle can be reduced to a > centre-point, a semi-major axial vector (orienting it) and a semi-minor > axis length (at right angles). Naturally, we can equivalently scale the > axes by two to drop the semi-s. There's then an obvious correspondence > between a rectangle and an ellipse via matching characterisation in > these terms. Which you think of that set of parameters as representing > is then somewhat arbitrary. The area of contact between a finger and a > flat surface is closer to elliptical than to rectangular; but there's a > stronger reason to prefer an ellipse. > > Now, I know nothing of the implementation details of touch screens: but > have to guess that the actual raw data of an object pressing on a screen > is a noisy mess of pressure signals from nearby sensors. The natural > way to process that noisy mess shall be statistically and the natural > statistical trickery to use for it is going to give you a mean (vector) > and variance (matrix). The former is your centre-point; the latter is > (necessarily, from how it'll be computed from raw data) a symmetric > positive-definite quadratic form, a.k.a. a metric, which shall be > diagonalised by some specific choice of coordinates - characterised by > two perpendicular vectors, one of which we get to construe as semi-major > axial vector, with the other telling us the semi-minor axis length. All > of this would still be true for markers of stranger shapes, thanks to > the noisy mess of physcal sensor data. So I'm not surprised to hear > that a touchpoint ends up represented by these three data - centre, > major axial vector, minor axis length - or some geometrical entity > equivalent to them. > > While these data can indeed be understood equally as characterising a > rectangle or an ellipse, coming via a metric makes the ellipse (the > "unit circle" of the distance associated with the metric) the more > natural form. When major and minor axes are close to equal in length, > the ellipse strongly de-emphasises its incidental orientation, becoming > completely orientation-agnostic when we get to major = minor, the > circle. In contrast, a rectangle retains its sense of orientation all > the way to that degenerate case, where the square still has a definite > orientation, albeit modulo quarter turns. > > We need an orientation in our representation, to support the case where > the axial lengths are significantly different, but we need to think of > that orientation as only relevant in so far as the axial lengths *are* > significantly different. Data derived from a metric in the form of > centre, major axial vector and minor axial size are thus more naturally > thought of as describing an ellipse. > > So let me encourage you to think in terms of ellipses in this modern > era, as the more natural reading of "centre, major axial vector, minor > axial size" data, rather than in terms of the rectangles you grew up > with - they are an artefact of upright rectangular screens. The tactile > UI folk rightly prefer a well-rounded future, > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Ariel Molina R. http://edis.mx -------------- next part -------------- An HTML attachment was scrubbed... URL: From nospam at vuorela.dk Fri Feb 12 08:50:22 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Fri, 12 Feb 2016 07:50:22 +0000 (UTC) Subject: [Development] API/ABI changes report References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> <1603831455198412@web30o.yandex.ru> <1717011.eDQn0EExJk@tjmaciei-mobl4> Message-ID: On 2016-02-11, Thiago Macieira wrote: >> There are several remaining issues in the report. So I have some questions: >> >> - Is class QPlatformScreen private and all related changes should be removed >> from the report? >> (http://abi-laboratory.pro/tracker/compat_report/qt/5.5.1/5.6.0-beta/8f965/ >> abi_compat_report.html) > > Yes, that's a private class (QPlatform* is QPA, like QWindowSystem*). It is a public private class. I'm not sure it is fully correct to hide it. I'm also not sure it is fully correct to keep it. Many parts of the QPA bits are unfortunately widely used. We should really work towards making it public ... /Sune From Lars.Knoll at theqtcompany.com Fri Feb 12 09:00:09 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Fri, 12 Feb 2016 08:00:09 +0000 Subject: [Development] API/ABI changes report In-Reply-To: References: <2945201454679259@web22o.yandex.ru> <2274263.zrLsn6XqlA@tjmaciei-mobl4> <1603831455198412@web30o.yandex.ru> <1717011.eDQn0EExJk@tjmaciei-mobl4> Message-ID: On 12/02/16 08:50, "Development on behalf of Sune Vuorela" wrote: >On 2016-02-11, Thiago Macieira wrote: >>> There are several remaining issues in the report. So I have some questions: >>> >>> - Is class QPlatformScreen private and all related changes should be removed >>> from the report? >>> (http://abi-laboratory.pro/tracker/compat_report/qt/5.5.1/5.6.0-beta/8f965/ >>> abi_compat_report.html) >> >> Yes, that's a private class (QPlatform* is QPA, like QWindowSystem*). > >It is a public private class. I'm not sure it is fully correct to hide >it. I'm also not sure it is fully correct to keep it. > >Many parts of the QPA bits are unfortunately widely used. We should >really work towards making it public ... There are very good reasons we’re not promising compatibility on these parts. So far we have been doing incompatible changes in these APIs with almost every minor version of Qt. Keeping BC here would have made our QPA implementation impossible (or at least a *lot* harder) to maintain by now. These APIs should really only be used by a very limited set of plugins to Qt, not by general apps.If there’s something apps in general require, let’s discuss how a public API for that feature could look like. But we should not go down the road of starting to promise BC for our backend APIs. Cheers, Lars From kde at carewolf.com Fri Feb 12 10:25:26 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 12 Feb 2016 10:25:26 +0100 Subject: [Development] API/ABI changes report In-Reply-To: <2945201454679259@web22o.yandex.ru> References: <2945201454679259@web22o.yandex.ru> Message-ID: <201602121025.26248.kde@carewolf.com> On Friday 05 February 2016, Ponomarenko Andrey wrote: > Hello, > > I've started to maintain API/ABI changes report for the Qt library here: > http://abi-laboratory.pro/tracker/timeline/qt/ > > It took about two weeks to build and perform analysis for ~50 versions of > the library from 4.0 up to 5.6.0-beta and finally I can share the report > with the community. Hope the report will help Linux maintainers of the > library to be aware of ABI structure changes and added/removed binary > symbols. > > I understand that the report contains several false positives and > definitely some false negatives. Also it says nothing about behavioral ABI > changes. But it still can be used as a first approximation. > > Please let me know if some information in the report is incorrect/missed or > you see some obvious false positives/negatives. I'll try to improve basic > analysis tools. > Well QtWebEngine is missing. Of course that is only relevant for the latest versions, but an full ABI check would still be very appreciated. `Allan From jani.heikkinen at theqtcompany.com Fri Feb 12 13:49:37 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Fri, 12 Feb 2016 12:49:37 +0000 Subject: [Development] New Qt 5.6.0 RC snapshot available, please test Message-ID: Hi all, We have finally packages for testing, Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/335/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/331/ Mac:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/271/ src:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/latest_src Unfortunately these packages are from a bit old qt5.git integration (https://codereview.qt-project.org/#/c/147715/) so latest changes from '5.6.0' (https://codereview.qt-project.org/#/c/148570/) are missing from the packages, sorry about that! We are trying to release RC as soon as possible so it is really important to test these packages now to see if there is still something to be fixed before we can release the RC. Current RC blockers are here: https://bugreports.qt.io/issues/?filter=17225 .Please make sure all blocker are visible here (but remember, just a real blockers anymore!). And please start creating changelogs for final release now if not already started. br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From gcharbonnier at simplisim.net Fri Feb 12 14:57:04 2016 From: gcharbonnier at simplisim.net (Guillaume Charbonnier) Date: Fri, 12 Feb 2016 14:57:04 +0100 Subject: [Development] Request for a new playground project References: Message-ID: <3FBFE087-BC29-407D-B6F7-35FF40633A1E@simplisim.net> Hi all, Following engin.io services ramping down notification, Qt mobile developers (like me) are lacking a MBaaS (mobile backend as a service) that would play nicely with Qt. I think this lack could be quite a big impedance for the promotion of Qt for mobile development as most mobile applications use the basic features a MBaaS offer... I would like to start a playground project (with the help of everyone interested in that topic) to offer a set of Qt classes and QML elements to manage the following services : • authentification and authorization (with social login) • datastore (nosql) • push notifications • statistics I think it would be great to design this new module to be backend agnostic. Thus supporting several backend providers such as : - google Firebase - BaasBox - IBM Cloudant - Apigee I have never participate in Qt project so I am an absolute beginner in this field. I have read the development topics in the wiki despite some of them state to be outdated - any advice and recommandation will be greatly appreciated. Here is a link to the corresponding forum topic : https://forum.qt.io/topic/63777/looking-for-engin-io-replacement-joining-our-effort-initiative To conclude, I think it would be helpful to create a playground project for this project, hence my request : Description : Qt Mobile Backed as a Service Playground project name : MBaaS Best regards. Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: From ekke at ekkes-corner.org Fri Feb 12 15:49:11 2016 From: ekke at ekkes-corner.org (ekke) Date: Fri, 12 Feb 2016 15:49:11 +0100 Subject: [Development] Request for a new playground project In-Reply-To: <3FBFE087-BC29-407D-B6F7-35FF40633A1E@simplisim.net> References: <3FBFE087-BC29-407D-B6F7-35FF40633A1E@simplisim.net> Message-ID: <56BDF0E7.8040905@ekkes-corner.org> +1 this sounds great - I'm also looking for BaaS with Qt Mobile development Am 12.02.16 um 14:57 schrieb Guillaume Charbonnier: > Hi all, > > Following engin.io services ramping down > notification, Qt mobile developers (like me) are lacking a MBaaS > (mobile backend as a service) that would play nicely with Qt. > I think this lack could be quite a big impedance for the promotion of > Qt for mobile development as most mobile applications use the basic > features a MBaaS offer... > > I would like to start a playground project (with the help of everyone > interested in that topic) to offer a set of Qt classes and QML > elements to manage the following services : > • authentification and authorization (with social login) > • datastore (nosql) > • push notifications > • statistics > > I think it would be great to design this new module to be backend > agnostic. Thus supporting several backend providers such as : > - google Firebase > - BaasBox > - IBM Cloudant > - Apigee > > I have never participate in Qt project so I am an absolute beginner in > this field. > I have read the development topics in the wiki despite some of them > state to be outdated - any advice and recommandation will be > greatly appreciated. > Here is a link to the corresponding forum topic > : https://forum.qt.io/topic/63777/looking-for-engin-io-replacement-joining-our-effort-initiative > > To conclude, I think it would be helpful to create a playground > project for this project, hence my request : > _Description_ : Qt Mobile Backed as a Service > _Playground project name_ : MBaaS > > Best regards. > Guillaume > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- ekke (ekkehard gentz) independent software architect international development native mobile business apps BlackBerry 10 | Qt Mobile (Android, iOS) workshops - trainings - bootcamps *BlackBerry Elite Developer BlackBerry Platinum Enterprise Partner* max-josefs-platz 30, D-83022 rosenheim, germany mailto:ekke at ekkes-corner.org blog: http://ekkes-corner.org apps and more: http://appbus.org twitter: @ekkescorner skype: ekkes-corner LinkedIn: http://linkedin.com/in/ekkehard/ Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bm_witness at yahoo.com Fri Feb 12 16:17:21 2016 From: bm_witness at yahoo.com (BRM) Date: Fri, 12 Feb 2016 15:17:21 +0000 (UTC) Subject: [Development] Request for a new playground project In-Reply-To: <56BDF0E7.8040905@ekkes-corner.org> References: <56BDF0E7.8040905@ekkes-corner.org> Message-ID: <2124100696.3275937.1455290241301.JavaMail.yahoo@mail.yahoo.com> Sounds great as well...while I'd like something for Mobile, I also need something accessible for non-Mobile so the two can easily integrate.(E.g mobile applications and desktop applications integrating for a shared experience). $0.02 Ben On Friday, February 12, 2016 10:10 AM, ekke wrote: +1 this sounds great - I'm also looking for BaaS with Qt Mobile development Am 12.02.16 um 14:57 schrieb Guillaume Charbonnier: Hi all, Following engin.io services ramping down notification, Qt mobile developers (like me) are lacking a MBaaS (mobile backend as a service) that would play nicely with Qt.  I think this lack could be quite a big impedance for the promotion of Qt for mobile development as most mobile applications use the basic features a MBaaS offer... I would like to start a playground project (with the help of everyone interested in that topic) to offer a set of Qt classes and QML elements to manage the following services : • authentification and authorization (with social login) • datastore (nosql) • push notifications • statistics I think it would be great to design this new module to be backend agnostic. Thus supporting several backend providers such as : - google Firebase - BaasBox - IBM Cloudant - Apigee I have never participate in Qt project so I am an absolute beginner in this field.  I have read the development topics in the wiki despite some of them state to be outdated - any advice and recommandation will be greatly appreciated. Here is a link to the corresponding forum topic : https://forum.qt.io/topic/63777/looking-for-engin-io-replacement-joining-our-effort-initiative To conclude, I think it would be helpful to create a playground project for this project, hence my request : Description : Qt Mobile Backed as a Service Playground project name : MBaaS Best regards. Guillaume _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- ekke (ekkehard gentz) independent software architect international development native mobile business apps BlackBerry 10 | Qt Mobile (Android, iOS) workshops - trainings - bootcamps BlackBerry Elite Developer BlackBerry Platinum Enterprise Partner max-josefs-platz 30, D-83022 rosenheim, germany mailto:ekke at ekkes-corner.org blog: http://ekkes-corner.org apps and more: http://appbus.org twitter: @ekkescorner skype: ekkes-corner LinkedIn: http://linkedin.com/in/ekkehard/ Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490 _______________________________________________ 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 tuukka.turunen at theqtcompany.com Fri Feb 12 16:51:14 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Fri, 12 Feb 2016 15:51:14 +0000 Subject: [Development] Qt 5.7 new features: MAINTAINERS, your input needed! In-Reply-To: References: Message-ID: Hi, Looking at http://wiki.qt.io/New_Features_in_Qt_5.7 there is already a lot of content, but nothing is listed under the following modules: * Qt Core * Qt GUI * Qt Network * Qt Widgets * Qt Test * Qt WebView * Qt Multimedia * Qt Positioning * Qt Location For some of these it may be that there really is nothing so big that it should be mentioned in the list of most important new features, but in some of these there certainly are items to mention. We are soon approaching Qt 5.7 Alpha by which time we should be able to communicate to the users what is new and exciting in Qt 5.7. Maintainers, please update the list for your modules or in case there is nothing important, delete your module from the list. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Heikkinen Jani Sent: maanantaina 8. helmikuuta 2016 14.56 To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] Qt 5.7 new features: MAINTAINERS, your input needed! Importance: High Hi all, Feature Freeze has been in effect a week but new features page(https://wiki.qt.io/New_Features_in_Qt_5.7) needs still some updates. Maintainers: please add missing items there as soon as possible, it would be really good to have this "ready" before Alpha release br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Fri Feb 12 18:45:05 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 12 Feb 2016 18:45:05 +0100 Subject: [Development] Qt 5.7 new features: MAINTAINERS, your input needed! In-Reply-To: References: Message-ID: <201602121845.06019.marc.mutz@kdab.com> On Friday 12 February 2016 16:51:14 Turunen Tuukka wrote: > Maintainers, please update the list for your modules or in case there is > nothing important, delete your module from the list. Is there any particular reason this needs to be hand-edited instead of being automatically generated from [ChangeLog] commits? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From ariel at edis.mx Fri Feb 12 17:52:34 2016 From: ariel at edis.mx (Ariel Molina) Date: Fri, 12 Feb 2016 10:52:34 -0600 Subject: [Development] Extending touch semantic information and Qt backends In-Reply-To: References: <56BC63E6.6080307@rusbitech.ru> Message-ID: Further investigating i just read: https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt Which is a good read about the status of multitouch in the Kernel, moreover it explains the type of objects to be reported which are divided non identifiable and identifiable objects. Moreover it explains about blobs, it's touching ellipse and orientation (rotation) and even goes as far as talking about hover events. Ariel On Thu, Feb 11, 2016 at 12:33 PM, Ariel Molina wrote: > Edward, > > I strongly agree with your analysis. Any generalized touch (marker, > finger, pen) has a general elliptic shape defined by a rectangle, when a > device does not support that info, touches are just degenerate squares 0 by > 0 and zero area. But richer devices might provide blob rect and blob angle, > blob unique ID *and* the type of blob: Touch, PenTouch, Blob either > uniquely identified or not (and the source of them if we can dream that > far). > > Thinking like this we can easily support Normal Fingertouches (non > universally identified Touch with only temporary ID, -null blob area, zero > angle or pressure if not supported-), Makers can be blobs with an ID, area > and angle; palms, hands, a cup of coffee and others are just unidentified > blobs on devices that can recognize them (SUR40?, current optical trackers > and future new devices). > > Please correct me, but I see this as paving future support for those > recent haptic devices such as Apple Pen, Wacoms (and Im sure Google has > something in the works for Android). > > Ariel > > > > On Thu, Feb 11, 2016 at 8:05 AM, Welbourne Edward < > edward.welbourne at theqtcompany.com> wrote: > >> Very much a digression but ... >> >> > TUIO models the touchpoint as a rotated ellipse though, right? [snip >> > URL] And I think that’s nice, for finger touchpoints at least >> > (although markers could be any shape). It can be assumed to be the >> > ellipse inscribed in a rect >> >> Traditional graphics always thinks in terms of *coordinate-aligned* >> rectangles, characterised by a width and height with respect to a single >> fixed coordinate system. This works fine for the classical (vertical >> rectangular) screen and even for most modern tablets, where "rotation" >> may be supported but only in multiples of a quarter turn. However, once >> you get to the kind of "touch surface as table" that the reactable video >> illustrated - a horizontal round table, no less - there ceases being any >> naturality to any one choice of coordinate alignment. It's then >> necessary to support all orientations equally well, without privileging >> one of them. >> >> In such a context, either an ellipse or a rectangle can be reduced to a >> centre-point, a semi-major axial vector (orienting it) and a semi-minor >> axis length (at right angles). Naturally, we can equivalently scale the >> axes by two to drop the semi-s. There's then an obvious correspondence >> between a rectangle and an ellipse via matching characterisation in >> these terms. Which you think of that set of parameters as representing >> is then somewhat arbitrary. The area of contact between a finger and a >> flat surface is closer to elliptical than to rectangular; but there's a >> stronger reason to prefer an ellipse. >> >> Now, I know nothing of the implementation details of touch screens: but >> have to guess that the actual raw data of an object pressing on a screen >> is a noisy mess of pressure signals from nearby sensors. The natural >> way to process that noisy mess shall be statistically and the natural >> statistical trickery to use for it is going to give you a mean (vector) >> and variance (matrix). The former is your centre-point; the latter is >> (necessarily, from how it'll be computed from raw data) a symmetric >> positive-definite quadratic form, a.k.a. a metric, which shall be >> diagonalised by some specific choice of coordinates - characterised by >> two perpendicular vectors, one of which we get to construe as semi-major >> axial vector, with the other telling us the semi-minor axis length. All >> of this would still be true for markers of stranger shapes, thanks to >> the noisy mess of physcal sensor data. So I'm not surprised to hear >> that a touchpoint ends up represented by these three data - centre, >> major axial vector, minor axis length - or some geometrical entity >> equivalent to them. >> >> While these data can indeed be understood equally as characterising a >> rectangle or an ellipse, coming via a metric makes the ellipse (the >> "unit circle" of the distance associated with the metric) the more >> natural form. When major and minor axes are close to equal in length, >> the ellipse strongly de-emphasises its incidental orientation, becoming >> completely orientation-agnostic when we get to major = minor, the >> circle. In contrast, a rectangle retains its sense of orientation all >> the way to that degenerate case, where the square still has a definite >> orientation, albeit modulo quarter turns. >> >> We need an orientation in our representation, to support the case where >> the axial lengths are significantly different, but we need to think of >> that orientation as only relevant in so far as the axial lengths *are* >> significantly different. Data derived from a metric in the form of >> centre, major axial vector and minor axial size are thus more naturally >> thought of as describing an ellipse. >> >> So let me encourage you to think in terms of ellipses in this modern >> era, as the more natural reading of "centre, major axial vector, minor >> axial size" data, rather than in terms of the rectangles you grew up >> with - they are an artefact of upright rectangular screens. The tactile >> UI folk rightly prefer a well-rounded future, >> >> Eddy. >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > > > -- > Ariel Molina R. > > http://edis.mx > -- Ariel Molina R. http://edis.mx -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at theqtcompany.com Fri Feb 12 17:58:13 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Fri, 12 Feb 2016 17:58:13 +0100 Subject: [Development] HEADS UP: Qt 5.7 branching ongoing Message-ID: <20160212165813.GB20706@troll08.it.local> with some rather significant delay, the 5.7 branch is now available. please start using it for new changes intented for the Qt 5.7 release. we will downmerge dev to 5.7 the last time in a few days - i don't know any particular date, but it may be *quite* soon, as we're running late. it's recommended that you send retargeting requests for pending changes on dev meant for 5.7 to me immediately. if the changes still integrate on dev before monday, that's fine. From erik at ortogonal.com Fri Feb 12 19:17:17 2016 From: erik at ortogonal.com (Erik Larsson) Date: Fri, 12 Feb 2016 19:17:17 +0100 Subject: [Development] Request for a new playground project In-Reply-To: <3FBFE087-BC29-407D-B6F7-35FF40633A1E@simplisim.net> References: <3FBFE087-BC29-407D-B6F7-35FF40633A1E@simplisim.net> Message-ID: +1 fredag 12 februari 2016 skrev Guillaume Charbonnier < gcharbonnier at simplisim.net>: > Hi all, > > Following engin.io services ramping down notification, Qt mobile > developers (like me) are lacking a MBaaS (mobile backend as a service) > that would play nicely with Qt. > I think this lack could be quite a big impedance for the promotion of Qt > for mobile development as most mobile applications use the basic features a > MBaaS offer... > > I would like to start a playground project (with the help of everyone > interested in that topic) to offer a set of Qt classes and QML elements > to manage the following services : > • authentification and authorization (with social login) > • datastore (nosql) > • push notifications > • statistics > > I think it would be great to design this new module to be backend > agnostic. Thus supporting several backend providers such as : > - google Firebase > - BaasBox > - IBM Cloudant > - Apigee > > I have never participate in Qt project so I am an absolute beginner in > this field. > I have read the development topics in the wiki despite some of them state > to be outdated - any advice and recommandation will be greatly appreciated. > Here is a link to the corresponding forum topic : > https://forum.qt.io/topic/63777/looking-for-engin-io-replacement-joining-our-effort-initiative > > To conclude, I think it would be helpful to create a playground project > for this project, hence my request : > *Description* : Qt Mobile Backed as a Service > *Playground project name* : MBaaS > > Best regards. > Guillaume > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From krnekit at gmail.com Sat Feb 13 02:24:34 2016 From: krnekit at gmail.com (Nikita Krupenko) Date: Sat, 13 Feb 2016 03:24:34 +0200 Subject: [Development] Documentation for methods of QML basic type Message-ID: Hi all! I'm working on adding methods to basic QML type (color) and I need to document it. What qdoc tags should I use for this methods to be included into doc? I tried to use "\qmlmethod" but it does not work (or I do something wrong). I have suspicion, that qdoc does not support documenting methods of QML basic type. Is it even possible to document methods not only for "\qmlclass" but for "\qmlbasictype" too? I have not found any examples of such use case in Qt sources. From Martin.Smith at theqtcompany.com Sat Feb 13 06:21:12 2016 From: Martin.Smith at theqtcompany.com (Smith Martin) Date: Sat, 13 Feb 2016 05:21:12 +0000 Subject: [Development] Documentation for methods of QML basic type In-Reply-To: References: Message-ID: qdoc doesn't support it yet, because it wasn't done before. I will add it. martin ________________________________________ From: Development on behalf of Nikita Krupenko Sent: Saturday, February 13, 2016 2:24 AM To: development at qt-project.org Subject: [Development] Documentation for methods of QML basic type Hi all! I'm working on adding methods to basic QML type (color) and I need to document it. What qdoc tags should I use for this methods to be included into doc? I tried to use "\qmlmethod" but it does not work (or I do something wrong). I have suspicion, that qdoc does not support documenting methods of QML basic type. Is it even possible to document methods not only for "\qmlclass" but for "\qmlbasictype" too? I have not found any examples of such use case in Qt sources. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From tuukka.turunen at theqtcompany.com Sat Feb 13 08:12:24 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Sat, 13 Feb 2016 07:12:24 +0000 Subject: [Development] Qt 5.7 new features: MAINTAINERS, your input needed! In-Reply-To: <201602121845.06019.marc.mutz@kdab.com> References: , <201602121845.06019.marc.mutz@kdab.com> Message-ID: <59E7620E-C1A3-4D39-B7C9-675226FA58EE@theqtcompany.com> Hi, Idea is the same as with earlier releases, i.e. to mention only the most important features from user's viewpoint. Automatically generated list of all commits typically does not work even for the full change log, because it contains also unnecessary items. For the high level feature list it is often a large number of commits that together build a new feature. Please check the earlier releases' wiki entries to see what we are targeting to have. Yours, -- Tuukka > Marc Mutz kirjoitti 12.2.2016 kello 18.35: > >> On Friday 12 February 2016 16:51:14 Turunen Tuukka wrote: >> Maintainers, please update the list for your modules or in case there is >> nothing important, delete your module from the list. > > Is there any particular reason this needs to be hand-edited instead of being > automatically generated from [ChangeLog] commits? > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts From kde at carewolf.com Sat Feb 13 12:22:35 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sat, 13 Feb 2016 12:22:35 +0100 Subject: [Development] Qt 5.7 new features: MAINTAINERS, your input needed! In-Reply-To: <59E7620E-C1A3-4D39-B7C9-675226FA58EE@theqtcompany.com> References: <201602121845.06019.marc.mutz@kdab.com> <59E7620E-C1A3-4D39-B7C9-675226FA58EE@theqtcompany.com> Message-ID: <201602131222.35616.kde@carewolf.com> On Saturday 13 February 2016, Turunen Tuukka wrote: > Hi, > > Idea is the same as with earlier releases, i.e. to mention only the most > important features from user's viewpoint. Automatically generated list of > all commits typically does not work even for the full change log, because > it contains also unnecessary items. For the high level feature list it is > often a large number of commits that together build a new feature. > But maybe we could still have the full automatically generated changelog posted somewhere. It is better than nothing, and could be used by non- maintainers to fill out the hand-edited changelog. Best reagards `Allan From denis.shienkov at gmail.com Sat Feb 13 12:24:38 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Sat, 13 Feb 2016 14:24:38 +0300 Subject: [Development] [Proposal] Future QtSerialPort with plugins architecture Message-ID: <56BF1276.5070100@gmail.com> Hi, folks, I would like to discuss new idea of transition of QtSerialPort to an architecture with the plug-ins/backends. The reason is that we can use different approaches on different platforms to enumerating a list of available devices, and to implementing a code of I/O engine. It will simplify a code and its maintenance for developers, and also will provide flexibility for users. = QSerialPortInfo = For example QSerialPortInfo::availablePorts() can be made with, different ways, which I suggest to divide into plug-ins/backends: * on Windows : [setupapi], wmi, generic * on WinCE : [devmgr] * on Linux : [udev], sysfs, generic * on OSX : [iokit], generic * on FreeBSD : [sysctl], generic * on QNX : [generic?] * other Unix : [generic] where [...] means that this plugin is preferred/default for this platform. The user can use/change desired plugin, e.g. via the QT_SERIALPORTINFO_PLUGIN environment, or via command line e.g.: {code} set QT_SERIALPORTINFO_PLUGIN=wmi // on windows myapp.exe {code} {code} export QT_SERIALPORTINFO_PLUGIN=sysfs // on linux myapp {code} {code} myapp -qspi sysfs // on linux {code} and so on, similar to the Qt's platform backends, like this: * http://doc.qt.io/qt-5/embedded-linux.html Currently we have mess-up (mixing-up) multiple approaches in one implementation file, via ifdefs and so on, that is looks funny/hard, e.g,: * on Windows : setupapi + generic * on Unix : udev + sysfs + generic = QSerialPort = Here also can be divided to the plugins/backends. E.g. some vendors provides own HW chips which is RS232/485/TTL on the physical layer, but has own vendor-specific API. An example it is FTDI chip with the D2XX API, that is non-standard "serial port" API. In this case the user can choose desired plugins via other QT_SERIALPOR_PLUGIN environment, or via other command line, e.g.: {code} set QT_SERIALPORTINFO_PLUGIN=ftdi set QT_SERIALPOR_PLUGIN=ftdi myapp.exe {code} {code} myapp.exe -qspi ftdi -qsp ftdi {code} Currently, I don't like the current implementation of internal architecture of QtSserialPort where the code contains mix from different approaches and so on, that is hard and ugly, IMHO. So, dear community/developers/gurus, what do you think about? :) BR, Denis From denis.shienkov at gmail.com Sun Feb 14 12:42:46 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Sun, 14 Feb 2016 14:42:46 +0300 Subject: [Development] [Proposal] Future QtSerialPort with plugins architecture In-Reply-To: References: <56BF1276.5070100@gmail.com> Message-ID: <56C06836.1070700@gmail.com> Chris, > Indeed it would be nice to have an extended API for controlling vendor specific extension in a uniform way. Switching between RS232/422/485 is a pretty common feature (including switching b/w full/half duplex, (des)activating termination resistor), as is controlling a few extra GPIO. At the moment, the QSerialPort provides the handle() method for these purposes. Where the user can do a specific ioctl's on a device handle. I think, it is enough. > Concerning the plugin idea, did you check how QSerialBus is achieving the discovery and the handling of vendor specifics? Yes, of course, I have looked how it is doing in QtSerialBus. But, there is used a few others ideas... Besides there still is no any QxxInfo classes to take it as template for QSerialPortInfo... A near template - it is something like QCameraInfo implementation of QtMultimedia, IMHO. BR, Denis 14.02.2016 2:33, Ch'Gans пишет: > Hi Denis, > > Indeed it would be nice to have an extended API for controlling vendor > specific extension in a uniform way. > Switching between RS232/422/485 is a pretty common feature (including > switching b/w full/half duplex, (des)activating termination resistor), > as is controlling a few extra GPIO. These features are not FTDI > specific. > In the past where I made the HW myself, I had the possibility to query > for HW errors too, some TTL/RS level converters offer this feature. > There's as well the possibility to control somehow slew rate > limitation (typ. fast/slow). > > Maybe the Serial Port API could be enhanced with "capability" queries > and associated control functions. > Or maybe all of these should be implemented on top of QSP. > > Concerning the plugin idea, did you check how QSerialBus is achieving > the discovery and the handling of vendor specifics? > > Chris > > On 14 February 2016 at 00:24, Denis Shienkov wrote: >> Hi, folks, >> >> I would like to discuss new idea of transition of QtSerialPort to >> an architecture with the plug-ins/backends. >> >> The reason is that we can use different approaches on different >> platforms to enumerating a list of available devices, and to >> implementing a code of I/O engine. >> >> It will simplify a code and its maintenance for developers, >> and also will provide flexibility for users. >> >> = QSerialPortInfo = >> >> For example QSerialPortInfo::availablePorts() can be made with, >> different ways, which I suggest to divide into plug-ins/backends: >> >> * on Windows : [setupapi], wmi, generic >> * on WinCE : [devmgr] >> * on Linux : [udev], sysfs, generic >> * on OSX : [iokit], generic >> * on FreeBSD : [sysctl], generic >> * on QNX : [generic?] >> * other Unix : [generic] >> >> where [...] means that this plugin is preferred/default for this platform. >> >> The user can use/change desired plugin, e.g. via the >> QT_SERIALPORTINFO_PLUGIN environment, or via command line e.g.: >> >> {code} >> set QT_SERIALPORTINFO_PLUGIN=wmi // on windows >> myapp.exe >> {code} >> >> {code} >> export QT_SERIALPORTINFO_PLUGIN=sysfs // on linux >> myapp >> {code} >> >> {code} >> myapp -qspi sysfs // on linux >> {code} >> >> and so on, similar to the Qt's platform backends, like this: >> >> * http://doc.qt.io/qt-5/embedded-linux.html >> >> Currently we have mess-up (mixing-up) multiple approaches in one >> implementation file, via ifdefs and so on, that is looks funny/hard, e.g,: >> >> * on Windows : setupapi + generic >> * on Unix : udev + sysfs + generic >> >> = QSerialPort = >> >> Here also can be divided to the plugins/backends. E.g. some vendors >> provides own HW chips which is RS232/485/TTL on the physical layer, >> but has own vendor-specific API. An example it is FTDI chip with the >> D2XX API, that is non-standard "serial port" API. >> >> In this case the user can choose desired plugins via other >> QT_SERIALPOR_PLUGIN environment, or via other command line, e.g.: >> >> {code} >> set QT_SERIALPORTINFO_PLUGIN=ftdi >> set QT_SERIALPOR_PLUGIN=ftdi >> myapp.exe >> {code} >> >> {code} >> myapp.exe -qspi ftdi -qsp ftdi >> {code} >> >> Currently, I don't like the current implementation of internal architecture >> of QtSserialPort where the code contains mix from different approaches >> and so on, that is hard and ugly, IMHO. >> >> So, dear community/developers/gurus, what do you think about? :) >> >> BR, >> Denis >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development From gcharbonnier at simplisim.net Sun Feb 14 12:54:43 2016 From: gcharbonnier at simplisim.net (Guillaume Charbonnier) Date: Sun, 14 Feb 2016 12:54:43 +0100 Subject: [Development] Request for a new playground project In-Reply-To: <8F7BB2ED-5A46-4C3C-8110-7E38D124BC3F@simplisim.net> References: <8F7BB2ED-5A46-4C3C-8110-7E38D124BC3F@simplisim.net> Message-ID: Hi all ! Following my last message regarding Qt new module for "Mobile Backend as a Service », what is the procedure to follow for creating a Qt playground project ? My project is in a very early phase, it can only support REST api of Firebase for now but I felt it could help to mutualize our effort if we could have a published playground project. Best regards. Guillaume > Le 12 févr. 2016 à 14:54, Guillaume Charbonnier a écrit : > > Hi all, > > Following engin.io services ramping down notification, Qt mobile developers (like me) are lacking a MBaaS (mobile backend as a service) that would play nicely with Qt. > I think this lack could be quite a big impedance for the promotion of Qt for mobile development as most mobile applications use the basic features a MBaaS offer... > > I would like to start a playground project (with the help of everyone interested in that topic) to offer a set of Qt classes and QML elements to manage the following services : > • authentification and authorization (with social login) > • datastore (nosql) > • push notifications > • statistics > > I think it would be great to design this new module to be backend agnostic. Thus supporting several backend providers such as : > - google Firebase > - BaasBox > - IBM Cloudant > - Apigee > > I have never participate in Qt project so I am an absolute beginner in this field. > I have read the development topics in the wiki despite some of them state to be outdated - any advice and recommandation will be greatly appreciated. > Here is a link to the corresponding forum topic : https://forum.qt.io/topic/63777/looking-for-engin-io-replacement-joining-our-effort-initiative > > To conclude, I think it would be helpful to create a playground project for this project, hence my request : > Description : Qt Mobile Backed as a Service > Playground project name : MBaaS > > Best regards. > Guillaume -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at theqtcompany.com Mon Feb 15 07:30:56 2016 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Mon, 15 Feb 2016 06:30:56 +0000 Subject: [Development] Request for a new playground project In-Reply-To: References: <8F7BB2ED-5A46-4C3C-8110-7E38D124BC3F@simplisim.net> Message-ID: <77E023F7-7B37-4CB1-B83C-EC9583DF4AAA@theqtcompany.com> Drop the "mobile". Qt is a cross platform project and there does not seem to be any technical reason to restrict this to mobile platforms. So, just "Backend as a Service". On Feb 14, 2016, at 3:54 AM, Guillaume Charbonnier > wrote: Hi all ! Following my last message regarding Qt new module for "Mobile Backend as a Service », what is the procedure to follow for creating a Qt playground project ? My project is in a very early phase, it can only support REST api of Firebase for now but I felt it could help to mutualize our effort if we could have a published playground project. Best regards. Guillaume Le 12 févr. 2016 à 14:54, Guillaume Charbonnier > a écrit : Hi all, Following engin.io services ramping down notification, Qt mobile developers (like me) are lacking a MBaaS (mobile backend as a service) that would play nicely with Qt. I think this lack could be quite a big impedance for the promotion of Qt for mobile development as most mobile applications use the basic features a MBaaS offer... I would like to start a playground project (with the help of everyone interested in that topic) to offer a set of Qt classes and QML elements to manage the following services : • authentification and authorization (with social login) • datastore (nosql) • push notifications • statistics I think it would be great to design this new module to be backend agnostic. Thus supporting several backend providers such as : - google Firebase - BaasBox - IBM Cloudant - Apigee I have never participate in Qt project so I am an absolute beginner in this field. I have read the development topics in the wiki despite some of them state to be outdated - any advice and recommandation will be greatly appreciated. Here is a link to the corresponding forum topic : https://forum.qt.io/topic/63777/looking-for-engin-io-replacement-joining-our-effort-initiative To conclude, I think it would be helpful to create a playground project for this project, hence my request : Description : Qt Mobile Backed as a Service Playground project name : MBaaS Best regards. Guillaume _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at theqtcompany.com Mon Feb 15 07:59:30 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Mon, 15 Feb 2016 06:59:30 +0000 Subject: [Development] Qt 5.7 new features: MAINTAINERS, your input needed! In-Reply-To: <201602131222.35616.kde@carewolf.com> References: <201602121845.06019.marc.mutz@kdab.com> <59E7620E-C1A3-4D39-B7C9-675226FA58EE@theqtcompany.com>, <201602131222.35616.kde@carewolf.com> Message-ID: The full list based on changelog is in the dist/changes-5.x.y The aforementioned list is a much much higher level overview. We are talking major feature points. Because we are talking about such high level points it should not be difficult to indentify them when reviewing your personal work history. A change log system would be overkill and is geared towards the above mentioned changes files. -- Alex ________________________________________ From: Development on behalf of Allan Sandfeld Jensen Sent: Saturday, February 13, 2016 12:22 To: development at qt-project.org Cc: releasing at qt-project.org Subject: Re: [Development] Qt 5.7 new features: MAINTAINERS, your input needed! On Saturday 13 February 2016, Turunen Tuukka wrote: > Hi, > > Idea is the same as with earlier releases, i.e. to mention only the most > important features from user's viewpoint. Automatically generated list of > all commits typically does not work even for the full change log, because > it contains also unnecessary items. For the high level feature list it is > often a large number of commits that together build a new feature. > But maybe we could still have the full automatically generated changelog posted somewhere. It is better than nothing, and could be used by non- maintainers to fill out the hand-edited changelog. Best reagards `Allan _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From alexander.blasche at theqtcompany.com Mon Feb 15 08:05:30 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Mon, 15 Feb 2016 07:05:30 +0000 Subject: [Development] [Proposal] Future QtSerialPort with plugins architecture In-Reply-To: <56BF1276.5070100@gmail.com> References: <56BF1276.5070100@gmail.com> Message-ID: > -----Original Message----- > From: Denis Shienkov [mailto:denis.shienkov at gmail.com] > I would like to discuss new idea of transition of QtSerialPort to > an architecture with the plug-ins/backends. > The user can use/change desired plugin, e.g. via the > QT_SERIALPORTINFO_PLUGIN environment, or via command line e.g.: > > {code} > set QT_SERIALPORTINFO_PLUGIN=wmi // on windows > myapp.exe > {code} > > {code} > export QT_SERIALPORTINFO_PLUGIN=sysfs // on linux > myapp > {code} > > {code} > myapp -qspi sysfs // on linux > {code} In principle I have no problem. Maybe you forgot to mention it in your mail but choosing the plugin via env or app parameter is not sufficient. The system must support the concept of a default plugin for the current platform. -- Alex From denis.shienkov at gmail.com Mon Feb 15 10:03:47 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Mon, 15 Feb 2016 12:03:47 +0300 Subject: [Development] [Proposal] Future QtSerialPort with plugins architecture In-Reply-To: References: <56BF1276.5070100@gmail.com> Message-ID: > The system must support the concept of a default plugin for the current platform. Yes, of course. For example, the name of a default plug-in will be defined in DEFINES in the *.pro file at a stage of compilation of the module. > Maybe you forgot to mention it in your mail but choosing the plugin via env or app parameter is not sufficient. It is used only for specifying of other plugin's name, that is other than default plugin. BR, Denis 2016-02-15 10:05 GMT+03:00 Blasche Alexander < alexander.blasche at theqtcompany.com>: > > > > > -----Original Message----- > > From: Denis Shienkov [mailto:denis.shienkov at gmail.com] > > > I would like to discuss new idea of transition of QtSerialPort to > > an architecture with the plug-ins/backends. > > The user can use/change desired plugin, e.g. via the > > QT_SERIALPORTINFO_PLUGIN environment, or via command line e.g.: > > > > {code} > > set QT_SERIALPORTINFO_PLUGIN=wmi // on windows > > myapp.exe > > {code} > > > > {code} > > export QT_SERIALPORTINFO_PLUGIN=sysfs // on linux > > myapp > > {code} > > > > {code} > > myapp -qspi sysfs // on linux > > {code} > > In principle I have no problem. Maybe you forgot to mention it in your > mail but choosing the plugin via env or app parameter is not sufficient. > The system must support the concept of a default plugin for the current > platform. > > -- > Alex > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at theqtcompany.com Mon Feb 15 10:22:22 2016 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Mon, 15 Feb 2016 09:22:22 +0000 Subject: [Development] Request for a new playground project In-Reply-To: <77E023F7-7B37-4CB1-B83C-EC9583DF4AAA@theqtcompany.com> References: <8F7BB2ED-5A46-4C3C-8110-7E38D124BC3F@simplisim.net> <77E023F7-7B37-4CB1-B83C-EC9583DF4AAA@theqtcompany.com> Message-ID: <81D80AA1-AD7F-42F5-A5B8-A5F40948F7F2@digia.com> And then “backend” is awfully vague, could be anything other than application UI. (QPA is a kind of backend, so is ODBC.) Yes it’s a buzzword, but will it sound too dated or even more vague in 10 years? > On 15 Feb 2016, at 07:30, Petroules Jake wrote: > > Drop the "mobile". Qt is a cross platform project and there does not seem to be any technical reason to restrict this to mobile platforms. So, just "Backend as a Service". > >> On Feb 14, 2016, at 3:54 AM, Guillaume Charbonnier wrote: >> >> Hi all ! >> >> Following my last message regarding Qt new module for "Mobile Backend as a Service », what is the procedure to follow for creating a Qt playground project ? >> My project is in a very early phase, it can only support REST api of Firebase for now but I felt it could help to mutualize our effort if we could have a published playground project. >> >> Best regards. >> Guillaume >> >>> Le 12 févr. 2016 à 14:54, Guillaume Charbonnier a écrit : >>> >>> Hi all, >>> >>> Following engin.io services ramping down notification, Qt mobile developers (like me) are lacking a MBaaS (mobile backend as a service) that would play nicely with Qt. >>> I think this lack could be quite a big impedance for the promotion of Qt for mobile development as most mobile applications use the basic features a MBaaS offer... >>> >>> I would like to start a playground project (with the help of everyone interested in that topic) to offer a set of Qt classes and QML elements to manage the following services : >>> • authentification and authorization (with social login) >>> • datastore (nosql) >>> • push notifications >>> • statistics >>> >>> I think it would be great to design this new module to be backend agnostic. Thus supporting several backend providers such as : >>> - google Firebase >>> - BaasBox >>> - IBM Cloudant >>> - Apigee >>> >>> I have never participate in Qt project so I am an absolute beginner in this field. >>> I have read the development topics in the wiki despite some of them state to be outdated - any advice and recommandation will be greatly appreciated. >>> Here is a link to the corresponding forum topic : https://forum.qt.io/topic/63777/looking-for-engin-io-replacement-joining-our-effort-initiative >>> >>> To conclude, I think it would be helpful to create a playground project for this project, hence my request : >>> Description : Qt Mobile Backed as a Service >>> Playground project name : MBaaS >>> >>> Best regards. >>> Guillaume >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Jake Petroules - jake.petroules at theqtcompany.com > Consulting Services Engineer - The Qt Company > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From 83.manish at gmail.com Mon Feb 15 10:29:39 2016 From: 83.manish at gmail.com (manish sharma) Date: Mon, 15 Feb 2016 14:59:39 +0530 Subject: [Development] QAccessibleQuickItem setText Message-ID: I was exploring accessibility options to run some automation and looks like setting text to an item is not implemented in QAccessibleQuickItem which is preventing me from setting text to text items. https://code.woboq.org/qt5/qtdeclarative/src/quick/accessible/qaccessiblequickitem_p.h.html#83 And also it looks like windows plugins does not implement put_accName https://code.woboq.org/qt5/qtbase/src/plugins/platforms/windows/accessible/qwindowsmsaaaccessible.cpp.html#905 Any plans of getting this issue addressed? Or Is there any other way to set text to an quick Item? Thanks, Manish -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at theqtcompany.com Mon Feb 15 12:35:39 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Mon, 15 Feb 2016 12:35:39 +0100 Subject: [Development] [Proposal] Future QtSerialPort with plugins architecture In-Reply-To: <56BF1276.5070100@gmail.com> References: <56BF1276.5070100@gmail.com> Message-ID: <20160215113539.GB28239@troll08.it.local> On Sat, Feb 13, 2016 at 02:24:38PM +0300, Denis Shienkov wrote: > I would like to discuss new idea of transition of QtSerialPort to > an architecture with the plug-ins/backends. > why are you conflating backends and plugins? i see no apparent need to make the backends dynamically switchable, i.e., plugins. if you feel you need to refactor the code to achieve better structural clarity, i'm all for it - but don't over-engineer it just because you can. From pritam.ghanghas at gmail.com Mon Feb 15 12:36:41 2016 From: pritam.ghanghas at gmail.com (pritam.ghanghas at gmail.com) Date: Mon, 15 Feb 2016 17:06:41 +0530 Subject: [Development] some questions about QtGamePad Message-ID: Hi I have looking at QtGamePad for usage in another opensource project QGroundControl. It looks like a great module already, something that will reduce lot of cross platform headache for a lot of people trying to use joysticks with Qt. Awesome work by the authors. Looking at the API it seems it has a very hard assumption on 2 sticks and 18 buttons. It is quite possible that QGrounControl may have to support more than 2 sticks. Its quite common for robotics controller to have more than 2 sticks in the form of other photometers. It would be good if some more lower level cross platforms apis were exposed that allow one to enumerate the sticks and buttons. Something that can give us more raw data to handle such special cases. -- Regards, pritam -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Mon Feb 15 13:22:18 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Mon, 15 Feb 2016 15:22:18 +0300 Subject: [Development] [Proposal] Future QtSerialPort with plugins architecture In-Reply-To: <20160215113539.GB28239@troll08.it.local> References: <56BF1276.5070100@gmail.com> <20160215113539.GB28239@troll08.it.local> Message-ID: > why are you conflating backends and plugins? I don't know why I do it.. ;) > if you feel you need to refactor the code to achieve better structural clarity, i'm all for it - but don't over-engineer it just because you can. yes, I need in "to refactor the code to achieve better structural clarity", but I don't know how I can divide a code. I need help... BR, Denis 2016-02-15 14:35 GMT+03:00 Oswald Buddenhagen < oswald.buddenhagen at theqtcompany.com>: > On Sat, Feb 13, 2016 at 02:24:38PM +0300, Denis Shienkov wrote: > > I would like to discuss new idea of transition of QtSerialPort to > > an architecture with the plug-ins/backends. > > > why are you conflating backends and plugins? i see no apparent need to > make the backends dynamically switchable, i.e., plugins. if you feel you > need to refactor the code to achieve better structural clarity, i'm all > for it - but don't over-engineer it just because you can. > _______________________________________________ > 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 pritam.ghanghas at gmail.com Mon Feb 15 14:08:31 2016 From: pritam.ghanghas at gmail.com (pritam.ghanghas at gmail.com) Date: Mon, 15 Feb 2016 18:38:31 +0530 Subject: [Development] some questions about QtGamePad In-Reply-To: References: Message-ID: I meant potentiometers not photometers in there. On Mon, Feb 15, 2016 at 5:06 PM, pritam.ghanghas at gmail.com < pritam.ghanghas at gmail.com> wrote: > Hi > > I have looking at QtGamePad for usage in another opensource project > QGroundControl. It looks like a great module already, something that will > reduce lot of cross platform headache for a lot of people trying to use > joysticks with Qt. Awesome work by the authors. > > Looking at the API it seems it has a very hard assumption on 2 sticks and > 18 buttons. It is quite possible that QGrounControl may have to support > more than 2 sticks. Its quite common for robotics controller to have more > than 2 sticks in the form of other photometers. It would be good if some > more lower level cross platforms apis were exposed that allow one to > enumerate the sticks and buttons. Something that can give us more raw data > to handle such special cases. > > -- > Regards, > pritam > -- Regards, pritam -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.krus at kdab.com Mon Feb 15 15:08:56 2016 From: mike.krus at kdab.com (Mike Krus) Date: Mon, 15 Feb 2016 14:08:56 +0000 Subject: [Development] some questions about QtGamePad In-Reply-To: References: Message-ID: +1, looking at it from the AppleTV remote perspective, it also needs support for handling device orientation (tilt sensors, etc) Mike > On 15 Feb 2016, at 11:36, pritam.ghanghas at gmail.com wrote: > > Hi > > I have looking at QtGamePad for usage in another opensource project QGroundControl. It looks like a great module already, something that will reduce lot of cross platform headache for a lot of people trying to use joysticks with Qt. Awesome work by the authors. > > Looking at the API it seems it has a very hard assumption on 2 sticks and 18 buttons. It is quite possible that QGrounControl may have to support more than 2 sticks. Its quite common for robotics controller to have more than 2 sticks in the form of other photometers. It would be good if some more lower level cross platforms apis were exposed that allow one to enumerate the sticks and buttons. Something that can give us more raw data to handle such special cases. > > -- > Regards, > pritam > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK +44-1625-809908 Mobile: +44 7833 491941 KDAB - The Qt Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3859 bytes Desc: not available URL: From sh at theharmers.co.uk Mon Feb 15 15:18:57 2016 From: sh at theharmers.co.uk (Sean Harmer) Date: Mon, 15 Feb 2016 14:18:57 +0000 Subject: [Development] some questions about QtGamePad In-Reply-To: References: Message-ID: <56C1DE51.7090403@theharmers.co.uk> Hi, On 15/02/2016 11:36, pritam.ghanghas at gmail.com wrote: > Hi > > I have looking at QtGamePad for usage in another opensource project > QGroundControl. It looks like a great module already, something that > will reduce lot of cross platform headache for a lot of people trying > to use joysticks with Qt. Awesome work by the authors. > > Looking at the API it seems it has a very hard assumption on 2 sticks > and 18 buttons. It is quite possible that QGrounControl may have to > support more than 2 sticks. Its quite common for robotics controller > to have more than 2 sticks in the form of other photometers. It would > be good if some more lower level cross platforms apis were exposed > that allow one to enumerate the sticks and buttons. Something that can > give us more raw data to handle such special cases. We have some API in Qt 3D for this: http://code.qt.io/cgit/qt/qt3d.git/tree/src/input/frontend/qabstractphysicaldevice.h?h=5.7 We can look at making it available to more parts of Qt in the future but at the moment the implementation is tied to Qt 3D's architecture. We've tried this with Playstation 3 six axis controllers as well as SpaceNavigator Pro 3D mice. There is already a commit in that provides this on top of Andy's great QtGamepad efforts. Cheers, Sean > > -- > Regards, > pritam > > > _______________________________________________ > 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 bogdan.vatra at kdab.com Mon Feb 15 15:23:03 2016 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Mon, 15 Feb 2016 16:23:03 +0200 Subject: [Development] some questions about QtGamePad In-Reply-To: References: Message-ID: <1837231.OhosEvFqbl@zmeu> Hi, From a gamepad perspective it's almost complete. Yes I know that there are gamepads out there with more buttons, QtGamepad it's a technical preview, so we can change it. IMHO we just need to add a few more generic buttons/axes and that's it. I also agree with Mike that Qt needs some "generic" input device support, something similar with Android's InputDevice API (http://developer.android.com/reference/android/view/InputDevice.html), but that's another story. Cheers, BogDan. On Monday 15 February 2016 14:08:56 Mike Krus wrote: > +1, looking at it from the AppleTV remote perspective, it also needs support > for handling device orientation (tilt sensors, etc) > > > Mike > > > On 15 Feb 2016, at 11:36, pritam.ghanghas at gmail.com wrote: > > > > Hi > > > > I have looking at QtGamePad for usage in another opensource project > > QGroundControl. It looks like a great module already, something that will > > reduce lot of cross platform headache for a lot of people trying to use > > joysticks with Qt. Awesome work by the authors. > > > > Looking at the API it seems it has a very hard assumption on 2 sticks and > > 18 buttons. It is quite possible that QGrounControl may have to support > > more than 2 sticks. Its quite common for robotics controller to have more > > than 2 sticks in the form of other photometers. It would be good if some > > more lower level cross platforms apis were exposed that allow one to > > enumerate the sticks and buttons. Something that can give us more raw > > data to handle such special cases. > -- > Mike Krus | mike.krus at kdab.com | Senior Software Engineer > KDAB (UK) Ltd., a KDAB Group company > Tel: UK +44-1625-809908 Mobile: +44 7833 491941 > KDAB - The Qt Experts From mwoehlke.floss at gmail.com Mon Feb 15 19:04:04 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 15 Feb 2016 13:04:04 -0500 Subject: [Development] some questions about QtGamePad In-Reply-To: References: Message-ID: On 2016-02-15 06:36, pritam.ghanghas at gmail.com wrote: > Looking at the API it seems it has a very hard assumption on 2 sticks and > 18 buttons. Please support arbitrary axes and buttons, as done in e.g. SDL. Hard-coding this stuff is a terrible idea, as even devices with similar physical configurations may number their inputs differently. (Hard-coding the *nature* of the buttons, e.g. "home", "guide" is *also* a terrible design; not all controllers have anything like these.) Three controllers I have offhand have the following attributes: - 4 axes, 12 buttons, 1 hat - 5 axes, 8/9¹ buttons, 1 hat - 6 axes², 11 buttons, 1 hat These are, respectively, a Logitech WingMan Rumble Pad, Logitech Extreme 3D Pro, and standard XBox 360 controller. (I do note that you're at least treating the analog triggers as axes and not buttons.) Note that the second in particular has *one* stick with *three* axes (plus a throttle control). How do you even handle hats??? Then there are e.g. standard Wii controllers which have, I think, 6/7² axes (*none* of which are sticks), 6/7² buttons, and 1 hat. The nunchuck has at *8* (or 9²) axis, 1/2² buttons, and no hat. Please, *please* take the SDL approach and just support axes, buttons and hats (all in arbitrary number) without trying to assign any particular meaning to any of the above. (And keep in mind that axes can be self-centering, i.e. sticks, triggers, acceleromaters, or not, i.e. throttles, gyroscopes.) This way you support just about any device, including a degree of future-proofing. (¹ I think one of the buttons may be treated specially by the hardware and not generally "visible". I don't have the pad with me to check, though.) (² I don't have a Wii controller to test, and I'm not sure if the trigger is analog (axis) or digital (button).) -- Matthew From cavendish.qi at gmail.com Mon Feb 15 19:13:57 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Mon, 15 Feb 2016 19:13:57 +0100 Subject: [Development] Closing the 5.5 branch In-Reply-To: <2672846.XtEjAFYt09@frederik-thinkcentre-m93p> References: <2672846.XtEjAFYt09@frederik-thinkcentre-m93p> Message-ID: https://codereview.qt-project.org/146557 still need to be integrated. On 8 February 2016 at 14:03, Frederik Gladhorn < frederik.gladhorn at theqtcompany.com> wrote: > Hi all, > > due to the strain that we put on the VMs that are supposed to get the > releases > out and do the testing, we decided to "shut down" the CI for Qt 5.5 > branches. > This means literally that we shut down the VMs but we'll keep them around > in > case we ever need to make a 5.5 release. > The goal is to free capacity to let us finally get 5.6 and just after 5.7 > out > of the door. > > Cheers, > Frederik > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- http://www.qiliang.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Mon Feb 15 19:32:38 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 15 Feb 2016 13:32:38 -0500 Subject: [Development] some questions about QtGamePad In-Reply-To: References: Message-ID: On 2016-02-15 13:04, Matthew Woehlke wrote: > On 2016-02-15 06:36, pritam.ghanghas at gmail.com wrote: >> Looking at the API it seems it has a very hard assumption on 2 sticks and >> 18 buttons. > > Please support arbitrary axes and buttons, as done in e.g. SDL. I wrote a joystick API in Qt a while back. It had three signals (I didn't get around to hat support): buttonPressed(int button); buttonReleased(int button); motion(QHash axisPosition); The first two are obvious. The third (you'd probably want to use a different name) is emitted every time any axis value changes, and reports the current value of *all* axes. (This is an optimization / implementation detail; you could as easily have a signal per axis, or indeed do both.) Although I didn't need to have current-state accessors (consider if you really need these), they'd be easy enough to add. Hat support would probably look like: hatMoved(int hat, HatDirection direction); Looking at QGamepadManager, I notice that you treat the hat as a set of buttons. That doesn't strike me as a good idea. Buttons are normally orthogonal (that is, given any two buttons, both might be pressed at the same time). While it's true that you can be lazy and report hats that way, there are problems doing so. First, it precludes users mapping an entire hat to a single digital 2-axis control (or at least makes it much more difficult). Second, hat directions are *not* orthogonal; a hat is more of a digital version of an axis-pair, i.e. two values that are either {-1, 0, +1}. This isn't just a matter of how you can mash on the controller, it's also a question of what the hardware protocol is capable of reporting. -- Matthew From Andy.Nichols at theqtcompany.com Mon Feb 15 20:46:13 2016 From: Andy.Nichols at theqtcompany.com (Nichols Andy) Date: Mon, 15 Feb 2016 19:46:13 +0000 Subject: [Development] some questions about QtGamePad In-Reply-To: References: , Message-ID: Hi Matthew, Pritam, et alia QtGamepad is intentionally limited to gamepads, and does not include support for joysticks, or generic devices with an arbitrary number of axes/buttons. The design was primarily inspired by the HTML 5 gamepad API: https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API/Using_the_Gamepad_API Gamepads have roughly the same Button/Axes configurations and you can see this in the definitions of these similar API's: Apple platforms native Game Controller API's: https://developer.apple.com/library/ios/documentation/ServicesDiscovery/Conceptual/GameControllerPG/Introduction/Introduction.html Android Game Contorllers: http://developer.android.com/training/game-controllers/controller-input.html#button And even the specialized SDL2 GameController module (which yes, does use the joystick API behind the scenes, but demonstrates the importance of the Gamepad specialization): https://wiki.libsdl.org/CategoryGameController So I do not support expanding the scope of QtGamepad in the way you propose, as I think if it belongs anywhere it is in a generic input API (or you can always still just wrap SDL's input module pretty easily). There are however some API's missing that a gamepads API might actually need about like accelerometer based motion controls as well as haptic feedback, so during the tech preview phase this feedback and input is important, but I would like to reiterate the scope of this particular module before the discussion get too far off on a tangent (as it tends to do on this mailing list). Regards, Andy Nichols ________________________________________ From: Development on behalf of Matthew Woehlke Sent: Monday, February 15, 2016 7:32 PM To: development at qt-project.org Subject: Re: [Development] some questions about QtGamePad On 2016-02-15 13:04, Matthew Woehlke wrote: > On 2016-02-15 06:36, pritam.ghanghas at gmail.com wrote: >> Looking at the API it seems it has a very hard assumption on 2 sticks and >> 18 buttons. > > Please support arbitrary axes and buttons, as done in e.g. SDL. I wrote a joystick API in Qt a while back. It had three signals (I didn't get around to hat support): buttonPressed(int button); buttonReleased(int button); motion(QHash axisPosition); The first two are obvious. The third (you'd probably want to use a different name) is emitted every time any axis value changes, and reports the current value of *all* axes. (This is an optimization / implementation detail; you could as easily have a signal per axis, or indeed do both.) Although I didn't need to have current-state accessors (consider if you really need these), they'd be easy enough to add. Hat support would probably look like: hatMoved(int hat, HatDirection direction); Looking at QGamepadManager, I notice that you treat the hat as a set of buttons. That doesn't strike me as a good idea. Buttons are normally orthogonal (that is, given any two buttons, both might be pressed at the same time). While it's true that you can be lazy and report hats that way, there are problems doing so. First, it precludes users mapping an entire hat to a single digital 2-axis control (or at least makes it much more difficult). Second, hat directions are *not* orthogonal; a hat is more of a digital version of an axis-pair, i.e. two values that are either {-1, 0, +1}. This isn't just a matter of how you can mash on the controller, it's also a question of what the hardware protocol is capable of reporting. -- Matthew _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From mwoehlke.floss at gmail.com Mon Feb 15 21:23:08 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 15 Feb 2016 15:23:08 -0500 Subject: [Development] some questions about QtGamePad In-Reply-To: References: , Message-ID: On 2016-02-15 14:46, Nichols Andy wrote: > QtGamepad is intentionally limited to gamepads, and does not include support for joysticks, or generic devices with an arbitrary number of axes/buttons. That's... stupid IMNSHO. Especially since... > The design was primarily inspired by the HTML 5 gamepad API: > https://developer.mozilla.org/en-US/docs/Web/API/Gamepad_API/Using_the_Gamepad_API ...I don't see anything here that restricts the HTML 5 interface to some particular number of axes or buttons, or in any way really precludes it from being used for devices that are not "gamepads" (i.e. traditional joysticks). Nor do I see anything that tries to impose specific semantics on what buttons are available or have what indices. > Gamepads have roughly the same Button/Axes configurations *Modern* gamepads may happen to have similar button/axis configurations, but this is incidental. There is no guarantee that this "common configuration" won't change with the next generation of consoles. By imposing limits now, you are artificially constraining the API. > Apple platforms native Game Controller API's: > https://developer.apple.com/library/ios/documentation/ServicesDiscovery/Conceptual/GameControllerPG/Introduction/Introduction.html On the one hand, this isn't really applicable; they are artificially constraining the hardware. On the other... their artificial constraints *don't match* yours. That should be a red flag right there... > So I do not support expanding the scope of QtGamepad in the way you > propose, as I think if it belongs anywhere it is in a generic input API > (or you can always still just wrap SDL's input module pretty easily). I might be more inclined to agree if there was already a QJoystick or some such. As is, I think, at best, you're putting the cart before the horse. > There are however some API's missing that a gamepads API might > actually need about like accelerometer based motion controls If you supported arbitrary axes, *you'd have these already*. -- Matthew From mwoehlke.floss at gmail.com Mon Feb 15 21:34:46 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 15 Feb 2016 15:34:46 -0500 Subject: [Development] some questions about QtGamePad In-Reply-To: References: , Message-ID: On 2016-02-15 15:23, Matthew Woehlke wrote: >> So I do not support expanding the scope of QtGamepad in the way you >> propose, as I think if it belongs anywhere it is in a generic input API >> (or you can always still just wrap SDL's input module pretty easily). > > I might be more inclined to agree if there was already a QJoystick or > some such. As is, I think, at best, you're putting the cart before the > horse. Let me put that differently. By artificially constraining QGamePad, you are forcing people with needs that don't exactly conform to the completely arbitrary limitations you have chosen to impose to *recreate functionality that you are already using*. That's just... inconsiderate. -- Matthew From romain.pokrzywka at gmail.com Mon Feb 15 21:50:59 2016 From: romain.pokrzywka at gmail.com (Romain Pokrzywka) Date: Mon, 15 Feb 2016 12:50:59 -0800 Subject: [Development] Made with Qt - Bluescape at TED 2016 Message-ID: Hi all, I just wanted to share this piece of news, as a serious piece of hardware and UI is currently featured in the main lobby of the TED 2016 conference in Vancouver, and it's all made with Qt! https://www.bluescape.com/press/bluescape-introduces-visual-collaborative-workspace-to-1350-attendees-at-ted2016/ I've also attached a picture of the Bluescape Wall that was set up over there (sorry for the poor quality, it had to be under 100kb). It's a 3x5 array of 55'' multitouch displays sporting a total resolution of 9600x3240 pixels, and running on a 3-GPU machine (one GPU per row). It's running Qt 5.5 and makes a big use of QtQuick2 and QtWebEngine. There's also two 84'' single-display units on each side. Kudos to all contributors in the Qt community for making Qt such an awesome development framework, and special thanks to the folks at The Qt Company and KDAB. Hopefully we'll have a chance to showcase it again at the Qt World Summit in San Francisco this fall! Cheers, Romain -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bluescape at TED2016-small.jpg Type: image/jpeg Size: 95782 bytes Desc: not available URL: From Lars.Knoll at theqtcompany.com Tue Feb 16 08:29:30 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 16 Feb 2016 07:29:30 +0000 Subject: [Development] 5.7 new features and 5.6 changelog Message-ID: Hi everybody, It would be great if those of you who haven’t done so yet fill in the 5.7 new features page on the wiki (https://wiki.qt.io/New_Features_in_Qt_5.7), so that we can get a good overview over the bigger new features in 5.7. In addition, I’d like to ask every maintainer to have a look at the 5.6 changelog files, and checks that everything ok and the changelog is complete for your area. Thanks, Lars From mitch.curtis at theqtcompany.com Tue Feb 16 10:31:38 2016 From: mitch.curtis at theqtcompany.com (Curtis Mitch) Date: Tue, 16 Feb 2016 09:31:38 +0000 Subject: [Development] some questions about QtGamePad In-Reply-To: References: , Message-ID: I have no comments on this subject whatsoever, but I'd like to take the opportunity to make an example of how not to communicate to other people: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On Behalf Of > Matthew Woehlke > terrible idea > terrible design > How do you even handle hats??? > That's... stupid > If you supported arbitrary axes, *you'd have these already*. > That's just... inconsiderate. As is usually the case with people who behave like this, you sound like you have some really great points, but they're lost behind a lot of what seems like... outrage? People will be much more likely to take what you have to say into consideration and engage in discussion with you in the future if you tone it down and treat them like you'd like to be treated. That is, don't talk to people like they're idiots. From syntheticpp at gmx.net Tue Feb 16 14:38:05 2016 From: syntheticpp at gmx.net (=?UTF-8?Q?Peter_K=c3=bcmmel?=) Date: Tue, 16 Feb 2016 14:38:05 +0100 Subject: [Development] 5.7 new features and 5.6 changelog In-Reply-To: References: Message-ID: <56C3263D.2090801@gmx.net> Am 16.02.2016 um 08:29 schrieb Knoll Lars: > Hi everybody, > > It would be great if those of you who haven’t done so yet fill in the 5.7 new features page on the wiki (https://wiki.qt.io/New_Features_in_Qt_5.7), so that we can get a good overview over the bigger new features in 5.7. > > In addition, I’d like to ask every maintainer to have a look at the 5.6 changelog files, and checks that everything ok and the changelog is complete for your area. > > Thanks, > Lars A question about the new license-feature: - projects under the GPLv2 can not use a LGPLv3 library (Qt only as GPLv2) - LGPLv2.1 projects that want to use an LGPLv3 library. They must be upgraded to LGPLv3 ( http://nmav.gnutls.org/2013/03/the-perils-of-lgplv3.html ) Don't you fear a lot of projects will only use 5.6 and never upgrade to higher versions? Peter > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From kde at carewolf.com Tue Feb 16 15:21:00 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Tue, 16 Feb 2016 15:21:00 +0100 Subject: [Development] 5.7 new features and 5.6 changelog In-Reply-To: <56C3263D.2090801@gmx.net> References: <56C3263D.2090801@gmx.net> Message-ID: <201602161521.00207.kde@carewolf.com> On Tuesday 16 February 2016, Peter Kümmel wrote: > Am 16.02.2016 um 08:29 schrieb Knoll Lars: > > Hi everybody, > > > > It would be great if those of you who haven’t done so yet fill in the 5.7 > > new features page on the wiki > > (https://wiki.qt.io/New_Features_in_Qt_5.7), so that we can get a good > > overview over the bigger new features in 5.7. > > > > In addition, I’d like to ask every maintainer to have a look at the 5.6 > > changelog files, and checks that everything ok and the changelog is > > complete for your area. > > > > Thanks, > > Lars > > A question about the new license-feature: > > - projects under the GPLv2 can not use a LGPLv3 library (Qt only as GPLv2) > - LGPLv2.1 projects that want to use an LGPLv3 library. They must be > upgraded to LGPLv3 > But a GPLv2 project could easily use the Qt as GPLv2? This is precisely the reason we offer both GPLv2 and LGPLv3. Best regards `Allan From Lars.Knoll at theqtcompany.com Tue Feb 16 15:26:06 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 16 Feb 2016 14:26:06 +0000 Subject: [Development] 5.7 new features and 5.6 changelog In-Reply-To: <56C3263D.2090801@gmx.net> References: <56C3263D.2090801@gmx.net> Message-ID: On 16/02/16 14:38, "Development on behalf of Peter Kümmel" wrote: > > >Am 16.02.2016 um 08:29 schrieb Knoll Lars: >> Hi everybody, >> >> It would be great if those of you who haven’t done so yet fill in the 5.7 new features page on the wiki (https://wiki.qt.io/New_Features_in_Qt_5.7), so that we can get a good overview over the bigger new features in 5.7. >> >> In addition, I’d like to ask every maintainer to have a look at the 5.6 changelog files, and checks that everything ok and the changelog is complete for your area. >> >> Thanks, >> Lars > >A question about the new license-feature: > >- projects under the GPLv2 can not use a LGPLv3 library (Qt only as GPLv2) For project under GPLv2 there’s really no difference, as all parts of Qt that were available under LGPLv2.1 are still available under GPLv2. So you can continue to use Qt for your GPLv2 project as before. >- LGPLv2.1 projects that want to use an LGPLv3 library. They must be upgraded to LGPLv3 > >( http://nmav.gnutls.org/2013/03/the-perils-of-lgplv3.html ) This is only true if you combine these into a single work. This means, if you directly combine Qt code with code under the above licenses. If you use Qt as a shared library, it’s possible to keep LGPLv2.1 libraries in your stack. If you use libraries under both v2.1 and v3 in your application, you simply need to adhere to the license requirements of both licenses. Cheers, Lars > > >Don't you fear a lot of projects will only use 5.6 and never upgrade to higher versions? > >Peter > >> >> >> _______________________________________________ >> 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 mwoehlke.floss at gmail.com Tue Feb 16 16:29:27 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 16 Feb 2016 10:29:27 -0500 Subject: [Development] some questions about QtGamePad In-Reply-To: References: , Message-ID: On 2016-02-16 04:31, Curtis Mitch wrote: >> How do you even handle hats??? This, for the record, was an expression of confusion. (Since alleviated, though you'll notice from my latter post that I don't particularly agree with this part of the design either.) >> If you supported arbitrary axes, *you'd have these already*. ...because I am getting the impression that Nicols doesn't realize how his overly constrained design is getting in the way of features he knows are needed. >> That's just... inconsiderate. Sorry, but this one is just true, at least from my perspective as someone who would have liked to use this and can't/won't due to the poor design (and adamant refusal of the designer to make it more useful). > As is usually the case with people who behave like this, you sound > like you have some really great points, but they're lost behind a lot > of what seems like... outrage? I wouldn't use that word. I don't have enough personal stake to be outraged. "Perplexed" would be more accurate. QGamePad is a well intentioned addition to Qt that covers a valuable hole in functionality... that is (intentionally!) hobbled by an overly constrained API. > People will be much more likely to take what you have to say into > consideration and engage in discussion with you in the future if you > tone it down and treat them like you'd like to be treated. That is, > don't talk to people like they're idiots. If I'm writing a API that has serious issues, I want someone to tell me. If you pay attention to the order of posts, you'll note the conversation went like this: Me: Please¹ don't limit your API like this. Nichols: I reject everything you are saying. Me: I think you are making a mistake. (¹ The word "please" appeared three times in the original message.) Your original assertion is therefore flawed; at the point I expressed myself in a way you found objectionable, Nichols was already declining entirely to consider anything I was saying. Also, the unfortunate reality is that Free Software contributors (and engineers in general) tend to be jerks. We don't *have time* to coddle everyone we talk to. -- Matthew From Andy.Nichols at theqtcompany.com Tue Feb 16 18:08:15 2016 From: Andy.Nichols at theqtcompany.com (Nichols Andy) Date: Tue, 16 Feb 2016 17:08:15 +0000 Subject: [Development] some questions about QtGamePad In-Reply-To: References: Message-ID: Hi Matthew, I do appreciate the feedback and suggestions for the API as it is now. I’m sorry if my mail came off as obstructionist as it was not intended in this way. Since this is a Qt API I want it to be both useful and easy to use. I conceded that the current API is limited to the available buttons on an Xbox 360 Gamepad, as that was the intended API deliberately limited in scope as this leads to an easy to use, but definitely limited API. My fear is that a more expanded generic API would turn into what SDL Joystick is now. I think that kind of API is useful, but it mandates the use of an input mapper (like the one in the Qt3D Input Aspect) to be usable in any reasonable way. So I would prefer to keep the API limited as stated, but this is an open source project and the API isn’t nailed down yet so we can change things if it makes sense. I would contrast this module to the SDL GameController API which does include button and axis mappings that match the established “Gamepad” devices (Xbox, Playstation, WiiU Pro Controller): http://wiki.libsdl.org/SDL_GameControllerAxis http://wiki.libsdl.org/SDL_GameControllerButton By using QtGamepad, the expectation is that your end users would be able to plug in a “Gamepad” and that would have roughly the same button/axis configuration. Any other device that was “gamepadish” might work, but with no expectation of support. For many PC games, Gamepads work automatically assuming the same configuration. For games/applications that would need to support a multitude of devices, like a flight simulator, it would be important to use an API like SDL Joystick which does provide all button/axis/hats and their respective properties, and then provide a mapping mechanism to map Buttons/Axes/hats to actions, (and maybe even make that configurable ;-) ). It may be that it makes sense to create a lower level API for generic input devices. It was previously mentioned before but this would be similar to the SDL Joystick API where an input device could be queried and it would enumerate it’s buttons and axis as well is properties. This would serve the need of solving the original problem mentioned by Pritam regarding additional control sticks on a flight controller. So hopefully this add’s a bit more rational. I don’t think what you are saying is wrong at all, I just though what you suggested was out of the current scope of the module. And it could be that other disagree with the scope of the QtGamepad module as well, and there is still time to change it. And as always, contributions are appreciated as well, so If you’re feeling motivated submit some possible API revisions to code-review and add me as a reviewer. Regards, Andy Nichols freenode: nezticle Also, the unfortunate reality is that Free Software contributors (and engineers in general) tend to be jerks. We don't *have time* to coddle everyone we talk to. Tell me about it ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Tue Feb 16 18:45:39 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 16 Feb 2016 12:45:39 -0500 Subject: [Development] some questions about QtGamePad In-Reply-To: References: Message-ID: On 2016-02-16 12:08, Nichols Andy wrote: > I’m sorry if my mail came off as obstructionist as it was not intended in this way. Not at all :-). (Opinionated, perhaps, but I wouldn't say "obstructionist". I have no philosophical problem with strongly held opinions, being one who often holds strong opinions myself.) If the previous message seemed... "agitated", that was directed at Curtis, not you. > Since this is a Qt API I want it to be both useful and easy to use. > I conceded that the current API is limited to the available buttons on an > Xbox 360 Gamepad, as that was the intended API deliberately limited in > scope as this leads to an easy to use, but definitely limited API. My > fear is that a more expanded generic API would turn into what SDL > Joystick is now. And... what's wrong with that? :-) I happen to think that SDL is a very nice API, and I would *love* to see something similar (but with signals, of course!) in Qt. Again, while I don't think *I* would ever use the limited QGamepad API, my biggest objection is that you *need* the lower level API in order to implement QGamepad (which means you've *implemented* said lower level API), but you haven't exposed it. So, if QGamepad isn't a perfect fit for me, I have to implement the lower level abstraction myself, when I could just use yours if only it was made public. > I think that kind of API is useful, but it mandates the > use of an input mapper (like the one in the Qt3D Input Aspect) to be > usable in any reasonable way. This is another point where I find I can't agree. There are two major use cases for handling joystick input. Either I allow the user to map the controls the way they want (i.e. I have such an input mapper), or I require the user to use a particular controller and mapping, in which case I just hard-code the mapping anyway and don't need an abstraction layer over the raw hardware. It looks to me like QGamepad is trying to create a third case that combines the worst aspects of both options, where there is some ability for the user to "fix" a controller with the right number of inputs but "wrong" labeling of those inputs so that it can be used with a program that hard-codes what does what. I'd be much more interested in going that next little bit further and just providing a full blown input configuration system in a library. > I would contrast this module to the SDL GameController API which does include button and axis mappings that match the established “Gamepad” devices (Xbox, Playstation, WiiU Pro Controller): ...and I'll point out that, if this isn't suitable, you can use the SDL Joystick API :-). If there *was* a Qt joystick API, then having a restricted API built on top of it wouldn't bother me nearly so much, as I'd just ignore it. > So hopefully this add’s a bit more rational. Sure... and again, it's not so much that I'm opposed to having a high level abstraction for a restricted use case (if that use case is sufficiently common), it's that I dislike not making the less abstracted functionality available for the cases where the higher abstraction doesn't match, and/or users need to be able to fiddle with things "under the hood". Better (at least, more Qt-relevant) analogy: it's as if we had QTreeWidget but not QTreeView or QAbstractItemModel. -- Matthew From alexander.blasche at theqtcompany.com Wed Feb 17 08:29:49 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Wed, 17 Feb 2016 07:29:49 +0000 Subject: [Development] How to find the most appropriate "Fix Version" tag in Jira Message-ID: Hi, Some of you might have noticed that I did some global release version clean-ups in Jira. Several people asked me about the rationale behind the changes I did. There is a long explanation below and there is a short recommendation I'd like to give (in case you don't read the entire mail): Please always use the most appropriate/precise version tag you can find. This means it should be a 5.x.y tag. Only use the 5.x tags when you are not 100% certain. If you miss a 5.x.y Jira tag (where one should exist), please let me know and I'll add it. ------------------------------- The verion tag 5.5 is not a proper version tag. A bug consumer would not know where to find the fix. Issues should always be set to the most appropriate fix version tag. If you know that git's 5.x branch will later be branched off into 5.x.y then you should set it Jira to 5.x.y. The only case where the 5.x tag makes sense is in a scenario were you don't know whether the 5.x branch will still generate another patch level release. Once it is certain where the a 5.x branch ends up I go through the 5.x release tags and they become the next 5.(x+1).0 (RC|Beta|Alpha) or 5.x.y release. This is what happened during the last two day. 5.5 is no more (and meaningless as fixForVersion) and the 5.5->5.6 merge took place. Since the 5.6 branch at the time of the merge results in the 5.6.0RC that's what I set the FixVersion to. There were hundreds of such issues. It is impossible to check and validate each individual issue but the cleanup was necessary. Moving the version to 5.6.0RC may not be the most appropriate release tag but one that is not wrong. It was a compromise between accuracy and the sheer volume of tasks witch such tags. To avoid this in the future please set a precise patch level tag (5.x.y) if deducible from the current branching situation. For example today's situation would be like this: git branch 5.6.0 -> next 5.6.0RC -> 5.6.0 (after RC is out) git branch 5.6 -> 5.6.1 git branch 5.7 -> 5.7.0 Alpha git branch dev -> 5.7.0 Alpha (as long as Ossi still merges backwards) -> 5.8.0 Alpha (after last backmerge) Only if it is not possible then you can set 5.x which will be converted by me once the situation is more obvious. If my bulk change is incorrect and you have better more precise information please feel free to change it. I hope this helps and thank you for your help. -- Alex From tim at klingt.org Wed Feb 17 08:38:36 2016 From: tim at klingt.org (Tim Blechmann) Date: Wed, 17 Feb 2016 15:38:36 +0800 Subject: [Development] New Qt 5.6.0 RC snapshot available, please test In-Reply-To: References: Message-ID: > We have finally packages for testing, > > > Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/335/ > > Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/331/ > > Mac:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/271/ > > src:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/latest_src > > > Unfortunately these packages are from a bit old qt5.git integration > (https://codereview.qt-project.org/#/c/147715/) so latest changes from > '5.6.0' (https://codereview.qt-project.org/#/c/148570/) are missing from > the packages, sorry about that! > > > We are trying to release RC as soon as possible so it is really > important to test these packages now to see if there is still something > to be fixed before we can release the RC. Current RC blockers are here: > https://bugreports.qt.io/issues/?filter=17225 .Please make sure all > blocker are visible here (but remember, just a real blockers anymore!). > > > And please start creating changelogs for final release now if not > already started. seems that building statically linked qt is broken: windows: > link /NOLOGO /DYNAMICBASE /NXCOMPAT /DEBUG /OPT:REF /INCREMENTAL:NO /SUBSYSTEM:CONSOLE "/MANIFESTDEPENDENCY:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" /MANIFEST:embed /OUT:..\..\..\bin\canbusutil.exe @C:\Users\developer\AppData\Local\Temp\canbusutil.exe.3388.3853.jom > 16-Feb-2016 14:24:02 canbusutil_plugin_import.obj : error LNK2019: unresolved external symbol "struct QStaticPlugin const __cdecl qt_static_plugin_PeakCanBusPlugin(void)" (?qt_static_plugin_PeakCanBusPlugin@@YA?BUQStaticPlugin@@XZ) referenced in function "public: __cdecl StaticPeakCanBusPluginPluginInstance::StaticPeakCanBusPluginPluginInstance(void)" (??0StaticPeakCanBusPluginPluginInstance@@QEAA at XZ) > 16-Feb-2016 14:24:02 canbusutil_plugin_import.obj : error LNK2019: unresolved external symbol "struct QStaticPlugin const __cdecl qt_static_plugin_TinyCanBusPlugin(void)" (?qt_static_plugin_TinyCanBusPlugin@@YA?BUQStaticPlugin@@XZ) referenced in function "public: __cdecl StaticTinyCanBusPluginPluginInstance::StaticTinyCanBusPluginPluginInstance(void)" (??0StaticTinyCanBusPluginPluginInstance@@QEAA at XZ) osx: > Undefined symbols for architecture x86_64: > 16-Feb-2016 13:38:21 "qt_static_plugin_PeakCanBusPlugin()", referenced from: > 16-Feb-2016 13:38:21 __GLOBAL__sub_I_canbusutil_plugin_import.cpp in canbusutil_plugin_import.o > 16-Feb-2016 13:38:21 ld: symbol(s) not found for architecture x86_64 > 16-Feb-2016 13:38:21 clang: error: linker command failed with exit code 1 (use -v to see invocation) > 16-Feb-2016 13:38:21 make[4]: *** [../../../bin/canbusutil] Error 1 > 16-Feb-2016 13:38:21 make[3]: *** [sub-canbusutil-make_first] Error 2 > 16-Feb-2016 13:38:21 make[2]: *** [sub-tools-make_first] Error 2 would be great if statically linked qt could somehow be compiled regularly ... it breaks way too often :( cheers, tim From alexander.blasche at theqtcompany.com Wed Feb 17 08:58:28 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Wed, 17 Feb 2016 07:58:28 +0000 Subject: [Development] New Qt 5.6.0 RC snapshot available, please test In-Reply-To: References: , Message-ID: Thank you for pointing this out. I am working on it. -- Alex ________________________________________ From: Development on behalf of Tim Blechmann Sent: Wednesday, February 17, 2016 08:38 To: development at qt-project.org Subject: Re: [Development] New Qt 5.6.0 RC snapshot available, please test > We have finally packages for testing, > > > Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/335/ > > Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/331/ > > Mac:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/271/ > > src:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/latest_src > > > Unfortunately these packages are from a bit old qt5.git integration > (https://codereview.qt-project.org/#/c/147715/) so latest changes from > '5.6.0' (https://codereview.qt-project.org/#/c/148570/) are missing from > the packages, sorry about that! > > > We are trying to release RC as soon as possible so it is really > important to test these packages now to see if there is still something > to be fixed before we can release the RC. Current RC blockers are here: > https://bugreports.qt.io/issues/?filter=17225 .Please make sure all > blocker are visible here (but remember, just a real blockers anymore!). > > > And please start creating changelogs for final release now if not > already started. seems that building statically linked qt is broken: windows: > link /NOLOGO /DYNAMICBASE /NXCOMPAT /DEBUG /OPT:REF /INCREMENTAL:NO /SUBSYSTEM:CONSOLE "/MANIFESTDEPENDENCY:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" /MANIFEST:embed /OUT:..\..\..\bin\canbusutil.exe @C:\Users\developer\AppData\Local\Temp\canbusutil.exe.3388.3853.jom > 16-Feb-2016 14:24:02 canbusutil_plugin_import.obj : error LNK2019: unresolved external symbol "struct QStaticPlugin const __cdecl qt_static_plugin_PeakCanBusPlugin(void)" (?qt_static_plugin_PeakCanBusPlugin@@YA?BUQStaticPlugin@@XZ) referenced in function "public: __cdecl StaticPeakCanBusPluginPluginInstance::StaticPeakCanBusPluginPluginInstance(void)" (??0StaticPeakCanBusPluginPluginInstance@@QEAA at XZ) > 16-Feb-2016 14:24:02 canbusutil_plugin_import.obj : error LNK2019: unresolved external symbol "struct QStaticPlugin const __cdecl qt_static_plugin_TinyCanBusPlugin(void)" (?qt_static_plugin_TinyCanBusPlugin@@YA?BUQStaticPlugin@@XZ) referenced in function "public: __cdecl StaticTinyCanBusPluginPluginInstance::StaticTinyCanBusPluginPluginInstance(void)" (??0StaticTinyCanBusPluginPluginInstance@@QEAA at XZ) osx: > Undefined symbols for architecture x86_64: > 16-Feb-2016 13:38:21 "qt_static_plugin_PeakCanBusPlugin()", referenced from: > 16-Feb-2016 13:38:21 __GLOBAL__sub_I_canbusutil_plugin_import.cpp in canbusutil_plugin_import.o > 16-Feb-2016 13:38:21 ld: symbol(s) not found for architecture x86_64 > 16-Feb-2016 13:38:21 clang: error: linker command failed with exit code 1 (use -v to see invocation) > 16-Feb-2016 13:38:21 make[4]: *** [../../../bin/canbusutil] Error 1 > 16-Feb-2016 13:38:21 make[3]: *** [sub-canbusutil-make_first] Error 2 > 16-Feb-2016 13:38:21 make[2]: *** [sub-tools-make_first] Error 2 would be great if statically linked qt could somehow be compiled regularly ... it breaks way too often :( cheers, tim _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From alexander.blasche at theqtcompany.com Wed Feb 17 09:36:06 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Wed, 17 Feb 2016 08:36:06 +0000 Subject: [Development] New Qt 5.6.0 RC snapshot available, please test In-Reply-To: References: , , Message-ID: Fix: https://codereview.qt-project.org/#/c/149611/ -- Alex ________________________________________ From: Development on behalf of Tim Blechmann Sent: Wednesday, February 17, 2016 08:38 To: development at qt-project.org Subject: Re: [Development] New Qt 5.6.0 RC snapshot available, please test > We have finally packages for testing, > > > Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/335/ > > Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/331/ > > Mac:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/271/ > > src:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/latest_src > > > Unfortunately these packages are from a bit old qt5.git integration > (https://codereview.qt-project.org/#/c/147715/) so latest changes from > '5.6.0' (https://codereview.qt-project.org/#/c/148570/) are missing from > the packages, sorry about that! > > > We are trying to release RC as soon as possible so it is really > important to test these packages now to see if there is still something > to be fixed before we can release the RC. Current RC blockers are here: > https://bugreports.qt.io/issues/?filter=17225 .Please make sure all > blocker are visible here (but remember, just a real blockers anymore!). > > > And please start creating changelogs for final release now if not > already started. >seems that building statically linked qt is broken: windows: > link /NOLOGO /DYNAMICBASE /NXCOMPAT /DEBUG /OPT:REF /INCREMENTAL:NO /SUBSYSTEM:CONSOLE "/MANIFESTDEPENDENCY:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b64144ccf1df' language='*' processorArchitecture='*'" /MANIFEST:embed /OUT:..\..\..\bin\canbusutil.exe @C:\Users\developer\AppData\Local\Temp\canbusutil.exe.3388.3853.jom > 16-Feb-2016 14:24:02 canbusutil_plugin_import.obj : error LNK2019: unresolved external symbol "struct QStaticPlugin const __cdecl qt_static_plugin_PeakCanBusPlugin(void)" (?qt_static_plugin_PeakCanBusPlugin@@YA?BUQStaticPlugin@@XZ) referenced in function "public: __cdecl StaticPeakCanBusPluginPluginInstance::StaticPeakCanBusPluginPluginInstance(void)" (??0StaticPeakCanBusPluginPluginInstance@@QEAA at XZ) > 16-Feb-2016 14:24:02 canbusutil_plugin_import.obj : error LNK2019: unresolved external symbol "struct QStaticPlugin const __cdecl qt_static_plugin_TinyCanBusPlugin(void)" (?qt_static_plugin_TinyCanBusPlugin@@YA?BUQStaticPlugin@@XZ) referenced in function "public: __cdecl StaticTinyCanBusPluginPluginInstance::StaticTinyCanBusPluginPluginInstance(void)" (??0StaticTinyCanBusPluginPluginInstance@@QEAA at XZ) osx: > Undefined symbols for architecture x86_64: > 16-Feb-2016 13:38:21 "qt_static_plugin_PeakCanBusPlugin()", referenced from: > 16-Feb-2016 13:38:21 __GLOBAL__sub_I_canbusutil_plugin_import.cpp in canbusutil_plugin_import.o > 16-Feb-2016 13:38:21 ld: symbol(s) not found for architecture x86_64 > 16-Feb-2016 13:38:21 clang: error: linker command failed with exit code 1 (use -v to see invocation) > 16-Feb-2016 13:38:21 make[4]: *** [../../../bin/canbusutil] Error 1 > 16-Feb-2016 13:38:21 make[3]: *** [sub-canbusutil-make_first] Error 2 > 16-Feb-2016 13:38:21 make[2]: *** [sub-tools-make_first] Error 2 would be great if statically linked qt could somehow be compiled regularly ... it breaks way too often :( cheers, tim _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From helio at kde.org Wed Feb 17 09:36:23 2016 From: helio at kde.org (Helio Chissini de Castro) Date: Wed, 17 Feb 2016 09:36:23 +0100 Subject: [Development] New Qt 5.6.0 RC snapshot available, please test In-Reply-To: References: Message-ID: Hello all We are testing packages generated from git branch 5.6.0 from now in Fedora, since fails again to comply on the agreed rules of release splitted tarballs. And sorry, the "is just a snapshot" is no longer a valid excuse. Helio On Fri, Feb 12, 2016 at 1:49 PM, Heikkinen Jani < jani.heikkinen at theqtcompany.com> wrote: > Hi all, > > > We have finally packages for testing, > > > Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/335/ > > Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/331/ > > Mac:http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/271/ > > src: > http://download.qt.io/snapshots/qt/5.6/5.6.0-rc/latest_src > > > Unfortunately these packages are from a bit old qt5.git integration ( > https://codereview.qt-project.org/#/c/147715/) so latest changes from > '5.6.0' (https://codereview.qt-project.org/#/c/148570/) are missing from > the packages, sorry about that! > > > We are trying to release RC as soon as possible so it is really important > to test these packages now to see if there is still something to be fixed > before we can release the RC. Current RC blockers are here: > https://bugreports.qt.io/issues/?filter=17225 .Please make sure all > blocker are visible here (but remember, just a real blockers anymore!). > > > And please start creating changelogs for final release now if not already > started. > > 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 dangelog at gmail.com Wed Feb 17 11:27:47 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Wed, 17 Feb 2016 11:27:47 +0100 Subject: [Development] How to find the most appropriate "Fix Version" tag in Jira In-Reply-To: References: Message-ID: On Wed, Feb 17, 2016 at 8:29 AM, Blasche Alexander wrote: > > The verion tag 5.5 is not a proper version tag. A bug consumer would not know where to find the fix. Issues should always be set to the most appropriate fix version tag. If you know that git's 5.x branch will later be branched off into 5.x.y then you should set it Jira to 5.x.y. The only case where the 5.x tag makes sense is in a scenario were you don't know whether the 5.x branch will still generate another patch level release. Once it is certain where the a 5.x branch ends up I go through the 5.x release tags and they become the next 5.(x+1).0 (RC|Beta|Alpha) or 5.x.y release. I'm sorry, but this reasoning makes very little sense to me. The decision whether a given version will or will not be released from a branch belongs to the release team, and it's (99% of the time) just a bandwidth and packaging problem, i.e. "do we have enough resources to put 5.x.y out". A developer fixing a bug has no influence nor knowledge over that process; it's already enough of a burden to make patches target the right branch (*), as versioned branches come and go, overloading Oswald with "please move this patch" requests. Think of a bugfix landing in 5.6 right now. What's the tag I'm supposed to use? 5.6.1? What if there won't be one, and how am I supposed to know that (which by the way was exactly the case with bugfixes landed in 5.5 after 5.5.1)? Should I be conservative and use 5.7.0 then? So what happens if there is indeed a 5.6.1, people will think that it won't contain the bug fix? On the other hand, marking it as "5.6" is meaningful – whoever uses 5.6 from git knows they'll have the bug fixed. There are many downstreams which use specific branches from git (as for various reasons they can't "just upgrade"). If you think that "5.6" is confusing or not accurate, we could rename them, perhaps to "5.6 branch" or "5.6 git" or something like that (or use a different field on the report for this purpose). Next to that branch tag, you could add a specific version tag of the first released version of Qt that contains that bugfix. For the reasons above, it should be the job of the release team to do this, and luckily should be easily scriptable – for instance, by taking the SHA1 in the bug report and checking if the new release contains that SHA1, then tagging the report accordingly. (*) And we haven't discuessed yet how to tackle the LTS. But I rejoy thinking that for the next 3 years I'll have a automatic -2 if I spot bugfixes not targeting 5.6. My 2 c, -- Giuseppe D'Angelo From alexander.blasche at theqtcompany.com Wed Feb 17 12:24:30 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Wed, 17 Feb 2016 11:24:30 +0000 Subject: [Development] How to find the most appropriate "Fix Version" tag in Jira In-Reply-To: References: Message-ID: > -----Original Message----- > From: Giuseppe D'Angelo [mailto:dangelog at gmail.com] > On Wed, Feb 17, 2016 at 8:29 AM, Blasche Alexander > wrote: > > > > The verion tag 5.5 is not a proper version tag. A bug consumer would not know > where to find the fix. Issues should always be set to the most appropriate fix > version tag. If you know that git's 5.x branch will later be branched off into 5.x.y > then you should set it Jira to 5.x.y. The only case where the 5.x tag makes sense is > in a scenario were you don't know whether the 5.x branch will still generate > another patch level release. Once it is certain where the a 5.x branch ends up I go > through the 5.x release tags and they become the next 5.(x+1).0 > (RC|Beta|Alpha) or 5.x.y release. > > I'm sorry, but this reasoning makes very little sense to me. > > The decision whether a given version will or will not be released from > a branch belongs to the release team, and it's (99% of the time) just > a bandwidth and packaging problem, i.e. "do we have enough resources > to put 5.x.y out". A developer fixing a bug has no influence nor > knowledge over that process; it's already enough of a burden to make > patches target the right branch (*), as versioned branches come and > go, overloading Oswald with "please move this patch" requests. I disagree. Sure you may not know whether there will be a 5.6.3 but you do know today that the following will happen: - git5.6.0 will be 5.6.0 - git5.6 will be 5.6.1 (sure 5.6.2 will be harder to guess and by all means use 5.6 for it) so far we always had a .1 patch release and I cannot see this changing. On top of that you know it is an LTS. - git5.7 will be 5.7.0 Alpha (unless we will never have 5.7 as a release version) - dev will be 5.8 Alpha Where is the open question in your mind about the above 4 cases? > Think of a bugfix landing in 5.6 right now. What's the tag I'm > supposed to use? 5.6.1? What if there won't be one, and how am I > supposed to know that (which by the way was exactly the case with > bugfixes landed in 5.5 after 5.5.1)? Should I be conservative and use > 5.7.0 then? So what happens if there is indeed a 5.6.1, people will > think that it won't contain the bug fix? Use 5.6.1, there is no harm. We are 99% sure it will exist and even if it never comes about I will rewrite it to 5.7.0 when it is certain and I see the merge. After all the 5.5.3 release tag did exist as well till yesterday and they all got rewritten to 5.6.0RC because we had the last 5.5->5.6 merge. In fact Jira enforces this as we have to shift Jira release version tags into the "released" state. > On the other hand, marking it as "5.6" is meaningful – whoever uses > 5.6 from git knows they'll have the bug fixed. There are many > downstreams which use specific branches from git (as for various > reasons they can't "just upgrade"). If you think that "5.6" is > confusing or not accurate, we could rename them, perhaps to "5.6 > branch" or "5.6 git" or something like that (or use a different field > on the report for this purpose). 5.6 is a temporary release tag. During the entire history of Qt in Jira it has been this way. Sure, if you aren't sure then by all means use it but be prepared that we might end up with a situation where it ends up with the wrong tag. An excellent example for this is https://bugreports.qt.io/browse/QTBUG-40060 . And yes, I could have tracked this case down but doing so for hundreds of Jira items is unreasonable. What matters when a Qt user looks at a bug is the ultimate release version for the Qt at hand. Do I need to upgrade from 5.6.2 to 5.6.3 or not? Just stating 5.6 is meaningless once the bug is in a released Qt version as the meaning of 5.6 shifts over time. 5.6.0 does not change its meaning ever. Also it is unreasonable to expect that customers have to dive through gerrit and git to figure out which release got the patch eventually. I certainly don't want to do that for gcc versions or the linux kernel releases. > Next to that branch tag, you could add a specific version tag of the > first released version of Qt that contains that bugfix. For the > reasons above, it should be the job of the release team to do this, > and luckily should be easily scriptable – for instance, by taking the > SHA1 in the bug report and checking if the new release contains that > SHA1, then tagging the report accordingly. We all agree that a lot of things can be automated. Right now they are not and unless you volunteer to do this it won't get done. We all have priorities (including the release team which currently tries to manage 2 concurrent releases). Similar cases are change logs etc. In this case every developer has to set a FixVersion when resolving the bug. Is it too much asked to make an appropriate guess which might improve the accuracy of our data? It is hardly more effort for you as individual developer. If unsure you can use 5.x tag as always. -- Alex From thiago.macieira at intel.com Wed Feb 17 17:28:59 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Feb 2016 08:28:59 -0800 Subject: [Development] How to find the most appropriate "Fix Version" tag in Jira In-Reply-To: References: Message-ID: <3755377.kgIai7c4Lk@tjmaciei-mobl4> On quarta-feira, 17 de fevereiro de 2016 11:24:30 PST Blasche Alexander wrote: > - git5.6 will be 5.6.1 (sure 5.6.2 will be harder to guess and by all means > use 5.6 for it) so far we always had a .1 patch release and I cannot see > this changing. On top of that you know it is an LTS. I'd say you should use 5.6.2 even if you don't know if that release will happen. Worst case scenario, we have a bunch of fixes assigned to a release that didn't exist. So far, that simply implied it was in the next minor instead. For 5.6, since it's a long-term release, some fixes will have two Fix Version numbers (as in 5.6.4 and 5.7.2). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at theqtcompany.com Wed Feb 17 19:02:50 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 17 Feb 2016 19:02:50 +0100 Subject: [Development] HEADS UP: Qt 5.7 branching ongoing In-Reply-To: <20160212165813.GB20706@troll08.it.local> References: <20160212165813.GB20706@troll08.it.local> Message-ID: <20160217180249.GA32311@troll08.it.local> the downmerge is now done (*). that means that 5.7 is now finally properly feature-frozen, and dev is undisputably open for new features. that means that if you integrate something on dev now, it won't be in 5.7 - cherry-picks require special negotiation (with ME!) and earn you some Very Stern Words. as usual. you may still make retargeting requests for pending changes. as usual. (*) qtbase's and qtwebengine's merges are currently integrating. that means that dev is already open, but the content is not in 5.7 yet. On Fri, Feb 12, 2016 at 05:58:13PM +0100, Oswald Buddenhagen wrote: > with some rather significant delay, the 5.7 branch is now available. > please start using it for new changes intented for the Qt 5.7 release. > > we will downmerge dev to 5.7 the last time in a few days - i don't know > any particular date, but it may be *quite* soon, as we're running late. > it's recommended that you send retargeting requests for pending changes > on dev meant for 5.7 to me immediately. if the changes still integrate > on dev before monday, that's fine. From Simon.Hausmann at theqtcompany.com Thu Feb 18 11:50:22 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 18 Feb 2016 10:50:22 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) Message-ID: Hi, A little while ago Lars and I proposed to introduce physical units in the QML language for use in QtQuick. The idea was to make it easier to write user interfaces that adapt to different display resolutions by "pinning" your UI to physical dimensions. For example you could say Image { source: "mypprofilephoto.png" width: 5cm height: 5cm } and the image size in physical pixels would scale accordingly to always produce a 5cmx5cm profile image on the screen. The proposed units included "px", which was really an alias for nothing. We've had some very good discussions around this at last year's contributor summit as well as in smaller face-to-face discussions. The main feedback I recall was that this would seem like a nice feature on paper but in practice people create their resolution independent interfaces using the current "pixels" and a scale factor that they introduce in a qml file or as a context property. That's another way of saying that perhaps the feature wouldn't really find any use, which is fair :). Instead the desire was expressed that making it _easier_ to scale "logical" pixels in the application would perhaps be better. So today during a discussion another idea came up: (1) In order to make it really easy to scale "logical" pixels without having to introduce your own context property or factor in a .qml file that you multiply everywhere, we could turn the regular "pixels" in QtQuick into truly logical pixels that scale with an application wide (or window wide) factor. So Image { width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 physical pixels on a x2 display. This assumes the availability of API to change this mapping. (2) In the events where you still _want_ to use physical pixels, you could use "px" units. So at first nothing would change for app developers at all because we map logical pixels to physical pixels. But if you'd like to, you could opt into changing this mapping and having a relatively easy fallback to physical pixels using for example the "px" unit. We might as well offer the other physical units anyway, that probably causes little to no harm. What do you think? Simon From ritt.ks at gmail.com Thu Feb 18 11:57:17 2016 From: ritt.ks at gmail.com (=?UTF-8?B?0JjRgNC40L3QsCBGbG9yYQ==?=) Date: Thu, 18 Feb 2016 14:57:17 +0400 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: I like it! Some questions though: * Does (2) include coverage for cases like 5cm ? * Could we have a solution for writing `width: 90%` instead of `width: parent.width * 0.9` as well? Regards, Konstantin 2016-02-18 14:50 GMT+04:00 Hausmann Simon : > Hi, > > A little while ago Lars and I proposed to introduce physical units in the > QML language for use in QtQuick. The idea was to make it easier to write > user interfaces that adapt to different display resolutions by "pinning" > your UI to physical dimensions. For example you could say > > Image { > source: "mypprofilephoto.png" > width: 5cm > height: 5cm > } > > and the image size in physical pixels would scale accordingly to always > produce a 5cmx5cm profile image on the screen. The proposed units included > "px", which was really an alias for nothing. > > We've had some very good discussions around this at last year's > contributor summit as well as in smaller face-to-face discussions. The main > feedback I recall was that this would seem like a nice feature on paper but > in practice people create their resolution independent interfaces using the > current "pixels" and a scale factor that they introduce in a qml file or as > a context property. That's another way of saying that perhaps the feature > wouldn't really find any use, which is fair :). Instead the desire was > expressed that making it _easier_ to scale "logical" pixels in the > application would perhaps be better. > > So today during a discussion another idea came up: > > (1) In order to make it really easy to scale "logical" pixels without > having to introduce your own context property or factor in a .qml file that > you multiply everywhere, we could turn the regular "pixels" in QtQuick into > truly logical pixels that scale with an application wide (or window wide) > factor. So Image { width: 100 ... } will scale automatically from 100 > logical pixels to maybe 200 physical pixels on a x2 display. This assumes > the availability of API to change this mapping. > > (2) In the events where you still _want_ to use physical pixels, you could > use "px" units. > > So at first nothing would change for app developers at all because we map > logical pixels to physical pixels. But > if you'd like to, you could opt into changing this mapping and having a > relatively easy fallback to physical pixels using for example the "px" > unit. We might as well offer the other physical units anyway, that probably > causes little to no harm. > > What do you think? > > Simon > _______________________________________________ > 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 theqtcompany.com Thu Feb 18 12:05:42 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 18 Feb 2016 11:05:42 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: , Message-ID: Hi, (1) Do I understand your question correctly in the sense that you're wondering if 5cm would still produce a 5cm dimension on the screen regardless of the scale factor? Then the answer is yes :) (2) At first glance I do like that idea. Any other opinions? Simon ________________________________ From: Ирина Flora Sent: Thursday, February 18, 2016 11:57 To: Hausmann Simon Cc: development at qt-project.org Subject: Re: [Development] Scalable UIs in QtQuick (take 2) I like it! Some questions though: * Does (2) include coverage for cases like 5cm ? * Could we have a solution for writing `width: 90%` instead of `width: parent.width * 0.9` as well? Regards, Konstantin 2016-02-18 14:50 GMT+04:00 Hausmann Simon >: Hi, A little while ago Lars and I proposed to introduce physical units in the QML language for use in QtQuick. The idea was to make it easier to write user interfaces that adapt to different display resolutions by "pinning" your UI to physical dimensions. For example you could say Image { source: "mypprofilephoto.png" width: 5cm height: 5cm } and the image size in physical pixels would scale accordingly to always produce a 5cmx5cm profile image on the screen. The proposed units included "px", which was really an alias for nothing. We've had some very good discussions around this at last year's contributor summit as well as in smaller face-to-face discussions. The main feedback I recall was that this would seem like a nice feature on paper but in practice people create their resolution independent interfaces using the current "pixels" and a scale factor that they introduce in a qml file or as a context property. That's another way of saying that perhaps the feature wouldn't really find any use, which is fair :). Instead the desire was expressed that making it _easier_ to scale "logical" pixels in the application would perhaps be better. So today during a discussion another idea came up: (1) In order to make it really easy to scale "logical" pixels without having to introduce your own context property or factor in a .qml file that you multiply everywhere, we could turn the regular "pixels" in QtQuick into truly logical pixels that scale with an application wide (or window wide) factor. So Image { width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 physical pixels on a x2 display. This assumes the availability of API to change this mapping. (2) In the events where you still _want_ to use physical pixels, you could use "px" units. So at first nothing would change for app developers at all because we map logical pixels to physical pixels. But if you'd like to, you could opt into changing this mapping and having a relatively easy fallback to physical pixels using for example the "px" unit. We might as well offer the other physical units anyway, that probably causes little to no harm. What do you think? Simon _______________________________________________ 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 theqtcompany.com Thu Feb 18 12:18:50 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 18 Feb 2016 11:18:50 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: <855E6702-F5AF-4483-A700-9EDBCC0DF20F@theqtcompany.com> On 18/02/16 12:05, "Development on behalf of Hausmann Simon" wrote: >Hi, > > >(1) Do I understand your question correctly in the sense that you're wondering if 5cm would still produce a 5cm dimension on the screen regardless of the scale factor? Then the answer is yes :) > > >(2) At first glance I do like that idea. Any other opinions? The problem with this is to know what the percentage relates to. Percentages come from CSS, where this is usually (but not always) defined as the corresponding property in the parent element. What I’m afraid of with a CSS like model is that percentages will require quite some additional logic in the parser (and knowledge about individual properties) to know what the percentages are supposed to match against. Even if we define this as always relating to the same property name in the parent item, this creates some semantic difficulties, as the right hand side of the binding expression implicitly depends on the name on the left hand side. Cheers, Lars > > > > > > >Simon > > >________________________________________ >From: Ирина Flora >Sent: Thursday, February 18, 2016 11:57 >To: Hausmann Simon >Cc: development at qt-project.org >Subject: Re: [Development] Scalable UIs in QtQuick (take 2) > >I like it! > > >Some questions though: >* Does (2) include coverage for cases like 5cm ? >* Could we have a solution for writing `width: 90%` instead of `width: parent.width * 0.9` as well? > >Regards, >Konstantin > > >2016-02-18 14:50 GMT+04:00 Hausmann Simon >: > >Hi, > >A little while ago Lars and I proposed to introduce physical units in the QML language for use in QtQuick. The idea was to make it easier to write user interfaces that adapt to different display resolutions by "pinning" your UI to physical dimensions. For example > you could say > > Image { > source: "mypprofilephoto.png" > width: 5cm > height: 5cm > } > >and the image size in physical pixels would scale accordingly to always produce a 5cmx5cm profile image on the screen. The proposed units included "px", which was really an alias for nothing. > >We've had some very good discussions around this at last year's contributor summit as well as in smaller face-to-face discussions. The main feedback I recall was that this would seem like a nice feature on paper but in practice people create their resolution > independent interfaces using the current "pixels" and a scale factor that they introduce in a qml file or as a context property. That's another way of saying that perhaps the feature wouldn't really find any use, which is fair :). Instead the desire was expressed > that making it _easier_ to scale "logical" pixels in the application would perhaps be better. > >So today during a discussion another idea came up: > >(1) In order to make it really easy to scale "logical" pixels without having to introduce your own context property or factor in a .qml file that you multiply everywhere, we could turn the regular "pixels" in QtQuick into truly logical pixels that scale with > an application wide (or window wide) factor. So Image { width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 physical pixels on a x2 display. This assumes the availability of API to change this mapping. > >(2) In the events where you still _want_ to use physical pixels, you could use "px" units. > >So at first nothing would change for app developers at all because we map logical pixels to physical pixels. But >if you'd like to, you could opt into changing this mapping and having a relatively easy fallback to physical pixels using for example the "px" unit. We might as well offer the other physical units anyway, that probably causes little to no harm. > >What do you think? > >Simon >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development > > > > > > > > > > From krnekit at gmail.com Thu Feb 18 12:35:32 2016 From: krnekit at gmail.com (Nikita Krupenko) Date: Thu, 18 Feb 2016 13:35:32 +0200 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: 2016-02-18 12:50 GMT+02:00 Hausmann Simon : > (1) In order to make it really easy to scale "logical" pixels without having to introduce your own context property or factor in a .qml file that you multiply everywhere, we could turn the regular "pixels" in QtQuick into truly logical pixels that scale with an application wide (or window wide) factor. So Image { width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 physical pixels on a x2 display. This assumes the availability of API to change this mapping. > > (2) In the events where you still _want_ to use physical pixels, you could use "px" units. > > So at first nothing would change for app developers at all because we map logical pixels to physical pixels. But > if you'd like to, you could opt into changing this mapping and having a relatively easy fallback to physical pixels using for example the "px" unit. We might as well offer the other physical units anyway, that probably causes little to no harm. Isn't (1) already done with Qt::AA_EnableHighDpiScaling? Though disabling this feature for some items would be useful, like for Canvas, which is broken now with this scaling. From mike.krus at kdab.com Thu Feb 18 12:36:27 2016 From: mike.krus at kdab.com (Mike Krus) Date: Thu, 18 Feb 2016 11:36:27 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: <428C6DBD-F3B6-4D16-AC21-5FD3AE094B9B@kdab.com> Hi so (1) is what happens on iOS/OSX retina displays already right? and (2) lets you turn it off? Question then would be: would you ever need to mix? If not, then having a global/window switch would be a lot easier than putting px everywhere… And if you do want to mix, but mostly use px, then setting some default to px and then adding something like ‘pt’ in specific places may make sense? Mike > On 18 Feb 2016, at 10:50, Hausmann Simon wrote: > > Hi, > > A little while ago Lars and I proposed to introduce physical units in the QML language for use in QtQuick. The idea was to make it easier to write user interfaces that adapt to different display resolutions by "pinning" your UI to physical dimensions. For example you could say > > Image { > source: "mypprofilephoto.png" > width: 5cm > height: 5cm > } > > and the image size in physical pixels would scale accordingly to always produce a 5cmx5cm profile image on the screen. The proposed units included "px", which was really an alias for nothing. > > We've had some very good discussions around this at last year's contributor summit as well as in smaller face-to-face discussions. The main feedback I recall was that this would seem like a nice feature on paper but in practice people create their resolution independent interfaces using the current "pixels" and a scale factor that they introduce in a qml file or as a context property. That's another way of saying that perhaps the feature wouldn't really find any use, which is fair :). Instead the desire was expressed that making it _easier_ to scale "logical" pixels in the application would perhaps be better. > > So today during a discussion another idea came up: > > (1) In order to make it really easy to scale "logical" pixels without having to introduce your own context property or factor in a .qml file that you multiply everywhere, we could turn the regular "pixels" in QtQuick into truly logical pixels that scale with an application wide (or window wide) factor. So Image { width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 physical pixels on a x2 display. This assumes the availability of API to change this mapping. > > (2) In the events where you still _want_ to use physical pixels, you could use "px" units. > > So at first nothing would change for app developers at all because we map logical pixels to physical pixels. But > if you'd like to, you could opt into changing this mapping and having a relatively easy fallback to physical pixels using for example the "px" unit. We might as well offer the other physical units anyway, that probably causes little to no harm. > > What do you think? > > Simon > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK +44-1625-809908 Mobile: +44 7833 491941 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3859 bytes Desc: not available URL: From jeisecke at saltation.de Thu Feb 18 12:42:43 2016 From: jeisecke at saltation.de (Nils Jeisecke) Date: Thu, 18 Feb 2016 12:42:43 +0100 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: On Thu, Feb 18, 2016 at 11:50 AM, Hausmann Simon wrote: >I recall was that this would seem like a nice feature on paper but in practice >people create their resolution independent interfaces using the current >"pixels" and a scale factor that they introduce in a qml file or as a context property. This is the approach I'm using. However this adds lots and lots of property bindings, is tedious to write and looks ugly. So some alternative mechanism would be splendid. It should however be possible to change that scaling value on the fly - I think this would be necessary in multi-screen / multi-dpi environments. Nils From mitch.curtis at theqtcompany.com Thu Feb 18 12:59:50 2016 From: mitch.curtis at theqtcompany.com (Curtis Mitch) Date: Thu, 18 Feb 2016 11:59:50 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+mitch.curtis=theqtcompany.com at qt-project.org] On Behalf Of Nikita > Krupenko > Sent: Thursday, 18 February 2016 12:36 PM > To: development at qt-project.org > Subject: Re: [Development] Scalable UIs in QtQuick (take 2) > > 2016-02-18 12:50 GMT+02:00 Hausmann Simon > : > > (1) In order to make it really easy to scale "logical" pixels without > having to introduce your own context property or factor in a .qml file > that you multiply everywhere, we could turn the regular "pixels" in > QtQuick into truly logical pixels that scale with an application wide (or > window wide) factor. So Image { width: 100 ... } will scale automatically > from 100 logical pixels to maybe 200 physical pixels on a x2 display. This > assumes the availability of API to change this mapping. > > > > (2) In the events where you still _want_ to use physical pixels, you > could use "px" units. > > > > So at first nothing would change for app developers at all because we > > map logical pixels to physical pixels. But if you'd like to, you could > opt into changing this mapping and having a relatively easy fallback to > physical pixels using for example the "px" unit. We might as well offer > the other physical units anyway, that probably causes little to no harm. > > Isn't (1) already done with Qt::AA_EnableHighDpiScaling? > [snip] This was exactly my thought. I wonder if this functionality is still needed now that we have the high DPI support. _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Morten.Sorvig at theqtcompany.com Thu Feb 18 13:05:38 2016 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Thu, 18 Feb 2016 12:05:38 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: <1ABE7D74-43B1-40B9-B1C0-0F0EE847A0C0@digia.com> > On 18 Feb 2016, at 12:35, Nikita Krupenko wrote: > > 2016-02-18 12:50 GMT+02:00 Hausmann Simon : >> (1) In order to make it really easy to scale "logical" pixels without having to introduce your own context property or factor in a .qml file that you multiply everywhere, we could turn the regular "pixels" in QtQuick into truly logical pixels that scale with an application wide (or window wide) factor. So Image { width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 physical pixels on a x2 display. This assumes the availability of API to change this mapping. >> >> (2) In the events where you still _want_ to use physical pixels, you could use "px" units. >> >> So at first nothing would change for app developers at all because we map logical pixels to physical pixels. But >> if you'd like to, you could opt into changing this mapping and having a relatively easy fallback to physical pixels using for example the "px" unit. We might as well offer the other physical units anyway, that probably causes little to no harm. > > Isn't (1) already done with Qt::AA_EnableHighDpiScaling? Though > disabling this feature for some items would be useful, like for > Canvas, which is broken now with this scaling. This is indeed what is done for that flag and on OS X and iOS. In that sense logical pixels are already supported. “px” could be added, but what are the use cases? You almost never want to have small content on high-DPI display. I see doing custom scaling in the application as a possible one. As a minor platform note, “px” would not be guaranteed to be physical pixels on Apple operating systems. There can be further resolution virtualization, for example when setting a scaled resolution for the display. Morten From ritt.ks at gmail.com Thu Feb 18 13:20:11 2016 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Thu, 18 Feb 2016 15:20:11 +0300 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: <1ABE7D74-43B1-40B9-B1C0-0F0EE847A0C0@digia.com> References: <1ABE7D74-43B1-40B9-B1C0-0F0EE847A0C0@digia.com> Message-ID: Yet another question: when we write Item { id: item; width: 5cm }, what would item.width return? value expressed in logical pixels? Konstantin 2016-02-18 15:05 GMT+03:00 Sorvig Morten : > > > On 18 Feb 2016, at 12:35, Nikita Krupenko wrote: > > > > 2016-02-18 12:50 GMT+02:00 Hausmann Simon < > Simon.Hausmann at theqtcompany.com>: > >> (1) In order to make it really easy to scale "logical" pixels without > having to introduce your own context property or factor in a .qml file that > you multiply everywhere, we could turn the regular "pixels" in QtQuick into > truly logical pixels that scale with an application wide (or window wide) > factor. So Image { width: 100 ... } will scale automatically from 100 > logical pixels to maybe 200 physical pixels on a x2 display. This assumes > the availability of API to change this mapping. > >> > >> (2) In the events where you still _want_ to use physical pixels, you > could use "px" units. > >> > >> So at first nothing would change for app developers at all because we > map logical pixels to physical pixels. But > >> if you'd like to, you could opt into changing this mapping and having a > relatively easy fallback to physical pixels using for example the "px" > unit. We might as well offer the other physical units anyway, that probably > causes little to no harm. > > > > Isn't (1) already done with Qt::AA_EnableHighDpiScaling? Though > > disabling this feature for some items would be useful, like for > > Canvas, which is broken now with this scaling. > > This is indeed what is done for that flag and on OS X and iOS. In that > sense logical pixels are already supported. > > “px” could be added, but what are the use cases? You almost never want to > have small content on high-DPI display. I see doing custom scaling in the > application as a possible one. > > As a minor platform note, “px” would not be guaranteed to be physical > pixels > on Apple operating systems. There can be further resolution virtualization, > for example when setting a scaled resolution for the display. > > Morten > > > > _______________________________________________ > 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 theqtcompany.com Thu Feb 18 13:46:53 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 18 Feb 2016 12:46:53 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: <1ABE7D74-43B1-40B9-B1C0-0F0EE847A0C0@digia.com>, Message-ID: Hi, Yes, that is correct. But you could compare for example: if (item.width == 5cm) { ... } The idea is that this it build this into the numeric literals. Simon ________________________________ From: Development on behalf of Konstantin Ritt Sent: Thursday, February 18, 2016 13:20 To: Sorvig Morten Cc: Qt Project Development Mailing-List Subject: Re: [Development] Scalable UIs in QtQuick (take 2) Yet another question: when we write Item { id: item; width: 5cm }, what would item.width return? value expressed in logical pixels? Konstantin 2016-02-18 15:05 GMT+03:00 Sorvig Morten >: > On 18 Feb 2016, at 12:35, Nikita Krupenko > wrote: > > 2016-02-18 12:50 GMT+02:00 Hausmann Simon >: >> (1) In order to make it really easy to scale "logical" pixels without having to introduce your own context property or factor in a .qml file that you multiply everywhere, we could turn the regular "pixels" in QtQuick into truly logical pixels that scale with an application wide (or window wide) factor. So Image { width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 physical pixels on a x2 display. This assumes the availability of API to change this mapping. >> >> (2) In the events where you still _want_ to use physical pixels, you could use "px" units. >> >> So at first nothing would change for app developers at all because we map logical pixels to physical pixels. But >> if you'd like to, you could opt into changing this mapping and having a relatively easy fallback to physical pixels using for example the "px" unit. We might as well offer the other physical units anyway, that probably causes little to no harm. > > Isn't (1) already done with Qt::AA_EnableHighDpiScaling? Though > disabling this feature for some items would be useful, like for > Canvas, which is broken now with this scaling. This is indeed what is done for that flag and on OS X and iOS. In that sense logical pixels are already supported. "px" could be added, but what are the use cases? You almost never want to have small content on high-DPI display. I see doing custom scaling in the application as a possible one. As a minor platform note, "px" would not be guaranteed to be physical pixels on Apple operating systems. There can be further resolution virtualization, for example when setting a scaled resolution for the display. Morten _______________________________________________ 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 andre at familiesomers.nl Thu Feb 18 14:07:03 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 18 Feb 2016 14:07:03 +0100 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: <56C5C1F7.5070900@familiesomers.nl> Op 18/02/2016 om 11:50 schreef Hausmann Simon: > Hi, > > A little while ago Lars and I proposed to introduce physical units in the QML language for use in QtQuick. The idea was to make it easier to write user interfaces that adapt to different display resolutions by "pinning" your UI to physical dimensions. For example you could say > > Image { > source: "mypprofilephoto.png" > width: 5cm > height: 5cm > } > > and the image size in physical pixels would scale accordingly to always produce a 5cmx5cm profile image on the screen. The proposed units included "px", which was really an alias for nothing. > > We've had some very good discussions around this at last year's contributor summit as well as in smaller face-to-face discussions. The main feedback I recall was that this would seem like a nice feature on paper but in practice people create their resolution independent interfaces using the current "pixels" and a scale factor that they introduce in a qml file or as a context property. That's another way of saying that perhaps the feature wouldn't really find any use, which is fair :). Instead the desire was expressed that making it _easier_ to scale "logical" pixels in the application would perhaps be better. > > So today during a discussion another idea came up: > > (1) In order to make it really easy to scale "logical" pixels without having to introduce your own context property or factor in a .qml file that you multiply everywhere, we could turn the regular "pixels" in QtQuick into truly logical pixels that scale with an application wide (or window wide) factor. So Image { width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 physical pixels on a x2 display. This assumes the availability of API to change this mapping. > > (2) In the events where you still _want_ to use physical pixels, you could use "px" units. > > So at first nothing would change for app developers at all because we map logical pixels to physical pixels. But > if you'd like to, you could opt into changing this mapping and having a relatively easy fallback to physical pixels using for example the "px" unit. We might as well offer the other physical units anyway, that probably causes little to no harm. > > What do you think? > I'd like to have something like that. I would be wonderful to be able to specify units, even if you do that through some scaling factor. Please also take font sizes into account though. Sizes specified in points are supposed to be a physical size I'd think (it is defined as 1/72th of an inch). I'd really like it if those actually come out in the right size. I am thinking about an unusual case: print templates. I have been (and still am) working on a print engine that uses QML for its print templates. In such templates, physical size is much more relevant than pixel size. After all, every printer has a different resolution, but you want your printout to look the same anyway. André From tero.kojo at theqtcompany.com Thu Feb 18 14:07:33 2016 From: tero.kojo at theqtcompany.com (Kojo Tero) Date: Thu, 18 Feb 2016 13:07:33 +0000 Subject: [Development] QtCon in Berlin 1st-4th September 2016 Message-ID: Hello Qt Contributors, Please mark your calendars for QtCon in Berlin 1st - 4th September. The venue will be the bcc in the center of Berlin. QtCon is not just this year's major Free and Open Source event in Europe for participants with an interest in Qt, but also a unique forum for talks and knowledge sharing in a state-of-the-art environment. We are bringing together our annual events KDE Akademy, VideoLAN Developer Days, Qt Contributors' Summit, FSFE Summit and KDAB Qt training day under one roof. https://qtcon.org/ The call for talks and workshops will be posted later in the spring, as will be the registration guidelines. Best regards, Tero Kojo -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at theqtcompany.com Thu Feb 18 14:20:45 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 18 Feb 2016 14:20:45 +0100 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: <20160218132045.GC28638@troll08.it.local> On Thu, Feb 18, 2016 at 10:50:22AM +0000, Hausmann Simon wrote: > What do you think? > that it's a bit silly that we're having this discussion *yet again*. ;) http://thread.gmane.org/gmane.comp.lib.qt.devel/6572/focus=6807 i find the point about using arcminutes as a truly device independent unit particularly relevant. i thought we discussed this topic somewhere in more depth already, but i failed to find anything relevant. From edward.welbourne at theqtcompany.com Thu Feb 18 15:24:43 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 18 Feb 2016 14:24:43 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: <20160218132045.GC28638@troll08.it.local> References: , <20160218132045.GC28638@troll08.it.local> Message-ID: > On Thu, Feb 18, 2016 at 10:50:22AM +0000, Simon Hausmann wrote: >> What do you think? Oswald Buddenhagen replied: > that it's a bit silly that we're having this discussion *yet again*. ;) > http://thread.gmane.org/gmane.comp.lib.qt.devel/6572/focus=6807 I was amused that the discussion related to "retina" displays. It took a while to work out that these were just high-resolution screens - I was initially thinking that this was about directly projecting onto the user's retina, which would be kinda cool. It would also drive home, with particular force, the point in Tony van Eerd's first response in the thread: > i find the point about using arcminutes as a truly device independent > unit particularly relevant. See also: https://www.w3.org/TR/css3-values/#absolute-lengths Traditionally, displayed things have had their sizes measured in physical units that have been more-or-less approximate in practice due to the vagueness of nominal pixel sizes. Designers have stipulated the sizes of things to be big enough to read, making various assumptions about screen resolution and the distance of the reader from the screen. They have also, to some degree, chosen to subdivide the available space into aesthetically pleasing proportions, for which percentages are useful. These days we also need to make sure displayed objects are big enough to put a finger on reliably. (There are etymological reasons for the inch to be a unit that represents the size of a thumb, making it apt for this last purpose; but practical use, quite apart from the silliness of archaic units, has eliminated this as an option.) (Shawn Rutledge mentioned the problem of projectors, troubled by the question of how far the projector is from the screen. That measure is in fact less important than the ratio of that to the typical, or rear-most, audience member's distance from the screen. That ratio is consequently the ratio of angular sizes of an item on the screen, between the audience member and the projector.) To meet all the actual use cases, we need three different *kinds* of size for things: * fraction of the available display area - good for top-level sub-division of the space an app has at its disposal to work in; * physical size on screen - to make sure a finger shall actually hit a button reliably and not be mistaken for hitting the next button over; and * angular size subtended at the user's eye - for readability. Conventional length units address the second of these reasonably well; and percentages do the first perfectly. The first should not normally be in need of end-user customisation. The second may need a little - some folk's fingers are smaller than others and maybe, when I'm using a stylus, I'll be happy to have the stylus-size determine the "finger" size we need. The last needs lots - folk with eagle eyes want more detail on the screen at a time, while others need the text nice and big to be able to read it at all. Most sound uses of the first kind of size won't overlap with the other two; but these two overlap plenty. The user needs to be able to read the text on a button and to be able to operate the button. For the multi-touch case, things to be touched need to be far enough apart that distinct chubby fingers can actually hit them at the same time; they and related items need to be visually intelligible, too. All the while, everything wants to be small to fit on a screen that fits in a user's hands. It's a complex problem both to specify clearly what the designer's needs are and to implement in a way that meets those needs. Those trying to develop a solution would do well to talk to relevant experts in the CSS WG, Eddy. From mathias at taschenorakel.de Thu Feb 18 15:24:55 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Thu, 18 Feb 2016 15:24:55 +0100 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: <56C5D437.9090704@taschenorakel.de> Am 18.02.2016 um 11:50 schrieb Hausmann Simon: > A little while ago Lars and I proposed to introduce physical units in the QML language for use in QtQuick. The idea was to make it easier to write user interfaces that adapt to different display resolutions by "pinning" your UI to physical dimensions. For example you could say > > Image { > source: "mypprofilephoto.png" > width: 5cm > height: 5cm > } > Being able to annotate numbers with units might be a generally useful feature for QML. The obvious use cases are distances and positions. Another use case are timer and animation intervals. Finally I am thinking of this industrial touch UI demo we show at trade shows. The QML based DSL driving it would benefit greatly if one could easily express the physical unit of each number (ampere, newton, meters, ...) and if one could preserve this information during calculations. Of course I am going slightly off-topic with this thoughts... Ciao, Mathias From edward.welbourne at theqtcompany.com Thu Feb 18 15:37:13 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 18 Feb 2016 14:37:13 +0000 Subject: [Development] Units in QML In-Reply-To: <56C5D437.9090704@taschenorakel.de> References: , <56C5D437.9090704@taschenorakel.de> Message-ID: > Of course I am going slightly off-topic with this thoughts... So let's have a change of Subject. > The QML based DSL driving it would benefit greatly if one could easily > express the physical unit of each number (ampere, newton, meters, ...) > and if one could preserve this information during calculations. I've played with this problem [0] extensively. It turns out to be quite tricky to do at all well, in general. There are some amusing petty problems (like dealing with the milli kg - a base unit has a quantifier in its name, which makes quantifiers trickier to get right). There are units that conflate - a torque should be measured in Nm and not expressed in J even though J = Nm is normally valid (in one case, the force and displacement are perpendicular, in the other parallel). It's fairly easy to do a clumsy job - [0] just reduces everything to base units and leaves the user to divide by a composite unit they'd sooner have seen used - but hard to do a systematically good job. My design notes for how to do better are the worst case of second system effect I've ever embarked on. Here be dragons. [0] https://github.com/ediosyncratic/study.py/tree/master/value Eddy. From ekke at ekkes-corner.org Thu Feb 18 16:08:34 2016 From: ekke at ekkes-corner.org (ekke) Date: Thu, 18 Feb 2016 16:08:34 +0100 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: <56C5D437.9090704@taschenorakel.de> References: <56C5D437.9090704@taschenorakel.de> Message-ID: <56C5DE72.1040607@ekkes-corner.org> I'm just evaluating mobile development with Qt 5.6Beta, qt.labs.controls, Android, Material and have set Qt::AA_EnableHighDpiScaling now it would be cool to "think" in cm or mm for my device (BlackBerry PRIV, Android 5.1.1) with 544 ppi, where devicePixelRatio (scaling factor) is 3.5 would be more intuitive to define Rectangle { width: 1 cm height: 0.6 cm } compared with Rectangle { width: 64 height: 40 } and then to calculate: 64 * 3.5 = 224 / 544 ppi = 0.41 in = 1.04 cm BTW: HighDpiScaling works great. added images (to compare sizes with Rectangles): test.png (64x40) test at 2x.png (128x80) test at 3x.png (192x120) test at 4x.png (256x160) devicePixelRatio of 3.5 was exactly in the middle between @3x and @4x Qt uses the next larger one: test at 4x.png and scaled it down to 3.5 tested this also with a much larger image - all is well done. great work ! -- ekke (ekkehard gentz) independent software architect international development native mobile business apps BlackBerry 10 | Qt Mobile (Android, iOS) workshops - trainings - bootcamps *BlackBerry Elite Developer BlackBerry Platinum Enterprise Partner* max-josefs-platz 30, D-83022 rosenheim, germany mailto:ekke at ekkes-corner.org blog: http://ekkes-corner.org apps and more: http://appbus.org twitter: @ekkescorner skype: ekkes-corner LinkedIn: http://linkedin.com/in/ekkehard/ Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490 -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.blanc at nmc-company.com Thu Feb 18 17:20:13 2016 From: julien.blanc at nmc-company.com (Julien Blanc) Date: Thu, 18 Feb 2016 17:20:13 +0100 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: <20160218132045.GC28638@troll08.it.local> References: <20160218132045.GC28638@troll08.it.local> Message-ID: <1455812413.2621.54.camel@nmc-company.com> Le jeudi 18 février 2016 à 14:20 +0100, Oswald Buddenhagen a écrit : > On Thu, Feb 18, 2016 at 10:50:22AM +0000, Hausmann Simon wrote: > > What do you think? > > > that it's a bit silly that we're having this discussion *yet again*. ;) > http://thread.gmane.org/gmane.comp.lib.qt.devel/6572/focus=6807 > > i find the point about using arcminutes as a truly device independent > unit particularly relevant. i thought we discussed this topic somewhere > in more depth already, but i failed to find anything relevant. I made some experiments with that, but unfortunately, that’s far from a perfect solution either. The main problem is that the readability of items depends on both the size and the number of pixels (to say it differently : you can write smaller text on a retina display while still being human-readable). So you get to consider both, which basically completely breaks the purpose of angle oriented units. Add to that that some elements (eg touch buttons) must have some minimal physical size to be usable. There’s also the issue that the « typical eye distance » information is missing on devices (a 24“ computer fullhd monitor has not the same eye distance than a 24” fullhd TV, despite having the same physical characteristics). For now, i reverted to sailfish silica-like approach, which i found gives the best result (basically, use theme-given sizes for your elements, and layout them accordingly). However, some smarter logic than just a basic scaling factor could be implemented to automagically compute theme values depending on the device (instead or in complement of device-specific themes). Regards, Julien -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhaumann at kde.org Thu Feb 18 23:08:22 2016 From: dhaumann at kde.org (Dominik Haumann) Date: Thu, 18 Feb 2016 23:08:22 +0100 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: On Thu, Feb 18, 2016 at 11:50 AM, Hausmann Simon wrote: > Hi, > > A little while ago Lars and I proposed to introduce physical units in the QML language for use in QtQuick. The idea was to make it easier to write user interfaces that adapt to different display resolutions by "pinning" your UI to physical dimensions. For example you could say > > Image { > source: "mypprofilephoto.png" > width: 5cm > height: 5cm > } Interestingly, I once wrote a Value class [1] that does exactly this. It allows to have constructs like this: Value v1(2, Unit::Centimeter); Value v2 = Value::fromString("1in)"; // see also: toString() Value v3 = v1 * v2; // Restult is 4.45 cm bool v2GreaterThanv1 = v2 > v1; // = true Value v4(0, Unit::Millimeter); Value v5 = v1 / v4; // v5.isValid() == false I use this in tikzkit, a wysiwyg pgf/TikZ LaTeX diagram editor, to show the perfectly correct sizes on screen (works really well). The Value class supports only pt, cm, mm, and inch (could of course be extended. And conversion is fast, see the lookup implementation). Having this as integral part of the application. I never have to worry about unit conversion errors, since the result is always correct, and the unit type is even preserved when the user explicitly typed something in cm or inch etc. So from my experience, writing this Value class was a very good decision. Although I personally don't program much in QML, I still believe that something like this (or similar) is probably worth it (in QML and probably overall in Qt). Based on this, I also have a Pos class, that hast two Value members: x() and y(), so all what I said above is also valid for 2D positions (see [2]). Cheers, Dominik [1] https://github.com/dhaumann/tikzkit/blob/master/src/core/utils/Value.h [2] https://github.com/dhaumann/tikzkit/blob/master/src/core/utils/Pos.h From krnekit at gmail.com Fri Feb 19 09:48:43 2016 From: krnekit at gmail.com (Nikita Krupenko) Date: Fri, 19 Feb 2016 10:48:43 +0200 Subject: [Development] Scalable UIs in QtQuick (take 2) Message-ID: 2016-02-19 0:08 GMT+02:00 Dominik Haumann : > Interestingly, I once wrote a Value class [1] that does exactly this. > It allows to have > constructs like this: > > Value v1(2, Unit::Centimeter); > Value v2 = Value::fromString("1in)"; // see also: toString() > Value v3 = v1 * v2; // Restult is 4.45 cm > bool v2GreaterThanv1 = v2 > v1; // = true > > Value v4(0, Unit::Millimeter); > Value v5 = v1 / v4; // v5.isValid() == false > So from my experience, writing this Value class was a very good decision. > Although I personally don't program much in QML, I still believe that something > like this (or similar) is probably worth it (in QML and probably overall in Qt). In C++11 (which is required for Qt 5.7+) user-defined literals can simplify usage of units. Good video from QtDD on this: https://www.youtube.com/watch?v=39Yrk3FVFIc From gunnar at sletta.org Fri Feb 19 10:44:02 2016 From: gunnar at sletta.org (Gunnar Sletta) Date: Fri, 19 Feb 2016 10:44:02 +0100 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: <1ABE7D74-43B1-40B9-B1C0-0F0EE847A0C0@digia.com> References: <1ABE7D74-43B1-40B9-B1C0-0F0EE847A0C0@digia.com> Message-ID: <2E4B5E32-AE5E-4ECE-89F3-3049DAE9C40F@sletta.org> > On 18 Feb 2016, at 13:05, Sorvig Morten wrote: > >> >> On 18 Feb 2016, at 12:35, Nikita Krupenko wrote: >> >> 2016-02-18 12:50 GMT+02:00 Hausmann Simon : >>> (1) In order to make it really easy to scale "logical" pixels without having to introduce your own context property or factor in a .qml file that you multiply everywhere, we could turn the regular "pixels" in QtQuick into truly logical pixels that scale with an application wide (or window wide) factor. So Image { width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 physical pixels on a x2 display. This assumes the availability of API to change this mapping. >>> >>> (2) In the events where you still _want_ to use physical pixels, you could use "px" units. >>> >>> So at first nothing would change for app developers at all because we map logical pixels to physical pixels. But >>> if you'd like to, you could opt into changing this mapping and having a relatively easy fallback to physical pixels using for example the "px" unit. We might as well offer the other physical units anyway, that probably causes little to no harm. >> >> Isn't (1) already done with Qt::AA_EnableHighDpiScaling? Though >> disabling this feature for some items would be useful, like for >> Canvas, which is broken now with this scaling. > > This is indeed what is done for that flag and on OS X and iOS. In that > sense logical pixels are already supported. > > “px” could be added, but what are the use cases? You almost never want to > have small content on high-DPI display. I see doing custom scaling in the > application as a possible one. One obvious usecase which always comes back to haunt is when those logical units need to be translated to actual pixels, such as when dealing with graphics. Up until some time ago, Something::size() was enough to decide the pixel dimension of things. Now every piece of code needs to also know about device pixel ratio and that needs to passed down to image loaders, icon generators, texture produces, shader effects, blur algorithms, autotest-screengrabbers, etc. It is rather error prone. We've had probably hundreds of bugs in Qt over the last few years in various corner cases where the DPI has to be carried along to make the size into the actual size, and people still are running into them on a regular basis. And this is a bug chase that will never stop because users will always run into cases where they thought carrying the size was enough, but also need the DPR. If the objects operated in pixel sizes, the problem could be solved centrally once and for all. There are plenty of ways, as long as we don't violate that princible. Options include theme specific pixel sizes, using "units" in QML that end up being "blah cm" -> "blah * 32" in practice, where units can include arcseconds, points or physical sizes. Using a global scale factor to pixels ratio that is applied in QML before passed to objects is also fine, using percent of parent/sibling. Either one is a valid option, but the values we pass to our graphical objects, like Rectangle {} and Canvas {} and the values Item::width() report back should be in actual pixels, same with the values we pass to QQuickImageProvider and every were else. The logical scaling is something that happens in the app in QML. Otherwise, the bug tirade never ends :) (And to avoid the additional confusion, we should probably avoid having Font.pointSize, so that fonts operate in the same coordinate space as the other objects. The pixel size of a point should be accessible through other means when required). It has been deemed too much work to fix widgets and styles, but Qt Quick doesn't need to commit to the same mistake. cheers, Gunnar > > As a minor platform note, “px” would not be guaranteed to be physical pixels > on Apple operating systems. There can be further resolution virtualization, > for example when setting a scaled resolution for the display. > > Morten > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at theqtcompany.com Fri Feb 19 11:42:30 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Fri, 19 Feb 2016 10:42:30 +0000 Subject: [Development] Qt 5.6.0 missing change files Message-ID: Hi all, We are planning to release Qt 5.6.0 RC really soon, hoping at the beginning of next week. Final is targeted to be released within 2 weeks as well so we need to get all change files done & in before it. Following change files are still missing: qtandroidextras qtbase (ongoing, see https://codereview.qt-project.org/#/c/149325/ ) qtdeclarative qtdoc (qtenginio) qtmacextras qtmultimedia qtquickcontrols (qtscript) qtsensors qtsvg qttranslations qttools qtwayland qtwaylandqtwebchannel qtwebsockets qtx11extras qtxmlpatterns Maintainers, make sure needed change files are done & in before wed 24th Feb br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morten.Sorvig at theqtcompany.com Fri Feb 19 12:42:51 2016 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Fri, 19 Feb 2016 11:42:51 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: <20160218132045.GC28638@troll08.it.local> Message-ID: <4CB4F8B2-628F-4A70-8A97-CE5E7DCF8441@digia.com> > On 18 Feb 2016, at 15:24, Welbourne Edward wrote: > > To meet all the actual use cases, we need three different *kinds* of > size for things: > * fraction of the available display area - good for top-level > sub-division of the space an app has at its disposal to work in; > * physical size on screen - to make sure a finger shall actually hit a > button reliably and not be mistaken for hitting the next button > over; and > * angular size subtended at the user's eye - for readability. > I argue the situation is under control :) Display area sub-division is handled by the Qt layouts. Touch targets need to be larger than mouse targets: this is a styling issue which I think we are handling/can handle. But the important thing is that both these two are handled in logical pixels; display density does not factor into it. For you final point, I think the right place to solve this is at the hardware and OS level, and not in QML which should keep operating in logical pixels. The hardware designer selects a display panel with a certain pixel density and provides a scale factor/dpi value through the OS, taking into account the intended viewing distance for the device. For example, these are the pixel densities (pixels-per-inch) for three Apple devices: (all of them are 2x) iPhone : 326 iPad : 264 iMac (5K) : 218 The effect is that a 10x10 square will have a smaller visual size on the handheld devices, corresponding to the closer viewing distance. We need some support for cases where Qt is close to the hardware (embedded use cases), but I would argue the current scaling support (as configurable via QT_SCALE_FACTOR or AA_EnableHighDpiScaling) is sufficient here, at least for a first release. There are also cases where OS support is wanting, and we do more work in Qt. - Morten From Shawn.Rutledge at theqtcompany.com Fri Feb 19 13:45:57 2016 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Fri, 19 Feb 2016 12:45:57 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: <7CB99938-F754-4B3C-9762-6EC396C5C243@digia.com> > On 18 Feb 2016, at 11:50, Hausmann Simon wrote: > > Hi, > > A little while ago Lars and I proposed to introduce physical units in the QML language for use in QtQuick. The idea was to make it easier to write user interfaces that adapt to different display resolutions by "pinning" your UI to physical dimensions. For example you could say > > Image { > source: "mypprofilephoto.png" > width: 5cm > height: 5cm > } > > and the image size in physical pixels would scale accordingly to always produce a 5cmx5cm profile image on the screen. The proposed units included "px", which was really an alias for nothing. > > We've had some very good discussions around this at last year's contributor summit as well as in smaller face-to-face discussions. The main feedback I recall was that this would seem like a nice feature on paper but in practice people create their resolution independent interfaces using the current "pixels" and a scale factor that they introduce in a qml file or as a context property. That's another way of saying that perhaps the feature wouldn't really find any use, which is fair :). Instead the desire was expressed that making it _easier_ to scale "logical" pixels in the application would perhaps be better. > > So today during a discussion another idea came up: > > (1) In order to make it really easy to scale "logical" pixels without having to introduce your own context property or factor in a .qml file that you multiply everywhere, we could turn the regular "pixels" in QtQuick into truly logical pixels that scale with an application wide (or window wide) factor. So Image { width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 physical pixels on a x2 display. This assumes the availability of API to change this mapping. > > (2) In the events where you still _want_ to use physical pixels, you could use "px" units. > > So at first nothing would change for app developers at all because we map logical pixels to physical pixels. But > if you'd like to, you could opt into changing this mapping and having a relatively easy fallback to physical pixels using for example the "px" unit. We might as well offer the other physical units anyway, that probably causes little to no harm. > > What do you think? I thought support for units was on the way a long time ago. How soon can it be finished? It would be great to have extensible unit support, and not all of them need to be direct physical units either. I think we need some unit which is related to the user’s choice of default font size somehow (e.g. Android provides global settings for this, and so do some desktop environments). CSS specifies it in various ways: https://www.w3.org/TR/css3-values/#font-relative-lengths It took me a while to find again the reference to measuring in arc-minutes, but that is here: http://article.gmane.org/gmane.comp.lib.qt.devel/6863 But it’s easier to empirically adjust readability of text than to measure the user's ability to perceive a single dot; eye charts are made with text for a reason I think. And what’s really more important than designers being able to specify what they want, is for the end user to have total control. It’s very important to have a zoom control of some sort - preferably both a global one (like the Android font size setting - do we even respect that yet? or like Qt’s various confusing env variables), and a more-local one for correcting design mistakes (just like ctrl+ / ctrl- or ctrl-mousewheel in your browser, same thing in Creator’s editor, in our help system, etc). For the global setting, the easiest thing for the user is to specify a default font size - that’s a subjective choice based on preference as well as visual acuity and distance. So maybe the best way to design the visual aspect of most applications is to use font-based units (like the em space) for physical sizes, but for touch UIs, to also use physical measurements as a minimum. e.g. width: Math.max(7mm, 3em) - will it be possible, or can we have nicer syntax? For example a button must be able to fit its text (unless it’s so long that the designer plans for it to be elided), but the button must also be at least 7mm in both dimensions to be touchable. The user should choose the text size, while the designer should choose the minimum widget size, and otherwise tie physical size to text size. If the user chooses too large a text size, then less stuff fits on the screen… that’s the usual tradeoff. And Qt has always had decent layout management, to make use of increasing or diminishing space effectively. Qt’s lack of non-integral devicePixelRatio has been problematic. Users need fine-grained control without tweaking individual applications and style sheets and preferences, all in app-specific incompatible ways. Fortunately non-integral scaling is supposed to be getting done eventually (but it should have been several years ago). Unfortunately it’s done by means of too many confusing env variables which seem to change with every Qt version. In my ideal graphics toolkit, pixels don’t exist, the default unit was always millimeters since day zero, and sizes are guaranteed accurate on every device as long as zoom = 1. If you want to scale differently, you have to be explicit about it in your app, or the user can override it at runtime into an explicit “uncalibrated” mode. It’s like the Postscript doctrine, except that they chose points instead of millimeters. And it’s highly compatible with the fact that the OpenGL coordinate system is normalized by default, and you must determine the total transformation matrix from model to normalized to screen coordinates yourself. Much nonsense has been perpetuated because designers refuse to forget about the pixels and move into the post-pixel world of high-resolution displays. In the limit, pixels are like molecules in paper, or grains in film emulsion, with varying size depending on the substance; but we require an independent unit of precision, rather than molecular precision, to measure pieces of paper and text and graphics on the page. Even on low-resolution displays, the reason for antialiasing is to render graphics the same way a camera would see them. You will perceive the image smoothly enough without worrying about the color and alignment of every grain on the film. But although the majority apparently still disagrees with that (for how much longer, I wonder?), and even though entrenched legacy apps are making a real transition impossible, we at least need a way of achieving it by choice in new apps. And a selection of various proper units in QML would be a great feature in both the ideal world and the real one, as long as we strive to ensure that physical units are accurate by default, and can be calibrated accurately on hardware that doesn’t tell the truth about its own scaling. I also wish the ctrl+ / ctrl- / ctrl-mousewheel way of tweaking the zoom factor in individual widgets was more universal, because designers and developers will always choose bad sizes sometimes, no matter what tools are available to them. From Morten.Sorvig at theqtcompany.com Fri Feb 19 13:57:45 2016 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Fri, 19 Feb 2016 12:57:45 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: <2E4B5E32-AE5E-4ECE-89F3-3049DAE9C40F@sletta.org> References: <1ABE7D74-43B1-40B9-B1C0-0F0EE847A0C0@digia.com> <2E4B5E32-AE5E-4ECE-89F3-3049DAE9C40F@sletta.org> Message-ID: <7C5F3A23-6629-432F-A24D-D3F03D2D43F5@digia.com> > On 19 Feb 2016, at 10:44, Gunnar Sletta wrote: > > > One obvious usecase which always comes back to haunt is when those logical units need to be translated to actual pixels, such as when dealing with graphics. Up until some time ago, Something::size() was enough to decide the pixel dimension of things. Now every piece of code needs to also know about device pixel ratio and that needs to passed down to image loaders, icon generators, texture produces, shader effects, blur algorithms, autotest-screengrabbers, etc. It is rather error prone. The alternative is that the scale factor needs to be propagated upwards: into styles, layout specifications, animation velocities, etc. I’m not sure this is dramatically less error prone overall. For shaders and blurs: the inputs needs to be scaled, right? The algorithms themselves run entirely in device pixel space. I agree that code that deals with both logical and actual pixels tend to become complicated. We should seek to minimize this as much as possible. > > We've had probably hundreds of bugs in Qt over the last few years in various corner cases where the DPI has to be carried along to make the size into the actual size, and people still are running into them on a regular basis. And this is a bug chase that will never stop because users will always run into cases where they thought carrying the size was enough, but also need the DPR. However the failure mode for many, if not most, of these bugs is good: you get pixelated/blurry graphics instead of tiny UI elements and broken layouts. So I think you are overstating the brokenness a bit. We had Qt Creator running and looking good almost from day one, see the April 2013 screenshot of X11 Creator at goo.gl/8h1d4q. > > > If the objects operated in pixel sizes, the problem could be solved centrally once and for all. There are plenty of ways, as long as we don't violate that princible. Options include theme specific pixel sizes, using "units" in QML that end up being "blah cm" -> "blah * 32" in practice, where units can include arcseconds, points or physical sizes. Using a global scale factor to pixels ratio that is applied in QML before passed to objects is also fine, using percent of parent/sibling. Either one is a valid option, but the values we pass to our graphical objects, like Rectangle {} and Canvas {} and the values Item::width() report back should be in actual pixels, same with the values we pass to QQuickImageProvider and every were else. The logical scaling is something that happens in the app in QML. Otherwise, the bug tirade never ends :) But now the application code still has to deal with two coordinate systems, and there is no compatibility for legacy / dpi-unaware code. Are we sure there would be less bugs? Except that maybe the bugs are moved from the Qt code base to the application code bases. In addition we'll have a different set of bugs in Qt that needs to be fixed: hardcoded pixel values like the velocities in quickflickablebehavior_p.h now needs to be scaled by he target display DPI. > > (And to avoid the additional confusion, we should probably avoid having Font.pointSize, so that fonts operate in the same coordinate space as the other objects. The pixel size of a point should be accessible through other means when required). We agree on this point, except that the devicePixelRatio approach has pixelSize meaning logical pixels :) > > It has been deemed too much work to fix widgets and styles, but Qt Quick doesn't need to commit to the same mistake. At the very least the current solution should be recognized as an “alternative solution" and not labeled a “mistake”. - Morten From edward.welbourne at theqtcompany.com Fri Feb 19 18:27:18 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Fri, 19 Feb 2016 17:27:18 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: <7CB99938-F754-4B3C-9762-6EC396C5C243@digia.com> References: , <7CB99938-F754-4B3C-9762-6EC396C5C243@digia.com> Message-ID: Shawn said: > So maybe the best way to design the visual aspect of most applications > is to use font-based units (like the em space) for physical sizes, but > for touch UIs, to also use physical measurements as a minimum. > e.g. width: Math.max(7mm, 3em) - will it be possible, or can we have > nicer syntax? For example a button must be able to fit its text > (unless it’s so long that the designer plans for it to be elided), but > the button must also be at least 7mm in both dimensions to be > touchable. I think this means designers need to be specifying *bounds on* the sizes of things, rather than the sizes themselves. This image shouldn't be bigger, in either direction, than the screen; that button must be big enough for a finger to hit it. The rendering engine is then left to work out what *actual* size to make each thing. Unfortunately, graphical design historically took for granted that the designer knows the size of the page, hence also can control the size of every thing on the page. That actually failed to work for folk with poor visual accuity even when it was happening on the mashed carcasses of trees, but it's how many designers still think. They just "have to" adjust their design to several different sizes of page^W screen now; and still think, for each page-size, that they should control the exact size of everything on the page. Anyone who has learned TeX knows that's the wrong way to think, but it's not a cultural lesson that's made much progress into the graphical design community. > The user should choose the text size, Indeed - ideally as a device setup action that configures a device-global parameter that all apps get to work with. All font sizes should be specified in terms of the user-selected "comfortable size to read" for a font. The screen size, measured in this font-sizes's em unit, may be rather small for some users and significantly bigger for other users. That's, to some degree, true today - different devices have different-sized screens after all - but we'd need designers to start taking it seriously and stop thinking they can "fix" this by having the design respond to the "physical" size (in mm) of the screen. As you point out, physical pixels are now so small they're irrelevant; we used to care about them because pixelation was a visual wart of our displays, but that's long since passed. Only virtual pixels, or some equivalent unit (such as the "comfortable font size" - some suitable fraction of which can be used as the virtual pixel size), are relevant now. Eddy. From ekke at ekkes-corner.org Fri Feb 19 18:35:47 2016 From: ekke at ekkes-corner.org (ekke) Date: Fri, 19 Feb 2016 18:35:47 +0100 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: <7CB99938-F754-4B3C-9762-6EC396C5C243@digia.com> Message-ID: <56C75273.9080107@ekkes-corner.org> Am 19.02.16 um 18:27 schrieb Welbourne Edward: >> The user should choose the text size, > Indeed - ideally as a device setup action that configures a > device-global parameter that all apps get to work with. All font sizes > should be specified in terms of the user-selected "comfortable size to > read" for a font. The screen size, measured in this font-sizes's em > unit, may be rather small for some users and significantly bigger for > other users. That's, to some degree, true today - different devices > have different-sized screens after all - but we'd need designers to > start taking it seriously and stop thinking they can "fix" this by > having the design respond to the "physical" size (in mm) of the screen. In BlackBerry Cascades implementation I'm never using points or pixels, I'm using predefined sizes: TitleText SubtitleText Smalltext LargeText XLargeText BigText ... ... and I was sure on all BB10 devices with different dpi the font size is the same. It's not so easy not to re-think for Qt 5.6 and using px I like the qt.labs.controls where I can use colors as accent or primary etc. that's intuitive -- ekke (ekkehard gentz) independent software architect international development native mobile business apps BlackBerry 10 | Qt Mobile (Android, iOS) workshops - trainings - bootcamps *BlackBerry Elite Developer BlackBerry Platinum Enterprise Partner* max-josefs-platz 30, D-83022 rosenheim, germany mailto:ekke at ekkes-corner.org blog: http://ekkes-corner.org apps and more: http://appbus.org twitter: @ekkescorner skype: ekkes-corner LinkedIn: http://linkedin.com/in/ekkehard/ Steuer-Nr: 156/220/30931 FA Rosenheim, UST-ID: DE189929490 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at theqtcompany.com Fri Feb 19 22:01:02 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Fri, 19 Feb 2016 21:01:02 +0000 Subject: [Development] Supported platforms for Qt 5.8 Message-ID: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> Hi, Now that 5.7 is branched, I'd like to propose that we update our list of supported compilers and platforms for Qt 5.8. After some discussions with different people, here's an initial proposal from my side: * We drop support for VS2012. This implicitly drops support for WEC2013. Reason is that the compiler is still having rather large problems with it's C++11 support. I hope that we could serve the WEC market rather well with 5.6 and 5.7 for the years to come. In the end, the benefit we get with dropping the compiler will hopefully outweigh the cost (loosing WEC) by a good margin. * We drop support for Vista. Vista has a market share that is below 2%, and again we have 5.6 to cover that platform for the next 3 years. * We should upgrade MingW to a newer version, possibly based on gcc 5.2 * No changes for Windows Phone, we continue to support 8.1 and 10. * We require the latest Xcode toolchain and OS X on the Mac for compiling (see separate mailing list thread). We support deployment to OS X 10.9 and later (dropping 10.8) * On iOS, we also require the latest Xcode toolchain for compiling. We continue with iOS 7 as the minimum supported version for deployment. * Minimum version for Android is probably going to stay with 4.1 (as with 5.7). We would like to add a 64 bit build to the CI * We continue to support QNX 6.6 * On Linux, we will investigate upgrading our packaging machine from RHEL 6.6 to RHEL 7. We should also try to update our Ubuntu CI machines to 16.04 once it's released. Let me know if you see larger problems with these changes. Cheers, Lars From andreas.holzammer at kdab.com Sat Feb 20 07:58:09 2016 From: andreas.holzammer at kdab.com (Andreas Holzammer) Date: Sat, 20 Feb 2016 07:58:09 +0100 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> Message-ID: <56C80E81.3040602@kdab.com> Hi, What about support for Windows IoT, which might be the successor of WEC. Are there plans to support this? Thank you Andy Am 19.02.2016 um 22:01 schrieb Knoll Lars: > Hi, > > Now that 5.7 is branched, I'd like to propose that we update our list of supported compilers and platforms for Qt 5.8. After some discussions with different people, here's an initial proposal from my side: > > * We drop support for VS2012. This implicitly drops support for WEC2013. Reason is that the compiler is still having rather large problems with it's C++11 support. I hope that we could serve the WEC market rather well with 5.6 and 5.7 for the years to come. In the end, the benefit we get with dropping the compiler will hopefully outweigh the cost (loosing WEC) by a good margin. > > * We drop support for Vista. Vista has a market share that is below 2%, and again we have 5.6 to cover that platform for the next 3 years. > > * We should upgrade MingW to a newer version, possibly based on gcc 5.2 > > * No changes for Windows Phone, we continue to support 8.1 and 10. > > * We require the latest Xcode toolchain and OS X on the Mac for compiling (see separate mailing list thread). We support deployment to OS X 10.9 and later (dropping 10.8) > > * On iOS, we also require the latest Xcode toolchain for compiling. We continue with iOS 7 as the minimum supported version for deployment. > > * Minimum version for Android is probably going to stay with 4.1 (as with 5.7). We would like to add a 64 bit build to the CI > > * We continue to support QNX 6.6 > > * On Linux, we will investigate upgrading our packaging machine from RHEL 6.6 to RHEL 7. We should also try to update our Ubuntu CI machines to 16.04 once it's released. > > > Let me know if you see larger problems with these changes. > > Cheers, > Lars > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Andreas Holzammer | andreas.holzammer at kdab.com | Senior 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: 4070 bytes Desc: S/MIME Cryptographic Signature URL: From joseph.w.crowell at gmail.com Sat Feb 20 08:09:19 2016 From: joseph.w.crowell at gmail.com (Joseph Crowell) Date: Sat, 20 Feb 2016 17:09:19 +1000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> Message-ID: <56C8111F.50807@gmail.com> What about VS 2013? On 20/02/2016 7:01 AM, Knoll Lars wrote: > Hi, > > Now that 5.7 is branched, I'd like to propose that we update our list of supported compilers and platforms for Qt 5.8. After some discussions with different people, here's an initial proposal from my side: > > * We drop support for VS2012. This implicitly drops support for WEC2013. Reason is that the compiler is still having rather large problems with it's C++11 support. I hope that we could serve the WEC market rather well with 5.6 and 5.7 for the years to come. In the end, the benefit we get with dropping the compiler will hopefully outweigh the cost (loosing WEC) by a good margin. > > * We drop support for Vista. Vista has a market share that is below 2%, and again we have 5.6 to cover that platform for the next 3 years. > > * We should upgrade MingW to a newer version, possibly based on gcc 5.2 > > * No changes for Windows Phone, we continue to support 8.1 and 10. > > * We require the latest Xcode toolchain and OS X on the Mac for compiling (see separate mailing list thread). We support deployment to OS X 10.9 and later (dropping 10.8) > > * On iOS, we also require the latest Xcode toolchain for compiling. We continue with iOS 7 as the minimum supported version for deployment. > > * Minimum version for Android is probably going to stay with 4.1 (as with 5.7). We would like to add a 64 bit build to the CI > > * We continue to support QNX 6.6 > > * On Linux, we will investigate upgrading our packaging machine from RHEL 6.6 to RHEL 7. We should also try to update our Ubuntu CI machines to 16.04 once it's released. > > > Let me know if you see larger problems with these changes. > > Cheers, > Lars > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tuukka.turunen at theqtcompany.com Sat Feb 20 08:19:41 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Sat, 20 Feb 2016 07:19:41 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <56C80E81.3040602@kdab.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com>, <56C80E81.3040602@kdab.com> Message-ID: > Andreas Holzammer kirjoitti 20.2.2016 kello 8.58: > > Hi, > > What about support for Windows IoT, which might be the successor of WEC. > Are there plans to support this? > We already have support for Windows 10 / WinRT, so it is a rather straightforward task to do when there is need. Maurice has been looking into Windows 10 IoT Core a bit and if I recall correctly there still are some performance etc issues in the Windows IoT. It is the natural successor of WEC, and supporting it makes sense, perhaps to some extent even with Qt 5.8 - if that is seen feasible? Yours, Tuukka > Thank you > > Andy > >> Am 19.02.2016 um 22:01 schrieb Knoll Lars: >> Hi, >> >> Now that 5.7 is branched, I'd like to propose that we update our list of supported compilers and platforms for Qt 5.8. After some discussions with different people, here's an initial proposal from my side: >> >> * We drop support for VS2012. This implicitly drops support for WEC2013. Reason is that the compiler is still having rather large problems with it's C++11 support. I hope that we could serve the WEC market rather well with 5.6 and 5.7 for the years to come. In the end, the benefit we get with dropping the compiler will hopefully outweigh the cost (loosing WEC) by a good margin. >> >> * We drop support for Vista. Vista has a market share that is below 2%, and again we have 5.6 to cover that platform for the next 3 years. >> >> * We should upgrade MingW to a newer version, possibly based on gcc 5.2 >> >> * No changes for Windows Phone, we continue to support 8.1 and 10. >> >> * We require the latest Xcode toolchain and OS X on the Mac for compiling (see separate mailing list thread). We support deployment to OS X 10.9 and later (dropping 10.8) >> >> * On iOS, we also require the latest Xcode toolchain for compiling. We continue with iOS 7 as the minimum supported version for deployment. >> >> * Minimum version for Android is probably going to stay with 4.1 (as with 5.7). We would like to add a 64 bit build to the CI >> >> * We continue to support QNX 6.6 >> >> * On Linux, we will investigate upgrading our packaging machine from RHEL 6.6 to RHEL 7. We should also try to update our Ubuntu CI machines to 16.04 once it's released. >> >> >> Let me know if you see larger problems with these changes. >> >> Cheers, >> Lars >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > > -- > Andreas Holzammer | andreas.holzammer at kdab.com | Senior 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 From tuukka.turunen at theqtcompany.com Sat Feb 20 08:22:57 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Sat, 20 Feb 2016 07:22:57 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <56C8111F.50807@gmail.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com>, <56C8111F.50807@gmail.com> Message-ID: <3E6C78BC-3DA0-42A6-B7D1-F8D37CA22BD3@theqtcompany.com> > Joseph Crowell kirjoitti 20.2.2016 kello 9.09: > > What about VS 2013? > Based on our understanding it offers quite decent C++11 support and should stay supported. Yours, Tuukka >> On 20/02/2016 7:01 AM, Knoll Lars wrote: >> Hi, >> >> Now that 5.7 is branched, I'd like to propose that we update our list of supported compilers and platforms for Qt 5.8. After some discussions with different people, here's an initial proposal from my side: >> >> * We drop support for VS2012. This implicitly drops support for WEC2013. Reason is that the compiler is still having rather large problems with it's C++11 support. I hope that we could serve the WEC market rather well with 5.6 and 5.7 for the years to come. In the end, the benefit we get with dropping the compiler will hopefully outweigh the cost (loosing WEC) by a good margin. >> >> * We drop support for Vista. Vista has a market share that is below 2%, and again we have 5.6 to cover that platform for the next 3 years. >> >> * We should upgrade MingW to a newer version, possibly based on gcc 5.2 >> >> * No changes for Windows Phone, we continue to support 8.1 and 10. >> >> * We require the latest Xcode toolchain and OS X on the Mac for compiling (see separate mailing list thread). We support deployment to OS X 10.9 and later (dropping 10.8) >> >> * On iOS, we also require the latest Xcode toolchain for compiling. We continue with iOS 7 as the minimum supported version for deployment. >> >> * Minimum version for Android is probably going to stay with 4.1 (as with 5.7). We would like to add a 64 bit build to the CI >> >> * We continue to support QNX 6.6 >> >> * On Linux, we will investigate upgrading our packaging machine from RHEL 6.6 to RHEL 7. We should also try to update our Ubuntu CI machines to 16.04 once it's released. >> >> >> Let me know if you see larger problems with these changes. >> >> Cheers, >> Lars >> _______________________________________________ >> 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 Maurice.Kalinowski at theqtcompany.com Sat Feb 20 08:28:08 2016 From: Maurice.Kalinowski at theqtcompany.com (Kalinowski Maurice) Date: Sat, 20 Feb 2016 07:28:08 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com>, <56C80E81.3040602@kdab.com> Message-ID: > > > Andreas Holzammer kirjoitti 20.2.2016 > kello 8.58: > > > > Hi, > > > > What about support for Windows IoT, which might be the successor of > WEC. > > Are there plans to support this? > > > > We already have support for Windows 10 / WinRT, so it is a rather > straightforward task to do when there is need. Maurice has been looking into > Windows 10 IoT Core a bit and if I recall correctly there still are some > performance etc issues in the Windows IoT. It is the natural successor of > WEC, and supporting it makes sense, perhaps to some extent even with Qt > 5.8 - if that is seen feasible? > [Kalinowski Maurice] You are way too fast :) Indeed we support Windows 10 IoT Core via WinRT. Situation is improving, but there are mostly two issues we have limited impact on: 1. Our version of ANGLE has limited (if at all ) support for feature set 9.1. Microsoft is tackling this in their version and we will try out a new version from upstream soon (actually Olli has been working on it this week). That at least will help us to use the WARP software renderer 2. Driver situation on Win10 IoT Core devices is horrible right now. That is to be expected and we have to see how it improves over time. But that is also the reason Microsoft is investing into ANGLE as an intermediate step. So Lars was a bit generic with the Windows Phone 8.1 and Windows 10 for Mobile (no, it's not called Windows Phone 10 ;) ). But he rather implied the Qt for WinRT version, which has support for all those including the embedded offering. BR, Maurice > Yours, > > Tuukka > > > Thank you > > > > Andy > > > >> Am 19.02.2016 um 22:01 schrieb Knoll Lars: > >> Hi, > >> > >> Now that 5.7 is branched, I'd like to propose that we update our list of > supported compilers and platforms for Qt 5.8. After some discussions with > different people, here's an initial proposal from my side: > >> > >> * We drop support for VS2012. This implicitly drops support for WEC2013. > Reason is that the compiler is still having rather large problems with it's C++11 > support. I hope that we could serve the WEC market rather well with 5.6 and > 5.7 for the years to come. In the end, the benefit we get with dropping the > compiler will hopefully outweigh the cost (loosing WEC) by a good margin. > >> > >> * We drop support for Vista. Vista has a market share that is below 2%, > and again we have 5.6 to cover that platform for the next 3 years. > >> > >> * We should upgrade MingW to a newer version, possibly based on gcc > >> 5.2 > >> > >> * No changes for Windows Phone, we continue to support 8.1 and 10. > >> > >> * We require the latest Xcode toolchain and OS X on the Mac for > >> compiling (see separate mailing list thread). We support deployment > >> to OS X 10.9 and later (dropping 10.8) > >> > >> * On iOS, we also require the latest Xcode toolchain for compiling. We > continue with iOS 7 as the minimum supported version for deployment. > >> > >> * Minimum version for Android is probably going to stay with 4.1 (as > >> with 5.7). We would like to add a 64 bit build to the CI > >> > >> * We continue to support QNX 6.6 > >> > >> * On Linux, we will investigate upgrading our packaging machine from > RHEL 6.6 to RHEL 7. We should also try to update our Ubuntu CI machines to > 16.04 once it's released. > >> > >> > >> Let me know if you see larger problems with these changes. > >> > >> Cheers, > >> Lars > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > > > > > -- > > Andreas Holzammer | andreas.holzammer at kdab.com | Senior 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 > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Jake.Petroules at theqtcompany.com Sat Feb 20 08:38:27 2016 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Sat, 20 Feb 2016 07:38:27 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <56C80E81.3040602@kdab.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <56C80E81.3040602@kdab.com> Message-ID: <15B8CB18-D3BC-41B2-B038-3501344ABD7A@theqtcompany.com> On Feb 19, 2016, at 10:58 PM, Andreas Holzammer > wrote: Hi, What about support for Windows IoT, which might be the successor of WEC. Are there plans to support this? Isn't this implicitly covered under Universal Windows Platform (Windows 10 + WinRT APIs)? Thank you Andy Am 19.02.2016 um 22:01 schrieb Knoll Lars: Hi, Now that 5.7 is branched, I'd like to propose that we update our list of supported compilers and platforms for Qt 5.8. After some discussions with different people, here's an initial proposal from my side: * We drop support for VS2012. This implicitly drops support for WEC2013. Reason is that the compiler is still having rather large problems with it's C++11 support. I hope that we could serve the WEC market rather well with 5.6 and 5.7 for the years to come. In the end, the benefit we get with dropping the compiler will hopefully outweigh the cost (loosing WEC) by a good margin. * We drop support for Vista. Vista has a market share that is below 2%, and again we have 5.6 to cover that platform for the next 3 years. +1. Did Vista *ever* have more market share than XP or any of its successors? * We should upgrade MingW to a newer version, possibly based on gcc 5.2 * No changes for Windows Phone, we continue to support 8.1 and 10. * We require the latest Xcode toolchain and OS X on the Mac for compiling (see separate mailing list thread). We support deployment to OS X 10.9 and later (dropping 10.8) +1 * On iOS, we also require the latest Xcode toolchain for compiling. We continue with iOS 7 as the minimum supported version for deployment. "Continue" with iOS 7? It's currently iOS 6 in both 5.7 and dev branches. However, I wholeheartedly approve bumping it to 7. This puts us at a minimum of "last four releases" (by the time 5.8 is released) for both OS X and iOS. However I'd argue that iOS's schedule should be treated a little more aggressively given its extremely fast upgrade cycle compared to all other platforms. As of February 8th, 2016, the iOS version distribution (as measured by Apple - https://developer.apple.com/support/app-store/) is as follows: - iOS 9 - 77% - iOS 8 - 17% - iOS 7 and earlier - 6% By the time Qt 5.8 is released, iOS 10 will have just been released and iOS 8's market share will almost certainly less than 5%, as iOS 7's is now. In that case is there really much point supporting iOS 7 (or even 8)? iOS 8 was one of the biggest releases API-wise and so we would be able to reduce effort significantly by dropping v7. The current version of Xcode also provides no simulators for iOS prior to 8.1. * Minimum version for Android is probably going to stay with 4.1 (as with 5.7). We would like to add a 64 bit build to the CI +1 for 64-bit! * We continue to support QNX 6.6 * On Linux, we will investigate upgrading our packaging machine from RHEL 6.6 to RHEL 7. We should also try to update our Ubuntu CI machines to 16.04 once it's released. Let me know if you see larger problems with these changes. Cheers, Lars _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Andreas Holzammer | andreas.holzammer at kdab.com | Senior 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 -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Sat Feb 20 11:33:21 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 20 Feb 2016 11:33:21 +0100 Subject: [Development] GCC-built Qt 5.6 can't be used with Clang Message-ID: Hello, I built Qt dev branch with GCC. Then I tried to use it to build any trivial shared library with Clang: stephen at hal:/tmp/qmake$ make CXX=clang++ LINK=clang++ -B makeobj[0]: Entering directory `/tmp/qmake' /home/stephen/dev/prefix/qtbase/bin/qmake -o Makefile qmake.pro clang++ -c -pipe -g -std=gnu++11 -std=c++11 -Wall -W -D_REENTRANT -fPIC - DQT_CORE_LIB -I. -I/home/stephen/dev/prefix/qtbase/include - I/home/stephen/dev/prefix/qtbase/include/QtCore -I. - I/home/stephen/dev/prefix/qtbase/mkspecs/linux-g++ -o thelib.o thelib.cpp rm -f libthelib.so.1.0.0 libthelib.so libthelib.so.1 libthelib.so.1.0 clang++ -Wl,-rpath,/home/stephen/dev/prefix/qtbase/lib -shared -Wl,- soname,libthelib.so.1 -o libthelib.so.1.0.0 thelib.o - L/home/stephen/dev/prefix/qtbase/lib -lQt5Core -lpthread /usr/bin/ld: thelib.o: relocation R_X86_64_32 against `qt_version_tag' can not be used when making a shared object; recompile with -fPIC thelib.o: error adding symbols: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) Makefile:147: recipe for target 'libthelib.so.1.0.0' failed make: *** [libthelib.so.1.0.0] Error 1 makeobj[0]: Leaving directory `/tmp/qmake' 1) The qt_version_tag is new in Qt 5.6, so I assume this happens with that Qt version too. 2) If I compile with -DQT_NO_VERSION_TAGGING, then the link succeeds. Reading the preprocessor code in qtversiontagging, I can see why. 3) Is it deliberate that GCC-built Qt can no longer be used with Clang? I haven't seen mailing list discussion confirming that. 4) If that should still be possible, are clients expected to add their own define of -DQT_NO_VERSION_TAGGING? It could be added to the qmake/cmake files if so for these mixing conditions. Thanks, Steve. From Simon.Hausmann at theqtcompany.com Sat Feb 20 11:48:12 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Sat, 20 Feb 2016 10:48:12 +0000 Subject: [Development] GCC-built Qt 5.6 can't be used with Clang In-Reply-To: References: Message-ID: <20160220104811.5857363.1803.60535@theqtcompany.com> Hi, Hmm, change ‎https://codereview.qt-project.org/#/c/147846/ was supposed to fix this issue. ‎The subject of the email refers to 5.6 but in the body you say that you are building the dev branch. If it is the latter, could it be that the fix hasn't hit dev yet? Simon Original Message From: Stephen Kelly Sent: Saturday, February 20, 2016 11:33 To: development at qt-project.org Subject: [Development] GCC-built Qt 5.6 can't be used with Clang Hello, I built Qt dev branch with GCC. Then I tried to use it to build any trivial shared library with Clang: stephen at hal:/tmp/qmake$ make CXX=clang++ LINK=clang++ -B makeobj[0]: Entering directory `/tmp/qmake' /home/stephen/dev/prefix/qtbase/bin/qmake -o Makefile qmake.pro clang++ -c -pipe -g -std=gnu++11 -std=c++11 -Wall -W -D_REENTRANT -fPIC - DQT_CORE_LIB -I. -I/home/stephen/dev/prefix/qtbase/include - I/home/stephen/dev/prefix/qtbase/include/QtCore -I. - I/home/stephen/dev/prefix/qtbase/mkspecs/linux-g++ -o thelib.o thelib.cpp rm -f libthelib.so.1.0.0 libthelib.so libthelib.so.1 libthelib.so.1.0 clang++ -Wl,-rpath,/home/stephen/dev/prefix/qtbase/lib -shared -Wl,- soname,libthelib.so.1 -o libthelib.so.1.0.0 thelib.o - L/home/stephen/dev/prefix/qtbase/lib -lQt5Core -lpthread /usr/bin/ld: thelib.o: relocation R_X86_64_32 against `qt_version_tag' can not be used when making a shared object; recompile with -fPIC thelib.o: error adding symbols: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) Makefile:147: recipe for target 'libthelib.so.1.0.0' failed make: *** [libthelib.so.1.0.0] Error 1 makeobj[0]: Leaving directory `/tmp/qmake' 1) The qt_version_tag is new in Qt 5.6, so I assume this happens with that Qt version too. 2) If I compile with -DQT_NO_VERSION_TAGGING, then the link succeeds. Reading the preprocessor code in qtversiontagging, I can see why. 3) Is it deliberate that GCC-built Qt can no longer be used with Clang? I haven't seen mailing list discussion confirming that. 4) If that should still be possible, are clients expected to add their own define of -DQT_NO_VERSION_TAGGING? It could be added to the qmake/cmake files if so for these mixing conditions. Thanks, Steve. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From steveire at gmail.com Sat Feb 20 11:58:27 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 20 Feb 2016 11:58:27 +0100 Subject: [Development] GCC-built Qt 5.6 can't be used with Clang References: <20160220104811.5857363.1803.60535@theqtcompany.com> Message-ID: Hausmann Simon wrote: > Hi, > > Hmm, change ‎https://codereview.qt-project.org/#/c/147846/ was supposed > to fix this issue. > > ‎The subject of the email refers to 5.6 but in the body you say that you > are building the dev branch. If it is the latter, could it be that the fix > hasn't hit dev yet? Indeed, I built without that patch. Perhaps it is indeed fixed in 5.6 already (but I didn't check). Reading the commit message and the commit I don't have the expertise to know. Thanks, Steve. From mardy at users.sourceforge.net Sat Feb 20 13:19:44 2016 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Sat, 20 Feb 2016 15:19:44 +0300 Subject: [Development] Making ItemSelectionModel more useful Message-ID: <56C859E0.8030400@users.sourceforge.net> Hi all! Since Qt 5.5, the QItemSelectionModel class is exposed to QML as ItemSelectionModel (in the QtQml.Models module): http://doc.qt.io/qt-5/qml-qtqml-models-itemselectionmodel.html Apart from having almost no documentation, this component seems to be rather hard to use in QML: its methods work with QModelIndex (while all the models I've ever used in QML just speak row numbers) or QItemSelection, which I believe is not usable in QML at all (at least, it's not documented as a QML component). I understand that the reason for all of this is that QItemSelectionModel is a class originally created for C++ consumption, and that the QModelIndex makes a lot of sense there. However, I would argue that the QML version is hardly usable. As I see it, either this class gets a "model" property and methods which operate on integers (row numbers), or QModelIndex and QItemSelection need to become first class citizens in QML as well. I guess that having Q_GADGET is already a huge step forward, but we should also have a generic way to turn a model+rowNumber into a QModelIndex: maybe a global method Qt.makeIndex(model, row), which would also work on all models supported by the QML engine? Are there any plans about this, or what would be the best way to address this? Ciao, Alberto From filippocucchetto at gmail.com Sat Feb 20 14:18:16 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Sat, 20 Feb 2016 14:18:16 +0100 Subject: [Development] Fwd: Making ItemSelectionModel more useful In-Reply-To: References: <56C859E0.8030400@users.sourceforge.net> Message-ID: Hi Alberto, i think that QModelIndex has been brought in for dealing with TreeViews and hierachical item models. To be honest AFAIK you can manipulate QModelIndexes from QML. You can test for validity or obtaining its row or column and model. The implementation should be here Given that, i'm not totaly sold for a double interface (rows and indexes). I prefear dropping support for using integers for rows/columns from the components in QtQuickControls (TableView, ComboBox etc). This would also morph the styleData.index from being a int to a QModelIndex. F. 2016-02-20 13:19 GMT+01:00 Alberto Mardegan : > Hi all! > Since Qt 5.5, the QItemSelectionModel class is exposed to QML as > ItemSelectionModel (in the QtQml.Models module): > > http://doc.qt.io/qt-5/qml-qtqml-models-itemselectionmodel.html > > Apart from having almost no documentation, this component seems to be > rather hard to use in QML: its methods work with QModelIndex (while all > the models I've ever used in QML just speak row numbers) or > QItemSelection, which I believe is not usable in QML at all (at least, > it's not documented as a QML component). > > I understand that the reason for all of this is that QItemSelectionModel > is a class originally created for C++ consumption, and that the > QModelIndex makes a lot of sense there. However, I would argue that the > QML version is hardly usable. > > As I see it, either this class gets a "model" property and methods which > operate on integers (row numbers), or QModelIndex and QItemSelection > need to become first class citizens in QML as well. I guess that having > Q_GADGET is already a huge step forward, but we should also have a > generic way to turn a model+rowNumber into a QModelIndex: maybe a global > method Qt.makeIndex(model, row), which would also work on all models > supported by the QML engine? > > Are there any plans about this, or what would be the best way to address > this? > > Ciao, > Alberto > > _______________________________________________ > 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 sviatoslavf at icloud.com Sat Feb 20 18:03:24 2016 From: sviatoslavf at icloud.com (Sviatoslav Feshchenko) Date: Sat, 20 Feb 2016 12:03:24 -0500 Subject: [Development] Decimal arithmetic classes proposal Message-ID: I would like to propose to develop classes for inclusion in the Qt library to support general decimal arithmetic. Such classes would be useful for financial and other applications requiring accurate decimal arithmetic. The intent is to develop the classes as a wrapper around the existing decNumber C library which is a reference implementation of the standards applicable to decimal arithmetic (IEEE 754). More details about the library can be found here: http://speleotrove.com/decimal/ The deNumber library is available under ICU permissive licence, the details of which are here: http://source.icu-project.org/repos/icu/icu/trunk/license.html Before I spend the time developing the classes, I would like to ask the Qt developer community if such classes would be in line with Qt interest and if my contribution would have a reasonable chance of being accepted into the library assuming high quality Qt standards compliant code. There would be at least 3 classes: QDouble - decimal encoded compressed format 64 bits long QQuad - decimal encoded compressed format 128 bits long QDecimal - arbitrary precision There may be a 4th class: QDecimalContext - a context for computations which maintain details about precision of the result (number of digits, exponent etc.), rounding algorithm to use, and record if any errors occurred during an operation. I may implement this class as part of the 3 main decimal classes rather than as a separate class. The decision is yet to be made. Please advise if such classes would be of value to Qt and if I should spend the time developing them. Sviatoslav From thiago.macieira at intel.com Sat Feb 20 19:04:18 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 20 Feb 2016 10:04:18 -0800 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> Message-ID: <26003352.DV2JlzaxBy@tjmaciei-mobl4> On sexta-feira, 19 de fevereiro de 2016 21:01:02 PST Knoll Lars wrote: > * We drop support for VS2012. This implicitly drops support for WEC2013. > Reason is that the compiler is still having rather large problems with it's > C++11 support. I hope that we could serve the WEC market rather well with > 5.6 and 5.7 for the years to come. In the end, the benefit we get with > dropping the compiler will hopefully outweigh the cost (loosing WEC) by a > good margin. This buys us: - delegating constructors - "explicit operator" member funcvtions - nsdmi - initializer_list (not uniform initialisation!) - raw strings - template alias (using ... = ...) - variadic templates It would buy us, if we raised to GCC 4.8 too: - deleted and defaulted members (nsdmi, delegating constructors, template aliases require GCC 4.7) Is it worth it? The only things I'd really want are intialiser lists and variadic templates. Note that without constexpr, initialiser lists' value is limited. (I'm assuming Clang minimum version 3.4, as found on FreeBSD, which is feature-complete for C++11) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Feb 20 19:11:36 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 20 Feb 2016 10:11:36 -0800 Subject: [Development] Decimal arithmetic classes proposal In-Reply-To: References: Message-ID: <2553403.EKspuydZXt@tjmaciei-mobl4> On sábado, 20 de fevereiro de 2016 12:03:24 PST Sviatoslav Feshchenko wrote: > I would like to propose to develop classes for inclusion in the Qt library > to support general decimal arithmetic. Such classes would be useful for > financial and other applications requiring accurate decimal arithmetic. The > intent is to develop the classes as a wrapper around the existing decNumber > C library which is a reference implementation of the standards applicable > to decimal arithmetic (IEEE 754). More details about the library can be > found here: http://speleotrove.com/decimal/ Hello Sviatoslav How is this different from from the Decimal TR? It's implemented in libstdc++. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3407.html. > Please advise if such classes would be of value to Qt and if I should spend > the time developing them. I'm not sure it should be in Qt. It might be more useful to make an independent library that works with other compilers besides GCC until C++17 comes along. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kde at carewolf.com Sat Feb 20 22:09:20 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sat, 20 Feb 2016 22:09:20 +0100 Subject: [Development] Supported platforms for Qt 5.8rt In-Reply-To: <26003352.DV2JlzaxBy@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <26003352.DV2JlzaxBy@tjmaciei-mobl4> Message-ID: <201602202209.20944.kde@carewolf.com> On Saturday 20 February 2016, Thiago Macieira wrote: > On sexta-feira, 19 de fevereiro de 2016 21:01:02 PST Knoll Lars wrote: > > * We drop support for VS2012. This implicitly drops support for WEC2013. > > Reason is that the compiler is still having rather large problems with > > it's C++11 support. I hope that we could serve the WEC market rather > > well with 5.6 and 5.7 for the years to come. In the end, the benefit we > > get with dropping the compiler will hopefully outweigh the cost (loosing > > WEC) by a good margin. > > This buys us: > > - delegating constructors > - "explicit operator" member funcvtions > - nsdmi > - initializer_list (not uniform initialisation!) > - raw strings > - template alias (using ... = ...) > - variadic templates > > It would buy us, if we raised to GCC 4.8 too: > - deleted and defaulted members > (nsdmi, delegating constructors, template aliases require GCC 4.7) > > Is it worth it? The only things I'd really want are intialiser lists and > variadic templates. Note that without constexpr, initialiser lists' value > is limited. > > (I'm assuming Clang minimum version 3.4, as found on FreeBSD, which is > feature-complete for C++11) Well, feature-complete'ish. I recently found out we need clang 3.5 to use deleted constructors in Chromium. Clang 3.4 has a bug which will cause it to claim deleted methods causes ambiguity with non-deleted methods. So if we opt for gcc 4.8, I would suggest demanding clang 3.5 as well. Best regards `Allan From thiago.macieira at intel.com Sun Feb 21 06:15:13 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 20 Feb 2016 21:15:13 -0800 Subject: [Development] Supported platforms for Qt 5.8rt In-Reply-To: <201602202209.20944.kde@carewolf.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <26003352.DV2JlzaxBy@tjmaciei-mobl4> <201602202209.20944.kde@carewolf.com> Message-ID: <2932609.kMHNNApRdD@tjmaciei-mobl4> On sábado, 20 de fevereiro de 2016 22:09:20 PST Allan Sandfeld Jensen wrote: > Well, feature-complete'ish. I recently found out we need clang 3.5 to use > deleted constructors in Chromium. Clang 3.4 has a bug which will cause it > to claim deleted methods causes ambiguity with non-deleted methods. So if > we opt for gcc 4.8, I would suggest demanding clang 3.5 as well. That would drop FreeBSD 10.2, which is the current stable release today. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at theqtcompany.com Sun Feb 21 08:01:57 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Sun, 21 Feb 2016 07:01:57 +0000 Subject: [Development] Supported platforms for Qt 5.8rt In-Reply-To: <2932609.kMHNNApRdD@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <26003352.DV2JlzaxBy@tjmaciei-mobl4> <201602202209.20944.kde@carewolf.com>, <2932609.kMHNNApRdD@tjmaciei-mobl4> Message-ID: <34E26E0B-3072-4AFA-858C-3B5209068B28@theqtcompany.com> > Thiago Macieira kirjoitti 21.2.2016 kello 7.15: > >> On sábado, 20 de fevereiro de 2016 22:09:20 PST Allan Sandfeld Jensen wrote: >> Well, feature-complete'ish. I recently found out we need clang 3.5 to use >> deleted constructors in Chromium. Clang 3.4 has a bug which will cause it >> to claim deleted methods causes ambiguity with non-deleted methods. So if >> we opt for gcc 4.8, I would suggest demanding clang 3.5 as well. > > That would drop FreeBSD 10.2, which is the current stable release today. > According to their release plans both 10.3 and 11.0 should be out well before Qt 5.8. Yours, Tuukka > -- > 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 holger at freyther.de Sun Feb 21 11:19:39 2016 From: holger at freyther.de (Holger Freyther) Date: Sun, 21 Feb 2016 11:19:39 +0100 Subject: [Development] Supported platforms for Qt 5.8rt In-Reply-To: <34E26E0B-3072-4AFA-858C-3B5209068B28@theqtcompany.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <26003352.DV2JlzaxBy@tjmaciei-mobl4> <201602202209.20944.kde@carewolf.com> <2932609.kMHNNApRdD@tjmaciei-mobl4> <34E26E0B-3072-4AFA-858C-3B5209068B28@theqtcompany.com> Message-ID: > On 21 Feb 2016, at 08:01, Turunen Tuukka wrote: > > >> >> That would drop FreeBSD 10.2, which is the current stable release today. >> > > According to their release plans both 10.3 and 11.0 should be out well before Qt 5.8. Is 10.3 going to upgrade clang? I would assume that stable/10 will stay with clang-3.4? From tuukka.turunen at theqtcompany.com Sun Feb 21 12:16:48 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Sun, 21 Feb 2016 11:16:48 +0000 Subject: [Development] Supported platforms for Qt 5.8rt In-Reply-To: References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <26003352.DV2JlzaxBy@tjmaciei-mobl4> <201602202209.20944.kde@carewolf.com> <2932609.kMHNNApRdD@tjmaciei-mobl4> <34E26E0B-3072-4AFA-858C-3B5209068B28@theqtcompany.com>, Message-ID: <622C83DA-DCEE-43CD-9683-80299F7B3491@theqtcompany.com> > Holger Freyther kirjoitti 21.2.2016 kello 12.19: > > >> On 21 Feb 2016, at 08:01, Turunen Tuukka wrote: >> >> >>> >>> That would drop FreeBSD 10.2, which is the current stable release today. >>> >> >> According to their release plans both 10.3 and 11.0 should be out well before Qt 5.8. > > Is 10.3 going to upgrade clang? I would assume that stable/10 will stay with clang-3.4? > I do not know their practices, but would expect that at least 11.0 updates to a more recent tool chain. C++ is moving along and we can not stick with (too) old compilers. Qt 5.6 LTS is a good choice for those who need to use older compilers. Yours, Tuukka From kde at carewolf.com Sun Feb 21 12:23:41 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sun, 21 Feb 2016 12:23:41 +0100 Subject: [Development] Supported platforms for Qt 5.8rt In-Reply-To: <2932609.kMHNNApRdD@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <201602202209.20944.kde@carewolf.com> <2932609.kMHNNApRdD@tjmaciei-mobl4> Message-ID: <201602211223.41598.kde@carewolf.com> On Sunday 21 February 2016, Thiago Macieira wrote: > On sábado, 20 de fevereiro de 2016 22:09:20 PST Allan Sandfeld Jensen wrote: > > Well, feature-complete'ish. I recently found out we need clang 3.5 to use > > deleted constructors in Chromium. Clang 3.4 has a bug which will cause it > > to claim deleted methods causes ambiguity with non-deleted methods. So > > if we opt for gcc 4.8, I would suggest demanding clang 3.5 as well. > > That would drop FreeBSD 10.2, which is the current stable release today. The same bug also affects XCode 6.0-6.2 (though they are based on 3.5svn). Requiring a newer xcode than that would mean requiring OS X 10.10 to build. It might be better to not rely on deleted methods. Which then makes the upgrade to gcc 4.8 slightly less attractive. Regards `Allan From marc.mutz at kdab.com Sun Feb 21 23:17:32 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 21 Feb 2016 23:17:32 +0100 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <26003352.DV2JlzaxBy@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <26003352.DV2JlzaxBy@tjmaciei-mobl4> Message-ID: <201602212317.32845.marc.mutz@kdab.com> My 0.02$: On Saturday 20 February 2016 19:04:18 Thiago Macieira wrote: > - delegating constructors This can help reduce code size (both source and executable) for types with many constructors. E.g. QTreeWidgetitem, or QStringView. > - "explicit operator" member funcvtions Safe bool operators, but there's a C++98 pattern for it. > - nsdmi Don't see how this is interesting for library implementation. > - initializer_list (not uniform initialisation!) Easily ifdef'ed. Not really interesing for library implementation. Uniform init, though, would simplifiy a lot of things. > - raw strings > - template alias (using ... = ...) Not interesting for library implementation. > - variadic templates Enables perfect forwarding. Highly desireable in API and implementation. > - deleted and defaulted members Of all of the above, probably the most desireable. We have a lot of places where we need to hand-implement special member functions, because they are deleted or deprecated by newer C++ versions. = default would greatly simplify that process. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Sun Feb 21 23:51:14 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 21 Feb 2016 14:51:14 -0800 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> Message-ID: <5713144.LaDhhWVHYU@tjmaciei-mobl4> On sexta-feira, 19 de fevereiro de 2016 21:01:02 PST Knoll Lars wrote: > Now that 5.7 is branched, I'd like to propose that we update our list of > supported compilers and platforms for Qt 5.8. After some discussions with > different people, here's an initial proposal from my side: Let me just say that I don't think changing the requirements one release after such a big bump is a good idea. Maybe postpone the update to Qt 5.9? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Feb 21 19:01:03 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 21 Feb 2016 10:01:03 -0800 Subject: [Development] Supported platforms for Qt 5.8rt In-Reply-To: <34E26E0B-3072-4AFA-858C-3B5209068B28@theqtcompany.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <2932609.kMHNNApRdD@tjmaciei-mobl4> <34E26E0B-3072-4AFA-858C-3B5209068B28@theqtcompany.com> Message-ID: <3357985.JGI2DTR6is@tjmaciei-mobl4> On domingo, 21 de fevereiro de 2016 07:01:57 PST Turunen Tuukka wrote: > > Thiago Macieira kirjoitti 21.2.2016 kello 7.15: > >> On sábado, 20 de fevereiro de 2016 22:09:20 PST Allan Sandfeld Jensen > >> wrote: Well, feature-complete'ish. I recently found out we need clang > >> 3.5 to use deleted constructors in Chromium. Clang 3.4 has a bug which > >> will cause it to claim deleted methods causes ambiguity with > >> non-deleted methods. So if we opt for gcc 4.8, I would suggest demanding > >> clang 3.5 as well. > > > > That would drop FreeBSD 10.2, which is the current stable release today. > > According to their release plans both 10.3 and 11.0 should be out well > before Qt 5.8. 10.3 won 't update the compiler. 11.0 will. But let's keep Clang 3.4 as required, it's only 3 releases (currently) old. We're supporting GCC 4.7, which is also 3 releases old. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Eike.Ziller at theqtcompany.com Mon Feb 22 08:59:55 2016 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Mon, 22 Feb 2016 07:59:55 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <26003352.DV2JlzaxBy@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <26003352.DV2JlzaxBy@tjmaciei-mobl4> Message-ID: <41BE3D87-57B6-4710-9C60-E7A2804A0FB8@theqtcompany.com> > On Feb 20, 2016, at 7:04 PM, Thiago Macieira wrote: > > On sexta-feira, 19 de fevereiro de 2016 21:01:02 PST Knoll Lars wrote: >> * We drop support for VS2012. This implicitly drops support for WEC2013. >> Reason is that the compiler is still having rather large problems with it's >> C++11 support. I hope that we could serve the WEC market rather well with >> 5.6 and 5.7 for the years to come. In the end, the benefit we get with >> dropping the compiler will hopefully outweigh the cost (loosing WEC) by a >> good margin. > > This buys us: > > - delegating constructors > - "explicit operator" member funcvtions > - nsdmi > - initializer_list (not uniform initialisation!) > - raw strings > - template alias (using ... = ...) > - variadic templates > > It would buy us, if we raised to GCC 4.8 too: > - deleted and defaulted members Hm, deleted and defaulted members should work fine with gcc 4.7(.3) as well. Please note that MSVC2013 fails to recognize move constructors and move assignment operators as special member functions, so you cannot default or delete them. There is also an issue with perfect forwarding in MSVC2013 (it copies anyway). > (nsdmi, delegating constructors, template aliases require GCC 4.7) > > Is it worth it? The only things I'd really want are intialiser lists and > variadic templates. Note that without constexpr, initialiser lists' value is > limited. > > (I'm assuming Clang minimum version 3.4, as found on FreeBSD, which is > feature-complete for C++11) > > -- > 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 -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company 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 thiago.macieira at intel.com Mon Feb 22 09:28:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 22 Feb 2016 00:28:01 -0800 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <41BE3D87-57B6-4710-9C60-E7A2804A0FB8@theqtcompany.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <26003352.DV2JlzaxBy@tjmaciei-mobl4> <41BE3D87-57B6-4710-9C60-E7A2804A0FB8@theqtcompany.com> Message-ID: <5278800.l1EuoNIQ5Y@tjmaciei-mobl4> On segunda-feira, 22 de fevereiro de 2016 07:59:55 PST Ziller Eike wrote: > > It would buy us, if we raised to GCC 4.8 too: > > - deleted and defaulted members > > Hm, deleted and defaulted members should work fine with gcc 4.7(.3) as well. Right, I think I cut/pasted the wrong entry. We'd need GCC 4.8 for inheriting constructors. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bogdan.vatra at kdab.com Mon Feb 22 09:49:36 2016 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Mon, 22 Feb 2016 10:49:36 +0200 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> Message-ID: <2214891.Tu2FhpRmD8@zmeu> Hi, On Friday 19 February 2016 21:01:02 Knoll Lars wrote: > Hi, > > Now that 5.7 is branched, I'd like to propose that we update our list of > supported compilers and platforms for Qt 5.8. After some discussions with > different people, here's an initial proposal from my side: > [...] > > * Minimum version for Android is probably going to stay with 4.1 (as with > 5.7). We would like to add a 64 bit build to the CI > [...] I was hoping that (at least) 5.7 will add Android 64 bit. Is the any problem to add 64 bit support to 5.7 (or 5.6.1)? Cheers, BogDan. From tuukka.turunen at theqtcompany.com Mon Feb 22 10:00:25 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Mon, 22 Feb 2016 09:00:25 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <5713144.LaDhhWVHYU@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <5713144.LaDhhWVHYU@tjmaciei-mobl4> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=theqtcompany.com at qt-project.org] On Behalf Of > Thiago Macieira > Sent: sunnuntaina 21. helmikuuta 2016 23.51 > To: development at qt-project.org > Subject: Re: [Development] Supported platforms for Qt 5.8 > > On sexta-feira, 19 de fevereiro de 2016 21:01:02 PST Knoll Lars wrote: > > Now that 5.7 is branched, I'd like to propose that we update our list > > of supported compilers and platforms for Qt 5.8. After some > > discussions with different people, here's an initial proposal from my side: > > Let me just say that I don't think changing the requirements one release > after such a big bump is a good idea. Maybe postpone the update to Qt 5.9? > It is of course a matter of viewpoint, but I think similarly as Lars that it is better to do the required changes now for Qt 5.8 and then aim to avoid bigger changes for Qt 5.9 to the extent feasible. There will be quite many new things developed for Qt 5.8 and keeping support for some older compilers and platforms we aim to then drop immediately after would be just an extra burden for the development. With Qt 5.6 and to some extent also with Qt 5.7 we have a wide set of older compilers supported, which makes it a great choice for those who can not move to the newer ones yet. Yours, Tuukka From Morten.Sorvig at theqtcompany.com Mon Feb 22 11:01:14 2016 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Mon, 22 Feb 2016 10:01:14 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: <2E4B5E32-AE5E-4ECE-89F3-3049DAE9C40F@sletta.org> References: <1ABE7D74-43B1-40B9-B1C0-0F0EE847A0C0@digia.com> <2E4B5E32-AE5E-4ECE-89F3-3049DAE9C40F@sletta.org> Message-ID: > On 19 Feb 2016, at 10:44, Gunnar Sletta wrote: > > Now every piece of code needs to also know about device pixel ratio and that needs to passed down to image loaders, icon generators This is essential complexity, not accidental complexity. With high-DPI displays in use raster images now vary across two dimensions: amount of content and amount of detail. Consider a map tile provider: starting with a 50x50 base tile there are two ways to render a 100x100 tile: More map content or finer content detail. The inputs to the image provider is either (logical pixels, scale) or (actual pixels, scale). In both cases you have to carry the scale factor. The only way out is to reject the extra dimensionality (as I did initially with the QML image providers), but I think Qt will be better off if we support it. - Morten From edward.welbourne at theqtcompany.com Mon Feb 22 12:05:24 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Mon, 22 Feb 2016 11:05:24 +0000 Subject: [Development] GCC-built Qt 5.6 can't be used with Clang In-Reply-To: References: <20160220104811.5857363.1803.60535@theqtcompany.com>, Message-ID: > Simon Hausmann wrote: >> Hmm, change ‎https://codereview.qt-project.org/#/c/147846/ was >> supposed to fix this issue. >> >> ‎The subject of the email refers to 5.6 but in the body you say that >> you are building the dev branch. If it is the latter, could it be >> that the fix hasn't hit dev yet? Stephen Kelly replied > Indeed, I built without that patch. Perhaps it is indeed fixed in 5.6 > already (but I didn't check). Reading the commit message and the > commit I don't have the expertise to know. It was commit 3726c46735edb23ad37af818ff7d52d661ec87e7. I'm sure there's a specific command for asking git whether a given branch contains a given commit: but I can't remember it. Still, git log dev..3726c4673 reveals that it is indeed not yet in dev. (Or, at least, wasn't this morning when my nightly cron job pulled into my local bare repos.) Eddy. From Kai.Koehne at theqtcompany.com Mon Feb 22 12:27:24 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Mon, 22 Feb 2016 11:27:24 +0000 Subject: [Development] GCC-built Qt 5.6 can't be used with Clang In-Reply-To: References: <20160220104811.5857363.1803.60535@theqtcompany.com>, Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of > Welbourne Edward > Sent: Monday, February 22, 2016 12:05 PM > To: Stephen Kelly ; development at qt-project.org > Subject: Re: [Development] GCC-built Qt 5.6 can't be used with Clang > > > Simon Hausmann wrote: > >> Hmm, change ‎https://codereview.qt-project.org/#/c/147846/ was > >> supposed to fix this issue. > >> > >> ‎The subject of the email refers to 5.6 but in the body you say that > >> you are building the dev branch. If it is the latter, could it be > >> that the fix hasn't hit dev yet? > > Stephen Kelly replied > > Indeed, I built without that patch. Perhaps it is indeed fixed in 5.6 > > already (but I didn't check). Reading the commit message and the > > commit I don't have the expertise to know. > > It was commit 3726c46735edb23ad37af818ff7d52d661ec87e7. > I'm sure there's a specific command for asking git whether a given branch > contains a given commit: but I can't remember it. git branch -r --contains SHA Shows all remote branches containing a specific SHA The same works for tags git tag --contains SHA Commit 3726c46735edb23ad37af818ff7d52d661ec87e7 is only in 5.6.0 so far. Regards Kai From rogerbriggen at schleuniger.ch Mon Feb 22 15:59:52 2016 From: rogerbriggen at schleuniger.ch (Roger Briggen) Date: Mon, 22 Feb 2016 14:59:52 +0000 (UTC) Subject: [Development] Supported platforms for Qt 5.8 References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> Message-ID: Knoll Lars theqtcompany.com> writes: > > Hi, > > Now that 5.7 is branched, I'd like to propose that we update our list of supported compilers and platforms > for Qt 5.8. After some discussions with different people, here's an initial proposal from my side: > > * We drop support for VS2012. This implicitly drops support for WEC2013. Reason is that the compiler is > still having rather large problems with it's C++11 support. I hope that we could serve the WEC market > rather well with 5.6 and 5.7 for the years to come. In the end, the benefit we get with dropping the compiler > will hopefully outweigh the cost (loosing WEC) by a good margin. > Hi Lars, WEC2013 is also supported by Visual Studio 2013 and Visual Studio 2015 (according to https://msdn.microsoft.com/en-us/library/gg154234.aspx) because it uses now the ARM Desktop Compiler. So dropping VS2012 must not be the end of WEC2013 support of Qt. Regards, Roger From thiago.macieira at intel.com Mon Feb 22 16:54:33 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 22 Feb 2016 07:54:33 -0800 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> Message-ID: <4922415.jiWFqEyGVU@tjmaciei-mobl4> On segunda-feira, 22 de fevereiro de 2016 14:59:52 PST Roger Briggen wrote: > WEC2013 is also supported by Visual Studio 2013 and Visual Studio 2015 > (according to https://msdn.microsoft.com/en-us/library/gg154234.aspx) > because it uses now the ARM Desktop Compiler. > So dropping VS2012 must not be the end of WEC2013 support of Qt. Hi Roger That is IDE support using the compiler from VS2012. When we say we drop support for a compiler, we don't mean the IDE that you're using. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Feb 22 16:57:49 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 22 Feb 2016 07:57:49 -0800 Subject: [Development] GCC-built Qt 5.6 can't be used with Clang In-Reply-To: References: Message-ID: <2803269.9NXOlDKfjj@tjmaciei-mobl4> On segunda-feira, 22 de fevereiro de 2016 11:05:24 PST Welbourne Edward wrote: > I'm sure there's a specific command for asking git whether a given > branch contains a given commit: but I can't remember it. > Still, git log dev..3726c4673 reveals that it is indeed not yet in dev. That is actually the correct command to do what you asked. Using git branch --contains is more expensive, as it will check whether all branches, not just dev, contain it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andrew.knight at intopalo.com Mon Feb 22 17:01:45 2016 From: andrew.knight at intopalo.com (Andrew Knight) Date: Mon, 22 Feb 2016 18:01:45 +0200 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <4922415.jiWFqEyGVU@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <4922415.jiWFqEyGVU@tjmaciei-mobl4> Message-ID: <56CB30E9.5010801@intopalo.com> On 02/22/2016 05:54 PM, Thiago Macieira wrote: > On segunda-feira, 22 de fevereiro de 2016 14:59:52 PST Roger Briggen wrote: >> WEC2013 is also supported by Visual Studio 2013 and Visual Studio 2015 >> (according to https://msdn.microsoft.com/en-us/library/gg154234.aspx) >> because it uses now the ARM Desktop Compiler. >> So dropping VS2012 must not be the end of WEC2013 support of Qt. > Hi Roger > > That is IDE support using the compiler from VS2012. When we say we drop > support for a compiler, we don't mean the IDE that you're using. > That link clearly states that the MSVC2013 compiler is now used with WEC2013 Update 5 and 11, as is the latest C runtime. So, this indeed looks like a compiler and C runtime upgrade, not simply the new IDE targeting the old compiler. Maybe someone with a WEC2013 installation can check this out in practice? Andrew From gunnar.roth at gmx.de Mon Feb 22 18:51:04 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Mon, 22 Feb 2016 18:51:04 +0100 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <56CB30E9.5010801@intopalo.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <4922415.jiWFqEyGVU@tjmaciei-mobl4>, <56CB30E9.5010801@intopalo.com> Message-ID: An HTML attachment was scrubbed... URL: From tuukka.turunen at theqtcompany.com Mon Feb 22 19:16:47 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Mon, 22 Feb 2016 18:16:47 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <4922415.jiWFqEyGVU@tjmaciei-mobl4>, <56CB30E9.5010801@intopalo.com> Message-ID: Hi, For both WEC7 and WEC13 Qt 5.6 should be a very good release to use, while for WEC13 also Qt 5.7 is an option. However as Qt 5.6 is a LTS release supporting both WEC7 and WEC13, it is a very good baseline. With Qt 5.6.0 the WEC13 is still experimental, but target is to have it supported equally well as WEC7 is within Qt 5.6.x patch level releases. Yours, Tuukka From: Development [mailto:development-bounces+tuukka.turunen=theqtcompany.com at qt-project.org] On Behalf Of Gunnar Roth Sent: maanantaina 22. helmikuuta 2016 18.51 To: Andrew Knight Cc: development at qt-project.org Subject: Re: [Development] Supported platforms for Qt 5.8 This is a deja vu to me, somehow. please have a look at this discussion https://www.mail-archive.com/search?l=development at qt-project.org&q=subject:%22Re%5C%3A+%5C%5BDevelopment%5C%5D+QtCS%5C%3A+Long+Term+Release+discussion%22&o=newest&f=1 To quote myself: " Hi Björn, i had the assumption you could mean that, but thats not a knowledge base article. I think you mean Compact 2013 uses the Microsoft Visual Studio 2013 compiler,? That part was also sent to me by a colleage from another department when discussing v8 usage( as this has vs2013 depedancy according to wiki). So we startet a MS Request to clear this issue. The answer was that the arcticle is wrong here." MS promised to fix that article but maybe they need some more years for that. By the way I am strongly against droping wec2013 support after just one other version, actually support for wec2013 has not yet arrived yet. So this is probaly unique for a platform supported by qt , where the deprecation announcement comes before the release of the actual platform support. There is also a some importat stuff missing for wec2013 in qt 5.6 beta like no quick2 controls support, no webkit/engine support and no multimedia support, no neon intrinsics support, no openssl support, no sse2 support. Regards, Gunnar Roth Gesendet: Montag, 22. Februar 2016 um 17:01 Uhr Von: "Andrew Knight" > An: development at qt-project.org Betreff: Re: [Development] Supported platforms for Qt 5.8 On 02/22/2016 05:54 PM, Thiago Macieira wrote: > On segunda-feira, 22 de fevereiro de 2016 14:59:52 PST Roger Briggen wrote: >> WEC2013 is also supported by Visual Studio 2013 and Visual Studio 2015 >> (according to https://msdn.microsoft.com/en-us/library/gg154234.aspx) >> because it uses now the ARM Desktop Compiler. >> So dropping VS2012 must not be the end of WEC2013 support of Qt. > Hi Roger > > That is IDE support using the compiler from VS2012. When we say we drop > support for a compiler, we don't mean the IDE that you're using. > That link clearly states that the MSVC2013 compiler is now used with WEC2013 Update 5 and 11, as is the latest C runtime. So, this indeed looks like a compiler and C runtime upgrade, not simply the new IDE targeting the old compiler. Maybe someone with a WEC2013 installation can check this out in practice? Andrew _______________________________________________ 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 Mon Feb 22 19:32:04 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 22 Feb 2016 10:32:04 -0800 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> Message-ID: <3260609.aQ307eygZ4@tjmaciei-mobl4> On segunda-feira, 22 de fevereiro de 2016 18:16:47 PST Turunen Tuukka wrote: > Hi, > > For both WEC7 and WEC13 Qt 5.6 should be a very good release to use, while > for WEC13 also Qt 5.7 is an option. However as Qt 5.6 is a LTS release > supporting both WEC7 and WEC13, it is a very good baseline. With Qt 5.6.0 > the WEC13 is still experimental, but target is to have it supported equally > well as WEC7 is within Qt 5.6.x patch level releases. So, to echo what Gunnar is saying: Is Qt 5.7 going to be the *only* release to support WEC2013? I want that answer to be "no". Let's support it for at least a year. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at theqtcompany.com Mon Feb 22 22:08:12 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Mon, 22 Feb 2016 21:08:12 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <3260609.aQ307eygZ4@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <3260609.aQ307eygZ4@tjmaciei-mobl4> Message-ID: <7F8EC774-27EF-4343-B49E-5FA9C225C141@theqtcompany.com> On 22/02/16 19:32, "Development on behalf of Thiago Macieira" wrote: >On segunda-feira, 22 de fevereiro de 2016 18:16:47 PST Turunen Tuukka wrote: >> Hi, >> >> For both WEC7 and WEC13 Qt 5.6 should be a very good release to use, while >> for WEC13 also Qt 5.7 is an option. However as Qt 5.6 is a LTS release >> supporting both WEC7 and WEC13, it is a very good baseline. With Qt 5.6.0 >> the WEC13 is still experimental, but target is to have it supported equally >> well as WEC7 is within Qt 5.6.x patch level releases. > >So, to echo what Gunnar is saying: > >Is Qt 5.7 going to be the *only* release to support WEC2013? > >I want that answer to be "no". Let's support it for at least a year. I can see the reasoning here, just as well as I see the reasoning of the people that would like to get rid of VS2012 as quickly as possible. Before we continue this, could someone check the claim made in https://msdn.microsoft.com/en-us/library/gg154234.aspx ? That article has been published after we last discussed the topic. Thanks, Lars From Gabriel.deDietrich at theqtcompany.com Mon Feb 22 23:31:23 2016 From: Gabriel.deDietrich at theqtcompany.com (deDietrich Gabriel) Date: Mon, 22 Feb 2016 22:31:23 +0000 Subject: [Development] Making ItemSelectionModel more useful In-Reply-To: <56C859E0.8030400@users.sourceforge.net> References: <56C859E0.8030400@users.sourceforge.net> Message-ID: On Feb 20, 2016, at 4:19 AM, Alberto Mardegan wrote: > > Hi all! > Since Qt 5.5, the QItemSelectionModel class is exposed to QML as > ItemSelectionModel (in the QtQml.Models module): > > http://doc.qt.io/qt-5/qml-qtqml-models-itemselectionmodel.html > > Apart from having almost no documentation, this component seems to be > rather hard to use in QML: its methods work with QModelIndex (while all > the models I've ever used in QML just speak row numbers) or > QItemSelection, which I believe is not usable in QML at all (at least, > it's not documented as a QML component). > > I understand that the reason for all of this is that QItemSelectionModel > is a class originally created for C++ consumption, and that the > QModelIndex makes a lot of sense there. However, I would argue that the > QML version is hardly usable. > > As I see it, either this class gets a "model" property and methods which > operate on integers (row numbers), or QModelIndex and QItemSelection > need to become first class citizens in QML as well. I guess that having > Q_GADGET is already a huge step forward, but we should also have a > generic way to turn a model+rowNumber into a QModelIndex: maybe a global > method Qt.makeIndex(model, row), which would also work on all models > supported by the QML engine? QModelIndex is a rather simple class that’s closely tied to QAbstractItemModel. On the Qt Quick side, when you assign a model to a ListView, for example, Qt Quick will wrap it into an internal class. That class can work with both QAIM or a JS array (and others) and deals with the view in an opaque (to the view) way. In the latter case, there's no QAIM at all, so there's no way we can make a QModelIndex out of it. Whether that would be a wise thing to do internally is debatable. The story behind having QModelIndex and QItemSelectionModel exposed to the QML engine was to solve the selection problem in the Qt Quick Controls 1 TreeView. TableView could use a simple selection model because of the trivial mapping between table row and model index. That’s not possible for the TreeView, so we decided to reuse what was already available in the QtWidgets side. Note that QAbstractItemModel::index() and several more functions have been made invokable. So those are available in QML provided your model is QAIM-based. Best regards, Dr. Gabriel de Dietrich Senior Software Developer The Qt Company — www.qt.io > Are there any plans about this, or what would be the best way to address > this? > > Ciao, > Alberto > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Mon Feb 22 23:52:23 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 22 Feb 2016 14:52:23 -0800 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <7F8EC774-27EF-4343-B49E-5FA9C225C141@theqtcompany.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <3260609.aQ307eygZ4@tjmaciei-mobl4> <7F8EC774-27EF-4343-B49E-5FA9C225C141@theqtcompany.com> Message-ID: <6592024.SiRXsdEexG@tjmaciei-mobl4> On segunda-feira, 22 de fevereiro de 2016 21:08:12 PST Knoll Lars wrote: > I can see the reasoning here, just as well as I see the reasoning of the > people that would like to get rid of VS2012 as quickly as possible. Why do we need to get rid of it? What are the problems with it, aside from lack of certain C++11 support? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From filippocucchetto at gmail.com Tue Feb 23 00:47:53 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Tue, 23 Feb 2016 00:47:53 +0100 Subject: [Development] QtQuick mouse event handling Message-ID: Hi all, i want to talk about the mouse event handling in QtQuick. From my experience mouse event handling is rather unflexible. The current implementation is straightforward: the events are propagated from the top mousearea until accepted. This is fine however consider the common scenario of an item delegate for a row in a view (be it a TableView or TreeView) that needs to listen for mouse events: 1) The user put a MouseArea inside the item delegate 1.a) if the user is only interested in the press event the solution is simple: handle the onPress event in the MouseArea and simply propagate the event by setting "mouse.accepted = false" 1.b) if the user need to listen for the click event he can't reject the press event. This in turn break the view selection handling and maybe more. AFAIK there's no way to temporary store the mouse events and later propagate them beneath. The user has to reimplement most of the event handling in the item delegate (like handling selection/multi selection). 2) Rely on the view signals. Some view exposes some mouse signals like clicked and doubleClicked etc. Most of the implementations in QtQuickControls are not sufficient. For example they lack of the button pressed or mouse positions. Furthermore most of the view signals are for composed events (clicked) and so there're no press and release events. One could argue that most of the implementations expose the view mouseArea (__mouseArea) so a user can connect to it through a Connection object. This is a partial solution because the press[release] event is sent after the view handled it and again the user act after the view already handled it (so there's no way to swallow it). Another downside of option (2) is that most of the times the user need to do some actions on the item delegate. So from the view onClicked we must obtain the itemDelegate. This imply one these solutions: 1) the existance of a itemAt(index) or itemAt(row) function (AFAIK there isn't right now) 2) Each item delegate connect to the clicked signal of the view To me both solutions are ugly. First they have an overhead: connections costs in the delegate item construction and also finding an item could be expensive. Keep in mind that solution (1.b) is simpler since we handle the event directly in the delegate. What do you think about it? Do you have a solution for this kind of problems? 1) One possible solution could be exposing the views event handlers like callable functions ( onPressed, onRelease etc.) In this way with solution (1.b) we can both accept the mouse event and also propagate it to the view. i.e. MouseArea { onPressed: { mouse.accepted; view.onPressed(...) } } 2) Other frameworks like WPF has the notion of "handledEventsToo" where basically you let propagate an event even if it has been handled 3) Another solution could to remove the need of accepting the press event for having the notification for the click event. Most of the times the user just need to know that an item delegate has been clicked without swallowing it. But for receiving the click event he must swallow (accept) the press event. -- Filippo Cucchetto -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stefan.Walter at lisec.com Tue Feb 23 06:24:17 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Tue, 23 Feb 2016 05:24:17 +0000 Subject: [Development] QJSEngine replacement for QScriptEngine misses newFunction Message-ID: <3a7501416c644455be00a752441734e9@ATSE-MAIL4.lisec.internal> Hi, I am looking into migrating my code to QJSEngine, because of the deprecation of the QScriptEngine (QtScript). As we have used the functionality of newFunction very extensive and all related scripts are depending on this, the newFunction in QJSEngine is for us mandatory or something that creates and equivalent result. How do I currently map a native C++ class member function to the engine: QScriptValue func_sqrt = m_engine->newFunction(sqrt, liEngine); m_engine->globalObject().setProperty("sqrt", func_sqrt, QScriptValue::ReadOnly | QScriptValue::Undeletable); This is an example of a native function: QScriptValue ScriptModuleMath::sqrt(QScriptContext *context, QScriptEngine *engine, void *arg) { Q_UNUSED(engine) Q_UNUSED(arg) if (context->argumentCount()!=1) { return context->throwError( QScriptContext::SyntaxError, "sqrt(...): illegal number of arguments."); } else if (!context->argument(0).isNumber()) { return context->throwError( QScriptContext::SyntaxError, "sqrt(...): argument 1 is not a number."); } return qSqrt(context->argument(0).toNumber()); } And in this way. I can use it then in the script: value = sqrt(4); I actually don't want to map a whole QObject, because that would require a call like this: value = MyMath.sqrt(4); Is there any way to achive in QJSEngine the same result as I do within the QScriptEngine? Best Regards, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at theqtcompany.com Tue Feb 23 06:32:55 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Tue, 23 Feb 2016 05:32:55 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <3260609.aQ307eygZ4@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <3260609.aQ307eygZ4@tjmaciei-mobl4> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=theqtcompany.com at qt-project.org] On Behalf Of > Thiago Macieira > Sent: maanantaina 22. helmikuuta 2016 19.32 > To: development at qt-project.org > Subject: Re: [Development] Supported platforms for Qt 5.8 > > On segunda-feira, 22 de fevereiro de 2016 18:16:47 PST Turunen Tuukka > wrote: > > Hi, > > > > For both WEC7 and WEC13 Qt 5.6 should be a very good release to use, > > while for WEC13 also Qt 5.7 is an option. However as Qt 5.6 is a LTS > > release supporting both WEC7 and WEC13, it is a very good baseline. > > With Qt 5.6.0 the WEC13 is still experimental, but target is to have > > it supported equally well as WEC7 is within Qt 5.6.x patch level releases. > > So, to echo what Gunnar is saying: > > Is Qt 5.7 going to be the *only* release to support WEC2013? > No. Both Qt 5.6 and Qt 5.7 will support WEC13. > I want that answer to be "no". Let's support it for at least a year. > -- Me too. I want to support it 3 years with the Qt 5.6 LTS - and after that offer extended support to customers needing it. But let's re-check if VS2013 is actually now supported as a compiler or not. Maybe we can remove VS2012 but still support WEC13 with Qt 5.8 - however this may require some more though that just the compiler support. It seems very clear that Microsoft is aggressively pushing towards Windows 10 IoT, so I think that would be the right thing to focus on in the future of embedded Windows. Yours, Tuukka > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Feb 23 07:01:31 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 22 Feb 2016 22:01:31 -0800 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <3260609.aQ307eygZ4@tjmaciei-mobl4> Message-ID: <8568893.iZbDZqAgsO@tjmaciei-mobl4> On terça-feira, 23 de fevereiro de 2016 05:32:55 PST Turunen Tuukka wrote: > > Is Qt 5.7 going to be the *only* release to support WEC2013? > > No. Both Qt 5.6 and Qt 5.7 will support WEC13. Quoting you on your yesterday's email: "With Qt 5.6.0 the WEC13 is still experimental" So 5.6 doesn't count. That leaves just one release, which is way too short. > > I want that answer to be "no". Let's support it for at least a year. > > Me too. I want to support it 3 years with the Qt 5.6 LTS - and after that > offer extended support to customers needing it. > > But let's re-check if VS2013 is actually now supported as a compiler or not. > Maybe we can remove VS2012 but still support WEC13 with Qt 5.8 - however > this may require some more though that just the compiler support. It seems > very clear that Microsoft is aggressively pushing towards Windows 10 IoT, > so I think that would be the right thing to focus on in the future of > embedded Windows. While I wish that Windows 10 Core gain market share quickly compared to the older Embedded Compact versions, it's unlikely to happen. In fact, even VS 2012's market share is today too high to be dropped. It would be nice to confirm whether that's the case for us by checking the download counts for each version in the last 3 months and over the 5.6 release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From announce at qt-project.org Mon Feb 22 12:03:54 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Mon, 22 Feb 2016 12:03:54 +0100 Subject: [Development] [Announce] Qt VS Add-In 1.2.5 released Message-ID: Hi, it's been a while but we just released version 1.2.5 of the Qt Visual Studio Add-In. It contains an update to Qt 5.6.0's documentation as well as some bug fixes. Download: http://download.qt.io/official_releases/vsaddin/qt-vs-addin-1.2.5.exe Cheers, Olli _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From Graham.Labdon at avalonsciences.com Tue Feb 23 11:49:27 2016 From: Graham.Labdon at avalonsciences.com (Graham Labdon) Date: Tue, 23 Feb 2016 10:49:27 +0000 Subject: [Development] Qt Visual Studio V1.2.5 Message-ID: Hi So I just installed the latest visual studio addin (for VS2012) but I seem to have lost the integrated help Can anyone suggest why this might be? thanks From oliver.wolff at theqtcompany.com Tue Feb 23 12:35:22 2016 From: oliver.wolff at theqtcompany.com (Oliver Wolff) Date: Tue, 23 Feb 2016 12:35:22 +0100 Subject: [Development] Qt Visual Studio V1.2.5 In-Reply-To: References: Message-ID: <56CC43FA.7030706@theqtcompany.com> Am 23.02.2016 um 11:49 schrieb Graham Labdon: > Hi > So I just installed the latest visual studio addin (for VS2012) but I seem to have lost the integrated help > Can anyone suggest why this might be? > > thanks Hi Graham, what exactly does not work for you? Don't you have any Add-In or Qt help available or doesn't context sensitive help work for you? Can you check, whether "HELP -> Add and Remove Help Content" (Alt+Ctrl+F1) shows the help files shipped with the Add-In (Qt5 and Visual Studio Addin 1.2)? Best regards, Olli > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From mardy at users.sourceforge.net Tue Feb 23 12:42:20 2016 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Tue, 23 Feb 2016 14:42:20 +0300 Subject: [Development] Making ItemSelectionModel more useful In-Reply-To: References: <56C859E0.8030400@users.sourceforge.net> Message-ID: <56CC459C.1030304@users.sourceforge.net> On 23/02/2016 01:31, deDietrich Gabriel wrote: > The story behind having QModelIndex and QItemSelectionModel exposed > to the QML engine was to solve the selection problem in the Qt Quick > Controls 1 TreeView. TableView could use a simple selection model > because of the trivial mapping between table row and model index. > That’s not possible for the TreeView, so we decided to reuse what was > already available in the QtWidgets side. Note that > QAbstractItemModel::index() and several more functions have been made > invokable. So those are available in QML provided your model is > QAIM-based. Thanks Gabriel, I have a more clear understanding now. I actually notice that there is documentation here for QModelIndex and QItemSelection: http://code.qt.io/cgit/qt/qtdeclarative.git/tree/src/qml/types/qqmlitemmodels.qdoc However, I cannot find that page in the documentation website; could you please check why? Ciao, Alberto From jmullen at pasco.com Tue Feb 23 18:00:28 2016 From: jmullen at pasco.com (Jon Mullen) Date: Tue, 23 Feb 2016 17:00:28 +0000 Subject: [Development] Qt Nacl Message-ID: <13A41B2A-0388-4D8E-867C-62A2E3014712@pasco.com> Hey I’m trying to figure out how far along the Qt Nacl code is and if I’m able to use it on the project I’m working on. I have the code built from the qtbase wip/nacl branch. However, when I go to run the example window_widgets none of the UI seems to work. The line edit shows that it is focused, but never receives keyboard events. Also, once the line edit loses focus it never is able to get focus back again. It seems like all user input isn’t working. Is this the case? Any help would be appreciated. Thanks Jon Mullen -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas.holzammer at kdab.com Tue Feb 23 19:16:48 2016 From: andreas.holzammer at kdab.com (Andreas Holzammer) Date: Tue, 23 Feb 2016 19:16:48 +0100 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <6592024.SiRXsdEexG@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <3260609.aQ307eygZ4@tjmaciei-mobl4> <7F8EC774-27EF-4343-B49E-5FA9C225C141@theqtcompany.com> <6592024.SiRXsdEexG@tjmaciei-mobl4> Message-ID: <56CCA210.8090309@kdab.com> Am 22.02.2016 um 23:52 schrieb Thiago Macieira: > On segunda-feira, 22 de fevereiro de 2016 21:08:12 PST Knoll Lars wrote: >> I can see the reasoning here, just as well as I see the reasoning of the >> people that would like to get rid of VS2012 as quickly as possible. > > Why do we need to get rid of it? What are the problems with it, aside from > lack of certain C++11 support? > Mostly yes we see a demand in getting new c++ features into Qt. As far as my knowlege goes is that WEC2013 bundles they compiler with the SDK which is produced by the Platform Builder. As of now I did not see any indication that this bundled compiler will be updated(right now they bundle the VS2012 compiler). All websites which I did read say if you read closely that they are supporting the new Visual Studio IDE, but will take the toolchain of the SDK which is provided. Basically it means we are stuck with Visual Studio 2012 c++ featureset for Windows Embedded Compact 2013. If we want to support newer C++ with Qt 5.8 we would need to drop the complete platform. As of problems to support it in newer Qt Versions, I can say the market share right now is not very big, as also already indicated by someone else. Hardware vendors do release right now more experimental support for WEC2013, which means there might be years until they reach a decent market share. Thank you Andy -- Andreas Holzammer | andreas.holzammer at kdab.com | Senior 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: 4070 bytes Desc: S/MIME Cryptographic Signature URL: From gunnar.roth at gmx.de Tue Feb 23 20:53:55 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Tue, 23 Feb 2016 20:53:55 +0100 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <56CCA210.8090309@kdab.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <3260609.aQ307eygZ4@tjmaciei-mobl4> <7F8EC774-27EF-4343-B49E-5FA9C225C141@theqtcompany.com> <6592024.SiRXsdEexG@tjmaciei-mobl4> <56CCA210.8090309@kdab.com> Message-ID: Hi, I also like to add that Win10 IoT is NOT THE successor for wec2013. MS will offer some porting tools, but as you can see here http://embeddingwindowssuccess.blogspot.de/2015/03/the-future-of-windows-embedded-windows.html the wec2013 line is continuing, while all other lines end into the windows10 line. The reason is that none of the windows 10 editions has realtime support, so if you want to (or have to ) use a MS OS and you need realtime, wec2013 is what is left. Regards, Gunnar PS.: We are asking our MS contact again because of the MSDN page statements. > Am 23.02.2016 um 19:16 schrieb Andreas Holzammer : > > Am 22.02.2016 um 23:52 schrieb Thiago Macieira: >> On segunda-feira, 22 de fevereiro de 2016 21:08:12 PST Knoll Lars wrote: >>> I can see the reasoning here, just as well as I see the reasoning of the >>> people that would like to get rid of VS2012 as quickly as possible. >> >> Why do we need to get rid of it? What are the problems with it, aside from >> lack of certain C++11 support? >> > > Mostly yes we see a demand in getting new c++ features into Qt. As far > as my knowlege goes is that WEC2013 bundles they compiler with the SDK > which is produced by the Platform Builder. As of now I did not see any > indication that this bundled compiler will be updated(right now they > bundle the VS2012 compiler). All websites which I did read say if you > read closely that they are supporting the new Visual Studio IDE, but > will take the toolchain of the SDK which is provided. > > Basically it means we are stuck with Visual Studio 2012 c++ featureset > for Windows Embedded Compact 2013. > > If we want to support newer C++ with Qt 5.8 we would need to drop the > complete platform. > > As of problems to support it in newer Qt Versions, I can say the market > share right now is not very big, as also already indicated by someone > else. Hardware vendors do release right now more experimental support > for WEC2013, which means there might be years until they reach a decent > market share. > > Thank you > > Andy > > > > -- > Andreas Holzammer | andreas.holzammer at kdab.com | Senior 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.martins at kdab.com Tue Feb 23 22:01:39 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Tue, 23 Feb 2016 21:01:39 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <8568893.iZbDZqAgsO@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <8568893.iZbDZqAgsO@tjmaciei-mobl4> Message-ID: <5944746.IjZBYZEIzB@desktop> On Monday, 22 February 2016 22:01:31 WET Thiago Macieira wrote: > On terça-feira, 23 de fevereiro de 2016 05:32:55 PST Turunen Tuukka wrote: > > > Is Qt 5.7 going to be the *only* release to support WEC2013? > > > > No. Both Qt 5.6 and Qt 5.7 will support WEC13. > > Quoting you on your yesterday's email: > > "With Qt 5.6.0 the WEC13 is still experimental" > > So 5.6 doesn't count. That leaves just one release, which is way too short. Turunen said it's experimental with 5.6.0, not 5.6. By the time WEC13 is stable on 5.7 it's also stable on 5.6, because we commit fixes to 5.6 first. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5909 bytes Desc: not available URL: From thiago.macieira at intel.com Tue Feb 23 22:02:19 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 23 Feb 2016 13:02:19 -0800 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <56CCA210.8090309@kdab.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <6592024.SiRXsdEexG@tjmaciei-mobl4> <56CCA210.8090309@kdab.com> Message-ID: <6683065.rtdpzuQFHL@tjmaciei-mobl4> On terça-feira, 23 de fevereiro de 2016 19:16:48 PST Andreas Holzammer wrote: > As of problems to support it in newer Qt Versions, I can say the market > share right now is not very big, as also already indicated by someone > else. Hardware vendors do release right now more experimental support > for WEC2013, which means there might be years until they reach a decent > market share. To be clear: are you expecting WEC2013 market share to increase? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Feb 23 22:09:10 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 23 Feb 2016 13:09:10 -0800 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <5944746.IjZBYZEIzB@desktop> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <8568893.iZbDZqAgsO@tjmaciei-mobl4> <5944746.IjZBYZEIzB@desktop> Message-ID: <1592773.JnohfN3AF3@tjmaciei-mobl4> On terça-feira, 23 de fevereiro de 2016 21:01:39 PST Sergio Martins wrote: > On Monday, 22 February 2016 22:01:31 WET Thiago Macieira wrote: > > On terça-feira, 23 de fevereiro de 2016 05:32:55 PST Turunen Tuukka wrote: > > > > Is Qt 5.7 going to be the *only* release to support WEC2013? > > > > > > No. Both Qt 5.6 and Qt 5.7 will support WEC13. > > > > Quoting you on your yesterday's email: > > > > "With Qt 5.6.0 the WEC13 is still experimental" > > > > So 5.6 doesn't count. That leaves just one release, which is way too > > short. > > Turunen said it's experimental with 5.6.0, not 5.6. By the time WEC13 is > stable on 5.7 it's also stable on 5.6, because we commit fixes to 5.6 first. Fixes, yes. But you cannot commit major refactorings to improve stability in an patch release, especially not the LTS release. Remember that 5.6 is also the last release to support WEC7, so you cannot risk its stability for a platform that's only experimental. Users wanting WEC2013 support are advised to upgrade to Qt 5.7 as soon as possible and not stay in 5.6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sergio.martins at kdab.com Tue Feb 23 22:47:43 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Tue, 23 Feb 2016 21:47:43 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <1592773.JnohfN3AF3@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <5944746.IjZBYZEIzB@desktop> <1592773.JnohfN3AF3@tjmaciei-mobl4> Message-ID: <22754948.RmfqvIIdMP@desktop> On Tuesday, 23 February 2016 13:09:10 WET Thiago Macieira wrote: > On terça-feira, 23 de fevereiro de 2016 21:01:39 PST Sergio Martins wrote: > > On Monday, 22 February 2016 22:01:31 WET Thiago Macieira wrote: > > > On terça-feira, 23 de fevereiro de 2016 05:32:55 PST Turunen Tuukka wrote: > > > > > Is Qt 5.7 going to be the *only* release to support WEC2013? > > > > > > > > No. Both Qt 5.6 and Qt 5.7 will support WEC13. > > > > > > Quoting you on your yesterday's email: > > > > > > "With Qt 5.6.0 the WEC13 is still experimental" > > > > > > So 5.6 doesn't count. That leaves just one release, which is way too > > > short. > > > > Turunen said it's experimental with 5.6.0, not 5.6. By the time WEC13 is > > stable on 5.7 it's also stable on 5.6, because we commit fixes to 5.6 > > first. > Fixes, yes. > > But you cannot commit major refactorings to improve stability in an patch > release, especially not the LTS release. Remember that 5.6 is also the last > release to support WEC7, so you cannot risk its stability for a platform > that's only experimental. But are we going to need major refactorings ? We need to know the state of wec2013 before discussing further, no point in speculating on what was meant by "experimental". The 5.6-Release page says "Added support for WEC2013", it doesn't mention experimental, and also note that it just needs to be as feature-complete as WEC7, so the bar is pretty low ;) Regards, -- Sérgio Martins | sergio.martins at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5909 bytes Desc: not available URL: From thiago.macieira at intel.com Wed Feb 24 05:13:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 23 Feb 2016 20:13:01 -0800 Subject: [Development] Reduced availability Message-ID: <11560802.NkgIKCBGpm@tjmaciei-mobl4> Hello This to let everyone know I have been and will continue to be extremely busy with other projects at work. Please do not expect me to react to Gerrit reviews (mine or someone else's) until mid-April. If you need my attention, please send me an email or ping me on IRC. If any of my pending changes should become needed before April, please update and push it. I will continue to read email and attend the release meetings. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From announce at qt-project.org Wed Feb 24 06:41:33 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 24 Feb 2016 05:41:33 +0000 Subject: [Development] [Announce] Qt 5.6.0 RC released In-Reply-To: References: Message-ID: Hi all, Qt 5.6.0 RC is now released, see http://blog.qt.io/blog/2016/02/23/qt-5-6-0-release-candidate-available/ Big thanks to everyone involved! Best regards, Jani Heikkinen Release Manager | The Qt Company The Qt Company / Digia Finland Ltd, Elektroniikkatie 10, 90590 Oulu, Finland www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject Facebook: www.facebook.com/qt -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From jani.heikkinen at theqtcompany.com Wed Feb 24 07:57:43 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Wed, 24 Feb 2016 06:57:43 +0000 Subject: [Development] Qt 5.6.0 missing change files In-Reply-To: References: Message-ID: Hi all, We really need these during this week! Still missing: qtandroidextras qtbase (ongoing, see https://codereview.qt-project.org/#/c/149325/ ) qtdeclarative qtdoc (qtenginio) qtmacextras qtmultimedia qtquickcontrols (qtscript) qtsvg qttranslations qttools qtwayland qtwebchannel qtwebsockets qtx11extras qtxmlpatterns So no progress since last week! br, Jani ________________________________ Lähettäjä: Heikkinen Jani Lähetetty: 19. helmikuuta 2016 12:42 Vastaanottaja: development at qt-project.org Kopio: releasing at qt-project.org Aihe: Qt 5.6.0 missing change files Hi all, We are planning to release Qt 5.6.0 RC really soon, hoping at the beginning of next week. Final is targeted to be released within 2 weeks as well so we need to get all change files done & in before it. Following change files are still missing: qtandroidextras qtbase (ongoing, see https://codereview.qt-project.org/#/c/149325/ ) qtdeclarative qtdoc (qtenginio) qtmacextras qtmultimedia qtquickcontrols (qtscript) qtsensors qtsvg qttranslations qttools qtwayland qtwaylandqtwebchannel qtwebsockets qtx11extras qtxmlpatterns Maintainers, make sure needed change files are done & in before wed 24th Feb br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at theqtcompany.com Wed Feb 24 08:12:24 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Wed, 24 Feb 2016 07:12:24 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <22754948.RmfqvIIdMP@desktop> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <5944746.IjZBYZEIzB@desktop> <1592773.JnohfN3AF3@tjmaciei-mobl4> <22754948.RmfqvIIdMP@desktop> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=theqtcompany.com at qt-project.org] On Behalf Of > Sergio Martins > Sent: tiistaina 23. helmikuuta 2016 22.48 > To: development at qt-project.org > Cc: Thiago Macieira > Subject: Re: [Development] Supported platforms for Qt 5.8 > > On Tuesday, 23 February 2016 13:09:10 WET Thiago Macieira wrote: > > On terça-feira, 23 de fevereiro de 2016 21:01:39 PST Sergio Martins wrote: > > > On Monday, 22 February 2016 22:01:31 WET Thiago Macieira wrote: > > > > On terça-feira, 23 de fevereiro de 2016 05:32:55 PST Turunen > > > > Tuukka > wrote: > > > > > > Is Qt 5.7 going to be the *only* release to support WEC2013? > > > > > > > > > > No. Both Qt 5.6 and Qt 5.7 will support WEC13. > > > > > > > > Quoting you on your yesterday's email: > > > > > > > > "With Qt 5.6.0 the WEC13 is still experimental" > > > > > > > > So 5.6 doesn't count. That leaves just one release, which is way > > > > too short. > > > > > > Turunen said it's experimental with 5.6.0, not 5.6. By the time > > > WEC13 is stable on 5.7 it's also stable on 5.6, because we commit > > > fixes to 5.6 first. > > Fixes, yes. > > > > But you cannot commit major refactorings to improve stability in an > > patch release, especially not the LTS release. Remember that 5.6 is > > also the last release to support WEC7, so you cannot risk its > > stability for a platform that's only experimental. > > But are we going to need major refactorings ? We need to know the state of > wec2013 before discussing further, no point in speculating on what was > meant by "experimental". > > The 5.6-Release page says "Added support for WEC2013", it doesn't mention > experimental, and also note that it just needs to be as feature-complete as > WEC7, so the bar is pretty low ;) > > Andreas is probably the best person to comment, but as far as I have understood the enablers for WEC13 platform support are there in Qt 5.6 since a long time. It is just a matter of having solid WEC13 BSPs to test and fix possible glitches. And in any case WEC13 is not a new platform, just a successor in a long line of WinCE products. We typically bring support to, for example, new OS X releases in a patch release of a LTS Qt (like Qt 4.8). Therefore, I see no reason why someone using WEC13 could not stay with Qt 5.6 LTS if the functionality is fit for they needs. Especially since Qt 5.6 will be supported longer than Qt 5.7. Yours, Tuukka > > Regards, > -- > Sérgio Martins | sergio.martins at kdab.com | Software Engineer Klarälvdalens > Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The > Qt Experts From Morten.Sorvig at theqtcompany.com Wed Feb 24 08:30:50 2016 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Wed, 24 Feb 2016 07:30:50 +0000 Subject: [Development] Qt Nacl In-Reply-To: <13A41B2A-0388-4D8E-867C-62A2E3014712@pasco.com> References: <13A41B2A-0388-4D8E-867C-62A2E3014712@pasco.com> Message-ID: > On 23 Feb 2016, at 18:00, Jon Mullen wrote: > > Hey > > I’m trying to figure out how far along the Qt Nacl code is and if I’m able to use it on the project I’m working on. I have the code built from the qtbase wip/nacl branch. However, when I go to run the example window_widgets none of the UI seems to work. The line edit shows that it is focused, but never receives keyboard events. Also, once the line edit loses focus it never is able to get focus back again. It seems like all user input isn’t working. Is this the case? > > Any help would be appreciated. Hi, I can confirm that this is an “upstream” bug and not something that goes wrong on your end only. Input works in the general case and for Qt Quick. (You may use window_controls_gallery to verify). My guess is that something is not right with the widgets/QApplication even routing. Morten From rpzrpzrpz at gmail.com Wed Feb 24 08:32:29 2016 From: rpzrpzrpz at gmail.com (mark diener) Date: Wed, 24 Feb 2016 01:32:29 -0600 Subject: [Development] [Announce] Qt 5.6.0 RC released In-Reply-To: References: Message-ID: Hello List: Anybody running OSX El Capitan 10.11 with Qt 5.6.0 RC and IOS 9.2 and Xcode 7.2 and able to successfully debug under IOS Simulator? https://bugreports.qt.io/browse/QTCREATORBUG-15705 Any comments appreciated, md On Tue, Feb 23, 2016 at 11:41 PM, List for announcements regarding Qt releases and development wrote: > Hi all, > > > > Qt 5.6.0 RC is now released, see > http://blog.qt.io/blog/2016/02/23/qt-5-6-0-release-candidate-available/ > > > > Big thanks to everyone involved! > > > Best regards, > > Jani Heikkinen > > Release Manager | The Qt Company > > > > The Qt Company / Digia Finland Ltd, Elektroniikkatie 10, 90590 Oulu, Finland > > www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, > @Qtproject Facebook: www.facebook.com/qt > > > > > > _______________________________________________ > Announce mailing list > Announce at qt-project.org > http://lists.qt-project.org/mailman/listinfo/announce > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From milian.wolff at kdab.com Wed Feb 24 11:27:24 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Wed, 24 Feb 2016 11:27:24 +0100 Subject: [Development] Reduced availability In-Reply-To: <11560802.NkgIKCBGpm@tjmaciei-mobl4> References: <11560802.NkgIKCBGpm@tjmaciei-mobl4> Message-ID: <2423142.dHG1fhSYi4@agathebauer> On Dienstag, 23. Februar 2016 20:13:01 CET Thiago Macieira wrote: > Hello > > This to let everyone know I have been and will continue to be extremely busy > with other projects at work. Please do not expect me to react to Gerrit > reviews (mine or someone else's) until mid-April. > > If you need my attention, please send me an email or ping me on IRC. > > If any of my pending changes should become needed before April, please > update and push it. > > I will continue to read email and attend the release meetings. Hey Thiago, there is at least one change for 5.7 where people are currently blocked waiting for your input and expertise: Optimized QReadWriteLock: https://codereview.qt-project.org/#/c/140322/ I'd really like to see this get merged sooner rather than later to extend the exposure of the patch. Thanks -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From helio at kde.org Wed Feb 24 12:38:48 2016 From: helio at kde.org (Helio Chissini de Castro) Date: Wed, 24 Feb 2016 12:38:48 +0100 Subject: [Development] [Announce] Qt 5.6.0 RC released In-Reply-To: References: Message-ID: Hello Jani Thanks for the packages and submodules in .tar.xz We can confirm from our side that at least in Fedora all modules compiled fine and are in testing repositories. Regards On Wed, Feb 24, 2016 at 6:41 AM, List for announcements regarding Qt releases and development wrote: > Hi all, > > > > Qt 5.6.0 RC is now released, see > http://blog.qt.io/blog/2016/02/23/qt-5-6-0-release-candidate-available/ > > > > Big thanks to everyone involved! > > > Best regards, > > Jani Heikkinen > > Release Manager | The Qt Company > > > > The Qt Company / Digia Finland Ltd, Elektroniikkatie 10, 90590 Oulu, > Finland > > www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @ > Qtproject Facebook: www.facebook.com/qt > > > > > _______________________________________________ > Announce mailing list > Announce at qt-project.org > http://lists.qt-project.org/mailman/listinfo/announce > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.kelly at ableton.com Wed Feb 24 13:14:46 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Wed, 24 Feb 2016 13:14:46 +0100 Subject: [Development] Making ItemSelectionModel more useful In-Reply-To: <56C859E0.8030400@users.sourceforge.net> References: <56C859E0.8030400@users.sourceforge.net> Message-ID: <56CD9EB6.1090702@ableton.com> On 20/02/16 13:19, Alberto Mardegan wrote: > Hi all! > Since Qt 5.5, the QItemSelectionModel class is exposed to QML as > ItemSelectionModel (in the QtQml.Models module): > > http://doc.qt.io/qt-5/qml-qtqml-models-itemselectionmodel.html > > Apart from having almost no documentation, this component seems to be > rather hard to use in QML: its methods work with QModelIndex (while all > the models I've ever used in QML just speak row numbers) or > QItemSelection, which I believe is not usable in QML at all (at least, > it's not documented as a QML component). Hi Alberto, I think you're right about the integration of QAbstractItemModel related classes and QML types not being ideal. The recent addition of QItemSelectionModel support (for the TreeView) is a significant step forward, but some utilities are still missing. Mostly what's missing is just some declarative-friendly APIs for things that already exist in an imperative form. I've written several such components in work over the last year which I am upstreaming when I get the chance. Here's the SelectionInfo element, which I find particularly useful, and I just now uploaded: https://codereview.qt-project.org/#/c/150234/ It allows querying in a declarative way whether a particular QModelIndex is 'selected' or 'current'. I'd be happy for any feedback at this point! Thanks, Steve. -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 From gerry.boland at canonical.com Wed Feb 24 15:24:58 2016 From: gerry.boland at canonical.com (Gerry Boland) Date: Wed, 24 Feb 2016 14:24:58 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: <56CDBD3A.5060405@canonical.com> Hey Simon, I can try offering the Ubuntu Touch perspective on units with QML (sorry if late, was busy for MWC). We created a units system for our QML apps, called grid unit: units.gu(x). We did this as we needed the ability to scale the UI for different devices, from phones with highDpi screens to lowDpi monitors. DevicePixelRatio didn’t exist at the time, and when it appeared, it was too limited unfortunately, as we did not trust that non-integral values would work reliably in QML. And also such values break QWidget-based apps. Grid units are implemented as you predicted: as a context property. It can change at runtime too, as with our convergence strategy, we need apps to rescale dynamically at runtime. (We also have "device pixels" units.dp(x), which will map directly to your proposed logical pixels, which is good. But that is primarily used for things to be 1 or 2 pixel wide, like line thickness). We've implemented special image loaders that will respect this unit system. This all works, and we've found it clunky but not too troublesome so far. There are disadvantages however: 1. overhead of function call of a context property for every size specifier 2. multimonitor situations, we would like to have different scales on individual monitors. Context property not allowing that, so we need to rethink that. 3. does conflict with DevicePixelRatio somewhat. I've worked hard to make them work together, but the complexity is unpleasant, and I’ve still not solved all issues. 4. there are a few other internal non-visual tweaks Qt does which depends on DPR, but naturally not our grid unit value. This is why 3. above (marrying DPR and grid units) is being done at all, else we’d just ignore DPR for longer. So I'd be very happy to see some work on adding some concept of units to QML. Perhaps we are asking too much to allow registration of a custom unit system at QmlEngine startup? We'd love to enable app authors to write: Rectangle { width: 10gu; height 5gu; } and have the value runtime updatable. I understand that would make parsing harder though, and that our requirements are probably more complex than the norm. Instead, I thought about embracing your proposed logical/physical pixels approach. Our requirements would mean we have to allow logical pixels to be more varied than x2, x3... of the physical pixels - i.e. need float DPR values. However one of the fundamental ideas of the grid unit was to help UI layout consistency - it helps developers line-up their UI elements to be visually appealing. To look best, elements should be positioned on pixel-boundaries to ensure sharp edges. So units.gu always returns an integer. But using a pure float scale with your proposed logical pixels (or just today’s QML with a float DPR), I fear that something like: Rectangle { color: “red”; width: 10; height: 10; x: 5 } with a 1.5x scale, will be positioned at 7.5px and so will not have a sharp left/right edge. So unfortunately I fear your physical/logical pixels proposal is not of much use to us on Ubuntu Touch. We can use them to replace our units.dp "device pixels" thing, but our primary scaling system: grid units, won't work with it. Thanks for looking into this nonetheless. -Gerry On 18/02/16 10:50, Hausmann Simon wrote: > Hi, > > A little while ago Lars and I proposed to introduce physical units in the QML language for use in QtQuick. The idea was to make it easier to write user interfaces that adapt to different display resolutions by "pinning" your UI to physical dimensions. For example you could say > > Image { > source: "mypprofilephoto.png" > width: 5cm > height: 5cm > } > > and the image size in physical pixels would scale accordingly to always produce a 5cmx5cm profile image on the screen. The proposed units included "px", which was really an alias for nothing. > > We've had some very good discussions around this at last year's contributor summit as well as in smaller face-to-face discussions. The main feedback I recall was that this would seem like a nice feature on paper but in practice people create their resolution independent interfaces using the current "pixels" and a scale factor that they introduce in a qml file or as a context property. That's another way of saying that perhaps the feature wouldn't really find any use, which is fair :). Instead the desire was expressed that making it _easier_ to scale "logical" pixels in the application would perhaps be better. > > So today during a discussion another idea came up: > > (1) In order to make it really easy to scale "logical" pixels without having to introduce your own context property or factor in a .qml file that you multiply everywhere, we could turn the regular "pixels" in QtQuick into truly logical pixels that scale with an application wide (or window wide) factor. So Image { width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 physical pixels on a x2 display. This assumes the availability of API to change this mapping. > > (2) In the events where you still _want_ to use physical pixels, you could use "px" units. > > So at first nothing would change for app developers at all because we map logical pixels to physical pixels. But > if you'd like to, you could opt into changing this mapping and having a relatively easy fallback to physical pixels using for example the "px" unit. We might as well offer the other physical units anyway, that probably causes little to no harm. > > What do you think? > > Simon > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From thiago.macieira at intel.com Wed Feb 24 17:16:25 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 Feb 2016 08:16:25 -0800 Subject: [Development] Reduced availability In-Reply-To: <2423142.dHG1fhSYi4@agathebauer> References: <11560802.NkgIKCBGpm@tjmaciei-mobl4> <2423142.dHG1fhSYi4@agathebauer> Message-ID: <1598072.GtY4RBlcby@tjmaciei-mobl4> On quarta-feira, 24 de fevereiro de 2016 11:27:24 PST Milian Wolff wrote: > > If you need my attention, please send me an email or ping me on IRC. > > Hey Thiago, > > there is at least one change for 5.7 where people are currently blocked > waiting for your input and expertise: > > Optimized QReadWriteLock: > https://codereview.qt-project.org/#/c/140322/ > > I'd really like to see this get merged sooner rather than later to extend > the exposure of the patch. Hi Milian I will take a look at that one. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mail at michaelmoellney.de Wed Feb 24 22:38:56 2016 From: mail at michaelmoellney.de (=?UTF-8?Q?Michael_M=c3=b6llney?=) Date: Wed, 24 Feb 2016 22:38:56 +0100 Subject: [Development] Qt 5.6 LTS - who defines criteria what gets "bug fixed" Message-ID: <56CE22F0.1060604@michaelmoellney.de> Now (finally) Qt 5.6.0 LTS knocks at the door (RC published today) I appreciate the decisions to support this 5.6.x release for at least 3 years, plus possible time extension. Looking for a definition what this actually means, I could find in Planet Qt http://blog.qt.io/blog/2016/02/22/qt-roadmap-for-2016/ : [quote] Long-Term Support Qt 5.6 is the first Long-Term Supported (LTS) version of Qt since Qt 4.8. As part of our LTS promise, we guarantee that Qt 5.6 will be supported for three years via standard support, after which additional extended support can be purchased. During this time period, even though following Qt releases (Qt 5.7, Qt 5.8 and so on) are available, Qt 5.6 will receive patch releases providing bug fixes and security updates throughout the three-year period after the release. [quote] This sounds good: support, bug fixes and security updates! Yeah! In other mailing list threads (http://lists.qt-project.org/pipermail/development/2016-February/024943.html) there is even discussion if platforms that might establish in these 3 years should get support... wow! But who decides or gives guidance to the developers, if a bug found in 5.6.x should be fixed in this LTS. E.g. have a look at a patch history in https://codereview.qt-project.org/#/c/109157/ That patch evolved through 5.4, 5.5, 5.6 and now is moved to 5.7 with advice to use C++11 features. The comments finally focused in a discussion on what branch/release to put that particular bug fix / behavior change. There is some arguing that this patch is a "behavior change", but which fix is not a behavior change. Sometimes bugs do not crash they "just" do not what the documentation says: It's not always easy to tell. So my question or suggestion to reduced bug fixing time is: - Is there or should there be an authority/committee that decides early, if a bug is worth to be fixed for 5.6 LTS? Maybe in bugreports.qt.io: if the "Affects Version/s" contains "5.6.x" the authority could "Label" it 5.6-LTS to hint the fixing branch? - Is there or should there be a Wiki-Page giving rules of thump, what inconsistent between API docs and actual behavior is a bug that should be fixed in 5.6 LTS? I think this could help developers to decide early, if the patch should evolve with old compiler compatibility and becomes a fix in 5.6.x, or if the developer should jump directly to the 5.7 branch and make use of nice C++11 features. Cheers, Michael From alexander.blasche at theqtcompany.com Wed Feb 24 22:53:06 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Wed, 24 Feb 2016 21:53:06 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <56CCA210.8090309@kdab.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <3260609.aQ307eygZ4@tjmaciei-mobl4> <7F8EC774-27EF-4343-B49E-5FA9C225C141@theqtcompany.com> <6592024.SiRXsdEexG@tjmaciei-mobl4> <56CCA210.8090309@kdab.com> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=theqtcompany.com at qt-project.org] On Behalf Of > Andreas Holzammer ... > Am 22.02.2016 um 23:52 schrieb Thiago Macieira: > > On segunda-feira, 22 de fevereiro de 2016 21:08:12 PST Knoll Lars wrote: > >> I can see the reasoning here, just as well as I see the reasoning of the > >> people that would like to get rid of VS2012 as quickly as possible. > > > > Why do we need to get rid of it? What are the problems with it, aside from > > lack of certain C++11 support? > > > > Mostly yes we see a demand in getting new c++ features into Qt. As far > as my knowlege goes is that WEC2013 bundles they compiler with the SDK > which is produced by the Platform Builder. As of now I did not see any > indication that this bundled compiler will be updated(right now they > bundle the VS2012 compiler). All websites which I did read say if you > read closely that they are supporting the new Visual Studio IDE, but > will take the toolchain of the SDK which is provided. > > Basically it means we are stuck with Visual Studio 2012 c++ featureset > for Windows Embedded Compact 2013. I spoke to the Microsoft guys on Embedded World today. They confirmed that it is 2012 and there are no plans to update this. In fact that went as far as saying that the relevant development team behind WEC2013 has been abandoned to the point that the essential support is barely possible. > If we want to support newer C++ with Qt 5.8 we would need to drop the > complete platform. And this is the main reason behind this push. > On terça-feira, 23 de fevereiro de 2016 19:16:48 PST Andreas Holzammer wrote: > > As of problems to support it in newer Qt Versions, I can say the market > > share right now is not very big, as also already indicated by someone > > else. Hardware vendors do release right now more experimental support > > for WEC2013, which means there might be years until they reach a decent > > market share. > > To be clear: are you expecting WEC2013 market share to increase? Those projects which would grow this market would have to have acquired their license already as I have heard that new WEC2013 licenses are not handed out anymore. At the very least you have to "twist" Microsoft's arms to get hold of one. That's not a good starting point for a growing market. This is a firm Micosoft management decision despite the mentioned offering gaps. >On Tuesday, 23 February 2016 13:09:10 WET Thiago Macieira wrote: > > But you cannot commit major refactorings to improve stability in an patch > > release, especially not the LTS release. Remember that 5.6 is also the last > > release to support WEC7, so you cannot risk its stability for a platform > > that's only experimental. > But are we going to need major refactorings ? We need to know the state of > wec2013 before discussing further, no point in speculating on what was meant > by "experimental". The answer is no. The principle feature set is working. There are some gaps related to device debugging but those gaps are due to non-open protocols. The term "Experimental" is a rather bad choice of word. The commitment towards WEC2013 in Qt 5.6 is what really matters due to its LTS character. By the time 5.6 support runs out Qt 5.8 support has been ancient history. In summary Qt does not gain anything from pushing WEC2013 to 5.8: - Potential Qt Customers are not stranded due to 5.6 - WEC2013 in 5.8 doesn't really enable more projects - MS says it is dead and licenses are hard to come by - the currently visible project pipeline is rather dry on this platform *But* our C++11 offering is yet longer chained. There simply is no justification for such a move on the business and technical side. -- Alex From thiago.macieira at intel.com Thu Feb 25 00:13:10 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 Feb 2016 15:13:10 -0800 Subject: [Development] Qt 5.6 LTS - who defines criteria what gets "bug fixed" In-Reply-To: <56CE22F0.1060604@michaelmoellney.de> References: <56CE22F0.1060604@michaelmoellney.de> Message-ID: <1622940.Z8aLHLeKyj@tjmaciei-mobl4> On quarta-feira, 24 de fevereiro de 2016 22:38:56 PST Michael Möllney wrote: > So my question or suggestion to reduced bug fixing time is: > > - Is there or should there be an authority/committee that decides early, > if a bug is worth to be fixed for 5.6 LTS? > Maybe in bugreports.qt.io: if the "Affects Version/s" contains > "5.6.x" the authority > could "Label" it 5.6-LTS to hint the fixing branch? > - Is there or should there be a Wiki-Page giving rules of thump, what > inconsistent between API docs and actual behavior > is a bug that should be fixed in 5.6 LTS? The current rule should still apply: contributors decide among themselves. The author of the patch makes a suggestion, other contributors and approvers may make different suggestions. In case there's no consensus, the maintainer makes a decision. In case there's disagreement with the maintainer's decision, bring it to the mailing list and the Chief Maintainer will decide. Using bugreports.qt.io won't help, since the same people who can set labels and the version fields are the ones in the group above anyway. I really oppose the creation of a committee. We don't need more bureaucracy, especially without a proof that the current methods don't work. I think the above description does work. However, a wiki page giving rules of thumb of what may be acceptable and what may not is a very good idea. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Feb 25 00:17:40 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 Feb 2016 15:17:40 -0800 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <56CCA210.8090309@kdab.com> Message-ID: <1770390.C1vmfgVAFe@tjmaciei-mobl4> On quarta-feira, 24 de fevereiro de 2016 21:53:06 PST Blasche Alexander wrote: > > Basically it means we are stuck with Visual Studio 2012 c++ featureset > > for Windows Embedded Compact 2013. > > I spoke to the Microsoft guys on Embedded World today. (too bad I couldn't go) > They confirmed that it is 2012 and there are no plans to update this. This would support the position that we can't touch our compiler requirements unless we want to change our platform support promises. > In fact that went as far > as saying that the relevant development team behind WEC2013 has been > abandoned to the point that the essential support is barely possible. While this would indicate that people should stay away from WEC2013 and we should really be dropping it, to the point of not even finishing the experimental support. Of course, this is anecdotal information and I wouldn't make business decisions like that. > > If we want to support newer C++ with Qt 5.8 we would need to drop the > > complete platform. > > And this is the main reason behind this push. See Marc's reply to my list of enabled features. I didn't find anything there that would be compelling enough to warrant dropping a platform we've only barely added anyway. > The answer is no. The principle feature set is working. There are some gaps > related to device debugging but those gaps are due to non-open protocols. > The term "Experimental" is a rather bad choice of word. > > The commitment towards WEC2013 in Qt 5.6 is what really matters due to its > LTS character. By the time 5.6 support runs out Qt 5.8 support has been > ancient history. > > In summary Qt does not gain anything from pushing WEC2013 to 5.8: > > - Potential Qt Customers are not stranded due to 5.6 > - WEC2013 in 5.8 doesn't really enable more projects > - MS says it is dead and licenses are hard to come by > - the currently visible project pipeline is rather dry on this platform > > *But* our C++11 offering is yet longer chained. So why are we bothering with VS2012 for Qt 5.7 then? Why wait until 5.8? Let's drop it now. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From michael.brasser at live.com Thu Feb 25 01:41:01 2016 From: michael.brasser at live.com (Michael Brasser) Date: Thu, 25 Feb 2016 00:41:01 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: Message-ID: Hi, Regarding (2), last time around I had concerns about the proposed limitations associated with language-level unit support (see some of the discussion at https://codereview.qt-project.org/98288). I'd be interested to hear the particulars of what unit support might look like this time around. Regards, Michael ________________________________________ From: Development on behalf of Hausmann Simon Sent: Thursday, February 18, 2016 4:50 AM To: development at qt-project.org Subject: [Development] Scalable UIs in QtQuick (take 2) Hi, A little while ago Lars and I proposed to introduce physical units in the QML language for use in QtQuick. The idea was to make it easier to write user interfaces that adapt to different display resolutions by "pinning" your UI to physical dimensions. For example you could say Image { source: "mypprofilephoto.png" width: 5cm height: 5cm } and the image size in physical pixels would scale accordingly to always produce a 5cmx5cm profile image on the screen. The proposed units included "px", which was really an alias for nothing. We've had some very good discussions around this at last year's contributor summit as well as in smaller face-to-face discussions. The main feedback I recall was that this would seem like a nice feature on paper but in practice people create their resolution independent interfaces using the current "pixels" and a scale factor that they introduce in a qml file or as a context property. That's another way of saying that perhaps the feature wouldn't really find any use, which is fair :). Instead the desire was expressed that making it _easier_ to scale "logical" pixels in the application would perhaps be better. So today during a discussion another idea came up: (1) In order to make it really easy to scale "logical" pixels without having to introduce your own context property or factor in a .qml file that you multiply everywhere, we could turn the regular "pixels" in QtQuick into truly logical pixels that scale with an application wide (or window wide) factor. So Image { width: 100 ... } will scale automatically from 100 logical pixels to maybe 200 physical pixels on a x2 display. This assumes the availability of API to change this mapping. (2) In the events where you still _want_ to use physical pixels, you could use "px" units. So at first nothing would change for app developers at all because we map logical pixels to physical pixels. But if you'd like to, you could opt into changing this mapping and having a relatively easy fallback to physical pixels using for example the "px" unit. We might as well offer the other physical units anyway, that probably causes little to no harm. What do you think? Simon _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From tuukka.turunen at theqtcompany.com Thu Feb 25 07:17:58 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Thu, 25 Feb 2016 06:17:58 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <1770390.C1vmfgVAFe@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <56CCA210.8090309@kdab.com> <1770390.C1vmfgVAFe@tjmaciei-mobl4> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=theqtcompany.com at qt-project.org] On Behalf Of > Thiago Macieira > Sent: torstaina 25. helmikuuta 2016 0.18 > To: development at qt-project.org > Subject: Re: [Development] Supported platforms for Qt 5.8 > > On quarta-feira, 24 de fevereiro de 2016 21:53:06 PST Blasche Alexander > wrote: > > > > The commitment towards WEC2013 in Qt 5.6 is what really matters due to > > its LTS character. By the time 5.6 support runs out Qt 5.8 support has > > been ancient history. > > > > In summary Qt does not gain anything from pushing WEC2013 to 5.8: > > > > - Potential Qt Customers are not stranded due to 5.6 > > - WEC2013 in 5.8 doesn't really enable more projects > > - MS says it is dead and licenses are hard to come by > > - the currently visible project pipeline is rather dry on this > > platform > > > > *But* our C++11 offering is yet longer chained. > > So why are we bothering with VS2012 for Qt 5.7 then? Why wait until 5.8? > > Let's drop it now. > That is fine for me as well. As Alex wrote, most important is that Qt 5.6 LTS supports both WEC7 and WEC13 and that latest for Qt 5.8 we no longer have these to slow down adoption of C++11 and other planned changes. Yours, Tuukka From shiva.s at rsageventures.com Thu Feb 25 08:46:50 2016 From: shiva.s at rsageventures.com (Shiva sitamraju) Date: Thu, 25 Feb 2016 13:16:50 +0530 Subject: [Development] QDesktopWidget for an X display Message-ID: Hi, I am trying to put a widget on a given X Display from inside QT application. Also posted same question on stackexchange http://stackoverflow.com/questions/35498895/qdesktopwidget-for-an-x-display . Would be very grateful if anyone can help me in this regards Shiva -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Thu Feb 25 08:48:25 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 25 Feb 2016 08:48:25 +0100 Subject: [Development] Units in QML (was: Re: Scalable UIs in QtQuick (take 2)) In-Reply-To: References: Message-ID: <56CEB1C9.1020404@familiesomers.nl> Op 25/02/2016 om 01:41 schreef Michael Brasser: > Hi, > > Regarding (2), last time around I had concerns about the proposed limitations associated with language-level unit support (see some of the discussion at https://codereview.qt-project.org/98288). I'd be interested to hear the particulars of what unit support might look like this time around. > > Regards, > Michael > Thanks for bringing up that patch again, and pointing out your (valid!) concerns there as well again. I think that generic unit support in the QML language would be awesome to have, but indeed I don't like it to be tied too much to Quick and screens. It would be great if it were possible somehow to define your own units in Quick or whatever other domain specific use you make of the language, and you then specify properties using those units in quantities instead of plain numerical values as we do now. Numerical values could be implicitly convertable to quantities, but not to each other unless such a relation is explicitly defined. That should prevent anyone from trying to do 3cm + 4s. Perhaps the basic units and their relations could be defined by default already (the different length units like mm, cm, m*, inch, and the different time units ms, s, m*, h, day), and then adding domain specific units like px at the Quick level. In a domain application like aviation you may want to add specific units like FL (fleight level; which is an altitude in hundreds of feet above a standard isobaric reference plain at 1013,2 hectopascal), feet_QNH or m_QNH which can depend on some context variable. Properties would be in some defined unit, and any numerical value assigned to that would be implicitly be regarded to be specified into that unit. André )* Note the first clash already... From edward.welbourne at theqtcompany.com Thu Feb 25 10:33:04 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 25 Feb 2016 09:33:04 +0000 Subject: [Development] Qt 5.6 LTS - who defines criteria what gets "bug fixed" In-Reply-To: <1622940.Z8aLHLeKyj@tjmaciei-mobl4> References: <56CE22F0.1060604@michaelmoellney.de>, <1622940.Z8aLHLeKyj@tjmaciei-mobl4> Message-ID: On quarta-feira, 24 de fevereiro de 2016 22:38:56 PST Michael Möllney wrote: >> - Is there or should there be a Wiki-Page giving rules of thump, what >> inconsistent between API docs and actual behavior is a bug that >> should be fixed in 5.6 LTS? (I like the concept of a "rule of thump", but it would mean something different than the usual English idiom to which Thiago revised it.) Thiago Macieira replied (inter alia): > However, a wiki page giving rules of thumb of what may be acceptable > and what may not is a very good idea. I'd also be glad of such a page - I get to do bug triage (setting priority on newly submitted bugs) some sporadic weeks and would be glad of some guidance on what kinds of bug deserve what priority. As an illustration: when I use Debian's reportbug facility, it asks me about the severity (roughly corresponding to priority) of the issue and explains carefully (see [0]) what the Debian project's criteria are for each severity level. [0] https://www.debian.org/Bugs/Developer#severities Having some similar explanation for the priorities we use would give some clarity and likely improve consistency among triagers. It'll surely retain some subjective element, but guidelines would give me more confidence that my evaluation is in line with consensus. Submitters might also get more of a sense of their reports being evaluated justly. Decisions about what should be considered for LTS are at least kindred to those for priority and it would make sense to document them together, Eddy. From Kai.Koehne at theqtcompany.com Thu Feb 25 10:47:56 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Thu, 25 Feb 2016 09:47:56 +0000 Subject: [Development] Qt 5.6 LTS - who defines criteria what gets "bug fixed" In-Reply-To: References: <56CE22F0.1060604@michaelmoellney.de>, <1622940.Z8aLHLeKyj@tjmaciei-mobl4> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of > Welbourne Edward > Sent: Thursday, February 25, 2016 10:33 AM > To: development at qt-project.org > Subject: Re: [Development] Qt 5.6 LTS - who defines criteria what gets "bug > fixed" > [...] > I'd also be glad of such a page - I get to do bug triage (setting priority on > newly submitted bugs) some sporadic weeks and would be glad of some > guidance on what kinds of bug deserve what priority. As an > illustration: when I use Debian's reportbug facility, it asks me about the > severity (roughly corresponding to priority) of the issue and explains > carefully (see [0]) what the Debian project's criteria are for each severity > level. The current descriptions of the priorities in JIRA [1] IMO aren't too helpful, since they focus too much on impact on a release. But I also feel that the right priority is a computation of several factors, including Severity, Impact, whether it's a regression, and whether there's a workaround. Based on this I tried to come up with an 'algorithm' for JIRA bug priorities a while ago: https://wiki.qt.io/JIRA-Priorities In general I think the prioritization works somewhat, except that we're putting way too many things in the P2 basket. Kai [1]: https://bugreports.qt.io/secure/ShowConstantsHelp.jspa?#PriorityLevels From Shawn.Rutledge at theqtcompany.com Thu Feb 25 10:47:59 2016 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Thu, 25 Feb 2016 09:47:59 +0000 Subject: [Development] QDesktopWidget for an X display In-Reply-To: References: Message-ID: <7E6E3E81-127B-4989-916C-0D45F7EB90A5@digia.com> On 25 Feb 2016, at 08:46, Shiva sitamraju > wrote: Hi, I am trying to put a widget on a given X Display from inside QT application. Also posted same question on stackexchange http://stackoverflow.com/questions/35498895/qdesktopwidget-for-an-x-display . Would be very grateful if anyone can help me in this regards I answered it on stackoverflow. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Smith at theqtcompany.com Thu Feb 25 10:56:01 2016 From: Martin.Smith at theqtcompany.com (Smith Martin) Date: Thu, 25 Feb 2016 09:56:01 +0000 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ Message-ID: Send ideas for upgrading the Qt documentation to C++11. 1. Which C++11 constructs will be used in Qt? 2. Which of these should appear in the documentation? Send comments to the CC list. martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Thu Feb 25 11:08:07 2016 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 25 Feb 2016 11:08:07 +0100 Subject: [Development] Qt 5.6 LTS - who defines criteria what gets "bug fixed" In-Reply-To: <1622940.Z8aLHLeKyj@tjmaciei-mobl4> References: <56CE22F0.1060604@michaelmoellney.de> <1622940.Z8aLHLeKyj@tjmaciei-mobl4> Message-ID: <13011123.hhJouJ56l5@finn> Am Mittwoch, 24. Februar 2016, 15:13:10 CET schrieb Thiago Macieira: > On quarta-feira, 24 de fevereiro de 2016 22:38:56 PST Michael Möllney wrote: > > So my question or suggestion to reduced bug fixing time is: > > > > - Is there or should there be an authority/committee that decides early, > > if a bug is worth to be fixed for 5.6 LTS? > > > > Maybe in bugreports.qt.io: if the "Affects Version/s" contains > > > > "5.6.x" the authority > > > > could "Label" it 5.6-LTS to hint the fixing branch? > > > > - Is there or should there be a Wiki-Page giving rules of thump, what > > inconsistent between API docs and actual behavior > > > > is a bug that should be fixed in 5.6 LTS? > > The current rule should still apply: contributors decide among themselves. > The author of the patch makes a suggestion, other contributors and > approvers may make different suggestions. In case there's no consensus, the > maintainer makes a decision. The problem is that then not the same standards are applied to everything. > In case there's disagreement with the maintainer's decision, bring it to the > mailing list and the Chief Maintainer will decide. > > Using bugreports.qt.io won't help, since the same people who can set labels > and the version fields are the ones in the group above anyway. > > I really oppose the creation of a committee. We don't need more bureaucracy, > especially without a proof that the current methods don't work. I think the > above description does work. > > However, a wiki page giving rules of thumb of what may be acceptable and > what may not is a very good idea. There is already a wiki page about that. https://wiki.qt.io/Branch_Guidelines#Where_to_push_a_change.3F Should it be relaxed to more changes "because it is a LTS"? I don't really understand why make a difference between bugs that are not regressions, and new features. Fixing bugs is usually changing behaviour and touching existing code which makes it more risky to introduces new bugs or break existing applications. New feature on the other hand, since they add new code, are less likely to break applications. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From jedrzej.nowacki at theqtcompany.com Thu Feb 25 11:10:52 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Thu, 25 Feb 2016 11:10:52 +0100 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: References: Message-ID: <15191409.E6E0AdK8cQ@42> On Thursday 25 of February 2016 09:56:01 Smith Martin wrote: > Send ideas for upgrading the Qt documentation to C++11. > > 1. Which C++11 constructs will be used in Qt? All of them, in longer run C++14 too :-) > 2. Which of these should appear in the documentation? I do not understand the question. All of them that are documented? Cheers, Jędrek From cristian.adam at gmail.com Thu Feb 25 11:20:16 2016 From: cristian.adam at gmail.com (Cristian Adam) Date: Thu, 25 Feb 2016 11:20:16 +0100 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: References: Message-ID: On Thu, Feb 25, 2016 at 10:56 AM, Smith Martin < Martin.Smith at theqtcompany.com> wrote: > Send ideas for upgrading the Qt documentation to C++11. > > > 1. Which C++11 constructs will be used in Qt? > > > 2. Which of these should appear in the documentation? > > > Send comments to the CC list. > Since qdoc will be using libclang, any change of getting the same treatment for moc? See more about moc-ng (based on libclang) here: https://woboq.com/blog/moc-myths.html and here: https://woboq.com/blog/moc-with-clang.html Qt installers ship Qt Creator, and Qt Creator ships libclang for the clang code model. It should be easy to move libclang out from Qt Creator and be used by qdoc and moc-ng. Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at theqtcompany.com Thu Feb 25 11:20:45 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 25 Feb 2016 10:20:45 +0000 Subject: [Development] Units in QML (was: Re: Scalable UIs in QtQuick (take 2)) In-Reply-To: <56CEB1C9.1020404@familiesomers.nl> References: , <56CEB1C9.1020404@familiesomers.nl> Message-ID: André Somers used m* for minutes and metres, footnoting: > )* Note the first clash already... I think it is fairly sane to just insist that SI units take precedence, especially given that we support multi-letter unit names (e.g. pt, px, mm, cm), so min will do fine for minutes. > Numerical values could be implicitly convertable to quantities, but > not to each other unless such a relation is explicitly defined. That > should prevent anyone from trying to do 3cm + 4s. While I agree, I should note that the general case (for a language in which units are first-class citizens) would need to deal with the fact that some contexts shall want to deem certain dimensioned quantities as unities. In particular, theoretical physicists routinely treat the speed of light as 1 (not 1 length-unit per time-unit but the pure number 1), identifying lengths and times as being "of the same kind". At that point, 3cm is about a tenth of a light nano-second, so 3cm + 4s = 4.0000000001s is perfectly good arithmetic. I mention this mostly as an argument against *trying* to deal with the fully general case ... Eddy. From andre at familiesomers.nl Thu Feb 25 11:26:58 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 25 Feb 2016 11:26:58 +0100 Subject: [Development] Units in QML In-Reply-To: References: <56CEB1C9.1020404@familiesomers.nl> Message-ID: <56CED6F2.6060409@familiesomers.nl> Op 25/02/2016 om 11:20 schreef Welbourne Edward: > André Somers used m* for minutes and metres, footnoting: >> )* Note the first clash already... > I think it is fairly sane to just insist that SI units take precedence, > especially given that we support multi-letter unit names (e.g. pt, px, > mm, cm), so min will do fine for minutes. Sure, fair point. It just goes to show that one will have to be careful claiming units in order not to cause clashes later on. > >> Numerical values could be implicitly convertable to quantities, but >> not to each other unless such a relation is explicitly defined. That >> should prevent anyone from trying to do 3cm + 4s. > While I agree, I should note that the general case (for a language in > which units are first-class citizens) would need to deal with the fact > that some contexts shall want to deem certain dimensioned quantities as > unities. In particular, theoretical physicists routinely treat the > speed of light as 1 (not 1 length-unit per time-unit but the pure number > 1), identifying lengths and times as being "of the same kind". At that > point, 3cm is about a tenth of a light nano-second, so 3cm + 4s = > 4.0000000001s is perfectly good arithmetic. I mention this mostly as an > argument against *trying* to deal with the fully general case ... > > Eddy. What's wrong with in that case defining the conversion? Or resetting the default conversions and defining everything in "space-time"? André From Martin.Smith at theqtcompany.com Thu Feb 25 11:31:06 2016 From: Martin.Smith at theqtcompany.com (Smith Martin) Date: Thu, 25 Feb 2016 10:31:06 +0000 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: <15191409.E6E0AdK8cQ@42> References: , <15191409.E6E0AdK8cQ@42> Message-ID: I mean, for example, if a class is "final" how should this be stated in the documentation? Should qdoc automatically include "This class may not be used as a base class." or should qdoc just include the word "final" in the title? martin ________________________________________ From: Nowacki Jedrzej Sent: Thursday, February 25, 2016 11:10 AM To: development at qt-project.org Cc: Smith Martin Subject: Re: [Development] We are planning to upgrade qdoc to use clang for parsing C++ On Thursday 25 of February 2016 09:56:01 Smith Martin wrote: > Send ideas for upgrading the Qt documentation to C++11. > > 1. Which C++11 constructs will be used in Qt? All of them, in longer run C++14 too :-) > 2. Which of these should appear in the documentation? I do not understand the question. All of them that are documented? Cheers, Jędrek From karsten.heimrich at digia.com Thu Feb 25 12:08:36 2016 From: karsten.heimrich at digia.com (Karsten Heimrich) Date: Thu, 25 Feb 2016 12:08:36 +0100 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: References: Message-ID: <00b501d16fbc$e1fb1b80$a5f15280$@digia.com> Hi, From: Development [mailto:development-bounces+karsten.heimrich=theqtcompany.com at qt-project.org] On Behalf Of Cristian Adam Sent: Donnerstag, 25. Februar 2016 11:20 Uhr To: Smith Martin Cc: development at qt-project.org Subject: Re: [Development] We are planning to upgrade qdoc to use clang for parsing C++ On Thu, Feb 25, 2016 at 10:56 AM, Smith Martin > wrote: Send ideas for upgrading the Qt documentation to C++11. 1. Which C++11 constructs will be used in Qt? 2. Which of these should appear in the documentation? Send comments to the CC list. Since qdoc will be using libclang, any change of getting the same treatment for moc? I’ve heard these now several times without finding any reasonable source for the rumor. Can please someone point me to the place where this is stated. --Karsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From Martin.Smith at theqtcompany.com Thu Feb 25 12:17:12 2016 From: Martin.Smith at theqtcompany.com (Smith Martin) Date: Thu, 25 Feb 2016 11:17:12 +0000 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: <00b501d16fbc$e1fb1b80$a5f15280$@digia.com> References: , <00b501d16fbc$e1fb1b80$a5f15280$@digia.com> Message-ID: I'm stating it now. What is your objection? martin ________________________________ From: Development on behalf of Karsten Heimrich Sent: Thursday, February 25, 2016 12:08 PM To: development at qt-project.org Subject: Re: [Development] We are planning to upgrade qdoc to use clang for parsing C++ Hi, From: Development [mailto:development-bounces+karsten.heimrich=theqtcompany.com at qt-project.org] On Behalf Of Cristian Adam Sent: Donnerstag, 25. Februar 2016 11:20 Uhr To: Smith Martin Cc: development at qt-project.org Subject: Re: [Development] We are planning to upgrade qdoc to use clang for parsing C++ On Thu, Feb 25, 2016 at 10:56 AM, Smith Martin > wrote: Send ideas for upgrading the Qt documentation to C++11. 1. Which C++11 constructs will be used in Qt? 2. Which of these should appear in the documentation? Send comments to the CC list. Since qdoc will be using libclang, any change of getting the same treatment for moc? I've heard these now several times without finding any reasonable source for the rumor. Can please someone point me to the place where this is stated. --Karsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at theqtcompany.com Thu Feb 25 12:27:05 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 25 Feb 2016 11:27:05 +0000 Subject: [Development] Qt 5.6 LTS - who defines criteria what gets "bug fixed" In-Reply-To: References: <56CE22F0.1060604@michaelmoellney.de>, <1622940.Z8aLHLeKyj@tjmaciei-mobl4> , Message-ID: Koehne Kai added, to the discussion of priorities and LTS, > The current descriptions of the priorities in JIRA [1] IMO aren't too > helpful, since they focus too much on impact on a release. The release is in the (possibly distant) future when prioritising; and, when doing triage, I don't know which release shall fix a bug, unless it's so high priority it must be in the next release. I'd sooner have priority definitions in terms of what I can see when it's submitted. I think those deciding LTS questions need the same. > But I also feel that the right priority is a computation of several > factors, including Severity, Impact, whether it's a regression, and > whether there's a workaround. > > Based on this I tried to come up with an 'algorithm' for JIRA bug > priorities a while ago: That sounds like the page we should expand for what we want here. I've duly added > https://wiki.qt.io/JIRA-Priorities and > [1]: https://bugreports.qt.io/secure/ShowConstantsHelp.jspa?#PriorityLevels to the links section of our Triage Dashboard in Jira, Eddy. From karsten.heimrich at digia.com Thu Feb 25 12:39:25 2016 From: karsten.heimrich at digia.com (Karsten Heimrich) Date: Thu, 25 Feb 2016 12:39:25 +0100 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: References: , <00b501d16fbc$e1fb1b80$a5f15280$@digia.com> Message-ID: <00c701d16fc1$300796b0$9016c410$@digia.com> Hi, From: Smith Martin [mailto:Martin.Smith at theqtcompany.com] Sent: Donnerstag, 25. Februar 2016 12:17 Uhr To: Heimrich Karsten ; development at qt-project.org Subject: Re: [Development] We are planning to upgrade qdoc to use clang for parsing C++ I'm stating it now. What is your objection? martin no objections. As I said, I've heard it several times without someone knowing the source. Talked to Kai now and found where it originated from. --Karsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From mardy at users.sourceforge.net Thu Feb 25 12:49:01 2016 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Thu, 25 Feb 2016 14:49:01 +0300 Subject: [Development] Units in QML In-Reply-To: References: <56CEB1C9.1020404@familiesomers.nl> Message-ID: <56CEEA2D.9020207@users.sourceforge.net> On 25/02/2016 13:20, Welbourne Edward wrote: > André Somers used m* for minutes and metres, footnoting: >> )* Note the first clash already... > > I think it is fairly sane to just insist that SI units take precedence, > especially given that we support multi-letter unit names (e.g. pt, px, > mm, cm), so min will do fine for minutes. I find this attention to physical units a bit improper. Sure, some drawing applications or text editors should be enabled to draw UI following specific physical dimensions (like, for example, for the ruler bars), but I think it's more of an isolated case than the norm. Most UIs won't set a button's height to 1 cm (or any other physical size), because while such a size might be OK for a desktop + mouse system, it would be definitely be too small for a UI in running a television set and too big for a UI running on a smartwatch. Ciao, Alberto From marc.mutz at kdab.com Thu Feb 25 14:22:55 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 25 Feb 2016 14:22:55 +0100 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: References: Message-ID: <201602251422.55468.marc.mutz@kdab.com> On Thursday 25 February 2016 10:56:01 Smith Martin wrote: > Send ideas for upgrading the Qt documentation to C++11. > > > 1. Which C++11 constructs will be used in Qt? > > > 2. Which of these should appear in the documentation? > > > Send comments to the CC list. It would be nice if std:: types and funcitons automatically linked to .cppreference.com. override and final should indeed appear in the docs, but imo just as part of the function / class signature. Same for constexpr and noexcept, = default and = delete. If a function with override, = default, or = delete has no comment block, it should default to \reimp, \defaulted, and \deleted, resp., with no warning (whatever \defaulted, \deleted actually expand to). The most interesting thing is special member functions. For moves, I find it important that we describe the state of moved-from objects. Or we just document all move special members as "leaves the rhs object in a partially-formed state, in which the only valid operations on the object are assignment or destruction." I don't think we should document dtors by default, except when done manually (e.g. for RAII classes, or QFIle, where it's important to note that the dtor closes the file). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From edward.welbourne at theqtcompany.com Thu Feb 25 13:17:56 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 25 Feb 2016 12:17:56 +0000 Subject: [Development] Units in QML In-Reply-To: <56CED6F2.6060409@familiesomers.nl> References: <56CEB1C9.1020404@familiesomers.nl> , <56CED6F2.6060409@familiesomers.nl> Message-ID: > What's wrong with in that case defining the conversion? Or resetting > the default conversions and defining everything in "space-time"? By all means provide the means for the user to define context-specific conversion. I'm mostly arguing against trying to automagically do it all for them. Eddy. From fabrice.salvaire at orange.fr Thu Feb 25 13:33:00 2016 From: fabrice.salvaire at orange.fr (Fabrice Salvaire) Date: Thu, 25 Feb 2016 13:33:00 +0100 Subject: [Development] Though about rich text (html, WebView) rendering Message-ID: <56CEF47C.5090303@orange.fr> Dear all, I am investigating to port a content server to an off-line mobile application in order to don't rely to a network connection at all. Thus I have to port a database, a kind of web framework, a template engine and a rendering engine. I believe it can be a use of case of Qt on mobile platform. If we consider HTML is the right way to display rich text there is actually to solution with Qt : Text for basic HTML and WebView for a full compliance. I am not sure to understand why we cannot use WebEngine on mobile platform. WebEngine seems more interesting since it provides WebChannel hooks. I succeed to hack the WebView using the loadingChanged signal in order to simulate a dynamic HTML framework, i.e. call loadHtml according to the url. But I don't known if it is the right way to achieve this. Maybe we can extend the Java wrapper for this purpose? The fact the rendering surface is a light web browser behind the scene can be disturbing since it doesn't integrate very well with the QML application. I think there is something evil since a Web engine is a concurrent of QML. We can render math formulas out of the box using a QML WebView and mathjax, but we can also implement a full application using HTML5 and javascript. Thus use a stack over a stack ... What is the future plan and advices for this topic? Fabrice From andre at familiesomers.nl Thu Feb 25 13:37:54 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 25 Feb 2016 13:37:54 +0100 Subject: [Development] Units in QML In-Reply-To: <56CEEA2D.9020207@users.sourceforge.net> References: <56CEB1C9.1020404@familiesomers.nl> <56CEEA2D.9020207@users.sourceforge.net> Message-ID: <56CEF5A2.2040507@familiesomers.nl> Op 25/02/2016 om 12:49 schreef Alberto Mardegan: > On 25/02/2016 13:20, Welbourne Edward wrote: >> André Somers used m* for minutes and metres, footnoting: >>> )* Note the first clash already... >> I think it is fairly sane to just insist that SI units take precedence, >> especially given that we support multi-letter unit names (e.g. pt, px, >> mm, cm), so min will do fine for minutes. > I find this attention to physical units a bit improper. Sure, some > drawing applications or text editors should be enabled to draw UI > following specific physical dimensions (like, for example, for the ruler > bars), but I think it's more of an isolated case than the norm. > > Most UIs won't set a button's height to 1 cm (or any other physical > size), because while such a size might be OK for a desktop + mouse > system, it would be definitely be too small for a UI in running a > television set and too big for a UI running on a smartwatch. > The discussion here is units, not physical units per se. And not every application of QML is "drawing stuff on screen". For your application, pixels is just as useless a unit to start from. Perhaps you need units like Em or "strut" for the standard target size on your device or something like that. I'd like it if it were possible to define such units and use them in QML as a language feature. André From thiago.macieira at intel.com Thu Feb 25 17:15:39 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 Feb 2016 08:15:39 -0800 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: References: Message-ID: <2447389.PsW4KIE3lR@tjmaciei-mobl4> On quinta-feira, 25 de fevereiro de 2016 11:20:16 PST Cristian Adam wrote: > Since qdoc will be using libclang, any change of getting the same treatment > for moc? I don't think that's a good idea. We can't require people to install Perl in order to compile Qt. Requiring them to install and build llvm + clang (which implies now installing cmake too) is too much. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Feb 25 17:20:45 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 Feb 2016 08:20:45 -0800 Subject: [Development] Dropping VS 2012 in Qt 5.7 Message-ID: <8947616.A7UhMYDDIY@tjmaciei-mobl4> Just starting a new thread to get the attention of those that may have missed it in the other platform. The proposal is to drop VS 2012 support in Qt 5.7 already, instead of supporting it in 5.7 only and dropping in 5.8. The rationale is that we need VS2012 for WEC 2013 support, but there's no point in supporting that operating system in Qt 5.7. It suffices that it is supported in Qt 5.6, which is the long-term release. In other words, needing WEC 2013 customers are better served by staying in Qt 5.6 than upgrading to 5.7. Opinions? Objections? I'd like to see this answered BEFORE we release 5.6 so we can add this interesting tidbit to the changelog. The 5.5.0 changelog said: - Qt 5.7 will begin requiring certain C++11 features in order to compile. The minimum compiler versions for that release will be: * Clang 3.2 (included in XCode 5.0) * GCC 4.7 * Intel C++ Composer XE 2013 SP1 (compiler version 14.0) * Microsoft Visual Studio 2012 (compiler version 17.0) Since that went out, we've already risen our minimum Clang required version to 3.4. > > > In summary Qt does not gain anything from pushing WEC2013 to 5.8: > > > > > > - Potential Qt Customers are not stranded due to 5.6 > > > - WEC2013 in 5.8 doesn't really enable more projects > > > - MS says it is dead and licenses are hard to come by > > > - the currently visible project pipeline is rather dry on this > > > platform > > > > > > *But* our C++11 offering is yet longer chained. > > > > So why are we bothering with VS2012 for Qt 5.7 then? Why wait until 5.8? > > > > Let's drop it now. > > That is fine for me as well. As Alex wrote, most important is that Qt 5.6 > LTS supports both WEC7 and WEC13 and that latest for Qt 5.8 we no longer > have these to slow down adoption of C++11 and other planned changes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From cristian.adam at gmail.com Thu Feb 25 17:33:52 2016 From: cristian.adam at gmail.com (Cristian Adam) Date: Thu, 25 Feb 2016 17:33:52 +0100 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: <2447389.PsW4KIE3lR@tjmaciei-mobl4> References: <2447389.PsW4KIE3lR@tjmaciei-mobl4> Message-ID: On Thu, Feb 25, 2016 at 5:15 PM, Thiago Macieira wrote: > On quinta-feira, 25 de fevereiro de 2016 11:20:16 PST Cristian Adam wrote: > > Since qdoc will be using libclang, any change of getting the same > treatment > > for moc? > > I don't think that's a good idea. We can't require people to install Perl > in > order to compile Qt. Requiring them to install and build llvm + clang > (which > implies now installing cmake too) is too much. > > This might be a burden for some of the Qt developers (Windows ones). But all the Qt users get a modern / flexible moc, see this thread: https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c90e Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From charleyb123 at gmail.com Thu Feb 25 17:48:13 2016 From: charleyb123 at gmail.com (charleyb123 .) Date: Thu, 25 Feb 2016 08:48:13 -0800 Subject: [Development] Dropping VS 2012 in Qt 5.7 In-Reply-To: <8947616.A7UhMYDDIY@tjmaciei-mobl4> References: <8947616.A7UhMYDDIY@tjmaciei-mobl4> Message-ID: On Thu, Feb 25, 2016 at 8:20 AM, Thiago Macieira wrote: > Just starting a new thread to get the attention of those that may have > missed > it in the other platform. > > The proposal is to drop VS 2012 support in Qt 5.7 already, instead of > supporting it in 5.7 only and dropping in 5.8. > > The rationale is that we need VS2012 for WEC 2013 support, but there's no > point in supporting that operating system in Qt 5.7. It suffices that it is > supported in Qt 5.6, which is the long-term release. In other words, > needing > WEC 2013 customers are better served by staying in Qt 5.6 than upgrading to > 5.7. > > Opinions? Objections? > > I'd like to see this answered BEFORE we release 5.6 so we can add this > interesting tidbit to the changelog. The 5.5.0 changelog said: > > - Qt 5.7 will begin requiring certain C++11 features in order to > compile. The minimum compiler versions for that release will be: > * Clang 3.2 (included in XCode 5.0) > * GCC 4.7 > * Intel C++ Composer XE 2013 SP1 (compiler version 14.0) > * Microsoft Visual Studio 2012 (compiler version 17.0) > > Since that went out, we've already risen our minimum Clang required > version to > 3.4. > > > > > In summary Qt does not gain anything from pushing WEC2013 to 5.8: > > > > > > > > - Potential Qt Customers are not stranded due to 5.6 > > > > - WEC2013 in 5.8 doesn't really enable more projects > > > > - MS says it is dead and licenses are hard to come by > > > > - the currently visible project pipeline is rather dry on this > > > > platform > > > > > > > > *But* our C++11 offering is yet longer chained. > > > > > > So why are we bothering with VS2012 for Qt 5.7 then? Why wait until > 5.8? > > > > > > Let's drop it now. > > > > That is fine for me as well. As Alex wrote, most important is that Qt 5.6 > > LTS supports both WEC7 and WEC13 and that latest for Qt 5.8 we no longer > > have these to slow down adoption of C++11 and other planned changes. Works for me. Since Microsoft now has WEC2013 as deprecated legacy, makes sense for the long-term-support of Qt5.6 to be the last to support that platform. I don't see what it gains to keep MSVC2012 beyond Qt5.6. --charley -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Feb 25 18:02:11 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 25 Feb 2016 09:02:11 -0800 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: References: <2447389.PsW4KIE3lR@tjmaciei-mobl4> Message-ID: <1698764.6Goq3gLcPQ@tjmaciei-mobl4> On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote: > This might be a burden for some of the Qt developers (Windows ones). > > But all the Qt users get a modern / flexible moc, see this thread: > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c90e I don't think we need a more flexible moc. What do we want to do that we can't do with the current one? Don't say "template QObjects". That has other reasons for being a bad idea, currently. Is it Olivier's maintenance burden? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From olivier at woboq.com Thu Feb 25 18:36:16 2016 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 25 Feb 2016 18:36:16 +0100 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: <1698764.6Goq3gLcPQ@tjmaciei-mobl4> References: <1698764.6Goq3gLcPQ@tjmaciei-mobl4> Message-ID: <1687438.ejgbNIrEzN@finn> Am Donnerstag, 25. Februar 2016, 09:02:11 CET schrieb Thiago Macieira: > On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote: > > This might be a burden for some of the Qt developers (Windows ones). > > > > But all the Qt users get a modern / flexible moc, see this thread: > > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c90e > > I don't think we need a more flexible moc. What do we want to do that we > can't do with the current one? > > Don't say "template QObjects". That has other reasons for being a bad idea, > currently. > > Is it Olivier's maintenance burden? The parser need to be adapted if we want to support trailing type for signals/ slots/Q_INVOKABLE; or C++11 attributes; decltype as argument type for invokable; or fancy default arguments. There might be other things. As long as the QObject system does string comparison for return value, I think there is no way to support automatic return type deduction in invokables without a fully complient C++ parser. Maybe if we had a QMetaType system that did not care about strings that would work better. But we need to do some other way to query the argument types and return type than putting it in the QMetaObject's array, because qMetaTypeId() is not constexpr. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From pierrechicoine606 at gmail.com Thu Feb 25 19:02:05 2016 From: pierrechicoine606 at gmail.com (Pierre) Date: Thu, 25 Feb 2016 18:02:05 +0000 (UTC) Subject: [Development] Add widgets into qt3d window References: <2122416.x1DTXIxobc@cartman> Message-ID: Sean Harmer kdab.com> writes: > > On Monday 30 Mar 2015 17:38:37 Arjun Das wrote: > > Hi , > > > > I have created a simple qt3d application in c++, which has a rotating cube. > > I would like to add buttons to the windows to stop/start rotating the cube. > > I am not able to see such an example anywhere in the qt3d examples which > > has support for widgets. > > > > Could anyone please help me? > > QWidget::createWindowContainer() if you wish to embed the window in a widget > hierarchy. > > Alternatively, use a Scene3D element if you wish to use a Qt3D scene within a > Qt Quick 2 scene (i.e. to overlay Qt Quick 2 controls over the 3D scene). > > More integration points will come later. > > Cheers, > > Sean > It won't work Sean. In 5.6 QWidget::createWindowContainer() has been deprecated. Since many of us use c++ with Qt3d with widgets we seem to be out of luck here unless something changes. From milian.wolff at kdab.com Thu Feb 25 19:22:55 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Thu, 25 Feb 2016 19:22:55 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <1698764.6Goq3gLcPQ@tjmaciei-mobl4> References: <1698764.6Goq3gLcPQ@tjmaciei-mobl4> Message-ID: <6809745.CJ549IbFAA@agathebauer> On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote: > On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote: > > This might be a burden for some of the Qt developers (Windows ones). > > > > But all the Qt users get a modern / flexible moc, see this thread: > > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c90e > > I don't think we need a more flexible moc. What do we want to do that we > can't do with the current one? > > Don't say "template QObjects". That has other reasons for being a bad idea, > currently. Can you explain what those reasons are? I'd really love to write a generic QAbstractTableModel implementation that operates using concepts. Currently that would require type erasure and thus another set of virtual function calls... I.e. in many projects I end up writing the same boiler plate code to display a QVector in a view. As far as I can see most of that could be abstracted away easily, leaving only slim concepts to the struct: struct MyRowType { QString foo; int bar; QVariant data(int column, int role) const { if (!role == Qt::DisplayRole) return {} switch (column) { case 1: return foo; case 2: return bar; } return {}; } }; this could easily be extended to other methods, such as setData, headerData, etc. pp. In the end, one would only need to implement a trivial minimal API at the place where the data is actually stored. And no, I do _not_ consider the current QAIM interface trivial to implement, not even for "simple" lists! If we'd have templates QObjects, the above could easily be written. I bet there are other valid use-cases. Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From sean.harmer at kdab.com Thu Feb 25 20:01:21 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Thu, 25 Feb 2016 19:01:21 +0000 Subject: [Development] Add widgets into qt3d window In-Reply-To: References: <2122416.x1DTXIxobc@cartman> Message-ID: <56CF4F81.2000400@kdab.com> Hi, On 25/02/2016 18:02, Pierre wrote: > Sean Harmer kdab.com> writes: > >> On Monday 30 Mar 2015 17:38:37 Arjun Das wrote: >>> Hi , >>> >>> I have created a simple qt3d application in c++, which has a rotating > cube. >>> I would like to add buttons to the windows to stop/start rotating the > cube. >>> I am not able to see such an example anywhere in the qt3d examples > which >>> has support for widgets. >>> >>> Could anyone please help me? >> QWidget::createWindowContainer() if you wish to embed the window in a > widget >> hierarchy. >> >> Alternatively, use a Scene3D element if you wish to use a Qt3D scene > within a >> Qt Quick 2 scene (i.e. to overlay Qt Quick 2 controls over the 3D scene). >> >> More integration points will come later. >> >> Cheers, >> >> Sean >> > It won't work Sean. In 5.6 QWidget::createWindowContainer() has been > deprecated. Since many of us use c++ with Qt3d with widgets we seem to be > out of luck here unless something changes. That doesn't mean you can't use it. It will have to exist until at least the end of the Qt 5.x series for source compatibility. We do not yet have any widget/Qt3D integrations. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From steveire at gmail.com Thu Feb 25 21:37:23 2016 From: steveire at gmail.com (Stephen Kelly) Date: Thu, 25 Feb 2016 21:37:23 +0100 Subject: [Development] Though about rich text (html, WebView) rendering References: <56CEF47C.5090303@orange.fr> Message-ID: Fabrice Salvaire wrote: > Dear all, > > I am investigating to port a content server to an off-line mobile > application in order to don't rely to a network connection at all. Thus > I have to port a database, a kind of web framework, a template engine > and a rendering engine. I believe it can be a use of case of Qt on > mobile platform. Grantlee has an example which is exactly that, but it uses QtWebKit and QNetworkAccessManager: https://steveire.wordpress.com/2011/02/06/templating-html-applications-with-grantlee/ Unfortunately I used a video host which no longer exists. Perhaps there is similar request-interception API in the new WebView stuff which you could use. I haven't looked into the new web API yet. Thanks, Steve. From andy.shaw at theqtcompany.com Fri Feb 26 01:16:35 2016 From: andy.shaw at theqtcompany.com (Shaw Andy) Date: Fri, 26 Feb 2016 00:16:35 +0000 Subject: [Development] Auto-assignment in JIRA Message-ID: I was creating another bug report earlier today in JIRA and I noticed that it was assigning to someone who didn't seem to be right for the component at all since I don't believe they are the maintainer for it and I recalled that this is not the first time I've noticed that the auto-assigner is clearly incorrect and therefore it could end up in some sort of limbo. I know that anyone can pick up a bug report not actively being worked on so it doesn't have much meaning in that regard, but is there an actual benefit to having the auto-assigner set? Are the maintainers actively utilizing this or would it be best that all new bugs are unassigned by default and then someone picks them up when they are going to actively work on it? I don't have an agenda (aside from the auto-assignment being correct if this is the work flow we want) either way on this but I am curious as to whether it is useful or not. Therefore if it is useful then we can at least clean it up a bit so it is assigning correctly (either to the maintainer or to unassigned). Andy From jedrzej.nowacki at theqtcompany.com Fri Feb 26 08:40:57 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 26 Feb 2016 08:40:57 +0100 Subject: [Development] Auto-assignment in JIRA In-Reply-To: References: Message-ID: <5455226.MXbUcEzd6a@42> On Friday 26 of February 2016 00:16:35 Shaw Andy wrote: > I was creating another bug report earlier today in JIRA and I noticed that > it was assigning to someone who didn't seem to be right for the component > at all since I don't believe they are the maintainer for it and I recalled > that this is not the first time I've noticed that the auto-assigner is > clearly incorrect and therefore it could end up in some sort of limbo. > > I know that anyone can pick up a bug report not actively being worked on so > it doesn't have much meaning in that regard, but is there an actual benefit > to having the auto-assigner set? Are the maintainers actively utilizing > this or would it be best that all new bugs are unassigned by default and > then someone picks them up when they are going to actively work on it? > > I don't have an agenda (aside from the auto-assignment being correct if this > is the work flow we want) either way on this but I am curious as to whether > it is useful or not. Therefore if it is useful then we can at least clean > it up a bit so it is assigning correctly (either to the maintainer or to > unassigned). > > Andy Hi, This was discussed few times already. As far I remember we concluded that it is up to maintainer to decide how to handle incoming bugs. Some prefer auto assignment to see what is going in and some prefer to see a dashboard and reduce amount of noisy emails. Regarding invalid auto assignment, ping our JIRA admins, they will clean it up. Cheers, Jędrek From jedrzej.nowacki at theqtcompany.com Fri Feb 26 09:43:40 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 26 Feb 2016 09:43:40 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <6809745.CJ549IbFAA@agathebauer> References: <1698764.6Goq3gLcPQ@tjmaciei-mobl4> <6809745.CJ549IbFAA@agathebauer> Message-ID: <2392739.VTU6nKzX78@42> On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote: > On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote: > > On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote: > > > This might be a burden for some of the Qt developers (Windows ones). > > > > > > But all the Qt users get a modern / flexible moc, see this thread: > > > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c9 > > > 0e > > > > I don't think we need a more flexible moc. What do we want to do that we > > can't do with the current one? > > > > Don't say "template QObjects". That has other reasons for being a bad > > idea, > > currently. > > Can you explain what those reasons are? I'd really love to write a generic > QAbstractTableModel implementation that operates using concepts. Currently > that would require type erasure and thus another set of virtual function > calls... > > I.e. in many projects I end up writing the same boiler plate code to display > a QVector in a view. As far as I can see most of that could be > abstracted away easily, leaving only slim concepts to the struct: > > struct MyRowType { > QString foo; > int bar; > QVariant data(int column, int role) const > { > if (!role == Qt::DisplayRole) return {} > switch (column) { > case 1: return foo; > case 2: return bar; > } > return {}; > } > }; > > this could easily be extended to other methods, such as setData, headerData, > etc. pp. In the end, one would only need to implement a trivial minimal API > at the place where the data is actually stored. And no, I do _not_ consider > the current QAIM interface trivial to implement, not even for "simple" > lists! > > If we'd have templates QObjects, the above could easily be written. I bet > there are other valid use-cases. > > Cheers Hi, When first time I heard about templated QObject, QAIM was my first thought :-) The thought evolved over last months and now I think that QAIM should not be QObject at all, it is just an unnecessary cost. The main problems of templated QObject are captured more or less in this thread: http://lists.qt-project.org/pipermail/development/2013-March/010288.html Personally I still think it would be a fancy feature, a bit dangerous to implement maybe even dangerous to use, but really cool :-D Cheers, Jędrek From Kai.Koehne at theqtcompany.com Fri Feb 26 11:15:48 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Fri, 26 Feb 2016 10:15:48 +0000 Subject: [Development] Though about rich text (html, WebView) rendering In-Reply-To: <56CEF47C.5090303@orange.fr> References: <56CEF47C.5090303@orange.fr> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of > Fabrice Salvaire > Sent: Thursday, February 25, 2016 1:33 PM > To: development at qt-project.org > Subject: [Development] Though about rich text (html, WebView) rendering > > Dear all, > > I am investigating to port a content server to an off-line mobile application > in order to don't rely to a network connection at all. Thus I have to port a > database, a kind of web framework, a template engine and a rendering > engine. I believe it can be a use of case of Qt on mobile platform. > > If we consider HTML is the right way to display rich text there is actually to > solution with Qt : Text for basic HTML and WebView for a full compliance. I > am not sure to understand why we cannot use WebEngine on mobile > platform. WebEngine seems more interesting since it provides WebChannel > hooks. Let's be clear here on the terminology: With "WebView" I assume you refer to Qt WebView (http://doc.qt.io/qt-5/qtwebview-index.html), which on Android integrates the native browser. Since Qt WebChannel can use WebSockets as a means of communciation, you can use it with Qt WebView on Android, too. You'd need to set up a local websocket server though ("ws://localhost/..."). Not sure how exactly that works for an Android app. Qt WebEngine is indeed currently only supported for Windows, OS X and Linux. Porting it to Android is possible, but a lot of work. > I succeed to hack the WebView using the loadingChanged signal in order to > simulate a dynamic HTML framework, i.e. call loadHtml according to the url. > But I don't known if it is the right way to achieve this. Maybe we can extend > the Java wrapper for this purpose? The fact the rendering surface is a light > web browser behind the scene can be disturbing since it doesn't integrate > very well with the QML application. I'm not sure I really understood what you've been doing with the loadingChanged Signal. A tight integration into the scene graph is indeed an advantage of Qt WebEngine. > I think there is something evil since a Web engine is a concurrent of QML. What do you mean by that? > We can render math formulas out of the box using a QML WebView and > mathjax, but we can also implement a full application using HTML5 and > javascript. Thus use a stack over a stack ... > > What is the future plan and advices for this topic? I'm afraid there are no direct plans to support Qt WebEngine on Android. If I'd be you I'd try to set up a WebSocket. If that ain't possible you could Still try to communicate between the WebView and your app just via runJavaScript(). Regards Kai From fabrice.salvaire at orange.fr Fri Feb 26 11:54:20 2016 From: fabrice.salvaire at orange.fr (Fabrice Salvaire) Date: Fri, 26 Feb 2016 11:54:20 +0100 Subject: [Development] Though about rich text (html, WebView) rendering In-Reply-To: References: <56CEF47C.5090303@orange.fr> Message-ID: <56D02EDC.1090601@orange.fr> Hi Kai, Le 26/02/2016 11:15, Koehne Kai a écrit : > >> -----Original Message----- >> From: Development [mailto:development- >> bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of >> Fabrice Salvaire >> Sent: Thursday, February 25, 2016 1:33 PM >> To: development at qt-project.org >> Subject: [Development] Though about rich text (html, WebView) rendering >> >> Dear all, >> >> I am investigating to port a content server to an off-line mobile application >> in order to don't rely to a network connection at all. Thus I have to port a >> database, a kind of web framework, a template engine and a rendering >> engine. I believe it can be a use of case of Qt on mobile platform. >> >> If we consider HTML is the right way to display rich text there is actually to >> solution with Qt : Text for basic HTML and WebView for a full compliance. I >> am not sure to understand why we cannot use WebEngine on mobile >> platform. WebEngine seems more interesting since it provides WebChannel >> hooks. > Let's be clear here on the terminology: With "WebView" I assume you refer > to Qt WebView (http://doc.qt.io/qt-5/qtwebview-index.html), which on Android > integrates the native browser. Since Qt WebChannel can use WebSockets as > a means of communciation, you can use it with Qt WebView on Android, too. > You'd need to set up a local websocket server though ("ws://localhost/..."). > Not sure how exactly that works for an Android app. Ok, I could investigate this. > > Qt WebEngine is indeed currently only supported for Windows, OS X and > Linux. Porting it to Android is possible, but a lot of work. Thus android and ios don't forbid it. >> I succeed to hack the WebView using the loadingChanged signal in order to >> simulate a dynamic HTML framework, i.e. call loadHtml according to the url. >> But I don't known if it is the right way to achieve this. Maybe we can extend >> the Java wrapper for this purpose? The fact the rendering surface is a light >> web browser behind the scene can be disturbing since it doesn't integrate >> very well with the QML application. > I'm not sure I really understood what you've been doing with the loadingChanged > Signal. What I did basically to catch page loading and set the content according to the url ( WebView get page -> LoadingChanged signal -> call loadHtml -> ... ) : function handle_loading(load_request) { if (load_request.url == "qrc:/index.html" && load_request.status == 0) { var html_content = "

Main Page

A link

"; } if (load_request.url == "qrc:/page1" && load_request.status == 0) { var html_content = "

Basic HTML

"; } var base_url = "qrc:/"; web_view.loadHtml(html_content, base_url) } WebView { id: web_view objectName: "web_view" anchors.fill: parent url: "qrc:/index.html" onLoadingChanged: handle_loading(loadRequest) } >> I think there is something evil since a Web engine is a concurrent of QML. > What do you mean by that? I am just thinking how to implement the power of HTML for text rendering in QML cleverly. And don't use any web framework for mobile platform. Mathjax is a good example. How can we implement a computer algebra system //using Qt for example ? > >> We can render math formulas out of the box using a QML WebView and >> mathjax, but we can also implement a full application using HTML5 and >> javascript. Thus use a stack over a stack ... >> >> What is the future plan and advices for this topic? > I'm afraid there are no direct plans to support Qt WebEngine on Android. > If I'd be you I'd try to set up a WebSocket. If that ain't possible you could > Still try to communicate between the WebView and your app > just via runJavaScript(). > > Regards > > Kai Fabrice -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at theqtcompany.com Fri Feb 26 13:34:45 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Fri, 26 Feb 2016 12:34:45 +0000 Subject: [Development] change log creation tool (was: Re: Qt 5.6.0 missing change files) In-Reply-To: References: Message-ID: Hi, To simplify the creation of the change files I have written a small tool that facilitates this job. It's written in golang and you get install it by simply running go get code.qt.io/qt/qtqa.git/src/createchangelog The binary will be placed in $GOPATH/bin. (If you are not familiar with go, then you can also "cheat" and just set GOPATH=$PWD just to get this tool) Afterwards you can go into the git directory of the module you'd like to create the change log, make sure you have the correct branch checked out and simply run the program. It will read .qmake.conf to figure out the version of the upcoming Qt release and it will use the output of "git tag -l" to determine the previous release the change log should be made against. Afterwards it will go through the changes between those the previous release and HEAD and print "preliminary" ChangeLog file to standard output. You can redirect the output and then do the usual manual editing. Simon ________________________________ From: Releasing on behalf of Heikkinen Jani Sent: Friday, February 19, 2016 11:42 To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Releasing] Qt 5.6.0 missing change files Hi all, We are planning to release Qt 5.6.0 RC really soon, hoping at the beginning of next week. Final is targeted to be released within 2 weeks as well so we need to get all change files done & in before it. Following change files are still missing: qtandroidextras qtbase (ongoing, see https://codereview.qt-project.org/#/c/149325/ ) [https://codereview.qt-project.org/static/logo_qt.png] Qt - Gerrit Code Review codereview.qt-project.org Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet Qt; Qt Repository Browser qtdeclarative qtdoc (qtenginio) qtmacextras qtmultimedia qtquickcontrols (qtscript) qtsensors qtsvg qttranslations qttools qtwayland qtwaylandqtwebchannel qtwebsockets qtx11extras qtxmlpatterns Maintainers, make sure needed change files are done & in before wed 24th Feb br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From ravikumarverma686 at gmail.com Fri Feb 26 14:52:07 2016 From: ravikumarverma686 at gmail.com (ravi kumar verma) Date: Fri, 26 Feb 2016 19:22:07 +0530 Subject: [Development] platform neutrality in Qt Message-ID: Hi, Can anyone please elaborate how Qt framework achieves platform netrality? I mean what feature in it makes it platform neutral. regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Fri Feb 26 15:09:39 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 26 Feb 2016 15:09:39 +0100 Subject: [Development] platform neutrality in Qt In-Reply-To: References: Message-ID: <56D05CA3.5050903@familiesomers.nl> QPA (lighthouse) is a major factor in that. Other than that: lots of hard work. André Op 26/02/2016 om 14:52 schreef ravi kumar verma: > Hi, > Can anyone please elaborate how Qt framework achieves platform netrality? > > I mean what feature in it makes it platform neutral. > > > regards > > > _______________________________________________ > 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 ravikumarverma686 at gmail.com Fri Feb 26 15:30:40 2016 From: ravikumarverma686 at gmail.com (ravi kumar verma) Date: Fri, 26 Feb 2016 20:00:40 +0530 Subject: [Development] Qthread & porting the qt code to another platform Message-ID: Hi, are qt a wrapper over (posix thread in unix) and (win32 threads on windows)? Moreover , How do we port a Qt code from one platform to another ? for eg . from windows to linux . regards Ravi Kumar Verma -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Fri Feb 26 15:39:22 2016 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 26 Feb 2016 15:39:22 +0100 Subject: [Development] Qthread & porting the qt code to another platform In-Reply-To: References: Message-ID: <2548774.OmQIkKlxhM@finn> Am Freitag, 26. Februar 2016, 20:00:40 CET schrieb ravi kumar verma: > Hi, > are qt a wrapper over (posix thread in unix) and (win32 threads on windows)? Yes. > Moreover , How do we port a Qt code from one platform to another ? > for eg . from windows to linux . You can take qthread_unix.cpp or qthread_win.cpp and make a new qthread_xxx.cpp that wraps the thread on your platform. For example, if your platform supports C++11 thread, you could make qthread_cxx11.cpp which wraps std::thread. And long term we could use it on every platform, just like we did for qatomic. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From ravikumarverma686 at gmail.com Fri Feb 26 15:41:19 2016 From: ravikumarverma686 at gmail.com (ravi kumar verma) Date: Fri, 26 Feb 2016 20:11:19 +0530 Subject: [Development] porting Message-ID: hi, How do we port a Qt code from one platform to another ? for eg . from windows to linux . regards Ravi Kumar Verma -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Fri Feb 26 15:44:06 2016 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 26 Feb 2016 15:44:06 +0100 Subject: [Development] Qthread & porting the qt code to another platform In-Reply-To: <2548774.OmQIkKlxhM@finn> References: <2548774.OmQIkKlxhM@finn> Message-ID: <1518144.ug0XfOXbIZ@finn> Am Freitag, 26. Februar 2016, 15:39:22 CET schrieb Olivier Goffart: > Am Freitag, 26. Februar 2016, 20:00:40 CET schrieb ravi kumar verma: > > Hi, > > are qt a wrapper over (posix thread in unix) and (win32 threads on > > windows)? > Yes. > > > Moreover , How do we port a Qt code from one platform to another ? > > for eg . from windows to linux . > > You can take qthread_unix.cpp or qthread_win.cpp and make a new > qthread_xxx.cpp that wraps the thread on your platform. > > For example, if your platform supports C++11 thread, you could make > qthread_cxx11.cpp which wraps std::thread. And long term we could use it on > every platform, just like we did for qatomic. Sorry, I think I might have misunderstood your question. I thought you asked how to port QThread code to a new platform. If you asked how to port a Qt application from Windows to Linux, then you just try to compile it and fix the compilation problems and error as they come. then you test it and fix the remaining bugs. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From Kai.Koehne at theqtcompany.com Fri Feb 26 16:03:59 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Fri, 26 Feb 2016 15:03:59 +0000 Subject: [Development] porting In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of ravi > kumar verma > Sent: Friday, February 26, 2016 3:41 PM > To: development at qt-project.org > Subject: [Development] porting > > > > hi, > How do we port a Qt code from one platform to another ? > for eg . from windows to linux . No offense, but this is the mailing list for developing Qt itself. It seems you should rather target your questions to interest at qt-project.org, which is about how to write apps with Qt. Regards Kai From mitch.curtis at theqtcompany.com Fri Feb 26 16:16:04 2016 From: mitch.curtis at theqtcompany.com (Curtis Mitch) Date: Fri, 26 Feb 2016 15:16:04 +0000 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <2392739.VTU6nKzX78@42> References: <1698764.6Goq3gLcPQ@tjmaciei-mobl4> <6809745.CJ549IbFAA@agathebauer> <2392739.VTU6nKzX78@42> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+mitch.curtis=theqtcompany.com at qt-project.org] On Behalf Of Jedrzej > Nowacki > Sent: Friday, 26 February 2016 9:44 AM > To: development at qt-project.org > Cc: Thiago Macieira ; Milian Wolff > > Subject: Re: [Development] templated QObjects [was: Re: We are planning to > upgrade qdoc to use clang for parsing C++] > > On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote: > > On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote: > > > On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam > wrote: > > > > This might be a burden for some of the Qt developers (Windows ones). > > > > > > > > But all the Qt users get a modern / flexible moc, see this thread: > > > > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked > > > > /d09c9 > > > > 0e > > > > > > I don't think we need a more flexible moc. What do we want to do > > > that we can't do with the current one? > > > > > > Don't say "template QObjects". That has other reasons for being a > > > bad idea, currently. > > > > Can you explain what those reasons are? I'd really love to write a > > generic QAbstractTableModel implementation that operates using > > concepts. Currently that would require type erasure and thus another > > set of virtual function calls... > > > > I.e. in many projects I end up writing the same boiler plate code to > > display a QVector in a view. As far as I can see most of > > that could be abstracted away easily, leaving only slim concepts to the > struct: > > > > struct MyRowType { > > QString foo; > > int bar; > > QVariant data(int column, int role) const { > > if (!role == Qt::DisplayRole) return {} > > switch (column) { > > case 1: return foo; > > case 2: return bar; > > } > > return {}; > > } > > }; > > > > this could easily be extended to other methods, such as setData, > > headerData, etc. pp. In the end, one would only need to implement a > > trivial minimal API at the place where the data is actually stored. > > And no, I do _not_ consider the current QAIM interface trivial to > implement, not even for "simple" > > lists! > > > > If we'd have templates QObjects, the above could easily be written. I > > bet there are other valid use-cases. > > > > Cheers > > Hi, > > When first time I heard about templated QObject, QAIM was my first > thought :-) The thought evolved over last months and now I think that QAIM > should not be QObject at all, it is just an unnecessary cost. What about using C++ models in QML? QAbstractItemModel has to be a QObject for that reason alone. Often you also want to control the contents of the model by some UI-driven property in QML (e.g. a filter for a list of contacts based on a text input field). > The main problems of templated QObject are captured more or less in this > thread: http://lists.qt-project.org/pipermail/development/2013- > March/010288.html > > Personally I still think it would be a fancy feature, a bit dangerous to > implement maybe even dangerous to use, but really cool :-D > > Cheers, > Jędrek > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Fri Feb 26 18:47:44 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 26 Feb 2016 18:47:44 +0100 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> Message-ID: <201602261847.44912.marc.mutz@kdab.com> On Friday 19 February 2016 22:01:02 Knoll Lars wrote: > * We continue to support QNX 6.6 Does someone here know (Rafael) when we can expect a QNX that supports C++11 at the library level? People want to use std::unique_ptr and currently we need to stop them from doing so, in platform-independent code... I guess the Clang-on-OSX-with-old-libstdc++ platform is obsolete, these days? Do we have other platforms where the std library doesn't match what the compiler supports of C++11? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Fri Feb 26 17:59:22 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Feb 2016 08:59:22 -0800 Subject: [Development] change log creation tool (was: Re: Qt 5.6.0 missing change files) In-Reply-To: References: Message-ID: <2097108.jEs4uOeqCI@tjmaciei-mobl4> How is this different from the tool that already exists? On sexta-feira, 26 de fevereiro de 2016 12:34:45 PST Hausmann Simon wrote: > Hi, > > > To simplify the creation of the change files I have written a small tool > that facilitates this job. It's written in golang and you get install it by > simply running > > > go get code.qt.io/qt/qtqa.git/src/createchangelog > > > The binary will be placed in $GOPATH/bin. (If you are not familiar with go, > then you can also "cheat" and just set GOPATH=$PWD just to get this tool) > > Afterwards you can go into the git directory of the module you'd like to > create the change log, make sure you have the correct branch checked out > and simply run the program. It will read .qmake.conf to figure out the > version of the upcoming Qt release and it will use the output of "git tag > -l" to determine the previous release the change log should be made > against. Afterwards it will go through the changes between those the > previous release and HEAD and print "preliminary" ChangeLog file to > standard output. You can redirect the output and then do the usual manual > editing. > > > Simon > > ________________________________ > From: Releasing > on > behalf of Heikkinen Jani Sent: Friday, > February 19, 2016 11:42 > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: [Releasing] Qt 5.6.0 missing change files > > > Hi all, > > > We are planning to release Qt 5.6.0 RC really soon, hoping at the beginning > of next week. Final is targeted to be released within 2 weeks as well so we > need to get all change files done & in before it. Following change files > are still missing: > > > qtandroidextras > > qtbase (ongoing, see https://codereview.qt-project.org/#/c/149325/ ) > > [https://codereview.qt-project.org/static/logo_qt.png] -project.org/#/c/149325/> > > Qt - Gerrit Code Review > codereview.qt-project.org > Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; > Planet Qt; Qt Repository Browser > > > > qtdeclarative > > qtdoc > > (qtenginio) > > qtmacextras > > qtmultimedia > > qtquickcontrols > > (qtscript) > > qtsensors > > qtsvg > > qttranslations > > qttools > > qtwayland > > qtwaylandqtwebchannel > > qtwebsockets > > qtx11extras > > qtxmlpatterns > > > Maintainers, make sure needed change files are done & in before wed 24th Feb > > > br, > > Jani -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Feb 26 18:02:27 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Feb 2016 09:02:27 -0800 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: <1687438.ejgbNIrEzN@finn> References: <1698764.6Goq3gLcPQ@tjmaciei-mobl4> <1687438.ejgbNIrEzN@finn> Message-ID: <3193642.KirRKZEmJY@tjmaciei-mobl4> On quinta-feira, 25 de fevereiro de 2016 18:36:16 PST Olivier Goffart wrote: > The parser need to be adapted if we want to support trailing type for > signals/ slots/Q_INVOKABLE; or C++11 attributes; decltype as argument type > for invokable; or fancy default arguments. There might be other things. Is there value in doing that for non-template classes and members? It's probably the same discussion as the almost-always-auto we had before, but since we're talking about the public interface of something, I'd expect people to write their types more often than just relying on the compiler to guess it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at theqtcompany.com Fri Feb 26 20:06:06 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Fri, 26 Feb 2016 19:06:06 +0000 Subject: [Development] change log creation tool (was: Re: Qt 5.6.0 missing change files) In-Reply-To: <2097108.jEs4uOeqCI@tjmaciei-mobl4> References: , <2097108.jEs4uOeqCI@tjmaciei-mobl4> Message-ID: <20160226190606.5922897.15581.61452@theqtcompany.com> Hi, It is different in three aspects: 1. It does not require passing git revision ranges as command line parameters. 2. It works on a per module basis instead of from the qt5 supermodule. 3. It includes the task number from the commit message. Simon Original Message From: Thiago Macieira Sent: Friday, February 26, 2016 17:59 To: development at qt-project.org Subject: Re: [Development] change log creation tool (was: Re: Qt 5.6.0 missing change files) How is this different from the tool that already exists? On sexta-feira, 26 de fevereiro de 2016 12:34:45 PST Hausmann Simon wrote: > Hi, > > > To simplify the creation of the change files I have written a small tool > that facilitates this job. It's written in golang and you get install it by > simply running > > > go get code.qt.io/qt/qtqa.git/src/createchangelog > > > The binary will be placed in $GOPATH/bin. (If you are not familiar with go, > then you can also "cheat" and just set GOPATH=$PWD just to get this tool) > > Afterwards you can go into the git directory of the module you'd like to > create the change log, make sure you have the correct branch checked out > and simply run the program. It will read .qmake.conf to figure out the > version of the upcoming Qt release and it will use the output of "git tag > -l" to determine the previous release the change log should be made > against. Afterwards it will go through the changes between those the > previous release and HEAD and print "preliminary" ChangeLog file to > standard output. You can redirect the output and then do the usual manual > editing. > > > Simon > > ________________________________ > From: Releasing > on > behalf of Heikkinen Jani Sent: Friday, > February 19, 2016 11:42 > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: [Releasing] Qt 5.6.0 missing change files > > > Hi all, > > > We are planning to release Qt 5.6.0 RC really soon, hoping at the beginning > of next week. Final is targeted to be released within 2 weeks as well so we > need to get all change files done & in before it. Following change files > are still missing: > > > qtandroidextras > > qtbase (ongoing, see https://codereview.qt-project.org/#/c/149325/ ) > > [https://codereview.qt-project.org/static/logo_qt.png] -project.org/#/c/149325/> > > Qt - Gerrit Code Review > codereview.qt-project.org > Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; > Planet Qt; Qt Repository Browser > > > > qtdeclarative > > qtdoc > > (qtenginio) > > qtmacextras > > qtmultimedia > > qtquickcontrols > > (qtscript) > > qtsensors > > qtsvg > > qttranslations > > qttools > > qtwayland > > qtwaylandqtwebchannel > > qtwebsockets > > qtx11extras > > qtxmlpatterns > > > Maintainers, make sure needed change files are done & in before wed 24th Feb > > > br, > > Jani -- 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 jpnurmi at theqtcompany.com Fri Feb 26 20:07:53 2016 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Fri, 26 Feb 2016 19:07:53 +0000 Subject: [Development] 5.7 feature freeze In-Reply-To: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> Message-ID: <59A5F98F-EC4D-4F0B-89DB-628794ACC895@theqtcompany.com> Hi Lars, > On 27. jan. 2016, at 09.30, Knoll Lars wrote: > > If anybody else has a feature he believes absolutely has to make it to 5.7, get it done until Monday or talk to me :) I would like to ask for an exception for text selection handles. It's a crucial feature to make the new editor controls usable on mobile and embedded. There's a task for qtquickcontrols2 (https://bugreports.qt.io/browse/QTBUG-51010), but the groundwork needs to be done in qtbase and qtdeclarative. I'm aware of the following WIP patches: - qtbase: Add support for ImhAnchorRectangle: https://codereview.qt-project.org/#/c/142132/ - qtbase: Android selection handles: https://codereview.qt-project.org/#/c/142466/ - qtdeclarative: WIP: Add support for input method selection handles: https://codereview.qt-project.org/#/c/142133/ I would imagine that we may need some new API in such areas as QInputMethod, Qt::InputMethodHint, and QStyleHints. Would it be acceptable to finish off this work in the 5.7 branch? -- J-P Nurmi From alexander.blasche at theqtcompany.com Fri Feb 26 20:15:37 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Fri, 26 Feb 2016 19:15:37 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <201602261847.44912.marc.mutz@kdab.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <201602261847.44912.marc.mutz@kdab.com> Message-ID: > -----Original Message----- > From Marc Mutz > On Friday 19 February 2016 22:01:02 Knoll Lars wrote: > > * We continue to support QNX 6.6 > > Does someone here know (Rafael) when we can expect a QNX that supports > C++11 > at the library level? During Embedded World, a person at the QNX booth told me that QNX 7.0 is what will fix this gap. Please don't nail me down on the timeline but I believe it was 2H 2017 (2017 for sure). -- Alex From milian.wolff at kdab.com Fri Feb 26 20:30:28 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Fri, 26 Feb 2016 20:30:28 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <2392739.VTU6nKzX78@42> References: <6809745.CJ549IbFAA@agathebauer> <2392739.VTU6nKzX78@42> Message-ID: <1566797.NsfuvUYKtX@agathebauer> On Freitag, 26. Februar 2016 09:43:40 CET Jędrzej Nowacki wrote: > On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote: > > On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote: > > > On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote: > > > > This might be a burden for some of the Qt developers (Windows ones). > > > > > > > > But all the Qt users get a modern / flexible moc, see this thread: > > > > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09 > > > > c9 > > > > 0e > > > > > > I don't think we need a more flexible moc. What do we want to do that we > > > can't do with the current one? > > > > > > Don't say "template QObjects". That has other reasons for being a bad > > > idea, > > > currently. > > > > Can you explain what those reasons are? I'd really love to write a generic > > QAbstractTableModel implementation that operates using concepts. Currently > > that would require type erasure and thus another set of virtual function > > calls... > > > > I.e. in many projects I end up writing the same boiler plate code to > > display a QVector in a view. As far as I can see most of that > > could be abstracted away easily, leaving only slim concepts to the > > struct: > > > > struct MyRowType { > > QString foo; > > int bar; > > QVariant data(int column, int role) const > > { > > > > if (!role == Qt::DisplayRole) return {} > > switch (column) { > > > > case 1: return foo; > > case 2: return bar; > > > > } > > return {}; > > > > } > > }; > > > > this could easily be extended to other methods, such as setData, > > headerData, etc. pp. In the end, one would only need to implement a > > trivial minimal API at the place where the data is actually stored. And > > no, I do _not_ consider the current QAIM interface trivial to implement, > > not even for "simple" lists! > > > > If we'd have templates QObjects, the above could easily be written. I bet > > there are other valid use-cases. > > > > Cheers > > Hi, > > When first time I heard about templated QObject, QAIM was my first thought > :-) The thought evolved over last months and now I think that QAIM should > not be QObject at all, it is just an unnecessary cost. Can you explain how you imagine the code to look like for the model to notify the view about changes? Curtis' note on QML requiring introspection for models is also very valid. > The main problems of templated QObject are captured more or less in this > thread: > http://lists.qt-project.org/pipermail/development/2013-March/010288.html > > Personally I still think it would be a fancy feature, a bit dangerous to > implement maybe even dangerous to use, but really cool :-D Thanks for the link. How often is the MOC layout changed in an ABI incompatible way? I.e. what problems would we get from having to install the moc files? Alternatively: couldn't moc re-create the required data from included files when they contain templated objects? That would solve the problem as well, no? Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From marc.mutz at kdab.com Fri Feb 26 22:37:31 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 26 Feb 2016 22:37:31 +0100 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <201602261847.44912.marc.mutz@kdab.com> Message-ID: <201602262237.32159.marc.mutz@kdab.com> On Friday 26 February 2016 20:15:37 Blasche Alexander wrote: > > -----Original Message----- > > From Marc Mutz > > > > On Friday 19 February 2016 22:01:02 Knoll Lars wrote: > > > * We continue to support QNX 6.6 > > > > Does someone here know (Rafael) when we can expect a QNX that supports > > C++11 > > at the library level? > > During Embedded World, a person at the QNX booth told me that QNX 7.0 is > what will fix this gap. Please don't nail me down on the timeline but I > believe it was 2H 2017 (2017 for sure). I don't know whether to LOL or cry... -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From jmcdonnell at qnx.com Fri Feb 26 21:30:30 2016 From: jmcdonnell at qnx.com (James McDonnell) Date: Fri, 26 Feb 2016 20:30:30 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <201602261847.44912.marc.mutz@kdab.com> Message-ID: unique_ptr is probably useable. The library is only a problem when you need something that involves constexpr. constexpr support has been disabled in the library because some constexpr code uses C floating point functions that weren¹t changed to allow their use in constexpr C++ functions. Disabling constexpr can cause problems with other C++11 functionality as we discovered with std::atomic. Initialization order of static atomics was incorrect because constructors in the atomics classes weren't constexpr. A constexpr related problem with unique_ptr seems...unlikely. QNX 7.0 is currently early 2017. (2H is incorrect if 2H == second half) ----- Original Message ----- On 2016-02-26, 2:15 PM, "Development on behalf of Blasche Alexander" wrote: > >> -----Original Message----- >> From Marc Mutz >> On Friday 19 February 2016 22:01:02 Knoll Lars wrote: >> > * We continue to support QNX 6.6 >> >> Does someone here know (Rafael) when we can expect a QNX that supports >> C++11 >> at the library level? > >During Embedded World, a person at the QNX booth told me that QNX 7.0 is >what will fix this gap. Please don't nail me down on the timeline but I >believe it was 2H 2017 (2017 for sure). > >-- >Alex >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Sat Feb 27 00:56:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Feb 2016 15:56:08 -0800 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <1566797.NsfuvUYKtX@agathebauer> References: <2392739.VTU6nKzX78@42> <1566797.NsfuvUYKtX@agathebauer> Message-ID: <2146618.dGbZ6ML4ne@tjmaciei-mobl4> On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote: > > The main problems of templated QObject are captured more or less in this > > > > thread: > > http://lists.qt-project.org/pipermail/development/2013-March/010288.html > > > > Personally I still think it would be a fancy feature, a bit dangerous to > > > > implement maybe even dangerous to use, but really cool :-D > > Thanks for the link. How often is the MOC layout changed in an ABI > incompatible way? There's no historical pattern. There was a major break from Qt 3 to 4 and smaller one from 4 to 5. Qt 4 did have updates that didn't break the ABI; the Qt 5.0 update removed the ability to read meta objects created with Qt 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still used register-on-load meta objects). But since the meta object itself has a version number and the only code that ever reads the internal data is inside QtCore, so we could make changes that change the layout. We haven't done that: all changes between major releases have added things without changing the layout. That's the structure layout though. The file itself compares the Q_MOC_OUTPUT_REVISION macro for equality (not ordering). > I.e. what problems would we get from having to install the > moc files? Lots. First of all, note that you're asking that a) installing generated code b) including such generated code from your public headers That means the headers do not compile until moc has generated its output. Moc is currently able to ignore missing includes and we need that when parsing .cpp files that contain Q_OBJECT. But doing that in headers is just... ick. There's also the fact that now the generated code becomes part of your public ABI and will be compiled by your users. That means the code from moc needs to compile with their compiler settings, whichever that may be. And we would need to be very careful in how we change moc, because we need to keep users' compatibility requirements when they upgrade Qt. Their requirements could be stricter than Qt's (to a point). If we talk simply about non-templated QObjects, there are only drawbacks. The first is that the current output produces functions and data which would end up in *each* and *every* translation unit that included the output. You'd get linker errors. We could fix this by marking all the functions as inline, but we can't fix the data. This includes the most important data member of all: const QMetaObject * ClassName::staticMetaObject. It's a class-level static, so it needs to be defined in a single .cpp and nowhere else. Period, no fix possible. So the discussion ends here for non-template classes, at least without breaking Qt API. If we were willing to break Qt API, we could remove the staticMetaObject class member and make it static inside a member static inline function. Static data inside inline functions need to be merged by the linker and the dynamic linker. This however produces data bloat and reduces performance. For one thing, instead of getting the address of the meta object directly, you need to call a function that will return the address. For another, since we created work for the dynamic linker, now it needs to resolve a named relocation in places it didn't before. And there's still the fact that the meta object is present in every shared object / DLL that it got used from, even if at runtime only one copy is ever used. And then there are the problems of dynamic linkers actually merging static data inside inline functions at runtime. This is an area where several ABIs fall short and that's assuming that they even try. I have one word for you here: dynamic_cast. And then there are templates. If we talk about template classes, then we have more problems. First, note the bloating and runtime-deduplication problem I mentioned above. They'd apply here. Though note that you can declare static data of template classes in headers, so we wouldn't need to break the Qt API just for this. The next problem is the meta object layout. Currently, it's optimised to contain static strings (an array of QByteArrayLiteral data in Qt 5, one long const char array in Qt 4, which I'll bring back for Qt 6). Obviously, the name of the instantiated class isn't constant, so the data can't be constant either. It stands to reason that the use of a templated class in the first place is the ability to use the template parameters in reflected members (signals, slots, invocables, properties, enums, classinfo), so the types and signatures for those members would need to change. Then we go back to whether we can keep the current Qt API: if the data isn't constant, can we even return const char* from the QMetaObject member functions like we do? If we're going to calculate the strings at runtime, are we even able to? What happens for: signal: void somethingHappened( typename std::enable_if, typename std::remove_cv::type>::type); How can QMetaObject understand what that type will be? Or we just say "the hell with it" and keep the template names in the class name and reflected members. Of course, you can't connect that signal above to SLOT(doSomething(int)) even if T was int. (no such problem with the new connect style) The above also points to another problem: signals need to be reflected, so you can't use std::enable_if like I did. Then we need to look into template members (whether in a template class or not). They simply can't be extracted for reflection. So a template slot would never be usable in the SLOT() macro and template invocables would never be callable from dynamic bindings (QML, QtDBus, QtScript). And there couldn't be any template signals without a major overhauling of the way that signals are identified. See my blog "the future of moc" from 2012 for more information on the signal identification problem. To work around that, we'd need an explicit list of which template members we'd like to be extracted for reflection in the meta object. Have I convinced you? I'm only getting warmed up. I'm sure I can find more issues. > Alternatively: couldn't moc re-create the required data from included files > when they contain templated objects? That would solve the problem as well, > no? I have no idea what you meant here. Or, well, I do have one, but I don't think that I understood correctly what you're suggesting. I understood that we keep a copy of the header file's source in the target application and run moc at runtime to dynamically create the meta object, on the fly. Since I don't think that's what you're suggesting and since the above has so many problems (starting with the fact that it doesn't resolve the problem), I'm not even going to analyse it. Can you clarify what you meant? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Feb 27 00:58:28 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Feb 2016 15:58:28 -0800 Subject: [Development] change log creation tool (was: Re: Qt 5.6.0 missing change files) In-Reply-To: <20160226190606.5922897.15581.61452@theqtcompany.com> References: <2097108.jEs4uOeqCI@tjmaciei-mobl4> <20160226190606.5922897.15581.61452@theqtcompany.com> Message-ID: <85799145.xNj1AxyheL@tjmaciei-mobl4> On sexta-feira, 26 de fevereiro de 2016 19:06:06 PST Hausmann Simon wrote: > Hi, > > It is different in three aspects: > > 1. It does not require passing git revision ranges as command line > parameters. So you have a heuristic algorithm that tries to guess the target version and which version was the last. You could have added this to the Perl script. > 2. It works on a per module basis instead of from the qt5 supermodule. So does the Perl script. > 3. It includes the task number from the commit message. So does the Perl script. So we gained the ability to run without being explicit which revisions we want, but now we need to install a compiler we didn't use before and compile code? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Sat Feb 27 09:48:36 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 27 Feb 2016 09:48:36 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <2146618.dGbZ6ML4ne@tjmaciei-mobl4> References: <1566797.NsfuvUYKtX@agathebauer> <2146618.dGbZ6ML4ne@tjmaciei-mobl4> Message-ID: <201602270948.37249.marc.mutz@kdab.com> On Saturday 27 February 2016 00:56:08 Thiago Macieira wrote: > Have I convinced you? I'm only getting warmed up. I'm sure I can find more > issues. That's all correct. But can't we create a subset of features that the QObject template may use in order to make that subset work? After all, function templates as slots don't work in classical QObject, either, so we don't lose anything by banning them in QObject templates, either. As for the staticMetaObject, moc could write its output not as C++ code, but as a macro containing the C++ code, for QObject templates, to be called with those QObject template instantiations that the user creates (similar to the old method of template instantiation where the user needs to list the explicit template instantiation in a separately-compiled TU). Only one TU would contain the macro call for any given instantiation, solving the multiple-definition problem you mentioned. template class ListModel : QAbstractListModel { Q_OBJECT_TEMPLATE(T) public: // ... }; // in some other TU #include "listmodel.moc" Q_MOC_INSTANTIATE(ListModel, MyStruct) // resolves to something like // Q_MOC_INSTANTIATE_ListModel(MyStruct, #MyStruct) void Foo::Bar() { auto *model = new ListModel(this); // use 'model' } ... other code ... Partly, this can already be emulated by just not including the Q_OBJECT macro in the QObject template and then deriving non-template QObjects from it that do contain the Q_OBJECT macro, hiding the actual subclass from moc with Q_MOC_RUN. This would just move the boilerplate code into moc's hands, where it belongs. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Sat Feb 27 09:19:17 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 27 Feb 2016 00:19:17 -0800 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <201602270948.37249.marc.mutz@kdab.com> References: <2146618.dGbZ6ML4ne@tjmaciei-mobl4> <201602270948.37249.marc.mutz@kdab.com> Message-ID: <2783662.FOiuqL8JND@tjmaciei-mobl4> On sábado, 27 de fevereiro de 2016 09:48:36 PST Marc Mutz wrote: > On Saturday 27 February 2016 00:56:08 Thiago Macieira wrote: > > Have I convinced you? I'm only getting warmed up. I'm sure I can find more > > issues. > > That's all correct. But can't we create a subset of features that the > QObject template may use in order to make that subset work? I don't think so. The thing with currently no solution is the ability to add mix templates and signals (signals in template class or template signals). Without signals, it all breaks down. > As for the staticMetaObject, moc could write its output not as C++ code, > but as a macro containing the C++ code, for QObject templates, to be called > with those QObject template instantiations that the user creates (similar > to the old method of template instantiation where the user needs to list > the explicit template instantiation in a separately-compiled TU). Only one > TU would contain the macro call for any given instantiation, solving the > multiple-definition problem you mentioned. This would be severely limited, but doable. It would only work for a small, hand-crafted list of template parameters and only if the template parameters were used in very trivial uses, like these: > template > class ListModel : QAbstractListModel { > Q_OBJECT_TEMPLATE(T) > public: > // ... adding: Q_PROPERTY(T value READ value WRITE setValue) signals: void changed(const T &); public slots: void change(const T &t); > }; > > // in some other TU But you can't do anything non-trivial with T, like use it in remove_cv. If we were to do this, I'd also require the list of explicit instantiations to be in the header file. This serves two purposes: a) it makes it clear to the user that only those instantiations are permitted, and to the compiler that it should not instantiate on its own b) it allows moc to know which instantiations to create a meta object for, dispensing with the need for a macro. By doing this, moc-ng could even deal with complex uses of the template parameters. There's no solution for template members, though. Is it worth it? How often are templates used with only a very small list of explicit instantiations? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From olivier at woboq.com Sat Feb 27 11:54:35 2016 From: olivier at woboq.com (Olivier Goffart) Date: Sat, 27 Feb 2016 11:54:35 +0100 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: <3193642.KirRKZEmJY@tjmaciei-mobl4> References: <1687438.ejgbNIrEzN@finn> <3193642.KirRKZEmJY@tjmaciei-mobl4> Message-ID: <1960674.GsIaWdGl3K@finn> Am Freitag, 26. Februar 2016, 09:02:27 CET schrieb Thiago Macieira: > On quinta-feira, 25 de fevereiro de 2016 18:36:16 PST Olivier Goffart wrote: > > The parser need to be adapted if we want to support trailing type for > > signals/ slots/Q_INVOKABLE; or C++11 attributes; decltype as argument type > > for invokable; or fancy default arguments. There might be other things. > > Is there value in doing that for non-template classes and members? > > It's probably the same discussion as the almost-always-auto we had before, > but since we're talking about the public interface of something, I'd expect > people to write their types more often than just relying on the compiler to > guess it. We are talking about about user's code. They might have a style guide that says that every function need to use trailing return types (for consistency). They may also want to do stuff like Q_INVOKABLE auto userName(int userId) { return m_users.value(userId).name; } It's convinient. You might not like the use of auto, but it is not a good reason to forbid its use to Qt users. They see this as a limitation of moc. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From olivier at woboq.com Sat Feb 27 12:56:11 2016 From: olivier at woboq.com (Olivier Goffart) Date: Sat, 27 Feb 2016 12:56:11 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <2146618.dGbZ6ML4ne@tjmaciei-mobl4> References: <1566797.NsfuvUYKtX@agathebauer> <2146618.dGbZ6ML4ne@tjmaciei-mobl4> Message-ID: <3385044.5EnPRJ4lC3@finn> Am Freitag, 26. Februar 2016, 15:56:08 CET schrieb Thiago Macieira: > On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote: > > > The main problems of templated QObject are captured more or less in > > > this > > > > > > thread: > > > http://lists.qt-project.org/pipermail/development/2013-March/010288.html > > > > > > Personally I still think it would be a fancy feature, a bit dangerous > > > to > > > > > > implement maybe even dangerous to use, but really cool :-D > > > > Thanks for the link. How often is the MOC layout changed in an ABI > > incompatible way? > > There's no historical pattern. There was a major break from Qt 3 to 4 and > smaller one from 4 to 5. Qt 4 did have updates that didn't break the ABI; > the Qt 5.0 update removed the ability to read meta objects created with Qt > 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still > used register-on-load meta objects). > > But since the meta object itself has a version number and the only code that > ever reads the internal data is inside QtCore, so we could make changes > that change the layout. We haven't done that: all changes between major > releases have added things without changing the layout. > > That's the structure layout though. The file itself compares the > Q_MOC_OUTPUT_REVISION macro for equality (not ordering). Indeed, the Q_MOC_OUTPUT_REVISION could not change without breaking the installed moc files, if they get installed. > > I.e. what problems would we get from having to install the > > moc files? > > Lots. > > First of all, note that you're asking that > a) installing generated code > b) including such generated code from your public headers Not necessarily installed: - The feature might be used only for application code or implementation without having the need of installing them. - The build system can be adapted such that moc is run on headers containing object template from a library, and put these generated code in the build directory. > That means the headers do not compile until moc has generated its output. > Moc is currently able to ignore missing includes and we need that when > parsing .cpp files that contain Q_OBJECT. But doing that in headers is > just... ick. I don't see why this is an issue at all. As you said we already sometimes include the moc code from the .cpp in some cases. > There's also the fact that now the generated code becomes part of your > public ABI and will be compiled by your users. That means the code from moc > needs to compile with their compiler settings, whichever that may be. And > we would need to be very careful in how we change moc, because we need to > keep users' compatibility requirements when they upgrade Qt. Their > requirements could be stricter than Qt's (to a point). No changes from now. The generated code is already stricter than Qt headers themself. (we guard against more warnings). And since they include Qt header they already would have the problem with Qt headers. Also they would already have the problem with the moc generated files in their own application too. > If we talk simply about non-templated QObjects, there are only drawbacks. > The first is that the current output produces functions and data which > would end up in *each* and *every* translation unit that included the > output. You'd get linker errors. We could fix this by marking all the > functions as inline, but we can't fix the data. > > This includes the most important data member of all: const QMetaObject * > ClassName::staticMetaObject. It's a class-level static, so it needs to be > defined in a single .cpp and nowhere else. Period, no fix possible. Why would we even have to install the moc generated files for non templated QObject? We can split the moc generated files in two: one with the data that is not installed, and one with the functions that is included by every user of the templated object. => fix possible > So the discussion ends here for non-template classes, at least without > breaking Qt API. > > If we were willing to break Qt API, we could remove the staticMetaObject > class member and make it static inside a member static inline function. > Static data inside inline functions need to be merged by the linker and the > dynamic linker. [This would be good step to allow unnamed class or local classes to be Q_OBJECT/Q_GADGET since such class cannot have static data member. But this is incompatible with moc anyway. And has nothing to do with the discussion at hand] This is not relevant for templated QObject so i'll skip the next paragraphes. > [...] > And then there are templates. > > If we talk about template classes, then we have more problems. First, note > the bloating and runtime-deduplication problem I mentioned above. They'd > apply here. Though note that you can declare static data of template > classes in headers, so we wouldn't need to break the Qt API just for this. This bloat is a classig problem with templates in general. But that has not prevented them to be part of the C++ standard and used by many. > The next problem is the meta object layout. Currently, it's optimised to > contain static strings (an array of QByteArrayLiteral data in Qt 5, one long > const char array in Qt 4, which I'll bring back for Qt 6). Obviously, the > name of the instantiated class isn't constant, so the data can't be > constant either. It stands to reason that the use of a templated class in > the first place is the ability to use the template parameters in reflected > members (signals, slots, invocables, properties, enums, classinfo), so the > types and signatures for those members would need to change. that depends how you define the names. They can as well stay constant. (not including the template parametter). We would just need to disable automatic type registration in QMetaType for pointer to templated QObject. > Then we go back to whether we can keep the current Qt API: if the data isn't > constant, can we even return const char* from the QMetaObject member > functions like we do? If we're going to calculate the strings at runtime, > are we even able to? What happens for: > > signal: > void somethingHappened( > typename std::enable_if, > typename std::remove_cv::type>::type); > > How can QMetaObject understand what that type will be? > > Or we just say "the hell with it" and keep the template names in the class > name and reflected members. Of course, you can't connect that signal above > to SLOT(doSomething(int)) even if T was int. (no such problem with the new > connect style) Yes, it will be "std::enable_if, typename std::remove_cv::type>::type" Not really usable for the string based connection syntax. But not a problem for the function pointer based syntax. > The above also points to another problem: signals need to be reflected, so > you can't use std::enable_if like I did. Correct. But can be considered as a known limitation. > Then we need to look into template members (whether in a template class or > not). > > They simply can't be extracted for reflection. So a template slot would > never be usable in the SLOT() macro and template invocables would never be > callable from dynamic bindings (QML, QtDBus, QtScript). And there couldn't > be any template signals without a major overhauling of the way that signals > are identified. See my blog "the future of moc" from 2012 for more > information on the signal identification problem. > > To work around that, we'd need an explicit list of which template members > we'd like to be extracted for reflection in the meta object. > The proposal here is about templated QObject. Not templated signals or slots. Note that the function pointer connect allows templated slots. > Have I convinced you? I'm only getting warmed up. I'm sure I can find more > issues. The issues are either non issues, or can be worked around. There will be limitations for some corner case. But it can work in the general case. > > Alternatively: couldn't moc re-create the required data from included > > files > > when they contain templated objects? That would solve the problem as well, > > no? > > I have no idea what you meant here. > > Or, well, I do have one, but I don't think that I understood correctly what > you're suggesting. I understood that we keep a copy of the header file's > source in the target application and run moc at runtime to dynamically > create the meta object, on the fly. > > Since I don't think that's what you're suggesting and since the above has so > many problems (starting with the fact that it doesn't resolve the problem), > I'm not even going to analyse it. > > Can you clarify what you meant? It is what I re-worded at the begining of the email to avoid having to install generated files. While compiling an application, the build system would re- generate the moc generated files for the library. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Sat Feb 27 20:07:44 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 27 Feb 2016 11:07:44 -0800 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <3385044.5EnPRJ4lC3@finn> References: <2146618.dGbZ6ML4ne@tjmaciei-mobl4> <3385044.5EnPRJ4lC3@finn> Message-ID: <1901529.I9DEWmGBDb@tjmaciei-mobl4> On sábado, 27 de fevereiro de 2016 12:56:11 PST Olivier Goffart wrote: > > First of all, note that you're asking that > > > > a) installing generated code > > b) including such generated code from your public headers > > Not necessarily installed: > - The feature might be used only for application code or implementation > without having the need of installing them. > - The build system can be adapted such that moc is run on headers > containing object template from a library, and put these generated code in > the build directory. Ok, this is an interesting solution. I don't like it, but it's workable. If you want to use template QObjects, you need to tell your buildsystem where the header files declaring such a QObject are (/usr/include/...) and which template expansion of it you want. Each one. Then moc gets run for creating the meta object for those classes, which will need to be Q_DECL_EXPORT'ed from your module. If we do this, I recommend moc-ng, so that it can actually understand the templates and calculate the proper expansions for the reflection. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Feb 27 20:17:40 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 27 Feb 2016 11:17:40 -0800 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: <1960674.GsIaWdGl3K@finn> References: <3193642.KirRKZEmJY@tjmaciei-mobl4> <1960674.GsIaWdGl3K@finn> Message-ID: <3580704.WmUCd3luYC@tjmaciei-mobl4> On sábado, 27 de fevereiro de 2016 11:54:35 PST Olivier Goffart wrote: > > It's probably the same discussion as the almost-always-auto we had before, > > but since we're talking about the public interface of something, I'd > > expect > > people to write their types more often than just relying on the compiler > > to > > guess it. > > We are talking about about user's code. They might have a style guide that > says that every function need to use trailing return types (for > consistency). I think I got slightly mixed up. This part of the thread was talking about moc and I agree on your arguments. But my reply above was actually about qdoc... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From vindrg at gmail.com Sun Feb 28 15:08:44 2016 From: vindrg at gmail.com (Vincas Dargis) Date: Sun, 28 Feb 2016 16:08:44 +0200 Subject: [Development] Local static variable initialization in multithreaded code Message-ID: <56D2FF6C.9010905@gmail.com> Hello, If Qt 5.7 are going to support only "proper" C++11 compilers, can new Qt code assume that function local static variable initialization is thread-safe? Qt 5.7 Wiki page [1] makes me think that only Visual Studio 2013 and above are supported, is that right? If so, it appears that "magic statics" are implemented in 2013 RC [2] . So, is it appropriate to write code like this: // might be called in multiple threads int Foo::bar() { static QAtomicInteger count; return count.fetchAndAddRelaxed(1); } I am thinking maybe I could refactor small helper function qMakePreparedStmtId() [3] to use QAtomicInteger instead of unsigned int and mutex. Thanks. [1] https://wiki.qt.io/Qt-5.7.0-tools-and-versions [2] http://herbsutter.com/2013/09/09/visual-studio-2013-rc-is-now-available/ [3] http://code.qt.io/cgit/qt/qtbase.git/tree/src/sql/drivers/psql/qsql_psql.cpp?h=v5.5.1#n594 From olivier at woboq.com Sun Feb 28 16:37:22 2016 From: olivier at woboq.com (Olivier Goffart) Date: Sun, 28 Feb 2016 16:37:22 +0100 Subject: [Development] Local static variable initialization in multithreaded code In-Reply-To: <56D2FF6C.9010905@gmail.com> References: <56D2FF6C.9010905@gmail.com> Message-ID: <2312070.k5o3QjJnS7@finn> Am Sonntag, 28. Februar 2016, 16:08:44 CET schrieb Vincas Dargis: > Hello, > > If Qt 5.7 are going to support only "proper" C++11 compilers, can new Qt > code assume that function local static variable initialization is > thread-safe? > > Qt 5.7 Wiki page [1] makes me think that only Visual Studio 2013 and above > are supported, is that right? If so, it appears that "magic statics" are > implemented in 2013 RC [2] . > > So, is it appropriate to write code like this: > > // might be called in multiple threads > int Foo::bar() { > static QAtomicInteger count; > return count.fetchAndAddRelaxed(1); > } > > I am thinking maybe I could refactor small helper function > qMakePreparedStmtId() [3] to use QAtomicInteger instead of > unsigned int and mutex. Yes, if every supported compiler have support for it. But I think it is only working from MSVC 2015. (At least that's how we define Q_COMPILER_THREADSAFE_STATICS) In other words, you cannot use it inconditionaly, but you can use #ifdef Q_COMPILER_THREADSAFE_STATICS But in qMakePreparedStmtId() you can do this inconditionally: static QBasicAtomicInt qPreparedStmtCount = Q_BASIC_ATOMIC_INITIALIZER(0); Since QBasicAtomic is a literal type, it is going to be initialized at compile time and can be used without mutexes. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From vindrg at gmail.com Sun Feb 28 17:52:30 2016 From: vindrg at gmail.com (Vincas Dargis) Date: Sun, 28 Feb 2016 18:52:30 +0200 Subject: [Development] Local static variable initialization in multithreaded code In-Reply-To: <2312070.k5o3QjJnS7@finn> References: <56D2FF6C.9010905@gmail.com> <2312070.k5o3QjJnS7@finn> Message-ID: <56D325CE.8060604@gmail.com> 2016.02.28 17:37, Olivier Goffart rašė: > Since QBasicAtomic is a literal type, it is going to be initialized at compile > time and can be used without mutexes. That's interesting, thanks. Though should I add TODO for the future to simplify it when MSVC2013 support ends? Or it could be like that "forever"? From thiago.macieira at intel.com Sun Feb 28 18:16:34 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 28 Feb 2016 09:16:34 -0800 Subject: [Development] Local static variable initialization in multithreaded code In-Reply-To: <56D325CE.8060604@gmail.com> References: <56D2FF6C.9010905@gmail.com> <2312070.k5o3QjJnS7@finn> <56D325CE.8060604@gmail.com> Message-ID: <29849004.gEff8uuQPM@tjmaciei-mobl4> On domingo, 28 de fevereiro de 2016 18:52:30 PST Vincas Dargis wrote: > 2016.02.28 17:37, Olivier Goffart rašė: > > Since QBasicAtomic is a literal type, it is going to be initialized at > > compile time and can be used without mutexes. > > That's interesting, thanks. > > Though should I add TODO for the future to simplify it when MSVC2013 support > ends? Or it could be like that "forever"? Not worth it, since there's a lot of code using Q_GLOBAL_STATIC and they often have more reasons than just thread-safely initialisation. PS: MSVC 2015 RTM is also affected. Only Update 1 is fixed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From abbapoh at gmail.com Mon Feb 29 09:11:28 2016 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Mon, 29 Feb 2016 11:11:28 +0300 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <2392739.VTU6nKzX78@42> References: <1698764.6Goq3gLcPQ@tjmaciei-mobl4> <6809745.CJ549IbFAA@agathebauer> <2392739.VTU6nKzX78@42> Message-ID: 2016-02-26 11:43 GMT+03:00 Jędrzej Nowacki : > On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote: > > The thought evolved over last months and now I think that QAIM should not > be > QObject at all, it is just an unnecessary cost. > > Hm... Really? http://doc.qt.io/qt-5/qabstractitemmodel.html#signals AFAIK, Q_GADGET doesn't support signals -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo at vikingsoft.eu Mon Feb 29 09:44:29 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Mon, 29 Feb 2016 09:44:29 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <1901529.I9DEWmGBDb@tjmaciei-mobl4> References: <2146618.dGbZ6ML4ne@tjmaciei-mobl4> <3385044.5EnPRJ4lC3@finn> <1901529.I9DEWmGBDb@tjmaciei-mobl4> Message-ID: <56D404ED.70507@vikingsoft.eu> Den 27-02-2016 kl. 20:07 skrev Thiago Macieira: > On sábado, 27 de fevereiro de 2016 12:56:11 PST Olivier Goffart wrote: >>> First of all, note that you're asking that >>> >>> a) installing generated code >>> b) including such generated code from your public headers >> >> Not necessarily installed: >> - The feature might be used only for application code or implementation >> without having the need of installing them. >> - The build system can be adapted such that moc is run on headers >> containing object template from a library, and put these generated code in >> the build directory. > > Ok, this is an interesting solution. I don't like it, but it's workable. > > If you want to use template QObjects, you need to tell your buildsystem where > the header files declaring such a QObject are (/usr/include/...) and which > template expansion of it you want. Each one. Then moc gets run for creating > the meta object for those classes, which will need to be Q_DECL_EXPORT'ed from > your module. Well, you could give the include path to moc and let it search? If the compiler can find the proper file, moc can too. In qmake it would be possible to add something like EXTERNAL_TEMPLATE_HEADERS += foobar.h And magic stuff happens... It sounds like this is something that would require qmake, moc and qdoc support, not just moc-ng. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From Simon.Hausmann at theqtcompany.com Mon Feb 29 09:53:49 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Mon, 29 Feb 2016 08:53:49 +0000 Subject: [Development] change log creation tool (was: Re: Qt 5.6.0 missing change files) In-Reply-To: <85799145.xNj1AxyheL@tjmaciei-mobl4> References: <2097108.jEs4uOeqCI@tjmaciei-mobl4> <20160226190606.5922897.15581.61452@theqtcompany.com>, <85799145.xNj1AxyheL@tjmaciei-mobl4> Message-ID: Hi, I think that perhaps there is a misunderstanding - the perl script didn't do any of these things for me. Running this in declarative gives me: ~/dev/qtsdk/packaging-tools/create_changelog.pl $PWD 5.5.1..HEAD push on reference is experimental at /home/simon/dev/qtsdk/packaging-tools/create_changelog.pl line 107. keys on reference is experimental at /home/simon/dev/qtsdk/packaging-tools/create_changelog.pl line 151. Same in other modules. What am I missing? Simon ________________________________________ From: Development on behalf of Thiago Macieira Sent: Saturday, February 27, 2016 0:58 To: development at qt-project.org Subject: Re: [Development] change log creation tool (was: Re: Qt 5.6.0 missing change files) On sexta-feira, 26 de fevereiro de 2016 19:06:06 PST Hausmann Simon wrote: > Hi, > > It is different in three aspects: > > 1. It does not require passing git revision ranges as command line > parameters. So you have a heuristic algorithm that tries to guess the target version and which version was the last. You could have added this to the Perl script. > 2. It works on a per module basis instead of from the qt5 supermodule. So does the Perl script. > 3. It includes the task number from the commit message. So does the Perl script. So we gained the ability to run without being explicit which revisions we want, but now we need to install a compiler we didn't use before and compile code? -- 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 jedrzej.nowacki at theqtcompany.com Mon Feb 29 10:09:51 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 29 Feb 2016 10:09:51 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <2146618.dGbZ6ML4ne@tjmaciei-mobl4> References: <1566797.NsfuvUYKtX@agathebauer> <2146618.dGbZ6ML4ne@tjmaciei-mobl4> Message-ID: <2436443.lQHY3mroNT@42> On Friday 26 of February 2016 15:56:08 Thiago Macieira wrote: > > I.e. what problems would we get from having to install the > > moc files? > > Lots. And probably all go away if instead of installing anything we use QMetaObjectBuilder (assuming it's api stabilization). Yes it would have performance impact, but only on the templated version and only during initialization, qml is paying that price constantly without bigger complains. It would not require any build system changes. The only limitation I can think of right now is that in QObject, Foo needs to be know to QMetaType system, which is not a big deal. Cheers, Jędrek From Lars.Knoll at theqtcompany.com Mon Feb 29 10:19:25 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Mon, 29 Feb 2016 09:19:25 +0000 Subject: [Development] Supported platforms for Qt 5.8rt In-Reply-To: <3357985.JGI2DTR6is@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <2932609.kMHNNApRdD@tjmaciei-mobl4> <34E26E0B-3072-4AFA-858C-3B5209068B28@theqtcompany.com> <3357985.JGI2DTR6is@tjmaciei-mobl4> Message-ID: On 21/02/16 19:01, "Development on behalf of Thiago Macieira" wrote: >On domingo, 21 de fevereiro de 2016 07:01:57 PST Turunen Tuukka wrote: >> > Thiago Macieira kirjoitti 21.2.2016 kello >7.15: >> >> On sábado, 20 de fevereiro de 2016 22:09:20 PST Allan Sandfeld Jensen >> >> wrote: Well, feature-complete'ish. I recently found out we need clang >> >> 3.5 to use deleted constructors in Chromium. Clang 3.4 has a bug which >> >> will cause it to claim deleted methods causes ambiguity with >> >> non-deleted methods. So if we opt for gcc 4.8, I would suggest demanding >> >> clang 3.5 as well. >> > >> > That would drop FreeBSD 10.2, which is the current stable release today. >> >> According to their release plans both 10.3 and 11.0 should be out well >> before Qt 5.8. > >10.3 won 't update the compiler. 11.0 will. > >But let's keep Clang 3.4 as required, it's only 3 releases (currently) old. >We're supporting GCC 4.7, which is also 3 releases old. That's probably ok for Qt 5.8, let's reevaluate gcc 4.7 and clang 3.4 for Qt 5.9. Cheers, Lars From Lars.Knoll at theqtcompany.com Mon Feb 29 10:19:22 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Mon, 29 Feb 2016 09:19:22 +0000 Subject: [Development] We are planning to upgrade qdoc to use clang for parsing C++ In-Reply-To: <1698764.6Goq3gLcPQ@tjmaciei-mobl4> References: <2447389.PsW4KIE3lR@tjmaciei-mobl4> <1698764.6Goq3gLcPQ@tjmaciei-mobl4> Message-ID: On 25/02/16 18:02, "Development on behalf of Thiago Macieira" wrote: >On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote: >> This might be a burden for some of the Qt developers (Windows ones). >> >> But all the Qt users get a modern / flexible moc, see this thread: >> https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c90e > >I don't think we need a more flexible moc. What do we want to do that we can't >do with the current one? > >Don't say "template QObjects". That has other reasons for being a bad idea, >currently. > >Is it Olivier's maintenance burden? I think we will need a moc that understands and correctly interprets all of C++11/14/17's language constructs in the longer term. We will in any case need clang in quite some places in Qt, like qdoc, the code model in Qt Creator, and maybe other places. Yes, having that dependency is a burden on building Qt, but it's one we need. Cheers, Lars From Lars.Knoll at theqtcompany.com Mon Feb 29 10:19:23 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Mon, 29 Feb 2016 09:19:23 +0000 Subject: [Development] Dropping VS 2012 in Qt 5.7 In-Reply-To: <8947616.A7UhMYDDIY@tjmaciei-mobl4> References: <8947616.A7UhMYDDIY@tjmaciei-mobl4> Message-ID: <9463E139-8671-4FBD-9C28-CC9C9ADE7275@theqtcompany.com> I don't have big objections to that neither, given that MS isn't going forward with WEC2013. At the same time I wonder if it gives us a lot, as 5.7 is already in feature freeze. The main advantage would be on the CI side where we could drop the compiler. Cheers, Lars On 25/02/16 17:20, "Development on behalf of Thiago Macieira" wrote: >Just starting a new thread to get the attention of those that may have missed >it in the other platform. > >The proposal is to drop VS 2012 support in Qt 5.7 already, instead of >supporting it in 5.7 only and dropping in 5.8. > >The rationale is that we need VS2012 for WEC 2013 support, but there's no >point in supporting that operating system in Qt 5.7. It suffices that it is >supported in Qt 5.6, which is the long-term release. In other words, needing >WEC 2013 customers are better served by staying in Qt 5.6 than upgrading to >5.7. > >Opinions? Objections? > >I'd like to see this answered BEFORE we release 5.6 so we can add this >interesting tidbit to the changelog. The 5.5.0 changelog said: > > - Qt 5.7 will begin requiring certain C++11 features in order to > compile. The minimum compiler versions for that release will be: > * Clang 3.2 (included in XCode 5.0) > * GCC 4.7 > * Intel C++ Composer XE 2013 SP1 (compiler version 14.0) > * Microsoft Visual Studio 2012 (compiler version 17.0) > >Since that went out, we've already risen our minimum Clang required version to >3.4. > >> > > In summary Qt does not gain anything from pushing WEC2013 to 5.8: >> > > >> > > - Potential Qt Customers are not stranded due to 5.6 >> > > - WEC2013 in 5.8 doesn't really enable more projects >> > > - MS says it is dead and licenses are hard to come by >> > > - the currently visible project pipeline is rather dry on this >> > > platform >> > > >> > > *But* our C++11 offering is yet longer chained. >> > >> > So why are we bothering with VS2012 for Qt 5.7 then? Why wait until 5.8? >> > >> > Let's drop it now. >> >> That is fine for me as well. As Alex wrote, most important is that Qt 5.6 >> LTS supports both WEC7 and WEC13 and that latest for Qt 5.8 we no longer >> have these to slow down adoption of C++11 and other planned changes. >-- >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 Stefan.Walter at lisec.com Mon Feb 29 12:20:35 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Mon, 29 Feb 2016 11:20:35 +0000 Subject: [Development] Equivalent functionality of QScriptEngine::checkSyntax() in QJSEngine Message-ID: <0ea02d8ac1104f57a4c00201cc5f072c@ATSE-MAIL4.lisec.internal> Hi, I am migrating my code from QSCriptEngine to QJSEngine. What is the equivalent functionality of QScriptEngine::checkSyntax() in QJSEngine? Best Regards, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jedrzej.nowacki at theqtcompany.com Mon Feb 29 13:11:58 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 29 Feb 2016 13:11:58 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: References: <2392739.VTU6nKzX78@42> Message-ID: <1655586.etYY9lptjA@42> On Monday 29 of February 2016 11:11:28 Иван Комиссаров wrote: > 2016-02-26 11:43 GMT+03:00 Jędrzej Nowacki > On Thursday 25 of February 2016 19:22:55 Milian Wolff wrote: > > > > The thought evolved over last months and now I think that QAIM should not > > be > > QObject at all, it is just an unnecessary cost. > > Hm... Really? http://doc.qt.io/qt-5/qabstractitemmodel.html#signals AFAIK, > Q_GADGET doesn't support signals I was not explicit enough, I do not think QAIM, in the current state, is a very good API. I was thinking about new API with a similar functionality. Cheers, Jędrek From milian.wolff at kdab.com Mon Feb 29 13:21:52 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Mon, 29 Feb 2016 13:21:52 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <2146618.dGbZ6ML4ne@tjmaciei-mobl4> References: <1566797.NsfuvUYKtX@agathebauer> <2146618.dGbZ6ML4ne@tjmaciei-mobl4> Message-ID: <1939915.iN7lKn2x1G@milian-kdab2> On Friday, February 26, 2016 3:56:08 PM CET Thiago Macieira wrote: > On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote: > > > The main problems of templated QObject are captured more or less in > > > this > > > > > > thread: > > > http://lists.qt-project.org/pipermail/development/2013-March/010288.html > > > > > > Personally I still think it would be a fancy feature, a bit dangerous > > > to > > > > > > implement maybe even dangerous to use, but really cool :-D > > > > Thanks for the link. How often is the MOC layout changed in an ABI > > incompatible way? > > There's no historical pattern. There was a major break from Qt 3 to 4 and > smaller one from 4 to 5. Qt 4 did have updates that didn't break the ABI; > the Qt 5.0 update removed the ability to read meta objects created with Qt > 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still > used register-on-load meta objects). > > But since the meta object itself has a version number and the only code that > ever reads the internal data is inside QtCore, so we could make changes > that change the layout. We haven't done that: all changes between major > releases have added things without changing the layout. > > That's the structure layout though. The file itself compares the > Q_MOC_OUTPUT_REVISION macro for equality (not ordering). OK, but changing the layout between major versions is fine as we break ABI anyways then, no? > > I.e. what problems would we get from having to install the > > moc files? > > Lots. > Have I convinced you? I'm only getting warmed up. I'm sure I can find more > issues. Thanks for the exhaustive, and educative list! I think this should be put on the Wiki somewhere for future reference. > > Alternatively: couldn't moc re-create the required data from included > > files > > when they contain templated objects? That would solve the problem as well, > > no? > > I have no idea what you meant here. > > Or, well, I do have one, but I don't think that I understood correctly what > you're suggesting. I understood that we keep a copy of the header file's > source in the target application and run moc at runtime to dynamically > create the meta object, on the fly. > > Since I don't think that's what you're suggesting and since the above has so > many problems (starting with the fact that it doesn't resolve the problem), > I'm not even going to analyse it. > > Can you clarify what you meant? Yes, what I had in mind from my outsiders POV was the following, and I have no clue whether it is feasible at all: We have the following structure: $path1/lib/foo.h template Foo : QObject { ...}; moc is not doing anything here as the templated QObject is not fully specialized. $path2/app/bar.h: #include using Bar = Foo; Now when we compile app, moc runs over the fully specialized templated QObject and can instantiate it as needed and put all the required code into the moc_bar.cpp file as it would for a "normal" QObject. I.e. there is no need to install the templated QObject's moc file. This also is close to how an ordinary template is handled by a C++ compiler as far as I know. Maybe I'm missing something, but this sounds like an elegant solution? The only downside is increased complexity in moc to find such instantiations. Until clang can be used for moc, we could add a macro, lets say Q_INSTANTIATE(Foo), or similar. What do you say? What am I missing that would break my assumptions? -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From jani.heikkinen at theqtcompany.com Mon Feb 29 14:08:18 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Mon, 29 Feb 2016 13:08:18 +0000 Subject: [Development] Dropping VS 2012 in Qt 5.7 In-Reply-To: <9463E139-8671-4FBD-9C28-CC9C9ADE7275@theqtcompany.com> References: <8947616.A7UhMYDDIY@tjmaciei-mobl4> <9463E139-8671-4FBD-9C28-CC9C9ADE7275@theqtcompany.com> Message-ID: Hi! It seems we need a decision for this now to be able to proceed with https://codereview.qt-project.org/#/c/149325/ Br, Jani >>-----Original Message----- >>From: Development [mailto:development- >>bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of Knoll >>Lars >>Sent: 29. helmikuuta 2016 11:19 >>To: Thiago Macieira ; development at qt- >>project.org >>Subject: Re: [Development] Dropping VS 2012 in Qt 5.7 >> >>I don't have big objections to that neither, given that MS isn't going forward >>with WEC2013. >> >>At the same time I wonder if it gives us a lot, as 5.7 is already in feature freeze. >>The main advantage would be on the CI side where we could drop the compiler. >> >>Cheers, >>Lars >> >> >> >> >> >>On 25/02/16 17:20, "Development on behalf of Thiago Macieira" >>>behalf of thiago.macieira at intel.com> wrote: >> >>>Just starting a new thread to get the attention of those that may have missed >>>it in the other platform. >>> >>>The proposal is to drop VS 2012 support in Qt 5.7 already, instead of >>>supporting it in 5.7 only and dropping in 5.8. >>> >>>The rationale is that we need VS2012 for WEC 2013 support, but there's no >>>point in supporting that operating system in Qt 5.7. It suffices that it is >>>supported in Qt 5.6, which is the long-term release. In other words, needing >>>WEC 2013 customers are better served by staying in Qt 5.6 than upgrading to >>>5.7. >>> >>>Opinions? Objections? >>> >>>I'd like to see this answered BEFORE we release 5.6 so we can add this >>>interesting tidbit to the changelog. The 5.5.0 changelog said: >>> >>> - Qt 5.7 will begin requiring certain C++11 features in order to >>> compile. The minimum compiler versions for that release will be: >>> * Clang 3.2 (included in XCode 5.0) >>> * GCC 4.7 >>> * Intel C++ Composer XE 2013 SP1 (compiler version 14.0) >>> * Microsoft Visual Studio 2012 (compiler version 17.0) >>> >>>Since that went out, we've already risen our minimum Clang required version to >>>3.4. >>> >>>> > > In summary Qt does not gain anything from pushing WEC2013 to 5.8: >>>> > > >>>> > > - Potential Qt Customers are not stranded due to 5.6 >>>> > > - WEC2013 in 5.8 doesn't really enable more projects >>>> > > - MS says it is dead and licenses are hard to come by >>>> > > - the currently visible project pipeline is rather dry on this >>>> > > platform >>>> > > >>>> > > *But* our C++11 offering is yet longer chained. >>>> > >>>> > So why are we bothering with VS2012 for Qt 5.7 then? Why wait until 5.8? >>>> > >>>> > Let's drop it now. >>>> >>>> That is fine for me as well. As Alex wrote, most important is that Qt 5.6 >>>> LTS supports both WEC7 and WEC13 and that latest for Qt 5.8 we no longer >>>> have these to slow down adoption of C++11 and other planned changes. >>>-- >>>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 thiago.macieira at intel.com Mon Feb 29 17:35:44 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Feb 2016 08:35:44 -0800 Subject: [Development] change log creation tool (was: Re: Qt 5.6.0 missing change files) In-Reply-To: References: <85799145.xNj1AxyheL@tjmaciei-mobl4> Message-ID: <2286376.NgFNp7q6Q2@tjmaciei-mobl4> On segunda-feira, 29 de fevereiro de 2016 08:53:49 PST Hausmann Simon wrote: > Hi, > > I think that perhaps there is a misunderstanding - the perl script didn't do > any of these things for me. > > Running this in declarative gives me: > > ~/dev/qtsdk/packaging-tools/create_changelog.pl $PWD 5.5.1..HEAD > push on reference is experimental at > /home/simon/dev/qtsdk/packaging-tools/create_changelog.pl line 107. keys on > reference is experimental at > /home/simon/dev/qtsdk/packaging-tools/create_changelog.pl line 151. > > Same in other modules. What am I missing? I don't know. Works here. $ ../qtsdk/packaging-tools/create_changelog.pl . v5.5.1..origin/5.6 | wc -l push on reference is experimental at ../qtsdk/packaging-tools/ create_changelog.pl line 107. keys on reference is experimental at ../qtsdk/packaging-tools/ create_changelog.pl line 151. Malformed line: " Added QOpenGLExtraFunctions providing OpenGL ES 3.0 and 3.1 function wrappers in a cross-platform manner." Malformed line: " Added support for multiple render targets in QOpenGLFramebufferObject" Malformed line: " Made QInputMethod's visible more accurate" 474 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Feb 29 17:38:30 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Feb 2016 08:38:30 -0800 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <2436443.lQHY3mroNT@42> References: <2146618.dGbZ6ML4ne@tjmaciei-mobl4> <2436443.lQHY3mroNT@42> Message-ID: <2705763.7WDAeJMAmA@tjmaciei-mobl4> On segunda-feira, 29 de fevereiro de 2016 10:09:51 PST Jędrzej Nowacki wrote: > On Friday 26 of February 2016 15:56:08 Thiago Macieira wrote: > > > I.e. what problems would we get from having to install the > > > moc files? > > > > Lots. > > And probably all go away if instead of installing anything we use > QMetaObjectBuilder (assuming it's api stabilization). Yes it would have > performance impact, but only on the templated version and only during > initialization, qml is paying that price constantly without bigger > complains. It would not require any build system changes. The only > limitation I can think of right now is that in QObject, Foo needs to > be know to QMetaType system, which is not a big deal. What source data do you propose for QMOB? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Feb 29 17:40:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Feb 2016 08:40:08 -0800 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <1939915.iN7lKn2x1G@milian-kdab2> References: <2146618.dGbZ6ML4ne@tjmaciei-mobl4> <1939915.iN7lKn2x1G@milian-kdab2> Message-ID: <2004097.UGxYAqL1YT@tjmaciei-mobl4> On segunda-feira, 29 de fevereiro de 2016 13:21:52 PST Milian Wolff wrote: > What do you say? What am I missing that would break my assumptions? This is what Olivier proposed too. Like I said, I don't like it, but it works. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Feb 29 17:41:04 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Feb 2016 08:41:04 -0800 Subject: [Development] Dropping VS 2012 in Qt 5.7 In-Reply-To: References: <8947616.A7UhMYDDIY@tjmaciei-mobl4> <9463E139-8671-4FBD-9C28-CC9C9ADE7275@theqtcompany.com> Message-ID: <6940019.VT1iTT2XCW@tjmaciei-mobl4> On segunda-feira, 29 de fevereiro de 2016 13:08:18 PST Heikkinen Jani wrote: > Hi! > > It seems we need a decision for this now to be able to proceed with > https://codereview.qt-project.org/#/c/149325/ Hi Jani We have so far not got any objections. Assume it's going to be the case and add it to the changelog. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mathias at taschenorakel.de Mon Feb 29 17:58:38 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Mon, 29 Feb 2016 17:58:38 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <6809745.CJ549IbFAA@agathebauer> References: <1698764.6Goq3gLcPQ@tjmaciei-mobl4> <6809745.CJ549IbFAA@agathebauer> Message-ID: <56D478BE.3070908@taschenorakel.de> Am 25.02.2016 um 19:22 schrieb Milian Wolff: > Can you explain what those reasons are? I'd really love to write a generic > QAbstractTableModel implementation that operates using concepts. Currently > that would require type erasure and thus another set of virtual function > calls... > > I.e. in many projects I end up writing the same boiler plate code to display a > QVector in a view. As far as I can see most of that could be > abstracted away easily, leaving only slim concepts to the struct: > > struct MyRowType { > QString foo; > int bar; > QVariant data(int column, int role) const > { > if (!role == Qt::DisplayRole) return {} > switch (column) { > case 1: return foo; > case 2: return bar; > } > return {}; > } > }; Yes, please! Writing the almost same list model over and over again is boring. Although MyRowType::data() should not be a member, but a free-standing function to allow any type to be used as row data type. > If we'd have templates QObjects, the above could easily be written. I bet > there are other valid use-cases. QFutureWatcher comes to mind. Regularly using its pattern in projects and would prefer I could avoid this boilerplate. Ciao, Mathias From mail at michaelmoellney.de Mon Feb 29 18:33:39 2016 From: mail at michaelmoellney.de (=?UTF-8?Q?Michael_M=c3=b6llney?=) Date: Mon, 29 Feb 2016 18:33:39 +0100 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? Message-ID: <56D480F3.2050307@michaelmoellney.de> (Sorry if this is not the right place ... or was handled before ... is there a search over mailing list somewhere ?) I'm looking what C++11 feature I could use in my further cross platform development. For my production code there is a potpourri of VS2005 / VS2010 / gcc 4.5 / gcc 4.7 that is used for development. Some of them I would like to throw out (or even all) .... maybe I should skip to newer ones.... So I was looking around to see, what C++11 feature would be usable in what compiler version. I was spying what Qt knows about this and found the file: qcompilerdetection.h defining a lot of Q_COMPILER_XXXXX depending on the version of the compiler.... Bingo What confused me was that Q_COMPILER_RANGE_FOR is first defined for VS2015, the older ones are not setting this define. Following the discussion in this list about what compiler should be supported in what Qt version: 5.7, 5.8, ... and seeing in gerrit how many foreach are replaced by C++11 range for I hope that Q_COMPILER_RANGE_FOR should have been defined for VS2012 and up. At least this is what can be found on: http://en.cppreference.com/w/cpp/compiler_support https://msdn.microsoft.com/en-us/library/hh567368.aspx So is it an error in https://github.com/qtproject/qtbase/blob/5.7/src/corelib/global/qcompilerdetection.h#L917 ? Is the test https://github.com/qtproject/qtbase/blob/5.7/tests/auto/other/compiler/tst_compiler.cpp#L991 skipped for all VS compilers older than VS2015? Or does Qt know something about VS2012 and VS2013 that can not be found on the two sites I mentioned, so range for should not be used for these...? Cheers, Michael From vindrg at gmail.com Mon Feb 29 18:57:10 2016 From: vindrg at gmail.com (Vincas Dargis) Date: Mon, 29 Feb 2016 19:57:10 +0200 Subject: [Development] Local static variable initialization in multithreaded code In-Reply-To: <29849004.gEff8uuQPM@tjmaciei-mobl4> References: <56D2FF6C.9010905@gmail.com> <2312070.k5o3QjJnS7@finn> <56D325CE.8060604@gmail.com> <29849004.gEff8uuQPM@tjmaciei-mobl4> Message-ID: <56D48676.9000106@gmail.com> 2016.02.28 19:16, Thiago Macieira rašė: >> Though should I add TODO for the future to simplify it when MSVC2013 support >> ends? Or it could be like that "forever"? > > Not worth it, since there's a lot of code using Q_GLOBAL_STATIC and they often > have more reasons than just thread-safely initialisation. > > PS: MSVC 2015 RTM is also affected. Only Update 1 is fixed. > Thanks Olivier and Thiago for guidance! From thiago.macieira at intel.com Mon Feb 29 19:15:13 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Feb 2016 10:15:13 -0800 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? In-Reply-To: <56D480F3.2050307@michaelmoellney.de> References: <56D480F3.2050307@michaelmoellney.de> Message-ID: <4485416.HDKLJEExJc@tjmaciei-mobl4> On segunda-feira, 29 de fevereiro de 2016 18:33:39 PST Michael Möllney wrote: > What confused me was that > Q_COMPILER_RANGE_FOR > is first defined for VS2015, the older ones are not setting this define. [cut] > At least this is what can be found on: > http://en.cppreference.com/w/cpp/compiler_support > https://msdn.microsoft.com/en-us/library/hh567368.aspx > > So is it an error in > https://github.com/qtproject/qtbase/blob/5.7/src/corelib/global/qcompilerdet > ection.h#L917 ? It's intentional. It's buggy in previous versions, so the #define is not present. > Is the test > https://github.com/qtproject/qtbase/blob/5.7/tests/auto/other/compiler/tst_c > ompiler.cpp#L991 skipped for all VS compilers older than VS2015? > > Or does Qt know something about VS2012 and VS2013 that can not be found on > the two sites I mentioned, so range for should not be used for these...? Use it only if you can test that it actually works. The deal for Qt's own code is that the submitter using ranged for must test with at least one version of the MS compiler before hitting the Stage button. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mail at michaelmoellney.de Mon Feb 29 19:40:07 2016 From: mail at michaelmoellney.de (=?UTF-8?Q?Michael_M=c3=b6llney?=) Date: Mon, 29 Feb 2016 19:40:07 +0100 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? In-Reply-To: <4485416.HDKLJEExJc@tjmaciei-mobl4> References: <56D480F3.2050307@michaelmoellney.de> <4485416.HDKLJEExJc@tjmaciei-mobl4> Message-ID: <56D49087.8070608@michaelmoellney.de> Am 29.02.2016 um 19:15 schrieb Thiago Macieira: > On segunda-feira, 29 de fevereiro de 2016 18:33:39 PST Michael Möllney wrote: >> At least this is what can be found on: >> http://en.cppreference.com/w/cpp/compiler_support >> https://msdn.microsoft.com/en-us/library/hh567368.aspx >> >> So is it an error in >> https://github.com/qtproject/qtbase/blob/5.7/src/corelib/global/qcompilerdet >> ection.h#L917 ? > It's intentional. It's buggy in previous versions, so the #define is not > present. Wow, thank you for this info. Do you have a link at hand, where this is shown? Is there a code pattern that's producing buggy code? >> Is the test >> https://github.com/qtproject/qtbase/blob/5.7/tests/auto/other/compiler/tst_c >> ompiler.cpp#L991 skipped for all VS compilers older than VS2015? >> >> Or does Qt know something about VS2012 and VS2013 that can not be found on >> the two sites I mentioned, so range for should not be used for these...? > Use it only if you can test that it actually works. > > The deal for Qt's own code is that the submitter using ranged for must test > with at least one version of the MS compiler before hitting the Stage button. > Sorry, I could not find this info. Sounds like a strong burden for developers coming from the gcc platform committing patches to Qt that they have to test on VS2012 first. Should this be mentioned in https://wiki.qt.io/Coding_Conventions#Conventions_for_C.2B.2B11_usage From sergio.martins at kdab.com Mon Feb 29 18:47:11 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Mon, 29 Feb 2016 18:47:11 +0100 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? In-Reply-To: <56D49087.8070608@michaelmoellney.de> References: <56D480F3.2050307@michaelmoellney.de> <4485416.HDKLJEExJc@tjmaciei-mobl4> <56D49087.8070608@michaelmoellney.de> Message-ID: <1592009.3t1q8t43qM@desktop-ga45d22> On Monday, February 29, 2016 07:40:07 PM Michael Möllney wrote: > Am 29.02.2016 um 19:15 schrieb Thiago Macieira: > > On segunda-feira, 29 de fevereiro de 2016 18:33:39 PST Michael Möllney wrote: > >> At least this is what can be found on: > >> http://en.cppreference.com/w/cpp/compiler_support > >> https://msdn.microsoft.com/en-us/library/hh567368.aspx > >> > >> So is it an error in > >> https://github.com/qtproject/qtbase/blob/5.7/src/corelib/global/qcompiler > >> det ection.h#L917 ? > > > > It's intentional. It's buggy in previous versions, so the #define is not > > present. > > Wow, thank you for this info. > Do you have a link at hand, where this is shown? > Is there a code pattern that's producing buggy code? https://connect.microsoft.com/VisualStudio/feedback/details/799458 Regards, -- Sérgio Martins | sergio.martins at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From thiago.macieira at intel.com Mon Feb 29 20:12:30 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Feb 2016 11:12:30 -0800 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? In-Reply-To: <56D49087.8070608@michaelmoellney.de> References: <56D480F3.2050307@michaelmoellney.de> <4485416.HDKLJEExJc@tjmaciei-mobl4> <56D49087.8070608@michaelmoellney.de> Message-ID: <26489832.CfDmPXSt7F@tjmaciei-mobl4> On segunda-feira, 29 de fevereiro de 2016 19:40:07 PST Michael Möllney wrote: > >> So is it an error in > >> https://github.com/qtproject/qtbase/blob/5.7/src/corelib/global/qcompiler > >> det ection.h#L917 ? > > > > It's intentional. It's buggy in previous versions, so the #define is not > > present. > > Wow, thank you for this info. > Do you have a link at hand, where this is shown? I thought I had added it to qcompilerdetection.h, but apparently didn't. Searching in MS connect is awful (only Apple's bugtracking is worse), so no, I don't have the link handy. > Is there a code pattern that's producing buggy code? Whatever is in tst_compiler.cpp. It happens when you don't use braces with the statement. > > The deal for Qt's own code is that the submitter using ranged for must > > test > > with at least one version of the MS compiler before hitting the Stage > > button. > Sorry, I could not find this info. > > Sounds like a strong burden for developers coming from the gcc platform > committing patches to Qt > that they have to test on VS2012 first. Yes. Tough luck. The CI is not for checking that your code compiles. You must have done that before you even pushed. If you don't want to be forced to test this specific thing on VS2012, don't use range-fors. > Should this be mentioned in > https://wiki.qt.io/Coding_Conventions#Conventions_for_C.2B.2B11_usage Yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Mon Feb 29 22:47:02 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 29 Feb 2016 22:47:02 +0100 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? In-Reply-To: <56D480F3.2050307@michaelmoellney.de> References: <56D480F3.2050307@michaelmoellney.de> Message-ID: <201602292247.02877.marc.mutz@kdab.com> On Monday 29 February 2016 18:33:39 Michael Möllney wrote: > What confused me was that > Q_COMPILER_RANGE_FOR > is first defined for VS2015, the older ones are not setting this define. Try for (int i : container) QCOMPARE(i, i); on VS < 2015. You'll hit a parse error. For more details on what's supposed to be allowed and what not: https://codereview.qt-project.org/142782 HTH, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From mail at michaelmoellney.de Mon Feb 29 22:13:50 2016 From: mail at michaelmoellney.de (=?UTF-8?Q?Michael_M=c3=b6llney?=) Date: Mon, 29 Feb 2016 22:13:50 +0100 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? In-Reply-To: <201602292247.02877.marc.mutz@kdab.com> References: <56D480F3.2050307@michaelmoellney.de> <201602292247.02877.marc.mutz@kdab.com> Message-ID: <56D4B48E.4040009@michaelmoellney.de> Am 29.02.2016 um 22:47 schrieb Marc Mutz: > On Monday 29 February 2016 18:33:39 Michael Möllney wrote: >> What confused me was that >> Q_COMPILER_RANGE_FOR >> is first defined for VS2015, the older ones are not setting this define. > Try > > for (int i : container) > QCOMPARE(i, i); > > on VS < 2015. You'll hit a parse error. > > For more details on what's supposed to be allowed and what not: > https://codereview.qt-project.org/142782 > > HTH, > Marc > Ah, ok, thank you for the details. Maybe someone could teach the "Qt Sanity Bot" to detect that pattern, so (gcc) developers that are VS agnostic (or simply do not have that MS platform in access) could still support in patching Qt. Cheers Michael From thiago.macieira at intel.com Mon Feb 29 23:05:15 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Feb 2016 14:05:15 -0800 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? In-Reply-To: <56D4B48E.4040009@michaelmoellney.de> References: <56D480F3.2050307@michaelmoellney.de> <201602292247.02877.marc.mutz@kdab.com> <56D4B48E.4040009@michaelmoellney.de> Message-ID: <2451423.VTaIDnAVTP@tjmaciei-mobl4> On segunda-feira, 29 de fevereiro de 2016 22:13:50 PST Michael Möllney wrote: > Maybe someone could teach the "Qt Sanity Bot" to detect that pattern, so > (gcc) developers that are VS agnostic > (or simply do not have that MS platform in access) could still support > in patching Qt. The sanity bot can be taught a lot of things from that document. But developers are also expected to be familiar with it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center