Re: Moving windows in Maemo

ext Kemal Hadimli wrote:
> (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.
>

Well I don't really agree that 2.5 secs is 'too long' but I
agree that
sometimes infoprints are irritating, especially if there's
more than 2
of them on top of each other ... it would be much better to
have a
quake-console instead. We have had some discussion about
more
centralized system, 'infoprint daemon' which could handle
the queue of
messages with more intelligence and maybe user could also
read the stuff
from backlog if does not want them infoprints to appear.
Suggestions are
welcome!

> 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)
>
Yep I don't like that too, I think maemo-mapper should just
have some
kind of small animated icon in corner or toolbar with
progressbar.

> (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_GENER
R,
> "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.pallinokia.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
>
>

// Tapani

_______________________________________________
maemo-developers mailing list
maemo-developersmaemo.org
h
ttps://maemo.org/mailman/listinfo/maemo-developers

Re: Moving windows in Maemo

Thread: Re: Moving windows in Maemo