Activation: b-a-s problems.
Mon, 05 Jan 2004 18:26:33 -0500
On Mon, 2004-01-05 at 12:12, Michael Meeks wrote:
> Sure; however - this instantly removes gettext from the picture, and we
> all have to start re-writing that code in new, odd &&|| less efficient
> ways - which is not pleasant, and creates a need for things like
If gettext means a single process can only serve one language, then I
see these options:
1. The service "name" (name = full identifying information) contains
the language and we start a process per language
2. We fix gettext, perhaps with GTK support for something like a
language per toplevel window
3. For now we just dictate that you have to use the same language for
the whole session (seems more feasible in a Unicode age)
4. When feasible we can include the language in requests, as with gconf
The option I don't like is:
5. The service with name "foo" can be in language A or B depending on
where/how it was activated
I don't think option 5 works around the gettext problem, anyhow, it just
happens to work with "LANG=foo bar" if bar hasn't been launched yet.
So what I'm saying is, if we want a service named "Spreadsheet,LANG=foo"
then that's fine, but if we want a service named "Spreadsheet" with LANG
determined by the activator, that seems broken.
> Well; ultimately - this just moves the problem. It moves it from
> activation time to method invocation time (at which point the app has to
> know what context a given method is going to require), i18n is one,
> others are perhaps harder to think of: AUDIODEVICE perhaps ? and of
> course the display/screen stuff for anything with 1/2 a chance of doing
> something that causes a dialog to be thrown up.
My basic feeling is that environment variables need to lose in most
cases. AUDIODEVICE for example should just be a global
dynamically-modifiable configuration option. Language might be ideally,
though it won't ever happen due to infeasibility.
If we have a generic "unique application" facility, then that should
cover the display/screen issue.
> It's fair enough to push it to method invocation, and nice to hope that
> all services will cope with arbitrarily broard contexts. Indeed perhaps
> i18n is not so important / difficult for simple services, however this
> is one nastily problematic area that we ran into with bonobo. I forget
> if D/BUS allows/encourages the use of exceptions / user-readable return
> strings - does it ?
Yes, it does.