When the user just clicks somewhere, and thus rejects the selection due
to the previous commit, show the initial 'nothing selected' helper
tooltip again.
The menu is now collapsed in the background half a second after
the user clicked on the screenshot button. This is to let the WM have
some time to open the fullscreen window, which itself is now shown
immediately.
If this doesn't help we'll need to split the screen capture display
into tiles and display those instead, allowing Qt to only draw
a few of them instead of everything.
After clicking the "Screenshot" button in the file flyout, the flyout
now collapses and then triggers the screenshot functionality. This adds
a delay of ca. 1/3 seconds between the click and the action.
When hovering over the "attach file" button in the chat form, an
additional button for the screenshot functionality will 'fly out'
to the left, showing a computer monitor as icon. Leaving the attach
file or the take screenshot button will collapse the fly out again.
Bug: Moving the mouse over the fly out and then back again to the
attach button collapses the fly out. Will sort this out later.
Also used the opportunity to rename headers from hpp -> h extension
I added earlier.
I've moved the key bindings in the main widget instead of the chat form given it
doesn't seem to be the chat form's responsibility to handle switching between
conversations it shouldn't know about in the first place. I've also included new
shortcuts to provide a more familiar feel to most people.
All in all this provides Ctrl+Tab and Ctrl+Shift+Tab for cycling as well as
Ctrl+PgUp and Ctrl+PgDown for cycling. This mimics common application behaviour.
In Qt chat boxes filter out events related to text editing, including tabs.
Unfortunately tabs with modifiers like those used to cycle through contacts are
being filtered despite not being used for anything.
This fixes the keybind for cycling forward through contacts (Ctrl+Tab).
I've implemented this by having the contacts list container return all contact
widgets in the order they appear each time it's time to cycle. It's perhaps
inefficient but given cycling isn't done often I don't see a need to optimize.
This code does make the assumption that the friends list isn't empty, which I'd
guess would be the case if there's an active conversation.
New friends must be added to the friend list before loading history, otherwise the history code won't find the friend in the friendlist, and the history will have blank names for the friend
askProfiles is a really dangerous function. Awful things happen when the user closes that message box. We now prevent it from being closed in more places
There are small instants on startup and while profile switching during which no profile is loaded but the GUI could still receive events, e.g. between two modal windows. Disable the GUI to prevent that.
Don't just let the user close the profile select box and continue with an empty value. We would create a new profile and save it back on top of the previous encrypted profile
- Add AvatarBroadcaster, in charge of making sure our friends have our avatar without spamming file transfers
- Fix file sending code not closing the file after transfer, which prevented file previews, and make the QFile a shared_ptr to fix the obvious memory leak
Some small additions to Core to support AvatarBroadcaster
1) action received gets modified on restart
2) sender's name is written twice if action is sent using offline messaging
3) /me is written when action is sent in groupchat having one peer
4) /me is not saved in last message variable in friendd chat
This fixes the potential edge case where a frozen then unfrozen qTox instance could have its locks delete by a new qTox instance.
We now check that we still own our locks, restoring them if we can, before saving
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.
If we're running on a given profile, reload the qtox.ini, and it has a diffeent value for the current profile, we don't overwrite our current value with whatever qtox.ini says anymore
It would cause current profile confusions when multiple qTox instances where using different instances but sharing the qtox.ini
It would only trigger when multiple instances where running in parallel,
with one having enough privilege to block the other from accessing the shared memory (e.g. root)
We returned a shallow copy of the delete[]'d salt buffer
As a result the history consistently failed to decrypt and was removed as corrupted. This is now fixed.
Profile encryption should be fairly stable. History encryption was *NOT* tested yet and as such may not work, cause profile corruption, or invoke nasal daemons.
what happened was- When message exceeded TOX_MESSAGE_LENGTH, the whole message was inserted in sender's chatlog X times.
if length of message is N,
X = (N/TOX_MESSAGE_LENGTH) + 1
There is no bug in recieving end. Receving end gets X messages (splitted).
In the sample case provided, the message had whitespaces in the end, so the reciever thought the message is empty.
* 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
disable light tray icon if system tray icon disabled (didn't work for
some reason)
disable emoticons combobox if emoticons disabled globally
prevent comoboxes and spinboxes stealing mouse scroll event while
scrolling in generalform, prevents from accidential language/timestamp
format/theme/skin changes while scrolling in the widget
disable passing CSS to qfiledialog in general form, qfiledialog will use
default system theme instead of not fully written from qwidget
fixed tab order in generalsettings
groupchats placed at the top of the friends list, or below the online
contacts.
-A checkbox was added to generalsettings.ui
-FriendListWidget's constructor was changed so that the friends list can
be initialized with the appropriate layout arrangement
Also comments out the debug output in
FriendListWidget::getFriendLayout() because hitting the default return
statement is no longer anomalous behavior.
friends list. Widgets are sorted upon being added to the friends list in
the first place, and re-sorted if a user changes their name, or if a
user is given an alias.
-Friend now inherits from QObject
-Friend objects now emit a signal when their display name is changed
-FriendListWidget::moveWidget() is now a slot
This patch adds ability to override qTox window and tray icons with ones from user's desktop theme. Some people prefer keeping tray icons consistent to achieve best looks.
Following theme icons used:
* qtox: general window icon which is also used in taskbar
* qtox-online, qtox-offline, qtox-busy, qtox-away, qtox-invisible, qtox-event: tray icons
If theme icon is not available then default built-in icon will be used.
Make the page directly accessible from the main screen by clicking the avatar or the username. Changing the avatar or the username are now possible only from the profile page
This one is deprecated, but should work much better than any other system tray icon backend we currently have, both in term of supported features and reliability. It justs needs some testing to see where we can enable it now.
It was really just spam, let's wait thrice as long to stay reasonnable. I remember a long time ago some people couldn't connect because we were spamming too much bootstrap nodes
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.
