Re: [Development] QtWebChannel: Upstreaming of Python client
Hi Arno, On 26 October 2016 at 19:32, Arno Rehn wrote: > On 25.10.2016 13:36, Johannes Lochmann wrote: > >> Hi Arno, >> >> On 24 October 2016 at 00:53, Arno Rehn >>> wrote: >>> Hey everybody, At my company we've developed a Python client for QtWebChannel. It consists of a more or less direct translation of qwebchannel.js and an additional layer on top of it, providing async/await syntax support for Python3.5+. Ideally, we'd like to push this upstream. Before I post a patch to gerrit, I'd like to get some feedback on whether this is wanted at all. QtWebChannel seems to be pretty much focused on HTML and the web, but the infrastructure behind it can be used for remoting from pretty much any scripting language. I'd also plan on implementing a C++ client, maybe also Ruby and Matlab (since we're using this in a scientific setting). What's your take on this? >>> >>> Seems useful. Would be interested to try it out. >>> >> >> I agree, this sounds pretty useful, especially given that we’re also >> working again on pyside since this spring. >> >> ...especially an implementation in Python and C++ both from the Qt >> Project could be a really nice combo - sign me up! >> > Thanks for all the feedback! Nice to know that people are interested :) > I'll polish the code a little and create a review request. Did this ever get followed up? Regards, Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWebChannel: Upstreaming of Python client
Hi Arno, On 24 October 2016 at 00:53, Arno Rehn wrote: > Hey everybody, > > At my company we've developed a Python client for QtWebChannel. It > consists of a more or less direct translation of qwebchannel.js and an > additional layer on top of it, providing async/await syntax support for > Python3.5+. > Ideally, we'd like to push this upstream. Before I post a patch to > gerrit, I'd like to get some feedback on whether this is wanted at all. > QtWebChannel seems to be pretty much focused on HTML and the web, but > the infrastructure behind it can be used for remoting from pretty much > any scripting language. > I'd also plan on implementing a C++ client, maybe also Ruby and Matlab > (since we're using this in a scientific setting). > > What's your take on this? Seems useful. Would be interested to try it out. > > Regards, > > -- > Arno Rehn > Tel +49 89 189 166 0 > Fax +49 89 189 166 111 > a.r...@menlosystems.com > www.menlosystems.com > > Menlo Systems GmbH > Am Klopferspitz 19a, 82152 Martinsried, Germany > Amtsgericht München HRB 138145 > Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth > USt.-IdNr. DE217772017, St.-Nr. 14316170324 Regards, Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QML] Singletons are deleted before the other objects
On 19/09/2014 10:37 PM, BogDan wrote: > Hello folks, > >Singletons registered using qmlRegisterSingletonType, are deleted *before* > the other active objects. I consider it to be wrong because some of the active > objects may still need to access the singletons in their destructor ... > > IMHO singletons should be the very last objects deleted (also in the reverse > order). > > Is there any reason why they are deleted before the other active objects? > Or this is just a bug? > > Cheers, > BogDan. > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Would this also be related to https://bugreports.qt-project.org/browse/QTBUG-38422? Regards, Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Dropping XP?
On 11/12/2013 8:03 PM, Ziller Eike wrote: > On Dec 11, 2013, at 6:27 AM, Jonathan Liu wrote: > >> On 10 December 2013 18:34, Koehne Kai wrote: >>>> -Original Message- >>>> From: development-bounces+kai.koehne=digia@qt-project.org >>>> [mailto:development-bounces+kai.koehne=digia@qt-project.org] On >>>> Behalf Of Thiago Macieira >>>> Sent: Monday, December 09, 2013 11:24 PM >>>> To: development@qt-project.org >>>> Subject: [Development] Dropping XP? >>>> >>>> As Kenneth reminds us[1], Microsoft is ending the security updates for >>>> Windows XP in April 2014. That's about when we plan to release Qt 5.3. >>> Actually ANGLE (one of the OpenGL backends we have for Windows) doesn't >>> support Windows XP already now, which is why e.g. Qt Creator 3.0 will not >>> support it either in 5.2. >> Another option would be to build Qt Creator 3.0 for Windows using >> desktop OpenGL and have an option in the installer to install the Mesa >> LLVMpipe software renderer. I have written some instructions for cross >> compiling Mesa for Windows here: >> http://qt-project.org/wiki/Cross-compiling-Mesa-for-Windows > I think even if Qt will still support Windows XP (as a deployment platform) > it is completely fine if the pre-built Qt Creator packages do not. At least I > don’t think we should at this point start investing a lot of time on this. > Of course if someone writes down instructions on how one can build Qt Creator > even for Windows XP somewhere in our wiki (or maybe even extending/fixing the > README in Qt Creator’s sources), that’d be a perfectly welcome addition ;) You don't need to do anything special for building Qt Creator for Windows XP. The Qt libraries just need to be built targetting desktop OpenGL. If you have proper OpenGL 2.1 drivers, run Qt Creator as normal. If you don't, copy Mesa's opengl32.dll to same folder as qtcreator.exe and then run Qt Creator. Regards, Jonathan > > My 2 1/2 cents, > Eike > >> Regards, >> Jonathan >> >>>> Should we stop supporting Windows XP? Is there anything we can improve in >>>> our codebase if we do? >>> I don't know about the codebase, but given the feedback for Qt Creator >>> there are still a lot of people using XP even as a development platform ... >>> so I'd expect quite some backslash if we completely drop support for >>> Windows XP, at least for 'traditional' QWidget based apps. >>> >>> My 2 cents >>> >>> Kai >> ___ >> Development mailing list >> Development@qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Dropping XP?
On 10 December 2013 18:34, Koehne Kai wrote: > >> -Original Message- >> From: development-bounces+kai.koehne=digia@qt-project.org >> [mailto:development-bounces+kai.koehne=digia@qt-project.org] On >> Behalf Of Thiago Macieira >> Sent: Monday, December 09, 2013 11:24 PM >> To: development@qt-project.org >> Subject: [Development] Dropping XP? >> >> As Kenneth reminds us[1], Microsoft is ending the security updates for >> Windows XP in April 2014. That's about when we plan to release Qt 5.3. > > Actually ANGLE (one of the OpenGL backends we have for Windows) doesn't > support Windows XP already now, which is why e.g. Qt Creator 3.0 will not > support it either in 5.2. Another option would be to build Qt Creator 3.0 for Windows using desktop OpenGL and have an option in the installer to install the Mesa LLVMpipe software renderer. I have written some instructions for cross compiling Mesa for Windows here: http://qt-project.org/wiki/Cross-compiling-Mesa-for-Windows Regards, Jonathan > >> Should we stop supporting Windows XP? Is there anything we can improve in >> our codebase if we do? > > I don't know about the codebase, but given the feedback for Qt Creator there > are still a lot of people using XP even as a development platform ... so I'd > expect quite some backslash if we completely drop support for Windows XP, at > least for 'traditional' QWidget based apps. > > My 2 cents > > Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Switch of MinGW toolchain for Qt 5.1
On 4/04/2013 8:38 PM, Koehne Kai wrote: > I'd like to update the recommended 32 bit MinGW toolchain (that we also ship > in binary installers) for 5.1 from > >x32-4.7.2-release-posix-sjlj-rev8 > to >x32-4.8.0-release-posix-dwarf-rev1 > > The recommended 64 bit toolchain would change accordingly from > >x64-4.7.2-release-posix-sjlj-rev8 > to >x64-4.8.0-release-posix-seh-rev1 Hi, ANGLE doesn't compile with GCC 4.8.0 Rev 1 toolchain. d3dcompiler.h needs some patches which I've submitted upstream to wine-patches mailing list (mingw-w64 DirectX headers are from Wine): http://source.winehq.org/patches/data/95566 http://source.winehq.org/patches/data/95567 Patch status: http://source.winehq.org/patches/ Regards, Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 mingw official build
On 20/12/2012 7:33 PM, Hausmann Simon wrote: > I think Jonathan's latest webkit fixes actually made it into the release tar > ball. Not all of the fixes. See towards the end of this page for the other patches you need - http://qt-project.org/wiki/MinGW-64-bit >> Good day! >> >> Just one question. >> >> What about mingw official builds. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Qt 4.8.4 Release candidate 3 available
On 15/11/2012 12:28 AM, Taipale Juhani wrote: Qt 4.8.4 Release candidate 3 packages are available at http://releases.qt-project.org/digia/4.8.4_RC3/ It is built on SHA1: d742aa4ee727de0e318e26ba24b11a780081f0c9 .tag file in qt-everywhere-opensource-src-4.8.4-rc3.tar.gz indicates source revision is actually 5ec6e2aca2950634d39195cc858bf062a2e2618d. Regards, Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Qt 4.8.4 release candidates are available
On 6/11/2012 2:55 AM, Salovaara Akseli wrote: > Thank you for notification. SHA-1 c16471dd7aa6ce9b9768e70de66763f73584d880 > will be in Qt 4.8.4. changes-4.8.4_RC2 has incorrect reference to QTBUG. - QGLTextureGlyphCache: Fix text rendering artifacts on NVIDIA [QTBUG-27658] should be: - QGLTextureGlyphCache: Fix text rendering artifacts on NVIDIA [QTBUG-26444] Regards, Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt wiki MinGW for 64 bit
On 14/09/2012 10:55 PM, kai.koe...@nokia.com wrote: >>> That's interesting. So the linking of designer_components with the >>> precompiled header works for you? >> It turns out so .. >> Or, perhaps, the matter is that you used 32-bit MinGW for >> crosscompiling for 64-bit. > No, actually the error only appeared when I was using the native 64 bit > toolchain. > >>> Which exact sha of qttools are you using? >> fe4595462835acd930477079a09838147ea8d053 > I'll try to verify on Monday ... I submitted a workaround for this sometime ago: https://codereview.qt-project.org/#change,34049 It should be building fine with latest qttools git master. Regards, Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt wiki MinGW for 64 bit
On 14/09/2012 7:55 PM, niXman wrote: > Today, reading this(qt-project.org/wiki/MinGW-64-bit) note, I paid > attention to the fact that it refers to the need to edit qmake.conf > Qt5 for building 64-bit. > But yesterday, I have built Qt5 for 64-bit successfully without > changing qmake.conf. > Tell me please, why in the wiki is said that it is necessary to change > qmake.conf? The mkspec changes are needed if you have a GCC multilib compiler that can target both 32-bit and 64-bit. If the compiler is targeting 32-bit by default, it needs some additional flags to tell it to build for 64-bit. Regards, Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Building Qt5 on windows
Hi Kai, On 14/09/2012 6:45 PM, kai.koe...@nokia.com wrote: >>> From: development-bounces+kai.koehne=nokia@qt-project.org >>> [development-bounces+kai.koehne=nokia@qt-project.org] on behalf of ext >>> Jonathan Liu [net...@gmail.com] >> GCC uses CPATH with paths separated by colons instead of INCLUDE. >> GCC uses LIBRARY_PATH with paths separated by colons instead of LIB. >> >> INCLUDE and LIB are used by Microsoft Visual C++ Compiler not GCC. > I'm not sure about the exact relationship between CPATH/INCLUDE and > LIBRARY_PATH/LIB, but what I know is that gcc does care about INCLUDE and > LIB. I managed to run mingw32-make one or two times in an environment with > INCLUDE and LIB set to MSVC, and the result was that gcc picked up the wrong > headers ... CPATH and LIBRARY_PATH in the GCC documentation: http://gcc.gnu.org/onlinedocs/gcc/Environment-Variables.html LIB for Visual C++ Linker: http://msdn.microsoft.com/en-us/library/6y6t9esh.aspx INCLUDE for Visual C++ Compiler: http://msdn.microsoft.com/en-us/library/kezkeayy.aspx There could be other things that are affected by INCLUDE and LIB environment variables that influence the invocation of GCC. GCC is not affected by the INCLUDE and LIB environment variables if you just call gcc directly. Regards, Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Building Qt5 on windows
On 13/09/2012 8:57 PM, Алексей Павлов wrote: /set INCLUDE=%MINGW_HOME%\%MINGW_HOST%\include;%EXTRA%\include;%QTINSTDIR%\databases\firebird\include;%QTINSTDIR%\databases\mysql\include;%QTINSTDIR%\databases\pgsql\include/ /set LIB=%MINGW_HOME%\%MINGW_HOST%\lib;%EXTRA%\lib;%QTINSTDIR%\databases\firebird\lib;%QTINSTDIR%\databases\mysql\lib;%QTINSTDIR%\databases\pgsql\lib/ GCC uses CPATH with paths separated by colons instead of INCLUDE. GCC uses LIBRARY_PATH with paths separated by colons instead of LIB. INCLUDE and LIB are used by Microsoft Visual C++ Compiler not GCC. Regards, Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Choosing a new MinGW for Qt 5
On 31/08/2012 2:16 AM, Thiago Macieira wrote: > On quinta-feira, 30 de agosto de 2012 17.25.24, Pau Garcia i Quiles wrote: >> There are more differences than that. There are differences in >> features, such as threading support, large-file support, etc. >> Mingw-w64 is usually ahead of any other in terms of features. > > My suggestion on how to proceed is to choose one that offers the following or > most of the following: > > - most recent GCC (4.7 preferably, 4.6 if not) I had a problem with MinGW-builds GCC 4.7.1 32-bit. Qt Creator would crash if I opened the Qt resource editor if Qt 4.8.2 and Qt Creator 2.5.2 were compiled with it. MinGW-builds GCC 4.7.1 64-bit didn't crash. I switched to MinGW-builds 4.6.3 for both 32-bit and 64-bit and it seems to be working fine. Also, GCC 4.7.x has problem where it runs out of memory in some cases (https://bugs.archlinux.org/task/28329). > - make with -j support Patch for that here: http://www.mail-archive.com/make-w32@gnu.org/msg02283.html. I use this regularly with 8 threads (set MAKEFLAGS=-j8). It is also in GNU Make CVS. > - if this exists: can link to .dll directly, instead of import libs I've done this before linking to some proprietary C dlls created by Visual C++. YMMV. > > We should choose one version to be the reference platform and work on making > it Tier 1. We shouldn't have two versions, that duplicates work. I agree. Some other MinGW-related notes follow. Compiling WebKit fails due to mingw32-make using temporary batch files which are subject to 8191 character limit per line. Can be fixed using instructions at: http://old.nabble.com/Re%3A-command-line-limit-in-mingw-make-p33909533.html ICU can be compiled with MinGW-w64 after applying: http://bugs.icu-project.org/trac/changeset/31770/icu/trunk/source/tools/toolutil/pkg_genc.c?format=diff&new=31770 Regards, Jonathan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
