ubports / keyboard-component

Moved to https://gitlab.com/ubports/core/lomiri-keyboard
https://gitlab.com/ubports/core/lomiri-keyboard
GNU Lesser General Public License v3.0
10 stars 36 forks source link

Add arrow keys to many layouts #96

Closed tallero closed 3 years ago

tallero commented 5 years ago

If I remember correctly is it possible to add arrow keys in maliit layouts. I think it would be very useful to have them outside terminal.

I do not know in what position they would best fit, I think it could be feasible to have them in a third symbol level and at the same time in appropriate letter popups.

What do you think?

Fuseteam commented 5 years ago

hmm arrow keys and the cursor mover seem related

JassMan23 commented 5 years ago

@tallero I believe you will be happy once the new space key trickles down from dev to RC. It provides a virtual touchpad along with start, end, top, bottom keys and a full set of edit keys such as undo, redo, cut, paste.

tallero commented 4 years ago

I switched to Dev channel some days ago (and tried to install anbox); NetworkManager loop crashes since then.

In any case I found the new feature really useful; key modifiers are still missing, by the way. Can I add them to this feature request?

Fuseteam commented 4 years ago

key modifiers as in ctrl and alt?

UniversalSuperBox commented 4 years ago

Modifier keys are left out on purpose. Ubuntu Touch applications should not need them when on a touch screen, and Libertine applications should be used with an external mouse and keyboard to be useful at all.

JassMan23 commented 4 years ago

OTOH, a keyboard with modifier keys (at least control) would be really useful in console and nano instead of having to select specific subsets using the little popup tool.
Also since UT is all about convergence, wouldn't it be useful to provide the ability to use modifier keys if the user expects a similar desktop app to work in the same way.

UniversalSuperBox commented 4 years ago

Designing for Convergence is not "we shoehorned your desktop apps onto a 5 inch screen," it's well thought-out design patterns that work across screen sizes and input methods. That is, keyboard shortcuts make sense when you have two hands on a keyboard. Tapping icons makes sense when you have two thumbs on a screen.

"Convergence" is not a reason to add things that don't make sense for the interaction mode. Libertine is for running desktop apps when you have a mouse and keyboard attached. The experience is bad with thumbs on a small screen because the applications are not meant to be used that way.

JassMan23 commented 4 years ago

I was thinking the other way round. That some phone apps/clickables would be equally valid on a desktop running as a widget. On the desktop, you would expect to be able to use modifiers and having used modifiers, some users may find it easier than remembering whether such and such action is a long press or a 2 finger tap etc. when using the same app on a phone.
The real strength of modifier keys is that certain actions can be called even though the appropriate icons are not yet on screen. ie you don't need to drill down/expand action groups to get to the action you want.
Also many tablets have screens which rival small desktops and can be operated with a keyboard at you desk but act as a normal tablet on the go.

I do agree though this would be something for a long distant future as there are lots of more important things to fix.

kugiigi commented 3 years ago

Is this still valid? If it's only about arrow keys, then I guess it can be close? But if it's about key modifiers then the title should be changed :)

tallero commented 3 years ago

The mechanism introduced in OTA-12 (at the time it was the testing branch), "the scroll horizontalli to move the cursor", to me solve this issue. About modifiers, what do you think about having them only in landscape and/or in a separate mode? @UniversalSuperBox

Fuseteam commented 3 years ago

@tallero the issue with modifiers is not related to screen real estate. the osk's only purpose is to manipulate text. while a physical keyboard is used for two purposes: text manipulation and program interaction. the latter is why a physical keyboard has modifiers, this is not something the osk should handle.

afaict the main use for modifiers on ubuntu touch would be the terminal app, it should be handled by the terminal app as such the app does try to do that by mapping tab to taps and arrow keys to swipes, I do agree that it is insufficient as is.

tallero commented 3 years ago

@Fuseteam Personally I think a lot of space in mobile keyboards in wasted on landscape, that's why I use "Hacker's Keyboard" (pretty lame name, I know) on android.

I use it as a normal computer keyboard and most of the shortcuts I use are copy (ctrl-c), paste (ctrl-v), find (ctrl-f), select all (ctrl-a) and reverse search (ctrl-r) where is available.

I think I would like a modifier layout to be enabled as an option, because it is in many occasions really useful to have a control button.

Adding a screenshot for reference

Screenshot from 2021-03-03 18-59-57

Fuseteam commented 3 years ago

@Fuseteam Personally I think a lot of space in mobile keyboards in wasted on landscape, that's why I use "Hacker's Keyboard" (pretty lame name, I know) on android.

I use it as a normal computer keyboard and most of the shortcuts I use are copy (ctrl-c), paste (ctrl-v), find (ctrl-f), select all (ctrl-a) and reverse search (ctrl-r) where is available.

I think I would like a modifier layout to be enabled as an option, because it is in many occasions really useful to have a control button.

Adding a screenshot for reference

Screenshot from 2021-03-03 18-59-57

again the issue isn't space, the issue is function and feature creep. the function for the osk on ubuntu touch is text manipulation and only text manipulation. out of the useful functions you mentioned we already have a text selection, select all, cut, copy and paste through the cursor and selection modes of the keyboard. i think text search should be handled in the application interface itself. and reverse search sounds like something the terminal needs a button for in staged mode. while I understand the sentiment, having had the same sentiment some time ago (you should see my first draft of the flick keyboard), adding program interaction to the keyboard doesn't fit the vision of convergence.

the idea of convergence is that applications are designed to work across form factors and input methods. the latter means that we should be able to interact fully with the program without any modifier keys.

the "hacker" keyboard is made for those who want to use a terminal on android. for that use case, I can see modifier keys be very useful indeed. but that is something the terminal app should solve, not the system-wide osk. The terminal already has some pretty creative solutions for the tab key and the arrow keys. I have an idea how key modifiers could be handled by the terminal app but I still haven't worked out all the implementation details. recently I started thinking the terminal doesn't have to utilize the system osk at all it could have its own keyboard controls, modifier keys, and all, completely separate from the system osk

but in short, the vision of convergence means that the osk on ubuntu touch will only ever be for text manipulation, not for program interaction. program interaction includes (reverse) search, escape, close tab, open a new tab, kill a program, switch between programs, and such

thinking out loud about what modifier keys enable to do, does put into perspective what issues it would create. did you know that alt-tab "just works" on ubuntu touch? what do you suppose will happen when you have the osk open and alt tab? should the keyboard disappear? but letting alt tab should exit the app spread..... it creates scenarios we'll have to account, workaround, and test for; it affects the vision of the project and future design choices

peat-psuwit commented 3 years ago

Hello,

Thank you for contributing to UBports. As part of project renaming and the effort to port Ubuntu Touch stack to Ubuntu 20.04, we're incrementally migrating repositories to GitLab.

Your issue is now migrated to: https://gitlab.com/ubports/core/lomiri-keyboard/-/issues/96

Sorry for your inconvenience.