This commit makes is snappier to switch between chat by caching the Gspell.Checker
objects.
It triggers a linter error about a possible memory leak using lru_cache on methods but AFAIU it can be safely ignored since MessageInputTextView
and TextBufferManager
are singletons, see https://bugs.python.org/issue19859
Maybe 128 is too high a value for this cache, I'm not sure what's a sane size.
Procedure: switching contacts 20 times
Name | Call Count | Time (ms) | Own time (ms) |
---|---|---|---|
_init_spell_checker | 20 | 884 | 883 |
show_chat | 20 | 1842 | 224 |
switch_contact | 20 | 1088 | 185 |
Name | Call Count | Time (ms) | Own time (ms) |
---|---|---|---|
show_chat | 20 | 823 | 223 |
switch_contact | 20 | 3 | 0 |
_init_spell_checker | 20 | 100 | 0 |
Delivery receipt (activable in preferences->chat) are I how make sure that my recipients' devices actually received my messages.
I reported this issue upstream: https://github.com/pywinrt/pywinrt/issues/44
I think that this is caused by gcc treating /std:c++20 /permissive-
as paths and not flags:
Michel@DESKTOP-XXXXXXX MINGW64 ~
$ g++ test.cpp -o test /std:c++20
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find /std:c++20: No such file or directory
collect2.exe: error: ld returned 1 exit status
I was recently made aware that the text input field is disabled when no server connection is available. I have not had the slightest idea that this was on purpose. I had previously believed it was just some UI bug and had my own ritual (reminiscent of #11783) of minimizing and re-opening gajim to "make it work again".
I believe adding a brief notification of some kind, informing the user that no connection is available, would go a long way for intuitive UX.
I could imagine a status message directly in the disabled input field, or something similar to the loading indicator for transmitting files.
Participants joins and leaves are not shown by default, which is a good thing in a world where a lot of people are using mobile.
That said, in private groups, knowing if there is a new member is valuable information, and most chat apps will inform their users of such events.
This commit implements that feature.
Currently there is no visual indication that a message failed to send because of a connectivity loss. Steps to reproduce:
# iptables -I INPUT 1 -s <gajim ip> -p tcp --dport 5222 -j DROP
.Even though Gajim sends <r xmlns="urn:xmpp:sm:3" />
and never receives an answer and eventually notices the loss of the connectivity when a ping fails, there is never any indication that the message has not been submitted to the server! For instant messaging it is catastrophic if a user thinks a message has been sent, but it has, in fact, not been sent.
If stream management is supported by the server, we should be able to detect this situation and Gajim should indicate whether a message has been received by the server. This could be done by having a label "sending..." on the message until a SM ACK is received, additionally graying out the message or even not displaying the message until it has been received by the server like in MUCs (but the message just disappearing after pressing ENTER is very irritating to me). Additionally it would probably be a good idea to notify the user that some message could not be submitted to the server after a few minutes.
(Finally, the connectivity can be restored by deleting the firewall rule again with # iptables -D INPUT 1
.)
I do not have a setup to easily test flatpak builds. Does selection.get_uris()
return something or should I use something else when target_type == 0
?
Some possible relations to #11777 too, in the sense that this needs some thinking for a not-too-weird UI/UX. :)
I think there are valid use-cases for both behaviors so I suggest this would be toggleable in the settings, maybe in the advanced settings. Also, Conversations does that because it makes a lot of sense with the android address book integration, it's not entirely clear to me that this should be the default in gajim.
FWIW, in !999 I did work about separating participant nickname and resource part of the JID, so it is somehow related to this feature request, in the sense that some parts could be reused, maybe.
I use a minimalist notification manager (dunst) and while it can display images, it does not work if the "icon" is a Gdk.Pixbuf
, which I guess is GNOME-specific. Passing a Gio.FileIcon
does work though and that's what this commit does.
It requires writing the icon to disk, but it seems we can easily cache that using the hash of the cairo.Surface
object, so I don't think the performance impact is going to be an issue.
I pushed some improvements so that the proper nickname is used in the notifications and in the chat list rows last message preview.
It seems to work fine for me. It does not feel great to store the resource/nickname table in the GroupChatContact class, but I haven't found a better way yet.
This make the app main menu hideable with a keyboard shortcut, and a menu entry.
Menus are so old-school anyway!
@mimi89999 maybe you can make something out of this error (started from MSYS2 MINGW64):
$ SETUPTOOLS_USE_DISTUTILS=stdlib pip3 install winrt-Windows.UI.ViewManagement
Collecting winrt-Windows.UI.ViewManagement
Using cached winrt-Windows.UI.ViewManagement-2.0.0b2.tar.gz (20 kB)
Installing build dependencies ... done
Getting requirements to build wheel ... done
Installing backend dependencies ... done
Preparing metadata (pyproject.toml) ... done
Collecting winrt-runtime==2.0.0-beta.2 (from winrt-Windows.UI.ViewManagement)
Using cached winrt-runtime-2.0.0b2.tar.gz (12 kB)
Installing build dependencies ... done
Getting requirements to build wheel ... done
Installing backend dependencies ... done
Preparing metadata (pyproject.toml) ... done
Building wheels for collected packages: winrt-Windows.UI.ViewManagement, winrt-runtime
Building wheel for winrt-Windows.UI.ViewManagement (pyproject.toml) ... error
error: subprocess-exited-with-error
× Building wheel for winrt-Windows.UI.ViewManagement (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [30 lines of output]
WARNING setuptools_scm._integration.setuptools pyproject.toml does not contain a tool.setuptools_scm section
running bdist_wheel
running build
running build_py
package init file 'winrt/__init__.py' not found (or not a regular file)
package init file 'winrt/windows/__init__.py' not found (or not a regular file)
package init file 'winrt/windows/ui/__init__.py' not found (or not a regular file)
creating build
creating build/lib.mingw_x86_64-3.11
creating build/lib.mingw_x86_64-3.11/winrt
creating build/lib.mingw_x86_64-3.11/winrt/windows
creating build/lib.mingw_x86_64-3.11/winrt/windows/ui
creating build/lib.mingw_x86_64-3.11/winrt/windows/ui/viewmanagement
copying winrt/windows/ui/viewmanagement/__init__.py -> build/lib.mingw_x86_64-3.11/winrt/windows/ui/viewmanagement
running egg_info
writing winrt_Windows.UI.ViewManagement.egg-info/PKG-INFO
writing dependency_links to winrt_Windows.UI.ViewManagement.egg-info/dependency_links.txt
writing requirements to winrt_Windows.UI.ViewManagement.egg-info/requires.txt
writing top-level names to winrt_Windows.UI.ViewManagement.egg-info/top_level.txt
ERROR setuptools_scm._file_finders.git listing git files failed - pretending there aren't any
reading manifest file 'winrt_Windows.UI.ViewManagement.egg-info/SOURCES.txt'
writing manifest file 'winrt_Windows.UI.ViewManagement.egg-info/SOURCES.txt'
copying winrt/_winrt_windows_ui_viewmanagement.pyi -> build/lib.mingw_x86_64-3.11/winrt
running build_ext
building 'winrt._winrt_windows_ui_viewmanagement' extension
creating build/temp.mingw_x86_64-3.11
gcc -DNDEBUG -g -fwrapv -O3 -Wall -march=nocona -msahf -mtune=generic -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong -O3 -march=nocona -msahf -mtune=generic -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong -O3 -IC:/msys64/tmp/pip-build-env-p91heuwi/overlay/lib/python3.11/site-packages/winrt_sdk/cppwinrt -IC:/msys64/tmp/pip-build-env-p91heuwi/overlay/lib/python3.11/site-packages/winrt_sdk/pywinrt -IC:/msys64/mingw64/include/python3.11 -c py.Windows.UI.ViewManagement.cpp -o build/temp.mingw_x86_64-3.11/py.Windows.UI.ViewManagement.o /std:c++20 /permissive-
gcc.exe: fatal error: cannot specify '-o' with '-c', '-S' or '-E' with multiple files
compilation terminated.
error: command 'C:\\msys64\\mingw64\\bin/gcc.exe' failed with exit code 1
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for winrt-Windows.UI.ViewManagement
Building wheel for winrt-runtime (pyproject.toml) ... error
error: subprocess-exited-with-error
× Building wheel for winrt-runtime (pyproject.toml) did not run successfully.
│ exit code: 1
╰─> [26 lines of output]
WARNING setuptools_scm._integration.setuptools pyproject.toml does not contain a tool.setuptools_scm section
running bdist_wheel
running build
running build_py
package init file 'src/winrt/__init__.py' not found (or not a regular file)
creating build
creating build/lib.mingw_x86_64-3.11
creating build/lib.mingw_x86_64-3.11/winrt
creating build/lib.mingw_x86_64-3.11/winrt/system
copying src/winrt/system/__init__.py -> build/lib.mingw_x86_64-3.11/winrt/system
running egg_info
writing src/winrt_runtime.egg-info/PKG-INFO
writing dependency_links to src/winrt_runtime.egg-info/dependency_links.txt
writing top-level names to src/winrt_runtime.egg-info/top_level.txt
ERROR setuptools_scm._file_finders.git listing git files failed - pretending there aren't any
reading manifest file 'src/winrt_runtime.egg-info/SOURCES.txt'
writing manifest file 'src/winrt_runtime.egg-info/SOURCES.txt'
copying src/winrt/_winrt.pyi -> build/lib.mingw_x86_64-3.11/winrt
copying src/winrt/py.typed -> build/lib.mingw_x86_64-3.11/winrt
running build_ext
building 'winrt._winrt' extension
creating build/temp.mingw_x86_64-3.11
gcc -DNDEBUG -g -fwrapv -O3 -Wall -march=nocona -msahf -mtune=generic -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong -O3 -march=nocona -msahf -mtune=generic -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fstack-protector-strong -O3 -IC:/msys64/tmp/pip-build-env-rw297qt2/overlay/lib/python3.11/site-packages/winrt_sdk/cppwinrt -IC:/msys64/tmp/pip-build-env-rw297qt2/overlay/lib/python3.11/site-packages/winrt_sdk/pywinrt -IC:/msys64/mingw64/include/python3.11 -c _winrt.cpp -o build/temp.mingw_x86_64-3.11/_winrt.o /std:c++20 /permissive-
gcc.exe: fatal error: cannot specify '-o' with '-c', '-S' or '-E' with multiple files
compilation terminated.
error: command 'C:\\msys64\\mingw64\\bin/gcc.exe' failed with exit code 1
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for winrt-runtime
Failed to build winrt-Windows.UI.ViewManagement winrt-runtime
ERROR: Could not build wheels for winrt-Windows.UI.ViewManagement, winrt-runtime, which is required to install pyproject.toml-based projects
(Running version 1.8.4)
In group chats, the names of their members are displayed as defined in the group's member list. I propose that, if a member is registered in the account's roaster, that custom name is displayed instead. As a reference, this feature is enabled by default on Conversations.
This breaks the manifest. gajim
needs to be the last module.
I'd suggest to move these module between farstream and python3-pillow.
Dragging files from external applications works with flatpak, because for these target_type
is 80. But for other dragged objects target_type
is 0.
Nope, it isn't. I was only vaguely aware of dataclasses when I wrote this part and was not aware that they have sufficient features. I'll remove attrs usage.
XEP is now experimental https://xmpp.org/extensions/xep-0490.html
Wait, but I didn't actually change anything related to the target_type? DnD from external apps does not work for flatpak, but this MR does not change anything about it. I believe if we want to fix flatpak dnd it should be another MR.