Thoughts on the systray II.

[Lubos Lunak]

On Monday 18 of April 2005 20:48, Aaron Seigo wrote:
> On April 18, 2005 15:34, Lubos Lunak wrote:
> >  I'm talking about applet-like systray icons now of course, the ones like
> > kxkb, docked cpu/network/whatever indicators and so on,
>
> kxkb is not the same as a network monitor.
>
> yes, a network monitor probably belongs as an applet. though ask yourself:
> WHY didn't they make an applet. answer: form factor. forcing people to make
> applets will lead to me having to add support for "applets that have a form
> factor more like the systray icons used to".

 I think I could argue much better about this if I knew what form factor 
meant, at least after consulting a dictionary and Google :-/ .

> this may make you happy, but 
> all it does it put the problem somewhere else for me.

 Well, but just moving a problem around doesn't do any harm, does it? It 
doesn't solve it, but it also doesn't make things worse. What's the 
difference if you have systray problems to solve or you have applet problems 
to solve? Doing things differently means having some things simpler and some 
more complicated, that's the way it is. I don't have a silver bullet 
solution, I'm just suggesting something that I believe will improve things in 
general.

> but let's say we just 
> tell the network monitor author to get a clue and Do The Right Thing(tm)
> and make it an applet. this doesn't address kxkb:
>
> kxkb does not need to take up the full size of a panel, does it?

 Once more about Kicker's inability to have two applets at the same X 
coordinate ...

> should 
> kxkb need to be added manually by the user or should it just "appear" when
> multiple keyboard layouts are selected? we will end up duplicating all the
> features of the systray

 Not duplicating. If you have something new, it usually replaces the old 
thing.

> elsewhere in the panel to get the desired and most natural behaviour.

 I have certain doubts about a mess of icons stacked in random order in a 
specially reserved area of the Kicker being the desired and natural 
behaviour.

> and then instead of having all our "problems" localized 
> in one little area of the panel, they'll exist everywhere one of these
> "systray like" applets appears ...

 I see. So let's pile up all the broken things into one place, perhaps nobody 
will notice it's there.

>
> have you ever seen that Disney cartoon the Sorcerer's Apprentice? where
> Mickey Mouse cuts up the possessed broom in hopes that breaking it up will
> stop the problem? instead each splinter replicated the problem and he had a
> million little brooms replicating the original problem, swamping the entire
> place.

 Hmm, no, probably not. I guess when I was small I watched instead things like 
the fairy tale from Karel Capek about the dog and kitten trying to make the 
best cake in the world by putting every good thing in it. For some reason all 
those good things to eat tasted much better separately than when mixed 
together ... well, at least one didn't get awfully sick.

> >  In fact in some cases that could be even simpler. E.g. my favourite
> > Klipper quit dialog again - you don't need anything like that with
> > applets. Do you want a new kicker applet? Just add it with the menu.
>
> the more manual intervention the panel requires, the more of a failure it
> is for users. saying "just add it yourself" is abandoning the user and
> making them do what the panel ought to be doing on its own.
>
> we've been here once with the menuapplet.

 Just like with the kxkb example above, it still needs some manual 
intervention. One used to have to add the menuapplet manually because it came 
noticeably later than the standalone menubar feature, and when originally 
writing the menuapplet I still preferred not to use it myself. But now one 
activates the standalone menubar, and the applet for it comes automatically. 
What's the difference to kxkb? Why couldn't one select multiple layouts and 
have the kxkb applet come automatically as well? Sure, you could argue 
there's the question of where exactly it should appear, but the question is 
there also more or less with the kxkb systray icon.

>
> > Do you want a systray icon? Run
>
> ..
>
> > find some checkbox. Or maybe something else, who knows?
>
> this is a highly dramatic interpretation.

 Maybe, but it's true nevertheless.

> >  There may be things that might need some work this way. E.g. Kicker
> > should allow applets not to take the full panel height and two of them
> > have the same X coordinate. I intentionally say X coordinate because I
> > think there's no need to implement a grid. Just if two applets have the
> > same X and fit together within the height, put the first one above the
> > second one.
>
> ... which is a two dimensional grid. and then there has to be a way to
> individually move each applet .... and a way to determine which one is on
> top or on the bottom ...

 No, it's not. If something depends on only one coordinate, then it's not 
really a grid. I can be just like it is now. There is a way to individually 
move each applet now. The way to determine which one is on top is described 
few lines above. Would it be really that difficult to have other applets also 
move up and down like they now move to the sides when you're moving one 
applet?

> hey, it's the systray all over again, only this time spread out across the
> entire panel! ug. 

 I beg to differ.

> >  But I think you still fail to realize what I really want.
>
> i understand what you want. i'm not liking it because it makes a whole lot
> of pain for kicker and will result in a poorer experience for its users.

 Systemtray is a part of kicker, so you'll have your pain anyway. And the 
users already have a poor experience with the systray.

> > mechanism isn't that good either. But the real problem with the systray
> > is that it's just a random inconsistent mess of everything.
>
> right. so let's fix it by defining it better. not "get rid of it completely
> and move the problem everywhere else instead."

 You've never started anew because you simply decided something was broken 
beyond repair?

>
> > > > 4) not using the systray for daemons, quick access and such stuff,
> > > > instead simply not having any GUI for those, or using
> > > > applets/whatever. I'm not actually sure what was the opinion on this.
> > >
> > > depends on the daemon. for some this is the obvious step (e.g. the
> > > uiserver), for others it may not be. i don't think we can classify them
> > > all together unfortunately.
> >
> >  But we can try.
>
> fine; list every daemon that currently has systray icons and see if they
> all work together. this is a change you are trying to promote, so it's up
> to you to do the homework if you care to see this happen.
>
> >  Do you have any examples that'd be different from George's
> > KWallet and print manager case?

 It'll take some time because I don't have a single such a thing in my 
systray. But yes, I guess that's my homework.

> >
> > On Friday 15 of April 2005 23:29, Aaron Seigo wrote:
> > > On April 15, 2005 16:46, Lubos Lunak wrote:
> > > > flags, NET::Trayed and NET::TrayedHidden, first one meaning the
> > > > window
> > >
> > > thinking about this a bit more, i'm ok with using WM hints for now ....
> > > but i'd like to see this move away from being X specific so that it
> > > runs as expected elsewhere too and is therefore futureproofed. of
> > > course, that means having an IPC mechanism that doesn't require an
> > > explicit target but allows the consumer to poll for information as WM
> > > hints do.
> >
> >  It is not X-specific, strictly speaking. Why should you care how
> > KWinModule::trayedWindows() gets the list?
>
> because i'd also like to see things happen like the ability for
> applications not running in the current X session to be represented. i'd 
> like to see more expressiveness than just "hey, here's an icon"; i'd like
> to be able to know if the thing that icon represents is in a state of
> panic, calmness or coma so that it can be reflected in the UI... etc...

 And why exactly is X not good enough for that? Do you have any special 
problem e.g. in the taskbar with knowing a window demands attention, that 
it's minimized, that it's modal, or whatever? As long as it somewhat 
reasonably hidden behind some API, who cares? Not to mention I doubt we're 
going to see KDE the desktop running on something else than X that soon 
anyway.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/