[Sugar-devel] Stepping down as Sugar maintainer
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
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
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
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
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
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
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)
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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?
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
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
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
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
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
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
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
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)
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)
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
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
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)
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
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
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
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
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
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)
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?
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
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
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
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
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
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
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))
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
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
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)
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)
[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
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
[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
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
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
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
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
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
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
=?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
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
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
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
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)
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
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
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
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
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
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
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)
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
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)
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
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
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
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)
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
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)
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
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)
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
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
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)
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
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
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
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
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)
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)
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
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)
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
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
Re: [Sugar-devel] Read and Browse dependencies (was: Re: error in ./sugar-jhbuild update)
Excerpts from Gonzalo Odiard's message of 2012-03-14 04:26:09 +0100: Read depends on evince 3.3.2.(And evince 3.3.2 depends on glib 2.31.0 Thanks, that was an important missing piece of the mosaic. What Read needs (at runtime) is the following gobject introspection files of Evince = 3.3.2, GStreamer and WebKit, usually located in /usr/lib/girepository-1.*: EvinceDocument-3.0.typelib EvinceView-3.0.typelib Gst-0.10.typelib WebKit-3.0.typelib In addition Read needs GDK/GTK/... introspection files, but we require all of those for sugar-toolkit-gtk3 already (distro maintainers may want to add explicit dependencies regardless). 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
