Re: Applets? [was Re: Planning for GNOME 3.0]

[Olafur Arason <olafra gmail com>]

What I would die is two things that stem from the same concept:

A low operation mode that would be sent through a term signal
so that the application knows it only has to perform basic
operations. Like Rhytmbox only playing music and giving status
updates, basically suspending there graphical user interface.
For most application this would result in the same reaction
as with Ctrl-Z, even possible sending Suspend to application
that don't support some dbus service. This would eliminate
polling and lot's of other stuff that minimized application should
not do. This could also be used for applets.
This would happen when application are minimized.

And a suspended to disk mode which would pack the memory
data to disk to be restored the next time the users clicks on the
icon. This would be menu option in the minimized application,
"Put application to sleep". This is a killer feature for any user
of firefox that has to do short memory intensive operations. I
basically do killall firefox now.

Regards,
Olafur Arason

On Tue, Apr 21, 2009 at 1:25 PM, Martin Meyer<elreydetodo gmail com> wrote:
> I've found that I really like the plasmoid approach from KDE4. Most of
> those things fit the description of "infrequently needed for short
> periods of time", or "crack". From my point of view (a user), I mainly
> want to be able to get to applets quickly. With the current small
> format of applets on the panel, getting any significant amount of info
> requires that I actually mouse-over or click many of them to see
> what's going on. Since I'm already context-switching my mind from what
> I was doing to whatever I'm about to do with the applet, I don't
> particularly mind if my current application disappears temporarily
> while I work with the "applet". With that in mind...
>
> What if we create a new class of window for applets with these characteristics:
> - Does not appear in the Window list
> - Does not appear in the alt-tab switcher
> - No window borders (they will draw their own content somehow)
> - The Window Manager will have a certain key event that will bring all
> of these class of windows to the foreground until that button is
> pressed again (or each applet could register its own)
> - These windows (or maybe their children?) can be configured to be on
> top of all windows permanently, maybe with a lowered opacity (so you
> can always see f.e. your CPU usage on the system monitor applet)
> - The windows can be positioned anywhere on the screen
> - Ability to toggle temporary visibility in order to inform of events
> (next song playing, network disconnected, etc.) (maybe a good way to
> do notifications in the future?)
> - Would be nice if each app could have a "collapsed" state to further
> minimize screen usage (for people with smaller screens)
>
> The goals of this design would be:
> - Quick access to any of these applications when you need them;
> already running, just a keypress to activate them / bring to
> foreground
> - Can display more information because they have a larger display area
> - Can be written into any applicable spec so other environments could
> implement these
> - No specific framework required to these applications, just create a
> certain type of window
> - No language constraints; anything that can make a graphical app can
> make one of these
> - Any app could have a "minimize as applet" state (media players would
> like this) which shows just the basic info about them in a small
> footprint
>
> I personally think that the current state of applets is a little
> limiting. I like the panel well enough, but I feel like applets could
> be displaying more information about their state if they just had a
> little more screen real estate to play with. Since many people have
> very large screens now, why not work on letting the applets take up
> more of it?
>
> - Martin
>
>
> On Tue, Apr 21, 2009 at 8:10 AM, Emilio Pozuelo Monfort
> <pochu ubuntu com> wrote:
>> Milan Bouchet-Valat wrote:
>>> While I agree your proposal would be a great enhancement for most
>>> applications that abuse of the notification area (e.g. music players), I
>>> don't think that could  fully replace applets. Applets like timerapplet
>>> or sticky notes are different from standard applications in the sense
>>> that you don't work with them as a full task, but only keep them in the
>>> background to be easily accessible, while you actually use them for a
>>> very short period.
>>>
>>> The point with them is that the ratio (time running)/(time use) is very
>>> low compared with e.g. a text processor. Thus, you need them not to take
>>> too much space on the screen, not even, as you suggested, stacked in a
>>> corner by the window manager. I'd argue that the best place to put them
>>> is on a separate layer à la dashboard (Apple), or directly on the
>>> desktop. This layer could be accessed with a button in the top panel,
>>> somewhere or in the overlay. Many "widgets" of this kind exist, see
>>> Screenlets, Superkaramba, or Google gadgets, or Plasmoids. A simple way
>>> of reintroducing applets in a "correct" way would be to support e.g.
>>> Screenlets in an overlay: replacements for Tomboy already exist in that
>>> framework, which is AFAIK compatible with other widget formats.
>>>
>>> At least, that's really how I consider we could get rid of the clutter
>>> on the main screen, which is distracting us with icons we don't need to
>>> be always visible.
>>
>> I like the proposed solution that the panel launchers would somehow become a dock.
>>
>> e.g. for Tomboy or Hamster Applet, you have the icon launcher. If you click on
>> it, the app is opened. If you click on it again, it's closed. That could be
>> achieved with single-instance applications (libunique), for example (when you
>> try to launch it again, the instance is closed). For many cases, I can imagine
>> such a workflow would be fine. It wouldn't solve all of them though, for example
>> you don't want system-monitor to be a launcher, but rather to see the system
>> activity IRL.
>>
>> Another benefit of this is that a) your applet doesn't need to be started up on
>> login, and b) you don't have it running everytime. Of course, you need it to be
>> quick to start up. But if it doesn't for such small applications, it's a big
>> fail IMHO.
>>
>> Best regards,
>> Emilio
>>
>>
>> _______________________________________________
>> desktop-devel-list mailing list
>> desktop-devel-list gnome org
>> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list