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.
The auto-updater is essentially done, except for the GUI. For now this is only an API.
The API works, but the tools to manage the update server would need some love
