[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: ksytray madness
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2003-10-29 17:50:47
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 29 October 2003 05:04, Lubos Lunak wrote:
> > > All these tasks are really separate, but are lumped together into the
> > > "tray" because that's what Windows has always done. Then you end up
> > > with nasty hacks like in XP.
> >
> > "nasty hacks" that seem to work just fine for the majority of people who
> > use it.
>
>  They maybe seem to work, but they don't really.  I'm quite sure you'd find 
> a couple of examples in our bugs database, or just search http://
> mail.gnome.org/archives/desktop-devel-list/2003-March/thread.html for some
> examples (the long thread called Notification Area guidelines).

we were talking about XP's tray management, not ours or GNOMEs =) as for the 
thread on the GNOME list, that's the sort of stuff we would be able to do 
with a DCOP-driven systray and at least part of the reason i'm suggesting 
that route.

> > > a) Add a new EWMH hint which causes the window list/taskbar to shrink
> > > the window button to just an icon (and hide the border), then pack it
> > > to one end. Combined with the sticky flags that already exist, that
> > > allows you to have a window always accessible on any desktop - one of
> > > the primary things many apps use the system tray to do.
> >
> > so...... create a system tray in the taskbar.
> >
> > first, this is not how system tray icons work as they may not have an
> > associated window at all. so while some icons would appear in the
> > taskbar, others would then appear in the system tray, probably seemingly
> > randomly to most users. either that or else there would be icons with no
> > associated window in the taskbar. gah. that's one aspect of MacOS X i'd
> > prefer to see KDE not reimplement.
> >
> > second, this overloads the meaning of buttons in the taskbar and makes
> > the two concepts (windows and "action mini-icons) linked so that to have
> > one you have to have both and they must be right next to each other.
> > sounds like a regression to me.
>
>  Even you yourself are confused by the way systray works. Systray is
> currently used for several different things - this proposal is supposed to
> be only for the case when the app is trayed just to save space
> (kscd,ksirc).

read what i said again: because the systray doesn't work only as a place for 
icons that also have windows, we'd now have two places that these things 
appear. this is bad design and would make for a rather stupid interface. i 
understood it completely, i simply wouldn't be comfortable with the idea.

> > third, it means that each app would have to do the right dance: sticky
> > the window when closed, say that it should be shrunk in the taskbar. this
> > could be addressed by adding support for this to the various window
> > classes, but it just feels hacky.
>
>  Of course not. It would be the systray/taskbar/WM who would do it.

that doesn't decrease the hack value of it, though. it basically conflates the 
meaning of sticky hidden windows with "traditional" systray behaviour. 
overloading meanings in the UI is a path towards insanity, for even when they 
are hidden from the average user they are not hidden from the programmer 
writing the code or the advanced user... there are some things in kicker 
which are "hidden" from the user, but which as a developer i simply detest. 
systray's use of QXembed, for example ;-) of course, this eventually bleeds 
out to the end user as the illusion isn't always perfect because it's, well, 
a hack.

> > yes, some uses of systray icons are just broken and should be fixed.
> > there are broken implementations using just about every desktop service
> > available, in fact.
>
>  It would be much easier to do if we had cleared guidelines for this.
> http://
> developer.kde.org/documentation/standards/kde/style/basics/systray.html is
> apparently not enough,

because unlike the rest of KDE, the systray isn't managed by policy set in the 
libraries but relying on each app author to do the right thing. even when we 
extend the system tray guidelines, it'll remain an issue. the systray ought 
to manage itself.

> if we do have the broken cases (my personal 
> favourite is Klipper's "do you really want to start me next time?").

you mean when you quit Klipper by it's icon? yeah, this is one of those 
unfortunate and hard to avoid situations due to the interface.

> Your 
> suggestion to have always-visible/only-when-active-visible and allow the
> user to hide some of the systray icons can improve the situation. But maybe
> we can simply improve the whole concept, instead of bandaging it.

the two sentences above are orthogonal to each other =)

even when we improve the means of communication, we'll still end up with a 
list of applications that are requesting use of the system notification 
area / systray. that facility will need to decide when, where and how to 
facilitate the UI of this.

as for improving rather than bandaging, i'd really like to see us drop QXembed 
altogether save for backwards compatibility and move to a 100% DCOP-driven 
system. at this point we can make the UI look like pretty much whatever we 
want, even have multiple types of interfaces as options if we wanted.

which brings us to the question of what the DCOP interface would look like. i 
don't have time to sit down and really design that until post-3.2, but am 
looking forward to that process =)

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/n/331rcusafx20MRAthvAKCVQ1nTpaywXCt53iAHwXDtCdeODwCgp3Jz
PY9QU196ANFjs1OAvJbakRU=
=LNwZ
-----END PGP SIGNATURE-----
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]