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