[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: System tray "close" dialog needs work
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2005-01-07 12:34:19
Message-ID: 200501071334.20674.l.lunak () suse ! cz
[Download RAW message or body]

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/
[prev in list] [next in list] [prev in thread] [next in thread]