@kazmroz is it here that you find the super key mentioned?
and is it this that you want to use the super key for?
Zoom in : Alt+Super+=
Zoom out: Alt+Super±
These are found in Settings, Keyboard Shortcuts.
The font of a note Iam working on gets smaller for some unknown reason (I might have pressed or touched a key combination to get the unwanted result).
If font size can be zoomed out by mistake of my hands touching a certain, unknown key combo, that key combo already exists for the system to use it and produce the related result, without me needing to write code that would do that. So the purism developers are not aware of that code already existing, when they tell me I might write the code for font zooming. Or does the phone system do things that one would want but only by mistake?
… in many standard Linux environments. So the complaint here might be that they should have been removed from the “help” in the specific context of the Librem 5 in the specific situation (as yet unknown) that they don’t work. In truth though I doubt that software can tell whether other software will or will not be capable of producing the “Super” key.
The point of those settings is that they are settings i.e. if that key combination doesn’t work in your environment (e.g. no usable “Super” key) then you can change it to a different combination. You can instead disable those Zoom in/out key combinations if you are accidentally using them.
Zoom in/out can also be achieved in e.g. Firefox with Ctrl/+ and Ctrl/- but each application gets to choose key combinations so that may not apply to whichever specific application you are using.
Did anyone really tell you that? Could you quote it?
Look, I understand that you’re not happy with the problem you encountered, but I don’t think unfounded accusations are the optimal way to solve it.
So now, could you share what program you are using to make a note? It definitely should not change the font size by accident.
As for keyboard shortcuts shown in keyboard settings, I think that makes sense. They apply when a keyboard is attached.
1 Like
I quote : 
dczPhone developer
There are two ways to get there:
- The phone gains a hardware keyboard (unlikely)
- Someone writes a keyboard emulator (maybe you?).
A keyboard emulator is not a goal of the Librem 5 team at the moment.
------->Someone writes a keyboard emulator (maybe you?).<---------
You wrote the line between the arrows, 7 days ago. Scroll up in these comments to see your comment containing that line.
Librem 5 has no keyboard, but if you connect a keyboard to your phone, all these shortcuts will work just fine.
1 Like
I don’t see how a keyboard emulator is a tool for font zooming, but I appreciate that you went through the trouble to provide a quote.
In either case, if you want to get this sorted, the strategy that might bring some success is to describe the problem, for example by providing the information I asked for.
2 Likes
I think what @kazmroz is trying to communicate is that since there isn’t currently a keyboard emulator we can’t use global shortcuts like alt+super+ +/-
And since the code for accepting those shortcuts is already written it shouldn’t need to be reimplimented via some new shortcut (though I personally doubt this is being done).
What I think @kazmroz is missing is that you’re not saying to rewrite the shortcuts portion. You’re saying what looks like a keyboard isn’t actually a keyboard and that someone could write a keyboard if they want one to interact with the shortcuts.
It kind of surprises me that this would be something different than an on-screen keyboard emulator, but I’m hopeful there’s a real technical advantage to doing it this way and it wasn’t a case of not thinking anyone would want a keyboard emulator as a keyboard input method.
Kazmroz is saying “I want a keyboard” where in reality he means “I want to undo this accidental zoom that happened”. I suggested the solution to the first, which looks dumb if you need a solution to the second (as kazmroz didn’t miss an opportunity to make clear).
Discussing this problem in keyboard terms is discussing workarounds. Better solve the core problem IMO.
I see them as 2 unrelated things that both should be addressed.
-
The lack of ability to use the on screen keyboard looking tool as an actual keyboard for global shortcuts.
-
The unexpected change from some application implementation of zoom independent of the global keys.
The first does allow fixing the second without digging into the cause, which is a plenty good work around for most people if it’s infrequent enough. Sure as a technical minded person I’d prefer to know a root cause and address it that way, but for most usage the root cause is less important than a quick resolution and ability to move forward. Point is “better” is relative.
Does Android or iOS do that? Honest question, I don’t use either. I’m guessing that no, because it’s only a thing when you support poorly designed desktop apps on a touch screen. That’s a stretch goal on a phone, and we have bigger fish to fry. And no, it’s in no way a fix for some software’s broken user interface. We are based in a Free Software environment, where everyone has the ability to fix things, so there’s no excuse to extend compatibility for the purpose of letting software stay broken.
I don’t know why you’re hung up on the applications implementing their own solutions. Just because a user didn’t read the documentation and doesn’t know how they made a change doesn’t mean the application is poorly designed, and if it does then PureOS meets that description…
Also, if a keyboard were implemented then global shortcuts could be used and applications wouldn’t need to each implement their own disparit solutions thus it would be a better solution for the ecosystem on the whole.
That’s our difference. If an application needs a manual, it’s already bad, IMO. Where PureOS meets that description, I consider this a bug, and that’s why I’m asking for more info.
Global actions don’t require a keyboard. Notice that you can copy-paste on a mainstream phone without a keyboard. For universally-supported actions, we need a universal solution. On the other hand, application-specific actions that can only be triggered by a keyboard betray a design that was not concerned with touch screens. When such an application runs on a touch screen, the lack of a native way to trigger the action automatically makes it bad user experience, and, subjectively, a bug.
I have seen this view before and I find it to be a bit optimistic, unrealistically so the more complex the program becomes, but a nice goal.
shouldn’t
At least with the Librem5 I find situations where the actions I expect to be global aren’t actually global, including copy/paste, tap to highlight, swipe to scroll, pinch to zoom… and my point is not to complain about this functionality not being where we want it to be yet (we are on the same team here), it’s to point out the reality of the current situation.
This is a separate issue, one that you’re justified in wanting to solve in the application, though the best solution would be to not have to adjust the application because it should work with both the new touch solution and the legacy keyboard/mouse solution, especially when the phone is docked.
The issue raised here has been around global shortcuts being triggered by a keyboard as a work around to the touch friendly solutions not being completely there yet (and the keyboard solutions already existing from the desktop development side). Much like how I use the terminal layout in squeekboard then ctrl+c/v to copy/paste in things like chatty because they don’t bring up the copy/paste context menu. That’s a workaround not the desired long term solution.
Okay, I exaggerate with the manual. But the manual should describe the mental model and syntax of commands, or perhaps a secondary way to trigger the same action, rather than explain which menu to open or what button to press. Discoverability has its limits, but it they are bigger than zooming.
And yeah, totally shouldn’t. I’m a bit disappointed in how badly gnome handles contextual actions 
Still, it’s all bugs which deserve solutions rather than workarounds.
Are you sure? We have an unknown application X, where the user triggered an unknown action Y, which resulted in something Z being zoomed wrong. Then the user found that the system manual has a shortcut for zooming described, but the user did not indicate using it, or it being a successful workaround. There’s no evidence whether there is a global shortcut/action involved here or not.
Anyway, you’ve inspired me to take a look into global shortcuts. It’s a joke that the terminal layout must be used for copy-paste. I’m just disappointed that no one bothered to fix it yet - could it be because there’s a crappy workaround present, removing the motivation?
That is possible, though it also allows others who aren’t equipped to solve the problem to continue to use the system and maybe even improve other things that they can. It’s a complex thing, and there is likely no correct/best path, just different paths. IMO anyway.
And yeah, I should probably made more of an effort to find out if there’s an existing issue for the copy/paste and other issues I’ve encountered but I’ve not done my part there either…
Surely that’s the key, um, point. Many applications in the Linux space were not designed to run on a touch screen, and aren’t adaptive either. So this issue is going to come up for a while to come - until the Mobile Linux ecosystem fills out.
(I wouldn’t necessarily call it bad design or a bug if a GUI application was written and worked long before touch screens were even a thing. There’s only so much abstraction and configurability that you can build in so as to future-proof your application.)
I would have thought that if the original problem is that some setting has been messed up and the only way of fixing it right now is to issue some Super+… combination then … just attach a keyboard temporarily. The Librem 5 comes with a nice USB port at the bottom. Just needs a USB-C to USB-A adapter (as most keyboards will be USB-A).
Who doesn’t have access to a real keyboard? I mean, sure, it’s a bit retro but … 
If the only way to find out about an action is to know a keyboard combo, then it’s broken design, except in very few circumstances. Totally a bug, touchscreen or not. Typically, when an action can be learned about in another way, it’s because there’s a button somewhere, which is automatically solving the touch screen problem.
Making broken applications work is a gesture of goodwill from Squeekboard, not an expected feature 
Even if there are still many broken applications.
By this logic nearly every application that the Librem 5 ships with is broken.
Is it more beneficial to say nearly everything is broken and the user should report that to every application maintainer, or is it more beneficial to provide the workaround so the user of your product can have a functional experience while still being able to report that the experience could be improved to those previously mentioned maintainers? I’m obviously biased toward the latter.
1 Like
I’m not sure if “nearly every”, but if it matches your experience, then it seems so.
It’s more beneficial to provide a stronger incentive to maintainers to fix the apps and not give crappy workarounds. Touch screens are not going away, and it’s time to face that reality. Workarounds have a good staying power, and people might start relying on them rather than fix the core problem, resulting in a clunky experience for everyone (see the current copy-paste issue).
For users of our product, we (try to) provide a default set of applications that are checked to not be broken (we have special marking on packages in the software installation app). If an important functionality is broken, we have a development team to fix it. For community-provided applications, we rely on the community to care about not having bugs
It all checks out IMO.