As I mentioned earlier I was pretty interested in this as nothing else with sufficiently good end-user experience exists in the Qt world. There is the Qt Installer Framework, but from what I've seen in Qt Creator, that is designed for developers - pulling people through wizards is not the way to go in 2017.
I've implemented DBLSQD in Mudlet, an open-source project (code available). We use DBLSQD handle the server-side part of running an updater - provide a feed clients can check for new versions, and parts of the client-side as well. On the client-side, it handles downloading of the new binaries, showing the update window, and a changelog window post-update.
Installing updates is complemented by Squirrel on Windows and since we use AppImage on Linux, no installation is necessary there. I did find it too difficult to integrate with Sparkle on macOS given by lack of Objective-C knowledge that Sparkle required, on macOS we use Sparkle entirely and DBLSQD provides the feed for Sparkle to work with.
So, overall, I'm super happy with this! Finally been able to add an updater to our application and @pentacent has been super helpful throughout the process. He's super responsive in communication, he adapted dblsqd to fit our needs, and he was also happy to include contributions we made to the clientside code. If I need an update solution for a commercial project, I would be more than happy to purchase a plan - the tech is good and support is top-notch.
I know I'm late to the party, but for what it's worth:
There is rarely ever a need to manually update the GraphicsScene. It will automatically update parts whenever you move items (setPos), or change properties of ready-to-use items such as QGraphicsRectItem
If you implement your own item and your own paint method, naturally the scene cannot know which properties will affect the paint and which won't. Therefore, you just call update() on the item after you changed any properties that affect the way the item looks
If you change the boundingRect(), don't forget to call prepareGeometryChange(), otherwise you will have nasty painting effects
Re sorting: qSort, anyone?
After further investigation, it appears that this is because I am using OpenGL - the 'fullUpdate' flag in updateScene is always set in this case - qgraphicsView has "accelerateScrolling = !isGlWidget" [in setupViewport, line 2759] and "fullUpdate = !d->accelerateScrolling" [in updateScene, line 2675]
Thank you. In fact that was what I thought too, I was just worried, since I read that processEvents() [...] can cause a lot of unexpected issues if your code is not reentrant. Here it says that it [...] makes the application react with delays to events. Furthermore the code is difficult to read and analyze, therefore this solution is only suited for short and simple problems that are to be processed in a single thread, such as splash screens and the monitoring of short operations. In response to this, I can say that, graphically speaking, the application works really well indeed, without delays (for example when I press a button to stop the execution). Here it is said that you can call this function occasionally when your program is busy performing a long operation. But, in the event that you are running a local loop which calls this function continuously, without an event loop, the DeferredDelete events will not be processed. As far as I know, this is not my case, since I do have an event loop (I think) in the main.cpp, in which I have return a.exec();:
so if I prefer 16ms, that will make the cursor move 8 pixels each 16ms, which is maybe too jolting to see ...
It's not a question of preference. It's a hardware constraint. paintEvent won't happen more often that the hardware allows. It's not that you shouldn't update more often. It's physically impossible (unless you've got a high-frequency display, which very few people do).
Thank you very much alex. I just tried what you suggested and it works perfectly.
I thought about slots and timer too, as suggested in the examples on qt's site, but it requires subclassing a QGraphicsItem for each item in the QGraphicsView. The problem is, I don't know the number of items that will be generated until runtime, and apart from this, creating 10.000 classes (one for each item) would be very resource intensive, I think.
Anyway, the method above, the one with
QCoreApplication::processEvents () ;
works perfectly for my purpose.
So thanks both for your politeness: it is very nice to see such a great community :)
If I call glFinish() after my rendering is done, then I can make it work right (given that I specified double-buffering, otherwise the colors appear way too bright).
The downside is that with glFinish(), the rendering takes 30% longer..
@Chris-Kawa Hi thanks for your reply. For some reason, though, it has started working again. All i changed was I added QWidget::resizeEvent(pEvent); to the GameView class and it started working. However, here is where it gets weird. when i remove that line it still works, so effectively i have changed nothing and it started working
@alex_malyu Well, it actually not. At least in this case (I don't know if this depends on your operating system, or on the type of widget or something like that)
If I comment my update() call, paintEvent is never called, no matter how much I move the mouse over it.
I know about the proxy settings of the MaintenanceTool.exe but did not find any possibility for setting a proxy in the QtSdkRepoChooser.exe tool :-(
Anyway, thanks for the tip with the Interest mailing list. I will try there.