Thank you for the report. I have banned the user, which got rid of the spam posting. Not a loss, as this user did not post any other content on the site. Just deleting this one posting was not possible.
It's obviously quicker to read/write the database in memory rather than on the HDD.
Just as a note.
I would check/measure that assumption before copying the database around as if its small enough to fit in memory,
the file system/OS might already cache it and reading speed gains would be nonexisting and also the
write cache on the hard drive might also reduce any speed effect seen on actual write.
Im only saying to check it as at work i did move DB from disk to in mem for the logging system
and did not see much improvements. just a few microseconds for the logging.
However, the disk is a solid state type so if you are using a spin disk, it might give more.
Just as a note.
It seems to be http://wiringpi.com/
that gpio executables comes from - and its also a library
so if calling the command line utility turns out to be a no-go then
the library should be directly useable. ( and seems easy too)
Although I am not the person to advise you on what videos/tutorials to use, perhaps it is time to accept that one, which is years old and completely does not work in Qt5, is simply not the right one to persist with now. If you read the comments to the youtube video you already see lots of "this doesn't work with Qt5, how do you do it using QNetworkReply?", indicating that others are aware this is not a suitable starting point nowadays, and may not be a good idea for beginners....
Out of curiosity, and not wanting to start a flame war, I'm slightly surprised that you ship I/O access out-of-process. It may well be convenient for debugging/testing, but for production? Then again I know nothing about hardware, so you may so that serial port top speed is slow it doesn't matter, I don't know....
That's about what I kind of expected. It's telling us something, but I'm not sure what! Next steps:
I'm not quite sure if you can do this, but can you now move timer2 into its own thread and see how it behaves? It probably doesn't need to log timer1's remaining time, because you know what happens to that, it can probably just log itself. You want to know whether that keeps ticking after timer1 stops?
It might be time to try @Kent-Dorfman's suggestion: just a standalone project/executable which does nothing but logs a timer, if that too stops then...?
Let's be clear: you say you have two threads. Does your timer1 run in the same thread as your GUI (which you say remains responsive), or does it run in the other thread??
You could install an older Qt Version (for example 5.6). Then go to help in Qt creator, search for Websocket, open it and a pop up window should give you the choice among the available Qt versions on your system. Choose Qt 5.6, and there you are. May not be the slimmest possibility, though.
If you are talking about the fact that in general apps for mobile platforms like iOS and Android are generally unavailable for desktops ... then it's only a business constraint, there is no technical limitation.
Even if you use a framework like Qt, you have to take in mind that user interaction and interface are different from mobile platform to desktop, so if you started to develop with a mobile phone in mind, then making it a proper desktop app requires revisiting the UX design and eventually add functionality that people using desktop apps are expecting. This means an additional cost that no one wants to risk until has an enough number of requests that justify this cost.
For those wondering, I had to add the --multimedia option to the windeployqt command. I didn't realize there were separate options in windeployqt for each Qt module... guess I should have read the docs more carefully! Thanks to SGaist.
@J.Hilk Just switched off QtCreator-> help -> About Plugins->ClangCodeModel The first issue became solved. All is OK with duplicating. The first impression of the switching off this plugin - QT Creator became working MUCH FASTER! It's working without unreasonable pauses.