Proposal for a better text editor

[Chronon]

You'll notice that I said "first step".  You are welcome to continue to discuss other interface ideas.   

[DancemasterGlenn]

And you know I will, haha 

[Llorean]

My point with "400 characters" was that any future solutions should take into account loadable layouts that aren't restricted to the alphabet we use in English. A long linear strip of characters is pretty much the worse possible way to move through a very long list of characters, especially since you can't see them all. Having it display as many characters as possible, and with the ability to move forward/backward a page at a time too, improves this problem greatly.

[DefineByte]

The longest alphabet appears to be 74 characters. Should be able to accommodate that easily with scroll acceleration. I guess Kanji and the like could be split over multiple lines. x)

[Llorean]

Does that count include characters in that alphabet, English letters (for recognizable extensions at least), numbers, and all associated non-alphanumeric symbols?

And again, wouldn't you prefer to SEE which direction to scroll? You don't seem to get this: The controls would be essentially the same as the linear mode suggested, it would just offer the option of OTHER controls and the ability to SEE what you wanted. What exactly is your problem with it? Or perhaps, what advantages does your method offer?

[DefineByte]

Does that count include characters in that alphabet, English letters (for recognizable extensions at least), numbers, and all associated non-alphanumeric symbols?

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.

[Chronon]

I know.   

I'm just trying to build a bridge.

[DancemasterGlenn]

I think larger font is kind of tangential to this discussion.  Wouldn't that be addressed by support for multi-font capability?

Yes. I said that earlier, and realize that it will eventually be addressed. Not really a problem for me, but something I was thinking ahead about.

As well, if you load a custom keyboard then it should use the user font instead of the system font.

Most definitely.

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.

I think I understand?  I definitely don't want all the character sets on one huge line, so yes, I think this is correct.

Also, I think I just actually realized what everyone meant by paging. Let's see if I'm correct: all the capital letters would be on the display at once, and you could scroll through them as they wrap around the screen and all. Then you would press a button (whatever, a long next I guess on an ipod?) and it would display lowercase (turning a page, as it were. This is the paging part, right?). Another click, symbols, another click, numbers (order doesn't matter here, I'm just trying to understand). Is this correct?

Assuming it is, I have no problem whatsoever with this idea. I like my idea fine because in my head it looks pretty, but this sounds like this would be just as easy to use, more visible everything (only having one of these sets on the screen at once frees up more space than the current model of having everything on the screen at once), the idea of having a permanent cursor always on (like my comment in the flyspray task) for moving around with next/prev on an ipod, or deleting something with a long select (examples) still works, and it would even keep the menu button freed up if we wanted to keep using it for morse code. Excellent. Unless I missed something and I'm getting this all wrong.

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

It seems I was not understanding quite what you meant, but I never had an outright objection to anything you said. I already told you, your idea was a good one. And it's even better now that (I think) I understand it completely.

EDIT (classic me...): I also can appreciate how this setup would work better than my original idea for non-english languages.

[Chronon]

Good.  I'm glad my post had some apparent effect in clarifying the situation.

And to confirm, yes, by using pages you could consolidate all capital ASCII letters into one scrollable page, lowercase into another, uppercase Greek into another, etc.

[Llorean]

And (in my opinion) a significant benefit is that it wouldn't be fundamentally different than the display for non-wheel targets, they'd just have a more classical way of navigating around the screen full of characters. And touchscreen UIs  could allow you to simply tap the desired character. Thus, you wouldn't have different input screens for different targets, just different controls for that screen.

[DancemasterGlenn]

Sounds fine to me.

EDIT (I'm on a roll!!!): The more I think about paging, the more I like it. This would really benefit smaller screens, like the nano. I like this idea a lot!