From kde-core-devel Mon Apr 18 18:48:54 2005 From: Aaron Seigo Date: Mon, 18 Apr 2005 18:48:54 +0000 To: kde-core-devel Subject: Re: Thoughts on the systray II. Message-Id: <200504181848.54571.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=111385018909017 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart16635951.ODyA8toNri" --nextPart16635951.ODyA8toNri Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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.=20 yes, a network monitor probably belongs as an applet. though ask yourself: = WHY=20 didn't they make an applet. answer: form factor. forcing people to make=20 applets will lead to me having to add support for "applets that have a form= =20 factor more like the systray icons used to". this may make you happy, but a= ll=20 it does it put the problem somewhere else for me. but let's say we just tel= l=20 the network monitor author to get a clue and Do The Right Thing(tm) and mak= e=20 it an applet. this doesn't address kxkb: kxkb does not need to take up the full size of a panel, does it? should kxk= b=20 need to be added manually by the user or should it just "appear" when=20 multiple keyboard layouts are selected? we will end up duplicating all the= =20 features of the systray elsewhere in the panel to get the desired and most= =20 natural behaviour. and then instead of having all our "problems" localized = in=20 one little area of the panel, they'll exist everywhere one of these "systra= y=20 like" applets appears ...=20 have you ever seen that Disney cartoon the Sorcerer's Apprentice? where Mic= key=20 Mouse cuts up the possessed broom in hopes that breaking it up will stop th= e=20 problem? instead each splinter replicated the problem and he had a million= =20 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 applet= s. > 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 i= s=20 for users. saying "just add it yourself" is abandoning the user and making= =20 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 =2E. > 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 shou= ld > 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. =2E.. which is a two dimensional grid. and then there has to be a way to=20 individually move each applet .... and a way to determine which one is on t= op=20 or on the bottom ... hey, it's the systray all over again, only this time=20 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=20 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.=20 right. so let's fix it by defining it better. not "get rid of it completely= =20 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/whateve= r. > > > 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 al= l=20 work together. this is a change you are trying to promote, so it's up to yo= u=20 to do the homework if you care to see this happen. > Do you have any examples that'd be different from George's=20 > 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, th= at > > means having an IPC mechanism that doesn't require an explicit target b= ut > > 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 application= s=20 not running in the current X session to be represented. i'd like to see mor= e=20 expressiveness than just "hey, here's an icon"; i'd like to be able to know= =20 if the thing that icon represents is in a state of panic, calmness or coma = so=20 that it can be reflected in the UI... etc... > I don't think something like=20 > DCOP could work here because that way one stuck app could freeze everythi= ng > that'd want to find out some detail.=20 i didn't say DCOP, and there are reasons i didn't.=20 > 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."=20 =2D-=20 Aaron J. Seigo Society is Geometric --nextPart16635951.ODyA8toNri Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQBCZAEW1rcusafx20MRAvNrAKCqG45NWwNJtj4XTLxmwpPHSxThEACfeSc+ e+dFLsTXLYNz7o1fQT3mFfY= =/9mQ -----END PGP SIGNATURE----- --nextPart16635951.ODyA8toNri--