Re: [Development] CI broken again
any update on this? It seems tst_pauseanimation is failing constantly (only on OSX 10.9) Jan Arve Fra: development-bounces+jan-arve.saether=theqtcompany@qt-project.org [development-bounces+jan-arve.saether=theqtcompany@qt-project.org] på vegne av BogDan [bog_dan...@yahoo.com] Sendt: 17. oktober 2014 15:03 Til: Sarajärvi Tony; Qt Development Group Emne: Re: [Development] CI broken again Some tests fails even the patches that we are trying to push are not released. Check https://codereview.qt-project.org/#/c/97244https://codereview.qt-project.org/#/c/97244/ and https://codereview.qt-project.org/#/c/96681https://codereview.qt-project.org/#/c/96681/ Cheers, BogDan. From: Sarajärvi Tony tony.saraja...@theqtcompany.com To: BogDan bog_dan...@yahoo.com; Qt Development Group development@qt-project.org Sent: Friday, October 17, 2014 3:58 PM Subject: RE: [Development] CI broken again Hi What exactly is broken? -T From: development-bounces+tony.sarajarvi=theqtcompany@qt-project.org [mailto:development-bounces+tony.sarajarvi=theqtcompany@qt-project.org] On Behalf Of BogDan Sent: 17. lokakuuta 2014 10:54 To: Qt Development Group Subject: [Development] CI broken again Hello, It seems that CI is broken for a few days, is anyone working on it? When should we expect a fix? Thanks! Cheers, BogDan. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5*Config.cmake files: _qt5_*_check_file_exists macros and plugins
Kevin Kofler wrote: Those _qt5_*_check_file_exists checks look unnecessary to me in the first place. Part of the intention of the way CMake config-packages and IMPORTED targets work is that if the FooConfig.cmake is present and found, and the Foo IMPORTED target is present, then you can use it without further checks. http://www.cmake.org/cmake/help/v3.0/manual/cmake-buildsystem.7.html * If a file is NOT actually required to build against the library, then it should NOT be checked for (as is the case for those plugins). The intention of the check is to verify that the things defined/exported by the package actually exist - it's not about whether the files are required to build against the library, per se. That's not the intention of the check. But I also don't see the checks being useful for self-built Qt (where make install will just install everything) nor your upstream binaries (which also contain everything that is needed). 1) If I reference a plugin in my buildsystem (so I can make a mac bundle or whatever), and I have not installed the Fedora package for the plugin, things might seem fine in the buildsystem, but the plugin won't be packaged, and I'll have runtime bugs to debug. The check turns that into a build-time report. 2) Other people can also create packages for use within an organization, and they may not do it right, may not have the rules/guarantees that you provide with your packages etc. In saying that though, the check is probably relatively low value. So the question there is: Why were those checks added in the first place? Can they be removed in upstream Qt? My suggestion is similar to the idea behind https://codereview.qt-project.org/61334 Namely, add a component to the *Config.cmake packages such that the user can write find_package(Qt5Core REQUIRED Plugins) to express that the plugins are needed in the buildsystem (for whatever reason). The semantic might be, * if the Plugins component is specified, then check for existence, otherwise don't. or * if the Plugins component is specified, then load the *PluginConfig.cmake files, otherwise don't. This has the side-effect that the existence check won't be done. I prefer the second option (and there may be more options). The problem is backward compatibility though - currently people are not specifying the Plugins component and the plugin IMPORTED targets are defined and usable. After such a change they wouldn't be. However, users would have to update their Qt to get the new behavior and it would be immediately noticable, and maybe something like a CMake policy could be emulated for it. So I think that would be ok. What do you think? Then, afaiu, you could continue to ship the *Config.cmake files in your -devel package, but they won't cause a fatal error if the plugin is not present, unless the user specifies that they want the plugin, and then the fatal error is appropriate. 3.b. One subpackage per *Plugin.cmake file, i.e. for every qt5-modulename-pluginname package, we'd have a qt5-modulename-pluginname-devel. That means many subpackages. This looks to me like the most correct but probably least convenient solution. Thanks, Steve. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QtIFW] CPack IFW Generator
Konstantin Podsvirov wrote: Thank you! This is what I need. I have a Gerrit account (user: kot). But I haven't contributed in Qt code. What sequence of actions? What instruction I to read? I can also create a patch with boilerplate topics or sections where you can add the information. For planning purposes, do you have information about the generator somewhere that I could look at? A working version of CMake is not accompanied by a public documentation, Documentation generated from the master branch is updated daily here: http://www.cmake.org/cmake/help/git-master/module/CPackIFW.html Also, what's the time frame for CMake version 3.1.0 ? I don't want to add links to a yet unreleased feature ... The roadmap says early November: http://public.kitware.com/Bug/roadmap_page.php but it's likely to slip some weeks if past experience is a good forecast. Whatever is true about additions to the Qt documentation, the CPackIFW generator looks like it should get a mention in http://www.cmake.org/cmake/help/v3.0/manual/cmake-qt.7.html One option would be to add primary prose there and link to that from http://doc-snapshot.qt-project.org/qt5-5.3/cmake-manual.html and http://qt-project.org/doc/qt-5/deployment.html The CMake documentation can be loaded in creator http://www.kdab.com/context-sensitive-cmake-documentation-qtcreator/ and CMake releases will include a qch file from now on. Eg http://www.cmake.org/cmake/help/v3.1/CMake.qch Thanks, Steve. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Thursday, October 16, 2014 11:14:53 AM Stottlemyer, Brett wrote: Qt Devs, I know I've been silent for a while after the discussing Replicant and QQSM at the Qt Contributors Summit. If you aren't aware, QQSM was renamed to DSM (Declarative State Machine) and has been incorporated into QML. It is already merged and will be released with Qt 5.4. The 2nd project was Replicant. As noted at QtCS, the name Replicant is already in use in software. So we have a new name: QtRemoteObjects. Not quite ahead of Dev Days, we've pushed it out to Qt's playground area. You can find it at https://qt.gitorious.org/qtplayground/qtremoteobjects. It is sparse on documentation, but that will be worked on over the coming weeks. We've made a bunch of changes since QtCS, some based on excellent suggestions from contributors, some based on internal needs. Hope you like it. The key to QtRemoteObjects, which I think differentiates it from other IPC/RPC approaches, is the idea of having a full (Qt) object in the new process. All property changes on the Source object will be reflected (with notification Signals) on the Replica object(s). Any Signals emitted from the Source will be emitted from every Replica. You can set properties on a Replica, as well as call Slots, but the implementation is such that the requests are sent to the Source, which responds to the calls. Any changes are then reflected by Signals or Property changes, as appropriate - this means that all instances (including the Source) will reflect the changes. The net result is that you can have a very complex object (talking to sensors, managing a resource, etc) in one process (or device), yet still interact with it in a Qt friendly way from another process (or device). All of the complexity of the IPC is handled internally by QtRemoteObjects. Feedback if, of course, welcome. I'm very fond of the idea of Qt making it very easy to talk to other applications living in other processes on potentially other machines (devices). I think if we want to address this in Qt, then we should take three requirements very very seriously: 1) Not everything is written in Qt. Perhaps only a GUI frontend? Or perhaps some services are written in Qt and others are written in a different language? I think the key to success is to allow for interoperability across language/runtime barriers. 2) The system must allow for versioning. Not all devices/services/processes will always be using the same version of the overall protocol. 3) The system should support a very convenient and robust mechanism to discover and connect to other processes. Based on experience with an in-house project I would suggest to avoid a wire format that is tied to Qt, i.e. QDataStream. My current favorite on this are actually google protocol buffers, because they are rather good with versioning and you can get bindings for _a lot_ of languages, including JavaScript. QDataStream on the other hand is terrible when it comes to versioning, compared to the convenience other solutions offer. Another option would be CaptnProto or Flatbuffers, but they language support is not as wide spread as protocol buffers. Either way they are rather similar in concept and I think a good fit. Regarding discovery it would be really nice to support bluetooth for peer to peer connectivity and zeroconf for regular IP based networks. We have had a very good experience using Zeroconf for this matter and it's easily available these days (including Android, iOS, Linux and even Windows) Binding just QObjects across process boundaries is tempting in the short run, but I think it would put us (Qt) on an island. I'd much rather see Qt provide the low-level enablers to allow our users to either do their own RPC _and_ provide a sample implementation for convenience (that uses futures/promises). Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] CI broken again
The OS X 10.9 nodes seem to be heavily loaded. For Qt3D integrations, the OS X 10.9 nodes are taking about 3.5 hours longer than any other platforms. Is something hogging CPU or IO on there? Cheers, Sean On 19/10/2014 09:58, Saether Jan-Arve wrote: any update on this? It seems tst_pauseanimation is failing constantly (only on OSX 10.9) Jan Arve Fra: development-bounces+jan-arve.saether=theqtcompany@qt-project.org [development-bounces+jan-arve.saether=theqtcompany@qt-project.org] på vegne av BogDan [bog_dan...@yahoo.com] Sendt: 17. oktober 2014 15:03 Til: Sarajärvi Tony; Qt Development Group Emne: Re: [Development] CI broken again Some tests fails even the patches that we are trying to push are not released. Check https://codereview.qt-project.org/#/c/97244https://codereview.qt-project.org/#/c/97244/ and https://codereview.qt-project.org/#/c/96681https://codereview.qt-project.org/#/c/96681/ Cheers, BogDan. From: Sarajärvi Tony tony.saraja...@theqtcompany.com To: BogDan bog_dan...@yahoo.com; Qt Development Group development@qt-project.org Sent: Friday, October 17, 2014 3:58 PM Subject: RE: [Development] CI broken again Hi What exactly is broken? -T From: development-bounces+tony.sarajarvi=theqtcompany@qt-project.org [mailto:development-bounces+tony.sarajarvi=theqtcompany@qt-project.org] On Behalf Of BogDan Sent: 17. lokakuuta 2014 10:54 To: Qt Development Group Subject: [Development] CI broken again Hello, It seems that CI is broken for a few days, is anyone working on it? When should we expect a fix? Thanks! Cheers, BogDan. ___ 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] Event loop of Qt window in DLL injected into another process
Hello, I have a problem with event loop. I am creating DLL which I am injecting into MFCapplication – my dll spawns a qt window. it works fine, except ‘input’ to spawned window is blocked: for ex. i have edit box, i am typing into it and nothing happens – unless, I resize / minimalzie window then it’s somehow ‘flushed’. does anyone have any idea why this happen? Here is my code: http://pastebin.com/iXqnwwCu I am using Qt version 5.3.2.--- Pozdrawiam, Arkadiusz Szulakiewicz tel.: 693-556-823 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] boot android app
Hi, i have developed a simple application, main screen with 6 button. On Nexus 5 the app start-up time is immediate, on Samsung Galaxy tab 3, i have 10 seconds. Why is this difference? Nicola ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects (was Replicant)
On Sunday, October 19, 2014 10:12 AM Simon Hausmann wrote: I'm very fond of the idea of Qt making it very easy to talk to other applications living in other processes on potentially other machines (devices). Me too ;-) I think if we want to address this in Qt, then we should take three requirements very very seriously: ... skipping #1 for a moment 2) The system must allow for versioning. Not all devices/services/processes will always be using the same version of the overall protocol. I agree, and I recognize this is one of many things that should be improved going forward. Same applies to types being passed by the protocol (as opposed to the protocol itself). 3) The system should support a very convenient and robust mechanism to discover and connect to other processes. I agree, and I'm a fan of zeroconf myself. But it needs to be optional, as I can think of cases where it would not be desired. So I see this as more of an extension/enhancement. 1) Not everything is written in Qt. Perhaps only a GUI frontend? Or perhaps some services are written in Qt and others are written in a different language? I think the key to success is to allow for interoperability across language/runtime barriers. I agree in theory (who wouldn't?), but not at all in practice. Off the top of my head, I'm using: QIODevice/QDatastream/QtypeSocket/QtypeServer for communication QVariant for data marshaling MOC for Properties/Signals/Slots, including object introspection QEventLoop for event serialization, notification +More (container classes, qpa, etc) If the suggestion is to use/create non-Qt versions of all of the above, why use Qt at all? Or maybe I'm misinterpreting your suggestion? It doesn't sound like you are thinking of a wrapper, along the lines of PyQt/PySide, so I'm not sure what else you could mean. Please clarify. Also, your points on protocol buffers and limitations of QDataStream are more accurately issues with Qt itself, aren't they? Should they not be addressed directly in Qt, rather than only in a playground module? More specifically, why not incorporate protocol buffers directly into Qt's QObject/MOC? I'm not kidding here, the thought has occurred to me several times when creating custom qt_metacall() code. Within the MOC generated code, you have void * pointers, QVariants and static_casting to/from types relying on the auto-generated code to guarantee the necessary types. Why not have MOC auto-generate protocol buffer templates instead? You already need to compile the MOC output, which could compile the protocol buffer just as easily. Such an implementation would provide simple validation, improved type safety, and possibly a performance boost. It would remove the artificial/arbitrary 9 argument limitation (as in QMetaMethod::invoke). It would probably be overkill for DirectConnection, but would make sense for QueuedConnection, where you need to copy the arguments anyway. And it would also likely simplify/standardize QVariant and QDataStream as well. And then extending QtRemoteObjects would be a lot more straight forward. Brett ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSettings refactor updates
Cache format: binary json You use json internally as cache. What is the motivation to introduce new classes with similar API like QJson classes? Is the implicit shared semantics not suitable for this use case? Can it be addressed in QJson classes directly? If Qt gets some type safe wrappers above the QConfig string based api, it would be great to have these wrappers above QJson classes directly. Kind regards Brano ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Event loop of Qt window in DLL injected into another process
On Sunday 19 October 2014 19:12:29 Arkadiusz Szulakiewicz wrote: Hello, I have a problem with event loop. I am creating DLL which I am injecting into MFCapplication – my dll spawns a qt window. it works fine, except ‘input’ to spawned window is blocked: for ex. i have edit box, i am typing into it and nothing happens – unless, I resize / minimalzie window then it’s somehow ‘flushed’. does anyone have any idea why this happen? Here is my code: http://pastebin.com/iXqnwwCu I am using Qt version 5.3.2 The usual answer is to give Qt the event loop. If you control the host application, you can create a QAbstractEventDispatcher to make it work with the MFC application. Or you can use the MFC migration framework (I think it's only available for enterprise customers). If you can't do any of those, you should use modal dialogs and use exec() for your Qt dialog. You'll be able to interact with the Qt dialog only, not the rest of the application, for the duration of the dialog. -- 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 Sunday 19 October 2014 22:39:42 Branislav Katreniak wrote: Cache format: binary json You use json internally as cache. What is the motivation to introduce new classes with similar API like QJson classes? It's an implementation detail because the binary json loading and parsing is extremely fast. -- 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] Event loop of Qt window in DLL injected into another process
Hello, I have a problem with event loop. I am creating DLL which I am injecting into MFCapplication – my dll spawns a qt window. it works fine, except ‘input’ to spawned window is blocked: for ex. i have edit box, i am typing into it and nothing happens – unless, I resize / minimalzie window then it’s somehow ‘flushed’. does anyone have any idea why this happen? Here is my code: http://pastebin.com/iXqnwwCu I am using Qt version 5.3.2 The usual answer is to give Qt the event loop. If you control the host application, you can create a QAbstractEventDispatcher to make it work with the MFC application. Or you can use the MFC migration framework (I think it's only available for enterprise customers). if you are referring to the qtwinmigrate, in my experience it is pretty broken ... registering, but not cleaning up itself which results in crashes when unloading the dll and the like ... one important point when injecting a function into the mfc event loop manually is to guard it against infinite recursion, as it may be called from qt_GetMessageHook ... If you can't do any of those, you should use modal dialogs and use exec() for your Qt dialog. You'll be able to interact with the Qt dialog only, not the rest of the application, for the duration of the dialog. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
