[sugar] Sugar mtg minutes, March 25, 2008 - Text to Speech

[Hemant Goyal]

Hi all,

Here are the minutes of the recent Sugar meeting with respect to Text To
Speech.

Some decisions that have been taken are as follows:

   1. speech-dispatcher has been accepted to be shipped with the XO as
   the speech synthesis server.
   2. speech-dispatcher language bindings and API was discussed and it
   was found to be useful.
   3. hemantg and assimd must now complete the RPM packaging of
   speech-dispatcher and dotconf packages respectively.
   4. eben and erikos will together take a decision on how to expose
   speech synthesis capabilities on the XO. A speech device will be present in
   the activity tray which can have a palette exposing a subset of speech
   synthesis settings. The control panel will contain an option to modify all
   the speech synthesis parameters with an audio preview button.
   5. hemantg will in parallel work on the command line interface for
   modifying/storing/retrieving all the default/sugar speech synthesis
   settings.
   6. timthelion discussed about the need for having well defined UI for
   the highlight and speak feature, and accessibility.


Please add anything that I've missed or correct anything not written
clearly.

The meeting logs are available at :
http://dev.laptop.org/~erikos/sugar_meeting_Mar_25.log

Thanks,
Hemant
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] some new matchbox rpm testing results

[Marco Pesenti Gritti]

On Wed, Mar 26, 2008 at 5:18 AM, Chris Ball <[EMAIL PROTECTED]> wrote:
>  Assuming this is additive in the measurements you took, though, is there
>  any reason that it needs to be?  What composited operations do we want
>  to be able to perform?  If we're only really trying to speed up things
>  like overlaying windows or the frame on top of a base window, can we get
>  away with asking matchbox to only composite on top of the currently
>  shown window?

We are considering to iconify/unmap "inactive" windows which would
have that effect.

>
>
>> After launching etoys (which didn't seem to want to draw itself,
>> but dunno if that's my build or the compositing) and stopping it,
>
>  I see the following in one of the latest matchbox commit messages, might
>  be relevant:
>
>  "compositor now compiles again - but dont work 100%"
>
>  Michael mentioned that etoys doesn't work for him either, and that
>  Record is failing to render its Xvideo window sometimes too.

Yeah mb1 compositor is not great, Matthew warned us about it in the
past and suggest to wait for mb2. We could see if it's possible to
fixup mb1 compositor or consider to switch to mb2 or to another window
manager altogether (metacity?) if we want compatibility with desktop
applications.

Marco
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Compositing and Frame Animation

[Marco Pesenti Gritti]

On Wed, Mar 26, 2008 at 5:34 AM, Michael Stone <[EMAIL PROTECTED]> wrote:
>
>  Dear sugar developers,
>
>  I've been looking for easily modifiable UI "features" that feel to me to be
>  less than snappy.  Compositing support has made animation of the frame into 
> one
>  of these "features"; therefore, here is a patch that removes it for your
>  experimental consideration. Feel free to apply it (or to ignore it) as your
>  preferences dictate.

I'm confused. Are you saying that compositing made frame animation
less than snappy? I'd expect the opposite and the testing reports I
got so far confirms the theory.

Marco
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] GVFS, OLPC, and GIT ?

[Alexander Larsson]

On Tue, 2008-03-25 at 15:46 -0400, Martin Langhoff wrote:
> On Tue, Mar 25, 2008 at 10:29 AM, Benjamin M. Schwartz
> <[EMAIL PROTECTED]> wrote:
> >  |> sufficiently generic to encompass multiple versions.  I do not fully
> >  |> grasp the layering between GIO and GVFS.
> 
> Be aware that GIO/GVFS are very high level. In other words, they work
> for the Gnome guys because they don't realise that not all the world
> links to libgnome ;-)

gio/gvfs doesn't link to anything but glib, dbus and hal on the client
side.

> zip and tar and rsync and amanda won't work with them. Any modern
> program will break trying to use a GIO/GVFS "mount" as their location
> of storage. Moderately modern interfaces like mmap - that you need to
> work on advanced filehandling, for example in image manipulation
> programs - don't work either.

GVfs does contain a fuse filesystem implementation that allows posix
apps to access the mounted gvfs filesystems, but you're right that the
full extent of the posix semantics are not availible in the gio APIs.
This is very much by design, as many of the features of posix are just
unimplementable on the backends that we want to support. 

Furthermore, some of the features posix give you to implement certain
highlevel operations do not match other backends, even if there are
features availible that allow you to implement the desired highlevel
operation in some other way. For instance, you want a highlevel "save"
operation that implements atomic safe file overwrite (to the extent
possible). On posix this is implemented via O_EXCL open of tempfile and
then relying on atomic replacement of rename()[1]. However, this just
doesn't match how things like ftp and webdav work, but they have other
ways to implement this operation. Thus gvfs has a highlevel operation
for this with backend-specific implementations.

Of course, the goal of gio/gvfs is not to replace all file access. It
would make no sense to implement e.g. a database over it, and neighter
would it make sense to use for application data files or internal
implementation details. Its goal is to be used for what I call "user
document" files. This doesn't mean they have to be word processor
documents, just the kind of files the user produce and consume during
his normal work.

If your "modern" application expects to be able to mmap something and
get the behaviour you generally expect from mmap that means that then
app (by design) can't ever e.g. directly work on a file on an ftp server
(in any sane way). Thats a design choice of the app author, although he
could of course use gvfs to download the file and then work on it
locally.

> I expect GVFS to work well for file copy, move and for basic file
> viewers, not for a real read/write application.

It depends on what you mean by a "real" application of course. The main
usecase is for applications that use a load/save document model where
the entire document is streamed into memory.

> >  | * Have some kind of operation that takes a versioned filesystem mount
> >  | (globally) to a different version.
> 
> Look at git-fuse.

fuse is inherently path based too and has no notion of versions, so its
not any different from gvfs in this respect.

[1] Well, this is a simplification of the posix save code, as its really
quite a bit more complicated, but you get the point.

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] GVFS, OLPC, and GIT ?

[Alexander Larsson]

On Tue, 2008-03-25 at 16:27 -0400, Benjamin M. Schwartz wrote:
> On Tue, 2008-03-25 at 15:46 -0400, Martin Langhoff wrote:
> > On Tue, Mar 25, 2008 at 10:29 AM, Benjamin M. Schwartz
> > <[EMAIL PROTECTED]> wrote:
> > >  |> sufficiently generic to encompass multiple versions.  I do not fully
> > >  |> grasp the layering between GIO and GVFS.
> > 
> > Be aware that GIO/GVFS are very high level. In other words, they work
> > for the Gnome guys because they don't realise that not all the world
> > links to libgnome ;-)
> 
> To be clear, my disappointment is in fact that GVFS is not high-level
> enough.  It seems to me that a path-based filesystem API is not
> appropriate for a versioning datastore, because the versioned objects
> themselves contain path trees, leading to ambiguity about the meaning of
> a path.  This goes double when both versioning and complex metadata are
> present.  I would prefer something much more like a typed OO interface.
> Indeed, that is what we have now: an object-oriented DBus API.  That
> still seems like the best solution to me.

I agree that a path based filesystem is not the ideal for a versioned
datastore. However, it may be useful as a *view* of such a datastore for
applications that are not programmed against the (likely very different)
API of the data store. 

However, as the olpc project has much more control of the software
running on the laptops you might be able to only ship software that uses
the native datastore APIs.

A "native" API for a versioned datastore should probably make away
completely with filenames, instead use some autogenerated unique
identifier like uuids, have document type specified in the file creation
operation and allow specifying which version fork to open in the open
content stream call. This is interesting in its own, but not the goal of
gvfs, the gvfs goal is more like allowing access to the path-based file
stores that already exists and where users have files stored.


___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Merging sugar-toolkit changes from tomeu repository

[Tomeu Vizoso]

On Wed, Mar 26, 2008 at 12:23 AM, Marco Pesenti Gritti
<[EMAIL PROTECTED]> wrote:
>  2 Accell support.

First patch attached.

Thanks,

Tomeu
From 2b0f3000e3a91dc6f676743f7b038af785913fa5 Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso <[EMAIL PROTECTED]>
Date: Wed, 26 Mar 2008 11:50:46 +0100
Subject: [PATCH] Add support for accelerators to buttons and toolbars.

---
 sugar/activity/activity.py|   13 --
 sugar/graphics/Makefile.am|1 +
 sugar/graphics/palette.py |   34 +
 sugar/graphics/radiotoolbutton.py |   76 ++--
 sugar/graphics/toolbox.py |   59 +---
 sugar/graphics/toolbutton.py  |   64 --
 6 files changed, 218 insertions(+), 29 deletions(-)

diff --git a/sugar/activity/activity.py b/sugar/activity/activity.py
index 146d863..996de53 100644
--- a/sugar/activity/activity.py
+++ b/sugar/activity/activity.py
@@ -28,6 +28,7 @@ See the methods of the Activity class below for more information on what you
 will need for a real activity.
 """
 # Copyright (C) 2006-2007 Red Hat, Inc.
+# Copyright (C) 2007-2008 One Laptop Per Child
 #
 # This library is free software; you can redistribute it and/or
 # modify it under the terms of the GNU Lesser General Public
@@ -125,14 +126,14 @@ class ActivityToolbar(gtk.Toolbar):
 
 self._update_share()
 
-self.keep = ToolButton('document-save')
-self.keep.set_tooltip(_('Keep'))
+self.keep = ToolButton('document-save', label=_('Keep'))
+self.keep.props.accelerator = _('S')
 self.keep.connect('clicked', self.__keep_clicked_cb)
 self.insert(self.keep, -1)
 self.keep.show()
 
-self.stop = ToolButton('activity-stop')
-self.stop.set_tooltip(_('Stop'))
+self.stop = ToolButton('activity-stop', label=_('Stop'))
+self.stop.props.accelerator = _('Q')
 self.stop.connect('clicked', self.__stop_clicked_cb)
 self.insert(self.stop, -1)
 self.stop.show()
@@ -291,7 +292,7 @@ class ActivityToolbox(Toolbox):
 Toolbox.__init__(self)
 
 self._activity_toolbar = ActivityToolbar(activity)
-self.add_toolbar(_('Activity'), self._activity_toolbar)
+self.add_toolbar(_('Activity'), self._activity_toolbar, _('1'))
 self._activity_toolbar.show()
 
 def get_activity_toolbar(self):
@@ -433,6 +434,8 @@ class Activity(Window, gtk.Container):
 self._max_participants = 0
 self._invites_queue = []
 
+self.add_accel_group(gtk.AccelGroup())
+
 self._bus = ActivityService(self)
 self._owns_file = False
 
diff --git a/sugar/graphics/Makefile.am b/sugar/graphics/Makefile.am
index 0a3a846..57b19eb 100644
--- a/sugar/graphics/Makefile.am
+++ b/sugar/graphics/Makefile.am
@@ -1,6 +1,7 @@
 sugardir = $(pythondir)/sugar/graphics
 sugar_PYTHON =			\
 	__init__.py		\
+accellabel.py   \
 alert.py\
 	animator.py		\
 	combobox.py		\
diff --git a/sugar/graphics/palette.py b/sugar/graphics/palette.py
index e84cc51..29cfb05 100644
--- a/sugar/graphics/palette.py
+++ b/sugar/graphics/palette.py
@@ -1,4 +1,5 @@
 # Copyright (C) 2007, Eduardo Silva <[EMAIL PROTECTED]>
+# Copyright (C) 2008, One Laptop Per Child
 #
 # This library is free software; you can redistribute it and/or
 # modify it under the terms of the GNU Lesser General Public
@@ -26,6 +27,7 @@ import pango
 from sugar.graphics import palettegroup
 from sugar.graphics import animator
 from sugar.graphics import style
+from sugar.graphics.accellabel import AccelLabel
 from sugar import _sugarext
 
 # Helper function to find the gap position and size of widget a
@@ -141,7 +143,7 @@ class Palette(gtk.Window):
  gobject.TYPE_NONE, ([]))
 }
 
-def __init__(self, label, accel_path=None, menu_after_content=False,
+def __init__(self, label, accelerator=None, menu_after_content=False,
 text_maxlen=0):
 gtk.Window.__init__(self)
 
@@ -176,9 +178,13 @@ class Palette(gtk.Window):
 
 vbox = gtk.VBox()
 
+hbox = gtk.HBox()
+hbox.set_size_request(-1, style.zoom(style.GRID_CELL_SIZE)
+  - 2 * self.get_border_width())
+vbox.pack_start(hbox, expand=False)
+hbox.show()
+
 self._label = gtk.Label()
-self._label.set_size_request(-1, style.zoom(style.GRID_CELL_SIZE)
-  - 2*self.get_border_width())
 self._label.set_alignment(0, 0.5)
 self._label.set_padding(style.DEFAULT_SPACING, 0)
 
@@ -186,7 +192,11 @@ class Palette(gtk.Window):
 self._label.set_max_width_chars(text_maxlen)
 self._label.set_ellipsize(pango.ELLIPSIZE_MIDDLE)
 
-vbox.pack_start(self._label, False)
+hbox.pack_start(self._label)
+
+self._accel_label = AccelLabel()
+self._accel_label.set_paddin

Re: [sugar] some new matchbox rpm testing results

[Tomeu Vizoso]

On Wed, Mar 26, 2008 at 1:43 AM, Martin Dengler
<[EMAIL PROTECTED]> wrote:
> I ran into a discussion on #sugar about a new matchbox rpm from tomeu
>  with compositing enabled[1], and he asked me to email some testing
>  results to sugar@ - in particular, to determine the memory impact, and
>  whether that memory was in Xorg or the activities.

Thanks a lot, this is a great help. I'm going to post here a simple
patch for sugar that iconifies all activity windows except the active
one. Would be good to see how that reduces mem usage.

Thanks again,

Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Merging sugar-toolkit changes from tomeu repository

[Tomeu Vizoso]

On Wed, Mar 26, 2008 at 11:52 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 26, 2008 at 12:23 AM, Marco Pesenti Gritti
>  <[EMAIL PROTECTED]> wrote:
>  >  2 Accell support.
>
>  First patch attached.

Sorry, one file was missing.

Tomeu
From 49eb30cd182b983edb4938b8ec234d667a71cd84 Mon Sep 17 00:00:00 2001
From: Tomeu Vizoso <[EMAIL PROTECTED]>
Date: Wed, 26 Mar 2008 12:07:41 +0100
Subject: [PATCH] Add support for accelerators to buttons and toolbars.

---
 sugar/activity/activity.py|   13 --
 sugar/graphics/Makefile.am|1 +
 sugar/graphics/accellabel.py  |   59 
 sugar/graphics/palette.py |   34 +
 sugar/graphics/radiotoolbutton.py |   76 ++--
 sugar/graphics/toolbox.py |   59 +---
 sugar/graphics/toolbutton.py  |   64 --
 7 files changed, 277 insertions(+), 29 deletions(-)
 create mode 100644 sugar/graphics/accellabel.py

diff --git a/sugar/activity/activity.py b/sugar/activity/activity.py
index 146d863..996de53 100644
--- a/sugar/activity/activity.py
+++ b/sugar/activity/activity.py
@@ -28,6 +28,7 @@ See the methods of the Activity class below for more information on what you
 will need for a real activity.
 """
 # Copyright (C) 2006-2007 Red Hat, Inc.
+# Copyright (C) 2007-2008 One Laptop Per Child
 #
 # This library is free software; you can redistribute it and/or
 # modify it under the terms of the GNU Lesser General Public
@@ -125,14 +126,14 @@ class ActivityToolbar(gtk.Toolbar):
 
 self._update_share()
 
-self.keep = ToolButton('document-save')
-self.keep.set_tooltip(_('Keep'))
+self.keep = ToolButton('document-save', label=_('Keep'))
+self.keep.props.accelerator = _('S')
 self.keep.connect('clicked', self.__keep_clicked_cb)
 self.insert(self.keep, -1)
 self.keep.show()
 
-self.stop = ToolButton('activity-stop')
-self.stop.set_tooltip(_('Stop'))
+self.stop = ToolButton('activity-stop', label=_('Stop'))
+self.stop.props.accelerator = _('Q')
 self.stop.connect('clicked', self.__stop_clicked_cb)
 self.insert(self.stop, -1)
 self.stop.show()
@@ -291,7 +292,7 @@ class ActivityToolbox(Toolbox):
 Toolbox.__init__(self)
 
 self._activity_toolbar = ActivityToolbar(activity)
-self.add_toolbar(_('Activity'), self._activity_toolbar)
+self.add_toolbar(_('Activity'), self._activity_toolbar, _('1'))
 self._activity_toolbar.show()
 
 def get_activity_toolbar(self):
@@ -433,6 +434,8 @@ class Activity(Window, gtk.Container):
 self._max_participants = 0
 self._invites_queue = []
 
+self.add_accel_group(gtk.AccelGroup())
+
 self._bus = ActivityService(self)
 self._owns_file = False
 
diff --git a/sugar/graphics/Makefile.am b/sugar/graphics/Makefile.am
index 0a3a846..57b19eb 100644
--- a/sugar/graphics/Makefile.am
+++ b/sugar/graphics/Makefile.am
@@ -1,6 +1,7 @@
 sugardir = $(pythondir)/sugar/graphics
 sugar_PYTHON =			\
 	__init__.py		\
+accellabel.py   \
 alert.py\
 	animator.py		\
 	combobox.py		\
diff --git a/sugar/graphics/accellabel.py b/sugar/graphics/accellabel.py
new file mode 100644
index 000..ceb5283
--- /dev/null
+++ b/sugar/graphics/accellabel.py
@@ -0,0 +1,59 @@
+# Copyright (C) 2008, One Laptop Per Child
+#
+# This library is free software; you can redistribute it and/or
+# modify it under the terms of the GNU Lesser General Public
+# License as published by the Free Software Foundation; either
+# version 2 of the License, or (at your option) any later version.
+#
+# This library 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
+# Lesser General Public License for more details.
+#
+# You should have received a copy of the GNU Lesser General Public
+# License along with this library; if not, write to the
+# Free Software Foundation, Inc., 59 Temple Place - Suite 330,
+# Boston, MA 02111-1307, USA.
+
+import logging
+
+import gtk
+import gobject
+
+_KEY_MODIFIERS = {gtk.gdk.SHIFT_MASK:   0x21E7,
+  gtk.gdk.CONTROL_MASK: 0x2666,
+  gtk.gdk.MOD1_MASK:0x25C7}
+
+class AccelLabel(gtk.Label):
+__gtype_name__ = "SugarAccelLabel"
+
+def __init__(self, **kwargs):
+self._accelerator = None
+
+gobject.GObject.__init__(self, **kwargs)
+
+def set_accelerator(self, accelerator):
+if self._accelerator != accelerator:
+self._accelerator = accelerator
+self.set_markup(self._format_accelerator())
+
+def get_accelerator(self):
+return self._accelerator
+
+accelerator = gobject.property(type=str, setter=set_accelerator,
+getter=get_ac

Re: [sugar] Merging sugar-toolkit changes from tomeu repository

[Marco Pesenti Gritti]

On Wed, Mar 26, 2008 at 12:09 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 26, 2008 at 11:52 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
>  > On Wed, Mar 26, 2008 at 12:23 AM, Marco Pesenti Gritti
>  >  <[EMAIL PROTECTED]> wrote:
>  >  >  2 Accell support.
>  >
>  >  First patch attached.
>
>  Sorry, one file was missing.

Here are the problems I see with the patch (I know you are aware of
some of these):

1 We are picking a random accel group from the window (well the first one).
2 We are duplicating a lot of non trivial code in each toolbar item
implementation.
3 I still don't like the idea of using translated strings as
accelerators. More importantly I don't think we should differ from gtk
in such a basic functionality.

All of these looks pretty difficult to solve.

Marco
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)

[Guillaume Desmottes]

Le mardi 25 mars 2008 à 16:02 -0400, Benjamin M. Schwartz a écrit :
> This works, and will work for the proposed case.  For the future, I see
> file transfer as precisely the sort of thing that should be handled
> internally to Telepathy.  Perhaps Telepathy should implement XEP-0234
> (file transfer)[2] or even XEP-0214 (file sharing)[3].
> 

We have a draft of spec for file transfer (but it will be probably
modified) and a Salut branch implementing it. So that's definitely
something that could be done at some point.


G.

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] some new matchbox rpm testing results

[Martin Dengler]

On Wed, Mar 26, 2008 at 12:18:37AM -0400, Chris Ball wrote:
> Hi Martin,
> 
>> It looks like the memory is in Xorg[2], and is around 2 MiB per
>> activity[3]:
> 
> First of all, thanks so much for doing this profiling, it's awesome.

No problem.

> I'm unclear on whether this 2 MiB per activity is additive or not --
> matchbox seems to destroy the composition pixmap on client window hide,

It seems very additive, though with the caveat that it seems to have
some "overhead" that can be made to change +/-3 MiB (as I mentioned in
my footnote.

> - Chris.

Martin


pgphZZtFZ7qzb.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] some new matchbox rpm testing results

[Martin Dengler]

On Wed, Mar 26, 2008 at 12:27:51AM -0400, Michael Stone wrote:
> > "compositor now compiles again - but dont work 100%"
> > 
> > Michael mentioned that etoys doesn't work for him either, and that
> > Record is failing to render its Xvideo window sometimes too.
> 
> Measure's waveform display is just a gray box (though the rest of its
> GUI is fine) and Gnash video also seems like it may be having trouble.

Record's video window behaves really badly too, and etoys doesn't
repaint as I mentioned and (for which you kindly opened a trac).

> Michael

Martin



pgpwJTkNJCazT.pgp
Description: PGP signature
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Merging sugar-toolkit changes from tomeu repository

[Tomeu Vizoso]

On Wed, Mar 26, 2008 at 1:32 PM, Marco Pesenti Gritti
<[EMAIL PROTECTED]> wrote:
>
> On Wed, Mar 26, 2008 at 12:09 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
>  > On Wed, Mar 26, 2008 at 11:52 AM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
>  >  > On Wed, Mar 26, 2008 at 12:23 AM, Marco Pesenti Gritti
>  >  >  <[EMAIL PROTECTED]> wrote:
>  >  >  >  2 Accell support.
>  >  >
>  >  >  First patch attached.
>  >
>  >  Sorry, one file was missing.
>
>  Here are the problems I see with the patch (I know you are aware of
>  some of these):
>
>  1 We are picking a random accel group from the window (well the first one).
>  2 We are duplicating a lot of non trivial code in each toolbar item
>  implementation.
>  3 I still don't like the idea of using translated strings as
>  accelerators. More importantly I don't think we should differ from gtk
>  in such a basic functionality.
>
>  All of these looks pretty difficult to solve.

So, trying to summarize discussion in #sugar:

1 Accel group will be pushed from the top level window downwards.
s.g.Window would push it to the toolbox, which would push it into the
toolbars and then into the toolitems. (see details below)

2 We'll share the duplicated code similarly by simply sharing some
methods without inheritance.

3 Not really part of the API, I would prefer if this decision was
taken by the translation groups, but personally don't feel as
strongly.

4 (Having our own AccelLabel) This is needed for showing diamonds
instead of "ctrl" or "alt". We'll drop it by now and later try to do
this with the upstream AccelLabel.

When setting up the UI, the window creates an accel_group and gives it
to the toolbox:
toolbox.set_data('accel_group', accel_group)

The toolbox will do the same to the toolbar and the toolbar to the toolitems.

ToolItems and Toolbars will listen for parent-set, and then set the
accelerator to that accel_group.

Marco, what about shortcuts for widgets not in the toolbar and CanvasItems?

Thanks,

Tomeu
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Merging sugar-toolkit changes from tomeu repository

[Marco Pesenti Gritti]

On Wed, Mar 26, 2008 at 4:09 PM, Tomeu Vizoso <[EMAIL PROTECTED]> wrote:
>  So, trying to summarize discussion in #sugar:
>
>  1 Accel group will be pushed from the top level window downwards.
>  s.g.Window would push it to the toolbox, which would push it into the
>  toolbars and then into the toolitems. (see details below)
>
>  2 We'll share the duplicated code similarly by simply sharing some
>  methods without inheritance.
>
>  3 Not really part of the API, I would prefer if this decision was
>  taken by the translation groups, but personally don't feel as
>  strongly.

I suggest we just punt on this for now (i.e. we don't make those
strings translatable in Sugar).

>  4 (Having our own AccelLabel) This is needed for showing diamonds
>  instead of "ctrl" or "alt". We'll drop it by now and later try to do
>  this with the upstream AccelLabel.
>
>  When setting up the UI, the window creates an accel_group and gives it
>  to the toolbox:
>  toolbox.set_data('accel_group', accel_group)

I think we don't need to use set_data here. We can make the
accell_group a toolbox property.

>  The toolbox will do the same to the toolbar and the toolbar to the toolitems.

We can either subclass toolbar or use set_data. I'd probably use set_data.

>  ToolItems and Toolbars will listen for parent-set, and then set the
>  accelerator to that accel_group.

Unless I'm missing something Toolbar will not need to listen for
parent_set. The items will then setup their accel on
self.parent.get_data('accell_group').

>
>  Marco, what about shortcuts for widgets not in the toolbar and CanvasItems?

Can you give concrete examples?

Marco
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)

[Jameson "Chema" Quinn]

Develop clearly needs to be aware of whatever solution we come up with for
activity updates. This means that Develop has to be able to do the signing.
Right now, bitfrost does not give out the private key to activities
(correctly) and does not allow activities to request a signature for
something (wrongly - there is a P_IDENT bitfrost privilege which should
allow activities which have it to sign things).

I raised this issue on IRC and got two responses.

1. neuralis/ ivan krstic was the security guy on the team and he has just
left. Do not expect this to be fixed soon.

2. Do not try to fix this yourself, as security must be done right or not at
all.

(apologies for stripping the nuances)

I disagree with #2. Security must not be done wrong, but it can be done
partially if we think things through. Adding a hook so that activities with
P_IDENT can request signatures, without seeing the private key, is IMO safe
and simple enough to be worth doing if it helps us with activity updates.

(More summary from IRC: the tricky, unresolved issue is key trust - does a
given public key mean what we think it means? This is separate from key
security. Let me give a scenario.

Activities spread virally by sharing. Alicia codes a new activity V1 and
signs it, it starts to spread. Bad Bob replaces Alicia's sig with his own
and keeps spreading it. Now Bad Bob can add his malicious code to the
activity later, and all the people who got the activity downstream from him
will automatically update to the malicious version.

To me this is not a problem, because Bob could have added his code to the
activity in the first place. It just lets him be a little lazier. It is 100%
equivalent if Bob had added some general-purpose trojan to the app
immediately, so auto-update has not created any new vulnerabilities. Also,
if there are two versions of the same activity floating around with
different signatures, noticeable things will start to happen - either
someone downstream from Bob will get an update from Alicia that will
mysteriously fail to autoinstall, or vice versa.)

On Wed, Mar 26, 2008 at 7:10 AM, Guillaume Desmottes <
[EMAIL PROTECTED]> wrote:

> Le mardi 25 mars 2008 à 16:02 -0400, Benjamin M. Schwartz a écrit :
> > This works, and will work for the proposed case.  For the future, I see
> > file transfer as precisely the sort of thing that should be handled
> > internally to Telepathy.  Perhaps Telepathy should implement XEP-0234
> > (file transfer)[2] or even XEP-0214 (file sharing)[3].
> >
>
> We have a draft of spec for file transfer (but it will be probably
> modified) and a Salut branch implementing it. So that's definitely
> something that could be done at some point.
>
>
>G.
>
> ___
> Sugar mailing list
> Sugar@lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Playing w/ Activity packs in build 702

[Arjun Sarwal]

 Bryan,

Thanks for the feedback.



>
> Minimal documentation for Starchart, Go, Measure, Jump, Implode,
> Connect. These are __great__ activities but it would be hard for a kid
> to get into them w/out having background knowledge. Our two schools will
> share a 128 kbps Internet connection so it will be harder for the kids
> to google for answers.
>


Im working on a document which I'd base off the Measure wiki page that could
be included on the XO (thus one can start doing things w/o having to look
for anything on the internet). Any suggestions on what topics to include
would be great.

thanks
Arjun
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Compositing and Frame Animation

[Michael Stone]

Marco,

Apologies if I confused you. Composition does make the animation much
smoother. Instead, I was making the UI statement that, having tried both
animation with today's constants and no animation, I prefer no
animation. (A higher frame rate or a shorter animation might work just
as well.) I included the code merely so that others could try the same
experiment more easily.

Nothing special here,

Michael

On Wed, Mar 26, 2008 at 10:56:07AM +0100, Marco Pesenti Gritti wrote:
> On Wed, Mar 26, 2008 at 5:34 AM, Michael Stone <[EMAIL PROTECTED]> wrote:
> >
> >  Dear sugar developers,
> >
> >  I've been looking for easily modifiable UI "features" that feel to me to be
> >  less than snappy.  Compositing support has made animation of the frame 
> > into one
> >  of these "features"; therefore, here is a patch that removes it for your
> >  experimental consideration. Feel free to apply it (or to ignore it) as your
> >  preferences dictate.
> 
> I'm confused. Are you saying that compositing made frame animation
> less than snappy? I'd expect the opposite and the testing reports I
> got so far confirms the theory.
> 
> Marco
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Joyride is reopened for development.

[Mikus Grinbergs]

Chris wrote
 > * Continue to have (all) activities present in Joyride builds.
I was asked to describe how I see Activity precedence affecting me.


I dual-boot my G1G1 - one build is "the public will see this" (e.g., 
Update.1) and the other build is "development" (e.g., Joyride).  I 
customize these builds (which takes time), so I don't install 
*every* Joyride build that comes along.

Used to be that every kind of build carried its Activities in 
/usr/share -- when I booted a different build, I got access to *its* 
activities.  Now Update.1 builds expect all their Activities (except 
for Journal) in /home/olpc (which is NOT replaced when I boot a 
different build).  Supposing that I want to segregate "public" 
Activities from "development" Activities, what are now my options ?



If /usr/share/activities has precedence over /home/olpc/Activities, 
I can keep any uniquely "development" Activities in /usr/share in 
Joyride.  When I boot Joyride, they take precedence over the 
Update.1 Activities in /home/olpc.  When I boot Update.1, *its* 
/usr/share is empty (except for Journal), so the "public" Activities 
in /olpc/home are the ones which are accessed.  Everything works.

[I started this particular discussion with a request for information 
about the "correct" way to individually add Activities to /usr/share 
-- in particular, do I need to do something to keep rainbow happy? ]



On my system /home/olpc/Activities will keep "officially released" 
Activities.  If /home//Activities has precedence 
over /usr/share/activities, then where to put any uniquely 
"development" Activities (that I want to run under Joyride)?

Quickest way appears to be to define a __new__ user (different from 
'olpc').  When I log on with that new_user_id, the system will be 
looking in /home/new_user_id/Activities - that's where I can put all 
"Joyride" Activities, while leaving /home/olpc/Activities untouched.



As you can see, if Joyride continues to have all activities present 
in /usr/share/activities (and if that takes precedence over 
/home/olpc/Activities), it makes installing my dual-boot setup easy.

If Joyride builds continue to supply activities, but as a separate 
package, there is the matter of where to install the Joyride 
provided Activities vs. the "officially available" Activities.


mikus

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)

[Michael Stone]

On Wed, Mar 26, 2008 at 10:05:19AM -0600, Jameson Chema Quinn wrote:
> I disagree with #2. 

I disagree with both #1 and #2 and, as the current maintainer of
Rainbow, that should tell you something. More bluntly, please experiment
and please publish your work with a public solicitation of criticism.
It's true that, these days, I lack the uninterrupted time for serious
attacks on our really security hard problems (X, communications
security, and making isolation available on other platforms come to
mind), but I'll _make_ time for patch review, discussion, and writing on
these topics.

(Understand that, like any occasionally capricious maintainer, I may or
may not like your work, may or may not demand changes in your work
before I decide to merge it with mine, and probably won't agree with you
about the Right Way Forward. However, don't let that stop you!)

> partially if we think things through. Adding a hook so that activities with
> P_IDENT can request signatures, without seeing the private key, is IMO safe
> and simple enough to be worth doing if it helps us with activity updates.

It's a certainly a place to start - in other words, it may be
independently useful and it will certainly give us better understanding
of the overall problem. Please try it.

> Activities spread virally by sharing. Alicia codes a new activity V1 and
> signs it, it starts to spread. Bad Bob replaces Alicia's sig with his own
> and keeps spreading it. Now Bad Bob can add his malicious code to the
> activity later, and all the people who got the activity downstream from him
> will automatically update to the malicious version.

As I said in my previous email, Bitfrost clearly states (correctly, in
my mind) that even justified belief that code originates from some known
individual implies no trust relationship with that code. Period. Use
isolation to make it safer to play with code and use signing to help
reduce attackers' abilities to lie to you about what code you're going
to be running.

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Automatic transfer/update of activities on the mesh (Was: Sharing behavior in the core Read activity)

[Jameson "Chema" Quinn]

>
> As I said in my previous email, Bitfrost clearly states (correctly, in
> my mind) that even justified belief that code originates from some known
> individual implies no trust relationship with that code. Period. Use
> isolation to make it safer to play with code and use signing to help
> reduce attackers' abilities to lie to you about what code you're going
> to be running.
>

If you take this to the extreme, then you would reset manually-granted
bitfrost privileges on every activity update, and even remove the default
"resume" behavior from the journal for instances of that activity (if it is
not the same code, it cannot be trusted to handle to handle the same data
without an explicit "resume with new version" choice by the user).

I think new versions which are from the same source should get an implied
trust level - the same trust as prior versions, which, in general, will be
strictly limited by Bitfrost. I think that the fact that such "same source"
may be the same corrupted source does not affect this.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] XO-user's communications security needs

[Michael Stone]

Folks,

Pursuant to recent discussions about P_IDENT, I've begun drafting
principles and use cases in order to discover some of the communications
security needs of XO-users.

My thoughts to date (with substantial input from both Daf and
Polychronis) are recorded, haphazardly, at

  http://wiki.laptop.org/go/Communications_security

Finally, I will be meeting briefly with Jonathan Herzog tomorrow morning
in order to review this material. If you have the opportunity, please
examine my thoughts, let me know what you consider to be the most
pressing concerns either by replying to this email or on the wiki page.
I'll do what I can to dig up convincing answers. :)

Michael

___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] XO-user's communications security needs

[Jameson "Chema" Quinn]

I see 3 meaningful possibilities:

1. P_IDENT activities can sign/unencrypt anything with users private key,
with no user knowledge. Thus a signature means only that communication comes
from a given laptop, and has no implication about the awareness or assent of
the user of that laptop.

2. P_IDENT only lets activities use signatures/unencryption within strictly
limited communications protocols OR with some explicit, trusted-UI agreement
from the user. The communications protocols are designed such that each
encrypted/signed block is identifiable and validated as part of that
protocol (ie, header in every block, or only the temporary private key is
encrypted against the real private key and the OS refuses to unencrypt
temporary private keys unless they are marked as part of that protocol).
Thus a signature on, or the ability to unencrypt, data that is not marked as
part of that protocol, implies user assent.

3. There is one private key used for communications security, and another
one used for user identity verification.

Are my possibilities comprehensive? If so, which one are we aiming for?

Jameson

On Wed, Mar 26, 2008 at 11:40 AM, Michael Stone <[EMAIL PROTECTED]> wrote:

> Folks,
>
> Pursuant to recent discussions about P_IDENT, I've begun drafting
> principles and use cases in order to discover some of the communications
> security needs of XO-users.
>
> My thoughts to date (with substantial input from both Daf and
> Polychronis) are recorded, haphazardly, at
>
>  http://wiki.laptop.org/go/Communications_security
>
> Finally, I will be meeting briefly with Jonathan Herzog tomorrow morning
> in order to review this material. If you have the opportunity, please
> examine my thoughts, let me know what you consider to be the most
> pressing concerns either by replying to this email or on the wiki page.
> I'll do what I can to dig up convincing answers. :)
>
> Michael
>
> ___
> Sugar mailing list
> Sugar@lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] Application for Typing Tutor

[Prakhar Agarwal]

Hello Everyone,
I have finally submitted my application yesterday.
I have put together all the details on  wiki.laptop.org/go/LetsType
Your feedback is valuable, please provide your comments/suggestions. It
would be very useful for me.
Also, please refer my homepage:  prakhar.jiit.googlepages.com

Thanks for participating!!

Cheers,
-- 
Prakhar Agarwal
Technical Head - Library R&D Team
3rd Year
B.Tech, IT
JIIT University,Noida
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] Testing Update.1-702

[Michael Stone]

Dear everyone,

At today's software status meeting, several individuals, including:

  dgilmore
  erikos
  bemasc
  Blaketh
  mstone

volunteered [had their arms twisted] into running the 

  http://wiki.laptop.org/go/1_Hour_Smoke_Test 
  
on Update.1 702 with Spanish-language laptops when available and with
other languages as the opportunity arises. Installation instructions:

  http://wiki.laptop.org/go/Testing_Update.1

The purpose of this testing is to generate data that will help qualify
or disqualify Update.1-702's suitability to be our Update.1 release and
that will help us to improve the stub Update.1 release notes at:

  http://wiki.laptop.org/go/OLPC_Update.1_Software_Release_Notes

I have charged Simon Schampijer (erikos) with the task of cleaning and
collating information gleaned from this testing by ensuring that 
information makes its way into Trac and by preparing daily public status
reports describing the measurements that were made and what they
revealed. Please cooperate with him to the best of your ability.

Finally, if you were not able to attend the status meeting and would
like to assist in this testing effort but lack access to laptops, please
contact us on the mailing lists and we'll see if we can find some
loaners.

Michael

P.S. - A raw transcript of the meeting is available upon request.
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

Re: [sugar] Testing Update.1-702

[Simon Schampijer]

Michael Stone wrote:
> Dear everyone,
> 
> At today's software status meeting, several individuals, including:
> 
>   dgilmore
>   erikos
>   bemasc
>   Blaketh
>   mstone
> 
> volunteered [had their arms twisted] into running the 
> 
>   http://wiki.laptop.org/go/1_Hour_Smoke_Test 
>   
> on Update.1 702 with Spanish-language laptops when available and with
> other languages as the opportunity arises. Installation instructions:
> 
>   http://wiki.laptop.org/go/Testing_Update.1
> 
> The purpose of this testing is to generate data that will help qualify
> or disqualify Update.1-702's suitability to be our Update.1 release and
> that will help us to improve the stub Update.1 release notes at:
> 
>   http://wiki.laptop.org/go/OLPC_Update.1_Software_Release_Notes
> 
> I have charged Simon Schampijer (erikos) with the task of cleaning and
> collating information gleaned from this testing by ensuring that 
> information makes its way into Trac and by preparing daily public status
> reports describing the measurements that were made and what they
> revealed. Please cooperate with him to the best of your ability.

I have setup a simple wiki page where you can add some information 
(name, language you did the test in, Trac ticket numbers you entered 
information) about the smoke test you did. I hope this gives a rough 
estimation of how many tests have been made.

http://wiki.laptop.org/go/Testing_Update.1_Results

Thanks,
Simon
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar

[sugar] [Testing] Automated testing, OLPC, code+screencasts.

[Titus Brown]

Hi all,

I'm delurking with a vengeance here, I think :).

A few months ago I was invited to take an interest in the OLPC with
specific regard to testing; I've been involved with Python and testing
for a while, and someone asked Grig Gheorghiu and me to take a look at
the OLPC work to see if we could help out with the QA process.

For a variety of reasons (GHOP, and a baby, etc.) I didn't do much for a
while, but I had submitted a talk proposal about my (fictitious) OLPC
automated testing work to PyCon '08 and had to make good on the talk.
So I finally put into action a bit of the stuff I'd been thinking about.

If you want to skip the ranting and opinions you can go directly to my
last blog post, here,

   http://ivory.idyll.org/blog/mar-08/peekaboo-and-screencasts.html

where I show some screencasts of some simple Sugar GUI automation as
well as instrumentation of the Sugar GUI with code coverage analysis
using my 'figleaf' Python code coverage tool and 'peekaboo', a dynamic
code tracing tool.

The GUI automation was done with a simple twill-based domain specific
language wrapping xmacro, and it's very fragile.  But it does work.

You're welcome to all of this code, although it needs some serious
polishing.

Note that I'm working with a student (Zach Riggle) to submit a "testing
tools" GSoC application to the Python Software Foundation, with the aim
of making robust GUI driving and trace recording tools for the OLPC (and
other apps).

Other than that, I'm interested in figuring out how to encourage the
OLPC project to build some automated tests without doing it all myself
:).  Thoughts welcome.

Basically I think it's incredibly important for the OLPC to invest in
automated tests.

---

OK, now for the ranting and opinions, which are less polite, I offer up
the following posts (with one line summaries).

The OLPC is crazy and needs to test; and its community interactions
with Python are broken:
http://ivory.idyll.org/blog/mar-08/pycon-08-thoughts.html

My talk materials:
http://ivory.idyll.org/blog/mar-08/pycon-08-materials.html

Why I think automated testing is important, inspired by my OLPC
experience:
http://ivory.idyll.org/blog/mar-08/software-quality-death-spiral.html

And the above screencasts etc.:
http://ivory.idyll.org/blog/mar-08/peekaboo-and-screencasts.html

As you can guess from the "death spiral" post, I'm not terribly
interested in *debating* the usefulness of automated tests, and I don't
buy into the notion that GUI automation is impossible, either.  I would
very much like to try to introduce systematic and robust GUI testing
into the OLPC and I will be working towards that end as time and
resources permit.  Constructive comments and genuine interest are
welcome!

cheers,
--titus
-

Dr. C. Titus Brown, [EMAIL PROTECTED]
Asst Prof., Michigan State U.
http://ged.cse.msu.edu/
___
Testing mailing list
[EMAIL PROTECTED]
http://lists.laptop.org/listinfo/testing
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar