[Panel-devel] System tray

[Aaron J. Seigo]

On Thursday 23 June 2005 08:45, Lubos Lunak wrote:
>  IMHO technical aspects are actually the last thing to be discussed ...
> well, or at least not the very first. It's been at least three times that I
> got various new understandings of what Aaron does (or doesn't) want to do
> with the systray.

well, i've been fairly consistent about what i've been saying. you can read my 
blogs on the matter, the page on my website on the matter and the threads on 
kde-core-devel .. i've stuck pretty close to what i've said all along.

> In short, if I finally got it right, Aaron's idea on the 
> systray UI itself is something like "the UI concept itself is fine, just
> the implementation sucks",

well, the implementation and how it is commonly (ab)used by applications suck.

> - systray icons that are much like normal panel applets, i.e. without
> associated main window (cpu monitors, mail checkers, keyboard layout
> switcher, etc.), should simply become real applets - Aaron's main gripes
> about this, if I'm not mistaken, are "applets take too much space" and "too
> difficult for the developer"

yes, they take up more space, take more time for developers (note how i'm 
always trying to make things easier for people who would like to make KDE 
better?) ... regular applets would need to communicate with the main 
application in some way, most likely DCOP, and that's yet more overhead for 
the developer. BUT all of this is ballanced against the MOST important point 
which you constantly forget to add:

	moving them out of the systray doesn't substantially fix anything

it simply moves the problem of how to handle autoadding icons/applets, or how 
to encourage proper usage of this service, etc, etc, etc...

if there was some actual tangible benefit to rearranging the problem that 
outweighed the space and developer time issues, i'd be all happy for it. but 
the fact is that rearranging the problem doesn't solve any of the issues 
inherent with this. and THAT is why i don't think it's worthwhile.

> - systray icons that are kind of minimized apps that provide additional
> information in the systray icon or are there simply not to occupy taskbar
> space should be either added as small icons normally to taskbar or to a
> separate applet that might actually pretty much resemble the current

and it's precisely the "minimized app, not much else" icons that i find to be 
the greatest abusers of the systray. 

the systray is NOT another taskbar. or at least it shouldn't be. that's not 
the bloody point of it. it should be there as a way to provide quick access 
to information and interaction with services that are otherwise not possible. 
the systray does have a function in life in a proper desktop environment, and 
it isn't to minimize shit to. look at the current systray. the PROBLEM with 
it is we have a billion icons in it, MOST of which are simply "here's a quick 
way to access the main window".

i don't know how many times i can say this before just throwing my hands up in 
the air and giving up completely on the matter. this is now probably the 4th 
or 5th forum in which i've communicated this. what part is difficult to 
understand?

>  Is there some session about Kicker/desktop/whatever scheduled for aKademy?

i've requested a BoF session there, yes.

> > a) we can do it right now. DCOP isn't good enough for this, and DBUS
> > isn't really an option at the moment either. if/when DBUS gets into KDE4
> > then we can perhaps use that.
>
>  Unless you want to allow a single element to block everything, something
> like DCOP or DBUS is not suitable because it cannot provide the state
> without having to do a roundtrip asking for the information first.

and you want the systray icons to become applets, which will almost certainly 
mean more dcop between the panel and the app, which will almost certainly 
mean the looming issue of blocking.

but yes, having truly async calls would be a bare minimum requirement for the 
IPC used here.

> > a) it's tied to X11. would be nice to allow non-X apps to easily use this
> > new service.
>
>  Maybe nice, but not necessary. Currently anything you see on the screen is
> tied to X11, because, well, it's X11 handling it all.

the issue is that there are things that run on your computer that you may well 
want to see that aren't X applications and never will be. it would also be 
nice if we could have little bits of functionality that run in the background 
without having to have any X dep whatsoever but still have a way to show up 
in the systray if that was applicable.

how many times have i gone over this before?

> > b) it requires a window to map the wm hints to
>
>  See above the part about visions not quite matching.

no kidding. =(

> > c) it still doesn't really answer needs like being able to easily query
> > the app for information such as "what's your current status?" to get info
> > for autohiding, etc. this is possibly solvable through inventive use of
> > xatoms, but it's really going to be annoying
>
>  It does answer those needs, and it does it by use of xatoms that actually
> doesn't need to be inventive at all. It's been working like this for ages,
> how do you think the taskbar gets the window icon or window caption? The
> only possibly annoying part I can see is me having to wrap this for you
> into some nicer API than direct X.

it means adding lots of new xatoms because the exact semantics we are looking 
for aren't covered. which means that the current capabilities do not cover 
our needs, which in turn means we need to come up with new solutions. so it's 
not like going the xatom route is a magic solution. if we're going to come up 
with a bunch of new API for this, it would be nice if we eventually did it 
right. or, as an expository question: why do we have dcop at all? why don't 
we just use xatoms for all our IPC needs?

and i think this is fundamentally where you and i part ways. i see this as an 
issue of IPC between the systray host and the systray using application. you 
see it as a cool way to use xatoms. as a window manager developer, this isn't 
surprising really =) 

this leads to differences in viewpoint since the xatom way makes some 
fundamental assumptions such as "window == application" which is IMHO 
demonstrably false.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/panel-devel/attachments/20050623/fea99ccf/attachment.pgp