Activation: b-a-s problems.

[Michael Meeks]

On Fri, 2003-12-26 at 20:57, Mikael Hallendal wrote:
> > * Need to standardize .desktop format for more than menus if using
> > desktop files
> 
> Hm. Do we really want to use .desktop files for this? This is the way
> it's done in KDE, right? But what about services that has nothing to do
> with the desktop (activated through the system bus for example)? Doesn't
> really make sense to call them desktop files then.

	As I recall, the previous discussion about this concluded that a new
extension .service (or something), and a standardised '.desktop' caching
system that a) split out and collated the i18n strings and b) coalesced
the files into a single cache file (to kill the chronic seek penalty
problems of hundreds of scattered files) is a sensible solution.

	IMHO the most difficult issue with activation is getting the scope
right; it transpires the world is more ugly than most would imagine; eg.
multi-language desktops - you have to fork a new service for (the
hundreds) of different combinations of LC_ALL, LC_MESSAGES, LC_CTYPE,
LC_IJUSTMADETHISUP, LANG etc. since there is no good way to propagate
multi-language contexts / get gettext to play ball (AFAIK), worse you
have to wrestle with the daft-return value of setlocale, and/or somehow
parse the stuff yourself, and then work out what is unique.

	Then of course, you have the multi-display problems - virtually nothing
will work across multiple displays - (pwrt. session management) - and so
you have to uniquify / for multiple instances one-per-display; sounds
easy - however, canonicalising 'DISPLAY' is not. eg. in the simple case:
':0' == ':0.0' and happens a lot, much worse is 'foo.baa:0.0' ==
'foo:0.0' or even 'totally.different:0' I believe there was some
suggestion (from Mark) that having a system list of registered displays
might help ease this problem, of course the multiple-host-name-aliases /
multiple-network-interfaces issue is somewhat acutely nasty - but again,
perhaps a system bus would help here.

	I think lang/display are the worst of the environment variables, but
you can easily envisage others that cause grief eg. AUDIODEV. Our first
pass attempt to solve this was badly broken - the activating application
had to determine the scope - in fact the activated component should
really determine the scope. Also - it's worth propagating as much of the
environment from the client to the server as possible - pwrt.
LD_LIBRARY_PATH, PATH, etc.

	HTH,

		Michael.

-- 
 michael@ximian.com  <><, Pseudo Engineer, itinerant idiot