Re: [Sugar-devel] [Dextrose] [PATCH v3] Reduction in the time taken for loading of the menu (SL#1169)
On Wed, 2010-10-27 at 06:05 +0530, Manusheel Gupta wrote: Are we ready to commit this patch? I consider this patch good, but I have no authority to ack patches for the sugar module. We need approval from either Alsroot, Silbe or Erikos. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] New maintainer for Words
On Wed, 2010-10-27 at 06:11 +0530, Manusheel Gupta wrote: Shachi and Sarvagya are interested to co-maintain Words. They did submit a patch this month (needs to be reviewed). Would you and Chris like to have a word with them on this matter? Yes, but I will be (mostly) offline until the weekend. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080
On Tue, Oct 26, 2010 at 7:50 PM, James Cameron qu...@laptop.org wrote: On Tue, Oct 26, 2010 at 05:41:58PM +0530, Anurag Chowdhury wrote: The conclusion of XO-1.5 being nearly 2.5 times faster than the XO-1 could be verified by comparing their hardware specifications. at http://en.wikipedia.org/wiki/OLPC_XO-1 (For XO-1) and http://wiki.laptop.org/go/Hardware_specification_1.5 (For XO-1.5) These specifications do not describe CPU or graphics performance, and so your conclusion 2.5 times faster is not supported by these specifications. Also we can see the test results of James'(quozl) at http://bugs.sugarlabs.org/ticket/245 which suggests that XO-1.5 is atleast twice as fast as XO-1. That test compared two entirely different methods of rendering the languages control panel section; one method used by Sugar 0.82.1 and the other method used Sugar 0.84.11. So your conclusion 2.5 times faster is not supported by this test either. http://dev.laptop.org/ticket/9325 is the best test result that I can remember that compares CPU and graphics performance, and the latest results there show XO-1 and XO-1.5 at about equal, because the bit plane depth has changed from 16 on XO-1 to 24 on XO-1.5 at the same time as the graphics subsystem became faster. The test is less relevant to Sugar though, since it is (a) full screen fill, and (b) using SDL and pygame rather than GTK+. I'd like to test your change on Sugar 0.84 (not HEAD) on XO-1 and XO-1.5 once I can understand how to measure the performance. It is more important for me that power is conserved. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Just an FYI I am releasing a new Dextrose today. os4dx2 which will soon be available on wiki.sugarlabs.org/go/Dextrose One feature is an updated cairo which seems to have decreased the render times. You might want to check it out. I have done some local testing and it seems much improved so might just render this a mute point. Steven ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080
Hi Steven, On 27 Oct 2010, at 15:55, Steven Parrish wrote: On Tue, Oct 26, 2010 at 7:50 PM, James Cameron qu...@laptop.org wrote: On Tue, Oct 26, 2010 at 05:41:58PM +0530, Anurag Chowdhury wrote: The conclusion of XO-1.5 being nearly 2.5 times faster than the XO-1 could be verified by comparing their hardware specifications. at http://en.wikipedia.org/wiki/OLPC_XO-1 (For XO-1) and http://wiki.laptop.org/go/Hardware_specification_1.5 (For XO-1.5) These specifications do not describe CPU or graphics performance, and so your conclusion 2.5 times faster is not supported by these specifications. Also we can see the test results of James'(quozl) at http://bugs.sugarlabs.org/ticket/245 which suggests that XO-1.5 is atleast twice as fast as XO-1. That test compared two entirely different methods of rendering the languages control panel section; one method used by Sugar 0.82.1 and the other method used Sugar 0.84.11. So your conclusion 2.5 times faster is not supported by this test either. http://dev.laptop.org/ticket/9325 is the best test result that I can remember that compares CPU and graphics performance, and the latest results there show XO-1 and XO-1.5 at about equal, because the bit plane depth has changed from 16 on XO-1 to 24 on XO-1.5 at the same time as the graphics subsystem became faster. The test is less relevant to Sugar though, since it is (a) full screen fill, and (b) using SDL and pygame rather than GTK+. I'd like to test your change on Sugar 0.84 (not HEAD) on XO-1 and XO-1.5 once I can understand how to measure the performance. It is more important for me that power is conserved. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel Just an FYI I am releasing a new Dextrose today. os4dx2 which will soon be available on wiki.sugarlabs.org/go/Dextrose One feature is an updated cairo which seems to have decreased the render times. You might want to check it out. I have done some local testing and it seems much improved so might just render this a mute point. Oooh, some good news at last! Thanks for the heads up. Regards, --Gary Steven ___ 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] [PATCH Paint Activity] Fixed aspect ratio mode for Shape tools (OLPC#3705)
Added fixed aspect ratio mode for line,ellipse and rectangle tool using Shift key as mask.This allows drawing of straight lines 45 degree lines from line tool,circle from ellipse tool and square from rectangle tool Signed-off-by: Ayush Goyal ay...@seeta.in --- Area.py | 33 - 1 files changed, 32 insertions(+), 1 deletions(-) diff --git a/Area.py b/Area.py index ba06758..0bef28b 100644 --- a/Area.py +++ b/Area.py @@ -412,6 +412,12 @@ class Area(gtk.DrawingArea): coords = int(x), int(y) +if state gtk.gdk.SHIFT_MASK: +if self.tool['name'] in ['rectangle', 'ellipse']: +coords = self._keep_selection_ratio(coords) +elif self.tool['name'] == 'line': +coords = self._keep_line_ratio(coords) + if state gtk.gdk.BUTTON1_MASK and self.pixmap != None: if self.tool['name'] == 'pencil': self.d.brush(widget, coords, self.last, @@ -530,11 +536,17 @@ class Area(gtk.DrawingArea): @param event -- GdkEvent coords = int(event.x), int(event.y) +if event.state gtk.gdk.SHIFT_MASK: +if self.tool['name'] in ['rectangle', 'ellipse']: +coords = self._keep_selection_ratio(coords) +if self.tool['name'] == 'line': +coords = self._keep_line_ratio(coords) + width, height = self.window.get_size() if self.desenha or self.sel_get_out: if self.tool['name'] == 'line': self.pixmap.draw_line(self.gc_line, self.oldx, self.oldy, -int(event.x), int(event.y)) + coords[0], coords[1]) widget.queue_draw() self.enableUndo(widget) @@ -1411,3 +1423,22 @@ class Area(gtk.DrawingArea): return (self.oldx + sign(dx) * size, self.oldy + sign(dy) * size) + +def _keep_line_ratio(self, coords): + +def sign(x): +return x and x / abs(x) or 0 + +dx = int(coords[0]) - self.oldx +dy = int(coords[1]) - self.oldy +size = max(abs(dx), abs(dy)) + +if abs(dx) 0.5 * size and abs(dy) 0.5 * size: +return (self.oldx + sign(dx) * size, + self.oldy + sign(dy) * size) +elif abs(dx) 0.5 * size and abs(dy) 0.5 * size: +return (self.oldx, + self.oldy + sign(dy) * size) +elif abs(dx) 0.5 * size and abs(dy) 0.5 * size: +return (self.oldx + sign(dx) * size, + self.oldy) -- 1.7.1 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Paint Activity] Fixed aspect ratio mode for Shape tools (OLPC#3705)
Thanks! Is very nice. In the selection tool palette, we have a check box to enable change the fixed ratio. Can you add the checkbox to the palettes from ellipse, rectangle and line? Gonzalo On Wed, Oct 27, 2010 at 4:28 PM, Ayush Goyal ay...@seeta.in wrote: Added fixed aspect ratio mode for line,ellipse and rectangle tool using Shift key as mask.This allows drawing of straight lines 45 degree lines from line tool,circle from ellipse tool and square from rectangle tool Signed-off-by: Ayush Goyal ay...@seeta.in --- Area.py | 33 - 1 files changed, 32 insertions(+), 1 deletions(-) diff --git a/Area.py b/Area.py index ba06758..0bef28b 100644 --- a/Area.py +++ b/Area.py @@ -412,6 +412,12 @@ class Area(gtk.DrawingArea): coords = int(x), int(y) + if state gtk.gdk.SHIFT_MASK: + if self.tool['name'] in ['rectangle', 'ellipse']: + coords = self._keep_selection_ratio(coords) + elif self.tool['name'] == 'line': + coords = self._keep_line_ratio(coords) + if state gtk.gdk.BUTTON1_MASK and self.pixmap != None: if self.tool['name'] == 'pencil': self.d.brush(widget, coords, self.last, @@ -530,11 +536,17 @@ class Area(gtk.DrawingArea): @param event -- GdkEvent coords = int(event.x), int(event.y) + if event.state gtk.gdk.SHIFT_MASK: + if self.tool['name'] in ['rectangle', 'ellipse']: + coords = self._keep_selection_ratio(coords) + if self.tool['name'] == 'line': + coords = self._keep_line_ratio(coords) + width, height = self.window.get_size() if self.desenha or self.sel_get_out: if self.tool['name'] == 'line': self.pixmap.draw_line(self.gc_line, self.oldx, self.oldy, - int(event.x), int(event.y)) + coords[0], coords[1]) widget.queue_draw() self.enableUndo(widget) @@ -1411,3 +1423,22 @@ class Area(gtk.DrawingArea): return (self.oldx + sign(dx) * size, self.oldy + sign(dy) * size) + + def _keep_line_ratio(self, coords): + + def sign(x): + return x and x / abs(x) or 0 + + dx = int(coords[0]) - self.oldx + dy = int(coords[1]) - self.oldy + size = max(abs(dx), abs(dy)) + + if abs(dx) 0.5 * size and abs(dy) 0.5 * size: + return (self.oldx + sign(dx) * size, + self.oldy + sign(dy) * size) + elif abs(dx) 0.5 * size and abs(dy) 0.5 * size: + return (self.oldx, + self.oldy + sign(dy) * size) + elif abs(dx) 0.5 * size and abs(dy) 0.5 * size: + return (self.oldx + sign(dx) * size, + self.oldy) -- 1.7.1 -- Gonzalo Odiard ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Development Meetings
On Wed, Oct 27, 2010 at 11:33:12AM -0400, Michael Stone wrote: 1. I am *much* more likely to read and/or participate in your discussions if they occur in email as opposed to in IRC. I agree. Mail is asynchronous. I tend not to use IRC for Sugar discussions, though my attention can be attracted in working hours if my nickname is mentioned. 2. If you do decide to use email, please use separate threads for separate topics, perhaps with RFC: and RFD: subject prefixes. I agree. 3. Regardless of medium, how do you imagine summarizing the feedback received as a result of discussion for easy access in the future? I imagine that a thread closing summary post, with the subject tag [SUMMARY], would be posted. A link to this might then be recorded in other medium. 4. How do you intend to bring discussions to closure? I don't know how to do that, and it is frustrating to me. Discussions seem to keep going on and on, drilling down into trivialities, bringing in orthogonal points, introducing new motions or variations to motions without any seconding. The community here does act in any way like a deliberative assembly. Achieving consensus is hard. -- 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] Development Meetings
On Wed, Oct 27, 2010 at 11:47:03AM +, Aleksey Lim wrote: On Wed, Oct 27, 2010 at 09:05:40AM +1100, James Cameron wrote: On Tue, Oct 26, 2010 at 12:16:47PM +, Aleksey Lim wrote: What about having [only] upcoming meeting on nearest weekends, something like Saturday, 22:00 UTC? Nak. Already booked, weekly event, high priority. http://whenisgood.net/ may interest you, it is a way to schedule an event ... I've found it very useful. Yeah, but I guess choosing 3rd date will be overkill, also, imho, static date for regular meetings sounds more useful. Fine. If you think it is important that I be there, I'm sure you'll find a way to achieve it. But anyway, in my mind upcoming meeting should take motions about organizational questions and nothing prevents us to discuss/vote for motions before the meeting. During the meeting, motion will be taken keeping in mind votes of people who couldn't take part. I've tried to formalize all questions that are important for me. Please do the same for yours questions. So, people can post theirs +/-. Of course this thread might be used to discuss all topics before the meeting. I'd prefer breaking into a new thread for motions. However I've no motions to suggest, and don't really have much to say. ;-) -- 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] [Dextrose] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080
On Wed, Oct 27, 2010 at 11:15:01PM +0530, Anurag Chowdhury wrote: I carried out the same benchmark test, which I earlier conducted on an XO-1.5, on a XO-1. And I have attached the log files obtained in both the cases. I have reviewed them. Can you show me the patch you used for benchmark test? I re-read the code from launcher.py, pulsingicon.py in sugar.git, down to icon.py in sugar-toolkit.git, but wasn't able to figure out where you might have added that benchmark timing. Without it, I don't understand what you are measuring, and so I don't understand the result. And found my assertion of XO-1.5 being a faster system in parameters of the pulsing icon rendering also i found out the delay of the first frame to be nearly 1.5 secs on XO-1 as compared to 0.8 secs on XO-1.5. also the consecutive times taken for the rendering of the frames on the XO-1 were much larger as compared to that on a XO-1.5. Yes, it seems to be a CPU task, not a graphics task, that you have removed by your proposed patch. Hence, the above taken log results verify that XO-1.5 has better system performance in case of graphic rendering than XO-1. Graphics rendering, yes. Graphics performance, no. I'm so sorry, all this time I thought you were talking about graphics performance, but now I see you are addressing a graphics rendering issue. And shipping the update function call for the first frame reduces the delay by nearly 1.5secs on an XO-1 and by 0.8 secs on XO-1.5. So Bernie's questions in the bug spark my curiosity as well ... why is it that the first frame is slower to render than the other frames? (An unrelated side-issue ... the launcher is stealing CPU cycles from the startup of the activity, the task run queue shows this during a launch. I wonder if activities might start up faster if there was no launcher, just a busy cursor.) -- 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] [Dextrose] Fwd: [PATCH] Changed outline of checkbox from grey to black when activated. Ticket #305
Shan,
The patch indeed works well. Thanks for testing it.
Better to check this at couple of places (menus), where this feature does
have a role to play.
Regards,
Manu
On Tue, Oct 26, 2010 at 10:25 PM, Shanjit Singh Jajmann shan...@seeta.inwrote:
Hello team,
I have attached the screen shot for the check box without making the
changes present in the patch.
I have made a new window to test the working of the checkbox.
The checkbox seems to be working fine.
Please find the two screenshots of the checkbox (both selected and
unselected) attached.
Regards
Shanjit Singh Jajmann
On Wed, Oct 20, 2010 at 9:45 PM, Ishan Bansal is...@seeta.in wrote:
Hi
I have submitted the patch for the ticket #305.
Wish if you could review it and provide me suggestions on any improvement
required.
Regards
ishan
-- Forwarded message --
From: Ishan Bansal is...@seeta.in
Date: Fri, Sep 10, 2010 at 12:07 AM
Subject: [PATCH] Changed outline of checkbox from grey to black when
activated. Ticket #305
To: sugar-devel@lists.sugarlabs.org
Changed outline of checkbox from grey to black so that it does not
disappears into the grey highlight of the mouseover selection. (Ticket #305)
---
gtk/theme/gtkrc.em |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/gtk/theme/gtkrc.em b/gtk/theme/gtkrc.em
index 69dccd9..3c0d7f6 100644
--- a/gtk/theme/gtkrc.em
+++ b/gtk/theme/gtkrc.em
@@ -48,6 +48,7 @@ button_grey = '#808080'
selection_grey = '#A6A6A6'
panel_grey = '#C0C0C0'
text_field_grey = '#E5E5E5'
+text_field_black = '#00'
white = '#FF'
@@ -630,7 +631,7 @@ style checkbutton
{
base[NORMAL] = $white
base[PRELIGHT]= $white
-base[ACTIVE] = $text_field_grey
+base[ACTIVE] = $text_field_black
text[PRELIGHT]= $toolbar_grey
text[NORMAL] = $toolbar_grey
--
1.7.0.4
___
Dextrose mailing list
dextr...@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/dextrose
___
Dextrose mailing list
dextr...@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/dextrose
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Development Meetings
On Wed, Oct 27, 2010 at 16:51:00 + Aleksey Lim wrote: These are good questions. I personally think that having more formalized ML discussion (to take core team decisions) will be a huge plus (it is impossible to take any decision only during a meeting) and not only for people who prefer email to IRC. Does anyone have ready to use recipes? Yes, several. Three outlines that come to mind immediately are: 1. parliamentary procedure, which James brought up implicitly in his comment when he mentioned the words motions and deliberative assembly. (See Robert's Rules.) 2. consensus, e.g. as exemplified in the IETF processes, which I brought up when I mentioned RFCs. (See RFC 2026.) 3. dictatorship/oligarchy. (See LKML.) Which are you interested in recipes for? Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Research: 0.84 Launcher Cost
Earlier in the context of SL#2080 patch review, I had said the
launcher is stealing CPU cycles from the startup of the activity, the
task run queue shows this during a launch. I wonder if activities
might start up faster if there was no launcher, just a busy cursor.
Looks like activities would start faster; between one and four seconds,
mostly depending on the activity, and slightly depending on the icon
complexity.
Details below.
--
Research: will activities start faster if there is no launcher?
Method: using an XO-1, freshly installed with Sugar 0.84.22, as part
of OLPC OS 10.1.2 build os852, test the startup time of three
activities (Memorize, Moon and Chat), remove the launcher, retest,
subtract.
The launcher is implemented by source file launcher.py in
/usr/lib/python2.6/site-packages/jarabe/view/ ... the modification
made is attached as a patch.
The times were captured with a stopwatch. The timing began when Start
was selected from the list view, and ended once the activity had
completed display of the UI.
Result:
a. unmodified launcher.py
Memorize-34 9.43s, 9.56s, 9.51s
Moon-11 11.58s, 11.60s, 11.65s
Chat-65 6.65s, 6.54s, 6.59s
b. modified launcher.py (black background, no animation),
Memorize-34 7.60s, 7.63s, 7.60s
Moon-11 7.78s, 7.78s, 7.95s
Chat-65 5.04s, 4.93s, 4.88s
c. calculated cost of launcher
Memorize-34 1.89s
Moon-11 3.73s
Chat-65 1.64s
Diagnosis: removing the launcher animation saved between one and four
seconds of startup time. The saving was greatest for the Moon activity.
--
Research: determine if the SVG icon for the Moon activity contributes
to the delay.
Method: swap the icons, restart Sugar, retest only Chat activity with
Moon icon.
Result:
a. unmodified launcher.py
Chat-65 7.83s, 7.59s, 7.62s
b. modified launcher.py (black background, no animation),
Chat-65 4.99s, 4.87s, 4.90s
c. calculated cost of launcher
Chat-65 2.75s (greater than previous)
d. calculated cost of moon icon over chat icon
Chat-65 1.09s
Diagnosis: the degree of saving has a little to do with the SVG icon
complexity. The degree of saving has much to do with the mix of
operations performed by the activity during startup.
--
So, between 23 and 92 wasted days of looking at the launcher across
two million laptops. Good time to think and plan, kids.
--
James Cameron
http://quozl.linux.org.au/
--- launcher.py.orig 2010-10-28 02:56:43.0 +
+++ launcher.py 2010-10-28 02:58:18.0 +
@@ -35,13 +35,13 @@
self.props.type_hint = gtk.gdk.WINDOW_TYPE_HINT_NORMAL
canvas = hippo.Canvas()
-canvas.modify_bg(gtk.STATE_NORMAL, style.COLOR_WHITE.get_gdk_color())
+canvas.modify_bg(gtk.STATE_NORMAL, style.COLOR_BLACK.get_gdk_color())
self.add(canvas)
canvas.show()
self._activity_id = activity_id
-self._box = LaunchBox(activity_id, icon_path, icon_color)
-canvas.set_root(self._box)
+#self._box = LaunchBox(activity_id, icon_path, icon_color)
+#canvas.set_root(self._box)
self.connect('realize', self.__realize_cb)
@@ -52,7 +52,7 @@
def show(self):
self.present()
-self._box.zoom_in()
+#self._box.zoom_in()
def _update_size(self):
self.resize(gtk.gdk.screen_width(), gtk.gdk.screen_height())
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] wordgroupz ( A vocabulary building app) ported to sugar
@Gary ping ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] an ardent proposal to bring *LOVE* back into Sugar Labs
(1) In-person meetings in between Bostonian http://wiki.sugarlabs.org/go/Oversight_Board members and Sugar/OLPC Local Lab Boston, quasimonthly. Community is neither a buzzword, nor a fantasy, with Sugar Labs' only 4 active board members now living in Boston today. Community is the 132 volunteer members of http://lists.laptop.org/listinfo/olpc_boston who want to particitepate in Sugar/OLPC but our promise withers, when accomplished teachers and volunteers willing to pull their weight, simply don't -- as too many of us are unintentionally hiding behind our IRC koolaid, yep myself guilty as charged :) So it's time to throw a few parties. And get over a couple of our antisocial hangups, at all levels of our organizing. As our 130+ person high-energy http://olpcSF.org/summit this past weekend proved far beyond a shadow of a doubt. As SF's own amazing hackerspace (http://noisebridge.net) reminded us all late into the night before. Sustainable volunteerism == bringing people together in a physical space, even in Boston! Like others have already done globally here: http://wiki.sugarlabs.org/go/Local_Labs . I made this happen last week in San Francisco for almost 10 valiant-but-poor-volunteers, by lining them up with other more well-off volunteers, using peer2peer donations instead of bureaucratic budget molasses. Next year we can do this for 20 volunteers instead of 10, if we bring ourselves together. Meantime: I, Walter, Bernie and CJB (etc) can do our Boston and Global community a gigantic favor if we Get Out More right here at home :) Learning (i.e. healthy) communities live or die based on the Rhythm their members create -- physical bonds feed online bonds and vice versa. Let us begin now. Progress beckons: Walter, Bernie I will meet all together Thurs (tomorrow) for the first time in about a year, to discuss our breakthrough community catapult in SF, even before SF's Mayor issued his proclamation: http://blog.laptop.org/2010/10/22/october-23-is-olpc-day-in-sf/ (2) Democracy does NOT grow on trees, or in the back of stale legalistic texts. It is the worst form of governance, if we believe Churchill, and accordingly I and Sugar Labs' Oversight Board have been negligent in not getting folks fired up about the current election process, failing to bringing strong awareness around precise key election dates, even understanding it ourselves! I personally consider both to be constitutional duty: the cleanest elections happen when we enable get-out-the-vote mobilizations of all kind, enabling expression and reflection AKA learning. Disturbing evidence I've uncovered in the past 24hrs is that board members themselves I've spoken to privately remain confused about nomination/election dates, confused about duration of terms, confused about lame duck/impeachment/replacement/re-invitation procedures for the several absentee board members already gone. Pity our rank+file volunteer just trying to get some work done, or get fired up about our so-sweet possibilities! Now drowning in this unadvertised/undecided election machinery-- No more! I suggest we start with Informed Consent, meaning strong advance awareness of all deadlines and voting times -- that we hopefully all together agree to publicize very directly off: http://google.com/search?q=sugar+labs+election (3) One specific proposal around strengthening awareness of Sugar Labs' election clearly, widely and far more passionately, with all dates clearly layed out, right off the uniquely memorable page above -- was advanced by Luke Faraone (administering the election) earlier this evening. Walter Bender says he would agree to support Luke's proposal to extend registration (welcoming quality candidates eligible voters both) until something like Nov 10th 23:59 EST, if the election itself was delayed until approximately Nov 14-27, IF our broad community and board agrees this will all deepen our Participative process, strengthen who we are, illustrate our shared sacrifice -- and most importantly: waken our family and friends to our cause. Yes, I'm paraphrasing, Walter please speak for yourself :) In any case, for me clearness-in-democracy is non-negotiable, as is our blessed responsibility to stay young, Meaningfully open (Lovable too please!) while at last growing up as a 2008-2012 organization, as this election will now decide. I support Luke's above thoughtful proposal and hope others will too, enhancing it ideally if you can, but most important all speaking our consciences towards deciding quickly and carefully, however we proceed. (4) First kill all the lawyers (but please Shakespeare DO read our SFC by-laws at http://wiki.sugarlabs.org/go/Sugar_Labs/SFC-SugarLabs_Agreement and http://wiki.sugarlabs.org/go/Sugar_Labs/Members/List carefully before the light goes out :) And if a board meeting is needed to finalize any electoral learning learning consensus(es)
Re: [Sugar-devel] wordgroupz ( A vocabulary building app) ported to sugar
On Wed, Oct 20, 2010 at 2:55 PM, Tim McNamara paperl...@timmcnamara.co.nz wrote: I think Collect would be an excellent name for an Activity. It's a verb with a single word. Indeed. It is a good suggestion. Thank you. -- sankarshan mukhopadhyay http://sankarshan.randomink.org/blog ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
