[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:       Sébastien_Laoût <slaout () linux62 ! org>
Date:       2005-01-06 0:48:06
Message-ID: 1104972486.3083.47.camel () localhost ! localdomain
[Download RAW message or body]

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.

> 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:
> 
> 	KWin::WindowInfo info = KWin::windowInfo(emb->embeddedWinId());
> 	KWin::setState(emb->embeddedWinId(), info->state() | NET::Hidden)
> 
> 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.

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...

> 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.

--
Séb.



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