Re: [Sugar-devel] [PATCH sugar 1/7] SugarEventIcon: Add a hippo-free implementation of the CanvasIcon

2012-08-07 Thread Simon Schampijer 

On 08/06/2012 03:53 PM, Benjamin Berg wrote:

On Mon, 2012-08-06 at 15:49 +0200, Sascha Silbe wrote:

Benjamin Berg  writes:

+# HACK to supress the grey background around the icon
+# won't be needed in GTK3
+self.modify_bg(gtk.STATE_NORMAL, style.COLOR_WHITE.get_gdk_color())


Not really too bad, but I am pretty sure that
gtk.EventBox.set_visible_window(False) should work fine here.


Doesn't look that way to me:


Oh, thanks for the screenshot. That is kinda obvious. One needs to add
allocation.x and allocation.y to the coordinates if you don't have a
visible window.

So:

+def do_expose_event(self, event):
+surface = self._buffer.get_surface()
+if surface:
+allocation = self.get_allocation()
+
+x = (allocation.width - surface.get_width()) / 2
+y = (allocation.height - surface.get_height()) / 2
+
+cr = self.window.cairo_create()
+cr.set_source_surface(surface, x, y)
+if self._alpha == 1.0:
+cr.paint()
+else:
+cr.paint_with_alpha(self._alpha)


Also change the x/y calculation to add allocation.x and allocation.y
respectively. Then things should work fine.

Benjamin



diff --git a/src/jarabe/view/eventicon.py b/src/jarabe/view/eventicon.py
index 4166798..0432c34 100644
--- a/src/jarabe/view/eventicon.py
+++ b/src/jarabe/view/eventicon.py
@@ -94,16 +94,13 @@ class EventIcon(gtk.EventBox):
 self._alpha = 1.0

 gtk.EventBox.__init__(self)
+self.set_visible_window(False)
 for key, value in kwargs.iteritems():
 self.set_property(key, value)

 self._palette_invoker = CursorInvoker()
 self._palette_invoker.attach(self)

-# HACK to supress the grey background around the icon
-# won't be needed in GTK3
-self.modify_bg(gtk.STATE_NORMAL, style.COLOR_WHITE.get_gdk_color())
-
 self.connect('destroy', self.__destroy_cb)

 def do_expose_event(self, event):
@@ -111,8 +108,8 @@ class EventIcon(gtk.EventBox):
 if surface:
 allocation = self.get_allocation()

-x = (allocation.width - surface.get_width()) / 2
-y = (allocation.height - surface.get_height()) / 2
+x = allocation.x + (allocation.width - surface.get_width()) / 2
+y = allocation.y + (allocation.height - 
surface.get_height()) / 2


 cr = self.window.cairo_create()
 cr.set_source_surface(surface, x, y)


This will work now. As Benjamin stated the one needs to add 
allocation.x/y in expose, the current code works fine if the event box 
has a visible window, because then allocation.x and allocation.y are 0 
by definition. Attached is the updated patch as well.


Regards,
   Simon



>From f1e4ccbee809d099f1af1d70694d32d2790033e9 Mon Sep 17 00:00:00 2001
From: Simon Schampijer 
Date: Wed, 25 Jul 2012 00:23:46 +0200
Subject: [PATCH sugar 1/5] SugarEventIcon: Add a hippo-free implementation of
 the CanvasIcon

The icon consists of an GtkEventBox and an IconBuffer. The
GtkEventBox is a subclass of GtkBin which has its own window
and therefor is used to catch events for our IconBuffer
which does not have it's own window.

The EventIcon uses the CursorInvoker that has been introduced in
the GTK+ 3 toolkit to invoke a palette the same way as the
CanvasIcon did.

We keep the same API as with the CanvasIcon, only the 'size'
property is changed to be called 'pixel_size' in order to
make clearer which values it expects to be passed. We don't
expect a GtkIconSize to be passed here.

Another option would have been to put a SugarIcon inside a
a GtkEventBox and make the properties available through an
icon property but the API would have not been as nice and
logically it seems to make more sense to have the IconBuffer
being the base for both the SugarIcon and the SugarEventIcon.

This patch is highly based on the work from Walter Bender,
Daniel Drake and Raul Gutierrez Segales.

Signed-off-by: Simon Schampijer 
[moved from sugar-toolkit to sugar]
Signed-off-by: Sascha Silbe 

[1] http://developer.gnome.org/gtk/2.24/GtkEventBox.html
[2] http://developer.gnome.org/gtk/2.24/gtk-Themeable-Stock-Images.html#GtkIconSize
---
 src/jarabe/view/Makefile.am  |   1 +
 src/jarabe/view/eventicon.py | 274 +++
 2 files changed, 275 insertions(+)
 create mode 100644 src/jarabe/view/eventicon.py

diff --git a/src/jarabe/view/Makefile.am b/src/jarabe/view/Makefile.am
index 630f184..31ccfa4 100644
--- a/src/jarabe/view/Makefile.am
+++ b/src/jarabe/view/Makefile.am
@@ -4,6 +4,7 @@ sugar_PYTHON =\
 	buddyicon.py			\
 	buddymenu.py			\
 	customizebundle.py		\
+	eventicon.py			\
 	keyhandler.py			\
 	launcher.py			\
 	palettes.py			\
diff --git a/src/jarabe/view/eventicon.py b/src/jarabe/view/eventicon.py
new file mode 100644
index 000..0432c34
--- /dev/null
+++ b/src/jarabe/view/eventicon.py
@@ -0,0 +1,274 @@
+# Co

Re: [Sugar-devel] [PATCH sugar-toolkit-gtk3] props.accelerator available at ToggleToolButton SL#3774

2012-08-07 Thread Simon Schampijer 

On 08/06/2012 06:47 PM, Manuel Kaufmann wrote:

Hello,

On Wed, Aug 1, 2012 at 11:10 PM, Daniel Francis  wrote:

Signed-off-by: Daniel Francis 

---
  src/sugar3/graphics/toggletoolbutton.py | 39 +


The patchs look great. Good work, Daniel!

I tested both and they are working properly. I made a comment on the ticket[1].

Tested-by: Manuel Kaufmann 


[1] http://bugs.sugarlabs.org/ticket/3774




Pushed. http://bugs.sugarlabs.org/ticket/3774#comment:5

Regards,
   Simon


___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar-artwork] Add help icon for the toolbars - SL #3746

2012-08-07 Thread Simon Schampijer 

Thanks, pushed.

On 07/28/2012 01:11 PM, Manuel Quiñones wrote:

So activities have a standard help icon for their toolbar moving
forward.

Design-by: Gary C. Martin 
Signed-off-by: Manuel Quiñones 
---
  icons/scalable/actions/toolbar-help.svg |   32 +++
  1 file changed, 32 insertions(+)
  create mode 100644 icons/scalable/actions/toolbar-help.svg

diff --git a/icons/scalable/actions/toolbar-help.svg 
b/icons/scalable/actions/toolbar-help.svg
new file mode 100644
index 000..36f763c
--- /dev/null
+++ b/icons/scalable/actions/toolbar-help.svg
@@ -0,0 +1,32 @@
+http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd' [
+   
+   
+]>
+
+http://www.w3.org/2000/svg";
+xmlns:xlink="http://www.w3.org/1999/xlink";>
+
+  
+
+  
+



___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar-build] Support Fedora 16

2012-08-07 Thread Simon Schampijer 

On 07/12/2012 10:48 AM, Daniel Narvaez wrote:

Hi Manuel,

thanks for your patch.

I prefer to not support old distributions in sugar-build, to reduce
the maintenance cost. It appears to just work right now but that
might change during the development cycle or when we make changes to
sugar-build itself (we will have to add master gtk soon for the shell
port, for example) and ensuring everything works as expected on many
distributions is very time consuming. I'd also have to setup two other
buildbot slaves for F16 and those are also quite expensive to
maintain. And when things will start breaking we would probably have
to add special cases to check-system, build certain stuff only on
certain distro, which will increase complexity and bring us back to
the sugar-jhbuild situation...

So, all in all, I prefer to be absolutely certain stuff works out of
the box for everyone on the latest distribution, at a reasonable
maintenance cost, rather than trying to support everything and failing
to do so reliably. I understand it might be annoying for some users to
have to upgrade to F17, but I think it's reasonable to accept that
limitation in exchange for reliability.

If in the future sugar development stops depending on the very cutting
edge of the GNOME stuff I think it might be possible to reasses this
decision, but unfortunately right now I don't see it coming very soon.


I absolutely agree here. Everything comes at a cost. If you want to do 
edge development you have to be on the edge (hence F17 upwards). I would 
not loose time on supporting F16.


Regards,
   Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar-toolkit v2] presence: use RoomConfig1 to configure channel properties (#3629)

2012-08-07 Thread Simon Schampijer 

On 07/04/2012 12:21 AM, Daniel Drake wrote:

This code was still using regular Telepathy properties to
set important configuration such as Anonymous=False.

However, as of Telepathy specification 0.24.0, these properties have
gone away.

 http://telepathy.freedesktop.org/spec/Channel_Type_Text.html
 Changed in 0.24.0. This interface used to have a bunch of clunky
 Telepathy.Properties. They have been removed in favour of D-Bus
 properties on the Room2, Subject2 and RoomConfig1 interfaces.

Switch to using RoomConfig1 (where available) to set this
configuration. The invite-restricted flag is no longer available and
actually seems to have been removed a long while back.

Fixes sharing of activities over gabble on new platforms such
as Fedora 17.

Signed-off-by: Daniel Drake 


Thanks Daniel for that one, I cherry-picked it to the sucrose-0.96 
branch as well.


Simon

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar-toolkit-gtk3 (shell-port)] The icon consists of an GtkEventBox and an IconBuffer. The GtkEventBox is a subclass of GtkBin which has its own window and therefor is used t

2012-08-07 Thread Simon Schampijer 

On 07/03/2012 08:05 PM, Benjamin Berg wrote:

On Fri, 2012-06-22 at 16:08 +0200, Simon Schampijer wrote:

The EventIcon does emit the 'activated' signal when clicked
and uses the CursorInvoker to invoke a palette the same
way as the CanvasIcon did.

We keep the same API as with the CanvasIcon, only the 'size'
property is changed to be called 'pixel_size' in order to
make clearer which values it expects to be passed. We don't
expect a GtkIconSize to be passed here.

Another option would have been to put a SugarIcon inside a
a GtkEventBox and make the properties available through an
icon property but the API would have not been as nice and
logically it seems to make more sense to have the IconBuffer
being the base for both the SugarIcon and the SugarEventIcon.

This patch has ben developed based on the one that is
proposed for the toolkit-gtk2.


The patch looks good.


Signed-off-by: Simon Schampijer 

Reviewd-by: Benjamin Berg 





Thanks for the review, pushed that one after polishing the description.

http://git.sugarlabs.org/sugar-toolkit-gtk3/sugar-toolkit-gtk3/commit/6438c89dea729fbca08e33f6b0175e85b1c72795

Note, that in GTK+ 3 we do not need to take allocation.x/y and in the 
drawing into account as we had to do with the GTK+ 2 version.


Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH sugar v5 1/3] Properly wrap labels in the Network Control Panel (GTK#318276 workaround)

2012-08-07 Thread Sascha Silbe 
When line wrapping is enabled (label.set_line_wrap(True)), GTK restricts
labels to an arbitrary size, rather than utilising the entire allocated space.
This has been known upstream since 2005 (GTK#318276 [1]), but remains unfixed
to date.

Work around this bug by using a size-allocate signal handler that sets the
requested size of the label to the actual allocation.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=318276

Signed-off-by: Sascha Silbe 
---
v5->v4: no changes
v4: introduced this patch into the series

 extensions/cpsection/network/view.py |   42 +-
 1 file changed, 31 insertions(+), 11 deletions(-)

diff --git a/extensions/cpsection/network/view.py 
b/extensions/cpsection/network/view.py
index 381dcb6..6298f5c 100644
--- a/extensions/cpsection/network/view.py
+++ b/extensions/cpsection/network/view.py
@@ -31,6 +31,28 @@ TITLE = _('Network')
 _APPLY_TIMEOUT = 3000
 
 
+class WrappedLabel(gtk.Label):
+"""Variant of gtk.Label that automatically line-wraps the text as needed.
+
+In theory, stock gtk.Label can already do this, but in practice a
+long-standing bug in GTK prevents it from working as expected.
+This class includes a workaround for that bug.
+
+Cave-at: WrappedLabel.set_alignment() will stop working.
+"""
+
+def __init__(self, string=None):
+gtk.Label.__init__(self, str=string)
+self.set_line_wrap(True)
+self.connect('size-allocate', self.__size_allocate_cb)
+
+def __size_allocate_cb(self, widget, rect):
+"""Propagate parent size allocation to gtk.Label"""
+# This is a workaround for GTK bug #318276
+# https://bugzilla.gnome.org/show_bug.cgi?id=318276
+widget.set_size_request(rect.width, -1)
+
+
 class Network(SectionView):
 def __init__(self, model, alerts):
 SectionView.__init__(self)
@@ -66,10 +88,9 @@ class Network(SectionView):
 box_wireless.set_border_width(style.DEFAULT_SPACING * 2)
 box_wireless.set_spacing(style.DEFAULT_SPACING)
 
-radio_info = gtk.Label(_('Turn off the wireless radio to save battery'
- ' life'))
+radio_info = WrappedLabel(_('Turn off the wireless radio to save'
+' battery life'))
 radio_info.set_alignment(0, 0)
-radio_info.set_line_wrap(True)
 radio_info.show()
 box_wireless.pack_start(radio_info, expand=False)
 
@@ -95,10 +116,9 @@ class Network(SectionView):
 self._radio_alert.props.msg = self.restart_msg
 self._radio_alert.show()
 
-history_info = gtk.Label(_('Discard network history if you have'
-   ' trouble connecting to the network'))
+history_info = WrappedLabel(_('Discard network history if you have'
+  ' trouble connecting to the network'))
 history_info.set_alignment(0, 0)
-history_info.set_line_wrap(True)
 history_info.show()
 box_wireless.pack_start(history_info, expand=False)
 
@@ -127,12 +147,12 @@ class Network(SectionView):
 box_mesh.set_border_width(style.DEFAULT_SPACING * 2)
 box_mesh.set_spacing(style.DEFAULT_SPACING)
 
-server_info = gtk.Label(_("The server is the equivalent of what"
-  " room you are in; people on the same server"
-  " will be able to see each other, even when"
-  " they aren't on the same network."))
+server_info = WrappedLabel(_("The server is the equivalent of what"
+ " room you are in; people on the same"
+ " server will be able to see each other,"
+ " even when they aren't on the same "
+ " network."))
 server_info.set_alignment(0, 0)
-server_info.set_line_wrap(True)
 box_mesh.pack_start(server_info, expand=False)
 server_info.show()
 
-- 
1.7.10.4

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH sugar v5 3/3] sugar-session: export manual Gnome proxy settings as $http_proxy

2012-08-07 Thread Sascha Silbe 
Some applications and tools and even some parts of Sugar will use the
http_proxy and no_proxy environment variables [1] if set, but don't use the
Gnome (GConf) proxy settings.

After changing the GConf proxy settings, Sugar needs to be restarted for these
environment variables to be updated. The Network Control Panel will now show
a restart alert that informs the user about the need to restart and offer to
do the restart immediately (other options are undo and restart later).

[1] https://www.gnu.org/software/wget/manual/html_node/Proxies.html

Based on a patch by Jerry Vonau .

Signed-off-by: Sascha Silbe 
---
v4->v5: no changes
original version->v4: Add support for no_proxy, some minor changes

 bin/sugar-session|   29 +
 extensions/cpsection/network/view.py |   34 +-
 2 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/bin/sugar-session b/bin/sugar-session
index e9c8d50..a2c4204 100755
--- a/bin/sugar-session
+++ b/bin/sugar-session
@@ -208,6 +208,34 @@ def set_fonts():
 settings = gtk.settings_get_default()
 settings.set_property("gtk-font-name", "%s %f" % (face, size))
 
+
+def export_proxy_settings():
+"""Export manual proxy settings from GConf as environment variables
+
+Some applications and tools and even some parts of Sugar will use
+the http_proxy environment variable if set, but don't use the Gnome
+(GConf) proxy settings.
+"""
+client = gconf.client_get_default()
+if client.get_string('/system/proxy/mode') != 'manual':
+return
+
+http_host = client.get_string('/system/http_proxy/host')
+http_port = client.get_int('/system/http_proxy/port')
+use_auth = client.get_bool('/system/http_proxy/use_authentication')
+if use_auth:
+user = client.get_string('/system/http_proxy/authentication_user')
+pw = client.get_string('/system/http_proxy/authentication_password')
+http_proxy = 'http://%s:%s@%s:%d/' % (user, pw, http_host, http_port)
+else:
+http_proxy = 'http://%s:%d/' % (http_host, http_port)
+
+os.environ['http_proxy'] = http_proxy
+ignore_hosts = client.get_list('/system/http_proxy/ignore_hosts',
+   gconf.VALUE_STRING)
+os.environ['no_proxy'] = ','.join(ignore_hosts)
+
+
 def main():
 try:
 from sugar import env
@@ -243,6 +271,7 @@ def main():
 if timezone is not None and timezone:
 os.environ['TZ'] = timezone
 
+export_proxy_settings()
 set_fonts()
 
 # this must be added early, so that it executes and unfreezes the screen
diff --git a/extensions/cpsection/network/view.py 
b/extensions/cpsection/network/view.py
index e3dd48d..5c46ae3 100644
--- a/extensions/cpsection/network/view.py
+++ b/extensions/cpsection/network/view.py
@@ -140,6 +140,10 @@ class GConfMixin(object):
 client = gconf.client_get_default()
 return _gconf_value_to_python(client.get(self._gconf_key))
 
+@property
+def changed(self):
+return self._undo_value != self.get_value_for_gconf()
+
 
 class GConfEntry(gtk.Entry, GConfMixin):
 """Text entry backed by GConf
@@ -241,6 +245,10 @@ class GConfHostListSettingBox(GConfStringSettingBox):
 """Revert to original value if modified"""
 self.hosts_entry.undo()
 
+@property
+def changed(self):
+return self.hosts_entry.changed
+
 
 class GConfHostPortSettingBox(SettingBox):
 """A configuration line for a combined host name and port GConf setting"""
@@ -263,6 +271,10 @@ class GConfHostPortSettingBox(SettingBox):
 self.host_name_entry.undo()
 self.port_spin_button.undo()
 
+@property
+def changed(self):
+return self.host_name_entry.changed or self.port_spin_button.changed
+
 
 class ExclusiveOptionSetsBox(gtk.VBox):
 """
@@ -695,7 +707,6 @@ class Network(SectionView):
 
 self._jabber_valid = True
 self._radio_valid = True
-self.needs_restart = False
 self._radio_change_handler = self._button.connect( \
 'toggled', self.__radio_toggled_cb)
 self._jabber_change_handler = self._entry.connect( \
@@ -713,6 +724,27 @@ class Network(SectionView):
 for setting in self._undo_objects:
 setting.undo()
 
+# pylint: disable=E0202
+@property
+def needs_restart(self):
+# Some parts of Sugar as well as many non-Gnome applications
+# use environment variables rather than gconf for proxy
+# settings, so we need to restart for the changes to take
+# _full_ effect.
+for setting in self._undo_objects:
+if setting.changed:
+return True
+
+return False
+
+# pylint: disable=E0102,E1101
+@needs_restart.setter
+def needs_restart(self, value):
+# needs_restart is a property (i.e. gets calculated) in this Control
+# Panel, but SectionView.__init__() wants to ini

[Sugar-devel] [PATCH sugar v5 0/3] Improve proxy support

2012-08-07 Thread Sascha Silbe 
This series includes a completely reworked version of the Proxy
Control Panel (now Proxy section in the Network Control Panel) patch.
The new version has been based on Simon Schampijers mock-up [1],
reflecting UI changes requested by both Simon and Gary Martin [2].

v5 of the series only has a minor change over v4 that doesn't affect
the behaviour (including UI layout).

Sascha Silbe (3):
  Properly wrap labels in the Network Control Panel (GTK#318276
workaround)
  Add proxy configuration support to Network Control Panel
  sugar-session: export manual Gnome proxy settings as $http_proxy

 bin/sugar-session|   29 ++
 extensions/cpsection/network/view.py |  589 +-
 2 files changed, 601 insertions(+), 17 deletions(-)

[1] message-id:4f2717e2.7010...@schampijer.de
http://lists.sugarlabs.org/archive/sugar-devel/2012-January/035498.html
[2] message-id:be4dc5a8-4b0a-40db-8091-049aaad31...@gmail.com
http://lists.sugarlabs.org/archive/sugar-devel/2012-January/035483.html

-- 
1.7.10.4

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [PATCH sugar v5 2/3] Add proxy configuration support to Network Control Panel

2012-08-07 Thread Sascha Silbe 
Both individual users and deployments need to be able to set a proxy for
Sugar and activities to use. While we'd like the system to work that all
out automatically (e.g. using WPAD [1]), this often isn't possible. Common
reasons include legacy ("inherited") setups and network uplinks simply being
out of control of the user respectively deployment.

The existing Network Control Panel is enhanced by adding a new section for the
proxy settings. For consistency between Sugar and Gnome, the basic layout of
the Gnome 3 proxy settings has been mirrored: A combo box allows the user to
select how the proxy setting should be determined (None=direct connection,
Automatic=WPAD or PAC, Manual=enter host names and ports for each protocol).
Based on which method was selected, additional configuration options are
presented to the user.

The settings are stored via gconf, using the same keys as Gnome 2 [2].

This implements the Proxy Settings Feature [3].

[1] https://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol
[2] http://people.gnome.org/~bmsmith/gconf-docs/C/gnome-vfs.html
[3] https://wiki.sugarlabs.org/go/Features/Proxy_Settings

Signed-off-by: Sascha Silbe 
---
v4->v5: dropped set_alignment() calls on WrappedLabel instances, they
don't have any effect and would only cause confusion.
v3->v4: completely reworked to turn it into a new section in the
Network Control Panel and mirroring Gnome 3 design, rather
than a separate Control Panel mirroring Gnome 2 design.

 extensions/cpsection/network/view.py |  513 +-
 1 file changed, 508 insertions(+), 5 deletions(-)

diff --git a/extensions/cpsection/network/view.py 
b/extensions/cpsection/network/view.py
index 6298f5c..e3dd48d 100644
--- a/extensions/cpsection/network/view.py
+++ b/extensions/cpsection/network/view.py
@@ -13,10 +13,13 @@
 # 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 logging
 
-import gtk
+import gconf
 import gobject
-from gettext import gettext as _
+import gtk
+import pango
 
 from sugar.graphics import style
 
@@ -53,6 +56,379 @@ class WrappedLabel(gtk.Label):
 widget.set_size_request(rect.width, -1)
 
 
+class GConfMixin(object):
+"""Mix-in class for GTK widgets backed by GConf
+
+It is the callers responsibility to call GConfClient.add_dir() for the
+GConf directory containing the key.
+"""
+
+def __init__(self, gconf_key, widget=None, signal='changed'):
+self._timeout_id = None
+self._gconf_key = gconf_key
+client = gconf.client_get_default()
+self._notify_id = client.notify_add(gconf_key, self.__gconf_notify_cb)
+initial_value = self._get_gconf_value()
+self._undo_value = initial_value
+self.set_value_from_gconf(initial_value)
+widget = widget or self
+widget.connect(signal, self.__changed_cb)
+
+def undo(self):
+"""Revert to original value if modified"""
+if not self.changed:
+return
+
+logging.debug('Reverting %r to %r', self._gconf_key, self._undo_value)
+self._set_gconf_value(self._undo_value)
+
+def get_value_for_gconf(self):
+"""
+Return the current value of the widget in a format suitable for GConf
+
+MUST be implemented by subclasses.
+"""
+raise NotImplementedError()
+
+def set_value_from_gconf(self, value):
+"""
+Set the current value of the widget based on a value from GConf
+
+MUST be implemented by subclasses.
+"""
+raise NotImplementedError()
+
+def __changed_cb(self, widget):
+if self._timeout_id is not None:
+gobject.source_remove(self._timeout_id)
+
+self._timeout_id = gobject.timeout_add(_APPLY_TIMEOUT, self._commit,
+   widget)
+
+def __gconf_notify_cb(self, client, transaction_id_, entry, user_data_):
+new_value = _gconf_value_to_python(entry.value)
+self.set_value_from_gconf(new_value)
+
+def _commit(self, widget):
+new_value = self.get_value_for_gconf()
+logging.debug('Setting %r to %r', self._gconf_key, new_value)
+
+widget.handler_block_by_func(self.__changed_cb)
+try:
+self._set_gconf_value(new_value)
+finally:
+widget.handler_unblock_by_func(self.__changed_cb)
+
+def _set_gconf_value(self, new_value):
+client = gconf.client_get_default()
+gconf_type = client.get(self._gconf_key).type
+if gconf_type == gconf.VALUE_STRING:
+client.set_string(self._gconf_key, new_value)
+elif gconf_type == gconf.VALUE_INT:
+client.set_int(self._gconf_key, new_value)
+elif gconf_type == gconf.VALUE_FLOAT:
+clie

[Sugar-devel] Proposal: Adding Manuel Quiñones as a Sugar shell maintainer

2012-08-07 Thread Simon Schampijer 

Hi,

Something I wanted to propose in todays developer meeting (but as it did 
not happen), I send it here for an async proposal.


We are short on maintainers and we have to grow new members that helps 
us share the load. The patch list is long and help in that regard will 
be appreciated that especially small patches do not take so long to get in.


Lately Manuel Quiñones have been stepping up as a Sugar module 
maintainer. He is already maintaining sugar-artwork and 
sugar-toolkit-gtk3 [1]. He has been showing great talent with porting 
the Browse activity to WebkitGtk [2] and he has been working on porting 
the Sugar theme and the sugar-toolkit to GTK+ 3.


We are currently working on the shell port to GTK+ 3 and introspection 
and Manuel has been advancing already quite a lot [3]. As all of those 
Sugar sub-modules are interlinked I think it makes absolute sense to add 
him as a maintainer to the Sugar shell as well.


To make sure: the general work-flow should not change, patches have to 
be sent to the mailing list for review. For non-trivial reviews a 
maintainer should have at least one review, preferred a review and 
acknowledgment from another maintainer. It is good practice to leave a 
patch for a few days so everyone maintainer can at least have a high 
level look if he disagrees with an approach.


I hope we can address the issues listed in that way,
   Simon

[1] http://wiki.sugarlabs.org/go/Development_Team/Release/Modules
[2] http://git.sugarlabs.org/browse
[3] http://git.sugarlabs.org/~manuq/sugar/manuqs-erikos-shell-port
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Proposal: Adding Manuel Quiñones as a Sugar shell maintainer

2012-08-07 Thread Chris Leonard 
On Tue, Aug 7, 2012 at 10:51 AM, Simon Schampijer  wrote:
> Hi,
>
> Something I wanted to propose in todays developer meeting (but as it did not
> happen), I send it here for an async proposal.
>
> We are short on maintainers and we have to grow new members that helps us
> share the load. The patch list is long and help in that regard will be
> appreciated that especially small patches do not take so long to get in.
>
> Lately Manuel Quiñones have been stepping up as a Sugar module maintainer.
> He is already maintaining sugar-artwork and sugar-toolkit-gtk3 [1]. He has
> been showing great talent with porting the Browse activity to WebkitGtk [2]
> and he has been working on porting the Sugar theme and the sugar-toolkit to
> GTK+ 3.
>
> We are currently working on the shell port to GTK+ 3 and introspection and
> Manuel has been advancing already quite a lot [3]. As all of those Sugar
> sub-modules are interlinked I think it makes absolute sense to add him as a
> maintainer to the Sugar shell as well.
>
> To make sure: the general work-flow should not change, patches have to be
> sent to the mailing list for review. For non-trivial reviews a maintainer
> should have at least one review, preferred a review and acknowledgment from
> another maintainer. It is good practice to leave a patch for a few days so
> everyone maintainer can at least have a high level look if he disagrees with
> an approach.
>
> I hope we can address the issues listed in that way,
>Simon


What a great tragedy, we have contributions coming in faster than we
can approve them :-)

Here are my observations:

We have been blessed by a larger than usual number of contributors to
the core modules this cycle, just to mention a few of the new
contributors and apologies to anyone I've missed, dnarvaez, danielf,
Caspar and several others that are contributing via Activity Central.
As a community we want to encourage this influx by giving rapid
feedback (and ideally acceptance) of their contributions as a fitting
form of thanks for their efforts.

This will be an unusually "disruptive" development cycle because of
the underlying technology shift from gtk2 to gtk3, the removal of
obsoleted technologies like hippo, the introduction of introspection,
etc., etc., etc.  There is a large amount of ground to cover.

This cycle will see nearly every module touched and modified in some
fundamental way, which requires lots of coordination and careful
review of contributions against "the big picture".  Given the larger
number of contributors, having a larger number of "gatekeepers"
performing that detailed review and high-level integration is
essential to achieve the ambitious goals of this development cycle.

This cycle is seeing the proposed integration of a substantial series
of carefully considered feature enhancements coming from Activity
Central's Dextrose 3.  These features were all based on end-user
requests and all have been extensively field tested in deployments
running Dextrose.  Nonetheless, reviewing and accepting them is a
substantial task and again, it is only appropriate that Activity
Central's effort in developing these and offering them back to the
upstream should be recognized by a respectful consideration of their
contributions for inclusion.

Code shuffling:  Please forgive me if I mis-characterize anyone's
proposals, but I have seen ideas floated about rearranging functional
elements for a variety of reasons, whether it is abstracting
text-to-speech to a higher level or modularizing the control panel
functions to provide great flexibility for customization, there are a
number of ideas out there on moving bits of functionality about in the
code base in ways that clearly make sense to the proposer (and
probably many others) and are certainly worthy of consideration.

All of the above is more-or-less without really breaking any new
ground, but we also have the impending need to support touch input and
on screen keyboards being driven by OLPC's technology developments,
which will likely see the integration of new bits of code with
widespread potential impact.

There is a lot of work to be done and we need trusted hands guiding
that work into our repository and releases, I am entirely in favor of
granting manuq the privilege of tackling a portion of that important
effort in collaboration with silbe and erikos (doesn't dsd own an
OLPC-specific element of this as well?  I can't recall clearly.)
Manuel has my confidence that he will "do the right thing".

Given the scope of the effort being undertaken this development cycle,
it will be a minor miracle if we do not hit a "flag day" at some
point, but I am fairly confident that if we do, it will not be out of
sloppiness or inattention by the maintainers, but because of the leaps
forward being taken.  In the immortal words of Robert Browning "Ah,
but a man's reach should exceed his grasp -- or what's a heaven for?"

On a more somber note, the testing and QA phase at the end of this
developmen

Re: [Sugar-devel] Proposal: Adding Manuel Quiñones as a Sugar shell maintainer

2012-08-07 Thread Gonzalo Odiard 
After the long reply from cjl, I only can say ...

+1 to have manuq as new maintainer in sugar module

Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [MINUTES] Development team meeting --- 07. August 2012 (15:00 UTC)

2012-08-07 Thread Simon Schampijer 
It has not been announced, but there have been people around, so we did 
a quick informal meeting:


Minutes: 
http://meeting.sugarlabs.org/sugar-meeting/meetings/2012-08-07T15:10:10.html
Log: 
http://meeting.sugarlabs.org/sugar-meeting/meetings/2012-08-07T15:10:10


Will announce again next time,
   Simon
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Idea for a New Activity in Sugar: To code and run C, C++ programs

2012-08-07 Thread Anish Mangal 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tuesday 07 August 2012 01:36 AM, Gonzalo Odiard wrote:
>
>
> On Sun, Aug 5, 2012 at 12:03 PM, Kartik Kumar mailto:kartik.p...@gmail.com>> wrote:
>
> Hi All,
>
> I was thinking of an Activity for Sugar using which children can write
programs in C and C++ and execute them.
>
>
> Why? Why, poor kids?! :)
>
> Jokes aside, I don't think is a good idea:
> * C is more difficult to learn than python.
> * In the images there are not gcc and make.
> * Compiled c code is dependent of the platform,
> and we do not have a good solution to multiplatform binaries in the
activities.
>
> Why you think, learning C can be good for kids?
>

Not saying that learning C is particularly good (or better than python),
it is still the defacto programming language taught at nearly all
schools in India atleast (in higher secondary levels)

So, while learning C might not be a good idea (when compared with
python), it would be better than not learning at all ;-)

and the point of free s/w is scratching your itch ;-)

> Create a IDE with the simplicity needed by the sugar design is a challenge.
> If you want help with a development tool to write python activities,
> check http://git.sugarlabs.org/develop
>

+1 or there are plenty of ideas around developing pippy
(http://wiki.sugarlabs.org/go/User:Quozl) as well :-)

> Gonzalo
>
>
>
> This is similar to Pippy activity but this activity will use GCC for
compilation and execution of these programs created by children.
>
> We can present them with such features:
> 1. Use pre-existing code snippets( from Journal)
> 2. Write custom code
> 3. Compilation and Execution
>
> Please provide your inputs whether this seems useful with classroom
perspective and is worth taking it further?
>
>
> Kartik Perisetla
>
>
> ___
> 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


- -- 
Anish Mangal
Sugar Labs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQIUBzAAoJEBoxUdDHDZVpcfAH/2ZgHABl3BxLq5KXCPcBgb/t
EOtA9zYe0jUsMUYiuCNokh48fc6sGUP06seCr/ROb2mSJnN+RrOxlQq196tvokWU
LHss6uonkHU8MjtPQfdcAvosKWt0cepqOXQza3VrmNd+LsV+2cAkFLFOuZXidRug
NggIi3j/DqBgUprZuCTh7YAzp94wKGBzpFDWNm3LPgaaZaROMy2A2lyNXZpeoQit
2ljfOCF4Jj6+xOpmT9ccXaHS3NikBq4aZa16WhvqV0EvaRssZrrFFTo9FIxsUNI3
haXbbGPLxFtUT9MHGU5KFlWcO8cnk/uUMLdaclYHsii5Ha+VTqMbXAS45az+4Sc=
=eaLP
-END PGP SIGNATURE-

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Proposal: Lease expiry information display in My Settings -> About My Computer

2012-08-07 Thread Daniel Drake 
On Wed, Aug 1, 2012 at 1:12 PM, Anish Mangal  wrote:
> One problem they were also trying to get around in Paraguay is that
> during vacations, the kids don't go to the schools and hence the
> leases expire. If the kids also know about this information, then they
> can easily make sure that they don't get 'locked out'

You'd hope that the project would make provisions for long-enough
leases to be supplied before the vacations.
But I can see the use for this for when that doesn't happen (which is
understandable given high workloads and so on).

Talking more with the team in Nicaragua, this functionality would be
useful for them too. Similar situations are occuring here where
laptops were activated for a certain amount of time, with the strong
expectation that internet connectivity would become available in the
schools before the activations expire (so that they can be
automatically updated/renewed). These expectations look like they
won't turn out to be true :(

So a manual activation update process will happen and the ability for
someone less-technical to be able to quickly check whether this manual
update process has completed OK would be of value (that would be the
person's only contact with activations - we aren't expecting them to
be able to solve any problems if the results are bad, other than
report up the chain).

Anyway, the use cases you describe in your mail don't seem to be
described on the feature page. Could you please extend the feature
page to go into more detail about this? I'll then add the above local
case if its of interest.


Why is the proposal to show the number of days remaining?

The Nicaraguan team have expressed a strong preference that this
should (instead, or additionally) display the expiry date. When
dealing with long duration activations, which is often the case (until
good connectivity is established), having a teacher phone up and say
"there are 137 days remaining" (and then having to calculate the day
of expiry in order to put an appropriately timed school visit on the
calendar) would be a pain.

> Since this feature is only relevant for the XO at the moment, making
> use of the bitfrost API would be acceptable to me, but I don't see a
> lot wrong here by parsing the lease.sig directly. This file is
> supposed to be automatically generated/updated in normal use cases.

Are you planning to parse sig02 (delegated leases) "by hand" as well?
What if the lease is corrupt in some way?

I can see myself objecting to any implementation of this that doesn't
reuse bitfrost. It takes care of all of the corner cases and will
avoid code duplication.

Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Proposal: Lease expiry information display in My Settings -> About My Computer

2012-08-07 Thread Anish Mangal 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Daniel,

Thanks for replying!

On Tuesday 07 August 2012 10:12 PM, Daniel Drake wrote:
> On Wed, Aug 1, 2012 at 1:12 PM, Anish Mangal
>  wrote:
>> One problem they were also trying to get around in Paraguay is
>> that during vacations, the kids don't go to the schools and hence
>> the leases expire. If the kids also know about this information,
>> then they can easily make sure that they don't get 'locked out'
> 
> You'd hope that the project would make provisions for long-enough 
> leases to be supplied before the vacations. But I can see the use
> for this for when that doesn't happen (which is understandable
> given high workloads and so on).
> 
> Talking more with the team in Nicaragua, this functionality would
> be useful for them too. Similar situations are occuring here where 
> laptops were activated for a certain amount of time, with the
> strong expectation that internet connectivity would become
> available in the schools before the activations expire (so that
> they can be automatically updated/renewed). These expectations look
> like they won't turn out to be true :(
> 
> So a manual activation update process will happen and the ability
> for someone less-technical to be able to quickly check whether this
> manual update process has completed OK would be of value (that
> would be the person's only contact with activations - we aren't
> expecting them to be able to solve any problems if the results are
> bad, other than report up the chain).
> 

This is exactly the kind of clear info that should have been in the
feature page in the first place. Sorry for not doing it earlier.

> Anyway, the use cases you describe in your mail don't seem to be 
> described on the feature page. Could you please extend the feature 
> page to go into more detail about this? I'll then add the above
> local case if its of interest.
> 

+1

> 
> Why is the proposal to show the number of days remaining?
> 

Yes, I remember discussing specifically this with Roberto (PyEduca
Technical head) back in Dec 2010, and my suggestion was exactly the
same (to display the date).

However, as per them (and I know this is not a rational explanation),
they wanted us to display "no of days remaining".

> The Nicaraguan team have expressed a strong preference that this 
> should (instead, or additionally) display the expiry date. When 
> dealing with long duration activations, which is often the case
> (until good connectivity is established), having a teacher phone up
> and say "there are 137 days remaining" (and then having to
> calculate the day of expiry in order to put an appropriately timed
> school visit on the calendar) would be a pain.
> 

I agree with this, and since I cannot seem to remember exactly why
they wanted it to display in terms of no. of days remaining, I'll ping
them or we can go with this.

>> Since this feature is only relevant for the XO at the moment,
>> making use of the bitfrost API would be acceptable to me, but I
>> don't see a lot wrong here by parsing the lease.sig directly.
>> This file is supposed to be automatically generated/updated in
>> normal use cases.
> 
> Are you planning to parse sig02 (delegated leases) "by hand" as
> well? What if the lease is corrupt in some way?
> 
> I can see myself objecting to any implementation of this that
> doesn't reuse bitfrost. It takes care of all of the corner cases
> and will avoid code duplication.
> 

Again, it seemed to solve the use case we had in Paraguay, and the
idea behind upstreaming a feature is that it goes through this process
of review. I am up for changing the code to use the bitfrost api. It
should not be complex (if it's adequately documented somewhere).

> Daniel ___ Sugar-devel
> mailing list Sugar-devel@lists.sugarlabs.org 
> http://lists.sugarlabs.org/listinfo/sugar-devel
> 


- -- 
Anish Mangal
Dextrose Project Manager
Activity Central
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQIUh6AAoJEBoxUdDHDZVpEX8H/j5oCzGUvnfIWdy1f/awAnkf
Trtsm4Me8r2D0ufxEyIZkUHugCQPUTdPqDEAlexr8ziQjy8mqNLrbvEWwwxxl4ho
XstY7RZsk9gPGVYiE1bLniIZnO5e63lIyBEkM3eNgkHrO8XTPw86lBBcTcx9XDrx
T00HW8J1UGDMo29SRcrnxnNVd6j+uArJXcaeSXhLAPb3xkaharF22AbTlWgQ+4s5
YIzvIfmEYMpqXbCCY+IPSVxzcpdRuHhueaFKchDfzRm01Wf77laACUg6+ZFkq/Ft
9ChV1LNekysQwf+yCZ9dB9HZdfIjjJ4m1WjrPhrQtqruevs9/nglTp2djqsPU00=
=QHV1
-END PGP SIGNATURE-
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [PATCH sugar] Allow to build outside the source directory

2012-08-07 Thread Simon Schampijer 

On 06/26/2012 02:26 PM, Daniel Narvaez wrote:

From: Daniel Narvaez 

This is based on a patch by
Marco Pesenti Gritti ,
with reviewer comments addressed.


Hi Daniel,

thanks for following up on this! I pushed now all of them, hope it will 
ease your work now.


Keep up the good work,
   Simon

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [DESIGN] Proposal: Lease expiry information display in My Settings -> About My Computer

2012-08-07 Thread Chris Leonard 
On Tue, Aug 7, 2012 at 12:55 PM, Anish Mangal  wrote:

>> Why is the proposal to show the number of days remaining?
>>
>
> Yes, I remember discussing specifically this with Roberto (PyEduca
> Technical head) back in Dec 2010, and my suggestion was exactly the
> same (to display the date).
>
> However, as per them (and I know this is not a rational explanation),
> they wanted us to display "no of days remaining".

Is there any limitation on displaying the information in both terms?
Days remaining and expiration date?

Just speculating about how I would mentally process such information,
my guess is that more than two weeks out, I'd look at the date, less
that two weeks out, I'd look at the days remaining.

cjl
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Idea for a New Activity in Sugar: To code and run C, C++ programs

2012-08-07 Thread Kartik Kumar 
Hi Gonzalo, I really appreciate your feedback :)

I second your view Anish.The scenario is mostly seen in India.

C, C++ are the languages that laid foundation for OOPS(C++ to be more
specific).

My personal experience is that, I started with C as my first programming
language when I was in school, then went for C++. It helps to build strong
OOPS foundation and thus facilitated me to pick up any new language at
pace. Now it helped to pick up Java and Python pretty quickly. So I believe
the OOPS concepts are easy to understand in C++ ( maybe because I picked
C++ prior to python) which helped me in my further learnings.

It would be great if we could provide something that would help children
learn in terms of programming languages with lot many examples :D

Also, We are planning to have an activity for web development. Through this
children will be able to design HTML pages, write JS in that. We can even
allow them to build entire webapp(in the long run). The unique part will be
easy to use interface where children can select, drag and drop HTML widget
on page. We can provide many more features like this.

Yes, I would definitely like to look into Develop activity and Pippy :)


Feel free to add to it !

Cheers!
Kartik Perisetla
On Aug 7, 2012 9:51 PM, "Anish Mangal"  wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tuesday 07 August 2012 01:36 AM, Gonzalo Odiard wrote:
> >
> >
> > On Sun, Aug 5, 2012 at 12:03 PM, Kartik Kumar   > wrote:
> >
> > Hi All,
> >
> > I was thinking of an Activity for Sugar using which children can write
> programs in C and C++ and execute them.
> >
> >
> > Why? Why, poor kids?! :)
> >
> > Jokes aside, I don't think is a good idea:
> > * C is more difficult to learn than python.
> > * In the images there are not gcc and make.
> > * Compiled c code is dependent of the platform,
> > and we do not have a good solution to multiplatform binaries in the
> activities.
> >
> > Why you think, learning C can be good for kids?
> >
>
> Not saying that learning C is particularly good (or better than python),
> it is still the defacto programming language taught at nearly all schools
> in India atleast (in higher secondary levels)
>
> So, while learning C might not be a good idea (when compared with python),
> it would be better than not learning at all ;-)
>
> and the point of free s/w is scratching your itch ;-)
>
> > Create a IDE with the simplicity needed by the sugar design is a
> challenge.
> > If you want help with a development tool to write python activities,
> > check http://git.sugarlabs.org/develop
> >
>
> +1 or there are plenty of ideas around developing pippy (
> http://wiki.sugarlabs.org/go/User:Quozl) as well :-)
>
> > Gonzalo
> >
> >
> >
> > This is similar to Pippy activity but this activity will use GCC for
> compilation and execution of these programs created by children.
> >
> > We can present them with such features:
> > 1. Use pre-existing code snippets( from Journal)
> > 2. Write custom code
> > 3. Compilation and Execution
> >
> > Please provide your inputs whether this seems useful with classroom
> perspective and is worth taking it further?
> >
> >
> > Kartik Perisetla
> >
> >
> > ___
> > 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
>
>
> - --
> Anish Mangal
> Sugar Labs
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJQIUBzAAoJEBoxUdDHDZVpcfAH/2ZgHABl3BxLq5KXCPcBgb/t
> EOtA9zYe0jUsMUYiuCNokh48fc6sGUP06seCr/ROb2mSJnN+RrOxlQq196tvokWU
> LHss6uonkHU8MjtPQfdcAvosKWt0cepqOXQza3VrmNd+LsV+2cAkFLFOuZXidRug
> NggIi3j/DqBgUprZuCTh7YAzp94wKGBzpFDWNm3LPgaaZaROMy2A2lyNXZpeoQit
> 2ljfOCF4Jj6+xOpmT9ccXaHS3NikBq4aZa16WhvqV0EvaRssZrrFFTo9FIxsUNI3
> haXbbGPLxFtUT9MHGU5KFlWcO8cnk/uUMLdaclYHsii5Ha+VTqMbXAS45az+4Sc=
> =eaLP
> -END PGP SIGNATURE-
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Idea for a New Activity in Sugar: To code and run C, C++ programs

2012-08-07 Thread Flavio Danesse 
Yo pienso que vale la pena hacerlo, pero pensando más en alumnos de
secundaria que de primaria, pero yo le agregaría buena documentación y
tutorials.

Sin lugar a dudas no va a ser una aplicación de uso masivo, pero
enriquecería el entorno de los chicos, yo me animo hacer experiencia en el
uso con mis alumnos.

Yo pienso que tienes que hacerla, tu aporte es bienvenido.



I think it's worth doing, but thinking more high school students of
primary, but I would add good documentation and tutorials.

Undoubtedly it will not be an application for mass use, but enrich the
environment of the children, I encourage you to experience using with my
students.

I think you have to do it, your input is welcome.




2012/8/7 Anish Mangal 

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Tuesday 07 August 2012 01:36 AM, Gonzalo Odiard wrote:
> >
> >
> > On Sun, Aug 5, 2012 at 12:03 PM, Kartik Kumar   > wrote:
> >
> > Hi All,
> >
> > I was thinking of an Activity for Sugar using which children can write
> programs in C and C++ and execute them.
> >
> >
> > Why? Why, poor kids?! :)
> >
> > Jokes aside, I don't think is a good idea:
> > * C is more difficult to learn than python.
> > * In the images there are not gcc and make.
> > * Compiled c code is dependent of the platform,
> > and we do not have a good solution to multiplatform binaries in the
> activities.
> >
> > Why you think, learning C can be good for kids?
> >
>
> Not saying that learning C is particularly good (or better than python),
> it is still the defacto programming language taught at nearly all schools
> in India atleast (in higher secondary levels)
>
> So, while learning C might not be a good idea (when compared with python),
> it would be better than not learning at all ;-)
>
> and the point of free s/w is scratching your itch ;-)
>
> > Create a IDE with the simplicity needed by the sugar design is a
> challenge.
> > If you want help with a development tool to write python activities,
> > check http://git.sugarlabs.org/develop
> >
>
> +1 or there are plenty of ideas around developing pippy (
> http://wiki.sugarlabs.org/go/User:Quozl) as well :-)
>
> > Gonzalo
> >
> >
> >
> > This is similar to Pippy activity but this activity will use GCC for
> compilation and execution of these programs created by children.
> >
> > We can present them with such features:
> > 1. Use pre-existing code snippets( from Journal)
> > 2. Write custom code
> > 3. Compilation and Execution
> >
> > Please provide your inputs whether this seems useful with classroom
> perspective and is worth taking it further?
> >
> >
> > Kartik Perisetla
> >
> >
> > ___
> > 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
>
>
> - --
> Anish Mangal
> Sugar Labs
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJQIUBzAAoJEBoxUdDHDZVpcfAH/2ZgHABl3BxLq5KXCPcBgb/t
> EOtA9zYe0jUsMUYiuCNokh48fc6sGUP06seCr/ROb2mSJnN+RrOxlQq196tvokWU
> LHss6uonkHU8MjtPQfdcAvosKWt0cepqOXQza3VrmNd+LsV+2cAkFLFOuZXidRug
> NggIi3j/DqBgUprZuCTh7YAzp94wKGBzpFDWNm3LPgaaZaROMy2A2lyNXZpeoQit
> 2ljfOCF4Jj6+xOpmT9ccXaHS3NikBq4aZa16WhvqV0EvaRssZrrFFTo9FIxsUNI3
> haXbbGPLxFtUT9MHGU5KFlWcO8cnk/uUMLdaclYHsii5Ha+VTqMbXAS45az+4Sc=
> =eaLP
> -END PGP SIGNATURE-
>
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Idea for a New Activity in Sugar: To code and run C, C++ programs

2012-08-07 Thread Bert Freudenberg 
On 07.08.2012, at 19:17, Kartik Kumar wrote:

> C, C++ are the languages that laid foundation for OOPS(C++ to be more 
> specific).

This list here is not the place for language wars, but this statement is so far 
from the truth it cannot be left uncommented. Please learn about the history of 
computing before making such broad statements.

- Bert -

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [sugar-toolkit-gtk3] Finish the port of ColorToolButton to gtk3

2012-08-07 Thread godiard 
From: Gonzalo Odiard 

This patch solves the following problems:

* API changed in the drag and drop code in Gtk
* Changes in the way to get color information from the theme.
* The internal button was not visible.

Signed-of-by: Gonzalo Odiard 
---
 src/sugar3/graphics/colorbutton.py | 30 ++
 1 file changed, 18 insertions(+), 12 deletions(-)

diff --git a/src/sugar3/graphics/colorbutton.py 
b/src/sugar3/graphics/colorbutton.py
index c21da47..3b847b3 100644
--- a/src/sugar3/graphics/colorbutton.py
+++ b/src/sugar3/graphics/colorbutton.py
@@ -64,20 +64,19 @@ class _ColorButton(Gtk.Button):
 GObject.GObject.__init__(self, **kwargs)
 
 if self._accept_drag:
-Gtk.drag_dest_set(self, Gtk.DEST_DEFAULT_MOTION |
-   Gtk.DEST_DEFAULT_HIGHLIGHT |
-   Gtk.DEST_DEFAULT_DROP,
-   [('application/x-color', 0, 0)],
-   Gdk.DragAction.COPY)
-self.drag_source_set(Gdk.EventMask.BUTTON1_MASK | 
Gdk.EventMask.BUTTON3_MASK,
- [('application/x-color', 0, 0)],
- Gdk.DragAction.COPY)
+self.drag_dest_set(Gtk.DestDefaults.MOTION |
+Gtk.DestDefaults.HIGHLIGHT | Gtk.DestDefaults.DROP,
+[Gtk.TargetEntry.new('application/x-color', 0, 0)],
+Gdk.DragAction.COPY)
+self.drag_source_set(Gdk.ModifierType.BUTTON1_MASK | \
+Gdk.ModifierType.BUTTON3_MASK,
+[Gtk.TargetEntry.new('application/x-color', 0, 0)],
+Gdk.DragAction.COPY)
 self.connect('drag_data_received', self.__drag_data_received_cb)
 self.connect('drag_data_get', self.__drag_data_get_cb)
 
 self._preview.fill_color = get_svg_color_string(self._color)
-self._preview.stroke_color = \
-get_svg_color_string(self.style.fg[Gtk.StateType.NORMAL])
+self._preview.stroke_color = self._get_fg_style_color_str()
 self.set_image(self._preview)
 
 if self._has_palette and self._has_invoker:
@@ -103,8 +102,14 @@ class _ColorButton(Gtk.Button):
 self.color = self._palette.color
 
 def do_style_set(self, previous_style):
-self._preview.stroke_color = \
-get_svg_color_string(self.style.fg[Gtk.StateType.NORMAL])
+self._preview.stroke_color = self._get_fg_style_color_str()
+
+def _get_fg_style_color_str(self):
+context = self.get_style_context()
+fg_color = context.get_color(Gtk.StateType.NORMAL)
+# the color components are stored as float values between 0.0 and 1.0
+return '#%.2X%.2X%.2X' % (fg_color.red * 255, fg_color.green * 255,
+  fg_color.blue * 255)
 
 def do_clicked(self):
 if self._palette:
@@ -438,6 +443,7 @@ class ColorToolButton(Gtk.ToolItem):
 # Replace it with a ColorButton
 color_button = _ColorButton(icon_name=icon_name, has_invoker=False)
 self.add(color_button)
+color_button.show()
 
 # The following is so that the behaviour on the toolbar is correct.
 color_button.set_relief(Gtk.ReliefStyle.NONE)
-- 
1.7.11.2

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [sugar-toolkit-gtk3] Finish the port of ColorToolButton to gtk3

2012-08-07 Thread Gonzalo Odiard 
This patch is needed by Paint port to Gtk3, but can be tested applying the
following patch to HelloWorld activity:

diff --git a/activity.py b/activity.py
index 2252983..96ee5d3 100644
--- a/activity.py
+++ b/activity.py
@@ -28,6 +28,8 @@ from sugar3.activity.widgets import TitleEntry
 from sugar3.activity.widgets import StopButton
 from sugar3.activity.widgets import ShareButton
 from sugar3.activity.widgets import DescriptionItem
+from sugar3.graphics.colorbutton import ColorToolButton

 class HelloWorldActivity(activity.Activity):
 """HelloWorldActivity class as specified in activity.info"""
@@ -58,7 +60,14 @@ class HelloWorldActivity(activity.Activity):
 share_button = ShareButton(self)
 toolbar_box.toolbar.insert(share_button, -1)
 share_button.show()
+
+color = ColorToolButton()
+tool_item = Gtk.ToolItem()
+tool_item.add(color)
+color.show()
+tool_item.show()
+toolbar_box.toolbar.insert(tool_item, -1)
+
 separator = Gtk.SeparatorToolItem()
 separator.props.draw = False
 separator.set_expand(True)
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [sugar-toolkit-gtk3] Finish the port of ColorToolButton to gtk3

2012-08-07 Thread Benjamin Berg 
On Tue, 2012-08-07 at 16:06 -0300, godi...@sugarlabs.org wrote:
> From: Gonzalo Odiard 
> 
> This patch solves the following problems:
> 
> * API changed in the drag and drop code in Gtk
> * Changes in the way to get color information from the theme.
> * The internal button was not visible.
> 
> Signed-of-by: Gonzalo Odiard 
Reviewd-by: Benjamin Berg 

Looks like a pretty straigt forward port, and I don't see anything that
seems wrong.

Benjamin

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ASLO] Release Jukebox-27

2012-08-07 Thread Sugar Labs Activities 
Activity Homepage:
http://activities.sugarlabs.org/addon/4045

Sugar Platform:
0.98 - 0.98

Download Now:
http://activities.sugarlabs.org/downloads/file/28184/jukebox-27.xo

Release notes:
Port to Gtk3 - Manuel Kaufmann
Current and total time SL #3714 - Manuel Kaufmann
Improved toolbar  - Manuel Kaufmann



Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ASLO] Release Get Books-12

2012-08-07 Thread Sugar Labs Activities 
Activity Homepage:
http://activities.sugarlabs.org/addon/4304

Sugar Platform:
0.98 - 0.98

Download Now:
http://activities.sugarlabs.org/downloads/file/28185/get_books-12.xo

Release notes:
Port to Gtk3 - Manuel Kaufmann
Use Gio to monitor external devices  - Manuel Kaufmann
Drop libxml2 SL #3419 - Manuel Kaufmann
Report when could not reach the server SL #3180 - Manuel Kaufmann
Avoid error using the activity in spanish due to accents in translation - SL 
#3763 - Gonzalo Odiard



Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] [ASLO] Release Log-30

2012-08-07 Thread Sugar Labs Activities 
Activity Homepage:
http://activities.sugarlabs.org/addon/4056

Sugar Platform:
0.98 - 0.98

Download Now:
http://activities.sugarlabs.org/downloads/file/28186/log-30.xo

Release notes:
Activity ported to Gtk3


Sugar Labs Activities
http://activities.sugarlabs.org

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] Idea for a New Activity in Sugar: To code and run C, C++ programs

2012-08-07 Thread James Cameron 
On Tue, Aug 07, 2012 at 09:51:07PM +0530, Anish Mangal wrote:
> +1 or there are plenty of ideas around developing pippy (http://
> wiki.sugarlabs.org/go/User:Quozl) as well :-)

Ideas are easy, implementation is hard.

If we have someone willing to implement a C teaching environment, then
I'm in favour of getting out of the way to let them do it.

-- 
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] [sugar-toolkit-gtk3] Finish the port of ColorToolButton to gtk3

2012-08-07 Thread Manuel Quiñones 
Thanks Gonzalo.

2012/8/7  :
> From: Gonzalo Odiard 
>
> This patch solves the following problems:
>
> * API changed in the drag and drop code in Gtk
> * Changes in the way to get color information from the theme.

I would also add in the message that this is because Gtk.Style was
deprecated by Gtk.StyleContext.  If you mention it the next time, the
review can be faster too :)

> * The internal button was not visible.
>
> Signed-of-by: Gonzalo Odiard 
> ---
>  src/sugar3/graphics/colorbutton.py | 30 ++
>  1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/src/sugar3/graphics/colorbutton.py 
> b/src/sugar3/graphics/colorbutton.py
> index c21da47..3b847b3 100644
> --- a/src/sugar3/graphics/colorbutton.py
> +++ b/src/sugar3/graphics/colorbutton.py
> @@ -64,20 +64,19 @@ class _ColorButton(Gtk.Button):
>  GObject.GObject.__init__(self, **kwargs)
>
>  if self._accept_drag:
> -Gtk.drag_dest_set(self, Gtk.DEST_DEFAULT_MOTION |
> -   Gtk.DEST_DEFAULT_HIGHLIGHT |
> -   Gtk.DEST_DEFAULT_DROP,
> -   [('application/x-color', 0, 0)],
> -   Gdk.DragAction.COPY)
> -self.drag_source_set(Gdk.EventMask.BUTTON1_MASK | 
> Gdk.EventMask.BUTTON3_MASK,
> - [('application/x-color', 0, 0)],
> - Gdk.DragAction.COPY)
> +self.drag_dest_set(Gtk.DestDefaults.MOTION |
> +Gtk.DestDefaults.HIGHLIGHT | Gtk.DestDefaults.DROP,
> +[Gtk.TargetEntry.new('application/x-color', 0, 0)],
> +Gdk.DragAction.COPY)
> +self.drag_source_set(Gdk.ModifierType.BUTTON1_MASK | \
> +Gdk.ModifierType.BUTTON3_MASK,
> +[Gtk.TargetEntry.new('application/x-color', 0, 0)],
> +Gdk.DragAction.COPY)

Drag and drop is not working for me.  A way to test it: drag one color
from the same palette to the toolbar button.  Another: add two color
buttons and drag from the palette of one to the other button.

I will try to figure out the problem and report back.

Are the PyGi devs aware that this constants are not being converted in
the pygi-convert script?

>  self.connect('drag_data_received', self.__drag_data_received_cb)
>  self.connect('drag_data_get', self.__drag_data_get_cb)
>
>  self._preview.fill_color = get_svg_color_string(self._color)
> -self._preview.stroke_color = \
> -get_svg_color_string(self.style.fg[Gtk.StateType.NORMAL])
> +self._preview.stroke_color = self._get_fg_style_color_str()

I think would be a more readable name: _get_preview_stroke_color.

>  self.set_image(self._preview)
>
>  if self._has_palette and self._has_invoker:
> @@ -103,8 +102,14 @@ class _ColorButton(Gtk.Button):
>  self.color = self._palette.color
>
>  def do_style_set(self, previous_style):
> -self._preview.stroke_color = \
> -get_svg_color_string(self.style.fg[Gtk.StateType.NORMAL])
> +self._preview.stroke_color = self._get_fg_style_color_str()
> +
> +def _get_fg_style_color_str(self):
> +context = self.get_style_context()
> +fg_color = context.get_color(Gtk.StateType.NORMAL)
> +# the color components are stored as float values between 0.0 and 1.0
> +return '#%.2X%.2X%.2X' % (fg_color.red * 255, fg_color.green * 255,
> +  fg_color.blue * 255)

Great, this is because of the deprecation mentioned above.  The
returned colors are the same as in GTK2.

>  def do_clicked(self):
>  if self._palette:
> @@ -438,6 +443,7 @@ class ColorToolButton(Gtk.ToolItem):
>  # Replace it with a ColorButton
>  color_button = _ColorButton(icon_name=icon_name, has_invoker=False)
>  self.add(color_button)
> +color_button.show()

Yes, tested and without this addition the button is not shown.

>  # The following is so that the behaviour on the toolbar is correct.
>  color_button.set_relief(Gtk.ReliefStyle.NONE)
> --
> 1.7.11.2
>
> ___
> Sugar-devel mailing list
> Sugar-devel@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel

-- 
.. manuq ..
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] listing of activities that do not start in sugar 0.96.2 in http://scotland.proximity.on.ca/raspberrypi/test-releases/rpfr17/latest/raspberrypi-fedora-remix-17-test-004.img

2012-08-07 Thread Thomas C Gilliard 


These were installed with "yum install sugar*"
 (I think this command downloads sugar; sugar-emulator; and all of the 
sugar activities available in sugar 0.96.2 arm)


Report:[1]

 http://wiki.sugarlabs.org/go/Testing/Reports/ARM_RPi#Applications

The error message in log.activity is listed for the activities that do 
not start in f17 sugar 0.96.2 arm


Tom Gilliard

[1] 
http://wiki.sugarlabs.org/go/Testing/Reports/ARM_RPi#Test_report_raspberrypi-fedora-remix-17-test-004.img

___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

Re: [Sugar-devel] [sugar-toolkit-gtk3] Finish the port of ColorToolButton to gtk3

2012-08-07 Thread Gonzalo Odiard 
>
> > * API changed in the drag and drop code in Gtk
> > * Changes in the way to get color information from the theme.
>
> I would also add in the message that this is because Gtk.Style was
> deprecated by Gtk.StyleContext.  If you mention it the next time, the
> review can be faster too :)
>
>
Be free to suggest a more descriptive comment.




> Drag and drop is not working for me.  A way to test it: drag one color
> from the same palette to the toolbar button.  Another: add two color
> buttons and drag from the palette of one to the other button.
>
> I will try to figure out the problem and report back.
>
>
Sadly, you are right. Now I have tried a lot, but didn't found what is
happening.
If anybody have a idea, is welcomed. The call back methods for the signals
'drag_data_received' and 'drag_data_get' are not called.



> Are the PyGi devs aware that this constants are not being converted in
> the pygi-convert script?
>
>
I have not reported it yet.

> +self._preview.stroke_color = self._get_fg_style_color_str()
>
> I think would be a more readable name: _get_preview_stroke_color.
>
>
Well, the method get the foreground color from the style...
Anyway, if you are happy with other method name, change it.



Gonzalo
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel

[Sugar-devel] 0.98 Schedule proposal

2012-08-07 Thread Simon Schampijer 

Hi,

I have been drafting the schedule for the 0.98 release [1]. We are a
bit late in defining it but things have been in flux for a while. We
normally follow the GNOME schedule and release every six months. This
time those of us at OLPC have ambitious goals:

- port the shell to GTK+ 3 and PyGobject/gobject-introspection
- make Sugar usable with touch devices such as the upcoming XO-4 touch

And I think these 0.98 goals are also shared by other key contributors
outside of the direct OLPC umbrella.

To make this possible we would need to extend the 0.98 schedule this
time and align with the OLPC one for the upcoming 12.2.0 release [2].
Releasing in September (i.e. following the GNOME schedule) would just
be too soon to meet the above goals, furthermore it would involve
freezing in less than 2 weeks time (we wouldn't be able to achieve
much at all).

Of course there are more Sugar users than the OLPC ones but it is by
far the largest user group and this is a big opportunity to bring
Sugar itself to the next level, having it ready for touch! So we
better take it.

For the next Sugar release (is that 1.0? or do we call it 0.100 :) we
can go back to the normal schedule and align again with the GNOME
schedule.

Regards,
   Simon

[1] http://wiki.sugarlabs.org/go/0.98/Roadmap#Schedule
[2] http://wiki.laptop.org/go/12.2.0/Release_plan
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel