Re: [Development] Qt LTS & C++11 plans (CopperSpice)

On Tuesday 28 July 2015 06:19:03 Andre Somers wrote: > > The section 2 says "grants the Foundation [...] the right and license, to > > use, copy, duplicate [...] any and all existing and future Qt Free > > Edition releases ..." > > So, the foundation has the right, but not the obligation to do so.

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

On 27-7-2015 18:13, Thiago Macieira wrote: > On Monday 27 July 2015 08:44:30 Knoll Lars wrote: >> I can understand the issues that non latin speakers are facing with this >> well. I’ve often used qDebug() to debug non latin use cases, and in 90% of >> the cases I just want to know what the string r

Re: [Development] Qt LTS & C++11 plans (CopperSpice)

On 27-7-2015 18:21, Thiago Macieira wrote: > On Monday 27 July 2015 08:01:53 André Somers wrote: >> I am not a lawer and I don't know the wording of the KDE Free Qt >> Foundation agreement, but are you sure that in case that agreement is >> triggered the verion you branched off off will fall under

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

Hi Thiago, 2015-07-28 1:34 GMT+09:00 Thiago Macieira : > On Monday 27 July 2015 19:27:44 NIkolai Marchenko wrote: >> > Or just use qPrintable() around your strings. >> >> you do realize, that it will require editing thousands of instances of >> qDebug in the old code? > > Yes. grepped "QDebug\s*&

Re: [Development] Replace QtXml backend

On Monday 27 July 2015 16:25:10 Thiago Macieira wrote: > > Reusing libxml2 and libxlt should actually cause code decrease. > > Huh... not really > > It would cause a minimal decrease for anyone using qtwebengine, but it > would increase the code size for everyone who isn't. Remember that every

Re: [Development] Replace QtXml backend

On Monday 27 July 2015 23:43:06 Cristian Adam wrote: > libxml2 and libxlt are already part of the Qt source tree, part of > QtWebEngine-chromium > http://code.qt.io/cgit/qt/qtwebengine-chromium.git/tree/chromium/third_party > /libxml > http://code.qt.io/cgit/qt/qtwebengine-chromium.git/tree/chromi

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Thiago Macieira wrote: > The total memory allocated for QList is always equal to or bigger than > QVector for the same size, regardless of T. So in addition to having the > same memory size, you access the data through one extra indirection. I was talking about speed, not memory consumption. > Th

Re: [Development] Replace QtXml backend

On 7/27/2015 11:21 PM, Cristian Adam wrote: On Mon, Jul 27, 2015 at 9:58 AM, Gerhard Scheikl wrote: I didn't fully think it through yet, was just an idea. :) > > So we came up with the idea to replace the back-end with Xerces and try to > > leave the Qt API part the same.

Re: [Development] Replace QtXml backend

On Mon, Jul 27, 2015 at 9:58 AM, Gerhard Scheikl > wrote: I didn't fully think it through yet, was just an idea. :) > > So we came up with the idea to replace the back-end with Xerces and try to > > leave the Qt API part the same. > > That's in

Re: [Development] Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 22:01:26 Andreas Aardal Hanssen wrote: > > On 27 Jul 2015, at 21:14, Thiago Macieira > > wrote:> > > On Monday 27 July 2015 21:50:15 NIkolai Marchenko wrote: > >> Oh, but now you KNOW that it is a misspeled link to paypal. In real > >> situation you won't have this forward

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On Monday 27 July 2015 21:44:32 Kevin Kofler wrote: > > For "bad" types for QList, that O(1) is hiding two indirections. Only > > one with QVector. That's a huge cost you're not talking about. > > It's a factor 2, vs. a factor sizeof(T)/sizeof(T*) in the opposite > direction for the middle insert

Re: [Development] Backwards compatibiltiy break in Qt 5.5

> On 27 Jul 2015, at 21:14, Thiago Macieira wrote: > > On Monday 27 July 2015 21:50:15 NIkolai Marchenko wrote: >> Oh, but now you KNOW that it is a misspeled link to paypal. In real >> situation you won't have this forward knowlegde. > > The point is that I have all of the information I need.

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

Giuseppe D'Angelo wrote: > Also nobody says that middle insertions of removals should be "extra > cheap". This is a very common operation for a random-access, ordered but not auto- sorted, array/vector-type list. The "array of pointers" data structure is an effective compromise to make this reaso

Re: [Development] Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 21:50:15 NIkolai Marchenko wrote: > Oh, but now you KNOW that it is a misspeled link to paypal. In real > situation you won't have this forward knowlegde. The point is that I have all of the information I need. If I see a debug output saying: ClassName::openLink: trying to

Re: [Development] Backwards compatibiltiy break in Qt 5.5

Oh, but now you KNOW that it is a misspeled link to paypal. In real situation you won't have this forward knowlegde. On Mon, Jul 27, 2015 at 9:43 PM, Thiago Macieira wrote: > On Monday 27 July 2015 21:27:23 NIkolai Marchenko wrote: > > \u0440\u0430\u0443\u0440\u0430l.\u0441\u043em > > > > Oh, re

Re: [Development] Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 21:41:44 NIkolai Marchenko wrote: > Yes,but this requires making override visible in every file of the project. We can solve this by having a global #ifdef that can change the setting. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open So

Re: [Development] Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 21:27:23 NIkolai Marchenko wrote: > \u0440\u0430\u0443\u0440\u0430l.\u0441\u043em > > Oh, really? Note, I said, without copypasting to uncode converter. It's quite evident it's not a link to paypal.com because I can't see "paypal" there. -- Thiago Macieira - thiago.macie

Re: [Development] Backwards compatibiltiy break in Qt 5.5

Yes,but this requires making override visible in every file of the project. On Mon, Jul 27, 2015 at 9:34 PM, Ruslan Nigmatullin wrote: > 27.07.2015, 11:01, "NIkolai Marchenko" : > > > Once we venture into the territory of debugging 50%+ non-latin, it will > be impossible to extract any useful in

Re: [Development] Backwards compatibiltiy break in Qt 5.5

27.07.2015, 11:01, "NIkolai Marchenko" :> Once we venture into the territory of debugging 50%+ non-latin, it will be impossible to extract any useful information from debug output at a glance. And that is the situation, where aforementioned flag to change the behaviour in one place will be VERY use

Re: [Development] Backwards compatibiltiy break in Qt 5.5

> \u0440\u0430\u0443\u0440\u0430l.\u0441\u043em Can you really tell at a glance what exactly you are looking at here without consulting the oracle or, at least, reencoding it to readable format? On Mon, Jul 27, 2015 at 9:22 PM, Thiago Macieira wrote: > On Monday 27 July 2015 20:52:24 NIkolai Ma

Re: [Development] Backwards compatibiltiy break in Qt 5.5

\u0440\u0430\u0443\u0440\u0430l.\u0441\u043em Oh, really? Note, I said, without copypasting to uncode converter. On Mon, Jul 27, 2015 at 9:22 PM, Thiago Macieira wrote: > On Monday 27 July 2015 20:52:24 NIkolai Marchenko wrote: > > Let's make it harder, can you guesss that it even is a link t

Re: [Development] Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 20:52:24 NIkolai Marchenko wrote: > Let's make it harder, can you guesss that it even is a link to paypal > website with qDebug() as you intend it to work without copypasting? > > раураl.соm ? > > Hint: only 2 letters here are in english. With qDebug() as it is in Qt 5.5,

Re: [Development] Backwards compatibiltiy break in Qt 5.5

> Once we venture into the territory of debugging 50%+ non-latin, it will be impossible to extract any useful information from debug output at a glance. And that is the situation, where aforementioned flag to change the behaviour in one place will be VERY useful. Unlike your suggestion of fixing s

Re: [Development] Backwards compatibiltiy break in Qt 5.5

The problem with your approach to qDebug is that it only works well where most of the text is in English and only individual letters are unicode. Once we venture into the territory of debugging 50%+ non-latin, it will be impossible to extract any useful information from debug output at a glance. 2

Re: [Development] Backwards compatibiltiy break in Qt 5.5

Let's make it harder, can you guesss that it even is a link to paypal website with qDebug() as you intend it to work without copypasting? раураl.соm ? Hint: only 2 letters here are in english. 2015-07-27 20:25 GMT+03:00 Thiago Macieira : > On Monday 27 July 2015 09:05:29 Thiago Macieira wrote:

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

Ok, let's try another line of inquiry I just thought of : Since when debuggin with qDebug requires external unicode converter, not provided with Qt? Surely you realize that without an access to one, the output will not be helpful to ANYONE ? And while we're at it: let's say we are debugging applic

Re: [Development] Backwards compatibiltiy break in Qt 5.5

Question, how much do you think this use case happens for non-latin users compared to the one I, and Knoll Lars are arguing about? 2015-07-27 20:25 GMT+03:00 Thiago Macieira : > On Monday 27 July 2015 09:05:29 Thiago Macieira wrote: > > "а", which was the attack vector for homograph sites like pа

Re: [Development] Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 09:05:29 Thiago Macieira wrote: > "а", which was the attack vector for homograph sites like pаypal.com or > pаypаl.com or раураl.com or other permutations of the letters. A control Question: which of the three is the legit website? And what method did you use to find out?

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 16:54:49 Knoll Lars wrote: > QChar::isPrint() is not that expensive, and this is about debug output. Your > code escaping all these chars is a more expensive if it gets hit. I don't think so. The code is pretty efficient and it's just a simple stateful loop. QChar::isPrint

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 16:57:23 Knoll Lars wrote: > On 27/07/15 18:52, "development-bounces+lars.knoll=theqtcompany.com@qt- project.org on behalf of Thiago Macieira" wrote: > >On Monday 27 July 2015 19:49:15 NIkolai Marchenko wrote: > >> If we are to believe Thiago, every developer that needs to s

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

On 27/07/15 18:52, "development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira" wrote: >On Monday 27 July 2015 19:49:15 NIkolai Marchenko wrote: >> If we are to believe Thiago, every developer that needs to see trace >> information from an old code, now needs

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

On 27/07/15 18:13, "development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Thiago Macieira" wrote: >On Monday 27 July 2015 08:44:30 Knoll Lars wrote: >> I can understand the issues that non latin speakers are facing with this >> well. I’ve often used qDebug() to debug non

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 19:49:15 NIkolai Marchenko wrote: > If we are to believe Thiago, every developer that needs to see trace > information from an old code, now needs to edit all of his qDebug()'ed > instances to use qPrintable. Yes, all of them. However much there is, > manually, one by one. Y

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

If we are to believe Thiago, every developer that needs to see trace information from an old code, now needs to edit all of his qDebug()'ed instances to use qPrintable. Yes, all of them. However much there is, manually, one by one. On Mon, Jul 27, 2015 at 7:34 PM, Thiago Macieira wrote: > On Mon

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

> you do realize, that it will require editing thousands of instances of > qDebug in the old code? > Yes. And here, ladies and gentlemen, is exactly the reason this discussion is even happening. This.Should. Not. Be. The. Case. This is just wrong on so many levels I cannot express it in words.

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 19:27:44 NIkolai Marchenko wrote: > > Or just use qPrintable() around your strings. > > you do realize, that it will require editing thousands of instances of > qDebug in the old code? Yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Op

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

Not to mention, this is cumbersome to the extreme. On Mon, Jul 27, 2015 at 7:26 PM, Thiago Macieira wrote: > On Monday 27 July 2015 19:20:34 NIkolai Marchenko wrote: > > b) getting the old behaviour "back" requires using "noquote" everywhere > > which breaks the code if you need to build it with

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

> Or just use qPrintable() around your strings. you do realize, that it will require editing thousands of instances of qDebug in the old code? On Mon, Jul 27, 2015 at 7:26 PM, Thiago Macieira wrote: > On Monday 27 July 2015 19:20:34 NIkolai Marchenko wrote: > > b) getting the old behaviour "bac

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 19:20:34 NIkolai Marchenko wrote: > b) getting the old behaviour "back" requires using "noquote" everywhere > which breaks the code if you need to build it with earlier qt version Or just use qPrintable() around your strings. -- Thiago Macieira - thiago.macieira (AT) intel.

Re: [Development] Replace QtXml backend

On Monday 27 July 2015 14:24:27 Gerhard Scheikl wrote: > > QXmlStreamReader is not a SAX parser. > > But the approach is very similar. Both are "iterative". :) Indeed. The term is "StAX parser". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technol

Re: [Development] Qt LTS & C++11 plans (CopperSpice)

On Monday 27 July 2015 08:01:53 André Somers wrote: > I am not a lawer and I don't know the wording of the KDE Free Qt > Foundation agreement, but are you sure that in case that agreement is > triggered the verion you branched off off will fall under that licence > and be the one that will be re

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

> I'm ok with a flag, as long as it's the default. I am ok with a flag too. As long as escaping can be turned off, preferably in one place instead of editing qDebug()'s everywhere it is ok. I am so vehemently against the change as it is now primarily because it a) cannot be contained in a simple #i

Re: [Development] Q_DECLARE_TYPEINFO compile time checks

On Monday 27 July 2015 17:59:24 Marc Mutz wrote: > On Monday 27 July 2015 15:12:03 Curtis Mitch wrote: > > Hmmm, I don't think that helps with > > https://codereview.qt-project.org/#/c/122268/, for example. > > > > Oh well. > > We could have syncqt.pl check for Q_DECLARE_TYPEINFO(T, X) for any T

Re: [Development] FW: Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 08:44:30 Knoll Lars wrote: > I can understand the issues that non latin speakers are facing with this > well. I’ve often used qDebug() to debug non latin use cases, and in 90% of > the cases I just want to know what the string reads. The unicode content > of it is interesting

Re: [Development] Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 01:25:18 NIkolai Marchenko wrote: > Hi! We (Russian Qt community) have a situation we could not resolve with > Thiago Macieira in bug tracker, so have to ask for Chief Maintainer's > attention. > The bug in question is there: > https://bugreports.qt.io/browse/QTBUG-47316 Yes

Re: [Development] Replace QtXml backend

On Monday 27 July 2015 09:58:42 Gerhard Scheikl wrote: > > How is it licensed? > > Apache 2.0 This is a deal-breaker. > Maybe creating a 3rd party library would be the better choice. > Maybe creating something like QtXml2 would be an option. QtXml2 under an LGPLv3 licence might be a acceptable

Re: [Development] Q_DECLARE_TYPEINFO compile time checks

On Monday 27 July 2015 15:12:03 Curtis Mitch wrote: > Hmmm, I don't think that helps with > https://codereview.qt-project.org/#/c/122268/, for example. > > Oh well. We could have syncqt.pl check for Q_DECLARE_TYPEINFO(T, X) for any T it generates a header for, but that doesn't work for several r

Re: [Development] Backwards compatibiltiy break in Qt 5.5

On Monday 27. July 2015 01:25:18 NIkolai Marchenko wrote: > Hi! We (Russian Qt community) have a situation we could not resolve with > Thiago Macieira in bug tracker, so have to ask for Chief Maintainer's > attention. > The bug in question is there: > https://bugreports.qt.io/browse/QTBUG-47316 >[.

Re: [Development] Replace QtXml backend

On Monday 27. July 2015 14:24:27 Gerhard Scheikl wrote: > On Monday 27 July 2015 09:47:34 Knoll Lars wrote: > > With the old QXmlReader or with QXmlStreamReader? > > We are currently using QXmlSchemaValidator for the validation. > > > QXmlStreamReader is not a SAX parser. > > But the approach is

Re: [Development] Q_DECLARE_TYPEINFO compile time checks

> -Original Message- > From: m...@kdab.com [mailto:m...@kdab.com] On Behalf Of Marc Mutz > Sent: Monday, 27 July 2015 3:29 PM > To: Curtis Mitch > Cc: development@qt-project.org > Subject: Re: Q_DECLARE_TYPEINFO compile time checks > > On Monday 27 July 2015 14:02:59 Curtis Mitch wrote: >

Re: [Development] Replace QtXml backend

On Monday 27 July 2015 09:47:34 Knoll Lars wrote: > > With the old QXmlReader or with QXmlStreamReader? We are currently using QXmlSchemaValidator for the validation. > QXmlStreamReader is not a SAX parser. But the approach is very similar. Both are "iterative". :) Best regards Gerhard ___

Re: [Development] Q_DECLARE_TYPEINFO compile time checks

On Monday 27 July 2015 14:02:59 Curtis Mitch wrote: > You mentioned that you have some kind of enforcement of the > Q_DECLARE_TYPEINFO stuff - can you please share this so that others can > run it on their modules? It currently conflicts with Thiago's changes to add Q_RELOCATABLE_TYPE. I'll upstr

[Development] Tool to record GIFs

Hi. I recently pushed a patch [1] that adds a GIF recorder "tool" (it's a manual test) to qt-labs/qtquickcontrols2. The tool provides a convenient way to record a GIF as you interact with a Qt application. It can also record the events that occurred during the recording and output them as call

Re: [Development] Replace QtXml backend

On 27/07/15 11:23, "Gerhard Scheikl" wrote: > >> Did you consider using QXmlStreamReader/Writer instead of the old QXml? >> These classes are fully compliant, well tested and very fast. The only >> drawback is that there is no equivalent to the QDom* classes, but in >>most >> cases you’re better

Re: [Development] Replace QtXml backend

> Did you consider using QXmlStreamReader/Writer instead of the old QXml? > These classes are fully compliant, well tested and very fast. The only > drawback is that there is no equivalent to the QDom* classes, but in most > cases you’re better off parsing directly into your own data structures >

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

I guess we could add some output to your container benchmark app that explains what your QList will actually do and not do. martin From: development-bounces+martin.smith=theqtcompany@qt-project.org on behalf of Marc Mutz Sent: Monday, July 27, 20

Re: [Development] Replace QtXml backend

On 27/07/15 09:58, "Gerhard Scheikl" wrote: >On Friday 24 July 2015 08:50:07 Thiago Macieira wrote: >> On Friday 24 July 2015 15:26:30 Gerhard Scheikl wrote: >> Hello Gerhard >> >> Your question is answered mostly by your paragraph above: QtXml is in >>Done >> state, so we really don't want to d

Re: [Development] Backwards compatibiltiy break in Qt 5.5

My first instinct was suggesting MS to support Unicode in their console... but then I tried to reproduce the described issue on OS X and succeeded. qDebug() << "this is сообщение на русском"; which I'd expect to be treated like a byte array, gives me this is сообщение на русском though qDebug()

[Development] FW: Backwards compatibiltiy break in Qt 5.5

Hi, I can understand the issues that non latin speakers are facing with this well. I’ve often used qDebug() to debug non latin use cases, and in 90% of the cases I just want to know what the string reads. The unicode content of it is interesting to me in only 10% of the cases. For most users not d

Re: [Development] Backwards compatibiltiy break in Qt 5.5

On Monday 27 July 2015 00:25:18 NIkolai Marchenko wrote: > (I am not entirely sure why I haven't received at least a notification of > why this post has not appeared the first time I tried to send it, so here > we go again. Btw, it was Thiago Macieira himself who actually suggested I > mail this li

Re: [Development] HEADS UP: Don't use QList, use Q_DECLARE_TYPEINFO

On Monday 27 July 2015 00:27:18 Kevin Kofler wrote: > It doesn't switch the stuff it actually guarantees: That sentence is perfectly correct. But here's the catch: The docs guarantee _a certain implementation_, incl. the switching. The problem is that the conditions under which the switch occurs

Re: [Development] Replace QtXml backend

On Friday 24 July 2015 08:50:07 Thiago Macieira wrote: > On Friday 24 July 2015 15:26:30 Gerhard Scheikl wrote: > Hello Gerhard > > Your question is answered mostly by your paragraph above: QtXml is in Done > state, so we really don't want to do major surgery in it, which could open > the door up