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

List:       kde-usability
Subject:    Re: ksytray madness
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2003-10-24 16:31:20
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 24 October 2003 09:44, Lubos Lunak wrote:
> > but we also need to extend the icon <-> systray communication. the
> > program responsible for the systray icon needs to be able to attach some
> > metadata for the systray to use (e.g. it's in an active state), and this
> > needs to be done in such a way as to make the systray able to react in
> > real time to these changes. i'm heavily in favour of extending the
> > KSystemTray class to have methods that allow setting the state, which
> > then uses dcop to communicate with the system tray. yes, this means it
> > would be KDE specific (until DBUS becomes a reality) but doing it via X
> > atoms and the like really looks ugly. bleh.
>
>  How can you mention using XDG spec and being KDE specific at the same
> time? And I have certain doubts about DCOP making it nicer than X11.

i meant that we could add it on top of the XDG spec and implement a superset 
of it, or just sidestep it all together. 

> > we may also want to allow the systray to talk to the icons in a direct
> > fashion (something that's not so easy thanks to the QXEmbed class and raw
> > X juggling that is used for this hack we call a system tray). honestly,
> > if it was up to me and i didn't care about non-KDE systray icons i'd say
> > we dump the whole X embeding stupidity and make it a 100% DCOP interface,
> > where the systemtray owns the icons, creates the menus, etc.... all via a
> > set of DCOP calls that apps can access, transparently to them via the
> > KSystemTray class.
>
>  What exactly is that supposed to buy us, besides trading some (already
> existing) complexity for another proprietary complexity that even does not
> exist yet, and that actually sounds more complex to me?

three things: 

first, it buys us the ability to communicate much more clearly between the app 
using the systray and the systray applet itself, e.g. attaching an activity 
status to an icon that's accesable to the systray. yes, this could be 
accomplished by doing it "by hand" via X Atoms, but we could also just write 
all our widgets directly to Xlib and not use Qt/KDE widgets ;-) using DCOP 
would make this part easier to write and more KDE-like.

second, by doing everything via DCOP the systray wouldn't embed out-of-process 
icons but display them in-process. take a look at the painting issues caused 
by the current QXEmbed process, how fragile the systray is when restarted (it 
often won't show the existing systray icons in this case), etc. this is all 
due to the out-of-process embeding hacks.

third, consistency. since the icons and things like menu construction will all 
be in-process to the systray applet, the system tray can now exert much more 
control over how things work. e.g. it can put standard items in all of the 
icons' context menus.

there are some challenges, such as displaying custom icons and getting the 
results of RMB menus back to the apps but they aren't insurmountable.

- -- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/mVPZ1rcusafx20MRAvhKAJ9CtaCksQpna20y1/QTTPlDA0ppfACfSb8G
CVaQlSf5kSFBkUaKQneg8+Q=
=Ic0k
-----END PGP SIGNATURE-----
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]