Thoughts on the systray II.

[Aaron Seigo]

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". this may make you happy, but all 
it does it put the problem somewhere else for me. 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? 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 elsewhere in the panel to get the desired and most 
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 ... 

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.

>  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.

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

this is a highly dramatic interpretation.

>  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 ... hey, it's the systray all over again, only this time 
spread out across the entire panel! ug.

>  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.

> 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."

> > > 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?
>
> 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...

> I don't think something like 
> DCOP could work here because that way one stuck app could freeze everything
> that'd want to find out some detail. 

i didn't say DCOP, and there are reasons i didn't. 

> since the patches move major portion of the functionality to KWin, it
> simply has to be X.

lol.. "the implementation must use X because the implementation uses X." 

-- 
Aaron J. Seigo
Society is Geometric
-------------- 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/kde-core-devel/attachments/20050418/a61eda8a/attachment.sig>