So I was thinking about what projects I could start on to help the L5, and I was thinking about how the vast majority of Linux programs don’t work on the L5 merely because they don’t conform to the screen resolution limitation.
This got me thinking about how VNC clients on Android, for example, often times can’t show you the whole screen and the screen itself is scrollable with touch to get around this.
As the vertical height resolution of the L5 isn’t the issue but rather the horizontal resolution, why couldn’t a similar functionality be added to Phosh? Render the whole window as it would on the desktop, but make it horizontally scrollable.
You could use a two finger swipe / scroll to adjust what part of the program window you have showing.
This is obviously a band-aid solution to make it so more apps are useable right out of the box. Outside of the technical implementation of this idea, what does the community here think about the idea?
One problem I’ve noticed with many apps I’ve tested is that, besides not fitting the screen, they are also unscrollable vertically or horizontally. Not all, but many. FYI.
Right this would get around this by essentially panning the actual screen, and not trying to scroll within the app.
Easiest way to think of it is viewing a 4k screen by looking at 1 /4 of the screen at a time, or being able to move freely around the 4k image with your ‘1k’ viewport.
I’ve done that sort of thing before, long time ago (long enough that I don’t really remember the motivation behind it…). It works passably well. It works much better with a physical keyboard, as you can lock and unlock screen panning.
Given that the L5 uses a custom Wayland compositor, it’s both easier and harder than under X11. With X11, xrandr could give you a virtual screen larger than your physical screen, dynamically at runtime, and then you “just” had to configure something to scroll the physical screen’s location around. Doing it on the L5 would require the compositor support it (probably not too difficult, given that they’re using wlroots). On the bright side, it would be possible to add a lock button to it, so you could do a swipe to relocate the view, hit the lock button, then swipe and have it passed to the active Wayland client.
The idea is obviously good but, personally, I think it would be a mistake to insert this feature and I explain, in my opinion, the reasons.
This functionality would lead, I believe, that any user who wants to switch from android or apple systems to linux would find many applications that would work “in a strange way” and not giving the possibility of an easy transition. Furthermore, this would mean that we would no longer try to make every application adaptive beyond, perhaps, that it would slow down the development of phosh in this sense.
Perhaps, and I repeat perhaps because I do not have the preparation to think about what would be better in terms of programming and development also in the future, you might think like in this article https://puri.sm/posts/easy-librem-5-app-development -scale-the-screen / to an automatism in the automatic scalability of applications, that is by making sure that both Phosh and, detecting that an application has a wider interface than the screen, automatically adapt it.
It’s just my small contribution.
Regards
Yep, was talking a little about this on the Librem 5 Matrix channel, and both Dos and Guenther mentioned that there is functionality already baked in that kind of make this a redundancy.
Should it be implemented a locking mechanism to handle scrolling would probably be the most elegant technical implementation, but would be clunky for the user. Things to think about, although I think I’m going to work on something else.
Perhaps, but I think this would work inversely. This gets apps on the L5 right now, but users who would be using an app like this will not find it super nice to work with. Instead it would be rather clunky. Users then would push for the app to be made adaptive.
Scaling is a good solution of sorts, but where touch input is necessary scaled items like that may be unusable or frustratingly usable.
I rather disagree there… For most applications, there will already be an on screen keyboard, so a button (on the keyboard) to lock the compositor view isn’t going to cost significant space. Even if the button isn’t docked to the keyboard, the fact that you can just scroll the display means the lock button won’t keep you from seeing what you need to see. Without it, I suspect there would be serious pain points trying to use gesture-aware applications.
IF the keyboard is up then this is a good solution. Still even if I don’t like it, the keyboard might provide an excellent place to stuff a key that DOESN’T mess with gestures, keeping this functionality from breaking that functionality.
Imagine you don’t need the keyboard up and are just using the UI in the program, needing to have the keyboard come up everytime you want to pan the screen would be tedious. (especially if UI elements have you going back and forth across the app.) I was thinking a touch gesture itself could be used to enable and disable panning.
You could use one to disable panning, but anything that could be used to enable panning might be needed in the application itself. A small button on the edge would likely be less obtrusive (if it’s in the way, just scroll the view slightly). But once the basic functionality is working, letting the user configure how to enable or disable panning would be pretty simple. Heck, with the vibration sensors inside it could even be bound to a sharp shake of the whole device, which is quite unlikely to interfere with any application not already adapted to the phone.
Another obvious place for a button to switch between modes would be the quick settings you see when unfolding the top bar. I also thought that the user can activate the panning mode, moves the viewport of the application and after that the panning mode automatically gets disabled, so that the user can interact with the app without beeing forced to deactivate panning manually. This could make the use easier.
Also it might be useful to scale manually in panning mode by two finger stretching / compressing gesture like we zoom pictures on touch devices.
Edit: Isn’t the keyboard always availible via the button at the corner? Way better than android, where I hardly can use the keyboard outside of input fields.