(I'd sent this to Mimi & Sheila without copying the list; they both
replied and corrected me; I've edited it a little, too)
I'm turning my list of "architectural tasks that I think will need to
get done in 0.7" into a more detailed list, and I wanted to get feedback
about changing the detail view's layout strategy, which I think is going
to be necessary soon. I'd suggested this in the past, but I got the
feeling Mimi didn't like it, so I thought I'd bring it up for discussion
as part of our 0.7 planning...
The current detail view is comprised of single-line text controls and
one multiline control (the notes body) that stretches to fill available
space. If the text in a single-line field is too long, the user has to
scroll horizonally to see it; the text in the multiline control wraps
and displays a scrollbar if the text is too tall.
I think that this strategy is impractical in the real world: Horizontal
scrolling isn't a great on-screen solution in our calendar--focused
world, and won't work at all when it comes time to print the detail view
or target email (since 'to' lists can get really long). Also, we keep
adding fields to the detail view (I just added cc & bcc for emails)
which makes the visible part of the notes even smaller: The viewable
area of the body of an Event+Email item is already reduced to the size
of a business card, which seems ridiculous since the important part of
an email is the body of the message.
So, my suggestion was twofold:
- Change the text controls (both single-line and multiline) to always be
tall enough to display all the text in the item, dynamically
expanding/contracting as the user edits the text.
- Put a scrollbar on the full height of the detail view if the height
exceeds the available space.
I don't know how hard this is going to be: I think it's going to require
some wxWidgets work (since I don't think we have enough control over the
presentation of the textcontrol as it is). I just know that if we're
going to do it, we need to think about it now. (And if we're not going
to do this, we're going to have to think up other strategies for
managing long lists of addressees and printing the detail view!)
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
