Re: [Sugar-devel] [DESIGN] Record UI
Art, I don't know if i will see the glitches when we do the visual representation. I agree, in a tool to record audio, is important the audio is well recorded. And when I have anything to show, I will inform and we can test it and see what can we do. Regards Gonzalo On Thu, Mar 31, 2011 at 10:15 PM, Art Hunkins wrote: > > - Original Message - From: "C. Scott Ananian" > To: "Art Hunkins" > Cc: "Gonzalo Odiard" ; "Sugar-dev Devel" < > sugar-devel@lists.sugarlabs.org> > Sent: Thursday, March 31, 2011 6:54 PM > Subject: Re: [Sugar-devel] [DESIGN] Record UI > > > > On Fri, Mar 18, 2011 at 12:18 PM, Art Hunkins wrote: >> >>> Please ensure that, in *audio* recording mode, any video display >>> (including >>> an oscilloscope-style display) does not cause glitches in the audio. >>> (This >>> was an apparent problem in earlier versions.) Of course, the surest >>> guarantee of this is no simultaneous (changing) video display. >>> >> >> I think video feedback is vital. How do you know it's actually doing >> something if nothing seems to happen when you start recording audio? >> It doesn't necessarily have to be a waveform display, but *something* >> needs to be changing. >> >> A waveform display has pedagogical value. It's worth making that work >> right. >> --scott >> > > If it "works right", fine. > > Otherwise, there is the elapsed time indicator that is the "something" that > "needs to be changing. Also there are visual changes when you start and stop > recording - all sorts of visual cues. > > I too rather like the waveform display - it does have some pedagogical > value; it just *must not* interrupt smooth audio flow. > > Art Hunkins > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit] Avoid showing decorated windows during start-up (OLPC#10713)
On 03/27/2011 12:28 PM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Tue Mar 08 00:13:43 +0100 2011: I actually tried similar already as well. The issue can still be seen, it seem a bit less visible but I can still see it. Do you mean that even with my patch, you can still trigger this issue? If so, can you give a recipe for triggering it? Hmm, I just tried to reproduce it again, I have seen some flickering mayebe but not the decorated window. Maybe lets get it in and see if it still occurs in certain conditions. I wondered today, if we could set those properties (fullscreen all windows) in a metacity theme [1], but that does not seem to be possible from here at first glance. Even if it were possible, it would probably affect all windows, including those of "legacy" applications like Gimp. Ahh, yeah, this is true indeed. forget about it then. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
- Original Message - From: "C. Scott Ananian" To: "Art Hunkins" Cc: "Gonzalo Odiard" ; "Sugar-dev Devel" Sent: Thursday, March 31, 2011 6:54 PM Subject: Re: [Sugar-devel] [DESIGN] Record UI On Fri, Mar 18, 2011 at 12:18 PM, Art Hunkins wrote: Please ensure that, in *audio* recording mode, any video display (including an oscilloscope-style display) does not cause glitches in the audio. (This was an apparent problem in earlier versions.) Of course, the surest guarantee of this is no simultaneous (changing) video display. I think video feedback is vital. How do you know it's actually doing something if nothing seems to happen when you start recording audio? It doesn't necessarily have to be a waveform display, but *something* needs to be changing. A waveform display has pedagogical value. It's worth making that work right. --scott If it "works right", fine. Otherwise, there is the elapsed time indicator that is the "something" that "needs to be changing. Also there are visual changes when you start and stop recording - all sorts of visual cues. I too rather like the waveform display - it does have some pedagogical value; it just *must not* interrupt smooth audio flow. Art Hunkins ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dropbox on the XO
On Thu, Mar 31, 2011 at 10:06:45AM -0400, Rodolfo D. Arce S. wrote: > Dropbox is designed based on syncing in multiple machines, if a child > has only one machine, then i don't think it to be necessary. I'd like to work on the assumption that Sugar is for a child who has at least one machine, not at most one machine. if n = 0, our software will not run; if n = 1, our software will run; if n > 1, our software will still run. -- 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] [DESIGN] Record UI
On Fri, Mar 18, 2011 at 12:18 PM, Art Hunkins wrote: > Please ensure that, in *audio* recording mode, any video display (including > an oscilloscope-style display) does not cause glitches in the audio. (This > was an apparent problem in earlier versions.) Of course, the surest > guarantee of this is no simultaneous (changing) video display. I think video feedback is vital. How do you know it's actually doing something if nothing seems to happen when you start recording audio? It doesn't necessarily have to be a waveform display, but *something* needs to be changing. A waveform display has pedagogical value. It's worth making that work right. --scott ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] adding support for Tuquito GNU/Linux distribution
Excerpts from Alvar Maciel's message of Thu Mar 31 17:53:28 +0200 2011: > From 50c37da039dc8baafccd925b6b3f034a4ffbaaa9 Mon Sep 17 00:00:00 2001 > From: amaciel > Date: Tue, 29 Mar 2011 15:10:53 -0300 > Subject: [PATCH] Adding support for Tuquito GNU/Linux distribution [...] Thanks for the patch! I'll take a closer look within the next few days (if I don't, feel free to ping me). Just one thing: You need to use lower case 'tuquito' in sysdeps.py because we force all names to lower case before usage (see _get_distribution() and _pipe_lower()). 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-datastore 1/3] Add regression test for SL#2668
Excerpts from Simon Schampijer's message of Thu Mar 31 18:16:00 +0200 2011: > Ahh, I see - there is the plan for a full testsuite (aehm, unreviewed), > go for it then. Thanks! I added your Ack to the patch, but will hold off on pushing it until after the test suite enters mainline. On that note, I'd like to push the test suite to master within the next few days. It has been in the queue for a long time without anyone willing to review it. A full release cycle (0.94) should be enough to catch any bug it might have introduced. The test suite itself has already caught a fair share of bugs, so even if it adds new bugs the overall balance would still be positive. 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-datastore 2/3] Make sure data store checkouts are read-only
Excerpts from Simon Schampijer's message of Thu Mar 31 18:20:48 +0200 2011: > Ok, that sounds tricky indeed. So go for it without the conversion. Thanks! Pushed as a7644fc [1] to master and sucrose-0.92. Sascha [1] http://git.sugarlabs.org/sugar-datastore/mainline/commit/a7644fcca13db182cd44378ac1402f17c023e601 -- 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] Reveal the file transfer palette immediatly on left click #10796
Excerpts from Simon Schampijer's message of Thu Mar 31 21:28:17 +0200 2011: > Good catch, done, anything else? The code looks good. My spell checker nags about "immediatly" in the subject and I'd prefer to have an OLPC prefix for the bug number since it's not an upstream ticket. Acked-by: Sascha Silbe Thanks for the patch! Yet another small step towards solving SL#1169 [1]. Owner buddy fix anyone? :) Sascha [1] https://bugs.sugarlabs.org/ticket/1169#comment:8 -- 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] Reveal the file transfer palette immediatly on left click #10796
Thanks for the quick feedback.
On 03/31/2011 03:05 PM, Sascha Silbe wrote:
Excerpts from Simon Schampijer's message of Thu Mar 31 19:01:23 +0200 2011:
+def __button_clicked_cb(self, button):
+self.palette.popup(immediate=True, state=1)
I guess this should use the Palette.SECONDARY constant instead of hard
coding an integer value.
Good catch, done, anything else?
Regards,
Simon
From 689db7a7db2ba4c7726a0eee9358505b32f01205 Mon Sep 17 00:00:00 2001
From: Simon Schampijer
Date: Thu, 31 Mar 2011 15:25:28 -0400
Subject: [PATCH sugar] Reveal the file transfer palette immediatly on left
click #10796
Mail-Followup-To:
As there are no other options to left click the palette should
be popped up immediately. See 4c2d26ccaeb502037484ced70b5944e3e20aa3f6
for a similar case.
Signed-off-by: Simon Schampijer
---
src/jarabe/frame/activitiestray.py |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/jarabe/frame/activitiestray.py
b/src/jarabe/frame/activitiestray.py
index 906ec77..eea0a15 100644
--- a/src/jarabe/frame/activitiestray.py
+++ b/src/jarabe/frame/activitiestray.py
@@ -331,12 +331,17 @@ class BaseTransferButton(ToolButton):
self.notif_icon.connect('button-release-event',
self.__button_release_event_cb)
+self.connect('clicked', self.__button_clicked_cb)
+
def __button_release_event_cb(self, icon, event):
if self.notif_icon is not None:
frame = jarabe.frame.get_view()
frame.remove_notification(self.notif_icon)
self.notif_icon = None
+def __button_clicked_cb(self, button):
+self.palette.popup(immediate=True, state=Palette.SECONDARY)
+
def remove(self):
frame = jarabe.frame.get_view()
frame.remove_notification(self.notif_icon)
--
1.7.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Reveal the file transfer palette immediatly on left click #10796
Excerpts from Simon Schampijer's message of Thu Mar 31 19:01:23 +0200 2011: > +def __button_clicked_cb(self, button): > +self.palette.popup(immediate=True, state=1) I guess this should use the Palette.SECONDARY constant instead of hard coding an integer value. FWIW, the way I did this for the Speaker frame device [1] was to call self.palette_invoker.notify_right_click(). Sascha [1] http://git.sugarlabs.org/sugar/mainline/commit/7b44b42605a72f99a2285c90542e7cf7629c8752 -- 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] [RELEASE] sugar-presence-service-0.90.2
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-presence-service/sugar-presence-service-0.90.2.tar.bz2 == News == * Make PS not dependent on buddy-icon.jpg to be around OLPC #10739 == Packager Notes == As the presence service is in the process of getting deprecated (only Etoys is still using it) I just made this a bugfix release only. This bug fix is needed because the buddy-icon.jpg has been removed from the profile: sugar: c38e03f641e2f409464340bf67826809cf2f94dc This cleanup has been introduced in 0.92, therefore this package has only to be packaged for a 0.92 based release. Packaging it for a 0.9 based release does not do any harm, though. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH sugar] Reveal the file transfer palette immediatly on left click #10796
As there are no other options to left click the palette should
be popped up immediately. See 4c2d26ccaeb502037484ced70b5944e3e20aa3f6
for a similar case.
Signed-off-by: Simon Schampijer
---
src/jarabe/frame/activitiestray.py |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/src/jarabe/frame/activitiestray.py
b/src/jarabe/frame/activitiestray.py
index 906ec77..3426b73 100644
--- a/src/jarabe/frame/activitiestray.py
+++ b/src/jarabe/frame/activitiestray.py
@@ -331,12 +331,17 @@ class BaseTransferButton(ToolButton):
self.notif_icon.connect('button-release-event',
self.__button_release_event_cb)
+self.connect('clicked', self.__button_clicked_cb)
+
def __button_release_event_cb(self, icon, event):
if self.notif_icon is not None:
frame = jarabe.frame.get_view()
frame.remove_notification(self.notif_icon)
self.notif_icon = None
+def __button_clicked_cb(self, button):
+self.palette.popup(immediate=True, state=1)
+
def remove(self):
frame = jarabe.frame.get_view()
frame.remove_notification(self.notif_icon)
--
1.7.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
- Original Message - From: Gonzalo Odiard To: Gary Martin Cc: Sugar-dev Devel Sent: Thursday, March 31, 2011 9:29 AM Subject: Re: [Sugar-devel] [DESIGN] Record UI - I suggested the sugar-artwork microphone icon (lips) would be good for the audio recording icon (I believe it was originally designed for use as the device icon for a proposed microphone input gain control palette). We didn't formally +1 in the meeting, but worth considering if you don't find it controversial I think the lips icons is better to text to speech (I am using it in Read now). We need a coherent set of metaphor here. What will be represent the icon? The action done by computer or the action done by the child? Also, we can record music too, no only talking. I totally agree with Gonzalo about the lips icon (see my previous mail) - for these and other reasons. Frankly, I really like the microphone icon. Any reason not to use (reuse) it? (Otherwise, perhaps the ear.) Art Hunkins___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Record UI
Comments/suggestions regarding the Record UI:
1) I think Tom's ideas (http://www.flatlandfarm.de/blog/?p=283) are right on
target in re: audio recording. +1.
2) I'm unclear as to whether the oscilloscope ("measure-type") display is a
preview only, or is active during the entire record process. If the latter,
I fear for audio glitches (and if Record ends up audio-glitching, you are
likely to hear from me about it indefinitely!) Probably safer would be to
display oscilloscope only in preview mode, for setting appropriate record
level, and demoing (or otherwise exploring) other aspects of sound. (By
"preview" here, I refer to testing the record level.)
3) Let's keep in mind that Audacity is available as a Suger activity - at
least from the command line. It's full-featured, can edit soundfiles and be
used for all kinds of sound demos and displays. In my view, we should not
worry that Record doesn't include these features.
4) I dislike the lips icon intensely. Besides otherwise being misleading, it
suggests *voice* recording only (and probably only speech). The "ear" seems
much more appropriate, or (for that matter) a stylized waveform or
oscilloscope display. I see the primary application as the recording of
environmental (often nature) sounds, i.e., exploring the *world* of sound.
Art Hunkins
- Original Message -
From: "Gary Martin"
To: "Gonzalo Odiard"
Cc: "Sugar-dev Devel"
Sent: Thursday, March 31, 2011 8:56 AM
Subject: Re: [Sugar-devel] [DESIGN] Record UI
Hi Gonzalo,
On 18 Mar 2011, at 15:15, Gonzalo Odiard wrote:
I have prepared mockups about the changes I want to do in the Record UI.
[1]
The changes were discussed with Simon Schampijer and we take ideas from
Tom Staubitz.
Just following up from Sunday's design meeting:
http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-03-27T15:04:42
See the above log for details, but here's a quick summary:
- place the chronometer combo in the secondary toolbars, as opposed to the
main toolbar
- write each object to Journal upon its creation rather than trying to write
all of them at once on an Activity switch or Stop (which can feel like a
crash/hang if you have recorded more than a few new objects)
- remove the (i) info icon from the toolbar and instead badge each media
thumbnail on the bottom right corner with an info widget (icon still to be
decided)
- use the Journal detail view API explicitly for editing individual object
metadata information, rather than the custom info/take notes side bar, see
Browse and its download complete alert for example code. We standardise on
an edit details UI for all Activities that want to edit their metadata at
any time, an existing proposal already being worked on [1].
- camera icon should be the one as seen in sugar-artwork for
camera-external, need a similar styled icon for video (Walter has also
recently started using camera-external in Turtle Art/Blocks)
- I suggested the sugar-artwork microphone icon (lips) would be good for the
audio recording icon (I believe it was originally designed for use as the
device icon for a proposed microphone input gain control palette). We didn't
formally +1 in the meeting, but worth considering if you don't find it
controversial
There is still some concern over the user interaction for a primary tool,
with sub-toolbar, triggering a full screen canvas change (e.g. as mocked up
in your Record camera vs video vs audio, and my Memorize play vs create UI
modes), as it might be confusing to get back out of a mode (especially when
triggered unexpectedly by hover delay). I'll make a test activity with this
interaction for next Sunday's design meeting and see how it feels.
Regards,
--Gary
[1] Option 1. from Christian's 'detail view anywhere' mockups
http://wiki.sugarlabs.org/go/File:Detailview_20110313.pdf
Regards
Gonzalo
[1] http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar
___
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
Re: [Sugar-devel] [PATCH sugar-datastore 2/3] Make sure data store checkouts are read-only
On 03/31/2011 09:20 AM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Tue Mar 29 21:31:20 +0200 2011: On 03/05/2011 03:26 PM, Sascha Silbe wrote: We don't want anyone to be able to alter a file that is inside the data store, bypassing the API. What happens to the files that have been written prior to that patch? Any plan to convert them? I'm not sure about that. The copy time change respects the umask, thus taking the users decisions re. privacy into account. If we want to preserve that behaviour, we'd need to explicitly mask out the chmod() permission bits. But os.umask() (like the umask() system call) doesn't provide a way to get the current umask without modifying it. Since our copy operations get spawned off as new threads (even if they actually operate just in the single thread running the glib main loop) that might lead to race conditions. Retrieving the umask during start-up would be an option, but I'm starting to wonder whether it's worth the effort. What do you think? Ok, that sounds tricky indeed. So go for it without the conversion. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-datastore 1/3] Add regression test for SL#2668
On 03/31/2011 09:03 AM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Tue Mar 29 21:35:33 +0200 2011: In general: I wonder if we should add test suites for specific bugs, or if they should be just test the available API. Maybe a test that can be done by a human [1] is good enough for those bugs. The best way to ensure high quality is by automating tests as much as possible. It provides instant feedback to developers (so a bug gets caught even prior to review) and enables system integrators to verify that Sugar works as intended on a target platform. It also gives our testers more time to test for bugs we don't already anticipate. I agree on all those points. This particular bug was not caught by the existing (though still unreviewed) test suite [1-3] and a regression test seemed to be the best idea. Ahh, I see - there is the plan for a full testsuite (aehm, unreviewed), go for it then. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit] Store all the buddies that have been joined in the activity metadata OLPC #10578
On 03/31/2011 08:51 AM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Tue Mar 29 23:32:57 +0200 2011: Before only the buddies that were present when closing the activity were logged in the Journal. This patch does add another dictionary '_joined_buddies' to keep track of the users that did join. The '_buddies' dictionary keeps on tracking the users currently in the activity. Is this a regression from pre-0.90? If so, please mention that in the description. It actually 'never' worked. 0.84 had the same issue. Acked-by: Sascha Silbe Sascha Pushed as: master: http://git.sugarlabs.org/sugar-toolkit/mainline/commit/17e52db2b6a6ba0b3aba6246b720f8b91ba1b57f sucrose-0.92: http://git.sugarlabs.org/sugar-toolkit/mainline/commit/95b4eeec758ffa729d0dbb219b21d428115fcc74 Regards, Simon ___ 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
On 03/31/2011 08:38 AM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Tue Mar 29 17:55:04 +0200 2011: We need it in both occasions when we do invite a friend to an activity [1]. What I meant is that I do not want to store this information on disk as I think that it is information that can change and therefore should not be stored. When we read the friends information from disk the contact_id and account information gets added to the model whenever we have it [2]. That was the part I was looking for, thanks! Great! Thanks for the review. [2] http://git.sugarlabs.org/sugar/mainline/blobs/master/src/jarabe/model/friends.py#line57 Acked-By: Sascha Silbe Sascha Pushed to: master: http://git.sugarlabs.org/sugar/mainline/commit/4c2fca5532c0e0ac731279beb30f384a885badef sucrose-0.92: http://git.sugarlabs.org/sugar/mainline/commit/9c4c22249a4773551fa7dc8f5c1a6f3b1e45cc14 Regards, Simon ___ 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
On 03/31/2011 08:35 AM, Sascha Silbe wrote: Excerpts from Simon Schampijer's message of Tue Mar 29 17:41:26 +0200 2011: Hmm, the default behavior is that the Invoker does cache the palette [1]. OK, good point. So as a pure bug fix, your current patch is more in line with the existing code. Therefore: Acked-by: Sascha Silbe Thanks for the review, pushed to master and sucrose-0.92: http://git.sugarlabs.org/sugar/mainline/commit/98d61eebf274a3d2aea4f5c924e30bc74967307e http://git.sugarlabs.org/sugar/mainline/commit/aa889e81c7e8bd9a9df5c7fc27432a7335d2d905 We might want to consider changing the default behaviour some time in the future, however (provided there are measurable performance benefits). If there is evidence, I am open to a suggested patch :) Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] adding support for Tuquito GNU/Linux distribution
On Tue, Mar 29, 2011 at 10:53 AM, Simon Schampijer wrote:
> Hi Amaciel,
>
> thanks very much for your patch! Maybe you can add a few secondary lines
> about the patch describing it - is Tuqito Debian based, a link to the
> project page?
>
> And maybe you can tell gt your name that it does come up in your patch [1].
>
> Regards,
> Simon
>
> [1]
> http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#telling-git-your-name
>
>
hi simon tanks a lot for the advisors I sent again the patch to sugar devel
with more information in this email too maybe you can add this directly or
could you explain how to upload directly using git (I think I did but I am
very new at this, really I'm just a teacher)
>From 50c37da039dc8baafccd925b6b3f034a4ffbaaa9 Mon Sep 17 00:00:00 2001
From: amaciel
Date: Tue, 29 Mar 2011 15:10:53 -0300
Subject: [PATCH] Adding support for Tuquito GNU/Linux distribution
Tuquito is a Ubuntu based distribution - http://www.tuquito.org.ar
Made in Argentina our goal is to make an usable distribution whit
support for educators from a collaborative learning perspective.
---
config/sysdeps/10tuquito-allversions.xml |1 +
config/sysdeps/50tuquito-4.1.xml | 25 +
config/sysdeps/50tuquito-allversions.xml |5 +
sjhbuild/sysdeps.py |3 ++-
4 files changed, 33 insertions(+), 1 deletions(-)
create mode 12 config/sysdeps/10tuquito-allversions.xml
create mode 100644 config/sysdeps/50tuquito-4.1.xml
create mode 100644 config/sysdeps/50tuquito-allversions.xml
diff --git a/config/sysdeps/10tuquito-allversions.xml
b/config/sysdeps/10tuquito-allversions.xml
new file mode 12
index 000..ce85b51
--- /dev/null
+++ b/config/sysdeps/10tuquito-allversions.xml
@@ -0,0 +1 @@
+debian-family.xml
\ No newline at end of file
diff --git a/config/sysdeps/50tuquito-4.1.xml b/config/sysdeps/50tuquito-4.1.xml
new file mode 100644
index 000..5ed0ce8
--- /dev/null
+++ b/config/sysdeps/50tuquito-4.1.xml
@@ -0,0 +1,25 @@
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/config/sysdeps/50tuquito-allversions.xml
b/config/sysdeps/50tuquito-allversions.xml
new file mode 100644
index 000..e523b3a
--- /dev/null
+++ b/config/sysdeps/50tuquito-allversions.xml
@@ -0,0 +1,5 @@
+
+
+
+
+
diff --git a/sjhbuild/sysdeps.py b/sjhbuild/sysdeps.py
index 7aeb026..aac1af9 100644
--- a/sjhbuild/sysdeps.py
+++ b/sjhbuild/sysdeps.py
@@ -15,6 +15,7 @@ _UNSTABLE_NAMES = {
'fedora': 'rawhide',
'mandrivalinux': 'cooker',
'ubuntu': 'unstable',
+'Tuquito':'unstable',
}
@@ -49,7 +50,7 @@ def check_package(package):
if name in ['fedora', 'mandrivalinux']:
ret = subprocess.call(['rpm', '--quiet', '-q', package])
return ret == 0
-elif name in ['ubuntu', 'debian']:
+elif name in ['ubuntu', 'debian', 'Tuquito']:
cmd = ["dpkg-query", "-f='${status}'", "-W", package]
out, err_ = subprocess.Popen(cmd, stdout=subprocess.PIPE).communicate()
return out.find('install ok installed') != -1
--
1.7.1
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Fully update the salut account information when the nick name changes #10749
On 03/31/2011 08:27 AM, Sascha Silbe wrote:
Excerpts from Simon Schampijer's message of Wed Mar 23 15:56:54 +0100 2011:
[src/jarabe/model/neighborhood.py]
+params_needing_reconnect = account.UpdateParameters(
+{'server': server,
+ 'account': account_id,
+ 'register': True},
+dbus.Array([], 's'), dbus_interface=ACCOUNT)
The dictionary fits on a single line, increasing the amount of code that
fits on the screen and thus making it easier to grok the code when
viewing it on an XO.
+params_needing_reconnect = account.UpdateParameters(
+{'jid': account_id},
+dbus.Array([], 's'), dbus_interface=ACCOUNT)
Similarly, all parameters fit on a single line.
I did this to match the rest of the code of that file. I am ok with both
ways, so I went away with moving it on one line.
Acked-by: Sascha Silbe
Thanks for the patch!
Sascha
Pushed to master and sucrose-0.92:
http://git.sugarlabs.org/sugar/mainline/commit/e385144b67404de98ddcd74b99e4745bbe0d7834
Thanks for the review,
Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] The activity icon does not handle the case of a activity without metadata.
Hi Gonzalo, thanks for the patch! Can we open a ticket that has a test case for it and add the bug number to the description? If you open it on SL infra please add the '11.2.0' keywords. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] The activity icon does not handle the case of a activity without metadata.
If the activity is initiated with create_object=False
Acked-by: Sascha Silbe
---
src/sugar/activity/widgets.py |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/sugar/activity/widgets.py b/src/sugar/activity/widgets.py
index b5e4ce7..ef23032 100644
--- a/src/sugar/activity/widgets.py
+++ b/src/sugar/activity/widgets.py
@@ -34,7 +34,7 @@ _ = lambda msg: gettext.dgettext('sugar-toolkit', msg)
def _create_activity_icon(metadata):
-if metadata.get('icon-color', ''):
+if metadata is not None and metadata.get('icon-color'):
color = XoColor(metadata['icon-color'])
else:
client = gconf.client_get_default()
--
1.7.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] 0.92 branching
Hi, I branched off today (created a sucrose-0.92 branch) the following repositories: sugar sugar-toolkit sugar-base sugar-datastore sugar-artwork I did NOT branch off sugar-presence-service as it is deprecated. We must now update pootle accordingly. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dropbox on the XO
Hi Christoph: What is the purpouse of this? What is the final result you wish to acomplish? Dropbox is designed based on syncing in multiple machines, if a child has only one machine, then i don't think it to be necessary. Unless working with the "sharing" option of dropbox, but then again, sugar already has many sharing features. If you mean for your use or a developer then, I don't really know.. What i do know is that works closely with nautilus rather than stand-alone. So we would need to figure out how to make it work on the gnome interface in a sugar+gnome+fedora enviroment. Cheers.. R 2011/3/31 Christoph Derndorfer : > Hi all, > and again another question from the Austrian pilot project: > Has anyone tried using Dropbox on an XO? I see that Fedora x86 packages are > available on http://www.dropbox.com/downloading?os=lnx and hence I assume > that there shouldn't be any problems with GNOME, right? The question now is > whether there's an easy way to potential have synced files also show up in > the Journal? > Thanks in advance, > Christoph > > -- > Christoph Derndorfer > co-editor, olpcnews > url: www.olpcnews.com > e-mail: christ...@olpcnews.com > > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > > -- Rodolfo D. Arce S. web: rodolfoarce.com twitter: @rodolfoarces ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [AC Update] We are what we do.
On Wed, Mar 30, 2011 at 7:05 AM, NoiseEHC wrote: > >>> "About pane" has a psychological effect, it provides recognition and >>> maybe a sense of ownership for developers and mantainers. I will >>> propose it on sugar-devel and the HIG once I've implemented a design. >>> Also it gives a starting point for eventually getting involved in the >>> development and improvement of each activity. >> >> The idea of an About dialog (or menu) already came up on sugar-devel, >> not long ago. IIRC, Gary Martin was quite opposed to increasing UI >> clutter with non-essential information. >> >> Perhaps we could still define a few meta-tags for activity.info and >> _not_ display them in the UI at all? They would still be easy to find >> for developers. > > You can show this info in view source mode and in the journal. Or perhaps in the Detail View in the Journal, where we already show things like mime-type? And perhaps we could even add the ability to launch Browse from the Detail View to go to the activity's homepage? -walter > > ___ > Dextrose mailing list > dextr...@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/dextrose > -- 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] Record UI
Thanks Gary and all the team. On Thu, Mar 31, 2011 at 9:56 AM, Gary Martin wrote: > Hi Gonzalo, > > On 18 Mar 2011, at 15:15, Gonzalo Odiard wrote: > > > I have prepared mockups about the changes I want to do in the Record UI. > [1] > > The changes were discussed with Simon Schampijer and we take ideas from > > Tom Staubitz. > > Just following up from Sunday's design meeting: > > > http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-03-27T15:04:42 > > See the above log for details, but here's a quick summary: > > - place the chronometer combo in the secondary toolbars, as opposed to the > main toolbar > > Ok. > - write each object to Journal upon its creation rather than trying to > write all of them at once on an Activity switch or Stop (which can feel like > a crash/hang if you have recorded more than a few new objects) > Ok. > > - remove the (i) info icon from the toolbar and instead badge each media > thumbnail on the bottom right corner with an info widget (icon still to be > decided) > The idea with the (i) button in the main toolbar was make a explicit difference in the UI between the play/reproduce use and the recording use. The icon is not good (was a temporary icon only) > > - use the Journal detail view API explicitly for editing individual object > metadata information, rather than the custom info/take notes side bar, see > Browse and its download complete alert for example code. We standardise on > an edit details UI for all Activities that want to edit their metadata at > any time, an existing proposal already being worked on [1]. > Are you talking about the "Show in Journal" button? I think is not a good idea for the workflow, but can be a fist step, until we have the detail view [1] implemented. - camera icon should be the one as seen in sugar-artwork for > camera-external, need a similar styled icon for video (Walter has also > recently started using camera-external in Turtle Art/Blocks) > > Ok. - I suggested the sugar-artwork microphone icon (lips) would be good for the > audio recording icon (I believe it was originally designed for use as the > device icon for a proposed microphone input gain control palette). We didn't > formally +1 in the meeting, but worth considering if you don't find it > controversial > > I think the lips icons is better to text to speech (I am using it in Read now). We need a coherent set of metaphor here. What will be represent the icon? The action done by computer or the action done by the child? Also, we can record music too, no only talking. > > > There is still some concern over the user interaction for a primary tool, > with sub-toolbar, triggering a full screen canvas change (e.g. as mocked up > in your Record camera vs video vs audio, and my Memorize play vs create UI > modes), as it might be confusing to get back out of a mode (especially when > triggered unexpectedly by hover delay). I'll make a test activity with this > interaction for next Sunday's design meeting and see how it feels. > > Yes. Can we disable the hover delay triggered change? May be we can use a RadioToolButton and display the sub-toolbars when the button is toggled? Regards Gonzalo [1] Option 1. from Christian's 'detail view anywhere' mockups > http://wiki.sugarlabs.org/go/File:Detailview_20110313.pdf > ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-datastore 2/3] Make sure data store checkouts are read-only
Excerpts from Simon Schampijer's message of Tue Mar 29 21:31:20 +0200 2011: > On 03/05/2011 03:26 PM, Sascha Silbe wrote: > > We don't want anyone to be able to alter a file that is inside the data > > store, > > bypassing the API. > What happens to the files that have been written prior to that patch? > Any plan to convert them? I'm not sure about that. The copy time change respects the umask, thus taking the users decisions re. privacy into account. If we want to preserve that behaviour, we'd need to explicitly mask out the chmod() permission bits. But os.umask() (like the umask() system call) doesn't provide a way to get the current umask without modifying it. Since our copy operations get spawned off as new threads (even if they actually operate just in the single thread running the glib main loop) that might lead to race conditions. Retrieving the umask during start-up would be an option, but I'm starting to wonder whether it's worth the effort. What do you think? 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] Dropbox on the XO
Hi all, and again another question from the Austrian pilot project: Has anyone tried using Dropbox on an XO? I see that Fedora x86 packages are available on http://www.dropbox.com/downloading?os=lnx and hence I assume that there shouldn't be any problems with GNOME, right? The question now is whether there's an easy way to potential have synced files also show up in the Journal? Thanks in advance, Christoph -- Christoph Derndorfer co-editor, olpcnews url: www.olpcnews.com e-mail: christ...@olpcnews.com ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-datastore 3/3] don't destroy unchanged data store entries (SL#2668)
Excerpts from Simon Schampijer's message of Tue Mar 29 21:29:22 +0200 2011: > This part of the patch looks good. I added a test case to [1] to make > sure we can test it accordingly. [...] > Acked-by: Simon Schampijer Thanks! Pushed as ad9244e [1]. Sascha [1] http://git.sugarlabs.org/sugar-datastore/mainline/commit/ad9244e31184415e73be075e9ace053fca97d2f5 -- 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-datastore 1/3] Add regression test for SL#2668
Excerpts from Simon Schampijer's message of Tue Mar 29 21:35:33 +0200 2011: > In general: I wonder if we should add test suites for specific bugs, or > if they should be just test the available API. Maybe a test that can be > done by a human [1] is good enough for those bugs. The best way to ensure high quality is by automating tests as much as possible. It provides instant feedback to developers (so a bug gets caught even prior to review) and enables system integrators to verify that Sugar works as intended on a target platform. It also gives our testers more time to test for bugs we don't already anticipate. This particular bug was not caught by the existing (though still unreviewed) test suite [1-3] and a regression test seemed to be the best idea. Sascha [1] https://patchwork.sugarlabs.org/patch/641/ [2] https://patchwork.sugarlabs.org/patch/640/ [3] https://patchwork.sugarlabs.org/patch/642/ -- 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] [DESIGN] Record UI
Hi Gonzalo, On 18 Mar 2011, at 15:15, Gonzalo Odiard wrote: > I have prepared mockups about the changes I want to do in the Record UI. [1] > The changes were discussed with Simon Schampijer and we take ideas from > Tom Staubitz. Just following up from Sunday's design meeting: http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-03-27T15:04:42 See the above log for details, but here's a quick summary: - place the chronometer combo in the secondary toolbars, as opposed to the main toolbar - write each object to Journal upon its creation rather than trying to write all of them at once on an Activity switch or Stop (which can feel like a crash/hang if you have recorded more than a few new objects) - remove the (i) info icon from the toolbar and instead badge each media thumbnail on the bottom right corner with an info widget (icon still to be decided) - use the Journal detail view API explicitly for editing individual object metadata information, rather than the custom info/take notes side bar, see Browse and its download complete alert for example code. We standardise on an edit details UI for all Activities that want to edit their metadata at any time, an existing proposal already being worked on [1]. - camera icon should be the one as seen in sugar-artwork for camera-external, need a similar styled icon for video (Walter has also recently started using camera-external in Turtle Art/Blocks) <> - I suggested the sugar-artwork microphone icon (lips) would be good for the audio recording icon (I believe it was originally designed for use as the device icon for a proposed microphone input gain control palette). We didn't formally +1 in the meeting, but worth considering if you don't find it controversial <> There is still some concern over the user interaction for a primary tool, with sub-toolbar, triggering a full screen canvas change (e.g. as mocked up in your Record camera vs video vs audio, and my Memorize play vs create UI modes), as it might be confusing to get back out of a mode (especially when triggered unexpectedly by hover delay). I'll make a test activity with this interaction for next Sunday's design meeting and see how it feels. Regards, --Gary [1] Option 1. from Christian's 'detail view anywhere' mockups http://wiki.sugarlabs.org/go/File:Detailview_20110313.pdf > Regards > Gonzalo > > [1] http://wiki.laptop.org/go/User:Godiard/Record/NewToolbar > ___ > 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] The activity icon does not handle the case of a activity without metadata.
Excerpts from Gonzalo Odiard's message of Wed Mar 30 19:22:43 +0200 2011:
> +if metadata is not None and metadata.get('icon-color', ''):
We can drop the second parameter of the get(). The default is None which
will be evaluated as False, like the empty string did.
Acked-by: Sascha Silbe
Thanks for the patch!
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-toolkit] Store all the buddies that have been joined in the activity metadata OLPC #10578
Excerpts from Simon Schampijer's message of Tue Mar 29 23:32:57 +0200 2011: > Before only the buddies that were present when closing the activity > were logged in the Journal. This patch does add another dictionary > '_joined_buddies' to keep track of the users that did join. The > '_buddies' dictionary keeps on tracking the users currently in the > activity. Is this a regression from pre-0.90? If so, please mention that in the description. Acked-by: Sascha Silbe 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] Fix inviting from friends view OLPC #10767
Excerpts from Simon Schampijer's message of Tue Mar 29 17:55:04 +0200 2011: > We need it in both occasions when we do invite a friend to an activity > [1]. What I meant is that I do not want to store this information on > disk as I think that it is information that can change and therefore > should not be stored. > When we read the friends information from disk the > contact_id and account information gets added to the model whenever we > have it [2]. That was the part I was looking for, thanks! > [2] > http://git.sugarlabs.org/sugar/mainline/blobs/master/src/jarabe/model/friends.py#line57 Acked-By: Sascha Silbe 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 Tue Mar 29 17:41:26 +0200 2011: > Hmm, the default behavior is that the Invoker does cache the palette > [1]. OK, good point. So as a pure bug fix, your current patch is more in line with the existing code. Therefore: Acked-by: Sascha Silbe We might want to consider changing the default behaviour some time in the future, however (provided there are measurable performance benefits). 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] Fully update the salut account information when the nick name changes #10749
Excerpts from Simon Schampijer's message of Wed Mar 23 15:56:54 +0100 2011:
[src/jarabe/model/neighborhood.py]
> +params_needing_reconnect = account.UpdateParameters(
> +{'server': server,
> + 'account': account_id,
> + 'register': True},
> +dbus.Array([], 's'), dbus_interface=ACCOUNT)
The dictionary fits on a single line, increasing the amount of code that
fits on the screen and thus making it easier to grok the code when
viewing it on an XO.
> +params_needing_reconnect = account.UpdateParameters(
> +{'jid': account_id},
> +dbus.Array([], 's'), dbus_interface=ACCOUNT)
Similarly, all parameters fit on a single line.
Acked-by: Sascha Silbe
Thanks for the patch!
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 Gonzalo Odiard's message of Mon Mar 28 05:35:22 +0200 2011: > Thanks for review this patch. I can't wait for faster startup in activities > :) > I attach a new patch and reply your comments here I accidentally pulled in the OLPC Sugar 0.92 packages into my Dextrose test images and they seem to already include your patch. The animation is faster, but looks quite different: With the old behaviour, the icon is always visible and just cross-fades the two colours. With your patch however, the entire icon (i.e. both colours) is faded and (almost) disappears from screen, making it harder to recognise (especially in non-optimal lighting conditions). This is a significant UI change. And it doesn't affect just the launcher animation as your patch description suggests, but all pulsing icons - e.g. the wireless device icons in the Neighbourhood and the Frame. I don't think the patch qualifies for inclusion in 0.92.x (it's not a bug fix). And if possible, it should be reworked before merging into 0.94 to avoid the UI change mentioned above. If there's a trade-off to be made between performance and UI behaviour (i.e. if we can't fix the patch without making the animation slow again), we should include the Design Team in our decision process. Sorry about the confusion that results from Simon having already Ack'ed your patch; we clearly need to improve our internal coordination (the same happened in the other direction as well). > We compared two XO with and without the patch and reading the lines like > "a4a52fc2a33b5356bcce073513223d7a62fe38af launched in 2.128857 seconds." > in shell.log Please include the timings (number of runs, average times, standard deviation) in the patch description. > > 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_. > The effect we are talking is, in many activities, the startup zoom was not > visible at all, > because the svg rendering takes more time than the 0.1 second available > before > the next image must be displayed. > With the patch you can see the zoom effect even in XO-1 OK. We can handle the "pulsing icon is sometimes delayed by a few seconds, during which you only get to see a white window" part of the original report in #2080 [1] (so please append "(SL#2080)" to your patch summary) and the remaining issues in separate tickets (like #2565). > > 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). > I think the old code is stopping the animation because the destroy can be > delayed by python. Does not harm anyway. Ah, I see. Thanks! > > [src/jarabe/view/pulsingicon.py] > > > +_MINIMAL_ALPHA_VALUE = 0.2 > > > > How was this value determined? > Experimentation and testing :) We should document the criteria for choosing this value then. > > 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. > Ok. I agree. But in this case, the code is simplest in this way. Hmm, I checked the code and there doesn't seem to be any place where setting self._start_scale and self._end_scale to None instead of 1.0 would make a difference. If we were to set self._zoom_steps to None, we'd just need to swap the two comparisons in __pulse_cb(): +if self._start_scale != self._end_scale and \ +self._current_zoom_step <= self._zoom_steps: If self._start_scale and self._end_scale are None, the first comparison will return True and short-circuit the second one. > self._current_zoom_step is not the same than self._phase, because the zoom > can stop and the pulsing continues. Also you can have have a pulsing icon > without zooming at all (like in the neighborhood view). Ok, I see now. > You are righth about self._phase and self._level, can be simplified, i did > it. Looks better now, thanks! > > 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. > Ok Hmm, I imagined a bit more information than the function and parameter names already provided. ;) How about this: """Configure zoom effect. The icon will be shown at the fraction (0-1.0) of the allocated display space given by start_scale. Over the course of zoom_steps discrete zooming steps (time interval 0.1s) the icon will be enlarged or shrunken to reach its final size, again given as a fraction of the display space. The zoom animation will not be repeated. Pulsing will happen in parallel with zooming, but continue ev
