Re: [Development] QTBUG-42038 also happens with wec2013 arm imx6 device
Done. Gesendet:Montag, 15. Dezember 2014 um 00:09 Uhr Von:Sergio Martins iamser...@gmail.com An:development@qt-project.org, Gunnar Roth gunnar.r...@gmx.de Betreff:Re: [Development] QTBUG-42038 also happens with wec2013 arm imx6 device On Friday, December 12, 2014 17:47:16 Gunnar Roth wrote: I fix it by using #if defined(_M_ARM) // QTBUG-42038 , only talks about winrt but this also happens at least on wec2013 arm devices too, maybe even on ce 6/7. #pragma optimize(, off) #endif instead of #if defined(Q_OS_WINRT) defined(_M_ARM) // QTBUG-42038 #pragma optimize(, off) #endif Maybe this helps anyone. Hi, Can you submit a patch and add your findings to the bug report ? Regards, Srgio Martins ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] quickcontrols has now a hard dependancy on widgets.
Hi, Recently i deteced that quickcontrols plugim has started to add a hard dependency on widgets ( on wec2013 and win32 at least ). dpends.exe is showing ??0QStyleHintReturnMask@@QAE@XZ ??0QStyleOption@@QAE@HH@Z ??0QStyleOptionButton@@QAE@XZ ??0QStyleOptionComboBox@@QAE@XZ ??0QStyleOptionFocusRect@@QAE@XZ ??0QStyleOptionFrame@@QAE@XZ ??0QStyleOptionGroupBox@@QAE@XZ ??0QStyleOptionHeader@@QAE@XZ ??0QStyleOptionMenuItem@@QAE@XZ ??0QStyleOptionProgressBar@@QAE@XZ ??0QStyleOptionSlider@@QAE@XZ ??0QStyleOptionSpinBox@@QAE@XZ ??0QStyleOptionTab@@QAE@XZ ??0QStyleOptionTabWidgetFrame@@QAE@XZ ??0QStyleOptionToolBar@@QAE@XZ ??0QStyleOptionToolButton@@QAE@XZ ??0QStyleOptionViewItem@@QAE@XZ ??1QStyleHintReturnMask@@QAE@XZ ??1QStyleOption@@QAE@XZ ??1QStyleOptionViewItem@@QAE@XZ ?font@QApplication@@SA?AVQFont@@XZ ?globalStrut@QApplication@@SA?AVQSize@@XZ ?hideText@QToolTip@@SAXXZ ?palette@QApplication@@SA?AVQPalette@@PBD@Z ?showText@QToolTip@@SAXABVQPoint@@ABVQString@@PAVQWidget@@@Z ?style@QApplication@@SAPAVQStyle@@XZ as imported functions from Widgets library. In contrast to this the quickcontrols dialog plugin has only a soft dependency via qpa, because of the possibility to use the widgets dialogs as a fallback. Ir is very surprising to have a dependency on widgets, which loads this huge dll on our wec2013 platform into memory ( for performance reasons paging of exe/dll is switched off) . I admit that this does only happen if you also build widgets library, but i usually build as much a i can on a platform, even if i don't use it yet. With this patch i now disable that dependency. --- a\qtquickcontrols\src\src.pro 2014-12-05 17:24:10.0 +0100 +++ b\qtquickcontrols\src\src.pro 2014-12-08 13:45:54.616785600 +0100 @@ -7,6 +7,6 @@ SUBDIRS += layouts SUBDIRS += dialogs SUBDIRS += dialogs/Private -qtHaveModule(quick):qtHaveModule(widgets): SUBDIRS += widgets +#qtHaveModule(quick):qtHaveModule(widgets): SUBDIRS += widgets I would really appreciate a configure option for this. Regards, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QTBUG-42038 also happens with wec2013 arm imx6 device
On Friday, December 12, 2014 17:47:16 Gunnar Roth wrote: I fix it by using #if defined(_M_ARM) // QTBUG-42038 , only talks about winrt but this also happens at least on wec2013 arm devices too, maybe even on ce 6/7. #pragma optimize(, off) #endif instead of #if defined(Q_OS_WINRT) defined(_M_ARM) // QTBUG-42038 #pragma optimize(, off) #endif Maybe this helps anyone. Hi, Can you submit a patch and add your findings to the bug report ? Regards, Sérgio Martins ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] quickcontrols has now a hard dependancy on widgets.
Hi Gunnar, You can always rebuild QtQuick Controls making sure you add CONFIG += no_desktop in the .pro file. The widgets dependency is automatic if widgets are present except on mobile platforms (which, paradoxically, exclude embedded). Best regards, Dr. Gabriel de Dietrich Senior Software Developer The Qt Company — www.qt.io From: development-bounces+gabriel.dedietrich=theqtcompany@qt-project.org development-bounces+gabriel.dedietrich=theqtcompany@qt-project.org on behalf of Gunnar Roth gunnar.r...@gmx.de Sent: Monday, December 15, 2014 10:07 AM To: development@qt-project.org Subject: [Development] quickcontrols has now a hard dependancy on widgets. Hi, Recently i deteced that quickcontrols plugim has started to add a hard dependency on widgets ( on wec2013 and win32 at least ). dpends.exe is showing ??0QStyleHintReturnMask@@QAE@XZ ??0QStyleOption@@QAE@HH@Z ??0QStyleOptionButton@@QAE@XZ ??0QStyleOptionComboBox@@QAE@XZ ??0QStyleOptionFocusRect@@QAE@XZ ??0QStyleOptionFrame@@QAE@XZ ??0QStyleOptionGroupBox@@QAE@XZ ??0QStyleOptionHeader@@QAE@XZ ??0QStyleOptionMenuItem@@QAE@XZ ??0QStyleOptionProgressBar@@QAE@XZ ??0QStyleOptionSlider@@QAE@XZ ??0QStyleOptionSpinBox@@QAE@XZ ??0QStyleOptionTab@@QAE@XZ ??0QStyleOptionTabWidgetFrame@@QAE@XZ ??0QStyleOptionToolBar@@QAE@XZ ??0QStyleOptionToolButton@@QAE@XZ ??0QStyleOptionViewItem@@QAE@XZ ??1QStyleHintReturnMask@@QAE@XZ ??1QStyleOption@@QAE@XZ ??1QStyleOptionViewItem@@QAE@XZ ?font@QApplication@@SA?AVQFont@@XZ ?globalStrut@QApplication@@SA?AVQSize@@XZ ?hideText@QToolTip@@SAXXZ ?palette@QApplication@@SA?AVQPalette@@PBD@Z ?showText@QToolTip@@SAXABVQPoint@@ABVQString@@PAVQWidget@@@Z ?style@QApplication@@SAPAVQStyle@@XZ as imported functions from Widgets library. In contrast to this the quickcontrols dialog plugin has only a soft dependency via qpa, because of the possibility to use the widgets dialogs as a fallback. Ir is very surprising to have a dependency on widgets, which loads this huge dll on our wec2013 platform into memory ( for performance reasons paging of exe/dll is switched off) . I admit that this does only happen if you also build widgets library, but i usually build as much a i can on a platform, even if i don't use it yet. With this patch i now disable that dependency. --- a\qtquickcontrols\src\src.pro2014-12-05 17:24:10.0 +0100 +++ b\qtquickcontrols\src\src.pro2014-12-08 13:45:54.616785600 +0100 @@ -7,6 +7,6 @@ SUBDIRS += layouts SUBDIRS += dialogs SUBDIRS += dialogs/Private -qtHaveModule(quick):qtHaveModule(widgets): SUBDIRS += widgets +#qtHaveModule(quick):qtHaveModule(widgets): SUBDIRS += widgets I would really appreciate a configure option for this. Regards, Gunnar ___ 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] QtWayland windows decoration on the Raspberry Pi
Hi everyone,so now that Qt 5.4.0 is released, I dedicated some efforts to have QtWayland running on the Raspberry Pi. I have a QtWidget based application that runs fullscreen on eglfs, but all the children windows created by the app are not decorated. This is a known thing, thus I tried to go the Wayland way. A few days ago I found this: http://raspberrypi.collabora.co.uk/maynard.html Straightforward packages for Wheezy of Wayland/Weston version 1.4.0. With those, I've been able to build and run QtWayland 5.4.0 ! Quick note about what the Collabora team is doing: it seems the Collabora team and the RPi team are writing their own DE and they called it Maynard. (http://www.raspberrypi.org/preview-the-upcoming-maynard-desktop/) It's still under heavy development but when I gave it a try, it looked promising. Didn't experience crashes but obviously all the applications are missing, since nobody builds for Wayland yet. So, my application runs on Maynard using -platform wayland but all the windows are not decorated. So basically I have the same result as if I run it on eglfs.I haven't checked on Weston, but if Maynard is the direction the RPi team wants to take, then I would like to stick with it. Also, it's not clear to me if the wayland QPA is actually using the BRCM backend. Since I cannot move windows, I couldn't tell if performances are acceptable or what. So, my questions to the QtWayland guys are: - have you people already done some tests on Weston/Maynard on the Raspberry Pi ? - how could I check which backend the QtWayland QPA is loading ? - is there any chance to have windows decorations (bradient ?) on the RPi or is it something still being evaluated/developed ? Thanks in advance for any answer you could provide. Regards,Massimo___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWayland windows decoration on the Raspberry Pi
On Mon, Dec 15, 2014 at 12:37 PM, Massimo Callegari massimocalleg...@yahoo.it wrote: So, my application runs on Maynard using -platform wayland but all the windows are not decorated. So basically I have the same result as if I run it on eglfs. See: https://codereview.qt-project.org/#/c/93128/ So, my questions to the QtWayland guys are: - have you people already done some tests on Weston/Maynard on the Raspberry Pi ? I haven't personally touched the Pi since I fried mine a year or more ago. I don't know of many other people working on there, either, but perhaps there's someone lurking that I don't know of. - how could I check which backend the QtWayland QPA is loading ? The easiest way is probably to just make sure that you have the right client buffer integration plugin available. But I'm not sure if the regular one even works on the pi - at least I presume there's a reason there's a custom integration made available of it. - is there any chance to have windows decorations (bradient ?) on the RPi or is it something still being evaluated/developed ? If someone does the work for it, possibly. Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWayland windows decoration on the Raspberry Pi
You are most certainly using the brcm backend since you don't have decorations. wayland-egl (the only one that has decoration support atm) does not work on the Pi with the default graphics stack. Not sure about the state of Mesa. Cheers, Laszlo From: development-bounces+laszlo.agocs=theqtcompany@qt-project.org development-bounces+laszlo.agocs=theqtcompany@qt-project.org on behalf of Robin Burchell robin...@viroteck.net Sent: Monday, December 15, 2014 1:04 PM To: Massimo Callegari Cc: development@qt-project.org Subject: Re: [Development] QtWayland windows decoration on the Raspberry Pi On Mon, Dec 15, 2014 at 12:37 PM, Massimo Callegari massimocalleg...@yahoo.it wrote: So, my application runs on Maynard using -platform wayland but all the windows are not decorated. So basically I have the same result as if I run it on eglfs. See: https://codereview.qt-project.org/#/c/93128/ So, my questions to the QtWayland guys are: - have you people already done some tests on Weston/Maynard on the Raspberry Pi ? I haven't personally touched the Pi since I fried mine a year or more ago. I don't know of many other people working on there, either, but perhaps there's someone lurking that I don't know of. - how could I check which backend the QtWayland QPA is loading ? The easiest way is probably to just make sure that you have the right client buffer integration plugin available. But I'm not sure if the regular one even works on the pi - at least I presume there's a reason there's a custom integration made available of it. - is there any chance to have windows decorations (bradient ?) on the RPi or is it something still being evaluated/developed ? If someone does the work for it, possibly. Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] quickcontrols has now a hard dependancy on widgets.
HI Gabriel, I didn't know that, but i don't want any widgets dependency for a qml application, neither on desktop nor anywhere else. Regards, Gunnar Gesendet: Montag, 15. Dezember 2014 um 12:04 Uhr Von: deDietrich Gabriel gabriel.dedietr...@theqtcompany.com An: Gunnar Roth gunnar.r...@gmx.de, development@qt-project.org development@qt-project.org Betreff: Re: [Development] quickcontrols has now a hard dependancy on widgets. Hi Gunnar, You can always rebuild QtQuick Controls making sure you add CONFIG += no_desktop in the .pro file. The widgets dependency is automatic if widgets are present except on mobile platforms (which, paradoxically, exclude embedded). Best regards, Dr. Gabriel de Dietrich Senior Software Developer The Qt Company — www.qt.io[http://www.qt.io] From: development-bounces+gabriel.dedietrich=theqtcompany@qt-project.org development-bounces+gabriel.dedietrich=theqtcompany@qt-project.org on behalf of Gunnar Roth gunnar.r...@gmx.de Sent: Monday, December 15, 2014 10:07 AM To: development@qt-project.org Subject: [Development] quickcontrols has now a hard dependancy on widgets. Hi, Recently i deteced that quickcontrols plugim has started to add a hard dependency on widgets ( on wec2013 and win32 at least ). dpends.exe is showing ??0QStyleHintReturnMask@@QAE@XZ ??0QStyleOption@@QAE@HH@Z ??0QStyleOptionButton@@QAE@XZ ??0QStyleOptionComboBox@@QAE@XZ ??0QStyleOptionFocusRect@@QAE@XZ ??0QStyleOptionFrame@@QAE@XZ ??0QStyleOptionGroupBox@@QAE@XZ ??0QStyleOptionHeader@@QAE@XZ ??0QStyleOptionMenuItem@@QAE@XZ ??0QStyleOptionProgressBar@@QAE@XZ ??0QStyleOptionSlider@@QAE@XZ ??0QStyleOptionSpinBox@@QAE@XZ ??0QStyleOptionTab@@QAE@XZ ??0QStyleOptionTabWidgetFrame@@QAE@XZ ??0QStyleOptionToolBar@@QAE@XZ ??0QStyleOptionToolButton@@QAE@XZ ??0QStyleOptionViewItem@@QAE@XZ ??1QStyleHintReturnMask@@QAE@XZ ??1QStyleOption@@QAE@XZ ??1QStyleOptionViewItem@@QAE@XZ ?font@QApplication@@SA?AVQFont@@XZ ?globalStrut@QApplication@@SA?AVQSize@@XZ ?hideText@QToolTip@@SAXXZ ?palette@QApplication@@SA?AVQPalette@@PBD@Z ?showText@QToolTip@@SAXABVQPoint@@ABVQString@@PAVQWidget@@@Z ?style@QApplication@@SAPAVQStyle@@XZ as imported functions from Widgets library. In contrast to this the quickcontrols dialog plugin has only a soft dependency via qpa, because of the possibility to use the widgets dialogs as a fallback. Ir is very surprising to have a dependency on widgets, which loads this huge dll on our wec2013 platform into memory ( for performance reasons paging of exe/dll is switched off) . I admit that this does only happen if you also build widgets library, but i usually build as much a i can on a platform, even if i don't use it yet. With this patch i now disable that dependency. --- a\qtquickcontrols\src\src.pro 2014-12-05 17:24:10.0 +0100 +++ b\qtquickcontrols\src\src.pro 2014-12-08 13:45:54.616785600 +0100 @@ -7,6 +7,6 @@ SUBDIRS += layouts SUBDIRS += dialogs SUBDIRS += dialogs/Private -qtHaveModule(quick):qtHaveModule(widgets): SUBDIRS += widgets +#qtHaveModule(quick):qtHaveModule(widgets): SUBDIRS += widgets I would really appreciate a configure option for this. Regards, Gunnar ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development] ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] RFC: Improved Q_ENUM
Hello, I have been working on some improvements to moc and the meta type system to improve Q_ENUM. Those changes are targeting Qt 5.5 You can see the list of change there in the q_gadget topic (I put the changes in that topic even if it is an orthogonal changes to the Q_GADGET changes that are already in) https://codereview.qt-project.org/#/q/status:open+project:qt/qtbase+branch:dev+topic:q_gadget,n,z This is something that I have actually started working on a long time ago. The problem I wanted to solve was to show the actual string of the value when using qDebug with enum values that are registered with Q_ENUMS I tried many different option, and finally got a working solution, but it does require small changes, so I added a new macro Q_ENUM to keep compatibility Q_ENUM is almost the same as Q_ENUMS, but: - It can only contains one enum at the time, while you can put several in a Q_ENUMS - It need to be placed *after* the enum declaration in the class. Q_ENUMS is still existing and do not regress. But if you use Q_ENUM instead, you get: - Using it with qDebug prints the actual string of the value. - It is automatically registered as a QMetaType and you do not need Q_REGISTER_METATYPE anymore - It is also possible to get the related QMetaObject from the QMetaType. - You can get the QMetaEnum using the new QMetaEnum::fromTypeT() - a QVariant containing that enum can automatically be converted to QString or QByteArray with the value name. Also, if the QVariant contains a QString or a QByteArray with a value name, it can be converted to the enum type. (This could be useful for QML as well, as you should not need to artificially expose the enums to QML anymore) At first, I wanted to deprecate Q_ENUMS and show a warning when Q_ENUMS is used. But because it is a bit of work to move to Q_ENUM, I just did not put a warning yet. I can already hear the resistant to change nay-sayer I like to put my Q_ENUMS at the beginning of the class with all the meta-stuff. Well, Q_ENUM can go directly after the enum in question, so it stays together. This is also where you would put things like Q_DECLARE_FLAGS Any opinions or comments? You can review the patches. (First patch is there: https://codereview.qt-project.org/89415/ ) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWayland windows decoration on the Raspberry Pi
Thanks Robin and Laszlo for the replies. So I take QtWayland is still a work in progress especially on the Pi. I personally believe QtWayland should have a special regard for the RPi platform, as they are abandoning the Xorg server, and looking forward to lighter solutions to give users a smoother UI experience. Just my personal opinion, don't take me wrong. As far as I know, the same is not happening on desktop systems, at least not in a short term. If Qt can be a first class option to write applications on the RPi + Wayland then you guys have made bingo ! So I guess my current options are to wait if someone ports decoration on the brcm backend or go the QtQuick way (which I already started to do) Thanks again,Massimo Da: Agocs Laszlo laszlo.ag...@theqtcompany.com A: Robin Burchell robin...@viroteck.net; Massimo Callegari massimocalleg...@yahoo.it Cc: development@qt-project.org development@qt-project.org Inviato: Lunedì 15 Dicembre 2014 13:19 Oggetto: Re: [Development] QtWayland windows decoration on the Raspberry Pi You are most certainly using the brcm backend since you don't have decorations. wayland-egl (the only one that has decoration support atm) does not work on the Pi with the default graphics stack. Not sure about the state of Mesa. Cheers, Laszlo From: development-bounces+laszlo.agocs=theqtcompany@qt-project.org development-bounces+laszlo.agocs=theqtcompany@qt-project.org on behalf of Robin Burchell robin...@viroteck.net Sent: Monday, December 15, 2014 1:04 PM To: Massimo Callegari Cc: development@qt-project.org Subject: Re: [Development] QtWayland windows decoration on the Raspberry Pi On Mon, Dec 15, 2014 at 12:37 PM, Massimo Callegari massimocalleg...@yahoo.it wrote: So, my application runs on Maynard using -platform wayland but all the windows are not decorated. So basically I have the same result as if I run it on eglfs. See: https://codereview.qt-project.org/#/c/93128/ So, my questions to the QtWayland guys are: - have you people already done some tests on Weston/Maynard on the Raspberry Pi ? I haven't personally touched the Pi since I fried mine a year or more ago. I don't know of many other people working on there, either, but perhaps there's someone lurking that I don't know of. - how could I check which backend the QtWayland QPA is loading ? The easiest way is probably to just make sure that you have the right client buffer integration plugin available. But I'm not sure if the regular one even works on the pi - at least I presume there's a reason there's a custom integration made available of it. - is there any chance to have windows decorations (bradient ?) on the RPi or is it something still being evaluated/developed ? If someone does the work for it, possibly. Robin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWayland windows decoration on the Raspberry Pi
2014-12-15 15:43 GMT+02:00 Massimo Callegari massimocalleg...@yahoo.it: Thanks Robin and Laszlo for the replies. So I take QtWayland is still a work in progress especially on the Pi. I personally believe QtWayland should have a special regard for the RPi platform, as they are abandoning the Xorg server, and looking forward to lighter solutions to give users a smoother UI experience. Just my personal opinion, don't take me wrong. I don't think that will happen until the standard Wayland EGL platfom is available on it, the brcm plugin is kind of a stop-gap measure. Which shouldn't work when running on Weston, btw. As such, i don't think you have EGL available. You should get Using $foo when starting a Qt app. What is $foo? Being a QtWidget application you don't need EGL though, so it should be fine... unless you're using some QOpenGL* thing. -- Giulio As far as I know, the same is not happening on desktop systems, at least not in a short term. If Qt can be a first class option to write applications on the RPi + Wayland then you guys have made bingo ! So I guess my current options are to wait if someone ports decoration on the brcm backend or go the QtQuick way (which I already started to do) Thanks again, Massimo Da: Agocs Laszlo laszlo.ag...@theqtcompany.com A: Robin Burchell robin...@viroteck.net; Massimo Callegari massimocalleg...@yahoo.it Cc: development@qt-project.org development@qt-project.org Inviato: Lunedì 15 Dicembre 2014 13:19 Oggetto: Re: [Development] QtWayland windows decoration on the Raspberry Pi You are most certainly using the brcm backend since you don't have decorations. wayland-egl (the only one that has decoration support atm) does not work on the Pi with the default graphics stack. Not sure about the state of Mesa. Cheers, Laszlo From: development-bounces+laszlo.agocs=theqtcompany@qt-project.org development-bounces+laszlo.agocs=theqtcompany@qt-project.org on behalf of Robin Burchell robin...@viroteck.net Sent: Monday, December 15, 2014 1:04 PM To: Massimo Callegari Cc: development@qt-project.org Subject: Re: [Development] QtWayland windows decoration on the Raspberry Pi On Mon, Dec 15, 2014 at 12:37 PM, Massimo Callegari massimocalleg...@yahoo.it wrote: So, my application runs on Maynard using -platform wayland but all the windows are not decorated. So basically I have the same result as if I run it on eglfs. See: https://codereview.qt-project.org/#/c/93128/ So, my questions to the QtWayland guys are: - have you people already done some tests on Weston/Maynard on the Raspberry Pi ? I haven't personally touched the Pi since I fried mine a year or more ago. I don't know of many other people working on there, either, but perhaps there's someone lurking that I don't know of. - how could I check which backend the QtWayland QPA is loading ? The easiest way is probably to just make sure that you have the right client buffer integration plugin available. But I'm not sure if the regular one even works on the pi - at least I presume there's a reason there's a custom integration made available of it. - is there any chance to have windows decorations (bradient ?) on the RPi or is it something still being evaluated/developed ? If someone does the work for it, possibly. Robin ___ 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 mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Bugtracker update and new URL
Hi, It is time to move the Qt bug tracker to its new home under qt.io. The new URL is going to be: https://bugreports.qt.io The change is going to happen on Wed, 7. January 2015. To facilitate the change the old server will be taken offline at 18:00 CET (GMT+1) and the latest changes will be copied to the new server. If everything goes well, the new server will be online at 20:00 CET (GMT+1). This implies that the Qt bug tracker is going to be down for about 2hrs. We are sorry for the inconvenience. Redirects will be in place following the move and all existing user accounts will continue to work. At the same time, Jira will be updated from 5.x to 6.3. The user interface style looks a bit different and you might find some minor new features here and there. As always, if you encounter any problems when using the new Jira instance, please file a report against the QTJIRA project (http://bugreports.qt.io/browse/QTJIRA) and if you are not even able to login you may use jira-admin (at) qt-project.org. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSG render thread crashes during volumetric rendering
Maybe try a call to QQuickWindow::resetOpenGLState() after VTK finishes. It may be some dangling GL state that messes up for the renderer. cheers, Gunnar On 12 Dec 2014, at 21:19, Cartik Sharma cartik.sha...@gmail.com wrote: Hello, I'm trying to do volumetric rendering with VTK using the QVTKFramebufferObject class from https://gist.github.com/nocnokneo/c3fb01bb7ecaf437f7d6 https://gist.github.com/nocnokneo/c3fb01bb7ecaf437f7d6 Essentially this is a class based on QQuickFramebufferObject and over rides rendering with certain presets for OpenGL states. It works well for images and 3D objects but crashes the QSG render thread during render calls from vtkFixedPointVolumeRayCastMapper. I need help debugging the crash and fixing this error. (please refer crash report in render_crash.txt) Best regards, Cartik render_crash.txt___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] quickcontrols has now a hard dependancy on widgets.
On Mon, Dec 15, 2014 at 12:04 PM, deDietrich Gabriel gabriel.dedietr...@theqtcompany.com wrote: [...] The widgets dependency is automatic [...] except on mobile platforms [...] A bit OOT, but having the same logic for QtSvg would be great! (Yes, QtSvg unfortunately depends on QtWidgets, regardless of the target platform). /me prepares patch Br, Alessandro ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSG render thread crashes during volumetric rendering
Thanks so much. I tried a view.resetOpenGLState and it works without crashing. Best regards, Cartik On Mon, Dec 15, 2014 at 1:53 PM, Gunnar Sletta gun...@sletta.org wrote: Maybe try a call to QQuickWindow::resetOpenGLState() after VTK finishes. It may be some dangling GL state that messes up for the renderer. cheers, Gunnar On 12 Dec 2014, at 21:19, Cartik Sharma cartik.sha...@gmail.com wrote: Hello, I'm trying to do volumetric rendering with VTK using the QVTKFramebufferObject class from https://gist.github.com/nocnokneo/c3fb01bb7ecaf437f7d6 Essentially this is a class based on QQuickFramebufferObject and over rides rendering with certain presets for OpenGL states. It works well for images and 3D objects but crashes the QSG render thread during render calls from vtkFixedPointVolumeRayCastMapper. I need help debugging the crash and fixing this error. (please refer crash report in render_crash.txt) Best regards, Cartik render_crash.txt___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- There is plenty of room at the bottom! R. Feynman ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtWayland windows decoration on the Raspberry Pi
On Monday 15 December 2014 13:43:26 Massimo Callegari wrote: I personally believe QtWayland should have a special regard for the RPi platform, as they are abandoning the Xorg server, and looking forward to lighter solutions to give users a smoother UI experience. Just my personal opinion, don't take me wrong. The solution to that is for RPi to give special regard to Wayland. This problem is not really a Qt issue, since it happens to all Wayland applications on the RPi (or so I'm told). It would have helped if the RPi had better graphics drivers, but those are the compromises you make when you try to sell a part at $35. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSG render thread crashes during volumetric rendering
On Monday 15 December 2014 14:16:17 Cartik Sharma wrote: Thanks so much. I tried a view.resetOpenGLState and it works without crashing. One of the common ways this crashes the driver is inside calls to glDrawElements if you have a bad element buffer bound which then indexes into some random memory address. This is easy to have happen if VTK leaves some state configured when control goes back to Qt Quick. Qt Quick assumes the state has not been tampered with and may go ahead and update something which tramples over one of your buffers. A handy technique is to run your app through a debug tracing tool like apitrace to see what state is left behind by your custom rendering code. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] D-Bus libs for Windows
Hello I've created a zip file containing the necessary libs for D-Bus on Windows. You can download it from: http://macieira.org/~thiago/dbus.zip It contains both a 32- and a 64-bit version of D-Bus libs and executables. The bus protocol is identical for both, so it doesn't matter which daemon you run. The headers are also identical, but for historical reasons there's one file (dbus-arch-deps.h) which is located inside a lib dir, instead of include. The headers are not required to build a runtime QtDBus. All you need to do to enable running of the D-Bus tests in tests/auto/dbus and in tests/benchmarks/dbus is to add the correct bin directory to your $PATH. The daemon will automatically launch itself on first use. I did not build these packages. I simply re-packaged the files from OpenSUSE's MinGW32 and MinGW64 builds by copying all the files and placing them in a suitable path (all files listed by rpm -ql `rpm -qa mingw*dbus* mingw*expat*`). This should work for all compilers on Windows since the libraries don't link to any MinGW library: $ dumpbin -dependents /c/Qt/3rdparty/dbus/64/bin/libdbus-1-3.dll Microsoft (R) COFF/PE Dumper Version 14.00.22310.1 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file c:/Qt/3rdparty/dbus/64/bin/libdbus-1-3.dll File Type: DLL Image has the following dependencies: ADVAPI32.dll IPHLPAPI.DLL KERNEL32.dll msvcrt.dll WS2_32.dll Source packages: windows:mingw:win32 / openSUSE_13.2 mingw32-dbus-1-1.8.10-1.2 windows:mingw:win32 / openSUSE_13.2 mingw32-dbus-1-devel-1.8.10-1.2 windows:mingw:win32 / openSUSE_13.2 mingw32-libdbus-1-3-1.8.10-1.2 windows:mingw:win32 / openSUSE_13.2 mingw32-libexpat-devel-2.0.1-11.3 windows:mingw:win32 / openSUSE_13.2 mingw32-libexpat1-2.0.1-11.3 windows:mingw:win64 / openSUSE_13.2 mingw64-dbus-1-1.8.10-2.1 windows:mingw:win64 / openSUSE_13.2 mingw64-dbus-1-devel-1.8.10-2.1 windows:mingw:win64 / openSUSE_13.2 mingw64-libdbus-1-3-1.8.10-2.1 windows:mingw:win64 / openSUSE_13.2 mingw64-libexpat-devel-2.0.1-10.4 windows:mingw:win64 / openSUSE_13.2 mingw64-libexpat1-2.0.1-10.4 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QSG render thread crashes during volumetric rendering
Thanks. The volume rendering seems to work fine with just one problem. When I rotate an image in a 2d window and get back to the 3d window, and try to rotate the 3d object, it crashes again. VTK must be changing the gl state and so I must call resetOpenGLState before I rotate the view except I can't call it in the new mousePressEvent since the original context is lost. Any idea how to fix this. Best regards, Cartik On Mon, Dec 15, 2014 at 2:35 PM, Sean Harmer sean.har...@kdab.com wrote: On Monday 15 December 2014 14:16:17 Cartik Sharma wrote: Thanks so much. I tried a view.resetOpenGLState and it works without crashing. One of the common ways this crashes the driver is inside calls to glDrawElements if you have a bad element buffer bound which then indexes into some random memory address. This is easy to have happen if VTK leaves some state configured when control goes back to Qt Quick. Qt Quick assumes the state has not been tampered with and may go ahead and update something which tramples over one of your buffers. A handy technique is to run your app through a debug tracing tool like apitrace to see what state is left behind by your custom rendering code. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions -- There is plenty of room at the bottom! R. Feynman ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Modifying QQmlFileSelector selector at runtime without Loader or Component
On Fri, Dec 12, 2014 at 8:29 PM, achart...@fastmail.fm wrote:
Hello,
I would like to modify the extraSelectors of QQmlFileSelector at runtime
and have QML load the new QML file from the appropriate selector folder.
I have gotten this to work by calling setExtraSelectors() from a C++
object I have exposed to QML and then forcing a re-evaluation of the
Loader's source property:
Loader {
id: myLoader
source: Qt.resolvedUrl(MyItem.qml)
}
Connections {
target: myCppObject
onSelectorChanged: myLoader.source = Qt.resolvedUrl(MyItem.qml)
}
Now, for my use case I really need the ability to achieve the same
behavior without using Loader or Component. I essentially want something
like this:
MyItem { }
Connections {
target: myCppObject
onSelectorChanged: // when selector changes, the MyItem instance
above is automatically resolved to the MyItem definition in the
appropriate selector folder.
How can this be accomplished?
This cannot be accomplished (I actually tried last year). The problem
is that you have an actual instance of MyItem there, and there's no
way to magically map it into another instance. You have to destroy
that instance and bring up a new one - which basically means Loader.
What you probably want is to have certain parts of the instance shift,
but not destroy the whole instance. For that I recommend using QtQuick
States. You can have a base state, and then a list of property changes
to things within the instance in a sub state and use transitions to
animate it. That shifts the parts of the instance that need to,
without destroying the whole thing. Or save state in another object
(such as in a QtObject{} on the Loader) and bind your internal state
to that so that you can use the Loader approach to recreate whole
instances.
PS: Moving to qt-interest since you didn't seem to be offering to
develop this feature as a part of Qt.
--
Alan Alpert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
[Development] [QtIFW] Offline from online?
Hi, QtIFW develooers!!!What about creation offline installers based on shared in online repository components? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
