Unfortunately, can not pass local variable on ChatLine::Ptr through
several method calls so ChatMessage inserted after its creating in the
same scope. Updated docs
Brief list of changes:
- "resolveToxId" method's name replaced with "resolveToxPk";
- updated comments for "resolveToxPk" and "needsToHideName";
- changed "resolveToxPk" return value for fail case;
- fixed typo.
Brief list of changes:
- contentdialog.* and friendlistwidget.cpp reverted to their previous states;
- added macros for setting stylesheets for form components;
- added 'static' qualificator for 'fontToCss' function;
- added 'needsToHideName' method and several places in code replaced with this
method's calls;
- some changes which are related to previous listed;
- 'resolveToxId' returned to GenericChatForm class.
Return value of "addMessage" was not used at all, so now this method
(and "addSelfMessage" too) does not have return value - just inserts
message into ChatLog. Also messages are creating with "createMessage"
and "createSelfMessage"
Brief list of changes:
- removed unnecessary headers from core.h and core.cpp;
- added missing brackets and aligned long lists of parameters;
- some other small changes.
Made as single commit because this change requires an explanation. As i
understand, `getTypingNotification` always return the same value because
`setTypingNotification` is not connected for any signal and the only
time it's called - from `PrivacyForm`'s method which is never called and
also is not connected to signals. I guess that removing `getTypingNotification`
from `onTextEditChanged` will not affect anything
Previously GroupInviteForm included several collections of components
which were supposed to use as a single object. Now they are replaced
with a class and all functionality related to this collections moved
there too. Also fix#3621
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
