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

Applets in general are broken because they are no different in
functionality from regular applications, or from each other (in terms of
desklets vs panel applets vs. the notification area). Many applets are
applets because they have very small, simple interfaces; too small to
justify having big top-level windows, too big to sit entirely in the

The big usability disaster this distinction creates is that the
application menu goes from being The Way to run applications to being A
Way to run applications; another bunch of them are run by right clicking
on the panel and choosing to add an applet.

Lots of applets act as launchers. For example, timerapplet[0]. The user
clicks it, it opens a little dialog, the applet becomes a stylish
countdown timer with a nice icon. This could have been done differently.
Alternatively, timerapplet could be opened from
Applications->Accessories, create a notification icon and be reasonably
close to the HIG. The problem there is Accessories would become bloated
with stuff like Wanda the fish, stock tickers, eyes and alarm clocks,
and also timerapplet would be jumping from one corner of the screen
(where it's a launcher) to another (where it's a "window"). Hence the
panel applets; a dumping ground for accessories that don't quite deserve
to take up 30 pixels of vertical space in the Applications menu but can
go somewhere else we never expect the user to use.

Instead, because timerapplet is too small and insignificant to consume
menu space, it is opened with the panel every time the user logs in!
(Wait, what?...)

Similarly, all sorts of applications choose to hide within the
notification area because they want to stay out of the user's way and
window managers fail to provide the necessary functionality themselves.
Thus, they take window management upon themselves and start playing with
system trays. This should remind you, tenacious reader, of tabbed
document interfaces, notification-daemon abuse (for fancy looking dialog
boxes), anthropomorphic dogs and rabbity things.

So here are some questions to answer:
What is so vastly inferior about the application menu that necessitates
"applet" software to provide another distinct list of less important
applications? Why can't we have big and small applications in the same

I do have a guess what could be done. Firstly, abolish applets as things
which must be run differently from other applications; the user should
not Ever see the word "applet" again. Enhance running applications and
how they connect with application launchers and their windows; one of
the things GNOME Shell seems to be doing.

Maybe one way about this is to build on that part of the window manager
where it's up to The User whether he wants to minimize a window, shade
it or put it beside another on the right side of the screen. How about
window management hotspots, such as a panel and a sidebar, each with
unique properties for how they treat windows? The user places a window
in one of those and, depending on whether it supports some fancy
extensions, it becomes a docked window like any file in the panel or the
desktop (eg: a window icon that when clicked opens into a full window
again). Super awesomeness could extend that so the docked window gains
desklety / applety functionality when supported.
Basically, kill the distinction and leave it up to the user to say what
he wants a window to do rather than have them making unpredictable
guesses, and have the window - or whatever other object - do what it can
to meet the user's commands.


Thanks, sorry for the hugeness,
Dylan McCall

PS: I wrote this bit by bit over a couple /days/, so I'm sending this at
risk of it being completely incomprehensible. Forgive me if that's the
case. Mockup almost at the ready if it'll help.

PPS: A nice process here is writing out key features of different parts
of the desktop environment which implement window management. Lots of
overlap, but also lots of examples for how existing infrastructure can
be beefed up as an alternative, tidier solution.

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]