[Sugar-devel] Sugar theme for Pharo Smalltalk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, We are working on customizing Pharo Smalltalk to turn it as a development platform to develop Sugar activities. http://code.google.com/p/pharo/wiki/PharoForSugar Examples of such activities are DrGeo and MagicWords. We things Pharo Smalltalk greatly improves the productivity to write activities. Hilaire Reference page: http://code.google.com/p/pharo/wiki/PharoForSugar Screen shot of themed Pharo: http://blog.ofset.org/hilaire/index.php?post/2010/07/17/Sugar-theme- fpr-Pharo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkxFXg4ACgkQSAvrR6lz6PRcwwCfTNufSdNtiKRlUC3iLPeAim/9 /XEAn0+axRU0D/QNJECth7OoTiE3AorR =DXEc -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] behaviour of F-keys on XO HS
james wrote: On Tue, Jul 20, 2010 at 01:04:06AM -0400, Raul Gutierrez Segales wrote: On Mon, 2010-07-19 at 21:33 -0400, Walter Bender wrote: On Mon, Jul 19, 2010 at 9:27 PM, Gonzalo Odiard godi...@gmail.com wrote: Yeah How we detect what keyboard is present? http://wiki.laptop.org/go/OLPC_Firmware_q3a44 mentions: 1889: OLPC keyboard driver, avoid confusing EC with enable scan command That's unrelated, I think. yes. the keyboards are indistinguishable electrically, without user input. I wonder if somehow the type of detected keyboard is discoverable via /ofw. The manufacturing data may help to narrow the possibilities, but they would have to be maintained correctly in conjunction with any keyboard changes by deployment repair. Perhaps someone else knows more. right. when the laptops are build, the included keyboard is identified with a specific tag. specifically, the KM tag is olpcm for the mechanical keyboard, and olpc for the membrane keyboards. however, someday it will be possible to swap between membrane and mechanical keyboards (it isn't yet), and that will raise a new identification issue. i suspect we'll end up with a user utility of some sort to correctly identify the keyboard to the system. the upper right-hand key, for instance, is unique on each, so asking the user to hit that will be sufficient. the utility will then rewrite the mfg tag (doubtful) or modify the filesystem (more likely) to record the identification. further background: the KM mfg tag is used by /etc/init.d/olpc-configure to set up the XKB_MODEL variable assignment in /etc/sysconfig/keyboard (this happens just once per software install). when the user session starts, olpc-session sources /etc/sysconfig/keyboard, and passes the XKB_MODEL value to setxkbmap. setxkbmap can in turn be queried to find out what keyboard model (and layout and variant) is in use. i suspect that this is the mechanism that applications should use to detect which keyboard they have, because it's xkb that has to have the right answer in order for all the characters to work correctly. i don't know if there's a programming API lurking under the covers in setxkbmap -print, or not. paul =- paul fox, p...@laptop.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [Testing request] Browse-webkit
El Tue, 20-07-2010 a las 03:07 +0100, Lucian Branescu escribió: rgs and myself have ported Browse to pywebkitgtk with all features and we could use some testing. You can get it from here http://git.sugarlabs.org/projects/browse/repos/mainline/trees/webkit It requires pywebkitgtk 1.1.6 and webkitgtk 1.2.*. Can you provide an installable xo bundle? Also, note that pywebkitgtk 1.1.6 in fedora (11 and 12 have been observed so far) segfaults. So either wait for the fix or use another distro in a VM. I've just pushed an updated pywebkitgtk-1.1.7 rpm to the f11-0.88 repository. -- // 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
[Sugar-devel] Call for Testers: LiveUSB Creator on other Distributions
Hi all, I'd like us to get a coherent way in terms of user interfaces for creating Sugar on a Stick on as many distributions as possible. I do have a first iteration of such a release using Fedora's LiveUSB Creator ready and need some testers with - preferably different - distributions. There are a couple of things that need to be checked before this is ready for mass-consumption, but if you're interested in giving this a try, please drop me a line and note the distributions you're running on real machines on which you could actually test this. Thanks, --Sebastian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Read/evince quick follow up
I've implemented copy and search. There may still be some loose ends somewhere and I haven't tested epubs at all. On 20 July 2010 05:24, Gary C Martin garycmar...@googlemail.com wrote: Hi Lucian, Fab thanks. A git clone of your http://git.sugarlabs.org/git/read/evince-2-30.git now does the trick for testing in SoaS Mirabelle. Toolbars look good this time :-) I've only tested it on a couple of Gutenberg text PDFs so far, so yes as you mentioned the Edit toolbar is not so functional yet (no copy, no search). Everything else seems great so far e.g. - creating bookmarks work - page count and current page is correct - forward/back work moving one screens worth at a time (sub menus for by page and bookmarks also work) - view zoom in/out is good - view zoom to fit width is good - incremental zoom widget good - full screen view (and back again) good I'll try a wider range of test PDF's later (with more image content, some really great edu material at http://www.ck12.org if perhaps at our upper target age range). Are there any other document types that evince was supporting that I should go test? Fantastic work!! Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Call for Testers: LiveUSB Creator on other Distributions
2 links from wiki: http://wiki.sugarlabs.org/go/Category:Live_USB http://wiki.sugarlabs.org/go/Downloads (for different distros) + http://wiki.sugarlabs.org/go/VMware#openSUSE http://download.sugarlabs.org/activities/4216/usb_creator-1.xo (For Trisquel-Toast) possibly also Ubuntu? Most can be run from VMware or installed to USB Tom Gilliard satellit Sebastian Dziallas wrote: Hi all, I'd like us to get a coherent way in terms of user interfaces for creating Sugar on a Stick on as many distributions as possible. I do have a first iteration of such a release using Fedora's LiveUSB Creator ready and need some testers with - preferably different - distributions. There are a couple of things that need to be checked before this is ready for mass-consumption, but if you're interested in giving this a try, please drop me a line and note the distributions you're running on real machines on which you could actually test this. Thanks, --Sebastian ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Read/evince quick follow up
Another feature that doesn't work is Table of Contents for pdfs that have it. On 20 July 2010 15:00, Lucian Branescu lucian.brane...@gmail.com wrote: I've implemented copy and search. There may still be some loose ends somewhere and I haven't tested epubs at all. On 20 July 2010 05:24, Gary C Martin garycmar...@googlemail.com wrote: Hi Lucian, Fab thanks. A git clone of your http://git.sugarlabs.org/git/read/evince-2-30.git now does the trick for testing in SoaS Mirabelle. Toolbars look good this time :-) I've only tested it on a couple of Gutenberg text PDFs so far, so yes as you mentioned the Edit toolbar is not so functional yet (no copy, no search). Everything else seems great so far e.g. - creating bookmarks work - page count and current page is correct - forward/back work moving one screens worth at a time (sub menus for by page and bookmarks also work) - view zoom in/out is good - view zoom to fit width is good - incremental zoom widget good - full screen view (and back again) good I'll try a wider range of test PDF's later (with more image content, some really great edu material at http://www.ck12.org if perhaps at our upper target age range). Are there any other document types that evince was supporting that I should go test? Fantastic work!! Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #1669 UNSP: Accessibility - keyboard
modification for the svg file icon and remove makefile.in
diff -u -r -N sugar-0.88.1.original.con.parches.viejos/bin/sugar-session
sugar-0.88.1/bin/sugar-session
--- sugar-0.88.1.original.con.parches.viejos/bin/sugar-session2010-06-02
09:33:43.0 -0300
+++ sugar-0.88.1/bin/sugar-session2010-06-21 11:48:06.837182011 -0300
@@ -1,6 +1,7 @@
#!/usr/bin/env python
# Copyright (C) 2006, Red Hat, Inc.
# Copyright (C) 2009, One Laptop Per Child Association Inc
+# Copyright (C) 2010, Plan Ceibal comuni...@plan.ceibal.edu.uy
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
@@ -190,6 +191,7 @@
gobject.idle_add(setup_notification_service_cb)
gobject.idle_add(setup_file_transfer_cb)
gobject.idle_add(show_software_updates_cb)
+gobject.idle_add(setup_accessibility_cb)
if sys.modules.has_key('xklavier'):
gobject.idle_add(setup_keyboard_cb)
@@ -201,6 +203,11 @@
settings = gtk.settings_get_default()
settings.set_property(gtk-font-name, %s %f % (face, size))
+def setup_accessibility_cb():
+from jarabe.model import accessibility
+accessibility_manager = accessibility.AccessibilityManager()
+accessibility_manager.setup_accessibility()
+
def main():
try:
from sugar import env
diff -u -r -N sugar-0.88.1.original.con.parches.viejos/configure.acsugar-0.88.1/
configure.ac
--- sugar-0.88.1.original.con.parches.viejos/configure.ac2010-06-21
11:39:19.902054000 -0300
+++ sugar-0.88.1/configure.ac2010-06-21 11:44:16.697208930 -0300
@@ -50,6 +50,7 @@
data/Makefile
data/sugar-emulator.desktop
extensions/cpsection/aboutcomputer/Makefile
+extensions/cpsection/accessibility/Makefile
extensions/cpsection/aboutme/Makefile
extensions/cpsection/datetime/Makefile
extensions/cpsection/frame/Makefile
diff -u -r -N
sugar-0.88.1.original.con.parches.viejos/data/icons/Makefile.am
sugar-0.88.1/data/icons/Makefile.am
--- sugar-0.88.1.original.con.parches.viejos/data/icons/Makefile.am
2010-06-21 11:39:19.902054000 -0300
+++ sugar-0.88.1/data/icons/Makefile.am2010-06-21 11:54:27.040055731
-0300
@@ -3,6 +3,7 @@
sugar_DATA =\
module-about_me.svg \
module-about_my_computer.svg\
+module-accessibility.svg\
module-date_and_time.svg\
module-frame.svg\
module-journalmanagement.svg\
diff -u -r -N
sugar-0.88.1.original.con.parches.viejos/data/icons/module-accessibility.svg
sugar-0.88.1/data/icons/module-accessibility.svg
---
sugar-0.88.1.original.con.parches.viejos/data/icons/module-accessibility.svg
1969-12-31 21:00:00.0 -0300
+++ sugar-0.88.1/data/icons/module-accessibility.svg2010-07-08
09:19:22.288067133 -0300
@@ -0,0 +1,92 @@
+?xml version=1.0 encoding=UTF-8 standalone=no?
+!-- Created with Inkscape (http://www.inkscape.org/) --
+
+svg
+ xmlns:svg=http://www.w3.org/2000/svg;
+ xmlns=http://www.w3.org/2000/svg;
+ version=1.0
+ width=55
+ height=55
+ id=svg795
+ defs
+ id=defs797 /
+ g
+ id=layer1
+path
+ d=m -23.738584,30.440666 a 8.901969,11.301082 0 1 1 -17.803937,0
8.901969,11.301082 0 1 1 17.803937,0 z
+ transform=matrix(1.2765958,0,0,1.0558659,19.192898,-13.127946)
+ id=path12
+ style=fill:none;stroke:#ff /
+path
+ d=m 30.145644,37.823484 c -0.583589,6.659344 -6.7511,11.52268
-13.775517,10.862567 C 9.3457054,48.02594 4.1243814,42.092348
4.7079694,35.433004 5.2915594,28.773661 20.67887,20.597949
14.885997,24.011638 -12.777062,40.313232 24.43362,62.068174
30.145644,37.823484 z
+ id=path1405-0
+
style=fill:none;stroke:#ff;stroke-width:1.44962609;stroke-opacity:1 /
+rect
+ width=2.916333
+ height=21.188446
+ ry=1.3939767
+ x=18.332197
+ y=13.76814
+ id=rect1438-8
+
style=fill:#ff;fill-opacity:1;stroke:#ff;stroke-width:1.50547338;stroke-opacity:1
/
+rect
+ width=2.8716421
+ height=19.140917
+ ry=1.259271
+ x=-35.091366
+ y=-38.207035
+ transform=matrix(0,-1,-1,0,0,0)
+ id=rect1438-1-87
+
style=fill:#ff;fill-opacity:1;stroke:#ff;stroke-width:1.41987956;stroke-opacity:1
/
+rect
+ width=2.5733202
+ height=15.766372
+ ry=1.0372615
+ x=-5.4068875
+ y=-65.997124
+
transform=matrix(-0.55477829,0.83199823,-0.68762037,-0.72607041,0,0)
+ id=rect1438-0-4
+
style=fill:#ff;fill-opacity:1;stroke:#ff;stroke-width:1.21988189;stroke-opacity:1
/
+rect
+ width=2.0588
+ height=12.916228
+ ry=0.84975183
+ x=6.7647386
+ y=-38.278324
+
transform=matrix(-0.21998034,0.97550431,-0.88967727,-0.45658992,0,0)
+ id=rect1438-0-1-8
+
style=fill:#ff;fill-opacity:1;stroke:#ff;stroke-width:0.98759735;stroke-opacity:1
/
+rect
+ width=0.98179615
+ height=13.275604
+ ry=0.87339497
+
[Sugar-devel] Hosting activities(and its deps) sources(and not only) tarballs
Hi all, I'm working on Zero Sugar packaging infrastructure and wandering how to solve activity tarballs/bundles/etc hoisting issue. Until now, I kept in mind only rsync access to remote directory (on sunjammer by default). But I guess it is overkill to require arbitrary activity developer to have ssh access to sunjammer (but it fine for core/fructose developers). There could be, at least, several options: * OBS (hosted by openSUSE or SL). http://wiki.opensuse.org/openSUSE:Build_Service It is full functional packaging environment but mainly targeting to native packages. But at the end, activities could be implicitly turned (using 0sugar) to native packages just by having an analog of existed activity.info file. So, we can have one packaging/code-sharing portal for developers (in comparing with sharing portal for users - ASLO). * reuse ASLO. It is already used for .xo uploads, but .xo, as primary sharing model, should die at earlier or later. Activity developers will upload sources (manually or via tools like 0sugar) to ASLO via web UI or http api like OBS has (https://api.opensuse.org/apidocs/). Any ideas? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hosting activities(and its deps) sources(and not only) tarballs
On Tue, Jul 20, 2010 at 04:04:56PM +, Aleksey Lim wrote: Hi all, I'm working on Zero Sugar packaging infrastructure and wandering how to solve activity tarballs/bundles/etc hoisting issue. Until now, I kept in mind only rsync access to remote directory (on sunjammer by default). But I guess it is overkill to require arbitrary activity developer to have ssh access to sunjammer (but it fine for core/fructose developers). There could be, at least, several options: * OBS (hosted by openSUSE or SL). http://wiki.opensuse.org/openSUSE:Build_Service It is full functional packaging environment but mainly targeting to native packages. But at the end, activities could be implicitly turned (using 0sugar) to native packages just by having an analog of existed activity.info file. So, we can have one packaging/code-sharing portal for developers (in comparing with sharing portal for users - ASLO). * reuse ASLO. It is already used for .xo uploads, but .xo, as primary sharing model, should die at earlier or later. Activity developers will upload sources (manually or via tools like 0sugar) to ASLO via web UI or http api like OBS has (https://api.opensuse.org/apidocs/). In the system, I'm implementing right now, there is no difference what particular server will be used to host tarballs (every activity is identified by http url and the page for this url will contain all information to get info about sources/home-page/etc). But activity developer needs a server to host activities anyway. Any ideas? -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Read/evince quick follow up
I've enabled epub view. It requires both python-lxml and python-BeautifulSoup installed (for some reason) and none of the toolbars work in epub view. On 20 July 2010 16:51, Lucian Branescu lucian.brane...@gmail.com wrote: Another feature that doesn't work is Table of Contents for pdfs that have it. On 20 July 2010 15:00, Lucian Branescu lucian.brane...@gmail.com wrote: I've implemented copy and search. There may still be some loose ends somewhere and I haven't tested epubs at all. On 20 July 2010 05:24, Gary C Martin garycmar...@googlemail.com wrote: Hi Lucian, Fab thanks. A git clone of your http://git.sugarlabs.org/git/read/evince-2-30.git now does the trick for testing in SoaS Mirabelle. Toolbars look good this time :-) I've only tested it on a couple of Gutenberg text PDFs so far, so yes as you mentioned the Edit toolbar is not so functional yet (no copy, no search). Everything else seems great so far e.g. - creating bookmarks work - page count and current page is correct - forward/back work moving one screens worth at a time (sub menus for by page and bookmarks also work) - view zoom in/out is good - view zoom to fit width is good - incremental zoom widget good - full screen view (and back again) good I'll try a wider range of test PDF's later (with more image content, some really great edu material at http://www.ck12.org if perhaps at our upper target age range). Are there any other document types that evince was supporting that I should go test? Fantastic work!! Regards, --Gary ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] touchpad section for Sugar Control Panel
Here is another version of the touchpad-on-the-frame patch with all of
the changes recommended by Marco et al.
From 47221ac4277a649c4808231f5616d75d73ab48e0 Mon Sep 17 00:00:00 2001
From: Walter Bender wal...@sugarlabs.org
Date: Tue, 20 Jul 2010 14:11:28 -0400
Subject: [PATCH] touchpad device on frame
---
extensions/deviceicon/Makefile.am |1 +
extensions/deviceicon/touchpad.py | 129 +
2 files changed, 130 insertions(+), 0 deletions(-)
create mode 100644 extensions/deviceicon/touchpad.py
diff --git a/extensions/deviceicon/Makefile.am
b/extensions/deviceicon/Makefile.am
index 8a2e765..7f82a3f 100644
--- a/extensions/deviceicon/Makefile.am
+++ b/extensions/deviceicon/Makefile.am
@@ -5,4 +5,5 @@ sugar_PYTHON = \
battery.py \
network.py \
speaker.py \
+touchpad.py \
volume.py
diff --git a/extensions/deviceicon/touchpad.py
b/extensions/deviceicon/touchpad.py
new file mode 100644
index 000..7f3ecb5
--- /dev/null
+++ b/extensions/deviceicon/touchpad.py
@@ -0,0 +1,129 @@
+# Copyright (C) 2010, Walter Bender, Sugar Labs
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+
+
+from gettext import gettext as _
+import os
+
+import gtk
+import gconf
+
+from sugar.graphics.tray import TrayIcon
+from sugar.graphics.xocolor import XoColor
+from sugar.graphics.palette import Palette
+from sugar.graphics import style
+
+from jarabe.frame.frameinvoker import FrameWidgetInvoker
+
+TOUCHPAD_MODES = ['capacitive', 'resistive']
+STATUS_TEXT = {TOUCHPAD_MODES[0]: _('finger'), TOUCHPAD_MODES[1]: _('stylus')}
+STATUS_ICON = {TOUCHPAD_MODES[0]: 'touchpad-' + TOUCHPAD_MODES[0],
+ TOUCHPAD_MODES[1]: 'touchpad-' + TOUCHPAD_MODES[1]}
+# FLAG_PATH is used to preserve status between boots.
+FLAG_PATH = '/home/olpc/.olpc-pentablet-mode'
+# NODE_PATH is used to communicate with the touchpad device.
+NODE_PATH = '/sys/devices/platform/i8042/serio1/ptmode'
+
+class DeviceView(TrayIcon):
+ Manage the touchpad mode from the device palette on the Frame.
+
+FRAME_POSITION_RELATIVE = 500
+
+def __init__(self):
+ Create the touchpad palette and display it on Frame.
+icon_name = STATUS_ICON[read_touchpad_mode()]
+
+client = gconf.client_get_default()
+color = XoColor(client.get_string('/desktop/sugar/user/color'))
+TrayIcon.__init__(self, icon_name=icon_name, xo_color=color)
+
+self.set_palette_invoker(FrameWidgetInvoker(self))
+self.connect('button-release-event', self.__button_release_event_cb)
+
+def create_palette(self):
+ On create, set the current mode.
+self.palette = ResourcePalette(_('My touchpad'), self.icon)
+self.palette.set_group_id('frame')
+return self.palette
+
+def __button_release_event_cb(self, widget, event):
+ On button release, switch modes.
+self.palette.toggle_mode()
+return True
+
+
+class ResourcePalette(Palette):
+ Query the current state of the touchpad and update the display.
+
+def __init__(self, primary_text, icon):
+ Create the palette and initilize with current touchpad status.
+Palette.__init__(self, label=primary_text)
+
+self._icon = icon
+
+vbox = gtk.VBox()
+self.set_content(vbox)
+
+self._status_text = gtk.Label()
+vbox.pack_start(self._status_text, padding=style.DEFAULT_PADDING)
+self._status_text.show()
+
+vbox.show()
+
+self._mode = read_touchpad_mode()
+self._update()
+
+def _update(self):
+ Update the label and icon based on the current mode.
+self._status_text.set_label(STATUS_TEXT[self._mode])
+self._icon.props.icon_name = STATUS_ICON[self._mode]
+
+def toggle_mode(self):
+ On mouse click, toggle the mode.
+self._mode = TOUCHPAD_MODES[1 - TOUCHPAD_MODES.index(self._mode)]
+write_touchpad_mode(self._mode)
+self._update()
+
+
+def setup(tray):
+ Touchpad palette only appears when the device exisits.
+if os.path.exists(NODE_PATH):
+tray.add_device(DeviceView())
+
+
+def read_touchpad_mode():
+ Read the touchpad mode from the node path.
+node_file_handle = open(NODE_PATH, 'r')
+text =
[Sugar-devel] [PATCH 1/2] new color selector for control panel
These modifications to xocolor.py are used by the new color selector.
-walter
From ced1b1cde0117441665b5eae7ac7c20f7e39a743 Mon Sep 17 00:00:00 2001
From: Walter Bender wal...@sugarlabs.org
Date: Tue, 20 Jul 2010 14:58:22 -0400
Subject: [PATCH] extended xocolor for new color selector
---
src/sugar/graphics/xocolor.py | 78 +---
1 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/src/sugar/graphics/xocolor.py b/src/sugar/graphics/xocolor.py
index fd329cb..8b5a686 100644
--- a/src/sugar/graphics/xocolor.py
+++ b/src/sugar/graphics/xocolor.py
@@ -1,4 +1,5 @@
# Copyright (C) 2006-2007 Red Hat, Inc.
+# Copyright (C) 2008-2010 Sugar Labs
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
@@ -225,14 +226,34 @@ def is_valid(color_string):
return (_parse_string(color_string) != None)
+def get_random_color():
+color_index = int(random.random() * (len(colors) - 1))
+return %s,%s % (colors[color_index][0], colors[color_index][1])
+
+
+def _next_index(i):
+next_index = i + 1
+if next_index == len(colors):
+next_index = 0
+return next_index
+
+
+def _prev_index(i):
+prev_index = i - 1
+if prev_index 0:
+prev_index = len(colors)-1
+return prev_index
+
+
class XoColor:
def __init__(self, color_string=None):
if color_string == None:
randomize = True
elif not is_valid(color_string):
-logging.debug('Color string is not valid: %s, '
- 'fallback to default', color_string)
+logging.error(
+'Color string is not valid: %s; fallback to default',
+color_string)
client = gconf.client_get_default()
color_string = client.get_string('/desktop/sugar/user/color')
randomize = False
@@ -240,10 +261,9 @@ class XoColor:
randomize = False
if randomize:
-n = int(random.random() * (len(colors) - 1))
-[self.stroke, self.fill] = colors[n]
-else:
-[self.stroke, self.fill] = _parse_string(color_string)
+color_string = get_random_color()
+[self.stroke, self.fill] = _parse_string(color_string)
+self._current_color_index = self._find_index()
def __cmp__(self, other):
if isinstance(other, XoColor):
@@ -257,9 +277,55 @@ class XoColor:
def get_fill_color(self):
return self.fill
+def set_color(self, color_string):
+if color_string == None or not is_valid(color_string):
+logging.error(
+'Color string is not valid: %s; fallback to default',
+color_string)
+else:
+[self.stroke, self.fill] = _parse_string(color_string)
+self._current_color_index = self._find_index()
+
+def get_next_color(self):
+next_index = _next_index(self._current_color_index)
+return %s,%s % (colors[next_index][0], colors[next_index][1])
+
+def get_prev_color(self):
+prev_index = _prev_index(self._current_color_index)
+return %s,%s % (colors[prev_index][0], colors[prev_index][1])
+
+def get_next_stroke_color(self):
+next_index = _next_index(self._current_color_index)
+while (colors[next_index][1] != self.fill):
+next_index = _next_index(next_index)
+return %s,%s % (colors[next_index][0], colors[next_index][1])
+
+def get_prev_stroke_color(self):
+prev_index = _prev_index(self._current_color_index)
+while (colors[prev_index][1] != self.fill):
+prev_index = _prev_index(prev_index)
+return %s,%s % (colors[prev_index][0], colors[prev_index][1])
+
+def get_next_fill_color(self):
+next_index = _next_index(self._current_color_index)
+while (colors[next_index][0] != self.stroke):
+next_index = _next_index(next_index)
+return %s,%s % (colors[next_index][0], colors[next_index][1])
+
+def get_prev_fill_color(self):
+prev_index = _prev_index(self._current_color_index)
+while (colors[prev_index][0] != self.stroke):
+prev_index = _prev_index(prev_index)
+return %s,%s % (colors[prev_index][0], colors[prev_index][1])
+
def to_string(self):
return '%s,%s' % (self.stroke, self.fill)
+def _find_index(self):
+for color in range(0, len(colors)):
+if colors[color] == [self.stroke, self.fill]:
+return color
+return 0
if __name__ == __main__:
import sys
--
1.7.0.4
--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH 2/2] new color selector for control panel
And the mods to the color selector itself.
From 31e9281e8c3439462ed58ec53558b1c47f74c471 Mon Sep 17 00:00:00 2001
From: Walter Bender wal...@sugarlabs.org
Date: Tue, 20 Jul 2010 14:50:47 -0400
Subject: [PATCH] new color selector for cpsection
---
extensions/cpsection/aboutme/view.py | 182 ++
1 files changed, 117 insertions(+), 65 deletions(-)
diff --git a/extensions/cpsection/aboutme/view.py
b/extensions/cpsection/aboutme/view.py
index cabd66a..caf6d29 100644
--- a/extensions/cpsection/aboutme/view.py
+++ b/extensions/cpsection/aboutme/view.py
@@ -25,13 +25,21 @@ from sugar.graphics.xocolor import XoColor
from jarabe.controlpanel.sectionview import SectionView
from jarabe.controlpanel.inlinealert import InlineAlert
+_DIRECTION_LEFT = 0
+_DIRECTION_TOP = 1
+_DIRECTION_CENTER = 2
+_DIRECTION_BOTTOM = 3
+_DIRECTION_RIGHT = 4
+
+
class EventIcon(gtk.EventBox):
-__gtype_name__ = SugarEventIcon
-def __init__(self, **kwargs):
+__gtype_name__ = SugarEventIcon
+
+def __init__(self, **kwargs):
gtk.EventBox.__init__(self)
-self.icon = Icon(pixel_size = style.XLARGE_ICON_SIZE, **kwargs)
-
+self.icon = Icon(pixel_size=style.XLARGE_ICON_SIZE, **kwargs)
+
self.set_visible_window(False)
self.set_app_paintable(True)
self.set_events(gtk.gdk.BUTTON_PRESS_MASK)
@@ -39,28 +47,45 @@ class EventIcon(gtk.EventBox):
self.add(self.icon)
self.icon.show()
+
class ColorPicker(EventIcon):
__gsignals__ = {
'color-changed': (gobject.SIGNAL_RUN_FIRST,
gobject.TYPE_NONE,
- ([str]))
-}
-def __init__(self, xocolor=None):
+ ([object]))
+}
+
+def __init__(self, direction):
EventIcon.__init__(self)
-self.icon.props.xo_color = xocolor
+
self.icon.props.icon_name = 'computer-xo'
+self._direction = direction
+self._color = None
+
self.icon.props.pixel_size = style.XLARGE_ICON_SIZE
-self.connect('button_press_event', self.__pressed_cb)
-def __pressed_cb(self, button, event):
-self._set_random_colors()
+self.connect('button_press_event', self.__pressed_cb, direction)
+
+def update(self, color):
+if self._direction == _DIRECTION_CENTER:
+self._color = color
+elif self._direction == _DIRECTION_LEFT:
+self._color = XoColor(color.get_prev_fill_color())
+elif self._direction == _DIRECTION_RIGHT:
+self._color = XoColor(color.get_prev_stroke_color())
+elif self._direction == _DIRECTION_TOP:
+self._color = XoColor(color.get_next_fill_color())
+else:
+self._color = XoColor(color.get_next_stroke_color())
+self.icon.props.xo_color = self._color
+
+def __pressed_cb(self, button, event, direction):
+if direction != _DIRECTION_CENTER:
+self.emit('color-changed', self._color)
-def _set_random_colors(self):
-xocolor = XoColor()
-self.icon.props.xo_color = xocolor
-self.emit('color-changed', xocolor.to_string())
class AboutMe(SectionView):
+
def __init__(self, model, alerts):
SectionView.__init__(self)
@@ -69,44 +94,45 @@ class AboutMe(SectionView):
self._nick_sid = 0
self._color_valid = True
self._nick_valid = True
-self._color_change_handler = None
-self._nick_change_handler = None
+self._handlers = []
self.set_border_width(style.DEFAULT_SPACING * 2)
self.set_spacing(style.DEFAULT_SPACING)
self._group = gtk.SizeGroup(gtk.SIZE_GROUP_HORIZONTAL)
+self._color_label = gtk.HBox(spacing=style.DEFAULT_SPACING)
+self._color_box = gtk.HBox(spacing=style.DEFAULT_SPACING)
+self._color_alert_box = gtk.HBox(spacing=style.DEFAULT_SPACING)
+self._color_alert = None
+
+self._pickers = {
+_DIRECTION_CENTER: ColorPicker(_DIRECTION_CENTER),
+_DIRECTION_LEFT: ColorPicker(_DIRECTION_LEFT),
+_DIRECTION_RIGHT: ColorPicker(_DIRECTION_RIGHT),
+_DIRECTION_TOP: ColorPicker(_DIRECTION_TOP),
+_DIRECTION_BOTTOM: ColorPicker(_DIRECTION_BOTTOM)
+}
+
+self._setup_color()
+initial_color = XoColor(self._model.get_color_xo())
+self._update_pickers(initial_color)
+
self._nick_box = gtk.HBox(spacing=style.DEFAULT_SPACING)
self._nick_alert_box = gtk.HBox(spacing=style.DEFAULT_SPACING)
self._nick_entry = None
self._nick_alert = None
self._setup_nick()
-
-self._color_box = gtk.HBox(spacing=style.DEFAULT_SPACING)
-self._color_alert_box = gtk.HBox(spacing=style.DEFAULT_SPACING)
-self._color_picker = None
-self._color_alert = None
-self._setup_color()
-
self.setup()
def
Re: [Sugar-devel] HELP REQUEST: Record activity developers / gstream experts
On Fri, Jul 16, 2010 at 02:54:39PM +0300, Joseph Gordon wrote:
Dear developers
First I'd like to say I love your code and it was easy to find where the
changes would be made. I am working on a secondary school deployment of 1.5s
and I would like to support usb microscopes within the sugar environment. I
am working at Ntugi school in kenya www.ntugischool.com feel free to look us
up.
My device can be called with gstream as /dev/video1 but does not support
frame caps, colorspace or other driver controls. All i want to be able to do
is see the live image and take a picture. I can make most of the gui changes
but im stuck when it comes to glive.py. I do not know where the changes need
to be made to support this device. I can take a pic with pipeline =
gst.parse_launch('v4l2src device=/dev/video1 ! jpegenc ! filesink
location=/tmp/microscope.jpg')
Any feedback would be great.
What about creating activity only for this particular purpose,
I mean it could be more useful to keep Record simple and support
in Microscope activity special workflows. For example there is TimeLaps
activity (http://activities.sugarlabs.org/en-US/sugar/addon/4270) which
is also record/video related.
Adam Gordon
Upper Canada College
Toronto, ON, Canada
www.ntugischool.com
PS. I am in Kenya until the 21st where implementation would be easy, though
the communication between us is strong enough to impliment this later aswell.
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] Call for Testers: LiveUSB Creator on other Distributions
On Tue, Jul 20, 2010 at 9:41 AM, Sebastian Dziallas sebast...@when.com wrote: Hi all, I'd like us to get a coherent way in terms of user interfaces for creating Sugar on a Stick on as many distributions as possible. I do have a first iteration of such a release using Fedora's LiveUSB Creator ready and need some testers with - preferably different - distributions. There are a couple of things that need to be checked before this is ready for mass-consumption, but if you're interested in giving this a try, please drop me a line and note the distributions you're running on real machines on which you could actually test this. Thanks, --Sebastian ___ SoaS mailing list s...@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/soas Comments: * All of the .so files are marked as +x in the tar file. Probably only the script itself need be executable. * The script needs to be run as root from the shell. * It would be great to set a non-zero persistent storage -walter (testing on Lucid) -- 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] Calculate bug, help!
Hi Reinier, On 20 Jul 2010, at 00:45, Reinier Heeres wrote: Hi Gary, I agree that the AstParser class is a bit scary, but I still believe it's a good ingredient for Calculate: it allows us to do symbolic evaluation of functions. This brings us the features of plotting graphs and using not-completely-resolved functions in later calculations. This would be quite a bit harder otherwise (not to mention that the previous parser was a hideous piece of code). Understood, well I think I do, just glad the AstParser scariness has a good reason for being there :) Anyway, I have attached a patch to fix the bug you mentioned. If you can have a look whether you agree I'll push it asap. Tested here, works great and also fixes the bug in the sci/exp button as well :)) I'm cursing myself a little as I had been playing around with a helper function in functions.py without luck, but hadn't considered what was really needed was a helper class. I'm trying to get back to writing some sugar activity code in the coming time, so I hope to get a few more Calculate bugs out of the way as well. That would be fab! One thing to note is that v31 in git all this time with the new toolbar support has never been officially released. My plan was to try and hit a few low hanging bugs in trac (failed that one) and get a release out the door, perhaps just in time to have it added to the next Soas release (feature freeze is next week and I'd need to convince someone to package it for fedora, at least there are no binary blobs to worry about). Does that fit in with your schedule? I could do the release bit, ASLO, update wikis, upload the source, if you are pushed for time this week? Regards, --Gary Cheers, Reinier On Mon, Jul 19, 2010 at 6:11 AM, Gary C Martin garycmar...@googlemail.com wrote: Hi Reinier, Help! :) I've burnt a week of misc free time trying to untangle this deg/rad bug, but it's a nightmare for me and I seem to have got nowhere. Any hints much appreciated: http://bugs.sugarlabs.org/ticket/ After much poking I discovered you implemented some type of custom plugin system (in the rather scary AstParser class) for the 'functions.py' and 'constants.py' code, which seems to do some magic import tricks that seem to prevent obvious access to accessing the 'functions.py' variable _angle_scaling from the outside, and/or blocking the 'functions.py' plugin code from accessing that value from the outside. The toolbar code changes the angle_scaling property in the MathLib class, but that value is never used by the actual imported AstParser function calls, and I've found no way to access the actuall deg/rad scaling value to change it from the outside. Thanks for any hints. Regards, --Gary -- Reinier Heeres Tel: +31 6 10852639 fix_angle_scaling.diff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Some activities to fix (or check) for F11-0.88
Hello Jorge, I know activities are low-priority now, but when you have time it would be good to try to fix these activities with known problems: com.laptop.Ruler, The ruler is scaled incorrectly (since Sugar 0.84) com.socialtext.SocialCalcActivity, This one has startup problems (since Sugar 0.84) due to a hard-coded timeout to synchronize the Python part with the JavaScript part. There are also bugs in charts. OLPC dropped it from their builds. org.worldwideworkshop.PollBuilder, org.worldwideworkshop.olpc.JigsawPuzzle, org.worldwideworkshop.olpc.SliderPuzzle, These are simply untested on 0.88. They might work out of the box. Do we want PollBuilder in the default installation of F11-0.88? org.laptop.AcousticMeasure (aka Distance) It is said to work badly on the XO-1.5. But did it ever work well? While we cannot expect the method used by Distance to yield very accurate results, but in the past I've always seen pseudo-random numbers even with the X-1. tv.alterna.Clock This one does not make much sense until we set the time from ntp (no need to test it) -- // 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] Some activities to fix (or check) for F11-0.88
On Tue, Jul 20, 2010 at 11:24 PM, Bernie Innocenti ber...@codewiz.org wrote: Hello Jorge, I know activities are low-priority now, but when you have time it would be good to try to fix these activities with known problems: com.laptop.Ruler, The ruler is scaled incorrectly (since Sugar 0.84) Is there a ticket for this? I had not seen this problem. (It has been suggested that the rule fill the screen, but that is not a scaling issue. Also, we have no reliable way of determining display resolution on non-XO hardware, so there is a spinner to let the user set DPI in such cases. com.socialtext.SocialCalcActivity, This one has startup problems (since Sugar 0.84) due to a hard-coded timeout to synchronize the Python part with the JavaScript part. There are also bugs in charts. OLPC dropped it from their builds. org.worldwideworkshop.PollBuilder, org.worldwideworkshop.olpc.JigsawPuzzle, org.worldwideworkshop.olpc.SliderPuzzle, These are simply untested on 0.88. They might work out of the box. Do we want PollBuilder in the default installation of F11-0.88? org.laptop.AcousticMeasure (aka Distance) It is said to work badly on the XO-1.5. But did it ever work well? While we cannot expect the method used by Distance to yield very accurate results, but in the past I've always seen pseudo-random numbers even with the X-1. tv.alterna.Clock This one does not make much sense until we set the time from ntp (no need to test it) -- // 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 -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Some activities to fix (or check) for F11-0.88
On 21 Jul 2010, at 04:24, Bernie Innocenti ber...@codewiz.org wrote: Hello Jorge, I know activities are low-priority now, but when you have time it would be good to try to fix these activities with known problems: com.laptop.Ruler, The ruler is scaled incorrectly (since Sugar 0.84) com.socialtext.SocialCalcActivity, This one has startup problems (since Sugar 0.84) due to a hard-coded timeout to synchronize the Python part with the JavaScript part. There are also bugs in charts. OLPC dropped it from their builds. org.worldwideworkshop.PollBuilder, org.worldwideworkshop.olpc.JigsawPuzzle, org.worldwideworkshop.olpc.SliderPuzzle, These are simply untested on 0.88. They might work out of the box. Do we want PollBuilder in the default installation of F11-0.88? org.laptop.AcousticMeasure (aka Distance) It is said to work badly on the XO-1.5. But did it ever work well? While we cannot expect the method used by Distance to yield very accurate results, but in the past I've always seen pseudo-random numbers even with the X-1. tv.alterna.Clock This one does not make much sense until we set the time from ntp (no need to test it) FWIW: this is an activity I picked up maintenance of from Pierre Métras, I can confirm it fails under Mirabelle, but not sure if it is F13 or Sugar 0.88 related yet. Need to investigate (it's not picking up widget.window, perhaps some 0.88 canvas change in Sugar I seem to remember being discussed). Regards, --Gary -- // 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 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Help needed adding microformat support to the activity updater
El Sat, 17-07-2010 a las 10:20 -0700, akashg1611 escribió:
--- /dev/null
+++ b/extensions/cpsection/updater/backends/microformat.py
@@ -0,0 +1,124 @@
+#!/usr/bin/python
+# Copyright (C) 2009, Sugar Labs
2010. Also, you might prefer to assign the Copyright to yourself or
Activity Central.
+#
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+
+'''Sugar Microformat Parser.
+
+This module implements the microformat parser for the
+activity updater.
+'''
+from HTMLParser import HTMLParser
+from urllib2 import urlopen, URLError
+
+dic = {}
Consider a more descriptive variable name: what is this dictionary for?
+_fetcher = None
+
+
+class _Microformat_UpdateFetcher(object):
+
+def __init__(self, bundle, completion_cb):
+
+
_MicroformatParser('http://wiki.paraguayeduca.org/index.php/Actividades_y_contenidos')
This will block the Sugar shell process until the HTTP request is
completed. Consider an asynchronous approach like the aslo backend does.
+def _get_updated_info(self):
+try:
+version, link = dic[self._bundle.get_bundle_id()]
+except KeyError:
+print No bundle with this id
+ return
+else:
+size = 0
+global _fetcher
+_fetcher = None
+self._completion_cb(self._bundle, version, link, size, None)
Throwing away the fetcher on each invocation is going to cause a new
HTTP request to be issued for each bundle, rather than reusing the
information after the first time.
You might need to rework or extend the current model-backend interface
to provide a way to tell you when to start a new check. A common OOP
pattern is to employ RAII:
from backends import microformat
updater = microformat.new_updater()
for bundle in bundles:
updater.fetch_info(bundle, completion_cb)
# the updater will stay alive until there are references to it
updater = None
The new_updater() function would return an instance of a
MicroformatUpdater object that will cache the update information after
the first invocation.
However, this improved interface still wouldn't solve the issue of how
to communicate information about bundles that aren't currently
installed.
So, probably, we need to push the loop inside the backend:
from backends import microformat
updater = microformat.new_updater()
updater.fetch_update_info(bundles, completion_cb)
from backends import aslo
-
+from backends import microformat
class UpdateModel(gobject.GObject):
__gtype_name__ = 'SugarUpdateModel'
@@ -76,7 +76,7 @@ class UpdateModel(gobject.GObject):
self.emit('progress', UpdateModel.ACTION_CHECKING, bundle.get_name(),
current, total)
-aslo.fetch_update_info(bundle, self.__check_completed_cb)
+microformat.fetch_info(bundle, self.__check_completed_cb)
Either we make this configurable, or we stop importing the aslo backend.
Once the ASLO microformat support is completed, I'd be in favor of
killing the aslo backend altogether. What do the Sugar maintainers
think?
--
// 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] [ANNOUNCE] sugar-toolkit has been branched
El Tue, 06-07-2010 a las 09:27 +0200, Simon Schampijer escribió: sugar-toolkit has now a sucrose-0.88 [1] branch for backporting fixes intended for future releases in the 0.88.x series. Who is going to maintain the 0.88 branch? If nobody else is available, I could take care of the 0.88 branches of all repositories until October (at least). -- // 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
