[Development] Qt Platform Extras
Hi, Getting ready for the 5.1 feature freeze, I think we should take some time unifying the structure and API of the platform extras modules. There has already been some private discussion on this topic, and this is an attempt at reaching a final consensus. I think it's important that these modules are as similar as possible. API: - Some classes and functions are named for Qt 4 compatbilty. These need to stay as is. * qt_mac_set_dock_menu(QMenu *) - Classes: QPlatformFoo (QMacNativeWidget, QX11Info) - Stand-alone function namespace: * Qt::toPlatformType (“Qt::toWindowsHBITMAP”. “Qt::toMacCGImageRef”) -OR- * QPlatform::toType(“QWindows::toHBITMAP”, QMac::toCGImageRef) Structure: - Filesystem structure: - src/ - examples/ - tests/ - Public header naming: * Cross-platform header: qplatformfoo.h (qmacunifiedtoolbar.h) * Platform-dependent header: qplatformfoo_platform.h (qx11info_x11.h) * Build a .so/dll/dylib/framework: QtMacExtras.framework, QtX11Extras.so * If Qt is built with widgets, then qplatformextras may depend on QtWidgets. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiling with GCC 4.8
On Saturday, February 23, 2013 23:19:33 David Narvaez wrote: On Sat, Feb 23, 2013 at 12:29 PM, Thiago Macieira thiago.macie...@intel.com wrote: I haven't seen any patches fixing warnings or compilation errors come in for 4.8. Usually, there are a few warnings that need fixing but until my -Werror patches land, those are not stoppers. Usually, there are no compilation errors. No one has reported anything. Well, I think I got scared with the amount of errors I got from my first try but apparently it is all solved with a rather simple patch I have put on codereview. I added you as a reviewer, if anybody else is interested just let me know. This was pushed to the stable branch, which means that Qt 5.0.2 will not build with GCC 4.8, right? Is that intentional? Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal - QtSerialPort graduation from the Playground
Hi, I just want to drop in with a little thank you and basically to share my thoughts about QtSP. Last week I've built a project using QtSerialPort (with Qt4) to communicate with an Arduino board, and tested it on Linux (Ubuntu and Kubuntu) and Windows (7 and embedded), on numerous PCs (VM, laptop, embedded board, standalone PC). Works like a charm - installation is easy, API very clear, easy to grasp and done in Qt-style, documentation is good (maybe not fully mature, but more or less complete) and in general it just works. Good job, people, congratulations! I'm happy to see this becoming part of Qt. Cheers, sierdzio ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Hello, Don't forget about the documentation. Some links: http://qt-project.org/wiki/Category:Developing_Qt::Documentation http://qt-project.org/wiki/Qt5DocumentationProject Cheers, Jerome P. Documentation Engineer - Digia, Qt Fra: development-bounces+jerome.pasion=digia@qt-project.org [development-bounces+jerome.pasion=digia@qt-project.org] p#229; vegne av Sorvig Morten [morten.sor...@digia.com] Sendt: 25. februar 2013 09:35 To: development@qt-project.org Emne: [Development] Qt Platform Extras Hi, Getting ready for the 5.1 feature freeze, I think we should take some time unifying the structure and API of the platform extras modules. There has already been some private discussion on this topic, and this is an attempt at reaching a final consensus. I think it's important that these modules are as similar as possible. API: - Some classes and functions are named for Qt 4 compatbilty. These need to stay as is. * qt_mac_set_dock_menu(QMenu *) - Classes: QPlatformFoo (QMacNativeWidget, QX11Info) - Stand-alone function namespace: * Qt::toPlatformType (“Qt::toWindowsHBITMAP”. “Qt::toMacCGImageRef”) -OR- * QPlatform::toType(“QWindows::toHBITMAP”, QMac::toCGImageRef) Structure: - Filesystem structure: - src/ - examples/ - tests/ - Public header naming: * Cross-platform header: qplatformfoo.h (qmacunifiedtoolbar.h) * Platform-dependent header: qplatformfoo_platform.h (qx11info_x11.h) * Build a .so/dll/dylib/framework: QtMacExtras.framework, QtX11Extras.so * If Qt is built with widgets, then qplatformextras may depend on QtWidgets. Morten ___ 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] Qt Platform Extras
On 25/02/2013 09:35, Sorvig Morten wrote: - Stand-alone function namespace: * Qt::toPlatformType (“Qt::toWindowsHBITMAP”. “Qt::toMacCGImageRef”) -OR- * QPlatform::toType(“QWindows::toHBITMAP”, QMac::toCGImageRef) I vote for the latter naming scheme. We should not simulate namespaces by cluttering the function names. Looking at the Windows example, it might be wise to call the platform namespaces QtPlatform, not QPlatform to make the namespace QtWindows and the class QWindow easier distinguishable. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
Hi, On Wednesday 13 February 2013 09:49:56 Knoll Lars wrote: Hi everybody, I would like to start the feature freeze Qt 5.1 middle of March. This is a bit later then I originally proposed in December. There's two reasons for this. First of all it'll reduce some of the integration pressure for the Android ports as well as the Qt Quick Controls. Secondly, the release team will be busy to get 5.0.2 out by by that time and won't have time to focus on the 5.1 branch before middle of March. The freeze will be done by merging dev back into stable, and then working mainly on stable for a while to get a 5.1 beta and then 5.1.0 out. The beta should happen as soon as possible after the feature freeze, and I'd like to aim for 5.1.0 final by end of April. Quite a bit of new functionality has made it into the dev branch, but I'd also like to add a few of the modules left out in 5.0 to the release. The candidates I can see so far are: * Qt X11 Extras * Qt Mac Extras * Qt Sensors * Qt Serial Port * Qt Quick Controls (formerly known as desktop components) Great to see QtSensors back in. I am about to create a patch to include it in qt5.git. What else needs to be done so that its documentation shows up in http://doc-snapshot.qt-project.org/? Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Review of wip/android multimedia plugin
The multimedia plugin for android is now getting into usable state, and before we start looking at the possibility of merging into dev, we would like to get some feedback on the code. If you feel up for it, please take a look at the squashed commit on Gerrit. https://codereview.qt-project.org/#change,48909 -- Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
I'd prefer Qt namespace with no platform indicators, i.e.: Qt::toHICON Qt::toHBITMAP Qt::toCGImageRef Qt::toNSString It's obvious to which platform each function belongs; there's no need to qualify it beyond necessary. If WinRT introduces an NSString class and OS X adds HBITMAPs only then should we think about adding the platform name to the function. :) Also, despite that qt_mac_set_dock_menu is around for backwards compatibility, how about we introduce a second name for it, like Qt::setDockMenu and deprecate the original or otherwise advise against its usage? Then we can both maintain compatibility and not force usage of a disgustingly named function. Jake Petroules Petroules Corporation (www.petroules.com) Email: jake.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Feb 25, 2013, at 6:03 AM, Joerg Bornemann joerg.bornem...@digia.com wrote: On 25/02/2013 09:35, Sorvig Morten wrote: - Stand-alone function namespace: * Qt::toPlatformType (“Qt::toWindowsHBITMAP”. “Qt::toMacCGImageRef”) -OR- * QPlatform::toType(“QWindows::toHBITMAP”, QMac::toCGImageRef) I vote for the latter naming scheme. We should not simulate namespaces by cluttering the function names. Looking at the Windows example, it might be wise to call the platform namespaces QtPlatform, not QPlatform to make the namespace QtWindows and the class QWindow easier distinguishable. BR, Joerg ___ 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] Evolving Qt's multithreading API
On segunda-feira, 25 de fevereiro de 2013 20.36.24, Sze Howe Koh wrote: Thank you for the comprehensive explanation. I know little about Qt's internal mechanisms, so I'm curious now. Could the guarantee also be provided by posting QThread::start() into the event loop during setup? QMetaObject::invokeMethod(thread, start, Qt::QueuedConnection) Yes, that guarantee could be done like that, but that also implies delaying the start. I'd rather start immediately, potentially allow it to finish immediately, but delay *just* the notification. If so, what's the cost of having two QObjects (trampoline object and returned object), and how does it compare to the cost of deferring the start until the next event loop iteration? It's comparing apples to oranges. One delays the start of the work, so the expense is measured in time, plus a bit of complexity of code to make it start if waitForFinished() is somehow called. The other expense is measured in memory. In my mind, the costs of 3 different approaches to starting this new method are: - Trampoline object: 2 QObjects, delay of 0 loop iterations, 0 extra LOC for user - Queued auto-start: 1 QObject, delay of 1 loop iteration, 0 extra LOC for user - Manual start: 1 QObject, delay of 0 loop iterations, 1 extra LOC for user Which costs the least? How do the optimizations to the trampoline change things? Now you're mixing things. First we choose the API: does it start automatically or not? After we've done that, we choose how to implement it and that is an implementation detail. QThread signals the status of the thread, but QFutureWatcher signals the status of the future, the task. The thread itself may not have finished. What I'm saying is that you should not return a QThread, but something else. And then you can connect QThread's finished() signal to that something else's finished(). As I described above, that alone will be enough to guarantee the right semantics. Then, should we put this new function outside the QThread class? The task-management interface feels like it abstracts away the underlying QThread, so it would be messy to mix the API. We could do that, but I think that putting it in QThread also makes sense because that's where people will go to look for it. If this method is restricted to a run-replacement -- a static method that takes a lambda -- then it should be in QThread and it should return a QThread*. It should not be more complex than that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiling with GCC 4.8
On segunda-feira, 25 de fevereiro de 2013 11.31.01, Stephen Kelly wrote: On Saturday, February 23, 2013 23:19:33 David Narvaez wrote: On Sat, Feb 23, 2013 at 12:29 PM, Thiago Macieira thiago.macie...@intel.com wrote: I haven't seen any patches fixing warnings or compilation errors come in for 4.8. Usually, there are a few warnings that need fixing but until my -Werror patches land, those are not stoppers. Usually, there are no compilation errors. No one has reported anything. Well, I think I got scared with the amount of errors I got from my first try but apparently it is all solved with a rather simple patch I have put on codereview. I added you as a reviewer, if anybody else is interested just let me know. This was pushed to the stable branch, which means that Qt 5.0.2 will not build with GCC 4.8, right? Is that intentional? It was a matter of timing. Since GCC 4.8 is not released yet, I can't make the case for it being a P1. If there's a 5.0.3, the fix will be in it. Otherwise, it will be in 5.1.0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compiling with GCC 4.8
On Monday, February 25, 2013 08:07:48 Thiago Macieira wrote: It was a matter of timing. Since GCC 4.8 is not released yet, I can't make the case for it being a P1. I fully disagree with that :). I think compile fixes for compilers that are not released yet qualify. But what's done is done, and you can disagree with what I think too. Thanks, -- Stephen Kelly stephen.ke...@kdab.com | Software Engineer KDAB (Deutschland) GmbH Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.1 feature set and freeze date
Hello, The main requirements are: -the docs are modularized and conform to the Qt 5 documentation structure: http://qt-project.org/wiki/Qt5DocumentationProject -the docs compile readily using make docs I only listed modules that have an official stable (or master) branch. The Qt Quick Controls will be listed once we get notification. It would be helpful if Qt Sensors are in qt5.git as well. Let me know if you have other questions. See https://codereview.qt-project.org/#change,48902 for an example of how the pages might be set up. Cheers, Jerome P. Documentation Engineer - Digia, Qt Fra: development-bounces+jerome.pasion=digia@qt-project.org [development-bounces+jerome.pasion=digia@qt-project.org] p#229; vegne av Thomas McGuire [thomas.mcgu...@kdab.com] Sendt: 25. februar 2013 14:17 To: development@qt-project.org Emne: Re: [Development] Qt 5.1 feature set and freeze date Hi, On Wednesday 13 February 2013 09:49:56 Knoll Lars wrote: Hi everybody, I would like to start the feature freeze Qt 5.1 middle of March. This is a bit later then I originally proposed in December. There's two reasons for this. First of all it'll reduce some of the integration pressure for the Android ports as well as the Qt Quick Controls. Secondly, the release team will be busy to get 5.0.2 out by by that time and won't have time to focus on the 5.1 branch before middle of March. The freeze will be done by merging dev back into stable, and then working mainly on stable for a while to get a 5.1 beta and then 5.1.0 out. The beta should happen as soon as possible after the feature freeze, and I'd like to aim for 5.1.0 final by end of April. Quite a bit of new functionality has made it into the dev branch, but I'd also like to add a few of the modules left out in 5.0 to the release. The candidates I can see so far are: * Qt X11 Extras * Qt Mac Extras * Qt Sensors * Qt Serial Port * Qt Quick Controls (formerly known as desktop components) Great to see QtSensors back in. I am about to create a patch to include it in qt5.git. What else needs to be done so that its documentation shows up in http://doc-snapshot.qt-project.org/? Regards, Thomas -- Thomas McGuire | thomas.mcgu...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Why is that...? Jake Petroules Petroules Corporation (www.petroules.com) Email: jake.petrou...@petroules.com Telephone: +1 (970) 587-3821 On Feb 25, 2013, at 11:12 AM, Joerg Bornemann joerg.bornem...@digia.com wrote: On 25/02/2013 16:27, Jake Thomas Petroules wrote: I'd prefer Qt namespace with no platform indicators, i.e.: Qt::toHICON Qt::toHBITMAP Qt::toCGImageRef Qt::toNSString It's obvious to which platform each function belongs; there's no need to qualify it beyond necessary. If WinRT introduces an NSString class and OS X adds HBITMAPs only then should we think about adding the platform name to the function. :) That means we're restricting ourselves to type conversion functions? A function that's potentially useful on more than one platform wouldn't be possible. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Monday, February 25, 2013 05:12:48 PM Joerg Bornemann wrote: On 25/02/2013 16:27, Jake Thomas Petroules wrote: I'd prefer Qt namespace with no platform indicators, i.e.: Qt::toHICON Qt::toHBITMAP Qt::toCGImageRef Qt::toNSString It's obvious to which platform each function belongs; there's no need to qualify it beyond necessary. If WinRT introduces an NSString class and OS X adds HBITMAPs only then should we think about adding the platform name to the function. :) That means we're restricting ourselves to type conversion functions? A function that's potentially useful on more than one platform wouldn't be possible. Why would a function that is potentially useful on more than one platform go to platform extras? Sascha ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On 25/02/2013 17:25, Sascha Cunz wrote: Why would a function that is potentially useful on more than one platform go to platform extras? Because it's working on native types (more than just one) and encoding all type names into the function name would be strange. The same function name could make sense on a different platform. Note that I'm talking about the function name, not the full signature. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Installation and compilation Qt Linux embedded
Hi everyone I have followed instructions from QT webpage, but I have many problems to cross-compile an example (plugandpaint) I installed Qt embedded 4.8 without demos and examples succesfully. Now I'm trying to compile plugins to use with plugandpaint application (plugandpaintplugins). Steps followed are: (I have to execute ./configure from source directory: /home/juanpablo/Qt/qt-everywhere-opensource-src-4.8.4. Qt installation is in /usr/local/Qt_dinamicas). $PATH contains /usr/local/Qt_dinamicas/bin ./configure -xplatform qws/arm-linux-gnueabi-g++ -embedded arm nomake-examples...etc qmake-project qmake make The result is: root@ubuntu:/home/juanpablo/Qt/qt-everywhere-opensource-src-4.8.4/examples/tools/plugandpaintplugins# make g++ -c -pipe -O2 -Wall -W -D_REENTRANT -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/local/Qt_dinamicas/mkspecs /qws/linux-x86-g++ -I. -I/usr/local/Qt_dinamicas/include/QtCore -I/usr/local/Qt_dinamicas/include/QtNetwork -I/usr/local/Qt_dinamicas/include/QtGui -I/usr/local/Qt_dinamicas/include -I. -Ibasictools -Iextrafilters -I. -o basictoolsplugin.o basictools/basictoolsplugin.cpp In file included from basictools/basictoolsplugin.cpp:46:0: basictools/basictoolsplugin.h:51:37: fatal error: plugandpaint/interfaces.h: No such file or directory compilation terminated. make: *** [basictoolsplugin.o] Error 1 My question: (see red text) -Why does the compilation use /qws/linux-x86-g++ instead of qws/arm-linux-gnueabi-g++? Juan Pablo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
On Monday, February 25, 2013 05:50:06 PM Joerg Bornemann wrote: On 25/02/2013 17:25, Sascha Cunz wrote: Why would a function that is potentially useful on more than one platform go to platform extras? Because it's working on native types (more than just one) and encoding all type names into the function name would be strange. The same function name could make sense on a different platform. Note that I'm talking about the function name, not the full signature. Actually, i don't get this: If there is some feature that is reasonable to have on more than one platform, then Qt should probably abstract it with a Qt-ish API, right? That's at least how things worked for ages. In terms of Qt 5, this would probably result in an add on QtFooFeature, which is tagged as available for the platforms it works upon. If on the other hand there's a complex feature that is bound to one platform and it is not yet covered by a add on on it's own, this feature should be properly abstracted into a Qt-ish Api, too, right? Properly abstracted here refers to a class inside the add on's namespace. As far as i can see, this leaves two kinds of functions that could possibly become members of the Qt- or the addon's namespace: - Functions that extent the API of an already abstracted feature (i.e. QString or QImage) with platform specific code. These would provide platform specific additions to the feature itself. If there is one of them, they could as well go to a namespace; If it is foreseeable that their number will increase by time, they should probably go into a class; c.f. qt4's qt_mac_XXX stuff for unified toolbar support. - Functions that convert Qt objects into their native pendant. These don't introduce new features themselves. They just provide compatibility to additional features of the native platform. These usually don't overlap in signature. Sascha ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] GSoC 2013
On segunda-feira, 25 de fevereiro de 2013 19.14.16, Lydia Pintscher wrote: On Mon, Feb 25, 2013 at 6:13 PM, Mathieu STEFANI mathieu.stef...@supinfo.com wrote: Any update on this ? I think that Qt Project would greatly benefit from such a program that GSoC represents. Let's deal with legal issues right now and get prepared for project submission. If there's still legal problems KDE might be able to step in. We will apply again this year. I don't see a legal problem for the Qt Project Hosting Foundation. If it's too much work to receive the money for the 2 or 3 students that get selected, we can just tell Google we don't need the $1000 or $1500 and that it can be put to better use by funding someone at the mentor summit. The real question here is if there is anyone with the time required to admin the effort. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] GSoC 2013
On 25 February 2013 20:44, Thiago Macieira thiago.macie...@intel.com wrote: The real question here is if there is anyone with the time required to admin the effort. Is it required for this person to be affiliated with the Qt Project Hosting Foundation somehow or could this be administred by KDE people as well? Cheers, -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] GSoC 2013
Lähettäjä: development-bounces+tuukka.turunen=digia@qt-project.org [development- bounces+tuukka.turunen=digia@qt-project.org] k#228;ytt#228;j#228;n Giuseppe D'Angelo [dange...@gmail.com] puolesta Lähetetty: 25. helmikuuta 2013 21:48 Vastaanottaja: Thiago Macieira Cc: development@qt-project.org Aihe: Re: [Development] GSoC 2013 On 25 February 2013 20:44, Thiago Macieira thiago.macie...@intel.com wrote: The real question here is if there is anyone with the time required to admin the effort. Is it required for this person to be affiliated with the Qt Project Hosting Foundation somehow or could this be administred by KDE people as well? Quickly reading through the agreement and terms for mentoring organizations I can easily understand why Nokia has not been eager to participate. The idea is good, but naturally Google has to cover a lot of angles in order to run this kind of a program. That said it might be feasible to sign in as Qt Project through the foundation provided that we have solid projects to work on and good mentors from the community. But for sure it is not easy money - it takes a lot of work just to do all the paperwork and financials properly. Yours, Tuukka ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Platform Extras
Hi Sascha, My point is that we cannot know whether we'll have to encode the platform in a function name again in the future, in which case we'll have functions with and without the platform in their name. Your point is that this won't ever happen. We can just avoid this risk of an inconsistent future API by using different namespaces. BR, Joerg ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
