[Sugar-devel] [ASLO] Release StopWatch-7
Activity Homepage: http://activities.sugarlabs.org/addon/4263 Sugar Platform: 0.82 - 0.92 Download Now: http://activities.sugarlabs.org/downloads/file/27297/stopwatch-7.xo Release notes: Patch for d.l.o#10787 by james Cameron Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [AToiDeJouer] New activity from OLPC-France for animated story editing ... work in progress
HI.
On Thu, Mar 24, 2011 at 12:10 PM, Florent Pigout
wrote:
> Hello,
>
> With OLPC-France, we are currently working on a new activity named
> 'AToiDeJouer' ('YourTurnToPlay'). The project is in its early stage and
> still needs effort for its achievement. Here is a recent screencast of the
> activity:
>
> http://olpc-france.org/download/OLPC_AToiDeJouer_Demo_Graphic_Editing.mp4
>
>
Really nice..I hope you are working on having support for
internationalization and localization for you activity in a near future.
Cheers!.
> I confirm, this demo goes really fast, and doesn't reflect standard use or
> discovery. But as the status of this project, it gives an idea of the goal
> we aim and the remaining work to do.
>
> The activity should be provided with 4 stories on an USB stick. For
> download, these stories should be delivered separately but we didn't work on
> that issue yet.
>
> List of the USB stories:
> . Le corbeau et le renard
> . La grenouille qui veut se faire aussi grosse que le bœuf
> . Le lièvre et la tortue
> . La cigale et la fourmi
>
> This activity fully use GTK as UI library and gst for sound playing. It's
> ok, if we key keep a rendering of 1 frame per second, but the performance
> issue can evolve if we find a nicer way to edit the story and manage
> editable frame transition. May be we will be able to manage story with more
> than 1 frame per second and will need stronger rendering backend, like a
> pygame integration in the GTK all thing. I found some info about that but
> haven't try anything yet.
>
> For the USB version, children will open the activity with an existing story
> and play with it. But managing graphics, sequences, sounds, frames, time,
> loops, etc. can be quiet complicated for children. I tried to reproduce a
> adobe flash like UI, but it remains difficult to use for new user in
> general, and surely more for a younger audience. We already have some idea
> on that issue, like: put tooltip on all buttons, prepare sequence in motion
> instead of simple image list, offer simple | medium | advanced editing mode.
> But, we certainly to step back and see if other good ideas or compromise can
> be found.
>
> I developed and tested the activity on a trisquel-sugar-4.1 virtualbox
> instance. Also I tried it once on a XO 1.5, but it seems that
> activity.ActivityToolbox and gtk.Color works in a different way. I still
> need to figure out if it the only compatibility problem and work on it. The
> USB version will use a trisquel-sugar-4.1 instance too, but it can be
> interresting to keep an eye on compatibility for larger deployment.
>
> I will post a link to mockups and screenshots of the main screens soon to
> illustrate the work done and to think about a nicer ergonomy. Meanwhile,
> here is the gitorious link:
>
> http://git.sugarlabs.org/atoidejouer
>
> Please don't hesitate to fork this project, send patch, comment, give your
> opinion and point of view ...
>
> ++
> florent
>
>
> ___
> 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] [PATCH sugar] Fix inviting from friends view OLPC #10767
Excerpts from Simon Schampijer's message of Thu Mar 24 21:52:04 +0100 2011: > Add the contact_id and the account information to the buddymodel used in > the group view. We do not store it in the friends model as the id and the > account information may vary. Why do we need those two when adding a friend from the UI, but not when loading the friends list from disk (jarabe.model.friends.Friends.load())? Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Do startup animation of the activity icon using scaling and alpha - v2
Excerpts from godiard's message of Wed Mar 23 19:40:47 +0100 2011: Thanks for your patch! I can't wait for an accelerated launcher screen. ;) > This render the SVG image only one time, and then use alpha and scaling > of the rendered icon and will speed up the overall activity startup. Any patch that claims improved performance needs to include proof of that, i.e. test results plus a description of the test hardware and test procedure so the results can be reproduced by the reviewer and/or a third party. > Another side effect is that the ticket #2080 effects are reduced greatly. Which side effects exactly? #2080 mentions a) empty window getting displayed for several seconds and b) the launch window getting shown after the activity was _closed_. > Signed-off-by: Gonzalo Odiard > Acked-By: Simon Schampijer Did he (Ack your patch)? [src/jarabe/view/launcher.py] I like that you're getting rid of the HippoCanvas based class. I'm not so sure about not using sugar.graphics.animator.Animation anymore, though. The old code used an exponential formula while yours is purely linear. We might want to check with the Design Team whether that makes a difference to the user. [LaunchWindow.__destroy_cb(self, box)] > +self._activity_icon.props.pulsing = False > +self._home.disconnect_by_func(self.__active_activity_changed_cb) If the launcher and with it the icon gets destroyed anyway, why do we need to tell it to stop pulsing? (Yes, I'm aware this was already the case in the old code - just wondering whether we really need it). [src/jarabe/view/pulsingicon.py] > +_MINIMAL_ALPHA_VALUE = 0.2 How was this value determined? [Pulser.__init__(self, icon)] > -self._level = 0 > +self._level = 1.0 > self._phase = 0 > +self._start_scale = 1.0 > +self._end_scale = 1.0 I would prefer to use None for indicating no scaling is to take place (this applies to the other patch as well). It's probably ok in this particular place, but in general (in)equality comparisons of floating point numbers are tricky at best. > +self._zoom_steps = 1 > +self._current_zoom_step = 1 > +self._scale = 1.0 > +self._current_scale_step = 1 self._current_zoom_step seems to be a counter, duplicating self._phase (though scaling by 1/_STEP). self._current_scale_step OTOH seems to be a scaling factor. Please rename the variables appropriately and if possible eliminate some of them (self._phase and self._level would be good candidates). Do we need to keep a copy of the current scale (i.e. self._scale)? AFAICT assigning directly to self._icon.scale should suffice. [Pulser] > +def set_zooming_properties(self, start_scale, end_scale, zoom_steps): > +self._start_scale = start_scale > +self._end_scale = end_scale > +self._zoom_steps = zoom_steps > +self._current_scale_step = abs(self._start_scale - self._end_scale) > / \ > +self._zoom_steps > +self._scale = self._start_scale > +self._icon.scale = self._scale Please provide a docstring explaining what this function is about (see PEP 257). I also wonder if the caller isn't more interested in specifying a time interval rather than the number of steps. set_zooming_properties sounds a bit strange, but I can't think of a much better name. set_zooming might be a start - it should at least get rid of some of the line continuations. :) [Pulser.__pulse_cb(self)] > -self._level = (math.sin(self._phase) + 1) / 2 > +self._level = _MINIMAL_ALPHA_VALUE + \ > +(1 - _MINIMAL_ALPHA_VALUE) * (math.sin(self._phase) + 1) / 2 > +if self._current_zoom_step <= self._zoom_steps: > +if self._start_scale != self._end_scale: These two ifs can be combined to a single one, thus removing one level of indentation. [PulsingIcon] > +def set_zooming_properties(self, start_size=style.SMALL_ICON_SIZE, > + end_size=style.XLARGE_ICON_SIZE, > + zoom_steps=10): > +if start_size > end_size: > +start_scale = 1.0 > +end_scale = float(end_size) / float(start_size) You don't need to convert the second operand to float. If the first operand is float, the result will always be float. > +if end_size > start_size: > +start_scale = float(start_size) / float(end_size) > +end_scale = 1.0 Replacing the second if with an else would avoid throwing a NameError if start_size == end_size. Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Cache the XO palette in the Home View, part of #2726
Excerpts from Simon Schampijer's message of Thu Mar 24 21:16:32 +0100 2011: > The patch does cache the palette of the Owner, this has been > the behavior before 356641c332d6cc889b265dfc29598004cf37763c. As > registering (and therefore the change of the palette) happens > rather seldom compared to the change of a buddy palette, I think > the Owner palette can be considered to be mostly static > and therefore we can cache it. I'd approach this from a different angle (than the palette being static) and prefer the second patch [1] you attached to #2726 [2]: The owner palette provides access to functions (My Settings, Register, end session) that I don't expect to be used rather often during the lifetime of a Sugar session and the palette can easily be reconstructed, so we don't need to cache it (thus saving a tiny bit of memory). You can consider this an Ack for your second patch. I trust you to add a nice description. ;) BTW: Thanks for all your recent patches! Sascha [1] https://bugs.sugarlabs.org/raw-attachment/ticket/2726/no_cache.patch [2] https://bugs.sugarlabs.org/ticket/2726 -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v4 sugar] Time out on registration process to prevent indefinite UI hang (SL#2289)
Excerpts from Simon Schampijer's message of Thu Mar 24 15:04:29 +0100 2011: > > PS: Filing bugs upstream will a) increase the chance they get fixed by > > someone else, b) avoid duplicate work by sharing test results and c) > > give both upstream and other downstreams a better overview of what's > > (known to be) broken. > > I think this time it was more efficient to use the ml to report > upstream, since I wanted to gather the attention from the originator of > the code and I doubted he would read all the bugs in the sugarlabs bug > tracker. My note was targeted at filing bugs (just) downstream. This mailing list is public (and upstream), thus providing most of the benefits outlined above. Thanks for filing #2726! Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Limit the nick name to be only 8 characters maximum #10737
Excerpts from Simon Schampijer's message of Tue Mar 22 22:49:53 +0100 2011: > Avahi uses "GetHostName" (on the XO this is something like 'xo-a7-2e-70' > based on the HW address). If GetHostName is based on gethostname(), then it is far from unique. Most distributions default to a constant name like "debian". The user can override it during installation, but many users are lazy / don't care. > In the PS we did use the first 8 characters of the ssh key of the user > and pushed that into 'published-name'. My first patch was based on that [1]. > > As I understood Tomeu he wanted to use the nick name instead now to > enhance the information we give out. I can understand the goal of human readable names, but I'm worried about what happens if the new assumptions (unique host name) are not met. What exactly does this value get used for? How would a human use it? Aren't the 'nickname' and 'jid' properties that are part of the same dictionary more useful to a human in the first place? > [1] http://dev.laptop.org/ticket/10737#comment:4 Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: PGP signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Palabras-7
Activity Homepage: http://activities.sugarlabs.org/addon/4315 Sugar Platform: 0.82 - 0.92 Download Now: http://activities.sugarlabs.org/downloads/file/27298/words-7.xo Release notes: -Add langs by pootle -Es translation Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [AToiDeJouer] New activity from OLPC-France for animated story editing ... work in progress
Hi,
On Fri, Mar 25, 2011 at 7:57 PM, Rafael Ortiz wrote:
> HI.
>
> On Thu, Mar 24, 2011 at 12:10 PM, Florent Pigout > wrote:
>
>> Hello,
>>
>> With OLPC-France, we are currently working on a new activity named
>> 'AToiDeJouer' ('YourTurnToPlay'). The project is in its early stage and
>> still needs effort for its achievement. Here is a recent screencast of the
>> activity:
>>
>> http://olpc-france.org/download/OLPC_AToiDeJouer_Demo_Graphic_Editing.mp4
>>
>>
> Really nice..I hope you are working on having support for
> internationalization and localization for you activity in a near future.
>
>
> Cheers!.
>
>
Yes internationalization and localization is on it's way, for france first,
but i18n text will be extracted and french PO redacted, then all new po
files would be welcome ;)
> I confirm, this demo goes really fast, and doesn't reflect standard use or
>> discovery. But as the status of this project, it gives an idea of the goal
>> we aim and the remaining work to do.
>>
>> The activity should be provided with 4 stories on an USB stick. For
>> download, these stories should be delivered separately but we didn't work on
>> that issue yet.
>>
>> List of the USB stories:
>> . Le corbeau et le renard
>> . La grenouille qui veut se faire aussi grosse que le bœuf
>> . Le lièvre et la tortue
>> . La cigale et la fourmi
>>
>> This activity fully use GTK as UI library and gst for sound playing. It's
>> ok, if we key keep a rendering of 1 frame per second, but the performance
>> issue can evolve if we find a nicer way to edit the story and manage
>> editable frame transition. May be we will be able to manage story with more
>> than 1 frame per second and will need stronger rendering backend, like a
>> pygame integration in the GTK all thing. I found some info about that but
>> haven't try anything yet.
>>
>> For the USB version, children will open the activity with an existing
>> story and play with it. But managing graphics, sequences, sounds, frames,
>> time, loops, etc. can be quiet complicated for children. I tried to
>> reproduce a adobe flash like UI, but it remains difficult to use for new
>> user in general, and surely more for a younger audience. We already have
>> some idea on that issue, like: put tooltip on all buttons, prepare sequence
>> in motion instead of simple image list, offer simple | medium | advanced
>> editing mode. But, we certainly to step back and see if other good ideas or
>> compromise can be found.
>>
>> I developed and tested the activity on a trisquel-sugar-4.1 virtualbox
>> instance. Also I tried it once on a XO 1.5, but it seems that
>> activity.ActivityToolbox and gtk.Color works in a different way. I still
>> need to figure out if it the only compatibility problem and work on it. The
>> USB version will use a trisquel-sugar-4.1 instance too, but it can be
>> interresting to keep an eye on compatibility for larger deployment.
>>
>> I will post a link to mockups and screenshots of the main screens soon to
>> illustrate the work done and to think about a nicer ergonomy. Meanwhile,
>> here is the gitorious link:
>>
>> http://git.sugarlabs.org/atoidejouer
>>
>>
Here is the main screenshots and mockups of the application:
http://olpc-france.org/download/AToiDeJouer_Screenshots_and_Mockups.tar.bz2
Please don't hesitate to share you ideas on these ...
Regards,
florent
Please don't hesitate to fork this project, send patch, comment, give your
>> opinion and point of view ...
>>
>> ++
>> florent
>>
>>
>> ___
>> 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] [AToiDeJouer] New activity from OLPC-France for animated story editing ... work in progress
On Thu, Mar 24, 2011 at 6:55 PM, Sascha Silbe wrote:
> Excerpts from Florent Pigout's message of Thu Mar 24 18:10:43 +0100 2011:
>
> > With OLPC-France, we are currently working on a new activity named
> > 'AToiDeJouer' ('YourTurnToPlay').
>
> Nice!
>
> > I developed and tested the activity on a trisquel-sugar-4.1 virtualbox
> > instance. Also I tried it once on a XO 1.5, but it seems that
> > activity.ActivityToolbox and gtk.Color works in a different way.
>
> I guess you're talking about the stock OLPC OS build. That contains
> Sugar 0.84 with the "old" toolbars. Dextrose 2 is using Sugar 0.88 which
> has the "new" toolbars; both Dextrose 3 and OLPC OS 11.2.0 (in
> development) will contain Sugar 0.92. The Trisquel image you mention
> seems to have Sugar 0.88.
>
> What puzzles me, though, is that your activity is still using the "old"
> toolbars, so it should already work on 0.84. Maybe you managed to mix
> both old and new classes?
>
> The Compatibility Tips wiki page has some tips [1] for supporting both
> "old" and "new" toolbars.
>
> Sascha
>
> [1]
> https://wiki.sugarlabs.org/go/Activity_Team/Compatibility_Tips#Sugar_toolbar_version
> --
> http://sascha.silbe.org/
> http://www.infra-silbe.de/
>
Thanks a lot for all these information. Sorry for this lake of information
about my development environment and target. I'll try to keep an eye on all
these version and I will may be come back with more precise questions soon
to ensure a good compatibility level for this activity.
Regards,
florent
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ASLO] Release Paths-6
Activity Homepage: http://activities.sugarlabs.org/addon/4409 Sugar Platform: 0.82 - 0.92 Download Now: http://activities.sugarlabs.org/downloads/file/27299/paths-6.xo Release notes: 6 * fixed scaling problem on old-style Sugar that caused clipping of bottom row * sharing with up to 4 player enabled * animate dragging tiles * added scoring * added hint button Note: there are some restore issues when sharing. Sugar Labs Activities http://activities.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
