On 06/05/2012 01:19 PM, Sascha Silbe wrote:
Simon Schampijer<si...@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'] = langpackdirI 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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
