Telegram Desktop input field is under onscreen keyboard on tablet in landscape orientation, so it's not visible to user

[RussianNeuroMancer]

Steps to reproduce

1. Install Linux with Gnome Shell and Onboard on x86 tablet; deal with touchscreen driver, if there is any issue,
2. Configure Gnome Shell and Onboard by following recommendations below,
3. Set screen to landscape orientation if it's not default, start Telegram, select chat, summon Onboard.

Expected behaviour

Onboard appear on the screen, input field is visible

Actual behaviour

Onboard interfere with Telegram's windowMinHeight, therefore input field turn out to be under Onboard, so user can't see text that he enter. Qt seems like take font size from "Gnome Tweak Tool" as recommendation for DPI calculation, so issue is reproducible even if there is enough space for Telegram window (480 or more pixels is available.)

Configuration

Environment: Ubuntu Gnome 16.04, 16.10 and 17.04 was tested Lenovo Thinkpad Helix, Dell 5855, Dell 7140, Dell 9250, DEXP Ursus 7W, DEXP Ursus 10XW tablets was tested Screen resolution from 1024x600 to 1920x1080 was tested Onscreen keyboard Onboard has been used instead of Caribou (Gnome Shell integrated onscreen keyboard) because there is no Russian keyboard layout in Caribou Telegram version is 1.0.29, default theme.

Gnome Tweak Tool settings: Font size was set to 1.15-1.5 depends on the screen size and screen resolution. This is important to adjust this option to some sane value to reproduce this issue. For example for 1920x1080 set Font size to 1.30.

Onboard settings: Onboard was configured to be attached the bottom edge of the screen Onboard size was set to around 40% of the screen in landscape orientation

[Aokromes]

#1297 ?

[RussianNeuroMancer]

Different issue, I think. In my case window get resized, but not below windowMinHeight.

[ghost]

Hey there!

We're automatically closing this issue since there was no activity in this issue since 399 days ago. We therefore assume that the user has lost interest or resolved the problem on their own. Closed issues that remain inactive for a long period may get automatically locked.

Don't worry though; if this is in error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

_{(Please note that this is an automated comment.)}

[RussianNeuroMancer]

Still reproducible, so please keep it open.

[ell1e]

Sorry for making the duplicate issue #8058, but to sum it up: this is also an issue with the PinePhone, and possibly the upcoming Librem 5, Vollafone, and other mobile phones that might run Linux in the future (with systems like Ubuntu Touch, Phosh, or Plasma Mobile)

[stale[bot]]

Hey there!

This issue will be automatically closed in 7 days if there would be no activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[ell1e]

This is definitely still a problem, and not resolved.

[stale[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[ell1e]

Still broken.

[proycon]

I see this issue has popped up in several tickets already (#8058, #16368), most of them got closed without an actual solution and with the note that tdesktop wasn't designed for phones/tablets or small screens. I of course respect that the focus is on desktops, but I want to emphasize that in Sxmo (a UI for linux phones like the pinephone), tdesktop really works almost perfectly under Xorg (with dwm as window manager), despite the small screen. I say this to:

1. Request that tdesktop is not completely discarded as a viable solution for linux phones. The experience on Sxmo shows that tdesktop works quite well in general, also in combination with the virtual keyboard and the limited screen estate.
2. Inform that this issue seems wayland specific (and possibly specific to wlr-layer-shell). We're currently developing a wayland version of Sxmo, using sway as compositor, and we can replicate the exact same issue there; the text input field is missing there; and this can also be replicated on a desktop system with a virtual keyboard. The available screen estate to telegram in Xorg vs sway is almost identical and only the latter has the problem.
3. As this issue indicates, it's not limited to mobile devices, I can also replicate it on laptop/desktop with sway with a slightly oversized virtual keyboard. I used our fork of wvkbd, where the height of the keyboard is configurable through a parameter, which it useful for good testing this bug.

I attach of screenshot of tdesktop working well on sxmo (X11, dwm) on a pinephone (may also in part be due to the small size patch alpine linux ships):

[ilya-fedin]

It's unlikely tdesktop will be ever adapted to linux phones by efforts of their team. If you want better support for linux phones (or tablets, transformers, etc, yeah), the only way is to create PRs. You can ask @john-preston which changes in the widgets are needed to decrease minimal window height if you want to work on that.

[stale[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[ell1e]

:weary:

[gurucubano]

I have a similar issue with one of my Linux mobile phone Purism L5. The one which works fine runs telegram-desktop 3.7.3, the other runs 4.1.1 and there the OSK overlaps the input widget when the OSK is brought up. The problem seems to be that in 4.1.1 the list of older messages in the chat is not shifted upwards enough. See attached screen (two of the correct working 3.7.7m the last of the broken one):

broken:

[gurucubano]

Hello @john-preston could you please point me to the location where to change this problem. Thanks

[ilya-fedin]

@john-preston sadly doesn't seem to be interested in resolving this problem. Another way to fix the problem is probably adjusting input fields to QInputMethod::keyboardRectangle (or maybe QInputMethod::inputClipRectangle?). QInputMethod instance can be gotten with QGuiApplication::inputMethod. This should be an easier way to fix that as this doesn't require changing window limits and so working together with Telegram designers, but sadly personally I can't work on this as I don't have any device to reproduce this. But I think I'll be able to help anyone interested to implement this with QInputMethod.

[gurucubano]

El día Dienstag, Dezember 06, 2022 a las 11:52:05 -0800, ilya-fedin escribió:

@john-preston sadly doesn't seem interested in resolving this problem. Another way to fix the problem is probably adjusting input fields to QInputMethod::keyboardRectangle. QInputMethod instance can be gotten with QGuiApplication::inputMethod. This should be an easier way to fix this as this doesn't require changing window limits and so working together with Telegram designers, but sadly personally I can't work on this as I don't have any device to reproduce this. But I think I'll be able to help anyone interested to implement this with QInputMethod.

If some could produce a flatpak pkg for the Purism L5 (Debian), I could give it a try. Actually, I can't compile from sources.

-- Matthias Apitz, ✉ @.***, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub

[ilya-fedin]

The thing is someone having appropriate device and/or interest has to compile from sources and do the development

[chloe-everhart]

Still broken: I use Pop! OS with 200% scaling and the Night Color always turned up most of the way. Telegram is installed as Flatpak through Pop! Shop.

My accessibility options broke the Telegram UI. Using 200% scaling from the GNOME settings menu, the area where I type the messages is off the screen, and I can't shrink the window so it will fit on the screen. I can't get to all the menu options.

When I click the thoughtfully placed icon to switch to 100%, everything gets too small to read easily, but the buttons are back on the page. When I turn off "use system defaults", and use the slider to increase the scale to where reading it is comfortable, the type box and menu options are off the page and inaccessible again.

Could you please help me find a solution, so that Telegram won't get bigger than my monitor when I scale to 250% or 300%?"

[ilya-fedin]

@chloe-everhart there's sadly no solution as tdesktop is just not designed for such small window sizes

[WhyNotHugo]

FWIW, this is also an issue on desktop when I have a another window below Telegram.

I've simply learnt to always give Telegram more space if I want to type on it, but there's nothing phone-specific about the issue (though there's no workaround on a phone).

I'm not sure about X11, but on Wayland this is by design, from xdg_toplevel::set_min_size:

The client should not rely on the compositor to obey the minimum size. The compositor may decide to ignore the values set by the client and request a smaller size.

I understand that you're not talking to Wayland directly, and using Qt as an intermediate, and the problem is that Qt's abstraction promises something different. But FYI, that promise is broken because it is not possible to uphold.

I know on floating desktops a window can be larger than the screen and you can just drag then up and down to see the "off-screen" parts, but there's no such concept on tiling desktops: windows are always rendered in their entirety, never partially and they never overlap. So if there's not enough space, they will be made smaller.

[ilya-fedin]

The problem here is not Qt but the lack of development will in having a re-design that fits smaller screens. Even if tdesktop was talking to Wayland directly, this particular issue would exist as we just can't handle smaller sizes. Qt just makes the life easier by providing the sane guarantees and enforcing the size for us. If it wouldn't, we would patch it to do that (that's something we will likely do for X if this won't be fixed upstream to avoid crashes).

[WhyNotHugo]

I think we're not seeing eye to eye on the "minimum size" issue.

I understand that as part of Telegram's design, you want Telegram's window to always be larger than a minimum size. This expectation can be met on a few specific scenarios (basically, on a stacking compositor/desktop), but it's just unrealistic anywhere else.

On my particular scenario (a tiling compositor), if I want to have a window below Telegram, then the vertical space left for Telegram is less than its minimum height. In such a scenario, how would you enforce a minimum height? There's literally no more pixels left on screen. This isn't about a "small screen" either; my screen is 34" (3440x1400px) but I might want to have something below telegram. See example screenshot:

Note that in this specific scenario, it's perfectly feasible to render the chat-history widget smaller; it would still be able to fit plenty of content.

[ilya-fedin]

Note that in this specific scenario, it's perfectly feasible to render the chat-history widget smaller; it would still be able to fit plenty of content.

No doubt it's possible, the problem is there's no development will. Just lowering the limits will lead to visual artifacts what was already proven in the past. The reality is tdesktop needs work from someone interested to fix the widgets to handle such sizes, likely with redesigning various place (there's not only the chat history, but also settings view and etc, etc, etc all of which has to be fixed as well before the limit could be lowered).

but I might want to have something below telegram

tdesktop is just not optimized for such use-case, sorry, but you can't use it like that.

how would you enforce a minimum height?

As it currently does on Wayland: by rendering outside of the window. If you want correct operation, you have to enlarge the window. It's better than crashing, do you agree? And we can't do anything better without massive changes.

but it's just unrealistic anywhere else.

Such use-cases are just unsupported, sorry. You're losing your warranty when bypassing application's requirements.

[ilya-fedin]

Also, as we won't crash anymore, it will also be possible to handle that with a "Please increase your window size" plumb like was proposed in #25539. The question is whether this is something @john-preston would like to have though.

[WhyNotHugo]

The reality is tdesktop needs work from someone interested to fix the widgets to handle such sizes, likely with redesigning various place (there's not only the chat history, but also settings view and etc, etc, etc all of which has to be fixed as well before the limit could be lowered).

C++ is far outside my area of expertise, so I doubt I'll ever be able to contribute that much. Maybe someday someone coming across this issue will have the right skill-sets to address this. :crossed_fingers:

You're losing your warranty when bypassing application's requirements.

What exactly re the requirements? "The window must be at least X size"? :joy:

it will also be possible to handle that with a "Please increase your window size" plumb like was proposed in https://github.com/telegramdesktop/tdesktop/issues/25539. The question is whether this is something @john-preston would like to have though.

I don't really think that this is worth the effort. I'd rather just leave the issue open until someone has the time+skill to address is properly. At least now it works for reading a conversation.

[ilya-fedin]

The window must be at least X size

Yes.

[github-actions[bot]]

Hey there!

This issue was inactive for a long time and will be automatically closed in 30 days if there isn't any further activity. We therefore assume that the user has lost interest or resolved the problem on their own.

Don't worry though; if this is an error, let us know with a comment and we'll be happy to reopen the issue.

Thanks!

[ell1e]

Can't you mark this as confirmed or something? It won't just "disappear" just because the misguided GitHub action is designed to assume so.

[gurucubano]

El día miércoles, octubre 18, 2023 a las 01:19:39 -0700, Ellie escribió:

Can't you mark this as confirmed or something? It won't just "disappear" just because the misguided GitHub action is designed to assume so.

+1

-- Matthias Apitz, ✉ @.***, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub