Support and General Use > User Interface and Voice

usability: On-screen keyboard

<< < (6/8) > >>

salival:
I haven't tested the patch, but:
The description says it creates new pages when needed. Can the user decide what's on every page, or does the code decides whether to use a new page or not?
If it doesn't, I think using a (multidimensional?) array (layout=[a,b,..,y,z][A,B,..,Y,Z]) would do the trick.

This can bring the "final solution" closer, since most of the code needed for the keyboard as described in the design document is already there.

What that solution IMO needs is: (hardcoded or not)
- definable layouts
- definable menu options
- multipage suport, where the pages are chosen by a menu.
- the option to allow a page to return to the default or previous page when a key is pressed. an example would be "shift", where the layout should return to lowercase when a character is entered.

I am not much of a programmer, but I think the following could work:
One array for the menu options where every position corresponds with a page. So, position [ 0 ], which for instance has the value "sym" (for symbols), corresponds to page 0 in the pagelayout array, which contains the set for the symbols page.

example (pseudo code):
array menu=[default]["shift"]["Caps"]["acc"]["sym"]; (the first position of the array is not shown in the menu.)
array layout=[a,b,c,...,x,y,z][A,B,C,...,X,Y,Z][á,ä,..][@,#,...]

There are some other points, but I think it would be better if those are discussed in a technical design doc, so they can be explained in greater detail.

markun:
salival: I think your ideas are too complex. phaedrus961's patch works very well regardless of screen size and font size (which I think your probosal does not). Try it and tell us what you think of it.

salival:
I don't think my proposal is much more complex then the current implementation or the mentioned patch.

The reason they might look complex might be of they way I explain things. (I have the tendency to make things look more complex than they are.)

I try to explain the "philosophy" of my proposal in a few sentences.

1. There should be one keyboard which is optimised on a per target basis, while the basic layout remains the same.
2. There should be one single keyboard that can easily be implemented in any program/plugin, while maintaining the feel of that program.
3. The keyboard should have support for non-latin character sets.
4. The keyboard should have support for multiple character subsets, like accented characters, which can be selected by a menu.

It is about the same concept as used in onscreen keyboards on game consoles.

That's the basic premisse.

The main functions needed for this are:
- multi page support, which is already available in the current keyboard.
- custom layouts, which are (partially) supported by the current keyboard and phaedrus961's patch.

All in all it is more a redesign than a completely new design. I always try to keep in mind how easy or difficult an option is to implement.

kenshin:
I adjusted the wiki with a more complete Japanese character set. There are 10 small characters in both the Hiragana and Katakana, not just the 1 Hiragana and 4 Katakana that was already there.

salival:
The hira/katakana layout now occupies 5 rows, which IMO is one too many. Either the small characters have to be fitted between the large ones or, as you suggested and in my eyes the best solution, use a shift button to show a layout with only the small characters.

Navigation

[0] Message Index

[#] Next page

[*] Previous page