[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java
From: |
Benja Fallenstein |
Subject: |
Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java |
Date: |
Sat, 11 Jan 2003 15:20:14 +0100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 |
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
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, (continued)
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Benja Fallenstein, 2003/01/10
- [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Asko Soukka, 2003/01/10
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Benja Fallenstein, 2003/01/10
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Asko Soukka, 2003/01/10
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Benja Fallenstein, 2003/01/10
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Tuomas Lukka, 2003/01/10
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Benja Fallenstein, 2003/01/10
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Asko Soukka, 2003/01/11
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Tuomas Lukka, 2003/01/11
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Asko Soukka, 2003/01/11
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java,
Benja Fallenstein <=
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Asko Soukka, 2003/01/11
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Benja Fallenstein, 2003/01/11
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Asko Soukka, 2003/01/11
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Benja Fallenstein, 2003/01/11
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Tuomas Lukka, 2003/01/11
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Benja Fallenstein, 2003/01/11
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Tuomas Lukka, 2003/01/11
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Benja Fallenstein, 2003/01/11
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Tuomas Lukka, 2003/01/12
- Re: [Gzz-commits] gzz/gzz/view LinebrokenCellContentView.java, Benja Fallenstein, 2003/01/12