From kde-core-devel Fri Jan 07 12:34:19 2005 From: Lubos Lunak Date: Fri, 07 Jan 2005 12:34:19 +0000 To: kde-core-devel Subject: Re: System tray "close" dialog needs work Message-Id: <200501071334.20674.l.lunak () suse ! cz> X-MARC-Message: https://marc.info/?l=kde-core-devel&m=110510128201848 On Thursday 06 of January 2005 1:48, Sébastien Laoût wrote: > Le jeu 06/01/2005 à 00:19, Aaron J. Seigo a écrit : > > hrm.. .would sth like: > > > > QPoint p = systemtray->mapToGlobal(QPoint(0,0)); > > if (QApplication::desktop()->screenGeometry()->contains(p)) > > > > work? > > Yes it works. This is not going to work when the systray icon is obscured by another window (at least, maybe in more cases). > > > i wonder even if just > > > > QApplication::desktop()->screenNumber(systemtray) == -1 > > > > would work? > > I tested and it doesn't work. > I have one screen: when kicker is shown, it returns 0, and when hidden > (automatically or with an hide button), it returns... 0. > > > as for the KSystemTray object always returning true for isVisible(), the > > systemtray could do something like: If I'm not mistaken, isVisible() means "show() was called for the widget". Which means that if something from outside hides the widget, e.g. KWin by minimizing it, or the systray manager by hiding it, isVisible() will be true even if you can't actually see the thing. I'm not aware of anything in Qt that'd tell if something is really visible. > > > > KWin::WindowInfo info = KWin::windowInfo(emb->embeddedWinId()); > > KWin::setState(emb->embeddedWinId(), info->state() | NET::Hidden) Window manager state flags don't make sense on systray icons, and this specific code is actually no-op anyway. > > > > and then do the reverse on showing ... > > Yes, perhapse. > But every systray managers would have to set this. > And it would solve an already solved problem (in a more beautiful way, > of course). > > > Jason's suggestion to have the pixmap passed back via DCOP is likely the > > most foolproof method. > > Yes, I think it is. I don't see how this should help. Waldo's problem is that the screenshot given is bogus, because the whole systray area is hidden by KMail. How is a pixmap of a systray icon going to help? Besides, the app knows its own icon, so why DCOP? > > Or a way to raise kicker (quickly, and give kicker the time to redraw > itself...). > Don't know if GNOME taskbar can be raised programatically this way... Hackish, and unreliable. You don't know how much time is needed, and if there's a passive popup above or the window manager decides it doesn't care about some feeble attempts to raise the panel, you're out of luck. I think the best possible solution is: 1) check the systray icon is within the screen geometry and visible [*] , if yes, simply take the screenshot 2) if not, check the systray is managed by Kicker, and if yes, ask Kicker to apply the standard raise procedure, show the systray icon, then wait for a moment, and try step 1 once more 3) bad luck [*] Needs Xlib code - I can write that. > > > as for not working in KDE, well, the user just doesn't get > > a pretty picture when they aren't in KDE? > > Yes. > Until a solution, or a standard across desktops, is found. P.S. Where is the code for this stuff actually? Are we going to have half a dozen half-broken implementations scattered all over CVS again? -- 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/