[maemo-developers] Moving windows in Maemo

[From: Tapani Pälli]

ext Sean Luke wrote:
> On Apr 11, 2007, at 12:07 PM, Eero Tamminen wrote:
>
>>> For the moment I'm experimenting with various floating windows for
>>> various utility functions -- my drag-and-drop example on my N800
>>> website, say.
>>
>> Do you have an URL?
>
> cs.gmu.edu/~sean/stuff/n800/
>
> [Perhaps I might issue that entire webpage as a bug on Bugzilla, but
> then I'd be ask to break it up into individual reports :-)]
>
>> Drag and drop is initiated with stylus being pressed & moved and
>> it goes away when the stylus is lifted.  So an OverrideRedirect (popup)
>> window is OK for D&D indication (and a stylus grab is implicit when the
>> stulys/button is down), but Gtk should already be doing the D&D
>> indication for you...?
>
> It's a different need than that, but thanks for the info nonetheless. 
> I'm thinking I might try something similar to the Newton's cut/paste
> mechanism (see the article).
>
>> Hm.  I think all the dialogs should be modal according to the UI
>> guidelines.
>
> I've found at least two apps where that's not been the case.  I can
> mention one off the top of my head: deletion of email in the email
> program.
>
>
>>>  Even if the window manager's movable-windows switch
>>> *was* turned on, I'm not sure if they could still be moved, as they
>>> don't have decorations.
>>
>> Which windows don't have decorations?
>
> Notification windows.
>

I don't see any reason to make infoprints resizable / movable. They are
there for few seconds only and for notifications it's good to have one
single place where they popup so your eye catches them.

>
>>> And various panels (fonts, saves, etc.) are not
>>
>> Panels = dialogs?
>
> Yes, sorry my NeXTSTEP past colors my vocabulary.
>
>
>>> resizable even when their size is unneccessarily too small to be
>>> useful.  In all cases, if you moved them or resized these dialogs,
>>
>> If something is unusably small and there would be more space on screen
>> to present that, it's definitely a bug.  Could you file this to Maemo
>> Bugzilla?
>
> It'd be for a lot of dialogs.
>
> The *right* thing would be to make all maemo dialogs and notifcations:
>     1. Resiable
>     2. Movable
>     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)
>
> This would allow users to adjust dialogs and notifications as they
> prefer.
>

Yes, this is *right* thing for someone, something else is *right* thing
for someone else. Persistency sounds good to me, however I don't see
much reason in moving modal dialogs on the screen except 'just for fun'.
Resizing dialogs assumes that they all have scrollable and resizable
content. Layout of the content has been carefully designed and will very
likely 'break' when dialog is resized unless content is packed in a
scrollable widget. In fact you can try this with several desktop apps
and see how they break.

>
>>> 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.
>
> Sean
> _______________________________________________
> maemo-developers mailing list
> maemo-developers at maemo.org
> https://maemo.org/mailman/listinfo/maemo-developers
>

// Tapani