[Panel-devel] Re: System tray

[Georges A.K.]

What if we provide a standard way for programmers to implement the
tray, much like KNotify (for example). That way, the user can always
find the option to turn on/off the icon at the same place (instead of
searching for it in the options) and he could also be able to change
the icon (the application could also present multiple icons for
multiple states, and the user can change any one of them). And if the
application doesn't support the tray icon by default, then it's no
problem since the option will always be there. I haven't thought of
all the details yet, I'll keep thinking about it.

What do you guys think ?

Georges.

On 6/23/05, Aaron J. Seigo <aseigo at kde.org> wrote:
> 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
> 
>