Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17
Hi Tuukka, 2017-02-16 17:13 GMT+01:00 Tuukka Turunen : > As multiple people and teams have planned their development according to > initially agreed feature freeze time of Qt 5.9, it would be very > inefficient to reopen 5.9 now or postpone getting the release out. > I would use the same argument for all customers and users of Qt who planned their development on a 5.8.1 release, but with my argument that a bug fix release should have priority over a new feature release. > > If we can get KDAB and others helping with Qt 5.9 with even remotely > similar effort than it would be to create Qt 5.8.1 release I am sure we can > make an awesome Qt 5.9.0 ahead of the planned schedule. This means we can > make the CI system improvements earlier and thus also have Qt 5.9.1 earlier. > My question might sound sarcastic but it is really serious: Who does guarantee me that a 5.9.1 release won't be dropped again in favor of the 5.10 release schedule? Maybe I'm not familiar with the process and details how and when a decision for a patch release is made, but I learned from this discussions that it was expected by most people. If there is no guarantee in the future, this decreases dramatically my will to test and fix bugs after a .0 release in this branch. My contribution might not be high and in total insignificant though. I can only repeat my personal opinion: Bug fixes first, then new features. If the time between two feature releases is too close, then increase the time or change to a release-when-its-ready timeline. My 2 cts. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Warning about unknown escape sequences in qtremoteobjects
Dear Qt developers, when building Qt 5.9.0 from git (by coincidence it was the same commit as 5.9.0 Alpha), I got many of the following warnings in qtremoteobjects: In file included from main.cpp:43:0: repparser.h:2:10: warning: unknown escape sequence: '\.' #line 57 "..\..\src\repparser\parser.g" caused by lines like #line 57 "..\..\src\\repparser\parser.g" in repparser.h and repparser.cpp. Those are just warnings, but treated as errors in the dev build. I always try to fix things like those myself, but this time, I'm a bit stuck where this came from. Hence my question: 1. Should it be #line 57 "../../src/repparser/parser.g" or #line 57 "..\\..\\src\\repparser\\parser.g" 2. The files are generated by qlalr. So is the bug in qlalr or is it in the input document, qlalr is parsing or even somewhere else? Any ideas? Cheers R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Announce] Qt 5.9 Beta released
Am 07.04.2017 um 12:33 schrieb List for announcements regarding Qt releases and development: > Hi, > > I am happy to inform Qt 5.9 Beta is released today, see > http://blog.qt.io/blog/2017/04/07/qt-5-9-beta-released/. > As informed earlier beta binaries are available only via qt online installer > (except QNX package for enterprise users which is still using offline > installer & available in qt account) > > br, > Jani Heikkinen > Release Manager Sorry, if this question was answered already, but I couldn't find anything in the docs nor a final statement in the mailing list. Will there be official MSVC 2017 binaries available for the 5.9 release? I thought I read it will be, but there aren't any at the moment for the beta release. Cheers Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Behavior change for QMake install targets since 5.9
Dear Qt developers, since 5.9 some of my projects install targets are failing. Investigation has shown that the generated Makefiles reference now a different INSTALL executable. Before it was 'install' from GNU coreutils and now it is calling 'qmake -install qinstall'. Apart from the fact that I could not find anything in the changelog about this bigger change (only a few references that make install will no longer modify the timestamp etc), there are several behavior changes affecting existing install targets. * Installing a symbol link was deep copying the link target under the link name. Example: libfoo.so -> libfoo1.0.0.so Installing libfoo.so installed the binary libfoo.so without creating a symbol link. * Using wildcards to copy several targets is broken. Example: libfoo.so -> libfoo1.0.0.so Installing libfoo*.so fails now. Before it was copying the link and the binary. Maybe the above use cases are not the perfect solution for a specific problem, but they were working. Also there might be other features (or even bugs), users of coreutils install were relying on and are no longer available. Is this considered acceptable since the usage of coreutils install was a private configuration and developers should never rely on its behavior? Cheers R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Behavior change for QMake install targets since 5.9
Hi Simon, Preamble: The problem I was trying to solve with wildcards was to install a shared library target into two different directories. The first directory is installed with a simple 'INSTALLS += target' line. The other path is installed manually by a second INSTALLS definition and the files are selected with a wild card. This was the easiest solution at the time and the documentation said it was fine to do so. > Since Qt itself has installs libraries alongside with .so symlinks and > those are installed as symlinks, I wonder what the difference is between Qt > and your application. Can you compare the command lines generated in the > Makefiles? > I've checked the Makefiles. The only difference is that -$(INSTALL_FILE) is replaced by -$(QINSTALL). The problem here is that make install used to be able to handle wildcards during install time. QMake isn't. The difference between Qt and my application is explained in the preamble (install to second directory). > It's true that the internal install command does not support wild-cards. > We decided that it is the responsibility of the caller to resolve those > (qmake). > The problem I have is that the build products are not yet available when qmake is running. Qmake *is* able to resolve wild cards if the files are available when qmake is running. But the products aren't existing yet. With Qt 5.8 the install command line was something like -$(INSTALL) /path/to/libfoo* $(INSTALL_ROOT)/path/to/install/libfoo* which was perfectly ok on most OS's. I think only MacOS didn't like it. But now its -$(QINSTALL) /path/to/libfoo* $(INSTALL_ROOT)/path/to/install/libfoo* and I get the error "Error: usage: [-exe] source target. I can completely understand that the installation behavior needed to be aligned across all operating systems. If we could revise the decision to no allow wild cards, I would be very happy about it. Cheers ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.10 beta 3 released
2017-11-01 11:59 GMT+01:00 Jani Heikkinen : > > Qt 5.10 beta3 is out. Instructions how to get the release are here: > https://wiki.qt.io/How_to_get_snapshot_via_online_installer. > Hi Jani, first of all thanks a lot for this new way of shipping beta versions. It is so much nicer now to just run the maintenance tool via the online installer and install the new beta instead of having several single offline installer versions in parallel. One question: How likely are the chances that the prebuilt MSVC 32 bit packages will be built with MSVC 2017 instead of 2015? As far as I know, the v140 toolset in VS 2015 and the v141 toolset in VS 2017 are binary compatible. So if I'm not wrong, MSVC 2015 could also use the MSVC2017 binaries, no? Cheers R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Stop delivering 32 bit MinGW binaries from 5.12 ->
2017-12-21 11:37 GMT+01:00 Jani Heikkinen : > With Qt 5.11 it seems we can finally drop MSVC2013 so we could > "temporarily" add MinGW 64 bit pre-build binaries in our packages in > addition to 32 bit ones and remove 32 bit MinGW pre-built binaries from > 5.12 onwards. Making this decision now would complete this discussion > finally and still give users time to move from 32 bit to 64 bit ones... > Hi Jani, adding MinGW 64 bit sounds great. I would prefer to keep the MinGW 32 bit ones too, because there are several projects which are plugins to host applications in 32 bit. So sometimes its not in the scope of the developer to change his project to 64 bit. Please keep that in mind. I personally use MSVC2017 together with MSVC2015 32 bit binaries for the published product. But I regularly use MinGW for daily development. Other people might prefer MinGW over MSVC for published products though. So 32 bit software projects are still very common on Windows platforms. Cheers R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Prebuilt 32-bit versjon for MSVC 2017
2018-02-21 13:44 GMT+01:00 Harald Kjølberg : > > Hi, > > Currently Qt ships with 32-bit binaries for MSVC 2015, but not for MSVC > 2017. The Qt Company have received requests for adding prebuilt 32-bit > binaries also for MSVC 2017. By adding more prebuilt binaries, we increase > the complexity, and add to the overall maintenance of our QA system. Our > preferred approach would be to add binaries for MSVC 2017 and remove the > binaries for MSVC 2015, as the numbers of binaries in the build remains the > same. It will still be possible to manually build Qt for MSVC 2015, in the > same way as it is possible to manually build for MSVC 2017 today. Feedback > and viewpoints are much appreciated and will enable us to make the best > possible decision. > I'm using MSVC 2017 with Qt5 2015 prebuilt binaries. I never had issues with this combination so far, but still would appreciate to have the also have the 32 bit binaries prebuilt with 2017. So I'm happy to hear that this is considered. A little bit offtopic: I think those discussions about prebuilt binaries would be less controversal, if it would be easier to produce custom Qt installers. I'm aware that I can build 32 bit with MSVC 2017 on my own, but creating an installer for my colleagues is a mystery to me. Yes, its easy enough to _build_ Qt yourself. I regularly do that. But its a pain to produce any kind of installers to share it with team members or relocate the built. I would produce more custom prebuilts of Qt, if the documentation about how to create custom installers is up to date and accurate. I tried once to follow http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/README but it was so much dependent on the Qt CI infrastructure (shares, node names etc), hard to follow and presumably outdated (it referenced Qt 5.5). R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] How to create a Qt5 offline installer myself
Dear Qt Devs, I think I asked this question in the past, but I never got a reasonable answer. The question is actually quite simple: How can I create a Qt5 offline installer for example for 5.11.1 MinGW 5.3.0 32 bit? I'm aware of the qt/qtsdk repository and its scripts. There is also some high level description in the READMEs. But following the coin builds, those are using GO scripts which are as far as I can see not public.So that means, Qt build servers have been using those python scripts in the past, but now they don't and that renders them in fact untested and unmaintained. I don't mind doing more steps manual (even if automating it fully would be super great), but I cannot even find a easy way of doing it manually. It was often mentioned in this mailing list, that users/developers can build their own version of Qt and the official binaries are just a subset. That's fair enough and I can and do regularly build Qt on my own. But my own build doesn't help me much, if I cannot bundle it into a proper installer and make it available to other people and/or build servers.To me, this is still a very important step which should be properly documented and as easy reproducable as the regular Qt5 build. So if anyone has a good and easy to follow guide, how to produce my own offline installer, please share it with me. Ideally we come up with a wiki page similar to https://wiki.qt.io/Building_Qt_5_from_Git. The reason why I'm asking is, that I would like to try and get some changes into the binaries (release build with debug symbols for crash dumps, MSVC 2017 32 and 64 bit builds etc). Looking forward to any help. Thanks, Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] VulkanSDK path added to includes since 5.12.1
Hey everyone, I noticed that since the upgrade to 5.12.1 the following include option is added to my projects compiler flags: "-IC:\VulkanSDK\1.0.51.0\include" It seems to origin from "modules/qt_lib_gui_private.pri:QMAKE_INCDIR_VULKAN". It does not do any harm to my build, but I wonder if that include was added accidentally or on purpose? Thanks, Roland ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Intention of dropping UWP 2015 x86 builds in favour of MinGW 32-bit packages
Am Mi., 6. Feb. 2019 um 13:01 Uhr schrieb Jesus Fernandez < jesus.fernan...@qt.io>: > > The original mail said nothing about 5.12.2. And I would remove support > for both compilers in 5.13. Any 32 bits is an outdated platform. > > > 32 bit is not only about platform. 32 bit applications still run perfectly fine on 64 bit Windows OS and there are many older but relevant applications and libraries that haven't been ported yet to 64 bit and require still 32 bit builds. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Add API method to QDBusServer allowing anonymous authentication
Hi there, first of all I want to say hello. I was using Qt since quite a while now, but never did any developing for Qt itself. For my next project I identified some things I would need to add to the offical Qt libraries. Since I don't want to role out my customised ones, but stick with the official releases (especially on linux), I thought its time to say hello. The first feature I would need, is a new API method in QtDBus. Freedesktops DBus library has a method to allow anonymous access (http://dbus.freedesktop.org/doc/api/html/group__DBusConnection.html#gade349ff04ed548993a8054250e317c12). You can easily configure the dbus-daemon to allow this kind of authentication in the dbus config file, but I would not advise to use that (since it allows anonymous authentication for everything). However, I need anonymous authentication for my next project, so I decided to go for a peer2peer concept. Unfortunately, in the QtDBus API there is no way to apply this. There is no configuration file for QDBusServer and no method to enable it. I also cannot set my own callback for new connections, since it needs to use QDBusConnectionPrivate. My idea was to add a new API method to QDBusServer::allowAnonymous(bool allow = false), which sets a new member variable in QDBusConnectionPrivate. If a new connection is established, void dbus_connection_set_allow_anonymous could be applied accordingly. I have now 2 questions: - First of all, is this something, that has a chance to get into the official repository? - If yes, how should I proceed. Start developing it locally and send it to gerrit? I have of course read the Qt Contribution Guidelines, but the question is, do I have to ask someone in advance if this is in line with the roadmap and goals of the project? Thanks in advance Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Trigger Qt event loop from external message loop
Hi there, I'm working on an application using Qt5 for its window framework. The requirement for this application is to run standalone and as a plugin for a native application. While the case standalone application is easy, I'm struggling a bit with the plugin part. I have the following in mind: The plugin is loaded by a native application as a plugin. After the plugin is attached as a shared library a QApplication object is created and a dialog is shown, when the user selects it from the menu. Since I cannot run Qt's event loop with QApplication::exec() - I dont want the plugin to block the parent application - I try to trigger the event loop externally. The two options I have are: qApp->sendPostedEvents(); or qApp->processEvents(); The second one is not a good idea, since it calls PeekMessage(..., PM_REMOVE) which removes any message. Even that targeted for the parent application -> not a good idea. qApp->sendPostedEvents() on the other hand does send everything except window system messages. qwindowsysteminterface.cpp sais the following about this topic: "The platform plugins call the various functions to notify about events. The events are queued until sendWindowSystemEvents() is called by the event dispatcher." So I would need to call sendWindowSystemEvents() before. This can be done by calling QEventDispatcherWin32::sendPostedEvents() which is protected and part of the private headers. Even though it is virtual, its base class QAbstractEventDispatcher does not have such a method. During runtime a QWindowsGuiEventDispatcher object is allocated and its virtual method sendPostedEvents() is used. This is what I would need. Now I'm stuck. Would it be possible to just add a public method in QAbstractEventDispatcher, e.g. QAbstractEventDispatcher::sendPostedGuiEvents() or anything else? Any other ideas? I know this is a special case, but I think its worth to solve it. Summary - the following use cases work: - QApplication::processEvent() for long running methods (in case all messages are really targeted to your Qt application). - QApplication::sendPostedEvents() which sends every core application events. The following use case does not work up to now: - Qt application has a parent with its own message loop. Window system events get stuck and are never sent. (besides some exceptions, e.g. resizing, since it triggers flushWindowSystemEvents() ). Any would be appreciated! Thanks, Roland PS: I've raised https://bugreports.qt-project.org/browse/QTBUG-32962 some month ago. Yesterday I tried it with 5.2.0 and forgot, I had a local workaround in place. So contrary to what is written, it is not fixed in 5.2.0 --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Trigger Qt event loop from external message loop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 14.12.2013 02:16, schrieb Thiago Macieira:
> On sábado, 14 de dezembro de 2013 00:45:20, Roland Winklmeier
> wrote:
>> Since I cannot run Qt's event loop with QApplication::exec() - I
>> dont want the plugin to block the parent application - I try to
>> trigger the event loop externally.
>
> You have to do that.
>
> Use another thread then. All of your proposed solutions in your
> email will run into trouble sooner or later.
>
Thiago,
thanks for that hint. I changed the plugin to start its own thread. In
this thread I create the QApplication, the dialog and call
QApplication::exec(). Everything fine and clean now besides the
following issue:
In qthread_win.cpp
QThreadPrivate::start ->
void QThreadPrivate::createEventDispatcher(QThreadData *data)
{
QEventDispatcherWin32 *theEventDispatcher = new QEventDispatcherWin32;
data->eventDispatcher.storeRelease(theEventDispatcher);
theEventDispatcher->startingUp();
}
but I expected to have a pointer to QWindowsGuiEventDispatcher which
is a subclass from QEventDispatcherWin32 and located in the QPA plugin.
If I run the standalone application without threading, the event
dispatcher is created in qapplication_qpa.cpp:
void QApplicationPrivate::createEventDispatcher()
{
QGuiApplicationPrivate::createEventDispatcher();
}
- ->
void QGuiApplicationPrivate::createEventDispatcher()
{
Q_ASSERT(!eventDispatcher);
if (platform_integration == 0)
createPlatformIntegration();
// The platform integration should not mess with the event dispatcher
Q_ASSERT(!eventDispatcher);
// Creates a QWindowsGuiEventDispatcher on windows
eventDispatcher = platform_integration->createEventDispatcher();
}
So if I run the application in its own thread, QThread creates its
custom event dispatcher, hence no QWindowsGuiEventDispatcher object is
created later in QApplication. But QEventDispatcherWin32 is not
handling window system messages in its sendPostedEvents() method.
Thats why the application does not do anything when I click on buttons.
Does this make sense and could it be fixed, that I get the same event
dispatcher in both cases?
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSrEQoAAoJEI9ELizP04ba2CAH+QHoxVVbL9UJOud0vpEw5zwj
catLBSIvz/r4vAwrt6iDu/FHbrZ6aobWX0t1HhdGzaiT90OMjBdbPZNskvd5+gwA
PyO8GTgUXRPF58GCgY6dtW2X7PBd1S1Am3MXWAUeLjES1olZ0CRVDeuJRVgCp+No
o57FcI7vKACekzNitDBgn/hkclcor/oOinRzY8R1qEkyc8HUURD2kG6FhEiZfaQS
zFzom7qJ+3IXJ+9vpHgmobPQJil3rHApgfWQIZ47rdcsjV5mqnm+y85K92qWLNeL
FXTjYrZwxooFQhBWGl05MnM6zM9YVuW1k02hYMefSwH9iNdetSayOhPYkvJW4Yk=
=Xh1g
-END PGP SIGNATURE-
---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz
ist aktiv.
http://www.avast.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Trigger Qt event loop from external message loop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Thanks very much Olivier and Thiago!
That works brilliant.
No idea why I forgot that QThread must not be used. But its of course
obvious. I made a quick setup with native threads (std::thread is
unfortunately not supported by VC2010) and it works perfectly now.
In case someone is interested:
- - I added a additional shared library spawning a thread and links the
actual plugin during runtime with LoadLibrary/dlopen. No Qt stuff in here.
- - Second shared library creates QApplication object and runs its
exec() loop.
Cheers Roland
Am 14.12.2013 19:23, schrieb Thiago Macieira:
> On sábado, 14 de dezembro de 2013 12:42:32, Roland Winklmeier
> wrote:
>> n qthread_win.cpp QThreadPrivate::start -> void
>> QThreadPrivate::createEventDispatcher(QThreadData *data) {
>> QEventDispatcherWin32 *theEventDispatcher = new
>> QEventDispatcherWin32;
>> data->eventDispatcher.storeRelease(theEventDispatcher);
>> theEventDispatcher->startingUp(); }
>
> You must not use QThread.
>
> You need to start your thread before using any QObject-derived
> classes. Once you're there, instantiate the QApplication.
>
>
>
> ___ Development mailing
> list Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.20 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJSrL69AAoJEI9ELizP04baQVUH/2G6IGrxCz2UJxl/tVGeKxkE
LGZyzjYu5zLZnG93pUKGWoaUoHzB4VPfrzr+ILgbYuO+OOgmRw/h8dlRjpgJTIvu
H5P9WmyxSmgkBaD+x4bxwOE/gtlQZ8eTchD/vfHvOxqET3g3RBXt+8yrF3QJUNqd
g8v6m3BGrTHY7E7X3Oqs8kqkr/Q8KmcLyrSSrSu1bB4yir+eyukj3CkIX0TKoLG8
hOexewm5O2G97sqB99/Jm6q45hpeSxKYX5J5ahahEJCJlbfgluOk35RSlM5K8yYS
d2WbSsA16bnadl+G2ElRYWEOx4q1sWpio5aXBxefmDOnDNWoUs9ZPr1BxQfQwoE=
=nv6M
-END PGP SIGNATURE-
---
Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz
ist aktiv.
http://www.avast.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Trigger Qt event loop from external message loop
Unfortunately Mac is (additional to Win and Linux) a target OS, so if this
is not working on that I have to find another way to do it. I found
QMacNativeWidget which looks promising and looking into its implementation
I'm wondering how Qt's event loop is triggered?
With Qt4 I also used QWinWidget alot, which worked fine in Qt4 but is
broken in Qt5. QWinWidget created a QApplication and was registering a
message monitor (with SetWindowsHookEx) and triggered the event loop in the
callback by qApp->sendPostedEvents().
2013/12/20 Sze Howe Koh
> On 20 December 2013 04:52, Kuba Ober wrote:
> > Is this supported on all platforms now? IIRC it did not work OS X last
> time I tried, but yes,
> > it did work great on Windows.
> >
> > — Kuba
>
> The Cocoa framework mandates that all GUI-related operations must be
> done in the first thread in a process [1]. That's why this technique
> cannot work on OS X. I believe it was possible with Carbon apps, but
> not Cocoa apps.
>
>
> Regards,
> Sze-Howe
>
> [1]
> http://www.cocoabuilder.com/archive/cocoa/315103-why-is-the-threading-and-ui-updating-designed-to-be-done-only-on-main-thread.html
>
>
> > On Dec 14, 2013, at 3:25 PM, Roland Winklmeier <
> roland.m.winklme...@gmail.com> wrote:
> >
> >> Thanks very much Olivier and Thiago!
> >> That works brilliant.
> >>
> >> No idea why I forgot that QThread must not be used. But its of course
> >> obvious. I made a quick setup with native threads (std::thread is
> >> unfortunately not supported by VC2010) and it works perfectly now.
> >>
> >> In case someone is interested:
> >> - - I added a additional shared library spawning a thread and links the
> >> actual plugin during runtime with LoadLibrary/dlopen. No Qt stuff in
> here.
> >> - - Second shared library creates QApplication object and runs its
> >> exec() loop.
> >>
> >> Cheers Roland
> >>
> >> Am 14.12.2013 19:23, schrieb Thiago Macieira:
> >>> On sábado, 14 de dezembro de 2013 12:42:32, Roland Winklmeier
> >>> wrote:
> >>>> n qthread_win.cpp QThreadPrivate::start -> void
> >>>> QThreadPrivate::createEventDispatcher(QThreadData *data) {
> >>>> QEventDispatcherWin32 *theEventDispatcher = new
> >>>> QEventDispatcherWin32;
> >>>> data->eventDispatcher.storeRelease(theEventDispatcher);
> >>>> theEventDispatcher->startingUp(); }
> >>>
> >>> You must not use QThread.
> >>>
> >>> You need to start your thread before using any QObject-derived
> >>> classes. Once you're there, instantiate the QApplication
> ___
> 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
[Development] QtDBus in official Windows and OSX installers
Hi list, I have a quick question. I know that QtDBus is officially supported for linux platforms only but I'm using it also on windows and OSX platforms successfully since one year now. This means I have to build Qt5 for these platforms myself all the time to include QtDBus. While this is not a big issue for me individually, its hard to distribute the custom build to my team. I have no automatic packaging in place. In the beginning I even did a tarball of the build products. In the meantime we managed to create an offline installer, but they are still far away from being as awesome as the official packages are. Btw. is Qt's Jenkins CI job setup and configuration open and downloadable? I would love to create a Jenkins CI project out of it and let it create packages. This would also solve my problem. But my main question is, is there a chance QtDBus is shipped officially and what needs to be done for that. I guess one point is to run the dbus unit tests, but what else needs to be done to ship it at least in an experimental state? Or is the answer just "No", this will never happen? Cheers Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDBus in official Windows and OSX installers
Am 06.02.2014 18:02, schrieb Thiago Macieira: > Em qui 06 fev 2014, às 17:28:40, Roland Winklmeier escreveu: >> But my main question is, is there a chance QtDBus is shipped officially and >> what needs to be done for that. I guess one point is to run the dbus unit >> tests, but what else needs to be done to ship it at least in an >> experimental state? Or is the answer just "No", this will never happen? > > It should already be included in the Mac installers. If it isn't, it's a > regression bug and needs to be fixed. > > For Windows, I don't know. I know configure.exe can enable D-Bus, but I've > never even tried, so I don't know what it takes. > I haven't checked earlier versions but at least Qt 5.2.1 Mac OSX Clang64 (both online and offline) do not contain any QtDBus modules. I'm wondering how this would be done anyway, should dbus-daemon be shipped with the installer or installed manually? Building for windows is pretty easy. Make sure is in your include path and enable it configure -dbus. Builds and runs fine. --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Requiring minimum GCC 7/MinGW (was: Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral))
Am Do., 22. Aug. 2019 um 22:47 Uhr schrieb Thiago Macieira < thiago.macie...@intel.com>: > On Thursday, 22 August 2019 12:05:39 PDT Danila Malyutin wrote: > > Isn't it already the case: > https://doc.qt.io/qt-5/supported-platforms.html > > ? > > Looks like it. > > I'll dust-off the Q_THREAD_LOCAL patch and send it off through the CI. If > any > platform can't compile it, we'll just remove the platform from the > rotation > until they properly implement C++11 thraed_local. > Just for your awareness: There is an old bug related to thread_local in MinGW which afaik was never fixed. It compiles correctly, but every executable crashes during shutdown. Not sure if this relevant in this case, just mentioning it: https://github.com/msys2/MINGW-packages/issues/2519 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Qt 5.14 MinGW debug build doesn't add debug suffix
Hey everyone, First, happy new year! Second, I switched my nightly build to 5.14 branch and was building debug binaries as usual. Configure arguments: configureArguments=-developer-build -debug -opensource -nomake examples -nomake tests -confirm-license -opengl desktop -dbus -openssl -I D:\Downloads\openssl-1.1.1d-win32-mingw/include The config summary seems to agree with me Build options: Mode ... debug; optimized tools however, the binaries don't have the typical debug suffix: $ ls Qt5* Qt5Core.dll* Qt 5.14 branch pulled this morning pointing to 2c3eaa7b87219d24facfe81a5b22cb218324f1ae. What am I doing wrong? Cheers Roland ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.14 MinGW debug build doesn't add debug suffix
Am Di., 7. Jan. 2020 um 13:52 Uhr schrieb Roland Winklmeier < roland.m.winklme...@gmail.com>: > Hey everyone, > > First, happy new year! > > Second, I switched my nightly build to 5.14 branch and was building debug > binaries as usual. Configure arguments: > > configureArguments=-developer-build -debug -opensource -nomake examples > -nomake tests -confirm-license -opengl desktop -dbus -openssl -I > D:\Downloads\openssl-1.1.1d-win32-mingw/include > > The config summary seems to agree with me > > Build options: > Mode ... debug; optimized tools > > however, the binaries don't have the typical debug suffix: > > $ ls Qt5* > Qt5Core.dll* > > Qt 5.14 branch pulled this morning pointing to > 2c3eaa7b87219d24facfe81a5b22cb218324f1ae. > > What am I doing wrong? > > Cheers Roland > Found the answer myself in https://bugreports.qt.io/browse/QTBUG-80792. I got confused after qmake telling me Qt5Cored.dll could not be found when building my own project. Seems like I need to adopt something to get my project working without the suffix. Cheers Roland ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.14 MinGW debug build doesn't add debug suffix
Am Mi., 8. Jan. 2020 um 20:09 Uhr schrieb Thiago Macieira < thiago.macie...@intel.com>: > On Wednesday, 8 January 2020 10:10:06 PST Sérgio Martins via Development > wrote: > > Wondering if there's a reason why the suffix is needed in the first > > place... > > I thought only MSVC had problems mixing debug and release runtimes. > > Correct. > > We stopped adding the suffix in MinGW builds. > > I wonder what happens to debug-and-release builds now. > I was doing a normal release build of Qt itself and tried to build a sample project (created with QtCreator - new empty application project called debug) with debug flags and got: mingw32-make: *** No rule to make target 'D:/projects/qt5/qtbase/lib/libQt5Cored.a', needed by 'debug.exe'. Stop. Release build works fine. So something inside Qt still expects the d extension. It might has something to do that I used win32-clang-g++ as compiler. But I think the same happens with a regular MinGW built. Is this already known or shall I raise a bugreport? Cheers Roland ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.14 MinGW debug build doesn't add debug suffix
Am Fr., 10. Jan. 2020 um 09:40 Uhr schrieb Roland Winklmeier <
roland.m.winklme...@gmail.com>:
> Am Mi., 8. Jan. 2020 um 20:09 Uhr schrieb Thiago Macieira <
> thiago.macie...@intel.com>:
>
>> On Wednesday, 8 January 2020 10:10:06 PST Sérgio Martins via Development
>> wrote:
>> > Wondering if there's a reason why the suffix is needed in the first
>> > place...
>> > I thought only MSVC had problems mixing debug and release runtimes.
>>
>> Correct.
>>
>> We stopped adding the suffix in MinGW builds.
>>
>> I wonder what happens to debug-and-release builds now.
>>
>
> I was doing a normal release build of Qt itself and tried to build a
> sample project (created with QtCreator - new empty application project
> called debug) with debug flags and got:
>
> mingw32-make: *** No rule to make target
> 'D:/projects/qt5/qtbase/lib/libQt5Cored.a', needed by 'debug.exe'. Stop.
>
Found the problem:
diff --git a/mkspecs/features/qt_functions.prf
b/mkspecs/features/qt_functions.prf
index 45d4492788..ef2bb17c5d 100644
--- a/mkspecs/features/qt_functions.prf
+++ b/mkspecs/features/qt_functions.prf
@@ -5,7 +5,7 @@ defineReplace(qtPlatformTargetSuffix) {
else: CONFIG(debug, debug|release) {
!debug_and_release|build_pass {
mac: return($${suffix}_debug)
-win32: return($${suffix}d)
+ msvc: return($${suffix}d)
}
}
return($$suffix)
Cheers Roland
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
Am Mo., 4. Jan. 2021 um 14:38 Uhr schrieb Benjamin TERRIER < b.terr...@gmail.com>: > > > On Mon, 4 Jan 2021 at 14:14, Oswald Buddenhagen > wrote: > >> On Mon, Jan 04, 2021 at 10:55:03AM +, Tuukka Turunen wrote: >> >With Qt 6.0.0 released and the first patch release (Qt 6.0.1) coming >> >soon, it is time to enter the commercial-only LTS phase for Qt 5.15 >> >LTS. >> > >> that's some brilliant timing, given that no actual qt 6 release even >> exists yet. (yeah, 6.0 is a joke given that you intend to break binary >> compat in 6.1 - that's the wisdom of linking r&d's bonus payments to >> release dates even for major versions). >> >> > Yes, it would have made sense that the Qt Company waits for all modules to > be available in Qt 6 before dropping the 5.15 open support... > I cannot express how much I agree to this. Qt6 has half of the modules required by my project not yet available, so upgrading is not possible. On the other hand, 5.15 LTS is closed for the open source users - this is quite a heavy restriction for me since my project is non-profit and open source. Buying a commercial license is not an option. Yes I'm aware that I'm a small fish in a large pond and QtC won't care about my contributions or me as a developer using Qt since there is no profit to make with me. On the other hand, I will carefully think about using Qt again in future projects or recommend it to other people. This is not a complaint. Its your business and your rules. I'm just trying to express the thoughts of a bigger but usally silent group of open source/non-profit users which are directly impacted by this. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January
Am Mo., 4. Jan. 2021 um 15:57 Uhr schrieb Tuukka Turunen <
tuukka.turu...@qt.io>:
>
>
> Hi Roland,
>
>
>
> Just so that there is no misunderstanding Qt 5.15.2 release stays
> available for all users, it is just the upcoming LTS phase patch releases
> that will be commercial only. In essence for the open-source users Qt 5.15
> is similar to Qt 5.13 and Qt 5.14 (non-LTS releases).
>
Tuukka,
I'm aware of that, but the upcoming LTS phase patch releases are exactly
what I need. If there was a bug in the last 5.13 release, I could upgrade
to 5.14.{0,1} which typically included the fixes after the last 5.13
release. Qt6 does not yet include many important modules, so I have nothing
to upgrade to until 6.1 or 6.2.
Also not every open source project is interested to track the bleeding edge
releases, but I was rather interested in stability, hence following LTS
releases.
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt6 repo
Alex Blasche schrieb am Mi. 13. Jan. 2021 um 11:58: > > -Original Message- > > From: Development On Behalf Of > > Nibedit Dey > > Is there any plan to move the qt6 source code to a different repo (qt6)? > > Currently, the branch lies inside the qt5 repo. > > Is there going to be a Qt6 super module in near future? > > Thiago's reply from the interest mailing list still stands. There has not > been any discussion or plan being made. Well, how about starting a discussion then? I guess that was the intention of the originator. > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Add QTBUG title to new release changelog
Good morning, I was curious to see what changed in Qt 6.0.2 release and found a list of fixed QTBUGS: [qtbase] 443ce5d073 Fixes: QTBUG-89578 b61275ee72 Fixes: QTBUG-90042 e255716291 Fixes: QTBUG-74088 The QTBUG number itself does not tell me much, hence it is very hard to predict if anything relevant is in that release affecting my projects. How hard would it be to change it to [qtbase] 443ce5d073 Fixes: QTBUG-89578 QLineEdit Cursor show white line when use property of setInputMask b61275ee72 Fixes: QTBUG-90042 QIcon not using Hi DPI pixmap version e255716291 Fixes: QTBUG-74088 Menu Bar Items Disabled When QMainWindow Has Window Modal Child and Another Window Made Active That would be much easier to read. Cheers Roland ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open?
Dear list, I'm trying to understand a strange situation and hope you can enlighten me. In December I have raised QTBUG-49971 (a FTBFS bug) since it was not possible to build MinGW 4.9 with the alpha sources and also from git since then. The issue is obvious: Commit e19bedc8466a6b8086a0048b7b88c0f6d3fa822f introduced ''WINAPI_FAMILY_PC_APP" which is defined in the MSVC Windows API but not in MinGW 4.9. So the built with MinGW fails. So how is it possible that this error does not show up in CI? I did download the Qt MinGW 4.9 version, so CI should fail to build. Does anyone have an idea why it passes anyway? Cheers Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open?
2016-03-03 9:14 GMT+01:00 Thiago Macieira : > On quinta-feira, 3 de março de 2016 00:06:41 PST Thiago Macieira wrote: > > On quinta-feira, 3 de março de 2016 08:56:35 PST Roland Winklmeier wrote: > > > So how is it possible that this error does not show up in CI? I did > > > download the Qt MinGW 4.9 version, so CI should fail to build. > > > > -Wundef is not enabled by either -Wall or -Wextra. It's entirely correct > C > > source to #if on undefined tokens: they become zeroes. > > > > -Werror is never enabled to end-users either, so QTBUG-49971 is not a > real > > FTBFS. > > But -Wundef and -Werror are part of our headersclean target. So you have a > point: how is the CI building this? > No matter if I download the source from download.qt.io or clone from git and run the normal build as configured in CI, I get the build error. I'm not changing any flags. So my and CI configuration should be exactly the same and either both pass or fail. But CI passes and the build of several people locally fail. I wonder how thats possible. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open?
2016-03-03 16:51 GMT+01:00 Thiago Macieira : > On quinta-feira, 3 de março de 2016 10:51:40 PST Roland Winklmeier wrote: > > No matter if I download the source from download.qt.io or clone from git > > and run the normal build as configured in CI, I get the build error. I'm > > not changing any flags. So my and CI configuration should be exactly the > > same and either both pass or fail. But CI passes and the build of several > > people locally fail. I wonder how thats possible. > > Can you give us the command-line of the compilation that failed? Like I > said, > -Werror=undef is not supposed to be enabled by default, unless you turn > headersclean on. And that's not the default. > > Note that -developer-build turns it on. But if you use that option, you > say "I > will fix bugs I find too". > I think that is the "mistake" I did. I'm pretty sure I tried the -developer-build. There is now a fix on the way and it was always easy to workaround the problem when building locally. I also understand why CI passed (no developer-build turned on) and everything makes sense now. I'm going to try once more with latest RC sources and then it should be good. Thanks everyone. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Does Qt 5.6 still depend on ICU?
Dear Qt Devs, I'm currently preparing installers for a cross platform application (Win, Linux, OSX). I have investigated, which dependencies apart from the Qt5 libraries themselves are need to be shipped as well. But I'm a bit confused about the role of ICU. >From wiki pages (https://wiki.qt.io/Qt_5.6_Tools_and_Versions and https://wiki.qt.io/Building_Qt_5_from_Git), I understood that, ICU is only required for QtWebkit. I also learned that the ICU version shipped in Qt 5.6.0 is 56.1. However, I found the following facts a bit inconsistent: * Windows is actually shipping 54.1 instead of 56.1. Was the upgrade missed or is this on purpose? To me it is a minor issue, but I'm curious. * Official Windows QtCore binary is not linked against ICU libraries (at least from what I can see in dependency walker). Does it link at runtime? * Official Linux QtCore binary in contrast is linked against ICU (verified with ldd). * Official OS X QtCore binary again is not linked against ICU. Now my question: Is ICU mandatory for all platforms or maybe only for Linux? Ideally I could just skip shipping it in my installer, since I'm using a custom Qt5 build on my Debian server (I did not yet manage to use the official installer on a headless server with an install script). But I want to be sure, what features I'm loosing before any decision. ? *guess mode on* I guess, ICU was shipped previously because of QtWebkit. Since QtWebkit is no longer shipped in official installers, could ICU also be removed? I know what ICU is, but why is it shipped without linking against it? *guess mode off* Cheers Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Does Qt 5.6 still depend on ICU?
On 05/08/2016 01:10 AM, Thiago Macieira wrote: > On sábado, 7 de maio de 2016 23:25:16 PDT Roland Winklmeier wrote: >> From wiki pages (https://wiki.qt.io/Qt_5.6_Tools_and_Versions and >> https://wiki.qt.io/Building_Qt_5_from_Git), I understood that, ICU is >> only required for QtWebkit. I also learned that the ICU version shipped >> in Qt 5.6.0 is 56.1. >> >> However, I found the following facts a bit inconsistent: >> * Windows is actually shipping 54.1 instead of 56.1. Was the upgrade >> missed or is this on purpose? To me it is a minor issue, but I'm curious. > > Looks like a mistake. Do you want me to raise a bug report? >> Now my question: >> Is ICU mandatory for all platforms or maybe only for Linux? Ideally I >> could just skip shipping it in my installer, since I'm using a custom >> Qt5 build on my Debian server (I did not yet manage to use the official >> installer on a headless server with an install script). But I want to be >> sure, what features I'm loosing before any decision. ? > > It's mandatory for none. You can choose if you build from sources, but note > that the POSIX fallback for Unix systems is of much lower quality. > > The choices made for the binary builds are just that: choices. > Thanks a lot. Now it is much clearer to me. I'll follow the official release binaries choice and link my custom Linux build against ICU. Cheers Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Symbol strip warnings when installing release products on Mac OS X since 5.6.1
Dear list, I have upgraded my Mac OS X CI node to Qt 5.6.1. Since then I see several warnings at the build step 'make install' similar to: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: symbols referenced by indirect symbol table entries that can't be stripped in: /Users/jenkins/workspace/macosx_qt_5.6.1/build/dist/lib/ __ZN5QIconC1ERK7QPixmap __ZN6QBrushC1ERK6QColorN2Qt10BrushStyleE __ZN6QBrushD1Ev __ZN6QColor13setNamedColorERK7QString __ZN6QColor6setRgbE __ZN6QColorC1EN2Qt11GlobalColorE __ZN6QImage4fillEN2Qt11GlobalColorE ... After some investigations, I found a difference between 5.6.0 and 5.6.1. 5.6.1 added a strip step for release builds, which was previously not there: -$(STRIP) $(INSTALL_ROOT)/Users/jenkins/workspace/macosx_qt_5.6.1/build/dist/lib/$(TARGET) After bit of googling I saw similar bug reports on KDE [1] and adding '-x' fixed it, but I'm not a strip expert. Question is now, am I doing anything wrong or was this an intentional change in 5.6.1? How can the warnings silenced best? Cheers Roland [1] https://bugs.kde.org/show_bug.cgi?id=288756 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt 5.9
> On 28 Nov 2016, at 16:40, Alexander Blasche wrote: > > Ok, let's summarize and restate the package list for Qt 5.9 based on the > comments provided on this mail thread. The list describes the delta to Qt 5.8 > packages: > > * MinGW remains 5.3 using 32 bit Since I'm using MinGW binaries in 32 bit and 64 bit mode (as plugins for flight simulator applications which exist in 32 and 64 bit), I would be very happy to have both as official MinGW installers. Especially since the MinGW debug binaries are huge compared to the MSVC ones. So I tend to use 64 bit ones (up to now self compiled from source) whenever possible. Would it be an option to add the MinGW 64 bit installer and keep the 32 bit one? Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17
2017-02-15 12:52 GMT+01:00 Shawn Rutledge : > > > On 15 Feb 2017, at 11:11, Marc Mutz wrote: > > > > On Wednesday 15 February 2017 10:36:33 Sean Harmer wrote: > >> First of all, apologies for not being able to make the release meeting > >> yesterday. I was in a workshop all day. > >> > >> For the record I think skipping 5.8.1 is a big mistake. I would much > rather > >> delay 5.9 by a few weeks and have a 5.8.1 release out than skip it and > try > >> for a quick 5.9.0. > > > > Amen. > > > > I would like to add that this decision, made behind closed doors, does > not > > match well with Qt-as-an-open-governance-project. In particular, it > feels like > > we OSS contributors are being held hostage here. If you close the 5.8 CI, > > anything we can do, incl. following the dictate of TQC to focus on 5.9, > will > > hurt Qt users one way or another. Either we fragment Qt by releasing a > 5.8.1 > > without TQC backing or we leave users hanging in the air for extended > periods > > of time without the ability for bugfixes. Both are unacceptable, IMHO. > > There are a lot of potential bug fixes. Skipping 5.8.1 might pull some > users into upgrading to 5.9 sooner than they might otherwise, which is good > from one side, but the ones who are afraid of new features and new > regressions will resist. So I think it’s a mistake because of those > people… > Speaking for myself, I also think, skipping 5.8.1 is a mistake. We just upgraded our project from 5.6 to 5.8 and realized that it had several regressions. For example we are using a QNetworkAccessManager and for random reasons it always switches to NotAccessible after some minutes. No recovery possible except restarting the application. I wonder why nobody else got affected by this. I _think_ the cause was QTBUG-51543, even though I never finally understood whats going on. In any case, the fix for this bug went into 5.8.1, which now won't get released. For me this is very frustrating, since we counted our next milestone on an early 5.8.1 release. Now I would have to wait for 5.9.0 which is planned end of May if everything goes smooth. Even then, there is no guarantee that there is no new regression which would require 5.9.1 release. I also can't produce custom builds, since I never managed to create a custom offline installer for my team members (we are are non profil OSS group without many infrastructure and resources). I do regular builds of Qt itself, but the rest is out of my capabilities. In summary, for me it is very unfortunate that I have to delay our milestone minimum until June if everything goes well. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Features in Qt-5.3
2014-02-27 12:11 GMT+01:00 Wolfgang Baron : > > On Wed, 26 Feb 2014 07:40:31 -0800, Thiago Macieira < > thiago.macie...@intel.com> wrote: > > > Em qua 26 fev 2014, ?s 12:18:41, Kevin Krammer escreveu: > > > On Tuesday, 2014-02-25, 09:00:21, Wolfgang Baron wrote: > > > > Hi all, > > > > > > > > I read somewhere, that there are plans for a pure-Qt QtDBus (not > using > > > > dbus-1) implementation in Qt-5.3, which would run on all platforms > > > > (including mswindows). > > > > > > QtDBus already works on Windows. > > > As far as I know it is just not built by default. > > > > That is true. > > I know it works, I have been using it for years now. Having to compile my > own Qt binaries all the time is just very annoying, so I am looking forward > to a compiled QtDBus in the official Windows binaries. > > > And one of the reasons why it isn't built by default is the lack > > of libdbus-1 headers on Windows systems. Once we no longer depend on > > libdbus-1, QtDBus will be enabled by default on all platforms. > > I don't understand the problem. The freedesktop.org headers work nicely. > Their license should not be the problem either. You could leave compiling > the dbus binaries to the customer (it's a breeze). Are there any other > reasons? > > Kind regards, > > Wolfgang Baron > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > +1 for shipping QtDBus with Windows binaries. As far as I know, OSX has the same problem. It does not have DBus headers/binaries installed by default, so you have to take of them yourselves. Currently QtDBus is not shipped in OSX installers either, but it got requested for the next release. So why not doing the same for windows? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Features in Qt-5.3
2014-02-27 18:20 GMT+01:00 Thiago Macieira : > Em qui 27 fev 2014, às 12:32:36, Roland Winklmeier escreveu: > > Because we haven't received requests for this. We have for OS X, going as > far > back as Qt 4.3. > Sorry for this stupid question, but how must a request look like? I would very much appreciate to have QtDBus in the official windows installers, ideally in Qt 5.3 already. I have no idea how much effort that is, but I would of course contribute to any required task to get it done. Just tell me, what needs to be done. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
Am 21.04.2014 05:27, schrieb Joshua Kolden: > I’m curious why you are not interested in QML. > > I’m just finishing up a an initial production release of software oriented > towards high-performance graphics. We used QML for the interface, > coffeescript for view logic, and Qt/c++ for processing and business logic. > It works astonishingly well sine we can design and build the UI separately > from the business logic, and designers can work interactively without a > compilation step, while the business logic can worry about threads and other > performance processing complexity without regard to the event loop, just > throwing things over the fence to the UI when ready. > > I see no reason to stay with Qt Widgets at all other than legacy application > support. So what is your concern? Is it just that you don’t what to go from > being an expert in the tools you already know to an beginner at new tools, or > are you up to speed on QML and you have some details on why this approach is > a bad idea? I haven’t found any major issues, other then a few bugs and > missing features that will be fixed soon enough. > > Please don’t read this as me being facetious, I’m genuinely looking for any > information that would indicate the we are on the wrong path with our > application design. > > Thanks, > j > > > On Apr 20, 2014, at 6:40 PM, Michael Knight wrote: > >> I feel like Qt is going in the direction of being Qml and Javascript only.I >> fear that they may abandon Qt Widgets in the near future,I think they are >> heavily promoting Qml.I don't want to use Qml,and before I start using Qt,I >> want to be sure that they will not abandon C++ side of Qt and that they >> continue to develop C++ side.It seems to me that they are developing Qml >> side >> mostly. >> >> What do you think about this? > I'm working for a Flight Simulator addon project which was initiated 1 year ago. When we started with the UI part, QML was heavily promoted in Qt5 to be the future of Qt and I also got the feeling that QtWidgets are not longer developed (except of bug fixing and minor features - but the focus is now on QML). I hadn't used QML or QtQuick before at all, so I looked into it and the demonstrations were indeed nice. So we started to design our UI with QML. I liked the design to split business logic into C++ and UI design into QML and I still like it, but I came across several blocking issues (some of them are only valid for our application, some of them are general): - Our application has a huge framework of value classes. They cannot (or at least it does not make sense to) derive from QObject for several reasons. But subclassing QObject is the requirement to access data from C++ in QML. So we had our framework of well designed value classes and cannot use them in QML. There were evaluations to create QObject wrappers, but no nice solution. So no support for value classes is probably a show stopper for many projects. With Widgets we were able to use them easily. - When we did our QML tests, I got the feeling QML in general is not yet stable enough. The performance was not always the best (e.g. scrolling in a table view was not smooth). - UI components: QML did not have the set of standard UI components. I know this is currently changing with QQuickControls but one year ago, there wasn't much. So Widgets were easier to start with. - Memory consumption: Even a mini example took about 70 MB of memory, QtWidgets need a lot less. This is not a complain, I know the JS runtime needs its initial memory. It was just one factor, because our application is running as an addon to Flight Simulators and they usally consum a lot memory. This is especially a major problem with MS Flight Simulator since it is only available as 32 bit application. Therefore every any MegaByte is important. Dont get me wrong. I'm excited about QML. Doing UI design in C++ is awfull and QML really would improve things. The current implementation is good for some projects, but it is not the solution for everything. There are still even new projects going back to QtWidgets (as we did), because QML is not suitable. So to me its not only legacy support. However I rethink my descision when most the above points are addressed in later QML versions. --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
>> >> - Our application has a huge framework of value classes. They cannot (or >> at least it does not make sense to) derive from QObject for several >> reasons. But subclassing QObject is the requirement to access data from >> C++ in QML. So we had our framework of well designed value classes and >> cannot use them in QML. There were evaluations to create QObject >> wrappers, but no nice solution. So no support for value classes is >> probably a show stopper for many projects. With Widgets we were able to >> use them easily. > > Hmm, I’m not sure what you mean by value classes. Do you mean literally data > models? You don’t need to move QObjects across to QML if you are just > sending data for display in the UI. We have lots of complicated data types > that we simply save in QVariantMaps, and they show up as javascript objects > in QML. You may not have this flexibility, but as the application designer on > our project I don’t allow anyone to put new classes into QML from c++ unless > they directly drive a viewable element, because that contaminates the view > layer with business logic, following the MVC pattern. I wouldn’t allow that > with widgets either. > The term value classes is due to history reasons in our project. We started creating classes to handle physical values. Hence the name. Some of them are data models representing entities (e.g. aircrafts) and also abstract items (e.g. altitude, callsign, flightplan). All these classes have an advanced API and logic written in C++, for example CAltitude has complex API methods to get the value in different units. We also use them as a property/value for example to assign it to an aircraft: setAltitude(const CAltitude &altitude). If I want to access this methods from QML I would have to derive them from QObject and register it in the QML context. I remember QVariantMaps were also discussed. I cannot remember exactly why we finally did not use them. But I guess QVariantMaps are only for easy types. Maybe there is a way to do it and I have overlooked it. I can remember some discussion in this list (http://lists.qt-project.org/pipermail/interest/2013-October/009202.html) and also in IRC saying, some kind of value class support is planned. For the time being it was a lot easier to call a c++ method getAltitude(AltitudeUnit unit) from QtWidgets than QML :) --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
>
>
> > > If I want to access this methods from QML I would have to derive them
> > >
> > > > from QObject and register it in the QML context.
> > >
> > > Not necessarily, depends on what you want to do.
> > > However, it is true that it would be nice to have something similar to
> > > QtScript's binding facilities.
> >
> > Agree with Roland. Must. I MUST have "Cytometer" and "Laser" and
> > "Wavelength" exposed to QML.
> >
> > In only the "simplest-of-toy-applications" could we pretend that a
> > "QmlCytometer" exposed to QML has a vector-of-double values to represent
> > the "several-wavelengths" that might be associated with that "cytometer".
> >
> > In our system: We code-gen to wrap everything. "Wavelength" is now a
> QML
> > exposed property of "Laser", which is a QML exposed property of
> "Cytometer".
>
> What I meant was: what kind of operations in QML do need access to these
> compond types?
>
> For example in a widget based UI you wouldn't have a standard widget [1]
> that
> knows how to display or enter a Wavelength, right?
>
> You would have some adapter code that will take a Wavelength object and
> then
> process it into something a standard widget can handle.
>
> Why does the adapter code no longer suffice?
>
> Since I don't know about your data types let me try a different example.
>
> If I had the need to display width/height/depth of an image I would likely
> have a widget that has three labels or read-only spinboxes, neither of
> which
> can read the image properties themselves.
>
> So I would have adapter code that takes a QImage and accesses its width(),
> height() and depth() methods and put those into the widgets.
>
> As far as I can tell I could use the exact same adapter code if the UI was
> in
> QML.
> For additional declarative niceness I might be inclined to expose the
> wrapper
> in the form of a type with an image property for input and three
> appropriately
> named integer properties for output.
> But the actual adapter code would be the same.
>
What you are saying is correct and I'm not an expert in GUI design (sorry
if my explanations violate any Model-View theorems), but here is a real
world example.
Lets say we have a UI to display the Com and NAV frequency settings of your
aircraft. The whole aircraft is encapsulated in a CAircraft which looks
similar to this
class CAircraft
{
public:
CComDevice getCom1() const;
private:
CComDevice m_com1;
CComDevice m_com2;
CNavDevice m_nav1;
CNavDevice m_nav2;
}
class CComDevice
{
enum Unit
{
MHz,
kHz
};
CFrequency getFrequency(Unit unit) const;
private:
CFrequency m_frequency();
}
In a C++ QtWidget environment I'm now able to do the following to display
the frequency in a widget:
dataModel->getAircraft().getCom1().getFrequency(chosenUnit).toQString();
The main points are that at the time of writing the C++ model I don't know
which unit the user might select during runtime - MHz or kHz. So I need to
invoke getFrequency or call it from a wrapper.
In general I don't know what a GUI designer might need.
The second point is that the C++ data models are nested a lot and they are
easily accessible in C++ code because C++ of course knows how all these
data classes look like. The idea behind that is, the GUI designer can
choose what he wants to display and how. This is transparent to the C++
models.
Ideally I can to the same via QML by accessing the property hierarchy. This
would mean my data models are decoupled from my QML view implementation:
dataModel.aircraft.com1.frequency.string
but that requires of course that all classes are known in the QML context
which is not possible (if they dont subclass QObject).
As you said I can of course create C++ wrappers specific to a view, add the
line
dataModel->getAircraft().getCom1().getFrequency(chosenUnit).toQString();
into it and transfer the result as a QVariant, but that also means QML is
limited to what the wrappers provide. This is a loss of flexibility
additional to the effort writing the wrapper. This is of course possible
but not nice. Widgets are a lot more flexibel. If I want to display
different data in my view, I have to add/change only one line C++.
I'm missing this flexibility in QML to walk through my nested objects and
display in QML whatever I like. Having that, I would be a fan of QML :)
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] QtQml value types
Hi list, we discussed the topic whether non-QObject types can be used in QML or not several times. The last time is only a few days ago as part of the Qt future discussions. So I had some thoughts what needs to happen to solve this issue. I can remember someone told me there are plans to add such a feature. So my first question is, how far are we on this? Is it just a plan or is someone really working on it already? Are there any details? If there is nothing happening at the moment, I'd like to share some ideas I had during the last days. I'm not an expert in QtQuick/QML internals so I have no idea what might be possible or not. At the moment I assume only QObject derived classes can be used in QML contexts. Charley's presentation ( http://www.qtdeveloperdays.com/sites/default/files/presentation_pdf/QtDevDaysSFO-2013_WrappingCppForQml_final.pdf) was very interesting to me as I see this as a possible workaround until something more sophisticated is in place. During discussions in our team one of the members pointed me to internal class QQmlValueType ( https://qt.gitorious.org/qt/qtdeclarative/source/HEAD:src/qml/qml/qqmlvaluetype_p.h). This is used to make Qt value types like QSize, QPointF available through a QObject wrapper and is very similar to what charley presented. Now I wonder can't we just make this (or something similar) available as a public API? This would allow developers to add their custom types without much effort and would solve a lot problems. I don't think this is much effort but it will help a lot. Thoughts? Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtQml value types
2014-04-24 22:42 GMT+02:00 Dominik Holland :
>
> I like that idea, but couldn't we do something like this ?
>
> qRegisterWrapper(qMetaTypeId())
>
> MyWrapper is a QObject based class which can whatever you want and gets
> YourType as reference or per value.
>
> It would mean you create your wrapper once for all your Types of your
> Interface and afterwards the QmlEngine will create the Wrapper
> automatically for every object which is exposed to QML.
>
> I could also think of having some automatically created wrappers for
> QList.
>
>
> The wrapper itself gives you the flexiblity to decide whether you can
> support changedSignals of what functions you want to expose to QML.
>
> In the end it would also be great to register the Wrapper as a own QML
> Type to be able to create the object in QML.
>
> Dominik
>
>
This is similar to what I had in mind in first place. I don't have
experience with the Qt script engine and how powerful it is, so I cannot
really comment on it.
To my knowledge QObject wrappers are the only solution atm to expose type
safe variables, because signals and slots require the QObject base class.
QQmlValueType is a good starter. It needs for sure some improvements and
careful thinking, but it is the easiest way of doing it.
Unfortunately it produces a lot boiler plate code, cause you have to write
a wrapper for each non-QObject class you want to expose. In an ideal world
we could register them without any wrapper (although I don't know how we
would bind their methods then). In a nearly perfect world we would have a
generator for this wrappers, similar to moc. You for example mark your
custom class with some macros and a generator creates the wrappers for you
during compile time.
class MyValueClass
{
VALUE_PROPERTY( int value READ value WRITE setValue )
VALUE_PROPERTY( int anotherValue READ anotherValue WRITE
setAnotherValue )
public:
MyValueClass();
~MyValueClass();
int value() const;
int anotherValue() const;
setValue(int value);
setAnotherValue(int value);
private:
int m_value;
int m_anotherValue;
};
Doing wrappers manually is a bigger maintenance effort to keep both in
sync, an automatic step would reduce the burden.
The explanations regarding QVariantMap were really interesting and for
smaller projects this is for sure a good idea. But as others already said,
it has several drawbacks. In general, however, you explanations about MVC
made sense.
The line
dataModel->getAircraft().getCom1().getFrequency(chosenUnit).toQString();
can for sure moved into a model/controller class dedicated to a specific
view. But in this case i still need to transfer a CFrequency object to QML
and no QString. The reason is simple and you immediately see it if you look
into the API of CFrequency:
class CFrequency
{
public:
enum FrequencyUnit
{
Hz,
MHz,
kHz,
};
double getValue(FrequencyUnit unit);
...
private:
int m_siValue;
};
It has only one private member, but the returned value from getValue
depends which Unit you want to have and is automatically calculated during
runtime. Imagine a class CTemperature, which has the value in celsius but
someone wants it in Fahrenheit getValue(TemperatureValue::Fahrenheit);.
Which values would you put into QVariantMap? The SI value or all of them?
The design of this classes is, that you can decide during runtime, which
value you want to display depending on the application settings.
Theoretically I could create a controller class doing this step for me. So
the view class provides the unit as user input and the controller class
updates the QVariantMap. But this would mean, I have a stupid view class
and have to do all the logic in C++. This is fine if I use plain QML, but
as soon as I want to do some logic in JS, the engine needs to know the
types.
So to summarize, we are discussing two different concepts:
* In order to use plain QML, QVariantMap can be sufficient. QML as the view
implementation does not need to know the data structure.
* As soon as someone wants to move some logic from C++ into JS, JS needs to
know the data type.
According to my understanding it is the second one we are discussing here.
Roland
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
2014-04-27 13:31 GMT+02:00 Peter Kümmel : > On 21.04.2014 13:39, Roland Winklmeier wrote: > > - Memory consumption: Even a mini example took about 70 MB of memory, > > QtWidgets need a lot less. This is not a complain, I know the JS runtime > > needs its initial memory. It was just one factor, because our > > application is running as an addon to Flight Simulators and they usally > > consum a lot memory. This is especially a major problem with MS Flight > > Simulator since it is only available as 32 bit application. Therefore > > every any MegaByte is important. > > Especially on "non-fat" embedded systems this is a problem: > When you wanna use Linux you need some MBs Ram for the kernel, > some to get a running system, and some MBs for your application. > So you end at minimum 5-32MBs. > Then adding 100MB just to run QML really hurts, and you start > looking for alternatives, like using only QWidgets with very > limited OpenGL support or not to use a Qt-GUI at all. > > Maybe such systems are also interesting from a business perspective. > I did a test with Qt 5.3 beta using an nearly empty dialog and the numbers aren't that bad: Dialog with two buttons and one menu (release build) QtWidgets: about 15 MB QML: about 29 MB. The numbers came from TaskManager, so no idea how reliable they are. The 70 MB came from a more complex application. I cannot tell how memory increase is associated with the complexity of a QML project. So one would really need to perform a more sophisticated benchmark. But its definitely not 100 MB just for the JS engine. Sorry if I caused confusion or mixed the numbers in my head. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtDBus roadmap
Hi there, this quote originated from "Request for a sandbox area: Replicant", but I did not want to hijack this discussion for something different. On 05/31/2014 01:33 AM, Thiago Macieira wrote: > One of the goals for QtDBus is to replace the need to have libdbus-1 > installed. We discussed this at QtCS last year and we all agreed this is the > future, but work has not happened. This is required for kdbus support on > Linux. See the notes from last year: > http://qt-project.org/groups/qt-contributors-summit-2013/wiki/QtDBus_CS > > Correct, but only because libdbus-1 does not offer native support for > encryption and authentication. It does offer a "d-tube" functionality, which > is > simply getting and setting the bytes that correspond to one D-Bus message, so > that the upper layer could send over their preferred communication method. By > using this, we'd be able to put the bytes over a QSslSocket provided by the > user and thus execute RPC securely. > > Converting QtDBus to use "d-tube" is one of the steps in getting rid of the > lidbus-1 dependency altogether. See the QtCS link above. > > Once we get QtDBus independent of libdbus-1, it should be possible to simply > provide an opened, bidirectional QIODevice* to a QDBusConnection and would do > the communication for you. > Having a QtDBus connection via an encrypted ssl socket would be super awesome. And here is my question: How far is this libdbus-1 replacement? I have read the work has not been done yet. Is it because there wasn't the time to do it or are there any blocking points? Is there anything I can contribute to and help to get it implemented? Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtMultimedia and Musepack
Am 22.08.2014 14:04, schrieb Cornelius Hald: >> I recently ported application from Qt4 to Qt5 and I rewrote a bit the >> audioplayer in it. Now it is using QtMultimedia instead of Phonon. >> There is an unresolved dependency issue with the combination Qt5 - GStreamer: Qt5 uses GStreamer on Linux, GStreamer itself uses libproxy, which again interfaces with Qt4 and bombs the application. Qt5 -> GStreamer -> ... -> libproxy -> Qt4. https://bugs.kde.org/show_bug.cgi?id=323407. I'm not sure who is in charge to fix this (if there is someone at all). KDE closed the bug report, because its of course not their fault. Up to now, I'm not aware of any workaround. --- Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus Schutz ist aktiv. http://www.avast.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtDBus Improvements
On 09/30/2014 01:49 PM, Thiago Macieira wrote: > On Tuesday 30 September 2014 12:22:26 Daniele E. Domenichelli wrote: >> So, are these improvements still in the plan for QtDBus? Has anyone else >> been working on them? Where can I start? > > Hi Daniele > > Yes, those are still the targets and so far no work has happened. > Hi there, as I'm using DBus on several platforms (Linux, Mac and also Win) I'm eager to get these improvements done. Especially DBus per default in Windows installers would be very nice. Therefore I'm happy to help and contribute, if there is a concrete task to do. I would especially be interested to be work on DBus across machines in the network (also called remote DBus). I understood it could be possible via a ssl socket. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Why is QSignalSpy using Qt::DirectConnection?
Dear list, quick question: I spotted the class QSignalSpy while writing unit tests for one of my projects. There was nothing written in the documentation, that it is not thread safe and had assumed it is. So I connected signals from a QObject running in a different thread and got several warnings (timers cannot be killed, etc). After inspecting its header file, I saw the usage of Qt::DirectConnection. if (!QMetaObject::connect(obj, sigIndex, this, memberOffset, Qt::DirectConnection, 0)). I wonder now if this is intended or the two occurrences can be changed to Qt::AutoConnection. if (!QMetaObject::connect(obj, sigIndex, this, memberOffset, Qt::AutoConnection, 0)). That should make the class pretty thread safe, no? There is even a suggestion report: https://bugreports.qt-project.org/browse/QTBUG-40616. If you guys are happy, I'll send the patch to gerrit. But before doing it, I wanted to check with you, if there is anything I might have missed. Cheers Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why is QSignalSpy using Qt::DirectConnection?
> > QSignalSpy::wait() isn't thread-safe because it's using QTestEventLoop > instead > of a regular QEventLoop. That former does use a timer and, unlike the > latter, > you can't stop the loop from outside the loop's own thread. > That was indeed the origin of the warnings. They appeared after introducing lines with QSignalSpy::wait(). I suspected a bug in Qt, because my derived QObject did not start any timers and was actually pretty empty. It has only 2 dummy methods which trigger two different signals. I'll have a look QTestEventLoop then. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why is QSignalSpy using Qt::DirectConnection?
As promissed I had a look into QTestEventLoop.
> QSignalSpy::wait() isn't thread-safe because it's using QTestEventLoop
> instead
> of a regular QEventLoop. That former does use a timer and, unlike the latter,
> you can't stop the loop from outside the loop's own thread.
Just to be sure: The reason why you cannot stop a QTestEventLoop from
outside the loops own thread is because of the running timer?
QTestEventLoop owns a QEventLoop and extends it with the timer.
Anyhow, I found a potential fix and would like to hear your opinions
before submitting it.
Lets say QSignalSpy runs in thread 0, while another QObject runs in
thread 1. When running QSignalSpy::wait() two situations can happen:
1. QTestEventLoop's internal timer will time out and exit its own loop.
Since QSignalSpy and QTestEventLoop run in the same thread 0, it's all fine.
2. The connected signal is emitted and QSignalSpy will try to stop the
event loop internally in its slot. Due to the Qt::DirectConnection, this
will happen in the thread which emitted the signal, so thread 1 -> Error
message.
The easiest fix would be to make QTestEventLoop::exitLoop() thread-safe
by adding the if condition at the beginning of the method:
if (thread() != QThread::currentThread())
{
QMetaObject::invokeMethod(this, "exitLoop", Qt::QueuedConnection);
return;
}
If it is called from a different thread, it will post an event into its
own event queue and call the slot again from the correct thread and
execute there.
Would this fix be acceptable?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] qmake command line assignments are not considered by config.tests
Dear Qt devs, I addressed the question below first to the interest list. But since nobody replied, I did some investigations and found out this behavior is caused by the macro qtCompileTest defined in qtbase/mkspecs/features/configure.prf. I also found a codereview similar to what I had planned to submit ( https://codereview.qt-project.org/#/c/96521/ ) but it was abandoned with the explanation the tests should be self-contained and I agree with that. However, I'm still missing a feature to add custom include and linker paths. Otherwise qtCompileTest is just not usable on Windows. Cheers R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qmake command line assignments are not considered by config.tests
2014-10-30 15:26 GMT+01:00 Roland Winklmeier : > Dear Qt devs, > > I addressed the question below first to the interest list. But since > nobody replied, I did some investigations and found out this behavior > is caused by the macro qtCompileTest defined in > qtbase/mkspecs/features/configure.prf. > > I also found a codereview similar to what I had planned to submit ( > https://codereview.qt-project.org/#/c/96521/ ) but it was abandoned > with the explanation the tests should be self-contained and I agree > with that. However, I'm still missing a feature to add custom include > and linker paths. Otherwise qtCompileTest is just not usable on > Windows. > > Cheers R. > Forgot to copy the original email. Is now appended. Dear list, I'm using qmake project files for a library project. On Linux with a standard pathes for installed headers and libraries, there was rarely the need to add a non-standard path. If that happened, a command line assignment did the job: qmake "INCLUDEPATH+=C:/path/to/ headers" file.pro I used the same approach on Windows, due to the lack of a default header path. I want to keep the project files clean from local path changes as much as possible, because it used to produce conflicts when pulling from origin. Recently I found qtCompileTest(test) macro and loved it. So I added config tests to my latest project. On Linux config tests are building successfully and everything is fine. But on Windows even though I passed the custom include as commandline assignment to qmake, the tests fail. Looking into the produced Makefile, I see that config.tests were lacking the custom include and failed of course. Commenting the tests the build is fine. Is this intended behaviour? I would expect the tests use the same include path settings as the actual builds. Otherwise a test wouldn't make much sense, would it? Did I do something wrong or is it worth a bug report? Cheers Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enabling of QtDBus in Qt 5.4 and 5.5
To me this is amazing news. I'm using DBus on all platforms since nearly 2 years and always had to build Qt myself instead of using the official installers because of missing QtDBus libraries. They are shipped for Mac OS X meanwhile, but Windows was still a burden. 2014-12-11 9:40 GMT+01:00 Blasche Alexander < alexander.blas...@theqtcompany.com>: > > Personally, I think it is rather useless to enable QtDBus on for example > Windows. Yes, its better cross-platform programming and there are some > esoteric guys/projects who use dbus at this stage on Windows. However the > default setting to enable it for the esoteric use case means you ship tons > more code for nothing. Alternatives might have been to only enable it when > specifically requested only (aka change your configure2 option to disabled > on windows if no dbus option passed) or even compile the lib against some > no-op code (which would satisfy the true cross platform development use > case). I guess you might argue that QtDBus is not that large but without > more strict qmake changes you may create more code to be shipped in other > modules/projects too. > I don't think my project or myself is esoteric. As said DBus is used by my application successfully on all platforms including Windows for over two years now. libdbus is running on Windows for even longer. Several people have stated in this mailing list, they would appreciate QtDBus to be shipped also on Windows. I wonder on which facts you have based the statement that this is useless. Were there any problems reported, did anyone complain it is not working etc? IMHO there are only few people using it on Windows, because it hasn't been shipped yet and not everyone is building Qt themselves. DBus is a great cross platform solution and it is good to enable it on all platforms. If someone doesn't like it, don't use it. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] QtRemoteObjects - POD types derive from QObject
Dear list, a while ago the QtRemoteObjects project was started in the playground area. I had followed the discussions closely, because I'm running a project which has a perfect use case for QtRemoteObjects. I haven't had much time to look into the details yet, but now I did. In the absence of documentation, I have several questions. Quick background: the *.rep file format seem to support two types - POD and class. * Does POD types officially support composition? So can I define a POD type and use it as a member of a following POD/class? My tests seem to confirm my assumption, but I wanted to be sure. * I was quite surprised to see POD types are deriving from QObject. I would expect it to be a non-QObject class. Is this a requirement for QtRemoteObjects or can I disable it? I have quite a lot classes which are not derived from QObject, because they are used in value semantics (actively copied, assigned etc). This contradicts the QObject policy to be entities and not copyable. I was even more surprised to see the usage of qRegisterMetaType with QObjects. As already mentioned I have a lot value classes, which are already registered with the Qt metatype system, provide QDataStream operators. So if subclassing QObject would not be a requirement, what would I need to add to handcraft the headers? I would bypass the repc tool completely and add the missing parts by hand. Btw. is there any kind of roadmap or design goal? Because I would love to see this in Qt and I'm curious what is still missing or what I still can expect. This would help me to evaluate whether I use it in my project or not. Best regards, Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtRemoteObjects - POD types derive from QObject
Hi Brett,
thanks for your quick answer.
We have a patch for the initial version of documentation in progress.
> Should be out in the next week or two.
>
That sounds brilliant. I'm looking forward to it.
> > This contradicts the QObject policy to be entities and not copyable. I
> >was
> >even more surprised to see the usage of qRegisterMetaType with QObjects.
> >As already mentioned I have a lot value classes, which are already
> >registered
> >with the Qt metatype system, provide QDataStream operators.
> Registration and QDataStream operators are the key elements, otherwise
> QtRO has no way of passing the types over a socket. They trick is that
> this code needs to be compiled into every process using these types. It
> was added to repc to make this easier, but obviously repc creates the
> types then. Not helpful in your case. Repc will copy any initial
> #include statements, which should let you avoid use of POD types.
>
I think we have the same understanding of the POD type purpose. They are
mainly used as parameters or properties of a QObject.
What I don't understand is, why these POD types need to derive from
QObject. Maybe there is an important reason, hence the question.
The source objects clearly need to derive from QObject because they provide
signals and slots, but properties and parameters usually don't - at least I
haven't seen any QObject derived property in Qt's source code. Unless they
are meant to be used in a parent-child hierarchy: Object A is parent of
Object B and this hierarchy is replicated on the other side. Correct me if
I'm wrong but the QObject parent-child system is orthogonal to QObject
property system. It seems both systems are currently implemented in QtRO in
a mixed way. AFAIK copying around QObjects per value, is generally ok, but
not nice and not recommended.
I'll give a quick example of what I'm trying to achieve. Lets say we have a
source object which has several signals and slots. For the sake of the
example, I use a thermometer source giving me the temperature of a
connected device.
class CThermometer : public QObject
{
Q_OBJECT
Q_PROPERTY(float temperature READ temperature WRITE setTemperature
NOTIFY temperatureChanged)
public:
explicit CThermometer(float temperature, QObject *parent = Q_NULLPTR) :
QObject(parent), _temperature(temperature) {}
CThermometer(const CThermometer& other)
: QObject()
{
QtRemoteObjects::copyStoredProperties(&other, this);
}
CThermometer &operator=(const CThermometer &other)
{
if (this != &other)
QtRemoteObjects::copyStoredProperties(&other, this);
return *this;
}
float temperature() const { return _temperature; }
void setTemperature(int temperature) { if (temperature != _temperature)
{ _temperature = temperature; Q_EMIT temperatureChanged(); } }
Q_SIGNALS:
void temperatureChanged(float temperature);
private:
float _temperature;
};
Now I want to use a custom type for temperature. So instead of float
_temperature, I use CTemperature _temperature acting as the value type.
CTemperature is a plain custom C++ class, does have QDataStream operators
and is registered as QMetaType. If the temperature value changes
CThermometer will send a signal with the value as its parameter. The
property itself does not need nor have signals itself. So to me it looks
like, I shouldn't use the repc POD type, but rather include the header of
CTemperature. repc will handle it as any other basic type and the compiler
sorts out the rest. Is that correct?
In any case, I will try to implement a basic test with this scenario to see
if that works.
Regards,
Roland
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] QMetaTypeId::Defined illegal in Qt 5.5 beta
Hi all,
I was testing the Qt 5.5 beta binaries with my application and quickly
run into the following issue:
Short version:
The expression "QMetaTypeId::Defined" seems to be no longer
allowed in 5.5. It is fine until 5.4.2 (or more precise until
3cf8e426f49ee6adb1090865854506aa92316ce3).
Is this intended behaviour or an accepted source incompatibility since
QMetaTypeId is part of the private API?
Long Version:
Attached is a small example to reproduce the compiler error [1].
QMetaTypeId::Defined is often used by users of Qt to write
conditional code. As far as I know it is the only method to find out at
compile time whether T was declared as Qt meta type or not. In the
project I'm working on, most of the classes have a common base class
CValueObject which helps with automatic registration as Qt Meta Type,
DBus Meta Type, etc. In here we are using some template magic
conditional on "QMetaTypeId< typename SomeMagic::type>::Defined".
SomeMagic::type defaults to void, if T does not fulfil specific type
requirements. Unfortunately, we cannot simply change the default to
void* without rewriting a lot.
I wonder if others will have the same problem with it. I didn't raise it
yet as QTBUG since I wasn't sure if this is part of the private API and
I have to accept it. But since there is no other official alternative to
QMetaTypeId::Defined - at least known to me - would it be possible
to change the Qt header to make it compatible again?
Opinions, thoughts, advice?
Regards,
R.
[1] Compiler error:
g++ -c -pipe -g -Wall -W -D_REENTRANT -fPIE -DQT_CORE_LIB -I../metatype
-I. -I../../../Qt5.5.0/5.5/gcc_64/include
-I../../../Qt5.5.0/5.5/gcc_64/include/QtCore -I.
-I../../../Qt5.5.0/5.5/gcc_64/mkspecs/linux-g++ -o metatype_void.o
../metatype/metatype_void.cpp
In file included from
../../../Qt5.5.0/5.5/gcc_64/include/QtCore/qobject.h:48:0,
from
../../../Qt5.5.0/5.5/gcc_64/include/QtCore/qcoreapplication.h:40,
from
../../../Qt5.5.0/5.5/gcc_64/include/QtCore/QCoreApplication:1,
from ../metatype/metatype_void.cpp:1:
../../../Qt5.5.0/5.5/gcc_64/include/QtCore/qmetatype.h: In instantiation
of 'struct QtPrivate::IsQEnumHelper':
../../../Qt5.5.0/5.5/gcc_64/include/QtCore/qmetatype.h:1562:60:
required from 'struct QMetaTypeId'
../metatype/metatype_void.cpp:16:43: required from here
../../../Qt5.5.0/5.5/gcc_64/include/QtCore/qmetatype.h:1377:25: error:
forming reference to void
static const T &declval();
^
../../../Qt5.5.0/5.5/gcc_64/include/QtCore/qmetatype.h:1382:60: error:
'declval' was not declared in this scope
enum { Value = sizeof(qt_getEnumMetaObject(declval())) ==
sizeof(QMetaObject*) };
^
Makefile:552: recipe for target 'metatype_void.o' failed
#include
#include
#include
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
QTextStream out(stdout, QIODevice::WriteOnly);
out << "Is QString defined?" << endl;
out << "Defined=" << QMetaTypeId::Defined << endl;
out << "Id=" << qMetaTypeId() << endl;
out << "Is void defined?" << endl;
out << "Defined=" << QMetaTypeId::Defined << endl;
out << "Id=" << qMetaTypeId() << endl;
return a.exec();
}
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QMetaTypeId::Defined illegal in Qt 5.5 beta
Hi Olivier, On 05/16/2015 12:34 PM, Olivier Goffart wrote: > This was not intentional. > I made a fix here: https://codereview.qt-project.org/112436 I was about to suggest the same and then saw your email. I was able to patch my local installation and it works perfectly. Thanks for the quick reply and fix. Regards, Roland ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
