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

List:       kde-core-devel
Subject:    Re: RFC: DBUS & KDE 4
From:       Aaron Seigo <aseigo () kde ! org>
Date:       2004-09-29 19:50:23
Message-ID: 200409291350.23416.aseigo () kde ! org
[Download RAW message or body]

On September 29, 2004 12:31, Lubos Lunak wrote:
>  if( numberOfAttempsToExplainToAaron == INT_MAX )
>  kdFatal() << "grmbl" << endl;
>  ++numberOfAttempsToExplainToAaron;

funny, i feel the same way only in the opposite direction ;-)

>  You're still missing the point. X-based in this case can mean only as
> little as s/DBUS/X11/ in your proposal.

except the systray (both ends of it, application and systray applet) should be 
available to non-X-aware apps (GUI and otherwise), and if we're using XAtoms 
or some other X11 primitive i'd rather A) pull my fingernails out or B) use a 
nice API like the Qt DBUS wrapper. i'd also like to see fewer rather than 
more X11 dependencies in KDE.

>  WMs, which act as the whole "desktop", are often a single process. And I
> can imagine all their developers being eager to bring into such fragile
> things like windowmanagers something external that could increase chances
> it will deadlock or fall flat on its face in some other way (not that it
> has to be this way, but good luck explaining that).

if blackbox or windowmaker devels can't get their head around it, so be it. i 
want something for desktop environments that works for desktop environments. 
like KDE.

>  For this reason I doubt you'd get support from these guys, and with GNOME
> I expect you to have trouble with their HIG (your proposal will come with
> some UI guidelines about how the systray should actually work, right?).

actually, no. it allows the systray host to define the user interaction 
behaviour. e.g. what happens on left click versus right click? this was 
purposefully done for exactly the reason you state above.

-- 
Aaron J. Seigo
[prev in list] [next in list] [prev in thread] [next in thread]