From kde-core-devel Mon Apr 18 15:34:25 2005 From: Lubos Lunak Date: Mon, 18 Apr 2005 15:34:25 +0000 To: kde-core-devel Subject: Re: Thoughts on the systray II. Message-Id: <200504181734.25471.l.lunak () suse ! cz> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=111383850719999 On Friday 15 of April 2005 20:29, Aaron Seigo wrote: > On April 15, 2005 16:46, Lubos Lunak wrote: > > 2) converting applet-like systray apps to real applets. Aaron had some > > issues with this because of having bad nightmares about XEmbed, so this > > no, not because of XEmbed, but because the systray form factor and > ease-of-programming have real world benefits that applets will not be able > to cover as well. Really? What exactly should be the difference? With a systray app is roughly like this, if I'm mistaken: - get some template app with the Makefile.am and the stub with main() - use KSystemTray to provide the necessary info and the contents of the systray icon - make install - add the systray icon by finding it in the K-Menu I'm talking about applet-like systray icons now of course, the ones like kxkb, docked cpu/network/whatever indicators and so on, not things like KMail's or KArm's systray icon. Now, what's should be the big difference compared to something like: - get some template with the Makefile.am - use KPanelApplet or KSimplePanelApplet to provide the necessary info (roughly the same info like above I'd say) and the contents of the applet - make install - add the applet by finding in the the kicker RMB menu 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. Don't you want the applet anymore? Remove it and be done. Do you want a systray icon? Run the app. Don't you want it anymore? Remove it. Doesn't work? Well, perhaps you need to confirm that you really want to get rid of it completely and that you haven't got just momentarily bored by it. Or perhaps you need to find some checkbox. Or maybe something else, who knows? 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. But I think you still fail to realize what I really want. My problem is that the current systray as a whole sucks big time. Yeah, the underlying mechanism isn't that good either. But the real problem with the systray is that it's just a random inconsistent mess of everything. There are applets. It's used for notifications and status reporting. It's used for removing rarely used things from the taskbar. It's used for quick access. People don't know how to put some things there (sorry, ksystraycmd is just a hack). People get annoyed by the "really quit? ... er ... like forever?" dialogs. People get confused by the minimize vs close buttons functionality. Why should I have a keyboard layout indicator next to some icon representing a window I'm not going to touch for the next hour and some icon that will blink when something important happens? I think that if we just split the systray into separate parts for such separate uses that would be already an improvement. That's why I want to have applet-like systray icons converted to real applets. Because, face it, applet-like systray icons are just like real applets from the UI point of view, it's just the underlying implementation that's different. This may cause some problems in Kicker like having too much space taken by the applet handles, but I think those are rather problems of Kicker than applets. > > 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. 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? 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. WMs don't ask apps about details, but apps always set the info and the WM can fetch it anytime it wants. Also, since the patches move major portion of the functionality to KWin, it simply has to be X. I have no idea how other platforms handle that. -- 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/