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

List:       kde-devel
Subject:    Re: Thoughts on the systray II.
From:       LiuCougar <liucougar () gmail ! com>
Date:       2005-04-15 21:18:13
Message-ID: 95580678050415141850f7ebef () mail ! gmail ! com
[Download RAW message or body]

What if I have an app which does not have task bar entry, but requires
a system tray icon and another kicker panel applet to ahieve more
advanced features (docking the main window of my app to the kicker,
which is an existing feature in windows XP).

It seems to me that this is not possible in the new model. Or am I wrong?

I really do not like QXEmbed class: it requires a lot of hack to work
as expected; but I have to use it in my app to implement the applet I
mentioned above...

(I can not post to kde-core-devel, so I have to post it here)

On 4/15/05, Aaron Seigo <aseigo@kde.org> wrote:
> On April 15, 2005 16:46, Lubos Lunak wrote:
> > 1) not using systray for apps minimizing, using another taskbar instead,
> > which may in the end even look a lot like a systray from the user's point
> > of view. As you'll see below this in practice mainly means replacing
> > KSystemTray and the underlying protocol. People in general seemed(?) to
> > like this part, so see below about the code.
> 
> yes, i love this. this is pretty much exactly what i'm looking for. i think we
> sould pursue this. it's probably a KDE4 thing due to the amount of changes it
> requires, though there's no reason we couldn't experiment with it in 3.5 ...
> 
> though this would mean changes to libs in 3.5, and i thought 3.5 was going to
> be an "applications" release. or are we releasing the whole platform from
> arts -> adddons again?
> 
> > 2) converting applet-like systray apps to real applets. Aaron had some
> > issues with this because of having bad nightmares about XEmbed, so this
> 
> no, not because of XEmbed, but because the systray form factor and
> ease-of-programming have real world benefits that applets will not be able to
> cover as well.
> 
> > 3) improving KNotify so that apps that now use systray just to notify about
> > things will stop using systray, will stop rolling their own notification
> > implementations, and will simply use KNotify. This seemed to be generally
> > like as well.
> 
> yes.
> 
> > 4) not using the systray for daemons, quick access and such stuff, instead
> > simply not having any GUI for those, or using applets/whatever. I'm not
> > actually sure what was the opinion on this.
> 
> depends on the daemon. for some this is the obvious step (e.g. the uiserver),
> for others it may not be. i don't think we can classify them all together
> unfortunately.
> 
> >  Ok, now the more interesting part, i.e. the one with patches. See
> > attachments with patches for kdelibs/kdecore,
> > kdebase/kicker/applets/systemtray and kdebase/kwin . They kind of implement
> > 1), it still needs quite some work and they're a bit hackish in some
> > places, but it's good enough for seeing the idea in practice. Note that you
> > need current CVS of kdecore for them to work properly.
> 
> ok, i love this idea. let's pursue it further.
> 
> --
> Aaron J. Seigo
> Society is Geometric
> 
> 
> 


-- 
"People's characters are strengthened through struggle against
difficulties; they are weakened by comfort."
- Old Chinese adage
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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