Added null checks around usage of tray icon object.
This change solves issues/crashes where tray is not immediately available when qTox is started. It is common on linux desktops. While for example lxqt has option to delay application autostart until panel (and thus tray) is available other desktops (like KDE) do not. Adding checks around use of icon object was not enough because application may start a little bit earlier than panel is available. For that reason tray icon creation is delayed to timer event and tried multiple times with delay of one second. Usually after few tries icon creation succeeds and signal is disconnected.
In case tray is not available qTox window is shown. This creates a side effect where starting qTox before tray is available will make application window briefly appear and when tray is available window will be hidden or remain visible as per settings. Window has to be visible if tray is unavailable because otherwise users may end up with qTox running and no way to access it. If application is started and tray is available no window flashing happens and settings are restored as usual.
Without this patch if qTox started before tray is available window is shown and changing tray icon visibility option crashes application. Thats probably a known issue.
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.
Setting to always notify on messages in group chats (like normal chats)
Check for mentioned name only triggers if name is not in the middle of other word
The GUI is slow to update after accepting a password, but a cursory ten minute investigation didn't yield why
I inserted a processEvents() call before ready = true; at the end of Core::start, but that didn't help.
Define the total time between the password dialog disappearing and the UI updating with your own status is T:
Then my debug statement indicated that this processEvents call happened around 1/3T, raising two questions:
1) What the hell is happening between 0 and 1/3 T? Decryption doesn't take that long...
Note that bad passwords are immediately rejected with a new dialog, so I highly doubt it's the decryption cpu time
2) The remaining 2/3rds: processEvents has been called after the avatar and username signals, yet they
don't update in the UI till time T when everything updates after bootstrapping...
Oh well, like I said, only a cursory investigation
With the update server hosted on my laptop...
Fun fact: Updates are really easy to mess up right now. If I forget to update the update server, everyone gets downgraded. Upload a bad file and everyone will crash. Fun stuff.
Upates Are Experimental™ and off by default.
