Activation: b-a-s problems.

[Michael Meeks]

On Mon, 2004-01-05 at 23:26, Havoc Pennington wrote:
>  2. We fix gettext, perhaps with GTK support for something like a 
>     language per toplevel window

	Well - it'd be nice to fix gettext of course; however you still have to
propagate a huge chunk of context around your application to get this to
work; it's a lot of work to have

	g_("Foo", gtk_window_get_i18n_context (toplevel))

	or worse all over the shop.

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

	This is essentially the decision that people complain about; although
it is clearly highly attractive; they also want the full set of LC_*
behavior.

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

	I think perhaps my confusion with the above sentence stems from the
fact that you assume a service name maps to a single unique process,
activation not being context aware at all; I was trying to discuss
whether activation being context aware was a good idea.

	Either way - it comes back down to where we started: my contention that
things like activating : "Spreadsheet,LANG=foo" we thought was generally
the wrong approach - since the activator had to determine the scope and
capabilities of the activated[1], whereas arguably the component that is
activated might want to determine that. Of course - that is all
predicated on not attaching an arbitrary amount of state to each method
invocation, and assuming that some client/context can be stored at the
server (such as per-client LANG). If so - then perhaps gedit can't cope
with per-client LANG but kedit can, both implementing the same service
name - which means you've tied the client to the server implementation
(?).

> If we have a generic "unique application" facility, then that should
> cover the display/screen issue.

	So one would hope; but that was just another prominent example of
client context being important in an activation.

	Regards,

		Michael.

[1] - ie. that is if spreadsheet,LANG=baa implicitely activates another
process.
-- 
 michael@ximian.com  <><, Pseudo Engineer, itinerant idiot