Closed facundobatista closed 10 months ago
that fixed it for me @ilya-fedin can't believe this bug is from 2015!
Wow
The fix in 2.1.12 If no one says that the issue still valid in 7 days, the issue will be closed
Linux Mint 17.3 Rosa : Fail
Workaround (at first glance) with QT_IM_MODULE=xim
Linux Mint 17.3 Rosa : Fail
How did you install tdesktop?
Linux Mint 17.3 Rosa : Fail
How did you install tdesktop?
Humm... Updated from the program itself and it failed.
I tried now the desktop.telegram.org version and for now it is working.
Edit: After leaving the computer one night in "sleep" mode, this morning the Telegram Desktop has started to fail to write accented text. Restarting the application works again, but it fails on the next on-screen application change (Alt-Tab).
Restarting the application works again, but it fails on the next on-screen application change (Alt-Tab).
Well, looks like this bug has multiple causes And I fixed only one of them
But I need more info about your system to try to reproduce that (distro name, distro version, DE name, DE version, echo $QT_IM_MODULE
(without QT_IM_MODULE=xim
)
Description: Linux Mint 17.3 Rosa echo $QT_IM_MODULE: ibus
Description: Linux Mint 17.3 Rosa
DE?..
KDE 4:4.14.2-0ubuntu1~ubuntu14.04~ppa1
KDE
4:4.14.2-0ubuntu1~ubuntu14.04~ppa1
Could you tell how you configured the compose key in ibus and with which language you using this key? (i never used compose key feature before)
Possibly related: https://bugs.kde.org/show_bug.cgi?id=411729
As you can see, Telegram is stated as working, that's due to the backported fix for ibus on wayland from Qt dev branch: https://github.com/desktop-app/patches/blob/master/qtbase_5_12_8/0025-fix-ibus-on-wayland.patch
But that thing would work only with static binary, since it is impossible to control how Qt is built with other ways of distribution (snap, flatpak, packages in distro repositories)
That Qt bug was discussed there: https://github.com/telegramdesktop/tdesktop/issues/2013#issuecomment-614030382
And there are no need in XCOMPOSEFILE, since libxkbcommon is built with the right path now: https://github.com/telegramdesktop/tdesktop/blob/0b939e72c1305d96727c84d1b4a4978dfe43ea43/.github/workflows/linux.yml#L406-L407
Well, I found that Qt bug report: https://bugreports.qt.io/browse/QTBUG-44847 But I have a feel that this bug is reproducible only on old systems and the bug is in old system libraries actually rather than in Qt :thinking:
It would be very helpful if someone who experience the problem with losing of accent letters after focus change (note: when you opening a context menu, it's actually a separate window and focus changes) test the issue with other Qt applications on the same system (e.g. qbittorent, vlc, etc)
I usually leave the computer in "sleep" mode at night. Some days, when waking up the computer, I have noticed that some applications, like the Mozilla Thunderbird, lose the ability to write with accents. In that case, I switch to another application, for example Kate, or the same Telegram (started with the workaround), and when I return to edit the mail message it already works well. Other days, I don't notice any problems in any application.
I don't notice any problems in any application.
That might be just because you aren't using any other Qt applications or use them not so intensive. I saw a lot of issues where people say "I saw this problem only with telegram", but after testing with qbittorrent/vlc they confirm that they can reproduce the issue with these apps.
Just checked Ubuntu 14.04 repositories (I assume that's the base of Linux Mint 17.3) and found that almost all Qt apps are using Qt4 (VLC, qBittorrent, Kate). That explains why you can't reproduce even with Kate. But then I don't know which app suggest you to test. I suggest to update your OS.
I have just started observing the issue again.
I'm using my laptop's built-in keyboard now, while I usually use an external one (which I don't have at hand right now).
So either:
And also:
This whole thing is f@ing pathetic. The issue was first reported five f@ing years ago.
except for Snap, whatever that is
it is fixed in snap, by adding ibus-daemon binary
The issue was first reported five f@ing years ago.
No one can fix the issue if no one knows why it's happening :see_no_evil:
I've same issue...
Seems ralt works as tab or something like that, because it insert big space when I'm pressing it.
It types oC
instead of ℃
$ printf " oC" | hexdump -C
00000000 09 6f 43 |.oC|
calling QT_IM_MODULE=xim telegram-desktop
not fixing issue for me
OS: Manjaro 20.0.3 Lysia
Kernel: x86_64 Linux 4.19.133-1-MANJARO
Telegram Desktop Version 2.2
AUR telegram-desktop-bin
Seems ralt works as tab or something like that
What do you mean by "ralt"? Did you set ralt as a compose key or just trying to use it with out-of-the-box settings? AFAIK manjaro doesn't use ralt out-of-the-box for anything, at least with Qt apps.
ralt
is Compose Key
Here is line from my xorg config
Option "XkbOptions" "grp:caps_toggle,grp_led:caps,compose:ralt"
This strange behavior appears only in telegram…
This strange behavior appears only in telegram…
Are you sure that other Qt applications aren't affected? vlc, qbittorrent...
VLC works fine
qbittorrent also fine
echo $QT_IM_MODULE
echo $QT_IM_MODULE
Empty. Nothing there
I have no idea, sorry :man_shrugging:
Package from here https://aur.archlinux.org/packages/telegram-desktop-bin
Package from here
Started my VM with Manjaro XFCE, updated to the latest packages, executed setxkbmap -layout us,ru -option grp:caps_toggle,grp_led:caps,compose:ralt
, started tdesktop 2.2 downloaded from desktop.telegram.org, opened some chat, clicked on the input field, pushed ralt, typed o, c - got copyright symbol.
Don't know what changed, but now it works, thanks :)
I can now type accentuated letters without the env QT_IM_MODULE=xim
trick from one of the other tickets. But I have a local passcode and since recently (few weeks, the last month at most) I can't type accentuated letters there, with or without the previous trick. The only way to unlock Telegram now is to copy the password from another place and then paste it into the password field.
System: Fedora 32, GNOME 3.36.6, X11.
But I have a local passcode and since recently (few weeks, the last month at most) I can't type accentuated letters there, with or without the previous trick.
If your system uses ibus, it's by design.
I didn't read this whole thread (TL;DR), but I have the same problem here: sometimes the accented letters can't be entered. I learned that if I switch to another window, and enter a composite accented letter there, then switch to Telegram again, then I can enter accented characters in Telegram again (until the bug comes back sometime later).
@bart9h system info?
I have the same issue (Debian Linux 10.10 + XFCE 4.12 + Telegram Desktop 2.8.1) but I can add some information I haven't read in this thread.
Some time ago, when the issue happened, I closed Telegram Desktop (Exit from bar icon) and restarted and I could write composed characters again.
Now I have discovered that when the issue happens (after suspending, etc.?), if I insert any emoji then I can write composed characters again [àèòáéíóú, for example] so I do not need to restart the program.
I imagine that now this issue is related to just to keyboard state within the Telegram Desktop and not related to external components.
I hope this helps to find the bug.
Well, composite keys are completely handled on Qt side. The fact that this is reproducible only in some specific cases and only on Linux means that the bug is somewhere in Qt platform code and probably triggers due to tdesktop's massive widget usage. I fixed all the cases that were clearly due to the way tdesktop is built, for remaining you should contact Qt folks and ask how to debug these things, it's unlikely that the source of the bug will be ever found without their help since all tdesktop does is uses Qt's high level APIs.
for remaining you should contact Qt folks
Or rather you should.
Or rather you should.
I have nothing to tell to them since I can't reproduce
@bart9h system info?
Sorry for the long delay, I missed the notification.
I'm running Devuan beowulf, with a combination of MATE desktop and the i3 window manager. Uname -a gives:
Linux bambu 4.19.0-17-amd64 #1 SMP Debian 4.19.194-2 (2021-06-21) x86_64 GNU/Linux
I have upgraded Telegram recently, so I can't tell for certain that the bug is happening on my current version, or which was the last version that I saw the bug on. I'll report again when (if) it happens.
Hello there, a friend and I have been having this problem for several months if not a year, at least.
$ uname -a
Linux martin 5.4.0-77-generic #86-Ubuntu SMP Thu Jun 17 02:35:03 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
This description (by @edio) is exactly what happens to us:
Case 3
1. Open telegram with any chat having previous messages 2. Right click on any message from history and select _Reply_ 3. Type known compose sequence, f.ex. `<compose>'o` to get `ó` ✘ It doesn't work, `'o` is typed instead 4. Switch to any other window and then back to telegram 5. Type known compose sequence, f.ex. `<compose>'o` to get `ó` heavy_check_mark It works, `ó` is typed
I'm not totally sure that's the only way it happens but it's the most common. I use i3 and i don't even have to move between windows to make accents and compose work again: just moving window focus, even if it doesn't actually move because there's no window in that direction, solves it (temporarily, of course). It's really tiring, though.
Can I help you debug it, @ilya-fedin ? 😃 🙏🏽
Can I help you debug it, @ilya-fedin ? smiley 🙏🏽
I would be very glad if someone explain me how to setup this composite thing right since my language doesn't have diacritics.
Can I help you debug it, @ilya-fedin ? smiley 🙏🏽
I would be very glad if someone explain me how to setup this composite thing right since my language doesn't have diacritics.
I have this set up: setxkbmap -layout us,latam -option "grp:switch,compose:rctrl"
What this does is:
I'll reduce it to: setxkbmap -option "compose:rctrl"
so it's just the latter functionality. Run it, it's not permanent. Now you can do something like: [Hold RCtrl] + o + c => ©
setxkbmap -option "compose:rctrl"
Ok, I've chosen that variant, but I'm still able to type ©
after step 2, checked on NixOS unstable with MATE and Telegram 2.8.1 official binary from https://desktop.telegram.org.
Yeah, from this thread it seems it doesn't happen to everyone. Is there any info i can gather for you to find the root cause? Maybe it's a Qt thing as you say but find the reason for it happening to some people or variants of the application.
I also just remembered (by it happening) that it also makes the :emoji:
syntax not work! In that the emoji mini-panel doesn't show up. Any ideas from that?
Yeah, from this thread it seems it doesn't happen to everyone. Is there any info i can gather for you to find the root cause?
Well, I don't understand why people post results of uname -a
, it's absolutely useless, Telegram is not running on bare kernel, lol. The minimum required info pack is: Telegram version, installation source (static binary / flatpak / snap / distro package / etc), distro name and version; DE, WM names and versions; X11 or Wayland
I also just remembered (by it happening) that it also makes the
:emoji:
syntax not work!
That's absolutely weird, like your WM is grabbing the input and prevents Telegram from functioning properly
The minimum required info pack is
in this case it's also important to know whether any environments variables that change Qt behavior are set: env | grep QT
When I normally write in all the rest of the programs, if I hit ' and e, I see é.
However, in Telegram app it appears the e without the tilde.
Same happens for all the composite letters. Note that this doesn't seem to be an "unicode" problem... if I hit "ñ" (I have a separate key in the keyboard for it), it appears ok.
Thanks!