[Sugar-devel] Stepping down as Sugar maintainer

2013-01-06 Thread Sascha Silbe
Hello everyone,

I am stepping down as maintainer for Sugar and some related
services. This is mostly due to lack of time, but even if I had more of
that to spare for Sugar, the way I work is sufficiently different from
that of the most active contributors that I'd do more harm than good.

For some time now, my business didn't have any Sugar-related contract,
so as an entrepreneur I can't afford investing time, effort or money
into Sugar. My spare time is pretty limited these days and I tend to
spend what's left of it on reflecting, relaxing and some minor non-Sugar
projects, so even as a volunteer I can't spend much on Sugar.

However, I will continue using an XO as my primary laptop, so I may
contribute to some of the lower-level parts of the stack (powerd,
kernel, etc.) from time to time. I'll also continue working on some data
store stuff (gdatastore, datastore-fuse, etc.), but strictly outside of
Sugar as I wouldn't be able to hold your pace.

It's been exciting times working with you and I've learned a lot. But
now it's time to move on and let younger folks take over. That seems to
have worked fine the past few months; hopefully it'll work out in the
long run as well. This side of the ocean, my current customers have come
to appreciate the way I work. And taking Sundays off for relaxing and
reflecting, I'm much more at ease. So everyone is better off now.

So long and thanks for all the fish,
Sascha


pgpPCRduOsPHG.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


[Sugar-devel] [PATCH sugar] Add support for connecting to shared upstream network connections via Ad-hoc

2012-09-15 Thread Sascha Silbe
Before, Sugar implicitly assumed all ad-hoc networks are peer-to-peer,
using link-local addressing. However, unlike infrastructure mode
wireless networks, where there's a clear master node (the Access
Point) and for most networks the AP is providing DHCP  co for clients
to use, there's no such obvious model for Ad-hoc. Some networks, like
those set up by Sugar by default, are fully peer-to-peer and use
link-local addressing. Others are created by a master node, often
used to provide access to some upstream network (e.g. the
internet). Various other ways of organising an ad-hoc network are in
active development (e.g. B.A.T.M.A.N).

Since there's neither a predominant model nor a way to reliably
determine the model in use for a particular network before connecting
to it (and NetworkManager can't do the detection automatically
either), we need to use some kind of heuristic.

Two kinds of models can be guessed from the SSID with reasonable
accuracy:

1. The default Ad-hoc network channels create by Sugar by default
   (on channels 1, 3 and 11), being fully peer-to-peer and using
   link-local addressing. The SSID of these networks is Ad-hoc
   Network channel number.

2. Upstream network connections shared by Dextrose (and probably
   future Sugar upstream versions). These use an SSID of user name
   network.

For any other network, we'll try DHCP, just in case it's an ad-hoc
network created with nm-applet (Gnome).

Signed-off-by: Sascha Silbe si...@activitycentral.com
---
This is a cleaned-up version of a three-line patch we've been shipping
in Dextrose ever since the 3G sharing feature landed in 2010.


 src/jarabe/desktop/networkviews.py |   17 -
 src/jarabe/model/network.py|   22 ++
 2 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/src/jarabe/desktop/networkviews.py 
b/src/jarabe/desktop/networkviews.py
index c949b7e..52ebf68 100644
--- a/src/jarabe/desktop/networkviews.py
+++ b/src/jarabe/desktop/networkviews.py
@@ -357,7 +357,22 @@ class WirelessNetworkView(EventPulsingIcon):
 settings.wireless.mode = 'adhoc'
 settings.wireless.band = 'bg'
 settings.ip4_config = IP4Config()
-settings.ip4_config.method = 'link-local'
+if network.is_sugar_adhoc_network(self._ssid):
+# The 3 default Sugar ad-hoc channels are
+# peer-to-peer with link-local addressing.
+settings.ip4_config.method = 'link-local'
+elif network.is_sugar_shared_network(self._ssid):
+# Upstream connection shared by another computer
+# running Sugar. The sharer set up DHCP  co for us to
+# use.
+settings.ip4_config.method = 'auto'
+else:
+# We don't recognise the type of network. As a random
+# guess, try DHCP.
+# TODO: When support for falling back to link-local on
+# DHCP failure lands in upstream NetworkManager, we
+# should switch to that.
+settings.ip4_config.method = 'auto'
 
 wireless_security = self._get_security()
 settings.wireless_security = wireless_security
diff --git a/src/jarabe/model/network.py b/src/jarabe/model/network.py
index 930ba13..0f76631 100644
--- a/src/jarabe/model/network.py
+++ b/src/jarabe/model/network.py
@@ -330,15 +330,29 @@ def frequency_to_channel(frequency):
 
 
 def is_sugar_adhoc_network(ssid):
-Checks whether an access point is a sugar Ad-hoc network.
+Check whether an access point is a sugar Ad-hoc network.
+
+Return True if the network identified by ssid is likely to be a
+Sugar Ad-hoc network channel (peer-to-peer, using link-local
+addressing), or False otherwise.
 
 Keyword arguments:
-ssid -- Ssid of the access point.
+ssid -- SSID of the access point
+
+return ssid.startswith('Ad-hoc Network ')
+
 
-Return: Boolean
+def is_sugar_shared_network(ssid):
+Check whether the AP is sharing an upstream connection via Sugar
 
+Return True if the network identified by ssid is likely to be
+sharing an upstream network connection via Sugar, or False
+otherwise.
+
+Keyword arguments:
+ssid -- SSID of the access point
 
-return ssid.startswith('Ad-hoc Network')
+return ssid.endswith(' network')
 
 
 class WirelessSecurity(object):
-- 
1.7.10.4

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


Re: [Sugar-devel] Adventures in the land of ENOSPC

2012-09-15 Thread Sascha Silbe
Martin Langhoff martin.langh...@gmail.com writes:

 Manuel Kaufmann has been looking at SL#394, and looking at the bug
 report, it struck me that it was reported backwards. I would have
 written: I filled up my disk and it knocked the system out, Sugar
 would not start again, etc. Oh, btw, it was with Browse.

I agree. Every single mishandling of ENOSPC is a bug in the affected
piece of software and should be fixed. However, there's a lot of broken
software (including Sugar) out there that doesn't always do the right
thing, often resulting in data loss (because files are updated
in-place). And there will always be new software that's broken in this
regard. It's the responsibility of system designers to reduce the risk
of this happening by avoiding an ENOSPC situation wherever reasonably
possible.

Browse in particular is a very good candidate for avoiding
ENOSPC. Usually the user is not going to be interested in a partial
download and the file size is known in advance. It doesn't make sense to
even start a download we already know to never complete
successfully.

Similarly, the data store should take care to leave some free
space. Maybe even some heuristic that somehow rejects easy-to-regenerate
entries earlier than others, if we can come up with a good enough one.


[...]
 I artificially filled up / with dd until barely 1MB was remaining,
 then experimented with filling it up completely, then leaving a few K
 free and saving stuff.

Yes, I fully expect it to break left and right, like it always breaks in
situations that are somewhat on the side of the road. We only test the
good cases and a few failure scenarios the patch author thinks about
(if any). There are no systematic tests that cover the less common
failure modes. We don't even have a list of scenarios that we care
about. We don't do system design where these kinds of things are
considered.


[...]
  - Next boot, my Journal was gone. Actually, it's not gone, I can see
 the files in ~/.sugar/default/datastore, but it is corrupt or [...]

Sounds like SL#2317 [1], as Gonzalo already pointed out.

Sascha

[1] https://bugs.sugarlabs.org/ticket/2317
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgp5qvDGyJJgl.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [DESIGN] Views: search behavior

2012-08-28 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

 - if you did a search in View A and then switch to View B the search 
 from A will not be applied in B, if you switch back to A the search you 
 did before in A has been cached and is still applied (behavior before 
 0.97.2)

IMO this makes the most sense to the user. The three screens look
similar and it's important to share as much code as possible in the
implementation, but they still are separate entities to the user. Think
class vs. instance: they all behave in a similar way (class), but
they're not the same thing (instance).

PS: Thanks for your work on unifying the Zoom Views!

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgp9pf7p1PCTp.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [DESIGN] unfocus search entries in Views and the Journal

2012-08-21 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

 I would suggest the following new behavior:

 - the entry is unfocused by default, the canvas is focused

 - the entry contains a hint (e.g. Search in your Journal...), adding a 
 placeholder text is available in GTK+3.2 [2]

 - when the user starts typing the entry is focused automatically 
 (listening on the canvas and switching focus)

How will this interact with accessibility tools? Will they recognise
that text can be entered even though the entry isn't focused and will
they send keystrokes that get redirected to the search entry?

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgp2YwC9LSRYy.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH sugar] Frame: reveal Palette on left click for device, friends and clipboard items v2

2012-08-21 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

 As well the clipboard icons will reveal now the Palette on left
 click. This is also true when selecting a clipboard item. Technically we
 have to listen to the 'button-release-event' of the child widget
 as the RadioToolButton does only emit a clicked signal. Using this
 would colide with the state changes of the clipboard items as those
 emit a signal [1]. We do let the event propagate further
 (return False) so that the state change when selecting another
 item is picked up.
[...]

[src/jarabe/frame/clipboardicon.py]
 +def __button_release_event_cb(self, widget, event):
 +if event.button != 1:
 +return False
 +self.props.palette_invoker.notify_right_click()
 +return False

We should document why we are returning False here, as explained in the
commit message.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpatTiAi6wFR.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Maintenance, reviews, QA co

2012-08-21 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

 VI.  Accept patches into mainline that are likely to increase the number
   of contributors using Sugar themselves (A) or to increase their
   usage of Sugar, even if the patch doesn't directly benefit the XO
   target user base. It should not have a negative impact on the XO
   target user base, of course. This addresses goals 2, 3, 4 and 5.

 When we setup SugarLabs the goal was to make Sugar available on other 
 platforms like the XO. This goal is still the case.

I'm talking about the target audience, not the hardware platform. The
question is whether to accept patches that most school children [1]
neither have a use for (i.e. no direct positive impact on them) nor get
in their way (i.e. no negative impact either).


 VII. Work on making Sugar more modular, using upstream components and
   standard protocols or APIs as much as possible (L), allowing users
   to mix and match components or simply configure them differently
   (A) and reducing the footprint of bugs. This addresses goals 2, 3,
   4 and 5.

 Using standards and upstream components has been a goal as well. So we 
 just have to continue that road.

So I can push the window manager related fixes [2,3] I posted last year?


 The two major changes are making in-depth reviews by senior developers
 optional and non-blocking (II.)

 But require public short reviews by some senior developer, correct?

Yes, that's III.


 as well as accepting no ceiling (VI.) and standards compliance
 (VII.) patches.

 But modularity comes at a cost. This should be decided on a case per 
 case basis.

Not being modular usually comes at an even higher cost in the long
run. Changes affect a larger part of functionality, requiring more
extensive testing and increasing the baseline of user-visible bugs. It
also reduces flexibility, preventing the user from choosing different
components that better fit their need. Right now, Sugar is essentially
all-or-nothing. You either use Sugar, or you can choose between and mix
a wide variety of other components. You can either launch Sugar (and
quit Gnome) or launch Gnome (and quit Sugar), not mix them to have the
best of both worlds.

Similarly, not being standards compliant will come back to bite you
sooner or later. It may work with the exact versions you tested with,
but any update of software we rely on can suddenly break the system in
unexpected ways. It also increases the costs of switching components,
like the matchbox to metacity change that created a lot of fallout.

Sascha

[1] 
http://wiki.laptop.org/go/Our_market#Child_is_a_nebulous_term.3B_what_is_the_exact_age_range_you_are_targeting.3F
[2] https://patchwork.sugarlabs.org/patch/826/
[3] https://patchwork.sugarlabs.org/patch/827/
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgp9KVaAmj5xE.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [REMINDER] Development team meeting --- 21 August 2012 (15:00 UTC)

2012-08-21 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

 - your item here

- review process and code acceptance policy [1]

Sascha

[1] message-id:toek3x5b15n@mimosa.sascha.silbe.org

https://lists.sugarlabs.org/archive/sugar-devel/2012-August/thread.html#38893
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpuiI2Hcu5nw.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH sugar] Example objects support

2012-08-21 Thread Sascha Silbe
Martin Abente Lahaye martin.abente.lah...@gmail.com writes:

[src/jarabe/journal/volumestoolbar.py]
[_set_up_activities_examples()]
[...]
 +activities = []
 +for home_activity in home_model._activities:
 +if home_activity.is_journal():
 +continue
 +
 +activity_name = home_activity.get_activity_name()
 +if activity_name not in activities:
 +self._add_activity_example(home_activity)
 +activities.append(activity_name)

I wonder if using a dictionary for deduplication would be better
here. E.g.:

activities = dict([(home_activity.get_activity_name(), home_activity)
   for home_activity in home_model])
for home_activity in activities.values():
self._add_activity_examples(home_activity)


Alternatively, you could just iterate over all entries and let
_add_activity_examples() take care of deduplication (as it has to do
anyway), at the risk of making it O(n²).


 +def _proper_occurrence(self, home_activity):

What's a proper occurrence?

 +if home_activity.is_journal():
 +return False
 +
 +home_model = shell.get_model()
 +act_name = home_activity.get_activity_name()
 +activities = filter(lambda act: act_name == act.get_activity_name(),
 +home_model._activities)
 +
 +return len(activities) = 1

I assume this is for deduplication again. The easiest and fastest way
overall (O(1) per iteration [1], O(n) in total) is probably a
ref-counting scheme:

def __init__(self, ...):
# ...the usual stuff...

self._activity_counts = {}
self._example_buttons = {}
for home_activity in home_model:
self._add_activity(home_activity)

def _add_activity(self, home_activity):
Keep track of an active activity session

Keep track of an active activity session and add the examples
folder if available and not already shown.

name = home_activity.get_activity_name()
old_count = self._activity_counts.get(name, 0)
self._activity_counts[name] = old_count + 1
if old_count:
return

# ...create button...

self._example_buttons[name] = example_button

def _remove_activity(self, home_activity):
Stop keeping track of an active activity session

Remove all internal references to this session. Remove the
corresponding examples folder if it's the last instance of
this activity.

name = home_activity.get_activity_name()
old_count = self._activity_counts[name]
self._activity_counts[name] = old_count - 1
if old_count  1:
return

example_button = self._example_buttons.pop(name)

# ...remove button...



 +def _add_activity_example(self, home_activity):
 +examples_path = os.path.join(home_activity.get_bundle_path(),
 +'examples')
 +
 +if not os.path.exists(examples_path):
 +return

If you add a guard against home_activity.get_bundle_path() returning
None, you can drop the special-casing for the Journal activity.


Sascha

[1] http://wiki.python.org/moin/TimeComplexity#dict
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpQep1f2ZmWD.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [HELP] Shell port to GTK3+: Removing hardcoded styles-- facing issue

2012-08-10 Thread Sascha Silbe
Kartik Kumar kartik.p...@gmail.com writes:

 Then I made changes to aboutcomputer/view.py to load the CSS: (changes are
 highlighted in bold):

Diffs are usually easier to read, especially in MUAs that don't render
font attributes for HTML mails. If you want all of the previous code to
be included in the diff, you can just give a sufficiently larger number
to the -U option of git diff. I'll include an example below.


 from sugar.graphics import style

The sugar Python package is provided by the pyGTK + GTK2 based sugar-toolkit
package. If you want to use gobject introspection + GTK3, you need to
use the sugar3 Python package which is provided by the
sugar-toolkit-gtk3 package.


 if USE_LOCAL_CSS:
 css_provider = GTK.CssProvider()
 css_provcss_provider.load_from_path('sugar-theme.css')
 context = GTK.StyleContext()
 context.add_provider_for_screen(screen, css_provider,
 GTK.STYLE_PROVIDER_PRIORITY_USER)*

Where does screen get defined? Do we need to load the theme from inside
each widget or can we do it once for an entire process?


sascha.silbe@twin:~/sugar-jhbuild/source/sugar$ git diff -U13
diff --git i/extensions/cpsection/aboutcomputer/view.py 
w/extensions/cpsection/aboutcomputer/view.py
index 6b16005..b011b37 100644
--- i/extensions/cpsection/aboutcomputer/view.py
+++ w/extensions/cpsection/aboutcomputer/view.py
@@ -8,59 +8,70 @@
 # (at your option) any later version.
 #
 # This program is distributed in the hope that it will be useful,
 # but WITHOUT ANY WARRANTY; without even the implied warranty of
 # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
 # along with this program; if not, write to the Free Software
 # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301 USA
 
 from gettext import gettext as _
 
-import gtk
+#import gtk
+from gi.repository import GTK
 
 from sugar.graphics import style
 
 from jarabe import config
 from jarabe.controlpanel.sectionview import SectionView
 
 
+USE_LOCAL_CSS = True
+
+
 class AboutComputer(SectionView):
 def __init__(self, model, alerts=None):
 SectionView.__init__(self)
 
 self._model = model
 
 self.set_border_width(style.DEFAULT_SPACING * 2)
 self.set_spacing(style.DEFAULT_SPACING)
 
 self._group = gtk.SizeGroup(gtk.SIZE_GROUP_HORIZONTAL)
 
 scrollwindow = gtk.ScrolledWindow()
 scrollwindow.set_policy(gtk.POLICY_NEVER, gtk.POLICY_AUTOMATIC)
 self.pack_start(scrollwindow, expand=True)
 scrollwindow.show()
 
 self._vbox = gtk.VBox()
 scrollwindow.add_with_viewport(self._vbox)
 self._vbox.show()
 
 self._setup_identity()
 
 self._setup_software()
 self._setup_copyright()
 
+if USE_LOCAL_CSS:
+css_provider = GTK.CssProvider()
+css_provcss_provider.load_from_path('sugar-theme.css')
+context = GTK.StyleContext()
+context.add_provider_for_screen(screen, css_provider,
+GTK.STYLE_PROVIDER_PRIORITY_USER)
+
 def _setup_identity(self):
 separator_identity = gtk.HSeparator()
 self._vbox.pack_start(separator_identity, expand=False)
 separator_identity.show()
 
 label_identity = gtk.Label(_('Identity'))
 label_identity.set_alignment(0, 0)
 self._vbox.pack_start(label_identity, expand=False)
 label_identity.show()
 vbox_identity = gtk.VBox()
 vbox_identity.set_border_width(style.DEFAULT_SPACING * 2)
 vbox_identity.set_spacing(style.DEFAULT_SPACING)
 

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpHnVkITzK5X.pgp
Description: PGP signature
___
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 si...@activitycentral.com
---
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 jvo...@shaw.ca.

Signed-off-by: Sascha Silbe si...@activitycentral.com
---
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__

[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 si...@activitycentral.com
---
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

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

2012-08-06 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

 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.
[...]

This is fine from my side, but as discussed during the Development Team
meeting a few weeks ago, I'd like Benjamin (CC'ed) to have a look at it
to make sure there are no (obvious) problems with the approach that will
cause significant trouble further down the road.

If Benjamin doesn't have time to do the review, I'll just accept the
patch as-is.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpUOOSkaLM6z.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH sugar 2/7] ControlPanel AboutMe section: use the EventIcon from the shell

2012-08-06 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

 We had a similar implmentation of the EventIcon in this section, now
 we can reuse the one from the shell.

Once the EventIcon patch has been merged:

Acked-by: Sascha Silbe si...@activitycentral.com

Thanks for the clean-up!

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgppUjK8I4xx5.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH sugar 6/7] Remove hippo mentions

2012-08-06 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

 From: Daniel Narvaez dwnarv...@gmail.com

 This is probably all very outdated anyway.

It's not even clear to me what the file is about. Is it a TODO list, a
specification, documentation of current behaviour, ...? So +1 from me
for simply dropping the file.

In case we decide to keep the file for some reason:

Acked-by: Sascha Silbe si...@activitycentral.com

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpvzWTpZ4aUc.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH sugar 7/7] Drop unused intro.py

2012-08-06 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

 From: Daniel Narvaez dwnarv...@gmail.com

 It was moved inside jarabe and ported to GTK+.

This file should be removed in the same patch that added the code to
jarabe, so that the code movement can easily be tracked and the actual
code changes be examined.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpdiSSh9Q9Z2.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH sugar 5/7] Move SpreadLayout logic to favoriteslayout.py

2012-08-06 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

 From: Daniel Narvaez dwnarv...@gmail.com

 The SpreadLayout derives now from the ViewLayout. The ViewLayout
 has a grid by default and the allocation happens here as well.

I don't see any code moves in this patch, just removal. Like for Drop
unused intro.py (7/7), the removal should happen in the same patch that
adds the codes elsewhere, so that we can follow the code movement.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgprMBvUnksFQ.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH sugar 0/7] Remove last hippo occurrences from the shell

2012-08-06 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

 This is a patch series to make the Sugar shell hippo free. Based on the
 work that has been done in [1] and [2]. It incorporates the patch from
 Sascha to move the EventIcon into the shell temporary. 
[...]

Thanks for the patch series and especially for the detailed
descriptions, they are rather helpful!

One thing I noticed while working on the UI tests (or rather the
prerequisite, making Sugar accessible): The Owner Icon is the _last_
entry in the list, at least for the Home View. Can we make it the first
one instead (without going to great lengths)?

With the version I tested, there was also some issue with positioning;
IIRC the Owner Icon was off-center. Has this been fixed? Are there any
(other) known bugs?

I've discussed the approach for both the hippo removal series and the
GTK3 port with a couple of community members over the past few weeks and
we agreed that we should focus on the architecture (i.e. external API,
internal API, interactions with other components / APIs) and work
towards merging the patches sooner rather than later. We fully expect
there to be major bugs, but by merging early we enable a) widespread
manual testing and b) development of automated UI tests that can verify
the GTK3 port against the current behaviour of the GTK2 version. Unless
we can't solve a number of technical issues [1] with accessibility
support, my plan would be to do things in this order:

1. Merge hippo removal patch series.
2. Finish and merge accessibility patch series. It should be complete
   enough to test all major parts of the UI. Accessibility support for
   humans (e.g. using screen readers) is only a side effect at this
   stage, not a goal. Help with this effort (especially fixing the
   current blockers [1]) would be quite appreciated.
3a. Develop a UI test suite based on the latest GTK2 version of Sugar.
3b. Finish and merge GTK3 port.

3a. and 3b. can happen in parallel.

Caspar and me would still review the patches and make a couple of
suggestions where the patches can be _easily_ improved, but in general
we'd focus on the interfaces rather than the implementation.

Would that work for you?

Sascha

[1] message-id:toeehnrlhad@twin.sascha.silbe.org

https://mail.gnome.org/archives/gnome-accessibility-list/2012-July/msg00029.html
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpU3QHJvpLsY.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH sugar 3/7] Views: Replace the hippo based layout with one using GTK+ containers

2012-08-06 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

[...]
  src/jarabe/desktop/transitionbox.py   |  50 +
  src/jarabe/journal/detailview.py  |  73 +++
[...]

[src/jarabe/desktop/Makefile.am]
 @@ -15,4 +15,5 @@ sugar_PYTHON =  \
  schoolserver.py  \
   snowflakelayout.py  \
   spreadlayout.py \
 - transitionbox.py
 + transitionbox.py\
 + viewcontainer.py

viewcontainer.py is missing from this patch. Noticed while trying to
test the series with Benjamin's suggested change.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpTwkWieR26n.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH sugar 7/7] Drop unused intro.py

2012-08-06 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

[src/intro/intro.py]
 It has been moved a long time ago, outside this patch series. I guess 
 Daniel came across this when grepping for hippo.

OK. Please mention in the commit message that it has been unused since
1f91f7f7afd34143721ac66936546e950369.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpl3abz2jn0A.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Help activity future

2012-07-30 Thread Sascha Silbe
Gonzalo Odiard gonz...@laptop.org writes:

 I was looking at Mallard, but I didn't wanted impose over the people
 writing the content, the charge of learning a new markup.

 For us, is difficult found people available to write the content,
 (the last full manual is from Sugar 0.82)
 then, I think we should try to get the help written, and later,
 we can see and translate to other markup if is useful.

Exactly. The best format is of no use when there's no content. Let those
who are willing to contribute documentation choose the format (as long
as it's an open format at least, i.e. no .docx or similar). When we
actually have the documentation, we can discuss how to get it into
something useful for distribution (including translation) and further
editing. As long as the input is structured well enough, we can come up
with some way to convert it.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgp3TegUP3bod.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] How to have CellRenderer.props take effect, without a UI refresh?

2012-07-30 Thread Sascha Silbe
Ajay Garg a...@activitycentral.com writes:

 [adding short-circuit logic to
 jarabe.journal.listview.BaseListView.refresh()]
[...]
 What we should do is enhancing the logic to

 a) just redraw instead of querying the back-end again for changes we
triggered ourselves and / or
 b) update our model based on the change notifications rather than
throwing away our state.


 Well, that's exactly what I did, via the patch
 http://git.sugarlabs.org/dextrose/mainline/commit/ad3897946e013f1ff4020aeab35375ccb122758b

Not really AFAICT. You're still inhibiting the refresh completely,
without doing a redraw. You're also doing a gratuitous data store query
for each favourite star. I'm expecting that to have considerable impact
on performance.


 I guess, if we could somehow cause the mouse to PROGRAMMATICALLY
 hover-away/disappear-momentarily when the star/favorite-icon is clicked, we
 could be done.
 However, I am not able to find a way to do this via pygtk.

Fortunately. :-P

As discussed on IRC, the way to _trigger_ _a_ _redraw_ (not: move the
pointer) is something like this:

x_, y_, width, height = self.allocation
area = (0, 0, width, height)
self.window.invalidate_rect(area, False)


Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpkGEtFdwIpJ.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] How to have CellRenderer.props take effect, without a UI refresh?

2012-07-24 Thread Sascha Silbe
Ajay Garg a...@activitycentral.com writes:

 This piece of code works as expected, and the toggling-UI-effect takes
 place as soon as the star/favorite-icon is clicked (that is, the
 mouse-pointer need not be hovered away).
 But note that, there is listview-refresh involved after each toggling of
 the star/favorite-icon.

What exactly do you mean by listview-refresh? Do you mean a) a redraw
of the current content or b) some operation that causes us to query the
data store (or file system)?


 If the listview-refresh is inhibited, the toggling-UI-effect does take
 place, but ONLY AFTER the mouse-pointer is hovered away from the
 star/favorite-icon.

What exactly do you mean by listview-refresh is inhibited? How did you
inhibit it?

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpwipKY9Pam9.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] How to have CellRenderer.props take effect, without a UI refresh?

2012-07-24 Thread Sascha Silbe
Ajay Garg a...@activitycentral.com writes:

[toggling favourite star causes a listview-refresh]
 What exactly do you mean by listview-refresh? Do you mean a) a redraw
 of the current content or b) some operation that causes us to query the
 data store (or file system)?

 By refresh, I mean to say that the data store is re-queried.

OK. We should try to avoid that; see below.


 More clearly, I changed the code (in src/jarabe/journal/listview) from ::
[adding short-circuit logic to jarabe.journal.listview.BaseListView.refresh()]

Well, if you inhibit our current way of refreshing the view, it's kind
of expected that it doesn't work anymore. ;)

What we should do is enhancing the logic to

a) just redraw instead of querying the back-end again for changes we
   triggered ourselves and / or
b) update our model based on the change notifications rather than
   throwing away our state.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpHNxELo7S95.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


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

2012-07-24 Thread Sascha Silbe
From: Simon Schampijer si...@schampijer.de

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 si...@laptop.org
[moved from sugar-toolkit to sugar]
Signed-off-by: Sascha Silbe si...@activitycentral.com

[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/eventicon.py |  277 ++
 1 file changed, 277 insertions(+)
 create mode 100644 src/jarabe/view/eventicon.py

diff --git a/src/jarabe/view/eventicon.py b/src/jarabe/view/eventicon.py
new file mode 100644
index 000..4166798
--- /dev/null
+++ b/src/jarabe/view/eventicon.py
@@ -0,0 +1,277 @@
+# Copyright (C) 2012, 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 gobject
+import gtk
+
+from sugar.graphics import style
+from sugar.graphics.icon import _IconBuffer
+from sugar.graphics.palette import Palette
+from sugar.graphics.palettewindow import Invoker
+
+
+class CursorInvoker(Invoker):
+
+def __init__(self, parent=None):
+Invoker.__init__(self)
+
+self._position_hint = self.AT_CURSOR
+self._enter_hid = None
+self._leave_hid = None
+self._release_hid = None
+self._item = None
+
+if parent:
+self.attach(parent)
+
+def attach(self, parent):
+Invoker.attach(self, parent)
+
+self._item = parent
+self._enter_hid = self._item.connect('enter-notify-event',
+ self.__enter_notify_event_cb)
+self._leave_hid = self._item.connect('leave-notify-event',
+ self.__leave_notify_event_cb)
+self._release_hid = self._item.connect('button-release-event',
+   self.__button_release_event_cb)
+
+def detach(self):
+Invoker.detach(self)
+self._item.disconnect(self._enter_hid)
+self._item.disconnect(self._leave_hid)
+self._item.disconnect(self._release_hid)
+
+def get_default_position(self):
+return self.AT_CURSOR
+
+def get_rect(self):
+window = self._item.get_window()
+allocation = self._item.get_allocation()
+rect = Gdk.Rectangle()
+rect.x, rect.y = window.get_root_coords(allocation.x, allocation.y)
+rect.width = allocation.width
+rect.height = allocation.height
+return rect
+
+def __enter_notify_event_cb(self, button, event):
+self.notify_mouse_enter()
+return False
+
+def __leave_notify_event_cb(self, button, event):
+self.notify_mouse_leave()
+return False
+
+def __button_release_event_cb(self, button, event):
+if event.button == 3:
+self.notify_right_click()
+return True
+else:
+return False
+
+def get_toplevel(self):
+return self._item.get_toplevel()
+
+
+class EventIcon(gtk.EventBox):
+
+__gtype_name__ = 'SugarEventIcon'
+
+def __init__(self, **kwargs):
+self._buffer = _IconBuffer()
+self._alpha = 1.0
+
+gtk.EventBox.__init__(self)
+for key, value in kwargs.iteritems():
+self.set_property(key, value)
+
+self._palette_invoker = CursorInvoker()
+self

[Sugar-devel] [PATCH sugar 0/2] Move EventIcon to sugar

2012-07-24 Thread Sascha Silbe
As agreed on during the Development Team meeting [1], the EventIcon
needed for the hippo-canvas removal project should be merged into
sugar, rather than sugar-toolkit. This patch series adds the icon to
sugar and modifies the code from the current working branch [2] of the
hippo-canvas removal project to make use of this private copy so that
it works with mainline sugar-toolkit.

The second patch (switching to the private implementation) should be
squashed into the other patches presented for review on sugar-devel,
rather than as a separate patch. It's a modification of the approach
taken by the hippo-canvas removal project, not a change to sugar.


Sascha Silbe (1):
  Switch to private implementation of EventIcon

Simon Schampijer (1):
  SugarEventIcon: Add a hippo-free implementation of the CanvasIcon

 extensions/cpsection/aboutme/view.py |3 +-
 src/jarabe/desktop/favoritesview.py  |2 +-
 src/jarabe/desktop/friendview.py |2 +-
 src/jarabe/desktop/groupbox.py   |2 +-
 src/jarabe/desktop/meshbox.py|2 +-
 src/jarabe/journal/expandedentry.py  |2 +-
 src/jarabe/journal/listview.py   |3 +-
 src/jarabe/view/Makefile.am  |1 +
 src/jarabe/view/buddyicon.py |3 +-
 src/jarabe/view/eventicon.py |  277 ++
 src/jarabe/view/pulsingicon.py   |5 +-
 11 files changed, 293 insertions(+), 9 deletions(-)
 create mode 100644 src/jarabe/view/eventicon.py

[1] http://meeting.sugarlabs.org/sugar-meeting/meetings/2012-06-26
[2] http://git.sugarlabs.org/~erikos/sugar/erikos-shell-port
-- 
1.7.10

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


Re: [Sugar-devel] GSM string question

2012-07-16 Thread Sascha Silbe
Chris Leonard cjlhomeaddr...@gmail.com writes:

 Can someone please explain the purpose of these GSM strings?

 In Sugar 0.94, they did *NOT* say (DEPRECATED/UNUSED), but in Sugar
 0.96 and Sugar 0.97, they say (DEPRECATED/UNUSED)

 If they are really deprecated or unused, why are we still carrying
 them in the UI?

They are used in the description of the GConf entries for Sugar. On the
first start of Sugar 0.96+, the content of these entries will be used to
create a system-wide connection in NetworkManager 0.9. Changes to the
values in GConf after the first start of Sugar 0.96 will be
ignored. Users / administrators who previously modified the GConf
content directly (instead of going through the Sugar UI) should now
modify the connection in NetworkManager.

I'm happy to accept a patch to clarify the wording. We should still keep
the description around for those upgrading from Sugar up to 0.94
to Sugar 0.98+, skipping Sugar 0.96 in the process.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpMmyUybxphs.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [ANNOUNCE] Design meeting Wednesday July 18th 2012 - 15:00 UTC 1hr

2012-07-16 Thread Sascha Silbe
Gary C Martin garycmar...@googlemail.com writes:

 It's time to start reviving the IRC Design Meetings for the next Sugar
 release cycle!

Thanks for restarting the Design Team meetings!


[...]
 Time: Wednesday July 18th 2012 - 15:00 UTC for 1hr
 Place: #sugar-meeting

Unfortunately, I'm unavailable on Wed+Thu (always, not just this
week). Is there any chance of re-scheduling to a different day of the
week? Mon or Tue would be best, but anything other than Wed or Thu would
work.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpLbKaluMT61.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Enable gnome-keyring to autostart in sugar-emulator

2012-07-05 Thread Sascha Silbe
Gonzalo Odiard gonz...@laptop.org writes:

 Why is

 Signed-off-by: Caspar Bothmer cas...@activitycentral.com

 if the patch was done by Daniel?

Because Caspar changed the patch. See the kernel patch submission guide
[1], section 12) Sign your work:

 [...] Rule (b) allows you to adjust the code, but then it is very
 impolite to change one submitter's code and make him endorse your
 bugs. To solve this problem, it is recommended that you add a line
 between the last Signed-off-by header and yours, indicating the
 nature of your changes.


It looks odd in this case because Daniel didn't sign off his own
patch. The kernel maintainers simply wouldn't accept a patch that isn't
signed off by the author, but as even Daniel Drake's and Simon's patches
aren't always signed off, I can't really enforce that rule for other
Sugar contributors.

Sascha

[1] https://www.kernel.org/doc/Documentation/SubmittingPatches
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpMLfigKyJPK.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH sugar] Drop the sugar-ui-check script

2012-07-05 Thread Sascha Silbe
Daniel Narvaez dwnarv...@gmail.com writes:

 Subject: Re: [Sugar-devel] [PATCH sugar] Drop the sugar-ui-check script
 From: Daniel Narvaez dwnarv...@gmail.com

 This was used by the old buildbot implementation. Now it's unused
 and it's not working anymore anyway.

Thanks for the patch! Pushed with slightly modified description as
db5623e [1] to master. This doesn't have any effect on the system, so no
need to push to the stable branch.

Sascha

[1] 
http://git.sugarlabs.org/sugar/mainline/commit/db5623ea948da5477e306cb54e766423b9bf0ea3
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpDixP6AIe1h.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Enable gnome-keyring to autostart in sugar-emulator

2012-07-04 Thread Sascha Silbe
Daniel Narvaez dwnarv...@gmail.com writes:

 Thanks. Can you please push the patch with updated log?

We will do that today. Thanks again for the patch and for your
patience. This change wasn't quite as simple as it looks; it took us
some time to understand the root cause of the bug and sorting out the
details (we thought we did the first time, but realised later there were
some inconsistencies in our theory). I hope we covered enough of that in
the commit message while still leaving out those parts that are outside
of Sugar's domain (like how gnome-keyring-daemon works internally).

If there's any detail that anyone would like to know about, please ask
now, while it's fresh in our memories.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgp76WLXpcdvZ.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Enable gnome-keyring to autostart in sugar-emulator

2012-07-04 Thread Sascha Silbe
Daniel Narvaez dwnarv...@gmail.com writes:

 Thanks. Can you please push the patch with updated log?

Pushed as f0ee9e9 [1] to master. AFAIK (and the commit message doesn't
state the opposite), it doesn't fix any user-visible issue, so I haven't
pushed to the stable branch (sucrose-0.96).

Sascha

[1] 
http://git.sugarlabs.org/sugar/mainline/commit/f0ee9e9fae87fe54e8bd59244b012a2aba23131f
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpeoVk9lSDIs.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


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

2012-07-03 Thread Sascha Silbe
Daniel Drake d...@laptop.org writes:

[...]
 However, as of Telepathy-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.

Ah, reading the quote carefully, it's clear that the version number
applies to the specification. It would be nice to adjust the
introductory sentence to reflect that (e.g. as of Telepathy
specification 0.24.0).


[...]
[src/sugar/presence/activity.py]
 @@ -43,6 +43,7 @@ from sugar.presence.buddy import Buddy
  
  CONN_INTERFACE_ACTIVITY_PROPERTIES = 
 'org.laptop.Telepathy.ActivityProperties'
  CONN_INTERFACE_BUDDY_INFO = 'org.laptop.Telepathy.BuddyInfo'
 +CONN_INTERFACE_ROOM_CONFIG = 
 'org.freedesktop.Telepathy.Channel.Interface.RoomConfig1'

This line is too long. According to the PEP-8 indentation
recommendations [1], I would suggest:

CONN_INTERFACE_ROOM_CONFIG = \
'org.freedesktop.Telepathy.Channel.Interface.RoomConfig1'

 @@ -675,13 +676,47 @@ class _JoinCommand(_BaseCommand):
  self_handle = self._global_self_handle
  
  if self_handle in added:

Since there's nothing else in this function that gets run if the
condition is False, it would make the code easier to read if we
converted this to guardian style. I.e.:

 if self_handle not in added:
return


 -if PROPERTIES_INTERFACE not in self.text_channel:
 -self._finished = True
 -self.emit('finished', None)
 -else:
 +# Use RoomConfig1 to configure the text channel. If this
 +# doesn't exist, fall-back on old-style PROPERTIES_INTERFACE.
 +if CONN_INTERFACE_ROOM_CONFIG in self.text_channel:
 +self.__update_room_config()
 +elif PROPERTIES_INTERFACE in self.text_channel:
  self.text_channel[PROPERTIES_INTERFACE].ListProperties(
  reply_handler=self.__list_properties_cb,
  error_handler=self.__error_handler_cb)
 +else:
 +self._finished = True
 +self.emit('finished', None)

It seems the if/elif blocks and the else block now handle cases that are
different in nature. While if block vs. elif block distinguishes between
the versions of Telepathy in use, if/elif blocks vs. else block
seems to distinguish between different stages of the protocol. That's
fine, but a comment explaining the latter check would make this code
block easier to understand.


 +def __update_room_config(self):
 +# FIXME: invite-only ought to be set on private activities; but
 +# since only the owner can change invite-only, that would break
 +# activity scope changes.
 +props = {
 +# otherwise buddy resolution breaks
 +'Anonymous': False,
 +# anyone who knows about the channel can join
 +'InviteOnly': False,
 +# vanish when there are no members
 +'Persistent': False,
 +# don't appear in server room lists
 +'Private': True,
 +}

This part seems to be a direct copy of the corresponding block in
__list_properties_cb(). How about factoring it out into a class
constant?


[...]
 +def __room_cfg_error_cb(self, error):
 +# If RoomConfig update fails, it's probably because we don't have
 +# permission (e.g. we are not the session initiator). Thats OK -
 +# ignore the failure and carry on.
 +self._finished = True
 +self.emit('finished', None)

Would it be possible to check the error and log it if it doesn't match
our expectations (i.e. permission denied)?


Otherwise the patch is looking good, thanks!

Sascha

[1] http://www.python.org/dev/peps/pep-0008/#id12
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpEbdrNhjSjc.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


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

2012-07-03 Thread Sascha Silbe
Daniel Drake d...@laptop.org writes:

 On Tue, Jul 3, 2012 at 8:04 AM, Sascha Silbe si...@activitycentral.com 
 wrote:
 It seems the if/elif blocks and the else block now handle cases that are
 different in nature. While if block vs. elif block distinguishes between
 the versions of Telepathy in use, if/elif blocks vs. else block
 seems to distinguish between different stages of the protocol. That's
 fine, but a comment explaining the latter check would make this code
 block easier to understand.

 I don't think its related to different stages in the protocol, but I
 don't know a huge amount on this topic. Can you point me towards what
 makes you think this so that I can write a good comment?

It's just what it looked like to me. If it isn't, a comment would be
even more important. So if you can figure out why we're doing this,
please add a corresponding note in the code. If you can't, please add a
FIXME. Code that we don't understand is likely to cause trouble in the
future.


 This part seems to be a direct copy of the corresponding block in
 __list_properties_cb(). How about factoring it out into a class
 constant?

 It's not a direct copy - the names are different, as are the set of
 properties (mentioned in commit message).

You're right, I didn't look carefully enough.


 I'll address the other comments, thanks.

Thanks! I expect your next patch to be good enough, so here's my

Acked-by: Sascha Silbe si...@activitycentral.com

However, please send the final patch to the list before pushing.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpqtvttS9Jh3.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] test automation

2012-07-02 Thread Sascha Silbe
Sridhar Dhanapalan srid...@laptop.org.au writes:

 I am keen to explore ways to improve the quality and delivery time of
 code. Is there any work being done to automate testing of code?

Yes, I've been working on this whenever I have time. We already have
a data store test suite [3-5] and a semi-automated set of tests for the
WLAN part of our NetworkManager UI (Neighbourhood, Frame).

The remainder of this mail will focus on UI tests for Sugar (and
Activities). The public D-Bus API for Sugar is quite limited; the
datastore test suite already covers the important part. Most of the rest
should be replaced by other protocols that have since been agreed on by
other desktop environments. We could test the public (Python) API
provided by sugar-toolkit, but I haven't looked yet into that yet. There
may be some promising targets in the non-UI part of sugar-toolkit
(e.g. the Activity / Journal / Journal Entry Bundle related
code). However, automated UI tests would exercise at least some of the
more commonly used code paths in sugar-toolkit.

The basic framework for Sugar UI tests is available [6], but not of much
use with current upstream Sugar. There are two problems:

1. Ensuring the accessibility helpers are running.

   The test suite already enables them, but they need to actually get
   started. This is done automatically by the upstream version of
   gnome-session, but sugar-toolkit ships an ancient copy that won't
   start the helpers. Starting them manually was problematic. For this
   reason (in addition to generally being a good idea), I've ported
   Sugar over to upstream gnome-session. Upstream now provides [7] API
   to run alternative (i.e. non-Gnome) sessions. A WIP patch for using
   the new API is available [8] in my sugar clone on git.sl.o. The
   remaining blockers are the Shutdown and Reboot actions. Upstream
   gnome-session currently doesn't [9] provide API to trigger shutdown
   or reboot from outside of gnome-session, either without showing a
   dialog (for shutdown) or at all (for reboot). I've cleaned up a patch
   for this recently in the hope of pushing it forwards (the RFE was
   filed over three years ago), but upstream doesn't seem interested in
   it.

   The systemd support landed in sugar-toolkit doesn't help with this,
   BTW. It's used with our own copy of gnome-session and will be called
   after we already did the session part, closing all activities. With
   upstream gnome-session, we wouldn't get that chance (nor need to, if
   upstream just added the two small functions we need).


2. The Zoom Views (i.e. Home View, Group View, Neighbourhood) and the
   Journal are based on hippo-canvas, which doesn't support the
   GTK/Gnome accessibility framework. This means pretty much all of the
   core functionality isn't testable by this approach, either because it
   uses hippo-canvas or because it can only be triggered via some other
   part of the UI that uses hippo-canvas.

   This has been the major blocker for a long time. However, Simon
   recently ported sugar from hippo-canvas to plain GTK (thanks a lot,
   Simon!) as a milestone of the GTK3 migration and during the last
   Development Team meeting [10] we agreed on a plan that enables us to
   make use this intermediate result in upstream Sugar. I still haven't
   seen the cleaned-up patches, but Caspar and me talked about it
   extensively last weekend and we may simply accept the patches with
   only minor cleanups. We'd fully expect major bugs, but the hope is
   that a) the accumulated amount of manual testing (we're early in the
   development cycle for 0.98) and b) the ability to write automated
   tests would more than offset this risk. If we start right away, we
   might even have some simple test cases during the GTK3 migration,
   speeding up testing each individual change and thus the entire
   development phase. And once we have automated tests, we can more
   confidently clean up the current Zoom Views related code. The Views
   all pretty much provide the same functionality in terms of layout,
   but they're doing it in different ways. A single (set of) base
   class(es) used by all Zoom Views would help a lot to make the code
   more manageable and prevent Zoom View specific bugs. Like the
   GTK2→GTK3 migration, this is a major change. But with sufficient test
   coverage, the risk is low.


 We recently had some university students working with us to create an
 activity [1], and they were using the Robot Framework [2].

For activities, we're in a much better shape because virtually none of
them use hippo-canvas. With some glue, you may be able to start right
away - as your students apparently have done. I'd be quite interested in
their usage of the Robot Framework, as I've taken a look at it before
and it didn't seem to do much that would be useful enough in the context
of Sugar UI testing (or even any of the automated testing I do for my
customers). Neither AU#634 nor the NoteBoard source code gives any 

Re: [Sugar-devel] sugarless.py Implode version

2012-07-02 Thread Sascha Silbe
James Cameron qu...@laptop.org writes:

 On Thu, Jun 28, 2012 at 11:36:25AM -0300, Gonzalo Odiard wrote:
 +1 to keep the sugarless version working.
 In the future, I hope we have more activities working in Gnome too.

 I would like to see every activity as a menu option in the GNOME
 menus.  ;-}

Then you may be interested in:

a) my proof-of-concept patch [1] to show XDG applications (e.g. Gnome
  applications) in a new mode of the Activities Favourites
  View. Feedback (e.g. reviews) would be quite welcome.

b) SL#2435: replacing activity.info with a .desktop file [2].

While a) is the opposite direction, the overall goal is having both
Sugar and non-Sugar applications show up in both the Sugar Home View and
non-Sugar menus / launchers.

As for the Python framework for writing Sugar Activities (AKA
sugar-toolkit), the file locations
(sugar.activity.activity.get_bundle_name(), .get_bundle_path(),
get_activity_root()) would need to be derived in a different way, as
Gnome doesn't set the Sugar-specific environment variables. The standard
Python trick of introspecting the path to the source of the current
module (__file__) may help. Or using a wrapper around
sugar.activity.activityfactory.create() to start the Activity inside
Gnome, which would take care of setting the environment variables that
the functions mentioned above expect.

It would also be good to get rid of the Sugar proprietary start-up
notification protocol [3], but when focusing on the running Activities
inside Gnome aspect, it may not even be necessary. A quick glimpse at
the code suggests that even though it's located inside sugar-toolkit,
the part of the start-up notification that would fail if the Shell
wasn't present is only used by sugar (jarabe.journal.misc.launch()). It
would also be used by the wrapper mentioned above, though. Simply
ignoring the failure to invoke org.laptop.Shell.NotifyLaunch() would be
an option.

So once the file location issues are sorted out, it would be interesting
to see what happens if you try to run a Sugar activity outside
Sugar. Apart from auto-save on Activity switch not working, I don't see
any obvious problem.

Sascha

[1] https://patchwork.sugarlabs.org/patch/717/
[2] https://bugs.sugarlabs.org/ticket/2435
[3] https://bugs.sugarlabs.org/ticket/2434
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpTDVEyRfh8Y.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


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

2012-07-02 Thread Sascha Silbe
Daniel Drake d...@laptop.org writes:

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

 However, as of Telepathy-0.24.0, these properties have gone away.
[...]
 Fixes sharing of activities over gabble on new platforms such
 as Fedora 17.

What about older versions of Telepathy? Or do we already require
Telepathy = 0.24 for other reasons? And to which part exactly does the
version number apply? There are many different telepathy packages and
all of them use different versions.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgp6JQYbpX7sW.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH sugar] Unset gnome keyring environment variables

2012-06-26 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:

 Thanks Daniel for the patch.

 Looks good to me and reading the bug conversation this looks like the 
 right thing to do to me.

 Sascha, you said you wanted to adjust some description?

Yes, the review showed the actual code change to be good, but the issue
is complex enough to warrant both a comment in the code and a more
elaborate patch description.

We have sorted out the infrastructure issues now and Caspar will
probably send the review first thing in the morning. Sorry for the
delay, Daniel! You're joining at an interesting time (read: when there's
a lot going on).

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpZL0PSURMH5.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Passphrase must be re-entered when XO loses then regains wifi connection

2012-06-26 Thread Sascha Silbe
Ajay Garg ajaygargn...@gmail.com writes:

 NM may (re-)request the secrets in the following cases ::

 a)
 Wifi connection is lost. (Yes, even if the AP is switched off permanently,
 the dialog-box keeps popping up periodically).

 b)
 After being lost, the wifi connection is again within the range.

 c)
 When the credentials for the wifi network change.


 Supposedly, for every case, the request_new parameter in GetSecrets
 method is True.

Have you verified this theory?


 Ideally, request_new should be True, only for case c).

Yes. If it doesn't, that's an NM bug, not a Sugar one. We know NM is
deficient in that area (see my reply [1] on the NM list), but that's
something to fix in NM, not in Sugar.


 However, case c) is rare (and when it does happen, usually the
 system-administrator, or the like,
 has the responsibility for issuing the changes publically).

The problem is that Sugar doesn't provide a way to change or remove
credentials for a single AP. You can only remove _all_ credentials. So
if we add a workaround (which may be a reasonable thing to do until NM
gets fixed), a single AP with changed credentials (and as someone
pointed out on a related thread, that may happen regularly in some
environments) would force the user to either re-acquire and re-enter all
other credentials or use some non-Sugar tool to remove the
connection. That may be fine for some of our users, but not all of them.

So if we're inclined to use the workaround while waiting for NM to get
fixed, I'd recommend to pick up the design discussion [2,3] about our
NetworkManager client UI again, especially about a way to remove
credentials for a single connection [4,5]. We even had a patch [6] for
that already. Gary seemed [7] fine with it, it just got stalled by
nobody reviewing the code changes. Due to the NM 0.9 port, the patch
would need to be rebased first.

Sascha

[1] message-id:toesjdixt3d@twin.sascha.silbe.org
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00103.html
[2] message-id:1307282514-sup-5...@xo15-sascha.sascha.silbe.org
https://lists.sugarlabs.org/archive/sugar-devel/2011-June/thread.html#31679
[3] http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-06-05T16:17:34
[4] 
http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-06-05T16:17:34#i_2671243
[5] 
http://meeting.sugarlabs.org/sugar-meeting/meetings/2011-06-05T16:17:34#i_2671359
[6] https://patchwork.sugarlabs.org/patch/846/
[7] message-id:5f1e4ccb-208f-47be-8b39-bdde8450c...@gmail.com
https://lists.sugarlabs.org/archive/sugar-devel/2011-June/032077.html
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgphgUB6GANZP.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Passphrase must be re-entered when XO loses then regains wifi connection

2012-06-25 Thread Sascha Silbe
Anish Mangal an...@activitycentral.com writes:

 The issue of sugar prompting users to enter wifi passphrase after a
 connection is broken and is re-established[1] has been in Sugar/OLPC
 for some time.

 The purpose of this email is to understand the causes of this:

It's a long-standing NetworkManager issue. See the upstream tickets
[1,2]. ISTR there was a ticket were Dan replied in detail, but a quick
search didn't turn it up. Checking the mailing list archives might turn
up something useful, IIRC it was discussed there several times as well.

Sascha

[1] https://bugzilla.gnome.org/show_bug.cgi?id=597889
[2] https://bugzilla.gnome.org/show_bug.cgi?id=599566
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpRhG8HJOl62.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Sugar Digest 2012-06-23

2012-06-25 Thread Sascha Silbe
Walter Bender walter.ben...@gmail.com writes:

 == Sugar Digest ==

 5. Daniel Francis, a youth from Uruguay, has joined Developer Team
 meetings and will be mentored by Sascha Silbe in reviewing patches to
 Sugar itself. A nice example for other aspiring contributors.

The nice flurry of new contributors led to a mix-up here:

1. Daniel Francis is (AFAICT) a youth from Uruguay. He has joined the
   Sugar Labs Development Team and already contributed a number of
   patches. I'm happy to help him as I help every other Sugar developer,
   but I'm not paying him. :)

2. Caspar Bothmer, a long-term friend of mine, is my new apprentice. He
   will help reviewing Sugar patches, with a focus on the upcoming GTK3
   port of sugar (the Shell).

In addition, Daniel Narvaez has not only been rebuilding our buildbots
(as you already mentioned) and written a new build system (that I
unfortunately had no chance yet to take a look at yet), but also started
contributing Sugar patches.

Please welcome all three of them!

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpg8TDXe2Buf.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Object Chooser

2012-06-05 Thread Sascha Silbe
Bert Freudenberg b...@freudenbergs.de writes:

 On 04.06.2012, at 14:13, Bert Freudenberg wrote:

 So you're saying that in the response, the second argument would more
 properly be named object_id_or_full_path. And to distinguish the two
 cases, we have to look at its first character: if it is '/' then it's
 a path, otherwise an object id. 

Yes, exactly.


 I now extended that documentation page with the object_id_or_full_path
 argument discussion.

Thanks! Just one minor point (re. this is a utf8-encoded absolute path
to a file): Unix paths are sequences of octets (binary strings), not
character strings. In most cases the path will be the representation of
a character string in some encoding (and Sugar only works with the UTF-8
encoding). But it's never the other way around (the path itself getting
UTF-8 encoded). However, you do have a point in that paths that are not
a valid UTF-8 representation of some character string will cause the
Object Chooser to break.


 Are there any other places in the API where instead of an object id we have 
 to expect a full path instead?

I would expect only the Journal D-Bus API to work this way. So
org.laptop.Journal.ShowObject() should be the only other place where
object_id or a full path is used (resp. supported).

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpKlfJDJZkL6.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Object Chooser (was Re: Etoys mp3 files)

2012-06-05 Thread Sascha Silbe
Ajay Garg ajaygargn...@gmail.com writes:

 a)
 As mentioned in one of the earlier emails, 'get_properties' method needs to
 succeed to open a journal/external-USB-drive object.
 So, my query is : is the end-result just opening of the file (from
 journal/external-USB-drive), or something more too ?

get_properties() is part of the data store API (i.e. we are talking
about org.laptop.sugar.DataStore.get_properties()), not of the Journal
API (there is no org.laptop.Journal.get_properties()). Unlike in Sugar
0.82, the current data store API (as implemented by sugar-datastore and
gdatastore) does not support external storage media.

Sugar 0.84.26+ and Sugar 0.92+ support metadata for files on external
storage devices, but this is handled in the Journal, not in the data
store. And while the Object Chooser (in the Journal) allows the user to
choose an object on an external storage device, it doesn't have API to
access the corresponding metadata. This wasn't a problem in Sugar 0.84 -
0.84.25 and 0.86 - 0.90 as there was no metadata for objects
(i.e. files) on external storage devices, but when adding the metadata
support in 0.84.26+ / 0.92+ we should have extended the API accordingly.

The easiest and backwards-compatible fix for this would indeed be to
copy the entry to the Journal first. It would also be consistent with
what we do when the user resumes an entry from within the Journal.

Maybe we should really just do the short-term fix and handle the
resulting large files problem as part of SL#496. The Object Chooser
needs a major overhaul anyway (the current API is prone to race
conditions and doesn't really support using the Object Chooser as a
powerbox [2]).

Sascha

[1] https://bugs.sugarlabs.org/ticket/496
[2] https://en.wikipedia.org/wiki/File_dialog#Powerbox
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpzC39hwi7o2.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] 0.96 Change?

2012-06-05 Thread Sascha Silbe
Art Hunkins abhun...@uncg.edu writes:

 I notice that for Sugar 0.96 it seems necessary, in copying a file from the 
 Terminal to a USB stick, to do:
   cp myfile.py /run/media/liveuser/myUSB/myfile.py (perhaps I've got 
 liveuser and myUSB reversed)
 instead of the much simpler (in 0.94 and before):
   cp myfile.py /media/myUSB/myfile.py
 (two new levels!)

That's a change on the distro level (Fedora resp. systemd in this case),
not in Sugar. When running Sugar 0.96 on most other distros (that don't
use systemd), it will still be /media/medium name. When running Sugar
0.94 (or really any version of Sugar) on Fedora 17, it will also be
/run/media/user name/medium name. You can't derive the path to use
From the Sugar version. For use in Activities, let me quote a recent
mail of mine:

 They should use proper API (gio on recent distros, HAL on old OLPC OS
 builds) rather than hardcoding paths. Check out the gio VolumeMonitor
 API documentation [1] and see _find_media() [2] in Backup [3] for an
 example (including fallback to HAL).


For your personal use (inside the Terminal), you could make /media a
symlink to the new path to save you the additional typing:

sudo ln -s run/media/$USER /media

Sascha

[1] http://developer.gnome.org/gio/stable/GVolumeMonitor.html
[2] https://git.sugarlabs.org/backup/mainline/blobs/master/backup.py#line671
[3] http://activities.sugarlabs.org/en-US/sugar/addon/4326
[4] message-id:toey5obxitl@twin.sascha.silbe.org
https://lists.sugarlabs.org/archive/sugar-devel/2012-May/037699.html
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpfQubmiw6rQ.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH sugar] Set the SUGAR_LANGPACKDIR env variable when reading the GConf key, part of SL #3654

2012-06-05 Thread Sascha Silbe
Simon Schampijer si...@schampijer.de writes:


 We can not mix static and dynamic gconf bindings in one process,  
   |
 export path as env variable so it can be read by sugar-activity
 when launching the activity.

This patch series would have been easier to review if it had been a
single thread (with a cover letter explaining the overall design)
instead of three patches in separate threads with nothing obvious to
relate them to each other. Arranging patches from different repositories
to appear as a patch series in a single thread requires some minor
manual fiddling (adding the numbering to the subject prefix, passing the
Message-ID of the cover letter via --in-reply-to), but IMO nothing I
couldn't sensibly expect from a core contributor.

What I'm especially missing is explanations of what the problem is that
the patches are going to solve, how they attempt to solve it and why
this particular approach was chosen.


[bin/sugar-session]
 +# can not mix static and dynamic gconf bindings in one process,
 +# export path as env variable, SL #3654
 +langpackdir = client.get_string('/desktop/sugar/i18n/langpackdir')
 +if langpackdir is not None and langpackdir:
 +os.environ['SUGAR_LANGPACKDIR'] = langpackdir

I don't really like adding code to sugar (the Shell) to work around a
shortcoming in the Python-based Activity Framework
(i.e. sugar-toolkit). You're modifying API for all Activities. That most
Activities are Python-based so far (with several notable exceptions, see
e.g. Scratch and Etoys) doesn't really make it any better from a
software architecture point of view, only in terms of the number of
developers affected.

Language packs are only really useful if they're picked up by _all_
applications. No non-Sugar applications and few non-Python Activities
are going to implement this language pack hack (be it the existing
/desktop/sugar/i18n/langpackdir gconf entry or the new SUGAR_LANGPACKDIR
environment variable). The right thing to do back when this feature was
introduced would have been to approach it at the gettext layer, as the
proof-of-concept code [1] by cscott already did. I can only assume that
hacking Sugar was deemed easier by the people implementing the feature
and since shipping Gnome on XO-1 isn't really practical, the limited
scope (only Activities) was considered acceptable. However, today the
situation is different. XO-1 is starting to reach its end-of-life and
AFAICT most deployments ship Gnome as part of their XO-1.5+ builds.

Combined with the apparent lack of use of this feature in the field
(please contradict me if you have evidence of it being used somewhere),
I'd rather remove it than to introduce hacks to keep it working for a
subset of applications.

To prevent misunderstanding: Language packs that users can install to
augment or update the translation database shipped with the system are a
legitimate need and going even further (e.g. online i.e. in-application
editing of translations) [2] is likely to help a lot of users. I just
consider sugar(-toolkit) the wrong place to address this problem.

Sascha

[1] https://dev.laptop.org/git/users/cscott/click2trans
[2] http://lists.laptop.org/pipermail/devel/2008-June/015838.html
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpPckbnzCcFA.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH calculate] Remove dependency on CanvasIcon

2012-06-05 Thread Sascha Silbe
Sascha Silbe sascha-ml-reply-to-201...@silbe.org writes:

 Excerpts from Sascha Silbe's message of 2011-11-14 21:59:11 +0100:

 The code that used CanvasIcon was commented out in 2007 already.
 [...]

 Gary, can you include this patch in Calculate, please?

Ping.

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgp7tfT2UlEOs.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Etoys mp3 files

2012-06-04 Thread Sascha Silbe
Ajay Garg a...@activitycentral.com writes:

 As seen from the logs, the (mp3) file that was opened, was present in a USB
 pen drive.
 ANY ENTRY, when accessed via USB-pen-drive, will give this error (i.e. mp3,
 jpeg, png - any file).

Can you give more details, please? I can't reproduce the problem with
Read on mainline master (sugar-jhbuild, Debian Wheezy). Or is this only
with Etoys? (your mail sounded like it is a general problem with Sugar)

It's quite likely that Etoys doesn't implement its side of the
essentially undocumented Object Chooser API of Sugar 0.84+ correctly. In
particular, the object_id parameter of the ObjectChooserResponse signal
will contain a) the data store object id (currently stored as property
'uid') for Journal objects or b) the full path to the file for entries
stored on external storage media.


 As happens with all entries that are accessed from USB pen-drives, these
 entries too need to be copied first to the journal, to maintain
 compatability.

No, we should not do even more automatic copies to the Journal than we
already do. See SL#496 [1] for why that's a problem.


[lots of full-quotes removed]

Please trim quotes when replying. See [2] for some general guidelines.

Sascha

[1] https://bugs.sugarlabs.org/ticket/496
[2] http://www.netmeister.org/news/learn2quote.html
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpFY92EnaQ2c.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [ASLO] Release Terminal-38

2012-06-01 Thread Sascha Silbe
Gonzalo Odiard gonz...@laptop.org writes:

 I think is not a good idea publish a activity with serious regressions like
 this.

+1

Anyone interested in the current state of development can clone the git
repository and use ./setup.py dev. For everybody else it's going to be
a rather bad surprise. Especially since the a.sl.o updater in upstream
Sugar picks up Terminal-38 automatically!

Please either remove this version entirely from a.sl.o or at least mark
it as experimental. I hope the latter suffices for the updater, but you
should check to be sure.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpp003BhZCO3.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH Sugar] Set favourites layout to RingLayout if it's not set in gconf SL #3652

2012-05-30 Thread Sascha Silbe
Manuel Quiñones ma...@laptop.org writes:

 Thanks, I see, seems that my gconf setup is wrong because is returning
 None for that key.  This is in sugar-jhbuild [...]

There's a good chance you're running into Gnome#664031. GConf 3.2.4+ has
my fix.

Sascha

[1] https://bugzilla.gnome.org/show_bug.cgi?id=664031
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpivKNBNfmCD.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [ASLO] Media mount point

2012-05-30 Thread Sascha Silbe
Alan Jhonn Aguiar Schwyn alan...@hotmail.com writes:

 And the back compatibility ??And all the activities/programs that
 search in /media ??
 ___

They should use proper API (gio on recent distros, HAL on old OLPC OS
builds) rather than hardcoding paths. Check out the gio VolumeMonitor
API documentation [1] and see _find_media() [2] in Backup [3] for an
example (including fallback to HAL).

Sascha

[1] http://developer.gnome.org/gio/stable/GVolumeMonitor.html
[2] https://git.sugarlabs.org/backup/mainline/blobs/master/backup.py#line671
[3] http://activities.sugarlabs.org/en-US/sugar/addon/4326
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpX5Qp0JjOKC.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Lists in foreign languages (was Port Gtk 3 (Chat.activity))

2012-05-30 Thread Sascha Silbe
fors...@ozonline.com.au writes:

 http://fedoraproject.org/wiki/Mailing_list_guidelines#Use_the_common_language
 http://tech.groups.yahoo.com/group/editplus/message/5510

+1

Like James I usually don't read non-English posts (with no English
translation included), though less because of concerns about the
accuracy of machine translation and more because my time is rather
limited. Judging whether a mail is interesting in any way is too hard
when it's written in a language I don't understand and translating it
first takes too much time.


 I would encourage those posting in a foreign language to include a
 Google Translate in the main language. I am not sure though, which
 should come first.

For translation between English and Spanish there's also the Open Source
software apertium [1], but the dictionary seems to be rather
limited. IIRC the automatic translation between #sugar and #sugar-es
(IRC) is based on this, so any improvement to the English↔Spanish
apertium dictionary would directly benefit #sugar-es users.

Sascha

[1] http://www.apertium.org
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpzuhGfSMYr8.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH Write] Optional data when it exports a file SL #2795

2012-05-30 Thread Sascha Silbe
Manuel Kaufmann humi...@gmail.com writes:

 'keep' and 'share-scope' are optional metadata for the activity metadata, so 
 we
 should use them only if they are set before and if not we should use default
 values for them. This patch fixes it.
[...]

Reviewed-By: Sascha Silbe si...@activitycentral.com

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpH4Z5oQ8qik.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH Sugar] Set favourites layout to RingLayout if it's not set in gconf SL #3652

2012-05-29 Thread Sascha Silbe
Manuel Quiñones ma...@laptop.org writes:

 This prevent crashing jhbuild's sugar emulator startup if there is not
 a gconf setting for '/desktop/sugar/desktop/favorites_layout'.

We already set a default for favorites_layout in sugar.schemas
(data/sugar.schemas.in). If you're getting None, your gconf setup is
broken. Sugar (shell) breaking when trying to use favorites_layout is
just the first and most obvious symptom. The real fix is to get your
gconf setup to use sugar.schemas, not working around the problem by
adding a Python level default value in addition to the gconf level
default value.

However, given that this is a fairly common failure mode, there is
something we should do in Sugar: Bailing out with a clear error message if
client.get_default_from_schema('/desktop/sugar/desktop/favorites_layout')
returns None. Patch welcome. :)

Out of curiousity, in which environment did you encounter this problem?
Native Debian or Fedora packages? sugar-jhbuild? sweets? Which distro
(version)?

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpSJuYl6oEbz.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


[Sugar-devel] bundlebuilder broken without git (was: Re: [Release] Clock-8)

2012-05-29 Thread Sascha Silbe
James Cameron qu...@laptop.org writes:

 However, testing using the StopWatch activity directory showed that
 Sugar still wanted git to be installed, and the directory to be a git
 repository as well before setup.py would run the dist_xo target.

It seems the fix for that somehow got through the cracks. I ack'ed
Simons patch [1] (with a few recommended string / whitespace changes),
but it never got pushed. It's marked as superseded in Patchwork, but I
don't see a newer version of the patch either on Patchwork or in Trac
(there's not even a bug report).

Sascha

[1] https://patchwork.sugarlabs.org/patch/1045/
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpEPi33DhpK8.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


[Sugar-devel] Closing audio devices on activity switch (was: Re: [PATCH powerd] audio inhibit support)

2012-05-22 Thread Sascha Silbe
[CC'ing sugar-devel as this is about Activity development]

Walter Bender walter.ben...@gmail.com writes:

[Closing the audio device when switching from Measure to something else]
 What about non-sugarised audio players? Jukebox seems to be broken, so
 someone using a Gnome application (e.g. Rhythmbox) instead would seem
 rather likely.

 I presume that in order to run the GNOME app, you need to either exit
 Sugar or launch Terminal. In either case, notify::active should be
 enough. Or am I not understanding something?

Hmm, thinking about this again, the music player probably isn't that
good of an example here. You'd want it running in the background,
playing music all the time, not just while you're away from Measure.

But just to counter your argument: You can a) easily bind application
launches to keyboards shortcuts with metacity (so no Terminal required)
and b) have started the application already and just switch windows to
use it. Hmm, maybe the music player still fits in here: Start the music
player to play some music before start of lesson, use Measure during
lesson (keeping the music player running), play some music again in the
break, use Measure again. Only slightly contrived IMO. :)

Let's make it work as well as we can without going to great
lengths. Users will always find novel ways to use our software, I
wouldn't want to limit what they can do just because we couldn't think
of a use case involving that particular kind of transition.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpYssRVkgucT.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830

2012-05-22 Thread Sascha Silbe
Sascha Silbe si...@activitycentral.com writes:

[...]
 1. UPower API

UPower has a D-Bus API to set latency requirements [1,2]. The
UPower back-end code uses the kernel PM QoS interface [3] to set the
requested CPU (DMA) latency (in µs, up to ~35 minutes) and network
throughput (in kbps). cpuidle hooks into the PM QoS framework to
provide CPU latency management.

This is likely the future of fully automatic suspend
mechanisms. Whatever other API we may want to use, it would make
sense to use this one as well, at least on the client side.
[...]

For the benefit of those not following the OLPC development list:

I've posted a patch for powerd to add UPower support, like I suggested
in this thread. If it gets accepted, we can add a convenience wrapper
around the UPower QoS interface to sugar-toolkit, so that Activities
only have to do a single function call to inhibit suspend.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpQshrBcb4cA.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830

2012-05-21 Thread Sascha Silbe

[CC'ing devel@l.l.o because it touches operation of low-level software
components on OLPC OS]

Paul Fox p...@laptop.org writes:

 the problem is that there's no good operating system mechanism that
 powerd can use to know that audio is truly in use.

 it's possible to know that the audio device has been opened, and i
 have tried using that in the past.  but most applications that use
 audio open the device once, and then leave it open.  so even when
 they're playing nothing but silence, the device appears to be in use.

While there could (and maybe should) be a distinction between the audio
device being a) opened by a process and b) in actual use for playback or
recording, ALSA doesn't make that distinction [1] and a lot of
commonplace hardware doesn't support more than one substream. As long as
the device is open, no other process will be able to use the
device. Whether we like it or not, this is the kernel-level ALSA API and
if applications don't obey their side of the contract (closing the
device to de-allocate resources) it's simply an application bug.

I haven't dug into GStreamer enough to tell what its API looks like
w.r.t. resource acquisition and how that translates into ALSA device
usage, but powerd is only concerned about the kernel level and a number
of well-behaving Activities show that there's no major roadblock ahead;
in fact a close look at the Record source doesn't even reveal any
obvious kind of hack.


 regarding the other elements of this thread:  it may be that system
 mechanisms for inhibiting suspend via upowerd or gnome are now mature
 enough to be of some use.  this has never seemed to be the case in the
 past.  plus -- they're all, as far as i can tell, just as specific to the
 power-manager-du-jour as the current powerd interfaces are.  i.e., no
 one has created a generic set of interfaces which can be implemented
 in various ways behind the scenes.

Yes, many of the Gnome APIs (remember, Sugar is built on Gnome
components) are annoyingly specific to Gnome components. There are a
number of cross-desktop environment APIs being worked on at
freedesktop.org [2], but nothing related to session or power management
is among them. The inhibit support of XSMP [3] is claimed [4] to be
problematic, so no common base there either.

When it comes to power management, we're living in a constantly changing
world. Like with any standardisation effort, it will take a) someone to
drive it and b) considerable time and effort to design and get people to
agree on a common API.

I've tried looking at what the APIs KDE uses for power management, but
only hit a number of partially [5,6] or completely [7-9] broken API docs
pages. What I've seen so far doesn't like any better or more
cross-desktop environment than what Gnome does.

Sascha

[1] http://www.alsa-project.org/~tiwai/writing-an-alsa-driver.pdf
page 28 (page 21 using in-pdf numbering)
[2] http://www.freedesktop.org/wiki/Specifications
[3] http://www.x.org/releases/X11R7.6/doc/libSM/xsmp.html
[4] http://live.gnome.org/SessionManagement/GnomeSession#Problems_and_Goals
[5] 
http://www.purinchu.net/kdelibs-apidocs/solid/html/namespaceSolid_1_1PowerManagement.html
[6] 
http://www.purinchu.net/kdelibs-apidocs/solid/html/powermanagement_8cpp_source.html
[7] http://api.kde.org/
[8] http://api.kde.org/4.x-api/kdelibs-apidocs/
[9] http://api.kde.org/4.8-api/kdelibs-apidocs/
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpW9MY3ht3TL.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830

2012-05-21 Thread Sascha Silbe
Gonzalo Odiard godi...@sugarlabs.org writes:

[...]
 That is a complete nonsense to me. [...]

I'm not going to reply to your mail in detail because it wasn't
constructive in any way; I even felt it to be slightly ad-hominem.

See my other mails (including a patch, and maybe another one later today
or tomorrow) for the way forward that I see.

For those following only sugar-devel: The powerd patch [1] was posted on
devel@l.l.o only as it doesn't touch Sugar code.

Sascha

[1] http://lists.laptop.org/pipermail/devel/2012-May/thread.html#35124
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpkiS2nu9hYa.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Dr.Geo on XO 1

2012-05-20 Thread Sascha Silbe
Bert Freudenberg b...@freudenbergs.de writes:

 Nope, that was not it. I compiled with -mtune=geode, makes no
 difference.

Make sure to set -march=architecture to something appropriate. -march
tells gcc what instructions it can use (so anything that doesn't support
these instructions will fail to run the resulting executable), whereas
-mtune only tells it to optimise for a certain processor type (but the
executable will continue to run on other processors as long as they
support the instruction set specified by -march).


 In gdb I see it's segfaulting inside the GC logic. It's really
 puzzling this only happens on the XO-1 ...

You could try booting an XO-1.5 with mem=256M (append that to boot-file
in /bootpart/boot/olpc.fth) to simulate the memory pressure of an XO-1.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpjulZTBZDG8.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830

2012-05-15 Thread Sascha Silbe
Gonzalo Odiard godi...@sugarlabs.org writes:

 Using  powerd-inhibit-suspend directory is how ALL the activities are
 working today,

Quantity isn't the same as quality. That everybody is doing it doesn't
make it suddenly a good idea. Quite the contrary, as platform developers
we have the responsibility to take the lead and show what _best_ (not
common) practice is. Activity authors can then adopt it.


 and how powerd is used.

That's exactly what I don't like: it's specific to powerd. That's fine
for downstreams to decide for themselves and use your patch (Dextrose
may be interested in it, for example), but it's not a good direction for
upstream to take.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpKtIzUvnx6h.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH Log 2/2] Log collector adds user's logs and list installed activities

2012-05-14 Thread Sascha Silbe
Manuel Kaufmann humi...@gmail.com writes:

 On Sun, May 13, 2012 at 8:51 AM, Sascha Silbe si...@activitycentral.com 
 wrote:
 This won't work if Sugar isn't installed in /usr (e.g. when using
 sugar-jhbuild).

 Why do you say this won't work?

 If the user doesn't have any activity installed there, that directory
 won't exist and the for won't be executed. That's all. There is no
 problem there.

But it will miss the Activities installed in the other location.


 On the other hand, I was talking with Martin these days and he told me
 there is a command called olpc-log that work in a similar way
 (collecting information and creating a tar.bz2 file), so maybe we
 should use this command inside log collector function to make them
 consistent.

I'm hesitant about using downstream-specific tools (and olpc- in the
name indicates it's downstream-specific) in upstream Sugar as those
usually only work properly on downstream systems (OLPC OS in this case).

What does olpc-log provide that we don't do yet? What dependencies does
it have? What information is hard-coded (e.g. user names and
directories)? What (other) assumptions does it make that may be true for
OLPC OS, but not necessarily for all systems running Sugar? What does it
do that we (= upstream Sugar) might not want to be done?

Sascha
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpdszGZbwEn9.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Wanting to know a bit of (NetworkManager) workflow upon resume-from-suspend

2012-05-14 Thread Sascha Silbe
Paul Fox p...@foxharp.boston.ma.us writes:

 yes.  i think we hope there won't actually be any more of those, but
 if there are, that patch will be there.

Great, thanks!

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpHKRhP9wUQ2.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH Sugar] Inhibit power suspend while playing text to speech - OLPC #11830

2012-05-14 Thread Sascha Silbe
godi...@sugarlabs.org writes:

 To avoid stoping playing the text when the xo go to sleep.
 This patch creates a file in /var/run/powerd-inhibit-suspend/
 and remove it when finish.

/var/run/powerd-* is an implementation detail of a particular downstream
implementation of power management (namely powerd). I don't think it's a
good fit for Sugar upstream to be this tightly bound to downstream code.

Leaving aside the question whether we need to interfere with power
management at all in this particular case (as Paul has pointed out
correctly, powerd should treat audio traffic as non-idleness and
inhibit suspending), there are likely to be other cases where it may be
beneficial to interface with the power management code. The important
thing is to make sure that it's implemented in a hardware- and
implementation-independent manner. Since AFAICT there is no open
standard (published by a standard-setting organisation) on this kind of
interface, the next best thing we can do is to choose an interface that
any power manager (implementation) _can_ implement; preferably one
that's already implemented by one or more existing components. Even
better if that component is in widespread use (but remember the
hardware- and implementation-independent rule).

The above is important not just for hardware independence of Sugar, but
also for better operation of non-Sugar applications on XOs. If we can
agree on a suitable interface, it can a) be implemented by any
power manager and b) be used by all applications.

Possible choices, potentially combined:

1. UPower API

   UPower has a D-Bus API to set latency requirements [1,2]. The
   UPower back-end code uses the kernel PM QoS interface [3] to set the
   requested CPU (DMA) latency (in µs, up to ~35 minutes) and network
   throughput (in kbps). cpuidle hooks into the PM QoS framework to
   provide CPU latency management.

   This is likely the future of fully automatic suspend
   mechanisms. Whatever other API we may want to use, it would make
   sense to use this one as well, at least on the client side. There's a
   gap to today's world of not-quite-transparent, user space initiated
   suspension. But we can close that gap by having powerd listen to the
   LatencyChanged signal (calling GetLatency() after setting up the
   signal handler to make sure it didn't miss some early request during
   boot) and having it inhibit suspend accordingly.

2. gnome-session API

   The org.gnome.SessionManager.Inhibit() method [4,5] allows registered
   clients to inhibit suspend (bit 3 of flags). This is a direct
   equivalent of the /var/run/powerd-inhibit-suspend/pid
   interface.

   gnome-session provides a lot of other functionality that wouldn't be
   sensible for a pure power manager like powerd to implement and the
   current implementation as part of gnome-session is geared towards
   manual suspension, not almost-transparent, automatic suspension like
   powerd is trying to achieve. But if we think this is the right choice
   of interface, Gnome folks may be open to extending the interface and
   / or implementation to match our needs.

3. Open Hardware Manager (OHM) API [8]

   While not in widespread use (anymore?), it's at least an existing API
   and doesn't interfere with other implementations (a problem the
   UPower and gnome-session may have, depending on how much the power
   manager wants to implement). OTOH there's a smaller chance many
   (non-Sugar) application developers will a) be aware of and b) use
   this interface, as it duplicates part of the above, commonly used
   interfaces.

   The advantage over touching a file in
   /var/run/powerd-inhibit-suspend/ is that with a D-Bus interface
   _code_ is running to handle the interfacing. An alternative power
   manager doesn't have to monitor arbitrary directories for random
   files that may appear.

4. Brand-new D-Bus API

   If we go this route, we should involve other desktop projects (Gnome,
   KDE, etc.) to agree on an API that all of us can use.

5. Brand-new CLI API

   At least better than hard-coding powerd directory paths.


Independent of the API issue, I'd prefer the Gnome components to be
extended to support our (= Sugar Labs and OLPC) use cases and letting
powerd die. Not because I consider powerd to be a bad piece of software
(quite the contrary, it's doing one thing and doing it well [9]), but
because it would align us better with mainstream. We'd get it a)
maintained by the much larger number of Gnome developers and b) used by
the many developers that write software for Gnome. Still not universal
(KDE etc. won't use it), but a step in the right direction.


Previous discussions on the same or a related topic:
- powerd-dbus network extension [6]
- Power management vs. activities [7]

Sascha

[1] http://upower.freedesktop.org/docs/QoS.html
[2] http://blogs.gnome.org/hughsie/2008/11/06/devicekit-power-latency-control/
[3] https://www.kernel.org/doc/Documentation/power/pm_qos_interface.txt
[4] 

Re: [Sugar-devel] Call for testing and feedback: alternative Journal implementation

2012-05-14 Thread Sascha Silbe
=?UTF-8?Q?Christophe_Gu=C3=A9ret?= c.d.m.gue...@vu.nl writes:

 The installation procedure is not super convenient but should be manageable
 anyway: http://wiki.sugarlabs.org/go/Features/Semantic_Web/Testing

I was able to install it on Debian Wheezy by using the distro packages
libraptor2-dev, librasqal3-dev, librdf0-dev and python-sparqlwrapper and
building redstore [1] (needs either pandoc or a fix to Makefile.am) and
python-rdflib [2] from source.

Adjusted file paths and python executable name in
datastore/bin/datastore-service (inside semanticxo repository) and
started it manually. Ran redstore -v in a separate xterm.

Sugar (latest mainline master) starts up fine, but trying to resume a
file from external storage (USB stick) fails with the following errors:

shell.log:
{{{
1337031865.456647 DEBUG root: get_file asked for file with path '/media/Debian 
Inst/Journal backup of Sascha Silbe (XO-1) (CSN7470103E) on 13.09.2010.xmj'
1337031865.457434 DEBUG root: model.write '' '/media/Debian Inst/Journal backup 
of Sascha Silbe (XO-1) (CSN7470103E) on 13.09.2010.xmj' True
1337031866.380370 DEBUG root: launch bundle_id=org.sugarlabs.Restore 
activity_id=a6c7ee02667a96e8e51e5656d22be575506e0e24 
object_id=dfe88839-6a71-4e7b-a16a-f0da7d5122ff uri=None
1337031866.521933 ERROR dbus.connection: Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/dbus/connection.py, line 214, in 
maybe_handle_message
self._handler(*args, **kwargs)
  File 
/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/sugar/datastore/datastore.py,
 line 61, in __datastore_created_cb
metadata = _get_data_store().get_properties(object_id, byte_arrays=True)
  File /usr/lib/python2.7/dist-packages/dbus/proxies.py, line 143, in __call__
**keywords)
  File /usr/lib/python2.7/dist-packages/dbus/connection.py, line 630, in 
call_blocking
message, timeout)
DBusException: org.freedesktop.DBus.Python.TypeError: Traceback (most recent 
call last):
  File /usr/lib/python2.7/dist-packages/dbus/service.py, line 745, in 
_message_cb
_method_reply_return(connection, message, method_name, signature, *retval)
  File /usr/lib/python2.7/dist-packages/dbus/service.py, line 252, in 
_method_reply_return
reply.append(signature=signature, *retval)
TypeError: Don't know how which D-Bus type to use to encode type NoneType

1337031866.567461 ERROR dbus.connection: Exception in handler for D-Bus signal:
Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/dbus/connection.py, line 214, in 
maybe_handle_message
self._handler(*args, **kwargs)
  File 
/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/jarabe/journal/model.py,
 line 507, in _datastore_created_cb
created.send(None, object_id=object_id)
  File 
/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/sugar/dispatch/dispatcher.py,
 line 125, in send
response = receiver(signal=self, sender=sender, **named)
  File 
/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/jarabe/journal/journalactivity.py,
 line 259, in __model_created_cb
self._check_for_bundle(kwargs['object_id'])
  File 
/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/jarabe/journal/journalactivity.py,
 line 284, in _check_for_bundle
metadata = model.get(object_id)
  File 
/home/sascha.silbe/sugar-jhbuild/install/lib/python2.7/site-packages/jarabe/journal/model.py,
 line 551, in get
metadata = _get_datastore().get_properties(object_id, byte_arrays=True)
  File /usr/lib/python2.7/dist-packages/dbus/proxies.py, line 143, in __call__
**keywords)
  File /usr/lib/python2.7/dist-packages/dbus/connection.py, line 630, in 
call_blocking
message, timeout)
DBusException: org.freedesktop.DBus.Python.TypeError: Traceback (most recent 
call last):
  File /usr/lib/python2.7/dist-packages/dbus/service.py, line 745, in 
_message_cb
_method_reply_return(connection, message, method_name, signature, *retval)
  File /usr/lib/python2.7/dist-packages/dbus/service.py, line 252, in 
_method_reply_return
reply.append(signature=signature, *retval)
TypeError: Don't know how which D-Bus type to use to encode type NoneType
}}}

org.sugarlabs.Restore-1.log:
{{{
1337031878.858341 DEBUG root: datastore.get
Traceback (most recent call last):
  File /home/sascha.silbe/sugar-jhbuild/install/bin/sugar-activity, line 146, 
in module
main()
  File /home/sascha.silbe/sugar-jhbuild/install/bin/sugar-activity, line 141, 
in main
instance = create_activity_instance(activity_constructor, activity_handle)
  File /home/sascha.silbe/sugar-jhbuild/install/bin/sugar-activity, line 34, 
in create_activity_instance
activity = constructor(handle)
  File /home/sascha.silbe/Activities/Restore.activity/restore.py, line 532, 
in __init__
activity.Activity.__init__(self, handle, create_jobject=False)
  File 
/home/sascha.silbe/sugar-jhbuild/install/lib

Re: [Sugar-devel] Call for testing and feedback: alternative Journal implementation

2012-05-14 Thread Sascha Silbe
Eduardo H. Silva hoboprim...@gmail.com writes:

 I have a question, could activities add new entries to the semantic
 datastore? For example, Paint and Write when installed would add these
 items:

 Painted a picture of,IsActionOf,Paint
 Wrote,IsActionOf,Write

 Then you could use this information to be used in the Diary-like view
 of the Journal
 (http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal):
[...]

FWIW, the same thing is possible using the existing data store. You can
store arbitrary metadata as key=value pairs. We can also teach
sugar-datastore to index a new property called type that would allow
us to distinguish between objects to show in the Journal (Object View)
and other kinds of entries, e.g. to store some information about actions
that may not naturally be coupled to an individual entry.

The power of SemanticXO comes from the combination with existing Linked
Data / Semantic Web data sets, not from extending the data store to
store triples instead of pairs or providing a potentially turing
complete ;) query language in addition to Xapian full text searches.

Come to think of it, maybe the same goal would be better achieved by a
kind of proxy that listens to data store updates, feeding them to a
triple store. Most Activities would use the (probably more performant
and definitely easier to test) data store API, whereas Activities that
benefit from the power of Linked Data can query the triple store via
SPARQL.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpY5UvsHYHj8.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH Log 2/2] Log collector adds user's logs and list installed activities

2012-05-13 Thread Sascha Silbe
Manuel Kaufmann humi...@gmail.com writes:

[logcollect.py]
 @@ -229,10 +229,11 @@ class MachineProperties:
  
  def installed_activities(self):
  s = ''
 -for path in glob.glob('/usr/share/activities/*.activity'):
 +for path in glob.glob('/usr/share/sugar/activities/*.activity'):

This won't work if Sugar isn't installed in /usr (e.g. when using
sugar-jhbuild). Unfortunately there doesn't seem to be public /
documented API to query for this; the best we have right now is
jarabe.config.activities_path. It's been there ever since we started
supporting system-installed activities [1], so until we provide a better
way it should be safe (albeit a bit hacky) to use
jarabe.config.activities_path.


  s += os.path.basename(path) + '\n'
  
 -for path in glob.glob('/home/olpc/Activities/*'):
 +home = os.path.expanduser('~')
 +for path in glob.glob(os.path.join(home, 'Activities', '*')):
  s += '~' + os.path.basename(path) + '\n'

Using sugar.env.get_user_activities_path() would be more future-proof,
matching what Sugar itself is doing.

Sascha

[1] 
https://git.sugarlabs.org/sugar/mainline/commit/d0cd8e27bdd3ef6745f2ec1ff02cc191ffbd2af8
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpK8ummznD1o.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] [PATCH v2 Terminal] Prevent Sugar capture Ctrlz and Ctrlq send them to vte SL #3222 OLPC #11836 Used the same approach than the solution for the Escape capture when the activity

2012-05-13 Thread Sascha Silbe
Manuel Kaufmann humi...@gmail.com writes:

 On Thu, May 10, 2012 at 11:05 AM, Manuel Quiñones ma...@laptop.org wrote:
 Tested-by: James Cameron qu...@laptop.org

 I tested this patch and it works.

Thanks for testing! If you put a Tested-By: line similar to James' in
your mail, Patchwork [1] will pick it up automatically and if the
maintainer is following the Code Review process [2] as recommended, that
line will appear in the commit message of the public git repository. Not
only does this give an indication of how well a commit was tested, but
it also credits you as having spent the time for testing.

Sascha

[1] https://patchwork.sugarlabs.org/project/sugar/list/
[2] 
https://wiki.sugarlabs.org/go/Development_Team/Code_Review#Internal_process_.28maintainers_only.29
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


pgpdJzNuyLC1u.pgp
Description: PGP signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel


Re: [Sugar-devel] Unit testing an activity

2012-05-07 Thread Sascha Silbe
Taylor Rose (RIT Student) tjr1...@rit.edu writes:

 Does anyone have advice about how to run unit tests for an activity? I am
 working on a video conferencing activity called Open Video
 Chathttps://github.com/FOSSRIT/Open-Video-chat.
 I'd like to be able to run some basic unit tests on the activity but I'm
 not sure how to instantiate an activity in a testing environment or if it's
 even possible. Can anyone offer advice or point me to an example? I'd like
 to be able to mock a connection and make sure the activity reacts properly,
 starting up gstreamer and such.

While the test support infrastructure for Activities is in better shape
than that for Sugar, it's mostly a set of general components, prototypes
and hacks that you have to tape together yourself. Especially automated
testing of shared Activities is going to hit some rather rough edges. If
you're willing to dive in nonetheless and get it all working well, we'd
appreciate you documenting the process so other Activity authors benefit
From your effort.

I'll describe the parts starting on the system layer.

As you want to include Collaboration in your tests (which makes sense
for Open Video Chat), you'll need two different systems. There are
various hacks to test Sugar with just a single system, but we don't
really know when they work and when they break, so I'd recommend
sticking with two entirely separate systems for now. Start the test
suite inside the Terminal activity on each system, distinguishing
between them by passing an option (Initiator vs. someone joining the
shared instance). That will bypass all the pitfalls of trying to remote
control a Sugar session from a different system. The two systems can
also be VMs on one physical host if they share a multicast-capable
network connection (e.g. private network between the VMs or bridging to
the physical network, but no NAT setup like the KVM user mode network
stack). Synchronisation between the two instances happens naturally in
your use case of testing Collaboration.

The Python unit testing framework shipped with Python 3 and backported
to Python 2.7 (as unittest2) is a natural choice for any Python based
application. It includes support for skipping tests (e.g. for
functionality that's not available in older versions of Sugar or for
tests that are hardware-specific) and marking tests as being expected to
fail, either always (e.g. for test-driven development, where you write
the test first) or based on some condition (e.g. if some versions of
Sugar contain a bug that causes the test to fail). There are hooks
(TestCase.setUp() and TestCase.tearDown()) to run code before and after
running each individual test to prepare the environment for the test
(e.g. start resp. stop the Activity). If you need to run code before and
after complete sets of tests (e.g. if you want to split up a sequence of
steps into individual tests, keeping the Activity running between the
tests), please contact me. I've already implemented this for several
test suites and can show you how to use it.

Launching the activity is where it gets tricky. The initiator side would
be easy enough using sugar-launch, but it has no support for joining a
shared activity. It'll also assign the activity_id randomly, so you'd
either need to determine the activity_id on the joiner side by scanning
for shared activities or control the Sugar platform UI (the Shell) by
scanning for the shared activity icon in the Neighbourhood (using a
special icon for the Activity running in test suite mode, so it doesn't
try to connect to somebody else instead) and simulating a click. The
third and probably best option is to tap into the semi-privates of
Sugar, giving you more control of the Activity session creation
process. Assign a fixed, hard-coded activity_id (use
sugar.activity.activityfactory.create_activity_id() to generate it) so
that the both sides know it. For the initiator side, set
sugar.activity.activity.Activity._activity_id to the fixed activity_id
and call Activity.share() on start-up. See below for how to tell your
activity it should do this magic. For the joining side, copy the code of
sugar-launch that you need to start you activity and enhance it to pass
the activity_id to sugar-activity (CLI option -a).

If you're going to do the tests on the code level (rather than on the UI
level) you're almost set if you get all of the above working. You can
phone in to your activity by setting an environment variable in your
test suite when calling sugar-activity to tell your activity to enter
test mode. There's a number of ways to remote control the activity if
you want to the test code to run outside the activity, or you could
set the environment variable to the name of the test you want to run and
have the activity execute it.

For tests on the UI level, we're entering less than firm ground
again. You could try SugarBot [1-4]. Given the way it works [5], I have
a feeling it would be a major effort to port SugarBot to GTK3. If you
don't get 

[Sugar-devel] [PATCH v3 sugar-datastore 2/2] Add API to check/wait for index rebuild to finish (SL#1160)

2012-05-01 Thread Sascha Silbe
The data store (re)builds the index in the background (idle loop), but
has no API to wait for this to finish. While it rebuilds the index, some API
functions work differently than they do during regular operation. In
particular, the find() function returns all entries, rather than just matching
ones. The requested sort order isn't respected, either.

This fact isn't mentioned in any public API description, so very few clients
are designed with it in mind. Every client would need to duplicate an important
subset of the data store functionality: filtering and sorting. The one
advantage of this approach is that, at least in theory, the data store is ready
to operate right away, allowing the user to start working. In practice, the
advantage isn't quite as clear: Migration happens synchronously [2] and
rebuilding is either fast (removing the need for it to happen in the
background) or takes significant system resources, reducing the usefulness of
the system while the rebuild is happening.

For these reasons, for most clients it's better to just wait for the data store
to finish rebuilding. We're adding API to allow them to do just that, in both
synchronous and asynchronous ways. wait_ready() blocks until the data store is
ready, whereas the Ready signal and the check_ready() function allow
implementing a race-free, asynchronous check.

Clients can now choose (and the Activity framework should probably do so by
default) to either wait for the rebuild to complete or cope with whatever the
data store does differently during rebuild.

The additional API functions don't affect the rest of the API in any way. The
queue that we add as part of this patch handles only the outstanding
wait_ready() calls. Other invocations get handled immediately.

It could be argued that index rebuilds should happen rarely in the field and we
should just always block until the data store is ready for normal operation. If
rebuilds are happening often in the field, we should analyse and fix the reason
for this, rather than covering up by making rebuild asynchronous and providing
inconsistent API. This patch provides a reasonable middle ground that we can
build on. If or when data store rebuilds happen rarely in the field, we can
still switch to blocking at start-up.

[1] https://bugs.sugarlabs.org/ticket/1160
[2] https://bugs.sugarlabs.org/ticket/1546

Signed-off-by: Sascha Silbe si...@activitycentral.com
---
v2-v3: Significantly enhanced description; no code changes

 src/carquinyol/datastore.py |   38 ++
 1 file changed, 38 insertions(+)

diff --git a/src/carquinyol/datastore.py b/src/carquinyol/datastore.py
index de79500..3c0c294 100644
--- a/src/carquinyol/datastore.py
+++ b/src/carquinyol/datastore.py
@@ -52,6 +52,7 @@ class DataStore(dbus.service.Object):
 
 
 def __init__(self, **options):
+self._wait_ready_queue = []
 bus_name = dbus.service.BusName(DS_SERVICE,
 bus=dbus.SessionBus(),
 replace_existing=False,
@@ -164,6 +165,12 @@ class DataStore(dbus.service.Object):
 self._index_store.flush()
 self._index_updating = False
 logging.debug('Finished updating index.')
+
+self.Ready()
+for callback in self._wait_ready_queue:
+callback()
+
+self._wait_ready_queue = []
 return False
 else:
 return True
@@ -443,3 +450,34 @@ class DataStore(dbus.service.Object):
 @dbus.service.signal(DS_DBUS_INTERFACE, signature=a{sv})
 def Unmounted(self, descriptor):
 pass
+
+@dbus.service.method(DS_DBUS_INTERFACE,
+ in_signature='',
+ out_signature='b')
+def check_ready(self):
+Check whether datastore is ready for processing (regular) API
+calls.
+
+Return True if datastore is fully operational.
+
+return not self._index_updating
+
+@dbus.service.method(DS_DBUS_INTERFACE,
+ in_signature='',
+ out_signature='',
+ async_callbacks=('async_cb', 'async_err_cb'))
+def wait_ready(self, async_cb, async_err_cb):
+Block until the datastore is ready for processing (regular) API
+calls.
+
+if not self._index_updating:
+async_cb()
+return
+
+self._wait_ready_queue.append(async_cb)
+
+@dbus.service.signal(DS_DBUS_INTERFACE, signature='')
+def Ready(self):
+Signal emitted after datastore is ready for processing API calls.
+
+pass
-- 
1.7.9.5

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


Re: [Sugar-devel] sugar.po string change

2012-04-24 Thread Sascha Silbe
Excerpts from Chris Leonard's message of 2012-04-24 07:33:37 +0200:

 Why did this change land in glucose 0.94 sugar.po instead of glucose
 0.95 sugar.po ?
 
 
 ../src/jarabe/desktop/keydialog.py:94
 A wireless encryption key is required for\n
 the wireless network '%s'.

It already landed in 0.95 some time ago. I should have discussed this
with you first (sorry!), but did not see any harm in including it as the
string was used previously, but not marked for translation. So the worst
thing that should happen is that, like before, the string is always
displayed in English.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


[Sugar-devel] [ANNOUNCE] bugs.sl.o (Trac): added component name to notification mail subject

2012-04-24 Thread Sascha Silbe
Hello everyone,

I've modified the subject line of Trac notification emails to include
the name of the component the ticket was filed against. This should help
scanning the notification emails, both visually and automatically
(tagging).

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] [PATCH] Only add one time every object in the clipboard v3 - SL #3371

2012-04-23 Thread Sascha Silbe
Excerpts from godiard's message of 2012-04-20 16:17:46 +0200:

 This patch change the behaviour of the clipboard tray,
 every object is added only one time, if already exist,
 the already added object is selected.

It's worth mentioning that even though the entry is just selected, we
still trigger a Clipboard notification (showing a flashing icon in the
lower left corner). Manually selecting an entry in the Clipboard does
not cause this to happen.

On the implementation side, it should be mentioned that we're changing
the type of clipboard object ids from 32-bit integer to long integer,
with object ids being either a strictly increasing number (produced by
Clipboard._get_next_object_id()) or the return value of the built-in
hash() function applied to the selection data.

[...]
 v2: Select the already added object if needed, as sugested by Sasha.
 v3: Show the notification when copy a already existing object, as sugested by 
 Gary

Please put the changelog below the marker line (---). BTW, my name is
Sascha, not Sasha. :)


[src/jarabe/frame/clipboard.py]
[class Clipboard]
 @@ -51,9 +53,16 @@ class Clipboard(gobject.GObject):
 -def add_object(self, name):
 -logging.debug('Clipboard.add_object')
 -object_id = self._get_next_object_id()
 +def add_object(self, name, data_hash=None):
 +logging.debug('Clipboard.add_object hash %s', data_hash)

We should document the new parameter data_hash. What are the
requirements for this parameter? Do you expect a specific hash function
to be used? (with the current patch, it needs to be the return value of
the built-in hash() function applied to the selection data)

Similarly, you're changing the set of possible return values. In
addition to a clipboard object id, the method can now also return
None. We need to document when it returns None and what that means to
the caller.


 +if data_hash is None:
 +object_id = self._get_next_object_id()
 +else:
 +object_id = data_hash
 +if object_id in self._objects:
 +logging.debug('Object rejected, already exist')

This message is misleading. We don't really reject the object, rather we
select to the existing instance. So how about:

 +logging.debug('Duplicate entry, selecting previous entry instead')


[...]
[src/jarabe/frame/clipboardicon.py]
 @@ -128,17 +128,19 @@ class ClipboardIcon(RadioToolButton):
  # Clipboard object became complete. Make it the active one.
  if self._current_percent  100 and cb_object.get_percent() == 100:
  self.props.active = True
 +self.show_notification()
  
 -self._notif_icon = NotificationIcon()
 -self._notif_icon.props.icon_name = self._icon.props.icon_name
 -self._notif_icon.props.xo_color = \
 -XoColor('%s,%s' % (self._icon.props.stroke_color,
 -   self._icon.props.fill_color))
 -frame = jarabe.frame.get_view()
 -frame.add_notification(self._notif_icon,
 -   gtk.CORNER_BOTTOM_LEFT)
  self._current_percent = cb_object.get_percent()
  
 +def show_notification(self):
 +self._notif_icon = NotificationIcon()
 +self._notif_icon.props.icon_name = self._icon.props.icon_name
 +self._notif_icon.props.xo_color = \
 +XoColor('%s,%s' % (self._icon.props.stroke_color,
 +   self._icon.props.fill_color))
 +frame = jarabe.frame.get_view()
 +frame.add_notification(self._notif_icon, gtk.CORNER_BOTTOM_LEFT)

Why don't you connect to the Clipboard.object-selected here in
ClipboardIcon, the same way it's already handling
Clipboard.object-state-changed? Routing related signals differently
(Clipboard - ClipboardIcon for object-state-changed and Clipboard -
ClipboardPanelWindow - ClipboardIcon for object-selected) makes it hard
to understand and debug the code.


Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] [PATCH] When a object is removed from the clipboard try, select the last available v2 - SL #1266

2012-04-23 Thread Sascha Silbe
Excerpts from godiard's message of 2012-04-20 16:35:52 +0200:

 From: Gonzalo Odiard godi...@gmail.com
 

More context would be useful. I had to read the ticket to understand
what this patch is about.


 v2: If there no more objects in the try, clean the clipboard

Please put the changelog below the marker line (the line with just ---
on it). It should not be part of the commit message on
mainline/master.

Similarly, please put the version number inside the subject prefix
(i.e. [PATCH v2 sugar]), rather than making it part of the patch
summary.


[src/jarabe/frame/clipboardtray.py]
 @@ -124,6 +124,14 @@ class ClipboardTray(tray.VTray):
  icon = self._icons[object_id]
  self.remove_item(icon)
  del self._icons[object_id]
 +# select the last available icon
 +if len(self._icons)  0:

PEP 8, Programming Recommendations:
 For sequences, (strings, lists, tuples), use the fact that empty sequences 
 are false
Yes: if not seq:
 if seq:

No: if len(seq)
if not len(seq)


 +n_icons = len(self.get_children())
 +last_icon = self.get_children()[n_icons - 1]

In Python, you can slice and dereference relative to the end of a
sequence by using a negative integer:

+last_icon = self.get_children()[-1]

No need to explicitly calculate the length of the sequence. In
specific cases, using negative indexes may be faster (depending on
implementation details of the sequence), but more importantly it's
more readable and concise.


 +last_icon.props.active = True
 +else:
 +gtk_clipboard = gtk.Clipboard()
 +gtk_clipboard.clear()

Shouldn't all of this happen in
jarabe.frame.clipboard.Clipboard.delete_object()? AIUI ClipboardTray
is just the graphical representation (UI), whereas Clipboard is the
actual clipboard service, managing and keeping references to the
clipboard objects.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] [PATCH sugar] Create a default unencrypted keyring, OLPC #10290

2012-04-23 Thread Sascha Silbe
Excerpts from Simon Schampijer's message of 2012-04-16 12:33:05 +0200:

 This patch does create an ununcrypted default keyring
 if there is not one available already. This will stop
 prompts for unlocking the keyring after logging into
 Sugar.
 
 In GNOME the session manager deals with creating
 that keyring. In the OLPC images we do create a default
 keyring on image creation time (see olpc-configure), same
 is true for Soas. This patch does check/create the
 keyring on every Sugar run. The advantage is that
 for example installs the live image to a disk install
 using liveinst, or install Sugar from the Fedora installer
 without installing or ever running GNOME that workaround
 will work for them as well.

At least the patch description is too downstream-centric for my
taste. It also looks like something the distro X session scripts should
do, not sugar. It may be fine to include in sugar-emulator, because
we're setting up the X session manually there, without calling the
distro X session scripts.

IIRC, somebody mentioned (on IRC?) that this functionality is also
included in gnome-session. Replacing our ancient embedded copy of
gnome-session in sugar-toolkit with using upstream gnome-session would
do the trick as well then. I've been working with upstream on that for
some time. gnome-session can now properly run non-default (read
non-Gnome) sessions [1] and I have working sugar [2] and sugar-toolkit
[3] patches to make use of that facility. The only reason I've not
posted it for upstream (Sugar) inclusion is that gnome-session doesn't
provide API for Sugar to trigger Shutdown and Reboot without presenting
non-Sugar UI [4]. With the systemd support patch that landed recently
(99bb52c [5]), this hurdle is gone at least on systemd based systems
(i.e. Fedora).

Sascha

[1] https://bugzilla.gnome.org/show_bug.cgi?id=633276
[2] https://git.sugarlabs.org/sugar/silbe/commits/gnome-session
[3] https://git.sugarlabs.org/sugar-toolkit/silbe/commits/gnome-session
[4] https://bugzilla.gnome.org/show_bug.cgi?id=575880
[5] 
https://git.sugarlabs.org/sugar/mainline/commit/99bb52c5dbea01a3ffc9b8821ec12af2536f76ca
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] [Sugar] Show a clean error in log if not libraries needed to do tts - SL #3345

2012-04-23 Thread Sascha Silbe
Excerpts from godiard's message of 2012-03-09 19:44:08 +0100:

 From: Gonzalo Odiard godi...@gmail.com

How about this for a patch summary and description:

Handle missing gst-plugins-espeak gracefully (fixes SL#3345)

The text-to-speech support in Sugar (jarabe.model.speech) depends on
gst-plugins-espeak [1]. While Sugar continues to work properly in the
absence of gst-plugins-espeak, loading the corresponding components
(keyboard shortcut handler and Frame device icon) currently fails hard
and produces a traceback in the log. However TTS support is entirely
optional and the traceback suggests an unhandled system failure rather
than optional support not being available. Fix this by catching the
exception when accessing the SpeechManager and logging a warning
instead.

[1] https://wiki.sugarlabs.org/go/Activity_Team/gst-plugins-espeak


[extensions/deviceicon/speech.py]
[...]
 +tts_available = True
 +try:
 +from jarabe.model import speech
 +except:
 +logging.error('Text to speech no avalable: error loading dependencies')
 +tts_available = False

We should not use unqualified except: (i.e. catching _all_ exceptions)
except in very rare circumstances. You expect a specific set of
exceptions, so catch only those. Catching everything else only hides
problems. It may be necessary to catch the low-level exception in
jarabe.model.speech.SpeechManager and raise a different one (maybe
even a custom one) instead. We don't want implementation details of
jarabe.model.speech leaking into other components. That's the whole
purpose of a model.

Just importing the module should not raise an exception. Only
accessing the singleton instance provided by the module (via
get_speech_manager()) should. A quick inspection of
jarabe.model.speech suggests it already works (resp. fails) that way,
so I'm not sure whether you've actually tested your patch.

Since TTS support is optional, we should only log a warning, not an
error. Nothing broke, it's just that we could offer an additional
feature if gst-plugins-espeak were available.


Thanks for working on this! It may seem superfluous to some as
everything works fine even without the patch, but having Tracebacks
in the log despite the system operating as it should makes debugging
and error feedback harder. In the long run I'd even like to inform the
user when an unexpected error occurs, because that means that the
system may break in subtle ways and the user may loose data if they
continue working. Any unexpected error (i.e. uncaught exception) is an
admission that we messed up badly and don't know what will happen
next.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)

2012-04-17 Thread Sascha Silbe
Excerpts from Sascha Silbe's message of 2012-04-11 23:40:55 +0200:

[embedded NUL in SSIDs]
 Yes, that's the one case I wanted to test but couldn't (quickly) get
 HostAP to do it.

I'm now quite sure that with the current versions, I can't get either
iwconfig (which can be used to set up a Prism 2.5 based AP at least in
open and WEP modes) or hostapd (required for WPA on Prism 2.5 and for
any AP mode on mac80211 based drivers) to use SSIDs with embedded
NULs. iwconfig supports escaping for SSIDs, but using an embedded NUL
causes truncation (possibly a driver bug). For hostapd, the
configuration can only take unescaped, literal values. I've filed a
corresponding feature request [1] upstream.

Sascha

[1] http://w1.fi/bugz/show_bug.cgi?id=441
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] [PATCH sugar] Fix shortcut for view source

2012-04-16 Thread Sascha Silbe
Excerpts from Simon Schampijer's message of 2012-04-16 10:42:39 +0200:

[extensions/globalkey/viewsource.py]
 -BOUND_KEYS = ['0xEC', 'altshiftv']
 +BOUND_KEYS = ['XF86KbdLightOnOff', 'altshiftv']

Is Keyboard light on/off really a key that we want to trigger View
Source? Maybe it's what current OLPC images call the key, but that's
fixable.

If upstream (Linux) really is averse to adding a new definition for the
gear key, the following existing one [1] sounds like a better fit:

KEY_PROPS (Display the properties of the current document [2])


That key would be better mapped to opening the Journal details view (for
the current activity session), but if there's really push-back from the
input subsystem maintainers, it would be a reasonable compromise.

Sascha

[1] 
https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=include/linux/input.h;hb=HEAD
[2] https://www.usb.org/developers/devclass_docs/Hut1_12v2.pdf (section 15.16)
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] [PATCH sugar-0.94] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)

2012-04-16 Thread Sascha Silbe
Excerpts from Sascha Silbe's message of 2012-04-10 20:39:18 +0200:
 This is a backport of 7f8ba95a66780828531eba0494e004757bf45c71.
[...]
 This backport was not tested in any way.

Tested:
- filtering on ASCII and non-ASCII parts of the name of and connecting to:
  - an unsecured AP with a UTF-8 SSID (äöü߀sugartest, HostAP)
  - an unsecured AP with an ISO-8859-1 SSID (äöüßsugartest, HostAP)
  - an unsecured AP with a non-character SSID (0d:06:f0:0d, HostAP)
  - a WEP-secured AP with a UTF-8 name (äöü߀sugartest2, HostAP)
  - a WEP-secured AP with an ISO-8859-1 name (äöüßsugartest2, HostAP)
  - a WEP-secured AP with a non-character SSID (0d:06:f0:0d, HostAP)

In each case the name was displayed correctly in
a) the palette of the AP icon in the Neighbourhood,
b) the palette of the wireless network Frame device and
c) the title of the WLAN credentials (WEP/WPA passphrase) dialog (for
   the WEP cases).


As the non-character SSID test case has caused even Sugar 0.94 to
crash without this patch, I'm going to push the fix to sucrose-0.94.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] Compiling sugar with jhbuild in Fedora 17

2012-04-15 Thread Sascha Silbe
Excerpts from Manuel Kaufmann's message of 2012-04-15 01:43:41 +0200:

 I installed Fedora 17 in my Netbook, I ran depscheck and I installed
 all the depencies to compile sugar but I'm getting this error:
 
 configure: error: Package requirements (telepathy-glib = 0.11.9) were not 
 met:
 
 No package 'telepathy-glib' found

What package exactly produced this error? I didn't find the string
'telepathy-glib' nor anything else that looked like it could throw the
above error in configure.ac of sugar, sugar-toolkit,
sugar-presence-service, sugar-base or sugar-toolkit-gtk3.


 [humitos@eulogia sugar-jhbuild]$ sudo yum install telepathy-glib
 Loaded plugins: langpacks, presto, refresh-packagekit
 Package telepathy-glib-0.18.0-1.fc17.i686 already installed and latest version
 Nothing to do
 [humitos@eulogia sugar-jhbuild]$

pkg-config files are usually part of -dev / -devel packages, so please
try installing telepathy-glib-devel.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] jhbuild in Ubuntu

2012-04-14 Thread Sascha Silbe
Excerpts from Manuel Kaufmann's message of 2012-04-14 09:19:48 +0200:

 I've just installed Ubuntu 11.10 in my netbook and I tried to compile
 Sugar on it. I'm getting this error:
 
 humitos@eulogia:~/sugar-jhbuild$ ./sugar-jhbuild depscheck
 Warning: unknown distro version, automatic fallback to unstable.
 ERROR: Dependencies information is missing (unknown distribution/version).

Ubuntu is currently unsupported for sugar-jhbuild [1]. The automatic
fallback to unstable message is misleading for Ubuntu, so I've
removed it now (commit df7bd66).

While Ubuntu is based on Debian, they've added problems of their own
that make running Sugar on Ubuntu a PITA (see e.g. [2]) and have shown
no interest of fixing them for several _years_ (which equates to a large
number of releases). For this reason, I'm not spending any more time
myself on getting sugar-jhbuild to work on Ubuntu.

Sascha

[1] 
https://wiki.sugarlabs.org/go/Development_Team/Jhbuild/Ubuntu#Supported_versions
[2] https://bugs.launchpad.net/ubuntu/+bug/325706
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] Running an activity through ssh

2012-04-13 Thread Sascha Silbe
Excerpts from Manuel Kaufmann's message of 2012-04-13 18:07:51 +0200:

 I'm trying to run an Activity over ssh -C -X to my XO.
[...]
 Is there a way to do this?

Sugar and the Gnome platform it builds on generally assume there's a
single, local, graphical session. In particular, the D-Bus session bus
is used for IPC (e.g. data store access, Collaboration, even some
interactions between Activities and the Shell).

If you're feeling adventurous, you can try using the D-Bus session bus
of the Sugar session, but still running the Activity a) outside the
Sugar session (POSIX session id, some environment variables etc. are
different) and b) on a different display (the one forwarded by ssh). I'm
using the method below to access the data store remotely, but never
tried anything more advanced (like running an Activity).

Put the following inside your X session script:

{{{
echo DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS  
~/.sugar/dbus-session-bus-address.sh
}}}

The X session script is ~/.xsession on most distros, but OLPC OS uses a
custom display manager called olpc-dm and IIRC there was something
peculiar about the way it treated ~/.xsession, which may (or may not)
prevent the above from working as expected. You may have better luck
sticking it into ~/.sugar/debug. That file isn't meant for this kind of
usage, but it currently works.

Then from your SSH session source the file created above and export
DBUS_SESSION_BUS_ADDRESS so applications can connect to the D-Bus
session bus:

{{{
. ~/.sugar/dbus-session-bus-address.sh
export DBUS_SESSION_BUS_ADDRESS
}}}


I used to have a ~/.ssh/rc that read
~/.sugar/dbus-session-bus-address.sh so I'd always use the D-Bus session
bus of the Sugar session. Unfortunately, for some reason, this broke
some time ago: environment variables set in ~/.ssh/rc don't get
propagated to the user shell anymore. But if you really wanted to
automate it, you could update ~/.ssh/environment from within ~/.xsession
or ~/.sugar/debug.

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)

2012-04-11 Thread Sascha Silbe
Excerpts from Martin Langhoff's message of 2012-04-10 21:43:20 +0200:

 There is only one thing that still worries me. According to the spec,
 the ESSID may also contain nulls in the middle of the array. I don't
 know how NM handles such cases in its communication with nm-client via
 d-bus. I don't know even how to setup an AP to broadcast an ESSID with
 a null embedded.

Yes, that's the one case I wanted to test but couldn't (quickly) get
HostAP to do it. It would be good to check this on an XO to be sure
it's not exploitable (DoS). Sugar (with my patch), Python and D-Bus
should handle it correctly (see preview PNG data in data store
metadata for a similar situation) and I'm more worried about drivers
than about NM. That's also why I didn't put more energy into it (with
my SL hat on - testing the 0.94 backport is still ongoing): we can't
test the large number of different wireless drivers, even if we do
manage to create a suitable test environment. I also doubt that
anybody _not_ interested in breaking things (for fun or for profit)
would set up an AP with an embedded-NUL SSID, and there's got to be a
whole bunch of easier ways to hack an F14 system (which is the most
recent distro most XOs in deployments are going to be running) than
using a 32-byte octet sequence that may contain embedded NULs. It
would be a rather interesting challenge, though. :)

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] doc sprint data save

2012-04-10 Thread Sascha Silbe
Excerpts from Bernie Innocenti's message of 2012-04-10 17:45:50 +0200:

 Start Sugar with this datastore and you'll see a few corrupted objects
 in the Journal. Perhaps Mark can describe what he did to get them (if
 anything).

I don't see anything unusual in the Journal and no errors in the logs
(backup or recent) when transplanting the data store into a system
running latest Sugar (sugar-jhbuild) inside a Debian Wheezy
chroot. Can you provide me with a raw disk image (using dd) of the
entire SoaS installation so I can try reproducing it in a VM?

Can you check /var/log/kern.log (or whatever the SoaS equivalent is)
to make sure there was no problem accessing permanent storage (AKA
hard disk), please?

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


[Sugar-devel] [PATCH sugar-0.94] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)

2012-04-10 Thread Sascha Silbe
This is a backport of 7f8ba95a66780828531eba0494e004757bf45c71.

IEEE 802.11 [2] defines the SSID as a sequence of octets (i.e. bytes), but
Sugar treated it as UTF-8 character data. While in most cases the SSID is
actually some human-readable string, there's neither a guarantee for that nor
does any (de-facto or de-jure) standard specify the encoding to use. As a
result, we'll encounter SSIDs in a large variety of encodings and will also
need to cope with arbitrary byte strings. Any assumption of a single (or in
fact any) character encoding is incorrect.

The D-Bus API of NetworkManager 0.9 [3] passes SSIDs as uninterpreted byte
strings (D-Bus signature ay). Before SSIDs can be displayed on screen, some
kind of interpretation must happen.

NetworkManager has a rather elaborate heuristic that takes the user locale into
account. In the future (i.e. when the NetworkManager client code in Sugar has
been ported to gobject-introspection) we may use nm_utils_ssid_to_utf8() [4],
but for now we're doing the following to allow the user to use non-UTF-8 APs at
all:

1. If the SSID is a valid character string consisting only of
   printable characters in one of the following encodings (tried in
   the given order), decode it accordingly:
   UTF-8, ISO-8859-1, Windows-1251.

2. Return a hex dump of the SSID.

The first rule should cover the majority of current Sugar users and hopefully
all AP vendors will switch to UTF-8 eventually. In the meantime, the second
rule allows users to distinguish between several APs with SSIDs in unknown
encodings (or even using arbitrary byte sequences that don't _have_ a character
representation).

This backport was not tested in any way.

[1] https://bugs.sugarlabs.org/ticket/2023
[2] http://standards.ieee.org/getieee802/download/802.11-2007.pdf
[3] http://projects.gnome.org/NetworkManager/developers/api/09/spec.html
[4] 
http://projects.gnome.org/NetworkManager/developers/libnm-util/09/libnm-util-nm-utils.html#nm-utils-ssid-to-utf8

Signed-off-by: Sascha Silbe si...@activitycentral.com
---
 extensions/deviceicon/network.py   |   17 +++--
 src/jarabe/desktop/keydialog.py|5 ++--
 src/jarabe/desktop/meshbox.py  |4 +--
 src/jarabe/desktop/networkviews.py |   32 +++
 src/jarabe/model/adhoc.py  |6 ++---
 src/jarabe/model/network.py|   49 +---
 6 files changed, 80 insertions(+), 33 deletions(-)

diff --git a/extensions/deviceicon/network.py b/extensions/deviceicon/network.py
index 789ea13..713a741 100644
--- a/extensions/deviceicon/network.py
+++ b/extensions/deviceicon/network.py
@@ -385,7 +385,8 @@ class WirelessDeviceView(ToolButton):
 self._device = device
 self._device_props = None
 self._flags = 0
-self._name = ''
+self._ssid = ''
+self._display_name = ''
 self._mode = network.NM_802_11_MODE_UNKNOWN
 self._strength = 0
 self._frequency = 0
@@ -405,7 +406,7 @@ class WirelessDeviceView(ToolButton):
 self._icon.show()
 
 self.set_palette_invoker(FrameWidgetInvoker(self))
-self._palette = WirelessPalette(self._name)
+self._palette = WirelessPalette(self._display_name)
 self._palette.connect('deactivate-connection',
   self.__deactivate_connection_cb)
 self.set_palette(self._palette)
@@ -482,7 +483,8 @@ class WirelessDeviceView(ToolButton):
 self._mode = properties['Mode']
 self._color = None
 if 'Ssid' in properties:
-self._name = properties['Ssid']
+self._ssid = properties['Ssid']
+self._display_name = network.ssid_to_display_name(self._ssid)
 self._color = None
 if 'Strength' in properties:
 self._strength = properties['Strength']
@@ -493,11 +495,11 @@ class WirelessDeviceView(ToolButton):
 
 if self._color == None:
 if self._mode == network.NM_802_11_MODE_ADHOC and \
-network.is_sugar_adhoc_network(self._name):
+network.is_sugar_adhoc_network(self._ssid):
 self._color = profile.get_color()
 else:
 sha_hash = hashlib.sha1()
-data = self._name + hex(self._flags)
+data = self._ssid + hex(self._flags)
 sha_hash.update(data)
 digest = hash(sha_hash.digest())
 index = digest % len(xocolor.colors)
@@ -519,7 +521,8 @@ class WirelessDeviceView(ToolButton):
 else:
 self._icon.props.badge_name = None
 
-self._palette.props.primary_text = glib.markup_escape_text(self._name)
+label = glib.markup_escape_text(self._display_name)
+self._palette.props.primary_text = label
 
 self._update_state()
 self._update_color()
@@ -531,7 +534,7 @@ class WirelessDeviceView(ToolButton):
 state = network.DEVICE_STATE_UNKNOWN

Re: [Sugar-devel] [PATCH sugar] Fix Traceback when connecting to a network for the first time

2012-04-10 Thread Sascha Silbe
Excerpts from Daniel Drake's message of 2012-04-03 19:17:14 +0200:

 Looks good to me, thanks

Thanks for the review! Pushed as 7f8ba95 [1] to master.

Sascha

[1] 
https://git.sugarlabs.org/sugar/mainline/commit/7f8ba95a66780828531eba0494e004757bf45c71
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)

2012-04-10 Thread Sascha Silbe
Excerpts from Daniel Drake's message of 2012-04-03 19:22:52 +0200:

 Had a quick read through the patch, looks good.

Thanks for the review! Pushed as 7f8ba95 [1] to master. Backport to
0.94 prepared [2], but not tested yet.

Sascha

[1] 
https://git.sugarlabs.org/sugar/mainline/commit/7f8ba95a66780828531eba0494e004757bf45c71
[2] https://patchwork.sugarlabs.org/patch/1348/
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] [PATCH sugar] Fix Traceback when connecting to a network for the first time

2012-04-10 Thread Sascha Silbe
Excerpts from Sascha Silbe's message of 2012-04-10 21:18:29 +0200:

 Thanks for the review! Pushed as 7f8ba95 [1] to master.

Sorry, this should have read b0cd1c [2].

Sascha

[2] 
https://git.sugarlabs.org/sugar/mainline/commit/b0cd1c99318f5fd95d254b263cd53b3f852c527a
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


[Sugar-devel] [PATCH sugar] Fix Traceback when connecting to a network for the first time

2012-04-02 Thread Sascha Silbe
When connecting to a network that we don't have settings for yet, the following
Traceback was logged:

Traceback (most recent call last):
  File /usr/lib/python2.7/dist-packages/dbus/connection.py, line 586, in 
msg_reply_handler
reply_handler(*message.get_args_list(**get_args_opts))
TypeError: _activate_reply_cb() takes exactly 1 argument (2 given)

This is because the same set of callbacks was used for both
ActivateConnection() and AddAndActivateConnection() even though they return
different sets of values.

Signed-off-by: Sascha Silbe si...@activitycentral.com
---
 I already hit this once while reviewing the original NM 0.9 patch,
 but could never reproduce it. Now I know why: the call succeeded, so
 any further connect attempt re-used the existing connection,
 triggering the code path with the correct number of arguments.

 src/jarabe/model/network.py |   21 +++--
 1 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/src/jarabe/model/network.py b/src/jarabe/model/network.py
index af510e1..40eb6d0 100644
--- a/src/jarabe/model/network.py
+++ b/src/jarabe/model/network.py
@@ -728,14 +728,22 @@ def get_secret_agent():
 return _secret_agent
 
 
-def _activate_reply_cb(connection):
-logging.debug('Activated connection: %s', connection)
+def _activate_reply_cb(connection_path):
+logging.debug('Activated connection: %s', connection_path)
 
 
 def _activate_error_cb(err):
 logging.error('Failed to activate connection: %s', err)
 
 
+def _add_and_activate_reply_cb(settings_path, connection_path):
+logging.debug('Added and activated connection: %s', connection_path)
+
+
+def _add_and_activate_error_cb(err):
+logging.error('Failed to add and activate connection: %s', err)
+
+
 class Connection(gobject.GObject):
 __gsignals__ = {
 'removed': (gobject.SIGNAL_RUN_LAST, gobject.TYPE_NONE, ()),
@@ -900,10 +908,11 @@ def activate_connection_by_path(connection, device_o,
 
 
 def add_and_activate_connection(device_o, settings, specific_object):
-get_manager().AddAndActivateConnection(settings.get_dict(), device_o,
-   specific_object,
-   reply_handler=_activate_reply_cb,
-   error_handler=_activate_error_cb)
+manager = get_manager()
+manager.AddAndActivateConnection(settings.get_dict(), device_o,
+ specific_object,
+ reply_handler=_add_and_activate_reply_cb,
+ error_handler=_add_and_activate_error_cb)
 
 
 def _migrate_old_wifi_connections():
-- 
1.7.9

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


[Sugar-devel] [PATCH sugar] Don't treat SSID as UTF-8 character sequence (fixes SL#2023)

2012-04-02 Thread Sascha Silbe
IEEE 802.11 [2] defines the SSID as a sequence of octets (i.e. bytes), but
Sugar treated it as UTF-8 character data. While in most cases the SSID is
actually some human-readable string, there's neither a guarantee for that nor
does any (de-facto or de-jure) standard specify the encoding to use. As a
result, we'll encounter SSIDs in a large variety of encodings and will also
need to cope with arbitrary byte strings. Any assumption of a single (or in
fact any) character encoding is incorrect.

The D-Bus API of NetworkManager 0.9 [3] passes SSIDs as uninterpreted byte
strings (D-Bus signature ay). Before SSIDs can be displayed on screen, some
kind of interpretation must happen.

NetworkManager has a rather elaborate heuristic that takes the user locale into
account. In the future (i.e. when the NetworkManager client code in Sugar has
been ported to gobject-introspection) we may use nm_utils_ssid_to_utf8() [4],
but for now we're doing the following to allow the user to use non-UTF-8 APs at
all:

1. If the SSID is a valid character string consisting only of
   printable characters in one of the following encodings (tried in
   the given order), decode it accordingly:
   UTF-8, ISO-8859-1, Windows-1251.

2. Return a hex dump of the SSID.

The first rule should cover the majority of current Sugar users and hopefully
all AP vendors will switch to UTF-8 eventually. In the meantime, the second
rule allows users to distinguish between several APs with SSIDs in unknown
encodings (or even using arbitrary byte sequences that don't _have_ a character
representation).

Tested:
- filtering on ASCII and non-ASCII parts of the name of and connecting to:
  - an unsecured AP with a UTF-8 SSID (äöü߀sugartest, HostAP)
  - an unsecured AP with an ISO-8859-1 SSID (äöüßsugartest, HostAP)
  - an unsecured AP with a non-character SSID (0d:06:f0:0d, HostAP)
  - a WEP-secured AP with a UTF-8 name (äöü߀sugartest2, HostAP)
  - a WEP-secured AP with an ISO-8859-1 name (äöüßsugartest2, HostAP)
  - a WEP-secured AP with a non-character SSID (0d:06:f0:0d, HostAP)
  - a WPA-secured AP with an ASCII name (COTS AP)

In each case the name was displayed correctly in
a) the palette of the AP icon in the Neighbourhood,
b) the palette of the wireless network Frame device and
c) the title of the WLAN credentials (WEP/WPA passphrase) dialog (for
   the WEP/WPA cases).

[1] https://bugs.sugarlabs.org/ticket/2023
[2] http://standards.ieee.org/getieee802/download/802.11-2007.pdf
[3] http://projects.gnome.org/NetworkManager/developers/api/09/spec.html
[4] 
http://projects.gnome.org/NetworkManager/developers/libnm-util/09/libnm-util-nm-utils.html#nm-utils-ssid-to-utf8

Signed-off-by: Sascha Silbe si...@activitycentral.com
---
 extensions/deviceicon/network.py   |   17 +++-
 src/jarabe/desktop/keydialog.py|5 ++-
 src/jarabe/desktop/meshbox.py  |4 +-
 src/jarabe/desktop/networkviews.py |   33 ---
 src/jarabe/model/adhoc.py  |6 ++--
 src/jarabe/model/network.py|   49 +--
 6 files changed, 81 insertions(+), 33 deletions(-)

diff --git a/extensions/deviceicon/network.py b/extensions/deviceicon/network.py
index 1beeb88..09a3abb 100644
--- a/extensions/deviceicon/network.py
+++ b/extensions/deviceicon/network.py
@@ -374,7 +374,8 @@ class WirelessDeviceView(ToolButton):
 self._device = device
 self._device_props = None
 self._flags = 0
-self._name = ''
+self._ssid = ''
+self._display_name = ''
 self._mode = network.NM_802_11_MODE_UNKNOWN
 self._strength = 0
 self._frequency = 0
@@ -394,7 +395,7 @@ class WirelessDeviceView(ToolButton):
 self._icon.show()
 
 self.set_palette_invoker(FrameWidgetInvoker(self))
-self._palette = WirelessPalette(self._name)
+self._palette = WirelessPalette(self._display_name)
 self._palette.connect('deactivate-connection',
   self.__deactivate_connection_cb)
 self.set_palette(self._palette)
@@ -471,7 +472,8 @@ class WirelessDeviceView(ToolButton):
 self._mode = properties['Mode']
 self._color = None
 if 'Ssid' in properties:
-self._name = properties['Ssid']
+self._ssid = properties['Ssid']
+self._display_name = network.ssid_to_display_name(self._ssid)
 self._color = None
 if 'Strength' in properties:
 self._strength = properties['Strength']
@@ -482,11 +484,11 @@ class WirelessDeviceView(ToolButton):
 
 if self._color == None:
 if self._mode == network.NM_802_11_MODE_ADHOC and \
-network.is_sugar_adhoc_network(self._name):
+network.is_sugar_adhoc_network(self._ssid):
 self._color = profile.get_color()
 else:
 sha_hash = hashlib.sha1()
-data = self._name + hex(self._flags

Re: [Sugar-devel] Local server equivalent of jabber.sugarlabs.org

2012-04-02 Thread Sascha Silbe
Excerpts from Ajay Garg's message of 2012-03-29 06:55:19 +0200:

 I am wanting to play around with a Jabber server, which is same in the
 basics as jabber.sugarlabs.org.
 So, what should I install locally? jabberd? ejabberd? any other server?

Depends on what exactly you want. Possibilities:

1. Some XMPP server that works with Sugar.

   Install ejabberd from distro packages and set up the shared roster
   groups [1]. This is what I did for my own personal server.

2. A server that mimics what most schools are going to have.

   Install XS-on-XO. I didn't get the non-XO variant to work (inside a
   VM), but XS-on-XO-1 worked fine the last time I tried it.

3. A replica of jabber.sugarlabs.org to debug problems with it.

   Ask Aleksey. AFAIK jabber.sl.o is running some patched version of
   Prosody.


Sascha

[1] 
http://wiki.laptop.org/go/XS_Installing_Software_0.5#Setup_Shared_Roster_Groups_for_ejabberd
[2] http://wiki.laptop.org/go/XS-on-XO
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] [PATCH sugar] Do not display APs that announce the ssid in invalid utf-8 data, OLPC #11698

2012-03-27 Thread Sascha Silbe
Excerpts from Simon Schampijer's message of 2012-03-27 10:19:30 +0200:

 Sugar is not doing well in dealing with non-utf8 data. If an AP
 does not announce the ssid in valid utf-8 data Sugar will fail in
 certain ways.

That's an odd way to put it. The actual problem is that - similar to
POSIX file systems - IEEE 802.11 [7] only defines the SSID to be a
sequence of octets (i.e. bytes), but Sugar treats it as UTF-8 character
data. While in most cases the SSID is actually some human-readable
string, there's neither a guarantee for that nor does any (de-facto or
de-jure) standard specify the encoding to use. As a result, we'll
encounter SSIDs in a large variety of encodings and will also need to
cope with arbitrary byte strings. Any assumption of a single (or in fact
any) character encoding is incorrect.

The D-Bus API of NetworkManager 0.9 [8] passes SSIDs as uninterpreted
byte strings (D-Bus signature ay). Before SSIDs can be displayed on
screen, some kind of interpretation must happen. A hex dump would be the
most straightforward and simple approach, but also the least useful to
users (for obvious reasons).

networkmanager-applet (and probably its successor in the Gnome 3 Shell)
uses nm_utils_ssid_to_utf8() [9] from libnm-util to get a display name
(in UTF-8) for a given SSID. This functions contains a set of heuristics
to interpret the SSID and should produce useful results in the majority
of cases where the user has the same language configured as the operator
of the access point. Arguably it could do even better by falling back to
hex escapes (rather than a question mark) for bytes that cannot be
converted to a UTF-8 character (because all heuristics failed or it
simply isn't a representation of a character), but hopefully those are
rare enough in practice not to matter.

Some of this has already been discussed (by yourself and others) in
SL#2023 [6]; I'm surprised that ticket wasn't referenced in the
description as it's the relevant upstream (i.e. Sugar Labs) ticket.


 In some cases Sugar will crash when feeded non utf-8 compliant data,
 as ssid which segfaults glib.markup_escape_text when trying to display
 the ssid: glib.markup_escape_text does assume correct utf8 data to be
 passed [3].

While it doesn't explicitly state that assumption in the docs you cite,
it also doesn't promise to handle non-UTF-8 data properly. Seems we need
another round of inspecting the code for potential sources of invalid
data and catch malformed UTF-8 strings.


 The patch does check early when the AP is announced by NM and verify
 that we do have a ssid with valid utf-8 data. If not, we don't display
 the AP and log a debug message.

That may be a reasonable stopgap measure downstream for the crash you
encounter [2], but I don't think we should do this upstream. Assuming
UTF-8 is simply incorrect; the way we currently handle it and the way
you propose both mean users are rendered unable to use the access points
in question (rather than just visual artifacts). While it's technically
not a regression, we should fix it properly rather than putting a small
band-aid on a major hole.

I can imagine the following approaches:

1. Use nm_utils_ssid_to_utf8() via gobject-instrospection:

from gi.repository import NetworkManager
print unicode(NetworkManager.utils_ssid_to_utf8(list(äöüß)), 'utf-8')
   äöüß

   We know that PyGTK and GTK3 via gobject-introspection shouldn't be
   mixed inside a single process; does that apply to mixing PyGTK with
   gobject-introspection in general or would calling a self-contained
   utility function be fine?

2. Use nm_utils_ssid_to_utf8() via ctypes.

   I didn't get this to work within a few minutes (returns an empty
   string), but I don't see any fundamental reason this shouldn't work.

3. Duplicate (a subset of) nm_utils_ssid_to_utf8() in Sugar.

   It should be pretty straightforward to write a Python function that
   can at least handle the most common cases. At the very least we can
   do a hex dump for non-UTF-8 strings, that would be only slightly more
   complex than your patch.


Sascha

 [1] 
 http://developer.gnome.org/libnm-util/unstable/libnm-util-nm-utils.html#nm-utils-ssid-to-utf8
 [2] http://dev.laptop.org/ticket/11698
 [3] 
 http://developer.gnome.org/pygobject/stable/glib-functions.html#function-glib--markup-escape-text
 [4] https://bugzilla.gnome.org/show_bug.cgi?id=672546
 [5] 
 http://developer.gnome.org/glib/2.30/glib-Unicode-Manipulation.html#g-utf8-validate
[6] https://bugs.sugarlabs.org/ticket/2023
[7] http://standards.ieee.org/getieee802/download/802.11-2007.pdf (section 
7.3.2.1)
[8] http://projects.gnome.org/NetworkManager/developers/api/09/spec.html
[9] 
http://projects.gnome.org/NetworkManager/developers/libnm-util/09/libnm-util-nm-utils.html#nm-utils-ssid-to-utf8
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


signature.asc
Description: PGP signature
___
Sugar-devel mailing list

Re: [Sugar-devel] Mobile dongles - XO-1 with release 11.3.0

2012-03-26 Thread Sascha Silbe
Excerpts from David Leeming's message of 2012-03-26 04:22:46 +0200:

 I have one old ZTE DC87 modem locked to Digicel that I have tried. I added
 the APN to the modem configuration. When plugged in, Sugar recognises a
 wireless modem is plugged in and shows the icon on the frame. If I click
 connect it tells me no GSM connection is available.

Make sure you fill in all of Username, Number and Access Point Name
(APN), even if your setup doesn't require them. Sugar  0.94 refused
to use incomplete settings (SL#3321 [1], OLPC-AU#1018 [2]).

If your ISP doesn't require authentication, you can pick any user
name. The number for the default connection is *99# (without the
quotes).

Sascha

[1] https://bugs.sugarlabs.org/ticket/3321
[2] https://dev.laptop.org.au/issues/1018
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] Changing the prompt when inside a Sugar shell

2012-03-26 Thread Sascha Silbe
Excerpts from Manuel Quiñones's message of 2012-03-25 20:47:14 +0200:

 what about changing the prompt when doing:
 
 ./sugar-jhbuild shell
 
 Is a bit confusing for me to know which tabs in my GNOME Terminal are
 inside Sugar shells.  I often end calling env and checking for the
 current environment variables.

Good idea. Can you file a ticket upstream [1], please?

Sascha

[1] https://bugzilla.gnome.org/enter_bug.cgi?product=jhbuild
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


[Sugar-devel] [PATCH v2 sugar] Recreate corrupted key pair (fixes SL#1568)

2012-03-26 Thread Sascha Silbe
Recreate a corrupted key pair instead of leaving it alone and failing horribly
later.

This case was encountered two years ago (OLPC#9612 [2]) and recently again
in Nicaragua.

[1] https://bugs.sugarlabs.org/ticket/1568
[2] https://dev.laptop.org/ticket/9612

Signed-off-by: Sascha Silbe si...@activitycentral.com
Signed-off-by: Daniel Drake d...@laptop.org
Reviewed-by: James Cameron qu...@laptop.org
---
 v1-v2: updated my email address, fixed some minor style issues

 Thanks to Daniel for digging this up! We indeed forgot to review and apply
 the sugar part of the patch series.

 src/jarabe/intro/window.py |   27 ---
 1 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/src/jarabe/intro/window.py b/src/jarabe/intro/window.py
index f7937b1..a6a2a29 100644
--- a/src/jarabe/intro/window.py
+++ b/src/jarabe/intro/window.py
@@ -15,6 +15,7 @@
 # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA

 import os
+import os.path
 import logging
 from gettext import gettext as _
 import gconf
@@ -24,6 +25,7 @@ import gtk
 import gobject

 from sugar import env
+from sugar import profile
 from sugar.graphics import style
 from sugar.graphics.icon import Icon
 from sugar.graphics.xocolor import XoColor
@@ -43,16 +45,27 @@ def create_profile(name, color=None):
 client.set_string('/desktop/sugar/user/color', color.to_string())
 client.suggest_sync()

+if profile.get_pubkey() and profile.get_profile().privkey_hash:
+logging.info('Valid key pair found, skipping generation.')
+return
+
 # Generate keypair
 import commands
 keypath = os.path.join(env.get_profile_path(), 'owner.key')
-if not os.path.isfile(keypath):
-cmd = ssh-keygen -q -t dsa -f %s -C '' -N '' % keypath
-(s, o) = commands.getstatusoutput(cmd)
-if s != 0:
-logging.error('Could not generate key pair: %d %s', s, o)
-else:
-logging.error('Keypair exists, skip generation.')
+if os.path.exists(keypath):
+os.rename(keypath, keypath + '.broken')
+logging.warning('Existing private key %s moved to %s.broken',
+keypath, keypath)
+
+if os.path.exists(keypath + '.pub'):
+os.rename(keypath + '.pub', keypath + '.pub.broken')
+logging.warning('Existing public key %s.pub moved to %s.pub.broken',
+keypath, keypath)
+
+cmd = ssh-keygen -q -t dsa -f %s -C '' -N '' % (keypath, )
+(s, o) = commands.getstatusoutput(cmd)
+if s != 0:
+logging.error('Could not generate key pair: %d %s', s, o)


 class _Page(gtk.VBox):
--
1.7.9

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


Re: [Sugar-devel] [PATCH] Recreate corrupted key pair (#1568)

2012-03-26 Thread Sascha Silbe
Excerpts from James Cameron's message of 2012-03-24 01:05:57 +0100:

 Reviewed-by: James Cameron qu...@laptop.org

Thanks for the review!

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] [PATCH Maze 4/4] Save and restore state of the game

2012-03-26 Thread Sascha Silbe
Excerpts from Manuel Kaufmann's message of 2012-03-21 02:52:54 +0100:


First of all, thanks for the patch! Your help is very welcome.

Disclaimer: I'm neither the maintainer of Maze nor a regular
contributor to it. My opinions and advice may differ from what you
need to do to get your patch accepted by the Maze maintainer.


[patch description]
 The data is saved (as JSON, with simplejson module) in the 'event.filename'
 path using the 'sugar.datastore' API.

 A filename example is:
 
  ~/.sugar/default/datastore/09/0940b7eb-1cb7-4687-aa7a-ac2c174dcfd7/data

The file name is an implementation detail of the current version of
sugar-datastore and shouldn't usually be mentioned in the commit
message of an unrelated component.


[game.py]
 @@ -23,13 +23,23 @@
  
  import sys
  import time
 -
 +import simplejson
[...]

At least in Glucose [1], we're trying to get rid of simplejson. If you
want Maze to continue to run on systems that don't have Python 2.6
yet, you can do the following to use the standard json module on
modern systems and fall back to simplejson on older ones:

try:
import json
except ImportError:
import simplejson as json


 +import tempfile
 +import shutil
  import pygame
 +import olpcgames
 +
 +import logging
 +log = logging.getLogger('Maze')
 +log.setLevel(logging.DEBUG)
 +logging.basicConfig()

sugar-activity will already initialise the logging subsystem for you,
so no need for the setLevel() and basicConfig() calls.

To set the log level, you can set the environment variable
SUGAR_LOGGER_LEVEL. There are generally three ways to do that:

1. In ~/.sugar/debug (contains commented-out examples).

   Easiest to do, affects all new Sugar sessions, works even if Sugar
   is started directly by the display manager.

2. Setting it in your shell before starting Sugar.

   Only affects the about-to-be-started Sugar session, which may be
   exactly what you want (in some cases).

3. Setting it in the Terminal (activity) shell before starting an
   activity session manually using sugar-activity.

   Only affects the about-to-be-started activity session, not Glucose
   or other activities.


[...]
[MazeGame.__init__()]
 -# start with a small maze using a seed that will be different
 -# each time you play
 -self.maze = Maze(int(time.time()), int(9 * self.aspectRatio), 9)
 -self.reset()
 +# no data is known yet (maybe the user is resuming a state or
 +# launching a new instance)
 +self.data = None
 +

See below for comments regarding this change.


 @@ -283,8 +293,42 @@ class MazeGame:
  (event, sys.exc_info())
  else:
  print Message from unknown buddy?
 +
 +elif event.type == pygame.USEREVENT:
 +# process fil save / restore events

typo: file


 +if event.code == olpcgames.FILE_READ_REQUEST:
 +log.debug(event)

The first argument to the log.level family of functions is a format
string. If you wish to log the value of some variable, you should use
%s or %r in the format string and pass the variable as second+ parameter:

log.debug('event=%r', event)

Depending on what exactly you're logging, this mistake may even be
exploitable [2,3], similar to printf() exploits with C.


 +log.debug('Loading the state of the game...')
 +self.data = simplejson.loads(open(event.filename, 
 'r').read())
 +log.debug('Loaded data: %s' % self.data)
 +return True

Why do you store the intermediate data, rather than passing it to a
Maze instance (that has previously been instantiated with default
values) or creating a new instance right away?


 +elif event.code == olpcgames.FILE_WRITE_REQUEST:
 +log.debug(event)
 +log.debug('Saving the state of the game...')
 +data = {'seed': self.maze.seed,
 +'width': self.maze.width,
 +'height': self.maze.height,
 +}
 +log.debug('Saving data: %s' % data)

As explained above, log.level can do the formatting for you:

log.debug('Saving data: %s', data)

The advantage of this is that the formatting is only do if this line
actually gets logged, providing a minor performance benefit on systems
that don't have debug logging enabled.


 +file_dsobject = datastore.create()
 +file_dsobject.metadata = event.metadata

You're creating a new Journal entry every time, rather than updating
an existing entry. This will result in Journal spam as activities are
expected to save their state whenever you switch away from them. It
also won't match the behaviour outlined in the Human Interface
Guidelines (HIG [4]) and implemented by other Sugar activities.

sugar.activity.activity.Activity already implements all of the logic
you need and AFAICT it should work similarly with olpcgames. 

[Sugar-devel] Gonzalo added as moderator in Trac (was: Re: Moderation on bugs.sl.o)

2012-03-26 Thread Sascha Silbe
Excerpts from Gonzalo Odiard's message of 2012-03-20 21:44:17 +0100:

 If you want, add me to the list.
 I think is important try to responsive with our possible volunteers.

Done. You should now see additional menu items Moderator and Admin
in Trac. Moderator (suffixed with the number of pending requests if
there are any) shows the moderation queue. You can inspect individual
requests and approve / reject them individually or in bulk.

Admin - General / Permissions should allow you to add users to the
group unmoderated (for real users) resp. spammer. I'm doing the same
using shell scripts as I have CLI access to Trac. If the volume went
high enough for this to be a significant nuisance, we could try hacking
the TicketModerator plugin to adjust the permissions automatically, but
so far it hasn't been worth the effort.

Your new permissions allow you to do more than just the above (probably
including elevating your own privileges); the general policy of the SL
infrastructure team is to trust people not to abuse their power rather
than impeding their work.

Thanks for volunteering!

Sascha

-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


Re: [Sugar-devel] Error on run sugar-emulator

2012-03-26 Thread Sascha Silbe
Excerpts from Manuel Kaufmann's message of 2012-03-26 21:16:37 +0200:

   File 
 /srv/sugar-jhbuild/install/lib/python2.7/site-packages/jarabe/desktop/homebox.py,
 line 294, in _update_icon
 self.props.named_icon = favoritesview.LAYOUT_MAP[self._layout]\
 KeyError: None
 1332789278.997674 DEBUG root: _cleanup_temp_files
 [humitos] [/srv/sugar-jhbuild]$
 
  ~/.sugar/default/logs/shell.log 
 
 
 I don't know what to do. I want to revise my Maze's patch but I can't
 because I'm not able to run sugar-emulator.
 
 By the way, I'm running Debian Testing.

Looks like you ran into Debian#648724 [1] again. Do you still have the
local packages with the fix or should I publish mine (amd64, armel,
i386)?

Sascha

[1] http://bugs.debian.org/648724
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/


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


  1   2   3   4   5   6   7   8   9   10   >