From jordan.software54 at gmail.com Tue Aug 2 02:21:11 2016 From: jordan.software54 at gmail.com (Michael Jordan) Date: Mon, 1 Aug 2016 20:21:11 -0400 Subject: [Development] Request for a new project to handle sf2 (soundfont) libraries Message-ID: <87B07811-5C7E-4288-A66E-A84C8EF89F54@gmail.com> I apologize in advance for sending a duplicate to the wrong list. My email client mangled the address. I hope I have the proper list now. Hello, I have developed a library based on Qt that handles sf2 (soundfont) libraries. It is moderately well developed at this point, so I would like to introduce it to the community in the proper way. I currently call it sflib. It has had no public exposure, but my personal testing has been as follows: The soundfont 2.0 specification is a freely available specification which can be downloaded here: http://freepats.zenvoid.org/sf2/sfspec24.pdf sf2 files are files which contain sound samples, most usually in wav format. They may contain anywhere from 1 to 100’s of different samples for 1 to 100’s of different kinds of instruments. A large variety of sf2 files are available for free on the Internet, and can be downloaded and played with free software (e.g. linuxsamplesr, synthfont, fluidsynth). This library will allow you to access the individual samples within an sf2 library containing multiple samples and repackage them to your liking. It uses Qt containers (QByteArray, QString, QMap, etc.) for information exchange between the host application and the sf2 package. This makes querying and unpacking/repacking a very trivial experience for anyone familiar with Qt. I have tested it with my personal library of sf2 files which, once parsed out, produced a collection of about 6300 individual sf2 files flawlessly. My current implementation has been tested with the latest Qt5 build. I would eventually like to develop the library to the point of delivering data live to a host synthesizer. Development has not been completed to this point yet. I have read over the information at https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt . While I feel the library is now functionally at a beta stage, it may certainly require some restructuring in order to assimilate appropriately with the current Qt directory architecture. Please advise me as to the proper way to allow me to present the code for review and advisement. Thank you, Michael Jordan -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert.astals at canonical.com Tue Aug 2 09:11:17 2016 From: albert.astals at canonical.com (Albert Astals Cid) Date: Tue, 2 Aug 2016 09:11:17 +0200 Subject: [Development] Image and PreserveAspectCrop In-Reply-To: References: Message-ID: Ping anyone? On Mon, Jul 18, 2016 at 10:24 AM, Albert Astals Cid wrote: > There is a problem when trying to optimally[*] show an Image with > PreserveAspectCrop fillMode. > [*]optimally => as best looking as possible while using as litte > memory as possible > > You can see that problem in the screenshot at http://i.imgur.com/LSSlFEB.png > that corresponds with the code at http://paste.ubuntu.com/19480453/ > > As you can see when displaying a landscape (width > height) image in a > square Image Item the optimal way > is to set the source size height only, but if the image is portrait > (height > width) then the optimal way > is to set the source size width only. > > The requirement my program has is to have the best rendering quality > and memory usage for Image Items using PreserveAspectCrop. > Image sources are totally arbitrary, they can be from disk, from the > internet or even from QQuickImageProviders > (since we are plugin based and plugins can bring their own QQuickImageProvider) > > This can be fixed in several ways. > > Workaround A > ********** > Changing the Image Item source size comparing the aspect ratio of the > image file with the one Image Item. > > You can see an implementation of that workaround at > http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/plugins/Dash/CroppedImageMinimumSourceSize.qml > > The problem with this workaround is that half of the times you end up > loading the image a second time. > This means extra CPU and potentially network usage. > > > > Workaround B > ********** > Implementing your own image provider that does compare the aspect > ratios before loading the image. > > You can see a partial implementation of this workaround at > https://code.launchpad.net/~aacid/unity8/croppedImageMinimumSourceSizeProvider/+merge/300176 > > There are two problems with this workaround: > * You end up implementing quite a bit of duplicated functionality > from qquickpixmapcache.cpp > * For the chained image providers (i.e. the original source was an > image provider url) you > still have to query the image provider twice half of the times > > > > Solution > ******** > Implementing the change in QtQuick internals so that when > PreserveAspectCrop fillMode is used > together with a sourceSize that has both width and height it does > return the optimal image > > You can see a work in progress implementation of this solution at > https://codereview.qt-project.org/#/c/165299/ > And how the previews could would look at > http://i.imgur.com/NRoXNzy.png (notice how the last column now is good > in both cases) > > There are two issues with this solution: > * It's a small behaviour change (but in my opinion for the better) > * Needs new api for the QQuickImageProvider to be able to implement > it, so we either need the proposed > QQuickImageProviderV2 or with a new "bool > shouldPreserveAspectRatioCrop(url, requestSize)" getter in the > existing QQuickImageProvider API > > > > All in all I think the solution i propose for QtQuick is acceptable > but i would like some agreeing that is fine adding new API before > finishing the patch. From gunnar at sletta.org Tue Aug 2 13:56:03 2016 From: gunnar at sletta.org (Gunnar Sletta) Date: Tue, 2 Aug 2016 13:56:03 +0200 Subject: [Development] Image and PreserveAspectCrop In-Reply-To: References: Message-ID: <8A63C998-7899-4013-B1BB-B4B6CEBD8997@sletta.org> Hi, I think the most sensible solution is to handle this inside the image provder. When I've seen this problem previously, it has was solved using a custom image provider for local files, but as you say, when the resources are scattered across the local and network alike, then you want the default internals to handle it correctly. So I agree with you that "Solution" is the way forward, rather than A or B :) I suspect the behavioural change won't be that big a deal, as it will in fact show up only as a slightly sharper image. A bit unfortunate that we have to add a V2 version of the image provider, though. Would be nice if we could extend what is already there somehow. However you end up solving it, it needs to be a bit more flexible than what you do in the proposed patch, as you also have to cover PreserveAspectFit. Perhaps using some flags as the last parameter there instead of a bool so we keep it open to add other states later on without having to introduce a new class. cheers, Gunnar > On 02 Aug 2016, at 09:11, Albert Astals Cid wrote: > > Ping anyone? > > On Mon, Jul 18, 2016 at 10:24 AM, Albert Astals Cid > wrote: >> There is a problem when trying to optimally[*] show an Image with >> PreserveAspectCrop fillMode. >> [*]optimally => as best looking as possible while using as litte >> memory as possible >> >> You can see that problem in the screenshot at http://i.imgur.com/LSSlFEB.png >> that corresponds with the code at http://paste.ubuntu.com/19480453/ >> >> As you can see when displaying a landscape (width > height) image in a >> square Image Item the optimal way >> is to set the source size height only, but if the image is portrait >> (height > width) then the optimal way >> is to set the source size width only. >> >> The requirement my program has is to have the best rendering quality >> and memory usage for Image Items using PreserveAspectCrop. >> Image sources are totally arbitrary, they can be from disk, from the >> internet or even from QQuickImageProviders >> (since we are plugin based and plugins can bring their own QQuickImageProvider) >> >> This can be fixed in several ways. >> >> Workaround A >> ********** >> Changing the Image Item source size comparing the aspect ratio of the >> image file with the one Image Item. >> >> You can see an implementation of that workaround at >> http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/plugins/Dash/CroppedImageMinimumSourceSize.qml >> >> The problem with this workaround is that half of the times you end up >> loading the image a second time. >> This means extra CPU and potentially network usage. >> >> >> >> Workaround B >> ********** >> Implementing your own image provider that does compare the aspect >> ratios before loading the image. >> >> You can see a partial implementation of this workaround at >> https://code.launchpad.net/~aacid/unity8/croppedImageMinimumSourceSizeProvider/+merge/300176 >> >> There are two problems with this workaround: >> * You end up implementing quite a bit of duplicated functionality >> from qquickpixmapcache.cpp >> * For the chained image providers (i.e. the original source was an >> image provider url) you >> still have to query the image provider twice half of the times >> >> >> >> Solution >> ******** >> Implementing the change in QtQuick internals so that when >> PreserveAspectCrop fillMode is used >> together with a sourceSize that has both width and height it does >> return the optimal image >> >> You can see a work in progress implementation of this solution at >> https://codereview.qt-project.org/#/c/165299/ >> And how the previews could would look at >> http://i.imgur.com/NRoXNzy.png (notice how the last column now is good >> in both cases) >> >> There are two issues with this solution: >> * It's a small behaviour change (but in my opinion for the better) >> * Needs new api for the QQuickImageProvider to be able to implement >> it, so we either need the proposed >> QQuickImageProviderV2 or with a new "bool >> shouldPreserveAspectRatioCrop(url, requestSize)" getter in the >> existing QQuickImageProvider API >> >> >> >> All in all I think the solution i propose for QtQuick is acceptable >> but i would like some agreeing that is fine adding new API before >> finishing the patch. From enmarantispam at gmail.com Tue Aug 2 14:22:45 2016 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 2 Aug 2016 15:22:45 +0300 Subject: [Development] Behavior of mapToGlobal function when application is not the one active. Message-ID: A little bit of context: I am trying to organize getting interface positions/sizes out of an application via RPC interface. To do this I have inserted grpc server code into a GUI app and grpc client into another, testing application. Essentially, when the client app sends a signal, the main app should do button->mapToGlobal(QPoint(0,0,)) and return this via RPC. What happens in fact, is that unless I specifically press the "get coordinates" button on the main app, the coordinates I get are completely wrong. Scenario 1: mapToGlobal at the button press of the same app: correct coordinates Scenario 2: mapToGlobal at rpc signal from client app: completely wrong coordinates AND size, coordinates for buttons in the same layour are the same. What can this be? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo at vikingsoft.eu Tue Aug 2 15:24:52 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Tue, 2 Aug 2016 15:24:52 +0200 Subject: [Development] Behavior of mapToGlobal function when application is not the one active. In-Reply-To: References: Message-ID: <5f3db269-8237-daba-57d1-12a5a1d490a0@vikingsoft.eu> Den 02-08-2016 kl. 14:22 skrev NIkolai Marchenko: > A little bit of context: I am trying to organize getting interface > positions/sizes out of an application via RPC interface. To do this I > have inserted grpc server code into a GUI app and grpc client into > another, testing application. > > Essentially, when the client app sends a signal, the main app should do > button->mapToGlobal(QPoint(0,0,)) and return this via RPC. > > What happens in fact, is that unless I specifically press the "get > coordinates" button on the main app, the coordinates I get are > completely wrong. > > Scenario 1: mapToGlobal at the button press of the same app: correct > coordinates > Scenario 2: mapToGlobal at rpc signal from client app: completely wrong > coordinates AND size, coordinates for buttons in the same layour are > the same. > > What can this be? Please send this to the interest mailing list instead. This is not the appropriate list. And when you resent it, you have to send some code as well because the but will be in your code and we can't help with that unless we see it. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From Shawn.Rutledge at qt.io Tue Aug 2 17:47:35 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 2 Aug 2016 15:47:35 +0000 Subject: [Development] Image and PreserveAspectCrop In-Reply-To: <8A63C998-7899-4013-B1BB-B4B6CEBD8997@sletta.org> References: <8A63C998-7899-4013-B1BB-B4B6CEBD8997@sletta.org> Message-ID: > On 02 Aug 2016, at 13:56, Gunnar Sletta wrote: > > A bit unfortunate that we have to add a V2 version of the image provider, though. Would be nice if we could extend what is already there somehow. However you end up solving it, it needs to be a bit more flexible than what you do in the proposed patch, as you also have to cover PreserveAspectFit. Perhaps using some flags as the last parameter there instead of a bool so we keep it open to add other states later on without having to introduce a new class. I wanted to introduce PDF as an image format soon, but don’t have time to finish up the loose ends right now. Handling scaling is of course critical, because you don’t want to re-render pages too often, but you need to re-render them when the scale changes too much. I found a few things to be dissatisfied about, both in how image plugins work, in how QtQuick handles scalable images, in how it handles frames of multi-page images, etc.; so I think changes will be needed in various places, but it needs more thought and coordination some time past 5.8. My point is that if API changes become necessary, we can find other itches to scratch when we do that. ;-) From albert.astals at canonical.com Tue Aug 2 18:03:04 2016 From: albert.astals at canonical.com (Albert Astals Cid) Date: Tue, 2 Aug 2016 18:03:04 +0200 Subject: [Development] Image and PreserveAspectCrop In-Reply-To: <8A63C998-7899-4013-B1BB-B4B6CEBD8997@sletta.org> References: <8A63C998-7899-4013-B1BB-B4B6CEBD8997@sletta.org> Message-ID: On Tue, Aug 2, 2016 at 1:56 PM, Gunnar Sletta wrote: > Hi, > > I think the most sensible solution is to handle this inside the image provder. When I've seen this problem previously, it has was solved using a custom image provider for local files, but as you say, when the resources are scattered across the local and network alike, then you want the default internals to handle it correctly. > > So I agree with you that "Solution" is the way forward, rather than A or B :) > > I suspect the behavioural change won't be that big a deal, as it will in fact show up only as a slightly sharper image. > > A bit unfortunate that we have to add a V2 version of the image provider, though. Would be nice if we could extend what is already there somehow. However you end up solving it, it needs to be a bit more flexible than what you do in the > proposed patch, as you also have to cover PreserveAspectFit. I don't understand what needs to be done regarding PreserveAspectFit. Isn't that the default mode of operation? > Perhaps using some flags as the last parameter there instead of a bool so we keep it open to add other states later on without having to introduce a new class. > > cheers, > Gunnar > > >> On 02 Aug 2016, at 09:11, Albert Astals Cid wrote: >> >> Ping anyone? >> >> On Mon, Jul 18, 2016 at 10:24 AM, Albert Astals Cid >> wrote: >>> There is a problem when trying to optimally[*] show an Image with >>> PreserveAspectCrop fillMode. >>> [*]optimally => as best looking as possible while using as litte >>> memory as possible >>> >>> You can see that problem in the screenshot at http://i.imgur.com/LSSlFEB.png >>> that corresponds with the code at http://paste.ubuntu.com/19480453/ >>> >>> As you can see when displaying a landscape (width > height) image in a >>> square Image Item the optimal way >>> is to set the source size height only, but if the image is portrait >>> (height > width) then the optimal way >>> is to set the source size width only. >>> >>> The requirement my program has is to have the best rendering quality >>> and memory usage for Image Items using PreserveAspectCrop. >>> Image sources are totally arbitrary, they can be from disk, from the >>> internet or even from QQuickImageProviders >>> (since we are plugin based and plugins can bring their own QQuickImageProvider) >>> >>> This can be fixed in several ways. >>> >>> Workaround A >>> ********** >>> Changing the Image Item source size comparing the aspect ratio of the >>> image file with the one Image Item. >>> >>> You can see an implementation of that workaround at >>> http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/plugins/Dash/CroppedImageMinimumSourceSize.qml >>> >>> The problem with this workaround is that half of the times you end up >>> loading the image a second time. >>> This means extra CPU and potentially network usage. >>> >>> >>> >>> Workaround B >>> ********** >>> Implementing your own image provider that does compare the aspect >>> ratios before loading the image. >>> >>> You can see a partial implementation of this workaround at >>> https://code.launchpad.net/~aacid/unity8/croppedImageMinimumSourceSizeProvider/+merge/300176 >>> >>> There are two problems with this workaround: >>> * You end up implementing quite a bit of duplicated functionality >>> from qquickpixmapcache.cpp >>> * For the chained image providers (i.e. the original source was an >>> image provider url) you >>> still have to query the image provider twice half of the times >>> >>> >>> >>> Solution >>> ******** >>> Implementing the change in QtQuick internals so that when >>> PreserveAspectCrop fillMode is used >>> together with a sourceSize that has both width and height it does >>> return the optimal image >>> >>> You can see a work in progress implementation of this solution at >>> https://codereview.qt-project.org/#/c/165299/ >>> And how the previews could would look at >>> http://i.imgur.com/NRoXNzy.png (notice how the last column now is good >>> in both cases) >>> >>> There are two issues with this solution: >>> * It's a small behaviour change (but in my opinion for the better) >>> * Needs new api for the QQuickImageProvider to be able to implement >>> it, so we either need the proposed >>> QQuickImageProviderV2 or with a new "bool >>> shouldPreserveAspectRatioCrop(url, requestSize)" getter in the >>> existing QQuickImageProvider API >>> >>> >>> >>> All in all I think the solution i propose for QtQuick is acceptable >>> but i would like some agreeing that is fine adding new API before >>> finishing the patch. > From thiago.macieira at intel.com Tue Aug 2 18:32:15 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 Aug 2016 09:32:15 -0700 Subject: [Development] QtCon rooms for QCS In-Reply-To: References: <8642194.NpyjyqBHBu@tjmaciei-mobl1> Message-ID: <1901223.U8SBlmx97Z@tjmaciei-mobl1> On sexta-feira, 29 de julho de 2016 09:57:11 PDT Morten Sorvig wrote: > Is there a sharp division between QtCon and QCS? > > I was told I should register my QCS topics for QtCon, which I have. If > others have done the same then rooms may already have been reserved. (An > extra free room for the unconference could not hurt though) Ok, so how to reserve a room now? I think we need a QtCore session, we need to discuss the botched 5.6.1-1 release, and I suggest we also need to discuss use of the C++11 standard library (there's a commit going in that makes a mandatory feature). Morten: is your session a traditional presentation + Q&A? Or is it a QCS working session? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Gabriel.deDietrich at qt.io Tue Aug 2 19:50:24 2016 From: Gabriel.deDietrich at qt.io (Gabriel de Dietrich) Date: Tue, 2 Aug 2016 17:50:24 +0000 Subject: [Development] QtCon rooms for QCS In-Reply-To: <1901223.U8SBlmx97Z@tjmaciei-mobl1> References: <8642194.NpyjyqBHBu@tjmaciei-mobl1> <1901223.U8SBlmx97Z@tjmaciei-mobl1> Message-ID: Hi Thiago, I’m replying on Morten’s behalf since that session was initially suggested by me and Jake. It’s going to be a QtCS session. We need to discuss some recurring issues related to rendering on Mac. Other related topics may arise, but no formal presentation AFAIK. Best regards, Dr. Gabriel de Dietrich Senior Software Developer The Qt Company — www.qt.io > On Aug 2, 2016, at 9:32 AM, Thiago Macieira wrote: > > On sexta-feira, 29 de julho de 2016 09:57:11 PDT Morten Sorvig wrote: >> Is there a sharp division between QtCon and QCS? >> >> I was told I should register my QCS topics for QtCon, which I have. If >> others have done the same then rooms may already have been reserved. (An >> extra free room for the unconference could not hurt though) > > Ok, so how to reserve a room now? I think we need a QtCore session, we need to > discuss the botched 5.6.1-1 release, and I suggest we also need to discuss use > of the C++11 standard library (there's a commit going in that makes > a mandatory feature). > > Morten: is your session a traditional presentation + Q&A? Or is it a QCS > working session? > > -- > 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 Aug 2 22:50:21 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 Aug 2016 13:50:21 -0700 Subject: [Development] QtCon rooms for QCS In-Reply-To: References: <8642194.NpyjyqBHBu@tjmaciei-mobl1> <1901223.U8SBlmx97Z@tjmaciei-mobl1> Message-ID: <2604825.ZszKcBHt3n@tjmaciei-mobl1> On terça-feira, 2 de agosto de 2016 17:50:24 PDT Gabriel de Dietrich wrote: > Hi Thiago, > > I’m replying on Morten’s behalf since that session was initially suggested > by me and Jake. > It’s going to be a QtCS session. We need to discuss some recurring issues > related to rendering on Mac. Other related topics may arise, but no formal > presentation AFAIK. Thanks. I still need to know how to add more topics. Previously, we had a wiki so we could edit. Tero, can you help? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From dangelog at gmail.com Wed Aug 3 01:05:00 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Wed, 3 Aug 2016 01:05:00 +0200 Subject: [Development] Programs crashing left and right in the CI In-Reply-To: <5799BD19.5010600@qt.io> References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1> <5951295.MVm6SEVxWd@42> <10723215.7zoGWthJmd@tjmaciei-mobl1> <5799BD19.5010600@qt.io> Message-ID: On Thu, Jul 28, 2016 at 10:06 AM, Michal Klocek wrote: > > It seems to happen in different modules (here qttools and qtlocation) > and in different branches (here dev and 5.6), but on mac/clang and during > moc compilation. Now I've got an ICE: http://testresults.qt.io/logs/qt/qtbase/920ef98db1070f97042845877e2fe61caa27e241/OSXOSX_10_10x86_64IOSIOS_ANYmultiClangqtci-osx-10.10-x86_64DebugAndRelease_DisableTests_Static/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.txt.gz -- Giuseppe D'Angelo From thiago.macieira at intel.com Wed Aug 3 02:17:59 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 Aug 2016 17:17:59 -0700 Subject: [Development] Programs crashing left and right in the CI In-Reply-To: References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1> <5799BD19.5010600@qt.io> Message-ID: <1924661.xlFp80US0Z@tjmaciei-mobl1> On quarta-feira, 3 de agosto de 2016 01:05:00 PDT Giuseppe D'Angelo wrote: > On Thu, Jul 28, 2016 at 10:06 AM, Michal Klocek wrote: > > It seems to happen in different modules (here qttools and qtlocation) > > and in different branches (here dev and 5.6), but on mac/clang and during > > moc compilation. > > Now I've got an ICE: > > http://testresults.qt.io/logs/qt/qtbase/920ef98db1070f97042845877e2fe61caa27 > e241/OSXOSX_10_10x86_64IOSIOS_ANYmultiClangqtci-osx-10.10-x86_64DebugAndRele > ase_DisableTests_Static/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog.tx > t.gz Ok, this is the first time that the compiler itself has crashed. Can you retry the integration with the exact same commits in the same order? If it crashes again compiling .obj/debug-iphoneos/qjsonparser.o, it's a compiler bug. If it passes, then we can't exclude compiler bug, but it's more likely to be a HW fault. Were there any changes to any files that could be used as source to qjsonparser.cpp (qmake, mkspec or other QtCore changes)? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Aug 3 02:38:45 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 02 Aug 2016 17:38:45 -0700 Subject: [Development] Programs crashing left and right in the CI In-Reply-To: <1924661.xlFp80US0Z@tjmaciei-mobl1> References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1> <1924661.xlFp80US0Z@tjmaciei-mobl1> Message-ID: <8289559.vUmOFzGLkc@tjmaciei-mobl1> On terça-feira, 2 de agosto de 2016 17:17:59 PDT Thiago Macieira wrote: > Ok, this is the first time that the compiler itself has crashed. Can you > retry the integration with the exact same commits in the same order? If it > crashes again compiling .obj/debug-iphoneos/qjsonparser.o, it's a compiler > bug. If it passes, then we can't exclude compiler bug, but it's more likely > to be a HW fault. > > Were there any changes to any files that could be used as source to > qjsonparser.cpp (qmake, mkspec or other QtCore changes)? Answering myself: yes, you modified qobject headers. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From xbenlau at gmail.com Wed Aug 3 05:26:17 2016 From: xbenlau at gmail.com (Ben Lau) Date: Wed, 3 Aug 2016 11:26:17 +0800 Subject: [Development] Image and PreserveAspectCrop In-Reply-To: <8A63C998-7899-4013-B1BB-B4B6CEBD8997@sletta.org> References: <8A63C998-7899-4013-B1BB-B4B6CEBD8997@sletta.org> Message-ID: On 2 August 2016 at 19:56, Gunnar Sletta wrote: > Hi, > > I think the most sensible solution is to handle this inside the image > provder. When I've seen this problem previously, it has was solved using a > custom image provider for local files, but as you say, when the resources > are scattered across the local and network alike, then you want the default > internals to handle it correctly. > > So I agree with you that "Solution" is the way forward, rather than A or B > :) > > I suspect the behavioural change won't be that big a deal, as it will in > fact show up only as a slightly sharper image. > > A bit unfortunate that we have to add a V2 version of the image provider, > though. Would be nice if we could extend what is already there somehow. > However you end up solving it, it needs to be a bit more flexible than what > you do in the proposed patch, as you also have to cover PreserveAspectFit. > Perhaps using some flags as the last parameter there instead of a bool so > we keep it open to add other states later on without having to introduce a > new class. > > cheers, > Gunnar > > Beside a V2 image provider, how about having QImage support in Image item directly? I think that would solve a lots of problem. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar at sletta.org Wed Aug 3 07:28:51 2016 From: gunnar at sletta.org (Gunnar Sletta) Date: Wed, 3 Aug 2016 07:28:51 +0200 Subject: [Development] Image and PreserveAspectCrop In-Reply-To: References: <8A63C998-7899-4013-B1BB-B4B6CEBD8997@sletta.org> Message-ID: <455FC6CE-589F-4495-A163-BF060A51BC12@sletta.org> > On 02 Aug 2016, at 18:03, Albert Astals Cid wrote: > > On Tue, Aug 2, 2016 at 1:56 PM, Gunnar Sletta wrote: >> Hi, >> >> I think the most sensible solution is to handle this inside the image provder. When I've seen this problem previously, it has was solved using a custom image provider for local files, but as you say, when the resources are scattered across the local and network alike, then you want the default internals to handle it correctly. >> >> So I agree with you that "Solution" is the way forward, rather than A or B :) >> >> I suspect the behavioural change won't be that big a deal, as it will in fact show up only as a slightly sharper image. >> >> A bit unfortunate that we have to add a V2 version of the image provider, though. Would be nice if we could extend what is already there somehow. However you end up solving it, it needs to be a bit more flexible than what you do in the > proposed patch, as you also have to cover PreserveAspectFit. > > I don't understand what needs to be done regarding PreserveAspectFit. > Isn't that the default mode of operation? > Nope, the default fill mode is Image.Stretch. PreserveAspectFill is similar to PreserveAspectCrop. It uses a different boundingBox to figure out the scale factor and doesn't crop, but because it scales aspect-ratio aware, it needs the same thing as PreserveAspectCrop. While we're on the subject. You do know about Image::mipmap, right? It will give you visually optimal results when displaying a larger image into a smaller area. It does come a slight memory overhead cost though, and the renderer won't be able to batch it, so it works best for single images, not for images in a grid or list. cheers, Gunnar >> Perhaps using some flags as the last parameter there instead of a bool so we keep it open to add other states later on without having to introduce a new class. >> >> cheers, >> Gunnar >> >> >>> On 02 Aug 2016, at 09:11, Albert Astals Cid wrote: >>> >>> Ping anyone? >>> >>> On Mon, Jul 18, 2016 at 10:24 AM, Albert Astals Cid >>> wrote: >>>> There is a problem when trying to optimally[*] show an Image with >>>> PreserveAspectCrop fillMode. >>>> [*]optimally => as best looking as possible while using as litte >>>> memory as possible >>>> >>>> You can see that problem in the screenshot at http://i.imgur.com/LSSlFEB.png >>>> that corresponds with the code at http://paste.ubuntu.com/19480453/ >>>> >>>> As you can see when displaying a landscape (width > height) image in a >>>> square Image Item the optimal way >>>> is to set the source size height only, but if the image is portrait >>>> (height > width) then the optimal way >>>> is to set the source size width only. >>>> >>>> The requirement my program has is to have the best rendering quality >>>> and memory usage for Image Items using PreserveAspectCrop. >>>> Image sources are totally arbitrary, they can be from disk, from the >>>> internet or even from QQuickImageProviders >>>> (since we are plugin based and plugins can bring their own QQuickImageProvider) >>>> >>>> This can be fixed in several ways. >>>> >>>> Workaround A >>>> ********** >>>> Changing the Image Item source size comparing the aspect ratio of the >>>> image file with the one Image Item. >>>> >>>> You can see an implementation of that workaround at >>>> http://bazaar.launchpad.net/~unity-team/unity8/trunk/view/head:/plugins/Dash/CroppedImageMinimumSourceSize.qml >>>> >>>> The problem with this workaround is that half of the times you end up >>>> loading the image a second time. >>>> This means extra CPU and potentially network usage. >>>> >>>> >>>> >>>> Workaround B >>>> ********** >>>> Implementing your own image provider that does compare the aspect >>>> ratios before loading the image. >>>> >>>> You can see a partial implementation of this workaround at >>>> https://code.launchpad.net/~aacid/unity8/croppedImageMinimumSourceSizeProvider/+merge/300176 >>>> >>>> There are two problems with this workaround: >>>> * You end up implementing quite a bit of duplicated functionality >>>> from qquickpixmapcache.cpp >>>> * For the chained image providers (i.e. the original source was an >>>> image provider url) you >>>> still have to query the image provider twice half of the times >>>> >>>> >>>> >>>> Solution >>>> ******** >>>> Implementing the change in QtQuick internals so that when >>>> PreserveAspectCrop fillMode is used >>>> together with a sourceSize that has both width and height it does >>>> return the optimal image >>>> >>>> You can see a work in progress implementation of this solution at >>>> https://codereview.qt-project.org/#/c/165299/ >>>> And how the previews could would look at >>>> http://i.imgur.com/NRoXNzy.png (notice how the last column now is good >>>> in both cases) >>>> >>>> There are two issues with this solution: >>>> * It's a small behaviour change (but in my opinion for the better) >>>> * Needs new api for the QQuickImageProvider to be able to implement >>>> it, so we either need the proposed >>>> QQuickImageProviderV2 or with a new "bool >>>> shouldPreserveAspectRatioCrop(url, requestSize)" getter in the >>>> existing QQuickImageProvider API >>>> >>>> >>>> >>>> All in all I think the solution i propose for QtQuick is acceptable >>>> but i would like some agreeing that is fine adding new API before >>>> finishing the patch. >> From jedrzej.nowacki at qt.io Wed Aug 3 09:05:24 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Wed, 3 Aug 2016 09:05:24 +0200 Subject: [Development] Programs crashing left and right in the CI In-Reply-To: <1924661.xlFp80US0Z@tjmaciei-mobl1> References: <2608077.ZIMrPSxkf7@tjmaciei-mobl1> <1924661.xlFp80US0Z@tjmaciei-mobl1> Message-ID: <70012013.mOoB5E5tTz@42> On Tuesday 02 of August 2016 17:17:59 Thiago Macieira wrote: > On quarta-feira, 3 de agosto de 2016 01:05:00 PDT Giuseppe D'Angelo wrote: > > On Thu, Jul 28, 2016 at 10:06 AM, Michal Klocek wrote: > > > It seems to happen in different modules (here qttools and qtlocation) > > > and in different branches (here dev and 5.6), but on mac/clang and > > > during > > > moc compilation. > > > > Now I've got an ICE: > > > > http://testresults.qt.io/logs/qt/qtbase/920ef98db1070f97042845877e2fe61caa > > 27 > > e241/OSXOSX_10_10x86_64IOSIOS_ANYmultiClangqtci-osx-10.10-x86_64DebugAndR > > ele > > ase_DisableTests_Static/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/buildlog > > .tx t.gz > > Ok, this is the first time that the compiler itself has crashed. Can you > retry the integration with the exact same commits in the same order? If it > crashes again compiling .obj/debug-iphoneos/qjsonparser.o, it's a compiler > bug. If it passes, then we can't exclude compiler bug, but it's more likely > to be a HW fault. > > Were there any changes to any files that could be used as source to > qjsonparser.cpp (qmake, mkspec or other QtCore changes)? I asked to check the node. Cheers, Jędrek From tero.kojo at qt.io Wed Aug 3 10:36:01 2016 From: tero.kojo at qt.io (Tero Kojo) Date: Wed, 3 Aug 2016 08:36:01 +0000 Subject: [Development] QtCon rooms for QCS In-Reply-To: <2604825.ZszKcBHt3n@tjmaciei-mobl1> References: <8642194.NpyjyqBHBu@tjmaciei-mobl1> <1901223.U8SBlmx97Z@tjmaciei-mobl1> <2604825.ZszKcBHt3n@tjmaciei-mobl1> Message-ID: Hi, Yes, there is a reservation of room space for topics that come up in for Qt contributors. I need to figure out the best (simplest) process for how we manage that space. For now mailing me directly is probably the best way, as I need to add the topics to the event management system. Tero > -----Original Message----- > From: Thiago Macieira [mailto:thiago.macieira at intel.com] > Sent: tiistaina 2. elokuuta 2016 23.50 > To: development at qt-project.org; akademy-team team at kde.org> > Cc: Tero Kojo > Subject: Re: [Development] QtCon rooms for QCS > > On terça-feira, 2 de agosto de 2016 17:50:24 PDT Gabriel de Dietrich wrote: > > Hi Thiago, > > > > I’m replying on Morten’s behalf since that session was initially > > suggested by me and Jake. > > > It’s going to be a QtCS session. We need to discuss some recurring > > issues related to rendering on Mac. Other related topics may arise, > > but no formal presentation AFAIK. > > Thanks. > > I still need to know how to add more topics. Previously, we had a wiki so we > could edit. > > Tero, can you help? > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center From Kai.Koehne at qt.io Wed Aug 3 10:52:16 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 3 Aug 2016 08:52:16 +0000 Subject: [Development] QtCon rooms for QCS In-Reply-To: References: <8642194.NpyjyqBHBu@tjmaciei-mobl1> <1901223.U8SBlmx97Z@tjmaciei-mobl1> <2604825.ZszKcBHt3n@tjmaciei-mobl1> Message-ID: I've submitted 4 'workshop' sessions, mostly as placeholders. I wouldn't mind replacing them with more urgent / interesting topics though, if there are ones. C++11 library usage would definitely be one I'm interested in myself :) Also, the agenda overview should clearly distinguish between presentations and workshops ... Regards Kai > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Tero Kojo > Sent: Wednesday, August 03, 2016 10:36 AM > To: Thiago Macieira ; development at qt- > project.org; akademy-team > Subject: Re: [Development] QtCon rooms for QCS > > Hi, > > Yes, there is a reservation of room space for topics that come up in for Qt > contributors. > > I need to figure out the best (simplest) process for how we manage that > space. For now mailing me directly is probably the best way, as I need to add > the topics to the event management system. > > Tero > > > -----Original Message----- > > From: Thiago Macieira [mailto:thiago.macieira at intel.com] > > Sent: tiistaina 2. elokuuta 2016 23.50 > > To: development at qt-project.org; akademy-team team at kde.org> > > Cc: Tero Kojo > > Subject: Re: [Development] QtCon rooms for QCS > > > > On terça-feira, 2 de agosto de 2016 17:50:24 PDT Gabriel de Dietrich wrote: > > > Hi Thiago, > > > > > > I’m replying on Morten’s behalf since that session was initially > > > suggested by me and Jake. > > > > > It’s going to be a QtCS session. We need to discuss some recurring > > > issues related to rendering on Mac. Other related topics may arise, > > > but no formal presentation AFAIK. > > > > Thanks. > > > > I still need to know how to add more topics. Previously, we had a wiki > > so we could edit. > > > > Tero, can you help? > > -- > > 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 Julius.Bullinger at asctec.de Thu Aug 4 09:49:59 2016 From: Julius.Bullinger at asctec.de (Julius Bullinger) Date: Thu, 4 Aug 2016 07:49:59 +0000 Subject: [Development] Building Qt with dynamic OpenGL on MinGW broken Message-ID: Hello, because of QTBUG-52487, there's currently no straight-forward way to build an OpenGL-dynamic QT 5.7 with MinGW on Windows. There's a patch attached to the bug report, but it's not on Gerrit (and the author hasn't responded to the request to push it to Gerrit). May I propose that somebody else takes the patch and pushes it to Gerrit for a proper review? Thanks and best regards, Julius From Oliver.Wolff at qt.io Thu Aug 4 10:33:42 2016 From: Oliver.Wolff at qt.io (Oliver Wolff) Date: Thu, 4 Aug 2016 10:33:42 +0200 Subject: [Development] Building Qt with dynamic OpenGL on MinGW broken In-Reply-To: References: Message-ID: <672914f9-c8c9-241c-6b2d-bddfbddfe6c2@qt.io> Hi, On 04/08/2016 09:49, Julius Bullinger wrote: > Hello, > > because of QTBUG-52487, there's currently no straight-forward way to build an OpenGL-dynamic QT 5.7 with MinGW on Windows. There's a patch attached to the bug report, but it's not on Gerrit (and the author hasn't responded to the request to push it to Gerrit). for me the straightforward way for that configuration is to install the DirectX SDK and use that. With that installed the build just works fine here. Are there any issues with that? > > May I propose that somebody else takes the patch and pushes it to Gerrit for a proper review? I think that there is more to that than the patch attached to the bug report (as the reporter says, that the PATH variable has to be adapted). So it's probably not just taking the patch and pushing it to gerrit. > > Thanks and best regards, > Julius Best regards, Olli > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Paul.Tvete at qt.io Thu Aug 4 12:22:58 2016 From: Paul.Tvete at qt.io (Paul Tvete) Date: Thu, 4 Aug 2016 10:22:58 +0000 Subject: [Development] Nominating Johan Helsing for Approver status Message-ID: Hi all, I'd like to nominate Johan Helsing for Approver status. He joined The Qt Company half a year ago, and has been working full time on Qt since. Johan has been actively involved in making the QtWaylandCompositor module ready for Qt 5.8, as well as doing a major part of the bug fixes for Qt Wayland in 5.6 and 5.7. Here is his gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Johan+Helsing%22,n,z Johan's list of reviews can be found at: https://codereview.qt-project.org/#/q/reviewer:%22Johan+Helsing+%253Cjohan.helsing%2540theqtcompany.com%253E%22,p,003e6e7d0002807d Cheers, - Paul From Shawn.Rutledge at qt.io Thu Aug 4 12:27:47 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Thu, 4 Aug 2016 10:27:47 +0000 Subject: [Development] Nominating Johan Helsing for Approver status In-Reply-To: References: Message-ID: <4ABF96CC-DD58-4661-8621-F730577D6167@qt.io> +1 from me. He’s been doing good work. > On 04 Aug 2016, at 12:22, Paul Tvete wrote: > > Hi all, > > > I'd like to nominate Johan Helsing for Approver status. He joined The Qt Company half a year ago, and has been working full time on Qt since. Johan has been actively involved in making the QtWaylandCompositor module ready for Qt 5.8, as well as doing a major part of the bug fixes for Qt Wayland in 5.6 and 5.7. > > Here is his gerrit dashboard: > > https://codereview.qt-project.org/#/q/owner:%22Johan+Helsing%22,n,z > > Johan's list of reviews can be found at: > > https://codereview.qt-project.org/#/q/reviewer:%22Johan+Helsing+%253Cjohan.helsing%2540theqtcompany.com%253E%22,p,003e6e7d0002807d > > Cheers, > > - Paul > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From laszlo.agocs at qt.io Thu Aug 4 12:28:10 2016 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Thu, 4 Aug 2016 10:28:10 +0000 Subject: [Development] Nominating Johan Helsing for Approver status In-Reply-To: References: Message-ID: +1 Cheers, Laszlo ________________________________ From: Development on behalf of Paul Tvete Sent: Thursday, August 4, 2016 12:22:58 PM To: Qt development mailing list Subject: [Development] Nominating Johan Helsing for Approver status Hi all, I'd like to nominate Johan Helsing for Approver status. He joined The Qt Company half a year ago, and has been working full time on Qt since. Johan has been actively involved in making the QtWaylandCompositor module ready for Qt 5.8, as well as doing a major part of the bug fixes for Qt Wayland in 5.6 and 5.7. Here is his gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Johan+Helsing%22,n,z Johan's list of reviews can be found at: https://codereview.qt-project.org/#/q/reviewer:%22Johan+Helsing+%253Cjohan.helsing%2540theqtcompany.com%253E%22,p,003e6e7d0002807d Cheers, - Paul _______________________________________________ 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 timur.pocheptsov at qt.io Thu Aug 4 12:29:38 2016 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Thu, 4 Aug 2016 10:29:38 +0000 Subject: [Development] Nominating Johan Helsing for Approver status In-Reply-To: References: Message-ID: + 1 Best regards, Timur. ________________________________ From: Development on behalf of Paul Tvete Sent: Thursday, August 4, 2016 12:22:58 PM To: Qt development mailing list Subject: [Development] Nominating Johan Helsing for Approver status Hi all, I'd like to nominate Johan Helsing for Approver status. He joined The Qt Company half a year ago, and has been working full time on Qt since. Johan has been actively involved in making the QtWaylandCompositor module ready for Qt 5.8, as well as doing a major part of the bug fixes for Qt Wayland in 5.6 and 5.7. Here is his gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Johan+Helsing%22,n,z Johan's list of reviews can be found at: https://codereview.qt-project.org/#/q/reviewer:%22Johan+Helsing+%253Cjohan.helsing%2540theqtcompany.com%253E%22,p,003e6e7d0002807d Cheers, - Paul _______________________________________________ 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 Andy.Nichols at qt.io Thu Aug 4 12:30:17 2016 From: Andy.Nichols at qt.io (Andy Nichols) Date: Thu, 4 Aug 2016 10:30:17 +0000 Subject: [Development] Nominating Johan Helsing for Approver status In-Reply-To: References: Message-ID: <0E284A95-4F3E-43F1-A7FF-CCD41AEE93EC@qt.io> +1 from me. Johan has been putting a lot of effort into QtWayland and it would be great to have him as an approver. ~ Andy Nichols > On 04 Aug 2016, at 12:22, Paul Tvete wrote: > > Hi all, > > > I'd like to nominate Johan Helsing for Approver status. He joined The Qt Company half a year ago, and has been working full time on Qt since. Johan has been actively involved in making the QtWaylandCompositor module ready for Qt 5.8, as well as doing a major part of the bug fixes for Qt Wayland in 5.6 and 5.7. > > Here is his gerrit dashboard: > > https://codereview.qt-project.org/#/q/owner:%22Johan+Helsing%22,n,z > > Johan's list of reviews can be found at: > > https://codereview.qt-project.org/#/q/reviewer:%22Johan+Helsing+%253Cjohan.helsing%2540theqtcompany.com%253E%22,p,003e6e7d0002807d > > Cheers, > > - Paul > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From pierluigi.fiorini at gmail.com Thu Aug 4 12:29:51 2016 From: pierluigi.fiorini at gmail.com (Pier Luigi Fiorini) Date: Thu, 4 Aug 2016 12:29:51 +0200 Subject: [Development] Nominating Johan Helsing for Approver status In-Reply-To: References: Message-ID: 2016-08-04 12:22 GMT+02:00 Paul Tvete : > Hi all, > > > I'd like to nominate Johan Helsing for Approver status. He joined The Qt > Company half a year ago, and has been working full time on Qt since. Johan > has been actively involved in making the QtWaylandCompositor module ready > for Qt 5.8, as well as doing a major part of the bug fixes for Qt Wayland > in 5.6 and 5.7. > > Here is his gerrit dashboard: > > https://codereview.qt-project.org/#/q/owner:%22Johan+Helsing%22,n,z > > Johan's list of reviews can be found at: > > https://codereview.qt-project.org/#/q/reviewer:%22Johan+ > Helsing+%253Cjohan.helsing%2540theqtcompany.com%253E%22,p,003e6e7d0002807d > > Cheers, > > - Paul > +1 Cheers -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Thu Aug 4 13:50:03 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Thu, 4 Aug 2016 14:50:03 +0300 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 Message-ID: {quote} Hi all. I have some QML application, where just use QQuickView as QML container. This application uses Qt 5.7.x and running on Linux embedded board with the NVIDIA core (Toradex Apalis T30). But sometimes I got flickering in process of animation. A flickering represents in form of a "white" strips with full-screen width and 1/5-1/6 screen heigth. This flickers happens quickly and frequently (every ~20-60 seconds, randomly)... I have seen this "Avoiding graphics flicker in Qt / QML" [1] blog where are used QML with Qt 4.x, where were used this trics: {code} int main(int argc, char **argv) { ... view.setAttribute(Qt::WA_OpaquePaintEvent); view.setAttribute(Qt::WA_NoSystemBackground); view.viewport()->setAttribute(Qt::WA_OpaquePaintEvent); view.viewport()->setAttribute(Qt::WA_NoSystemBackground); ... } {code} But, in my case I have use Quick v2, with QQuickView instead of QDeclarativeView, which does not allowed to setup any attributes. So, my questions is: is there are any way to setup Qt::WA_OpaquePaintEvent and/or Qt::WA_NoSystemBackground in Quck2? Or, maybe is it possible to use another tricks? BR, Denis [1]https://blog.rburchell.com/2011/11/avoiding-graphics-flicker-in-qt-qml.html {quote} This flickering present on some HDMI displays... We currently have this flags: {code} ... view.setFlags(Qt::FramelessWindowHint | Qt::WindowStaysOnTopHint); ... {code} Maybe is it an reasons of flikering? Has someone any ideas? BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Thu Aug 4 15:10:27 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Thu, 4 Aug 2016 16:10:27 +0300 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: <1470311864.417285.685842217.63CDB906@webmail.messagingengine.com> References: <1470311864.417285.685842217.63CDB906@webmail.messagingengine.com> Message-ID: Hi Robin, > Repeating my last answer... > http://lists.qt-project.org/pipermail/development/2016-July/026736.html I'm sorry, but I did not receive (did not see) your last answer. > I'm going to guess you're using eglfs or something like that Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are used NVIDIA's drivers. Seems, the flickering is when are used: export QT_QPA_EGLFS_FORCE888=1 ENV variable... (I need this variable to smooth the Image's gradients... even X11 started with 24-bit depth). PS: But, I'm not sure about QT_QPA_EGLFS_FORCE888... :( > Using an overlay to debug item positions (QSG_VISUALIZE=overdraw) could be handy for trying to rule this out, as if it is specific to the application, Ok, many thanks, I will try it. 2016-08-04 14:57 GMT+03:00 Robin Burchell : > Repeating my last answer... > > http://lists.qt-project.org/pipermail/development/2016-July/026736.html > > On Thu, Aug 4, 2016, at 01:50 PM, Denis Shienkov wrote: > > {quote} > > > > Hi all. > > > > I have some QML application, where just use QQuickView as QML container. > > This application uses Qt 5.7.x and running on Linux embedded board with > > the > > NVIDIA core (Toradex Apalis T30). > > > > But sometimes I got flickering in process of animation. A flickering > > represents in form of a "white" strips with full-screen width and 1/5-1/6 > > screen heigth. This flickers happens quickly and frequently (every ~20-60 > > seconds, randomly)... > > > > I have seen this "Avoiding graphics flicker in Qt / QML" [1] blog where > > are > > used QML with Qt 4.x, > > where were used this trics: > > > > {code} > > int main(int argc, char **argv) > > { > > ... > > view.setAttribute(Qt::WA_OpaquePaintEvent); > > view.setAttribute(Qt::WA_NoSystemBackground); > > view.viewport()->setAttribute(Qt::WA_OpaquePaintEvent); > > view.viewport()->setAttribute(Qt::WA_NoSystemBackground); > > ... > > } > > {code} > > > > But, in my case I have use Quick v2, with QQuickView instead of > > QDeclarativeView, > > which does not allowed to setup any attributes. > > > > So, my questions is: is there are any way to setup > > Qt::WA_OpaquePaintEvent > > and/or > > Qt::WA_NoSystemBackground in Quck2? Or, maybe is it possible to use > > another > > tricks? > > > > BR, > > Denis > > > > [1] > https://blog.rburchell.com/2011/11/avoiding-graphics-flicker-in-qt-qml.html > > > > {quote} > > > > This flickering present on some HDMI displays... > > > > We currently have this flags: > > > > {code} > > ... > > view.setFlags(Qt::FramelessWindowHint | Qt::WindowStaysOnTopHint); > > ... > > {code} > > > > Maybe is it an reasons of flikering? Has someone any ideas? > > > > BR, > > Denis > > _______________________________________________ > > 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 denis.shienkov at gmail.com Thu Aug 4 16:48:40 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Thu, 4 Aug 2016 17:48:40 +0300 Subject: [Development] [QML][EGLFS] Bits depth Message-ID: Hi guys, I have use Qt 5.7 on Linux Embedded board (Toradex Apalis T30) with the EGLFS via X11 platform (NVidia drivers). My QML application uses 24-bit PNG images. But I see that these images is looks like 16-bit (I see the gradients borders, and it looks ugly), howewer my X11 uses DefaultDepth == 24!!! Also this command: {quote} root at apalis-t30:~/deploy-apps# xdpyinfo | grep 'depth of root' depth of root window: 24 planes {quote} shows 24-bit mode too. Next, I have added this debug env variable: {quote} export QSG_INFO=1 {quote} to see what happens when my QML app starts: {quote} ... qt.scenegraph.general: threaded render loop qt.scenegraph.general: Using sg animation driver qt.scenegraph.general: Animation Driver: using vsync: 16.67 ms qt.scenegraph.general: Animation Driver: using vsync: 16.67 ms qt.scenegraph.general: texture atlas dimensions: 2048x2048 qt.scenegraph.general: R/G/B/A Buffers: 5 6 5 0 qt.scenegraph.general: Depth Buffer: 16 qt.scenegraph.general: Stencil Buffer: 8 qt.scenegraph.general: Samples: 0 qt.scenegraph.general: GL_VENDOR: NVIDIA Corporation qt.scenegraph.general: GL_RENDERER: NVIDIA Tegra 3 ... {quote} I see that OpenGL (yes?) initializes with the "R/G/B/A Buffers: 5 6 5 0" mode, that is 16-bit depth!!! O_O Next, I have tried to change the FB depth via: {quote} fbset -fb /dev/fb1 -depth 24 {quote} I see that FB changes own settings, but nothing changes when my app starts, it still shows images ugly, as 16-bit depth. Also I have tried to use QT_QPA_EGLFS_DEPTH variable (with 16, 24 or 32), but nothing changes, not helps. Helps only the QT_QPA_EGLFS_FORCE888 variable, but it introduces others bad issues, like the whole/half HDMI display flickering.. So, I can not to use QT_QPA_EGLFS_FORCE888.. So, is there are any tricks to use 24-bit depth? BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From laszlo.agocs at qt.io Thu Aug 4 17:39:38 2016 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Thu, 4 Aug 2016 15:39:38 +0000 Subject: [Development] [QML][EGLFS] Bits depth In-Reply-To: References: Message-ID: Hi Denis, QSurfaceFormat::setDefaultFormat() with a format of red/blue/green set to 8, or alternatively setting QT_QPA_EGLFS_FORCE888 is indeed what you need. The default format with unspecified sizes results in choosing 16 over 32 bit configs when both are offered, that's normal. Check with QSG_INFO what you get. It may either be 8880 or 8888, depending on what is offered by the EGL implementation. As for the 24 bit depth, regardless of what X or EGL says, under the hood it is quite likely that you have 32 bit framebuffers anyway, true packed 24 bit ones are probably rare. As for the "other bad issues", the flickering, that is the real issue here, but that's likely caused by something else outside of Qt's scope. Best regards, Laszlo ________________________________ From: Denis Shienkov Sent: Thursday, August 4, 2016 4:48:40 PM To: development at qt-project.org; Laszlo Agocs Subject: [QML][EGLFS] Bits depth Hi guys, I have use Qt 5.7 on Linux Embedded board (Toradex Apalis T30) with the EGLFS via X11 platform (NVidia drivers). My QML application uses 24-bit PNG images. But I see that these images is looks like 16-bit (I see the gradients borders, and it looks ugly), howewer my X11 uses DefaultDepth == 24!!! Also this command: {quote} root at apalis-t30:~/deploy-apps# xdpyinfo | grep 'depth of root' depth of root window: 24 planes {quote} shows 24-bit mode too. Next, I have added this debug env variable: {quote} export QSG_INFO=1 {quote} to see what happens when my QML app starts: {quote} ... qt.scenegraph.general: threaded render loop qt.scenegraph.general: Using sg animation driver qt.scenegraph.general: Animation Driver: using vsync: 16.67 ms qt.scenegraph.general: Animation Driver: using vsync: 16.67 ms qt.scenegraph.general: texture atlas dimensions: 2048x2048 qt.scenegraph.general: R/G/B/A Buffers: 5 6 5 0 qt.scenegraph.general: Depth Buffer: 16 qt.scenegraph.general: Stencil Buffer: 8 qt.scenegraph.general: Samples: 0 qt.scenegraph.general: GL_VENDOR: NVIDIA Corporation qt.scenegraph.general: GL_RENDERER: NVIDIA Tegra 3 ... {quote} I see that OpenGL (yes?) initializes with the "R/G/B/A Buffers: 5 6 5 0" mode, that is 16-bit depth!!! O_O Next, I have tried to change the FB depth via: {quote} fbset -fb /dev/fb1 -depth 24 {quote} I see that FB changes own settings, but nothing changes when my app starts, it still shows images ugly, as 16-bit depth. Also I have tried to use QT_QPA_EGLFS_DEPTH variable (with 16, 24 or 32), but nothing changes, not helps. Helps only the QT_QPA_EGLFS_FORCE888 variable, but it introduces others bad issues, like the whole/half HDMI display flickering.. So, I can not to use QT_QPA_EGLFS_FORCE888.. So, is there are any tricks to use 24-bit depth? BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Thu Aug 4 18:50:57 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Thu, 4 Aug 2016 19:50:57 +0300 Subject: [Development] [QML][EGLFS] Bits depth In-Reply-To: References: Message-ID: > Check with QSG_INFO what you get. It may either be 8880 or 8888 Yes, seems this: {code} QQuickView view; QSurfaceFormat format; format.setAlphaBufferSize(8); view.setFormat(format); {code} same as QT_QPA_EGLFS_FORCE888, I got: {quote} qt.scenegraph.general: texture atlas dimensions: 2048x2048 qt.scenegraph.general: R/G/B/A Buffers: 8 8 8 8 qt.scenegraph.general: Depth Buffer: 0 qt.scenegraph.general: Stencil Buffer: 0 qt.scenegraph.general: Samples: 0 qt.scenegraph.general: GL_VENDOR: NVIDIA Corporation qt.scenegraph.general: GL_RENDERER: NVIDIA Tegra 3 qt.scenegraph.general: GL_VERSION: OpenGL ES 2.0 14.01002 {quote} BUT: I faced with randomly flickering (with a random white polygons on a black background on 1/2 - 1/3 of height of my display) when an QML animation is running.. sad sad sad... :( I have tried to setup a different buffer's sizes, intervals, and other properties to QSurfaceFormat, but it did not help. It works without flickering only with RGBA=5650, but then I see borders of gradients of images.. :( 2016-08-04 18:39 GMT+03:00 Laszlo Agocs : > > Hi Denis, > > > QSurfaceFormat::setDefaultFormat() with a format of red/blue/green set to > 8, or alternatively setting QT_QPA_EGLFS_FORCE888 is indeed what you need. > The default format with unspecified sizes results in choosing 16 over 32 > bit configs when both are offered, that's normal. > > > Check with QSG_INFO what you get. It may either be 8880 or 8888, depending > on what is offered by the EGL implementation. As for the 24 bit depth, > regardless of what X or EGL says, under the hood it is quite likely that > you have 32 bit framebuffers anyway, true packed 24 bit ones are probably > rare. > > > As for the "other bad issues", the flickering, that is the real issue > here, but that's likely caused by something else outside of Qt's scope. > > > Best regards, > > Laszlo > ------------------------------ > *From:* Denis Shienkov > *Sent:* Thursday, August 4, 2016 4:48:40 PM > *To:* development at qt-project.org; Laszlo Agocs > *Subject:* [QML][EGLFS] Bits depth > > Hi guys, > > I have use Qt 5.7 on Linux Embedded board (Toradex Apalis T30) with the > EGLFS via X11 platform (NVidia drivers). > > My QML application uses 24-bit PNG images. But I see that these images is > looks like 16-bit (I see the gradients borders, and it looks ugly), > howewer my X11 uses DefaultDepth == 24!!! > > Also this command: > > {quote} > root at apalis-t30:~/deploy-apps# xdpyinfo | grep 'depth of root' > depth of root window: 24 planes > {quote} > > shows 24-bit mode too. > > Next, I have added this debug env variable: > > {quote} > export QSG_INFO=1 > {quote} > > to see what happens when my QML app starts: > > {quote} > ... > qt.scenegraph.general: threaded render loop > qt.scenegraph.general: Using sg animation driver > qt.scenegraph.general: Animation Driver: using vsync: 16.67 ms > qt.scenegraph.general: Animation Driver: using vsync: 16.67 ms > qt.scenegraph.general: texture atlas dimensions: 2048x2048 > qt.scenegraph.general: R/G/B/A Buffers: 5 6 5 0 > qt.scenegraph.general: Depth Buffer: 16 > qt.scenegraph.general: Stencil Buffer: 8 > qt.scenegraph.general: Samples: 0 > qt.scenegraph.general: GL_VENDOR: NVIDIA Corporation > qt.scenegraph.general: GL_RENDERER: NVIDIA Tegra 3 > ... > {quote} > > I see that OpenGL (yes?) initializes with the "R/G/B/A Buffers: 5 6 5 > 0" mode, > that is 16-bit depth!!! O_O > > Next, I have tried to change the FB depth via: > > {quote} > fbset -fb /dev/fb1 -depth 24 > {quote} > > I see that FB changes own settings, but nothing changes when my app starts, > it still shows images ugly, as 16-bit depth. > > Also I have tried to use QT_QPA_EGLFS_DEPTH variable (with 16, 24 or 32), > but nothing changes, not helps. > > Helps only the QT_QPA_EGLFS_FORCE888 variable, but it introduces others > bad issues, > like the whole/half HDMI display flickering.. So, I can not to use > QT_QPA_EGLFS_FORCE888.. > > So, is there are any tricks to use 24-bit depth? > > BR, > Denis > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Fri Aug 5 07:12:59 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 5 Aug 2016 08:12:59 +0300 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: References: <1470311864.417285.685842217.63CDB906@webmail.messagingengine.com> Message-ID: <1dcd9db7-0722-a09e-5868-c5bd42cc8c37@gmail.com> Hi all, I have an idea how to avoid flickering, but I don't know about results: what if I will discard the Open GL support in favor to Quick2 render? I have read this documentation: http://doc.qt.io/QtQuick2DRenderer/ which says about the "Qt Quick 2D Renderer" module. So, my things is: 1. Download && build && install this module: git://code.qt.io/qt/qtdeclarative-render2d.git 2. Use this env variable: export QMLSCENE_DEVICE=softwarecontext 3. Run my app... But, I don't understand: 1) What of engine is used to 2D rendering in case if I have EGLFS only? 2) Should I re-build Qt5 too with the "--no-opengl" option (or I can keep the "-opengl es2" option) ? 04.08.2016 16:10, Denis Shienkov пишет: > Hi Robin, > > > Repeating my last answer... > > http://lists.qt-project.org/pipermail/development/2016-July/026736.html > > I'm sorry, but I did not receive (did not see) your last answer. > > > I'm going to guess you're using eglfs or something like that > > Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are used > NVIDIA's drivers. > > Seems, the flickering is when are used: > > export QT_QPA_EGLFS_FORCE888=1 > > ENV variable... (I need this variable to smooth the Image's > gradients... even X11 started with 24-bit depth). > > PS: But, I'm not sure about QT_QPA_EGLFS_FORCE888... :( > > > Using an overlay to debug item positions (QSG_VISUALIZE=overdraw) > could be handy for trying to rule > this out, as if it is specific to the application, > > Ok, many thanks, I will try it. > > > 2016-08-04 14:57 GMT+03:00 Robin Burchell >: > > Repeating my last answer... > > http://lists.qt-project.org/pipermail/development/2016-July/026736.html > > On Thu, Aug 4, 2016, at 01:50 PM, Denis Shienkov wrote: > > {quote} > > > > Hi all. > > > > I have some QML application, where just use QQuickView as QML > container. > > This application uses Qt 5.7.x and running on Linux embedded > board with > > the > > NVIDIA core (Toradex Apalis T30). > > > > But sometimes I got flickering in process of animation. A flickering > > represents in form of a "white" strips with full-screen width > and 1/5-1/6 > > screen heigth. This flickers happens quickly and frequently > (every ~20-60 > > seconds, randomly)... > > > > I have seen this "Avoiding graphics flicker in Qt / QML" [1] > blog where > > are > > used QML with Qt 4.x, > > where were used this trics: > > > > {code} > > int main(int argc, char **argv) > > { > > ... > > view.setAttribute(Qt::WA_OpaquePaintEvent); > > view.setAttribute(Qt::WA_NoSystemBackground); > > view.viewport()->setAttribute(Qt::WA_OpaquePaintEvent); > > view.viewport()->setAttribute(Qt::WA_NoSystemBackground); > > ... > > } > > {code} > > > > But, in my case I have use Quick v2, with QQuickView instead of > > QDeclarativeView, > > which does not allowed to setup any attributes. > > > > So, my questions is: is there are any way to setup > > Qt::WA_OpaquePaintEvent > > and/or > > Qt::WA_NoSystemBackground in Quck2? Or, maybe is it possible to use > > another > > tricks? > > > > BR, > > Denis > > > > > [1]https://blog.rburchell.com/2011/11/avoiding-graphics-flicker-in-qt-qml.html > > > > {quote} > > > > This flickering present on some HDMI displays... > > > > We currently have this flags: > > > > {code} > > ... > > view.setFlags(Qt::FramelessWindowHint | Qt::WindowStaysOnTopHint); > > ... > > {code} > > > > Maybe is it an reasons of flikering? Has someone any ideas? > > > > BR, > > Denis > > _______________________________________________ > > 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 sean.harmer at kdab.com Fri Aug 5 10:53:53 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 05 Aug 2016 09:53:53 +0100 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: <1dcd9db7-0722-a09e-5868-c5bd42cc8c37@gmail.com> References: <1dcd9db7-0722-a09e-5868-c5bd42cc8c37@gmail.com> Message-ID: <1848382.queLgqDOTN@cartman> Hi, Can you try a plain OpenGL test application with RGBA8 framebuffer and see if that exhibits the same flashing/flickering problem. If so, it's a driver/hardware issue. If you are forced into then using a 16-bit framebuffer, then you can avoid the banding by using dithering in your gradients. Either apply the dithering offline and store the gradients as images or write a custom material that applies the dithering in the fragment shader. Cheers, Sean On Friday 05 August 2016 08:12:59 Denis Shienkov wrote: > Hi all, > > I have an idea how to avoid flickering, but I don't know about results: > what if I will discard the Open GL support in favor to Quick2 render? > > I have read this documentation: http://doc.qt.io/QtQuick2DRenderer/ > which says about the "Qt Quick 2D Renderer" module. > > So, my things is: > > 1. Download && build && install this module: > > git://code.qt.io/qt/qtdeclarative-render2d.git > > 2. Use this env variable: > > export QMLSCENE_DEVICE=softwarecontext > > 3. Run my app... > > > But, I don't understand: > > 1) What of engine is used to 2D rendering in case if I have EGLFS only? > > 2) Should I re-build Qt5 too with the "--no-opengl" option (or I can > keep the "-opengl es2" option) ? > > 04.08.2016 16:10, Denis Shienkov пишет: > > Hi Robin, > > > > > Repeating my last answer... > > > http://lists.qt-project.org/pipermail/development/2016-July/026736.html > > > > I'm sorry, but I did not receive (did not see) your last answer. > > > > > I'm going to guess you're using eglfs or something like that > > > > Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are used > > NVIDIA's drivers. > > > > Seems, the flickering is when are used: > > > > export QT_QPA_EGLFS_FORCE888=1 > > > > ENV variable... (I need this variable to smooth the Image's > > gradients... even X11 started with 24-bit depth). > > > > PS: But, I'm not sure about QT_QPA_EGLFS_FORCE888... :( > > > > > Using an overlay to debug item positions (QSG_VISUALIZE=overdraw) > > > > could be handy for trying to rule > > this out, as if it is specific to the application, > > > > Ok, many thanks, I will try it. > > > > > > 2016-08-04 14:57 GMT+03:00 Robin Burchell > > > >: > > Repeating my last answer... > > > > http://lists.qt-project.org/pipermail/development/2016-July/026736.htm > > l > > > > On Thu, Aug 4, 2016, at 01:50 PM, Denis Shienkov wrote: > > > {quote} > > > > > > Hi all. > > > > > > I have some QML application, where just use QQuickView as QML > > > > container. > > > > > This application uses Qt 5.7.x and running on Linux embedded > > > > board with > > > > > the > > > NVIDIA core (Toradex Apalis T30). > > > > > > But sometimes I got flickering in process of animation. A flickering > > > represents in form of a "white" strips with full-screen width > > > > and 1/5-1/6 > > > > > screen heigth. This flickers happens quickly and frequently > > > > (every ~20-60 > > > > > seconds, randomly)... > > > > > > I have seen this "Avoiding graphics flicker in Qt / QML" [1] > > > > blog where > > > > > are > > > used QML with Qt 4.x, > > > where were used this trics: > > > > > > {code} > > > int main(int argc, char **argv) > > > { > > > > > > ... > > > > > > view.setAttribute(Qt::WA_OpaquePaintEvent); > > > view.setAttribute(Qt::WA_NoSystemBackground); > > > view.viewport()->setAttribute(Qt::WA_OpaquePaintEvent); > > > view.viewport()->setAttribute(Qt::WA_NoSystemBackground); > > > > > > ... > > > > > > } > > > {code} > > > > > > But, in my case I have use Quick v2, with QQuickView instead of > > > QDeclarativeView, > > > which does not allowed to setup any attributes. > > > > > > So, my questions is: is there are any way to setup > > > Qt::WA_OpaquePaintEvent > > > and/or > > > Qt::WA_NoSystemBackground in Quck2? Or, maybe is it possible to use > > > another > > > tricks? > > > > > > BR, > > > Denis > > > > [1]https://blog.rburchell.com/2011/11/avoiding-graphics-flicker-in-qt-> > qml.html> > > > {quote} > > > > > > This flickering present on some HDMI displays... > > > > > > We currently have this flags: > > > > > > {code} > > > ... > > > view.setFlags(Qt::FramelessWindowHint | Qt::WindowStaysOnTopHint); > > > ... > > > {code} > > > > > > Maybe is it an reasons of flikering? Has someone any ideas? > > > > > > BR, > > > Denis > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK 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 denis.shienkov at gmail.com Fri Aug 5 11:02:10 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 5 Aug 2016 12:02:10 +0300 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: <1848382.queLgqDOTN@cartman> References: <1dcd9db7-0722-a09e-5868-c5bd42cc8c37@gmail.com> <1848382.queLgqDOTN@cartman> Message-ID: > Can you try a plain OpenGL test application with RGBA8 framebuffer Do you mean: I should take any OpenGL application from the Qt examples? And to check there? 2016-08-05 11:53 GMT+03:00 Sean Harmer : > Hi, > > Can you try a plain OpenGL test application with RGBA8 framebuffer and see > if > that exhibits the same flashing/flickering problem. If so, it's a > driver/hardware issue. > > If you are forced into then using a 16-bit framebuffer, then you can avoid > the > banding by using dithering in your gradients. Either apply the dithering > offline > and store the gradients as images or write a custom material that applies > the > dithering in the fragment shader. > > Cheers, > > Sean > > On Friday 05 August 2016 08:12:59 Denis Shienkov wrote: > > Hi all, > > > > I have an idea how to avoid flickering, but I don't know about results: > > what if I will discard the Open GL support in favor to Quick2 render? > > > > I have read this documentation: http://doc.qt.io/QtQuick2DRenderer/ > > which says about the "Qt Quick 2D Renderer" module. > > > > So, my things is: > > > > 1. Download && build && install this module: > > > > git://code.qt.io/qt/qtdeclarative-render2d.git > > > > 2. Use this env variable: > > > > export QMLSCENE_DEVICE=softwarecontext > > > > 3. Run my app... > > > > > > But, I don't understand: > > > > 1) What of engine is used to 2D rendering in case if I have EGLFS only? > > > > 2) Should I re-build Qt5 too with the "--no-opengl" option (or I can > > keep the "-opengl es2" option) ? > > > > 04.08.2016 16:10, Denis Shienkov пишет: > > > Hi Robin, > > > > > > > Repeating my last answer... > > > > http://lists.qt-project.org/pipermail/development/2016- > July/026736.html > > > > > > I'm sorry, but I did not receive (did not see) your last answer. > > > > > > > I'm going to guess you're using eglfs or something like that > > > > > > Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are used > > > NVIDIA's drivers. > > > > > > Seems, the flickering is when are used: > > > > > > export QT_QPA_EGLFS_FORCE888=1 > > > > > > ENV variable... (I need this variable to smooth the Image's > > > gradients... even X11 started with 24-bit depth). > > > > > > PS: But, I'm not sure about QT_QPA_EGLFS_FORCE888... :( > > > > > > > Using an overlay to debug item positions (QSG_VISUALIZE=overdraw) > > > > > > could be handy for trying to rule > > > this out, as if it is specific to the application, > > > > > > Ok, many thanks, I will try it. > > > > > > > > > 2016-08-04 14:57 GMT+03:00 Robin Burchell > > > > > >: > > > Repeating my last answer... > > > > > > http://lists.qt-project.org/pipermail/development/2016- > July/026736.htm > > > l > > > > > > On Thu, Aug 4, 2016, at 01:50 PM, Denis Shienkov wrote: > > > > {quote} > > > > > > > > Hi all. > > > > > > > > I have some QML application, where just use QQuickView as QML > > > > > > container. > > > > > > > This application uses Qt 5.7.x and running on Linux embedded > > > > > > board with > > > > > > > the > > > > NVIDIA core (Toradex Apalis T30). > > > > > > > > But sometimes I got flickering in process of animation. A > flickering > > > > represents in form of a "white" strips with full-screen width > > > > > > and 1/5-1/6 > > > > > > > screen heigth. This flickers happens quickly and frequently > > > > > > (every ~20-60 > > > > > > > seconds, randomly)... > > > > > > > > I have seen this "Avoiding graphics flicker in Qt / QML" [1] > > > > > > blog where > > > > > > > are > > > > used QML with Qt 4.x, > > > > where were used this trics: > > > > > > > > {code} > > > > int main(int argc, char **argv) > > > > { > > > > > > > > ... > > > > > > > > view.setAttribute(Qt::WA_OpaquePaintEvent); > > > > view.setAttribute(Qt::WA_NoSystemBackground); > > > > view.viewport()->setAttribute(Qt::WA_OpaquePaintEvent); > > > > view.viewport()->setAttribute(Qt::WA_NoSystemBackground); > > > > > > > > ... > > > > > > > > } > > > > {code} > > > > > > > > But, in my case I have use Quick v2, with QQuickView instead of > > > > QDeclarativeView, > > > > which does not allowed to setup any attributes. > > > > > > > > So, my questions is: is there are any way to setup > > > > Qt::WA_OpaquePaintEvent > > > > and/or > > > > Qt::WA_NoSystemBackground in Quck2? Or, maybe is it possible to > use > > > > another > > > > tricks? > > > > > > > > BR, > > > > Denis > > > > > > [1]https://blog.rburchell.com/2011/11/avoiding-graphics- > flicker-in-qt-> > qml.html> > > > > {quote} > > > > > > > > This flickering present on some HDMI displays... > > > > > > > > We currently have this flags: > > > > > > > > {code} > > > > ... > > > > view.setFlags(Qt::FramelessWindowHint | > Qt::WindowStaysOnTopHint); > > > > ... > > > > {code} > > > > > > > > Maybe is it an reasons of flikering? Has someone any ideas? > > > > > > > > BR, > > > > Denis > > > > _______________________________________________ > > > > Development mailing list > > > > Development at qt-project.org > > > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > 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 > _______________________________________________ > 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 sean.harmer at kdab.com Fri Aug 5 11:03:37 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 05 Aug 2016 10:03:37 +0100 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: References: <1848382.queLgqDOTN@cartman> Message-ID: <2360289.2QICv2mdQO@cartman> On Friday 05 August 2016 12:02:10 Denis Shienkov wrote: > > Can you try a plain OpenGL test application with RGBA8 framebuffer > > Do you mean: I should take any OpenGL application from the Qt examples? And > to check there? You may need to modify it to explicitly request R8G8B8A8 using a QSurfaceFormat but yes any of those should work to prove/disprove. Sean > > 2016-08-05 11:53 GMT+03:00 Sean Harmer : > > Hi, > > > > Can you try a plain OpenGL test application with RGBA8 framebuffer and see > > if > > that exhibits the same flashing/flickering problem. If so, it's a > > driver/hardware issue. > > > > If you are forced into then using a 16-bit framebuffer, then you can avoid > > the > > banding by using dithering in your gradients. Either apply the dithering > > offline > > and store the gradients as images or write a custom material that applies > > the > > dithering in the fragment shader. > > > > Cheers, > > > > Sean > > > > On Friday 05 August 2016 08:12:59 Denis Shienkov wrote: > > > Hi all, > > > > > > I have an idea how to avoid flickering, but I don't know about results: > > > what if I will discard the Open GL support in favor to Quick2 render? > > > > > > I have read this documentation: http://doc.qt.io/QtQuick2DRenderer/ > > > which says about the "Qt Quick 2D Renderer" module. > > > > > > So, my things is: > > > > > > 1. Download && build && install this module: > > > > > > git://code.qt.io/qt/qtdeclarative-render2d.git > > > > > > 2. Use this env variable: > > > > > > export QMLSCENE_DEVICE=softwarecontext > > > > > > 3. Run my app... > > > > > > > > > But, I don't understand: > > > > > > 1) What of engine is used to 2D rendering in case if I have EGLFS only? > > > > > > 2) Should I re-build Qt5 too with the "--no-opengl" option (or I can > > > keep the "-opengl es2" option) ? > > > > > > 04.08.2016 16:10, Denis Shienkov пишет: > > > > Hi Robin, > > > > > > > > > Repeating my last answer... > > > > > http://lists.qt-project.org/pipermail/development/2016-> > > > July/026736.html > > > > > > I'm sorry, but I did not receive (did not see) your last answer. > > > > > > > > > I'm going to guess you're using eglfs or something like that > > > > > > > > Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are used > > > > NVIDIA's drivers. > > > > > > > > Seems, the flickering is when are used: > > > > > > > > export QT_QPA_EGLFS_FORCE888=1 > > > > > > > > ENV variable... (I need this variable to smooth the Image's > > > > gradients... even X11 started with 24-bit depth). > > > > > > > > PS: But, I'm not sure about QT_QPA_EGLFS_FORCE888... :( > > > > > > > > > Using an overlay to debug item positions (QSG_VISUALIZE=overdraw) > > > > > > > > could be handy for trying to rule > > > > this out, as if it is specific to the application, > > > > > > > > Ok, many thanks, I will try it. > > > > > > > > > > > > 2016-08-04 14:57 GMT+03:00 Robin Burchell > > > > > > > >: > > > > Repeating my last answer... > > > > > > > > http://lists.qt-project.org/pipermail/development/2016-> > > > July/026736.htm > > > > > > l > > > > > > > > On Thu, Aug 4, 2016, at 01:50 PM, Denis Shienkov wrote: > > > > > {quote} > > > > > > > > > > Hi all. > > > > > > > > > > I have some QML application, where just use QQuickView as QML > > > > > > > > container. > > > > > > > > > This application uses Qt 5.7.x and running on Linux embedded > > > > > > > > board with > > > > > > > > > the > > > > > NVIDIA core (Toradex Apalis T30). > > > > > > > > > > But sometimes I got flickering in process of animation. A > > > > flickering > > > > > > > represents in form of a "white" strips with full-screen width > > > > > > > > and 1/5-1/6 > > > > > > > > > screen heigth. This flickers happens quickly and frequently > > > > > > > > (every ~20-60 > > > > > > > > > seconds, randomly)... > > > > > > > > > > I have seen this "Avoiding graphics flicker in Qt / QML" [1] > > > > > > > > blog where > > > > > > > > > are > > > > > used QML with Qt 4.x, > > > > > where were used this trics: > > > > > > > > > > {code} > > > > > int main(int argc, char **argv) > > > > > { > > > > > > > > > > ... > > > > > > > > > > view.setAttribute(Qt::WA_OpaquePaintEvent); > > > > > view.setAttribute(Qt::WA_NoSystemBackground); > > > > > view.viewport()->setAttribute(Qt::WA_OpaquePaintEvent); > > > > > view.viewport()->setAttribute(Qt::WA_NoSystemBackground); > > > > > > > > > > ... > > > > > > > > > > } > > > > > {code} > > > > > > > > > > But, in my case I have use Quick v2, with QQuickView instead of > > > > > QDeclarativeView, > > > > > which does not allowed to setup any attributes. > > > > > > > > > > So, my questions is: is there are any way to setup > > > > > Qt::WA_OpaquePaintEvent > > > > > and/or > > > > > Qt::WA_NoSystemBackground in Quck2? Or, maybe is it possible to > > > > use > > > > > > > another > > > > > tricks? > > > > > > > > > > BR, > > > > > Denis > > > > > > > > [1]https://blog.rburchell.com/2011/11/avoiding-graphics-> > > > flicker-in-qt-> > qml.html> > > > > > > > {quote} > > > > > > > > > > This flickering present on some HDMI displays... > > > > > > > > > > We currently have this flags: > > > > > > > > > > {code} > > > > > ... > > > > > view.setFlags(Qt::FramelessWindowHint | > > > > Qt::WindowStaysOnTopHint); > > > > > > > ... > > > > > {code} > > > > > > > > > > Maybe is it an reasons of flikering? Has someone any ideas? > > > > > > > > > > BR, > > > > > Denis > > > > > _______________________________________________ > > > > > Development mailing list > > > > > Development at qt-project.org > > > > > http://lists.qt-project.org/mailman/listinfo/development > > > > -- > > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > > 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 > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK 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 eskil.abrahamsen-blomfeldt at qt.io Fri Aug 5 11:34:12 2016 From: eskil.abrahamsen-blomfeldt at qt.io (Eskil Abrahamsen Blomfeldt) Date: Fri, 5 Aug 2016 11:34:12 +0200 Subject: [Development] Nominating Johan Helsing for Approver status In-Reply-To: References: Message-ID: <15ce3df9-f72b-54c8-18a6-dec38ccf784f@qt.io> Den 04.08.2016 12:22, skrev Paul Tvete: > Hi all, > > > I'd like to nominate Johan Helsing for Approver status. He joined The Qt Company half a year ago, and has been working full time on Qt since. Johan has been actively involved in making the QtWaylandCompositor module ready for Qt 5.8, as well as doing a major part of the bug fixes for Qt Wayland in 5.6 and 5.7. +1 -- Eskil Abrahamsen Blomfeldt Senior Manager, R&D The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfeldt at qt.io http://qt.io From denis.shienkov at gmail.com Fri Aug 5 13:22:00 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 5 Aug 2016 14:22:00 +0300 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: <2360289.2QICv2mdQO@cartman> References: <1848382.queLgqDOTN@cartman> <2360289.2QICv2mdQO@cartman> Message-ID: So, I have compiled the standard Samehame QMML application from: /home/builder/Projects/qt5/qtdeclarative/examples/quick/demos/samegame/ and got same artifacts when I use RDBA=8888 mode. I have "screenshoot" of this flicking attifact: http://pasteboard.co/4XjMl3GNq.png I'm personally don't think that this is an NVidia's OpenGL ES2 bug... I think it is Qt bug... I'm not an OpenGL expert... so, can anybody point me what I need to do with the Qt sources (where to look in)? Maybe I need to add some of gl_ functions to clear of content or something else... but where? 2016-08-05 12:03 GMT+03:00 Sean Harmer : > On Friday 05 August 2016 12:02:10 Denis Shienkov wrote: > > > Can you try a plain OpenGL test application with RGBA8 framebuffer > > > > Do you mean: I should take any OpenGL application from the Qt examples? > And > > to check there? > > You may need to modify it to explicitly request R8G8B8A8 using a > QSurfaceFormat but yes any of those should work to prove/disprove. > > Sean > > > > > 2016-08-05 11:53 GMT+03:00 Sean Harmer : > > > Hi, > > > > > > Can you try a plain OpenGL test application with RGBA8 framebuffer and > see > > > if > > > that exhibits the same flashing/flickering problem. If so, it's a > > > driver/hardware issue. > > > > > > If you are forced into then using a 16-bit framebuffer, then you can > avoid > > > the > > > banding by using dithering in your gradients. Either apply the > dithering > > > offline > > > and store the gradients as images or write a custom material that > applies > > > the > > > dithering in the fragment shader. > > > > > > Cheers, > > > > > > Sean > > > > > > On Friday 05 August 2016 08:12:59 Denis Shienkov wrote: > > > > Hi all, > > > > > > > > I have an idea how to avoid flickering, but I don't know about > results: > > > > what if I will discard the Open GL support in favor to Quick2 render? > > > > > > > > I have read this documentation: http://doc.qt.io/QtQuick2DRenderer/ > > > > which says about the "Qt Quick 2D Renderer" module. > > > > > > > > So, my things is: > > > > > > > > 1. Download && build && install this module: > > > > > > > > git://code.qt.io/qt/qtdeclarative-render2d.git > > > > > > > > 2. Use this env variable: > > > > > > > > export QMLSCENE_DEVICE=softwarecontext > > > > > > > > 3. Run my app... > > > > > > > > > > > > But, I don't understand: > > > > > > > > 1) What of engine is used to 2D rendering in case if I have EGLFS > only? > > > > > > > > 2) Should I re-build Qt5 too with the "--no-opengl" option (or I can > > > > keep the "-opengl es2" option) ? > > > > > > > > 04.08.2016 16:10, Denis Shienkov пишет: > > > > > Hi Robin, > > > > > > > > > > > Repeating my last answer... > > > > > > http://lists.qt-project.org/pipermail/development/2016-> > > > > July/026736.html > > > > > > > > I'm sorry, but I did not receive (did not see) your last answer. > > > > > > > > > > > I'm going to guess you're using eglfs or something like that > > > > > > > > > > Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are used > > > > > NVIDIA's drivers. > > > > > > > > > > Seems, the flickering is when are used: > > > > > > > > > > export QT_QPA_EGLFS_FORCE888=1 > > > > > > > > > > ENV variable... (I need this variable to smooth the Image's > > > > > gradients... even X11 started with 24-bit depth). > > > > > > > > > > PS: But, I'm not sure about QT_QPA_EGLFS_FORCE888... :( > > > > > > > > > > > Using an overlay to debug item positions (QSG_VISUALIZE=overdraw) > > > > > > > > > > could be handy for trying to rule > > > > > this out, as if it is specific to the application, > > > > > > > > > > Ok, many thanks, I will try it. > > > > > > > > > > > > > > > 2016-08-04 14:57 GMT+03:00 Robin Burchell > > > > > > > > > >: > > > > > Repeating my last answer... > > > > > > > > > > http://lists.qt-project.org/pipermail/development/2016-> > > > > July/026736.htm > > > > > > > > l > > > > > > > > > > On Thu, Aug 4, 2016, at 01:50 PM, Denis Shienkov wrote: > > > > > > {quote} > > > > > > > > > > > > Hi all. > > > > > > > > > > > > I have some QML application, where just use QQuickView as QML > > > > > > > > > > container. > > > > > > > > > > > This application uses Qt 5.7.x and running on Linux embedded > > > > > > > > > > board with > > > > > > > > > > > the > > > > > > NVIDIA core (Toradex Apalis T30). > > > > > > > > > > > > But sometimes I got flickering in process of animation. A > > > > > > flickering > > > > > > > > > represents in form of a "white" strips with full-screen width > > > > > > > > > > and 1/5-1/6 > > > > > > > > > > > screen heigth. This flickers happens quickly and frequently > > > > > > > > > > (every ~20-60 > > > > > > > > > > > seconds, randomly)... > > > > > > > > > > > > I have seen this "Avoiding graphics flicker in Qt / QML" [1] > > > > > > > > > > blog where > > > > > > > > > > > are > > > > > > used QML with Qt 4.x, > > > > > > where were used this trics: > > > > > > > > > > > > {code} > > > > > > int main(int argc, char **argv) > > > > > > { > > > > > > > > > > > > ... > > > > > > > > > > > > view.setAttribute(Qt::WA_OpaquePaintEvent); > > > > > > view.setAttribute(Qt::WA_NoSystemBackground); > > > > > > view.viewport()->setAttribute(Qt::WA_OpaquePaintEvent); > > > > > > view.viewport()->setAttribute(Qt::WA_NoSystemBackground); > > > > > > > > > > > > ... > > > > > > > > > > > > } > > > > > > {code} > > > > > > > > > > > > But, in my case I have use Quick v2, with QQuickView instead > of > > > > > > QDeclarativeView, > > > > > > which does not allowed to setup any attributes. > > > > > > > > > > > > So, my questions is: is there are any way to setup > > > > > > Qt::WA_OpaquePaintEvent > > > > > > and/or > > > > > > Qt::WA_NoSystemBackground in Quck2? Or, maybe is it possible > to > > > > > > use > > > > > > > > > another > > > > > > tricks? > > > > > > > > > > > > BR, > > > > > > Denis > > > > > > > > > > [1]https://blog.rburchell.com/2011/11/avoiding-graphics-> > > > > flicker-in-qt-> > qml.html> > > > > > > > > > {quote} > > > > > > > > > > > > This flickering present on some HDMI displays... > > > > > > > > > > > > We currently have this flags: > > > > > > > > > > > > {code} > > > > > > ... > > > > > > view.setFlags(Qt::FramelessWindowHint | > > > > > > Qt::WindowStaysOnTopHint); > > > > > > > > > ... > > > > > > {code} > > > > > > > > > > > > Maybe is it an reasons of flikering? Has someone any ideas? > > > > > > > > > > > > BR, > > > > > > Denis > > > > > > _______________________________________________ > > > > > > Development mailing list > > > > > > Development at qt-project.org project.org> > > > > > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > -- > > > 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 > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.harmer at kdab.com Fri Aug 5 13:39:57 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 05 Aug 2016 12:39:57 +0100 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: References: <2360289.2QICv2mdQO@cartman> Message-ID: <3665938.pz6XOfLHxi@cartman> I suggested to use an OpenGL example, not a Qt Quick one. We're trying to isolate where the issue is in the stack. So use a single threaded, plain OpenGL application with a 32 bit framebuffer and see if that gives the same issue. Cheers, Sean On Friday 05 August 2016 14:22:00 Denis Shienkov wrote: > So, I have compiled the standard Samehame QMML application from: > > /home/builder/Projects/qt5/qtdeclarative/examples/quick/demos/samegame/ > > and got same artifacts when I use RDBA=8888 mode. > > I have "screenshoot" of this flicking attifact: > http://pasteboard.co/4XjMl3GNq.png > > I'm personally don't think that this is an NVidia's OpenGL ES2 bug... I > think it is Qt bug... > > I'm not an OpenGL expert... so, can anybody point me what I need to do with > the Qt sources (where to look in)? > > Maybe I need to add some of gl_ functions to clear of content or something > else... but where? > > 2016-08-05 12:03 GMT+03:00 Sean Harmer : > > On Friday 05 August 2016 12:02:10 Denis Shienkov wrote: > > > > Can you try a plain OpenGL test application with RGBA8 framebuffer > > > > > > Do you mean: I should take any OpenGL application from the Qt examples? > > > > And > > > > > to check there? > > > > You may need to modify it to explicitly request R8G8B8A8 using a > > QSurfaceFormat but yes any of those should work to prove/disprove. > > > > Sean > > > > > 2016-08-05 11:53 GMT+03:00 Sean Harmer : > > > > Hi, > > > > > > > > Can you try a plain OpenGL test application with RGBA8 framebuffer and > > > > see > > > > > > if > > > > that exhibits the same flashing/flickering problem. If so, it's a > > > > driver/hardware issue. > > > > > > > > If you are forced into then using a 16-bit framebuffer, then you can > > > > avoid > > > > > > the > > > > banding by using dithering in your gradients. Either apply the > > > > dithering > > > > > > offline > > > > and store the gradients as images or write a custom material that > > > > applies > > > > > > the > > > > dithering in the fragment shader. > > > > > > > > Cheers, > > > > > > > > Sean > > > > > > > > On Friday 05 August 2016 08:12:59 Denis Shienkov wrote: > > > > > Hi all, > > > > > > > > > > I have an idea how to avoid flickering, but I don't know about > > > > results: > > > > > what if I will discard the Open GL support in favor to Quick2 > > > > > render? > > > > > > > > > > I have read this documentation: http://doc.qt.io/QtQuick2DRenderer/ > > > > > which says about the "Qt Quick 2D Renderer" module. > > > > > > > > > > So, my things is: > > > > > > > > > > 1. Download && build && install this module: > > > > > > > > > > git://code.qt.io/qt/qtdeclarative-render2d.git > > > > > > > > > > 2. Use this env variable: > > > > > > > > > > export QMLSCENE_DEVICE=softwarecontext > > > > > > > > > > 3. Run my app... > > > > > > > > > > > > > > > But, I don't understand: > > > > > > > > > > 1) What of engine is used to 2D rendering in case if I have EGLFS > > > > only? > > > > > > > 2) Should I re-build Qt5 too with the "--no-opengl" option (or I can > > > > > keep the "-opengl es2" option) ? > > > > > > > > > > 04.08.2016 16:10, Denis Shienkov пишет: > > > > > > Hi Robin, > > > > > > > > > > > > > Repeating my last answer... > > > > > > > http://lists.qt-project.org/pipermail/development/2016-> > > > > > > > > > July/026736.html > > > > > > > > > > I'm sorry, but I did not receive (did not see) your last answer. > > > > > > > > > > > > > I'm going to guess you're using eglfs or something like that > > > > > > > > > > > > Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are used > > > > > > NVIDIA's drivers. > > > > > > > > > > > > Seems, the flickering is when are used: > > > > > > > > > > > > export QT_QPA_EGLFS_FORCE888=1 > > > > > > > > > > > > ENV variable... (I need this variable to smooth the Image's > > > > > > gradients... even X11 started with 24-bit depth). > > > > > > > > > > > > PS: But, I'm not sure about QT_QPA_EGLFS_FORCE888... :( > > > > > > > > > > > > > Using an overlay to debug item positions > > > > > > > (QSG_VISUALIZE=overdraw) > > > > > > > > > > > > could be handy for trying to rule > > > > > > this out, as if it is specific to the application, > > > > > > > > > > > > Ok, many thanks, I will try it. > > > > > > > > > > > > > > > > > > 2016-08-04 14:57 GMT+03:00 Robin Burchell > > > > > > > > > > > >: > > > > > > Repeating my last answer... > > > > > > > > > > > > http://lists.qt-project.org/pipermail/development/2016-> > > > > > > > > > July/026736.htm > > > > > > > > > > l > > > > > > > > > > > > On Thu, Aug 4, 2016, at 01:50 PM, Denis Shienkov wrote: > > > > > > > {quote} > > > > > > > > > > > > > > Hi all. > > > > > > > > > > > > > > I have some QML application, where just use QQuickView as > > > > > > > QML > > > > > > > > > > > > container. > > > > > > > > > > > > > This application uses Qt 5.7.x and running on Linux embedded > > > > > > > > > > > > board with > > > > > > > > > > > > > the > > > > > > > NVIDIA core (Toradex Apalis T30). > > > > > > > > > > > > > > But sometimes I got flickering in process of animation. A > > > > > > > > flickering > > > > > > > > > > > represents in form of a "white" strips with full-screen > > > > > > > width > > > > > > > > > > > > and 1/5-1/6 > > > > > > > > > > > > > screen heigth. This flickers happens quickly and frequently > > > > > > > > > > > > (every ~20-60 > > > > > > > > > > > > > seconds, randomly)... > > > > > > > > > > > > > > I have seen this "Avoiding graphics flicker in Qt / QML" [1] > > > > > > > > > > > > blog where > > > > > > > > > > > > > are > > > > > > > used QML with Qt 4.x, > > > > > > > where were used this trics: > > > > > > > > > > > > > > {code} > > > > > > > int main(int argc, char **argv) > > > > > > > { > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > view.setAttribute(Qt::WA_OpaquePaintEvent); > > > > > > > view.setAttribute(Qt::WA_NoSystemBackground); > > > > > > > view.viewport()->setAttribute(Qt::WA_OpaquePaintEvent); > > > > > > > view.viewport()->setAttribute(Qt::WA_NoSystemBackground); > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > } > > > > > > > {code} > > > > > > > > > > > > > > But, in my case I have use Quick v2, with QQuickView instead > > > > of > > > > > > > > > QDeclarativeView, > > > > > > > which does not allowed to setup any attributes. > > > > > > > > > > > > > > So, my questions is: is there are any way to setup > > > > > > > Qt::WA_OpaquePaintEvent > > > > > > > and/or > > > > > > > Qt::WA_NoSystemBackground in Quck2? Or, maybe is it possible > > > > to > > > > > > use > > > > > > > > > > > another > > > > > > > tricks? > > > > > > > > > > > > > > BR, > > > > > > > Denis > > > > > > > > > > > > [1]https://blog.rburchell.com/2011/11/avoiding-graphics-> > > > > > > > > > flicker-in-qt-> > qml.html> > > > > > > > > > > > {quote} > > > > > > > > > > > > > > This flickering present on some HDMI displays... > > > > > > > > > > > > > > We currently have this flags: > > > > > > > > > > > > > > {code} > > > > > > > ... > > > > > > > view.setFlags(Qt::FramelessWindowHint | > > > > > > > > Qt::WindowStaysOnTopHint); > > > > > > > > > > > ... > > > > > > > {code} > > > > > > > > > > > > > > Maybe is it an reasons of flikering? Has someone any ideas? > > > > > > > > > > > > > > BR, > > > > > > > Denis > > > > > > > _______________________________________________ > > > > > > > Development mailing list > > > > > > > Development at qt-project.org > > > project.org> > > > > > > > > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > > > -- > > > > 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 > > > > _______________________________________________ > > > > Development mailing list > > > > Development at qt-project.org > > > > http://lists.qt-project.org/mailman/listinfo/development > > > > -- > > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > > 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 -- 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 denis.shienkov at gmail.com Fri Aug 5 13:53:29 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 5 Aug 2016 14:53:29 +0300 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: <3665938.pz6XOfLHxi@cartman> References: <2360289.2QICv2mdQO@cartman> <3665938.pz6XOfLHxi@cartman> Message-ID: > I suggested to use an OpenGL example Pure Open GL example does not work at all (e.g. I tried Cube example).. I see only a black screen, and some of OpenGL textures errors. PS: I have crerated a bug https://bugreports.qt.io/browse/QTBUG-55162 (just in case) 2016-08-05 14:39 GMT+03:00 Sean Harmer : > I suggested to use an OpenGL example, not a Qt Quick one. We're trying to > isolate where the issue is in the stack. So use a single threaded, plain > OpenGL application with a 32 bit framebuffer and see if that gives the same > issue. > > Cheers, > > Sean > > On Friday 05 August 2016 14:22:00 Denis Shienkov wrote: > > So, I have compiled the standard Samehame QMML application from: > > > > /home/builder/Projects/qt5/qtdeclarative/examples/quick/demos/samegame/ > > > > and got same artifacts when I use RDBA=8888 mode. > > > > I have "screenshoot" of this flicking attifact: > > http://pasteboard.co/4XjMl3GNq.png > > > > I'm personally don't think that this is an NVidia's OpenGL ES2 bug... I > > think it is Qt bug... > > > > I'm not an OpenGL expert... so, can anybody point me what I need to do > with > > the Qt sources (where to look in)? > > > > Maybe I need to add some of gl_ functions to clear of content or > something > > else... but where? > > > > 2016-08-05 12:03 GMT+03:00 Sean Harmer : > > > On Friday 05 August 2016 12:02:10 Denis Shienkov wrote: > > > > > Can you try a plain OpenGL test application with RGBA8 framebuffer > > > > > > > > Do you mean: I should take any OpenGL application from the Qt > examples? > > > > > > And > > > > > > > to check there? > > > > > > You may need to modify it to explicitly request R8G8B8A8 using a > > > QSurfaceFormat but yes any of those should work to prove/disprove. > > > > > > Sean > > > > > > > 2016-08-05 11:53 GMT+03:00 Sean Harmer : > > > > > Hi, > > > > > > > > > > Can you try a plain OpenGL test application with RGBA8 framebuffer > and > > > > > > see > > > > > > > > if > > > > > that exhibits the same flashing/flickering problem. If so, it's a > > > > > driver/hardware issue. > > > > > > > > > > If you are forced into then using a 16-bit framebuffer, then you > can > > > > > > avoid > > > > > > > > the > > > > > banding by using dithering in your gradients. Either apply the > > > > > > dithering > > > > > > > > offline > > > > > and store the gradients as images or write a custom material that > > > > > > applies > > > > > > > > the > > > > > dithering in the fragment shader. > > > > > > > > > > Cheers, > > > > > > > > > > Sean > > > > > > > > > > On Friday 05 August 2016 08:12:59 Denis Shienkov wrote: > > > > > > Hi all, > > > > > > > > > > > > I have an idea how to avoid flickering, but I don't know about > > > > > > results: > > > > > > what if I will discard the Open GL support in favor to Quick2 > > > > > > render? > > > > > > > > > > > > I have read this documentation: http://doc.qt.io/ > QtQuick2DRenderer/ > > > > > > which says about the "Qt Quick 2D Renderer" module. > > > > > > > > > > > > So, my things is: > > > > > > > > > > > > 1. Download && build && install this module: > > > > > > > > > > > > git://code.qt.io/qt/qtdeclarative-render2d.git > > > > > > > > > > > > 2. Use this env variable: > > > > > > > > > > > > export QMLSCENE_DEVICE=softwarecontext > > > > > > > > > > > > 3. Run my app... > > > > > > > > > > > > > > > > > > But, I don't understand: > > > > > > > > > > > > 1) What of engine is used to 2D rendering in case if I have EGLFS > > > > > > only? > > > > > > > > > 2) Should I re-build Qt5 too with the "--no-opengl" option (or I > can > > > > > > keep the "-opengl es2" option) ? > > > > > > > > > > > > 04.08.2016 16:10, Denis Shienkov пишет: > > > > > > > Hi Robin, > > > > > > > > > > > > > > > Repeating my last answer... > > > > > > > > http://lists.qt-project.org/pipermail/development/2016-> > > > > > > > > > > > July/026736.html > > > > > > > > > > > > I'm sorry, but I did not receive (did not see) your last > answer. > > > > > > > > > > > > > > > I'm going to guess you're using eglfs or something like that > > > > > > > > > > > > > > Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are > used > > > > > > > NVIDIA's drivers. > > > > > > > > > > > > > > Seems, the flickering is when are used: > > > > > > > > > > > > > > export QT_QPA_EGLFS_FORCE888=1 > > > > > > > > > > > > > > ENV variable... (I need this variable to smooth the Image's > > > > > > > gradients... even X11 started with 24-bit depth). > > > > > > > > > > > > > > PS: But, I'm not sure about QT_QPA_EGLFS_FORCE888... :( > > > > > > > > > > > > > > > Using an overlay to debug item positions > > > > > > > > (QSG_VISUALIZE=overdraw) > > > > > > > > > > > > > > could be handy for trying to rule > > > > > > > this out, as if it is specific to the application, > > > > > > > > > > > > > > Ok, many thanks, I will try it. > > > > > > > > > > > > > > > > > > > > > 2016-08-04 14:57 GMT+03:00 Robin Burchell < > robin+qt at viroteck.net > > > > > > > > > > > > > > >: > > > > > > > Repeating my last answer... > > > > > > > > > > > > > > http://lists.qt-project.org/pipermail/development/2016-> > > > > > > > > > > > July/026736.htm > > > > > > > > > > > > l > > > > > > > > > > > > > > On Thu, Aug 4, 2016, at 01:50 PM, Denis Shienkov wrote: > > > > > > > > {quote} > > > > > > > > > > > > > > > > Hi all. > > > > > > > > > > > > > > > > I have some QML application, where just use QQuickView as > > > > > > > > QML > > > > > > > > > > > > > > container. > > > > > > > > > > > > > > > This application uses Qt 5.7.x and running on Linux > embedded > > > > > > > > > > > > > > board with > > > > > > > > > > > > > > > the > > > > > > > > NVIDIA core (Toradex Apalis T30). > > > > > > > > > > > > > > > > But sometimes I got flickering in process of animation. A > > > > > > > > > > flickering > > > > > > > > > > > > > represents in form of a "white" strips with full-screen > > > > > > > > width > > > > > > > > > > > > > > and 1/5-1/6 > > > > > > > > > > > > > > > screen heigth. This flickers happens quickly and > frequently > > > > > > > > > > > > > > (every ~20-60 > > > > > > > > > > > > > > > seconds, randomly)... > > > > > > > > > > > > > > > > I have seen this "Avoiding graphics flicker in Qt / QML" > [1] > > > > > > > > > > > > > > blog where > > > > > > > > > > > > > > > are > > > > > > > > used QML with Qt 4.x, > > > > > > > > where were used this trics: > > > > > > > > > > > > > > > > {code} > > > > > > > > int main(int argc, char **argv) > > > > > > > > { > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > view.setAttribute(Qt::WA_OpaquePaintEvent); > > > > > > > > view.setAttribute(Qt::WA_NoSystemBackground); > > > > > > > > view.viewport()->setAttribute(Qt::WA_OpaquePaintEvent); > > > > > > > > view.viewport()->setAttribute( > Qt::WA_NoSystemBackground); > > > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > } > > > > > > > > {code} > > > > > > > > > > > > > > > > But, in my case I have use Quick v2, with QQuickView > instead > > > > > > of > > > > > > > > > > > QDeclarativeView, > > > > > > > > which does not allowed to setup any attributes. > > > > > > > > > > > > > > > > So, my questions is: is there are any way to setup > > > > > > > > Qt::WA_OpaquePaintEvent > > > > > > > > and/or > > > > > > > > Qt::WA_NoSystemBackground in Quck2? Or, maybe is it > possible > > > > > > to > > > > > > > > use > > > > > > > > > > > > > another > > > > > > > > tricks? > > > > > > > > > > > > > > > > BR, > > > > > > > > Denis > > > > > > > > > > > > > > [1]https://blog.rburchell.com/2011/11/avoiding-graphics-> > > > > > > > > > > > > flicker-in-qt-> > qml.html> > > > > > > > > > > > > > {quote} > > > > > > > > > > > > > > > > This flickering present on some HDMI displays... > > > > > > > > > > > > > > > > We currently have this flags: > > > > > > > > > > > > > > > > {code} > > > > > > > > ... > > > > > > > > view.setFlags(Qt::FramelessWindowHint | > > > > > > > > > > Qt::WindowStaysOnTopHint); > > > > > > > > > > > > > ... > > > > > > > > {code} > > > > > > > > > > > > > > > > Maybe is it an reasons of flikering? Has someone any > ideas? > > > > > > > > > > > > > > > > BR, > > > > > > > > Denis > > > > > > > > _______________________________________________ > > > > > > > > Development mailing list > > > > > > > > Development at qt-project.org > > > > > project.org> > > > > > > > > > > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > > > > > -- > > > > > 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 > > > > > _______________________________________________ > > > > > Development mailing list > > > > > Development at qt-project.org > > > > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > -- > > > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > > > 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 > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Fri Aug 5 14:56:08 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 5 Aug 2016 15:56:08 +0300 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: References: <2360289.2QICv2mdQO@cartman> <3665938.pz6XOfLHxi@cartman> Message-ID: >> I suggested to use an OpenGL example > Pure Open GL example does not work at all (e.g. I tried Cube example).. I see only a black screen, and some of OpenGL textures errors. Also I have tried to use an ContextInfo example, where it is possible to choose an OpenGL or OpenGL ES. 1. So, when it is selected OpenGL, then app says that it is impossible to create a context: {quote} Requesting surface format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 16, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior 0, swapInterval 1, profile 0) Cannot find EGLConfig, returning null config QEGLPlatformContext: Failed to create context: 3005 {quote} 2. So, when it is selected OpenGL ES, then app crashed: {quote} Requesting surface format QSurfaceFormat(version 2.0, options QFlags(), depthBufferSize 16, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize -1, samples -1, swapBehavior 0, swapInterval 1, profile 0) EGLFS: OpenGL windows cannot be mixed with others. sh: line 1: 1842 Aborted DISPLAY=':0.0' /home/root/deploy-apps/contextinfo Application finished with exit code 134. {quote} So, it is impossible for me check it with pure OpenGL at all.. 2016-08-05 14:53 GMT+03:00 Denis Shienkov : > > I suggested to use an OpenGL example > > Pure Open GL example does not work at all (e.g. I tried Cube example).. I > see only a black screen, and some of OpenGL textures errors. > > PS: I have crerated a bug https://bugreports.qt.io/browse/QTBUG-55162 > (just in case) > > 2016-08-05 14:39 GMT+03:00 Sean Harmer : > >> I suggested to use an OpenGL example, not a Qt Quick one. We're trying to >> isolate where the issue is in the stack. So use a single threaded, plain >> OpenGL application with a 32 bit framebuffer and see if that gives the >> same >> issue. >> >> Cheers, >> >> Sean >> >> On Friday 05 August 2016 14:22:00 Denis Shienkov wrote: >> > So, I have compiled the standard Samehame QMML application from: >> > >> > /home/builder/Projects/qt5/qtdeclarative/examples/quick/demos/samegame/ >> > >> > and got same artifacts when I use RDBA=8888 mode. >> > >> > I have "screenshoot" of this flicking attifact: >> > http://pasteboard.co/4XjMl3GNq.png >> > >> > I'm personally don't think that this is an NVidia's OpenGL ES2 bug... I >> > think it is Qt bug... >> > >> > I'm not an OpenGL expert... so, can anybody point me what I need to do >> with >> > the Qt sources (where to look in)? >> > >> > Maybe I need to add some of gl_ functions to clear of content or >> something >> > else... but where? >> > >> > 2016-08-05 12:03 GMT+03:00 Sean Harmer : >> > > On Friday 05 August 2016 12:02:10 Denis Shienkov wrote: >> > > > > Can you try a plain OpenGL test application with RGBA8 framebuffer >> > > > >> > > > Do you mean: I should take any OpenGL application from the Qt >> examples? >> > > >> > > And >> > > >> > > > to check there? >> > > >> > > You may need to modify it to explicitly request R8G8B8A8 using a >> > > QSurfaceFormat but yes any of those should work to prove/disprove. >> > > >> > > Sean >> > > >> > > > 2016-08-05 11:53 GMT+03:00 Sean Harmer : >> > > > > Hi, >> > > > > >> > > > > Can you try a plain OpenGL test application with RGBA8 >> framebuffer and >> > > >> > > see >> > > >> > > > > if >> > > > > that exhibits the same flashing/flickering problem. If so, it's a >> > > > > driver/hardware issue. >> > > > > >> > > > > If you are forced into then using a 16-bit framebuffer, then you >> can >> > > >> > > avoid >> > > >> > > > > the >> > > > > banding by using dithering in your gradients. Either apply the >> > > >> > > dithering >> > > >> > > > > offline >> > > > > and store the gradients as images or write a custom material that >> > > >> > > applies >> > > >> > > > > the >> > > > > dithering in the fragment shader. >> > > > > >> > > > > Cheers, >> > > > > >> > > > > Sean >> > > > > >> > > > > On Friday 05 August 2016 08:12:59 Denis Shienkov wrote: >> > > > > > Hi all, >> > > > > > >> > > > > > I have an idea how to avoid flickering, but I don't know about >> > > >> > > results: >> > > > > > what if I will discard the Open GL support in favor to Quick2 >> > > > > > render? >> > > > > > >> > > > > > I have read this documentation: http://doc.qt.io/QtQuick2DRend >> erer/ >> > > > > > which says about the "Qt Quick 2D Renderer" module. >> > > > > > >> > > > > > So, my things is: >> > > > > > >> > > > > > 1. Download && build && install this module: >> > > > > > >> > > > > > git://code.qt.io/qt/qtdeclarative-render2d.git >> > > > > > >> > > > > > 2. Use this env variable: >> > > > > > >> > > > > > export QMLSCENE_DEVICE=softwarecontext >> > > > > > >> > > > > > 3. Run my app... >> > > > > > >> > > > > > >> > > > > > But, I don't understand: >> > > > > > >> > > > > > 1) What of engine is used to 2D rendering in case if I have >> EGLFS >> > > >> > > only? >> > > >> > > > > > 2) Should I re-build Qt5 too with the "--no-opengl" option (or >> I can >> > > > > > keep the "-opengl es2" option) ? >> > > > > > >> > > > > > 04.08.2016 16:10, Denis Shienkov пишет: >> > > > > > > Hi Robin, >> > > > > > > >> > > > > > > > Repeating my last answer... >> > > > > > > > http://lists.qt-project.org/pipermail/development/2016-> > >> > > > > >> > > > > July/026736.html >> > > > > >> > > > > > > I'm sorry, but I did not receive (did not see) your last >> answer. >> > > > > > > >> > > > > > > > I'm going to guess you're using eglfs or something like that >> > > > > > > >> > > > > > > Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are >> used >> > > > > > > NVIDIA's drivers. >> > > > > > > >> > > > > > > Seems, the flickering is when are used: >> > > > > > > >> > > > > > > export QT_QPA_EGLFS_FORCE888=1 >> > > > > > > >> > > > > > > ENV variable... (I need this variable to smooth the Image's >> > > > > > > gradients... even X11 started with 24-bit depth). >> > > > > > > >> > > > > > > PS: But, I'm not sure about QT_QPA_EGLFS_FORCE888... :( >> > > > > > > >> > > > > > > > Using an overlay to debug item positions >> > > > > > > > (QSG_VISUALIZE=overdraw) >> > > > > > > >> > > > > > > could be handy for trying to rule >> > > > > > > this out, as if it is specific to the application, >> > > > > > > >> > > > > > > Ok, many thanks, I will try it. >> > > > > > > >> > > > > > > >> > > > > > > 2016-08-04 14:57 GMT+03:00 Robin Burchell < >> robin+qt at viroteck.net >> > > > > > > >> > > > > > > >: >> > > > > > > Repeating my last answer... >> > > > > > > >> > > > > > > http://lists.qt-project.org/pipermail/development/2016-> >> > >> > > > > >> > > > > July/026736.htm >> > > > > >> > > > > > > l >> > > > > > > >> > > > > > > On Thu, Aug 4, 2016, at 01:50 PM, Denis Shienkov wrote: >> > > > > > > > {quote} >> > > > > > > > >> > > > > > > > Hi all. >> > > > > > > > >> > > > > > > > I have some QML application, where just use QQuickView >> as >> > > > > > > > QML >> > > > > > > >> > > > > > > container. >> > > > > > > >> > > > > > > > This application uses Qt 5.7.x and running on Linux >> embedded >> > > > > > > >> > > > > > > board with >> > > > > > > >> > > > > > > > the >> > > > > > > > NVIDIA core (Toradex Apalis T30). >> > > > > > > > >> > > > > > > > But sometimes I got flickering in process of animation. >> A >> > > > > >> > > > > flickering >> > > > > >> > > > > > > > represents in form of a "white" strips with full-screen >> > > > > > > > width >> > > > > > > >> > > > > > > and 1/5-1/6 >> > > > > > > >> > > > > > > > screen heigth. This flickers happens quickly and >> frequently >> > > > > > > >> > > > > > > (every ~20-60 >> > > > > > > >> > > > > > > > seconds, randomly)... >> > > > > > > > >> > > > > > > > I have seen this "Avoiding graphics flicker in Qt / >> QML" [1] >> > > > > > > >> > > > > > > blog where >> > > > > > > >> > > > > > > > are >> > > > > > > > used QML with Qt 4.x, >> > > > > > > > where were used this trics: >> > > > > > > > >> > > > > > > > {code} >> > > > > > > > int main(int argc, char **argv) >> > > > > > > > { >> > > > > > > > >> > > > > > > > ... >> > > > > > > > >> > > > > > > > view.setAttribute(Qt::WA_OpaquePaintEvent); >> > > > > > > > view.setAttribute(Qt::WA_NoSystemBackground); >> > > > > > > > view.viewport()->setAttribute( >> Qt::WA_OpaquePaintEvent); >> > > > > > > > view.viewport()->setAttribute( >> Qt::WA_NoSystemBackground); >> > > > > > > > >> > > > > > > > ... >> > > > > > > > >> > > > > > > > } >> > > > > > > > {code} >> > > > > > > > >> > > > > > > > But, in my case I have use Quick v2, with QQuickView >> instead >> > > >> > > of >> > > >> > > > > > > > QDeclarativeView, >> > > > > > > > which does not allowed to setup any attributes. >> > > > > > > > >> > > > > > > > So, my questions is: is there are any way to setup >> > > > > > > > Qt::WA_OpaquePaintEvent >> > > > > > > > and/or >> > > > > > > > Qt::WA_NoSystemBackground in Quck2? Or, maybe is it >> possible >> > > >> > > to >> > > >> > > > > use >> > > > > >> > > > > > > > another >> > > > > > > > tricks? >> > > > > > > > >> > > > > > > > BR, >> > > > > > > > Denis >> > > > > > > >> > > > > > > [1]https://blog.rburchell.com/2011/11/avoiding-graphics-> >> > >> > > > > >> > > > > flicker-in-qt-> > qml.html> >> > > > > >> > > > > > > > {quote} >> > > > > > > > >> > > > > > > > This flickering present on some HDMI displays... >> > > > > > > > >> > > > > > > > We currently have this flags: >> > > > > > > > >> > > > > > > > {code} >> > > > > > > > ... >> > > > > > > > view.setFlags(Qt::FramelessWindowHint | >> > > > > >> > > > > Qt::WindowStaysOnTopHint); >> > > > > >> > > > > > > > ... >> > > > > > > > {code} >> > > > > > > > >> > > > > > > > Maybe is it an reasons of flikering? Has someone any >> ideas? >> > > > > > > > >> > > > > > > > BR, >> > > > > > > > Denis >> > > > > > > > _______________________________________________ >> > > > > > > > Development mailing list >> > > > > > > > Development at qt-project.org > > > >> > > project.org> >> > > >> > > > > > > > http://lists.qt-project.org/ma >> ilman/listinfo/development >> > > > > >> > > > > -- >> > > > > 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 >> > > > > _______________________________________________ >> > > > > Development mailing list >> > > > > Development at qt-project.org >> > > > > http://lists.qt-project.org/mailman/listinfo/development >> > > >> > > -- >> > > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK >> > > 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 >> >> -- >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangelog at gmail.com Fri Aug 5 15:16:03 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Fri, 5 Aug 2016 15:16:03 +0200 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: References: <2360289.2QICv2mdQO@cartman> <3665938.pz6XOfLHxi@cartman> Message-ID: On Fri, Aug 5, 2016 at 2:56 PM, Denis Shienkov wrote: > EGLFS: OpenGL windows cannot be mixed with others. Just change example, as you picked one which uses multiple TLWs... -- Giuseppe D'Angelo From denis.shienkov at gmail.com Fri Aug 5 15:47:07 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 5 Aug 2016 16:47:07 +0300 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: References: <2360289.2QICv2mdQO@cartman> <3665938.pz6XOfLHxi@cartman> Message-ID: > Just change example, as you picked one which uses multiple TLWs... I haven't found an example which works with the OpenGL ES2. I have tried "hellogles3" application, but it failed too. UPD: When I use RGBA8888 in QML, then I see following debug messages: {quote} qt.scenegraph.general: animation driver switched to timer mode qt.scenegraph.general: animation driver switched to vsync mode qt.scenegraph.general: animation driver switched to timer mode qt.scenegraph.general: animation driver switched to vsync mode qt.scenegraph.general: animation driver switched to timer mode {quote} is it normal? 2016-08-05 16:16 GMT+03:00 Giuseppe D'Angelo : > On Fri, Aug 5, 2016 at 2:56 PM, Denis Shienkov > wrote: > > EGLFS: OpenGL windows cannot be mixed with others. > > Just change example, as you picked one which uses multiple TLWs... > > -- > Giuseppe D'Angelo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Fri Aug 5 16:21:22 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 5 Aug 2016 17:21:22 +0300 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: References: <2360289.2QICv2mdQO@cartman> <3665938.pz6XOfLHxi@cartman> Message-ID: UPD: Now, I have running the qopenglwindow example application with QT_QPA_EGLFS_FORCE888=1 and see that flickering artifacts occurred sometimes. It is an interest moment, that without QT_QPA_EGLFS_FORCE888, the OpenGL draws the rectangle more slowly. 2016-08-05 16:47 GMT+03:00 Denis Shienkov : > > Just change example, as you picked one which uses multiple TLWs... > > I haven't found an example which works with the OpenGL ES2. I have tried > "hellogles3" application, but it failed too. > > UPD: When I use RGBA8888 in QML, then I see following debug messages: > > {quote} > qt.scenegraph.general: animation driver switched to timer mode > qt.scenegraph.general: animation driver switched to vsync mode > qt.scenegraph.general: animation driver switched to timer mode > qt.scenegraph.general: animation driver switched to vsync mode > qt.scenegraph.general: animation driver switched to timer mode > {quote} > > is it normal? > > > > 2016-08-05 16:16 GMT+03:00 Giuseppe D'Angelo : > >> On Fri, Aug 5, 2016 at 2:56 PM, Denis Shienkov >> wrote: >> > EGLFS: OpenGL windows cannot be mixed with others. >> >> Just change example, as you picked one which uses multiple TLWs... >> >> -- >> Giuseppe D'Angelo >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From louai.al-khanji at qt.io Fri Aug 5 19:11:33 2016 From: louai.al-khanji at qt.io (Louai Al-Khanji) Date: Fri, 5 Aug 2016 17:11:33 +0000 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: References: <1470311864.417285.685842217.63CDB906@webmail.messagingengine.com> Message-ID: <75E2CDCD-FC5C-47A0-9CC2-57962DF55477@qt.io> > On Aug 4, 2016, at 6:10 AM, Denis Shienkov wrote: > > I'm going to guess you're using eglfs or something like that > > Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are used NVIDIA's drivers. > Can you try the regular xcb qpa plugin and see whether that has the same behavior? Cheers, Louai -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3577 bytes Desc: not available URL: From erik at ortogonal.com Sat Aug 6 08:31:30 2016 From: erik at ortogonal.com (Erik Larsson) Date: Sat, 6 Aug 2016 08:31:30 +0200 Subject: [Development] Nominating Johan Helsing for Approver status In-Reply-To: References: Message-ID: +1 2016-08-04 12:22 GMT+02:00 Paul Tvete : > Hi all, > > > I'd like to nominate Johan Helsing for Approver status. He joined The Qt > Company half a year ago, and has been working full time on Qt since. Johan > has been actively involved in making the QtWaylandCompositor module ready > for Qt 5.8, as well as doing a major part of the bug fixes for Qt Wayland > in 5.6 and 5.7. > > Here is his gerrit dashboard: > > https://codereview.qt-project.org/#/q/owner:%22Johan+Helsing%22,n,z > > Johan's list of reviews can be found at: > > https://codereview.qt-project.org/#/q/reviewer:%22Johan+ > Helsing+%253Cjohan.helsing%2540theqtcompany.com%253E%22,p,003e6e7d0002807d > > Cheers, > > - Paul > > > _______________________________________________ > 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 giuliocamuffo at gmail.com Mon Aug 8 09:14:55 2016 From: giuliocamuffo at gmail.com (Giulio Camuffo) Date: Mon, 8 Aug 2016 09:14:55 +0200 Subject: [Development] Nominating Johan Helsing for Approver status In-Reply-To: References: Message-ID: +1 2016-08-06 8:31 GMT+02:00 Erik Larsson : > +1 > > 2016-08-04 12:22 GMT+02:00 Paul Tvete : >> >> Hi all, >> >> >> I'd like to nominate Johan Helsing for Approver status. He joined The Qt >> Company half a year ago, and has been working full time on Qt since. Johan >> has been actively involved in making the QtWaylandCompositor module ready >> for Qt 5.8, as well as doing a major part of the bug fixes for Qt Wayland in >> 5.6 and 5.7. >> >> Here is his gerrit dashboard: >> >> https://codereview.qt-project.org/#/q/owner:%22Johan+Helsing%22,n,z >> >> Johan's list of reviews can be found at: >> >> >> https://codereview.qt-project.org/#/q/reviewer:%22Johan+Helsing+%253Cjohan.helsing%2540theqtcompany.com%253E%22,p,003e6e7d0002807d >> >> Cheers, >> >> - Paul >> >> >> _______________________________________________ >> 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 jani.heikkinen at qt.io Mon Aug 8 12:57:30 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 8 Aug 2016 10:57:30 +0000 Subject: [Development] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming... Message-ID: Hi all, Qt5.git integration in 'dev' succeed during the weekend and we have soft branched '5.8' from 'dev'. It means Qt 5.8 Feature Freeze will be effect 15th August 2016 as well as final branching from 'dev' to '5.8' So please start using '5.8' for changes targeted to Qt 5.8 release and finalize ongoing ones in 'dev'. Final downmerge from 'dev' to '5.8' will happen Monday 15th Aug (morning). Please make sure - All new modules for Qt 5.8 are in 'dev' & part of qt5.git - All mandatory new features are in 'dev' now or coming in within a week? - New feature page contains all new features etc: https://wiki.qt.io/New_Features_in_Qt_5.8 We will create first src packages from latest qt5.git integration as soon as possible. Please check the packages immediately when available to see if something important is missing. Those packages should be quite close to Qt 5.8 alpha packages so it will be really important to check the packages now. br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Mon Aug 8 13:05:09 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Mon, 8 Aug 2016 14:05:09 +0300 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: <75E2CDCD-FC5C-47A0-9CC2-57962DF55477@qt.io> References: <1470311864.417285.685842217.63CDB906@webmail.messagingengine.com> <75E2CDCD-FC5C-47A0-9CC2-57962DF55477@qt.io> Message-ID: > Can you try the regular xcb qpa plugin and see whether that has the same behavior? Yes, I have tested it with XCB and see the same issue. But only when I use fullScreen() or resize(w, h), where 'w' and 'h' it is native screen size. BUT: If I use resize(w, h+1) or resize(w, h-1), then, seems I do not see any flickers. 2016-08-05 20:11 GMT+03:00 Louai Al-Khanji : > > > On Aug 4, 2016, at 6:10 AM, Denis Shienkov > wrote: > > > I'm going to guess you're using eglfs or something like that > > > > Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are used > NVIDIA's drivers. > > > > Can you try the regular xcb qpa plugin and see whether that has the same > behavior? > > Cheers, > Louai > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmartens at gmail.com Mon Aug 8 16:04:10 2016 From: rmartens at gmail.com (Rob Martens) Date: Mon, 8 Aug 2016 09:04:10 -0500 Subject: [Development] QT Touch Handling Bug Message-ID: I'm relatively sure this problem exposes a bug in qevdevtouchhandler.cpp. I sometimes get a 0 reported from a touch event when I know the locations from the driver never included a 0. I hope someone with experience in QEvdevTouchScreenData::processInputEvent would look at it and see if this isn't the case. Thanks, Rob Problem Summary Driver: FocalTech ft5x06 TouchScreen driver. ft5x06_ts.c QT Code: qevdevtouchhandler.cpp, within libQt5EglDeviceIntegration.so.5.5.0 Configuration: type A processing (or not B type) single touch is true Description of problem: When QEvdevTouchScreenData::processInputEvent gets the following (see below) set of events an invalid touch location (always zero) is reported to the qt Window. You can see below the full output trace (no other events occurred). When QT is processing the input events the second touch up reports the y as 0, which is wrong. The patterns seems to be the following. When QT doesn't get a ABS_Y location after the last BTN_TOUCH Down, it reports y as 0 which is incorrect. This always happens when y or x does not change between touches. So if a user happens to touch in the same spot (like on a button) the second click may not register. Is this a problem with QT not keeping the previous Y or X location and using that or is it a problem with the driver not reporting the X or Y location after the touch down event? This is an annoying problem because it means that on screens button presses are randomly missed. QEvdevTouchScreenData::processInputEvent EV_KEY, BTN_TOUCH, 1 DOWN ****** QEvdevTouchScreenData::processInputEvent EV_ABS, ABS_X, 334 QEvdevTouchScreenData::processInputEvent EV_ABS, ABS_Y, 174 QEvdevTouchScreenData::processInputEvent EV_ABS, ABS_PRESSURE, 100 QEvdevTouchScreenData::processInputEvent EV_SYN, SYN_REPORT, 0 QEvdevTouchScreenData::addTouchPoint tp.rawPositions.append(QPointF(334, 174)); QEvdevTouchScreenData::processInputEvent reportPoints() QWindowSystemInterface::handleTouchEvent m_touchPoints.count()=1 1 x=0.695833 y=0.639706 QEvdevTouchScreenData::processInputEvent EV_KEY, BTN_TOUCH, 0 UP QEvdevTouchScreenData::processInputEvent EV_ABS, ABS_PRESSURE, 0 QEvdevTouchScreenData::processInputEvent EV_SYN, SYN_REPORT, 0 QEvdevTouchScreenData::addTouchPoint tp.rawPositions.append(QPointF(334, 174)); QEvdevTouchScreenData::processInputEvent reportPoints() QWindowSystemInterface::handleTouchEvent m_touchPoints.count()=1 1 x=0.695833 y=0.639706 QEvdevTouchScreenData::processInputEvent EV_KEY, BTN_TOUCH, 1 DOWN *************** QEvdevTouchScreenData::processInputEvent EV_ABS, ABS_X, 336 >>>>>>>>>>>>>>>>>>>>>>>>>> NOTICE Y not reported because it is the same location as before QEvdevTouchScreenData::processInputEvent EV_ABS, ABS_PRESSURE, 100 QEvdevTouchScreenData::processInputEvent EV_SYN, SYN_REPORT, 0 QEvdevTouchScreenData::addTouchPoint tp.rawPositions.append(QPointF(336, 0 )); QEvdevTouchScreenData::processInputEvent reportPoints() QWindowSystemInterface::handleTouchEvent m_touchPoints.count()=1 1 0.700000 0.000000 QEvdevTouchScreenData::processInputEvent EV_KEY, BTN_TOUCH, 0 UP QEvdevTouchScreenData::processInputEvent EV_ABS, ABS_PRESSURE, 0 QEvdevTouchScreenData::processInputEvent EV_SYN, SYN_REPORT, 0 QEvdevTouchScreenData::addTouchPoint tp.rawPositions.append(QPointF(336, 0 )); QWindowSystemInterface::handleTouchEvent m_touchPoints.count()=1 1 x=0.700000 y=0.000000 DTS for ft5x06 dts ft5x06_ts at 38 { compatible = "focaltech,5x06"; reg = <0x38>; focaltech,family-id = <0x55>; pinctrl-names = "default"; pinctrl-0 = <&ctw6120_pins>; interrupt-parent = <&gpio0>; interrupts = <3 IRQ_TYPE_EDGE_FALLING>; vdd-supply = <&touch_3v3_regulator>; vcc_i2c-supply = <&touch_3v3_regulator>; focaltech,irq-gpio = <&gpio0 3 0x00>; focaltech,display-coords = <0 0 480 272>; focaltech,name = "ft6x06"; focaltech,no-force-update; focaltech,group-id = <1>; focaltech,hard-reset-delay-ms = <20>; focaltech,soft-reset-delay-ms = <150>; focaltech,num-max-touches = <1>; focaltech,fw-name = "ft_8610_qrd_fw.bin"; focaltech,fw-delay-aa-ms = <100>; focaltech,fw-delay-55-ms = <30>; focaltech,fw-upgrade-id1 = <0x79>; focaltech,fw-upgrade-id2 = <0x08>; focaltech,fw-delay-readid-ms = <10>; focaltech,fw-delay-era-flsh-ms = <2000>; focaltech,fw-auto-cal; //focaltech,mirror_h; //focaltech,mirror_v; }; -- Rob Martens -------------- next part -------------- An HTML attachment was scrubbed... URL: From announce at qt-project.org Mon Aug 8 11:55:32 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Mon, 8 Aug 2016 09:55:32 +0000 Subject: [Development] [Announce] Qt Creator 4.1 RC1 released Message-ID: We are pleased to announce the release of Qt Creator 4.1.0 RC1! http://blog.qt.io/blog/2016/08/08/qt-creator-4-1-rc1-released/ Br, -- Alessandro Portale Senior Manager, R&D The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin alessandro.portale at qt.io +123 45 6789012 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -------------- 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 denis.shienkov at gmail.com Mon Aug 8 18:03:21 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Mon, 8 Aug 2016 19:03:21 +0300 Subject: [Development] [QML] Avoiding graphics flicker in Quick2 In-Reply-To: References: <1470311864.417285.685842217.63CDB906@webmail.messagingengine.com> <75E2CDCD-FC5C-47A0-9CC2-57962DF55477@qt.io> Message-ID: > BUT: If I use resize(w, h+1) or resize(w, h-1), then, seems I do not see any flickers. Sorry, but with XCB also flickered. :( 2016-08-08 14:05 GMT+03:00 Denis Shienkov : > > Can you try the regular xcb qpa plugin and see whether that has the same > behavior? > > Yes, I have tested it with XCB and see the same issue. But only when I use > fullScreen() or resize(w, h), where 'w' and 'h' it is native screen size. > > BUT: If I use resize(w, h+1) or resize(w, h-1), then, seems I do not see > any flickers. > > > 2016-08-05 20:11 GMT+03:00 Louai Al-Khanji : > >> >> > On Aug 4, 2016, at 6:10 AM, Denis Shienkov >> wrote: >> > > I'm going to guess you're using eglfs or something like that >> > >> > Yes, I use EGLFS via X11 on Linux Apalis T30 board, where are used >> NVIDIA's drivers. >> > >> >> Can you try the regular xcb qpa plugin and see whether that has the same >> behavior? >> >> Cheers, >> Louai >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From announce at qt-project.org Mon Aug 8 20:47:20 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Mon, 8 Aug 2016 18:47:20 +0000 Subject: [Development] [Announce] Qt Creator 4.1 RC1 released (second attempt) Message-ID: (Sorry for the noise. My previous mail contained an incorrect link) We are pleased to announce the release of Qt Creator 4.1.0 RC1! http://blog.qt.io/blog/2016/08/08/qt-creator-4-1-rc1-released/ Br,  --  Alessandro Portale Senior Manager, R&D The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin alessandro.portale at qt.io +123 45 6789012 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From lars.knoll at qt.io Tue Aug 9 17:00:07 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 9 Aug 2016 15:00:07 +0000 Subject: [Development] Staging stuff Message-ID: <5E73459F-97D6-427F-AF50-94CF37ADF938@qt.io> Hi everybody, as we're getting close to feature freeze, there's the usual issue of getting the remaining features that we're hoping to have for 5.8 integrated. There were a couple of integrations failing today because of cleanup commits, something that can be extremely frustrating right now. Because of that, I'd like to ask everybody to not stage things right now that can easily wait until after 5.8. Thanks, Lars From lorn.potter at canonical.com Wed Aug 10 23:18:46 2016 From: lorn.potter at canonical.com (Lorn Potter) Date: Thu, 11 Aug 2016 07:18:46 +1000 Subject: [Development] out of date license headers in non supported modules Message-ID: <18869ce7-bfa3-b966-dd34-b9180f1a672e@canonical.com> Hello, Is there someone who has a script for updating license headers that can release this, or make it known? Or, alternatively, update the license headers or make the license test not run on non supported modules for integrations? Trying to upstream some stuff: Module "qt/qtsystems" (a1509631b047285239fcadbcf44d425d94e329d0) Failed test(s): license: agent:2016/08/10 13:16:31 build.go:298: Executing instruction 13 of 13 agent:2016/08/10 13:16:31 build.go:321: [perl qt/qtqa-latest/tests/prebuild/license/tst_licenses.pl] 1200 1..252 ok 1 - config.tests/bluez/main.cpp ok 2 - config.tests/gconf/main.cpp ok 3 - config.tests/mir/main.cpp ok 4 - config.tests/udev/main.cpp ok 5 - config.tests/x11/main.cpp Old license being used for doc/src/publishsubscribe/examples/battery-charge.qdoc. ok 6 - doc/src/publishsubscribe/examples/battery-charge.qdoc Old license being used for doc/src/publishsubscribe/examples/examples-publishsubscribe.qdoc. ... Also, What exactly does this mean? These are new files. Where is the reference text to use? not ok 69 - License text and reference text have different number of lines in src/imports/systeminfo/qdeclarativeinputdevicemodel.cpp # Failed test 'License text and reference text have different number of lines in src/imports/systeminfo/qdeclarativeinputdevicemodel.cpp' # at qt/qtqa-latest/tests/prebuild/license/tst_licenses.pl line 395. thanks- Lorn -- Software Engineer System Enablement, Canonical Ltd QtSystemInfo, QtSensors maintainer From sahumada at texla.cl Wed Aug 10 23:35:06 2016 From: sahumada at texla.cl (Sergio Ahumada) Date: Wed, 10 Aug 2016 23:35:06 +0200 Subject: [Development] out of date license headers in non supported modules In-Reply-To: <18869ce7-bfa3-b966-dd34-b9180f1a672e@canonical.com> References: <18869ce7-bfa3-b966-dd34-b9180f1a672e@canonical.com> Message-ID: On 10.08.2016 23:18, Lorn Potter wrote: > Hello, > Is there someone who has a script for updating license headers that can > release this, or make it known? Or, alternatively, update the license > headers or make the license test not run on non supported modules for > integrations? to exclude it, add your module here: http://code.qt.io/cgit/qt/qtqa.git/tree/tests/prebuild/license/tst_licenses.pl#n70 > Trying to upstream some stuff: > > Module "qt/qtsystems" (a1509631b047285239fcadbcf44d425d94e329d0) Failed > test(s): license: > agent:2016/08/10 13:16:31 build.go:298: Executing instruction 13 of 13 > agent:2016/08/10 13:16:31 build.go:321: [perl > qt/qtqa-latest/tests/prebuild/license/tst_licenses.pl] 1200 > 1..252 > ok 1 - config.tests/bluez/main.cpp > ok 2 - config.tests/gconf/main.cpp > ok 3 - config.tests/mir/main.cpp > ok 4 - config.tests/udev/main.cpp > ok 5 - config.tests/x11/main.cpp > Old license being used for > doc/src/publishsubscribe/examples/battery-charge.qdoc. > ok 6 - doc/src/publishsubscribe/examples/battery-charge.qdoc > Old license being used for > doc/src/publishsubscribe/examples/examples-publishsubscribe.qdoc. probably using http://code.qt.io/cgit/qt/qtbase.git/tree/header.BSD-OLD?h=dev instead of http://code.qt.io/cgit/qt/qtbase.git/tree/header.BSD?h=dev > Also, What exactly does this mean? These are new files. Where is the > reference text to use? eg: http://code.qt.io/cgit/qt/qtbase.git/tree/header.LGPL?h=dev > not ok 69 - License text and reference text have different number of > lines in src/imports/systeminfo/qdeclarativeinputdevicemodel.cpp > # Failed test 'License text and reference text have different number > of lines in src/imports/systeminfo/qdeclarativeinputdevicemodel.cpp' > # at qt/qtqa-latest/tests/prebuild/license/tst_licenses.pl line 395. yours has 41 lines and the reference only 38 http://code.qt.io/cgit/qt/qtbase.git/tree/header.LGPL?h=dev > > thanks- > Lorn > > -- Sergio Ahumada sahumada at texla.cl From lorn.potter at canonical.com Thu Aug 11 00:42:06 2016 From: lorn.potter at canonical.com (Lorn Potter) Date: Thu, 11 Aug 2016 08:42:06 +1000 Subject: [Development] out of date license headers in non supported modules In-Reply-To: References: <18869ce7-bfa3-b966-dd34-b9180f1a672e@canonical.com> Message-ID: <10460355.ATgHbUbhKM@lpotter-inspiron-2350> Thanks for that. On Wednesday, 10 August 2016 11:35:06 PM AEST Sergio Ahumada wrote: > yours has 41 lines and the reference only 38 > http://code.qt.io/cgit/qt/qtbase.git/tree/header.LGPL?h=dev Ok, so how to deal with files that have multiple copyright holders? -- Software Engineer System Enablement, Canonical QtSensors, QtSystemInfo Maintainer From thiago.macieira at intel.com Thu Aug 11 02:08:22 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 10 Aug 2016 17:08:22 -0700 Subject: [Development] out of date license headers in non supported modules In-Reply-To: <10460355.ATgHbUbhKM@lpotter-inspiron-2350> References: <18869ce7-bfa3-b966-dd34-b9180f1a672e@canonical.com> <10460355.ATgHbUbhKM@lpotter-inspiron-2350> Message-ID: <3075594.rHLGe5ftzI@tjmaciei-mobl1> On quinta-feira, 11 de agosto de 2016 08:42:06 PDT Lorn Potter wrote: > Thanks for that. > > On Wednesday, 10 August 2016 11:35:06 PM AEST Sergio Ahumada wrote: > > yours has 41 lines and the reference only 38 > > http://code.qt.io/cgit/qt/qtbase.git/tree/header.LGPL?h=dev > > Ok, so how to deal with files that have multiple copyright holders? Only the lines between QT_BEGIN_LICENSE and QT_END_LICENSE count. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Thu Aug 11 09:46:28 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 11 Aug 2016 07:46:28 +0000 Subject: [Development] out of date license headers in non supported modules In-Reply-To: <3075594.rHLGe5ftzI@tjmaciei-mobl1> References: <18869ce7-bfa3-b966-dd34-b9180f1a672e@canonical.com> <10460355.ATgHbUbhKM@lpotter-inspiron-2350> <3075594.rHLGe5ftzI@tjmaciei-mobl1> Message-ID: <2197A5C5-0936-4AC4-9C11-D7DFAAD98D47@qt.io> On 11/08/16 02:08, "Development on behalf of Thiago Macieira" wrote: >On quinta-feira, 11 de agosto de 2016 08:42:06 PDT Lorn Potter wrote: >> Thanks for that. >> >> On Wednesday, 10 August 2016 11:35:06 PM AEST Sergio Ahumada wrote: >> > yours has 41 lines and the reference only 38 >> > http://code.qt.io/cgit/qt/qtbase.git/tree/header.LGPL?h=dev >> >> Ok, so how to deal with files that have multiple copyright holders? > >Only the lines between QT_BEGIN_LICENSE and QT_END_LICENSE count. Afaik, Jani has a script that can help getting these updated. Cheers, Lars From mardy at users.sourceforge.net Thu Aug 11 10:22:36 2016 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Thu, 11 Aug 2016 11:22:36 +0300 Subject: [Development] Proposal: change QML Flickable's flickableDirection default value to AutoFlickIfNeeded in 5.8 In-Reply-To: References: Message-ID: <5973ca2a-bfdf-c2e6-a3ad-8df7ca05ba50@users.sourceforge.net> On 07/26/2016 05:12 PM, Andrea Bernabei wrote: > I'd like to propose changing the default value of QML Flickable's > flickableDirection in Qt 5.8. I vote against it :-) While I agree that your proposal makes sense, I would advise against implementing it before Qt 6. There are lots of programs out there using Flickable, and we don't know how this change will affect them. For instance, one application might be monitoring the "dragging" property and perform some action when it changes, and after your proposal is implemented it will stop receiving it. I'm especially thinking of "pull to refresh" implementations, which might completely stop working. Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! From jani.heikkinen at qt.io Thu Aug 11 11:50:50 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 11 Aug 2016 09:50:50 +0000 Subject: [Development] out of date license headers in non supported modules In-Reply-To: <2197A5C5-0936-4AC4-9C11-D7DFAAD98D47@qt.io> References: <18869ce7-bfa3-b966-dd34-b9180f1a672e@canonical.com> <10460355.ATgHbUbhKM@lpotter-inspiron-2350> <3075594.rHLGe5ftzI@tjmaciei-mobl1>, <2197A5C5-0936-4AC4-9C11-D7DFAAD98D47@qt.io> Message-ID: Yes, I have one. I'll find a link & sent it to Lorn. br, Jani ________________________________ From: Lars Knoll Sent: Thursday, August 11, 2016 10:46 AM To: Thiago Macieira; development at qt-project.org Cc: Jani Heikkinen Subject: Re: [Development] out of date license headers in non supported modules On 11/08/16 02:08, "Development on behalf of Thiago Macieira" wrote: >On quinta-feira, 11 de agosto de 2016 08:42:06 PDT Lorn Potter wrote: >> Thanks for that. >> >> On Wednesday, 10 August 2016 11:35:06 PM AEST Sergio Ahumada wrote: >> > yours has 41 lines and the reference only 38 >> > http://code.qt.io/cgit/qt/qtbase.git/tree/header.LGPL?h=dev >> >> Ok, so how to deal with files that have multiple copyright holders? > >Only the lines between QT_BEGIN_LICENSE and QT_END_LICENSE count. Afaik, Jani has a script that can help getting these updated. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From announce at qt-project.org Thu Aug 11 15:06:45 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 11 Aug 2016 13:06:45 +0000 Subject: [Development] [Announce] Qt VS Tools (Beta) released Message-ID: We are pleased to announce the release of the Qt VS Tools (Beta)! http://blog.qt.io/blog/2016/08/11/from-visual-studio-add-in-to-qt-vs-tools-beta/ Br, -- Alessandro Portale Senior Manager, R&D The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin alessandro.portale at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From aha_1980 at gmx.de Thu Aug 11 15:28:47 2016 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Thu, 11 Aug 2016 15:28:47 +0200 Subject: [Development] Adding 3rdpary libraries to QtSerialBus Message-ID: Hi all, [Re-sent as I think something went wrong the first time, the mail did not appear in the archive.] I'm working on a new feature for QCanBus to enumerate all available CAN interfaces and query more information about them [0]. As it turns out, the Linux SocketCAN API allows a lot, but exactly this task is a bit complicated, see mailing list thread [1]. In this thread, Kurt Van Dijck proposed his network interface enumeration library [2], licensed under LGPL V3, which perfectly allows to query all SocketCAN devices. QNetworkInterface::allInterfaces() lists them too, but there is for now no way to find out which of them are SocketCAN interfaces. Now I really don't know how to proceed. I already saw some libs like pcre included in the Qt source tree, but I don't know if this is possible with libenumif too, and which technical and legal requirements are needed. The same problem may occur with libsocketcan [3] which provides more low-level function like CAN controller hardware reset. But this library is more widely used and really stable, so dynamically loading with QLibrary may be enough here. Thanks for any pointers! Best regards, Andre [0] https://codereview.qt-project.org/#/c/166460 [1] https://marc.info/?l=linux-can&m=147074084303882&w=2 [2] https://github.com/kurt-vd/enumif [3] http://git.pengutronix.de/?p=tools/libsocketcan.git From edward.welbourne at qt.io Thu Aug 11 15:47:49 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 11 Aug 2016 13:47:49 +0000 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: References: Message-ID: André Hartmann > [Re-sent as I think something went wrong the first time, > the mail did not appear in the archive.] I haven't seen it before, at least. > In this thread, Kurt Van Dijck proposed his network interface > enumeration library [2], licensed under LGPL V3, which perfectly allows > to query all SocketCAN devices. QNetworkInterface::allInterfaces() lists > them too, but there is for now no way to find out which of them are > SocketCAN interfaces. > > [2] https://github.com/kurt-vd/enumif How hard would it be to teach QNetworkInterface how to detect CAN-iness in the interfaces it's clearly able to enumerate ? Eddy. From aha_1980 at gmx.de Thu Aug 11 16:18:22 2016 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Thu, 11 Aug 2016 16:18:22 +0200 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: References: Message-ID: Hi Edward, > How hard would it be to teach QNetworkInterface how to detect > CAN-iness in the interfaces it's clearly able to enumerate ? I'm currently trying to find this out. What I know so far, is that you can compare "something" to #define ARPHRD_CAN 280 to find out the interface is of type SocketCAN. As there are more of these definitions in /usr/include/linux/if_arp.h, a generic way to get the "type" of an interface could be added to QNetworkInterface. Maybe someone with more Linux programming knowlegde has a hint - libenumif surely knows it, but looks like a sledgehammer for my small problem. Cheers, Andre Am 11.08.2016 um 15:47 schrieb Edward Welbourne: > André Hartmann >> [Re-sent as I think something went wrong the first time, >> the mail did not appear in the archive.] > > I haven't seen it before, at least. > >> In this thread, Kurt Van Dijck proposed his network interface >> enumeration library [2], licensed under LGPL V3, which perfectly allows >> to query all SocketCAN devices. QNetworkInterface::allInterfaces() lists >> them too, but there is for now no way to find out which of them are >> SocketCAN interfaces. >> >> [2] https://github.com/kurt-vd/enumif > > How hard would it be to teach QNetworkInterface how to detect CAN-iness > in the interfaces it's clearly able to enumerate ? > > Eddy. > From thiago.macieira at intel.com Thu Aug 11 18:21:25 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 Aug 2016 09:21:25 -0700 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: References: Message-ID: <1804394.SLvpAnShSX@tjmaciei-mobl1> On quinta-feira, 11 de agosto de 2016 15:28:47 PDT André Hartmann wrote: > In this thread, Kurt Van Dijck proposed his network interface > enumeration library [2], licensed under LGPL V3 That would be a first if we allowed this. It's unlikely that we'll allow importing of an LGPLv3-licenced library. Instead, I advise: 1) detect the library at compile time, installed system-wide 2) add a workaround without that library, as the commercial version of QtSerialBus will most likely not enable this library -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Aug 11 18:23:14 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 Aug 2016 09:23:14 -0700 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: References: Message-ID: <1821312.1PjFT8cgZ4@tjmaciei-mobl1> On quinta-feira, 11 de agosto de 2016 16:18:22 PDT André Hartmann wrote: > Hi Edward, > > > How hard would it be to teach QNetworkInterface how to detect > > CAN-iness in the interfaces it's clearly able to enumerate ? > > I'm currently trying to find this out. What I know so far, is that > you can compare "something" to > > #define ARPHRD_CAN 280 > > to find out the interface is of type SocketCAN. As there are more of > these definitions in /usr/include/linux/if_arp.h, a generic way to get > the "type" of an interface could be added to QNetworkInterface. > > Maybe someone with more Linux programming knowlegde has a hint - > libenumif surely knows it, but looks like a sledgehammer for my small > problem. I have a preliminary patch that detects the interface type in QNetworkInterface. Just pushed at https://codereview.qt-project.org/167772. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nassian at bitshift-dynamics.de Thu Aug 11 19:12:26 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Thu, 11 Aug 2016 19:12:26 +0200 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: <1804394.SLvpAnShSX@tjmaciei-mobl1> References: <1804394.SLvpAnShSX@tjmaciei-mobl1> Message-ID: <1EEBA55E-6614-4202-A013-F905242FC317@bitshift-dynamics.de> Why should that not be possible? With Chromium we already have L-GPLv2 and many other. Qt itself is also available as v3. Beste Grüße / Best regards, Alexander Nassian > Am 11.08.2016 um 18:21 schrieb Thiago Macieira : > >> On quinta-feira, 11 de agosto de 2016 15:28:47 PDT André Hartmann wrote: >> In this thread, Kurt Van Dijck proposed his network interface >> enumeration library [2], licensed under LGPL V3 > > That would be a first if we allowed this. It's unlikely that we'll allow > importing of an LGPLv3-licenced library. > > Instead, I advise: > 1) detect the library at compile time, installed system-wide > 2) add a workaround without that library, as the commercial version of > QtSerialBus will most likely not enable this library > > -- > 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 Thu Aug 11 19:42:24 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 Aug 2016 10:42:24 -0700 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: <1EEBA55E-6614-4202-A013-F905242FC317@bitshift-dynamics.de> References: <1804394.SLvpAnShSX@tjmaciei-mobl1> <1EEBA55E-6614-4202-A013-F905242FC317@bitshift-dynamics.de> Message-ID: <8359485.hanWWxz3eu@tjmaciei-mobl1> On quinta-feira, 11 de agosto de 2016 19:12:26 PDT Alexander Nassian wrote: > Why should that not be possible? With Chromium we already have L-GPLv2 and > many other. Qt itself is also available as v3. WebKit (including JSC) was an exception and Chromium inherited that exception. It's one that didn't please commercial customers much. And they're LGPLv2. The v3 clauses cause lots of companies to run away. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nassian at bitshift-dynamics.de Thu Aug 11 19:50:35 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Thu, 11 Aug 2016 19:50:35 +0200 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: <8359485.hanWWxz3eu@tjmaciei-mobl1> References: <1804394.SLvpAnShSX@tjmaciei-mobl1> <1EEBA55E-6614-4202-A013-F905242FC317@bitshift-dynamics.de> <8359485.hanWWxz3eu@tjmaciei-mobl1> Message-ID: Am 11.08.2016 um 19:42 schrieb Thiago Macieira : > >> On quinta-feira, 11 de agosto de 2016 19:12:26 PDT Alexander Nassian wrote: >> Why should that not be possible? With Chromium we already have L-GPLv2 and >> many other. Qt itself is also available as v3. > > WebKit (including JSC) was an exception and Chromium inherited that exception. > It's one that didn't please commercial customers much. > > And they're LGPLv2. The v3 clauses cause lots of companies to run away. Really? v3 just clarifies some of the implications of v2 in a more suitable way for lawyers. Many people that run away don't know how to get their products safe with the requirement to let the user on the system. But it's possible and no real reason against v3. > > -- > 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 aha_1980 at gmx.de Thu Aug 11 19:58:48 2016 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Thu, 11 Aug 2016 19:58:48 +0200 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: References: <1804394.SLvpAnShSX@tjmaciei-mobl1> <1EEBA55E-6614-4202-A013-F905242FC317@bitshift-dynamics.de> <8359485.hanWWxz3eu@tjmaciei-mobl1> Message-ID: Hi, oops, looks like I triggerd an avalanche. Just to clarify, if we can solve the problem within Qt, then there is no need to include external libraries. Thiagos patch https://codereview.qt-project.org/#/c/167772/ looks quit promising, at least for an important part of my problem. Best regards, Andre Am 11.08.2016 um 19:50 schrieb Alexander Nassian: > Am 11.08.2016 um 19:42 schrieb Thiago Macieira : >> >>> On quinta-feira, 11 de agosto de 2016 19:12:26 PDT Alexander Nassian wrote: >>> Why should that not be possible? With Chromium we already have L-GPLv2 and >>> many other. Qt itself is also available as v3. >> >> WebKit (including JSC) was an exception and Chromium inherited that exception. >> It's one that didn't please commercial customers much. >> >> And they're LGPLv2. The v3 clauses cause lots of companies to run away. > > Really? v3 just clarifies some of the implications of v2 in a more suitable way for lawyers. Many people that run away don't know how to get their products safe with the requirement to let the user on the system. But it's possible and no real reason against v3. > >> >> -- >> 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 Thu Aug 11 22:22:12 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 Aug 2016 13:22:12 -0700 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: References: <8359485.hanWWxz3eu@tjmaciei-mobl1> Message-ID: <1842942.2tugbjrTF1@tjmaciei-mobl1> On quinta-feira, 11 de agosto de 2016 19:50:35 PDT Alexander Nassian wrote: > > And they're LGPLv2. The v3 clauses cause lots of companies to run away. > > Really? v3 just clarifies some of the implications of v2 in a more suitable > way for lawyers. Many people that run away don't know how to get their > products safe with the requirement to let the user on the system. But it's > possible and no real reason against v3. The "v3" is hardly "just clarifies" over the v2. It adds at least two extra provisions: * the patent grant * the "installation instructions" clause Regardless of whether the reasons why companies run away is valid or not, the fact is that they do. I submit Evidence A: Apple stopped updating GCC when it went GPLv3 in version 4.3 and instead started their own compiler. So it's unimportant whether the reasons are valid. It's important that we understand the consequences if we do choose to accept an LGPLv3 dependency. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Aug 11 22:22:51 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 Aug 2016 13:22:51 -0700 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: References: Message-ID: <14330143.0IrQ28PqXS@tjmaciei-mobl1> On quinta-feira, 11 de agosto de 2016 19:58:48 PDT André Hartmann wrote: > Thiagos patch https://codereview.qt-project.org/#/c/167772/ looks quit > promising, at least for an important part of my problem. Nice to know. Note the patch is crude at this point. It's at the earliest a Qt 5.9 feature. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From aha_1980 at gmx.de Thu Aug 11 22:31:13 2016 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Thu, 11 Aug 2016 22:31:13 +0200 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: <14330143.0IrQ28PqXS@tjmaciei-mobl1> References: <14330143.0IrQ28PqXS@tjmaciei-mobl1> Message-ID: <8e1174b4-ddf4-dea2-7473-2c9a99345c3d@gmx.de> Am 11.08.2016 um 22:22 schrieb Thiago Macieira: > On quinta-feira, 11 de agosto de 2016 19:58:48 PDT André Hartmann wrote: >> Thiagos patch https://codereview.qt-project.org/#/c/167772/ looks quit >> promising, at least for an important part of my problem. > > Nice to know. > > Note the patch is crude at this point. It's at the earliest a Qt 5.9 feature. Maybe it can be at least used internally in 5.9? The SocketCAN plugin already uses QT += core-private, so I guess this should be no big problem. From thiago.macieira at intel.com Thu Aug 11 23:22:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 11 Aug 2016 14:22:01 -0700 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: <8e1174b4-ddf4-dea2-7473-2c9a99345c3d@gmx.de> References: <14330143.0IrQ28PqXS@tjmaciei-mobl1> <8e1174b4-ddf4-dea2-7473-2c9a99345c3d@gmx.de> Message-ID: <49080789.OE7BXC5vI6@tjmaciei-mobl1> On quinta-feira, 11 de agosto de 2016 22:31:13 PDT André Hartmann wrote: > Am 11.08.2016 um 22:22 schrieb Thiago Macieira: > > On quinta-feira, 11 de agosto de 2016 19:58:48 PDT André Hartmann wrote: > >> Thiagos patch https://codereview.qt-project.org/#/c/167772/ looks quit > >> promising, at least for an important part of my problem. > > > > Nice to know. > > > > Note the patch is crude at this point. It's at the earliest a Qt 5.9 > > feature. > Maybe it can be at least used internally in 5.9? The SocketCAN plugin > already uses QT += core-private, so I guess this should be no big problem. It's adding front-end API. More importantly, I won't have the time to finish it any time soon. Either way, your new QtSerialBus feature is 5.9 material too. You haven't finished it yet and feature freeze is in less than one week. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nassian at bitshift-dynamics.de Fri Aug 12 06:32:22 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Fri, 12 Aug 2016 06:32:22 +0200 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: <1842942.2tugbjrTF1@tjmaciei-mobl1> References: <8359485.hanWWxz3eu@tjmaciei-mobl1> <1842942.2tugbjrTF1@tjmaciei-mobl1> Message-ID: Interesting enough that Qt itself switched the OSS license to v3 ... > Am 11.08.2016 um 22:22 schrieb Thiago Macieira : > > On quinta-feira, 11 de agosto de 2016 19:50:35 PDT Alexander Nassian wrote: >>> And they're LGPLv2. The v3 clauses cause lots of companies to run away. >> >> Really? v3 just clarifies some of the implications of v2 in a more suitable >> way for lawyers. Many people that run away don't know how to get their >> products safe with the requirement to let the user on the system. But it's >> possible and no real reason against v3. > > The "v3" is hardly "just clarifies" over the v2. It adds at least two extra > provisions: > * the patent grant > * the "installation instructions" clause > > Regardless of whether the reasons why companies run away is valid or not, the > fact is that they do. I submit Evidence A: Apple stopped updating GCC when it > went GPLv3 in version 4.3 and instead started their own compiler. > > So it's unimportant whether the reasons are valid. It's important that we > understand the consequences if we do choose to accept an LGPLv3 dependency. > > -- > 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 denis.shienkov at gmail.com Fri Aug 12 07:39:42 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 12 Aug 2016 08:39:42 +0300 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: References: Message-ID: <6182e9e5-fbaa-7a91-dcc4-74840054c9a9@gmail.com> Hi Andre, We can try to use libudev (or to parse the sysfs entries) to find out additional information too. At first, we just need to check what we can take from it. BR, Denis 11.08.2016 16:28, André Hartmann пишет: > Hi all, > > [Re-sent as I think something went wrong the first time, > the mail did not appear in the archive.] > > I'm working on a new feature for QCanBus to enumerate all available > CAN interfaces and query more information about them [0]. > > As it turns out, the Linux SocketCAN API allows a lot, but exactly > this task is a bit complicated, see mailing list thread [1]. > > In this thread, Kurt Van Dijck proposed his network interface > enumeration library [2], licensed under LGPL V3, which perfectly > allows to query all SocketCAN devices. > QNetworkInterface::allInterfaces() lists them too, but there is for > now no way to find out which of them are SocketCAN interfaces. > > Now I really don't know how to proceed. I already saw some libs like > pcre included in the Qt source tree, but I don't know if this is > possible with libenumif too, and which technical and legal > requirements are needed. > > The same problem may occur with libsocketcan [3] which provides more > low-level function like CAN controller hardware reset. But this > library is more widely used and really stable, so dynamically loading > with QLibrary may be enough here. > > Thanks for any pointers! > > Best regards, > Andre > > [0] https://codereview.qt-project.org/#/c/166460 > [1] https://marc.info/?l=linux-can&m=147074084303882&w=2 > [2] https://github.com/kurt-vd/enumif > [3] http://git.pengutronix.de/?p=tools/libsocketcan.git > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Fri Aug 12 10:52:52 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 12 Aug 2016 10:52:52 +0200 Subject: [Development] Which changes are suitable for 5.6? Message-ID: <201608121052.52787.marc.mutz@kdab.com> Hi, I'd like to know what the rules are supposed to for submitting to 5.6 (LTS). Should we enforce the strict rules of other minor releases (only regressions and P2+)? IMHO, 5.6 is not like 5.5. So with another 2+ years of 5.6 lifetime, more relaxed rules should apply. I'd like all bug-fixes to go to 5.6 first, even if the priority is not high, and regressions cannot be ruled out (they never can, anyway). I also think that dead code elimination should be in-scope for 5.6, to not construct unessesary diffs between 5.6 and dev. And last, some authors target optimisations at 5.6, some at 5.7 and others (me included, even though I sympathise with submitting to 5.6) at dev/5.8. What's the stance on this? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From aha_1980 at gmx.de Fri Aug 12 11:01:15 2016 From: aha_1980 at gmx.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Fri, 12 Aug 2016 11:01:15 +0200 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: <6182e9e5-fbaa-7a91-dcc4-74840054c9a9@gmail.com> References: <6182e9e5-fbaa-7a91-dcc4-74840054c9a9@gmail.com> Message-ID: Hi Denis, I've already have a prototype parsing the sysfs. It has no dependencies, consists of less than 100 lines code and determines the SocketCAN interfaces, checks if an interface is virtual and if the interface is CAN FD capable. You will be able to review it soon :) Best regards, Andre Am 12.08.2016 um 07:39 schrieb Denis Shienkov: > Hi Andre, > > We can try to use libudev (or to parse the sysfs entries) to find out > additional information too. > At first, we just need to check what we can take from it. > > BR, > Denis > > 11.08.2016 16:28, André Hartmann пишет: >> Hi all, >> >> [Re-sent as I think something went wrong the first time, >> the mail did not appear in the archive.] >> >> I'm working on a new feature for QCanBus to enumerate all available >> CAN interfaces and query more information about them [0]. >> >> As it turns out, the Linux SocketCAN API allows a lot, but exactly >> this task is a bit complicated, see mailing list thread [1]. >> >> In this thread, Kurt Van Dijck proposed his network interface >> enumeration library [2], licensed under LGPL V3, which perfectly >> allows to query all SocketCAN devices. >> QNetworkInterface::allInterfaces() lists them too, but there is for >> now no way to find out which of them are SocketCAN interfaces. >> >> Now I really don't know how to proceed. I already saw some libs like >> pcre included in the Qt source tree, but I don't know if this is >> possible with libenumif too, and which technical and legal >> requirements are needed. >> >> The same problem may occur with libsocketcan [3] which provides more >> low-level function like CAN controller hardware reset. But this >> library is more widely used and really stable, so dynamically loading >> with QLibrary may be enough here. >> >> Thanks for any pointers! >> >> Best regards, >> Andre >> >> [0] https://codereview.qt-project.org/#/c/166460 >> [1] https://marc.info/?l=linux-can&m=147074084303882&w=2 >> [2] https://github.com/kurt-vd/enumif >> [3] http://git.pengutronix.de/?p=tools/libsocketcan.git >> _______________________________________________ >> 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 annulen at yandex.ru Fri Aug 12 11:34:10 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 12 Aug 2016 12:34:10 +0300 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: References: <8359485.hanWWxz3eu@tjmaciei-mobl1> <1842942.2tugbjrTF1@tjmaciei-mobl1> Message-ID: <672401470994450@web5o.yandex.ru> 12.08.2016, 07:32, "Alexander Nassian" : > Interesting enough that Qt itself switched the OSS license to v3 ... Don't mix up changing license of your project to more restrictive with using restrictively licensed 3rd party libraries. > >>  Am 11.08.2016 um 22:22 schrieb Thiago Macieira : >> >>  On quinta-feira, 11 de agosto de 2016 19:50:35 PDT Alexander Nassian wrote: >>>>  And they're LGPLv2. The v3 clauses cause lots of companies to run away. >>> >>>  Really? v3 just clarifies some of the implications of v2 in a more suitable >>>  way for lawyers. Many people that run away don't know how to get their >>>  products safe with the requirement to let the user on the system. But it's >>>  possible and no real reason against v3. >> >>  The "v3" is hardly "just clarifies" over the v2. It adds at least two extra >>  provisions: >>  * the patent grant >>  * the "installation instructions" clause >> >>  Regardless of whether the reasons why companies run away is valid or not, the >>  fact is that they do. I submit Evidence A: Apple stopped updating GCC when it >>  went GPLv3 in version 4.3 and instead started their own compiler. >> >>  So it's unimportant whether the reasons are valid. It's important that we >>  understand the consequences if we do choose to accept an LGPLv3 dependency. >> >>  -- >>  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 -- Regards, Konstantin From olivier at woboq.com Fri Aug 12 12:01:19 2016 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 12 Aug 2016 12:01:19 +0200 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <201608121052.52787.marc.mutz@kdab.com> References: <201608121052.52787.marc.mutz@kdab.com> Message-ID: <4294275.lI0kctPuIx@maurice> On Freitag, 12. August 2016 10:52:52 CEST Marc Mutz wrote: > Hi, > > I'd like to know what the rules are supposed to for submitting to 5.6 (LTS). > > Should we enforce the strict rules of other minor releases (only regressions > and P2+)? > > IMHO, 5.6 is not like 5.5. So with another 2+ years of 5.6 lifetime, more > relaxed rules should apply. In my interpretation, LTS means it's just a stable branch, but that will stay maintained longer, with the same criterias as normal stable branches. [https://wiki.qt.io/Branch_Guidelines#Where_to_push_a_change.3F] That is, we make sure it works longer with more recent compiler/platform and keep security patches or crashes patches. > I'd like all bug-fixes to go to 5.6 first, even if the priority is not high, > and regressions cannot be ruled out (they never can, anyway). I think that's not a good definition of a stable branch. Bugfixes are risky as they touch working code. Why not also add all features? Features are less risky to break stuff as they add new code and are often not affecting the existing users. > I also think that dead code elimination should be in-scope for 5.6, to not > construct unessesary diffs between 5.6 and dev. Is the code really dead? Is that patch not going to cause even more merge conflicts as we merge through the branches? > And last, some authors target optimisations at 5.6, some at 5.7 and others > (me included, even though I sympathise with submitting to 5.6) at dev/5.8. > What's the stance on this? Optimisations are usually quite dangerous, and may cause regressions. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From nassian at bitshift-dynamics.de Fri Aug 12 12:32:14 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Fri, 12 Aug 2016 12:32:14 +0200 Subject: [Development] Adding 3rdpary libraries to QtSerialBus In-Reply-To: <1842942.2tugbjrTF1@tjmaciei-mobl1> References: <8359485.hanWWxz3eu@tjmaciei-mobl1> <1842942.2tugbjrTF1@tjmaciei-mobl1> Message-ID: > Am 11.08.2016 um 22:22 schrieb Thiago Macieira : > > On quinta-feira, 11 de agosto de 2016 19:50:35 PDT Alexander Nassian wrote: >>> And they're LGPLv2. The v3 clauses cause lots of companies to run away. >> >> Really? v3 just clarifies some of the implications of v2 in a more suitable >> way for lawyers. Many people that run away don't know how to get their >> products safe with the requirement to let the user on the system. But it's >> possible and no real reason against v3. > > The "v3" is hardly "just clarifies" over the v2. It adds at least two extra > provisions: > * the patent grant > * the "installation instructions" clause I recommend you viewing the Video with Dr. Till Jäger which is published on the Qt website - he also supports the view that mostly the same requirements exist (at least in european law) with 2.1 based on the license's spirit and wording: https://www.qt.io/qt-licensing-terms/ > > Regardless of whether the reasons why companies run away is valid or not, the > fact is that they do. I submit Evidence A: Apple stopped updating GCC when it > went GPLv3 in version 4.3 and instead started their own compiler. Apple's license strategy is not really an evidence. Apple was never a big fan of any kind of GPL licensed software. Which is understandable due to the BSD and more Unixishes nature of OS X. The license was surely one of the reasons for LLVM/Clang, but definetly not the only one. > > So it's unimportant whether the reasons are valid. It's important that we > understand the consequences if we do choose to accept an LGPLv3 dependency. > Sure. That's imprtant. Sorry if some people see me overtaking this thread with offtopic, but I just wanted to state my sight on this issue that came up as part of this thread. Best regards and have a nice weekend! Alexander Nassian From fredrik.devibe at qt.io Fri Aug 12 12:40:55 2016 From: fredrik.devibe at qt.io (Fredrik de Vibe) Date: Fri, 12 Aug 2016 12:40:55 +0200 Subject: [Development] New repository for QtOAuth Message-ID: Hi all, We have recently been working on an implementation of OAuth (1+2), and this is now approaching a state in which it can be distributed as a tech preview. For this we'll need a new public repository. The main reason for OAuth to reside in its own module (and not as a part of qtnetwork) is that it is specialized, and most qtnetwork users won't need it. This avoids increasing the footprint of, and unnecessary complexity in, qtnetwork. Another reason is that OAuth, while depending on and using networking mechanisms, isn't in itself really a networking mechanism. Cheers, - Fredrik - From lars.knoll at qt.io Fri Aug 12 13:18:52 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 12 Aug 2016 11:18:52 +0000 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <4294275.lI0kctPuIx@maurice> References: <201608121052.52787.marc.mutz@kdab.com> <4294275.lI0kctPuIx@maurice> Message-ID: <108E4DAF-1A5B-4808-91C0-FF4FE78E3DFF@qt.io> > On 12 Aug 2016, at 12:01, Olivier Goffart wrote: > > On Freitag, 12. August 2016 10:52:52 CEST Marc Mutz wrote: >> Hi, >> >> I'd like to know what the rules are supposed to for submitting to 5.6 (LTS). >> >> Should we enforce the strict rules of other minor releases (only regressions >> and P2+)? >> >> IMHO, 5.6 is not like 5.5. So with another 2+ years of 5.6 lifetime, more >> relaxed rules should apply. > > In my interpretation, LTS means it's just a stable branch, but that will stay > maintained longer, with the same criterias as normal stable branches. > [https://wiki.qt.io/Branch_Guidelines#Where_to_push_a_change.3F] > That is, we make sure it works longer with more recent compiler/platform and > keep security patches or crashes patches. Yes, same criteria as normal stable branches apply. The difference is that we might (but don't have to) do some additional work to ensure 5.6 works on newer OS versions if they come out during the lifetime of 5.6. > >> I'd like all bug-fixes to go to 5.6 first, even if the priority is not high, >> and regressions cannot be ruled out (they never can, anyway). > > I think that's not a good definition of a stable branch. Bugfixes are risky as > they touch working code. > Why not also add all features? Features are less risky to break stuff as they > add new code and are often not affecting the existing users. Agree. Bug fixes go in if they are regressions or critical issues that can't be worked around easily. > >> I also think that dead code elimination should be in-scope for 5.6, to not >> construct unessesary diffs between 5.6 and dev. > > Is the code really dead? Is that patch not going to cause even more merge > conflicts as we merge through the branches? We'll have enough diff between the branches anyway. Dead code removal and other cleanups should always happen in dev, never in stable branches. If the code is dead, nobody will touch it in 5.6 anyway, so it most likely won't cause merge conflicts neither. > >> And last, some authors target optimisations at 5.6, some at 5.7 and others >> (me included, even though I sympathise with submitting to 5.6) at dev/5.8. >> What's the stance on this? > > Optimisations are usually quite dangerous, and may cause regressions. Those go to dev. There can be exceptions, if e.g. a certain algorithm is showing exponential behaviour (thus rendering Qt unusable with large sets of data), but not for a patch that just makes something a couple of percent faster or reduces memory consumption by some bytes. Cheers, Lars > > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Fri Aug 12 13:19:20 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 12 Aug 2016 11:19:20 +0000 Subject: [Development] New repository for QtOAuth In-Reply-To: References: Message-ID: <561BBCF5-83F4-4B95-8508-40B92C616847@qt.io> +1. Lars > On 12 Aug 2016, at 12:40, Fredrik de Vibe wrote: > > Hi all, > > We have recently been working on an implementation of OAuth (1+2), and this is now approaching a state in which it can be distributed as a tech preview. For this we'll need a new public repository. > > The main reason for OAuth to reside in its own module (and not as a part of qtnetwork) is that it is specialized, and most qtnetwork users won't need it. This avoids increasing the footprint of, and unnecessary complexity in, qtnetwork. Another reason is that OAuth, while depending on and using networking mechanisms, isn't in itself really a networking mechanism. > > > Cheers, > - Fredrik - > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Fri Aug 12 14:00:10 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 12 Aug 2016 14:00:10 +0200 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <108E4DAF-1A5B-4808-91C0-FF4FE78E3DFF@qt.io> References: <201608121052.52787.marc.mutz@kdab.com> <4294275.lI0kctPuIx@maurice> <108E4DAF-1A5B-4808-91C0-FF4FE78E3DFF@qt.io> Message-ID: <201608121400.10365.marc.mutz@kdab.com> On Friday 12 August 2016 13:18:52 Lars Knoll wrote: > > On 12 Aug 2016, at 12:01, Olivier Goffart wrote: > > > > > > On Freitag, 12. August 2016 10:52:52 CEST Marc Mutz wrote: > >> Hi, > >> > >> > >> > >> I'd like to know what the rules are supposed to for submitting to 5.6 > >> (LTS). > >> > >> > >> > >> Should we enforce the strict rules of other minor releases (only > >> regressions and P2+)? > >> > >> > >> > >> IMHO, 5.6 is not like 5.5. So with another 2+ years of 5.6 lifetime, > >> more relaxed rules should apply. > > > > > > > > In my interpretation, LTS means it's just a stable branch, but that will > > stay maintained longer, with the same criterias as normal stable > > branches. > > [https://wiki.qt.io/Branch_Guidelines#Where_to_push_a_change.3F] That > > is, we make sure it works longer with more recent compiler/platform and > > keep security patches or crashes patches. > > Yes, same criteria as normal stable branches apply. The difference is that > we might (but don't have to) do some additional work to ensure 5.6 works > on newer OS versions if they come out during the lifetime of 5.6. Well, we told people "look, Qt 5.7 will drop support for your platform, and require C++11, but don't worry: you have 5.6 LTS". I doubt those people would be happy if they didn't get their bugs fixed because they don't involve crashes or security exploits. And if you look at what goes into 5.6, I don't buy that they're all critical crash or security fixes. The masses vote with their feet. Don't shoot the messenger. I think 5.6 is better for it. _Now_ you can shoot :) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From gunnar.roth at gmx.de Fri Aug 12 14:03:24 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Fri, 12 Aug 2016 14:03:24 +0200 Subject: [Development] Which changes are suitable for 5.6? Message-ID: An HTML attachment was scrubbed... URL: From rich at kde.org Fri Aug 12 14:21:50 2016 From: rich at kde.org (Richard Moore) Date: Fri, 12 Aug 2016 13:21:50 +0100 Subject: [Development] New repository for QtOAuth In-Reply-To: References: Message-ID: On 12 August 2016 at 11:40, Fredrik de Vibe wrote: > Hi all, > > We have recently been working on an implementation of OAuth (1+2), and > this is now approaching a state in which it can be distributed as a tech > preview. For this we'll need a new public repository. > > ​+1​ > The main reason for OAuth to reside in its own module (and not as a part > of qtnetwork) is that it is specialized, and most qtnetwork users won't > need it. This avoids increasing the footprint of, and unnecessary > complexity in, qtnetwork. Another reason is that OAuth, while depending on > and using networking mechanisms, isn't in itself really a networking > mechanism. > ​Yes, I think keeping this as a separate module makes sense. We really just want qtnetwork to be the core features. Cheers Rich.​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at qt.io Fri Aug 12 15:03:18 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 12 Aug 2016 13:03:18 +0000 Subject: [Development] [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming... In-Reply-To: References: Message-ID: Hi, Unfortunately, we're having great difficulties to get patches integrated into Qt WebEngine in the last days, right now due to qtlocation not compiling (QTBUG-55229). Unless the situation resolves itself over the weekend, I'd like to ask for an exception for getting features into 5.8 for Qt WebEngine even after Monday morning. The features still waiting to get merged are Printing: https://codereview.qt-project.org/#/c/162928/ and following Printing of CSS backgrounds: https://codereview.qt-project.org/#/c/167484/ Support for certificate transparency: https://codereview.qt-project.org/#/c/167275/ Support for custom QML context menu/ dialogs: https://codereview.qt-project.org/#/c/162263/, https://codereview.qt-project.org/#/c/165731/ Support for Qt Quick 2 Controls dialogs: https://codereview.qt-project.org/#/c/162262/ Regards Kai > -----Original Message----- > From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Jani Heikkinen > Sent: Monday, August 08, 2016 12:58 PM > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 > Feature Freeze coming... > > Hi all, > > > > > Qt5.git integration in 'dev' succeed during the weekend and we have soft > branched '5.8' from 'dev'. It means Qt 5.8 Feature Freeze will be effect 15th > August 2016 as well as final branching from 'dev' to '5.8' > > > > > > So please start using '5.8' for changes targeted to Qt 5.8 release and finalize > ongoing ones in 'dev'. Final downmerge from 'dev' to '5.8' will happen > Monday 15th Aug (morning). > > > > > Please make sure > > > - All new modules for Qt 5.8 are in 'dev' & part of qt5.git > > > - All mandatory new features are in 'dev' now or coming in within a week? > > > - New feature page contains all new features etc: > https://wiki.qt.io/New_Features_in_Qt_5.8 > > > > > We will create first src packages from latest qt5.git integration as soon as > possible. Please check the packages immediately when available to see if > something important is missing. Those packages should be quite close to Qt > 5.8 alpha packages so it will be really important to check the packages now. > > > > > br, > > Jani > > > > > > Jani Heikkinen > Release Manager > > The Qt Company > Elektroniikkatie 13 > 90590 Oulu Finland > jani.heikkinen at qt.io > +358 50 4873735 > http://qt.io > > > > > > > > > From nassian at bitshift-dynamics.de Fri Aug 12 15:56:58 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Fri, 12 Aug 2016 15:56:58 +0200 Subject: [Development] [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming... In-Reply-To: References: Message-ID: <8722E6E2-F4C0-4AE5-AA32-E5EB42AA77AC@bitshift-dynamics.de> May I kindly ask why PDF shall now be disabled on embedded systems? Best regards, Alexander Nassian > Am 12.08.2016 um 15:03 schrieb Kai Koehne : > > Hi, > > Unfortunately, we're having great difficulties to get patches integrated into Qt WebEngine in the last days, right now due to qtlocation not compiling (QTBUG-55229). Unless the situation resolves itself over the weekend, I'd like to ask for an exception for getting features into 5.8 for Qt WebEngine even after Monday morning. > > The features still waiting to get merged are > Printing: https://codereview.qt-project.org/#/c/162928/ and following > Printing of CSS backgrounds: https://codereview.qt-project.org/#/c/167484/ > Support for certificate transparency: https://codereview.qt-project.org/#/c/167275/ > Support for custom QML context menu/ dialogs: https://codereview.qt-project.org/#/c/162263/, https://codereview.qt-project.org/#/c/165731/ > Support for Qt Quick 2 Controls dialogs: https://codereview.qt-project.org/#/c/162262/ > > Regards > > Kai > > >> -----Original Message----- >> From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io at qt- >> project.org] On Behalf Of Jani Heikkinen >> Sent: Monday, August 08, 2016 12:58 PM >> To: development at qt-project.org >> Cc: releasing at qt-project.org >> Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 >> Feature Freeze coming... >> >> Hi all, >> >> >> >> >> Qt5.git integration in 'dev' succeed during the weekend and we have soft >> branched '5.8' from 'dev'. It means Qt 5.8 Feature Freeze will be effect 15th >> August 2016 as well as final branching from 'dev' to '5.8' >> >> >> >> >> >> So please start using '5.8' for changes targeted to Qt 5.8 release and finalize >> ongoing ones in 'dev'. Final downmerge from 'dev' to '5.8' will happen >> Monday 15th Aug (morning). >> >> >> >> >> Please make sure >> >> >> - All new modules for Qt 5.8 are in 'dev' & part of qt5.git >> >> >> - All mandatory new features are in 'dev' now or coming in within a week? >> >> >> - New feature page contains all new features etc: >> https://wiki.qt.io/New_Features_in_Qt_5.8 >> >> >> >> >> We will create first src packages from latest qt5.git integration as soon as >> possible. Please check the packages immediately when available to see if >> something important is missing. Those packages should be quite close to Qt >> 5.8 alpha packages so it will be really important to check the packages now. >> >> >> >> >> br, >> >> Jani >> >> >> >> >> >> Jani Heikkinen >> Release Manager >> >> The Qt Company >> Elektroniikkatie 13 >> 90590 Oulu Finland >> jani.heikkinen at qt.io >> +358 50 4873735 >> http://qt.io >> >> >> >> >> >> >> >> > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Fri Aug 12 18:02:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 12 Aug 2016 09:02:08 -0700 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <201608121400.10365.marc.mutz@kdab.com> References: <201608121052.52787.marc.mutz@kdab.com> <108E4DAF-1A5B-4808-91C0-FF4FE78E3DFF@qt.io> <201608121400.10365.marc.mutz@kdab.com> Message-ID: <1897117.XPNpZ9BzFM@tjmaciei-mobl1> On sexta-feira, 12 de agosto de 2016 14:00:10 PDT Marc Mutz wrote: > Well, we told people "look, Qt 5.7 will drop support for your platform, and > require C++11, but don't worry: you have 5.6 LTS". I doubt those people > would be happy if they didn't get their bugs fixed because they don't > involve crashes or security exploits. > > And if you look at what goes into 5.6, I don't buy that they're all > critical crash or security fixes. The masses vote with their feet. Don't > shoot the messenger. I think 5.6 is better for it. _Now_ you can shoot :) I agree with Marc, we should allow fixing bugs besides those that are critical or regressions. Even the regression category will change: once 5.6 is a year old, we'll start making judgement calls that we "had better leave it this way". I would prefer we do fix bugs that we can, so long as we can reasonably say that they are reasonably safe of causing further issues. At least for the next six months. We should probably become progressively stricter as the branch becomes older. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Aug 12 18:26:41 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 12 Aug 2016 09:26:41 -0700 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: References: Message-ID: <1810804.GJHUPgc3oh@tjmaciei-mobl1> On sexta-feira, 12 de agosto de 2016 14:03:24 PDT Gunnar Roth wrote: > Does a request of having qtquickcontrols2 and qtvirtualkeyboard 2.1 > backported to 5.6. x have chance? Actually I managed to do this myself, but > an upstream solutuion is preferrable. The problem is that some important OS > is no longer supported in 5.7. Quite impossible. Those are defintely new features. However, there's a compromise: we can have a branch for the unofficial support. Anyone using that will know "there be dragons" -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Fri Aug 12 21:31:25 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 12 Aug 2016 19:31:25 +0000 Subject: [Development] [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming... In-Reply-To: References: , Message-ID: Hi, I totally support Kai's request. On the upside: The qtlocation build is fixed :) Simon ________________________________ From: Development on behalf of Kai Koehne Sent: Friday, August 12, 2016 3:03:18 PM To: Jani Heikkinen; development at qt-project.org Cc: releasing at qt-project.org Subject: Re: [Development] [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming... Hi, Unfortunately, we're having great difficulties to get patches integrated into Qt WebEngine in the last days, right now due to qtlocation not compiling (QTBUG-55229). Unless the situation resolves itself over the weekend, I'd like to ask for an exception for getting features into 5.8 for Qt WebEngine even after Monday morning. The features still waiting to get merged are Printing: https://codereview.qt-project.org/#/c/162928/ and following Printing of CSS backgrounds: https://codereview.qt-project.org/#/c/167484/ Support for certificate transparency: https://codereview.qt-project.org/#/c/167275/ Support for custom QML context menu/ dialogs: https://codereview.qt-project.org/#/c/162263/, https://codereview.qt-project.org/#/c/165731/ Support for Qt Quick 2 Controls dialogs: https://codereview.qt-project.org/#/c/162262/ Regards Kai > -----Original Message----- > From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Jani Heikkinen > Sent: Monday, August 08, 2016 12:58 PM > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 > Feature Freeze coming... > > Hi all, > > > > > Qt5.git integration in 'dev' succeed during the weekend and we have soft > branched '5.8' from 'dev'. It means Qt 5.8 Feature Freeze will be effect 15th > August 2016 as well as final branching from 'dev' to '5.8' > > > > > > So please start using '5.8' for changes targeted to Qt 5.8 release and finalize > ongoing ones in 'dev'. Final downmerge from 'dev' to '5.8' will happen > Monday 15th Aug (morning). > > > > > Please make sure > > > - All new modules for Qt 5.8 are in 'dev' & part of qt5.git > > > - All mandatory new features are in 'dev' now or coming in within a week? > > > - New feature page contains all new features etc: > https://wiki.qt.io/New_Features_in_Qt_5.8 > > > > > We will create first src packages from latest qt5.git integration as soon as > possible. Please check the packages immediately when available to see if > something important is missing. Those packages should be quite close to Qt > 5.8 alpha packages so it will be really important to check the packages now. > > > > > br, > > Jani > > > > > > Jani Heikkinen > Release Manager > > The Qt Company > Elektroniikkatie 13 > 90590 Oulu Finland > jani.heikkinen at qt.io > +358 50 4873735 > http://qt.io > > > > > > > > > _______________________________________________ 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 nospam at vuorela.dk Sat Aug 13 09:28:58 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Sat, 13 Aug 2016 07:28:58 +0000 (UTC) Subject: [Development] New repository for QtOAuth References: Message-ID: On 2016-08-12, Fredrik de Vibe wrote: > We have recently been working on an implementation of OAuth (1+2), and > this is now approaching a state in which it can be distributed as a tech > preview. For this we'll need a new public repository. there is a handful of external projects doing oauth with qt. Have anything been done to ensure applications don't blow up if several libraries gets loaded into the same process? The ones I've found seems to have some of the following distinguishing marks One puts everything in namespace QOAuth and has a QtOAuth header One seems to put everything with O0foo O1foo and O2foo another one seems to name everything like KQOAuthfoo (and despite the name, I don't think it has any ties to the KDE project) and one just with a class OAuth2, and this one looks a bit like example code. So, depending on how the qt project qtoauth is done, it might conflict to some degree with the first of them. The first of them is also available in Debian and other linux distributions as qoauth (libqoauth1 and libqoauth-dev) > The main reason for OAuth to reside in its own module (and not as a part > of qtnetwork) is that it is specialized, and most qtnetwork users won't > need it. This avoids increasing the footprint of, and unnecessary > complexity in, qtnetwork. Another reason is that OAuth, while depending > on and using networking mechanisms, isn't in itself really a networking > mechanism. Agreed. /Sune From lars.knoll at qt.io Sat Aug 13 14:03:45 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Sat, 13 Aug 2016 12:03:45 +0000 Subject: [Development] [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming... In-Reply-To: References: Message-ID: <5A45BDD7-4AA0-44BA-A389-AA30EE8DE5D0@qt.io> Sounds good to me. We'll also need some days past the feature free to get the remaining changes to the configuration system merged. Cheers, Lars On 12 Aug 2016, at 21:31, Simon Hausmann > wrote: Hi, I totally support Kai's request. On the upside: The qtlocation build is fixed :) Simon ________________________________ From: Development > on behalf of Kai Koehne > Sent: Friday, August 12, 2016 3:03:18 PM To: Jani Heikkinen; development at qt-project.org Cc: releasing at qt-project.org Subject: Re: [Development] [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming... Hi, Unfortunately, we're having great difficulties to get patches integrated into Qt WebEngine in the last days, right now due to qtlocation not compiling (QTBUG-55229). Unless the situation resolves itself over the weekend, I'd like to ask for an exception for getting features into 5.8 for Qt WebEngine even after Monday morning. The features still waiting to get merged are Printing: https://codereview.qt-project.org/#/c/162928/ and following Printing of CSS backgrounds: https://codereview.qt-project.org/#/c/167484/ Support for certificate transparency: https://codereview.qt-project.org/#/c/167275/ Support for custom QML context menu/ dialogs: https://codereview.qt-project.org/#/c/162263/, https://codereview.qt-project.org/#/c/165731/ Support for Qt Quick 2 Controls dialogs: https://codereview.qt-project.org/#/c/162262/ Regards Kai > -----Original Message----- > From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io@qt- > project.org] On Behalf Of Jani Heikkinen > Sent: Monday, August 08, 2016 12:58 PM > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 > Feature Freeze coming... > > Hi all, > > > > > Qt5.git integration in 'dev' succeed during the weekend and we have soft > branched '5.8' from 'dev'. It means Qt 5.8 Feature Freeze will be effect 15th > August 2016 as well as final branching from 'dev' to '5.8' > > > > > > So please start using '5.8' for changes targeted to Qt 5.8 release and finalize > ongoing ones in 'dev'. Final downmerge from 'dev' to '5.8' will happen > Monday 15th Aug (morning). > > > > > Please make sure > > > - All new modules for Qt 5.8 are in 'dev' & part of qt5.git > > > - All mandatory new features are in 'dev' now or coming in within a week? > > > - New feature page contains all new features etc: > https://wiki.qt.io/New_Features_in_Qt_5.8 > > > > > We will create first src packages from latest qt5.git integration as soon as > possible. Please check the packages immediately when available to see if > something important is missing. Those packages should be quite close to Qt > 5.8 alpha packages so it will be really important to check the packages now. > > > > > br, > > Jani > > > > > > Jani Heikkinen > Release Manager > > The Qt Company > Elektroniikkatie 13 > 90590 Oulu Finland > jani.heikkinen at qt.io > +358 50 4873735 > http://qt.io > > > > > > > > > _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Releasing mailing list Releasing at qt-project.org http://lists.qt-project.org/mailman/listinfo/releasing -------------- next part -------------- An HTML attachment was scrubbed... URL: From ritt.ks at gmail.com Sat Aug 13 17:20:24 2016 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Sat, 13 Aug 2016 19:20:24 +0400 Subject: [Development] New repository for QtOAuth In-Reply-To: References: Message-ID: I don't see any need in distinguishing different OAuth implementations for Qt -- once we have an "officially supported" Qt module, it'll be a default opt-in for the user's code. +1 for QtOAuth as a separate module Regards, Konstantin 2016-08-13 11:28 GMT+04:00 Sune Vuorela : > On 2016-08-12, Fredrik de Vibe wrote: > > We have recently been working on an implementation of OAuth (1+2), and > > this is now approaching a state in which it can be distributed as a tech > > preview. For this we'll need a new public repository. > > there is a handful of external projects doing oauth with qt. Have > anything been done to ensure applications don't blow up if several > libraries gets loaded into the same process? > > The ones I've found seems to have some of the following distinguishing > marks > > One puts everything in namespace QOAuth and has a QtOAuth header > > One seems to put everything with O0foo O1foo and O2foo > > another one seems to name everything like KQOAuthfoo (and despite the > name, I don't think it has any ties to the KDE project) > > and one just with a class OAuth2, and this one looks a bit like example > code. > > > So, depending on how the qt project qtoauth is done, it might conflict > to some degree with the first of them. The first of them is also > available in Debian and other linux distributions as qoauth (libqoauth1 > and libqoauth-dev) > > > The main reason for OAuth to reside in its own module (and not as a part > > of qtnetwork) is that it is specialized, and most qtnetwork users won't > > need it. This avoids increasing the footprint of, and unnecessary > > complexity in, qtnetwork. Another reason is that OAuth, while depending > > on and using networking mechanisms, isn't in itself really a networking > > mechanism. > > Agreed. > > /Sune > > _______________________________________________ > 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 gunnar.roth at gmx.de Sat Aug 13 18:08:16 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Sat, 13 Aug 2016 18:08:16 +0200 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <1810804.GJHUPgc3oh@tjmaciei-mobl1> References: <1810804.GJHUPgc3oh@tjmaciei-mobl1> Message-ID: <1C328D28-B7DC-48CF-8960-D9C46D4A5FF3@gmx.de> Hi Thiago, to make qt 5.6.x support the quick controls2 there are only a few changes needed. 1. category is just adding code, which does not influence current code. a. adding qAsConst in qgolbal.h. That is actually something i really like to have in qt 5.6, because it is very useful and has no risk. b. adding EditorFont to qplatformtheme.h enumeration ,has also no risk. c. protect cleanup of QQmlEngine when removing from QQmlDebugConnector in destructor, because quickcontrols2 instantiates it in a way that it is not registered, but on cleanup crashes when removing as there is no check if it was added at all. I consider that a bug in Qt 5.6.1 d. adding QQuickItem::isAncestorOf function to qquickitem.* has also no risk. e. adding Q_QUICK_PRIVATE_EXPORT to QQuickStateAction class in qquickstate_p.h 2. category is enhancing code but also modifies existing code. a. enhance qml module lookup behavior in a way making things a lot easier. qqmlimport.* is changed ( by merging simply the code from 5.7 to do a lookup like this: For example, QtQml.Models 2.0: - base/QtQml/Models.2.0/qmldir - base/QtQml.2.0/Models/qmldir - base/QtQml/Models.2/qmldir - base/QtQml.2/Models/qmldir - base/QtQml/Models/qmldir This is very convenient. quickcontrols2 works without that but only with the default style. quickcontrols1 is jumping through hoops to achieve similar without change qtdeclarative. b. adding MovementDirection property to QQuickPathView, i just copied qquickpathview.* from qt 5.7. I assume a low risk, but qt 5.7 has the same risk then. The changes in the quick controls itself are just a matter of changing some 7 to a 6, 5.7.0 to 5.6.1 and 2.7 to 2.6 So actually I don’t see a dragon but maybe a dwarf lizard there ;-) I can send the actual patches on request, they do not contain any code I wrote myself ( other than changing numbers) Regards, Gunnar Roth > Am 12.08.2016 um 18:26 schrieb Thiago Macieira : > > On sexta-feira, 12 de agosto de 2016 14:03:24 PDT Gunnar Roth wrote: >> Does a request of having qtquickcontrols2 and qtvirtualkeyboard 2.1 >> backported to 5.6. x have chance? Actually I managed to do this myself, but >> an upstream solutuion is preferrable. The problem is that some important OS >> is no longer supported in 5.7. > > Quite impossible. Those are defintely new features. > > However, there's a compromise: we can have a branch for the unofficial support. > Anyone using that will know "there be dragons" > > -- > 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 Sat Aug 13 20:05:51 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 13 Aug 2016 11:05:51 -0700 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <1C328D28-B7DC-48CF-8960-D9C46D4A5FF3@gmx.de> References: <1810804.GJHUPgc3oh@tjmaciei-mobl1> <1C328D28-B7DC-48CF-8960-D9C46D4A5FF3@gmx.de> Message-ID: <7593266.SIDtfCmA6x@tjmaciei-mobl1> On sábado, 13 de agosto de 2016 18:08:16 PDT Gunnar Roth wrote: > 1. category is just adding code, which does not influence current > code. > a. adding qAsConst in qgolbal.h. That is actually something i really > like to have in qt 5.6, because it is very useful and has no risk. Except that it's impossible. For the feature to work, we need rvalue references to prevent wrong use. We can't do that in 5.6 because it doesn't require C++11. > b. adding EditorFont to qplatformtheme.h enumeration ,has also no risk. Not allowed per Qt API compatibility promise: code compiled with Qt 5.6.x must run just fine with Qt 5.6.y even if y < x. > c. protect cleanup of QQmlEngine when removing from QQmlDebugConnector in > destructor, because quickcontrols2 instantiates it in a way that it is not > registered, but on cleanup crashes when removing as there is no check if it > was added at all. I consider that a bug in Qt 5.6.1 I have no idea about this one. > d. adding QQuickItem::isAncestorOf function to qquickitem.* has also no > risk. But violates Qt API policy even worse than adding an enum because it would cause dynamic linker errors. > e. adding Q_QUICK_PRIVATE_EXPORT to QQuickStateAction class in > qquickstate_p.h That's ok. > 2. category is enhancing code but also modifies existing code. > > a. enhance qml module lookup behavior in a way making things a lot > easier. > > qqmlimport.* is changed ( by merging simply the code from 5.7 to do a > lookup like this: For example, QtQml.Models 2.0: > - base/QtQml/Models.2.0/qmldir > - base/QtQml.2.0/Models/qmldir > - base/QtQml/Models.2/qmldir > - base/QtQml.2/Models/qmldir > - base/QtQml/Models/qmldir > This is very convenient. quickcontrols2 works without that but only > with the default style. quickcontrols1 is jumping through hoops to achieve > similar without change qtdeclarative. No idea about this. > b. adding MovementDirection property to QQuickPathView, i just copied > qquickpathview.* from qt 5.7. I assume a low risk, but qt 5.7 has the same > risk then. API policy violation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From gunnar.roth at gmx.de Sat Aug 13 20:30:39 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Sat, 13 Aug 2016 20:30:39 +0200 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <7593266.SIDtfCmA6x@tjmaciei-mobl1> References: <1810804.GJHUPgc3oh@tjmaciei-mobl1> <1C328D28-B7DC-48CF-8960-D9C46D4A5FF3@gmx.de> <7593266.SIDtfCmA6x@tjmaciei-mobl1> Message-ID: Hi Thiago, thanks for you answers. > Am 13.08.2016 um 20:05 schrieb Thiago Macieira : > > On sábado, 13 de agosto de 2016 18:08:16 PDT Gunnar Roth wrote: >> 1. category is just adding code, which does not influence current >> code. >> a. adding qAsConst in qgolbal.h. That is actually something i really >> like to have in qt 5.6, because it is very useful and has no risk. > > Except that it's impossible. For the feature to work, we need rvalue > references to prevent wrong use. We can't do that in 5.6 because it doesn't > require C++11. Hmm ok, as that works with vs 2012 ( and wec2013) I didn’t think about that. But even vs2010 has this. But ok there may be other compilers , which I don’t have knowledge about then. > >> b. adding EditorFont to qplatformtheme.h enumeration ,has also no risk. > > Not allowed per Qt API compatibility promise: code compiled with Qt 5.6.x must > run just fine with Qt 5.6.y even if y < x. Well thats something I honestly di not know before. So that means something compiled with qt 5.6.2 is able to run with 5.6.0? > >> c. protect cleanup of QQmlEngine when removing from QQmlDebugConnector in >> destructor, because quickcontrols2 instantiates it in a way that it is not >> registered, but on cleanup crashes when removing as there is no check if it >> was added at all. I consider that a bug in Qt 5.6.1 > > I have no idea about this one. > >> d. adding QQuickItem::isAncestorOf function to qquickitem.* has also no >> risk. > > But violates Qt API policy even worse than adding an enum because it would > cause dynamic linker errors. As I thought API compatibility were like between 5.6 and 5.7 , I didn’t see the problem. >> e. adding Q_QUICK_PRIVATE_EXPORT to QQuickStateAction class in >> qquickstate_p.h > > That's ok. > >> 2. category is enhancing code but also modifies existing code. >> >> a. enhance qml module lookup behavior in a way making things a lot >> easier. >> >> qqmlimport.* is changed ( by merging simply the code from 5.7 to do a >> lookup like this: For example, QtQml.Models 2.0: >> - base/QtQml/Models.2.0/qmldir >> - base/QtQml.2.0/Models/qmldir >> - base/QtQml/Models.2/qmldir >> - base/QtQml.2/Models/qmldir >> - base/QtQml/Models/qmldir >> This is very convenient. quickcontrols2 works without that but only >> with the default style. quickcontrols1 is jumping through hoops to achieve >> similar without change qtdeclarative. > > No idea about this. > >> b. adding MovementDirection property to QQuickPathView, i just copied >> qquickpathview.* from qt 5.7. I assume a low risk, but qt 5.7 has the same >> risk then. > > API policy violation. Sure now i know. Well ok then I will just maintain my patches privately. Regards, Gunnar Roth From thiago.macieira at intel.com Sat Aug 13 20:36:28 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 13 Aug 2016 11:36:28 -0700 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: References: <7593266.SIDtfCmA6x@tjmaciei-mobl1> Message-ID: <2365818.R2HPirJiEC@tjmaciei-mobl1> On sábado, 13 de agosto de 2016 20:30:39 PDT Gunnar Roth wrote: > >> b. adding EditorFont to qplatformtheme.h enumeration ,has also no risk. > > > > Not allowed per Qt API compatibility promise: code compiled with Qt 5.6.x > > must run just fine with Qt 5.6.y even if y < x. > > Well thats something I honestly di not know before. So that means something > compiled with qt 5.6.2 is able to run with 5.6.0? Yes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Mon Aug 15 10:46:22 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 15 Aug 2016 08:46:22 +0000 Subject: [Development] [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming... In-Reply-To: References: , Message-ID: Hi, Unfortunately we have challenges again with qt5.git integration in 'dev' and we need to wait that until we can do the feature freeze and final branching. So there might be still time to get these in as well before ff. br, Jani ________________________________ From: Kai Koehne Sent: Friday, August 12, 2016 4:03 PM To: Jani Heikkinen; development at qt-project.org Cc: releasing at qt-project.org Subject: RE: [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming... Hi, Unfortunately, we're having great difficulties to get patches integrated into Qt WebEngine in the last days, right now due to qtlocation not compiling (QTBUG-55229). Unless the situation resolves itself over the weekend, I'd like to ask for an exception for getting features into 5.8 for Qt WebEngine even after Monday morning. The features still waiting to get merged are Printing: https://codereview.qt-project.org/#/c/162928/ and following Printing of CSS backgrounds: https://codereview.qt-project.org/#/c/167484/ Support for certificate transparency: https://codereview.qt-project.org/#/c/167275/ Support for custom QML context menu/ dialogs: https://codereview.qt-project.org/#/c/162263/, https://codereview.qt-project.org/#/c/165731/ Support for Qt Quick 2 Controls dialogs: https://codereview.qt-project.org/#/c/162262/ Regards Kai > -----Original Message----- > From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Jani Heikkinen > Sent: Monday, August 08, 2016 12:58 PM > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 > Feature Freeze coming... > > Hi all, > > > > > Qt5.git integration in 'dev' succeed during the weekend and we have soft > branched '5.8' from 'dev'. It means Qt 5.8 Feature Freeze will be effect 15th > August 2016 as well as final branching from 'dev' to '5.8' > > > > > > So please start using '5.8' for changes targeted to Qt 5.8 release and finalize > ongoing ones in 'dev'. Final downmerge from 'dev' to '5.8' will happen > Monday 15th Aug (morning). > > > > > Please make sure > > > - All new modules for Qt 5.8 are in 'dev' & part of qt5.git > > > - All mandatory new features are in 'dev' now or coming in within a week? > > > - New feature page contains all new features etc: > https://wiki.qt.io/New_Features_in_Qt_5.8 > > > > > We will create first src packages from latest qt5.git integration as soon as > possible. Please check the packages immediately when available to see if > something important is missing. Those packages should be quite close to Qt > 5.8 alpha packages so it will be really important to check the packages now. > > > > > br, > > Jani > > > > > > Jani Heikkinen > Release Manager > > The Qt Company > Elektroniikkatie 13 > 90590 Oulu Finland > jani.heikkinen at qt.io > +358 50 4873735 > http://qt.io > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Tue Aug 16 10:06:09 2016 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 16 Aug 2016 10:06:09 +0200 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <1897117.XPNpZ9BzFM@tjmaciei-mobl1> References: <201608121052.52787.marc.mutz@kdab.com> <201608121400.10365.marc.mutz@kdab.com> <1897117.XPNpZ9BzFM@tjmaciei-mobl1> Message-ID: <1626069.GIB9faJcai@maurice> On Freitag, 12. August 2016 09:02:08 CEST Thiago Macieira wrote: > On sexta-feira, 12 de agosto de 2016 14:00:10 PDT Marc Mutz wrote: > > Well, we told people "look, Qt 5.7 will drop support for your platform, > > and > > require C++11, but don't worry: you have 5.6 LTS". I doubt those people > > would be happy if they didn't get their bugs fixed because they don't > > involve crashes or security exploits. > > > > And if you look at what goes into 5.6, I don't buy that they're all > > critical crash or security fixes. The masses vote with their feet. Don't > > shoot the messenger. I think 5.6 is better for it. _Now_ you can shoot :) > > I agree with Marc, we should allow fixing bugs besides those that are > critical or regressions. Even the regression category will change: once 5.6 > is a year old, we'll start making judgement calls that we "had better leave > it this way". > > I would prefer we do fix bugs that we can, so long as we can reasonably say > that they are reasonably safe of causing further issues. At least for the > next six months. > > We should probably become progressively stricter as the branch becomes > older. Any rationale for this way? I disagree that we should fix non-critical bugs or regression. If the bug has been there for several years already and the user could live with it, they can continue to work it around unti they upgrade to the newer Qt. It can be seen as a feature. Our product is the latest version of Qt. LTS means previous versions stay supported, not actively developped. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From marc.mutz at kdab.com Tue Aug 16 10:48:27 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 16 Aug 2016 10:48:27 +0200 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <1626069.GIB9faJcai@maurice> References: <201608121052.52787.marc.mutz@kdab.com> <1897117.XPNpZ9BzFM@tjmaciei-mobl1> <1626069.GIB9faJcai@maurice> Message-ID: <201608161048.27861.marc.mutz@kdab.com> On Tuesday 16 August 2016 10:06:09 Olivier Goffart wrote: > On Freitag, 12. August 2016 09:02:08 CEST Thiago Macieira wrote: [...] > > I agree with Marc, we should allow fixing bugs besides those that are > > critical or regressions. Even the regression category will change: once > > 5.6 is a year old, we'll start making judgement calls that we "had > > better leave it this way". > > > > I would prefer we do fix bugs that we can, so long as we can reasonably > > say that they are reasonably safe of causing further issues. At least > > for the next six months. > > > > We should probably become progressively stricter as the branch becomes > > older. > > Any rationale for this way? > I disagree that we should fix non-critical bugs or regression. > > If the bug has been there for several years already and the user could live > with it, they can continue to work it around unti they upgrade to the newer > Qt. It can be seen as a feature. > > Our product is the latest version of Qt. LTS means previous versions stay > supported, not actively developped. The rationale IMHO is a direct consequence of the target audience of an LTS. What's the purpose of an LTS? Why do we jump through hoops to mainain an outdated codebase for three year? Because the LTS is for users who _cannot_ update to newer Qts (for whatever reason, dropped platforms just being one of them). Pointing them to a newer Qt where their bug is fixed is not going to help them one bit. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From jedrzej.nowacki at qt.io Tue Aug 16 11:15:21 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Tue, 16 Aug 2016 11:15:21 +0200 Subject: [Development] Which changes are suitable for 5.6? In-Reply-To: <201608121052.52787.marc.mutz@kdab.com> References: <201608121052.52787.marc.mutz@kdab.com> Message-ID: <7012001.b7SaITXe3R@42> On fredag 12. august 2016 10.52.52 CEST Marc Mutz wrote: > Hi, > > I'd like to know what the rules are supposed to for submitting to 5.6 (LTS). > > Should we enforce the strict rules of other minor releases (only regressions > and P2+)? I strongly believe that autotests improvements should go to LTS, flaky and broken tests affect all branches. Cheers, Jędrek From jani.heikkinen at qt.io Tue Aug 16 17:13:53 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 16 Aug 2016 15:13:53 +0000 Subject: [Development] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming... In-Reply-To: References: Message-ID: Hi all, We have still issues with qt5.git integration in 'dev' and some configuration system related changes are missing as well. That's why we agreed to postpone final branching (&FF) a bit in today's release team meeting (memo coming later). New target is Monday 22nd August 2016. Please do not merge new stuff into dev (that's not strictly required for 5.8) at this point to help us with qt5.git integration. Especially please avoid changes to public or internal APIs for this one week. Br, Jani From: Jani Heikkinen Sent: 8. elokuuta 2016 13:58 To: development at qt-project.org Cc: releasing at qt-project.org Subject: HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming... Hi all, Qt5.git integration in 'dev' succeed during the weekend and we have soft branched '5.8' from 'dev'. It means Qt 5.8 Feature Freeze will be effect 15th August 2016 as well as final branching from 'dev' to '5.8' So please start using '5.8' for changes targeted to Qt 5.8 release and finalize ongoing ones in 'dev'. Final downmerge from 'dev' to '5.8' will happen Monday 15th Aug (morning). Please make sure - All new modules for Qt 5.8 are in 'dev' & part of qt5.git - All mandatory new features are in 'dev' now or coming in within a week? - New feature page contains all new features etc: https://wiki.qt.io/New_Features_in_Qt_5.8 We will create first src packages from latest qt5.git integration as soon as possible. Please check the packages immediately when available to see if something important is missing. Those packages should be quite close to Qt 5.8 alpha packages so it will be really important to check the packages now. br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From kuba at mareimbrium.org Wed Aug 17 17:31:28 2016 From: kuba at mareimbrium.org (Kuba Ober) Date: Wed, 17 Aug 2016 11:31:28 -0400 Subject: [Development] Patch to fix ANGLE build for XP targets in Qt 5.7.0 Message-ID: Attached is a patch against 5.7.0 release to fix ANGLE to build for the Windows XP target. I don’t have the time to submit a proper change via gerrit, so I’ll leave it out here for grabs if anyone is interested. Other than that, 5.7 builds fine under MSVC 2015 configured with -target xp -skip qtwebengine Kuba P.S. I have agreed to the contributor agreement. -------------- next part -------------- A non-text attachment was scrubbed... Name: qt5fixes.patch Type: application/octet-stream Size: 2930 bytes Desc: not available URL: From thiago.macieira at intel.com Wed Aug 17 22:07:22 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 17 Aug 2016 13:07:22 -0700 Subject: [Development] Patch to fix ANGLE build for XP targets in Qt 5.7.0 In-Reply-To: References: Message-ID: <2072564.PhZUFGko2u@tjmaciei-mobl1> On quarta-feira, 17 de agosto de 2016 11:31:28 PDT Kuba Ober wrote: > Attached is a patch against 5.7.0 release to fix ANGLE to build for the > Windows XP target. I don’t have the time to submit a proper change via > gerrit, so I’ll leave it out here for grabs if anyone is interested. Windows XP is not supported in 5.7.0 and I'm sure it won't even start, since we're using functions we *know* don't exist in it. > > Other than that, 5.7 builds fine under MSVC 2015 configured with -target xp > -skip qtwebengine > > Kuba > > P.S. I have agreed to the contributor agreement. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From poizan at poizan.dk Thu Aug 18 16:26:30 2016 From: poizan at poizan.dk (Kasper F. Brandt) Date: Thu, 18 Aug 2016 16:26:30 +0200 Subject: [Development] qtbase/d8be811 makes it impossible to specify include path for zlib when building qtbase? Message-ID: In d8be811[0] qt_build_extra was made to skip the inclusion of EXTRA_DEFINES, EXTRA_INCLUDEPATH and EXTRA_LIBS into resp. DEFINES, INCLUDEPATH and INCLUDEPATH. This means that if you e.g. try to specify the include path to zlib with -I to configure then the compilation of bootstrap fails in qbytearray.cpp because it can't find zconf.h. Is there some other way you are supposed to specify the include path, or is this an oversight? [0]:d8be8110a484460504b977dade5f163ee37b8225 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Aug 18 16:58:47 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 18 Aug 2016 07:58:47 -0700 Subject: [Development] qtbase/d8be811 makes it impossible to specify include path for zlib when building qtbase? In-Reply-To: References: Message-ID: <2047366.TZ6fuigM2l@tjmaciei-mobl1> On quinta-feira, 18 de agosto de 2016 16:26:30 PDT Kasper F. Brandt wrote: > Is there some other way you are supposed to specify the include path, or is > this an oversight? It's coming back in another commit. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jedrzej.nowacki at qt.io Thu Aug 18 17:41:32 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Thu, 18 Aug 2016 17:41:32 +0200 Subject: [Development] Module maintainers: action required (Coin slowly migrates from sync.profile to .gitmodules) Message-ID: <2756158.WOgs6TtE6b@42> Hi, Short version: We plan to migrate from using sync.profile to qt5/.gitmodules in Coin, so please make sure that the files are in sync and that they contain sensible informations in every actively maintained branch. Long version: Currently, for every integration Coin is reading module dependency from sync.profile which is stored in the root directory of every module. The file contains section that looks more or less like that: %dependencies = ( "qtbase" => "", "qtxmlpatterns" => "", ); Which means that the module depends on qtbase and qtxmlpatterns. Now this approach happened to be not flexible enough, as it doesn't allow to easily define an alternative dependency chain without changing content of the module or forcing rebuild of depending modules. We want to migrate to qt5/.gitmodules that looks like that: [submodule "qtdeclarative"] depends = qtbase recommends = qtsvg qtxmlpatterns path = qtdeclarative url = ../qtdeclarative.git branch = dev status = essential As it leave outside of the module we can easily use a shadow definition that overwrites certain aspects of it. As a bonus changing .gitmodules would trigger partial qt5 check, verifying if all leaf modules are intact. For integrations Coin will use union of "depends" and "recommends" fields. Thank you! Jędrek ps. I heard rumors that Oswald want deprecate sync.profile too :-) From dominik.holland at pelagicore.com Thu Aug 18 17:46:41 2016 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Thu, 18 Aug 2016 17:46:41 +0200 Subject: [Development] Module maintainers: action required (Coin slowly migrates from sync.profile to .gitmodules) In-Reply-To: <2756158.WOgs6TtE6b@42> References: <2756158.WOgs6TtE6b@42> Message-ID: Am 08/18/2016 um 05:41 PM schrieb Jędrzej Nowacki: > Hi, > > Short version: > We plan to migrate from using sync.profile to qt5/.gitmodules in Coin, so > please make sure that the files are in sync and that they contain sensible > informations in every actively maintained branch. > > Long version: > Currently, for every integration Coin is reading module dependency from > sync.profile which is stored in the root directory of every module. The file > contains section that looks more or less like that: > %dependencies = ( > "qtbase" => "", > "qtxmlpatterns" => "", > ); > Which means that the module depends on qtbase and qtxmlpatterns. Now this > approach happened to be not flexible enough, as it doesn't allow to easily > define an alternative dependency chain without changing content of the module > or forcing rebuild of depending modules. We want to migrate to qt5/.gitmodules > that looks like that: > [submodule "qtdeclarative"] > depends = qtbase > recommends = qtsvg qtxmlpatterns > path = qtdeclarative > url = ../qtdeclarative.git > branch = dev > status = essential > As it leave outside of the module we can easily use a shadow definition that > overwrites certain aspects of it. As a bonus changing .gitmodules would > trigger partial qt5 check, verifying if all leaf modules are intact. > For integrations Coin will use union of "depends" and "recommends" fields. How are the dependencies managed for projects/modules which are not part of the qt5.git but are part of coin ? Dominik > > Thank you! > Jędrek > > ps. I heard rumors that Oswald want deprecate sync.profile too :-) > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Dominik Holland SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany +49 (0)171 760 25 96 dominik.holland at pelagicore.com www.pelagicore.com From charles.a.claunch at nasa.gov Thu Aug 18 22:12:00 2016 From: charles.a.claunch at nasa.gov (Claunch, Charles A. (JSC-ER4)[Jacobs Technology, Inc.]) Date: Thu, 18 Aug 2016 20:12:00 +0000 Subject: [Development] QtBluetooth Reading Advertising Data Message-ID: <48E23A32F386ED42A2684E989D22E2C2135A8A4B@NDJSMBX103.ndc.nasa.gov> I'm using QtBluetooth (5.7.0) to build a device which can read various Bluetooth Low Energy devices. I've been successful in reading lots of devices, heart rate monitors and really any device which reads/writes BLE characteristics. As I test more devices I find that a lot of newer devices pass the desired data directly in the BLE advertising data. As of Qt 5.7 I see no way to access this data directly. I assume the underlying code uses it otherwise it wouldn't be able to read the devices in the first place. I noticed the early versions of Qt 5.8 include methods to broadcast BLE advertising data, but I still don't see any methods to read said data. Is this in the plan or could perhaps be simple to expose the underlying methods? Thanks, Chuck Claunch -------------- next part -------------- An HTML attachment was scrubbed... URL: From timur.kristof at gmail.com Fri Aug 19 00:14:57 2016 From: timur.kristof at gmail.com (Timur =?ISO-8859-1?Q?Krist=F3f?=) Date: Fri, 19 Aug 2016 00:14:57 +0200 Subject: [Development] QtBluetooth Reading Advertising Data In-Reply-To: <48E23A32F386ED42A2684E989D22E2C2135A8A4B@NDJSMBX103.ndc.nasa.gov> References: <48E23A32F386ED42A2684E989D22E2C2135A8A4B@NDJSMBX103.ndc.nasa.gov> Message-ID: <1471558497.13875.26.camel@gmail.com> Hi Chuck, I asked the same question a couple of months ago. Take a look at this thread: http://lists.qt-project.org/pipermail/interest/2016-June/023287.html And this bug report: https://bugreports.qt.io/browse/QTBUG-46008 Best regards, Timur On cs, 2016-08-18 at 20:12 +0000, Claunch, Charles A. (JSC-ER4)[Jacobs Technology, Inc.] wrote: > I’m using QtBluetooth (5.7.0) to build a device which can read > various Bluetooth Low Energy devices.  I’ve been successful in > reading lots of devices, heart rate monitors and really any device > which reads/writes BLE characteristics.  As I test more devices I > find that a lot of newer devices pass the desired data directly in > the BLE advertising data.  As of Qt 5.7 I see no way to access this > data directly.  I assume the underlying code uses it otherwise it > wouldn’t be able to read the devices in the first place.  I noticed > the early versions of Qt 5.8 include methods to broadcast BLE > advertising data, but I still don’t see any methods to read said > data.  Is this in the plan or could perhaps be simple to expose the > underlying methods? > Thanks, > Chuck Claunch > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jedrzej.nowacki at qt.io Fri Aug 19 08:52:59 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 19 Aug 2016 08:52:59 +0200 Subject: [Development] Module maintainers: action required (Coin slowly migrates from sync.profile to .gitmodules) In-Reply-To: References: <2756158.WOgs6TtE6b@42> Message-ID: <16176940.ZuU55maq73@42> On torsdag 18. august 2016 17.46.41 CEST Dominik Holland wrote: > How are the dependencies managed for projects/modules which are not part > of the qt5.git but are part of coin ? > > Dominik That is the reason of migrating "slowly". We need to define/find a product repository for them. Such super repository would define testing platforms, configurations and dependencies configurations. For experimental modules and in general, playground I would propose to create "qt-labs" product. Cheers, Jędrek From oswald.buddenhagen at qt.io Fri Aug 19 12:53:25 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 19 Aug 2016 12:53:25 +0200 Subject: [Development] qtbase/d8be811 makes it impossible to specify include path for zlib when building qtbase? In-Reply-To: <2047366.TZ6fuigM2l@tjmaciei-mobl1> Message-ID: <20160819105325.GI3560@troll08> On Thu, Aug 18, 2016 at 04:26:30PM +0200, Kasper F. Brandt wrote: > In d8be811[0] qt_build_extra was made to skip the inclusion of > EXTRA_DEFINES, EXTRA_INCLUDEPATH and EXTRA_LIBS into resp. > DEFINES, INCLUDEPATH and INCLUDEPATH. This means that if you e.g. try to > specify the include path to zlib with -I to > configure then the compilation of bootstrap fails in qbytearray.cpp because > it can't find zconf.h. > if it fails to find the .h now, it will fail to find the .so/.a later on as well. it could have worked before only if you mixed the host paths into the target paths, and made sure that the target would not actually use them (i.e., -qt-zlib, and having the paths not contain any of the other libraries qt could find), which is rather fragile. > Is there some other way you are supposed to specify the include path, > or is this an oversight? > i think the commit message is pretty clear in this regard. On Thu, Aug 18, 2016 at 07:58:47AM -0700, Thiago Macieira wrote: > On quinta-feira, 18 de agosto de 2016 16:26:30 PDT Kasper F. Brandt wrote: > > Is there some other way you are supposed to specify the include > > path, or is this an oversight? > > It's coming back in another commit. > the commit you're thinking of (which is in dev, not 5.6, for that matter) still would not enable overrides of the host configuration (we discussed that option, but i didn't implement it so far). From poizan at poizan.dk Fri Aug 19 15:22:52 2016 From: poizan at poizan.dk (Kasper F. Brandt) Date: Fri, 19 Aug 2016 15:22:52 +0200 Subject: [Development] qtbase/d8be811 makes it impossible to specify include path for zlib when building qtbase? In-Reply-To: <20160819105325.GI3560@troll08> References: <2047366.TZ6fuigM2l@tjmaciei-mobl1> <20160819105325.GI3560@troll08> Message-ID: On Fri, Aug 19, 2016 at 12:53 PM, Oswald Buddenhagen < oswald.buddenhagen at qt.io> wrote: > On Thu, Aug 18, 2016 at 04:26:30PM +0200, Kasper F. Brandt wrote: > > In d8be811[0] qt_build_extra was made to skip the inclusion of > > EXTRA_DEFINES, EXTRA_INCLUDEPATH and EXTRA_LIBS into resp. > > DEFINES, INCLUDEPATH and INCLUDEPATH. This means that if you e.g. try to > > specify the include path to zlib with -I to > > configure then the compilation of bootstrap fails in qbytearray.cpp > because > > it can't find zconf.h. > > > if it fails to find the .h now, it will fail to find the .so/.a later > on as well. > I'm building against a static zlib build (on windows actually), and I can tell that it works just fine if I revert that commit. > it could have worked before only if you mixed the host paths into the > target paths, and made sure that the target would not actually use them > (i.e., -qt-zlib, and having the paths not contain any of the other > libraries qt could find), which is rather fragile. > It only applies to host builds so I don't understand this. The target and the host systems are the same. > Is there some other way you are supposed to specify the include path, > > or is this an oversight? > > > i think the commit message is pretty clear in this regard. > > make -D/-I/-L/-l/-R not affect bootstrapped tools No? -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Fri Aug 19 20:35:56 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 19 Aug 2016 21:35:56 +0300 Subject: [Development] [Announcement] QtWebKit Technology Preview 3 Message-ID: <901791471631756@web19o.yandex.ru> Hello everyone, We are pleased to announce QtWebKit Technology Preview 3! Highlights of this release are: * NPAPI and Qt plugins are finally supported on X11 and Windows (not on macOS yet, sorry) * Bulk of the patches which have never been in the trunk of webkit.org was merged from Qt repository. Also, some regressions resulting from migration to new WebKit branch were fixed, which means that now there's very little chance for you to hit a bug already fixed a year or two ago :) * Now we finally have nice compact tarballs, and lightweight git repository for those of you who just wants to build the bleeding edge and is not going to develop QtWebKit itself [1] More detailed release changelog, as well as binary builds you can find at https://github.com/annulen/webkit/releases/tag/qtwebkit-tp3 If you are wondering what is the deal with QtWebKit raised back from the dead, please read the following post (it also has a few screenshots): http://qtwebkit.blogspot.ru/2016/08/qtwebkit-im-back.html ---- [1] https://github.com/annulen/qtwebkit-snapshots -- Regards, Konstantin From thiago.macieira at intel.com Fri Aug 19 20:42:05 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 19 Aug 2016 11:42:05 -0700 Subject: [Development] [QML]: Register global enums/flags to QML ? In-Reply-To: <3367699.x3TbY3ak5d@debian> References: <1610394.huzr6IiSWS@debian> <4011190.8qyANoXpTy@maurice> <3367699.x3TbY3ak5d@debian> Message-ID: <20446620.RvLEYjfbPl@tjmaciei-mobl1> On quinta-feira, 28 de julho de 2016 10:54:31 PDT BogDan Vatra wrote: > Thanks Olivier! > > I created two new taks: > - https://bugreports.qt.io/browse/QTBUG-54981 (moc part) > - https://bugreports.qt.io/browse/QTBUG-54982 (qml part) The first part was merged. Sorry, but this is too big a feature to develop in a few days shortly before the feature freeze. This new feature should wait for 5.9. I wasn't paying attention because I thought it was understood by everyone involved. So I am reverting the change. https://codereview.qt-project.org/168651 Please justify in 24 hours why this feature is so urgent that it should go to 5.8 and risk destabilising the release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Fri Aug 19 21:16:03 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 19 Aug 2016 22:16:03 +0300 Subject: [Development] [Interest] [Announcement] QtWebKit Technology Preview 3 In-Reply-To: References: <901791471631756@web19o.yandex.ru> Message-ID: <944751471634163@web19o.yandex.ru> 19.08.2016, 22:08, "Jason H" : >>  Hello everyone, >> >>  We are pleased to announce QtWebKit Technology Preview 3! >> >>  Highlights of this release are: >> >>  * NPAPI and Qt plugins are finally supported on X11 and Windows (not on macOS >>  yet, sorry) >> >>  * Bulk of the patches which have never been in the trunk of webkit.org was >>  merged from Qt repository. Also, some regressions resulting from migration to >>  new WebKit branch were fixed, which means that now there's very little chance >>  for you to hit a bug already fixed a year or two ago :) >> >>  * Now we finally have nice compact tarballs, and lightweight git repository for >>  those of you who just wants to build the bleeding edge and is not going to >>  develop QtWebKit itself [1] >> >>  More detailed release changelog, as well as binary builds you can find at >> >>  https://github.com/annulen/webkit/releases/tag/qtwebkit-tp3 >> >>  If you are wondering what is the deal with QtWebKit raised back from the dead, >>  please read the following post (it also has a few screenshots): >> >>  http://qtwebkit.blogspot.ru/2016/08/qtwebkit-im-back.html > > If I understand correctly, QtWebKIT cannot be used on iOS? We're still only able to use QtWebENGINE? Unfortunately you cannot use any of them, the only working solution is Qt WebView module. And while it's theoretically possible to make QtWebKit working on iOS platform, you will be able to use it only for in-house application, as App Store rules forbid use of 3rd party browser engines. If this limited use case is interesting for anyone, you are welcome to contribute iOS support! -- Regards, Konstantin From Jake.Petroules at qt.io Sat Aug 20 01:32:21 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 19 Aug 2016 23:32:21 +0000 Subject: [Development] Qt on Apple watchOS Message-ID: Hi All, Preliminary support for Qt on Apple watchOS has been merged to dev branch (targeting Qt 5.9): https://codereview.qt-project.org/#/c/159725/ Due to platform limitations, there is no support for graphical content like QtWidgets, QML, etc., but can be useful for sharing cross platform backend code. -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Mon Aug 22 08:28:17 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 22 Aug 2016 06:28:17 +0000 Subject: [Development] First Qt 5.6.2 snapshot available In-Reply-To: References: Message-ID: Hi all, We have finally first Qt 5.6.2 snapshot available for testing Windows: http://download.qt.io/snapshots/qt/5.6/5.6.2/543/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.2/478/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.2/410/ src: http://download.qt.io/snapshots/qt/5.6/5.6.2/latest_src/ Please test the packages to see where we are with Qt 5.6.2 release. We are trying to release Qt5.6.2 as soon as possible (during September) so please make sure all release blockers are visible in blocker list (https://bugreports.qt.io/issues/?filter=17829) Packages are RTA smoke tested and it seems packages are good enough for testing. Known issues from RTA can be found from here: https://bugreports.qt.io/issues/?filter=17837 br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Mon Aug 22 13:03:07 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 22 Aug 2016 13:03:07 +0200 Subject: [Development] qtbase/d8be811 makes it impossible to specify include path for zlib when building qtbase? In-Reply-To: References: <2047366.TZ6fuigM2l@tjmaciei-mobl1> <20160819105325.GI3560@troll08> Message-ID: <20160822110307.GK3560@troll08> On Fri, Aug 19, 2016 at 03:22:52PM +0200, Kasper F. Brandt wrote: > On Fri, Aug 19, 2016 at 12:53 PM, Oswald Buddenhagen wrote: > > On Thu, Aug 18, 2016 at 04:26:30PM +0200, Kasper F. Brandt wrote: > > > In d8be811[0] qt_build_extra was made to skip the inclusion of > > > EXTRA_DEFINES, EXTRA_INCLUDEPATH and EXTRA_LIBS into resp. > > > DEFINES, INCLUDEPATH and INCLUDEPATH. This means that if you e.g. try to > > > specify the include path to zlib with -I to > > > configure then the compilation of bootstrap fails in qbytearray.cpp > > > because it can't find zconf.h. > > > > > if it fails to find the .h now, it will fail to find the .so/.a later > > on as well. > > > I'm building against a static zlib build (on windows actually), and I can > tell that it works just fine if I revert that commit. > nothing follows from that, as it's consistent with what i said. > > it could have worked before only if you mixed the host paths into the > > target paths, and made sure that the target would not actually use them > > (i.e., -qt-zlib, and having the paths not contain any of the other > > libraries qt could find), which is rather fragile. > > > It only applies to host builds so I don't understand this. > The target and the host systems are the same. > that is actually the relevant data point. fix uploaded. > > > Is there some other way you are supposed to specify the include path, > > > or is this an oversight? > > > > > i think the commit message is pretty clear in this regard. > > > > > make -D/-I/-L/-l/-R not affect bootstrapped tools > > No? > the commit message is longer than that. From edward.welbourne at qt.io Mon Aug 22 13:40:39 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 22 Aug 2016 11:40:39 +0000 Subject: [Development] Dead wip/ branches Message-ID: Hi all, We have a few old wip/ branches that appear to be ready for removal. * wip/qstring-utf8 - integrated long ago (2012) * wip/tizen - apparently abandoned (2015), is anyone interested ? * wip/mir - integrated 2015-08-09 There's a little more detail on each at [0]. [0] https://wiki.qt.io/Branches Does anyone object to removal of these branches from gerrit ? Let me know if you do and I'll stay the executioner's chainsaw ... The two that have been integrated might be of historical interest. There might be someone out there who wants to revive tizen; if so, please (let me know and) edit [0] to say what on earth it is ! Indeed, anyone who knows more about other wip/ branches listed at [0], please take a moment to update it, or at least drop me a line so that I can, Eddy. From gerry.boland at canonical.com Mon Aug 22 16:43:32 2016 From: gerry.boland at canonical.com (Gerry Boland) Date: Mon, 22 Aug 2016 15:43:32 +0100 Subject: [Development] Dead wip/ branches In-Reply-To: References: Message-ID: On 22/08/16 12:40, Edward Welbourne wrote: > Hi all, > > We have a few old wip/ branches that appear to be ready for removal. > > * wip/qstring-utf8 - integrated long ago (2012) > * wip/tizen - apparently abandoned (2015), is anyone interested ? > * wip/mir - integrated 2015-08-09 > > There's a little more detail on each at [0]. > [0] https://wiki.qt.io/Branches > > Does anyone object to removal of these branches from gerrit ? > Let me know if you do and I'll stay the executioner's chainsaw ... > The two that have been integrated might be of historical interest. > > There might be someone out there who wants to revive tizen; if so, > please (let me know and) edit [0] to say what on earth it is ! > > Indeed, anyone who knows more about other wip/ branches listed at [0], > please take a moment to update it, or at least drop me a line so that I > can, > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > Hi Eddy, can I request a stay of execution for wip/mir. We're iterating the code in our repository (lp:qtmir) but plan to update this wip branch once we're happy with the features and apis Thanks -Gerry From oswald.buddenhagen at qt.io Mon Aug 22 17:10:48 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 22 Aug 2016 17:10:48 +0200 Subject: [Development] [Releasing] HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming... In-Reply-To: References: Message-ID: <20160822151048.GM3560@troll08> the final downmerge from dev to 5.8 is now completed. 5.8 is now officially feature-frozen, approved exceptions notwithstanding. dev is 5.9 material now. as usual, cherry-picks only with a *really* good justification _and_ bribe/sacrifice. get your 5.8 must-have changes re-targeted *before* integrating. On Tue, Aug 16, 2016 at 03:13:53PM +0000, Jani Heikkinen wrote: > Hi all, > > We have still issues with qt5.git integration in 'dev' and some configuration system related changes are missing as well. That's why we agreed to postpone final branching (&FF) a bit in today's release team meeting (memo coming later). New target is Monday 22nd August 2016. > > Please do not merge new stuff into dev (that's not strictly required for 5.8) at this point to help us with qt5.git integration. Especially please avoid changes to public or internal APIs for this one week. > > Br, > Jani > > From: Jani Heikkinen > Sent: 8. elokuuta 2016 13:58 > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: HEADS-UP: Branching from 'dev' to '5.8' ongoing, Qt 5.8 Feature Freeze coming... > > > Hi all, > > > > Qt5.git integration in 'dev' succeed during the weekend and we have soft branched '5.8' from 'dev'. It means Qt 5.8 Feature Freeze will be effect 15th August 2016 as well as final branching from 'dev' to '5.8' > > > > So please start using '5.8' for changes targeted to Qt 5.8 release and finalize ongoing ones in 'dev'. Final downmerge from 'dev' to '5.8' will happen Monday 15th Aug (morning). > > > > Please make sure > > - All new modules for Qt 5.8 are in 'dev' & part of qt5.git > > - All mandatory new features are in 'dev' now or coming in within a week? > > - New feature page contains all new features etc: https://wiki.qt.io/New_Features_in_Qt_5.8 > > > > We will create first src packages from latest qt5.git integration as soon as possible. Please check the packages immediately when available to see if something important is missing. Those packages should be quite close to Qt 5.8 alpha packages so it will be really important to check the packages now. > > > br, > Jani > > > > Jani Heikkinen > Release Manager > > The Qt Company > Elektroniikkatie 13 > 90590 Oulu Finland > jani.heikkinen at qt.io > +358 50 4873735 > http://qt.io > > > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] > > > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing From edward.welbourne at qt.io Mon Aug 22 18:36:26 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 22 Aug 2016 16:36:26 +0000 Subject: [Development] Dead wip/ branches In-Reply-To: References: , Message-ID: On 22/08/16 12:40, Edward Welbourne wrote: >> We have a few old wip/ branches that appear to be ready for removal. >> >> * wip/qstring-utf8 - integrated long ago (2012) >> * wip/tizen - apparently abandoned (2015), is anyone interested ? >> * wip/mir - integrated 2015-08-09 >> >> There's a little more detail on each at [0]. >> [0] https://wiki.qt.io/Branches Gerry Boland replied: > can I request a stay of execution for wip/mir. Yes - this was the point of the exercise :-) > We're iterating the code in our repository (lp:qtmir) but plan to > update this wip branch once we're happy with the features and apis OK. I trust the new work shall be based on some more recent point in Qt's history ... Eddy. From ernst.maurer at gmail.com Tue Aug 23 15:06:40 2016 From: ernst.maurer at gmail.com (Ernst Maurer) Date: Tue, 23 Aug 2016 13:06:40 +0000 Subject: [Development] Gerrit setting up Message-ID: for the joining to the development, I'm trying to set up gerrit account. could someone assist with an issue: 1. logon to gerrit using this (ernst.maurer at gmail.com) address, I'm using the same addresss for all other Qt services too, including this maillist:, 2. see that address field in gerrit account is empty 3. trying to register this email from settings. 4. get confirmation email and go throu the link 5. "Identify is already in use" error message what is wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Tue Aug 23 16:07:40 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 23 Aug 2016 16:07:40 +0200 Subject: [Development] Gerrit setting up In-Reply-To: References: Message-ID: <20160823140740.GN3560@troll08> On Tue, Aug 23, 2016 at 01:06:40PM +0000, Ernst Maurer wrote: > for the joining to the development, I'm trying to set up gerrit account. > could someone assist with an issue: > 1. logon to gerrit using this (ernst.maurer at gmail.com) address, > I'm using the same addresss for all other Qt services too, including this > maillist:, > 2. see that address field in gerrit account is empty > 3. trying to register this email from settings. > 4. get confirmation email and go throu the link > 5. "Identify is already in use" error message > what is wrong? > you had two pre-existing gerrit (and jira) accounts. From ernst.maurer at gmail.com Tue Aug 23 16:13:27 2016 From: ernst.maurer at gmail.com (Ernst Maurer) Date: Tue, 23 Aug 2016 14:13:27 +0000 Subject: [Development] Gerrit setting up In-Reply-To: <20160823140740.GN3560@troll08> References: <20160823140740.GN3560@troll08> Message-ID: does it mean that I don't need to continue my attempts to fill upmy address ? and can use gerrit "as-is" ("as-is" - means with empty email address?) On Tue, Aug 23, 2016 at 5:08 PM Oswald Buddenhagen wrote: > On Tue, Aug 23, 2016 at 01:06:40PM +0000, Ernst Maurer wrote: > > for the joining to the development, I'm trying to set up gerrit account. > > could someone assist with an issue: > > 1. logon to gerrit using this (ernst.maurer at gmail.com) address, > > I'm using the same addresss for all other Qt services too, including this > > maillist:, > > 2. see that address field in gerrit account is empty > > 3. trying to register this email from settings. > > 4. get confirmation email and go throu the link > > 5. "Identify is already in use" error message > > what is wrong? > > > you had two pre-existing gerrit (and jira) accounts. > > _______________________________________________ > 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 edward.welbourne at qt.io Tue Aug 23 17:32:12 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 23 Aug 2016 15:32:12 +0000 Subject: [Development] Gerrit setting up In-Reply-To: References: <20160823140740.GN3560@troll08>, Message-ID: On Tue, Aug 23, 2016 at 5:08 PM Oswald Buddenhagen > wrote: >> you had two pre-existing gerrit (and jira) accounts. Ernst Maurer asked > does it mean that I don't need to continue my attempts to fill upmy address ? > and can use gerrit "as-is" ("as-is" - means with empty email address?) Hopefully, if you go to the Sign In or Log In link at the top right of a page, you should be able to tell the log-in form to reset your password or send you a new one, so that you can log in with your e-mail address and participate as your earlier-created persona. Eddy. From ernst.maurer at gmail.com Tue Aug 23 17:50:12 2016 From: ernst.maurer at gmail.com (Ernst Maurer) Date: Tue, 23 Aug 2016 15:50:12 +0000 Subject: [Development] Gerrit setting up In-Reply-To: References: <20160823140740.GN3560@troll08> Message-ID: did it. logged off, reset a password. log into gerrit again in the profile - still empty email address in Identifies: two rows: first one with an alias name and empty address (no option to delete this row) second one - with expected address but empty name. On Tue, Aug 23, 2016 at 6:32 PM Edward Welbourne wrote: > On Tue, Aug 23, 2016 at 5:08 PM Oswald Buddenhagen < > oswald.buddenhagen at qt.io> wrote: > >> you had two pre-existing gerrit (and jira) accounts. > > Ernst Maurer asked > > does it mean that I don't need to continue my attempts to fill upmy > address ? > > and can use gerrit "as-is" ("as-is" - means with empty email address?) > > Hopefully, if you go to the Sign In or Log In link at the top right of a > page, you should be able to tell the log-in form to reset your password > or send you a new one, so that you can log in with your e-mail address > and participate as your earlier-created persona. > > Eddy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Tue Aug 23 18:07:26 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 23 Aug 2016 16:07:26 +0000 Subject: [Development] Gerrit setting up In-Reply-To: References: <20160823140740.GN3560@troll08> , Message-ID: > reset a password. > log into gerrit again OK, so you can log in. > in the profile - still empty email address > in Identifies: two rows: > first one with an alias name and empty address (no option to delete this row) > second one - with expected address but empty name. This table is a bit of an odd way to present information, but it's all one Identity, to which you can attach many e-mail addresses; the first row tells you the identity name, the later rows list the e-mail addresses and have check-boxes to let you select them (for deletion). If you want to add a new e-mail address, go to Contact Information (in the left panel), and hit its "Register New Email" button; that'll get you a pop-up to tell it a new address. Once that's registered, I presume it shows up in the Identity "table" as a new address row. At least, I think that's how come I have two now ... You might have to log out and log back in again before a new e-mail address shows up. Yes, it's a weird UI. Does that answer what you were trying to do ? If not ... what were you trying to do, that you can't see how to do ? Eddy. From ernst.maurer at gmail.com Tue Aug 23 18:11:40 2016 From: ernst.maurer at gmail.com (Ernst Maurer) Date: Tue, 23 Aug 2016 16:11:40 +0000 Subject: [Development] Gerrit setting up In-Reply-To: References: <20160823140740.GN3560@troll08> Message-ID: So seems from your words currently it's valid, I only want to confirm that account is valid for the development, I'll try to re login for the showing email if it's important. вт, 23 авг 2016 г., 19:07 Edward Welbourne : > > reset a password. > > log into gerrit again > > OK, so you can log in. > > > in the profile - still empty email address > > in Identifies: two rows: > > first one with an alias name and empty address (no option to delete this > row) > > second one - with expected address but empty name. > > This table is a bit of an odd way to present information, but it's all > one Identity, to which you can attach many e-mail addresses; the first > row tells you the identity name, the later rows list the e-mail > addresses and have check-boxes to let you select them (for deletion). > > If you want to add a new e-mail address, go to Contact Information (in > the left panel), and hit its "Register New Email" button; that'll get > you a pop-up to tell it a new address. Once that's registered, I > presume it shows up in the Identity "table" as a new address row. > At least, I think that's how come I have two now ... > > You might have to log out and log back in again before a new e-mail > address shows up. > > Yes, it's a weird UI. > Does that answer what you were trying to do ? > If not ... what were you trying to do, that you can't see how to do ? > > Eddy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Wed Aug 24 12:03:44 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 24 Aug 2016 10:03:44 +0000 Subject: [Development] HEADS-UP: Branching from '5.6' to '5.6.2' ongoing In-Reply-To: References: Message-ID: Hi all, We have soft branched '5.6.2' from '5.6'. Final downmerge will happen after a week so there is enough time to start using '5.6.2' for fixes targeted to Qt 5.6.2 and finalize ongoing ones in '5.6'. br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Aug 24 15:23:01 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 24 Aug 2016 15:23:01 +0200 Subject: [Development] Should qMetaTypeId() == qMetaTypeId() ? Message-ID: <201608241523.02049.marc.mutz@kdab.com> Hi, Currently, it's not, which doesn't make much sense, does it? So, template int qMetyTypeId() { return qMetaTypeIdHelper::type>(); } ? (There's of course a lot more involved in this, registration should discard const, too, e.g.). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Wed Aug 24 16:05:40 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 Aug 2016 07:05:40 -0700 Subject: [Development] Should qMetaTypeId() == qMetaTypeId() ? In-Reply-To: <201608241523.02049.marc.mutz@kdab.com> References: <201608241523.02049.marc.mutz@kdab.com> Message-ID: <2456650.NzAsUGFcqd@tjmaciei-mobl1> On quarta-feira, 24 de agosto de 2016 15:23:01 PDT Marc Mutz wrote: > Hi, > > Currently, it's not, which doesn't make much sense, does it? No, but const types can't be registered as metatypes either. Shouldn't the caller drop the const qualifier on its own? > template > int qMetyTypeId() { > return qMetaTypeIdHelper::type>(); > } > > ? > > (There's of course a lot more involved in this, registration should discard > const, too, e.g.). Registration of const should be ill-formed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jedrzej.nowacki at qt.io Wed Aug 24 16:06:50 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Wed, 24 Aug 2016 16:06:50 +0200 Subject: [Development] Should qMetaTypeId() == qMetaTypeId() ? In-Reply-To: <201608241523.02049.marc.mutz@kdab.com> References: <201608241523.02049.marc.mutz@kdab.com> Message-ID: <6662597.K5zcpoVmBg@42> On onsdag 24. august 2016 15.23.01 CEST Marc Mutz wrote: > Hi, > > Currently, it's not, which doesn't make much sense, does it? > > So, > > template > int qMetyTypeId() { > return qMetaTypeIdHelper::type>(); > } > > ? > > (There's of course a lot more involved in this, registration should discard > const, too, e.g.). > > Thanks, > Marc Hi, From C++ perspective const T and T are kind of separate types, metatype mimics that. QMetaType is used in many places and in some constness matters. Consider that example: QMetaType::typeName(qMetaTypeId()) and QMetaType::typeName(qMetaTypeId()) The function is used in metaobject to compute signatures of invokables. Cheers, Jędrek From kuba at mareimbrium.org Wed Aug 24 20:05:56 2016 From: kuba at mareimbrium.org (Kuba Ober) Date: Wed, 24 Aug 2016 14:05:56 -0400 Subject: [Development] Would it make sense to make QObject moveable in Qt 6? Message-ID: <65F325A6-F77D-4C21-A996-12D29E30CC50@mareimbrium.org> `QObject` is already pretty much a handle to the underlying data due to pimpl. So that’s a good first step. To support this, the `QObject*` (and derived types) would be replaced with `QObject::Handle` that keeps a pimpl C pointer. E.g. we’d have `QObject::Handle * QObjectData::parent, QList QObjectData::children`. Q_OBJECT macro would have to define: 1. the Handle class, 2. Handle operator& that returns the handle instead of a pointer, 3. operator Handle()() to let an object reference be usable in the context of an object handle. Hopefully C++11 provides enough magic to allow deduction of the class’s type in method definition without having to resort to Q_OBJECT(MyObject). The event list and QPointer would use that handle instead of `QObject*`, of course. qobject_cast would accept it too. E.g. currently you may have std::vector objps; /* or */ std::vector objps; std::list objs; objs.emplace_back(…); objps.push_back(&objs.back()); You would have: std::vector objps; /* or */ std::vector objps; std::vector objs; objs.emplace_back(…); /* or */ objs.push_back(std::move(some_instance)); // alternative 1 - an object is convertible to a handle objps.push_back(objs.back()); // alternative 2 - an address of an object is a handle objps.push_back(&objs.back()); I’d have to test it on some large code bases to see how much work it’d imply in terms of source-code incompatibility. To aid in porting, QT_LEGACY_OBJ_HANDLE would make all `AnyObjectClass::Handle` convertible to `AnyObjectClass*` to make this aspect source-compatible with Qt 5. I’m sure there’s plenty of stuff I’m missing. Please comment. Cheers, Kuba From thiago.macieira at intel.com Wed Aug 24 21:42:29 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 24 Aug 2016 12:42:29 -0700 Subject: [Development] Would it make sense to make QObject moveable in Qt 6? In-Reply-To: <65F325A6-F77D-4C21-A996-12D29E30CC50@mareimbrium.org> References: <65F325A6-F77D-4C21-A996-12D29E30CC50@mareimbrium.org> Message-ID: <2667075.ROJqDeUsIy@tjmaciei-mobl1> On quarta-feira, 24 de agosto de 2016 14:05:56 PDT Kuba Ober wrote: > `QObject` is already pretty much a handle to the underlying data due to > pimpl. So that’s a good first step. Except that everything refers to QObjects by pointer. QObject is not a holder to the private data, its address *is* the data. And its address is copyable, so if we replaced the pointer with something, we'd have to use something copyable and non-owning. > To support this, the `QObject*` (and derived types) would be replaced with > `QObject::Handle` that keeps a pimpl C pointer. E.g. we’d have > `QObject::Handle * QObjectData::parent, QList > QObjectData::children`. Major API break. I doubt we can accept that. > std::vector objps; std::vector > objs; > objs.emplace_back(…); /* or */ objs.push_back(std::move(some_instance)); > // alternative 1 - an object is convertible to a handle > objps.push_back(objs.back()); > // alternative 2 - an address of an object is a handle > objps.push_back(&objs.back()); As I said, the solution would need to be copyable, not just movable. So I think it throws everything you suggested into question. I've ignored the rest of your email that assumes that a movable solution is possible. > I’d have to test it on some large code bases to see how much work it’d imply > in terms of source-code incompatibility. To aid in porting, > QT_LEGACY_OBJ_HANDLE would make all `AnyObjectClass::Handle` convertible to > `AnyObjectClass*` to make this aspect source-compatible with Qt 5. That's everything that exists today. > I’m sure there’s plenty of stuff I’m missing. Please comment. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nospam at vuorela.dk Thu Aug 25 09:28:16 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Thu, 25 Aug 2016 07:28:16 +0000 (UTC) Subject: [Development] Would it make sense to make QObject moveable in Qt 6? References: <65F325A6-F77D-4C21-A996-12D29E30CC50@mareimbrium.org> <2667075.ROJqDeUsIy@tjmaciei-mobl1> Message-ID: On 2016-08-24, Thiago Macieira wrote: > And its address is copyable, so if we replaced the pointer with something, > we'd have to use something copyable and non-owning. class QObjectHandle { public: QObjectHandle(QObject* obj) : m_obj(obj) { } operator QObject* () const ( return m_obj.data() } bool operator==(const QObjectHandle& other) const { return m_obj == other.m_obj;} // default created rest of it is fine private: QPointer m_obj; } There. made it. Unsure what it gains us. /Sune From marc.mutz at kdab.com Thu Aug 25 11:48:07 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 25 Aug 2016 11:48:07 +0200 Subject: [Development] Would it make sense to make QObject moveable in Qt 6? In-Reply-To: <65F325A6-F77D-4C21-A996-12D29E30CC50@mareimbrium.org> References: <65F325A6-F77D-4C21-A996-12D29E30CC50@mareimbrium.org> Message-ID: <201608251148.07977.marc.mutz@kdab.com> On Wednesday 24 August 2016 20:05:56 Kuba Ober wrote: > `QObject` is already pretty much a handle to the underlying data due to > pimpl. So that’s a good first step. I challenge the notion that QObject is a handle to date. QObject is first and foremost the base class of a polymorphic class hierarchy. If you wrap that in a parallel value-like-but-not-quite class hierarchy, you end up with QDomNode. I don't like QDomNode. Do you like QDomNode? That said, the Copperspice guys argue that the implicit memory management of QObject parent-child relationships is becoming alien for C++ developers. The Qt community can of course deny every claim that comes from that direction, but sometimes the look of an outsider is valuable, too. After all, the API quality matters most for newbies, not decade-long Qt users. So IMO, it's certainly worth asking the question whether we should change something there, e.g. by using shared_ptr/weak_ptr to manage lifetimes. That would cover your use-case: std::vector> is all you were asking for. And wether you then use shared_ptr explicitly, or template using QObjectHandle = std::shared_ptr; is pretty much secondary. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From announce at qt-project.org Thu Aug 25 14:10:12 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 25 Aug 2016 12:10:12 +0000 Subject: [Development] [Announce] Qt Creator 4.1.0 released Message-ID: We are happy to announce the release of Qt Creator 4.1.0 https://blog.qt.io/blog/2016/08/25/qt-creator-4-1-0-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From kuba at mareimbrium.org Thu Aug 25 15:42:45 2016 From: kuba at mareimbrium.org (Kuba Ober) Date: Thu, 25 Aug 2016 09:42:45 -0400 Subject: [Development] Would it make sense to make QObject moveable in Qt 6? In-Reply-To: <201608251148.07977.marc.mutz@kdab.com> References: <65F325A6-F77D-4C21-A996-12D29E30CC50@mareimbrium.org> <201608251148.07977.marc.mutz@kdab.com> Message-ID: <015FBF4D-D17B-4F5D-8C00-8FC45ADE3B33@mareimbrium.org> > On Aug 25, 2016, at 5:48 AM, Marc Mutz wrote: > > On Wednesday 24 August 2016 20:05:56 Kuba Ober wrote: >> `QObject` is already pretty much a handle to the underlying data due to >> pimpl. So that’s a good first step. > > I challenge the notion that QObject is a handle to date. > > QObject is first and foremost the base class of a polymorphic class hierarchy. > > If you wrap that in a parallel value-like-but-not-quite class hierarchy, you > end up with QDomNode. I don't like QDomNode. Do you like QDomNode? > > That said, the Copperspice guys argue that the implicit memory management of > QObject parent-child relationships is becoming alien for C++ developers. The > Qt community can of course deny every claim that comes from that direction, > but sometimes the look of an outsider is valuable, too. After all, the API > quality matters most for newbies, not decade-long Qt users. > > So IMO, it's certainly worth asking the question whether we should change > something there, e.g. by using shared_ptr/weak_ptr to manage lifetimes. > > That would cover your use-case: > > std::vector> > > is all you were asking for. This is fine and dandy except we’re holding shared pointers to pointers to data. That seems a bit wasteful when we know that internally it’s just Qt’s unique_ptr (QScopedPointer). I think that people would understand the fallout from QObject being movable if it was clearly documented, e.g. that if you hold any pointers to it, and then move it, the pointers aren’t valid. A QPointer that tracks the moves in principle is what anyone could use to track an object that has been moved, but it’d break its api a bit: after every move, the QPointer would return a different address. A QObject::Handle would be a cheaper version of a QPointer: it wouldn’t track destruction, but otherwise would work the same. Perhaps we could name it better? A movable QObject could be at the beginning just an implementation detail, and perhaps Qt shouldn't be moving any objects that are visible to the user. But internally it would track the moves all across the hierarchy. I’d need to see what the fallout of that would be, otherwise this will all be idle talk. I’ll see what an implementation would look like. Kuba From alexander.blasche at qt.io Thu Aug 25 16:15:35 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Thu, 25 Aug 2016 14:15:35 +0000 Subject: [Development] Nominating Johan Helsing for Approver status In-Reply-To: References: , Message-ID: Congratulations. The permission changes have been enacted. -- Alex ________________________________________ From: Development on behalf of Giulio Camuffo Sent: Monday, 8 August 2016 9:14:55 AM To: Erik Larsson Cc: Qt development mailing list Subject: Re: [Development] Nominating Johan Helsing for Approver status +1 2016-08-06 8:31 GMT+02:00 Erik Larsson : > +1 > > 2016-08-04 12:22 GMT+02:00 Paul Tvete : >> >> Hi all, >> >> >> I'd like to nominate Johan Helsing for Approver status. He joined The Qt >> Company half a year ago, and has been working full time on Qt since. Johan >> has been actively involved in making the QtWaylandCompositor module ready >> for Qt 5.8, as well as doing a major part of the bug fixes for Qt Wayland in >> 5.6 and 5.7. >> >> Here is his gerrit dashboard: >> >> https://codereview.qt-project.org/#/q/owner:%22Johan+Helsing%22,n,z >> >> Johan's list of reviews can be found at: >> >> >> https://codereview.qt-project.org/#/q/reviewer:%22Johan+Helsing+%253Cjohan.helsing%2540theqtcompany.com%253E%22,p,003e6e7d0002807d >> >> Cheers, >> >> - Paul >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From alexander.blasche at qt.io Fri Aug 26 10:17:12 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Fri, 26 Aug 2016 08:17:12 +0000 Subject: [Development] Nominating Paolo Angelelli for Approver status Message-ID: Hi, I'd like to nominate Paolo Angelelli for Approver status. He joined The Qt Company at the end of 2015, and has been working full time on Qt since. Paolo has been actively involved fixing and improving QtPositioning and QtLocation. -- Alex From eskil.abrahamsen-blomfeldt at qt.io Fri Aug 26 11:31:07 2016 From: eskil.abrahamsen-blomfeldt at qt.io (Eskil Abrahamsen Blomfeldt) Date: Fri, 26 Aug 2016 11:31:07 +0200 Subject: [Development] Nominating Paolo Angelelli for Approver status In-Reply-To: References: Message-ID: Den 26.08.2016 10:17, skrev Alexander Blasche: > Hi, > > I'd like to nominate Paolo Angelelli for Approver status. He joined The Qt Company at the end of 2015, and has been working full time on Qt since. Paolo has been actively involved fixing and improving QtPositioning and QtLocation. +1 Paolo has been and is doing great work on Qt Location :) -- Eskil Abrahamsen Blomfeldt Senior Manager, R&D The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfeldt at qt.io http://qt.io From laszlo.agocs at qt.io Fri Aug 26 11:34:38 2016 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Fri, 26 Aug 2016 09:34:38 +0000 Subject: [Development] Nominating Paolo Angelelli for Approver status In-Reply-To: References: , Message-ID: +1. Besides fixes he's been doing quite some new features as well. Keep them coming. Cheers, Laszlo ________________________________ From: Development on behalf of Eskil Abrahamsen Blomfeldt Sent: Friday, August 26, 2016 11:31 AM To: development at qt-project.org Subject: Re: [Development] Nominating Paolo Angelelli for Approver status Den 26.08.2016 10:17, skrev Alexander Blasche: > Hi, > > I'd like to nominate Paolo Angelelli for Approver status. He joined The Qt Company at the end of 2015, and has been working full time on Qt since. Paolo has been actively involved fixing and improving QtPositioning and QtLocation. +1 Paolo has been and is doing great work on Qt Location :) -- Eskil Abrahamsen Blomfeldt Senior Manager, R&D The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfeldt at qt.io http://qt.io _______________________________________________ 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 eirik.aavitsland at qt.io Fri Aug 26 13:35:55 2016 From: eirik.aavitsland at qt.io (Eirik Aavitsland) Date: Fri, 26 Aug 2016 13:35:55 +0200 Subject: [Development] Nominating Paolo Angelelli for Approver status In-Reply-To: References: Message-ID: <378e5a0f-3a8a-3055-abd7-2bed905687c2@qt.io> +1 - Eirik Aa. On 26. aug. 2016 11:34, Laszlo Agocs wrote: > > +1. Besides fixes he's been doing quite some new features as well. Keep > them coming. > > > Cheers, > > Laszlo > > > > ------------------------------------------------------------------------ > *From:* Development > on behalf of > Eskil Abrahamsen Blomfeldt > *Sent:* Friday, August 26, 2016 11:31 AM > *To:* development at qt-project.org > *Subject:* Re: [Development] Nominating Paolo Angelelli for Approver status > > > > Den 26.08.2016 10:17, skrev Alexander Blasche: >> Hi, >> >> I'd like to nominate Paolo Angelelli for Approver status. He joined The Qt Company at the end of 2015, and has been working full time on Qt since. Paolo has been actively involved fixing and improving QtPositioning and QtLocation. > > +1 > > Paolo has been and is doing great work on Qt Location :) > > -- > Eskil Abrahamsen Blomfeldt > Senior Manager, R&D > > The Qt Company > Sandakerveien 116 > 0484 Oslo, Norway > eskil.abrahamsen-blomfeldt at qt.io > http://qt.io > > _______________________________________________ > 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 michal.klocek at qt.io Fri Aug 26 13:42:35 2016 From: michal.klocek at qt.io (Michal Klocek) Date: Fri, 26 Aug 2016 13:42:35 +0200 Subject: [Development] Nominating Paolo Angelelli for Approver status In-Reply-To: <378e5a0f-3a8a-3055-abd7-2bed905687c2@qt.io> References: <378e5a0f-3a8a-3055-abd7-2bed905687c2@qt.io> Message-ID: +1 On 08/26/2016 01:35 PM, Eirik Aavitsland wrote: > > +1 > > - Eirik Aa. > > On 26. aug. 2016 11:34, Laszlo Agocs wrote: >> >> +1. Besides fixes he's been doing quite some new features as well. Keep >> them coming. >> >> >> Cheers, >> >> Laszlo >> >> >> >> ------------------------------------------------------------------------ >> *From:* Development >> on behalf of >> Eskil Abrahamsen Blomfeldt >> *Sent:* Friday, August 26, 2016 11:31 AM >> *To:* development at qt-project.org >> *Subject:* Re: [Development] Nominating Paolo Angelelli for Approver >> status >> >> >> >> Den 26.08.2016 10:17, skrev Alexander Blasche: >>> Hi, >>> >>> I'd like to nominate Paolo Angelelli for Approver status. He joined >>> The Qt Company at the end of 2015, and has been working full time on >>> Qt since. Paolo has been actively involved fixing and improving >>> QtPositioning and QtLocation. >> >> +1 >> >> Paolo has been and is doing great work on Qt Location :) >> >> -- >> Eskil Abrahamsen Blomfeldt >> Senior Manager, R&D >> >> The Qt Company >> Sandakerveien 116 >> 0484 Oslo, Norway >> eskil.abrahamsen-blomfeldt at qt.io >> http://qt.io >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Fri Aug 26 13:53:35 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 26 Aug 2016 11:53:35 +0000 Subject: [Development] Nominating Paolo Angelelli for Approver status In-Reply-To: References: <378e5a0f-3a8a-3055-abd7-2bed905687c2@qt.io> Message-ID: And another +1 :) Cheers, Lars On 26/08/16 13:42, "Development on behalf of Michal Klocek" wrote: >+1 > >On 08/26/2016 01:35 PM, Eirik Aavitsland wrote: >> >> +1 >> >> - Eirik Aa. >> >> On 26. aug. 2016 11:34, Laszlo Agocs wrote: >>> >>> +1. Besides fixes he's been doing quite some new features as well. Keep >>> them coming. >>> >>> >>> Cheers, >>> >>> Laszlo >>> >>> >>> >>> ------------------------------------------------------------------------ >>> *From:* Development >>> on behalf of >>> Eskil Abrahamsen Blomfeldt >>> *Sent:* Friday, August 26, 2016 11:31 AM >>> *To:* development at qt-project.org >>> *Subject:* Re: [Development] Nominating Paolo Angelelli for Approver >>> status >>> >>> >>> >>> Den 26.08.2016 10:17, skrev Alexander Blasche: >>>> Hi, >>>> >>>> I'd like to nominate Paolo Angelelli for Approver status. He joined >>>> The Qt Company at the end of 2015, and has been working full time on >>>> Qt since. Paolo has been actively involved fixing and improving >>>> QtPositioning and QtLocation. >>> >>> +1 >>> >>> Paolo has been and is doing great work on Qt Location :) >>> >>> -- >>> Eskil Abrahamsen Blomfeldt >>> Senior Manager, R&D >>> >>> The Qt Company >>> Sandakerveien 116 >>> 0484 Oslo, Norway >>> eskil.abrahamsen-blomfeldt at qt.io >>> http://qt.io >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From Shawn.Rutledge at qt.io Fri Aug 26 17:08:42 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 26 Aug 2016 15:08:42 +0000 Subject: [Development] Nominating Paolo Angelelli for Approver status In-Reply-To: References: Message-ID: <92DB96C3-A7C9-4AC4-B21D-502EA494070F@qt.io> +1 > On 26 Aug 2016, at 10:17, Alexander Blasche wrote: > > Hi, > > I'd like to nominate Paolo Angelelli for Approver status. He joined The Qt Company at the end of 2015, and has been working full time on Qt since. Paolo has been actively involved fixing and improving QtPositioning and QtLocation. > > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kollix at aon.at Fri Aug 26 20:04:08 2016 From: kollix at aon.at (Martin Koller) Date: Fri, 26 Aug 2016 20:04:08 +0200 Subject: [Development] QDBusConnection - connect to "catch all" slot ? Message-ID: <3332234.DKjMUEVlSb@lapi.koller> Hi, In QDBusConnection there are several connect() methods which check the signature of the signal against the connected slot. Since I'd like to implement a scripting possibility around this, I'd need the possibility to either be able to receive all QDBusMessages (at least from DBus signals) or a way where the slot just gets all arguments via a single QList parameter (from QDBusMessage::arguments()). Is there currently a way to achieve this ? I found qDBusAddSpyHook - probably this is what I'm looking for ? Or what was the reason to have this function ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From thiago.macieira at intel.com Fri Aug 26 21:48:33 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 26 Aug 2016 12:48:33 -0700 Subject: [Development] QDBusConnection - connect to "catch all" slot ? In-Reply-To: <3332234.DKjMUEVlSb@lapi.koller> References: <3332234.DKjMUEVlSb@lapi.koller> Message-ID: <1844862.YOqULsNVRS@tjmaciei-mobl1> Em sexta-feira, 26 de agosto de 2016, às 20:04:08 PDT, Martin Koller escreveu: > Hi, > > In QDBusConnection there are several connect() methods which check the > signature of the signal against the connected slot. > Since I'd like to implement a scripting possibility around this, I'd need > the possibility to either be able to receive all QDBusMessages (at least > from DBus signals) or a way where the slot just gets all arguments via a > single QList parameter (from QDBusMessage::arguments()). > > Is there currently a way to achieve this ? Yes. Make your slot take one parameter only: QDBusMessage. > I found qDBusAddSpyHook - probably this is what I'm looking for ? > Or what was the reason to have this function ? Don't use that function. I expect that there is exactly one application using the spy hook and that's kded. I will not support anyone else using it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ansel at copperspice.com Fri Aug 26 23:10:23 2016 From: ansel at copperspice.com (Ansel Sermersheim) Date: Fri, 26 Aug 2016 14:10:23 -0700 Subject: [Development] Would it make sense to make QObject moveable in Qt 6? In-Reply-To: <201608251148.07977.marc.mutz@kdab.com> References: <65F325A6-F77D-4C21-A996-12D29E30CC50@mareimbrium.org> <201608251148.07977.marc.mutz@kdab.com> Message-ID: <57C0B03F.30302@copperspice.com> On 08/25/2016 02:48 AM, Marc Mutz wrote: > On Wednesday 24 August 2016 20:05:56 Kuba Ober wrote: >> `QObject` is already pretty much a handle to the underlying data due to >> pimpl. So that’s a good first step. > I challenge the notion that QObject is a handle to date. > > QObject is first and foremost the base class of a polymorphic class hierarchy. > > If you wrap that in a parallel value-like-but-not-quite class hierarchy, you > end up with QDomNode. I don't like QDomNode. Do you like QDomNode? > > That said, the Copperspice guys argue that the implicit memory management of > QObject parent-child relationships is becoming alien for C++ developers. The > Qt community can of course deny every claim that comes from that direction, > but sometimes the look of an outsider is valuable, too. After all, the API > quality matters most for newbies, not decade-long Qt users. I would like to confirm your observation about our direction for CopperSpice is accurate. It is our goal to modify QObject so users can leverage shared pointers to manage the lifetime of QObjects. One of the ways we moved this forward is by refactoring QObject. We developed a completely new standalone signal/slot library which is independent of CopperSpice and can be used in any C++ project. CopperSpice was then modified to use the new CsSignal library. During this refactoring we were able to improve the maintainability of QObject by separating some of the functionality. As an off topic comment I wanted to briefly mention why the key developers of CopperSpice scaled back work over the past two months. Barbara had a total knee replacement and she is recovering nicely, but physical therapy has been her main focus. I am looking forward to her full return to the office and continued work on CopperSpice and DoxyPress. Ansel Sermersheim CopperSpice Cofounder From olivier at woboq.com Sat Aug 27 09:30:21 2016 From: olivier at woboq.com (Olivier Goffart) Date: Sat, 27 Aug 2016 09:30:21 +0200 Subject: [Development] Should qMetaTypeId() == qMetaTypeId()? In-Reply-To: <6662597.K5zcpoVmBg@42> References: <201608241523.02049.marc.mutz@kdab.com> <6662597.K5zcpoVmBg@42> Message-ID: <1509992.Zth8dSsqr1@maurice> On Mittwoch, 24. August 2016 16:06:50 CEST Jędrzej Nowacki wrote: > On onsdag 24. august 2016 15.23.01 CEST Marc Mutz wrote: > > Hi, > > > > Currently, it's not, which doesn't make much sense, does it? > > > > So, > > > > template > > int qMetyTypeId() { > > return qMetaTypeIdHelper::type>(); > > } > > ? > > > > (There's of course a lot more involved in this, registration should > > discard const, too, e.g.). I think it make sens, but it should be done at the QMetaTypeId2 Level. We already do this for const T&, See commit 03b25125986f083a260b421abeed1f1d088d27b3 In fact, the same should be done for const T > From C++ perspective const T and T are kind of separate types, metatype > mimics that. QMetaType is used in many places and in some constness > matters. > > Consider that example: > QMetaType::typeName(qMetaTypeId()) > and > QMetaType::typeName(qMetaTypeId()) > The function is used in metaobject to compute signatures of invokables. I can prove you wrong easily, both have the same result, since QMetaType::normalizedType("const QString") == "QString" They are different C++ type, yes, but from a practical purpose, their use in the metatype system is exactly the same. You allocate, destroy or copy a const QString the same way you do a QString. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From timur.pocheptsov at qt.io Sat Aug 27 10:39:45 2016 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Sat, 27 Aug 2016 08:39:45 +0000 Subject: [Development] Nominating Paolo Angelelli for Approver status In-Reply-To: References: Message-ID: + 1 Best regards, Timur. ________________________________ From: Development on behalf of Alexander Blasche Sent: Friday, August 26, 2016 10:17:12 AM To: development at qt-project.org Subject: [Development] Nominating Paolo Angelelli for Approver status Hi, I'd like to nominate Paolo Angelelli for Approver status. He joined The Qt Company at the end of 2015, and has been working full time on Qt since. Paolo has been actively involved fixing and improving QtPositioning and QtLocation. -- Alex _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From torger at ludd.ltu.se Mon Aug 29 10:20:24 2016 From: torger at ludd.ltu.se (Anders Torger) Date: Mon, 29 Aug 2016 10:20:24 +0200 Subject: [Development] QT5 and color management Message-ID: <1472458824.9018.22@paganini> Hello, The color management capabilities of QT for displaying images is quite hard to figure out. I've searched the internet and you get very few hits often pointing to discussions several years old. So I think it's appropriate to start a new thread to get the latest. I'm new to QT, but I'm not new to color management and ICC profiles. I've worked a bit with GTK and RawTherapee project so I know how color management is handled there in Windows / Linux and OS X. What you typically do in a cross-platform scenario is that you figure out which ICC profile the display has in a platform-specific way (if you have multi-head you just have to choose one, haven't seen anyone handle a window which is displayed on two screens simultaneously), and then you use LittleCMS or other third-party library to convert your RGB data yourself to an output that matches the display, and then you just put that raw data to the screen using the GUI toolkit. In other words, the GUI toolkit doesn't do any color conversions, but just delivers the raw pixel values to the display. This is how you do it in GTK. With GTK there is as far as I know a problem on Mac OS X, where GTK is not low-level enough; Mac OS X APIs (Quartz?) will do the display conversion always so you can only output sRGB(?). I've not worked too much with OS X so I'm not 100% sure how it works there or if there is a work-around to get larger color space than sRGB. If anyone happens to know that too, I'm all ears. Now I'm working on a QT-based application, and it needs to be able to output high saturation colors to wide gamut displays with correct color management, on both Windows and Mac OS X (Linux is only a bonus in this project). So the question is simply how is this done with QT -- if possible at all. Anyone who knows? Maybe there's an open-source/example application out there that has already solved the problem which we could look at? We're using QT5.7 /Anders From boud at valdyas.org Mon Aug 29 10:52:48 2016 From: boud at valdyas.org (Boudewijn Rempt) Date: Mon, 29 Aug 2016 10:52:48 +0200 (CEST) Subject: [Development] QT5 and color management In-Reply-To: <1472458824.9018.22@paganini> References: <1472458824.9018.22@paganini> Message-ID: On Mon, 29 Aug 2016, Anders Torger wrote: > Now I'm working on a QT-based application, and it needs to be able to > output high saturation colors to wide gamut displays with correct color > management, on both Windows and Mac OS X (Linux is only a bonus in this > project). So the question is simply how is this done with QT -- if > possible at all. Sure it's possible. We accidentally broke it because we didn't have test hardware, but Krita's been able to do that. We use opengl directly, but Qt5 has a 10 bit/channel QImage format, so that might work too. > Anyone who knows? Maybe there's an open-source/example application out > there that has already solved the problem which we could look at? Well, krita's been a fully color managed Qt application since 2004. > > We're using QT5.7 > > /Anders > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org From marc.mutz at kdab.com Mon Aug 29 13:01:48 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 29 Aug 2016 13:01:48 +0200 Subject: [Development] dev and 5.8 CIs reliably fail on LinuxRHEL_6_6x86_64 Message-ID: <201608291301.48480.marc.mutz@kdab.com> Cf. attached posts. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- An embedded message was scrubbed... From: "Qt CI Bot (Code Review)" Subject: Change in qt/qtbase[dev]: uic: use a real ordered set Date: Mon, 29 Aug 2016 10:45:08 +0000 Size: 6265 URL: -------------- next part -------------- An embedded message was scrubbed... From: "Qt CI Bot (Code Review)" Subject: Change in qt/qtbase[5.8]: Replace QLatin1Literal with QLatin1String Date: Mon, 29 Aug 2016 10:39:06 +0000 Size: 6426 URL: From laszlo.agocs at qt.io Mon Aug 29 13:24:58 2016 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Mon, 29 Aug 2016 11:24:58 +0000 Subject: [Development] dev and 5.8 CIs reliably fail on LinuxRHEL_6_6x86_64 In-Reply-To: <201608291301.48480.marc.mutz@kdab.com> References: <201608291301.48480.marc.mutz@kdab.com> Message-ID: It looks like the failures in https://codereview.qt-project.org/#/c/159484/ (we cannot currently build the bundled libxkbcommon with xkb support on these machines). The xkb stuff should be skipped in this case, but that recently went broken due to some configure cleanups. https://codereview.qt-project.org/#/c/169063 may fix this. Laszlo ________________________________ From: Development on behalf of Marc Mutz Sent: Monday, August 29, 2016 1:01:48 PM To: development at qt-project.org Subject: [Development] dev and 5.8 CIs reliably fail on LinuxRHEL_6_6x86_64 Cf. attached posts. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: From torger at ludd.ltu.se Mon Aug 29 14:20:55 2016 From: torger at ludd.ltu.se (Anders Torger) Date: Mon, 29 Aug 2016 14:20:55 +0200 Subject: [Development] QT5 and color management In-Reply-To: (from boud@valdyas.org on Mon Aug 29 10:52:48 2016) Message-ID: <1472473255.9018.23@paganini> Thanks, I'll have a look in the code! With GTK the problem was solvable on Linux & Windows using native ways to get the system display profile, and the same seems applicable to QT. However a showstopper on GTK on Mac OS X was that the underlaying layer (Quartz) was configured to only accept sRGB, and it would convert using the system's display profile automatically, so you could only get sRGB colors out regardless if you have a wide gamut screen or not. Do you know if QImage puts raw pixels to the screen also on OS X (that is there's no Quartz color management layer involved making-it-all- become-sRGB), or must I use OpenGL? /Anders On 08/29/2016 10:52:48 AM, Boudewijn Rempt wrote: > On Mon, 29 Aug 2016, Anders Torger wrote: > > > Now I'm working on a QT-based application, and it needs to be able > to > > output high saturation colors to wide gamut displays with correct > color > > management, on both Windows and Mac OS X (Linux is only a bonus in > this > > project). So the question is simply how is this done with QT -- if > > possible at all. > > Sure it's possible. We accidentally broke it because we didn't have > test > hardware, but Krita's been able to do that. We use opengl directly, > but Qt5 has a 10 bit/channel QImage format, so that might work too. > > > Anyone who knows? Maybe there's an open-source/example application > out > > there that has already solved the problem which we could look at? > > Well, krita's been a fully color managed Qt application since 2004. > > > > > We're using QT5.7 > > > > /Anders > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > -- > Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org > From Simon.Hausmann at qt.io Mon Aug 29 14:23:32 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 29 Aug 2016 12:23:32 +0000 Subject: [Development] dev and 5.8 CIs reliably fail on LinuxRHEL_6_6x86_64 In-Reply-To: References: <201608291301.48480.marc.mutz@kdab.com>, Message-ID: I can confirm that Laszlo's fix works with regards to the build breakage on RHEL 6.6. Simon ________________________________ From: Development on behalf of Laszlo Agocs Sent: Monday, August 29, 2016 1:24:58 PM To: Marc Mutz; development at qt-project.org Subject: Re: [Development] dev and 5.8 CIs reliably fail on LinuxRHEL_6_6x86_64 It looks like the failures in https://codereview.qt-project.org/#/c/159484/ (we cannot currently build the bundled libxkbcommon with xkb support on these machines). The xkb stuff should be skipped in this case, but that recently went broken due to some configure cleanups. https://codereview.qt-project.org/#/c/169063 may fix this. Laszlo ________________________________ From: Development on behalf of Marc Mutz Sent: Monday, August 29, 2016 1:01:48 PM To: development at qt-project.org Subject: [Development] dev and 5.8 CIs reliably fail on LinuxRHEL_6_6x86_64 Cf. attached posts. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morten.Sorvig at qt.io Mon Aug 29 15:16:16 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Mon, 29 Aug 2016 13:16:16 +0000 Subject: [Development] QT5 and color management In-Reply-To: <1472458824.9018.22@paganini> References: <1472458824.9018.22@paganini> Message-ID: > On 29 Aug 2016, at 10:20, Anders Torger wrote: > > > Hello, > > The color management capabilities of QT for displaying images is quite > hard to figure out. I've searched the internet and you get very few > hits often pointing to discussions several years old. So I think it's > appropriate to start a new thread to get the latest. > > I'm new to QT, but I'm not new to color management and ICC profiles. > I've worked a bit with GTK and RawTherapee project so I know how color > management is handled there in Windows / Linux and OS X. > > What you typically do in a cross-platform scenario is that you figure > out which ICC profile the display has in a platform-specific way (if > you have multi-head you just have to choose one, haven't seen anyone > handle a window which is displayed on two screens simultaneously), and > then you use LittleCMS or other third-party library to convert your > RGB data yourself to an output that matches the display, and then you > just put that raw data to the screen using the GUI toolkit. In other > words, the GUI toolkit doesn't do any color conversions, but just > delivers the raw pixel values to the display. > > This is how you do it in GTK. With GTK there is as far as I know a > problem on Mac OS X, where GTK is not low-level enough; Mac OS X APIs > (Quartz?) will do the display conversion always so you can only output > sRGB(?). I've not worked too much with OS X so I'm not 100% sure how it > works there or if there is a work-around to get larger color space than > sRGB. If anyone happens to know that too, I'm all ears. We’ve researched a bit into the OS X side of this, see QTBUG-47660. Input from application developers is very welcome here - I’d like to make sure what we implement is actually usable in practice. If you don’t want to use OpenGL then we’re looking at supporting two modes: * The application outputs sRGB/linear sRGB to Qt. Qt will configure the native view accordingly, color conversion to the display color space is done by the OS. * The application gets the ICC profile for the display and outputs per- display correct colors to Qt. Qt configures the native view to use the display profile. There is no color space conversion outside application code. There is currently no API available to support this; the first iteration would probably be a a mac-spesifc API. Recently Apple introduced the "extended linear sRGB” color space (with support for component values below 0.0 and above 1.0), specifically for wide-gamut displays. I think we need floating-point support in QImage to make use of this format. Morten From torger at ludd.ltu.se Mon Aug 29 15:58:14 2016 From: torger at ludd.ltu.se (Anders Torger) Date: Mon, 29 Aug 2016 15:58:14 +0200 Subject: [Development] QT5 and color management In-Reply-To: (from Morten.Sorvig@qt.io on Mon Aug 29 15:16:16 2016) Message-ID: <1472479094.9018.24@paganini> On 08/29/2016 03:16:16 PM, Morten Sorvig wrote: > > > On 29 Aug 2016, at 10:20, Anders Torger wrote: > > > > > > Hello, > > > > The color management capabilities of QT for displaying images is > quite > > hard to figure out. I've searched the internet and you get very few > > > hits often pointing to discussions several years old. So I think > it's > > appropriate to start a new thread to get the latest. > > > > I'm new to QT, but I'm not new to color management and ICC > profiles. > > > I've worked a bit with GTK and RawTherapee project so I know how > color > > management is handled there in Windows / Linux and OS X. > > > > What you typically do in a cross-platform scenario is that you > figure > > out which ICC profile the display has in a platform-specific way > (if > > > you have multi-head you just have to choose one, haven't seen > anyone > > > handle a window which is displayed on two screens simultaneously), > and > > then you use LittleCMS or other third-party library to convert your > > > RGB data yourself to an output that matches the display, and then > you > > just put that raw data to the screen using the GUI toolkit. In > other > > > words, the GUI toolkit doesn't do any color conversions, but just > > delivers the raw pixel values to the display. > > > > This is how you do it in GTK. With GTK there is as far as I know a > > problem on Mac OS X, where GTK is not low-level enough; Mac OS X > APIs > > (Quartz?) will do the display conversion always so you can only > output > > sRGB(?). I've not worked too much with OS X so I'm not 100% sure > how > it > > works there or if there is a work-around to get larger color space > than > > sRGB. If anyone happens to know that too, I'm all ears. > > We’ve researched a bit into the OS X side of this, see QTBUG-47660. > Input > from application developers is very welcome here - I’d like to make > sure > what we implement is actually usable in practice. > > If you don’t want to use OpenGL then we’re looking at supporting two > modes: > > * The application outputs sRGB/linear sRGB to Qt. Qt will configure > the > native view accordingly, color conversion to the display color > space > > is done by the OS. > > * The application gets the ICC profile for the display and outputs > per- > display correct colors to Qt. Qt configures the native view to use > the > display profile. There is no color space conversion outside > application code. > > There is currently no API available to support this; the first > iteration > would probably be a a mac-spesifc API. > > Recently Apple introduced the "extended linear sRGB” color space > (with > support for component values below 0.0 and above 1.0), specifically > for > wide-gamut displays. I think we need floating-point support in QImage > to make use of this format. > > Morten > > Thanks. Looking at QTBUG-47660, if I understand it correctly it says that since QT 5.5 a QImage will output "native" pixels to the display. That is if I send 255,0,0 the display it will show the reddest red it can output. If that is correct, it will work for us, as we then can do "the usual way", that is find and load the display ICC profile using a native method, and use LittleCMS to convert from our internal format to the display's color space. That would be great, as it would work the same in Linux, Windows and OS X then. In the longer term I'm sure the typical application developer would love the mode when color space is locked to sRGB (or better if you can pick among a number of presets) and then QT makes sure proper conversion to the display takes place under the surface. That is the typical application developer never needs to care about color management, "it just works". However the typical application developer probably doesn't care at all if colors vary a bit as few applications require accurate colors. If color management is required it's a special case, and I think application developers can then accept the extra complexity by having to use LittleCMS or similar to do the conversion on their own. The most important thing is that you actually *can* do it in some way or another. As said with GTK it was not possible on OSX due to output colorspace being locked to sRGB rather than native display like on the other platforms. When writing cross-platform applications I see an advantage in "dumbing down" color management so it becomes equal between Linux/ Windows/OSX. In Linux and Windows we've used to having to do it manually in the application as the colors we send to the toolkit will be displayed with native display values. OSX has more advanced/ automatic color management, but if QT makes use of that it would mean that either it would work differently in Linux/Windows or one would have to make QT's color management a lot more advanced on those platforms to make it as automatic as on OSX. The largest drawback with the application-doing-it-on-its-own approach is that multi-head configurations can't really be made to work. The classic example if you have half of your application window on one screen and the other half on another, which have different ICC profiles. App-controlled color management usually means that you convert for the primary display, and only that. If QT itself would handle color management on a lower level I assume multi-head could work too. However I find this problem to be a minor one, as when you do work with a color managed application, it's about graphics, photos etc, and then you generally have one expensive calibrated monitor which is your primary display where you place the GUI. /Anders From thiago.macieira at intel.com Mon Aug 29 22:55:04 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 29 Aug 2016 13:55:04 -0700 Subject: [Development] MSVC 2015 option /utf8: Qt only or everyone? In-Reply-To: References: <1870465.YMDxbbm7c5@tjmaciei-mobl4> Message-ID: <2471081.O0N9omhsjY@tjmaciei-mobl1> Em quarta-feira, 11 de maio de 2016, às 07:59:38 PDT, Lars Knoll escreveu: > Finally! > > We should certainly turn it on for Qt. FYI, I dropped the feature that was required to turn on this switch now. We'll only be able to turn it on for the next version of the MS compiler, whenever that is released. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Morten.Sorvig at qt.io Tue Aug 30 11:16:26 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Tue, 30 Aug 2016 09:16:26 +0000 Subject: [Development] QT5 and color management In-Reply-To: <1472479094.9018.24@paganini> References: <1472479094.9018.24@paganini> Message-ID: <24303D16-D8D3-401F-B2A1-87B1E3FB3A9B@qt.io> > On 29 Aug 2016, at 15:58, Anders Torger wrote: > > > Thanks. Looking at QTBUG-47660, if I understand it correctly it says > that since QT 5.5 a QImage will output "native" pixels to the display. > That is if I send 255,0,0 the display it will show the reddest red > it can output. If that is correct, it will work for us, as we then can > do "the usual way", that is find and load the display ICC profile using > a native method, and use LittleCMS to convert from our internal format > to the display's color space. That would be great, as it would work the > same in Linux, Windows and OS X then. Unfortuantely I think that Qt currently uses the color space for the main screen only, so you may find it lacking for multi-monitor setups. > > In the longer term I'm sure the typical application developer would > love the mode when color space is locked to sRGB (or better if you can > pick among a number of presets) and then QT makes sure proper > conversion to the display takes place under the surface. That is the > typical application developer never needs to care about color > management, "it just works”. One remaining issue (after the platform plumbing has been done) may be that QPainter and the raster paint engine assumes a linear color space when blending. As I understand it OpenGL solves this by converting sRGB framebuffer values to linear color for the blending step. > > However the typical application developer probably doesn't care at all > if colors vary a bit as few applications require accurate colors. > > If color management is required it's a special case, and I think > application developers can then accept the extra complexity by having > to use LittleCMS or similar to do the conversion on their own. The most > important thing is that you actually *can* do it in some way or > another. As said with GTK it was not possible on OSX due to output > colorspace being locked to sRGB rather than native display like on the > other platforms. > > When writing cross-platform applications I see an advantage in > "dumbing down" color management so it becomes equal between Linux/ > Windows/OSX. In Linux and Windows we've used to having to do it > manually in the application as the colors we send to the toolkit will > be displayed with native display values. OSX has more advanced/ > automatic color management, but if QT makes use of that it would mean > that either it would work differently in Linux/Windows or one would > have to make QT's color management a lot more advanced on those > platforms to make it as automatic as on OSX. Agreed. > The largest drawback with the application-doing-it-on-its-own approach > is that multi-head configurations can't really be made to work. The > classic example if you have half of your application window on one > screen and the other half on another, which have different ICC > profiles. App-controlled color management usually means that you > convert for the primary display, and only that. If QT itself would > handle color management on a lower level I assume multi-head could work > too. However I find this problem to be a minor one, as when you do work > with a color managed application, it's about graphics, photos etc, and > then you generally have one expensive calibrated monitor which is your > primary display where you place the GUI. OS X works around this issue by having windows display on one screen only. I think we want to assume “one active color space per window” for now and don’t get into multi-colorspace rendering. I've drafted out a possible API below. Note that I’ve considered the raster pipeline (QPainter/QBackingStore) only. I don’t know if/how this applies to OpenGL. Morten /*! Sets the global application color space to \a colorSpace. The application can then produce color in the set color space; Qt will propagate the setting to the native views. Note that the raster paint engine (QPainter) requires a linear color space and may produce inaccurate colors if a gamma-corrected color space (like sRGB) is used. The default color space is CGColorSpaceCreateWithName(kCGColorSpaceSRGB). Creating the color space from an ICC profile is possible: QByteArray profile = ...; CFDataRef profileData = profile.toCFData(); GColorSpaceRef colorSpace = CGColorSpaceCreateWithICCProfile(profileData); CFRelease(profileData); */ id qt_mac_setApplicationColorSpace(GColorSpaceRef colorSpace); /*! Returns the current application colorspace, or a null ref if per-screen color spaces are enabled. */ GColorSpaceRef qt_mac_getApplicationColorSpace(); /*! Enables use of the native screen color space. Applications must produce color in the screen color space to get correct colors. Use qt_mac_getScreenColorSpace() to get the color space for for the current screen. */ void qt_mac_setPerScreenColorSpaces(bool enable); /*! */ bool qt_mac_isPerScreenColorSpacesEnabled(); /*! Returns the current color space for \a screen Call this function on the screen change event, and then redraw on the following repaint event. */ ColorSpaceRef qt_mac_getScreenColorSpace(QScreen *screen) From tor.arne.vestbo at qt.io Tue Aug 30 13:51:04 2016 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Tue, 30 Aug 2016 13:51:04 +0200 Subject: [Development] Proposing Mike Krus as tvOS maintainer Message-ID: <400d311c-6f67-c507-5189-00894fc5b897@qt.io> Hi all! Mike Krus was so kind to contribute support for Apple's tvOS to the UIKit platforms, and I'd like to make it official that he's the tvOS maintainer. I'll still be maintaining the overall UIKit platform, including iOS. Cheers, Tor Arne From tor.arne.vestbo at qt.io Tue Aug 30 13:52:45 2016 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Tue, 30 Aug 2016 13:52:45 +0200 Subject: [Development] Proposing Jake Petroules as watchOS maintainer Message-ID: <9e54823b-5d82-6dff-3e52-b24becc47e1c@qt.io> Hi all! Jake Petroules recently added support for Apple's watchOS to the UIKit platforms, and I'd like to make it official that he's the watchOS maintainer. I'll still be maintaining the overall UIKit platform, including iOS. Cheers, Tor Arne From Simon.Hausmann at qt.io Tue Aug 30 14:25:48 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 30 Aug 2016 12:25:48 +0000 Subject: [Development] dev and 5.8 CIs reliably fail on LinuxRHEL_6_6x86_64 In-Reply-To: References: <201608291301.48480.marc.mutz@kdab.com>, , Message-ID: So the current status here is that qtbase 5.8 is fixed and changes to any module in the 5.8 branch should be okay. We've had a merge from qtbase 5.8 to dev ready, but it's been postponed because it seems there's another bad change in qtbase 5.8 that breaks qttools and the concern is that this "breakage" would "leak" into dev. Therefore nothing works in the dev branch right now. I'd personally be in favor of still taking in the merge to unblock all modules other than qttools, but just my two cents. Simon ________________________________ From: Development on behalf of Simon Hausmann Sent: Monday, August 29, 2016 2:23:32 PM To: Laszlo Agocs; Marc Mutz; development at qt-project.org Subject: Re: [Development] dev and 5.8 CIs reliably fail on LinuxRHEL_6_6x86_64 I can confirm that Laszlo's fix works with regards to the build breakage on RHEL 6.6. Simon ________________________________ From: Development on behalf of Laszlo Agocs Sent: Monday, August 29, 2016 1:24:58 PM To: Marc Mutz; development at qt-project.org Subject: Re: [Development] dev and 5.8 CIs reliably fail on LinuxRHEL_6_6x86_64 It looks like the failures in https://codereview.qt-project.org/#/c/159484/ (we cannot currently build the bundled libxkbcommon with xkb support on these machines). The xkb stuff should be skipped in this case, but that recently went broken due to some configure cleanups. https://codereview.qt-project.org/#/c/169063 may fix this. Laszlo ________________________________ From: Development on behalf of Marc Mutz Sent: Monday, August 29, 2016 1:01:48 PM To: development at qt-project.org Subject: [Development] dev and 5.8 CIs reliably fail on LinuxRHEL_6_6x86_64 Cf. attached posts. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Tue Aug 30 14:32:36 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 30 Aug 2016 14:32:36 +0200 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601310038.42104.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601310038.42104.marc.mutz@kdab.com> Message-ID: <201608301432.37372.marc.mutz@kdab.com> On Sunday 31 January 2016 00:38:41 Marc Mutz wrote: > > I'd already be happy with those that were (are, actually) already there. > > I'd rather have 10-20 common algorithms with a convenient API than 80+ > > obscure ones that force me to use iterators (especially the boilerplate > > .begin() and .end() iterators that will be used in 99+% of the cases – > > copy&paste programming sucks). > > I don't like how you demand work from others, but don't want to do any work > on Qt yourself. > > I note that you have not, yet, submitted a change to remove those QList > uses that make use of stability-of-references. Please make sure you do. > It's sufficient to fix QToolBox (Page, iirc) and QDataWidgetMapper > (WidgetMapper). The more the merrier, though. Have I missed your patch? Is it in, yet? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From frederik.gladhorn at qt.io Tue Aug 30 14:40:23 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 30 Aug 2016 14:40:23 +0200 Subject: [Development] dev and 5.8 CIs reliably fail on LinuxRHEL_6_6x86_64 In-Reply-To: <201608291301.48480.marc.mutz@kdab.com> References: <201608291301.48480.marc.mutz@kdab.com> Message-ID: <294512871.eboOgaXGla@frederik-thinkcentre-m93p> Yes, we finally added Red Hat 7.2 to the CI, giving us hopefully somewhat fresher Linux packages (hello gstreamer-1 and gtk 3). While that seems to work nicely, we modified the RHEL 6 configuration, which was admittedly naive. Things are back on track, we keep running RHEL 6.2, but don't upgrade it to run developer-builds, but regular release builds, since that shows some additional test failures that need to be addressed first. I'm sorry about that, I was a bit too optimistic and overjoyed that we'd finally get better Linux packages released ;) We are slowly moving to a model where all of these changes will have to pass CI itself, but it'll take a bit of time still. Cheers, Frederik On mandag 29. august 2016 13.01.48 CEST Marc Mutz wrote: > Cf. attached posts. From marc.mutz at kdab.com Tue Aug 30 14:42:45 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 30 Aug 2016 14:42:45 +0200 Subject: [Development] Proposing Mike Krus as tvOS maintainer In-Reply-To: <400d311c-6f67-c507-5189-00894fc5b897@qt.io> References: <400d311c-6f67-c507-5189-00894fc5b897@qt.io> Message-ID: <201608301442.46179.marc.mutz@kdab.com> On Tuesday 30 August 2016 13:51:04 Tor Arne Vestbø wrote: > Hi all! > > Mike Krus was so kind to contribute support for Apple's tvOS to the > UIKit platforms, and I'd like to make it official that he's the tvOS > maintainer. > > I'll still be maintaining the overall UIKit platform, including iOS. +1 (disclaimer: he's my colleage at KDAB) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From sergio.martins at kdab.com Tue Aug 30 13:46:22 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Tue, 30 Aug 2016 13:46:22 +0200 Subject: [Development] Proposing Mike Krus as tvOS maintainer In-Reply-To: <400d311c-6f67-c507-5189-00894fc5b897@qt.io> References: <400d311c-6f67-c507-5189-00894fc5b897@qt.io> Message-ID: <2904402.yGK2ApAtWo@desktop-ga45d22> On Tuesday, August 30, 2016 01:51:04 PM Tor Arne Vestbø wrote: > Hi all! > > Mike Krus was so kind to contribute support for Apple's tvOS to the > UIKit platforms, and I'd like to make it official that he's the tvOS > maintainer. Can't vote for maintainership as I'm not a maintainer, but +1 for becoming an approver. He has very deep knowledge about this apple stuff that so few of us dare to enter. (disclaimer: he's my colleage at KDAB) Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior 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 Jake.Petroules at qt.io Tue Aug 30 15:03:32 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Tue, 30 Aug 2016 13:03:32 +0000 Subject: [Development] Proposing Mike Krus as tvOS maintainer In-Reply-To: <400d311c-6f67-c507-5189-00894fc5b897@qt.io> References: <400d311c-6f67-c507-5189-00894fc5b897@qt.io> Message-ID: <6B96F40D-4715-4A16-831E-15B7BF9CE783@qt.io> +1 On Aug 30, 2016, at 4:51 AM, Tor Arne Vestbø > wrote: Hi all! Mike Krus was so kind to contribute support for Apple's tvOS to the UIKit platforms, and I'd like to make it official that he's the tvOS maintainer. I'll still be maintaining the overall UIKit platform, including iOS. Cheers, Tor Arne _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.harmer at kdab.com Tue Aug 30 15:05:45 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Tue, 30 Aug 2016 14:05:45 +0100 Subject: [Development] Proposing Mike Krus as tvOS maintainer In-Reply-To: <400d311c-6f67-c507-5189-00894fc5b897@qt.io> References: <400d311c-6f67-c507-5189-00894fc5b897@qt.io> Message-ID: <8123625.CQvIts3HSV@cartman> On Tuesday 30 August 2016 13:51:04 Tor Arne Vestbø wrote: > Hi all! > > Mike Krus was so kind to contribute support for Apple's tvOS to the > UIKit platforms, and I'd like to make it official that he's the tvOS > maintainer. +1 Disclaimer: I'm a colleague of Mike's at KDAB 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 mike.krus at kdab.com Tue Aug 30 15:24:17 2016 From: mike.krus at kdab.com (Mike Krus) Date: Tue, 30 Aug 2016 14:24:17 +0100 Subject: [Development] Proposing Jake Petroules as watchOS maintainer In-Reply-To: <9e54823b-5d82-6dff-3e52-b24becc47e1c@qt.io> References: <9e54823b-5d82-6dff-3e52-b24becc47e1c@qt.io> Message-ID: <09E9FE4C-3A5D-4E1A-804B-A5E47B1FF4FA@kdab.com> +1 (disclaimer, co-nominee for matching tvOS position :) ) > On 30 Aug 2016, at 12:52, Tor Arne Vestbø wrote: > > Hi all! > > Jake Petroules recently added support for Apple's watchOS to the UIKit platforms, and I'd like to make it official that he's the watchOS maintainer. > > I'll still be maintaining the overall UIKit platform, including iOS. > > Cheers, > Tor Arne > _______________________________________________ > 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 From thiago.macieira at intel.com Tue Aug 30 16:33:18 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 30 Aug 2016 07:33:18 -0700 Subject: [Development] Proposing Jake Petroules as watchOS maintainer In-Reply-To: <9e54823b-5d82-6dff-3e52-b24becc47e1c@qt.io> References: <9e54823b-5d82-6dff-3e52-b24becc47e1c@qt.io> Message-ID: <2303673.cqGN6vbEpr@tjmaciei-mobl1> Em terça-feira, 30 de agosto de 2016, às 13:52:45 PDT, Tor Arne Vestbø escreveu: > Hi all! > > Jake Petroules recently added support for Apple's watchOS to the UIKit > platforms, and I'd like to make it official that he's the watchOS > maintainer. > > I'll still be maintaining the overall UIKit platform, including iOS. +1 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From louai.al-khanji at qt.io Tue Aug 30 16:34:18 2016 From: louai.al-khanji at qt.io (Louai Al-Khanji) Date: Tue, 30 Aug 2016 14:34:18 +0000 Subject: [Development] Proposing Jake Petroules as watchOS maintainer In-Reply-To: <09E9FE4C-3A5D-4E1A-804B-A5E47B1FF4FA@kdab.com> References: <9e54823b-5d82-6dff-3e52-b24becc47e1c@qt.io>, <09E9FE4C-3A5D-4E1A-804B-A5E47B1FF4FA@kdab.com> Message-ID: +1 _____________________________ From: Mike Krus > Sent: Tuesday, August 30, 2016 6:24 AM Subject: Re: [Development] Proposing Jake Petroules as watchOS maintainer To: Tor Arne Vestb? > Cc: > +1 (disclaimer, co-nominee for matching tvOS position :) ) > On 30 Aug 2016, at 12:52, Tor Arne Vestb? > wrote: > > Hi all! > > Jake Petroules recently added support for Apple's watchOS to the UIKit platforms, and I'd like to make it official that he's the watchOS maintainer. > > I'll still be maintaining the overall UIKit platform, including iOS. > > Cheers, > Tor Arne > _______________________________________________ > 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 _______________________________________________ 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 kde at carewolf.com Tue Aug 30 22:11:13 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Tue, 30 Aug 2016 22:11:13 +0200 Subject: [Development] QT5 and color management In-Reply-To: <24303D16-D8D3-401F-B2A1-87B1E3FB3A9B@qt.io> References: <1472479094.9018.24@paganini> <24303D16-D8D3-401F-B2A1-87B1E3FB3A9B@qt.io> Message-ID: <201608302211.13836.kde@carewolf.com> On Tuesday 30 August 2016, Morten Sorvig wrote: > One remaining issue (after the platform plumbing has been done) may be > that QPainter and the raster paint engine assumes a linear color space > when blending. As I understand it OpenGL solves this by converting > sRGB framebuffer values to linear color for the blending step. > I have looked into that previously. It is mainly blocked by uncertain scope, what color-spaces should be supported, and should they be tied to QImage, QScreen, QGuiApplicaiton, QColor or all of the above? I also postponed adding support for RGB64 QImage formats until I figured out how gamma-correction should be handled. If we have a specific scope I can adjust my proto-type and suggest an implementation. Also I ran into the problem that gamma-corrected 2D anti-aliasing subjectively looks bad/wrong, probably because naive blending is closer to human perception, though it is less physically accurate (most screens gamma-curves are designed to fit human perception of brightness). Which raises the question if gamma-corrected blending is even worth the effort outside of photo realistic looking 3D rendering. `Allan From milian.wolff at kdab.com Tue Aug 30 23:14:08 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Tue, 30 Aug 2016 23:14:08 +0200 Subject: [Development] Proposing Mike Krus as tvOS maintainer In-Reply-To: <201608301442.46179.marc.mutz@kdab.com> References: <400d311c-6f67-c507-5189-00894fc5b897@qt.io> <201608301442.46179.marc.mutz@kdab.com> Message-ID: <1637176.AAilOxFEZg@agathebauer> On Dienstag, 30. August 2016 14:42:45 CEST Marc Mutz wrote: > On Tuesday 30 August 2016 13:51:04 Tor Arne Vestbø wrote: > > Hi all! > > > > Mike Krus was so kind to contribute support for Apple's tvOS to the > > UIKit platforms, and I'd like to make it official that he's the tvOS > > maintainer. > > > > I'll still be maintaining the overall UIKit platform, including iOS. > > +1 > > (disclaimer: he's my colleage at KDAB) +1 to both of the above -- 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 torger at ludd.ltu.se Wed Aug 31 09:20:03 2016 From: torger at ludd.ltu.se (Anders Torger) Date: Wed, 31 Aug 2016 09:20:03 +0200 Subject: [Development] QT5 and color management In-Reply-To: <24303D16-D8D3-401F-B2A1-87B1E3FB3A9B@qt.io> (from Morten.Sorvig@qt.io on Tue Aug 30 11:16:26 2016) Message-ID: <1472628003.9018.25@paganini> On 08/30/2016 11:16:26 AM, Morten Sorvig wrote: > Unfortuantely I think that Qt currently uses the color space for the > main screen only, so you may find it lacking for multi-monitor > setups. If that's the case, it's good enough for our immediate needs. Then we just get the ICC profile for the main screen, and use LittleCMS to transform from our internal format to the proper colors for the display. I was worried that the output was locked to sRGB on OS X (like the situation with GTK) so you couldn't make full use of wide gamut screens which would be very limiting for our application. As most users with a color-managed setup have one primary screen which they do all color-critical work on it's not too bad to only be able to present correct colors on that. /Anders From marc.mutz at kdab.com Wed Aug 31 09:38:21 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 31 Aug 2016 09:38:21 +0200 Subject: [Development] On deprecated APIs Message-ID: <201608310938.22262.marc.mutz@kdab.com> Hi, My porting guide for Q_FOREACH -> C++11 ranged for has created the expected outcry from users. I think some of the FUD comes from the fact that deprecation in 5.x usually means that the API is gone in Qt 6.0. I'd therefore like to propose a new contract with our users: The Qt Project: - continues to deprecate API it wants gone - maintains deprecated Qt N.x API until Qt (N+1).0. - does *not* remove deprecated N.x API anymore come (N+1).0 - does also *not* maintain deprecated N.x API after the initial (N+1).0.0 release * (ie. N+1).y CI runs with API deprecated in N.x (or earlier) disabled * also means Qt does the work of making sure deprecated API is turned all-inline before a .0.0 release to maintain BC. In return, the Qt users: - stop insisting on -Wdeprecated-clean builds without investing time of their own into updating their sources - provide patches to maintain deprecated APIs we no longer maintain In return, the Qt Project: - pledges to take those patches in without hackling about "but it's deprecated..." This allows us to continue to mark API deprecated, so new users have guidance on what API to avoid, while giving peace of mind to users of exisiting API that their investment is protected, as long as they're willing to participate in maintenance. I believe this is fair and beneficial for both sides. I don't know how far this will carry us (technically and socially), but maybe we can just try it in the Qt 5 -> 6 transition? I won't be able to come to QtCon this year, either, but feel free to take the opportunity to discuss this there. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From Jedrzej.Nowacki at qt.io Wed Aug 31 10:00:53 2016 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Wed, 31 Aug 2016 08:00:53 +0000 Subject: [Development] Should qMetaTypeId() == qMetaTypeId()? In-Reply-To: <1509992.Zth8dSsqr1@maurice> References: <201608241523.02049.marc.mutz@kdab.com> <6662597.K5zcpoVmBg@42>,<1509992.Zth8dSsqr1@maurice> Message-ID: I love to be proven wrong, but this time I would not call it easy [?] Try this: struct F{}; Q_DECLARE_METATYPE(F*); Q_DECLARE_METATYPE(const F*); Q_DECLARE_METATYPE(F); // Q_DECLARE_METATYPE(const F); doesn't compile, that is a bug! class O : public QObject { Q_OBJECT signals: void foo1(const F*); void foo2(F*); }; int main(int argc, char **argv) { qDebug() << QMetaMethod::fromSignal(&O::foo1).methodSignature(); qDebug() << QMetaMethod::fromSignal(&O::foo2).methodSignature(); return 0; } ________________________________ From: Development on behalf of Olivier Goffart Sent: Saturday, August 27, 2016 9:30:21 AM To: development at qt-project.org Subject: Re: [Development] Should qMetaTypeId() == qMetaTypeId()? On Mittwoch, 24. August 2016 16:06:50 CEST J?drzej Nowacki wrote: > On onsdag 24. august 2016 15.23.01 CEST Marc Mutz wrote: > > Hi, > > > > Currently, it's not, which doesn't make much sense, does it? > > > > So, > > > > template > > int qMetyTypeId() { > > return qMetaTypeIdHelper::type>(); > > } > > ? > > > > (There's of course a lot more involved in this, registration should > > discard const, too, e.g.). I think it make sens, but it should be done at the QMetaTypeId2 Level. We already do this for const T&, See commit 03b25125986f083a260b421abeed1f1d088d27b3 In fact, the same should be done for const T > From C++ perspective const T and T are kind of separate types, metatype > mimics that. QMetaType is used in many places and in some constness > matters. > > Consider that example: > QMetaType::typeName(qMetaTypeId()) > and > QMetaType::typeName(qMetaTypeId()) > The function is used in metaobject to compute signatures of invokables. I can prove you wrong easily, both have the same result, since QMetaType::normalizedType("const QString") == "QString" They are different C++ type, yes, but from a practical purpose, their use in the metatype system is exactly the same. You allocate, destroy or copy a const QString the same way you do a QString. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Wed Aug 31 10:04:55 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Wed, 31 Aug 2016 10:04:55 +0200 Subject: [Development] On deprecated APIs In-Reply-To: <201608310938.22262.marc.mutz@kdab.com> References: <201608310938.22262.marc.mutz@kdab.com> Message-ID: Op 31/08/2016 om 09:38 schreef Marc Mutz: > Hi, > > My porting guide for Q_FOREACH -> C++11 ranged for has created the expected > outcry from users. > > I think some of the FUD comes from the fact that deprecation in 5.x usually > means that the API is gone in Qt 6.0. > > I'd therefore like to propose a new contract with our users: > > The Qt Project: > - continues to deprecate API it wants gone > - maintains deprecated Qt N.x API until Qt (N+1).0. > - does *not* remove deprecated N.x API anymore come (N+1).0 > - does also *not* maintain deprecated N.x API after the initial (N+1).0.0 > release > * (ie. N+1).y CI runs with API deprecated in N.x (or earlier) disabled > * also means Qt does the work of making sure deprecated API is turned > all-inline before a .0.0 release to maintain BC. > > In return, the Qt users: > - stop insisting on -Wdeprecated-clean builds without investing time of their > own into updating their sources > - provide patches to maintain deprecated APIs we no longer maintain > > In return, the Qt Project: > - pledges to take those patches in without hackling about "but it's > deprecated..." > > This allows us to continue to mark API deprecated, so new users have guidance > on what API to avoid, while giving peace of mind to users of exisiting API > that their investment is protected, as long as they're willing to participate > in maintenance. > > I believe this is fair and beneficial for both sides. I don't know how far > this will carry us (technically and socially), but maybe we can just try it in > the Qt 5 -> 6 transition? > > I won't be able to come to QtCon this year, either, but feel free to take the > opportunity to discuss this there. > > Thanks, > Marc > Hi, While I understand the idea, I think it is very risky. I think it will be hard to explain to users, and even harder to defend against complaints and negative sentiments from users when the functionality _does_ break. Not maintaining something any more will mean that probably at one point, it will break. Do we really want to ship Qt in a way that we know will break, and will accumulate more breaks as time goes by? How do you deal with features that not too many (capable) people care about, do you just let them rot? I think asking the community to keep supporting certain features the project at large wants to deprecate without any support is not a fair deal for anyone. Would the people able to support such features into the future in fact already be likely contributing to the Qt project? Supporting a feature without the aid of CI is also quite a bit harder for any individual maintainer. In the case of Q_FOREACH: how would you maintain this without access to all the supported platforms and compilers? On the other hand: how do you as a user know which depreciated features are and which are not supported by the community? Doesn't that make Qt as a whole less reliable? I would like to make a slightly different suggestion: let a deprecation be a reversible state. It could signify that the Qt project is no longer willing to maintain it, and it thus will go away, _unless_ somebody stands up to accept maintainership of said feature/class/whatever and promisses to keep it working before the removal takes place. It would then *not* be removed from CI, but it could be marked as "community supported" or something like that to signify it's continued support is not as certain as other parts of Qt. Also, Qt internally would not be allowed to depend on such community supported code any more. If nobody stands up to take maintainership, it will indeed be removed at the appropriate time. BTW: A quick search on the ML archive did not turn up a discussion on the removal of Q_FOREACH. Would that not be required before marking it deprecated? I did find more of an announcement[1]. I also found a post[2] by you where you say: > Try to port all your Q_FOREACH to range-for loops. You will be surprised how > much digging is required if you don't always want to take the hit of taking a > copy. Isn't that essentially the contents user outcry you are refering to? André [1] http://lists.qt-project.org/pipermail/development/2016-May/025843.html [2] http://lists.qt-project.org/pipermail/development/2015-December/024187.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Wed Aug 31 10:46:42 2016 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 31 Aug 2016 10:46:42 +0200 Subject: [Development] Should qMetaTypeId() == qMetaTypeId()? In-Reply-To: References: <201608241523.02049.marc.mutz@kdab.com> <1509992.Zth8dSsqr1@maurice> Message-ID: <1808417.iH1gp4nKsV@maurice> On Mittwoch, 31. August 2016 08:00:53 CEST Jedrzej Nowacki wrote: > I love to be proven wrong, but this time I would not call it easy [?] Try > this: We were talking about "T" vs. "const T"; not "T *" vs "const T *". So in your example you should compare "F *" and "F * const" The question whether F* and const F* should have the same metatype is another question worth asking. Since their normalized type does not compare the same anyway, i guess it's ok if they are different. > > > struct F{}; > Q_DECLARE_METATYPE(F*); > Q_DECLARE_METATYPE(const F*); > Q_DECLARE_METATYPE(F); > // Q_DECLARE_METATYPE(const F); doesn't compile, that is a bug! > > class O : public QObject > { > Q_OBJECT > signals: > void foo1(const F*); > void foo2(F*); > }; > > int main(int argc, char **argv) { > qDebug() << QMetaMethod::fromSignal(&O::foo1).methodSignature(); > qDebug() << QMetaMethod::fromSignal(&O::foo2).methodSignature(); > return 0; > } > > > > ________________________________ > From: Development > on behalf of Olivier Goffart Sent: Saturday, August 27, > 2016 9:30:21 AM > To: development at qt-project.org > Subject: Re: [Development] Should qMetaTypeId() == > qMetaTypeId()? > On Mittwoch, 24. August 2016 16:06:50 CEST J?drzej Nowacki wrote: > > On onsdag 24. august 2016 15.23.01 CEST Marc Mutz wrote: > > > Hi, > > > > > > Currently, it's not, which doesn't make much sense, does it? > > > > > > So, > > > > > > template > > > int qMetyTypeId() { > > > > > > return qMetaTypeIdHelper::type>(); > > > > > > } > > > > > > ? > > > > > > (There's of course a lot more involved in this, registration should > > > discard const, too, e.g.). > > I think it make sens, but it should be done at the QMetaTypeId2 Level. > We already do this for const T&, See commit > 03b25125986f083a260b421abeed1f1d088d27b3 > In fact, the same should be done for const T > > > From C++ perspective const T and T are kind of separate types, metatype > > mimics that. QMetaType is used in many places and in some constness > > matters. > > > > Consider that example: > > QMetaType::typeName(qMetaTypeId()) > > > > and > > > > QMetaType::typeName(qMetaTypeId()) > > > > The function is used in metaobject to compute signatures of invokables. > > I can prove you wrong easily, both have the same result, since > QMetaType::normalizedType("const QString") == "QString" > > They are different C++ type, yes, but from a practical purpose, their use > in the metatype system is exactly the same. You allocate, destroy or copy > a const QString the same way you do a QString. > > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From philwave at gmail.com Wed Aug 31 10:50:41 2016 From: philwave at gmail.com (Philippe) Date: Wed, 31 Aug 2016 10:50:41 +0200 Subject: [Development] On deprecated APIs In-Reply-To: <201608310938.22262.marc.mutz@kdab.com> References: <201608310938.22262.marc.mutz@kdab.com> Message-ID: <20160831105040.7A5B.6F0322A@gmail.com> This is a debate convenience vs performance; * Q_FOREACH will never detach, hence it is convenient. * A for-loop can be (a very little more) optimized, as long as you work on const containers or use qAsCont (and many will forget about that... which is *not* convenient) Philippe On Wed, 31 Aug 2016 09:38:21 +0200 Marc Mutz wrote: > Hi, > > My porting guide for Q_FOREACH -> C++11 ranged for has created the expected > outcry from users. > > I think some of the FUD comes from the fact that deprecation in 5.x usually > means that the API is gone in Qt 6.0. > > I'd therefore like to propose a new contract with our users: > > The Qt Project: > - continues to deprecate API it wants gone > - maintains deprecated Qt N.x API until Qt (N+1).0. > - does *not* remove deprecated N.x API anymore come (N+1).0 > - does also *not* maintain deprecated N.x API after the initial (N+1).0.0 > release > * (ie. N+1).y CI runs with API deprecated in N.x (or earlier) disabled > * also means Qt does the work of making sure deprecated API is turned > all-inline before a .0.0 release to maintain BC. > > In return, the Qt users: > - stop insisting on -Wdeprecated-clean builds without investing time of their > own into updating their sources > - provide patches to maintain deprecated APIs we no longer maintain > > In return, the Qt Project: > - pledges to take those patches in without hackling about "but it's > deprecated..." > > This allows us to continue to mark API deprecated, so new users have guidance > on what API to avoid, while giving peace of mind to users of exisiting API > that their investment is protected, as long as they're willing to participate > in maintenance. > > I believe this is fair and beneficial for both sides. I don't know how far > this will carry us (technically and socially), but maybe we can just try it in > the Qt 5 -> 6 transition? > > I won't be able to come to QtCon this year, either, but feel free to take the > opportunity to discuss this there. > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Wed Aug 31 11:14:41 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 31 Aug 2016 11:14:41 +0200 Subject: [Development] On deprecated APIs In-Reply-To: References: <201608310938.22262.marc.mutz@kdab.com> Message-ID: <201608311114.42449.marc.mutz@kdab.com> Hi Andre, On Wednesday 31 August 2016 10:04:55 André Somers wrote: > While I understand the idea, I think it is very risky. I think it will > be hard to explain to users, and even harder to defend against > complaints and negative sentiments from users when the functionality > _does_ break. Not maintaining something any more will mean that probably > at one point, it will break. Do we really want to ship Qt in a way that > we know will break, and will accumulate more breaks as time goes by? How > do you deal with features that not too many (capable) people care about, > do you just let them rot? We've been doing this for a while now. QtWebkit, say, or Qt3Support in Qt 4. > I think asking the community to keep supporting certain features the > project at large wants to deprecate without any support is not a fair > deal for anyone. Would the people able to support such features into the > future in fact already be likely contributing to the Qt project? If they can't do it themselves, they can pay someone to do the contributing. Most people can't contribute to the Linux kernel, but most people can pay for it. > Supporting a feature without the aid of CI is also quite a bit harder > for any individual maintainer. In the case of Q_FOREACH: how would you > maintain this without access to all the supported platforms and > compilers? On the other hand: how do you as a user know which > depreciated features are and which are not supported by the community? > Doesn't that make Qt as a whole less reliable? No. If that was the case, Boost couldn't exist. Boost does not have a central CI, and lives by users providing patches. True, they have a test infrastructure that anyone can run locally and upload the result to the Boost web page. Maybe that would be a good idea for Qt, too? > I would like to make a slightly different suggestion: let a deprecation > be a reversible state. The point is that deprecated API is API we consider a *mistake*. We don't _want_ users to use this API, but we don't remove it (right away) out of respect for existing users. If deprecation was reversible, it would mean we think it's ok for this API to be used again. No, we don't think so. We think that new code should use neither Q_FOREACH, nor QList. New code should use C++11 ranged-for, or QVector/std::vector. So, no, deprecation cannot be a reversible state. > It could signify that the Qt project is no longer > willing to maintain it, and it thus will go away, _unless_ somebody > stands up to accept maintainership of said feature/class/whatever and > promisses to keep it working before the removal takes place. It would > then *not* be removed from CI, but it could be marked as "community > supported" or something like that to signify it's continued support is > not as certain as other parts of Qt. Also, Qt internally would not be > allowed to depend on such community supported code any more. If nobody > stands up to take maintainership, it will indeed be removed at the > appropriate time. And what do we do if the CI breaks due to running such community-supported code, and we can't get our stuff integrated anymore? How long do we wait for "the community" to fix it? Ain't it more likely that TQtC, woboq or KDAB will provide a fix to unblock the CI before "the community" even noticed there's a problem? No, if it runs in the official Qt CI, it will effectively be maintained by the Qt project. So no, it cannot run in the official CI. > BTW: A quick search on the ML archive did not turn up a discussion on > the removal of Q_FOREACH. Would that not be required before marking it > deprecated? I did find more of an announcement[1]. I also found a I don't think there's a requirement to discuss deprecating features on the ML. As long as the module maintainer is in the loop, and doesn't request an ML discussion, I don't see why we need to spam the ML with such stuff. Sure, the usual nay-sayers who are against any form of change will call this U-Boot tactics and demand a bikeshedding on the ML, but Qt is a meritocracy, not a democracy. > post[2] by you where you say: > > Try to port all your Q_FOREACH to range-for loops. You will be surprised > > how much digging is required if you don't always want to take the hit of > > taking a copy. > > Isn't that essentially the contents user outcry you are refering to? No, it's just testament to why Q_FOREACH is bad API. It's important to understand (and note in a code comment) if the container you're iterating over is modified further down in the call stack, because that severely restricts what can be done to the loop in the future. As I said in the blog post: Q_FOREACH is convenient for the writer of the code. *You* don't need to care about understanding the code you write. And since *you* don't understand the code, you don't write the necessary comment. That's an extremly egocentric approach, because it leaves the infamous maintenance programmer with the task of having to understand the code *you* refused to understand when writing. (with *you* I don't mean you personally, Andre :) > [1] http://lists.qt-project.org/pipermail/development/2016-May/025843.html Q_FOREACH use was never allowed in Qt library code, and this mail is about the removal from Qt libraries, not about deprecating it for users. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From ulf.hermann at qt.io Wed Aug 31 11:27:20 2016 From: ulf.hermann at qt.io (Ulf Hermann) Date: Wed, 31 Aug 2016 11:27:20 +0200 Subject: [Development] On deprecated APIs In-Reply-To: <20160831105040.7A5B.6F0322A@gmail.com> References: <201608310938.22262.marc.mutz@kdab.com> <20160831105040.7A5B.6F0322A@gmail.com> Message-ID: <858e42dd-21d6-9c70-139d-5f4eabe565f0@qt.io> > This is a debate convenience vs performance; > > * Q_FOREACH will never detach, hence it is convenient. > * A for-loop can be (a very little more) optimized, as long as you work > on const containers or use qAsCont (and many will forget about that... which > is *not* convenient) ... especially as there is no qAsConst() for containers returned from functions. Those have to be saved in a local variable first, which makes the code not only less convenient but also uglier. I understand that we should teach people to avoid premature pessimzation, but at some point the pessimization might not actually be premature anymore. Q_FOREACH always makes a copy. This means you cannot mess up the logic if you change the code to modify the container in the loop body. You might actively decide to take a small performance hit for the convenience of not having to take care of this every time you change a loop body. The rules on when a Q_FOREACH detaches an implicitly shared container are also comparably simple. If you take a non-const reference as "iterator", then it detaches. If the reference is const or if you iterate by value, it won't detach. The rules in the "ranged for" case are more complicated and the user might actively trade a small performance hit for the ability to see the detaching behavior on first glance. Those are valid tradeoffs to be considered by the users and we should not impose either solution on them. So, I think there is still a place for Q_FOREACH in user code and we should not deprecate it in the first place. I agree that it's a good idea not to use it in Qt code. regards, Ulf From niels_ole at salscheider-online.de Wed Aug 31 11:45:37 2016 From: niels_ole at salscheider-online.de (Niels Ole Salscheider) Date: Wed, 31 Aug 2016 11:45:37 +0200 Subject: [Development] QT5 and color management In-Reply-To: <201608302211.13836.kde@carewolf.com> References: <1472479094.9018.24@paganini> <24303D16-D8D3-401F-B2A1-87B1E3FB3A9B@qt.io> <201608302211.13836.kde@carewolf.com> Message-ID: <2514470.R8t6qhQT4r@oledesktop> > I have looked into that previously. It is mainly blocked by uncertain scope, > what color-spaces should be supported, and should they be tied to QImage, > QScreen, QGuiApplicaiton, QColor or all of the above? I also postponed > adding support for RGB64 QImage formats until I figured out how > gamma-correction should be handled. > > If we have a specific scope I can adjust my proto-type and suggest an > implementation. I started a discussion about colorspaces for qt5 back in 2011: http://lists.qt-project.org/pipermail/qt5-feedback/2011-September/001298.html One of the comments was that it would be good to see how color management could be done e.g. on wayland before deciding on how to implement it in Qt. Therefore, I proposed a wayland protocol for color management and a weston implementation of it: https://lists.freedesktop.org/archives/wayland-devel/2014-October/017759.html In the end, it was considered to be out of scope for weston at that time but I think that the protocol is still sane. Having the implementation in weston does not really help as long as there is no toolkit that supports it. But I think that we could get the implementation into libweston nowadays if there was a toolkit that wants to use the protocol. The most efficient way to use this protocol would be to ask the compositor for its blending space, render the window in this blending space (after converting all images to it) and then pass it to the compositor. If someone wants to work on this for Qt, I would try to pick up the wayland side again. Ole From jani.heikkinen at qt.io Wed Aug 31 12:05:29 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 31 Aug 2016 10:05:29 +0000 Subject: [Development] HEADS-UP: Branching from '5.6' to '5.6.2' completed Message-ID: Hi, Final downmerge from '5.6' to '5.6.2' is now done and '5.6' is for Qt 5.6.3 from now on. All changes targeted to Qt 5.6.2 must be done in '5.6.2'. Please note that we are now working in release branch and so no any nice-to-haves in '5.6.2' anymore. I and whole release team will monitor approved changes in '5.6.2' and stage the ones which are clearly critical enough for the Qt 5.6.2 release. If you have some changes in '5.6' and which has to be in Qt 5.6.2 release please sent re-targeting request to Ossi. br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From janne.anttila at qt.io Wed Aug 31 13:11:51 2016 From: janne.anttila at qt.io (Janne Anttila) Date: Wed, 31 Aug 2016 11:11:51 +0000 Subject: [Development] Maintenance break in list.qt-project.org & testresults@qt.io services Message-ID: Hi, We need to perform maintenance operations on list.qt-project.org & testresults at qt.io services with very tight schedule. The maintenance break will start 13:30 CET today and should last max 30 minutes. IP address of services will change during maintenance break. Sorry for inconvenience! Br -- Janne -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Aug 31 15:41:18 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 31 Aug 2016 15:41:18 +0200 Subject: [Development] Overly large Gerrit fetch in QtBase...?! Message-ID: <201608311541.18674.marc.mutz@kdab.com> Hi, Today's git fetch gerrit pulled in 70MiB of new data: $ git fetch gerrit remote: Counting objects: 50860, done remote: Finding sources: 100% (41981/41981) remote: Total 41981 (delta 21723), reused 29355 (delta 21723) Receiving objects: 100% (41981/41981), 70.13 MiB | 362 KiB/s, done. Resolving deltas: 100% (21723/21723), completed with 754 local objects. From codereview.qt-project.org:qt/qtbase e52fcb7..531a2b1 5.6 -> gerrit/5.6 47aad8f..8d8c7b3 5.6.2 -> gerrit/5.6.2 6cbd982..fa2aef5 5.7 -> gerrit/5.7 829c59a..84830fc 5.8 -> gerrit/5.8 b012f55..f510a51 dev -> gerrit/dev that's extreme, compared to the size of the .git, here from a repo copy I didn't fetch, yet: $ du -sch .git 212M .git 212M total Is there an explanation? It could indicate a manipulation of the git history, even though I didn't see anything funny on a cursory look through the commit ranges git fetch presented... Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From oswald.buddenhagen at qt.io Wed Aug 31 16:12:55 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 31 Aug 2016 16:12:55 +0200 Subject: [Development] [FYI] on gerrit change retargeting requests Message-ID: <20160831141255.GG2429@troll08> with the upcoming qtcon and my subsequent vacation, my availability will be rather sporadic, so consider this: - i'm not going to do reviews on a regular basis, so it's unwise to just add me to them and expect a reaction. send me a direct mail. - this recommendation actually applies irrespective of current plans - sometimes i actually want to get some work done instead of just doing reviews. ;) - you can also ask frederik gladhorn (fregl) generally speaking, send a complete list of change urls, as we can just paste that into the script which performs the operation. that's also the reason why a single mail (or irc messsage) instead of adding us to n reviews is always preferred. please don't give verbal descriptions of ranges - somebody has to do the click and paste orgy anyway, and that should be you. ;) From apoenitz at t-online.de Wed Aug 31 21:04:27 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Wed, 31 Aug 2016 21:04:27 +0200 Subject: [Development] On deprecated APIs In-Reply-To: <201608310938.22262.marc.mutz@kdab.com> References: <201608310938.22262.marc.mutz@kdab.com> Message-ID: <20160831190427.GA5342@klara.mpi.htwm.de> On Wed, Aug 31, 2016 at 09:38:21AM +0200, Marc Mutz wrote: > My porting guide for Q_FOREACH -> C++11 ranged for has created the expected > outcry from users. Expectedly so. And since you seem to be surprised: There are a few people that have just given up on commenting each and every mailing list topic, so silence does not imply affirmation. The main problem here is, again, that more or less independent issues are mangled into one: 1. The intent to not use certain functionality in Qt *internally* anymore. 2. The attempt to enforce those ideas on users. They are not completely independent, but a 'Q_FOREACH' ban in Qt proper does not have to imply its removal for users. If it is not useful in your view, you can mention it in the docs. Breaking formerly compilable code for no good reason is not a good base for a 'contract'. [Same for other 'helpful' deprecation activities or enforced development restrictions] Andre' From marc.mutz at kdab.com Wed Aug 31 21:38:03 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 31 Aug 2016 21:38:03 +0200 Subject: [Development] On deprecated APIs In-Reply-To: <20160831190427.GA5342@klara.mpi.htwm.de> References: <201608310938.22262.marc.mutz@kdab.com> <20160831190427.GA5342@klara.mpi.htwm.de> Message-ID: <201608312138.04076.marc.mutz@kdab.com> Hi André, On Wednesday 31 August 2016 21:04:27 André Pönitz wrote: > They are not completely independent, but a 'Q_FOREACH' ban in Qt > proper does not have to imply its removal for users. If it is > not useful in your view, you can mention it in the docs. Breaking > formerly compilable code for no good reason is not a good base > for a 'contract'. All the text in my email (which you cut away) is about how _not_ to break formerly compilable code, for *any* reason. What I actually don't understand is why people are so keen on enabling - Wdeprecated and at the same time don't want to move a finger about it. Why enable it if it just annoys you? Why not just *not enable* the warning? The fear, I guessed, is that if you don't enable it, you will get caught with your pants down when your start compiling against Qt 6. So this proposal is for a way to lift that fear, so people who don't want to don't feel that they need to enable -Wdeprecated, turning it into its former meaning: API we have deprecated, not removed. So, do you have any opinion on the actual proposal? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Wed Aug 31 21:41:15 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 31 Aug 2016 21:41:15 +0200 Subject: [Development] On deprecated APIs In-Reply-To: <201608312138.04076.marc.mutz@kdab.com> References: <201608310938.22262.marc.mutz@kdab.com> <20160831190427.GA5342@klara.mpi.htwm.de> <201608312138.04076.marc.mutz@kdab.com> Message-ID: <201608312141.15929.marc.mutz@kdab.com> On Wednesday 31 August 2016 21:38:03 Marc Mutz wrote: > So this proposal is for a way to lift that fear, so people who don't want > to don't feel that they need to enable -Wdeprecated, turning it into its > former meaning: API we have deprecated, not removed. From OALD: deprecate something (formal) to feel and express strong disapproval of something Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts