Re: [Interest] Qt online installer: Linux ARM platform?
Hi! On Fri, 2 Jun 2023 at 14:52, Alexander Dyagilev wrote: > > 1. In an ideal world, yes, I agree with you :) But, in this real world > we have to deal with a lot of issues including Qt bugs. In case we do > provide Qt binaries alongside with our app we provide our users the best > possible experience. As long as your Qt binaries have all the real support your app needs, yes. But that's normally what the distro-provided binaries do, else file a bug. > Before we made a release, we test our app with the > specific Qt version to make sure all is working fine. In case of an > update of Qt binaries, things can go wrong. And we have such examples in > our practice. So we prefer to provide prebuilt Qt binaries alongside > with our app. That depends on the distro. You mentioned the RPi, on which RaspberryPi OS is the default. RPiOS builds upon Debian stable, so you will not get any updates except CVE or very important bug fixes. > 2. I'm not a very experienced Unix developer. My primary platform was > always Windows. I'm not sure if I even understood you 100% correctly. > >a) You mean we should to just compile our code using ARM compiler and > let the system use the already installed Qt binaries ? Build with the system's toolchain, using the system's Qt. As long as your app is FLOSS and/or you only use the LGPL-licensed parts of Qt, of course. >b) But what about debugging then... It seems it's not supported in > any way. Yes, it is. Install the debug packages for the required libraries. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/ ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Wayland: handle one or two displays like Weston does
Hi Shawn! On Tue, 23 May 2023 at 18:21, Shawn Rutledge via Interest wrote: > > > > On 19 May 2023, at 16:02, Lisandro Damián Nicanor Pérez Meyer > > wrote: > > > > Hi! > > > > Is there any example of QtWayland's compositor handling one or two monitors > > like Weston does? > > > > To be more precise: my hardware, iMX8M-PLUS based, has an LVDS display and > > an HDMI output. > > > > The LVDS display is always connected, and if weston is started it will set > > the shell to be as big as the LVDS display itself. > > > > Now if an HDMI monitor gets attached Weston will expand the shell to the > > right with the new display's size... > > As far as I know, we have not yet implemented display hotplugging. The main > use case so far for QtWayland compositors is embedded: you might have > multiple screens on one GPU in your car, but they are fixed and configured at > the factory. I would also like to have hotplugging in eglfs though, because > it’s one of the obstacles in the way of using QtWayland on laptops and such > (don’t want to have to restart the compositor if I connect a second monitor); > but I think this involves more work with libdrm to achieve. (I've spoken to > colleagues about it a few years ago, so I’m just remembering what was said at > the time, but didn’t get around to trying to implement it.) Thanks for the reply! Well, turns out this is for an embedded device: a device in which a user could plug a monitor and get either the screen mirrored or a new window with some more content :-/ So basically I should try to make the Weston IVI shell work, at least for the moment. I'm talking about IVI here because one can position the window programmatically, not because of cars :-) If you ever get to try to implement it, ping me and I'll test it ;-) -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/ ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Wayland: handle one or two displays like Weston does
Anyone? signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Wayland: handle one or two displays like Weston does
El viernes, 19 de mayo de 2023 11:02:16 -03 Lisandro Damián Nicanor Pérez Meyer escribió: > Hi! > > Is there any example of QtWayland's compositor handling one or two monitors > like Weston does? > > To be more precise: my hardware, iMX8M-PLUS based, has an LVDS display and an > HDMI output. > > The LVDS display is always connected, and if weston is started it will set > the shell to be as big as the LVDS display itself. > > Now if an HDMI monitor gets attached Weston will expand the shell to the > right with the new display's size, something like: > > +-++ > |LVDS || > | | HDMI | > +-+| > | || > +--+ > > Hope you see that in fixed-size font :-) > > I have tried (hopefully all) the Qt 6.4.2 examples and: > > - The multi-output and multi-screen examples sadly fail with > > EGLFS: OpenGL windows cannot be mixed with others. > > This is not the same thing as what Weston does but would have helped to solve > my issue in a different way. > > - All the other options seems to require a pre-defined config file (normally > kms.conf) with the display's resolution previously harcoded in it. This I > need to avoid as I don't know what resolution will the plugged monitor have. > > Am I missing something? Is this possible at all with QtWayland's compositor? Actually another good question is: would it be possible to override the content on kms.conf at run time? Code for detecting a new display should be possible (weston does it, maybe there is even a dbus signal...) signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Qt Wayland: handle one or two displays like Weston does
Hi! Is there any example of QtWayland's compositor handling one or two monitors like Weston does? To be more precise: my hardware, iMX8M-PLUS based, has an LVDS display and an HDMI output. The LVDS display is always connected, and if weston is started it will set the shell to be as big as the LVDS display itself. Now if an HDMI monitor gets attached Weston will expand the shell to the right with the new display's size, something like: +-++ |LVDS || | | HDMI | +-+| | || +--+ Hope you see that in fixed-size font :-) I have tried (hopefully all) the Qt 6.4.2 examples and: - The multi-output and multi-screen examples sadly fail with EGLFS: OpenGL windows cannot be mixed with others. This is not the same thing as what Weston does but would have helped to solve my issue in a different way. - All the other options seems to require a pre-defined config file (normally kms.conf) with the display's resolution previously harcoded in it. This I need to avoid as I don't know what resolution will the plugged monitor have. Am I missing something? Is this possible at all with QtWayland's compositor? Kinds regards, Lisandro. signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] MSVC not-the-latest: are you using it? why?
Hi, On Sun, 22 Jan 2023 at 14:28, Philippe wrote: > > > Medical devices/software would need to go through a whole set of > > revalidation if the compiler changes > > This is understandable, but then logic would like it to be the same for > the use of any new version of the Qt framework. That's a valid remark, updating Qt means there should be no issue in updating the compiler at the same time. -- Lisandro Damián Nicanor Pérez Meyer https://perezmeyer.com.ar/ ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] MSVC not-the-latest: are you using it? why?
On Sun, 22 Jan 2023 at 13:18, Thiago Macieira wrote: > > In this case, MSVC 2019, which is still supported. > > I'm trying to understand why people don't upgrade their Visual Studios. In the > past, they used to use different and binary-incompatible VC runtimes, so large > projects often needed to stick to a single version because of different teams > needing to otherwise have a flag day. > > But that hasn't been the case since MSVC 2015. So, are you still sticking to > older MSVC releases years after there's a new one? Why? Medical devices/software would need to go through a whole set of revalidation if the compiler changes. On that field changes are complicated. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Building QtPdf from boot2qt 5.14.1
Hi Michal! El vie., 10 de septiembre de 2021 07:04, Michal Klocek escribió: > Hi > > I am not sure which documentation do you refer to, but QtPdf was merged to > be part of qtwebengine repository in 5.15 > https://doc.qt.io/qt-5/qtpdf-module.html "This module was introduced in Qt 5.14." But yes, it makes sense. Was it available as a separate repo before? The one I found has it's last commit from 2018. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Building QtPdf from boot2qt 5.14.1
Hi! I'm trying to build Qt PDF libraries from boot2qt using Qt 5.14.1. Documentation says it was added in 5.14, so it should be there. But even building the whole webengine I fail to see QtPdf mentioned in the configure step nor the libraries built. Am I missing something? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt 6 Ubuntu package
Hi! On Thu, 28 Jan 2021 at 03:57, Florian Bruhin wrote: > > Hey, > > On Thu, Jan 28, 2021 at 12:08:44PM +0530, Nibedit Dey wrote: > > I am looking for a way to install Qt6 without downloading the > > *qt-unified-linux-x86-4.0.1-online.run* file. > > Is there a Qt 6 Ubuntu package like the one for Qt 5? e.g.:- *sudo apt-get > > install qt5-default* > > Ubuntu's packages are mostly inherited from Debian, where the Qt package > maintainers stepped down before the Qt 6 release because of a lack of > time: > > https://perezmeyer.blogspot.com/2020/08/stepping-down-as-qt-6-maintainers.html > https://www.phoronix.com/scan.php?page=news_item=Debian-Needs-Qt6-Maintainers > > Also see: > > https://alioth-lists.debian.net/pipermail/pkg-kde-talk/2021-January/003236.html > > Given that everyone there is focusing on the next Debian Stable > (Bullseye) which will ship Qt 5.15.2, I doubt there was work on Qt 6 so > far. I can also add that so far no one stepped up to do the job yet. I only got one request for information about it. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Fail to compile qt4 on Ubuntu 20.04.
Or grab the packaging from Ubuntu and compile it from there, it has all the quirks resolved. On Mon, 18 May 2020 at 03:21, Vlad Stelmahovsky wrote: > > Hello > > check your gcc version > you cannot build Qt 4.xx with gcc > 5.0, afaik > > br, > vlad > > On Mon, May 18, 2020 at 1:35 AM Hongyi Zhao wrote: >> >> Hi, >> >> Ubuntu 20.04 dropped the qt4 from its official repo, but sometimes I >> still want to use it. So I try to compile it from the source but >> failed. See the info below: >> >> $ wget >> https://download.qt.io/archive/qt/4.8/4.8.7/qt-everywhere-opensource-src-4.8.7.tar.gz >> $ tar -zxvf qt-everywhere-opensource-src-4.8.7.tar.gz >> $ cd qt-everywhere-opensource-src-4.8.7 >> $ ./configure >> >> # The following step failed for Ubuntu 20.04: >> $ make -j4 >> ../../include/QtCore/../../src/corelib/tools/qpair.h:62:20: note: >> because ‘QPair’ has user-provided ‘QPair& QPair> T2>::operator=(const QPair&) [with T1 = int; T2 = int]’ >>62 | QPair =(const QPair ) >> |^~~~ >> make[1]: *** [Makefile:18175: .obj/release-shared/qsslsocket_openssl.o] >> Error 1 >> make[1]: Leaving directory >> '/home/werner/Downloads/qt-everywhere-opensource-src-4.8.7/src/network' >> make: *** [Makefile:278: sub-network-make_default-ordered] Error 2 >> >> Any hints for this problem? >> >> Regards, >> -- >> Hongyi Zhao >> ___ >> Interest mailing list >> Interest@qt-project.org >> https://lists.qt-project.org/listinfo/interest > > > > -- > Best regards, > Vlad > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QTableView, QSqlRelationalTableModel and QDateTimeEdit and timezones
Hi Tony! On Fri, 1 May 2020 at 02:00, Tony Rietwyk wrote: > > Hi Lisandro, > > AFAIK that is a bug in the design of the Qt SQL api's. There is no way > to specify to QSqlField/QSqlResult that the date being read is UTC. You > have to read the QSqlQuery yourself, convert the QVariant to QDateTime, > apply the time spec, then pass the value to the UI. > > Maybe you can derive from QSqlRelationalTableModel and override the data > method to set the time spec? I see.Maybe I'll try this, yes. I'll come back with the results if I get to do it. Thanks! -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] QTableView, QSqlRelationalTableModel and QDateTimeEdit and timezones
Hi! I have a database (PostgreSql) with a table that holds date/time in UTC. I've read this table with the QSqlRelationalTableModel and show the data with a QTableView and a QDateTimeEdit. I would like both the QTableView and the QDateEdit to show the time in local timezone, but I seem to be failing at this. I have tried with ui->admissionDateTimeEdit->setTimeSpec(Qt::OffsetFromUTC) and other time specs both before and after setting the model without success (there is a bug for that in [1]) Is there something else I am missing? The actual code is in [2] but it's not minimal. If needed I'll try to get a minimal example for this. [1] <https://bugreports.qt.io/browse/QTBUG-54781> [2] <https://gitlab.com/mosimpa/abm/-/blob/feature/manage-internments/src/internmentsform.cpp> Thanks in advance! -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] My first 5 years with Qt and 2 suggestions
El jueves, 9 de mayo de 2019 20:20:41 -03 Hamish Moffatt escribió: > On 9/5/19 6:04 pm, Shawn Rutledge wrote: > > Of course on Linux there are usually distro packages so it’s already > > easy (as long as you don’t mind them often being a bit outdated: shame > > on distros who still didn’t upgrade to 5.12 yet). And macOS has brew. > > Actually, I'd turn this around and say shame on the Qt project for not > publishing packages, at least for the major distributions. > > It's Debian's policy to publish stable releases which don't change > except for security and other essential updates. There is no argument > for updating Qt in a stable release. > > If Qt wants to get updates out to developers on Debian and Ubuntu it can > publish its own packages. > > > There are third party packages available for Ubuntu which I have rebuilt > for my Debian systems here, as I needed a newer version than 5.7 on my > Debian stable systems. With my Debian maintainer hat on: thanks for this. But I also have to say that we (Debian) currently lack certain infrastructure that would allow us to provide semi-official packages, like PPAs. It is normally not to difficult to backport Qt (except form buster to stretch, due to some changes done to allow [cross] building starting from system packages). If Debian had PPA-like infra I would certainly try to get a more or less decent backport around (would break KDE and other stuff though, due to API breakage in private API). And why not a multiver-se like PPA for Debian's (not yet existant) PPAs? That and man power/time, of course. It's always about free time :-/ [cross] <http://perezmeyer.blogspot.com/2018/11/cross-compiling-cmake-based-projects.html> -- La ciencia sin la religión es renga, la religión sin la ciencia es ciega. Albert Einstein Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Publish Qt app to fdroid
On Thu, 14 Feb 2019 at 15:25, Bernhard B wrote: > > Hello, > > I am wondering, if anyone of you has already published a Qt app to the fdroid > store? > > I did a bit of research and it seems that the fdroid guys have recently > removed Qt from their build environment (see: > https://gitlab.com/fdroid/fdroidserver/merge_requests/440). As the version > was already pretty old (I think they used Qt 5.7.x), it wouldn't have worked > for my app anyways, but I am wondering if there is anyone that has > successfully published a Qt app to fdroid or if anyone plans to publish their > app to fdroid soon? > > Any help is highly appreciated! Well, they seem to be installing the whole Qt, no wonder they get out of space quickly :-/ ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] clang-tidy version in Qt Creator
El martes, 5 de febrero de 2019 14:25:31 -03 Dmitriy Purgin escribió: > Well, try turning on more clang-tidy and clazy checks than the default > shipment of Qt Creator has! ;-) With a project of a decent size your PC's > fans will be blowing all the time like mining is still a thing! [snip] > > Since performance in static analysis is not actually important, it would > > be better if Creator would be able to use external clang binaries for > > this. Add to the mixture a not-so-new machine and voilá, performance is really important here. -- You know it's love when you memorize her IP number to skip DNS overhead. Anonymous Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Updated Debian packages or ppa for Qt 5.9+
Hi Konstantin! El miércoles, 7 de noviembre de 2018 05:12:28 -03 Konstantin Shegunov escribió: > On Wed, Nov 7, 2018 at 9:59 AM Hamish Moffatt > > wrote: > > Does anyone know of a repository for updated Qt packages for Debian > > stable (stretch / 9)? With my Debian Qt maintainer hat on: I'm afraid there is no official repo for that. I once tried to provide backports but that would mean that many packages would need to get rebuilt against the new Qt version, which seems not possible to do on Debian backports. Backporting Qt 5.10/11 to stable also requires a new dpkg due to the changes we did in order to be able to cross compile using plain Debian packages + multi arch. With my personal hat on: I would *love* to provide a PPA-like semi-official repo for this, but Debian currently lacks PPAs/bikesheds in order to do that, and my build power is limited t a 10 years old machine, so not for now. But yes, I do get lots of requests for this :-( > Pin debian testing repos with a low priority in the apt configuration and > you can get the binaries from there. Current it 5.11.2. Only if you really know what you are doing. If you use KDE stuff (kwin for example) you will certainly have to upgrade it, and thus half your system, because it uses Qt's private methods. Cheers, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] invalid Qt packaging heads up
Hi! El jue., 13 de sep. de 2018 10:53, Roland Hughes < rol...@logikalsolutions.com> escribió: > All, > > Ran into this in PinguyOS, but, probably goes all the way back to current > Ubuntu. > > > In Synaptic Package Manager one can find > > libqt5webengine5 > libqt5webengine5-dev > libqt5websockets5 > libqt5websockets5-dev > libqt5webenginewidgets5 > > but there is no libqt5webenginewidgets5-dev > If those headers are part of the qtwebengine source tarball then you only need to install libqt5webengine5-dev. If that does not helps then please ping me and I'll get it fixed. > > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.12
El mié., 15 de ago. de 2018 04:00, Christian Gagneraud escribió: > Hi all, > > Does anyone know if Qt 5.12 will support Linux on 32 bits Intel platforms? > I'm planning to try to build the new 5.12 branch on i386/ubuntu-16.04. > Any input/info appreciated. > It should. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] qmlscene install problems (was: Interest Digest, Vol 82, Issue 5)
El lunes, 16 de julio de 2018 08:12:25 -03 Ulf Hermann escribió: > This thread has gone so far south, we need to add some corrections ... [snip] > So, it turns out I have another qmake (and qmlscene) in > /usr/lib/x86_64-linux-gnu/qt5/bin/ which are explicitly the right ones, and > which I can invoke manually if I actually need them. Qt Creator autodetects > those. Mind you this is a debian-specific patch: <https://salsa.debian.org/qt-kde-team/qt/qtcreator/blob/master/debian/patches/ always_autotect_qt_versions> -- Dadme voto electrónico y con una terminal os haré presidente. el.machi Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Creating a hover form over a QGraphicsView
On martes, 7 de febrero de 2017 12:10:33 ART Lisandro Damián Nicanor Pérez Meyer wrote: > On sábado, 4 de febrero de 2017 10:19:34 ART Ch'Gans wrote: > > On 4 February 2017 at 07:55, Lisandro Damián Nicanor Pérez Meyer > > > > <perezme...@gmail.com> wrote: > > > Hi! I am creating a hover form over a QGraphicsView widget. For starters > > > I > > > used designer to create a QWidget with all the necessary hover form > > > widgets in it. Then I created a grid layout, added the hover form to it > > > and finally added it to the QGraphicsView widget. As I expected the > > > hover > > > form appears over the QGraphicsView. > > > > > > As the application runs on a touchscreen I was asked to let the user > > > scroll it using her fingers... The above approach doesn't allows that as > > > all the events end up in the widget containing the hover form. > > > > > > How could I achive a hover form over a QGraphicsView but letting the > > > user > > > scroll the QGView with her fingers? > > > > Hi > > > > I don't know what an "hover form" is supposed to be or do, > > Think of it as "widgets over a QGraphicsView", statically placed. Maybe another good word is "overlay". > > but maybe > > QWidget::setAttribute(Qt::WA_TransparentForMouseEvents) could help in > > your case. > > This indeed seems the right way to go, I'll try it. Thanks!!! Well no, as my overlay has clickable buttons as child widgets. Moreover the propagation order is always parent to child, and as the hoverform/overlay is a child of the QGraphicsView instance it won't work. I happen to find another (possibly non-elegant) way of achieving this: - Using designer create a hover form / overlay as wished. - Create an instance of the hover form *without a parent*. - Set up the hover form's layout as the QGraphicsView layout, always keeping the hover form instance. - Be sure to delete the hover form on the destructor ;-) Kinds regards, Lisandro. -- “I don’t think security can solve problems. We need to teach greater respect.” Oslo Mayor Stang when asked whether Oslo needs greater security after the attacks in Norway, 07/2011. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Creating a hover form over a QGraphicsView
On sábado, 4 de febrero de 2017 10:19:34 ART Ch'Gans wrote: > On 4 February 2017 at 07:55, Lisandro Damián Nicanor Pérez Meyer > > <perezme...@gmail.com> wrote: > > Hi! I am creating a hover form over a QGraphicsView widget. For starters I > > used designer to create a QWidget with all the necessary hover form > > widgets in it. Then I created a grid layout, added the hover form to it > > and finally added it to the QGraphicsView widget. As I expected the hover > > form appears over the QGraphicsView. > > > > As the application runs on a touchscreen I was asked to let the user > > scroll it using her fingers... The above approach doesn't allows that as > > all the events end up in the widget containing the hover form. > > > > How could I achive a hover form over a QGraphicsView but letting the user > > scroll the QGView with her fingers? > > Hi > > I don't know what an "hover form" is supposed to be or do, Think of it as "widgets over a QGraphicsView", statically placed. > but maybe > QWidget::setAttribute(Qt::WA_TransparentForMouseEvents) could help in > your case. This indeed seems the right way to go, I'll try it. Thanks!!! -- Theory and practice sometimes clash. And when that happens, theory loses. Every single time. Linus Benedict Torvalds. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Creating a hover form over a QGraphicsView
uups, little detail: I am using Qt 5.7. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Creating a hover form over a QGraphicsView
Hi! I am creating a hover form over a QGraphicsView widget. For starters I used designer to create a QWidget with all the necessary hover form widgets in it. Then I created a grid layout, added the hover form to it and finally added it to the QGraphicsView widget. As I expected the hover form appears over the QGraphicsView. As the application runs on a touchscreen I was asked to let the user scroll it using her fingers... The above approach doesn't allows that as all the events end up in the widget containing the hover form. How could I achive a hover form over a QGraphicsView but letting the user scroll the QGView with her fingers? Thanks in advace, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Performance of QGraphics[View Scene] changes with zoom
On Friday 20 May 2016 07:14:15 Uwe Rathmann wrote: > On Wed, 18 May 2016 15:57:04 -0300, Lisandro Damián Nicanor Pérez Meyer > > wrote: > > Now if I add a lot of straight lines (QGraphicsLineItem instances) > > performance (number of movements seen on screen per second) varies > > according the zoom. If I zoom in I get to a point in which everything is > > too slow. > > Qt does the polygon clipping very late, so a huge amount of pointless > caclulations is going on before it detects that it is not needed. IIRC > the Graphics View framework isn't any better than QPainter - but I havn't > checked the code quite some time. > > If this is still the case you need to implement your own polygon clipping > before entering Qt rendering code. > > At least this is what I do it in the Qwt project ( qwt.sf.net ). If you > need an implementation for polygon clipping you find something there too: > see https://sourceforge.net/p/qwt/code/HEAD/tree/trunk/qwt/src/ > qwt_clipper.cpp That sound svery plausible indeed! For now I switched to staright lines and "works for the moment", but if I need to speed up things or go back to other kind of lines I'll surely give it a look. Thanks a lot!! -- If you have an apple and I have an apple and we exchange these apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas. George Bernard Shaw Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Performance of QGraphics[View Scene] changes with zoom
On 18 May 2016 at 15:57, Lisandro Damián Nicanor Pérez <perezme...@gmail.com> wrote: > Before I try to code a stripped-down version of my issue I would like to > describe it in case I'm missing something obvious. > > I have an app with a QGraphicsScene that holds a vehicle which is constantly > moving at a fixed rate (~10 times per second). Every time it moves it draws > some polygons behind (the path it went trough). Up to that point, everything > is ok. > > Now if I add a lot of straight lines (QGraphicsLineItem instances) performance > (number of movements seen on screen per second) varies according the zoom. If > I zoom in I get to a point in which everything is too slow. If I zoom out > things go back to normal. Note that once the lines are generated they are not > changed in any way. > > I understand that performance might decrease if those lines are near 45º due > to bounding boxes, but I fail to understand why it varies with zoom. I minimized my code to simple lines and drawing the bounding box of the vehicle, and found out that the problems starts if I use anything different than Qt::SolidLine for drawing the lines. As soon as I zoom out enough (the transformation matrix becoming 0.1*Identity) the problem "goes away", so I suspect a rasterization issue. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Performance of QGraphics[View Scene] changes with zoom
Before I try to code a stripped-down version of my issue I would like to describe it in case I'm missing something obvious. I have an app with a QGraphicsScene that holds a vehicle which is constantly moving at a fixed rate (~10 times per second). Every time it moves it draws some polygons behind (the path it went trough). Up to that point, everything is ok. Now if I add a lot of straight lines (QGraphicsLineItem instances) performance (number of movements seen on screen per second) varies according the zoom. If I zoom in I get to a point in which everything is too slow. If I zoom out things go back to normal. Note that once the lines are generated they are not changed in any way. I understand that performance might decrease if those lines are near 45º due to bounding boxes, but I fail to understand why it varies with zoom. I'm using Qt 5.5 on Linux. Thanks in advance, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] harfbuzz support?
On Sunday 12 April 2015 01:20:36 René J.V. Bertin wrote: Hi, Qt can be built with or without support for text rendering using harfbuzz. Qt4 and Qt5 seem to differ slightly in this aspect, but from what I understand both can be made to use harfbuzz at runtime even when not compiled to use it (by default). I'd like to test this, as it would probably let text rendering benefit from the Infinality patches I have applied to my FreeType library. I checked my build of the Qt 4.8.7 snapshot released the other day: it's been built without giving a harfbuzz option, which should be equivalent to * -no-harfbuzz ... Disable HarfBuzz on Mac. It can still be enabled by setting QT_ENABLE_HARFBUZZ environment variable. Qt5 has the -system-harfbuzz compile switch, I don't know Qt4. If it doesn't it maybe tries to autodetect the lib at build time. -- Dadme voto electrónico y con una terminal os haré presidente. el.machi Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Mixing debug and release builds of Qt5 modules on Linux
On Friday 20 March 2015 01:03:55 Allan Sandfeld Jensen wrote: On Thursday 19 March 2015, Jan Kundrát wrote: Hi, are there any problems when some Qt5 modules are built using CONFIG+=debug and others in release mode on Linux? A Qt5 maintainer at Gentoo says that he's heard that this mixing debug and release can break the ABI. Based on what I know about Qt5, I do not think that it is true. Can we expect any problems when we do mix these modules? No that works perfectly fine on Linux. In fact you can even combine the two into release builds with debug symbols, and even have the debug symbols for the release build in a separate file. And that's what we use in Debian, for example. After building we strip out the symbols and then package them in different binary-packages. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] New Development Environment
On Saturday 07 February 2015 13:09:27 Karl Ruetz wrote: Our company is about to start the process of altering our Qt development environment. I’ve noticed that it seems most of the Trolls (if I can still use that term) are using Ubuntu. I’d like to save a little of trial and error and find out what version of Ubuntu 64-bit would be best to use if we plan to setup Qt and QtCreator from the latest Enterprise versions available. Any inputs would be welcome. If you are going to compile your own Qt then maybe the Ubuntu version currently used in the CI might be a good one. Else it simply depends on which features of Qt you need and maybe choose the latest LTS release or a newer version if you need a newer Qt. -- Quote me as saying I was mis-quoted. -- Groucho Marx Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.3 vs Qt 5.4 (etc)
On Tuesday 20 January 2015 11:42:39 René J.V. Bertin wrote: On Monday January 19 2015 23:06:05 Lisandro Damián Nicanor Pérez Meyer wrote: Hi, On Monday 12 January 2015 09:09:08 Andreas Pakulat wrote: [snip] Correct except for the packages that use Qt's private headers (please, don't do that except you are writing code for Qt itself) and between the different submodules of Qt5, as we need to ensure that qtsvg 5.x.y is always used with qtbase 5.x.y. But for the most use cases, yes, Andreas' explanation is just right. As a Debian developer you wouldn't happen to know about Ubuntu release too, would you? All I know is that two of my fellow Debian's comaintainers are also the Ubuntu ones, and they usually star doing the Debian packaging and then reusing and modifying whatever they need for Ubuntu. I've been slowly adding the various Qt 5.3 components to my 5.3.2 PPA, so the day approaches I could make another attempt to bump my 14.04LTS system from Qt 5.2 to Qt 5.3.2 ... unless someone can affirm that won't work anyway. In which case it's probably useless to continue the exercise ... All I can say is that, at least with respect to the Qt packaging, upgrading should be just smooth. And 5.3.2 is actually quite a stable release. -- 9: Que es el Explorador de Windows * El tipo que le roba las ideas a MacOs Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.3 vs Qt 5.4 (etc)
On Monday 19 January 2015 19:33:21 Thiago Macieira wrote: On Monday 19 January 2015 23:06:05 Lisandro Damián Nicanor Pérez Meyer wrote: Correct except for the packages that use Qt's private headers (please, don't do that except you are writing code for Qt itself) and between the different submodules of Qt5, as we need to ensure that qtsvg 5.x.y is always used with qtbase 5.x.y. By the way, I've been meaning to add a patch to Qt that would cause one library to use a symbol from QtCore that has the exact Qt version number in its ELF symbol. Would this help in the packaging and ensuring everything is ship-shape? Let me see if I'm getting this right because I must admit I don't even now what the GCC symbol does and I might be confusing things. If the library you mean is not part of Qt (ie, just any other lib using QtCore): would the library need to be recompiled in order to use a newer minor (z) or medium (y) Qt x.y.z version? I'm guessing not, but I want to be sure. If the library is part of Qt itself then it will certainly not hurt, but nowadays we need to push all Qt submodules at the same time because there are runtime checks in order. Ie, I can't just package qtbase 5.3.2 and push it alone waiting for another submodule like, let's say, qtsvg 5.3.1 to continue working. This is enforced by Qt itself at runtime. But then again, I need to understand it's purpose right first I guess :) -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.3 vs Qt 5.4 (etc)
On Tuesday 20 January 2015 08:15:53 Thiago Macieira wrote: On Tuesday 20 January 2015 10:25:04 Lisandro Damián Nicanor Pérez Meyer wrote: If the library is part of Qt itself then it will certainly not hurt, but nowadays we need to push all Qt submodules at the same time because there are runtime checks in order. Ie, I can't just package qtbase 5.3.2 and push it alone waiting for another submodule like, let's say, qtsvg 5.3.1 to continue working. This is enforced by Qt itself at runtime. But then again, I need to understand it's purpose right first I guess Right, this would be a run-time enforcement of the same exact version. Then it shouldn't be a problem (understanding a lib part of Qt, as you only replied to that part). -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.3 vs Qt 5.4 (etc)
On Tuesday 20 January 2015 11:08:10 Thiago Macieira wrote: [snip] Then it shouldn't be a problem (understanding a lib part of Qt, as you only replied to that part). Right. I meant anything using private API (or, at least, triggering the trick). This is intended for Qt libraries themselves, but it might help you catch mistaken uses of private API. Probably QObjectPrivate only. It will definitely help. = Just for the curious, contains debian-specific stuff Nowadays what we are doing is [0]. Basically it scans private headers and uses a special feature of Debian's symbols files, marking private symbols to create a special dependency on a certain virtual package instead of the library itself. This special package is only provided by a specific version of the library instead of just the major one. Might not be the best/more efficient thing out there for this, but it has proven to do the job quite right. The final result is that all packages that end up depending on this virtual package need either a new upload (the Qt stack) or a full rebuild (any external thing using private headers) and we can easily track them. [0] http://anonscm.debian.org/cgit/pkg-kde/qt/qtbase.git/tree/debian/mark_private_symbols.sh -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt 5.3 vs Qt 5.4 (etc)
On Monday 12 January 2015 09:09:08 Andreas Pakulat wrote: [snip] If you only look at the stable releases of Debian thats indeed how it would look like. Its a little different if you look at the 'rolling release' stream (the unstable line). You can see new Qt versions trickle in there without all kde packages following up the next days. It does happen sometimes though if a new KDE release is closely following a new Qt version. Its also visible in dependencies of packages using Qt, they are not tightened up but generally = x.y. So if a new qt version lands users can install that without all those qt-using packages 'breaking' (and hence enforcing to keep the old version until they are rebuilt). Correct except for the packages that use Qt's private headers (please, don't do that except you are writing code for Qt itself) and between the different submodules of Qt5, as we need to ensure that qtsvg 5.x.y is always used with qtbase 5.x.y. But for the most use cases, yes, Andreas' explanation is just right. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Run Qt Widget program with minimal Xorg installation on Linux
On Friday 09 January 2015 23:14:07 ruslan wrote: Ok, it should be clearer if I'll describe the program purpose. It will be server witch receives QML code, convert a visual result to image with QQuickWindow::grabWindow() and return it to caller. Some kind of remote execution. So all I need is VDS witch have ability to execute Qt program (not console). The only way I know to run it is Xorg server. May be framebuffer, but if I run the program with -target linuxfb I get same error. So VNC is only tool to see that Qt program runs in the server. Sure, I can connect with SSH and start the program from the Bash bet that gives me same errors as when I run it in BlackBox. I'll try to connect to X session on remote server with SSH and port forwarding but I still think the problem in X server itself. It looks like it misses something important. You might want to try xvfb. It provides an X virtual frame buffer which is not displayed to the user, but the application can run there. It is used a lot for automatically testing graphical stuff (and if I'm not mistaken, it was developed with that purpose). -- When the winds of change are blowing, some people are building shelters, and others are building windmills. Old Chinese Proverb Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] -headerdir causing headerfile version confusion building qtwebengine (was Qt5 cannot be build on Debian Wheezy? GLIBCXX_3.4.20' not found)
On Tuesday 20 January 2015 00:08:10 René J.V. Bertin wrote: [snip] I can only speak for Debian and Ubuntu and for those that is true for the packages that they ship, and for PPAs people can create. But do you really think that Debian or Ubuntu maintainers develop their packages starting with a clean install every time (creating a new VM each time as launchpad does)? Every Ubuntu package that I've tried to build locally builds just fine. And I don't have the impression that dpkg-build sets up some sort of chroot. I can answer that, as I am one of the people behind the Debian packages. Yes, we do build in clean chroots. We use special tools for that that helps us a lot like cowbuilder, pbuilder or sbuild. If I need to play with the source (for example, for tracing a bug) I use schroot's capabilities to create disposable chroots. It takes some time to create them, but then I'm sure I'm in a clean environment with just the tools I need. This is specially true for libraries. For applications the packaging might start in a clean environment, but must end in a clean one before uploading. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Qt automoc (CMAKE_AUTOMOC) failure with name clashes
On Sunday 14 December 2014 20:58:58 Roger Leigh wrote: I brought this up on the cmake list, since I think this is likely an issue with the cmake automoc implementation, but also posting here since it's primarily an issue when using Qt. I have a source directory layout like this: ├── gl │ ├── Axis2D.h │ ├── Grid2D.h │ ├── Image2D.h │ └── v20 │ ├── Axis2D.h │ ├── Grid2D.h │ └── Image2D.h ├── GLContainer.h ├── glsl │ └── v110 │ ├── GLFlatShader2D.h │ ├── GLImageShader2D.h │ └── GLLineShader2D.h ├── GLUtil.h ├── GLView2D.h ├── GLWindow.h └── TexelProperties.h And use this cmake configuration: set(CMAKE_AUTOMOC ON) set(CMAKE_INCLUDE_CURRENT_DIR ON) set(QTWIDGETS_GL_HEADERS gl/Axis2D.h gl/Grid2D.h gl/Image2D.h) set(QTWIDGETS_GL_V20_HEADERS gl/v20/Axis2D.h gl/v20/Grid2D.h gl/v20/Image2D.h) As you can see, the names are duplicated in the two subdirectories. I plan to have even more dupliated names as I add support for multiple gl/glsl versions. Unfortunately, cmake automoc generates this: /* This file is autogenerated, do not edit*/ #include moc_GLContainer.cpp #include moc_GLView2D.cpp #include moc_GLWindow.cpp #include moc_Axis2D.cpp #include moc_Grid2D.cpp #include moc_Image2D.cpp #include moc_Axis2D.cpp #include moc_Grid2D.cpp #include moc_Image2D.cpp #include moc_GLFlatShader2D.cpp #include moc_GLImageShader2D.cpp #include moc_GLLineShader2D.cpp Compilation inevitably fails due to it including the generated source files twice. It's discarded the path information and overwritten the generated sources where the names clash. - I've seen some old posts to this list and in other places which show this has been an issue historically, and the suggestion has been to rename the source/header files. However, that's not always possible or acceptable. In this case, it's definitely not. There's no problem with the sources/headers themselves, which are correct, just with moc. - is there any way to get automoc support to add the full pathname to the generated sources e.g. moc_gl_Axis2D.cpp and moc_gl_v20_Axis2D.cpp. - any workarounds with cmake known for this issue? Hi Roger! Did you find a solution? -- Q. How did the programmer die in the shower? A. He read the shampoo bottle instructions: Lather. Rinse. Repeat. http://www.devtopics.com/best-programming-jokes/ Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ signature.asc Description: This is a digitally signed message part. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
