[Development] Stepping down as Windows Embedded Compact port maintainer
Hi everybody, since I am changing my employer I will step down, from the position as WEC platform maintainer and I propose that Andreas Holzammer will succeed me in this position. He has been working with me on WEC issues for a long time and is also a long term contributor to Qt. Björn -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: Long Term Release discussion
Hi Gunnar, sadly i have to agree. I finally had the time to setup a Visual Studio 2013 with the recent Platform Builder and sadly the generated SDK's still have the Compiler Version 17.xx and says Visual Studio 2012. So the link indeed gets us to wrong assumptions. It is a bit sad since there is a working arm compiler as you said. But we can't force our users to try unsupported crude workarounds. So i hope we can find a consenus on having Visual Studio 2012 as a baseline. As otherwise we would drop Embedded Compact 2013 support directly after introducing it. Best regards Björn Breitmeyer -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Donnerstag, 18. Juni 2015, 12:50:27 schrieb Gunnar Roth: Hi Björn, i had the assumption you could mean that, but thats not a knowledge base article. I think you mean Compact 2013 uses the Microsoft Visual Studio 2013 compiler,? That part was also sent to me by a colleage from another department when discussing v8 usage( as this has vs2013 depedancy according to wiki). So we startet a MS Request to clear this issue. The answer was that the arcticle is wrong here. Where should the newer stdc++ lib for wec 2013 come from? As a side note, we were able to compile ffmpeg for wec2013 with the cl v18.00 arm compiler as this has sufficient c99 support. But that is not supported and c++ relies heavily on its stdc++ lib where we dont have a fitting version. Regards, Gunnar Gesendet: Donnerstag, 18. Juni 2015 um 11:48 Uhr Von: Björn Breitmeyer bjoern.breitme...@kdab.com An: Gunnar Roth gunnar.r...@gmx.de Cc: development@qt-project.org, Thiago Macieira thiago.macie...@intel.com Betreff: Re: Aw: Re: [Development] QtCS: Long Term Release discussion That would be this one, https://msdn.microsoft.com/en-us/library/gg154234.aspx btw, i would assume the use of the newer libstdc++ if i got it right, as that one comes from the sdk too. But maybe i am wrong, didn't gave this a lot of time yet, which is why i couldn't test it yet. -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Donnerstag, 18. Juni 2015, 11:00:30 schrieb Gunnar Roth: Hi Björn, what is the knowledgebase article? Would you mind to share a link? And even if there would be a v18.00 compiler, what about the standard c++ library (headers, libs and dlls) where do they come from? Or would then a mix of newer compiler and older std c++ libary be used? That could be quite problematic haven such a mix leading to unpredictable behaviour from a programmers view. Qt could then not say, vs2013 is the base, but only vs2013 compiler with vs12012 std libary. Sound crazy... Regards, Gunnar Gesendet: Donnerstag, 18. Juni 2015 um 10:41 Uhr Von: Björn Breitmeyer bjoern.breitme...@kdab.com An: development@qt-project.org Cc: Gunnar Roth gunnar.r...@gmx.de, Thiago Macieira thiago.macie...@intel.com Betreff: Re: [Development] QtCS: Long Term Release discussion Hello Gunnar, i still hadn't time to verify this, but. There is a platform builder for WEC2013, if you generate the SDk with that one it should have the Visual Studio 2013 compiler, at least thats how i read the knowledgebase article. Its on my TODO list to verify this, but i still didn't had the time to do so. Best regards Björn Breitmeyer -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Donnerstag, 18. Juni 2015, 10:16:49 schrieb Gunnar Roth: Gesendet: Donnerstag, 18. Juni 2015 um 08:43 Uhr Von: Thiago Macieira thiago.macie...@intel.com An: development@qt-project.org Betreff: Re: [Development] QtCS: Long Term Release discussion On Thursday 18 June 2015 08:23:52 Gunnar Roth wrote: Am 17.06.2015 um 22:35 schrieb Thiago Macieira thiago.macie...@intel.com: On Wednesday 17 June 2015 19:30:25 Gunnar Roth wrote: Yes that would make us (as a commercial user using a self made port of qt 5.4.1 to wec2013 ) very unhappy. This means 5.6 will be the last version wec2013 would be supported and you would go straight to making a back port very hard or even impossible. WEC 2013 was never considered deprecated. The deprecation applies to WEC 7 only. Well ok, but how does Lars Knoll’s sentence we could make VS2013 the compiler baseline for 5.7.“ fit
Re: [Development] QtCS: Long Term Release discussion
Hello Gunnar, i still hadn't time to verify this, but. There is a platform builder for WEC2013, if you generate the SDk with that one it should have the Visual Studio 2013 compiler, at least thats how i read the knowledgebase article. Its on my TODO list to verify this, but i still didn't had the time to do so. Best regards Björn Breitmeyer -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Donnerstag, 18. Juni 2015, 10:16:49 schrieb Gunnar Roth: Gesendet: Donnerstag, 18. Juni 2015 um 08:43 Uhr Von: Thiago Macieira thiago.macie...@intel.com An: development@qt-project.org Betreff: Re: [Development] QtCS: Long Term Release discussion On Thursday 18 June 2015 08:23:52 Gunnar Roth wrote: Am 17.06.2015 um 22:35 schrieb Thiago Macieira thiago.macie...@intel.com: On Wednesday 17 June 2015 19:30:25 Gunnar Roth wrote: Yes that would make us (as a commercial user using a self made port of qt 5.4.1 to wec2013 ) very unhappy. This means 5.6 will be the last version wec2013 would be supported and you would go straight to making a back port very hard or even impossible. WEC 2013 was never considered deprecated. The deprecation applies to WEC 7 only. Well ok, but how does Lars Knoll’s sentence we could make VS2013 the compiler baseline for 5.7.“ fit into this? As the only supported compiler for wec2013 is a cl with v 17.00 aka vs2012. Apparently VS2013 can also be used for WEC2013. IDE: yes Compiler: No This was recently confirmed to as by microsoft. The used compiler comes from the platfrombuilder wince800 tree, which is independent from the used IDE. The sdk wec2013 compiler form wec2013 qfe M08 has this version: Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50728.6 for ARM the vs2012 arm compiler ( which is meant for win pohne and winrt) has : Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for ARM I don't think the possible usage of the vs2013 ide has any impact on qt development. Regards, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: Long Term Release discussion
Sorry Visual Studio 2013 -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Donnerstag, 18. Juni 2015, 10:16:49 schrieb Gunnar Roth: Gesendet: Donnerstag, 18. Juni 2015 um 08:43 Uhr Von: Thiago Macieira thiago.macie...@intel.com An: development@qt-project.org Betreff: Re: [Development] QtCS: Long Term Release discussion On Thursday 18 June 2015 08:23:52 Gunnar Roth wrote: Am 17.06.2015 um 22:35 schrieb Thiago Macieira thiago.macie...@intel.com: On Wednesday 17 June 2015 19:30:25 Gunnar Roth wrote: Yes that would make us (as a commercial user using a self made port of qt 5.4.1 to wec2013 ) very unhappy. This means 5.6 will be the last version wec2013 would be supported and you would go straight to making a back port very hard or even impossible. WEC 2013 was never considered deprecated. The deprecation applies to WEC 7 only. Well ok, but how does Lars Knoll’s sentence we could make VS2013 the compiler baseline for 5.7.“ fit into this? As the only supported compiler for wec2013 is a cl with v 17.00 aka vs2012. Apparently VS2013 can also be used for WEC2013. IDE: yes Compiler: No This was recently confirmed to as by microsoft. The used compiler comes from the platfrombuilder wince800 tree, which is independent from the used IDE. The sdk wec2013 compiler form wec2013 qfe M08 has this version: Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50728.6 for ARM the vs2012 arm compiler ( which is meant for win pohne and winrt) has : Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for ARM I don't think the possible usage of the vs2013 ide has any impact on qt development. Regards, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtCS: Long Term Release discussion
That would be this one, https://msdn.microsoft.com/en-us/library/gg154234.aspx btw, i would assume the use of the newer libstdc++ if i got it right, as that one comes from the sdk too. But maybe i am wrong, didn't gave this a lot of time yet, which is why i couldn't test it yet. -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Donnerstag, 18. Juni 2015, 11:00:30 schrieb Gunnar Roth: Hi Björn, what is the knowledgebase article? Would you mind to share a link? And even if there would be a v18.00 compiler, what about the standard c++ library (headers, libs and dlls) where do they come from? Or would then a mix of newer compiler and older std c++ libary be used? That could be quite problematic haven such a mix leading to unpredictable behaviour from a programmers view. Qt could then not say, vs2013 is the base, but only vs2013 compiler with vs12012 std libary. Sound crazy... Regards, Gunnar Gesendet: Donnerstag, 18. Juni 2015 um 10:41 Uhr Von: Björn Breitmeyer bjoern.breitme...@kdab.com An: development@qt-project.org Cc: Gunnar Roth gunnar.r...@gmx.de, Thiago Macieira thiago.macie...@intel.com Betreff: Re: [Development] QtCS: Long Term Release discussion Hello Gunnar, i still hadn't time to verify this, but. There is a platform builder for WEC2013, if you generate the SDk with that one it should have the Visual Studio 2013 compiler, at least thats how i read the knowledgebase article. Its on my TODO list to verify this, but i still didn't had the time to do so. Best regards Björn Breitmeyer -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Senior Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Donnerstag, 18. Juni 2015, 10:16:49 schrieb Gunnar Roth: Gesendet: Donnerstag, 18. Juni 2015 um 08:43 Uhr Von: Thiago Macieira thiago.macie...@intel.com An: development@qt-project.org Betreff: Re: [Development] QtCS: Long Term Release discussion On Thursday 18 June 2015 08:23:52 Gunnar Roth wrote: Am 17.06.2015 um 22:35 schrieb Thiago Macieira thiago.macie...@intel.com: On Wednesday 17 June 2015 19:30:25 Gunnar Roth wrote: Yes that would make us (as a commercial user using a self made port of qt 5.4.1 to wec2013 ) very unhappy. This means 5.6 will be the last version wec2013 would be supported and you would go straight to making a back port very hard or even impossible. WEC 2013 was never considered deprecated. The deprecation applies to WEC 7 only. Well ok, but how does Lars Knoll’s sentence we could make VS2013 the compiler baseline for 5.7.“ fit into this? As the only supported compiler for wec2013 is a cl with v 17.00 aka vs2012. Apparently VS2013 can also be used for WEC2013. IDE: yes Compiler: No This was recently confirmed to as by microsoft. The used compiler comes from the platfrombuilder wince800 tree, which is independent from the used IDE. The sdk wec2013 compiler form wec2013 qfe M08 has this version: Microsoft (R) C/C++ Optimizing Compiler Version 17.00.50728.6 for ARM the vs2012 arm compiler ( which is meant for win pohne and winrt) has : Microsoft (R) C/C++ Optimizing Compiler Version 17.00.61030 for ARM I don't think the possible usage of the vs2013 ide has any impact on qt development. Regards, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Regarding the bloat, why not add the new functions and mark the old ones as deprecated. Of course it bloats the default. But it would also mean we know which functions will vanish encourage people not to use deprecated functions for old code and have a compile option that doesn't compile deprecated code(Maybe that exists already). -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Freitag, 20. Februar 2015, 10:04:31 schrieb André Somers: Bo Thorsen schreef op 20-2-2015 om 09:03: Andrés question about how this would change the API is a lot more interesting. I so far haven't seen a single case where someone has described how access to lambdas might improve the API. If they are there, I'd love to see them, because maybe this would teach me something I haven't figured out yet. One example I could come up with as a potential new API is QSortFilterProxyModel. Currently, it requires subclassing to change the sort or the filter functions: it supplies protected filterAcceptsRow, filterAcceptsColumn and lessThan functions. I think that it would be much more convenient if these filters and the comparator could be supplied as a function object (a lambda, or a functor, or a std::mem_fn, anything callable as a function). While this wasn't all that practical in the past, I think C++/11 makes this much more convenient than subclassing. This could of course just be added, instead of replacing. But that would mean API bloat. Downside of replacing is of course: you break old code. I think that if we go over the Qt classes, we'll find more examples of where a subclass or a separate function that you need to write could be replaced with a more modern API. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
I agree that it would be nice to have this, but we can do quite a bit of things with the Qt abstraction of most new features. And for std::function you can add new interfaces for compilers that do support it without breaking old code, its done for move constructors and co already. Sure it would be nice to have all the nice new and nifty features, but then again even msvc 2010 only supports a subset of c++11 and msvc2013 still doesn't fully support c++11 or c++98, neither will old gccs. What is allowed what not. And then breaking in a minor version is not very customer friendly. Dropping this would for e.g. drop the support for WinCE. Of course we are also porting to WEC2013 and maybe Qt6 only supports WEC2013, whichs compiler supports most c++11 and a lot of the windows platform plugin code, but i agree with Andre that this is something for a major release. Right the support for old hardware/software stacks is a big plus for Qt. Thats because customers are sitting on those platforms and want to go into the future, but they can just do that when their old platform goes End of Life. So Qt offers them a way to already build the next generation software on their old stack and then switch over. This is a big selling point for Qt. Customers in aviation, medical, automotive and others have demands to support their products for 10-20 years. And they also have to certify their stack. So long point short, i would like to dicuss this for a move to Qt6 because of this and the points Andre mentioned already. -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Donnerstag, 19. Februar 2015, 14:26:34 schrieb André Somers: Daniel Teske schreef op 19-2-2015 om 13:29: Hi, Standard C++ is evolving in a unprecedented pace at the moment. Both C++11 and C++14 added a lot of new good features. C++17 is planned to be a big step again. Qt needs to evolve together with C++ or it will be a outdated toolkit stuck in a C++98 world. As an example, Qt's container classes and C++11 range based for loop do not mix very well.[1] And for the same reason, the upcoming Ranges TS will not be too useful for Qt's container. We have started using some parts of C++11 in Creator a year ago and our experience is that lambdas (and std::function) are useful everywhere. Today we have more than 400 lambdas in Creator's source and have several interfaces that take a std::function. I would expect that allowing C++11 in Qt would similarly lead to a wider understanding on how to leverage the new features for better code and better APIs. We need to start now and deprecate old compilers that do not support any C++11 features at all. I I suggest requiring support for lambda as supported by MSVC 2010, g++ 4.5 and clang 3.1 in Qt 5.7 and deprecating all platforms that do not in Qt 5.6. daniel [1] ranged based for uses std::begin(container), which if not overloaded calls container.begin(), which detaches. So using range-based can be used: - If the container is const or - If the container is unshared or - To actually change the container's contents I do get what you mean, and I think they are all valid concerns. But I am wondering if the move to support/base Qt API more on top of modern C++ developments is not something that belongs in a major release instead of a minor one. I think there are quite a few APIs in Qt that may need reconsidering in this light. Would it not make more sense to introduce a break like that in a major release instead? Perhaps Qt 6 should not be in the too far future, and might be focused on breaking with the pre-C++ 11 heritage? At the same time, Qt 5 might be kept alive next to that for a while yet. Not just with bugfixes, but with whatever features are still feasible to backport to it. Question would be: if C++11 support could be dropped, what APIs would benefit from being re-designed? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
Well start with the easiest understanable reasons. People come from old platforms whith old applications and they don't know what their upcoming hardware platforms will be, so they decide why not go to Qt first and then decide, which platform is usable for us. Thats a pretty common theme and if you stop supporting the old platforms you likely won't get those customers. Besides its something were you can earn money. Putting pressure on a vendor is in most cases not achieving much. Even really really big companies are screwed if some important vendor in their stack isn't getting their job done, its one of the reasons why the chosen hardware is most likely not bleeding edge, as there are timeframes to meet until product release. Then there are industries which need certified operating systems for their field, they don't have the option to use the newest yocto and if they decided to use one kind of os the certification process most likely binds them to this os for the complete product lifetime. So yes they are putting the burden on us, because they can't reliably put them somewhere else. You might ask why should we take the burden, because those companies are paying quite a bit of money too get what they need if it actually helps. And yes of course we would like to use newer compiler versions, but in most cases with the option c++11 support how much extra pain do we have? Embedded is just not like desktop that even goes for gcc on linux. -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Sonntag, 8. Februar 2015, 10:25:51 schrieb Thiago Macieira: On Sunday 08 February 2015 19:15:18 Giuseppe D'Angelo wrote: Il 08/02/2015 17:58, Thiago Macieira ha scritto: So we come back to this question again and again: if you can't upgrade the OS and upgrade the compiler, why do you want to upgrade Qt? Because people want to use the latest features / bugfixes for developing their product, and yet they need to target such platforms... Indeed, but that is putting the burden on us. They should instead insist with their vendors to get a newer platform and put the burden on them. Or next time, make sure you use a device that can run Linux so you can easily rebuild with Yocto -- every 6 months you get a new toolchain and sysroot with the latest updates. I'm going to say that if you chose a vendor that won't upgrade, it's your fault and you should live with the consequences. Anyway, every time this comes up, the answer is the same: we will drop those platforms once they become too much of a burden to support and prevent us from doing new things. That's why OS X 10.6 went away. smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating modules with 5.5
This would be the same as dropping the Windows Embedded Compact support. So its a clear no from my side. -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Donnerstag, 5. Februar 2015, 09:07:12 schrieb Henry Skoglund: +1 for dropping VS2008. For those with thin wallets it's easier to upgrade nowadays anyway to the VS2013 Community Edition. /Rgrds Henry On 2015-02-05 08:31, Bo Thorsen wrote: Den 04-02-2015 kl. 15:56 skrev Olivier Goffart: On Wednesday 04 February 2015 09:23:12 Knoll Lars wrote: On 04/02/15 10:20, Olivier Goffart oliv...@woboq.com wrote: Also, is it not time to decide which platform are we going to stop supporting in Qt 5.6? For example, if we were to decide to start using some of the C++11, we should drop MSVC 2008 which would allow us to already use things like auto and decltype. We could also drop gcc 4.4 which would let us lambda function. In principle I agree. The problem with 2008 is that this is currently the only compiler supporting Windows Embedded 7, so we can’t easily get rid of it. Dropping gcc 4.4 is afaik not a big problem. The question then is how relevant will Windows Embedded 7 be in 2016 when Qt 5.6 will be there. And if it is worth to limit ourselves because of it. Sounds to me like 5.5 will be a release that will be around for a while then. This could be the one where those who need webkit, VS 2008 og Qt Quick 1 would use. So declaring support for this will continue for a while could make it easier to remove those parts. If this could be the case, it could even be considered to go even further and get rid of more stuff. VS 2010 would be one possibility. I'm writing this with VS 2010 open for the project I'm currently on, so I know it's still in use :) But getting rid of this opens for a lot more C++11 features. What I'm suggesting here is sort of a mini major release. It doesn't feel like a 6.0 is necessary yet, but as the 5 line is mayby around half through it's life, it might not be a bad idea to make a longer term release. Bo. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Any C++11-capable compiler for Windows CE?
There always were gcc versions that could compile to Wince, but getting that to work with the microsoft libs etc is quite a hassle, never bugfree and you loose the ability to use visual studio for debugging, remote deployment, etc. Or in short most customers won't even bother to look. -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Montag, 6. Oktober 2014, 11:58:40 schrieb Kevin Kofler: Hi, Thiago Macieira wrote: Question to the folks who follow Windows CE development: is there any light at the end of the tunnel about compiling C++11 code for that platform? Basically, Windows CE support right now completely blocks any idea of using C++11 code in Qt, since the only compiler supporting that platform that I know of is MSVC 2008. I know this is an old thread, but: http://max.kellermann.name/projects/cegcc/ has GCC 4.6.3. If that isn't new enough, upgrading from there to 4.7.x, 4.8.x or even 4.9.x is probably doable. It is never a good idea to rely on M$. ;-) Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Port Qt application to WEC2013
Hi, this is not yet supported, we are waiting for an OpenGL driver for our platform and some time to tackle this. Its planned though. It is correct that you will need to change qmake to find where VS2012 stores its SDK list. The Mkspec specified the SDK name in the WCE.VCPlatform.xml and allowed us to generate Makefiles with the correct environment. Apart from that you will need to adapt the mkspec compilerflags. Best regards Björn Breitmeyer -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Freitag, 27. Juni 2014, 16:11:16 schrieb Håkon B Grundnes: Hi! I'm trying to run a Qt application on WEC2013. Has anyone done this yet, and is it even possible? I am completely new to Qt. I was thinking I should configure qmake to compile the application for a WEC2013 SDK. First I was thinking I could use the configure file for wec7, but since wec2013 isn't running on VS2008 it doesn't apply. For instance CE_SDK uses a visual studio 2008 file *WCE.VCPlatform.xml* that is not a part of Visual Studio 2012 or 2013. Now I was thinking I could look into the configure files that's for platforms using VS2012 and compare them, find out what qmake needs of information to compile for VS2012 and kind of taylor it together. I suspect the problem is more complex than this though. All thoughts and help on this subject are highly appreciated. best regards Håkon smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Help with WinCE: time()
Hi Thiago, at most the struct is defined, i think sometime there was even a fordward declare of the time function. Short version you have to take a different codepath if you need that for ce. Have a look in qdatetime.cpp. Basically you would use a system call to get the time in a different format and use qfunctions_wince.h to convert that to a time_t. -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Mittwoch, 2. April 2014, 16:42:45 schrieb Thiago Macieira: According to the C standard, 7.23.2.4: 7.23.2.4 The time function Synopsis #include time.h time_t time(time_t *timer); The Linux manual says: CONFORMING TO SVr4, 4.3BSD, C89, C99, POSIX.1-2001. However, it's not working in https://codereview.qt-project.org/81697. The CI says: main.cpp(110) : error C3861: 'time': identifier not found http://testresults.qt-project.org/ci/QtBase_stable_Integration/build_03592/w ince70embedded-armv4i-msvc2008_Windows_7/log.txt.gz What gives? Where is time() defined for WinCE? smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The Dynamic OpenGL on Windows Change
Since i haven't followed the discussion in detail, based on which assumptions do you plan to use a dynamic switch. Exported GL Symbols from QtGui sounds like a very bad idea. Relying on QOpenGLFunctions makes more sense. But right now i don't really see how this buys anybody anything, you usually need to know which renderer to use, usually there is a switch in software if they have different rederers so the user can change them if they don't work as expected. I have never really seen any runtime detection that works really well. Best regards Björn Breitmeyer -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Freitag, 28. Februar 2014, 11:49:56 schrieb Agocs Laszlo: You cannot include multiple GL headers. In a dynamic build you have the desktop GL header ( + qopenglext.h), just like in a 'desktop' build. This does not change at all. Runtime errors are not a problem since all ES-specific paths are guarded by the appropriate condition. I realize however that there are genuine concerns around exporting all the symbols from QtGui, and that the approach will most likely not scale to other platforms. A compromise could be to revert the change for 5.3 (since it is anyway behind an experimental configuration option) and instead try gradually introducing an alternative approach in future releases: 1. Leave code that directly calls OpenGL functions alone. Instead, extend QOpenGLFunctions with the common subset of OpenGL 1.x and ES2 functions which are missing today. This would allow writing context-functions()-glClear() etc. which is not possible today. 2. Once this is in place, all of qtbase and qtdeclarative (and later all other modules) have to be changed to stop directly calling OpenGL functions. Instead, they must rely on QOpenGLFunctions (which they most likely do already for GL 2 specific calls anyhow). 3. QOpenGLFunctions gets platform specific backends that perform dynamic loading of the OpenGL implementation. For example, the Windows backend would do the tests for choosing between desktop - Angle and then dynamically load the selected implementation. QtGui stops linking to opengl32/libegl/libglesv2. 4. The windowing system interfacing code, for example all the usage of WGL and EGL in the windows platform plugin, has to be placed behind a new private wrapper similar to QOpenGLFunctions. This could expose an EGL-style API, with platform specific backends that provide an implementation using the dynamically resolved EGL/WGL/GLX functions. Another alternative would be to continue betting on Angle as the primary OpenGL enabler on Windows, and investigate how well the software rasterizer fallback in D3D11-based Angle works. As I understand this would be available on Win7+ in VS2012+ builds. If this could solve the issues we see today with virtual machines and machines without decent drivers, it might reduce the urgency for needing a true dynamic GL solution. Cheers, Laszlo -Original Message- From: Sean Harmer [mailto:sean.har...@kdab.com] Sent: 28. februar 2014 11:41 To: development@qt-project.org Cc: Gunnar Sletta; Agocs Laszlo Subject: Re: Re: [Development] The Dynamic OpenGL on Windows Change Hi Gunnar, On Friday 28 February 2014 07:14:24 Gunnar Sletta wrote: On 27 Feb 2014, at 22:17, Agocs Laszlo laszlo.ag...@digia.com wrote: On Thu, Feb 27, 2014 at 02:28:26PM +, Sean Harmer wrote: The apparent problem that this is attempting to address is the need for both ANGLE and desktop OpenGL builds of Qt on windows. As you know Qt As pointed out by Friedmann earlier, the big picture is a somewhat more complicated. This is just the beginning. ... And I agree to all this. It is a good change, and I'm happy to see it. Also, I would be very surprised if the added if-statements inside Qt makes much of a difference to performance. As long as that logic stays primarily inside Qt, it also doesn't hurt application complexity. What I don't understand, and which is quite likely entirely my fault as I'm rather sleep-deprived recently (new baby), is that to me it seems like situations such as trying to use desktop GL with an ES 2 build or vice versa would have until now resulted in compile time errors. Now they will become potential runtime errors (e.g. GL_INVALID_ENUM). Also, is it safe in #include the ES2 headers on top of the desktop ones now and in the future? That's a genuine question, I honestly don't know. If everybody else is happy to live with this then I'll shut up. We should still consider if it makes sense for QtGui to export these symbols or whether they should be moved to a new library though. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing
Re: [Development] The VS2008 WinCE errors
Hi Thiago, the internal error is a compiler bug. We don't exactly know whats necessary to trigger it. It happens more likely if there is more than one instance of the compiler running at the same time, or if a visual studio environment is opened. However some code pathes might be triggering this too. The preprocessor output can be found here: http://www.kdab.com/~bjoern/tst_qatomicint.7z Best regards Björn Breitmeyer -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Dienstag, 11. Februar 2014, 12:59:45 schrieb Thiago Macieira: Current tests are frequently showing the following error messages: c: \work\build\qt\qtbase\tests\auto\corelib\global\qtendian\tst_qtendian.cpp(14 0) : fatal error C1001: An internal error has occurred in the compiler. Anyone who can try to test what we could shuffle around to get rid of the error? The other error is: ..\tst_qatomicinteger.cpp(168) : error C2027: use of undefined type 'QStaticAssertFailureTest' Line 168 is a function declaration in the middle of the class: void fetchAndSub(); The nearest Q_STATIC_ASSERT is 20 lines down, in a function which is not the one declared above: Q_STATIC_ASSERT(sizeof(QAtomicIntegerT) == sizeof(T)); Q_STATIC_ASSERT(Q_ALIGNOF(QAtomicIntegerT) == Q_ALIGNOF(TypeInStructT)); This appears to be the char16_t test, but since VS 2008 does not support Unicode strings, the test should compile with T == int and simply cause a QSKIP in initTestCase. Given: - the above ICE - the fact that there's problem for compiling short, ushort, wchar_t or char32_t - 16-bit atomics are not supported on WinCE due to lack of intrinsics I'm guessing it's *also* a compiler bug. But can someone verify my assumptions? That it's the char16_t test, that the preprocessor output was correct and using QAtomicIntegerint, that there's a QSKIP in initTestCase? smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing MSVC2008 from the CI build farm?
No bad idea, 2008 is the last version supporting anything older than the new WEC2013 which we don't support yet, so its not likely to drop in the comming years without dropping CE support too. -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions Am Mittwoch, 5. Februar 2014, 08:50:10 schrieb Thiago Macieira: Hello guys Is it maybe time to get rid of MSVC 2008 from our build farm? Do the new versions support wince builds? c:\work\build\qt\qtbase\tests\auto\corelib\global\qtendian\tst_qtendian. cp p(140) : fatal error C1001: An internal error has occurred in the compiler. Build log: http://testresults.qt-project.org/ci/QtBase_dev_Integration/build_02794/ w ince70embedded-armv4i-msvc2008_Windows_7/log.txt.gz smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.2 Beta - is it really much slower to parse qml/javascript on android?
I think i know whats the issue if its still not fixed. My guess is that you don't use the resource system of Qt but the android application assets to store your components, the last time i had issues with this all the time was lost in the horrible slow fileengine for assets on android. It looked to me it was reopening the assets all the time which seems expensive. I haven't tried it since 5.1 but if it is not fixed its very likely the cause of your problem. Björn Am Mittwoch, 30. Oktober 2013, 07:07:41 schrieb Koehne Kai: -Original Message- From: development-bounces+kai.koehne=digia@qt-project.org [mailto:development-bounces+kai.koehne=digia@qt-project.org] On Behalf Of Felipe Crochik Sent: Tuesday, October 29, 2013 7:13 PM To: Hausmann Simon Cc: development@qt-project.org Subject: Re: [Development] Qt 5.2 Beta - is it really much slower to parse qml/javascript on android? Simon, Quick update: I tried arm7va and got almost the same results (a very small improvement but still over 3seconds). It doesn't seem to be related at all to my code. It seems that it is adding some fixed amount of time for each component than has to parse. It doesn't look like is related to what they are or how complex. For instance in one of my tests I had a component that was a Rectangle with a Text inside, by just refactoring the Text to become another component I went from 1.2s load time to almost 2. The example does not include any javascript Have you tried running the app with the QML Profiler attached? See http://qt-project.org/doc/qtcreator-2.8/creator-qml-performance-monitor.html Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML engine changes
Hi, Does that include to get rid of v8 as an JS engine option for QML2? I have not tested it yet, but it would be interesting to know if the new engine also uses just in time compilation, as we had quite some work done to get v8 running on WinCE due to wrong ARM abis for Windows CE among other things. Best regards Björn Breitmeyer Am Montag, 24. Juni 2013, 10:26:33 schrieb Simon Hausmann: Hi, As you may have heard (or read), Lars, Erik and I have been working on some bigger changes for qtdeclarative for a while. In a nutshell we've replaced the V8 JavaScript engine with a new engine that we wrote (based on work by Roberto and Aaron). We've progressed rather well and in our wip/v4 branch in qtdeclarative we're now passing all auto tests (as well as the ECMAScript 262 test suite). So that's why we'd like to propose merging this work into qtdeclarative mainline (dev branch), in the coming days/week(s) - in time for Qt 5.2 though. We think that this work brings in many advantages, among others much improved maintenance (we know how this thing works, which isn't something we can confidently say about V8 as much as we'd like to), a unified code path in QML [1], much less code overall and great opportunities for optimizations (way beyond what's possible with V8's API layer - you'd be surprised how often even in today's QML usage the V8 code path is not actually taken because it's slower that the built-in interpreter). So this is a heads-up and of course a last call for objections :) Simon [1] Did you know what when you read a URL property in QML binding expressions, sometimes it's a string and sometimes it's an opaque variant? That's because the builtin interpreter in qtdeclarative and V8 behave different. We're fixing that :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development Join us in October at Qt Developer Days 2013 - https://devdays.kdab.com -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Making WEC7 builds blocking on CI
Hey, thanks for you effort. The enforcing build would be very helpful. The most important issues we had during the last few month were changes in qmake, arch detection :) and some additions to the windows plugin. Besides changes to the windows platform plugin most changes were not really troubling, its usually about platform plugin features that are not available on windows ce. What more people should actually care about and which is not tested by the ci yet is that we had real issues with people break QT_NO_... there are some hard things we just don't have on windows ce and we run into those quite often. So if you add new patches it would be great to look out of for QT_NO_CURSOR QT_NO_ACCESSIBILITY QT_NO_PRINTER an more stuff like that. If you happen to work on the windows platform plugin, here are some recommendations. If you have functions taking strings that come in an A and W version( ansi and widestring(utf16) ) use the W version as that is usually available on ce too. And if you are unsure if the winapi function you used is available on ce too, just google function name msdn wince and you will usually get your answer in matter of a seconds. Besides that we of course had our low level arm fun, but thats mostly sorted out until there is a new javascriptengine. Best regards Björn Breitmeyer Am Mittwoch, 24. April 2013, 08:25:06 schrieb Thiago Macieira: On quarta-feira, 24 de abril de 2013 12.41.15, Andreas Holzammer wrote: Hey, I fully agree with Janne here, as normally its not so hard to fix Windows Embedded Compact issue, but if we let it run and try to fix it after a month or so, its very hard and takes time, as one need to understand the code and maybe even needs talking to the author of the patch. So I would really love to see the WEC7 CI enforcing. Thank you Janne for all the patches and all the efforts What's the track record for that build? Can you guys share what the most common failures have been in the past? What are the things people should be aware of? -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposed solution to the ICU problem
Hi, i am a bit confused now, will ICU be hard dependency on 5.0 instead of 5.1? As i already mentioned we are having problems with a hard ICU dependency for WindowsCE as its not supported by the ICU buildsystem. Will ICU become part of the 3rdparty repo with a more cross platform friendly buildsystem? As of know its a huge linux configure script and i was unable to even generate my own visual studio solution with the proposed cygwin setup. The only way to get a working windows build is use the shipped sln file which requires a new visual studio. In general i don't know how open the ICU guys are to new platforms. But i see this as a larger problem for porting qt to a non unix platform. I get the reason why ICU is a good idea for supported platforms, but is there a reason to enforce it on all platforms? Best regards Björn Breitmeyer Am Dienstag, 31. Juli 2012, 14:00:10 schrieb Thiago Macieira: Quick discussion on IRC happened. This is a summary of the discussion and proposal for the SDK. Situation: The ICU libraries *do* offer a stable C API, which they say they will maintain and keep compatible. However, the library soname changes on every version and most distributors enable symbol renaming. That means we cannot depend on the stable API. What's more, ICU may or may not be present on some systems. On WIndows, it's not present. Therefore, we need to supply our own ICU anyway. Any Windows programs will need to ship it and our deployment instructions should be adapted to match. On iOS, it is present but dlopen is not available to applications. Therefore, we must link to it anyway (note: I don't know if App Store rules permit that). If the ICU versions do change on different iOS versions, then application developers will need to create multiple versions of their applications. For Linux distribution packages, the version of ICU is tightly controlled by the distributors. Therefore, linking to it is no problem and should be the default. This is also the default for people downloading and building from sources. The problem remains for the Linux and Mac SDKs and for Android. I don't know the situation on QNX, but it is either this case or the one above of distribution packages. For the Linux and Mac SDKs, we *can* get away with shipping our own copy of ICU, just like it will be done for Windows. For Android, it would be preferable if we could dlopen the library. If we have the code to dlopen, however, then we could also use it for Linux and Mac SDKs. Unfortunately, due to the symbol renaming, soname renaming and the QtWebKit dependency, this solution is too much work for 5.0. Proposal: We propose then that for the 5.0 SDK packages, we ship our own copy of ICU, in all cases. It's already done for Windows. I'd also recommend going further and using ICU's own renaming system to insert a q in the function names and soname so they don't conflict with the system. As a 5.1 task, we propose investigating the searching+dlopen solution. -- Björn Breitmeyer | bjoern.breitme...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Germany: +49-30-521325470, Sweden (HQ): +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
