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

List:       kde-core-devel
Subject:    Re: Systray III.
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2005-05-30 10:32:46
Message-ID: 200505301232.46741.l.lunak () suse ! cz
[Download RAW message or body]

On Saturday 28 of May 2005 11:40, Aaron J. Seigo wrote:
> On Friday 27 May 2005 11:17, Lubos Lunak wrote:
> >  attached are final(?) patches for kdelibs/kdecore, kdelibs/kdeui,
> > kdebase/kicker/applets/systemtray and kdebase/kwin implementing tray
> > docking for any app, as already discussed before. I intend to commit them
> > to CVS, so if somebody sees something wrong with them, like a space not
>
> how many days do i have? i'm just building stuff with your patches now and
> may have it together by morning for testing, and i'd like some time to play
> with it all if you don't mind. i'll reply in more detail once i've done
> that.

 Well, I suppose I could wait a few days for your answer on this. But only 
because it's you :).

> > conforming to Kicker's HACKING file ;), now it's time to complain. If it
>
> heh.. yes, the kicker code in your patches is not well formatted .. =0

 Give me the proper switches for indent, and I'll fix it. I don't feel much 
like fixing every single space myself.

> > will show to be too confusing together with all KDE apps currently using
> > KSystemTray, the UI elements related to it can be disabled for 3.5.
>
> yes, i really don't see why we are targetting 3.5 with this at all.

 Well, it might be perhaps useful for some. And it's been sitting for too long 
on my disk, so I want it to go to CVS^H^H^HSVN to avoid having to update them 
for the latest HEAD again. That said, it probably really should be disabled 
for 3.5.

> >  Also, as another step in my insidious plan to destroy the evil systray,
> > attached is a patch for kicker that turns systray icons to applets (only
> > the old-style systray icons, not these). With the patch it's possible to
>
> not really interested in this going into kicker, to be honest.

 Only the applet, or also the code for automatic addition of applets in kicker 
itself? I don't think I can separate things like remembering applet positions 
out from Kicker.

>
> initial reactions:
>
> i don't like the window decoration addition. i know some people will, i
> find it annoying =) but that's ok, it's configurable and we can leave it
> off by default.

 The setting can be also set from the taskbar, or wherever (after somebody 
adds that of course).

> using the demo app, when right clicking the menu pops up nicely but but
> subsequent clicks don't cause it to go away.

 Fixed. See attachment.

> it should also keep kicker 
> from autohiding when shown, but that's something i can probably help with
> once in CVS.

 Hmm. I guess this will need the app sending messages "opening popup" and 
"popup closed" to Kicker, right?

>
> the state isn't remembered between runs of the app using the window
> decoration, but i assume that if the app wanted to use it more like a
> traditional systray icon then it would manage this on its own, correct?

 Actually the idea is that the setting of this would be preserved using the 
window-specific settings for the window (initial setting, remembering, 
forcing - whatever). Assuming that won't be too difficult for Joe User.

> and 
> if it wanted to have a systray-icon-only it would create a hidden window?

 Well, my plan here still reads "it would use a real applet". If that part of 
the plan eventually fails, I'd have to add another window flag systray-only 
or something like that. Just plain QWidget::hide() on it would also stop KWin 
from managing the window and the window would stop being visible to the 
systray etc.

> it'll also be vital to preserve the "this is an icon for this entire
> application" concept.

 Actually this is a separate issue of window grouping, which I'd like to 
tackle for KDE4 as well. Currently something as "window group" doesn't really 
exist, it's rather difficult for KWin to detect cases like two Konqueror 
window comming from one process but being two "applications" or main window 
and playlist window in media players belonging together. This needs to be 
fixed in Qt/KDE to make each logical group of windows belonging together to 
be one window group. The systray icon then simply would map to the whole 
window group, hiding them all together etc.

>
> i really don't grok the desire to have Yet Another Place To Minimize (only
> they aren't minimized) Windows To Area,

 Well, guessing from all the wishes make KMail/Konsole/Konqueror/whatever 
dockable in systray there are people who want this. Actually, thinking of 
this, in my original proposal, when I suggested splitting the current systray 
into several separate issues, one of them was only Yet Another Place to 
Minimize. Hmm. We'll see.

> but i do like how it gives more 
> control of the systray icon to the systray. yee-haw for that! =)
>
> it doesn't solve problems like wanting different size icons for the systray
> (which is why i wanted the icon to be defined by name if at all possible,
> using pixmaps as a fallback only).

 Using pixmaps is probably necessary, for cases of manually created pixmaps, 
like say KMail adding new mails count to it. The _NET_WM_ICON property allows 
several icons of various sizes, when it's read using KWin::icon() it tries to 
find the best size match and scale if needed.

 How about adding KDockHandler::setIcon( const QString& name, KInstance* inst 
= KGlobal::instance()) ? It would work a bit like KSystemTray's loadIcon(), 
except that it would try to load several sizes and set them in the property 
(ok, the multiple loading sucks a bit :( ). The setIcon( QPixmap/QImage ) 
variants could get also overloads for a QList of them, allowing to have more 
sizes.

 The variant of having a property with the icon name, taking precedence over 
_NET_WM_ICON, should be possible too.

>
> why are the mouse actions configurable for the systray icons? i mean,
> besides the fact that we _can_. is it really necessary?

 Probably because taskbar has it configurable too. Or perhaps because some 
people, like me, wouldn't want clicking on the icon to bring the window to 
the current desktop, but work like the taskbar does.

> (side note: using a 
> group box inside a tab when there are no other items isn't necessary; if
> you want the grouping behaviour of a groupbox in that case, set the frame
> to None, don't set a title and set the layout margin to 0px =)

 Funny how a UI developer can be pretty bad when it actually comes to creating 
UI, huh?

>
> ok.. those are my first thoughts ... i'll play with it some more over the
> coming days.

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

["systemtrayapplet.cpp.patch" (text/x-diff)]

--- systemtrayapplet.cpp.sav	2005-05-30 11:55:29.000000000 +0200
+++ systemtrayapplet.cpp	2005-05-30 11:56:23.000000000 +0200
@@ -53,6 +53,8 @@ CONNECTION WITH THE SOFTWARE OR THE USE 
 
 #include <X11/Xlib.h>
 
+extern Time qt_x_time;
+
 extern "C"
 {
     KDE_EXPORT KPanelApplet* init(QWidget *parent, const QString& configFile)
@@ -1090,6 +1092,7 @@ void TrayIcon::performAction( TrayAction
             KWin::setState( window, NET::TrayedHidden );
             break;
         case ShowOperationsMenu:
+            XUngrabPointer( qt_xdisplay(), qt_x_time );
             KDockHandler::requestMenu( window, QCursor::pos());
             break;
         case Lower:


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