From kde-core-devel Mon Feb 14 20:46:02 2005 From: "Aaron J. Seigo" Date: Mon, 14 Feb 2005 20:46:02 +0000 To: kde-core-devel Subject: Re: thoughts on the systray Message-Id: <200502141346.17842.aseigo () kde ! org> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110841412418641 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--nextPart2129717.EYSmDyalhL" --nextPart2129717.EYSmDyalhL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 14 February 2005 01:00, Lubos Lunak wrote: > A random list of things that are wrong with the systray: i would generally agree with this list. =3D) > Aaron's proposal clearly aims to fix some of these, but it might be > simpler to dump the systray idea altogether and start from scratch (which > doesn't exclude the possibility the result will resemble the original at > least somewhat). well, i think you're describing exactly what i'm suggesting. screw the curr= ent=20 systray, redefine it as an IPC driven concept and kick the offenders to the= =20 curb.. er, the taskbar. > The systray is currently used for the following things, at least the ones > I can think of: > > > 1) minimalization > - e.g. kscd, amarok, ksirc and similar - The basic intent is apparently > to save space from the taskbar. no. they are there to provide a place to easily access common actions in an= =20 omnipresent way without taking gobs of screen space. e.g. "Play" and "Stop" > - Suggested fix: Stop using the systray for this, and improve the taskba= r. > It shouldn't be a big deal to improve it so that certain taskbar entries > can be shrunk only to the icon and moved to the right. i agree with this. i even stole this idea of yours and mentioned it earlier= in=20 this very thread =3D) > - Aaron wouldn't have to bother with his spec for this. in fact, i certainly don't plan on doing so =3D) > - One more thing missing to be a good replacement for the current systray > way of doing this is the context menu, e.g. the play/stop/next etc. entri= es > for kscd/amarok. The idea is the application would simply associate the > actions with its main window, and the taskbar would provide these actions > in the popup. this requires the taskbar always being there, and falls apart rapidly when = we=20 deal with applications with multiple windows or that wish to do something=20 more interesting than offer a popup, as kontact likely will. > Since this is out-of-process, it's not possible to simply=20 > provide a QPopupMenu and give it to the taskbar (Aaron's proposal can't do > this either as far as I can say). i played for a while with an XMLUI-ish solution, but eventually settled on = the=20 concept of simply saying "pop whatever you (the app) consider your contextu= al=20 UI at point (x, y)" > - Suggested fix: Stop using the systray for it, convert them to applets. *cough*relocating the problem rather than fixing it*cough* a knotes applet, which has already been discussed in this thread, would als= o=20 suck heavily. this is not a universal hammer. > Another part is creating a spec that'd be shared with GNOME. The small > problem here is Aaron would have to be treated for his allergy to the X > character ;), like in the word XEmbed. that's like saying that a child has an allergy to hot stove elements becaus= e=20 they touched one once ;) > But I fail to see how using e.g.=20 > Python scripts instead can be considered simpler. did i ever say simpler? no. i said better, as in "won't hamstring kicker" a= nd=20 "won't make our users wonder why Open Source desktops are such crap" > In fact I'd support=20 > Havoc's opinion that many of the alleged XEmbed problems are caused by > incorrect usage of bugs (XEmbed is not exactly trivial after all). For > example, while I haven't tried it for real, after consulting some X11 docs > I don't a reason why fake transparency should be impossible with XEmbed. *sigh* i could give a flying you-know-what about transparency. i've mostly= =20 licked that with the system tray. it's horribly inefficient, but it works.= =20 composite will likely address a lot of that inefficiency.=20 the issue is with functionality. allowing the panel and the applet to talk= =20 with each other and work closely with each other. think KParts and how they= =20 leverage XMLGUI. i'm really dissapointed that i list all these _functionality_ issues and ye= t=20 you and some others keep picking on the more trivial painting issues. i dar= e=20 you to step up to the plate and consider the HARD problems i've put forward= ,=20 not the EASY ones that make it easy to make your argument stick together. > - One additional problem here is that the content of the applet window is > completely controlled by the applet. This is definitely necessary for some > applets, e.g. for the kmix applet (applet, not the systray kmix). But for > many the functionality along the lines of 'show this pixmap' and 'show > context menu', like in Aaron's proposal, is enough. I think this could be > simply handled by subclassing KPixmapPanelApplet from KPanelApplet, which > would solve Aaron's objections to applets. this isn't my objection to applets. > 3) Notification i totally agree with everything you say here in point 3. > 4) Daemons, quick access, whatever > - This is stuff like alarmd (or whatever that systray icon KOrganizer > brings all the time is called), the several systray icons from SUSE > (susewatcher, suseplugger, profile switcher), and maybe even Klipper. kalarmd, klipper, yes. i don't think this a universal truth however. kalarm= d,=20 kmail and akregator's systray icon should all be amalgated into one entity,= =20 really. this is made easier using IPC, actually =3D) > - Suggested fix: Stop using the systray for this. This stuff should be > invisible daemons, controlled by let's say their kcm modules. If there's > need for some visual representation, there can be an associated simple > kicker applet, which will using DCOP talk to the daemon. The same way the= re > can be applets for the quick access, so that people not wanting such waste > of space can still have the functionality, while those who want this simp= ly > add the applet. no. making people add applets is not something we can rationally expect. th= ink=20 about locked down configurations and new/simpler users. moreover, saying=20 "Make it an applet, talk via DCOP/DBUS" is no different than saying "make i= t=20 a systray icon, talk via DCOP/DBUS". it doesn't address an issue, it moves = it=20 to the main panel. and unless we wish to duplicate all the problems current= ly=20 contained in the small area of the systray to the larger space of the panel= =20 itself, we shouldn't go down that road. > The nice thing about this proposal is that 1), which bothers me the most, > requires only forking the taskbar applet or writing a new one, which I > intend to do unless somebody persuades me this whole thing is a bad idea, > so I can go for it and try at least 1) for real even if you don't like it. by "fork" i hope you mean "make a branch in CVS, where i'll try and coordin= ate=20 with the maintainer". i swear, if you create TaskbarV3 and make my life=20 merging all these independently created, positive improvements any harder, = i=20 will hunt you down, say "nazdar!" and beat you silly. well, i won't say=20 nazdar. but the rest... oooooooh. ;) > So, comments, flames, angry screams :) ? This is still no proper flamewar > so far, I hope this helps you to try harder ;). hahaha.. ok. hrm. let's see. your mom smells bad. and kwin's crap.=20 now, which one of those sentences got you more upset, Seli? ;) =2D-=20 Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 --nextPart2129717.EYSmDyalhL Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBCEQ4Z1rcusafx20MRAuGeAJwLM+H7C/y4L4GuONAkxRL+YgEQogCgjrGT lGFdL5fAkqCMt8+30zsRYUc= =PdPb -----END PGP SIGNATURE----- --nextPart2129717.EYSmDyalhL--