[maemo-developers] Moving windows in Maemo

From: Eero Tamminen eero.tamminen at nokia.com
Date: Mon Apr 16 19:06:38 EEST 2007

ext Sean Luke wrote:
>> This is just that string.  Before you know what space the string
>> can or should take you need to check the sizes for all the widgets
>> contents, take into account the expand etc. attributes in the co.
>> widget hierarchy etc.
> I'm missing the problem here.  Isn't this being done in the typical
> top-down fashion?
> 1. Set in stone the widget dimensions.
> 2. Compute and cut string lengths line by line
> 3. If the total height will be more than the widget, include a scroll
> bar if appropriate
> 3.5 If including a scroll bar, recompute and cut string lengths line by
> line
> 4. Paint
> This is at most an O(n) operation, at least it is on previous GUIs I've
> used.  Is there a misfeature in GNOME which is messing things up here? 
> Is GNOME allowing string painting calculations to change the widget
> size?

The reason why ellipsizing is used is that the text doesn't
(potentially) fit to the available space, e.g. when it's localized.
However, the minimum size requested by ellipsizable text or some other
items which can have a non-fixed size is usually very small.  In the
case of ellipsizable text it is "...".

Now.  How does the container decide whether it should use the full
length for the string (which as a filename, URL etc can be hundreds
of chars long), or minimum size which for ellipsizable string probably
isn't what user wanted to see ("..." doesn't contain any useful
information) or something in between?   Especially if how much space
is available is calculated based on it's contents of which some
are these items which sizes are somewhat flexible regarding their

> If so, this is very bad behavior indeed, particularly for a small
> device.  BTW, you can avoid 3.5 if you always include a scroll bar,
> blank or not.  That's what's standard on the Mac.

On small screen you might not have space for that.  Also, you would want
to avoid having items with scrollbars inside areas with scrollbars.
(another problem which one encounters more easily on smaller screens)

>> The device has a small screen, long strings might not fit into it.
>> What Mac OSX does e.g. when showing filenames or URLs that are, say 500
>> characters long?
> It truncates them.
> Here's a picture of various MacOS X text modes.  Note that in all cases,
> there are no ellipses.

These are not text labels, they are text edit widgets.

Think of for example a Browser menu listing *only* the pages you've
visited.  When page doesn't have a title, its URL is shown instead.
URLs can be very long (as admittedly can be some HTML page titles too).
However, (as code) you don't know which of the items are "too long".
All menu items are set as ellipsizable because any of them can be too
long, so the minumum menu width is "...".

The problem is not widgets telling what is their maximum size
(doesn't fit to available space) or minimum size (doesn't show enough
useful information to the user), but somehow things deciding
what is the the optimum size for them.  Programmer just hard-coding
the widget width in pixels is not really a solution.

It's not an easy problem to solve.

	- Eero

More information about the maemo-developers mailing list