Add PosixSignalNotifier utility class to covert POSIX signals to
Qt signals and allow qTox to quit appropriately on Linux, FreeBSD
and macOS.
Might protect from data corruption bugs when application is being
terminated during I/O.
Fixes: #4470
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.
In cmake builds, `__FILE__` is the absolute file path. In qmake, it's a
relative path. For in-tree qmake builds, it would be `"src/..."`, for
out of tree, it could be `"../src/..."` or `"../qTox/src/..."` or any
other relative path depending on how qTox was built. This change
normalises them to paths based in src.
Previously HiDPI support is conditionally enabled based on compilation
parameters as well as environmental variables which makes binary
distribution difficult. This commit automatically enables runtime DPI
scaling if Qt supports it (version 5.6 and beyond).
This is to prevent log files from ever exceeding a limit of 1MB each. Only the current and one other log file are kept, giving hopefully enough history for any neccessary debugging.
* Removed duplicate code of ipc event sending
* Removed duplicate code of profile loading
* Fixed bug where activating existing instance still started new instance of qtox asking to select a profile
* IPC messages are now profile-aware and are sent to instance that runs specified profile in -p flag or to ipc owner if -p is not specified.
If -p flag is specified ipc events will be send to instance which runs specified profile. If instance using that profile does not run - new qTox instance will be started. This works with password-protected profiles too - new instance will handle "uri" or "save" events after accepting user password.
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.
The qTox Project is not associated with the Tox Project in any ways, 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.
Starting a new instance with the -p option will force it to start a new instance with the given profile instead of bringing an eventual existing instance to the foreground
Two instances can not run with the same profiles, the profile locking code will ensure that. A user who likes to live dangerously could manually delete the lock to force two instances on the same profile, but such an hypothetical user would be asking for it.
If a qTox instance starts and becomes owner of the IPC shared memory on its first try, it considers itself the only running freshly-started instance, and deletes any possibly stale lock before starting up. This should be fine in the vast majority of cases, but if an existing qTox instance freezes for a long enough time to lose ownership of the IPC and a new instance is started without first killing the frozen one, the frozen instance's lock will be deleted as stale by the new one. If the frozen instance subsequentely unfreezes, it will be running on a profile for which it doesn't have a lock, which could cause trouble. This is an intentionaly allowed edge case, the alternative being a stale lock staying forever until removed manually. A potential solution not yet implemented would be to check that the lock is still actually present before attempting any write.
* added copyright header to src/platform/statusnotifier/enums.c
* 'switch(' → 'switch ('
* use Allman style
----
for / if / while / switch () {
↓
for / if / while / switch ()
{
----
----
for / if / while ()
{
1_line;
}
↓
for / if / while ()
1_line;
----
----
for / if / while ()
1_line;
line_out_of_loop;
↓
for / if / while ()
1_line;
line_out_of_loop;
----
* Removed waitUntilProcessed() because waitUntilAccepted() fits the job. They were nearly identical too so decreased code duplication
* Global events are set as processed only by instance that accepts them. Solves issue where global event would be consumed by first instance that saw it even if that instance ignored that event
* Fixed bug where running qtox instance would not properly exit after sending window activation event that was accepted by already running instance
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.
