[maemo-developers] Moving windows in Maemo

[From: Sean Luke]

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.


>> 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.


>> 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