Setting the parent of MessageBoxManager to Widget has a dual effect of
centreing the QMessageBox's on Widget' window which we want, but also
giving ownership of MessageBoxManager to Widget, which causes Widget to
destroy it in Widget's destructor. Since the original MessageBoxManager
must outlive Widget to be used in Settings and when loading Profiles
before Widget is constructed, we don't want Widget to destroy it.
Instead of juggling MessageBoxManager's parent around dynamically when
Nexus changes the active Window, just construct a second one in Widget
to be used by all its children with the parent set on Widget, centreing
the window and allowing it to have ownership.
Settings and Profile still use the original parent-less
MessageBoxManager since they show popups before Widget is constructed.
* Pass MessageBoxManager instantiation around instead of relying on a singleton
* Mock MessageBoxManager for unit tests when needed, since they don't have a
QApplication which is required for creating QWidgets
* Remove GUI class, which didn't have a clear purpose
Widget is the only caller, let it set its own title. Wrap inherited setTitle to
prepend "qTox". Check for thread is not needed since it is only called
from Widget's slots.
Style already has themeChanged, which was unused. GUI's themeReload just
dispatches to Style, which is already piped to GUI classes. Give the signal
to Style itself so that classes can connect to that, rather than relying on
GUI's singleton.
This allows leaf classes to update independently when the GUI has changed themes, without
their parent having to call updateTheme() manually.
Fix#5924Fix#5592
Fixes#1926 : When an IPC event was processed locally, if the window was closed before the core could start, the event handler would be forever stuck in the background waiting for the core to start. We fix this by substituting QApplication::quit() by a Nexus::quit() function and a Nexus::isRunning() function, which gives us a condition for exiting blocking processEvents() loops. We cannot simply use QApplication::quit(), because this function has no effect before the start of the event loop.
The problem was further exacerbated by the Tox URI event handler being (incorrectly) blocking. The IPC owner would block in this event handler, and the sender of the event would give up waiting and process the event itself a second time, potentially triggering the first bug. We fix the event handlers accordingly to be (mostly) non-blocking.
Also fixes a related deadlock between ~Core and ~Profile in the case of an early exit
Revert needed, since otherwise there is no way to do automatic sorting
of includes.
Also reverted change to the docs, as leaving it would make incorrect
docs.
In case of conflicts, includes were sorted according to the coding
standards from #3839.
This reverts commit b4a9f04f92.
This reverts commit 5921122960.
qTox will automatically import the old history on startup.
This new database code is much more robust.
It is very resilient and will not corrupt or disappear after a crash or
power failure, unlike the old code.
The on-disk database format is also much more compact now.
The database sync option in the advanced settings has been removed,
we know run many database operations asynchronously so performance
should not be a problem anymore, but we always ensure resiliency
in case of abrupt termination, so there is no tradeoff anymore.
The qTox Project is not associated with the Tox Project in any way, with the
exception of "qTox" using the Tox Projet's "toxcore" collection of libraries.
In particular, the Tox Projet does not own copyright over the qTox Project's
"qTox" collection of software, source code, and assets.
The qTox Project's assets are under the sole copyright of the qTox
contributors, and no partiular rights are granted to the Tox Project.
We create a GUI class to abstract common GUI needs (showing a message box, asking a question, ...) from the actual GUI backend.
We also create a Nexus class to manage the startup and lifetime of our main systems (Core, GUI, ...) instead of delegating that to Widget.
Eventually, Widget will only be in charge of the Desktop GUI and AndroidGUI of the mobile GUI. Nexus will overview the system and GUI will provide a clean platform-independant interface.