[Sugar-devel] [ASLO] Release Conozco Uruguay-12
Activity Homepage: http://activities.sugarlabs.org/addon/4199 Sugar Platform: 0.82 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28659/i_know_uruguay-12.xo Release notes: 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] rethinking your icon customization patch
This thread is about the technical solving of the issue, did we agree on
making this change, really? I am not at all convinced.
What do people think about my proposal with adding a picture/drawing per
kid that is part of the Palette then? We can see if we want to transfer
this compressed to the other users to have that available in the
neighborhood views. But we would have the same issue with the modified
icon that is proposed here.
Simon
On 06/19/2013 04:43 PM, Walter Bender wrote:
Here are some thoughts about the custom icon patch:
(1) if we prepend ~/.sugar/icons to the theme icon path, then anything
in that path will be used (as long as we flush the cache) as per
dnarvaez's comment on the patch
(2) if we have a sugar activity for selecting svg files (from the
journal and some samples) and loading the selected file as
computer-xo.svg into ~/.sugar/icons then we are done.
#1 is a two-line addition to jarabe/main.py
icons_path = os.path.join(os.path.expanduser('~'), '.sugar', 'icons')
Gtk.IconTheme.get_default().prepend_search_path(icons_path)
#2 is similar to what you already did for the cpsection, only it is a
stand-alone activity similar to xo-colors
We can use Turtle Art and other activities to generate SVGs. (The old
version of xo-colors let you edit the XO icon... with revisiting in
this context.)
We need to figure out how to flush the icon cache.
regards.
-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
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rethinking your icon customization patch
On Thursday, 20 June 2013, Simon Schampijer wrote: This thread is about the technical solving of the issue, did we agree on making this change, really? I am not at all convinced. The technical solution proposed here has pretty strong implications on the feature though. It becomes completely optional being an activity. That might affect our decision on making the change or not. We do have a problem agreeing on changes. Most of the time the outcome of these threads it's at best unclear. We can always rely on maintainers making the final decision, but it would be nice if we was able to build consensus instead. What do people think about my proposal with adding a picture/drawing per kid that is part of the Palette then? We can see if we want to transfer this compressed to the other users to have that available in the neighborhood views. But we would have the same issue with the modified icon that is proposed here. Will kids care about customising something which is hidden most of the time? -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rethinking your icon customization patch
I agree that the technical solution we have come up with to a large extent obviates the need for consensus around whether or not to implement this feature as it pushes it to the user space in the from of an activity. (Gonzalo and I have been discussing the fact that other cpsection widgets could also be moved to activities, but that is for another day. Regarding the specifics of this feature, I have not found any of the arguments that this feature is somehow going to confuse our users even remotely convincing. Three observations: (1) any change to the icon is driven by explicit user action, so no surprises there; (2) in virtually every other system or service our users encounter, there is the ability to set a personal avatar, so to argue that this is somehow going to confuse them in Sugar seems a stretch; and (3) particularly in light of the new approach, making it easier for our end users to make modifications to the system is in keeping with our overall pedagogy -- moving away from requiring root access to make changes is a good thing and while we don't want our users to inadvertently break things irreparably, there is something to be said for learning from the experience of breaking things. Bottom line, I seem to have more faith in the abilities of our users than perhaps is warranted, but I think that is aligned with our goals to encourage our users to take change. (The fact that this feature comes from one of our users says a lot.) Regarding our broken decision-making process, the problem I have is less that we don't reach consensus than that the discussions are happening very late in the process. We had, for example, had an email from our release manager months ago about the features proposed for this release. That was the time to question whether or not this feature should be accepted. To wait until now is not fair to the person, in the case, Ignacio, who has been working hard on his implementation. It is fine to give technical criticism at this point, and I think that discussion has been fruitful, but in my opinion, we really need to be more forthcoming earlier in the process about the features themselves. regards. -walter On Thu, Jun 20, 2013 at 6:16 AM, Daniel Narvaez dwnarv...@gmail.com wrote: On Thursday, 20 June 2013, Simon Schampijer wrote: This thread is about the technical solving of the issue, did we agree on making this change, really? I am not at all convinced. The technical solution proposed here has pretty strong implications on the feature though. It becomes completely optional being an activity. That might affect our decision on making the change or not. We do have a problem agreeing on changes. Most of the time the outcome of these threads it's at best unclear. We can always rely on maintainers making the final decision, but it would be nice if we was able to build consensus instead. What do people think about my proposal with adding a picture/drawing per kid that is part of the Palette then? We can see if we want to transfer this compressed to the other users to have that available in the neighborhood views. But we would have the same issue with the modified icon that is proposed here. Will kids care about customising something which is hidden most of the time? -- Daniel Narvaez ___ 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] rethinking your icon customization patch
On 06/20/2013 12:16 PM, Daniel Narvaez wrote: On Thursday, 20 June 2013, Simon Schampijer wrote: This thread is about the technical solving of the issue, did we agree on making this change, really? I am not at all convinced. The technical solution proposed here has pretty strong implications on the feature though. It becomes completely optional being an activity. That might affect our decision on making the change or not. For such a change I would like to see a design discussion first independent from the implementation. It is relatively easy to quickly implement something that sort of works, to hack something but creating a good user experience and work flow is not. There are all those little details to consider. The original question stands: do we make it easy to customize the most central icon in our UI. And there were concerns that we should not do it. As far as I understand the current proposal is to do it only locally. So it would change the XO icon in which places: The HOME/Groups/Neighborhood View for my icon? Will it change in the Frame as well? If I am sitting next to my friend and look on his screen for myself, why do my icon have the original shape? How would my icon look like in the members view of the Memorize activity when I play a game collaboratively? The color chooser in the CP uses this new icon? --- We actually made the background customizable, the shape of the circle is theoretically. The latter could be made easier imho maybe in a CP section. As well, I still think adding a photo/drawing would be a valuable addition. It is true it is not as present as the user icon change but would help to personalize. Cheers, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rethinking your icon customization patch
I still think adding a photo/drawing would be a valuable addition. This involves a lot of code rewrite.. I'm making a new activity for set XoIcon My idea is: A simple plaint for make svg icons.! 2013/6/20 Simon Schampijer si...@schampijer.de On 06/20/2013 12:16 PM, Daniel Narvaez wrote: On Thursday, 20 June 2013, Simon Schampijer wrote: This thread is about the technical solving of the issue, did we agree on making this change, really? I am not at all convinced. The technical solution proposed here has pretty strong implications on the feature though. It becomes completely optional being an activity. That might affect our decision on making the change or not. For such a change I would like to see a design discussion first independent from the implementation. It is relatively easy to quickly implement something that sort of works, to hack something but creating a good user experience and work flow is not. There are all those little details to consider. The original question stands: do we make it easy to customize the most central icon in our UI. And there were concerns that we should not do it. As far as I understand the current proposal is to do it only locally. So it would change the XO icon in which places: The HOME/Groups/Neighborhood View for my icon? Will it change in the Frame as well? If I am sitting next to my friend and look on his screen for myself, why do my icon have the original shape? How would my icon look like in the members view of the Memorize activity when I play a game collaboratively? The color chooser in the CP uses this new icon? --- We actually made the background customizable, the shape of the circle is theoretically. The latter could be made easier imho maybe in a CP section. As well, I still think adding a photo/drawing would be a valuable addition. It is true it is not as present as the user icon change but would help to personalize. Cheers, Simon __**_ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.**org Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/**listinfo/sugar-develhttp://lists.sugarlabs.org/listinfo/sugar-devel -- Ignacio Rodríguez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rethinking your icon customization patch
On Thu, Jun 20, 2013 at 7:32 AM, Simon Schampijer si...@schampijer.de wrote: On 06/20/2013 12:16 PM, Daniel Narvaez wrote: On Thursday, 20 June 2013, Simon Schampijer wrote: This thread is about the technical solving of the issue, did we agree on making this change, really? I am not at all convinced. The technical solution proposed here has pretty strong implications on the feature though. It becomes completely optional being an activity. That might affect our decision on making the change or not. For such a change I would like to see a design discussion first independent from the implementation. It is relatively easy to quickly implement something that sort of works, to hack something but creating a good user experience and work flow is not. There are all those little details to consider. The original question stands: do we make it easy to customize the most central icon in our UI. And there were concerns that we should not do it. As far as I understand the current proposal is to do it only locally. So it would change the XO icon in which places: The proposal and implementation changed the icon everywhere. The HOME/Groups/Neighborhood View for my icon? Will it change in the Frame as well? If I am sitting next to my friend and look on his screen for myself, why do my icon have the original shape? I think we want to do that as well, but it is beyond the current scope. The work from one of our GSoC students may help use stage this change down the road. We really do want to get to a point where the user's icon is personal. (In fact, this was part of the original design for the neighborhood, never implemented.) How would my icon look like in the members view of the Memorize activity when I play a game collaboratively? The color chooser in the CP uses this new icon? --- We actually made the background customizable, the shape of the circle is theoretically. The latter could be made easier imho maybe in a CP section. As well, I still think adding a photo/drawing would be a valuable addition. It is true it is not as present as the user icon change but would help to personalize. Cheers, Simon ___ 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] rethinking your icon customization patch
On 06/20/2013 01:28 PM, Walter Bender wrote: I agree that the technical solution we have come up with to a large extent obviates the need for consensus around whether or not to implement this feature as it pushes it to the user space in the from of an activity. (Gonzalo and I have been discussing the fact that other cpsection widgets could also be moved to activities, but that is for another day. Regarding the specifics of this feature, I have not found any of the arguments that this feature is somehow going to confuse our users even remotely convincing. Three observations: (1) any change to the icon is driven by explicit user action, so no surprises there; (2) in virtually every other system or service our users encounter, there is the ability to set a personal avatar, so to argue that this is somehow going to confuse them in Sugar seems a stretch; and (3) particularly in light of the new approach, making it easier for our end users to make modifications to the system is in keeping with our overall pedagogy -- moving away from requiring root access to make changes is a good thing and while we don't want our users to inadvertently break things irreparably, there is something to be said for learning from the experience of breaking things. Bottom line, I seem to have more faith in the abilities of our users than perhaps is warranted, but I think that is aligned with our goals to encourage our users to take change. (The fact that this feature comes from one of our users says a lot.) Regarding our broken decision-making process, the problem I have is less that we don't reach consensus than that the discussions are happening very late in the process. We had, for example, had an email from our release manager months ago about the features proposed for this release. That was the time to question whether or not this feature should be accepted. To wait until now is not fair to the person, in the case, Ignacio, who has been working hard on his implementation. It is fine to give technical criticism at this point, and I think that discussion has been fruitful, but in my opinion, we really need to be more forthcoming earlier in the process about the features themselves. Has that feature been accepted for 0.100? I must admit that I do not read all the mails and I might have overseen this one, at least I first saw [1] when the patch was submitted. Has there been a mail to ask for feedback for the design? The process tries to make room for that early feedback, especially for Features that changes UI or work flow. Simon [1] http://wiki.sugarlabs.org/go/Features/Icon_Change [2] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rethinking your icon customization patch
On 20 June 2013 13:28, Walter Bender walter.ben...@gmail.com wrote: Regarding our broken decision-making process, the problem I have is less that we don't reach consensus than that the discussions are happening very late in the process. We had, for example, had an email from our release manager months ago about the features proposed for this release. That was the time to question whether or not this feature should be accepted. To wait until now is not fair to the person, in the case, Ignacio, who has been working hard on his implementation. It is fine to give technical criticism at this point, and I think that discussion has been fruitful, but in my opinion, we really need to be more forthcoming earlier in the process about the features themselves. I agree about this. I was about to bring it up a couple of times myself but I didn't want to kill the discussion. Fortunately that's a problem with the process and it can be more easily addressed than the general consensus issue.The next time we have a feature discussion we should make sure it's clear that once a decision to include a feature has been made, it has been made... This is probably release manager responsibility, bad me :) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rethinking your icon customization patch
Yes it was accepted. You can see the list of accepted features here https://github.com/sugarlabs/roadmap/issues?milestone=1state=open On 20 June 2013 13:40, Simon Schampijer si...@schampijer.de wrote: On 06/20/2013 01:28 PM, Walter Bender wrote: I agree that the technical solution we have come up with to a large extent obviates the need for consensus around whether or not to implement this feature as it pushes it to the user space in the from of an activity. (Gonzalo and I have been discussing the fact that other cpsection widgets could also be moved to activities, but that is for another day. Regarding the specifics of this feature, I have not found any of the arguments that this feature is somehow going to confuse our users even remotely convincing. Three observations: (1) any change to the icon is driven by explicit user action, so no surprises there; (2) in virtually every other system or service our users encounter, there is the ability to set a personal avatar, so to argue that this is somehow going to confuse them in Sugar seems a stretch; and (3) particularly in light of the new approach, making it easier for our end users to make modifications to the system is in keeping with our overall pedagogy -- moving away from requiring root access to make changes is a good thing and while we don't want our users to inadvertently break things irreparably, there is something to be said for learning from the experience of breaking things. Bottom line, I seem to have more faith in the abilities of our users than perhaps is warranted, but I think that is aligned with our goals to encourage our users to take change. (The fact that this feature comes from one of our users says a lot.) Regarding our broken decision-making process, the problem I have is less that we don't reach consensus than that the discussions are happening very late in the process. We had, for example, had an email from our release manager months ago about the features proposed for this release. That was the time to question whether or not this feature should be accepted. To wait until now is not fair to the person, in the case, Ignacio, who has been working hard on his implementation. It is fine to give technical criticism at this point, and I think that discussion has been fruitful, but in my opinion, we really need to be more forthcoming earlier in the process about the features themselves. Has that feature been accepted for 0.100? I must admit that I do not read all the mails and I might have overseen this one, at least I first saw [1] when the patch was submitted. Has there been a mail to ask for feedback for the design? The process tries to make room for that early feedback, especially for Features that changes UI or work flow. Simon [1] http://wiki.sugarlabs.org/go/**Features/Icon_Changehttp://wiki.sugarlabs.org/go/Features/Icon_Change [2] http://wiki.sugarlabs.org/go/**Features/Policy#Propose_a_** feature_for_addition_into_the_**release_cyclehttp://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rethinking your icon customization patch
:) https://github.com/sugarlabs/roadmap/issues/7 Don't likes this feature. But I will do everything possible to work and be approved by the community! 2013/6/20 Daniel Narvaez dwnarv...@gmail.com Yes it was accepted. You can see the list of accepted features here https://github.com/sugarlabs/roadmap/issues?milestone=1state=open On 20 June 2013 13:40, Simon Schampijer si...@schampijer.de wrote: On 06/20/2013 01:28 PM, Walter Bender wrote: I agree that the technical solution we have come up with to a large extent obviates the need for consensus around whether or not to implement this feature as it pushes it to the user space in the from of an activity. (Gonzalo and I have been discussing the fact that other cpsection widgets could also be moved to activities, but that is for another day. Regarding the specifics of this feature, I have not found any of the arguments that this feature is somehow going to confuse our users even remotely convincing. Three observations: (1) any change to the icon is driven by explicit user action, so no surprises there; (2) in virtually every other system or service our users encounter, there is the ability to set a personal avatar, so to argue that this is somehow going to confuse them in Sugar seems a stretch; and (3) particularly in light of the new approach, making it easier for our end users to make modifications to the system is in keeping with our overall pedagogy -- moving away from requiring root access to make changes is a good thing and while we don't want our users to inadvertently break things irreparably, there is something to be said for learning from the experience of breaking things. Bottom line, I seem to have more faith in the abilities of our users than perhaps is warranted, but I think that is aligned with our goals to encourage our users to take change. (The fact that this feature comes from one of our users says a lot.) Regarding our broken decision-making process, the problem I have is less that we don't reach consensus than that the discussions are happening very late in the process. We had, for example, had an email from our release manager months ago about the features proposed for this release. That was the time to question whether or not this feature should be accepted. To wait until now is not fair to the person, in the case, Ignacio, who has been working hard on his implementation. It is fine to give technical criticism at this point, and I think that discussion has been fruitful, but in my opinion, we really need to be more forthcoming earlier in the process about the features themselves. Has that feature been accepted for 0.100? I must admit that I do not read all the mails and I might have overseen this one, at least I first saw [1] when the patch was submitted. Has there been a mail to ask for feedback for the design? The process tries to make room for that early feedback, especially for Features that changes UI or work flow. Simon [1] http://wiki.sugarlabs.org/go/**Features/Icon_Changehttp://wiki.sugarlabs.org/go/Features/Icon_Change [2] http://wiki.sugarlabs.org/go/**Features/Policy#Propose_a_** feature_for_addition_into_the_**release_cyclehttp://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Ignacio Rodríguez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rethinking your icon customization patch
On 20 June 2013 13:32, Simon Schampijer si...@schampijer.de wrote: For such a change I would like to see a design discussion first independent from the implementation. It is relatively easy to quickly implement something that sort of works, to hack something but creating a good user experience and work flow is not. There are all those little details to consider. I guess I don't consider this such an important change. It's not about the design only, I wouldn't think it's worth for example to hook it up with the neighborhood view, we have more fundamental issues to tackle :) I'm all for design driven development, but sometimes I think it's fine to throw in small interesting features that have not been fully thought out and just see where things go... Especially if they are implemented as activities or extensions. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rethinking your icon customization patch
On 20 June 2013 13:40, Simon Schampijer si...@schampijer.de wrote: Has there been a mail to ask for feedback for the design? Not that I can find. Though I'd say the features discussion should be a chance for the design team to take a look to the proposals and give input if they are aspects they are concerned about. (I know that at least Manuel was happy with this specific feature). ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Orphaned 0.100 features
Hello, I think two of the features on the 0.100 roadmap are in practice orphaned. There has been disagreement on how the patches should be submitted and reviewed, which blocked development. Then despite trying several times I have not been able to get any feedback from the owner about his plans. Enhanced support for 3G modems https://github.com/sugarlabs/roadmap/issues/2 Multiple selection in the Journal https://github.com/sugarlabs/roadmap/issues/1 Is anyone interested to pick these up? I think we need a new owner here, otherwise the features should be punted from 0.100. -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] rethinking your icon customization patch
There seem to be agreement that the ability to override theme icons makes sense as a backend, not user visible feature. Since that's the only dependency for Walter proposal I think we could probably just punt the icon change feature from 0.100. In the proposed implementation it's not a feature of core anymore. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Orphaned 0.100 features
On Thu, Jun 20, 2013 at 9:01 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I think two of the features on the 0.100 roadmap are in practice orphaned. There has been disagreement on how the patches should be submitted and reviewed, which blocked development. Then despite trying several times I have not been able to get any feedback from the owner about his plans. Enhanced support for 3G modems https://github.com/sugarlabs/roadmap/issues/2 Multiple selection in the Journal https://github.com/sugarlabs/roadmap/issues/1 Working on cleaning this one up today :) -walter Is anyone interested to pick these up? I think we need a new owner here, otherwise the features should be punted from 0.100. -- Daniel Narvaez ___ 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] rethinking your icon customization patch
If we can at least land the patch to extend the icon search path in the theme to include env.get_profile_path()/icons then we have the opportunity to user-space mods. Without that, it would be difficult for our users, w/o root access, to make changes. -walter On Thu, Jun 20, 2013 at 9:08 AM, Daniel Narvaez dwnarv...@gmail.com wrote: There seem to be agreement that the ability to override theme icons makes sense as a backend, not user visible feature. Since that's the only dependency for Walter proposal I think we could probably just punt the icon change feature from 0.100. In the proposed implementation it's not a feature of core anymore. -- 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] rethinking your icon customization patch
Yeah that's what I mean with the backend ability to override theme icons. On Thursday, 20 June 2013, Walter Bender wrote: If we can at least land the patch to extend the icon search path in the theme to include env.get_profile_path()/icons then we have the opportunity to user-space mods. Without that, it would be difficult for our users, w/o root access, to make changes. -walter On Thu, Jun 20, 2013 at 9:08 AM, Daniel Narvaez dwnarv...@gmail.comjavascript:; wrote: There seem to be agreement that the ability to override theme icons makes sense as a backend, not user visible feature. Since that's the only dependency for Walter proposal I think we could probably just punt the icon change feature from 0.100. In the proposed implementation it's not a feature of core anymore. -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Orphaned 0.100 features
Hello, I think I can go for enhanced support for 3G modems. Is this possible for a newcomer? On Thu, Jun 20, 2013 at 3:13 PM, Walter Bender walter.ben...@gmail.comwrote: On Thu, Jun 20, 2013 at 9:01 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I think two of the features on the 0.100 roadmap are in practice orphaned. There has been disagreement on how the patches should be submitted and reviewed, which blocked development. Then despite trying several times I have not been able to get any feedback from the owner about his plans. Enhanced support for 3G modems https://github.com/sugarlabs/roadmap/issues/2 Multiple selection in the Journal https://github.com/sugarlabs/roadmap/issues/1 Working on cleaning this one up today :) -walter Is anyone interested to pick these up? I think we need a new owner here, otherwise the features should be punted from 0.100. -- Daniel Narvaez ___ 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Orphaned 0.100 features
There is certainly no preclusion to newcomers :) I don't know about the complexity of that code, the best thing is probably for you to take a look and see if you are comfortable with it. We have until the half of August to land this, so there is some time to learn. On Thursday, 20 June 2013, Miguel González wrote: Hello, I think I can go for enhanced support for 3G modems. Is this possible for a newcomer? On Thu, Jun 20, 2013 at 3:13 PM, Walter Bender walter.ben...@gmail.comwrote: On Thu, Jun 20, 2013 at 9:01 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I think two of the features on the 0.100 roadmap are in practice orphaned. There has been disagreement on how the patches should be submitted and reviewed, which blocked development. Then despite trying several times I have not been able to get any feedback from the owner about his plans. Enhanced support for 3G modems https://github.com/sugarlabs/roadmap/issues/2 Multiple selection in the Journal https://github.com/sugarlabs/roadmap/issues/1 Working on cleaning this one up today :) -walter Is anyone interested to pick these up? I think we need a new owner here, otherwise the features should be punted from 0.100. -- Daniel Narvaez ___ 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 -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Orphaned 0.100 features
Perfect! I'll share with you my progress. On Thu, Jun 20, 2013 at 6:13 PM, Daniel Narvaez dwnarv...@gmail.com wrote: There is certainly no preclusion to newcomers :) I don't know about the complexity of that code, the best thing is probably for you to take a look and see if you are comfortable with it. We have until the half of August to land this, so there is some time to learn. On Thursday, 20 June 2013, Miguel González wrote: Hello, I think I can go for enhanced support for 3G modems. Is this possible for a newcomer? On Thu, Jun 20, 2013 at 3:13 PM, Walter Bender walter.ben...@gmail.comwrote: On Thu, Jun 20, 2013 at 9:01 AM, Daniel Narvaez dwnarv...@gmail.com wrote: Hello, I think two of the features on the 0.100 roadmap are in practice orphaned. There has been disagreement on how the patches should be submitted and reviewed, which blocked development. Then despite trying several times I have not been able to get any feedback from the owner about his plans. Enhanced support for 3G modems https://github.com/sugarlabs/roadmap/issues/2 Multiple selection in the Journal https://github.com/sugarlabs/roadmap/issues/1 Working on cleaning this one up today :) -walter Is anyone interested to pick these up? I think we need a new owner here, otherwise the features should be punted from 0.100. -- Daniel Narvaez ___ 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 -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] draft language asking permission to relicense (was Re: Licensing of the javascript libraries)
It is a relatively short list: Walter Bender (wal...@sugarlabs.org) I approve Dan Williams d...@redhat.org Gary Martin garycmar...@gmail.com Christian Marc Schmidt anyth...@christianmarcschmidt.com Tomeu Vizoso tomeu.viz...@gmail.com Manuel Quinones ma...@laptop.org Eben Eliason eben.elia...@gmail.com Marco Pesenti Gritti ma...@marcopg.org Benjamin Berg ben...@sugarlabs.org Did I miss anyone? regards. -walter On Thu, Jun 20, 2013 at 2:52 PM, Tony Sebro t...@sfconservancy.org wrote: On 06/18/2013 12:19 PM, Bradley M. Kuhn wrote: Meanwhile, Conservancy can help draft an email for permission to assent. I'll coordinate with Tony on it and get back to you as soon as we can. Hi, all: Here's some draft language we can use to collect the consent of various copyright holders to the relicensing of code under the Apache license. If you give Conservancy a clear git log of people to contact, we can do the work of collecting and recording the responses of contributors. Best, -Tony Hello; You're receiving this email because you are a contributor of code and/or other copyrighted content to the Sugar Labs project. Software Freedom Conservancy is the nonprofit corporate home of Sugar Labs, and we thank you for your contribution. We're writing you ask that you grant Conservancy and Sugar Labs permission to relicense the code and associated files stored in the https://github.com/sugarlabs/sugar-artwork repository (currently licensed under LGPL v2 or later) under the Apache License 2.0 as a second license. The result would be that everything in that repository would be available for use under both the LGPL2+ and the Apache License 2.0 concurrently. By adding the Apache License as a second license, Sugar Labs would be able to reuse code from /sugar-artwork in javascript libraries under the Apache license, and include javascript libraries licensed under the Apache License inside Sugar Labs application bundles [note: feel free to suggest a stronger/more clearly-articulated rationale as a replacement. -Tony] Please indicate your permission by replying to this email with the following: - the words I approve. - your full name We'll keep your email as record of your consent. Thanks again for your contribution and your continued support of the Sugar Labs project. -- Tony Sebro, General Counsel, Software Freedom Conservancy +1-212-461-3245 x11 t...@sfconservancy.org www.sfconservancy.org -- 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] draft language asking permission to relicense (was Re: Licensing of the javascript libraries)
There might be a few more people in some of the files I've seen after making that list. I'll try to send a complete list asap. On Thursday, 20 June 2013, Walter Bender wrote: It is a relatively short list: Walter Bender (wal...@sugarlabs.org javascript:;) I approve Dan Williams d...@redhat.org javascript:; Gary Martin garycmar...@gmail.com javascript:; Christian Marc Schmidt anyth...@christianmarcschmidt.com javascript:; Tomeu Vizoso tomeu.viz...@gmail.com javascript:; Manuel Quinones ma...@laptop.org javascript:; Eben Eliason eben.elia...@gmail.com javascript:; Marco Pesenti Gritti ma...@marcopg.org javascript:; Benjamin Berg ben...@sugarlabs.org javascript:; Did I miss anyone? regards. -walter On Thu, Jun 20, 2013 at 2:52 PM, Tony Sebro t...@sfconservancy.orgjavascript:; wrote: On 06/18/2013 12:19 PM, Bradley M. Kuhn wrote: Meanwhile, Conservancy can help draft an email for permission to assent. I'll coordinate with Tony on it and get back to you as soon as we can. Hi, all: Here's some draft language we can use to collect the consent of various copyright holders to the relicensing of code under the Apache license. If you give Conservancy a clear git log of people to contact, we can do the work of collecting and recording the responses of contributors. Best, -Tony Hello; You're receiving this email because you are a contributor of code and/or other copyrighted content to the Sugar Labs project. Software Freedom Conservancy is the nonprofit corporate home of Sugar Labs, and we thank you for your contribution. We're writing you ask that you grant Conservancy and Sugar Labs permission to relicense the code and associated files stored in the https://github.com/sugarlabs/sugar-artwork repository (currently licensed under LGPL v2 or later) under the Apache License 2.0 as a second license. The result would be that everything in that repository would be available for use under both the LGPL2+ and the Apache License 2.0 concurrently. By adding the Apache License as a second license, Sugar Labs would be able to reuse code from /sugar-artwork in javascript libraries under the Apache license, and include javascript libraries licensed under the Apache License inside Sugar Labs application bundles [note: feel free to suggest a stronger/more clearly-articulated rationale as a replacement. -Tony] Please indicate your permission by replying to this email with the following: - the words I approve. - your full name We'll keep your email as record of your consent. Thanks again for your contribution and your continued support of the Sugar Labs project. -- Tony Sebro, General Counsel, Software Freedom Conservancy +1-212-461-3245 x11 t...@sfconservancy.org javascript:; www.sfconservancy.org -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Daniel Narvaez ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] draft language asking permission to relicense (was Re: Licensing of the javascript libraries)
Sounds good, but please CC Daniel and me so that they have some sugar contact. thx. -walter On Thu, Jun 20, 2013 at 4:09 PM, Tony Sebro t...@sfconservancy.org wrote: On Thursday, 20 June 2013, Walter Bender wrote: It is a relatively short list: Walter Bender (wal...@sugarlabs.org) I approve Dan Williams d...@redhat.org Gary Martin garycmar...@gmail.com Christian Marc Schmidt anyth...@christianmarcschmidt.com Tomeu Vizoso tomeu.viz...@gmail.com Manuel Quinones ma...@laptop.org Eben Eliason eben.elia...@gmail.com Marco Pesenti Gritti ma...@marcopg.org Benjamin Berg ben...@sugarlabs.org Did I miss anyone? On 06/20/2013 04:08 PM, Daniel Narvaez wrote: There might be a few more people in some of the files I've seen after making that list. I'll try to send a complete list asap. So, upon receipt of the complete list, would the SLOBs like Conservancy to undertake the task of contacting those people to collect their approvals? Best, Tony -- Tony Sebro, General Counsel, Software Freedom Conservancy +1-212-461-3245 x11 t...@sfconservancy.org www.sfconservancy.org -- 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] draft language asking permission to relicense (was Re: Licensing of the javascript libraries)
On 20 June 2013 22:05, Walter Bender walter.ben...@gmail.com wrote: It is a relatively short list: Walter Bender (wal...@sugarlabs.org) I approve Dan Williams d...@redhat.org Gary Martin garycmar...@gmail.com Christian Marc Schmidt anyth...@christianmarcschmidt.com Tomeu Vizoso tomeu.viz...@gmail.com Manuel Quinones ma...@laptop.org Eben Eliason eben.elia...@gmail.com Marco Pesenti Gritti ma...@marcopg.org Benjamin Berg ben...@sugarlabs.org C. Scott Ananian csc...@laptop.org Gonzalo Odiard godi...@gmail.com Martin Abente mabe...@paraguayeduca.org Simon Schampijer si...@schampijer.de Attaching the relevant git log for reference. Generated by find -name *.svg -o -name *.png | xargs git log log Description: Binary data ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Calculate-42
Activity Homepage: http://activities.sugarlabs.org/addon/4076 Sugar Platform: 0.82 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28661/calculate-42.xo Release notes: - Fix invalid reference error in plotlib. SL#4297 (Aneesh Dogra) - Show numeric scales in axes. SL #2134 (Aneesh Dogra) - Improve error reporting. SL #2386 (Aneesh Dogra) - Report syntax error for incorrect plot statements. SL #2466 (Aneesh Dogra) - Fix significant digit issues in Calculate. SL #2700 (Aneesh Dogra) - Add ability to export graphs to clipboard. (Aneesh Dogra) - Add toolbar support for rotation/portrait mode. (Walter Bender) 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 I know America-8
Activity Homepage: http://activities.sugarlabs.org/addon/4464 Sugar Platform: 0.82 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28660/i_know_america-8.xo Release notes: -Update some stats -New translations 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 I know India-5
Activity Homepage: http://activities.sugarlabs.org/addon/4587 Sugar Platform: 0.82 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28658/i_know_india-5.xo Release notes: -add Uttar Pradesh -New translations 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 I know Peru-8
Activity Homepage: http://activities.sugarlabs.org/addon/4319 Sugar Platform: 0.82 - 0.100 Download Now: http://activities.sugarlabs.org/downloads/file/28657/i_know_peru-8.xo Release notes: -I18n (Aneesh Dogra) -Uses sugargames -Synchronize code with others Conozco -News translations Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
