date:20130328


On 03/27/2013 09:03 PM, Daniel Narvaez wrote:

On 27 March 2013 16:23, Manuel Quiñones ma...@laptop.org wrote:

I know all this can be replaced by a fork  pull workflow, and I'm
used to do that in github.  But gitorius interface is not as good as
github, in my opinion.  By the way, if we have consensus for a fork 
pull workflow, I have no problem switching.


There was actually some discussion in irc today about using github.
Reposting here for people that are not following irc.

It might not be a bad idea to give a try to a github based workflow
with 0.100. (git is flexible enough that giving it a try should not
have a big cost, you can easily go back to gitorious at any time).

17:26  cjb honestly just moving to github is probably not a bad idea IMO
17:26  dnarvaez I like the bug tracking stuff in github
17:26  cjb you'd get pull requests you can track, link between issues and
  commits, it's a more standard and approachable place for
  collaboration to happen, and they have export functions for
  getting your data back out
17:27  dnarvaez for review I wonder if pull requests would work
17:27  cjb sure, it's what everyone else does
17:28  dnarvaez I suppose the infra team would be glad to have few services
   less to support :)
17:30  cjb it made sense to run our own git when github was new and we were
  opposed to everyone standardizing on a centralized (and non-free
  software) web location for git repositories
17:30  cjb but github is huge now, and we're just losing contributors by
  refusing to take part, IMO
17:30  dnarvaez yeah pretty much everyone is one github these days



I read a bit about the differences. For a purist the 'is not using free 
software on their server' springs to mind. But maybe let's focus on the 
work flow first.


The merge requests on gitorious I never used. Maybe because I was too 
focused on the bug tracker or patch on email work flow. It does make 
sense to have a pull workflow for bigger changes that are linked to each 
other, for example a port-shell-to-gtk3 project.


I should check if I can get used to that as a general work flow model. 
Maybe I check with the ayopa project to get a feeling for it.


In general, I am not opposed to useing github as we do not change the 
underlying management system, and that stays the main part.


Regards,
   Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] can't 'yum update' from virtual environment


On 03/28/2013 10:51 AM, Basanta Shrestha wrote:

Hi all,
I am trying to build os for XO-1.75. I have installed fedora 14 as main OS
and installed fedora for ARM (Fedora 12)  under virtual
machine. Everything including network is working from within virtual OS and
I can ping outer world as well.

I now need to install essential packages to run olpc-os-builder from within
virtual machine OS,  but the problem is, I am not able to update ( yum
update) nor install any package. Need help.


What error message do you get?

Simon

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Tuxmath on 0.96+ mystery


On 03/27/2013 11:03 PM, Gonzalo Odiard wrote:

Another option is use http://dev.laptop.org/~gonzalo/nicaragua/Tuxmath-3.xo
and tuxmath packaged in fedora.

Gonzalo


Ok, the AND is important here. Would be good to write down the clear 
steps to get this into a build.


The no-sound option on the landing page is a bit misleading, it does 
only mean that click sounds are not audible, the background music is 
still playing.


Mission accomplished,
   Simon

PS: I made it crash it my first mission, and no, my additions were 
correct...

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] can't 'yum update' from virtual environment

2013-03-28 Thread Basanta Shrestha

[root@fedora-arm ~]# ping google.com
PING google.com (74.125.135.100) 56(84) bytes of data.
64 bytes from ni-in-f100.1e100.net (74.125.135.100): icmp_seq=1 ttl=47
time=142 ms

[root@fedora-arm ~]# yum update
Setting up Update Process
No Packages marked for Update

[root@fedora-arm ~]# yum install nmap
Setting up Install Process
No package nmap available.
Nothing to do


On Thu, Mar 28, 2013 at 3:38 PM, Simon Schampijer si...@schampijer.dewrote:

 On 03/28/2013 10:51 AM, Basanta Shrestha wrote:

 Hi all,
 I am trying to build os for XO-1.75. I have installed fedora 14 as main OS
 and installed fedora for ARM (Fedora 12)  under virtual
 machine. Everything including network is working from within virtual OS
 and
 I can ping outer world as well.

 I now need to install essential packages to run olpc-os-builder from
 within
 virtual machine OS,  but the problem is, I am not able to update ( yum
 update) nor install any package. Need help.


 What error message do you get?

 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




-- 
Basanta Shrestha
Network Engineer
Open Learning Exchange (OLE) Nepal
Tel: +977.1.551, 5520075 Ext. 303
Cell: +977.9818 605110
http://www.olenepal.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] JournalShare status

On 03/27/2013 10:57 PM, Gonzalo Odiard wrote:

I have created a page in the wiki to describe the status of JournalShare
activity.

http://wiki.sugarlabs.org/go/Activities/JournalShare

Enjoy Easter

Gonzalo

Thanks Gonzalo for the write-up!

The first thing that caught my eye was the way to define which items
should be shared. I wouldn't use the favorite metaphor for that. That
works for the Portfolio activity well, but here it is the wrong one, imho.

It should be explicit which items I want to share, using the
Objectchooser looks like the right approach. You might actually as well
to share an object from a usb key or an external sd-card, here the
metaphor of a favorite item works even less.

Another thing that is important is the notion of other members of the
session. I presume the communication should happen in all directions
(e.g. a teacher and five students each member of the session can share
items with the other one), therefore it is important to know who is in
the session and who has offered what.

Actually, we should think as well whether it should be a push or a pull
model. The current file transfers (with friended buddies) are a push
model where the receiver can accept or decline. I think here it is more
of a bulletin board (some ideas for wording and similar you might find
here [1]) where people post items they want to be shared with the group,
so a pull model makes sense here, imho.

Regards,
Simon

[1]
http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines/The_Laptop_Experience/Bulletin_Boards

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] github (was Re: Fwd: Proposal on how to speed up patch reviews)

On 28 March 2013 10:52, Simon Schampijer si...@schampijer.de wrote:
 I read a bit about the differences. For a purist the 'is not using free
 software on their server' springs to mind. But maybe let's focus on the work
 flow first.

Though are there any relevant web apps which are free software? And
despite that we are all using them...

 The merge requests on gitorious I never used. Maybe because I was too
 focused on the bug tracker or patch on email work flow. It does make sense
 to have a pull workflow for bigger changes that are linked to each other,
 for example a port-shell-to-gtk3 project.

 I should check if I can get used to that as a general work flow model. Maybe
 I check with the ayopa project to get a feeling for it.

Yeah, I was proposing to give it a try to see if it works well in general.

Btw I tend to think if we splitted patches a lot more then we are
currently doing reviews would be easier, though that might be personal
taste. With multiple patches as you say, the pull workflow should work
better than the others.

Anyway  I think a github workflow would cover three important things
we care about

* Patches are visible to anyone.
* Patches are trackable.
* Integration with issues tracking.

Of course it migth introduce other problems :)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Features for 0.100

Hello,

we already had a bit of discussion on what 0.100 should focus on in
the schedule thread. I'll try to summarize it here.

IMPORTANT: the consensus seems to be that we should be having the
discussion about features early this cycle, to try and narrow the
scope of the release as much as possible. So here is your chance to
propose features, there won't be a feature acceptance deadline later.

* Simon proposed that we make html5 activities the main focus of the
release and people responded favorably (do you think that's a bad
idea? Please speak up!). We need to articulate better what this
involves exactly, which new glucose components will have to be
developed, which activities. There as been some experimentation but
there is more left to do, the initial part of the cycle will involve
research.

* Ajay proposed a couple of features which has been delayed from
previous cycles.

http://wiki.sugarlabs.org/go/Features/Multi_selection

There is some concern that it might be too big of a change. We should
probably decide on the base of the patches that Ajay will be sending
out soon.

http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support

It seems to be ready to go in.

* Walter proposed a few other features which went already through
several reviews (do we have feature pages for these perhaps?)

- homeview background image
- multi-homeview
- webservices
- comment field in journal detail view


So 0.100 seems to be shaping up as a release devoted mainly to html5
activities, while landing a few features which are almost ready. What
does everyone think about that?

-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Features for 0.100

On Thu, Mar 28, 2013 at 7:44 AM, Daniel Narvaez dwnarv...@gmail.com wrote:
 Hello,

 we already had a bit of discussion on what 0.100 should focus on in
 the schedule thread. I'll try to summarize it here.

 IMPORTANT: the consensus seems to be that we should be having the
 discussion about features early this cycle, to try and narrow the
 scope of the release as much as possible. So here is your chance to
 propose features, there won't be a feature acceptance deadline later.

 * Simon proposed that we make html5 activities the main focus of the
 release and people responded favorably (do you think that's a bad
 idea? Please speak up!). We need to articulate better what this
 involves exactly, which new glucose components will have to be
 developed, which activities. There as been some experimentation but
 there is more left to do, the initial part of the cycle will involve
 research.

 * Ajay proposed a couple of features which has been delayed from
 previous cycles.

 http://wiki.sugarlabs.org/go/Features/Multi_selection

 There is some concern that it might be too big of a change. We should
 probably decide on the base of the patches that Ajay will be sending
 out soon.

 http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support

 It seems to be ready to go in.

 * Walter proposed a few other features which went already through
 several reviews (do we have feature pages for these perhaps?)

 - homeview background image [1]
 - multi-homeview [2]
 - webservices [3]
 - comment field in journal detail view [4]

[1] http://wiki.sugarlabs.org/go/Features/Background_image_on_home_view
[2] http://wiki.sugarlabs.org/go/Features/Multiple_home_views
[3] http://wiki.sugarlabs.org/go/Features/Web_services
[4] http://wiki.sugarlabs.org/go/Features/Comment_box_in_journal_detail_view

-walter


 So 0.100 seems to be shaping up as a release devoted mainly to html5
 activities, while landing a few features which are almost ready. What
 does everyone think about that?

 --
 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] Sugar on Raspberry Pi

2013-03-28 Thread Thomas Gilliard


On 03/28/2013 02:11 AM, Alexandro Colorado wrote:
Hi I want to know the status of a RaspberryPi distribution like 
Raspbian which can handle Sugar's environment. Something like Sugar on 
a Pi.


I could find this testing reports talking about Sweets
http://wiki.sugarlabs.org/go/Testing/Reports/Sweets_on_Raspberry_pi_armhf_raspbian

The reports seems to say is stable but slow. I wonder if there has 
been any optimization gone into this as of lately?


--
Alexandro Colorado
Apache OpenOffice Contributor
http://es.openoffice.org




___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Also look at:

http://wiki.sugarlabs.org/go/Testing/Reports/ARM_RPi#Test_report_rpfr-f18-final.img

There are several tests on this page using several different RPi 
software versions.


Sugar 0.96.2 runs nicely but slowly on both the B 512 and the  B 256 
Raspberry Pi

 http://wiki.sugarlabs.org/go/File:Rpfr-fi18-rc1.png

Tom Gilliard
satellit on #sugar freenode IRC


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Sugar on Raspberry Pi

On Thu, Mar 28, 2013 at 5:18 AM, Alexandro Colorado j...@oooes.org wrote:

On Thu, Mar 28, 2013 at 3:14 AM, Peter Robinson pbrobin...@gmail.com
wrote:

I could find this testing reports talking about Sweets

http://wiki.sugarlabs.org/go/Testing/Reports/Sweets_on_Raspberry_pi_armhf_raspbian

The reports seems to say is stable but slow. I wonder if there has been
any
optimization gone into this as of lately?

I don't think this is distro related issues but on architecture/code.

Peter
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

--
Alexandro Colorado
Apache OpenOffice Contributor
http://es.openoffice.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Regarding the broken activities, this is in large part due to the
limitations of the particular version of Sugar being run. I.e., newer
versions of Sugar/Browse use webkit and would probably run.

-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] github (was Re: Fwd: Proposal on how to speed up patch reviews)

On Thu, Mar 28, 2013 at 7:19 AM, Daniel Narvaez dwnarv...@gmail.com wrote:
 On 28 March 2013 10:52, Simon Schampijer si...@schampijer.de wrote:
 I read a bit about the differences. For a purist the 'is not using free
 software on their server' springs to mind. But maybe let's focus on the work
 flow first.

 Though are there any relevant web apps which are free software? And
 despite that we are all using them...

 The merge requests on gitorious I never used. Maybe because I was too
 focused on the bug tracker or patch on email work flow. It does make sense
 to have a pull workflow for bigger changes that are linked to each other,
 for example a port-shell-to-gtk3 project.

FWIW, I found merge-requests on gitorious to be much easier to explain
and manage with newbies such as the Google Code In students. And they
are visible. But I have not had much luck getting the veteran Sugar
developers to acknowledge or accept patches through that mechanism.


 I should check if I can get used to that as a general work flow model. Maybe
 I check with the ayopa project to get a feeling for it.

 Yeah, I was proposing to give it a try to see if it works well in general.

 Btw I tend to think if we splitted patches a lot more then we are
 currently doing reviews would be easier, though that might be personal
 taste. With multiple patches as you say, the pull workflow should work
 better than the others.

 Anyway  I think a github workflow would cover three important things
 we care about

 * Patches are visible to anyone.
 * Patches are trackable.
 * Integration with issues tracking.

 Of course it migth introduce other problems :)
 ___
 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] journal comments field patch (again)

On Tue, Mar 26, 2013 at 5:28 PM, Daniel Narvaez dwnarv...@gmail.com wrote:
 Some initial comments on 0001

I've renamed this thread to be specific to 0001, which is adding a
comments field to the journal expanded entry.

Thanks for the review.


 * Did you post screenshots of this so that we can get designers approval?

Yes. On the Feature page [1] is an image [2]. I had a long back and
forth with Gary on the specifics a few months back. Will dig up that
email thread.

 * An example of the json format somewhere would be useful. The icon
 property is a bit suspect (it can contain pretty different things).

I agree. I broke it up into separate fields in the latest patch. An
example of a comments entry in the metadata is included here:

[{message: painting with light, from: Walter Bender,
icon-color: [#ED2529, #69BC47]}, {message: more tests of
comment downloads, from: Walter Bender, icon:
facebook-share}, {message: one more time..., from: Walter
Bender, icon-color: [#69BC47, #3C54A3]}, {message: trying to
trigger a signal, from: Walter Bender, icon: facebook-share}]

 * There are several places where splitting up the code in blocks
 (vertical space is free of charge, promised!) would help readability.
 Most notably _init_model.

done

 * If you think something is kludgy please fix it before posting for review :)

I had forgotten to remove that comment after I had fixed it.

 * I think we can avoid the .props. everywhere, slightly nicer.

I have not made this change yet, since I modeled my code on
listview.py, which also uses props. I think we should have a separate
patch that cleans all of this up for both modules.

 * Let's use new-style pygobject signals in new code.

Again, I am using the same style as in listview.py. I think we should
have a separate global cleanup.

 * Widgets should not show themself imo, especially as a side effect of
 some unrelated method. It hurts code reusability.

fixed.

 * It would make the review a lot easier if the refactorings was
 splitted to separate patches.

Agreed. I have made 3 separate patches, although one of them is still
quite large.

0001 is to stage _create_scrollable for use with multiple widget types
0002 is to pull out _write_entry as a separate method so the code can
be used multiple places
0003 is the addition of the comments widget and its integration into
the expanded entry (using 0001 and 0002)

 In detail:

 -import simplejson

I left it as simplejson for the moment as to not to add unrelated
changes to this patch series.


 Let's move the whole sugar module to json while we are at it?

I believe we decided to move to json in general. Should be a separate
series of patches?


 -def _create_scrollable(self, label):
 +def _create_scrollable(self, label, widget_class):

 The changes to this function, with those related to it in the rest of
 the code, can be split to two patches:

 1 Make the label optional. (Also let's use named arguments and label=None)

Done.

 2 Allow to pass a widget_class, factor out code to DescTagsView.
 (Also, why passing a widget_class instead of just a widget there?)

I pass a widget now, not its class.


 -if self._metadata.get('mountpoint', '/') == '/':
 -model.write(self._metadata, update_mtime=False)
 -else:
 -old_file_path = os.path.join(self._metadata['mountpoint'],
 -model.get_file_name(old_title,
 -self._metadata['mime_type']))
 -model.write(self._metadata, file_path=old_file_path,
 -update_mtime=False)
 +self._write_entry()

  self._update_title_sid = None

 +def _write_entry(self):
 +if self._metadata.get('mountpoint', '/') == '/':
 +model.write(self._metadata, update_mtime=False)
 +else:
 +old_file_path = os.path.join(self._metadata['mountpoint'],
 +model.get_file_name(old_title,
 +self._metadata['mime_type']))
 +model.write(self._metadata, file_path=old_file_path,
 +update_mtime=False)
 +

 I can't easily say if you are making any changes there. But even if
 so, first factor out the code in one patch, then make the changes you
 need.

In a separate patch.

regards.

-walter

[1] 
http://wiki.sugarlabs.org/go/Features/Comment_box_in_journal_detail_view#UI_Design
[2] http://wiki.sugarlabs.org/go/File:FB-comments.png

-- 
Walter Bender
Sugar Labs
http://www.sugarlabs.org


0003-Add-comments-box-to-expanded-entry.patch
Description: Binary data


0002-Make-separate-method-for-_write_entry-so-code-can-be.patch
Description: Binary data


0001-Pass-a-widget-to-_create_scrollable-so-code-can-be-u.patch
Description: Binary data
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] journal comments field patch (again)

Hi,

would you mind to submit these as a pull request of

https://github.com/sugarlabs/sugar

As discussed in another thread I would like to give github workflow a
try. I will of course push the changes back to the official repo then.

On 28 March 2013 14:26, Walter Bender walter.ben...@gmail.com wrote:
 On Tue, Mar 26, 2013 at 5:28 PM, Daniel Narvaez dwnarv...@gmail.com wrote:
 Some initial comments on 0001

 I've renamed this thread to be specific to 0001, which is adding a
 comments field to the journal expanded entry.

 Thanks for the review.


 * Did you post screenshots of this so that we can get designers approval?

 Yes. On the Feature page [1] is an image [2]. I had a long back and
 forth with Gary on the specifics a few months back. Will dig up that
 email thread.

 * An example of the json format somewhere would be useful. The icon
 property is a bit suspect (it can contain pretty different things).

 I agree. I broke it up into separate fields in the latest patch. An
 example of a comments entry in the metadata is included here:

 [{message: painting with light, from: Walter Bender,
 icon-color: [#ED2529, #69BC47]}, {message: more tests of
 comment downloads, from: Walter Bender, icon:
 facebook-share}, {message: one more time..., from: Walter
 Bender, icon-color: [#69BC47, #3C54A3]}, {message: trying to
 trigger a signal, from: Walter Bender, icon: facebook-share}]

 * There are several places where splitting up the code in blocks
 (vertical space is free of charge, promised!) would help readability.
 Most notably _init_model.

 done

 * If you think something is kludgy please fix it before posting for review :)

 I had forgotten to remove that comment after I had fixed it.

 * I think we can avoid the .props. everywhere, slightly nicer.

 I have not made this change yet, since I modeled my code on
 listview.py, which also uses props. I think we should have a separate
 patch that cleans all of this up for both modules.

 * Let's use new-style pygobject signals in new code.

 Again, I am using the same style as in listview.py. I think we should
 have a separate global cleanup.

 * Widgets should not show themself imo, especially as a side effect of
 some unrelated method. It hurts code reusability.

 fixed.

 * It would make the review a lot easier if the refactorings was
 splitted to separate patches.

 Agreed. I have made 3 separate patches, although one of them is still
 quite large.

 0001 is to stage _create_scrollable for use with multiple widget types
 0002 is to pull out _write_entry as a separate method so the code can
 be used multiple places
 0003 is the addition of the comments widget and its integration into
 the expanded entry (using 0001 and 0002)

 In detail:

 -import simplejson

 I left it as simplejson for the moment as to not to add unrelated
 changes to this patch series.


 Let's move the whole sugar module to json while we are at it?

 I believe we decided to move to json in general. Should be a separate
 series of patches?


 -def _create_scrollable(self, label):
 +def _create_scrollable(self, label, widget_class):

 The changes to this function, with those related to it in the rest of
 the code, can be split to two patches:

 1 Make the label optional. (Also let's use named arguments and label=None)

 Done.

 2 Allow to pass a widget_class, factor out code to DescTagsView.
 (Also, why passing a widget_class instead of just a widget there?)

 I pass a widget now, not its class.


 -if self._metadata.get('mountpoint', '/') == '/':
 -model.write(self._metadata, update_mtime=False)
 -else:
 -old_file_path = os.path.join(self._metadata['mountpoint'],
 -model.get_file_name(old_title,
 -self._metadata['mime_type']))
 -model.write(self._metadata, file_path=old_file_path,
 -update_mtime=False)
 +self._write_entry()

  self._update_title_sid = None

 +def _write_entry(self):
 +if self._metadata.get('mountpoint', '/') == '/':
 +model.write(self._metadata, update_mtime=False)
 +else:
 +old_file_path = os.path.join(self._metadata['mountpoint'],
 +model.get_file_name(old_title,
 +self._metadata['mime_type']))
 +model.write(self._metadata, file_path=old_file_path,
 +update_mtime=False)
 +

 I can't easily say if you are making any changes there. But even if
 so, first factor out the code in one patch, then make the changes you
 need.

 In a separate patch.

 regards.

 -walter

 [1] 
 http://wiki.sugarlabs.org/go/Features/Comment_box_in_journal_detail_view#UI_Design
 [2] http://wiki.sugarlabs.org/go/File:FB-comments.png

 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org



-- 
Daniel Narvaez
___
Sugar-devel mailing list

Re: [Sugar-devel] journal comments field patch (again)

On Thu, Mar 28, 2013 at 10:03 AM, Daniel Narvaez dwnarv...@gmail.com wrote:
 Hi,

 would you mind to submit these as a pull request of

 https://github.com/sugarlabs/sugar

 As discussed in another thread I would like to give github workflow a
 try. I will of course push the changes back to the official repo then.

Done.  (While I was at it, I broke 0003 into two parts, hopefully
making it easier to digest.)


FWIW, the process, from the requesting side, is almost identical to
the merge request mechanism in gitorious.

-walter


 On 28 March 2013 14:26, Walter Bender walter.ben...@gmail.com wrote:
 On Tue, Mar 26, 2013 at 5:28 PM, Daniel Narvaez dwnarv...@gmail.com wrote:
 Some initial comments on 0001

 I've renamed this thread to be specific to 0001, which is adding a
 comments field to the journal expanded entry.

 Thanks for the review.


 * Did you post screenshots of this so that we can get designers approval?

 Yes. On the Feature page [1] is an image [2]. I had a long back and
 forth with Gary on the specifics a few months back. Will dig up that
 email thread.

 * An example of the json format somewhere would be useful. The icon
 property is a bit suspect (it can contain pretty different things).

 I agree. I broke it up into separate fields in the latest patch. An
 example of a comments entry in the metadata is included here:

 [{message: painting with light, from: Walter Bender,
 icon-color: [#ED2529, #69BC47]}, {message: more tests of
 comment downloads, from: Walter Bender, icon:
 facebook-share}, {message: one more time..., from: Walter
 Bender, icon-color: [#69BC47, #3C54A3]}, {message: trying to
 trigger a signal, from: Walter Bender, icon: facebook-share}]

 * There are several places where splitting up the code in blocks
 (vertical space is free of charge, promised!) would help readability.
 Most notably _init_model.

 done

 * If you think something is kludgy please fix it before posting for review 
 :)

 I had forgotten to remove that comment after I had fixed it.

 * I think we can avoid the .props. everywhere, slightly nicer.

 I have not made this change yet, since I modeled my code on
 listview.py, which also uses props. I think we should have a separate
 patch that cleans all of this up for both modules.

 * Let's use new-style pygobject signals in new code.

 Again, I am using the same style as in listview.py. I think we should
 have a separate global cleanup.

 * Widgets should not show themself imo, especially as a side effect of
 some unrelated method. It hurts code reusability.

 fixed.

 * It would make the review a lot easier if the refactorings was
 splitted to separate patches.

 Agreed. I have made 3 separate patches, although one of them is still
 quite large.

 0001 is to stage _create_scrollable for use with multiple widget types
 0002 is to pull out _write_entry as a separate method so the code can
 be used multiple places
 0003 is the addition of the comments widget and its integration into
 the expanded entry (using 0001 and 0002)

 In detail:

 -import simplejson

 I left it as simplejson for the moment as to not to add unrelated
 changes to this patch series.


 Let's move the whole sugar module to json while we are at it?

 I believe we decided to move to json in general. Should be a separate
 series of patches?


 -def _create_scrollable(self, label):
 +def _create_scrollable(self, label, widget_class):

 The changes to this function, with those related to it in the rest of
 the code, can be split to two patches:

 1 Make the label optional. (Also let's use named arguments and label=None)

 Done.

 2 Allow to pass a widget_class, factor out code to DescTagsView.
 (Also, why passing a widget_class instead of just a widget there?)

 I pass a widget now, not its class.


 -if self._metadata.get('mountpoint', '/') == '/':
 -model.write(self._metadata, update_mtime=False)
 -else:
 -old_file_path = os.path.join(self._metadata['mountpoint'],
 -model.get_file_name(old_title,
 -self._metadata['mime_type']))
 -model.write(self._metadata, file_path=old_file_path,
 -update_mtime=False)
 +self._write_entry()

  self._update_title_sid = None

 +def _write_entry(self):
 +if self._metadata.get('mountpoint', '/') == '/':
 +model.write(self._metadata, update_mtime=False)
 +else:
 +old_file_path = os.path.join(self._metadata['mountpoint'],
 +model.get_file_name(old_title,
 +self._metadata['mime_type']))
 +model.write(self._metadata, file_path=old_file_path,
 +update_mtime=False)
 +

 I can't easily say if you are making any changes there. But even if
 so, first factor out the code in one patch, then make the changes you
 need.

 In a separate patch.

 regards.

 -walter

 [1]

Re: [Sugar-devel] journal comments field patch (again)

On Thu, Mar 28, 2013 at 10:34 AM, Walter Bender walter.ben...@gmail.com wrote:
 On Thu, Mar 28, 2013 at 10:03 AM, Daniel Narvaez dwnarv...@gmail.com wrote:
 Hi,

 would you mind to submit these as a pull request of

 https://github.com/sugarlabs/sugar

 As discussed in another thread I would like to give github workflow a
 try. I will of course push the changes back to the official repo then.

I'll submit 0002 of the original webservices request to github as
well. 0002 creates the framework within Sugar for utilizing a
webservice, a relatively non-invasive patch. It does not add the
webservices themselves.

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

Re: [Sugar-devel] journal comments field patch (again)

A couple of problems on github (I may be doing things wrong):

1. No pull request shows up on my dashboard even though I seeming
successfully submitted one. How do I confirm it was received?
2. It is generated, because when I try to submit a second pull request
from the same fork for a different set of commits, it won't let me
because I have already submitted a pull request. Do I need to make a
new branch for each pull request?

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

Re: [Sugar-devel] journal comments field patch (again)

On Thu, Mar 28, 2013 at 10:53 AM, Walter Bender walter.ben...@gmail.com wrote:
 A couple of problems on github (I may be doing things wrong):

 1. No pull request shows up on my dashboard even though I seeming
 successfully submitted one. How do I confirm it was received?

Never mind. I was looking at the wrong repo.

 2. It is generated, because when I try to submit a second pull request
 from the same fork for a different set of commits, it won't let me
 because I have already submitted a pull request. Do I need to make a
 new branch for each pull request?

I still have the problem of not being able to add a second pull request.

-walter

 regards.

 -walter

 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.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] github (was Re: Fwd: Proposal on how to speed up patch reviews)

2013-03-28 Thread Chris Leonard

On Thu, Mar 28, 2013 at 7:19 AM, Daniel Narvaez dwnarv...@gmail.com wrote:
 Anyway  I think a github workflow would cover three important things
 we care about

 * Patches are visible to anyone.
 * Patches are trackable.
 * Integration with issues tracking.

 Of course it migth introduce other problems :)


So how does this work for Pootle integration and the L10n workflow?

At the present time, all translation-ready (i18n-ized) Sugar packages
have special gituser pootle added as a committer.  Lang admins can
click Commit to VCS in Pootle and the commit is made (on their
behalf) by the priv'ed pootle gituser.

Simple to manage at set-up time for new Sugar Activities/packages
(make sure git user pootle has commit.)  Simple to manage lang admin
privs via Pootle admin user interface.

What workflow has the equivalent simplicity in github?  I can tell you
there is no way that breaking out languages or localizers as
individual contributors to a repo (eliminating the special poolte
user) is going to work out well.

cjl
Sugar Labs Translation Team Coordinator
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Features for 0.100

2013-03-28 Thread Martin Abente

On Thu, Mar 28, 2013 at 7:44 AM, Daniel Narvaez dwnarv...@gmail.com wrote:

 Hello,

 we already had a bit of discussion on what 0.100 should focus on in
 the schedule thread. I'll try to summarize it here.

 IMPORTANT: the consensus seems to be that we should be having the
 discussion about features early this cycle, to try and narrow the
 scope of the release as much as possible. So here is your chance to
 propose features, there won't be a feature acceptance deadline later.

 * Simon proposed that we make html5 activities the main focus of the
 release and people responded favorably (do you think that's a bad
 idea? Please speak up!). We need to articulate better what this
 involves exactly, which new glucose components will have to be
 developed, which activities. There as been some experimentation but
 there is more left to do, the initial part of the cycle will involve
 research.

 * Ajay proposed a couple of features which has been delayed from
 previous cycles.

 http://wiki.sugarlabs.org/go/Features/Multi_selection

 There is some concern that it might be too big of a change. We should
 probably decide on the base of the patches that Ajay will be sending
 out soon.



I hope everyone considers that the journal-multi-selection feature has
passed through several iterations of design and code review already. This a
great improvement to journal's usability and is already being used in the
ground.

It was a joint effort between many SL community members since EduJAM 2011,
so I think there should be a consensus towards accepting it.

http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support

 It seems to be ready to go in.

 * Walter proposed a few other features which went already through
 several reviews (do we have feature pages for these perhaps?)

 - homeview background image


I know, at first hand, that Caacupe (Paraguay) kids will be more than happy
with this ^. We should support also features that makes Sugar more
enjoyable to it's users.


 - multi-homeview

- webservices
 - comment field in journal detail view


We should also keep in mind that webservices can offer a lot of utilities
for deployments in the near future, and it will give Sugar a another way to
expand its capabilities without writing-from-scratch everything.




So 0.100 seems to be shaping up as a release devoted mainly to html5
 activities, while landing a few features which are almost ready. What
 does everyone think about that?

 --
 Daniel Narvaez
 ___
 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] journal comments field patch (again)

I have not tried to push multiple requests myself yet so I can't be of much
help. Quick googling seems to indicate that selecting specific commits
might be possible but complicated... It think using one branch per patchset
would be good practice anyway.

On Thursday, 28 March 2013, Walter Bender wrote:

 On Thu, Mar 28, 2013 at 10:53 AM, Walter Bender 
 walter.ben...@gmail.comjavascript:;
 wrote:
  A couple of problems on github (I may be doing things wrong):
 
  1. No pull request shows up on my dashboard even though I seeming
  successfully submitted one. How do I confirm it was received?

 Never mind. I was looking at the wrong repo.

  2. It is generated, because when I try to submit a second pull request
  from the same fork for a different set of commits, it won't let me
  because I have already submitted a pull request. Do I need to make a
  new branch for each pull request?

 I still have the problem of not being able to add a second pull request.

 -walter
 
  regards.
 
  -walter
 
  --
  Walter Bender
  Sugar Labs
  http://www.sugarlabs.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] journal comments field patch (again)

On Thu, Mar 28, 2013 at 11:34 AM, Daniel Narvaez dwnarv...@gmail.com wrote:
 I have not tried to push multiple requests myself yet so I can't be of much
 help. Quick googling seems to indicate that selecting specific commits might
 be possible but complicated... It think using one branch per patchset would
 be good practice anyway.

OK. I'll make a new branch... stay tuned.

-walter



 On Thursday, 28 March 2013, Walter Bender wrote:

 On Thu, Mar 28, 2013 at 10:53 AM, Walter Bender walter.ben...@gmail.com
 wrote:
  A couple of problems on github (I may be doing things wrong):
 
  1. No pull request shows up on my dashboard even though I seeming
  successfully submitted one. How do I confirm it was received?

 Never mind. I was looking at the wrong repo.

  2. It is generated, because when I try to submit a second pull request
  from the same fork for a different set of commits, it won't let me
  because I have already submitted a pull request. Do I need to make a
  new branch for each pull request?

 I still have the problem of not being able to add a second pull request.

 -walter
 
  regards.
 
  -walter
 
  --
  Walter Bender
  Sugar Labs
  http://www.sugarlabs.org



 --
 Walter Bender
 Sugar Labs
 http://www.sugarlabs.org



 --
 Daniel Narvaez




-- 
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] github (was Re: Fwd: Proposal on how to speed up patch reviews)

I would expect the same workflow to be possible in GitHub.

But let's play a bit with it and see if we like it before making too many
plans about a switch :)

On Thursday, 28 March 2013, Chris Leonard wrote:

 On Thu, Mar 28, 2013 at 7:19 AM, Daniel Narvaez 
 dwnarv...@gmail.comjavascript:;
 wrote:
  Anyway  I think a github workflow would cover three important things
  we care about
 
  * Patches are visible to anyone.
  * Patches are trackable.
  * Integration with issues tracking.
 
  Of course it migth introduce other problems :)
 

 So how does this work for Pootle integration and the L10n workflow?

 At the present time, all translation-ready (i18n-ized) Sugar packages
 have special gituser pootle added as a committer.  Lang admins can
 click Commit to VCS in Pootle and the commit is made (on their
 behalf) by the priv'ed pootle gituser.

 Simple to manage at set-up time for new Sugar Activities/packages
 (make sure git user pootle has commit.)  Simple to manage lang admin
 privs via Pootle admin user interface.

 What workflow has the equivalent simplicity in github?  I can tell you
 there is no way that breaking out languages or localizers as
 individual contributors to a repo (eliminating the special poolte
 user) is going to work out well.

 cjl
 Sugar Labs Translation Team Coordinator



-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Web services (was Re: Features for 0.100)

On 28 March 2013 16:27, Martin Abente martin.abente.lah...@gmail.com wrote:
 - webservices
 - comment field in journal detail view


 We should also keep in mind that webservices can offer a lot of utilities
 for deployments in the near future, and it will give Sugar a another way to
 expand its capabilities without writing-from-scratch everything.

I would like to get a better sense of the amount of work that is
involved here. Is the framework ready for review or are there missing
pieces which are still in development? Which services have been
implemented and which ones do you plan to develop for 0.100? Is
support for all the services going to be part of the sugar module or
do you plan to maintain it outside?

Are you referring to the html5 effort with writing-from-scratch? I do
think there is a bit of tension between adding more functionalities
using the current toolkit and developing a new one based on html5. I
would say they are both worthwhile goals but they would benefit from
explicit planning/prioritization.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [ASLO] Release Music Keyboard-6

2013-03-28 Thread Chris Leonard

On Wed, Mar 27, 2013 at 7:50 AM, Simon Schampijer si...@schampijer.de wrote:

 Good. About the tooltips, I was not sure about the scales denomination. In
 some places, the scales with letters is named German and in other is
 American ! The scale starting in DO can be named Latin, but is not
 really clear for me and there are a lot of changes by countries and in the
 history. See:

 https://en.wikipedia.org/wiki/Musical_note


 Yes, I looked about a good way as well but could not find a global labeling
 myself. As you say, some say latin, others say german... We need a
 musicologist here...


Caryl Bigheno might be able to chime in on this, she has a background
in teaching music.

cjl
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] github (was Re: Fwd: Proposal on how to speed up patch reviews)

2013-03-28 Thread S. Daniel Francis

2013/3/28 Daniel Narvaez dwnarv...@gmail.com

 I would expect the same workflow to be possible in GitHub.

 But let's play a bit with it and see if we like it before making too many
 plans about a switch :)


Just some things which come to my mind:

* Will bugs.sugarlabs.org make sense having the github bug tracker?
* Should some subpages of http://wiki.sugarlabs.org/go/Activities be moved
to github wikis?

Cheers,
Daniel Francis.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Web services (was Re: Features for 0.100)

2013-03-28 Thread Martin Abente

On Thu, Mar 28, 2013 at 12:01 PM, Daniel Narvaez dwnarv...@gmail.comwrote:

 On 28 March 2013 16:27, Martin Abente martin.abente.lah...@gmail.com
 wrote:
  - webservices
  - comment field in journal detail view
 
 
  We should also keep in mind that webservices can offer a lot of utilities
  for deployments in the near future, and it will give Sugar a another way
 to
  expand its capabilities without writing-from-scratch everything.

 I would like to get a better sense of the amount of work that is
 involved here. Is the framework ready for review or are there missing
 pieces which are still in development? Which services have been
 implemented and which ones do you plan to develop for 0.100? Is
 support for all the services going to be part of the sugar module or
 do you plan to maintain it outside?


Are you referring to the html5 effort with writing-from-scratch? I do
 think there is a bit of tension between adding more functionalities
 using the current toolkit and developing a new one based on html5. I
 would say they are both worthwhile goals but they would benefit from
 explicit planning/prioritization.
 ___


No, I wasn't.


 
 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] [SLOBS] meeting reminder

Belated reminder that we (the Sugar Labs oversight board) are meeting
at 6PM (22UTC) on irc.freenode.net #sugar
Please join us.

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

Re: [Sugar-devel] Web services (was Re: Features for 0.100)

On Thu, Mar 28, 2013 at 12:01 PM, Daniel Narvaez dwnarv...@gmail.com wrote:
 On 28 March 2013 16:27, Martin Abente martin.abente.lah...@gmail.com wrote:
 - webservices
 - comment field in journal detail view


 We should also keep in mind that webservices can offer a lot of utilities
 for deployments in the near future, and it will give Sugar a another way to
 expand its capabilities without writing-from-scratch everything.

 I would like to get a better sense of the amount of work that is
 involved here. Is the framework ready for review or are there missing
 pieces which are still in development? Which services have been
 implemented and which ones do you plan to develop for 0.100? Is
 support for all the services going to be part of the sugar module or
 do you plan to maintain it outside?

We have a framework and two webservices up and running at this point.
The review process for the framework itself is underway. The
webservices by-in-large live outside of Sugar, but there are cpsection
services and webservice code to drop into extensions in order enable
individual services. We learned a lot from going from one service to
more-than-one service and a second rebased set of patches are being
prepared.

For 0.100, I expect we'll have two webservices that users could load
into their profiles (for Facebook and Twitter) and possibly ones for
Google+ and Google Drive. I am also in discussion with Gonzalo et al.
about using the webservce framework as the interface for his Journal
sharing service, but that is more speculation at this point. Plus
there has been discussion about developing a service for
status.sugarlabs.org (based on the next generation of status.net
services). The goal is to get framework in place so anyone can develop
services.


 Are you referring to the html5 effort with writing-from-scratch? I do
 think there is a bit of tension between adding more functionalities
 using the current toolkit and developing a new one based on html5. I
 would say they are both worthwhile goals but they would benefit from
 explicit planning/prioritization.
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel

-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] Patches -- Process and Culture

2013-03-28 Thread David Farning

On Wed, Mar 27, 2013 at 7:13 PM, Daniel Narvaez dwnarv...@gmail.com wrote:
 Hey,

 want to start on that kind of analysis? :)

James' self analysis is spot on.

We all wear several 'hats' Sugar contributor, Employee or volunteer,
person, . These hats bring bias which affect our decision making.

To use myself as an example: I am squeezed between money and power.
Activity Central provides technical service and support for
deployments. Deployments pay us to meet very specific needs for them.

Money -- Deployment pay us _only_what they think a fix or issues is
worth to them. We, in turn, can only pay one of our developers what
the deployment thinks their work is worth.

Power -- Deployments tell us _exactly_ what they want us to do and how
much time they are willing to pay us to do it.

The business model meets a need which adds value to the ecosystem.
However it does introduce conflicts. In the context of this discussion
a key conflict is cost and value of up-streaming deployment specific
'fixes'.

Dave

 I've been considering some cultural factors but they are not related to
 prestige and moneys, so they are probably pretty different from what
 you have in mind here.


 On Wednesday, 27 March 2013, David Farning wrote:

 Daniel Narvaez reopened an interesting thread that comes up every
 couple of years -- patch approval. This is an interesting and
 important issue to both the Sugar community and the OLPC ecosystem.

 In parallel to patch process, a discussion about culture might be
 beneficial. Sugar and OLPC are unique from many other free software
 projects. There is a significant amount of prestige  power, and money
 at stake.

 Implementation of any specific patch process might be enhanced by
 considering cultural factors at play.

 --
 David Farning
 ___
 Sugar-devel mailing list
 Sugar-devel@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel



 --
 Daniel Narvaez




--
David Farning
Activity Central: http://www.activitycentral.com
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Tuxmath on 0.96+ mystery

2013-03-28 Thread lionel

 

 Don't have sense that works if you patch after install and not if already
patched.

 The log says anything? and the shell.log?

 

I know it dont have sense. Its why Ive already spent hours on this
problem

Ive worked again on it today. Here some other information:

 

As I said, the working way to proceed is:

1) Download the latest-version form the Sugar App Store

2) Install it/launch it. An error occurs: bundle malformed

3) Patch the activity.info

4) Launch again, it works.

 

When the activity.info is patched before installing, it not works.

The error in log is:

 

Traceback (most recent call last):

File /usr/bin/sugar-activity, line 154, in module

   main()

File /usr/bin/sugar-activity, line 110, in main

   class_name = splitted_module[1]

IndexError: list index out of range

Exited with status 1, pid 933 data (None, open file 'fdopen', mode 'w' at
0x9bc7e90, '1bb1deaed1d6647ac6dfadf3e6dafaf8676cd71a')

 

Today, Ive tried another way to patch the app.

1) Put the latest version on an USB Key

2) Install it without launch using the sugar-install-bundle command line

3) Patch the activity.info

4) Launch the app, it dont work: the error is pretty the same:

 

Traceback (most recent call last):

File /usr/bin/sugar-activity, line 154, in module

   main()

File /usr/bin/sugar-activity, line 110, in main

   class_name = splitted_module[1]

IndexError: list index out of range

Exited with status 1, pid 748 data (None, open file 'fdopen', mode 'w' at
0x9ab85a0, dbus.ByteArray('e4a32a21d20c60809a3c9adbaac8f4b104eb8571',
variant_level=1))

 

Its like at first launch something was built when the bundle is mal
formed but not when the bundle is okay.

Its strange but its like this :-(

 

Another bad news (I must confirm) is that the same problem seems to occur on
GCompris.

 

Lionel.

 

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Tuxmath on 0.96+ mystery

On 28 March 2013 22:12,  lio...@olpc-france.org wrote:
 4) Launch the app, it don’t work: the error is pretty the same:



 Traceback (most recent call last):

 File /usr/bin/sugar-activity, line 154, in module

main()

 File /usr/bin/sugar-activity, line 110, in main

class_name = splitted_module[1]

 IndexError: list index out of range

 Exited with status 1, pid 748 data (None, open file 'fdopen', mode 'w' at
 0x9ab85a0, dbus.ByteArray('e4a32a21d20c60809a3c9adbaac8f4b104eb8571',
 variant_level=1))

I don't have an explanation for the installation thing, but that error
is caused by your exec line which is incorrect. sugar-activity expects
the path to a class as first argument, not the name of a script.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] github (was Re: Fwd: Proposal on how to speed up patch reviews)

Hey Daniel!

On 28 March 2013 17:53, S. Daniel Francis fran...@sugarlabs.org wrote:
 Just some things which come to my mind:

 * Will bugs.sugarlabs.org make sense having the github bug tracker?

Integration between git and the bug tracker would be pretty awesome
(being able to close bugs by just mentioning them in the log). Though
it's optional really, we might migrate only when we are really really
sure we love github :)

Mostly our sysadmins seems to hate trac. If we have to move away from
it and if we actually move code to github, then it probably make sense
to just use the bug tracker there and enjoy the integration.

 * Should some subpages of http://wiki.sugarlabs.org/go/Activities be moved
 to github wikis?

I tend to think this should stay where it is, I don't like to have too
many places where we host content, it gets confusing.

(Well if you ask me, we shouldn't host most of our content in a wiki
but in git, where you can keep some editorial control. But that's
probably just me, really!)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] github (was Re: Fwd: Proposal on how to speed up patch reviews)

On Thu, Mar 28, 2013 at 6:01 PM, Daniel Narvaez dwnarv...@gmail.com wrote:
 Hey Daniel!

 On 28 March 2013 17:53, S. Daniel Francis fran...@sugarlabs.org wrote:
 Just some things which come to my mind:

 * Will bugs.sugarlabs.org make sense having the github bug tracker?

 Integration between git and the bug tracker would be pretty awesome
 (being able to close bugs by just mentioning them in the log). Though
 it's optional really, we might migrate only when we are really really
 sure we love github :)

 Mostly our sysadmins seems to hate trac. If we have to move away from
 it and if we actually move code to github, then it probably make sense
 to just use the bug tracker there and enjoy the integration.

 * Should some subpages of http://wiki.sugarlabs.org/go/Activities be moved
 to github wikis?

 I tend to think this should stay where it is, I don't like to have too
 many places where we host content, it gets confusing.

 (Well if you ask me, we shouldn't host most of our content in a wiki
 but in git, where you can keep some editorial control. But that's
 probably just me, really!)

+1 except we need a way for mere mortals to edit and view it. The
advantage of a Mediawiki is that (probably) more non-techie people
know how to use it than any other content management system.

OTOH, using git for the Sugar Journal backend has been a long-standing dream.

-walter

 ___
 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] Features for 0.100

2013-03-28 Thread Ignacio Rodríguez

I have my feature  :)

http://wiki.sugarlabs.org/go/Features/Icon_Change

PD: Walter I need the *.patch ¿Remember?


2013/3/28 Martin Abente martin.abente.lah...@gmail.com



 On Thu, Mar 28, 2013 at 7:44 AM, Daniel Narvaez dwnarv...@gmail.comwrote:

 Hello,

 we already had a bit of discussion on what 0.100 should focus on in
 the schedule thread. I'll try to summarize it here.

 IMPORTANT: the consensus seems to be that we should be having the
 discussion about features early this cycle, to try and narrow the
 scope of the release as much as possible. So here is your chance to
 propose features, there won't be a feature acceptance deadline later.

 * Simon proposed that we make html5 activities the main focus of the
 release and people responded favorably (do you think that's a bad
 idea? Please speak up!). We need to articulate better what this
 involves exactly, which new glucose components will have to be
 developed, which activities. There as been some experimentation but
 there is more left to do, the initial part of the cycle will involve
 research.

 * Ajay proposed a couple of features which has been delayed from
 previous cycles.

 http://wiki.sugarlabs.org/go/Features/Multi_selection

 There is some concern that it might be too big of a change. We should
 probably decide on the base of the patches that Ajay will be sending
 out soon.



 I hope everyone considers that the journal-multi-selection feature has
 passed through several iterations of design and code review already. This a
 great improvement to journal's usability and is already being used in the
 ground.

 It was a joint effort between many SL community members since EduJAM 2011,
 so I think there should be a consensus towards accepting it.

 http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support

 It seems to be ready to go in.

 * Walter proposed a few other features which went already through
 several reviews (do we have feature pages for these perhaps?)

 - homeview background image


 I know, at first hand, that Caacupe (Paraguay) kids will be more than
 happy with this ^. We should support also features that makes Sugar more
 enjoyable to it's users.


 - multi-homeview

 - webservices
 - comment field in journal detail view


 We should also keep in mind that webservices can offer a lot of utilities
 for deployments in the near future, and it will give Sugar a another way to
 expand its capabilities without writing-from-scratch everything.




 So 0.100 seems to be shaping up as a release devoted mainly to html5
 activities, while landing a few features which are almost ready. What
 does everyone think about that?

 --
 Daniel Narvaez
 ___
 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 mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Fwd: Tuxmath on 0.96+ mystery

2013-03-28 Thread Lionel Laské

I don't have an explanation for the installation thing, but that error is
caused by your exec line which is incorrect. sugar-activity expects the
path to a class as
 first argument, not the name of a script.

Okay. I've changed the activity.info following your advice.
Now the patched version display the home page of the activity. But when I
click on the play button, there is another error in the log file:

Traceback (most recent call last):
 File /home/olpc/Activities/Tuxmath.activity/activity.py, line
192, in _button_play_clicked_cb
   self.create_script(os.getenv(TUXMATH_SCRIPT))
 File /home/olpc/Activities/Tuxmath.activity/activity.py, line
185, in create_script
   f = open(script_path, 'w')
TypeError: coercing to Unicode: need string or buffer, NoneType
found

Not sure to understand what it means but I was interested by the
TUXMATH_SCRIPT environment variable.
I've studied the difference between the unpatched version and the patched
version related to this script call.
When I start the unpatched version it create a
/home/olpc/.sugar/default/org.ceibaljam.Tuxmath/tux_homedir/tuxmath_scrip
t.sh.
This script seems to call the binary file to execute tuxmath.
But when I launched your patched version, the script was not created. It's
why the play button do nothing.
I told that at first launch the activity seems to build something. This
something is probably this script.
BTW I don't know why it is not created when the activity is patched
before.

Any idea ?

Lionel.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Features for 0.100

On Thu, Mar 28, 2013 at 6:37 PM, Ignacio Rodríguez nachoe...@gmail.com wrote:
 I have my feature  :)

 http://wiki.sugarlabs.org/go/Features/Icon_Change

 PD: Walter I need the *.patch ¿Remember?

OK. Can you point me to the code in git?

-walter


 2013/3/28 Martin Abente martin.abente.lah...@gmail.com



 On Thu, Mar 28, 2013 at 7:44 AM, Daniel Narvaez dwnarv...@gmail.com
 wrote:

 Hello,

 we already had a bit of discussion on what 0.100 should focus on in
 the schedule thread. I'll try to summarize it here.

 IMPORTANT: the consensus seems to be that we should be having the
 discussion about features early this cycle, to try and narrow the
 scope of the release as much as possible. So here is your chance to
 propose features, there won't be a feature acceptance deadline later.

 * Simon proposed that we make html5 activities the main focus of the
 release and people responded favorably (do you think that's a bad
 idea? Please speak up!). We need to articulate better what this
 involves exactly, which new glucose components will have to be
 developed, which activities. There as been some experimentation but
 there is more left to do, the initial part of the cycle will involve
 research.

 * Ajay proposed a couple of features which has been delayed from
 previous cycles.

 http://wiki.sugarlabs.org/go/Features/Multi_selection

 There is some concern that it might be too big of a change. We should
 probably decide on the base of the patches that Ajay will be sending
 out soon.



 I hope everyone considers that the journal-multi-selection feature has
 passed through several iterations of design and code review already. This a
 great improvement to journal's usability and is already being used in the
 ground.

 It was a joint effort between many SL community members since EduJAM 2011,
 so I think there should be a consensus towards accepting it.

 http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support

 It seems to be ready to go in.

 * Walter proposed a few other features which went already through
 several reviews (do we have feature pages for these perhaps?)

 - homeview background image


 I know, at first hand, that Caacupe (Paraguay) kids will be more than
 happy with this ^. We should support also features that makes Sugar more
 enjoyable to it's users.


 - multi-homeview

 - webservices
 - comment field in journal detail view


 We should also keep in mind that webservices can offer a lot of utilities
 for deployments in the near future, and it will give Sugar a another way to
 expand its capabilities without writing-from-scratch everything.




 So 0.100 seems to be shaping up as a release devoted mainly to html5
 activities, while landing a few features which are almost ready. What
 does everyone think about that?

 --
 Daniel Narvaez
 ___
 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





-- 
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] Features for 0.100

2013-03-28 Thread Ignacio Rodríguez

Walter, you have the *.zip in your mail :P (Remember?)


2013/3/28 Walter Bender walter.ben...@gmail.com

 On Thu, Mar 28, 2013 at 6:37 PM, Ignacio Rodríguez nachoe...@gmail.com
 wrote:
  I have my feature  :)
 
  http://wiki.sugarlabs.org/go/Features/Icon_Change
 
  PD: Walter I need the *.patch ¿Remember?

 OK. Can you point me to the code in git?

 -walter
 
 
  2013/3/28 Martin Abente martin.abente.lah...@gmail.com
 
 
 
  On Thu, Mar 28, 2013 at 7:44 AM, Daniel Narvaez dwnarv...@gmail.com
  wrote:
 
  Hello,
 
  we already had a bit of discussion on what 0.100 should focus on in
  the schedule thread. I'll try to summarize it here.
 
  IMPORTANT: the consensus seems to be that we should be having the
  discussion about features early this cycle, to try and narrow the
  scope of the release as much as possible. So here is your chance to
  propose features, there won't be a feature acceptance deadline later.
 
  * Simon proposed that we make html5 activities the main focus of the
  release and people responded favorably (do you think that's a bad
  idea? Please speak up!). We need to articulate better what this
  involves exactly, which new glucose components will have to be
  developed, which activities. There as been some experimentation but
  there is more left to do, the initial part of the cycle will involve
  research.
 
  * Ajay proposed a couple of features which has been delayed from
  previous cycles.
 
  http://wiki.sugarlabs.org/go/Features/Multi_selection
 
  There is some concern that it might be too big of a change. We should
  probably decide on the base of the patches that Ajay will be sending
  out soon.
 
 
 
  I hope everyone considers that the journal-multi-selection feature has
  passed through several iterations of design and code review already.
 This a
  great improvement to journal's usability and is already being used in
 the
  ground.
 
  It was a joint effort between many SL community members since EduJAM
 2011,
  so I think there should be a consensus towards accepting it.
 
  http://wiki.sugarlabs.org/go/Features/3G_Support/Database_Support
 
  It seems to be ready to go in.
 
  * Walter proposed a few other features which went already through
  several reviews (do we have feature pages for these perhaps?)
 
  - homeview background image
 
 
  I know, at first hand, that Caacupe (Paraguay) kids will be more than
  happy with this ^. We should support also features that makes Sugar more
  enjoyable to it's users.
 
 
  - multi-homeview
 
  - webservices
  - comment field in journal detail view
 
 
  We should also keep in mind that webservices can offer a lot of
 utilities
  for deployments in the near future, and it will give Sugar a another
 way to
  expand its capabilities without writing-from-scratch everything.
 
 
 
 
  So 0.100 seems to be shaping up as a release devoted mainly to html5
  activities, while landing a few features which are almost ready. What
  does everyone think about that?
 
  --
  Daniel Narvaez
  ___
  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
 
 



 --
 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] Tuxmath on 0.96+ mystery

On 28 March 2013 23:21, Lionel Laské lionel.la...@gmail.com wrote:

I don't have an explanation for the installation thing, but that error is
 caused by your exec line which is incorrect. sugar-activity expects the
 path to a class as
 first argument, not the name of a script.

 Okay. I've changed the activity.info following your advice.
 Now the patched version display the home page of the activity. But when I
 click on the play button, there is another error in the log file:

 Traceback (most recent call last):
  File /home/olpc/Activities/Tuxmath.activity/activity.py, line
 192, in _button_play_clicked_cb
self.create_script(os.getenv(TUXMATH_SCRIPT))
  File /home/olpc/Activities/Tuxmath.activity/activity.py, line
 185, in create_script
f = open(script_path, 'w')
 TypeError: coercing to Unicode: need string or buffer, NoneType
 found

It means TUXMATH_SCRIPT is unset. As I said the tuxmath-activity
script does more than running sugar-activity, including setting
TUXMATH_SCRIPT.

Did you try to leave the exec line unmodified? What error do you get
if you do that?
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] Github review workflow

Hi,

I started experimenting a bit with github code reviews, with Walter as
ginuea pig :) We wasn't too sure about stuff like rebasing, using
separate branches etc, so tonight I played a bit myself with creating
pull requests.

Something like the following might be a decent start for a workflow

1 Create one branch per topic

git checkout -b topic1

2 Make one or more commits
3 Push the branch

git push origin topic1

4 Submit a pull request for the branch (web UI)

5a The reviewer merges the patch.
5b The reviewer rejects the patch (and closes the request).
5c The reviewer requires changes (and closes the request).

If 5c:

6 Make changes using interactive rebase
(http://git-scm.com/book/en/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages)

git rebase -i master

7 Push the changes to another remote branch

git push origin topic1:topic1-try2

8 Submit the new pull request (web UI)


If someone has experience with github suggestions would be welcome.
Otherwise I hope Walter will keep being the ginuea pig in this
experiment  :)

-- 
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Tuxmath on 0.96+ mystery