Proposal for a better text editor

[j8048188]

i like the scrollable text idea, but it would have 3 separate lines that would be switched between using a trigger button.

see attached picture.

[DancemasterGlenn]

I think if anything happens to the keyboard layout. one thing that should really be changed is the size of the actual letters.

I see this as a problem that would hopefully be fixed when multifont is implemented. I have no personal problem with the current size on my ipod, but that's mostly because I don't use the editor very much, and never on the go due to it being a bit time consuming. the text sizes in my picture weren't any kind of scale (using text in gimp doesn't seem to be very editable yet...), but I'd say it's definitely readable. Ideally it would also be prettier, at least having the normal backdrop and font color (but that's why it's a rough sketch). It's my opinion that while these potential text editors might not act the same on all targets, it would make sense for them to at least be themed similarly in terms of any colors used (just an example, if any colors are in fact needed). In that way it would be kept at least somewhat uniform.

Have separate lines for Capitals, lowercase, numbers and punctuation and move between them with a button press (short menu?). Each individual line would wrap to the start of that same line.

My problem with multiple lines (besides clutter) is that we start running out of what I would think of as "sane" button combinations for normal use. If clicking "menu" now exits without saving, it doesn't seem like it would make sense to change that press to switch a line, and (I'm assuming) make quit a long press. I still think that if it scrolls nicely, having all the characters on one line (capital, lowercase, or other) should still be smooth.

Actually, now I'm curious. Do you want to be able to see all three lines at once, or are you talking about using menu to toggle between visible lines? Because that could be nice, actually... no clutter, and it might even be useful for putting other kinds of characters into my model (one could switch into foreign characters in this model, if toggling between formats was customisable with different character sets). In this way we could avoid getting a really huge line in any given situation, and some plugins do use a long menu to exit, if I remember correctly, so it's not that insane. We would lose our long menu going into Morse code, though, and I enjoy that feature (I think it's really smart). I suppose an option could be made to use Morse code, classic, or this potential third option in a text editor preference menu, but you'd lose the ease of switching you have now. Although if the idea worked well enough in practice, it would definitely be more useful on the go...

When I'm less swamped with work, I've been thinking about looking at as many of the targets as I can, to perhaps make more crappy concept drawings. Anyone could do this, really, and it might help if the person doing it actually owns the player, since I would just be looking at pictures/videos of players in action and reading their rockbox manuals. If this is a silly idea, please tell me so.

[DefineByte]

I was thinking of only one line being visible at a time and the line simply changing when you press a button. Text size could be as big as you wanted and the line would simply scroll across the top of the screen if it didn't fit.

Probably superfluous rough ASCII representation:

---------------
|stuvwxyzabcde|  <line scrolls with wheel
|      ^      |   Short menu for next line (numbers)
|             |
| pla|.m3u8   |  <line scrolls to follow caret if name too long
---------------

That's how it's been in my head for the last few months but I haven't really thought about any possible issues it may have. Maybe being able to see multiple lines would be better. I don't know. Should work with multiple targets, even those with tiny screens.

[DancemasterGlenn]

Yeah, that's the essential idea. On screens with room there could perhaps be something in the corner displaying which line you have in use ("abc", "ABC", "123", "!@#"), so people know they can toggle.

[bascule]

It would be worth reading this: http://www.almaden.ibm.com/u/zhai/papers/ZhaiHunterSmithHCIGalley.pdf

It describes the theory behind the OptiII layout that's on the Wiki (more interesting than you might think) and explains that it is optimised for minimum movement of the cursor i.e., common letters  grouped in the middle, least-used towards the outside.

However, this approach is less useful for the scrollwheel targets and something like that proposed above would be quite cool if done properly. As usual the stumbling block is finding someone both interested and capable of coding it.

[Llorean]

I think the simplest solution would be, for scrollwheel targets, to have it so if you scrolled off the right side of the screen you entered the next side one line down. Then it would behave similar to the line, but without a complicated new system, just one slight change to the behaviour?

[DancemasterGlenn]

It would be worth reading this...

Interesting... I'll check this out, looks like a good read.

But yes, the main reason I looked into it at all was the fact that using the scroll wheel to move up and down felt very unintuitive. I'm sure that on targets with four-directional scrolling have a better time with the current model (such as the gigabeat? I've never even held one, but it looks like it's got four directionals...). If the implementation of my idea was even slightly like using the pictureflow plugin, or entering one's name in an arcade game, it seems like it would make it pretty fun to do, as well

I think the simplest solution would be, for scrollwheel targets, to have it so if you scrolled off the right side of the screen you entered the next side one line down. Then it would behave similar to the line, but without a complicated new system, just one slight change to the behaviour?

That alone would be a nice change in the current behaviour... one of the weirder aspects is having all the empty space be treated as lots and lots of usable blank characters.

I'm not throwing out ideas simply to shake things up and cause a stir or anything (hopefully you don't think so)... I'm just off in my own little world brainstorming. Your suggestion would be great for the current model, but I'm still hoping someone with some actual skill (i.e. not me) will take enough of an interest in the idea to at least make a simple plugin for people to test out. I have a feeling this would be really fun in practice, and maybe being able to try it out would make more people take interest. And finally, you probably didn't mean this when you said complicated, but at least in my first picture I drew, wouldn't you agree that one line to navigate should potentially be less complicated to navigate?

[Llorean]

"Complicated" as in "Adding yet another text input method, causing there to be a yet more code of debatable merit." There would be no practical difference between having scrolling increment/decrement at line end, just a visual difference that would require new code. With my suggestion, existing custom .kbd files would still be entirely usable with it, and a user can usually see all the letters to know whether forward or backward is the shortest path to them (possibly important with non-alphabetical characters such as those in other languages, or symbols, which are not always placed predictably).

[DefineByte]

Having all characters on screen at once puts severe limitations on the potential size of the text. Something which I have a particular interest in.

[shotofadds]

Out of interest, why does the default keyboard use the system font, when a Loadable Keyboard uses the UI font?

[Llorean]

@Definebyte: It's not "all characters" but "each page of characters" since I believe the current method allows toggling between pages. Would being unable to tell if you need to scroll 10 characters to the left or 400 to the right be more or less useful than being able to skip between fully visible pages until you get to the one that has your character, then quickly scroll left or right to it depending on which end it's nearer?

@shotofadds: I think so the default one is *always* usable (visible on the screen, etc).

[DefineByte]

I don't know where 400 characters comes into it. I was talking about four lines (maybe three would be fine) of around 30 characters. Maybe I'm not understanding you.

Currently you can't 'scroll' left or right anyway, you have to use FF/Rew, which is much slower. Surely you can't think two separate input methods for horizontal and vertical scrolling is a good thing either (which both the default and opti2 layouts demand)?

The current method needs more buttons, is over-complicated and quite slow. If extra/target specific code is deemed undesirable to deal with that then there's not much else to say.

This is all from the perspective of an Ipod Video user of course.

[Chronon]

I also find the asymmetry between horizontal motion and vertical motion a bit troublesome at times (with a Sansa).  Maybe a good first step would be just to switch the scroll wheel action to horizontal and allow the scrolling to line wrap like Llorean suggested.

[bascule]

Agreed. Flyspray feature request raised:

http://www.rockbox.org/tracker/task/8904

[DancemasterGlenn]

I still like my idea a lot, but I think that the flyspray suggestion (using the scrollwheel to go through the wrapped letters in their current layout) is a really solid step in the right direction, with the least new code needing to be written. I'd be happy with this, for sure.