Re: [Sugar-devel] [FEATURE] [DESIGN] Journal Reload a new attempt
On Sun, Jan 03, 2010 at 12:56:28PM +0100, Tomeu Vizoso wrote: On Sun, Dec 6, 2009 at 03:20, Aleksey Lim alsr...@member.fsf.org wrote: (oops, wrong subject) Hi all, This post is not about particular feature but about proposed to 0.88 features that can be composited to one set. IMHO, instead of proposing (apparently out of the blue) new features that change everything including the development and deployment models, would be better to start from a stated need and then propose solutions for those. In the particular case of the Journal, we know from the 0.86 cycle that the current list widget is not the best we could use. Users are also demanding a way to select multiple items and perform operations on them. Sorting has also been requested. Do we really need to decide on the plugins thing before we solve these simpler issues? Just to make clear what I had(and have) in mind, our current development model(not core team but in wide sense) seems to me not adequate to sugar original purposes, we don't have essential and convenient way for casual doers to hack sugar, ok we can say - there is git.sl.o and you can fork any sugar project, but is it fair? There is no convenient ways to share doer's hacks, should be suggest git clone configure make install for any user who wants to test new hack? So, in my mind having such infrastructure which stimulates sugar hacks(by giving simple and convenient tool to hack and deploy them) is more important(at least doing explicit steps on that way is more important) then fixing current sugar. I had all these in my mind then I proposed plugins to sugar shell, now the full evolution of this idea is: shell-plugins - Sugar-Services - Saccharin-distribution[8] Back to discussion about what has prime priority, deployment needs or something else.. I guess answer here is simple, developers who represent deployment organisations like OLPC have more centralized focus and any casual contributor has his own view. We can make this difference smooth by creating needs.sugarlabs.org site with convenient database of deployment(and from individuals) needs but I don't see any progress on that way, I think answers like ask google don't play here. [8] http://wiki.sugarlabs.org/go/Community/Distributions/Saccharin Regards, Tomeu Some of them could be implemented in 0.88 partially, some are invasive, some not. We lost possibility to push several such features in 0.86 and we have a chance to do it once more in 0.88 release cycle. But in my mind, start to fix followed issue could be useful even in 0.88. * Reinforcing the storage metaphor in sugar (w/o loosing dairy component). Since in sugar we have only datastore(existed Journal from users POV) as a data storage(excluding external sources), we have *very* poor instruments to treat sugar object from users POV - user has to face to the whole list of objects from begging(there is not way to keep query - should look like replacement of regular directories), user even can't manually sort Journal objects. Could be fixed by: * [5] having sugar directories - bookmarks * [6] several views that could provide most useful browsing features * Having extended storage metaphor, we should save dairy component, so we can start implementing of long discussing Actions feature Could be fixed by: * [2] its only a stub, so any ideas are welcome * Make existed work flows more consistent (activities vs. objects-that-could-be-treated-as-activities, activities vs. activity bundles) Could be fixed by: * having [5], there is simple behaviour, all sugar objects are accessible from one place but from different views e.g. Hove view is just a special view that contain only activities(but could contain other objects too to speed up access) or new Actions view is a dairy view * Encourage activity developers make custom objects views, (having only one object view we either have complicated view or feature less one) Could be fixed by: * [1] These features are: [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins the name could be confusing but [1] should provide all features that are mentioned here How its invasive: * except [7], non of UI should be changed in default sugar distribution * code will be refactored to support plugins API [2] http://wiki.sugarlabs.org/go/Features/Actions this page just a stub, so who are original initiators (or have ideas) for this feature, please tweak wiki page to cover all workflows How its invasive: * the full implementation of this feature could be too invasive for UI and codebase, but we can just initiate this feature in 0.88 and collect users feedback to improve it in 0.90 [3] http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object How its invasive: * adds another confusion
Re: [Sugar-devel] [FEATURE] [DESIGN] Journal Reload a new attempt
On Tue, Jan 05, 2010 at 08:37:09AM +, Aleksey Lim wrote: On Sun, Jan 03, 2010 at 12:56:28PM +0100, Tomeu Vizoso wrote: On Sun, Dec 6, 2009 at 03:20, Aleksey Lim alsr...@member.fsf.org wrote: (oops, wrong subject) Hi all, This post is not about particular feature but about proposed to 0.88 features that can be composited to one set. IMHO, instead of proposing (apparently out of the blue) new features that change everything including the development and deployment models, would be better to start from a stated need and then propose solutions for those. In the particular case of the Journal, we know from the 0.86 cycle that the current list widget is not the best we could use. Users are also demanding a way to select multiple items and perform operations on them. Sorting has also been requested. Do we really need to decide on the plugins thing before we solve these simpler issues? Just to make clear what I had(and have) in mind, our current development model(not core team but in wide sense) seems to me not adequate to sugar original purposes, we don't have essential and convenient way for casual doers to hack sugar, ok we can say - there is git.sl.o and you can fork any sugar project, but is it fair? There is no convenient ways to share doer's hacks, should be suggest git clone configure make install for any user who wants to test new hack? So, in my mind having such infrastructure which stimulates sugar hacks(by giving simple and convenient tool to hack and deploy them) is more important(at least doing explicit steps on that way is more important) then fixing current sugar. I had all these in my mind then I proposed plugins to sugar shell, now the full evolution of this idea is: shell-plugins - Sugar-Services - Saccharin-distribution[8] Back to discussion about what has prime priority, deployment needs or something else.. I guess answer here is simple, developers who represent deployment organisations like OLPC have more centralized focus and any casual contributor has his own view. We can make this difference smooth by creating needs.sugarlabs.org site with convenient database of deployment(and from individuals) needs but I don't see any progress on that way, I think answers like ask google don't play here. btw such needs(or something else).sl.o could not only contain inforation about needs(and pyed needs) but be central point of colaboration work - schedules, involved developers to particular project(need) etc. it can leverage sugar infrastructure in wide sense. [8] http://wiki.sugarlabs.org/go/Community/Distributions/Saccharin Regards, Tomeu Some of them could be implemented in 0.88 partially, some are invasive, some not. We lost possibility to push several such features in 0.86 and we have a chance to do it once more in 0.88 release cycle. But in my mind, start to fix followed issue could be useful even in 0.88. * Reinforcing the storage metaphor in sugar (w/o loosing dairy component). Since in sugar we have only datastore(existed Journal from users POV) as a data storage(excluding external sources), we have *very* poor instruments to treat sugar object from users POV - user has to face to the whole list of objects from begging(there is not way to keep query - should look like replacement of regular directories), user even can't manually sort Journal objects. Could be fixed by: * [5] having sugar directories - bookmarks * [6] several views that could provide most useful browsing features * Having extended storage metaphor, we should save dairy component, so we can start implementing of long discussing Actions feature Could be fixed by: * [2] its only a stub, so any ideas are welcome * Make existed work flows more consistent (activities vs. objects-that-could-be-treated-as-activities, activities vs. activity bundles) Could be fixed by: * having [5], there is simple behaviour, all sugar objects are accessible from one place but from different views e.g. Hove view is just a special view that contain only activities(but could contain other objects too to speed up access) or new Actions view is a dairy view * Encourage activity developers make custom objects views, (having only one object view we either have complicated view or feature less one) Could be fixed by: * [1] These features are: [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins the name could be confusing but [1] should provide all features that are mentioned here How its invasive: * except [7], non of UI should be changed in default sugar distribution * code will be refactored to support plugins API [2] http://wiki.sugarlabs.org/go/Features/Actions this page just a stub, so who are original initiators (or have ideas)
[Sugar-devel] [FEATURE] Enhanced Gettext
Hello, Below is a proposal which I hope to get into Sugar 0.88. Note that this does not address Glucose translations. URL: http://wiki.sugarlabs.org/go/Features/Enhanced_Gettext Thanks, Sayamindu == Summary == Enhanced Gettext adds an extra search path for translation files for Sugar activities. This would allow deployments to add and update activity translations independently of the release process. == Owner == * Name: Sayamindu Dasgupta * Email: sayamindu at gmail dot com == Current status == * Targeted release: 0.88 * Last updated: Jan 3, 2010 * Percentage of completion: 10% == Detailed Description == Currently the translation process is tightly coupled with the release workflow. In order to get the latest translations for a particular activity, deployments need to either wait for the activity maintainer make a new release, or use the language pack mechanism, which is distribution specific, and an ugly hack at its best. This feature would add a sugar.gettext module, which, if used by activities, will search an alternative path (configurable via GConf) for translations before looking into the activity directory (where the translations present in the original release bundle exist. == Benefit to Sugar == * Life becomes a lot easier for deployments who rely on a small translator team to accomplish the job (smaller translation teams find it more difficult to keep up with the Sugar release cycle) * Activity maintainers do not have to worry about making new releases to incorporate newer translations. * See thread starting from http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg10663.html == Scope == * A sugar.gettext module needs to be created in sugar-toolkit (or sugar-base ??) * Activity authors need to do import sugar.gettext instead of import gettext (it may make sense to keep the import sugar.gettext in a try: block to retain backward compatibility) == UI Design == N/A == Contingency Plan == None necessary, revert to previous release behaviour. == Documentation == * See thread starting from http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg10663.html -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] suggestions for additions to platform page
vte (and Python bindings) should be added (Terminal requires this) and it should be noted explicitly that python bindings for csound are required (Pippy and other activities use these) What's the process for making such changes? or am I allowed just to use common sense for once? :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] karma repo is huge!
On 05.01.2010, at 10:17, Bernie Innocenti wrote: On Tue, 2010-01-05 at 08:11 +0545, Bryan Berry wrote: Is there a way to remove select files from the index that are no longer in the working tree? I never used it, but try git-filter-branch should do the job: git filter-branch --tree-filter ´rm filename´ HEAD It's very powerful, read the man page for more info. NOTE WELL: removing one file in the middle of the history is guaranteed to alter the sha1's of all the subsequent commits. This happens because of git's fundamental design, and can be seen as a security feature to prevent people from tampering with the history. On a side note, this hugeness when dealing with binary files in git is why etoys switched back to svn for binary content, only the textual stuff remains in git. Git is awesome for versioning code, but it's way less efficient with binaries. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] suggestions for additions to platform page
On Tue, Jan 5, 2010 at 11:54, Daniel Drake d...@laptop.org wrote: vte (and Python bindings) should be added (Terminal requires this) and it should be noted explicitly that python bindings for csound are required (Pippy and other activities use these) What's the process for making such changes? or am I allowed just to use common sense for once? :) The process is having some discussion such as what we are having now. I'm ok with these changes. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] suggestions for additions to platform page
On Tue, Jan 05, 2010 at 05:32:44PM +0100, Tomeu Vizoso wrote: On Tue, Jan 5, 2010 at 11:54, Daniel Drake d...@laptop.org wrote: vte (and Python bindings) should be added (Terminal requires this) and it should be noted explicitly that python bindings for csound are required (Pippy and other activities use these) What's the process for making such changes? or am I allowed just to use common sense for once? :) The process is having some discussion such as what we are having now. I'm ok with these changes. btw, during creating initial SP page for 0.84, such dependencies were included by default since fructose is part of sucrose thus SP, but anyway having explicit entries makes more sense. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [POLL] collab.sugarlabs.org
Hi all, Background: Step in issue, sugar is not unique here, thats the problem for other FOSS projects as well. But sugar has it's own specific nature - sugar stimulates(at least should) doing not just using, our audience could have additional layers - teachers for examples. Projects like sugar also unique because it's not only about producing final product but about improving basic things - education here. So, many people could want to participate to projects like sugar even if they are tacking part in other FOSS projects. Thus the critical thing for sugar is supporting casual participating. Participating not only by experienced developers but designers, casual doers etc. Someone could argue that it's about gaining critical mass of contributors and we didn't achieve this point yet. But what about achieving critical mass of targeted audience and even users of sugar(thanks to OLPC). For example what can do teacher somewhere in Uruguay if local needs requires some improvement in sugar, he can post en email to one of sugar related lists, ask someone on IRC but is it so friendly?(it's the same level of answers like ask google). What can do individual who needs some activity and going to pay for this activity development(during 0.86 cycle I got such request and had to bounce it since didn't have enough time). So, the question is should we have special place to treat such issues in convenient and casual developer/requester friendly manner. This collab.sugarlabs.org shouldn't be the only place to track all sugar users needs and of course any big deployment could have its own internal/external infrastructure. But having one place where every sugar users can look by default could useful. One of benefits of such site is a chance to coordinate sugar development contributions from outsiders/casual-contributors etc. BTW looks like even for core team we don't have strong coordination, there is no regular meetings etc. With collab.sl.o we at least can see what particular contributor is doing right now. Another benefit is that collab.sl.o could be right place to sustain developers by paying for implementing particular feature or having donation button like AMO does. -- This email was subjected by [POLL] to not loss this thread and since this question could be very arguable in details, lets split it to several stages, one for poll of necessity for this feature at all and next(if first stage will be accepted) for discussing details. Please attach +/- to your reply. -- +1 -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
Aleksey Lim wrote: So, the question is should we have special place to treat such issues in convenient and casual developer/requester friendly manner. -1 1. Fragmentation is bad. We should instead attempt to unify our development sites under an interface that is both friendly to novices and efficient for experts. Fragmentation prevents questions from reaching people who know the answers. 2. Without a much more detailed description of the website, it is impossible to judge whether it is worth building. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
Excellent suggestion! +1 Tomeu On Tue, Jan 5, 2010 at 17:50, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Background: Step in issue, sugar is not unique here, thats the problem for other FOSS projects as well. But sugar has it's own specific nature - sugar stimulates(at least should) doing not just using, our audience could have additional layers - teachers for examples. Projects like sugar also unique because it's not only about producing final product but about improving basic things - education here. So, many people could want to participate to projects like sugar even if they are tacking part in other FOSS projects. Thus the critical thing for sugar is supporting casual participating. Participating not only by experienced developers but designers, casual doers etc. Someone could argue that it's about gaining critical mass of contributors and we didn't achieve this point yet. But what about achieving critical mass of targeted audience and even users of sugar(thanks to OLPC). For example what can do teacher somewhere in Uruguay if local needs requires some improvement in sugar, he can post en email to one of sugar related lists, ask someone on IRC but is it so friendly?(it's the same level of answers like ask google). What can do individual who needs some activity and going to pay for this activity development(during 0.86 cycle I got such request and had to bounce it since didn't have enough time). So, the question is should we have special place to treat such issues in convenient and casual developer/requester friendly manner. This collab.sugarlabs.org shouldn't be the only place to track all sugar users needs and of course any big deployment could have its own internal/external infrastructure. But having one place where every sugar users can look by default could useful. One of benefits of such site is a chance to coordinate sugar development contributions from outsiders/casual-contributors etc. BTW looks like even for core team we don't have strong coordination, there is no regular meetings etc. With collab.sl.o we at least can see what particular contributor is doing right now. Another benefit is that collab.sl.o could be right place to sustain developers by paying for implementing particular feature or having donation button like AMO does. -- This email was subjected by [POLL] to not loss this thread and since this question could be very arguable in details, lets split it to several stages, one for poll of necessity for this feature at all and next(if first stage will be accepted) for discussing details. Please attach +/- to your reply. -- +1 -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
On Tue, Jan 5, 2010 at 17:58, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Aleksey Lim wrote: So, the question is should we have special place to treat such issues in convenient and casual developer/requester friendly manner. -1 1. Fragmentation is bad. We should instead attempt to unify our development sites under an interface that is both friendly to novices and efficient for experts. Fragmentation prevents questions from reaching people who know the answers. 2. Without a much more detailed description of the website, it is impossible to judge whether it is worth building. I thought the poll was about having a place where to track needs, not about how that site(s) would look. Regards, Tomeu -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
On Tue, Jan 5, 2010 at 11:50 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Background: Step in issue, sugar is not unique here, thats the problem for other FOSS projects as well. But sugar has it's own specific nature - sugar stimulates(at least should) doing not just using, our audience could have additional layers - teachers for examples. Projects like sugar also unique because it's not only about producing final product but about improving basic things - education here. So, many people could want to participate to projects like sugar even if they are tacking part in other FOSS projects. Thus the critical thing for sugar is supporting casual participating. Participating not only by experienced developers but designers, casual doers etc. Someone could argue that it's about gaining critical mass of contributors and we didn't achieve this point yet. But what about achieving critical mass of targeted audience and even users of sugar(thanks to OLPC). For example what can do teacher somewhere in Uruguay if local needs requires some improvement in sugar, he can post en email to one of sugar related lists, ask someone on IRC but is it so friendly?(it's the same level of answers like ask google). What can do individual who needs some activity and going to pay for this activity development(during 0.86 cycle I got such request and had to bounce it since didn't have enough time). So, the question is should we have special place to treat such issues in convenient and casual developer/requester friendly manner. This collab.sugarlabs.org shouldn't be the only place to track all sugar users needs and of course any big deployment could have its own internal/external infrastructure. But having one place where every sugar users can look by default could useful. One of benefits of such site is a chance to coordinate sugar development contributions from outsiders/casual-contributors etc. BTW looks like even for core team we don't have strong coordination, there is no regular meetings etc. With collab.sl.o we at least can see what particular contributor is doing right now. Another benefit is that collab.sl.o could be right place to sustain developers by paying for implementing particular feature or having donation button like AMO does. -- This email was subjected by [POLL] to not loss this thread and since this question could be very arguable in details, lets split it to several stages, one for poll of necessity for this feature at all and next(if first stage will be accepted) for discussing details. Please attach +/- to your reply. -- +1 -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep +1 as I am very sympathetic to you intentions. However, I worry that yet-another website might not be the solution. We have several places where we are already try to gather user needs and feedback (e.g., the Sur list, IAEP list, http://wiki.sugarlabs.org/go/Submit_Bugs/Problems, http://wiki.sugarlabs.org/go/Request_New_Features, http://wiki.sugarlabs.org/go/Sugar_Labs/Resources/Professional_services, etc.). How will this site be different/effective/unifying? -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
On Tue, Jan 05, 2010 at 11:58:17AM -0500, Benjamin M. Schwartz wrote: Aleksey Lim wrote: So, the question is should we have special place to treat such issues in convenient and casual developer/requester friendly manner. -1 1. Fragmentation is bad. We should instead attempt to unify our development sites under an interface that is both friendly to novices and efficient for experts. Fragmentation prevents questions from reaching people who know the answers. the core concern here is development sites collab.sl.o shouldn't be development site but central point there devs, users, doers, educators meet. Thus it shouldn't dublicate sites like wiki/track/etc. 2. Without a much more detailed description of the website, it is impossible to judge whether it is worth building. thats right, but the 1st(start) question is do we really need such place and then think about creating/reorginize-existed sites. --Ben -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
On Tue, Jan 5, 2010 at 18:05, Walter Bender walter.ben...@gmail.com wrote: On Tue, Jan 5, 2010 at 11:50 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Background: Step in issue, sugar is not unique here, thats the problem for other FOSS projects as well. But sugar has it's own specific nature - sugar stimulates(at least should) doing not just using, our audience could have additional layers - teachers for examples. Projects like sugar also unique because it's not only about producing final product but about improving basic things - education here. So, many people could want to participate to projects like sugar even if they are tacking part in other FOSS projects. Thus the critical thing for sugar is supporting casual participating. Participating not only by experienced developers but designers, casual doers etc. Someone could argue that it's about gaining critical mass of contributors and we didn't achieve this point yet. But what about achieving critical mass of targeted audience and even users of sugar(thanks to OLPC). For example what can do teacher somewhere in Uruguay if local needs requires some improvement in sugar, he can post en email to one of sugar related lists, ask someone on IRC but is it so friendly?(it's the same level of answers like ask google). What can do individual who needs some activity and going to pay for this activity development(during 0.86 cycle I got such request and had to bounce it since didn't have enough time). So, the question is should we have special place to treat such issues in convenient and casual developer/requester friendly manner. This collab.sugarlabs.org shouldn't be the only place to track all sugar users needs and of course any big deployment could have its own internal/external infrastructure. But having one place where every sugar users can look by default could useful. One of benefits of such site is a chance to coordinate sugar development contributions from outsiders/casual-contributors etc. BTW looks like even for core team we don't have strong coordination, there is no regular meetings etc. With collab.sl.o we at least can see what particular contributor is doing right now. Another benefit is that collab.sl.o could be right place to sustain developers by paying for implementing particular feature or having donation button like AMO does. -- This email was subjected by [POLL] to not loss this thread and since this question could be very arguable in details, lets split it to several stages, one for poll of necessity for this feature at all and next(if first stage will be accepted) for discussing details. Please attach +/- to your reply. -- +1 -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep +1 as I am very sympathetic to you intentions. However, I worry that yet-another website might not be the solution. We have several places where we are already try to gather user needs and feedback (e.g., the Sur list, IAEP list, http://wiki.sugarlabs.org/go/Submit_Bugs/Problems, http://wiki.sugarlabs.org/go/Request_New_Features, http://wiki.sugarlabs.org/go/Sugar_Labs/Resources/Professional_services, etc.). How will this site be different/effective/unifying? I personally like what Greg Smith did back at OLPC: http://wiki.laptop.org/go/Feature_requests Regards, Tomeu -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep -- «Sugar Labs is anyone who participates in improving and using Sugar. What Sugar Labs does is determined by the participants.» - David Farning ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
Aleksey Lim wrote: collab.sl.o shouldn't be development site but central point there devs, users, doers, educators meet. Thus it shouldn't dublicate sites like wiki/track/etc. What do you mean by meet? Are you proposing to run a forum? (We already have http://en.forum.laptop.org/) --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
On Tue, Jan 05, 2010 at 12:16:29PM -0500, Benjamin M. Schwartz wrote: Aleksey Lim wrote: collab.sl.o shouldn't be development site but central point there devs, users, doers, educators meet. Thus it shouldn't dublicate sites like wiki/track/etc. What do you mean by meet? Are you proposing to run a forum? (We already have http://en.forum.laptop.org/) to track what needs present, theirs status, involved developers etc so, more special and formal UI in comparing with forums or wiki like project managment software but more oriented to sugar nature - casual participating -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Enhanced Gettext
Sayamindu Dasgupta wrote: This feature would add a sugar.gettext module, which, if used by activities, will search an alternative path (configurable via GConf) for translations before looking into the activity directory (where the translations present in the original release bundle exist. Can't we do this with unmodified gettext by setting the LOCALEDIR envvar? --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
On Tue, Jan 05, 2010 at 12:05:31PM -0500, Walter Bender wrote: On Tue, Jan 5, 2010 at 11:50 AM, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, Background: Step in issue, sugar is not unique here, thats the problem for other FOSS projects as well. But sugar has it's own specific nature - sugar stimulates(at least should) doing not just using, our audience could have additional layers - teachers for examples. Projects like sugar also unique because it's not only about producing final product but about improving basic things - education here. So, many people could want to participate to projects like sugar even if they are tacking part in other FOSS projects. Thus the critical thing for sugar is supporting casual participating. Participating not only by experienced developers but designers, casual doers etc. Someone could argue that it's about gaining critical mass of contributors and we didn't achieve this point yet. But what about achieving critical mass of targeted audience and even users of sugar(thanks to OLPC). For example what can do teacher somewhere in Uruguay if local needs requires some improvement in sugar, he can post en email to one of sugar related lists, ask someone on IRC but is it so friendly?(it's the same level of answers like ask google). What can do individual who needs some activity and going to pay for this activity development(during 0.86 cycle I got such request and had to bounce it since didn't have enough time). So, the question is should we have special place to treat such issues in convenient and casual developer/requester friendly manner. This collab.sugarlabs.org shouldn't be the only place to track all sugar users needs and of course any big deployment could have its own internal/external infrastructure. But having one place where every sugar users can look by default could useful. One of benefits of such site is a chance to coordinate sugar development contributions from outsiders/casual-contributors etc. BTW looks like even for core team we don't have strong coordination, there is no regular meetings etc. With collab.sl.o we at least can see what particular contributor is doing right now. Another benefit is that collab.sl.o could be right place to sustain developers by paying for implementing particular feature or having donation button like AMO does. -- This email was subjected by [POLL] to not loss this thread and since this question could be very arguable in details, lets split it to several stages, one for poll of necessity for this feature at all and next(if first stage will be accepted) for discussing details. Please attach +/- to your reply. -- +1 -- Aleksey ___ IAEP -- It's An Education Project (not a laptop project!) i...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/iaep +1 as I am very sympathetic to you intentions. However, I worry that yet-another website might not be the solution. We have several places where we are already try to gather user needs and feedback (e.g., the Sur list, IAEP list, http://wiki.sugarlabs.org/go/Submit_Bugs/Problems, http://wiki.sugarlabs.org/go/Request_New_Features, http://wiki.sugarlabs.org/go/Sugar_Labs/Resources/Professional_services, etc.). How will this site be different/effective/unifying? yeah, at the end my concern wasn't about creating new site but about issue I'm facing(and guess not only me) - tracking needs, and this issue can't be fixed effectively(but can somehow) in existed env. So, details could be task for second poll round, but maybe we need to * call for mockups(not in tech details but to see regular workflows) for collab.sl.o/reorganizing-existed-env * schedule meeting to select more reasonable scenarios * announce 2nd poll ? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Enhanced Gettext
Benjamin M. Schwartz wrote: Sayamindu Dasgupta wrote: This feature would add a sugar.gettext module, which, if used by activities, will search an alternative path (configurable via GConf) for translations before looking into the activity directory (where the translations present in the original release bundle exist. Can't we do this with unmodified gettext by setting the LOCALEDIR envvar? s/LOCALEDIR/TEXTDOMAINDIR/ --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Enhanced Gettext
On Tue, Jan 5, 2010 at 11:03 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Benjamin M. Schwartz wrote: Sayamindu Dasgupta wrote: This feature would add a sugar.gettext module, which, if used by activities, will search an alternative path (configurable via GConf) for translations before looking into the activity directory (where the translations present in the original release bundle exist. Can't we do this with unmodified gettext by setting the LOCALEDIR envvar? s/LOCALEDIR/TEXTDOMAINDIR/ Ideally it would, but I don't think all programs/libraries honour this. IIRC, this works reliably only for bash scripts. It may make sense though to export the additional directory as $TEXTDOMAINDIR so that tools which take advantage of it would be able to do so. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Enhanced Gettext
Sayamindu Dasgupta wrote: On Tue, Jan 5, 2010 at 11:03 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: Benjamin M. Schwartz wrote: Sayamindu Dasgupta wrote: This feature would add a sugar.gettext module, which, if used by activities, will search an alternative path (configurable via GConf) for translations before looking into the activity directory (where the translations present in the original release bundle exist. Can't we do this with unmodified gettext by setting the LOCALEDIR envvar? s/LOCALEDIR/TEXTDOMAINDIR/ Ideally it would, but I don't think all programs/libraries honour this. Sure. The question is whether python's gettext module respects this. If it does, we don't have to make a python sugar.gettext module, and we don't have to modify the activities. If python's gettext isn't susceptible to environment variables, we can do it using a one-line call to gettext.bindtextdomain. We might even be able to hide that call inside import sugar.activity to avoid modifying the existing activities. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Enhanced Gettext
Sayamindu Dasgupta wrote: What I'm looking for is some sort of fallback mechanism in gettext, which would look for .mo files in the custom location first, and then in the usual location (as supplied to, say bindtextdomain()) I'm inclined to provide fallback by having Sugar synthesize a new directory of symlinked .mo files, as a composite of the available translation sets according to whatever rules we decide to employ. The activity can then be pointed to this directory with a single bindtextdomain call. I like this solution because (1) it minimizes the changes needed to activities, (2) it avoids forking gettext, and (3) it leaves the very tricky translation precedence logic in Glucose, which is where I think it belongs. This is especially important due to the complex interaction with security/containerization. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release TamTam Edit-52
Activity Homepage: http://activities.sugarlabs.org/addon/4059 Sugar Platform: 0.82 - 0.86 Download Now: http://activities.sugarlabs.org/downloads/file/26541/tamtamedit-52.xo Release notes: * Add binaries for debian based distros on x86_64 Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release TamTam Jam-53
Activity Homepage: http://activities.sugarlabs.org/addon/4060 Sugar Platform: 0.82 - 0.86 Download Now: http://activities.sugarlabs.org/downloads/file/26542/tamtamjam-53.xo Release notes: * Add binaries for debian based distros on x86_64 Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] suggestions for additions to platform page
On Tue, Jan 05, 2010 at 10:54:45AM +, Daniel Drake wrote: vte (and Python bindings) should be added (Terminal requires this) and it should be noted explicitly that python bindings for csound are required (Pippy and other activities use these) IPython has been asked for [1] as well. [1] http://bugs.sugarlabs.org/ticket/1449 CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Enhanced Gettext
On Tue, Jan 05, 2010 at 12:33:31PM -0500, Benjamin M. Schwartz wrote: Can't we do this with unmodified gettext by setting the LOCALEDIR envvar? s/LOCALEDIR/TEXTDOMAINDIR/ No because the default is hardcoded in Python (so no environment variable would get used unless explicitly passed by the activity): sascha.si...@twin:~$ grep prefix /usr/lib/python2.5/gettext.py _default_localedir = os.path.join(sys.prefix, 'share', 'locale') Actually it looks like gettext.py doesn't even support multiple directories, so either the site-specific directory must contain _all_ translations (including those that are unmodified) or we need to wrap some of the gettext code: def find(domain, localedir=None, languages=None, all=0): [...] if localedir is None: localedir = _default_localedir [...] for lang in nelangs: [...] mofile = os.path.join(localedir, lang, 'LC_MESSAGES', '%s.mo' % domain) CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Enhanced Gettext
On Tue, Jan 05, 2010 at 04:05:20PM +0530, Sayamindu Dasgupta wrote: Enhanced Gettext adds an extra search path for translation files for Sugar activities. +1, this would also fix SL#622. [1] [1] http://bugs.sugarlabs.org/ticket/622 CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release TamTam Mini-52
Activity Homepage: http://activities.sugarlabs.org/addon/4061 Sugar Platform: 0.82 - 0.86 Download Now: http://activities.sugarlabs.org/downloads/file/26543/tamtammini-52.xo Release notes: * Add binaries for debian based distros on x86_64 Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Several chapters of Make Your Own Sugar Activities! ready for review, feedback
I've been working on a Floss Manual that should be a beginner's guide to creating Sugar Activities. I've got 64 page's worth (in the PDF version) written and I feel confident that I will finish this book eventually. What I have now may be good enough to criticize. It contains some pretty good code samples, some reasonable recommendations, and a fair number of screen shots. So far it covers writing a basic Activity in Python, running it with sugar-emulator, and getting the code in Git. Future chapters will include doing i18n with Pootle, distributing the Activity, doing text to speech with and without highlighting, and collaboration features. I may stick something on Activity debugging techniques in somewhere too. Other stuff that *should* be included, but which I am not currently qualified to write, would include: * Developing Activities on a Mac * Creating an Activity using PyGame instead of PyGTK. * Creating the new-styled toolbars * etc., etc. If you want to check out what I have the URL is: http://en.flossmanuals.net/ActivitiesGuideSugar/Introduction Any help anyone can provide on this will be greatly appreciated. If you want to register as a writer and contribute stuff of your own or edit my stuff you have my blessing. Thanks, James Simmons ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release TamTam Synth Lab-53
Activity Homepage: http://activities.sugarlabs.org/addon/4062 Sugar Platform: 0.82 - 0.86 Download Now: http://activities.sugarlabs.org/downloads/file/26544/tamtamsynthlab-53.xo Release notes: * Add binaries for debian based distros on x86_64 Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Marketing] Linuxtag 2010
On 01/05/2010 03:10 AM, Christoph Derndorfer wrote: Hi Simon, as also mentioned over on the OLPC Germany list I have put the dates into my calendar and added myself to the wiki page. However I will only be able to confirm my attendance in April at the earliest as it very much depends on the state of things at university and work. Cheers, Christoph Thanks for the feedback! :) Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Several chapters of Make Your Own Sugar Activities! ready for review, feedback
On Tue, Jan 5, 2010 at 2:57 PM, Jim Simmons nices...@gmail.com wrote:
I've been working on a Floss Manual that should be a beginner's guide
to creating Sugar Activities. I've got 64 page's worth (in the PDF
version) written and I feel confident that I will finish this book
eventually. What I have now may be good enough to criticize. It
contains some pretty good code samples, some reasonable
recommendations, and a fair number of screen shots. So far it covers
writing a basic Activity in Python, running it with sugar-emulator,
and getting the code in Git. Future chapters will include doing i18n
with Pootle, distributing the Activity, doing text to speech with and
without highlighting, and collaboration features. I may stick
something on Activity debugging techniques in somewhere too.
Other stuff that *should* be included, but which I am not currently
qualified to write, would include:
* Developing Activities on a Mac
* Creating an Activity using PyGame instead of PyGTK.
* Creating the new-styled toolbars
* etc., etc.
If you want to check out what I have the URL is:
http://en.flossmanuals.net/ActivitiesGuideSugar/Introduction
Any help anyone can provide on this will be greatly appreciated. If
you want to register as a writer and contribute stuff of your own or
edit my stuff you have my blessing.
Jim,
This is a great start. I'll try to help out with some of the missing piece.
Re how to handle the new toolbars, I have some examples from other
programs, but I am happy to work with you on the ReadEtext example if
you want. The only thing you need are some icons to represent the
toolbar submenus. Your current activity icon will replace the
Activity toolbar; there is a standard icon for the Edit toolbar
('toolbar-edit'); likewise, for the 'View toolbar ('toolbar-view').
You'll need to decide on an icon for the Read toolbar, perhaps the
icon from the Read activity?
The trick then is to figure out which version of Sugar you are
running in order to decide which toolbars to use. I am lazy and just
catch an ImportError:
import sugar
from sugar.activity import activity
try: # 0.86+ toolbar widgets
from sugar.bundle.activitybundle import ActivityBundle
from sugar.activity.widgets import ActivityToolbarButton
from sugar.activity.widgets import StopButton
from sugar.graphics.toolbarbox import ToolbarBox
from sugar.graphics.toolbarbox import ToolbarButton
sugar86 = True
except ImportError:
sugar86 = False
pass
from sugar.graphics.toolbutton import ToolButton
from sugar.graphics.menuitem import MenuItem
from sugar.graphics.icon import Icon
later...
if sugar86 is True:
toolbar_box = ToolbarBox()
...
self.set_toolbar_box(toolbar_box)
toolbar_box.show()
else:
self.toolbox = activity.ActivityToolbox(self)
self.set_toolbox(self.toolbox)
...
self.toolbox.show()
self.toolbox.set_current_toolbar(1)
There are a few more details regarding sharing callbacks between the
toolbars, etc. Maybe checkout
http://git.sugarlabs.org/projects/visualmatch/repos/mainline/blobs/master/VisualMatchActivity.py
for an example.
-walter
Thanks,
James Simmons
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] [POLL] collab.sugarlabs.org
On Tue, Jan 05, 2010 at 06:15:46PM +0100, Tomeu Vizoso wrote: I personally like what Greg Smith did back at OLPC: http://wiki.laptop.org/go/Feature_requests does anyone know the right ml link for http://wiki.laptop.org/go/Feature_roadmap#Overview -- now it points to http://lists.laptop.org/pipermail/devel/2009-February/023079.html which is etoys related email -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Several chapters of Make Your Own Sugar Activities! ready for review, feedback
Walter,
I've used the import exception method myself. It looks like this will
be a bit more complicated than I had planned on, because it would seem
that I'd need a .86 environment to test in. I have two development
boxes at home, one running Fedora 10 (which I plan to leave alone) and
another running 11, which I could update to 12 if that would give me
.86. Unfortunately, Fedora's idea of upgrade seems to be a clean
install, which I'd like to put off. Maybe I should finish the rest of
the chapters before I try making new style toolbars.
You've given me a good start though, and I think I can figure out the
rest. I could probably figure out the PyGame stuff too. It's the
developing on a Mac topic that has me stumped.
Thanks,
James Simmons
On Tue, Jan 5, 2010 at 2:42 PM, Walter Bender walter.ben...@gmail.com wrote:
On Tue, Jan 5, 2010 at 2:57 PM, Jim Simmons nices...@gmail.com wrote:
I've been working on a Floss Manual that should be a beginner's guide
to creating Sugar Activities. I've got 64 page's worth (in the PDF
version) written and I feel confident that I will finish this book
eventually. What I have now may be good enough to criticize. It
contains some pretty good code samples, some reasonable
recommendations, and a fair number of screen shots. So far it covers
writing a basic Activity in Python, running it with sugar-emulator,
and getting the code in Git. Future chapters will include doing i18n
with Pootle, distributing the Activity, doing text to speech with and
without highlighting, and collaboration features. I may stick
something on Activity debugging techniques in somewhere too.
Other stuff that *should* be included, but which I am not currently
qualified to write, would include:
* Developing Activities on a Mac
* Creating an Activity using PyGame instead of PyGTK.
* Creating the new-styled toolbars
* etc., etc.
If you want to check out what I have the URL is:
http://en.flossmanuals.net/ActivitiesGuideSugar/Introduction
Any help anyone can provide on this will be greatly appreciated. If
you want to register as a writer and contribute stuff of your own or
edit my stuff you have my blessing.
Jim,
This is a great start. I'll try to help out with some of the missing piece.
Re how to handle the new toolbars, I have some examples from other
programs, but I am happy to work with you on the ReadEtext example if
you want. The only thing you need are some icons to represent the
toolbar submenus. Your current activity icon will replace the
Activity toolbar; there is a standard icon for the Edit toolbar
('toolbar-edit'); likewise, for the 'View toolbar ('toolbar-view').
You'll need to decide on an icon for the Read toolbar, perhaps the
icon from the Read activity?
The trick then is to figure out which version of Sugar you are
running in order to decide which toolbars to use. I am lazy and just
catch an ImportError:
import sugar
from sugar.activity import activity
try: # 0.86+ toolbar widgets
from sugar.bundle.activitybundle import ActivityBundle
from sugar.activity.widgets import ActivityToolbarButton
from sugar.activity.widgets import StopButton
from sugar.graphics.toolbarbox import ToolbarBox
from sugar.graphics.toolbarbox import ToolbarButton
sugar86 = True
except ImportError:
sugar86 = False
pass
from sugar.graphics.toolbutton import ToolButton
from sugar.graphics.menuitem import MenuItem
from sugar.graphics.icon import Icon
later...
if sugar86 is True:
toolbar_box = ToolbarBox()
...
self.set_toolbar_box(toolbar_box)
toolbar_box.show()
else:
self.toolbox = activity.ActivityToolbox(self)
self.set_toolbox(self.toolbox)
...
self.toolbox.show()
self.toolbox.set_current_toolbar(1)
There are a few more details regarding sharing callbacks between the
toolbars, etc. Maybe checkout
http://git.sugarlabs.org/projects/visualmatch/repos/mainline/blobs/master/VisualMatchActivity.py
for an example.
-walter
Thanks,
James Simmons
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Several chapters of Make Your Own Sugar Activities! ready for review, feedback
On Tue, Jan 05, 2010 at 03:20:15PM -0600, Jim Simmons wrote: I have two development boxes at home, one running Fedora 10 (which I plan to leave alone) and another running 11, which I could update to 12 if that would give me .86. Unfortunately, Fedora's idea of upgrade seems to be a clean install, which I'd like to put off. I don't know what tools there are for Fedora, but Debian has debootstrap and schroot which I'm using to install and use different versions of Debian inside chroots for Sugar development. Works quite well for me (except for #1401 [1] / #1403 [2], that is). For different distros I use KVM, but chroots are much more comfortable. PS: Thanks for the guide. I haven't read it yet, but your effort is quite appreciated. [1] http://bugs.sugarlabs.org/ticket/1401 [2] http://bugs.sugarlabs.org/ticket/1403 CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Release 9.0 ... Finally.
On Tue, Jan 05, 2010 at 11:53:57PM +0100, Bruno Coudoin wrote: After two years of work, the GCompris development team is happy to share with you the release of the version 9.0. GCompris is almost 10 years old and it needed to make some deep code restructuring. This release brings many mandatory changes to make it easier to enhance, maintain and distribute GCompris. The first major change has been driven by the Sugar community. On the XO there was a need to distribute the activities individually. Since the early days of GCompris, we had properly separated the core engine and the activities but the laters were shared in a single folder. Now each activity in GCompris have a single directory. This includes its code and its data (menu, icon, images, sounds, data set). Beside allowing per activity distribution, it is also makes it easier to contribute to GCompris, there is even an activity called pythontemplate that can be used as a starting point to create your own. The second major change has been to replace the old, unmaintained gnome-canvas toolkit by the more modern, Cairo based toolkit named goocanvas. This makes the rendering of GCompris much better, we now have an alpha channel and the antialiasing. The third change is our skin format that is now fully SVG based and uses the elements IDs. This way creating a skin can be done by editing a single file instead of 70 files. The last change is the image ratio (width versus height). In the old version we were using 800x600 (4/3) and could only do fullscreen by changing the screen resolution. Now, to accomodate newer monitors, we are using the 800x520 resolution which is wider. But GCompris playing area is not smaller because we managed to replace the big button bar to something more integrated. The full screen is done by rescaling ourself, you can even rescale GCompris in window mode. A good side effect is that GCompris can be used on big monitor and on smaller devices. Beside the major changes, there has been a lot of minor changes all around, it would take too many time to report these. At least, I have to mention: - The new graphism from Stephane Cabaraux for the canal lock and water cycle activities. - The new photo hunter activity by Marc Le Douarain - More famous paintings by Marc Levivier. To give an idea of the changes, you may want to look a an old and a new version of our clock activity: http://gcompris.net/IMG/jpg/old_clock.jpg http://gcompris.net/IMG/jpg/new_clock.jpg Great news, /me has switched to preparing new activities for ASLO. -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] New release of F11 for the XO-1 - Build11
This is the first release created with a new build system created by Daniel Drake. This new system can create builds for the XO-1 and XO-1.5. Known issues: Keyboard and mouse will not wakeup from sleep. Can be fixed by disabling power management in Sugar. Camera still does not work You can get it here http://dev.laptop.org/~smparrish/XO-1/builds/OS11 Issues can be filed @ http://dev.laptop.org/newticket Steven -- = Steven M. Parrish - gpg fingerprint: 4B6C 8357 059E B7ED 8095 0FD6 1F4B EDA0 A9A6 13C0 http://tuxbrewr.fedorapeople.org/ irc.freenode.net: Nickname: SMParrish Channels: #fedora-kde, #fedora-olpc, #fedora-edu, #sugar, #packagekit ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Release 9.0 ... Finally.
great work Bruno! On Wed, Jan 6, 2010 at 4:38 AM, Bruno Coudoin bruno.coud...@free.fr wrote: After two years of work, the GCompris development team is happy to share with you the release of the version 9.0. GCompris is almost 10 years old and it needed to make some deep code restructuring. This release brings many mandatory changes to make it easier to enhance, maintain and distribute GCompris. The first major change has been driven by the Sugar community. On the XO there was a need to distribute the activities individually. Since the early days of GCompris, we had properly separated the core engine and the activities but the laters were shared in a single folder. Now each activity in GCompris have a single directory. This includes its code and its data (menu, icon, images, sounds, data set). Beside allowing per activity distribution, it is also makes it easier to contribute to GCompris, there is even an activity called pythontemplate that can be used as a starting point to create your own. The second major change has been to replace the old, unmaintained gnome-canvas toolkit by the more modern, Cairo based toolkit named goocanvas. This makes the rendering of GCompris much better, we now have an alpha channel and the antialiasing. The third change is our skin format that is now fully SVG based and uses the elements IDs. This way creating a skin can be done by editing a single file instead of 70 files. The last change is the image ratio (width versus height). In the old version we were using 800x600 (4/3) and could only do fullscreen by changing the screen resolution. Now, to accomodate newer monitors, we are using the 800x520 resolution which is wider. But GCompris playing area is not smaller because we managed to replace the big button bar to something more integrated. The full screen is done by rescaling ourself, you can even rescale GCompris in window mode. A good side effect is that GCompris can be used on big monitor and on smaller devices. Beside the major changes, there has been a lot of minor changes all around, it would take too many time to report these. At least, I have to mention: - The new graphism from Stephane Cabaraux for the canal lock and water cycle activities. - The new photo hunter activity by Marc Le Douarain - More famous paintings by Marc Levivier. To give an idea of the changes, you may want to look a an old and a new version of our clock activity: http://gcompris.net/IMG/jpg/old_clock.jpg http://gcompris.net/IMG/jpg/new_clock.jpg -- Bruno Coudoin http://gcompris.net Free educational software for kids http://toulibre.org Logiciel Libre à Toulouse http://april.org Promouvoir et défendre le Logiciel Libre ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
