[Interest] Custom layouts
Hi. I found that if in setGeometry() method call hide() or show() on widgets inside layout then this leads to recursion of layout. What do you think on this problem? May be it is good suggestion to Qt developers to remove this recursion, because of it is sometimes useful to hide some widgets in layout for this or that reason?! Thank you.___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Qt on Wandboard-solo with Yocto -Problem
Hello,
If anyone can help me to sought out the this issue to built up Qt on
wandboard-Solo with yocto.
Based on the url
http://wiki.wandboard.org/index.php/Building_Qt5_using_yocto_on_Wandboard I
altered the local.conf and the bblayers.confand gave a bitbake
core-image-minimal with DISTRO_FEATURE_remove
I got the errors as posted http://pastebin.com/hsMhT9f8.
Then to circumvent the errors I removed the DISTRO_FEATURE_remove from the
local.conf
and gave a bitbake.with this i got the errors as posted
http://pastebin.com/QFu2Rw6G.
for the thirld time I tried to change the following
1) In /meta-fsl-arm/qt5-layer/recipes-qt/qt5/qtbase_%.bbappend
QT_CONFIG_FLAGS_append_mx6 = ${@base_contains('DISTRO_FEATURES', 'x11',
*'-xcb'*, ' -eglfs', d)}
I replaced -no-eglfs with -xcb
2)In /bin/fsl-community-bsp/sources/meta-qt5/recipes-qt/qt5/qtbase.in
QT_CONFIG_FLAGS += \
-reduce-relocations \
-shared \
* -silent \*
-no-pch \
-no-rpath \
-pkg-config \
${EXTRA_OECONF} \
-silent was deleted.
With this setup and without DISTRO_FEATURE_remove I gave i bitbake and was
encountered with the errors as posted http://pastebin.com/V2fMF785
Please suggest to resolve this issue.
Thanks
Nilesh Kokane
--
“The contents of this e-mail message and any attachments are confidential
and are intended solely for addressee. The information may also be legally
privileged. This transmission is sent in trust, for the sole purpose of
delivery to the intended recipient. If you have received this transmission
in error, any use, reproduction or dissemination of this transmission is
strictly prohibited. If you are not the intended recipient, please
immediately notify the sender by reply e-mail or phone and delete this
message and its attachments, if any.”
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QML TextEdit cursor not visible
Dear All, I have a problem in my application, I'm using Qt 4.8.5 and QML on our ARM freescale platform (QWS server, not X11). I have a TextEdit component in my QML page, and when I click on it to assign focus, the focus is assigned but I cannot see the cursor blinking. The same application on Windows platform is working, I'm wondering if I missed something. When I input a characted from the keyboard, then the cursor appear, but static (not blinking). Please notice that the component TextInput work properly (the cursor is visible and blinking), but I can't use it in this page because I need more than one line. Any Idea? Many Thanks Simone ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Custom layouts
Hi Igor, Your problem makes sense. Hiding and showing widgets triggers a layout recalculation, and the layout uses setGeometry to position the widgets. It sounds unusual to change widget visibility in a setGeometry override. I suggest to use a flag to prevent the recursion yourself. Regards, Tony Sent: Tuesday, 5 August 2014 4:14 PM Hi. I found that if in setGeometry() method call hide() or show() on widgets inside layout then this leads to recursion of layout. What do you think on this problem? May be it is good suggestion to Qt developers to remove this recursion, because of it is sometimes useful to hide some widgets in layout for this or that reason?! Thank you. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
OK, I'm not familiar with QML QtQuick at all yet, only quite recently started using Qt as an alternative for MS. If those support OpenGL core profile 4+ then I'll have to take a look when I have the time, for now I have to stick with Qt Creator. So the context is that QtWidgets (QWidget, QMainWindow etc) are the traditional but still fine-to-use UI component technology, and QML is the newer tech. The QML tech stack includes QWindow; QtWidgets doesn't really. You can mix QtWidgets and QWindow/QML (with that createContainerWidget method or QQuickWidget), but you shouldn't unless you have a reason to, and it sounds like you don't. If you want to use QtWidgets then you should probably just use QGLWidget. Ian All right, that clarifies things. Thanks, -Risto PS. Sorry about the previous unfinished message, a sudden hand movement trying to save my coffee mug. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
Am 04.08.2014 um 23:58 schrieb Ian Monroe i...@monroe.nu: On Mon, Aug 4, 2014 at 1:53 PM, rap r...@dlc.fi wrote: From: Ian Monroe On Mon, Aug 4, 2014 at 12:32 PM, rap r...@dlc.fi wrote: Why do you want to use QWindow if you are using QWidget-based windows? QGLWidget seems like the correct solution. Your question arises a question of the purpose and usefulness of QWindow class regarding opengl if you can not easily create UI controls to go with it, at least in a SDI application. I'll check how things turn out with MDI and QWindow for child wnds. Sure you can create UI controls with QWindow, just use QML and Qt Quick Controls.You could do your own OpenGL stuff by subclassing QQuickItem. That's what QWindow is for. It's not meant to be poor replacement for QGLWidget. Ian OK, I'm not familiar with QML QtQuick at all yet, only quite recently started using Qt as an alternative for MS. If those support OpenGL core profile 4+ then I'll have to take a look when I have the time, for now I have to stick with Qt Creator. So the context is that QtWidgets (QWidget, QMainWindow etc) are the traditional but still fine-to-use UI component technology, and QML is the newer tech. While traditional and newer sounds like the one is going to replace the other (which might or might not be the case), I'd say that QML is simply a different approach for designing GUIs. Simplified you could say it's all about declarative (QML) vs imperative (QWidgets). Personally - for desktop applications - I still prefer traditional widget hierarchies with their very common parent-child paradigm (also in other GUI tool kits). However if you're thinking about full screen custom OpenGL GUIs (well, games ;)) then mixing OpenGL with QtQuick (with its declarative GUI language QML) is definitively worth checking out! There is a Qt example which does just that. The QML tech stack includes QWindow; QtWidgets doesn't really. Technically QWindow is in the base QtGui library on which the QtWidget library is based (just like the corresponding QtQuick library, if I am not mistaken). But it is correct to say that QWindow was more meant to be a low level window container for QtQuick based applications. So it cannot really be directly incorporated into a QWidget hierarchy (like e.g. a top-level QDialog widget which could have another QMainWindow as parent). But if I am not mistaken under the hood a QWindow is also used as base for e.g. a QMainWindow. It is just the lowest common and most lightweight denominator for interaction with the underlying window system (which could also simply be a framebuffer on embedded systems, if I understood this correctly). You can mix QtWidgets and QWindow/QML (with that createContainerWidget method or QQuickWidget), That's exactly the magic keyword here, the static method of QWidget::createContainerWidget! The only downside is you cannot (?) do that entirely within Qt Designer: you cannot e.g. simply drag'n'drop a QGLWidget into the Designer form and promote it to MyOpenGLWidget. So you have to insert another Container widget into the form (e.g. your QMainWidow) and add a QLayout to it, then in the c'tor of your QMainWindow based class create an instance of your OpenGL enabled QWindow, then create a container widget for it with the above method (which takes ownership over the QWindow) and add that newly created widget to your QLayout. Works pretty well, with a little bit of hand-coding. Off course the upcoming QOpenGLWidget (which replaces QGLWidget) would make that boilerplate code unnecessary again. But for the time being - Qt 5.3 - and for new code QWindow/createWidgetContainer is the way to go, so I understand. but you shouldn't unless you have a reason to, and it sounds like you don't. If you want to use QWidgets for *new* code and want to make use of the most recent QOpenGL classes (as opposed to the old QGL classes) then the createWidgetContainer way is the most sensible one to me. Also see below. If you want to use QtWidgets then you should probably just use QGLWidget. There is a conversion method to convert a new QOpenGLContext (which was really designed to be used with QWindow and which you should be using now) to the old QGLContext, but that is really a detour, since QGLContext is just a wrapper over the newer QOpenGLContext again. So when you create a QGLWidget with your converted QGLContext under the hood it will be converted back to a QOpenGLContext. Not a huge performance hit (if at all), but probably just a hint that you should be using QWindow based OpenGL rendering for /new/ code (and the upcoming QOpenGLWindow which I expect will then work with the new QOpenGL classes exclusively). So for /existing/ code you can still use your QGLWidget, but progressively replace all other QGL classes with their QOpenGL counterparts. For new code start using QOpenGL classes right away (including the new
Re: [Interest] Embedding QWindow
Am 05.08.2014 um 10:27 schrieb Till Oliver Knoll till.oliver.kn...@gmail.com: ... That's exactly the magic keyword here, the static method of QWidget::createContainerWidget! That's QWidget::createWindowContainer() to be correct ;) Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
According to this blog post: http://blog.qt.digia.com/blog/2014/07/02/qt-weekly-16-qquickwidget never use the QWidget::createWindowContainer() :) use QQuickWidget instead. BR, Filip On Tue, Aug 5, 2014 at 10:31 AM, Till Oliver Knoll till.oliver.kn...@gmail.com wrote: Am 05.08.2014 um 10:27 schrieb Till Oliver Knoll till.oliver.kn...@gmail.com: ... That's exactly the magic keyword here, the static method of QWidget::createContainerWidget! That's QWidget::createWindowContainer() to be correct ;) Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
From: Till Oliver Knoll Sent: Tuesday, August 05, 2014 11:27 AM But if I am not mistaken under the hood a QWindow is also used as base for e.g. a QMainWindow. It is just the lowest common and most lightweight denominator for interaction with the underlying window system (which could also simply be a framebuffer on embedded systems, if I understood this correctly). That don't seem to be the case, QMainWindow inherits from QWidget, which probably is the reason for the need of QWidget::createWindowContainer() when using QWindow based classes in QWidget based contexts. ... Off course the upcoming QOpenGLWidget (which replaces QGLWidget) would make that boilerplate code unnecessary again. So for /existing/ code you can still use your QGLWidget, but progressively replace all other QGL classes with their QOpenGL counterparts. For new code start using QOpenGL classes right away (including the new QWindow based OpenGL rendering). Cheers, Oliver Right, this is exactly the reason for my initial question after studying some QtGuiApplication /QWindow based samples by KDAB, also the Qt examples in the gui subfolder. For now, if QWindow works for MDI child wnds without any user controls that would be sufficient for me at this point, actually even better. Working in that direction now. Thanks -Risto ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] How to force layout...
Den 04-08-2014 10:35, Igor Mironchik skrev: Hi. How to force layout to update geometries of items in it if some items changed theirs sizeHint property? For example if I rotate rectangle I want layout to update geometry of this rectangle. I’ve tried: layout-invalidate(); layout-update(); But with no success. widget-updateGeometry(); -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
There is a QWindow under the hood for each top-level widget, but it is not done via inheritance. The QWindow and QWidget hierarchies are distinct. The description from Oliver covers the situation pretty well. One thing worth noting in addition is that using QWindow for rendering OpenGL (or raster, for that matter) stuff without relying on widgets or Qt Quick is a perfectly valid use case. Applications that render everything on their own are better off with QWindow than QGLWidget (or QOpenGLWidget) if all they need is a window they can render to. Best regards, Laszlo From: interest-bounces+laszlo.agocs=digia@qt-project.org [interest-bounces+laszlo.agocs=digia@qt-project.org] on behalf of rap [r...@dlc.fi] Sent: Tuesday, August 05, 2014 12:09 PM To: Till Oliver Knoll; Qt Project Subject: Re: [Interest] Embedding QWindow From: Till Oliver Knoll Sent: Tuesday, August 05, 2014 11:27 AM But if I am not mistaken under the hood a QWindow is also used as base for e.g. a QMainWindow. It is just the lowest common and most lightweight denominator for interaction with the underlying window system (which could also simply be a framebuffer on embedded systems, if I understood this correctly). That don't seem to be the case, QMainWindow inherits from QWidget, which probably is the reason for the need of QWidget::createWindowContainer() when using QWindow based classes in QWidget based contexts. ... Off course the upcoming QOpenGLWidget (which replaces QGLWidget) would make that boilerplate code unnecessary again. So for /existing/ code you can still use your QGLWidget, but progressively replace all other QGL classes with their QOpenGL counterparts. For new code start using QOpenGL classes right away (including the new QWindow based OpenGL rendering). Cheers, Oliver Right, this is exactly the reason for my initial question after studying some QtGuiApplication /QWindow based samples by KDAB, also the Qt examples in the gui subfolder. For now, if QWindow works for MDI child wnds without any user controls that would be sufficient for me at this point, actually even better. Working in that direction now. Thanks -Risto ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
Am 05.08.2014 um 10:48 schrieb Filip Piechocki fpiecho...@gmail.com: According to this blog post: http://blog.qt.digia.com/blog/2014/07/02/qt-weekly-16-qquickwidget never use the QWidget::createWindowContainer() :) use QQuickWidget instead. Read the fine print: ;) having a QQuickView embedded via createWindowContainer() will always lead to better performance when compared to QQuickWidget The reason is probably related to buffering: according to the blog all drawing of the QQuickWidget - that includes (raw) OpenGL drawing as well, I guess - will first go into an application specific buffer where it is combined with all the other widget paintings (notably transparent overlays etc., which otherwise would cause rendering artifacts when using native windows). That per Qt application buffering (especially referring to raw OpenGL) even raises more interesting questions on platforms such as OS X where the Window (composition) Manager itself introduces yet another per application buffer (so swapping GL double buffers on OS X is in fact pointless, since the window manager will do this for you, too). So you render into the Qt application buffer, which gets copied into the OS specific per application buffer, which eventually (with the whole composited desktop) is copied into the video (front) buffer. Even more interesting: Retina displays (on OS X). By default the OpenGL framebuffer resolution that is created by the OS when requesting a window size of w times h points is half the resolution of the Retina display, such that the same amount of OpenGL fragments are processed by default, as compared to a non-Retina display with the same window size [in points]. If one really wants to draw with OpenGL in the native (physical) resolution then a flag (in Core Graphics?) can be set before creating the corresponding OpenGL Cocoa widget. Besides the Retina use case there is another full screen with custom resolution use case: instead of switching the graphic mode (resolution) for full screen OpenGL applications one simply requests a custom size of the frame buffer. The window manager itself will then scale up that buffer (without the application having to deal with that, apart from initially requesting the custom size buffer) to the physical screen resolution. I wonder how this all adds up when the application introduces yet another per application composition layer with buffer...? But yes, there are issues with createWindowContainer ;) (especially on certain embedded systems with no Window Manager). But from what I understand they are not worse than what we know from QGLWidget (on desktop systems anyway). And let's just wait what QOpenGLWidget brings to us and how it turns out in practise with all this buffering! By now it should be clear that if you want to have as few as possible between you and the GPU: use QWindow only! Cheers, Oliver___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
Thanks, this discussion has been really useful, I haven't found anything written giving the larger picture, just nuts and bolts everywhere. Regarding the idea of using MDI and QWindow for child wnds seems to stumble on the fact that QMdiSubWindow class is a QWidget based class too. There seems to be no escape from using QWidget::createWindowContainer() at the moment, even for MDI child wnds. - Risto From: Agocs Laszlo Sent: Tuesday, August 05, 2014 2:21 PM There is a QWindow under the hood for each top-level widget, but it is not done via inheritance. The QWindow and QWidget hierarchies are distinct. The description from Oliver covers the situation pretty well. One thing worth noting in addition is that using QWindow for rendering OpenGL (or raster, for that matter) stuff without relying on widgets or Qt Quick is a perfectly valid use case. Applications that render everything on their own are better off with QWindow than QGLWidget (or QOpenGLWidget) if all they need is a window they can render to. Best regards, Laszlo Sent: Tuesday, August 05, 2014 11:27 AM But if I am not mistaken under the hood a QWindow is also used as base for e.g. a QMainWindow. It is just the lowest common and most lightweight denominator for interaction with the underlying window system (which could also simply be a framebuffer on embedded systems, if I understood this correctly). That don't seem to be the case, QMainWindow inherits from QWidget, which probably is the reason for the need of QWidget::createWindowContainer() when using QWindow based classes in QWidget based contexts. ... Off course the upcoming QOpenGLWidget (which replaces QGLWidget) would make that boilerplate code unnecessary again. So for /existing/ code you can still use your QGLWidget, but progressively replace all other QGL classes with their QOpenGL counterparts. For new code start using QOpenGL classes right away (including the new QWindow based OpenGL rendering). Cheers, Oliver Right, this is exactly the reason for my initial question after studying some QtGuiApplication /QWindow based samples by KDAB, also the Qt examples in the gui subfolder. For now, if QWindow works for MDI child wnds without any user controls that would be sufficient for me at this point, actually even better. Working in that direction now. Thanks -Risto ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
Am 05.08.2014 um 12:09 schrieb rap r...@dlc.fi: From: Till Oliver Knoll Sent: Tuesday, August 05, 2014 11:27 AM But if I am not mistaken under the hood a QWindow is also used as base for e.g. a QMainWindow. ... That don't seem to be the case, QMainWindow inherits from QWidget, That's why I wrote [uses] under the hood and not inherits from ;) Maybe my used as base wording was a bit misleading here: I meant that the QtGui library acts as a base (basis? Sorry, not a native English speaker here ;)) for both QWidget and QtQuick applications to interact with the underlying windowing system. So whenever a QWidget figures out that it is a top-level widget it request a native window - by using a QWindow (in Qt 4.x and earlier that Window Manager interaction was probably all coded into the QWidget (support) classes directly). And I also wrote that a QWindow fits better into the QtQuick world, since there it is indeed a base class (now in the inheritance meaning ;)) for QQuickView etc. - for the QWidget world you need a wrapper class:, said QWindowContainer. Also refer to Laszo's reply :) Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
OK, got that now ;) Thanks, - Risto From: Till Oliver Knoll Sent: Tuesday, August 05, 2014 2:45 PM Am 05.08.2014 um 12:09 schrieb rap r...@dlc.fi: From: Till Oliver Knoll Sent: Tuesday, August 05, 2014 11:27 AM But if I am not mistaken under the hood a QWindow is also used as base for e.g. a QMainWindow. ... That don't seem to be the case, QMainWindow inherits from QWidget, That's why I wrote [uses] under the hood and not inherits from ;) Maybe my used as base wording was a bit misleading here: I meant that the QtGui library acts as a base (basis? Sorry, not a native English speaker here ;)) for both QWidget and QtQuick applications to interact with the underlying windowing system. So whenever a QWidget figures out that it is a top-level widget it request a native window - by using a QWindow (in Qt 4.x and earlier that Window Manager interaction was probably all coded into the QWidget (support) classes directly). And I also wrote that a QWindow fits better into the QtQuick world, since there it is indeed a base class (now in the inheritance meaning ;)) for QQuickView etc. - for the QWidget world you need a wrapper class:, said QWindowContainer. Also refer to Laszo's reply :) Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] question about relocating Qt library installation
On Monday 04 August 2014 09:47:55 Darren Dale wrote: I spent a good part of the weekend looking for information on the web. I'm not certain I understand the problem, but am certain there must be a solution, since the Qt installer for windows can install to an arbitrary location. It does that by binary-patching QtCore and qmake. Does your installation do that? I found a short discussion at http://stackoverflow.com/a/17640221 , talking about how qmake, Qt5Core, and a few other files need to be patched, but did not understand exactly what needs to be patched, and how. (Please excuse me for not understanding the c++ code that was posted.) Is there any documentation on how to do this? Looks like you didn't. Run strings on those files and you'll see the build paths. You need to replace those paths in the binaries and remove the qt.conf file. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Embedding QWindow
On Tue, Aug 5, 2014 at 1:29 PM, Till Oliver Knoll till.oliver.kn...@gmail.com wrote: Am 05.08.2014 um 10:48 schrieb Filip Piechocki fpiecho...@gmail.com: According to this blog post: http://blog.qt.digia.com/blog/2014/07/02/qt-weekly-16-qquickwidget never use the QWidget::createWindowContainer() :) use QQuickWidget instead. Read the fine print: ;) That's why I pasted the link to this article - so anybody can read it in details :) having a QQuickView embedded via createWindowContainer() will always lead to better performance when compared to QQuickWidget The reason is probably related to buffering: according to the blog all drawing of the QQuickWidget - that includes (raw) OpenGL drawing as well, I guess - will first go into an application specific buffer where it is combined with all the other widget paintings (notably transparent overlays etc., which otherwise would cause rendering artifacts when using native windows). That per Qt application buffering (especially referring to raw OpenGL) even raises more interesting questions on platforms such as OS X where the Window (composition) Manager itself introduces yet another per application buffer (so swapping GL double buffers on OS X is in fact pointless, since the window manager will do this for you, too). So you render into the Qt application buffer, which gets copied into the OS specific per application buffer, which eventually (with the whole composited desktop) is copied into the video (front) buffer. Even more interesting: Retina displays (on OS X). By default the OpenGL framebuffer resolution that is created by the OS when requesting a window size of w times h points is half the resolution of the Retina display, such that the same amount of OpenGL fragments are processed by default, as compared to a non-Retina display with the same window size [in points]. If one really wants to draw with OpenGL in the native (physical) resolution then a flag (in Core Graphics?) can be set before creating the corresponding OpenGL Cocoa widget. Besides the Retina use case there is another full screen with custom resolution use case: instead of switching the graphic mode (resolution) for full screen OpenGL applications one simply requests a custom size of the frame buffer. The window manager itself will then scale up that buffer (without the application having to deal with that, apart from initially requesting the custom size buffer) to the physical screen resolution. I wonder how this all adds up when the application introduces yet another per application composition layer with buffer...? But yes, there are issues with createWindowContainer ;) (especially on certain embedded systems with no Window Manager). But from what I understand they are not worse than what we know from QGLWidget (on desktop systems anyway). And let's just wait what QOpenGLWidget brings to us and how it turns out in practise with all this buffering! By now it should be clear that if you want to have as few as possible between you and the GPU: use QWindow only! Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] question about relocating Qt library installation
On 05/08/2014 05:59, Thiago Macieira wrote: On Monday 04 August 2014 09:47:55 Darren Dale wrote: I spent a good part of the weekend looking for information on the web. I'm not certain I understand the problem, but am certain there must be a solution, since the Qt installer for windows can install to an arbitrary location. It does that by binary-patching QtCore and qmake. Does your installation do that? I found a short discussion at http://stackoverflow.com/a/17640221 , talking about how qmake, Qt5Core, and a few other files need to be patched, but did not understand exactly what needs to be patched, and how. (Please excuse me for not understanding the c++ code that was posted.) Is there any documentation on how to do this? Looks like you didn't. Run strings on those files and you'll see the build paths. You need to replace those paths in the binaries and remove the qt.conf file. Or you may use this, which is pretty handy and easy to use: http://tver-soft.org/programs/qtbinpatcher Hope this helps. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] question about relocating Qt library installation
On Aug 5, 2014, at 8:39 AM, Yves Bailly yves.bai...@verosoftware.com wrote: On 05/08/2014 05:59, Thiago Macieira wrote: On Monday 04 August 2014 09:47:55 Darren Dale wrote: I spent a good part of the weekend looking for information on the web. I'm not certain I understand the problem, but am certain there must be a solution, since the Qt installer for windows can install to an arbitrary location. It does that by binary-patching QtCore and qmake. Does your installation do that? I found a short discussion at http://stackoverflow.com/a/17640221 , talking about how qmake, Qt5Core, and a few other files need to be patched, but did not understand exactly what needs to be patched, and how. (Please excuse me for not understanding the c++ code that was posted.) Is there any documentation on how to do this? Looks like you didn't. Run strings on those files and you'll see the build paths. You need to replace those paths in the binaries and remove the qt.conf file. Or you may use this, which is pretty handy and easy to use: http://tver-soft.org/programs/qtbinpatcher Hope this helps. -- /- Yves Bailly - Software developer -\ \- Sescoi RD - http://www.sescoi.fr -/ The possible is done. The impossible is being done. For miracles, thanks to allow a little delay. There is also the Qt Installer Framework which can patch the Qt Libraries for a given installation path. We have used this on the DREAM3D project for our SDK which includes Qt, though only on Windows. QtIFW supposedly also works on LINUX and OS X but we have not tried that functionality yet. Mike Jackson ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Preventing QUrl from encoding query parameters
You can't do what you want. QUrl will normalise what it has to. That's what I had feared. I was digging through the source I couldn't find a hidden force do things wrong flag. So just make sure that you are running Qt 5.3, since there were bugs in previous versions. If that doesn't work, fix your server. If it was my server, I'd fix it in an instant. But unfortunately it's a 3rd party server which I can't modify. While I try to get them to fix it, I think I'll just use curl spawned from QProcess. Thanks for the confirmation Thiago. -- Lorne Sturtevant Sum Ergo Cogito ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] [OT] Re: Preventing QUrl from encoding query parameters
Am 05.08.2014 um 18:01 schrieb Lorne Sturtevant dra...@shaw.ca: You can't do what you want. QUrl will normalise what it has to. That's what I had feared. I was digging through the source I couldn't find a hidden force do things wrong flag. You did not stumble over the most-wanted Do What I Mean(tm) flag by any chance during your research? ;) Cheers, Oliver ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] QHash memory management
Just a quick question about using QHash with pointers.
Lets say I have the following snippet:
//===
QWebView *view;
QHashint, QWebView * hash;
for(int i=0; i10; i++) {
view = new QWebView(this);
hash.insert(i, view);
}
go do something meaningful
//or do a hash.clear();
for(int j=0; j10; j++) {
hash.remove(j);
}
//===
After the remove or clear is called, do I still need to delete the
pointers? If so, would I just iterate through them using the value
function and delete them one by one?
-Jason
--
//---//
Jason R. Kretzer
Lead Application Developer
ja...@gocodigo.com
C:606.792.0079
H:606.297.2551
//---//
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Generating .avi or .mpg from Qt? (from sequence of QImages or QPixmaps)
We are generating on-screen animations in Qt 4.8.6 widgets on Windows (just redrawing, based on a repeating QTimer). Does Qt4 or Qt5 proper support (or will Qt5 soon support) generation of .mpg / .mpeg (MPEG) or .avi files for generated animations? I'm imagining that this would be done by providing a sequence of QImages or QPixmaps having consistent dimensions, perhaps with a specified frame rate. Short of that, are there any well supported third-party Qt packages for doing this? Thanks in advance, Phil Weinstein CADSWES, University of Colorado ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QHash memory management
Yes, you do need to delete them. You can keep them as scoped_ptr instead of
raw pointer.
On Aug 5, 2014 5:10 PM, Jason R. Kretzer ja...@gocodigo.com wrote:
Just a quick question about using QHash with pointers.
Lets say I have the following snippet:
//===
QWebView *view;
QHashint, QWebView * hash;
for(int i=0; i10; i++) {
view = new QWebView(this);
hash.insert(i, view);
}
go do something meaningful
//or do a hash.clear();
for(int j=0; j10; j++) {
hash.remove(j);
}
//===
After the remove or clear is called, do I still need to delete the
pointers? If so, would I just iterate through them using the value
function and delete them one by one?
-Jason
--
//---//
Jason R. Kretzer
Lead Application Developer
ja...@gocodigo.com
C:606.792.0079
H:606.297.2551
//---//
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Generating .avi or .mpg from Qt? (from sequence of QImages or QPixmaps)
On 5 August 2014 23:22, Phil Weinstein ph...@indra.com wrote: Short of that, are there any well supported third-party Qt packages for doing this? How about just feeding the sequence of images to an external encoder like ffmpeg/libav or mencoder? -- Giuseppe D'Angelo ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Generating .avi or .mpg from Qt? (from sequence of QImages or QPixmaps)
Hello, Try using QtGstreamer and a multifile source: http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugins/html/gst-plugins-good-plugins-multifilesrc.html On Tue, Aug 5, 2014 at 11:22 PM, Phil Weinstein ph...@indra.com wrote: We are generating on-screen animations in Qt 4.8.6 widgets on Windows (just redrawing, based on a repeating QTimer). Does Qt4 or Qt5 proper support (or will Qt5 soon support) generation of .mpg / .mpeg (MPEG) or .avi files for generated animations? I'm imagining that this would be done by providing a sequence of QImages or QPixmaps having consistent dimensions, perhaps with a specified frame rate. Short of that, are there any well supported third-party Qt packages for doing this? Thanks in advance, Phil Weinstein CADSWES, University of Colorado ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] QHash memory management
Hi, take a look at qDeleteAll() function: http://qt-project.org/doc/qt-5/qtalgorithms.html Cheers 2014-08-06 3:50 GMT+06:00 Giuseppe D'Angelo dange...@gmail.com: On 5 August 2014 23:24, preeteesh kakkar preeteesh.kak...@gmail.com wrote: Yes, you do need to delete them. You can keep them as scoped_ptr instead of raw pointer. You can't use scoped / unique ptr inside of a Qt container because they're not copiable. A shared pointer works, though. -- Giuseppe D'Angelo ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Preventing QUrl from encoding query parameters
On Tuesday 05 August 2014 10:01:30 Lorne Sturtevant wrote: You can't do what you want. QUrl will normalise what it has to. That's what I had feared. I was digging through the source I couldn't find a hidden force do things wrong flag. So just make sure that you are running Qt 5.3, since there were bugs in previous versions. If that doesn't work, fix your server. If it was my server, I'd fix it in an instant. But unfortunately it's a 3rd party server which I can't modify. While I try to get them to fix it, I think I'll just use curl spawned from QProcess. Just open a QTcpSocket to the server and send the GET command. And add this comment to your source code: // This looks like HTTP but isn't! // This is actually a binary protocol, since it doesn't conform // to RFC 2616 and RFC 3896. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
