Activation: b-a-s problems.
Tue, 06 Jan 2004 09:25:00 +0000
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_*
> 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, 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.
 - ie. that is if spreadsheet,LANG=baa implicitely activates another
firstname.lastname@example.org <><, Pseudo Engineer, itinerant idiot