Re: [Interest] QtWidget examples not being run
Hello Thiago, Thanks for your quick response. Yes there is an inbuilt Qt 5.9.7 version installed as part of TI sdk though am setting Qt 5.6 3 path before rebuilding examples. If we remove Qt 5.9.7 libs and Qt5 plugins, does it suffice or we need to remove .pc,cmake and includes as well? Best Regards, Ramakanth On Tue, 7 Jul, 2020, 21:40 Thiago Macieira, wrote: > On Tuesday, 7 July 2020 06:36:16 PDT Ramakanth Kesireddy wrote: > > ./animatedtiles: relocation error: ./animatedtiles: symbol > > _ZN14QGraphicsSceneC1EP7QObject, version Qt_5 not defined in file > > libQt5Widgets.so.5 with link time reference > > You have more than one Qt version in your system. > > Delete all but one and rebuild everything. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel System Software Products > > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Pause QTableView while model continues to update
On 08/07/2020 20:20, Murphy, Sean wrote: The only idea I have at the moment is to have a second model object, that is identical to the first one, except that it isn't connected to the sensor. At the time the user wants to pause the view, I copy the current data out of the main model into the second model, swap out the paused view's model out to the second model, and then swap it back to the main model when the user wants to go back live. Am I missing something easier? The only other idea I had was that I could try to change the second view from a pure QTableView to one that inherits from QTableView and then have my own slot that disconnects/connects the signals between the model and that view based on the when the user wants to pause/resume. This sounds much harder, hackish and difficult to test than simply having a "snapshotting" model like you proposed earlier. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: S/MIME Cryptographic Signature ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Pause QTableView while model continues to update
Is there a way to temporarily pause a QTableView while the underlying model continues to update? My scenario: - I have two separate QTableViews connected to a single model. - The model is being fed from a continuously updating data source, i.e. a sensor. - One of the views needs to remain live at all times - so as the model's data updates, the view updates immediately. For the other view, the user should be able to "pause" that view's display, spend as much time as they want looking at the data on that paused table, and then whenever they choose, they can un-pause that view and it returns to updating constantly. This view has to remain fully usable (scroll bars work, clicks work, etc.) while paused. The only idea I have at the moment is to have a second model object, that is identical to the first one, except that it isn't connected to the sensor. At the time the user wants to pause the view, I copy the current data out of the main model into the second model, swap out the paused view's model out to the second model, and then swap it back to the main model when the user wants to go back live. Am I missing something easier? The only other idea I had was that I could try to change the second view from a pure QTableView to one that inherits from QTableView and then have my own slot that disconnects/connects the signals between the model and that view based on the when the user wants to pause/resume. Sean This message has been scanned for malware by Forcepoint. www.forcepoint.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 105, Issue 25
On Tuesday, 7 July 2020 12:07:20 PDT Roland Hughes wrote: > > You know, it's sometimes amusing to listen to your rants and anecdotes > > (and sometimes not), but I'd really wish you would spend a bit more time > > on actually verifying stuff before posting it. Some people might actually > > believe you. > I wish people would spend a bit more time verifying things too. > > https://www.google.com/books/edition/Desktop_Linux/jHTj-clXms8C?hl=en=1 > =k+desktop+history=PA183=frontcover > > Page 183 of above book. The book is wrong. You do realise that Kai and I worked directly with Matthias Ettrich for many years and we asked him directly about this? The founder of KDAB (whose initials are KD) was also there and says the same story. The KDE representative to the KDE Free Qt Foundation was also there and he says he's the one who tried to retroactively call it "Kool" but it didn't stick. That's the opposite of Linux, where the original author had a different name for his project when he first uploaded it and it didn't stick. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] I love QML
On 2020-07-08 08:09, Till Oliver Knoll wrote: Am 03.07.20 um 17:46 schrieb joao morgado via Interest: When I started using Qt I never touched WIndows MFC again. Ha! But you actually /did/ touch MFC then ;) Here's another fan story (even though I am - unfortunately - not working professionally with Qt for a very long time)... ... ... Having some first experience with Linux and KDE 1.x I had heard about a thing called Qt (which was at version 2.x at the time, IIRC). My diploma work in 2001 was about developing a "3d paint editor" (www.pointshop3.com, for the interested) based on an existing "point-based software renderer", which was... of course written in C and MFC - yikes! So my first suggestion to the PhD student who was overseeing my work was to rip away everything that spelled "MFC", make it compile with a C++ compiler and use Qt instead. "Go ahead, son. But if you run into trouble you're on your own!" Turned out that my decision to use Qt (of which I only knew so little, but had browsed its excellent documentation, which already convinced me that I could pull it off - and of course the nice "Java-like" syntax of its API) was worth pure gold. After just two weeks or so I had the existing 3D "point-based renderer" compiling and running within a basic Qt application, with a main window and menu - yesss! After exact four months I had a "3d paint editor" with selectable brushes, "gauss texture filtering", a software and OpenGL renderer (switchable at runtime), and all extendable with plugins. Hadn't it be for Qt, its excellent API and especially the documentation and examples I wouldn't have come that far, in so little time! The application was later ported to Qt 3 by others and made runnable on Linux as well (I developed it mainly on Windows at the time), and was extended with some plugins "all over the world" (well, from some universities in France and Holland at least ;)) Lessons learned: a clean API and a great documentation with examples is what makes a great toolkit! And of course its functionality ;) Hooray for Qt! :) Hi, I think you used MFC in the wrong century :-) For all the MFC bashing: before it I used Microsoft C and the Windows SDK. So when MFC was released in 1992, it was a game changer which had a lot of influence (for example I wrote C++ code for the Palm Pilot using Metrowerks and a MFC clone). But with so many other Microsoft things, MFC had its peak in the early 00's. One great feature of Qt is the ownership model, which allows stuff like deleteLater(). MFC had no such concept, e.g. all the CStrings you placed on a listview, who owned them? Memory leaks were common. Another great feature of Qt is portability, on my Raspberry PI 4 I've just replaced the SD-card with a USB3-SSD, speed difference in file loading is about 10x. So now Qt Creator is just so nice to run on it, gives you a cheaper taste of the Apple Silicon to come :-) Rgrds Henry ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] I love QML
Am 03.07.20 um 17:46 schrieb joao morgado via Interest: > When I started using Qt I never touched WIndows MFC again. Ha! But you actually /did/ touch MFC then ;) Here's another fan story (even though I am - unfortunately - not working professionally with Qt for a very long time)... Back in the days(tm), near the end of my computer science education, I was so ready to write "real applications". You know, proper GUI, Windows 2000, games, ... enough with "silly Oberon", enough with "command line exercises" written in C, enough with ugly Motif/C++ feature extensions... I was ready for the real world! So I bought a book "GoTo Visual C++ 6" with a "comprehensive introduction to MFC", shortly around the time before my diploma work started. I don't know how many hours (possibly days, to be fair ;)) I had this book in my hands, but the very moment I came across "macro programming" as in: BEGIN_MESSAGE_MAP(...) ON_COMMAND(ID_APP_ABOUT, ...) // Don't change this generated code! ... END_MESSAGE_MAP() or "gems" like ON_BN_CLICKED(IDD_BUTTON_0, OnNumber) ... item.mask = LVIF_TEXT | LVIF_IMAGE; ... item.pszText = (LPSTR) I immediately knew: this is not it! I wasn't sure whether I should stick a needle through the book or burn it entirely... but don't touch that! (The above code snippets come straight from that book, which is proof that it still exists - I couldn't make up such evil stuff myself ;)) Having some first experience with Linux and KDE 1.x I had heard about a thing called Qt (which was at version 2.x at the time, IIRC). My diploma work in 2001 was about developing a "3d paint editor" (www.pointshop3.com, for the interested) based on an existing "point-based software renderer", which was... of course written in C and MFC - yikes! So my first suggestion to the PhD student who was overseeing my work was to rip away everything that spelled "MFC", make it compile with a C++ compiler and use Qt instead. "Go ahead, son. But if you run into trouble you're on your own!" Turned out that my decision to use Qt (of which I only knew so little, but had browsed its excellent documentation, which already convinced me that I could pull it off - and of course the nice "Java-like" syntax of its API) was worth pure gold. After just two weeks or so I had the existing 3D "point-based renderer" compiling and running within a basic Qt application, with a main window and menu - yesss! After exact four months I had a "3d paint editor" with selectable brushes, "gauss texture filtering", a software and OpenGL renderer (switchable at runtime), and all extendable with plugins. Hadn't it be for Qt, its excellent API and especially the documentation and examples I wouldn't have come that far, in so little time! The application was later ported to Qt 3 by others and made runnable on Linux as well (I developed it mainly on Windows at the time), and was extended with some plugins "all over the world" (well, from some universities in France and Holland at least ;)) Lessons learned: a clean API and a great documentation with examples is what makes a great toolkit! And of course its functionality ;) Hooray for Qt! :) Cheers, Oliver ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
