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
_______________________________________________
maemo-developers mailing list
[EMAIL PROTECTED]
https://maemo.org/mailman/listinfo/maemo-developers
