From kde-core-devel Wed Apr 27 13:05:42 2005 From: Lubos Lunak Date: Wed, 27 Apr 2005 13:05:42 +0000 To: kde-core-devel Subject: Re: Thoughts on the systray II. Message-Id: <200504271505.42425.l.lunak () suse ! cz> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=111460714516856 On Tuesday 26 of April 2005 20:07, Aaron Seigo wrote: > On April 26, 2005 3:21, Lubos Lunak wrote: > > The idea behind the patches is that one window can be turned into one > > tray icon by setting a certain flag on it. A bit like the taskbar. > > after sitting on this for a few days to consider it, i think these patches > are the right direction. there is a lot more than can and should be done > with it, but once we have it in CVS it'll be easier to work on it with you > =) > > > So as long as > > there's one window, there's at most one icon. Standalone KMail's tray > > icon would fall into category 1), i.e. tray icon being a small > > representation for the main window, showing status; the same aKregator. > > But with the rather unusual concept of Kontact swallowing several apps > > there seems to be a problem. > > this is one reason (among a few) that i don't want to use WM hints ... i'd > really prefer to use IPC for it. but that will likely ahve to wait for > DBUS. - With IPC you can't dock any arbitrary window, at least I don't see who'd do the other side of the IPC if the app simply doesn't support it. - With IPC, at least DBUS/DCOP, either any app would be able to freeze the tray (if you go for synchronous calls), or you'd have nice asynchronous madness ahead. I don't know if it's intentional with WM hints (it probably is), but the WM never does a roundtrip to the app - the apps sets hints on their windows, the WM sends messages to the apps, but the WM cannot get stuck on anything. - Who cares what the underlying implementation is, as long as it appears to work from the outside? > the particular reason here is that there is no one-to-one relationship > between windows and systray icons. nor should there need to be. the app > should be able to create as many or as few as it wants, regardless of how > many windows it's showing. That's questionable, and I think this is about the definition of the purpose of the tray, or rather the lack thereof. As long as you don't find "it's those small icons over there" to be a reasonable description I doubt anybody could come up with a good one. One more reason I tried to group the icons by purpose in those four groups 1)-4) and want to separate them. Additionally there might be probably some confusion caused by the naming, "systray" sometimes meaning what we have now, sometimes meaning my patches. I think I should consistently use "new tray" or some completely different name for my 1) - how about calling it let's say "dock" or whatever? And for this dock or whatever I think it's perfectly fine to define it as a place where application main windows are hidden and which allows them to show some state in an unobtrusive way in a small area. Actually thinking of it there's probably no reason the taskbar shouldn't be able to do the same, so the definition might be even just "it's the place to put some windows aside". I don't see a problem with one-to-one relationship there. The other group is applets, where you have one(applet)-to-no(windows) relationship. Where/why would you want one-to-many relationship? > > > - having only one tray icon - That'd mean the KMail and aKregator parts > > would have to share the icon (and merge the tooltip text, etc.). I have > > no > > this is what we're aiming for in KDE4, based on discussions i've had with > some of the KDE PIM people on IRC. Good, problem solved. > > > filtered on the server). Making the tray icon optionally wider would > > solve this, just like it would with media players that want to show more > > buttons (I think I've seen some media player to have several tray icons > > for several buttons), but that'd complicate the layouting for tall > > Kicker, and I'd expect to see Aaron moaning about that. > > i already have to deal with this in the systemtray, and i'm actually > improving support for such (ab?)uses of the tray in the applet. so ... no, > i don't have a problem with this =) If we say that one normal icon per window is ok, so Kontact should do with one tray icon, and that media player case should be solved by an applet, then you wouldn't have to at all. That is, as long as we stay discussing how it ideally should be and don't care about how it also unfortunately has to be because of backwards compatibility etc. > > > So far I think just having one merged tray icon would be ok. What do you > > think? > > yes. this is the "Right" solution for kontact, though i'm not sure it's > going to work in every case =) I haven't found any other, besides KMix, where I think the applet+app combo should work well (but apparently I wasn't that good at searching given I didn't find the KMail+aKgregator in Kontact problem). -- Lubos Lunak KDE developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: l.lunak@suse.cz , l.lunak@kde.org Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/