Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java

[Benja Fallenstein]

Asko Soukka wrote:
> Sat, 11 Jan 2003, Tuomas Lukka wrote:
>
> > > Umm... for me it seemed that PP didn't define any maximum width for
> > > CellView.
>
> ...
>
> > However, as with just about all text, having more than 80 chars on a line
> > is awkward to read so there *should* be some limit and automatic
> > row-splitting.
>
> Could this be interpreted as "artificial intelligence"?-)
>
>    "We must have some limits, because otherwise stupid users write
>     awkwardly long lines and limiting line width would be only for their
>     own best." O:-)

Personally, I simply dislike having to break my lines myself. It means I 
have to reflow myself when editing and so on. Automatic linebreaking 
means one thing less to keep track of...

> How should be make difference between implicit line-breaking and explicit
> "\n" breaks? Probably we shouldn't...

Probably not.

> How would giving a very long width string (60 times "X") work when the
> content of the cell is small? Would LCCV give smaller width if its has
> only one short line as its content?

No, it would always give the same  width. Why? What do you use the width 
for in PP?

(Speaking of which, what do you use the height for, anyway? ;-) )

> You should also know, that I implemented few keybingins on friday for
> editing multi-line cell contents. And they can handle lines only as
> content between two "\n"s (including the first and the last line). I don't
> even know how the line-splitted content could be get from LCCV? As
> string arrey maybe, but would it be any good?

Aaah, this is something we also need in the main client. String array 
doesn't sound good-- I think either an int array with the positions 
where line breaks are, or the gzz.vob.linebreaking.HBroken object 
directly (the latter may be better).

> New bindings:
>    Up: one line up, preserves the position from the beginning of the line
>    Down: one line down, [same as above]

What does 'preserves the position from the beginning of the line' mean? 
The *correct* behavior is to do it by pixels-- i.e., you remember that 
you're 87 pixels from the beginning of the display line and look for the 
character boundary closest to this position (the algorithm for finding 
the cursor position after a mouse click is usually used for this in 
PUIs). This behavior is correct because it matches user expectations 
best. There are a number of shortcuts, since the correct implementation 
is quite difficult, and PUIs have gone through all of them--

- go to the beginning of the line above/below (particularly annoying)
- remember the offset in characters from the beginning of the line--
  this is my best guess at what you're doing; this works well only for
  fixed-width fonts, otherwise you get jumping cursors
- look for the insert point visually above the current cursor position,
  but do not remember the offset in pixels from the beginning
  of the line, just the character position in the whole stream--
  this is lossy, because 'Up, Down' doesn't necessarily bring you back
  where you have been.

I don't know what route to take here; I find anything but the correct 
way and the last kludge above almost unusable, though. This also 
interacts with billowing, but I think we should KISS it right now and 
not think about this yet. The problem then becomes how to find the 
cursor position above/below another cursor position; the information in 
the HBroken object currently suffices for this (and will until we 
introduce billowing or undulating) so I think we should use that.

It would be nice if these were ready by next wednesday-- for both the pp 
and the email client demo :-)

>    Home: to the beginning of the line
>    End: to the end of the line
>    Ctrl+Home: to the beginning of the cell
>    Ctrl+End: to the end of the cell
>
> I'm not sure about the keys for those last two - you are free to fix.

I like them :-)

- Benja