Re: [Usability]Re: Notification area (was: Music player UI)



On Sun, 2003-02-23 at 18:13, Per Cederberg wrote:
> Sean Middleditch wrote:
> > On a home machine, you can't stop it no matter what.  If people install
> > Crap(tm), Crap(tm) will run.  If not a status docklet, then an applet,
> > if not an applet, a whole new panel, etc.  At the office, well - users
> > shouldn't be able to install Crap(tm).  
> 
> But the anarchy on Windows is worse than that. A lot of the
> applications that I actually *needed* to have for work showed
> silly tray icons informing me that they were running. The
> anti-virus program had two for example, and they couldn't
> be removed by other means than stopping the service... :-(

Ew.

> 
> So even in a controlled environment, things tend to get out
> of hand when every application thinks it is the most
> important one. Of course, this problem is not limited to the
> system tray.

No.  Apps could do the same thing with applets, panels, whatever.  A
good policy needs be written, and people need to file bugs against apps
that misuse the technology.  About all you can do.

> 
> > Ya, the multimedia keys one is pretty dumb.  I'm not sure what its
> > purpose is.  We don't have gconf or bonobo-activation running in there,
> > neither should we have a key-binding daemon there.  Preferences should
> > be linked to in the Control Center, like usual.
> 
> Yes. I've been wondering why there was a button "Launch
> multimedia key daemon" in the preferences for the multimedia
> keys... It also took me some time to figure out how to
> activate it upon login (and thus avoid going into the prefs
> every time).

Personally, I think the whole idea of a daemon just for multimedia keys
is silly.  It also wholly sucks, because it only works for multimedia
keys.  I'd love to map, say, ctrl-[ and ctrl-] to volume down/up, but
it's not possible using Acme.  A good central key binding daemon that
maps *all* possible key sets to all possible functions would be most
cool.  Acme would either be that daemon, or be a plugin/module/service
that uses it to provide multimedia functionality.  Other services could
be written to plug into the daemon, as well - daemons that need
keybindings would register themselves (and the functions they provide)
and their default key mappings, and the daemon would look up the users'
preferences, and do all the work of managing the actual key presses. 
The panel and Metacity, for example, would just be plugins to this
daemon.  That would be most nice.

> 
> I know, time to stop whining and go file some bug on this.
> (If there isn't one already, which wouldn't be surprising.)
> 
> > Ya, hide Applets from users.  Applets are evil evil evil.  ~,^  They
> > offer a lot of functionality for the advanced user, just like a terminal
> > does (a very useful app, but not something I'd embed in Nautilus or the
> > panel... oh wait, we already have one in the panel).  A user does *not*
> > need a command-line on the their panel, nor do they need to see their
> > CPU usage graphed, etc.
> 
> You're probably right, although I love my CPU usage
> applet... ;-)

lol.  Ya, lots of other people would have a fit I think if applets were
removed altogether.

> 
> But maybe right-click and "Add to Panel" isn't so intrusive
> for the general user after all? I don't see it as altogether
> wrong to keep this even if the notification area and the
> applet panel are merged together.

Well, what I'd like to see is the menues split into the standard panel
objects, and the l337 hacker applets, at the least.  A lot of other
usability improvements could be made to the panel objects, as well.  For
example, launchers instead of being independent items that are a pain in
the rear to manage (location/movemen on panel, mostly) something like
QuickLounge could become standard, get a nicer UI, and become the only
way to have launchers on the panel.  It adds organization, makes it
easier to manage space on the panel (only deal with location/size of one
panel object, versus N launchers).

Also can simplify the auto-magic panel object placement/resizing, since
these objects can be "optimized" to play together properly, and let
people who need to add eccentric applets deal with eccentric panel
layout management.

> 
> /Per
> 
> ----
> Per Cederberg
> http://www.percederberg.net/
> 




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