systray specification...

[Aaron J. Seigo]

oops.. at some point i hit "reply" instead of "reply to list". meh.

On Friday 03 February 2006 00:48, Carsten Haitzler wrote:
> On Thu, 2 Feb 2006 23:53:08 -0700 "Aaron J. Seigo" <aseigo at kde.org> babbled:
> > On Thursday 02 February 2006 21:18, you wrote:
> > > > as for standardized menus, i'd say don't bother. i looked into it and
> > > > came up with a similar scheme as to what was suggested but then i
> > > > looked at the menus people were actually showing and decided it
> > > > wasn't worth while. just let them show their menus at a screen
> > > > coordinate and be done with it. why?
> > >
> > > i am of 2 minds with this too - it is complex and a fair bit of work,
> > > but has some standardisation benefits for like 95% of systray apps. it
> > > again allows a daemon process to have a systray with only simypl using
> > > xlib to conect to x and use it as an ipc mechanism. it needs no widget
> > > set attached to it to ave a menu at least then :)
> >
> > hm. the lack of a widget set (and therefore being able to be a bare-bones
> > app) is very enticing. but really only if we aren't using X11 because
> > otherwise you may as well have a toolkit around ;)
>
> i do see your point - though any other means of being a systray app will
> require advertising data and likely via some ipc socket - and in the end we
> then either reuire dbus (may as well require xlib then anyway - we are just
> substituting one fat lib for another) or come up with some other heavy
> protocol that one way or another sucks in some big library for
> communications (ICE, or one of dozens of other ipc mechanisms) - the only
> other sane way i see is putting data in files that are shared and
> opened/read. this sounds nice from barebones side of things but loses us
> network transparency of a display : ( either way - any mechanism we come up
> with that is network transparent like the rest of the display is, will end
> up being as complex as using xlib i think- unless of course you have some
> suggestion - something i haven't thought of? please braindump! :)

well, it's not so much the size / complexity issue as it is ubiquity of the 
mechanism. while apache (to pick an absurd example) certainly will never 
write to xlib and require an X connection around, it just may use dbus. the 
less absurd example is the linux kernel which already uses dbus for hardware 
events via hal. imagine if hal were able to export its own systray entry. 
nice, but not likely not possible if we require xlib.

but like i said, i'm not overly married to the concept of non-X11 IPC. the 
common case is desktop apps wanting some sort of representation in a common 
spot on the desktop. this is just one of those interesting details. and it's 
also fairly easy to move between IPC systems later once we are using IPC to 
begin with. so if we start with X11 based IPC, great. if during development 
we find error in our ways, we can easily switch course. otherwise, bully.

so, other than stating "we may want to use something other than X at some 
point for IPC" for the record, i'm cool with moving ahead with an X based 
mechanism.

> thing - if we can send geometry information that should be enouhg to pop up
> a menu or slider etc. at the right spot when needed.

i think this is the safest/sanest route to go at the moment.

> > title entries
>
> true - if menus have titles - yes. :)

they happen to in KDE's systray ;)

> good. thats positive support. i want to improve things here for everyone -
> me and every other wm and DE coder out there as well as the app authors and
> finally the end-users. unfortunately this will mena compromises along the
> way - but lets hoep we make as few as possible :)

=)

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20060203/3ceac76b/attachment.pgp