Re: [Sugar-devel] [DESIGN] Proposal: Lease expiry information display in My Settings -> About My Computer
On Wed, Jul 18, 2012 at 1:07 PM, Anish Mangal wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi, > > I would like to propose a feature for discussion and inclusion in the > 0.98 cycle. > > http://wiki.sugarlabs.org/go/Features/Lease_Information_Display > > This feature, which has been tested to work on 0.94 based dextrose-3 > builds, displays information relating to lease expiry in the about my > computer section in the my settings menu. > > This feature is valuable for support staff in deployments which use > OLPC's security system built on the XO laptops, and was specifically > requested by the OLPC deployment in Paraguay. > > Please go through the feature page for a more in-depth explanation and > a screenshot. Looking forward to discussion and answering queries. > > +1 to me, it's been used in dextrose w/o problems. > Cheers, > Anish > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJQBvtoAAoJEBoxUdDHDZVp/MkH/R8FAidMLuPlxGzZ+kqJvInY > 7ZW+pDwNjunZv8NVEQ7iRyVgupti7/n5ENuME4HOQNj7Wb3LrOF08yF/jBfBhrKW > kUp3MJtMQ3zHM2HcVHwwA4v/LcQC6kVwePWvQSPodkqVhZuNPIYfajyOfYB7vK6H > +9xRKP3O6cFb9sVJZFdpSCNg0hiqPcreZbROOYL/XY6zQZ5pjlIEvsTRcdRa+dfg > MYGzIo04n42MMVZIFgo8kXCjUlj1MhPecGiQ9W6ChSGd4kyR0VALlO78yncsfFRF > wfKge/R0qTZKIs0DqvsIhA6Z2E953E/im0bvpjktkuQ1CKEs2P9/s/87CVepDQg= > =lBtG > -END PGP SIGNATURE- > ___ > 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] [DESIGN] Proposal: Lease expiry information display in My Settings -> About My Computer
Personally I think this would be a reasonable feature. But prior to this discussion I have never heard of the word "expiry" before. In US English the synonym "expiration" tends to be used much more often. I do not know what the preferred international form is. --- SJG On Thu, Jul 19, 2012 at 10:40 AM, Rafael Ortiz wrote: > > > On Wed, Jul 18, 2012 at 1:07 PM, Anish Mangal > wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi, >> >> I would like to propose a feature for discussion and inclusion in the >> 0.98 cycle. >> >> http://wiki.sugarlabs.org/go/Features/Lease_Information_Display >> >> This feature, which has been tested to work on 0.94 based dextrose-3 >> builds, displays information relating to lease expiry in the about my >> computer section in the my settings menu. >> >> This feature is valuable for support staff in deployments which use >> OLPC's security system built on the XO laptops, and was specifically >> requested by the OLPC deployment in Paraguay. >> >> Please go through the feature page for a more in-depth explanation and >> a screenshot. Looking forward to discussion and answering queries. >> >> > +1 to me, it's been used in dextrose w/o problems. > > > >> Cheers, >> Anish >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.12 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iQEcBAEBAgAGBQJQBvtoAAoJEBoxUdDHDZVp/MkH/R8FAidMLuPlxGzZ+kqJvInY >> 7ZW+pDwNjunZv8NVEQ7iRyVgupti7/n5ENuME4HOQNj7Wb3LrOF08yF/jBfBhrKW >> kUp3MJtMQ3zHM2HcVHwwA4v/LcQC6kVwePWvQSPodkqVhZuNPIYfajyOfYB7vK6H >> +9xRKP3O6cFb9sVJZFdpSCNg0hiqPcreZbROOYL/XY6zQZ5pjlIEvsTRcdRa+dfg >> MYGzIo04n42MMVZIFgo8kXCjUlj1MhPecGiQ9W6ChSGd4kyR0VALlO78yncsfFRF >> wfKge/R0qTZKIs0DqvsIhA6Z2E953E/im0bvpjktkuQ1CKEs2P9/s/87CVepDQg= >> =lBtG >> -END PGP SIGNATURE- >> ___ >> 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] [ASLO] Release Distance-33
Activity Homepage: http://activities.sugarlabs.org/addon/4264 Sugar Platform: 0.96 - 0.96 Download Now: http://activities.sugarlabs.org/downloads/file/28165/distance-33.xo Release notes: *First release based on GTK3, only sugar-0.96 and posterior compatible (flavio danesse fdane...@activitycentral.com, rafael ortiz raf...@activitycentral.com). == Notes == We still have http://bugs.sugarlabs.org/ticket/3386, clicking on share icon in toolbar should open the palettes with options. 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] [PATCH] Add abiword python bindings
From: Martin Abente Lahaye
Without this package Write activity won't start.
Adding it again, otherwise fedora users won't be
able to enjoy this activity out-of-the-box.
Signed-off-by: Martin Abente Lahaye
---
scripts/check-system |4
1 file changed, 4 insertions(+)
diff --git a/scripts/check-system b/scripts/check-system
index f4ff56a..f127588 100755
--- a/scripts/check-system
+++ b/scripts/check-system
@@ -255,6 +255,10 @@ checks = \
"checker": "gstreamer",
"packages": { "fedora": "gstreamer-plugins-good",
"ubuntu": "gstreamer0.10-plugins-good" } },
+ { "check": "import abiword",
+ "checker": "python",
+ "packages": { "fedora": "pyabiword",
+ "ubuntu": "python-abiword" } },
# System modules buildtime
--
1.7.10.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add abiword python bindings
Pushed. Thanks!
(please use a subject like [PATCH sugar-build] or something to make
sure I don't miss patches).
On 19 July 2012 23:42, wrote:
> From: Martin Abente Lahaye
>
> Without this package Write activity won't start.
>
> Adding it again, otherwise fedora users won't be
> able to enjoy this activity out-of-the-box.
>
> Signed-off-by: Martin Abente Lahaye
> ---
> scripts/check-system |4
> 1 file changed, 4 insertions(+)
>
> diff --git a/scripts/check-system b/scripts/check-system
> index f4ff56a..f127588 100755
> --- a/scripts/check-system
> +++ b/scripts/check-system
> @@ -255,6 +255,10 @@ checks = \
> "checker": "gstreamer",
> "packages": { "fedora": "gstreamer-plugins-good",
> "ubuntu": "gstreamer0.10-plugins-good" } },
> + { "check": "import abiword",
> + "checker": "python",
> + "packages": { "fedora": "pyabiword",
> + "ubuntu": "python-abiword" } },
>
> # System modules buildtime
>
> --
> 1.7.10.4
>
--
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add abiword python bindings
Thanks! I really like this building system.
In case ubuntu user have have troubles with the python-abiword package, I
think it could be replace by just the empty string so it will be simply
ignored (If i got it right). And fedora user won't be affected.
On Thu, Jul 19, 2012 at 1:03 PM, Daniel Narvaez wrote:
> Pushed. Thanks!
>
> (please use a subject like [PATCH sugar-build] or something to make
> sure I don't miss patches).
>
> On 19 July 2012 23:42, wrote:
> > From: Martin Abente Lahaye
> >
> > Without this package Write activity won't start.
> >
> > Adding it again, otherwise fedora users won't be
> > able to enjoy this activity out-of-the-box.
> >
> > Signed-off-by: Martin Abente Lahaye
> > ---
> > scripts/check-system |4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/scripts/check-system b/scripts/check-system
> > index f4ff56a..f127588 100755
> > --- a/scripts/check-system
> > +++ b/scripts/check-system
> > @@ -255,6 +255,10 @@ checks = \
> > "checker": "gstreamer",
> > "packages": { "fedora": "gstreamer-plugins-good",
> > "ubuntu": "gstreamer0.10-plugins-good" } },
> > + { "check": "import abiword",
> > + "checker": "python",
> > + "packages": { "fedora": "pyabiword",
> > + "ubuntu": "python-abiword" } },
> >
> > # System modules buildtime
> >
> > --
> > 1.7.10.4
> >
>
>
>
> --
> Daniel Narvaez
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [DESIGN] Examples objects support for activities.
Hello Everyone: In a recent conversation with Walter, he mentioned that it would be very useful if activities could include examples objects. From my experience in the field, I can tell this feature can be a really useful indeed. Therefore I would like to bring this idea to the general discussion and see what others think. The idea is simple: Activities include examples objects that can be bundled with and accessed from the activity. For the ones that also think this could be useful: I am sure you must have your own vision of how this feature should work and look like, so please share it here. In general terms and from my POV it should be something: (a) simple to access. (b) with a familiar interface to the users. (c) low-cost for activities developers to include. (d) Safe. One of the ideas, that meets these requirements, is to include a standard "Examples" folder in the activities root directory that would be accessible through a regular ObjetChooser. The ObjectChooser is already capable of presenting any folder's contents, thanks to recent years improvement in the journal to present external-media and documents-folder contents. Accessing to these objects would be as easy as just opening a ObjectChooser instance, many activities already do this (but limited to journal content). As I just said, the ObjectChooser interface is widely used, therefore users are already familiar with it. To ease the costs for activities developers I think that having this standard folder approach is crucial. One open question I still have is how this ObjectChooser should be opened from the activities in a standard way (suggestions?). By "safe" I mean that it should guarantee that it only presents this standard folder objects in read-only mode (at least from the GUI POV). I will stop here and I would like to hear what you guys think regarding the general idea first. Saludos. tincho. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Add abiword python bindings
Yup, keeping an eye on the buildbot to see what happens in Ubuntu.
On Thursday, 19 July 2012, Martin Abente wrote:
> Thanks! I really like this building system.
>
> In case ubuntu user have have troubles with the python-abiword package, I
> think it could be replace by just the empty string so it will be simply
> ignored (If i got it right). And fedora user won't be affected.
>
> On Thu, Jul 19, 2012 at 1:03 PM, Daniel Narvaez
>
> > wrote:
>
>> Pushed. Thanks!
>>
>> (please use a subject like [PATCH sugar-build] or something to make
>> sure I don't miss patches).
>>
>> On 19 July 2012 23:42, > 'cvml', 'martin.abente.lah...@gmail.com');>>
>> wrote:
>> > From: Martin Abente Lahaye > 'cvml', 't...@sugarlabs.org');>>
>> >
>> > Without this package Write activity won't start.
>> >
>> > Adding it again, otherwise fedora users won't be
>> > able to enjoy this activity out-of-the-box.
>> >
>> > Signed-off-by: Martin Abente Lahaye > > 'cvml', 't...@sugarlabs.org');>
>> >
>> > ---
>> > scripts/check-system |4
>> > 1 file changed, 4 insertions(+)
>> >
>> > diff --git a/scripts/check-system b/scripts/check-system
>> > index f4ff56a..f127588 100755
>> > --- a/scripts/check-system
>> > +++ b/scripts/check-system
>> > @@ -255,6 +255,10 @@ checks = \
>> > "checker": "gstreamer",
>> > "packages": { "fedora": "gstreamer-plugins-good",
>> > "ubuntu": "gstreamer0.10-plugins-good" } },
>> > + { "check": "import abiword",
>> > + "checker": "python",
>> > + "packages": { "fedora": "pyabiword",
>> > + "ubuntu": "python-abiword" } },
>> >
>> > # System modules buildtime
>> >
>> > --
>> > 1.7.10.4
>> >
>>
>>
>>
>> --
>> Daniel Narvaez
>>
>
>
--
Daniel Narvaez
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Examples objects support for activities.
On Thu, Jul 19, 2012 at 1:40 PM, Martin Abente wrote: > Hello Everyone: > > In a recent conversation with Walter, he mentioned that it would be very > useful if activities could include examples objects. From my experience in > the field, I can tell this feature can be a really useful indeed. Therefore > I would like to bring this idea to the general discussion and see what > others think. > > The idea is simple: Activities include examples objects that can be bundled > with and accessed from the activity. > > For the ones that also think this could be useful: I am sure you must have > your own vision of how this feature should work and look like, so please > share it here. > > In general terms and from my POV it should be something: > > (a) simple to access. > (b) with a familiar interface to the users. > (c) low-cost for activities developers to include. > (d) Safe. > > One of the ideas, that meets these requirements, is to include a standard > "Examples" folder in the activities root directory that would be accessible > through a regular ObjetChooser. The ObjectChooser is already capable of > presenting any folder's contents, thanks to recent years improvement in the > journal to present external-media and documents-folder contents. > > Accessing to these objects would be as easy as just opening a ObjectChooser > instance, many activities already do this (but limited to journal content). > As I just said, the ObjectChooser interface is widely used, therefore users > are already familiar with it. To ease the costs for activities developers I > think that having this standard folder approach is crucial. One open > question I still have is how this ObjectChooser should be opened from the > activities in a standard way (suggestions?). By "safe" I mean that it should > guarantee that it only presents this standard folder objects in read-only > mode (at least from the GUI POV). > > I will stop here and I would like to hear what you guys think regarding the > general idea first. > > Saludos. > tincho. > +1 The only other thing might be to extend the object chooser to be able to show "preview" images in addition to text listings. So, for example, I could generate a preview image for each Turtle Art example and let the user browse these as thumbnails. 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] [DESIGN] Examples objects support for activities.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 19 July 2012 11:10 PM, Martin Abente wrote: > Hello Everyone: > > In a recent conversation with Walter, he mentioned that it would be > very useful if activities could include examples objects. From my > experience in the field, I can tell this feature can be a really > useful indeed. Therefore I would like to bring this idea to the > general discussion and see what others think. > > The idea is simple: Activities include examples objects that can > be bundled with and accessed from the activity. > > For the ones that also think this could be useful: I am sure you > must have your own vision of how this feature should work and look > like, so please share it here. > > In general terms and from my POV it should be something: > > (a) simple to access. (b) with a familiar interface to the users. > (c) low-cost for activities developers to include. (d) Safe. > What kind of objects are we looking at? I assume it could mean: * Some sample programs in case of TA * Some sample setups in the physics activity The current way to go about doing that would be sample journal entries, so would I be correct in assuming that we're looking for a way to group those journal entries (in a way)? If not, and it's only the 'activity author/developer' that has the ability to bundle these example objects, then it places limitations. You'd ideally want to have teachers and others be able to bundle these examples as they best see them fit according to curriculum. > One of the ideas, that meets these requirements, is to include a > standard "Examples" folder in the activities root directory that > would be accessible through a regular ObjetChooser. The > ObjectChooser is already capable of presenting any folder's > contents, thanks to recent years improvement in the journal to > present external-media and documents-folder contents. > > Accessing to these objects would be as easy as just opening a > ObjectChooser instance, many activities already do this (but > limited to journal content). As I just said, the ObjectChooser > interface is widely used, therefore users are already familiar with > it. To ease the costs for activities developers I think that having > this standard folder approach is crucial. One open question I still > have is how this ObjectChooser should be opened from the > activities in a standard way (suggestions?). By "safe" I mean that > it should guarantee that it only presents this standard folder > objects in read-only mode (at least from the GUI POV). > > I will stop here and I would like to hear what you guys think > regarding the general idea first. > > Saludos. tincho. > > > > ___ Sugar-devel mailing > list Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > - -- Anish -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQCGVJAAoJEBoxUdDHDZVpDHkH+wY9JVTbDbnrDUYbsZnOgSqu qKYQH+7buCk3OYlvJFH2eRiZTf9AZQpQ4DXBpipjoYy5vvPGEtljZ9roCV4Oj5T6 0LHu+LLKLVmZqDcIHtBMOxNeDqD3/VoHka0e8FQP9FR72WKDiuuj+wd/nxAyM74P jGIMmFJs7c0O7z8MpbKCdoYkSlWPO77G6nlgwGxaKT0i+iiBucdQWOw97hLa0zMF LUMu1foZvAuDTpgo/FyVOeUbu4dJpG1QHDNJsqZtHPYjbUNjLinLUh8LGmr2LvqA CxeNqYtd3OrAVRUvedhoYvmWNakZ/waUj7TybnuSQZq/1VUqY+gsWexPi7kU8CY= =Dfal -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Examples objects support for activities.
On 19 Jul 2012, at 18:40, Martin Abente wrote: > Hello Everyone: > > In a recent conversation with Walter, he mentioned that it would be very > useful if activities could include examples objects. From my experience in > the field, I can tell this feature can be a really useful indeed. Therefore I > would like to bring this idea to the general discussion and see what others > think. > > The idea is simple: Activities include examples objects that can be bundled > with and accessed from the activity. > > For the ones that also think this could be useful: I am sure you must have > your own vision of how this feature should work and look like, so please > share it here. > > In general terms and from my POV it should be something: > > (a) simple to access. > (b) with a familiar interface to the users. > (c) low-cost for activities developers to include. > (d) Safe. > > One of the ideas, that meets these requirements, is to include a standard > "Examples" folder in the activities root directory that would be accessible > through a regular ObjetChooser. The ObjectChooser is already capable of > presenting any folder's contents, thanks to recent years improvement in the > journal to present external-media and documents-folder contents. > > Accessing to these objects would be as easy as just opening a ObjectChooser > instance, many activities already do this (but limited to journal content). > As I just said, the ObjectChooser interface is widely used, therefore users > are already familiar with it. To ease the costs for activities developers I > think that having this standard folder approach is crucial. One open question > I still have is how this ObjectChooser should be opened from the activities > in a standard way (suggestions?). By "safe" I mean that it should guarantee > that it only presents this standard folder objects in read-only mode (at > least from the GUI POV). Sounds good +1, we already have an icon design for activity 'collections', see Turtle Art for an example, but it is basically a small version of the activity icon, a box container with an arrow coming out of it (Walter currently raises a completely un-sugarised and scary GNOME file dialogue pointing inside a folder in the TA bundle, so it would be good to see this go ;) ). > > I will stop here and I would like to hear what you guys think regarding the > general idea first. I've added it to the agenda for Mondays design meeting. Regards, --Gary > > Saludos. > tincho. > > ___ > 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] [DESIGN] Examples objects support for activities.
On Thu, Jul 19, 2012 at 3:51 PM, Anish Mangal wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Thursday 19 July 2012 11:10 PM, Martin Abente wrote: > > Hello Everyone: > > > > In a recent conversation with Walter, he mentioned that it would be > > very useful if activities could include examples objects. From my > > experience in the field, I can tell this feature can be a really > > useful indeed. Therefore I would like to bring this idea to the > > general discussion and see what others think. > > > > The idea is simple: Activities include examples objects that can > > be bundled with and accessed from the activity. > > > > For the ones that also think this could be useful: I am sure you > > must have your own vision of how this feature should work and look > > like, so please share it here. > > > > In general terms and from my POV it should be something: > > > > (a) simple to access. (b) with a familiar interface to the users. > > (c) low-cost for activities developers to include. (d) Safe. > > > > What kind of objects are we looking at? I assume it could mean: > * Some sample programs in case of TA > * Some sample setups in the physics activity > > Exactly that kind of objects. > The current way to go about doing that would be sample journal > entries, so would I be correct in assuming that we're looking for a > way to group those journal entries (in a way)? > > Its about delivering these examples with the activity package and having them separately from the journal. > If not, and it's only the 'activity author/developer' that has the > ability to bundle these example objects, then it places limitations. > You'd ideally want to have teachers and others be able to bundle these > examples as they best see them fit according to curriculum. > > I don't think is a limitation since these are just separate things, teachers could still deliver their own examples as they do now. In more complex scenarios we could think of ways of how to easily redefine these examples. > > One of the ideas, that meets these requirements, is to include a > > standard "Examples" folder in the activities root directory that > > would be accessible through a regular ObjetChooser. The > > ObjectChooser is already capable of presenting any folder's > > contents, thanks to recent years improvement in the journal to > > present external-media and documents-folder contents. > > > > Accessing to these objects would be as easy as just opening a > > ObjectChooser instance, many activities already do this (but > > limited to journal content). As I just said, the ObjectChooser > > interface is widely used, therefore users are already familiar with > > it. To ease the costs for activities developers I think that having > > this standard folder approach is crucial. One open question I still > > have is how this ObjectChooser should be opened from the > > activities in a standard way (suggestions?). By "safe" I mean that > > it should guarantee that it only presents this standard folder > > objects in read-only mode (at least from the GUI POV). > > > > I will stop here and I would like to hear what you guys think > > regarding the general idea first. > > > > Saludos. tincho. > > > > > > > > ___ Sugar-devel mailing > > list Sugar-devel@lists.sugarlabs.org > > http://lists.sugarlabs.org/listinfo/sugar-devel > > > > - -- > Anish > > > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.12 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJQCGVJAAoJEBoxUdDHDZVpDHkH+wY9JVTbDbnrDUYbsZnOgSqu > qKYQH+7buCk3OYlvJFH2eRiZTf9AZQpQ4DXBpipjoYy5vvPGEtljZ9roCV4Oj5T6 > 0LHu+LLKLVmZqDcIHtBMOxNeDqD3/VoHka0e8FQP9FR72WKDiuuj+wd/nxAyM74P > jGIMmFJs7c0O7z8MpbKCdoYkSlWPO77G6nlgwGxaKT0i+iiBucdQWOw97hLa0zMF > LUMu1foZvAuDTpgo/FyVOeUbu4dJpG1QHDNJsqZtHPYjbUNjLinLUh8LGmr2LvqA > CxeNqYtd3OrAVRUvedhoYvmWNakZ/waUj7TybnuSQZq/1VUqY+gsWexPi7kU8CY= > =Dfal > -END PGP SIGNATURE- > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Design meeting Monday July 23rd 2012 - 14:30 UTC 1hr
Hi folks, It's a quick turnaround for our next design meeting on Monday, this time slightly earlier at 14:30 UTC. The plan is to keep the meetings to 1 hour, or under, and use our realtime meeting to keep the various design efforts ticking over and everyone who in interested up to date with progress made. I'm hoping the majority of design conversation will take place in mail-list design threads, wiki pages and or bug.SL.org tickets. Proposal & mail-list links for some of the below agenda items are at: http://wiki.sugarlabs.org/go/Design_Team/Meetings Provisional agenda * Journal multi-select * Touch hardware support Activities, Sugar Shell, OSK. * Re-assessment of text-to-speech engine options, in particular think about how we can improve upstream voices to cover more of our languages, mail-list thread. cjl * "Examples" support for activities – use Journal volumes strip and/or ObjectChooser to allow Activities to provide access to an examples folder inside their bundles. tch * Lease expiry information display in My Settings -> About My Computer, mail-list thread, wiki proposal. Anish * Time: Monday July 23rd 2012 - 14:30 UTC 1hr Place: #sugar-meeting Hope to see you there! Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Proposal: Lease expiry information display in My Settings -> About My Computer
I don't think it should be in a section titled "Identity", because it isn't an identifier, and is only related to serial number because of implementation details. I don't wish to constrain your creativity by saying how to fix that though. I'm sure you can imagine many alternatives. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Design meeting Monday July 23rd 2012 - 14:30 UTC 1hr
2012/7/19 Gary Martin : > Provisional agenda > * Journal multi-select I have School at 14:30 UTC, so I tell now my position about the Journal multi-select implementation. The function is very useful here in Uruguay, it's necessary in Sugar. But I think the UI implementation isn't the best. It has two toggle cell renderers one next to the other (I consider the star a toggle cell). A better way would be use the TreeSelection. But if the agreed implemented interface is with CheckBoxes, I would suggest to move the ToogleStar to the right, with the following organization. [[Checker] [Icon] . [Buddies] . . . . . [Last modified] [Star] (>)] Cheers. -danielf ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Design meeting Monday July 23rd 2012 - 14:30 UTC 1hr
Hi Daniel, On 19 Jul 2012, at 23:37, S. Daniel Francis wrote: > 2012/7/19 Gary Martin : > >> Provisional agenda >> * Journal multi-select > > I have School at 14:30 UTC, so I tell now my position about the > Journal multi-select implementation. Thanks, noted, the Monday time is just test to see who can make which times, looks like we'll need to have the Design Meeting on two different days and times so everyone interested can make it to some meetings. > The function is very useful here in Uruguay, it's necessary in Sugar. > But I think the UI implementation isn't the best. It has two toggle > cell renderers one next to the other (I consider the star a toggle > cell). A better way would be use the TreeSelection. Could you describe a little more what you mean by TreeSelection, I do not quite follow. I'm also not so keen on all the check boxed always cluttering up the view, one way to resolve this could be to have a button in the toolbar that switches to multi select mode (only then revealing all the check boxes). Apple designs use this extensively, they support list views that have an 'Edit' button in the toolbar, when you tap 'Edit' check boxes appear next to all list items and you get to make a multi selection, and usually a new toolbar appears with things like 'Delete' 'Move' for group actions. > But if the agreed > implemented interface is with CheckBoxes, I would suggest to move the > ToogleStar to the right, with the following organization. > > [[Checker] [Icon] . [Buddies] . . . . . [Last modified] [Star] (>)] Thanks for the feedback, we'll likely continue the discussion here in this mail thread for a while even after this Mondays meeting. Regards, --Gary > Cheers. > -danielf ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Examples objects support for activities.
Hello Tincho! Nice to read you here again :) I agree this can be a very good addition, and I see think we need solve two different parts: 1) Access the examples in the activities: using a widget similar to the object chooser, but showing files in a directory. I think Silbe said, the actual Object Chooser can't do it, due to limitations in the actual Journal implementation. (Sascha, can you confirm?) Probably we can create a a similar widget if is not possible use the original ObjectChooser, and should be great can show a preview if available. 2) Distribution of examples: This can be more controversial, but is related and should be good address in a related proposal. Today, there are activities as Turtle Confusion or Amazonas Tortugas, based on TurtleArt and may be can be data files added to TurtleArt. Also, if we provide a way to distribute examples, the deployments could generate them based in local needs. Other activities can be enhanced using examples, and if they have text should be difficult support i18n in the data files. May be we can create a variation of the infamous XOL files, with the information about what activity should manage them, and improve the installation to install them in a different place than Library (or the activities can look at the Library for examples) Gonzalo On Thu, Jul 19, 2012 at 2:40 PM, Martin Abente wrote: > Hello Everyone: > > In a recent conversation with Walter, he mentioned that it would be very > useful if activities could include examples objects. From my experience in > the field, I can tell this feature can be a really useful indeed. Therefore > I would like to bring this idea to the general discussion and see what > others think. > > The idea is simple: Activities include examples objects that can be bundled > with and accessed from the activity. > > For the ones that also think this could be useful: I am sure you must have > your own vision of how this feature should work and look like, so please > share it here. > > In general terms and from my POV it should be something: > > (a) simple to access. > (b) with a familiar interface to the users. > (c) low-cost for activities developers to include. > (d) Safe. > > One of the ideas, that meets these requirements, is to include a standard > "Examples" folder in the activities root directory that would be accessible > through a regular ObjetChooser. The ObjectChooser is already capable of > presenting any folder's contents, thanks to recent years improvement in the > journal to present external-media and documents-folder contents. > > Accessing to these objects would be as easy as just opening a ObjectChooser > instance, many activities already do this (but limited to journal content). > As I just said, the ObjectChooser interface is widely used, therefore users > are already familiar with it. To ease the costs for activities developers I > think that having this standard folder approach is crucial. One open > question I still have is how this ObjectChooser should be opened from the > activities in a standard way (suggestions?). By "safe" I mean that it should > guarantee that it only presents this standard folder objects in read-only > mode (at least from the GUI POV). > > I will stop here and I would like to hear what you guys think regarding the > general idea first. > > Saludos. > tincho. > > > ___ > 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] [ANNOUNCE] Design meeting Monday July 23rd 2012 - 14:30 UTC 1hr
> Could you describe a little more what you mean by TreeSelection About the Tree Selection, as you'll possibly know, the Journal was migrated from HippoCanvas to Gtk as a GtkTreeView. The GtkTreeSelection is for customize selections in GtkTreeViews: http://python-gtk-3-tutorial.readthedocs.org/en/latest/treeview.html#the-selection The starter idea about this was by Agustin Zubiaga (aguz), I tell the part I agree, but he has projected all the details for a purpose similar than the interface you describe, Gary. Personally, I don't like 'ghost' toolbars[1] in Sugar, but the buttons need a place, maybe a Sugar ToolbarButton and the property 'expanded' set to True and why not take advantage of that button for also enable/disable the MultiSelect mode. Cheers. [1] When all the buttons of the toolbar change for other different options. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Design Team agenda item: TTS, e-speak and voices
Thanks Chris by putting this topic on the table. Overall, I am no sure this is a topic to the Design Team, anyway, I will add a few comments below... On Wed, Jul 18, 2012 at 2:11 PM, Chris Leonard wrote: > Agenda item: TTS, e-speak and voices > > Summary: > We now have text-to-spech everywhere via e-speak, before we get too > far into speech engine technology "lock-in" we should thoughtfully > assess festival (or other options). In particular, we need to think > about how we can improve upstream voices to cover more of our user's > languages. > +1 In particular, would be great have the option to use better voices. In general better voices mean bigger data files, but if a local deployment can decide use it or not, is ok. We need research: * Can we use mbrola voices? (http://espeak.sourceforge.net/mbrola.html) * Gnome-speech: When I implemented the tts feature in sugar, tried to use gnome-speach to have a layer where we can use espeak or festival voices, but at the moment I tested it, festival voices were not recognized, then I decided use espeak only. We can change that if found a better solution. We should test again (a quick test in F17, only show a festival voice) * Move speech to sugar-toolkit: we have a lot of code copy pasted in the activities to implement tts. Having a central implementation should solve a lot of problems. > Issues: > > 1) e-speak currently has a limited repertoire of languages that it > "understands": > > http://espeak.sourceforge.net/languages.html > > The e-speak voice list is far shorter than the list of languages that > Sugar currently supports, making this in part a i18n/L10n issue. > > 2) However, e-speak is flexible and can be "taught" new languages by > means of creating new voice files. > > http://espeak.sourceforge.net/voices.html > > AFAIK, none of us at Sugar Labs or OLPC have ever created a new voice > file for e-speak before, so I can't give you a reliable estimate of > the challenges involved. That process should be investigated > systematically by a small team (to include at least a developer and a > localizer). > > 3) There are alternative speech engines and voice file formats (e.g. > festival) that have may have better quality or features, but this > almost certainly comes with trade-offs in size-on-disk and performance > (particularly on the large XO-1 installed base), making this partly a > UI developer issue of backwards compatibility. > > 4) Text-to-speech is an important feature for visually-impaired users, > making this in part an accessibility (a11y) issue. > > 5) AFAIK, e-speak is not currently packaged for Debian/Ubuntu, which > raises issues for non-Fedora-based Sugar users that could be addressed > by collaborating on packaging e-speak, which is a developer/packager > issue. > I think the problem is not espeak, but the gstreamer espeak plugin. > Conclusion: > > TTS touches many aspects of UI design, has many stakeholders and > requires careful investigation before proceeding further along our > current path. > > Suggested courses of action: > > 1) Identify someone willing to package / maintain e-speeak for Ubuntu > (dnarvaez?) > Check what is the missing package. > 2) Investigate other speech engines and their collectins of voices, > the complexity of creating new voices and hardware performance > characteristics on OLPC hardware. > +1 > 3) Investigate (and importantly, document) the process of developing > new voices or improving existing voices for e-speak (on assumption > that we will stick with it as our speech engine). A good pilot effort > might be to fine-tune English (en_rp) for Australia (see OLPC_OZ > tickets linked below) or Spanish, Latin America (es_la) voices for a > national variant like Peru. The main goal of such an effort should be > not so much the voice itself (though either of these could be great to > have), but understanding the process by which e-speak voice > development is accomplished and developing internal expertise in this > process that can be teamed up with other Sugar localizers as needed to > develop additional voices for our other supported languages. > I don't know how difficult this can be, but quidam said is very difficult create good voice files. I think we need find other groups of experts in the topic and try to create alliances. Many of the voices are created by universities. There are a long but useful HOWTO about using different voices in Festival, (is old and for Ubuntu, but is ok) http://ubuntuforums.org/showthread.php?t=751169 Gonzalo ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] Design meeting Monday July 23rd 2012 - 14:30 UTC 1hr
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Daniel, Gary, The design we settled on closely follows the design of the Gmail interface. I personally don't see it a big issue with the extra check boxes, because we seem to have plenty of horizontal space per row of a journal entry. IMHO moving the stars to the right wont be very intuitive. - From what I could understand, using TreeSelection would do away with the checkboxes, and not provide an UI element as feedback, which will be counter intuitive. Or maybe I don't understand what you're proposing. (A screenshot would help) On Friday 20 July 2012 04:39 AM, Gary Martin wrote: > Hi Daniel, > > On 19 Jul 2012, at 23:37, S. Daniel Francis wrote: > >> 2012/7/19 Gary Martin : >> >>> Provisional agenda * Journal multi-select >> >> I have School at 14:30 UTC, so I tell now my position about the >> Journal multi-select implementation. > > Thanks, noted, the Monday time is just test to see who can make > which times, looks like we'll need to have the Design Meeting on > two different days and times so everyone interested can make it to > some meetings. > >> The function is very useful here in Uruguay, it's necessary in >> Sugar. But I think the UI implementation isn't the best. It has >> two toggle cell renderers one next to the other (I consider the >> star a toggle cell). A better way would be use the >> TreeSelection. > > Could you describe a little more what you mean by TreeSelection, I > do not quite follow. I'm also not so keen on all the check boxed > always cluttering up the view, one way to resolve this could be to > have a button in the toolbar that switches to multi select mode > (only then revealing all the check boxes). Apple designs use this > extensively, they support list views that have an 'Edit' button in > the toolbar, when you tap 'Edit' check boxes appear next to all > list items and you get to make a multi selection, and usually a new > toolbar appears with things like 'Delete' 'Move' for group > actions. > >> But if the agreed implemented interface is with CheckBoxes, I >> would suggest to move the ToogleStar to the right, with the >> following organization. >> >> [[Checker] [Icon] . [Buddies] . . . . . [Last modified] [Star] >> (>)] > > Thanks for the feedback, we'll likely continue the discussion here > in this mail thread for a while even after this Mondays meeting. > > Regards, --Gary > >> Cheers. -danielf > > ___ Sugar-devel mailing > list Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > - -- Anish -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQCNkWAAoJEBoxUdDHDZVp228IAIpsKYFbrAjdN/QOFwoEKWWW zhvmpBl5WwZiMfvaG2jDozXGD4liGG+WXMG5sWfuRytKngtyqCwt5tMzRYxsl+fI X78/stovS7W++SloJWfnJ5kfG798QIL2cp+xeu1W+7cJum5pbv2M7bFBHAVJPKdd EO+y9YxNQAXIfjJW5luIYgYJFETJ9na2Ulb2z8NkN209qPbQCVsg3FSu/ZHOdN6i hLgx7fmtjGOcJHy61j+vIhOgWrzVtxuNdBkkHn7CoKbOa3+6a2cuXbGD5fGGyTwj gJG2Q7Uta6e8/BOqv9nox2KgRkd7cBSxcGkeqZrz0vXEM8nwZdotdKE5UdZQjKw= =LKWJ -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
