Some progress to handle notches / cutouts of #linuxmobile phones better in #phosh : I have a small lib that gets panel cutout / notch information as #svg paths and can calculate a bounding box . #phoc can use it to render cutouts for debugging and #phosh can use it for layout (so far only to shift the panel down). (see follow up posts for more pictures).
1️⃣ /4️⃣
phosh using that information to push the top panel down because there's a (simulated) notch:
3️⃣ /4️⃣
MRs are linked here: https://gitlab.gnome.org/guidog/gmobile/-/merge_requests/8
Next steps (after cleaning up a bit and getting it merged) is allowing phosh to make better use of that information (e.g. to shift ui elements to the side instead of down) and providing the information to wayland clients so e.g. video players can make use of it in fullscreen mode.
4️⃣ /4️⃣
And this is how it looks on a device with notch. Also enabled PHOC_DEBUG=cutouts so phoc renders the bounding box of these.
If your device has a notch or cutout and you want #phosh to handle it automatically check https://phosh.mobi/posts/notch-support/ on how to describe the display properties.
@agx awesome! will use my dumb patch until this happens, thanks!
@agx awesome! will use my dumb patch until this happens, thanks!
@agx awesome! will use my dumb patch until this happens, thanks!
@agx awesome! will use my dumb patch until this happens, thanks!
@agx instead of pushing down, shouldn't it efficiently utilise the space, like not display any indicators in the notch area, but still effectively use the panel
@hemish read thw whole thing: https://social.librem.one/@agx/109682949493890985
@joao optional features (battery percentage, date, ...) are ignored for the calculation - there's not enough space (there isn't even enough space without a notch). There's also the language indicatore for example and the two kill switches.
Landscape: we don't clamp the space on purpose yet. That's a job for the compositor and we want some wayland protocol for that so it's a different topic.
@craftyguy @joao Interesting. That's basically what happens with this MR atm.
So no one will be able to say: look at how google does it ;)
heh, I have looked at Android source code a few times to see how they solved a problem I have been having. In general, the answer is they implimented the first thing I thought of but figured that wasnt a great idea.
*shrug*
@agx On my OP6 I currently shift the clock to the right. I'd much prefer a smaller panel with more efficient icons e.g. signal bar with 4G could be combined and location could be on the left to allow wider date or battery percentage which could also be part of the icon. 250% scale is perfect for this phone but messes up the keyboard and lockscreen.
@joshfowler I assume you apply some custom CSS then? Both #phosh's lockscreen and #phosh-osk-stub look right here at scale 2.5 (got myself temporary access to a Oneplus 6T to check that)
@agx Not as far as I know, using stock pmOS but adjusted things with the Tweaks app provided with the image, that might change the css?
@joshfowler hmm...seems my reply somehow vanished: pmOS tweaks sets CSS which likely causes your problem. Basically if you add additional CSS you got to keep the pieces.
There's some other caveats with fractinal scaling atm but phosh itself should render correctly at scale 2.5 (it does here on current main).
@agx I removed the customisations in ~/.config/gtk-3.0/gtk.css, rebooted, changed the scaling and it still does the same thing to the keyboard.
@joshfowler But lockscreen is fixed?
Your screenshot show's squeekboard so I assume you're hitting https://gitlab.gnome.org/World/Phosh/squeekboard/-/issues/338 . I'm using phosh-osk-stub instead as I rely on some of it's features and that ones scales according to the screenshot I posted.
@agx My apologies "messes up the lockscreen" isn't very descriptive so I will attempt to explain better. The scaling on the lockscreen is correct, same as in Phosh, but it groups the numbers together on the numpad input because it is scaled away from the edges of the phone. At 300% scaling I regularly miss a number when unlocking, with 250% it's every time.
Aha, so there is a different keyboard! Do you know of a guide to switch between them?
@joshfowler Ah regarding lock screen, you want to send patches to allow for more spacing between the keys and maybe even scale up a bit.
Regarding switching keyboards:
That depends on your distro. In Debian it's just `update-alternatives`. On pmOS building from source and installing to `/usr/local/` should do the trick. That's at least how I run it there for testing. Note that phosh-osk-stub is experimental so make sure you have ssh access.
@joshfowler Generally speaking: while we try to take higher resolution devices into account when developing phosh it's not continuously tested (e.g. phosh's CI tests 360x720) so it needs people to step up to send patches for those devices and to get rid of the papercuts (and we can then make sure we don't regress via CI).
@agx Yeah, I understand that you need to limit scope to deliver a better experience faster to L5.
Just an aside, my friend pointed out that Phosh is technically illegal (at least in the UK) because you can't call emergency services from the lockscreen as far as we could figure out. I haven't personally verified if this is a legal requirement but it does make sense.
@joshfowler I'm not familiar with the regulations in UK but there's https://gitlab.gnome.org/World/Phosh/phosh/-/merge_requests/904 - basically for the bits in calls to land.
@agx I'm not sure where I would even begin with patching Phosh myself, I've only ever worked on smaller projects with other devs to guide me. (I work as DevOps but do some Dev work when needed)
Thank you, I'll give it a go. I do have SSH setup so hopefully I won't lose access!
@joshfowler I think the best thing is to have phosh running nested on your desktop and then use gtk-inspector to modify e.g. CSS at runtime. That's easier (and faster) than pocking at the phone directly.
@agx Thank you for taking the time to help me out with this BTW.
How did you get OSK to compile? It gives a dependency issue for gnome-desktop-3.0 when I follow the meson build instructions and I can't see anything other than 43 in the repos.
@joshfowler gnome-desktop 43 provides a libgnome-desktop-3 and libgnome-desktop-4. See e.g. how Debian handles it: https://salsa.debian.org/gnome-team/gnome-desktop/-/blob/debian/master/debian/control#L88
@agx Thanks for the tip. I've installed some dependencies now but am stuck on libsystemd, I can't find any systemd packes in the repo as pmOS doesn't use it. Any ideas?
@joshfowler This is the list of dependencies I use to build on pmOS/alpine: https://gitlab.gnome.org/guidog/phosh-osk-stub/-/blob/main/.gitlab-ci.yml#L29 , https://gitlab.gnome.org/guidog/phosh-osk-stub/-/jobs/2546824 has a build log that hopefully has all the details.
@agx Excellent, that got everything compiled but I get an error and a critical when I try to replace sqeekboard, pic attached.
@joshfowler Replacing a runing squeekboard doesn't work yet (https://gitlab.gnome.org/World/Phosh/squeekboard/-/issues/361) - replacing a running phosh-osk-stub with another phosh-osk-stub does though. To replace (temporarily) replace squeekboard you need to make sure sm.puri.OSK0.desktop invokes phosh-osk-stub, other by editing it, adding one to /usr/local/ or ~/.local/share/applications or (on Debian) by using `update-alternatives`: https://gitlab.gnome.org/guidog/phosh-osk-stub/-/blob/main/doc/phosh-osk-stub.rst
phoc rendering cutouts in nexted mode to simulate cutouts and rounded edges:
2️⃣ /4️⃣