[maemo-developers] Moving windows in Maemo

[From: Kemal Hadimli]

(Sorry, wrong from field. Reposting.)


The need for a close button and move option in infoprints is, as
stated before, they just prevent you from accessing stuff below them.

Example: I can't crank up the brightness immediately (or mute sound)
when the "Connected to AP" infoprint is shown and it bothers me to
wait. Can't interact with the widgets under the infoprint. A dismiss
button on the top right in each infoprint would solve this. Without
the ability to close/dismiss these makes the users wait unnecessarily,
and that is just bad design.

Another example: Some infoprints are there for a long time. Think
maemo-mapper downloading maps. The app is multithreaded and the
download process doesn't block you from browsing around, but you can't
access under the infoprint because there's no way to move it around
(or close/dismiss it)

(Also, persistency among different types of infoprints would be good,
position etc)


A good way to handle this would be to register "notifications" with
the system, and then make a control panel applet to browse through
notifications (grouped by applications that registered them) and reset
states, disable some notifications (Some people might not want to
receive notification from maemo-connectivity-something each time it's
connected to an AP) and such.

A workflow example off the top of my head would be something like this:

Application A (let's call this "mapper") registers notifications at
installation (or on run, whatever)
notificationSystem_register(UNIQUE_ID_FOR_NOTIFICATION_DLP, "Map
download notification", NSYS_PROGRESS);
notificationSystem_register(UNIQUE_ID_FOR_NOTIFICATION_DLC, "Download
complete", NSYS_TEXT);
notificationSystem_register(UNIQUE_ID_FOR_NOTIFICATION_GENERR,
"Error-generic", NSYS_TEXT);

first parameter could be a application-wide unique id for the
notification, second is the "name" (not text) and third is the type
(progressbar or whatnot)

then, to display notifications the app would just call:
notificationSystem_display(UNIQUE_ID_FOR_NOTIFICATION_DLC, "The
download is complete");

Then the system decides whether or not to show it (depending on the
user prefs, see blow) where to place it and what size, etc.

The control panel applet to manage notifications would show a list of
the applications that registered notifications:
+application b
+application c
+maemo-desktop
+mapper

and when clicked it would show a list of registered notifications for
that app. Which the user can then "set a size and position", disable
(disabled notifications are not displayed), or reset (defaults)


Ok, i went a little off topic there.

Best regards,
Kemal

On 4/12/07, Tapani Pälli <tapani.palli at nokia.com> wrote:
> 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


-- 
Kemal