[Development] iOS with current 5.4 git
Gentlemen, With 5.4 taken yesterday (and all recent commits are seen in log), somehow QTBUG-39981 issues are still inside, updated, and QTBUG-41275 was reopened. Thanks. Robert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Oct 10, 2014, at 8:16 PM, Adam Light acli...@gmail.com wrote: On Fri, Oct 10, 2014 at 7:25 AM, Ziller Eike eike.zil...@theqtcompany.com wrote: On Oct 10, 2014, at 3:37 PM, Adam Light acli...@gmail.com wrote: On the flip side, our large Qt application runs on Mac and Windows and we're intentionally using QSettings with INI format on both platforms for consistency. Since the storage of settings is really an implementation detail (users should hopefully never need to edit the settings files themselves), it's easier for us if the settings are stored the same way on all platforms. Qt Creator intentionally used ini format for “consistency” as well, but: * Since the paths are different through the platforms (Windows XP vs Windows vs Linux vs OS X), and have to be, there is not much consistency in the end after all, and * Uninstallation process involves manually removing settings and application data, at least on OS X, and there are even uninstallation tools out there which do it for you, if the application follows the platform convention So there are IMO very good reasons why someone would want their application to follow platform conventions for application settings. Possibly with a way to opt-in or opt-out. Sure, I understand why a developer might want an application to be able to follow platform conventions. I'm just making the case that I think there are valid reasons to *not* follow platform conventions as well. Currently QSettings makes it relatively easy for the developer to decide. But if this new class is eventually going to replace QSettings, I feel that the option should remain for the developer to force the settings to be saved in a consistent way across platforms, not always using the platform convention. Otherwise it's a loss of functionality. Then we agree ;) -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On 10 Oct 2014, at 13:27, Ziller Eike eike.zil...@theqtcompany.com wrote: On Oct 10, 2014, at 11:48 AM, Morten Johan Sørvig morten.sor...@digia.com wrote: Mac people: do we need access to plist files? Plist is the format for application and other settings on OS X, and there are native tools for nicely editing these. Ini is highly alien on OS X. So, I’d answer yes. On the other hand, git uses the ini file format for the config files also on OS X. git is a command line tool, and used by a very specific audience. I see this as two separate use cases: 1) Cross-platform API for managing application settings. We regularly have people which complain that Qt Creator application settings do not follow platform convention on OS X, because they do not find a qt creator plist in ~/Library/Preferences, or actually there is one that contains some settings coming from Qt (NSNavLastRootDirectory, PMPrintingExpandedState, some WebKit stuff, and a few more), but not the actual application settings. 2) API for reading native settings, following the conventions of the platform What kind of native settings are you thinking about here (on OS X)? If I may re-state my point it is that OS X settings is more than the Plist file format: NSUserDefaults has special behaviors for sandboxing, iCloud sync, the iOS Settings app, etc. Perhaps the best way to use NSUserDefaults from a Qt app is QUrl::toNSURL() and QString::toNSString() (i.e. enable it don’t wrap it). In that light supporting ini+json only is a project with a well-defined small scope. Creating a class that wraps the native settings is a much larger project. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt3D on windows
Hey Gunnar, On 13/10/2014 06:48, Gunnar Sletta wrote: On 12 Oct 2014, at 22:18, Sean Harmer sean.har...@kdab.com wrote: On 12/10/2014 21:08, Ray Donnelly wrote: On Sun, Oct 12, 2014 at 8:56 PM, Sean Harmer sean.har...@kdab.com wrote: Hi, just a quick heads up that Qt3D's wip/newapi branch now displays content usign threaded rendering on windows. I've tested with MSVC 2012 OpenGL x86_64 build with nVidia driver. Your mileage may vary with other drivers, compilers and OpenGL configurations. I wouldn't be surprised to find a few places need tweaks with a dynamic OpenGL build. Angle doesn't do multithreaded rendering, will it be possible to use Qt3D on Angle? Well, we're only doing actual GL calls on a single thread, it just happens that it's not the main thread. Does that include the QOpenGLContext creation? We've thus far required that QOpenGLContext gets created on the GUI thread and then moved to the rendering thread. Yes, this includes creating the context on a non-GUI thread. Before tackling this in Qt3D I made a simple QtGui + OpenGL example that loops a number of times and in each loop creates a QWindow (on the GUI thread) and spawns a QThread subclass which creates a QOpenGLContext and then renders with it. Without any synchronisation I was getting strange crashes inside the QPA which iirc may be related to the use of the static context inside the QPA. However, as long as I serialise the QWindow::create() and the QOpenGLContext::create() calls between the two threads it works perfectly having the GL context created on a non-gui thread. I'll see if this is also the case on other platforms (i.e. if it's a limitation of the windows QPA). From the MSDN docs and reading around it looks like it should be fine to create hDCs on additional threads as long as each hDC is only used on one thread at a time. The window hWND has affinity with the creating thread which must be the GUI thread in Qt. I'll see about extracting the example I was using and adding it to QtGui. Cheers, Sean cheers, Gunnar If ANGLE supports that then yes, we have an ES 2 backend that can be used. If not we'll need to try to come up with an alternative solution but to be honest we have enough variations dealing with real OpenGL implementations so we shall see how much of a time sink it becomes. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ 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 -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt3D on windows
Hi Sean, What Gunnar refers to is a pattern we use in a few places to get things functioning correctly with certain embedded GLES implementations. With such drivers, creating sharing contexts on different threads behaves incorrectly as you won't actually get sharing. The workaround was to create all contexts on the main/gui thread. This may not be relevant to you in Qt3D, but good to keep it in mind. Cheers, Laszlo From: development-bounces+laszlo.agocs=theqtcompany@qt-project.org development-bounces+laszlo.agocs=theqtcompany@qt-project.org on behalf of Sean Harmer sean.har...@kdab.com Sent: Monday, October 13, 2014 10:47 AM To: development@qt-project.org Subject: Re: [Development] Qt3D on windows Hey Gunnar, On 13/10/2014 06:48, Gunnar Sletta wrote: On 12 Oct 2014, at 22:18, Sean Harmer sean.har...@kdab.com wrote: On 12/10/2014 21:08, Ray Donnelly wrote: On Sun, Oct 12, 2014 at 8:56 PM, Sean Harmer sean.har...@kdab.com wrote: Hi, just a quick heads up that Qt3D's wip/newapi branch now displays content usign threaded rendering on windows. I've tested with MSVC 2012 OpenGL x86_64 build with nVidia driver. Your mileage may vary with other drivers, compilers and OpenGL configurations. I wouldn't be surprised to find a few places need tweaks with a dynamic OpenGL build. Angle doesn't do multithreaded rendering, will it be possible to use Qt3D on Angle? Well, we're only doing actual GL calls on a single thread, it just happens that it's not the main thread. Does that include the QOpenGLContext creation? We've thus far required that QOpenGLContext gets created on the GUI thread and then moved to the rendering thread. Yes, this includes creating the context on a non-GUI thread. Before tackling this in Qt3D I made a simple QtGui + OpenGL example that loops a number of times and in each loop creates a QWindow (on the GUI thread) and spawns a QThread subclass which creates a QOpenGLContext and then renders with it. Without any synchronisation I was getting strange crashes inside the QPA which iirc may be related to the use of the static context inside the QPA. However, as long as I serialise the QWindow::create() and the QOpenGLContext::create() calls between the two threads it works perfectly having the GL context created on a non-gui thread. I'll see if this is also the case on other platforms (i.e. if it's a limitation of the windows QPA). From the MSDN docs and reading around it looks like it should be fine to create hDCs on additional threads as long as each hDC is only used on one thread at a time. The window hWND has affinity with the creating thread which must be the GUI thread in Qt. I'll see about extracting the example I was using and adding it to QtGui. Cheers, Sean cheers, Gunnar If ANGLE supports that then yes, we have an ES 2 backend that can be used. If not we'll need to try to come up with an alternative solution but to be honest we have enough variations dealing with real OpenGL implementations so we shall see how much of a time sink it becomes. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ 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 -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ 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] Qt3D on windows
On 13/10/2014 10:27, Agocs Laszlo wrote: Hi Sean, What Gunnar refers to is a pattern we use in a few places to get things functioning correctly with certain embedded GLES implementations. With such drivers, creating sharing contexts on different threads behaves incorrectly as you won't actually get sharing. The workaround was to create all contexts on the main/gui thread. This may not be relevant to you in Qt3D, but good to keep it in mind. Ah right I see now. Thanks for the explanation. Right now, this isn't an issue as we're not sharing contexts but we'll bear it in mind for the future. Cheers, Sean Cheers, Laszlo From: development-bounces+laszlo.agocs=theqtcompany@qt-project.org development-bounces+laszlo.agocs=theqtcompany@qt-project.org on behalf of Sean Harmer sean.har...@kdab.com Sent: Monday, October 13, 2014 10:47 AM To: development@qt-project.org Subject: Re: [Development] Qt3D on windows Hey Gunnar, On 13/10/2014 06:48, Gunnar Sletta wrote: On 12 Oct 2014, at 22:18, Sean Harmer sean.har...@kdab.com wrote: On 12/10/2014 21:08, Ray Donnelly wrote: On Sun, Oct 12, 2014 at 8:56 PM, Sean Harmer sean.har...@kdab.com wrote: Hi, just a quick heads up that Qt3D's wip/newapi branch now displays content usign threaded rendering on windows. I've tested with MSVC 2012 OpenGL x86_64 build with nVidia driver. Your mileage may vary with other drivers, compilers and OpenGL configurations. I wouldn't be surprised to find a few places need tweaks with a dynamic OpenGL build. Angle doesn't do multithreaded rendering, will it be possible to use Qt3D on Angle? Well, we're only doing actual GL calls on a single thread, it just happens that it's not the main thread. Does that include the QOpenGLContext creation? We've thus far required that QOpenGLContext gets created on the GUI thread and then moved to the rendering thread. Yes, this includes creating the context on a non-GUI thread. Before tackling this in Qt3D I made a simple QtGui + OpenGL example that loops a number of times and in each loop creates a QWindow (on the GUI thread) and spawns a QThread subclass which creates a QOpenGLContext and then renders with it. Without any synchronisation I was getting strange crashes inside the QPA which iirc may be related to the use of the static context inside the QPA. However, as long as I serialise the QWindow::create() and the QOpenGLContext::create() calls between the two threads it works perfectly having the GL context created on a non-gui thread. I'll see if this is also the case on other platforms (i.e. if it's a limitation of the windows QPA). From the MSDN docs and reading around it looks like it should be fine to create hDCs on additional threads as long as each hDC is only used on one thread at a time. The window hWND has affinity with the creating thread which must be the GUI thread in Qt. I'll see about extracting the example I was using and adding it to QtGui. Cheers, Sean cheers, Gunnar If ANGLE supports that then yes, we have an ES 2 backend that can be used. If not we'll need to try to come up with an alternative solution but to be honest we have enough variations dealing with real OpenGL implementations so we shall see how much of a time sink it becomes. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ 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 -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ 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 -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Optional Dependencies and Distribution of Examples
Hey all, I have a question regarding the handling of optional dependencies, and how that influences the distribution of Qt code, esp. the creation of tarballs and binaries. Qt WebChannel uses Qt WebSockets for its examples, and that optionally and only there. The rest of the code works fine without websockets, to ensure that e.g. Qt WebKit or Qt WebEngine don't drag in Qt WebSockets as a dependency via the WebChannel. So far so good. But when qt5.git builds WebChannel without WebSockets available, the examples wont be build. What implications does this have? a) No CI coverage of whether the examples build on all platforms? b) What about packaging? Will the examples still be included in the Qt source tarballs? Will binary builds of Qt include the examples? c) more...? What should we do about this situation? Bye -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | milian.wo...@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
[Development] Qt3D Examples
Hi, somewhat of a meta question around Milian's recent email. Qt3D is obviously going to need a lot of examples to show how to implement various techniques and methods. 3D work in general is notorious of requiring fairly large assets to make interesting and visually pleasing examples e.g. textures (diffuse, specular, bump, alpha, etc) and meshes being the most common. Rather than clogging up the main Qt3D git repo with these, do you think that we should have a separate repo for the Qt3D examples and their assets? Is there a precedent for this or any other options? Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt3D Examples
On Monday 13. October 2014 11.49.01 Sean Harmer wrote: Hi, somewhat of a meta question around Milian's recent email. Qt3D is obviously going to need a lot of examples to show how to implement various techniques and methods. 3D work in general is notorious of requiring fairly large assets to make interesting and visually pleasing examples e.g. textures (diffuse, specular, bump, alpha, etc) and meshes being the most common. Rather than clogging up the main Qt3D git repo with these, do you think that we should have a separate repo for the Qt3D examples and their assets? Is there a precedent for this or any other options? I don't have an authoritative answer, but one possible option would be an sub-module that contains the assets for examples or (easier?) separate the Qt 3d examples and their assets into a standalone git repository. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Some more maintainer nominations
Hi, I’d like to nominate a few more maintainers. Most of the below should be simply about making the de-facto status official, ie. Putting the person that does most of the work on the module in charge. Qt WebChannel: Milian Wolff Qt Canvas 3D: Pasi Keranen Direct2D platform plugin: Louai Al-Khanji Eglfs linuxfb plugins: Lazlo Agocs Qt WebView: Christian Strømme qdoc: Martin Smith ActiveQt: Friedemann Kleint Qt Image Formats: Eirik Aavitsland Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt3D Examples
On 13. okt. 2014 13:13, Simon Hausmann wrote: On Monday 13. October 2014 11.49.01 Sean Harmer wrote: Hi, somewhat of a meta question around Milian's recent email. Qt3D is obviously going to need a lot of examples to show how to implement various techniques and methods. 3D work in general is notorious of requiring fairly large assets to make interesting and visually pleasing examples e.g. textures (diffuse, specular, bump, alpha, etc) and meshes being the most common. Rather than clogging up the main Qt3D git repo with these, do you think that we should have a separate repo for the Qt3D examples and their assets? Is there a precedent for this or any other options? I don't have an authoritative answer, but one possible option would be an sub-module that contains the assets for examples or (easier?) separate the Qt 3d examples and their assets into a standalone git repository. I support this. Having large Qt3D examples in a submodule seems like a good solution. However, I would still like smaller examples that are easy to run and test to be available in the default git repository (and binary installations). Such as simple lighting, camera handling, animation, etc. This will make it easier for newcomers to test Qt3D without having to download the huge asset repository. Best regards, Svenn-Arne Dragly ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some more maintainer nominations
On 13/10/2014 12:36, Knoll Lars wrote: Hi, I’d like to nominate a few more maintainers. Most of the below should be simply about making the de-facto status official, ie. Putting the person that does most of the work on the module in charge. Qt WebChannel: Milian Wolff Qt Canvas 3D: Pasi Keranen Direct2D platform plugin: Louai Al-Khanji Eglfs linuxfb plugins: Lazlo Agocs All +1 from me. Qt WebView: Christian Strømme I don't have enough insight. qdoc: Martin Smith ActiveQt: Friedemann Kleint Also both +1. Qt Image Formats: Eirik Aavitsland Not enough insight but I'm sure others do have. Cheers, Sean Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
Milian Wolff schreef op 11-10-2014 16:44: On Friday 10 October 2014 21:26:11 Tomaz Canabrava wrote: On Fri, Oct 10, 2014 at 6:35 AM, Milian Wolff milian.wo...@kdab.com wrote: On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote: Em 10/10/2014 06:18, Oswald Buddenhagen oswald.buddenha...@theqtcompany.com escreveu: On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote: may I ask why you don't simply copy KConfig? It's API design has proven to be extremely versatile and efficient over the years. actually, it has proven horrible and is slated for a rewrite for a decade. the only thing it does right is what tomaz copied to his api. (still sleeping, só I will write better latter) I used kconfig and I tougth it was terrible to use, that why I came to thiago and hélio Castro asking if I could try a new one. I'll read the emails on this thread and change the code accordingly. Please double-check the KConfig API and copy more of its behavior. Some of that stuff was also mentioned by Thiago, Bo and Kai: QConfig(identifier_or_filename); // this should also be the root group config.setValue(bla, 123); // would set a global config value, with multiple overloads or template functions QConfigGroup group = config.group(something); // smart handle with reference semantics group.readValue(blub, /* default value */); // read value in group, also overloads and/or template function foreach (QConfigGroup subGroup, group.groups()) // or similar qDebug() subGroup.name(); I still think that KConfig, API-wise, is extremely convenient and haven't seen anything better so far. The internals and performance is a bit lacking, but usually not a problem and definitely not related to the API. It's too error prone regarding typos. // main.cpp KConfig c; KConfigGroup g = c.group(blah); g.setValue(width, 10); // otherfile Kconfig c; KConfigGroup g = c.group(blah); g.value(widht); // - no error is issued, this is something that I wanna have it fixed. How do you intend to fix it? Esp. when looking at what Rafael proposes? If you declare any other class to be used instead of a string, the user can still mix two variables up. I don't see what that has to do with KConfig/QConfig, really. Bye We're moving away from using these keys directly at all. Instead, we only use a real, type safe interface anymore for settings. That is: every setting gets a real getter and setter in a Settings class. That class is responsible for storing and retreiving the setting from the backend (which, in our case, has several levels now). If needed, there is not only a getter and a setter, but also a corresponding changed signal, but that changed signal currently only works if the setting is changed from inside the application itself (good enough for us). Personally, I think that using string-based key-value pairs (whether the key has grouped semantics or not) and then manually casting the value to the needed everywhere you need it simply has no place in application code in all but the simplist applications. API's need to be type-safe if at all possible, and if not, the exposure to the non-type safe API should be kept to a minimum. Further more: default values need to be consistent. Allowing the application to access the backend from more than one place, also means having the specify the default value for settings in more than one place. That *will* lead to inconsistencies. In our case, that means that there is only one class where there is exposure to the non-type safe QVariant-based API of Qt, and that is the settings class itself. The rest of the application has no clue, nor needs to have any clue, on how the settings are stored: they are just using type-safe properties with clearly defined default values. I would like to see some (modular) kConfig XT-like settings specification that results in type save code within Qt though. Preferably with a nice editor-plugin inside Creator. Or, perhaps based on the Q_PROPERTIES or something similar allowing you to use a default getter/setter implementation for simple cases, and add your own for more complex ones. That would already save a lot of boilerplate code. I don't believe in auto-generating configuration dialogs, though a tree representation would be useful for advanced editing and developer settings. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
Thiago Macieira schreef op 11-10-2014 10:25: On Friday 10 October 2014 21:27:58 Tomaz Canabrava wrote: I tougth about having a changed() signal on the QConfig / QConfigGroup classes, is the QConfigWatcher a better approach? Put it in a separate class. QConfig (Group) should not be a QObject. Why not? André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt List Items in 5.3
Den 13-10-2014 00:44, Lee Powell skrev: I know all you folks are busy as this is probably not a high community request, but if you would consider adding dashes and stars to list items at the very least that would be awesome. We'd be happy to implement first and raise a merge request with the qt repository for the text based bullet styles if Digia debs were not able to add the dash and star decorations. Please let me know your preference. Sounds like this is a low risk feature. But since no one else have requested it for the many years those classes have been used, it's also a low gain feature. I suggest you try and create as small a patch as possible and do a merge request for it. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Monday 13 October 2014 13:46:21 André Somers wrote: Personally, I think that using string-based key-value pairs (whether the key has grouped semantics or not) and then manually casting the value to the needed everywhere you need it simply has no place in application code in all but the simplist applications. API's need to be type-safe if at all possible, and if not, the exposure to the non-type safe API should be kept to a minimum. Further more: default values need to be consistent. Allowing the application to access the backend from more than one place, also means having the specify the default value for settings in more than one place. That *will* lead to inconsistencies. In our case, that means that there is only one class where there is exposure to the non-type safe QVariant-based API of Qt, and that is the settings class itself. The rest of the application has no clue, nor needs to have any clue, on how the settings are stored: they are just using type-safe properties with clearly defined default values. I agree that we should have a code generator on top of a schema, so we have the defaults, types and key names centralised in one place. However, all of that builds on top of a central string-based API, which is required. The schema and code generator can come later. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Monday 13 October 2014 13:47:44 André Somers wrote: Thiago Macieira schreef op 11-10-2014 10:25: On Friday 10 October 2014 21:27:58 Tomaz Canabrava wrote: I tougth about having a changed() signal on the QConfig / QConfigGroup classes, is the QConfigWatcher a better approach? Put it in a separate class. QConfig (Group) should not be a QObject. Why not? QConfigGroup definitely cannot be a QObject. QObjects can't be copied, so we can't do the value semantics we asked for. Those are conflicting design principles. Make it like the QDBusPendingReply + QDBusPendingCallWatcher or QFuture + QFutureWatcher pairs. We have the precedent there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some more maintainer nominations
On Monday 13 October 2014 11:36:43 Knoll Lars wrote: Hi, I’d like to nominate a few more maintainers. Most of the below should be simply about making the de-facto status official, ie. Putting the person that does most of the work on the module in charge. Hi Lars all The nomination of Giulio Camuffo for Qt Wayland maintainer still requires another +1 from a Maintainer for confirmation. Qt WebChannel: Milian Wolff +1 Eglfs linuxfb plugins: Lazlo Agocs +1 qdoc: Martin Smith +1 ActiveQt: Friedemann Kleint +1 (Sorry, Friedemann...) Qt Image Formats: Eirik Aavitsland +1 The other ones I'm not familiar enough to be able to give a +1. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Monday 13 October 2014 14:41:08 Thiago Macieira wrote: On Monday 13 October 2014 13:47:44 André Somers wrote: Thiago Macieira schreef op 11-10-2014 10:25: On Friday 10 October 2014 21:27:58 Tomaz Canabrava wrote: I tougth about having a changed() signal on the QConfig / QConfigGroup classes, is the QConfigWatcher a better approach? Put it in a separate class. QConfig (Group) should not be a QObject. Why not? QConfigGroup definitely cannot be a QObject. QObjects can't be copied, so we can't do the value semantics we asked for. Those are conflicting design principles. Make it like the QDBusPendingReply + QDBusPendingCallWatcher or QFuture + QFutureWatcher pairs. We have the precedent there. Exactly. And also keep the other branch of this thread in mind: QConfig is/should be a low-level fundamental building-block for a high-level settings API. KConfig XT and KConfig have the same/similar connection. The high-level settings API could/should have signals, properties, getters/setters etc. pp. The low-level API is used internally to read/write settings. Bye -- Milian Wolff | milian.wo...@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] Some more maintainer nominations
On 13 Oct 2014, at 14:45, Thiago Macieira thiago.macie...@intel.com wrote: On Monday 13 October 2014 11:36:43 Knoll Lars wrote: Hi, I’d like to nominate a few more maintainers. Most of the below should be simply about making the de-facto status official, ie. Putting the person that does most of the work on the module in charge. Hi Lars all The nomination of Giulio Camuffo for Qt Wayland maintainer still requires another +1 from a Maintainer for confirmation. +1 (if it wasn't recorded already) Eglfs linuxfb plugins: Lazlo Agocs qdoc: Martin Smith ActiveQt: Friedemann Kleint Qt Image Formats: Eirik Aavitsland +1 cheers, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Some more maintainer nominations
On Monday 13. October 2014 11.36.43 Knoll Lars wrote: Qt WebView: Christian Strømme +1 Christian: you need to work on self promotion, obviously :p - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] osx search paths with 5.3.2
Hi all, I've been using qt 4.8.6 for quite some time on my macbook installed from homebrew with no problem whatsoever. I decided over the weekend to upgrade my install to the latest qt5 build which on homebrew is 5.3.2. Everything installed, qmake ran and I was able to successfully build qjsonrpc on my mac. Cool. Now, I've got another test app that links to qjsonrpc, and when I build that it turns out that I'm no longer able to find anything in /usr/include or link to anything in /usr/lib. I naturally assumed this was an issue with the compiler's search paths, but then why did 4.8.6 work? Hmm, okay, let's just use Qt's distributed 5.3.2 binaries, maybe homebrew got it wrong... Same problem. I went through a diff of the mkspecs dirs of both versions and couldn't see anything that would obviously cause this. Has anyone using Qt on mac run into this problem? Running out of ideas here! Cheers, Matt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On Oct 13, 2014, at 10:30 AM, Morten Johan Sørvig morten.sor...@digia.com wrote: On 10 Oct 2014, at 13:27, Ziller Eike eike.zil...@theqtcompany.com wrote: On Oct 10, 2014, at 11:48 AM, Morten Johan Sørvig morten.sor...@digia.com wrote: Mac people: do we need access to plist files? Plist is the format for application and other settings on OS X, and there are native tools for nicely editing these. Ini is highly alien on OS X. So, I’d answer yes. On the other hand, git uses the ini file format for the config files also on OS X. git is a command line tool, and used by a very specific audience. I see this as two separate use cases: 1) Cross-platform API for managing application settings. We regularly have people which complain that Qt Creator application settings do not follow platform convention on OS X, because they do not find a qt creator plist in ~/Library/Preferences, or actually there is one that contains some settings coming from Qt (NSNavLastRootDirectory, PMPrintingExpandedState, some WebKit stuff, and a few more), but not the actual application settings. 2) API for reading native settings, following the conventions of the platform What kind of native settings are you thinking about here (on OS X)? If I may re-state my point it is that OS X settings is more than the Plist file format: NSUserDefaults has special behaviors for sandboxing, iCloud sync, the iOS Settings app, etc. Perhaps the best way to use NSUserDefaults from a Qt app is QUrl::toNSURL() and QString::toNSString() (i.e. enable it don’t wrap it). In that light supporting ini+json only is a project with a well-defined small scope. Creating a class that wraps the native settings is a much larger project. Ok, right, if it is feasible to wrap such native settings” in a cross-platform API at all. So, from my perspective (1) should be able to generate something that users expect from an application they install (on OS X that’s a plist in ~/Library/Preferences), and (2) is nothing we should aim for (at least not at the moment, and since this seems even conceptionally different on different platforms, I’m not sure that at all). Br, Eike -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] osx search paths with 5.3.2
On Oct 13, 2014, at 4:55 PM, Matt Broadstone mbroa...@gmail.com wrote: Hi all, I've been using qt 4.8.6 for quite some time on my macbook installed from homebrew with no problem whatsoever. I decided over the weekend to upgrade my install to the latest qt5 build which on homebrew is 5.3.2. Everything installed, qmake ran and I was able to successfully build qjsonrpc on my mac. Cool. Now, I've got another test app that links to qjsonrpc, and when I build that it turns out that I'm no longer able to find anything in /usr/include or link to anything in /usr/lib. I naturally assumed this was an issue with the compiler's search paths, but then why did 4.8.6 work? Hmm, okay, let's just use Qt's distributed 5.3.2 binaries, maybe homebrew got it wrong... Same problem. I went through a diff of the mkspecs dirs of both versions and couldn't see anything that would obviously cause this. Has anyone using Qt on mac run into this problem? Running out of ideas here! Hard so say anything without knowing what the things are that are not found. General hints are: Have a look at the actual compiler command lines and look for the -I and -F s, and run qmake with “qmake -d -d -d” to get detailed information on which files are pulled in and how specific qmake variables get their values. Br, Eike -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] osx search paths with 5.3.2
On Mon, Oct 13, 2014 at 11:07 AM, Ziller Eike eike.zil...@theqtcompany.com wrote: On Oct 13, 2014, at 4:55 PM, Matt Broadstone mbroa...@gmail.com wrote: Hi all, I've been using qt 4.8.6 for quite some time on my macbook installed from homebrew with no problem whatsoever. I decided over the weekend to upgrade my install to the latest qt5 build which on homebrew is 5.3.2. Everything installed, qmake ran and I was able to successfully build qjsonrpc on my mac. Cool. Now, I've got another test app that links to qjsonrpc, and when I build that it turns out that I'm no longer able to find anything in /usr/include or link to anything in /usr/lib. I naturally assumed this was an issue with the compiler's search paths, but then why did 4.8.6 work? Hmm, okay, let's just use Qt's distributed 5.3.2 binaries, maybe homebrew got it wrong... Same problem. I went through a diff of the mkspecs dirs of both versions and couldn't see anything that would obviously cause this. Has anyone using Qt on mac run into this problem? Running out of ideas here! Hard so say anything without knowing what the things are that are not found. General hints are: Have a look at the actual compiler command lines and look for the -I and -F s, and run qmake with “qmake -d -d -d” to get detailed information on which files are pulled in and how specific qmake variables get their values. Br, Eike Hi Eike, Thanks for the quick response. The things that are not found are for isntance, /usr/include/qjsonrpc/qjsonrpcmessage.h. I can fix this manually by adding /usr/include to my INCLUDEPATH - no problem, but definitely wasn't a requirement on the exact same machine with the qt 4.8.6 install (maybe a more basic question: is this just something that changed in 5.x mkspecs?). My compile lines with 4.8.6 installed add -I/usr/include to the compile lines, while the 5.3.2 install does not. Additionally, adding -L/usr/lib to my LIBS line in the pro file with 5.3.2 still breaks and can't find files that are definitely there. I'll pour through this qmake -d -d -d now and see if I can provide any more information. Matt -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] osx search paths with 5.3.2
On Oct 13, 2014, at 5:23 PM, Matt Broadstone mbroa...@gmail.com wrote: On Mon, Oct 13, 2014 at 11:07 AM, Ziller Eike eike.zil...@theqtcompany.com wrote: On Oct 13, 2014, at 4:55 PM, Matt Broadstone mbroa...@gmail.com wrote: Hi all, I've been using qt 4.8.6 for quite some time on my macbook installed from homebrew with no problem whatsoever. I decided over the weekend to upgrade my install to the latest qt5 build which on homebrew is 5.3.2. Everything installed, qmake ran and I was able to successfully build qjsonrpc on my mac. Cool. Now, I've got another test app that links to qjsonrpc, and when I build that it turns out that I'm no longer able to find anything in /usr/include or link to anything in /usr/lib. I naturally assumed this was an issue with the compiler's search paths, but then why did 4.8.6 work? Hmm, okay, let's just use Qt's distributed 5.3.2 binaries, maybe homebrew got it wrong... Same problem. I went through a diff of the mkspecs dirs of both versions and couldn't see anything that would obviously cause this. Has anyone using Qt on mac run into this problem? Running out of ideas here! Hard so say anything without knowing what the things are that are not found. General hints are: Have a look at the actual compiler command lines and look for the -I and -F s, and run qmake with “qmake -d -d -d” to get detailed information on which files are pulled in and how specific qmake variables get their values. Br, Eike Hi Eike, Thanks for the quick response. The things that are not found are for isntance, /usr/include/qjsonrpc/qjsonrpcmessage.h. I can fix this manually by adding /usr/include to my INCLUDEPATH - no problem, but definitely wasn't a requirement on the exact same machine with the qt 4.8.6 install (maybe a more basic question: is this just something that changed in 5.x mkspecs?). Could be that it changed in Qt 5 mkspecs, since /usr/include actually is not required as an include path by the Qt libraries. Also, the Qt4 binary packages are installed systemwide, I’m not sure if that was just /usr/local/include, or also /usr/include. So, all in all, it looks to me like the Qt 5 behavior is the expected one, and adding INCLUDEPATH=/usr/include(/qjsonrpc) is the way to go. Br, Eike My compile lines with 4.8.6 installed add -I/usr/include to the compile lines, while the 5.3.2 install does not. Additionally, adding -L/usr/lib to my LIBS line in the pro file with 5.3.2 still breaks and can't find files that are definitely there. I'll pour through this qmake -d -d -d now and see if I can provide any more information. Matt -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Eike Ziller, Senior Software Engineer - Digia, Qt Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] osx search paths with 5.3.2
On Monday 13 October 2014 11:23:11 Matt Broadstone wrote: Thanks for the quick response. The things that are not found are for isntance, /usr/include/qjsonrpc/qjsonrpcmessage.h. I can fix this manually by adding /usr/include to my INCLUDEPATH - no problem, but definitely wasn't a requirement on the exact same machine with the qt 4.8.6 install (maybe a more basic question: is this just something that changed in 5.x mkspecs?). My compile lines with 4.8.6 installed add -I/usr/include to the compile lines, while the 5.3.2 install does not. Additionally, adding -L/usr/lib to my LIBS line in the pro file with 5.3.2 still breaks and can't find files that are definitely there. I'll pour through this qmake -d -d -d now and see if I can provide any more information. The difference is the way we call the compiler on OS X, starting with Qt 5.1 or 5.2. We now tell it to use the Apple sysroot that is present inside the XCode bundle. That means it will not search /usr/incude or /usr/lib -- instead, it will only use the libs that are inside that sysroot. That way, we're guaranteed to use only libraries that are always present on the target OS version. Previously, it was easy to make mistakes in depending on libraries that Apple doesn't ship just because they were in /usr/lib. On OS X, you should not link to libs in /usr/lib. Instead, make sure they are proper frameworks and that they get deployed into your app's bundle. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt List Items in 5.3
First of all, report the issue/suggestion via the Qt's official bug tracker (feel free to notify me, when done). We already have QTextListFormat class, through which one could control the list formatting options, so maybe it would be both easier and most-convenient to extend the QTextListFormat::Style enum with i.e. ListCharacter value, and a respective setBulletCharacter(const QString ) method (-- better names needed!). Regards, Konstantin 2014-10-13 16:25 GMT+04:00 Bo Thorsen b...@vikingsoft.eu: Den 13-10-2014 00:44, Lee Powell skrev: I know all you folks are busy as this is probably not a high community request, but if you would consider adding dashes and stars to list items at the very least that would be awesome. We'd be happy to implement first and raise a merge request with the qt repository for the text based bullet styles if Digia debs were not able to add the dash and star decorations. Please let me know your preference. Sounds like this is a low risk feature. But since no one else have requested it for the many years those classes have been used, it's also a low gain feature. I suggest you try and create as small a patch as possible and do a merge request for it. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ 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] Some more maintainer nominations
Hi, On 13.10.2014 13:36, Knoll Lars wrote: I’d like to nominate a few more maintainers. Most of the below should be simply about making the de-facto status official, ie. Putting the person that does most of the work on the module in charge. Qt WebChannel: Milian Wolff Having worked together with Milian on this project before, I can attest that he also has a great understanding of the JS world, in addition to the Qt world. So I think Milian will make a good maintainer and fully support the nomination. Disclaimer: We both work at the same company. 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 smime.p7s Description: S/MIME Cryptographic Signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
On 13.10.2014 13:46, André Somers wrote: Milian Wolff schreef op 11-10-2014 16:44: On Friday 10 October 2014 21:26:11 Tomaz Canabrava wrote: On Fri, Oct 10, 2014 at 6:35 AM, Milian Wolff milian.wo...@kdab.com wrote: On Friday 10 October 2014 06:22:12 Tomaz Canabrava wrote: Em 10/10/2014 06:18, Oswald Buddenhagen oswald.buddenha...@theqtcompany.com escreveu: On Fri, Oct 10, 2014 at 11:07:52AM +0200, Milian Wolff wrote: may I ask why you don't simply copy KConfig? It's API design has proven to be extremely versatile and efficient over the years. actually, it has proven horrible and is slated for a rewrite for a decade. the only thing it does right is what tomaz copied to his api. (still sleeping, só I will write better latter) I used kconfig and I tougth it was terrible to use, that why I came to thiago and hélio Castro asking if I could try a new one. I'll read the emails on this thread and change the code accordingly. Please double-check the KConfig API and copy more of its behavior. Some of that stuff was also mentioned by Thiago, Bo and Kai: QConfig(identifier_or_filename); // this should also be the root group config.setValue(bla, 123); // would set a global config value, with multiple overloads or template functions QConfigGroup group = config.group(something); // smart handle with reference semantics group.readValue(blub, /* default value */); // read value in group, also overloads and/or template function foreach (QConfigGroup subGroup, group.groups()) // or similar qDebug() subGroup.name(); I still think that KConfig, API-wise, is extremely convenient and haven't seen anything better so far. The internals and performance is a bit lacking, but usually not a problem and definitely not related to the API. It's too error prone regarding typos. // main.cpp KConfig c; KConfigGroup g = c.group(blah); g.setValue(width, 10); // otherfile Kconfig c; KConfigGroup g = c.group(blah); g.value(widht); // - no error is issued, this is something that I wanna have it fixed. How do you intend to fix it? Esp. when looking at what Rafael proposes? If you declare any other class to be used instead of a string, the user can still mix two variables up. I don't see what that has to do with KConfig/QConfig, really. Bye We're moving away from using these keys directly at all. Instead, we only use a real, type safe interface anymore for settings. That is: every setting gets a real getter and setter in a Settings class. That class is responsible for storing and retreiving the setting from the backend (which, in our case, has several levels now). If needed, there is not only a getter and a setter, but also a corresponding changed signal, but that changed signal currently only works if the setting is changed from inside the application itself (good enough for us). Personally, I think that using string-based key-value pairs (whether the key has grouped semantics or not) and then manually casting the value to the needed everywhere you need it simply has no place in application code in all but the simplist applications. API's need to be type-safe if at all possible, and if not, the exposure to the non-type safe API should be kept to a minimum. Further more: default values need to be consistent. Allowing the application to access the backend from more than one place, also means having the specify the default value for settings in more than one place. That *will* lead to inconsistencies. In our case, that means that there is only one class where there is exposure to the non-type safe QVariant-based API of Qt, and that is the settings class itself. The rest of the application has no clue, nor needs to have any clue, on how the settings are stored: they are just using type-safe properties with clearly defined default values. I would like to see some (modular) kConfig XT-like settings specification that results in type save code within Qt though. Preferably with a nice editor-plugin inside Creator. Or, perhaps based on the Q_PROPERTIES or something similar allowing you to use a default getter/setter implementation for simple cases, and add your own for more complex ones. That would already save a lot of boilerplate code. I don't believe in auto-generating configuration dialogs, though a tree representation would be useful for advanced editing and developer settings. +1, something like KConfigXT that auto-generates QObjects with appropriate getters, setters and Q_PROPERTIES would be very useful. Not just for type safety - also for exporting settings objects directly to the QML world, which otherwise is a lot of boilerplate code to write. 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 smime.p7s Description: S/MIME Cryptographic Signature ___
