[Sugar-devel] [PATCH sugar] Set the SUGAR_LANGPACKDIR env variable when reading the GConf key, part of SL #3654

[Simon Schampijer]

On 06/05/2012 01:19 PM, Sascha Silbe wrote:
> Simon Schampijer<simon at schampijer.de>  writes:
>
>
>> We can not mix static and dynamic gconf bindings in one process,                        |
>> export path as env variable so it can be read by sugar-activity
>> when launching the activity.
>
> This patch series would have been easier to review if it had been a
> single thread (with a cover letter explaining the overall design)
> instead of three patches in separate threads with nothing obvious to
> relate them to each other. Arranging patches from different repositories
> to appear as a patch series in a single thread requires some minor
> manual fiddling (adding the numbering to the subject prefix, passing the
> Message-ID of the cover letter via --in-reply-to), but IMO nothing I
> couldn't sensibly expect from a core contributor.
>
> What I'm especially missing is explanations of what the problem is that
> the patches are going to solve, how they attempt to solve it and why
> this particular approach was chosen.
>
>
> [bin/sugar-session]
>> +    # can not mix static and dynamic gconf bindings in one process,
>> +    # export path as env variable, SL #3654
>> +    langpackdir = client.get_string('/desktop/sugar/i18n/langpackdir')
>> +    if langpackdir is not None and langpackdir:
>> +        os.environ['SUGAR_LANGPACKDIR'] = langpackdir
>
> I don't really like adding code to sugar ("the Shell") to work around a
> shortcoming in the Python-based Activity Framework
> (i.e. sugar-toolkit). You're modifying API for all Activities. That most
> Activities are Python-based so far (with several notable exceptions, see
> e.g. Scratch and Etoys) doesn't really make it any better from a
> software architecture point of view, only in terms of the number of
> developers affected.
>
> Language packs are only really useful if they're picked up by _all_
> applications. No non-Sugar applications and few non-Python Activities
> are going to implement this language pack hack (be it the existing
> /desktop/sugar/i18n/langpackdir gconf entry or the new SUGAR_LANGPACKDIR
> environment variable). The right thing to do back when this feature was
> introduced would have been to approach it at the gettext layer, as the
> proof-of-concept code [1] by cscott already did. I can only assume that
> hacking Sugar was deemed easier by the people implementing the feature
> and since shipping Gnome on XO-1 isn't really practical, the limited
> scope (only Activities) was considered acceptable. However, today the
> situation is different. XO-1 is starting to reach its end-of-life and
> AFAICT most deployments ship Gnome as part of their XO-1.5+ builds.
>
> Combined with the apparent lack of use of this feature in the field
> (please contradict me if you have evidence of it being used somewhere),
> I'd rather remove it than to introduce hacks to keep it working for a
> subset of applications.

It was API that was present and I can not say for sure it has not been 
used at all. Me and Daniel discussed this quite a bit and for a released 
version we wanted to do a bugfix only. If agreement can be found we can 
remove it next release.

Simon