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

List:       kde-usability
Subject:    Re: ksytray madness
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2003-10-24 15:44:31
[Download RAW message or body]

On Friday 24 of October 2003 01:58, Aaron J. Seigo wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thursday 23 October 2003 09:56, Fabrice Mous wrote:
> > Don't no if this has been discussed here before. I checked out the
> > archives
>
> no, not here, but on bugs.kde.org there has been some... when i was looking
> at various systray issues a couple months back (still have a few more to
> address for 3.2.. must. find. time.) i rolled this exact problem around in
> my mind and on paper for the better part of a week... i even coded up a few
> possibilities with varying degrees of satisfaction, but eventually conceded
> that this requires extending the XDG system tray functional significantly.

 No problem. Especially given that we actually don't really use the XDG tray 
spec.

[snip]
> 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.

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

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

_______________________________________________
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]