l.lunak at suse.cz
Mon May 30 11:32:46 BST 2005
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
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
> > 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.
> 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
> 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
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
> ok.. those are my first thoughts ... i'll play with it some more over the
> coming days.
SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27 tel: +420 2 9654 2373
190 00 Praha 9 fax: +420 2 9654 2374
Czech Republic http://www.suse.cz/
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 670 bytes
Desc: not available
More information about the kde-core-devel