[maemo-developers] Moving windows in Maemo

[From: Eero Tamminen]

Hi,

Tapani Pälli wrote:
> ext Sean Luke wrote:
>> The *right* thing would be to make all maemo dialogs and notifcations:
>>     1. Resiable
>>     2. Movable

Why?

By the time user was able to start moving notifications,
they go away (within 3 secs I think).

The only reason why user would want to resize a dialog (that I can think
of) is to make it larger so that she can see more of its content.
However, these kind of dialogs usually already take all the available
space, so I don't see much point in that.

If the dialog doesn't fill up the screen and is instead in a size that's
not usable, that's a bug which should be reported separately.


Note that some of the dialogs have static sizes because Gtk doesn't
always handle automatic resizing well enough.  This is only a problem
with text ellipsizing though I think.  Gtk has only concepts of minimum
(for ellipsizable text="...") and full size of a widget, as getting
something reasonable in between would need a lot of iterating (slowdown)
for the widget sizes.


>>     3. Persistent (so next time you reopen the app, the dialog is pops
>> up in exactly the size and place you put it last time)
...
>>>> they'd not stay put next time, because maemo doesn't have persistent
>>>> state.
>>> Could you give an example of this problem?
>> Not for dialogs/notifications, as they're not adjustable.  But let's
>> take another example.  The email program (nicely) has adjustable
>> columns in its column view.  But if you quit the program after
>> carefully adjusting the columns, when you come back next time, they're
>> all reset to their default locations.  What's the point of that?
>>
>> In general, in a good PDA UI, things "stay put".  This is particularly
>> important for small screen devices like the 770/N800, as the user must
>> tweak to get things arranged in a usable state.  Having them
>> automatically untweak is very irritating.  Other examples of things
>> which should "stay put" after reloads:
>>
>>     - scroll bar positions
>>     - range settings
>>     - combo box settings
>>     - text
>>     - checkboxes and radio buttons
>>
>> Much of this _should_ have been done at a system level; but at least
>> it can be hacked by the coder at the app level.  Unfortunately,
>> Nokia's mechanism for storing state persistence is broken: it doesn't
>> survive reboots.

Maybe you could make a bug about the persistency?


	- Eero