Support and General Use > User Interface and Voice

Proposal for a better text editor

<< < (8/13) > >>

DefineByte:

--- Quote from: Llorean on April 17, 2008, 04:01:13 PM ---Does that count include characters in that alphabet, English letters (for recognizable extensions at least), numbers, and all associated non-alphanumeric symbols?
--- End quote ---
Why would they be put on the same line?

I'm not sure I have a problem until I try it. The current method, with a few tweaks may well be fine. The most important thing is how the scroll wheel is used.

I think most people know the alphabet so not seeing it shouldn't be a problem. The position of common glyphs on the punctuation line could be easily remembered and you'd see it as you scrolled anyway, as you do with lists in Rockbox now.

Llorean:
Even if you know the position, paging to it is faster than scrolling to it, and just scrolling within the page...

Why should we do a slower method that offers less visual feedback? What advantage does it offer, at all?

DancemasterGlenn:
Mostly it would offer the space for larger text and minor aesthetic appeal. As was stated by a couple of people, if a long menu press (as an example) could switch between capitals, lowercase and symbols, it stands to reason that it could also toggle different language sets as well (although this could potentially be slow in transition). Perhaps a setting that lets you check off which languages you want to be able to toggle to in basic use. I agree that it does help to see all the characters at once, but I still think that (and this has been said) with proper acceleration of the scroll wheel, there should be no speed loss. Unfortunately, I can't prove that without a plugin to back up my statements.

Chronon:
I think larger font is kind of tangential to this discussion.  Wouldn't that be addressed by support for multi-font capability?  As well, if you load a custom keyboard then it should use the user font instead of the system font.

It seems to me that there's no fundamental difference between the ideas of paging and toggling between character sets.  Basically, you're changing the topological structure from being a single LONG ring into a set of disconnected rings.  It's very often much faster to jump to the ring you want and then scroll within the ring than to have to scroll all the way through a long, monolithic ring.  Paging jumps you to a new set of characters that the scroll functionality allows you to traverse.  This is all that the toggling action that DancemasterGlenn has described accomplishes, as well. 

Of course a slight change to the page changing behavior seems necessary to make them more equivalent.  For instance you would want scrolling off of the end character on a page to wrap back to the beginning character on that page and not go to the next page.  I admit that I have never used a multi-page keyboard, so I am not very familiar with how this behaves with various targets.  My understanding is that some targets have a dedicated page turning button while others simply turn to a new page if you scroll off the side of the current page. 

What do people think of this idea?  It combines the basic structure of a set of rings that you traverse with the scroll wheel with visibility of all characters within a given subset.  Subsets can be chosen with the press of a button (i.e. turning to a new page).

Llorean:
That's what I suggested, but I'm having a hard time understanding Glenn and Definebyte's objection to it.

Navigation

[0] Message Index

[#] Next page

[*] Previous page