Re: [Sugar-devel] [ASLO] Problem with number of version
On Fri, Jul 20, 2012 at 7:39 AM, Walter Bender wrote: > Even so, how do we get the patch into the field? My suspicion is that it is already deployed in the 0.84 releases that went into the field - but someone will have to check, because I might be talking nonsense. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Proposal: Lease expiry information display in My Settings -> About My Computer
On Wed, Jul 18, 2012 at 12:07 PM, Anish Mangal wrote: > I would like to propose a feature for discussion and inclusion in the > 0.98 cycle. > > http://wiki.sugarlabs.org/go/Features/Lease_Information_Display > > This feature is valuable for support staff in deployments which use > OLPC's security system built on the XO laptops, and was specifically > requested by the OLPC deployment in Paraguay. I read the feature page, and I don't really understand the use case or problem that needs to be solved. I'm not convinced that changing sugar is the right answer, especially when this only affects support staff, not regular users. The feature page discusses the case when the lease has expired, but this seems like quite the corner case to me. Assuming that XO laptops are booted and shutdown on a daily basis, this bit of information would only be shown when the following happens: - The XO is booted in the morning - The lease expires shortly after boot - A support staff member happens to pick up that laptop that same day, before the laptop gets shut down, and opens "About my computer" Any member of support staff that deals with leases is going to need to be a little bit familiar with the lease.sig format and location. So running "cat /security/lease.sig" at the terminal can show the same information - its a little bit technical, but again, familiarity is required for this role anyway. For the rare occasions when leases need to be checked, running this command at a terminal suffices here in Nicaragua at least. It is harder to read the expiry of a sig02 lease from catting the file, but as far as I know those aren't used in Paraguay. If the format is too difficult then perhaps a command line tool in bitfrost would be a better solution. >From a technical perspective, the implementation would need to either be quite hacky (parsing lease.sig directly) or use bitfrost. Using bitfrost libraries would be OK but the feature page should note that this now becomes a dependency of sugar. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [sugar PATCH] sl#3326: Do not attach any signals to the dangling-connection-object after it has called the "__connection_ready_cb" callback.
On Wed, Jul 25, 2012 at 2:52 PM, Ajay Garg wrote: > Thanks to Jerry Vonau, for inspiring and guiding me to solve this :-) Thanks for working on this! > src/jarabe/model/neighborhood.py | 19 +++ > 1 files changed, 19 insertions(+), 0 deletions(-) > > diff --git a/src/jarabe/model/neighborhood.py > b/src/jarabe/model/neighborhood.py > index 39f648e..5692ca9 100644 > --- a/src/jarabe/model/neighborhood.py > +++ b/src/jarabe/model/neighborhood.py > @@ -260,6 +260,25 @@ class _Account(gobject.GObject): > > ready_handler=self.__connection_ready_cb) > > def __connection_ready_cb(self, connection): > +# http://bugs.sugarlabs.org/ticket/3326 > +# > +# Daniel Drake has given a comprehensive description of the > +# issue. So the fix is that, when the > +# dangling-connection-object calls the "__connection_ready_cb", > +# check to see if it is the same as the referenced > +# "self._connection" object. If not, simply return; this would > +# have the following consequences :: > +# > +# (i) > +# not connect any more signals to the > +# dangling-connection-object. > +# > +# (ii) > +# the dangling-connection-object would finally be > +# garbage-collected. > +if connection != self._connection: > +return > + This probably works, but its a workaround rather than a fix. (Also, I'm doubtful that it would be garbage collected at this point. Have you verified this?) The core of the problem is that two Connection objects are created to track a single telepathy connection. A patch that addresses this would correctly solve the problem. Have you considered the approach I suggested on the ticket? Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Proposal: Contol-Panel packaging
On Thu, Jul 26, 2012 at 7:51 PM, Jerry Vonau wrote: > I would like to propose a feature for discussion and inclusion in the > 0.98 cycle is packaging all control-panel applets as rpms. As this > discussion does not impact the UI and more of a packaging issue I'm an > not creating a Features page. The discussion can take place here on the > mailing-list. This sounds like a good idea. Indeed, its not a sugar feature request, its more a packaging detail. Peter, what do you think about splitting the cpsection extensions (in /usr/share/sugar) into individual subpackages, to be selected by the Sugar Desktop group but not as direct dependencies of the Sugar packages? For F18+ Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Proposal: Lease expiry information display in My Settings -> About My Computer
On Wed, Aug 1, 2012 at 1:12 PM, Anish Mangal wrote: > One problem they were also trying to get around in Paraguay is that > during vacations, the kids don't go to the schools and hence the > leases expire. If the kids also know about this information, then they > can easily make sure that they don't get 'locked out' You'd hope that the project would make provisions for long-enough leases to be supplied before the vacations. But I can see the use for this for when that doesn't happen (which is understandable given high workloads and so on). Talking more with the team in Nicaragua, this functionality would be useful for them too. Similar situations are occuring here where laptops were activated for a certain amount of time, with the strong expectation that internet connectivity would become available in the schools before the activations expire (so that they can be automatically updated/renewed). These expectations look like they won't turn out to be true :( So a manual activation update process will happen and the ability for someone less-technical to be able to quickly check whether this manual update process has completed OK would be of value (that would be the person's only contact with activations - we aren't expecting them to be able to solve any problems if the results are bad, other than report up the chain). Anyway, the use cases you describe in your mail don't seem to be described on the feature page. Could you please extend the feature page to go into more detail about this? I'll then add the above local case if its of interest. Why is the proposal to show the number of days remaining? The Nicaraguan team have expressed a strong preference that this should (instead, or additionally) display the expiry date. When dealing with long duration activations, which is often the case (until good connectivity is established), having a teacher phone up and say "there are 137 days remaining" (and then having to calculate the day of expiry in order to put an appropriately timed school visit on the calendar) would be a pain. > Since this feature is only relevant for the XO at the moment, making > use of the bitfrost API would be acceptable to me, but I don't see a > lot wrong here by parsing the lease.sig directly. This file is > supposed to be automatically generated/updated in normal use cases. Are you planning to parse sig02 (delegated leases) "by hand" as well? What if the lease is corrupt in some way? I can see myself objecting to any implementation of this that doesn't reuse bitfrost. It takes care of all of the corner cases and will avoid code duplication. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit-gtk3] Use class-based API for gettext translations
On Tue, Aug 14, 2012 at 1:15 PM, Manuel Kaufmann wrote: > Broadly speaking, the issue is related with "merging Unicode string > with 8bits ones" and this convey many problems that are difficult to > find out and solve. In Python, is highly recommended to use Unicode > throughout the source code Personally, I'd say that recommending universal use of unicode in Python 2 is questionable. > With this patch there is no need to change the source code of all the > activities, they should work as they are. But, we can omit the import > of gettext as _ because this patch installs it as a builtin > function[1]: > > from gettext import gettext as _ So _ will suddenly change from returning a string to a unicode for all activities? That is likely to break several things, for the same reasons that we recently saw in another thread: why doesn't pygi return unicode strings for GtkEntry.get_text() and so on? The unicode mess is sorted in Python 3; it may be better to invest effort in moving that direction instead. (after a quick glance at the thread you linked to, I'm not sure what the actual problem is). Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-toolkit-gtk3] Use class-based API for gettext translations
On Tue, Aug 14, 2012 at 4:19 PM, Manuel Kaufmann wrote: >> That is likely to break several things, for the same >> reasons that we recently saw in another thread: why doesn't pygi >> return unicode strings for GtkEntry.get_text() and so on? > > Can you point me out to that thread? I didn't read it. http://bugs.sugarlabs.org/ticket/2830 > How can I help you to make it clearer? Show us an activity that fails because of this and give some details/explanation. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] higher-resolution thumbnails
On Tue, Aug 21, 2012 at 8:56 AM, Sascha Silbe wrote: >> +1 though this is raises the question of what resolution would be good >> enough. Ideally we would store images at the full display resolution, >> and try to minimise the storage space tradeoff by being more >> aggressive on compression. > > +1 on storing in native display size. Folks with larger screens tend to > have more permanent storage space, making the proportional increase in > overhead less of an issue. The XO case is going to be the most > interesting one in terms of storage overhead. Another overhead to keep in mind: if my understanding is correct, we synchronously take this screenshot on activity exit and on changing to another activity (e.g. with the frame). Saving a full-resolution screenshot (with or without compression) is likely to take quite a while on XO, especially on XO-1. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Browse] Error page SL #3500
On Tue, Sep 18, 2012 at 11:00 AM, Manuel Kaufmann wrote: > On Tue, Sep 18, 2012 at 1:55 PM, Manuel Kaufmann wrote: >> This patch contains a HTML template (error_page.tmpl) that is used to >> generate the error page with the correct language. > > Please, comments and suggestions are welcomed here. I didn't find an > existent way (inside Sugar) to translate html content, so I decide to > make it by myself. How does epiphany handle this? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Port all activities from cjson to json
Hi, With the latest sugar-toolkit release, sugar now no longer uses cjson, which has long been unmaintained and buggy, and no longer has the speed advantages that it used to (as other libraries have caught up). Any activity that uses cjson should be ported to use the 'json' module included in python. http://docs.python.org/library/json.html This list includes: Anno author CCd Chat http://bugs.sugarlabs.org/ticket/3949 Info Slicer http://bugs.sugarlabs.org/ticket/3950 Memorize http://bugs.sugarlabs.org/ticket/3951 Speak http://bugs.sugarlabs.org/ticket/3952 Anyone know of others? This is more of a FYI than anything - its low priority, and OLPC builds will include python-cjson at least until the last 4 activities listed above have been ported, which I don't expect to happen immediately. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Fix external media mounting (#3911)
The GVolumeMonitor used for mounting devices must not drop out
of scope, otherwise it will be destroyed, and no signals will be
receieved. Move it into global scope.
Update mount and unmount calls for introspection.
Remove dead code from volumestoolbar.
---
extensions/deviceicon/volume.py | 10 ++
src/jarabe/journal/volumestoolbar.py | 7 ---
src/jarabe/view/palettes.py | 8 +---
3 files changed, 11 insertions(+), 14 deletions(-)
diff --git a/extensions/deviceicon/volume.py b/extensions/deviceicon/volume.py
index ec7b2e2..fe9e0e3 100644
--- a/extensions/deviceicon/volume.py
+++ b/extensions/deviceicon/volume.py
@@ -34,6 +34,7 @@ from jarabe.frame.frameinvoker import FrameWidgetInvoker
_icons = {}
+volume_monitor = None
class DeviceView(TrayIcon):
@@ -100,6 +101,7 @@ def setup(tray):
def _setup_volumes(tray):
+global volume_monitor
volume_monitor = Gio.VolumeMonitor.get()
for volume in volume_monitor.get_volumes():
@@ -121,17 +123,17 @@ def _mount(volume, tray):
# Follow Nautilus behaviour here
# since it has the same issue with removable device
# and it would be good to not invent our own workflow
-if hasattr(volume, 'should_automount') and not volume.should_automount():
+if not volume.should_automount():
return
#TODO: should be done by some other process, like gvfs-hal-volume-monitor
-#TODO: use volume.should_automount() when it gets into pygtk
if volume.get_mount() is None and volume.can_mount():
#TODO: pass None as mount_operation, or better, SugarMountOperation
-volume.mount(Gtk.MountOperation(tray.get_toplevel()), _mount_cb)
+volume.mount(0, Gtk.MountOperation(parent=tray.get_toplevel()), None,
+ _mount_cb, None)
-def _mount_cb(volume, result):
+def _mount_cb(volume, result, user_data):
logging.debug('_mount_cb %r %r', volume, result)
volume.mount_finish(result)
diff --git a/src/jarabe/journal/volumestoolbar.py
b/src/jarabe/journal/volumestoolbar.py
index 8f4692d..1fc368e 100644
--- a/src/jarabe/journal/volumestoolbar.py
+++ b/src/jarabe/journal/volumestoolbar.py
@@ -251,13 +251,6 @@ class VolumesToolbar(Gtk.Toolbar):
if button.props.active:
self.emit('volume-changed', button.mount_point)
-def _unmount_activated_cb(self, menu_item, mount):
-logging.debug('VolumesToolbar._unmount_activated_cb: %r', mount)
-mount.unmount(self.__unmount_cb)
-
-def __unmount_cb(self, source, result):
-logging.debug('__unmount_cb %r %r', source, result)
-
def _get_button_for_mount(self, mount):
mount_point = mount.get_root().get_path()
for button in self.get_children():
diff --git a/src/jarabe/view/palettes.py b/src/jarabe/view/palettes.py
index 35475d0..89d47db 100644
--- a/src/jarabe/view/palettes.py
+++ b/src/jarabe/view/palettes.py
@@ -246,11 +246,13 @@ class VolumePalette(Palette):
self.connect('popup', self.__popup_cb)
def __unmount_activate_cb(self, menu_item):
-self._mount.unmount(self.__unmount_cb)
+mount_op = Gtk.MountOperation(parent=self.content_box.get_toplevel())
+self._mount.unmount_with_operation(0, mount_op, None,
+ self.__unmount_cb, None)
-def __unmount_cb(self, mount, result):
+def __unmount_cb(self, mount, result, user_data):
logging.debug('__unmount_cb %r %r', mount, result)
-mount.unmount_finish(result)
+mount.unmount_with_operation_finish(result)
def __popup_cb(self, palette):
mount_point = self._mount.get_root().get_path()
--
1.7.11.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Hulahop Support
On Mon, Oct 1, 2012 at 10:17 AM, Daniel Castelo wrote: > Hi. In Uruguay we use the program JClic, one of the componentes of this > program required hulahop. > > Do you know if the library has support now? I know that the new Sugar > Browser is based on Webkit. Unfortunately its unsupported - a dead project. Mozilla made some changes internally which broke hulahop and other embedders, and it wasn't clear how to fix them, and Mozilla publicly stated that they don't support embedding any more. There were some patches around that fixed hulahop for Firefox 10 (but broke again for Firefox 11), or something like that. But I would suggest that you move to webkit, it is a much nicer experience. Here is a sample app: http://dev.laptop.org/~dsd/20110625/wkdemo.py Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] gettext vs unicode problem in wireless key dialog
Hi,
Sorry for not doing my homework, a bit overloaded...
What was the result of the discussion where _("str1") % str2 was
causing problems (assuming it has been resolved)?
The issue I'm looking at is that we do this exact pattern in
keydialog.py and it is raising an exception.
The Spanish translation of str1 includes accents, and gettext returns
it as a str. str2 is guaranteed to be unicode. And this is an unhappy
combination:
>>> "fóo%s" % u"bar"
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
1: ordinal not in range(128)
If posting a fix is easier than replying to this mail, please do so :)
The string is: A wireless encryption key is required for the wireless
network '%s'
Thanks
Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Key dialog: fix label creation
This incorrect syntax was probably introduced by pygi-convert.
This was one of the issues preventing the wireless key dialog from
popping up.
---
src/jarabe/desktop/keydialog.py | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/jarabe/desktop/keydialog.py b/src/jarabe/desktop/keydialog.py
index 5215d05..a0509d9 100644
--- a/src/jarabe/desktop/keydialog.py
+++ b/src/jarabe/desktop/keydialog.py
@@ -134,7 +134,7 @@ class WEPKeyDialog(KeyDialog):
self.key_combo.connect('changed', self._key_combo_changed_cb)
hbox = Gtk.HBox()
-hbox.pack_start(Gtk.Label(_('Key Type:', True, True, 0)))
+hbox.pack_start(Gtk.Label(_('Key Type:')), True, True, 0)
hbox.pack_start(self.key_combo, True, True, 0)
hbox.show_all()
self.vbox.pack_start(hbox, True, True, 0)
@@ -154,7 +154,7 @@ class WEPKeyDialog(KeyDialog):
self.auth_combo.set_active(0)
hbox = Gtk.HBox()
-hbox.pack_start(Gtk.Label(_('Authentication Type:', True, True, 0)))
+hbox.pack_start(Gtk.Label(_('Authentication Type:')), True, True, 0)
hbox.pack_start(self.auth_combo, True, True, 0)
hbox.show_all()
--
1.7.11.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Use NetworkManager to generate connection UUIDs
Recent versions of NetworkManager have gotten stricter when checking
UUIDs. A UUID must be 32 hex characters plus 4 dashes.
Sugar's unique_id() doesn't satisify this. Switch to using NM
to generate UUIDs.
---
src/jarabe/desktop/networkviews.py | 4 ++--
src/jarabe/model/adhoc.py | 4 ++--
src/jarabe/model/network.py| 4 ++--
src/jarabe/model/olpcmesh.py | 4 ++--
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/jarabe/desktop/networkviews.py
b/src/jarabe/desktop/networkviews.py
index c949b7e..02ab2b7 100644
--- a/src/jarabe/desktop/networkviews.py
+++ b/src/jarabe/desktop/networkviews.py
@@ -22,6 +22,7 @@ import hashlib
import dbus
import glib
+from gi.repository import NetworkManager
from sugar3.graphics.icon import Icon
from sugar3.graphics.xocolor import XoColor
@@ -30,7 +31,6 @@ from sugar3.graphics import style
from sugar3.graphics.icon import get_icon_state
from sugar3.graphics import palette
from sugar3.graphics.menuitem import MenuItem
-from sugar3.util import unique_id
from sugar3 import profile
from jarabe.view.pulsingicon import EventPulsingIcon
@@ -346,7 +346,7 @@ class WirelessNetworkView(EventPulsingIcon):
logging.debug('Creating new connection for SSID %r', self._ssid)
settings = Settings()
settings.connection.id = self._display_name
-settings.connection.uuid = unique_id()
+settings.connection.uuid = NetworkManager.utils_uuid_generate()
settings.connection.type = '802-11-wireless'
settings.wireless.ssid = self._ssid
diff --git a/src/jarabe/model/adhoc.py b/src/jarabe/model/adhoc.py
index dfd6caa..7b2c3ea 100644
--- a/src/jarabe/model/adhoc.py
+++ b/src/jarabe/model/adhoc.py
@@ -18,10 +18,10 @@ import logging
import dbus
from gi.repository import GObject
+from gi.repository import NetworkManager
from jarabe.model import network
from jarabe.model.network import Settings
-from sugar3.util import unique_id
from jarabe.model.network import IP4Config
@@ -187,7 +187,7 @@ class AdHocManager(GObject.GObject):
ssid = 'Ad-hoc Network %d' % (channel,)
settings = Settings()
settings.connection.id = self._get_connection_id(channel)
-settings.connection.uuid = unique_id()
+settings.connection.uuid = NetworkManager.utils_uuid_generate()
settings.connection.type = '802-11-wireless'
settings.connection.autoconnect = False
settings.wireless.ssid = dbus.ByteArray(ssid)
diff --git a/src/jarabe/model/network.py b/src/jarabe/model/network.py
index 930ba13..043a6a2 100644
--- a/src/jarabe/model/network.py
+++ b/src/jarabe/model/network.py
@@ -27,11 +27,11 @@ import dbus.service
from gi.repository import GObject
import ConfigParser
from gi.repository import GConf
+from gi.repository import NetworkManager
import ctypes
from sugar3 import dispatch
from sugar3 import env
-from sugar3.util import unique_id
NM_STATE_UNKNOWN = 0
NM_STATE_ASLEEP = 10
@@ -991,7 +991,7 @@ def create_gsm_connection(username, password, number, apn,
pin):
settings.connection.id = GSM_CONNECTION_ID
settings.connection.type = NM_CONNECTION_TYPE_GSM
-settings.connection.uuid = unique_id()
+settings.connection.uuid = NetworkManager.utils_uuid_generate()
settings.connection.autoconnect = False
settings.ip4_config.method = 'auto'
settings.serial.baud = GSM_BAUD_RATE
diff --git a/src/jarabe/model/olpcmesh.py b/src/jarabe/model/olpcmesh.py
index c2a81f5..dd35c29 100644
--- a/src/jarabe/model/olpcmesh.py
+++ b/src/jarabe/model/olpcmesh.py
@@ -18,11 +18,11 @@ import logging
import dbus
from gi.repository import GObject
+from gi.repository import NetworkManager
from jarabe.model import network
from jarabe.model.network import Settings
from jarabe.model.network import OlpcMesh as OlpcMeshSettings
-from sugar3.util import unique_id
_XS_ANYCAST = '\xc0\x27\xc0\x27\xc0\x00'
@@ -177,7 +177,7 @@ class OlpcMeshManager(object):
settings.ip4_config.method = 'link-local'
settings.connection.id = self._get_connection_id(channel, xs_hosted)
settings.connection.autoconnect = False
-settings.connection.uuid = unique_id()
+settings.connection.uuid = NetworkManager.utils_uuid_generate()
settings.connection.type = '802-11-olpc-mesh'
network.add_connection(settings,
reply_handler=self._add_connection_reply_cb,
--
1.7.11.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Use NetworkManager to generate connection UUIDs
On Tue, Oct 9, 2012 at 3:47 PM, Simon Schampijer wrote: > To know the scope of this issue a bit more: What current side effects do we > have? NetworkManager doesn't let sugar establish a connection because the uuid is invalid. > We can use the python module for uuid as well to generate an UUID with the 4 > dashes (e.g. uuid.uuid1()) [1]. That looks like a good option. > The other place we do use our own util is for the activity id, should we > switch there as well? I guess it depends what its used for, if changing the format breaks anything, etc. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Write activity for Abiword-2.9.x/GTK3
Hi Gonzalo, Is there Write activity code available for abiword-2.9.x/GTK3 or is this yet to be done? Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] sugar-session: initialize threading via glib
sugar extensions that use threads such as OLPC's software updater
require that threads have been properly initialised before the
main loop is ran.
For pygobject3, GLib.threads_init() must be called before doing
the same for Gdk, otherwise the threads hang in random places
for long periods of time. See e.g.
http://stackoverflow.com/questions/11070263/webkit-threads-with-pygobject-on-gtk3
---
bin/sugar-session | 2 ++
1 file changed, 2 insertions(+)
diff --git a/bin/sugar-session b/bin/sugar-session
index 7455f38..6f2bcd6 100755
--- a/bin/sugar-session
+++ b/bin/sugar-session
@@ -35,6 +35,7 @@ import gettext
import logging
import sys
+from gi.repository import GLib
from gi.repository import GConf
from gi.repository import Gtk
from gi.repository import Gdk
@@ -51,6 +52,7 @@ try:
except ImportError:
logging.debug('Could not load xklavier for keyboard configuration')
+GLib.threads_init()
Gdk.threads_init()
dbus.glib.threads_init()
--
1.7.11.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Request AP properties with dbus ByteArrays (#4031)
As we deal with the ssid property as a string, we need to explicitly
request byte array data as a ByteArray as is done in other places.
This wasn't a problem before the upgrade to dbus-1.6.8; its likely
that the byte_arrays setting was questionably inherited from other
places where we subscribe to this signal. But now it seems like
each call site is independent, which makes sense, and each one must
request byte_arrays if that is the format it wants to work with.
---
extensions/deviceicon/network.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/extensions/deviceicon/network.py b/extensions/deviceicon/network.py
index 79bc764..f014418 100644
--- a/extensions/deviceicon/network.py
+++ b/extensions/deviceicon/network.py
@@ -457,7 +457,8 @@ class WirelessDeviceView(ToolButton):
self._bus.add_signal_receiver(self.__ap_properties_changed_cb,
signal_name='PropertiesChanged',
path=self._active_ap_op,
-
dbus_interface=network.NM_ACCESSPOINT_IFACE)
+
dbus_interface=network.NM_ACCESSPOINT_IFACE,
+ byte_arrays=True)
def __get_active_ap_error_cb(self, err):
logging.error('Error getting the active access point: %s', err)
--
1.7.11.4
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Ruler-21
On Sat, Oct 27, 2012 at 8:17 AM, Sugar Labs Activities wrote: > Activity Homepage: > http://activities.sugarlabs.org/addon/4192 > > Sugar Platform: > 0.98 - 0.98 > > Download Now: > http://activities.sugarlabs.org/downloads/file/28270/ruler-21.xo > > Release notes: > 21 This doesn't seem to be in git, checking http://git.sugarlabs.org/ruler/mainline/commits/master Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Ruler-21
On Sat, Oct 27, 2012 at 9:49 AM, Walter Bender wrote: > http://git.sugarlabs.org/~flavio/ruler/rulergtk3 > > This raises an issue. I have not been consistent about where I have > been putting the gtk-3 branches of my activities. Many of the ports > are made by 3rd parties who make their own clones of the project and > then I help them on those branches. > > I have been putting the .tar.bz files on d.sl.o and uploading the .xo > files to a.sl.o, but it seems you need the .git to be in a particular > place? Thats going to be annoying for contributors who now have to go an extra few steps to find the git tree that they should base new work on. My suggestion would be to put GTK3 ports in master branches in the main repositories, and use a branch in the same repository for any GTK2 work. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Ruler-21
On Sat, Oct 27, 2012 at 9:57 AM, Walter Bender wrote: > Do you know any magic git foo that would enable me to do the following? > > Before: > Master == GTK2 > Clone == GTK3 > > After: > Master == GTK3 > Branch == GTK2 >From your repository, first create the GTK2 branch with: # git branch gtk2 Then pull in all GTK3 changes on top of the master branch: # git pull git://path/to/3rd/party/repo Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Ruler-21
On Sat, Oct 27, 2012 at 10:38 AM, Walter Bender wrote:
> Mostly kind of worked, but how do I get my local branch (gtk2) to
> appear on g.sl.o?
git push -u origin gtk2
That's a one-off - all future "git push" should then update both
branches (if there are local unpushed changes).
("git push --dry-run" first is a good habit to get into)
Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ASLO] Release Ruler-21
On Sat, Oct 27, 2012 at 8:17 AM, Sugar Labs Activities wrote: > Activity Homepage: > http://activities.sugarlabs.org/addon/4192 > > Sugar Platform: > 0.98 - 0.98 > > Download Now: > http://activities.sugarlabs.org/downloads/file/28270/ruler-21.xo The other weird thing here is that 13.1.0 build 6 (from October 12th) already includes this version, but this mail suggest it was just released a day or two ago. http://build.laptop.org/13.1.0/os6/xo-4/31006o4.activities.txt Are there two Ruler-21s in the wild? Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Write bundled with Sugar 0.97.8 fails to start and tells "Could not find any typelib for abi"
On Wed, Oct 31, 2012 at 8:20 AM, Daniel Narvaez wrote: > I know you guys are busy and I don't want to keep wasting your time > (in this discussion too!). Though let me just suggest that putting > links to the upstream bugs in a text file wouldn't take much time. > Using a separate branch/repo until the dependencies went upstream, > would have taken even less time. Probably the less painful approach both for us(abiword packagers) and you(someone interested in the patches) would just be to grab them from the SRPM which is published at http://rpmdropbox.laptop.org/f18/ Sorry that its not ideal; the situation will resolve itself soon. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH sugar-toolkit-gtk3] Restore use of XSMP client
In the GTK3 port we mistakenly moved from using the EggSMClientXSMP
class to the (stub-like) EggSMClient base class for Sugar's XSMPClient
class, instantiated for every activity.
This meant that the GTK3 activities weren't registering with the
session manager, meaning that they won't automatically save their work
when the user shuts down, and they can't inhibit shutdown, etc.
Restore this functionality by adding the appropriate header so that
EggSMClientXSMP is introspectable, and then use it from the Python code.
---
src/sugar3/Makefile.am| 2 +
src/sugar3/eggsmclient-xsmp.c | 64 +
src/sugar3/eggsmclient-xsmp.h | 96 +++
src/sugar3/session.py | 6 +--
4 files changed, 101 insertions(+), 67 deletions(-)
create mode 100644 src/sugar3/eggsmclient-xsmp.h
diff --git a/src/sugar3/Makefile.am b/src/sugar3/Makefile.am
index f25606b..be43461 100644
--- a/src/sugar3/Makefile.am
+++ b/src/sugar3/Makefile.am
@@ -126,6 +126,8 @@ SugarExt_1_0_gir_FILES = \
acme-volume-alsa.h \
eggsmclient.c \
eggsmclient.h \
+ eggsmclient-xsmp.c \
+ eggsmclient-xsmp.h \
gsm-session.c \
gsm-session.h \
gsm-xsmp.c \
diff --git a/src/sugar3/eggsmclient-xsmp.c b/src/sugar3/eggsmclient-xsmp.c
index 33c9a5d..85e3a91 100644
--- a/src/sugar3/eggsmclient-xsmp.c
+++ b/src/sugar3/eggsmclient-xsmp.c
@@ -26,6 +26,7 @@
#endif
#include "eggsmclient.h"
+#include "eggsmclient-xsmp.h"
#include "eggsmclient-private.h"
#include "eggdesktopfile.h"
@@ -39,35 +40,6 @@
#include
-#define EGG_TYPE_SM_CLIENT_XSMP(egg_sm_client_xsmp_get_type ())
-#define EGG_SM_CLIENT_XSMP(obj)(G_TYPE_CHECK_INSTANCE_CAST ((obj),
EGG_TYPE_SM_CLIENT_XSMP, EggSMClientXSMP))
-#define EGG_SM_CLIENT_XSMP_CLASS(klass)(G_TYPE_CHECK_CLASS_CAST ((klass),
EGG_TYPE_SM_CLIENT_XSMP, EggSMClientXSMPClass))
-#define EGG_IS_SM_CLIENT_XSMP(obj) (G_TYPE_CHECK_INSTANCE_TYPE ((obj),
EGG_TYPE_SM_CLIENT_XSMP))
-#define EGG_IS_SM_CLIENT_XSMP_CLASS(klass) (G_TYPE_CHECK_CLASS_TYPE ((klass),
EGG_TYPE_SM_CLIENT_XSMP))
-#define EGG_SM_CLIENT_XSMP_GET_CLASS(obj) (G_TYPE_INSTANCE_GET_CLASS ((obj),
EGG_TYPE_SM_CLIENT_XSMP, EggSMClientXSMPClass))
-
-typedef struct _EggSMClientXSMPEggSMClientXSMP;
-typedef struct _EggSMClientXSMPClass EggSMClientXSMPClass;
-
-/* These mostly correspond to the similarly-named states in section
- * 9.1 of the XSMP spec. Some of the states there aren't represented
- * here, because we don't need them. SHUTDOWN_CANCELLED is slightly
- * different from the spec; we use it when the client is IDLE after a
- * ShutdownCancelled message, but the application is still interacting
- * and doesn't know the shutdown has been cancelled yet.
- */
-typedef enum
-{
- XSMP_STATE_START,
- XSMP_STATE_IDLE,
- XSMP_STATE_SAVE_YOURSELF,
- XSMP_STATE_INTERACT_REQUEST,
- XSMP_STATE_INTERACT,
- XSMP_STATE_SAVE_YOURSELF_DONE,
- XSMP_STATE_SHUTDOWN_CANCELLED,
- XSMP_STATE_CONNECTION_CLOSED,
-} EggSMClientXSMPState;
-
static const char *state_names[] = {
"start",
"idle",
@@ -81,40 +53,6 @@ static const char *state_names[] = {
#define EGG_SM_CLIENT_XSMP_STATE(xsmp) (state_names[(xsmp)->state])
-struct _EggSMClientXSMP
-{
- EggSMClient parent;
-
- SmcConn connection;
- char *client_id;
-
- EggSMClientXSMPState state;
- char **restart_command;
- gboolean set_restart_command;
- int restart_style;
-
- guint idle;
-
- /* Current SaveYourself state */
- guint expecting_initial_save_yourself : 1;
- guint need_save_state : 1;
- guint need_quit_requested : 1;
- guint interact_errors : 1;
- guint shutting_down : 1;
-
- /* Todo list */
- guint waiting_to_emit_quit : 1;
- guint waiting_to_emit_quit_cancelled : 1;
- guint waiting_to_save_myself : 1;
-
-};
-
-struct _EggSMClientXSMPClass
-{
- EggSMClientClass parent_class;
-
-};
-
static void sm_client_xsmp_startup (EggSMClient *client,
const char *client_id);
static void sm_client_xsmp_set_restart_command (EggSMClient *client,
diff --git a/src/sugar3/eggsmclient-xsmp.h b/src/sugar3/eggsmclient-xsmp.h
new file mode 100644
index 000..1fbf5c5
--- /dev/null
+++ b/src/sugar3/eggsmclient-xsmp.h
@@ -0,0 +1,96 @@
+/* eggsmclient.h
+ * Copyright (C) 2007 Novell, Inc.
+ *
+ * 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
[Sugar-devel] [PATCH] CP: allow further selection beyond English fallback
Currently, the language control panel does not allow you to select
other languages after a en_US entry. This is built around the assumption
that source code strings are always in English, which is the common case,
but does not always have to be true.
As other apps can interpret the same LANGUAGE variable as a more general
priority list of languages (Maliit will start doing this), there is
further justification to remove the artificial en_US ending boundary.
---
extensions/cpsection/language/view.py | 27 ---
1 file changed, 27 deletions(-)
diff --git a/extensions/cpsection/language/view.py
b/extensions/cpsection/language/view.py
index 95066f8..77f7207 100644
--- a/extensions/cpsection/language/view.py
+++ b/extensions/cpsection/language/view.py
@@ -136,8 +136,6 @@ class Language(SectionView):
previous_add_removes = self._add_remove_boxes[-2]
previous_add_removes.hide()
-self._determine_add_remove_visibility()
-
combobox.show()
def _attach_to_table(self, widget, row, column, padding=20, \
@@ -216,8 +214,6 @@ class Language(SectionView):
selected_langs = self._get_selected_langs()
last_lang = selected_langs[-1]
-self._determine_add_remove_visibility(last_lang=last_lang)
-
self._changed = (selected_langs != self._selected_locales)
if self._changed == False:
@@ -247,29 +243,6 @@ class Language(SectionView):
return new_codes
-def _determine_add_remove_visibility(self, last_lang=None):
-# We should not let users add fallback languages for English (USA)
-# This is because the software is not usually _translated_ into English
-# which means that the fallback gets selected automatically
-
-if last_lang is None:
-selected_langs = self._get_selected_langs()
-last_lang = selected_langs[-1]
-
-add_remove_box = self._add_remove_boxes[-1]
-buttons = add_remove_box.get_children()
-add_button, remove_button = buttons
-
-if last_lang.startswith('en_US'):
-add_button.props.visible = False
-else:
-add_button.props.visible = True
-
-if self._selected_lang_count == 1:
-remove_button.props.visible = False
-else:
-remove_button.props.visible = True
-
def __lang_timeout_cb(self, codes):
self._lang_sid = 0
self._model.set_languages_list(codes)
--
1.7.11.7
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [sugar-update-control PATCH 1/2] Now, the selecting/unselecting particular activities works.
Thanks for the patch. If you'd like to speed up the process and save
me some time, please add a commit message explaining what was wrong
and how/why this fixes it. It does not jump out at me from the patch.
It also doesn't feel like the right place to be doing a spring
cleaning of the activities model.
On Tue, Nov 27, 2012 at 10:31 AM, Ajay Garg wrote:
> diff --git a/src/model.py b/src/model.py
> index 35896e2..533183b 100755
> --- a/src/model.py
> +++ b/src/model.py
> @@ -229,7 +229,13 @@ class UpdateList(Gtk.ListStore):
>
> def toggle_select(self, path):
> """Toggle whether the given update will be installed."""
> -row = self[path]
> +# We first need to remove all the spurious activities existing
> +# in the model, for whom "UPDATE_EXISTS" is False.
> +for act in self:
> +if act[UPDATE_EXISTS] is False:
> +self.remove(act.iter)
> +
> +row = self[self.get_iter_from_string(path)]
> row[UPDATE_SELECTED] = not row[UPDATE_SELECTED]
>
> # don't touch the UI in refresh, it needs to be thread-safe.
> diff --git a/src/view.py b/src/view.py
> index 32cb580..9c8efdb 100755
> --- a/src/view.py
> +++ b/src/view.py
> @@ -84,7 +84,6 @@ class ActivityListView(Gtk.ScrolledWindow):
> if self.activity_updater._in_sugar:
> crbool.set_property('indicator_size', style.zoom(26))
> def toggled_cb(crbool, path, self):
> -path = self.ftreestore.convert_path_to_child_path(path)
> self.activity_updater.activity_list.toggle_select(path)
> self.activity_pane._refresh_update_size()
> crbool.connect('toggled', toggled_cb, self)
> --
> 1.7.11.7
>
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] 13.1 ? and 12 ? Re: [IAEP] Sugar Digest 2012-11-30
On Fri, Nov 30, 2012 at 12:07 PM, Yama Ploskonka wrote: > 2) What is the role of these 31012 builds? are they meant as an official > update? are they undergoing further testing? In short, should I point people > to those instead of to the 21021? The naming scheme is described here: http://wiki.laptop.org/go/Release_Process#Version_numbering So really what you are asking is: should you point people at 12.1 or 13.1? http://wiki.laptop.org/go/Releases shows you that 12.1 is the latest stable, and 13.1 is in development. So it depends if you are working with users or developers... > background: > the link Walter offers (thanks!) > http://build.laptop.org/13.1.0/os13/ > has only XO-4 files... The de...@lists.laptop.org list has build announcements - thats the best place to keep up with whats going on. In this case build 13 was never announced; the build 12 announcement did mention that build 13 would be XO-4 only. > Also, if I look for 12.1 files, here: > http://build.laptop.org/13.1.0/os12/xo-1/ > they are named 31012 Your mistake here would be that you are looking for 12.1 files in a 13.1.0 directory. You can find 12.1 final on http://download.laptop.org or on the link you include below: > while > http://wiki.laptop.org/go/Release_notes/12.1.0#XO-1 > points to 21021 ones That is the 12.1 final release. > BTW, the os14 directories /do/ have X0-1 files, but I guess that's trying > timetravel :-) > http://build.laptop.org/13.1.0/os14/ Thats 13.1.0 build 14, the latest announced 13.1 development build. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [sugar-update-control PATCH 1/2] Now, the selecting/unselecting particular activities works.
On Fri, Nov 30, 2012 at 3:52 PM, Ajay Garg wrote: > It would be good if it is known whether the "Select/Deselect" feature worked > at all previously (I doubt it ever did). In the unlikely scenario that it > worked before, I will be happy to delve in more into this. Yes, it worked fine before. Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [sugar-update-control PATCH 1/2] Now, the selecting/unselecting particular activities works.
On Mon, Dec 3, 2012 at 1:44 AM, Ajay Garg wrote: > I will be grateful if you could let me know the download link of the image > where it worked. > That will provide me the mental push to have a go-ahead on what surely would > then be a regression. 12.1.0 from http://download.laptop.org/ Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar 12/20] No reason to unfreeze dcon on idle
On Mon, Dec 10, 2012 at 7:11 PM, Daniel Narvaez wrote: > From: Daniel Narvaez I think actually there is a good reason. The OLPC XO boot design is that the XO man is always visible - from the firmware, through the boot animation, and then when Sugar loads. This hasn't worked 100% correctly in our history but right now it is working fine. However, I imagine with this patch applied, there will be an uncomfortable moment late in the boot process where the XO man has not been drawn on-screen by Sugar. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Rework how we select the Xcursor theme
On Mon, Dec 10, 2012 at 10:32 PM, Daniel Narvaez wrote: > Distributions which are shipping both GNOME and sugar should make > sure to set XDG_CONFIG_HOME for either of the desktops to point > to a non default location, so that the settings are not conflicting. > It's necessary in this case if you don't want to get the sugar > cursors in GNOME, but it seems like a sane approach in general. We > are sharing several components with GNOME which are (or might in > the future) be using GNOME gsettings. This might be a good idea, but it would also mean that Sugar and activities share no settings at all with GNOME in cases where that might be desirable. I can't immediately think of any pitfalls, but this does needs some extra thought and testing to see if this is really what we want and if it will cause headaches for the OLPC distribution. Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH] Modem device icon: fix state detection (#4255)
Probably lacking an update from the NM-0.8 era, _update_state does not correctly handle NM_DEVICE_STATE_IP_CHECK and NM_DEVICE_STATE_SECONDARIES (triggered late in the connection-establishing process after NM_DEVICE_STATE_IP_CONFIG). This was causing backtraces like: File "/usr/share/sugar/extensions/deviceicon/network.py", line 856, in _update_state self._palette.update_state(gsm_state, reason) File "/usr/share/sugar/extensions/deviceicon/network.py", line 272, in update_state self._update_label_and_text(reason) File "/usr/share/sugar/extensions/deviceicon/network.py", line 310, in _update_label_and_text 'text, %s' % str(self._current_state)) ValueError: Invalid GSM state while updating label and text, None and it may have been confusing further code in the same class after. Fix _update_state to more accurately identify the "connecting" states. --- extensions/deviceicon/network.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/extensions/deviceicon/network.py b/extensions/deviceicon/network.py index ebbafdd..2a60481 100644 --- a/extensions/deviceicon/network.py +++ b/extensions/deviceicon/network.py @@ -846,7 +846,7 @@ class GsmDeviceView(TrayIcon): gsm_state = _GSM_STATE_NOT_READY elif (state >= network.NM_DEVICE_STATE_PREPARE) and \ - (state <= network.NM_DEVICE_STATE_IP_CONFIG): + (state < network.NM_DEVICE_STATE_ACTIVATED): gsm_state = _GSM_STATE_CONNECTING elif state == network.NM_DEVICE_STATE_FAILED: -- 1.8.0.1 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Porting to GSettings and XDG directories
On Sat, Dec 15, 2012 at 10:55 AM, Daniel Narvaez wrote: > * Port glucose to use GSettings. I guess this includes sugar-toolkit (gtk2 version). Are there gsettings bindings for pygtk? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [support-gang] Yama First impressions, OLPC OS 13.1 31018
Hi Yama, Thanks a lot for the feedback - all very useful. Focusing mainly on the items where a quick answer is possible: On Fri, Dec 14, 2012 at 6:35 PM, Yama Ploskonka wrote: > *Sugar GUI* > Terminal is hidden again. > If someone /deserves/ Terminal privileges, they can learn how to get it, so > it's OK Terminal isn't in the favourites view by default - thats indeed correct, but it's been like that for at least 2 years now, probably longer. This is easily overrideable by deployments if they wish. > 2) "Mayan numbers" for the Mesh Network was announced many times, but AFAIK > never implemented. > Mesh icons are still undistinguishable from each other The mayan numbers are used for the ad-hoc network points used on XO-1.5 and newer. These networks behave differently from the mesh, so the visual difference does make some sense. The XO-1 mesh icons could indeed do with some love. > Bottom line, after just a first look, Sugar doesn't seem improved, but Gnome > is much, much better than it ever was (even "good desktop Gnome" OS versions > used to have issues with the files I need) Yes, Sugar has not heavily changed for existing laptop users this time around. My first stab at http://wiki.laptop.org/go/Release_notes/13.1.0 gives some indication of where our efforts have been: touchscreen usability and XO-4 hardware. However, old platforms are not forgotten, and hopefully we'll be back to a broader ranging set of improvements for the next release. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Yama First impressions, OLPC OS 13.1 31018
On Fri, Dec 14, 2012 at 9:44 PM, Kim wrote: > I'd call my 1.5 HS first impressions "poor." Beginning from a clean install > (fs-update from a USB stick), things loaded fine and the opening "hello" > boot-up > experience is improved. After using the control panel to connect to the web, > set time, place, jabber, and frame settings, I killed Sugar in Browse amost > immediately (I tried to save the clipping I had just made of my developer key > link to my journal using the context menu the appears when hovering over the > clipping icon on the left side of the frame). In three years of using an xo-1 > and -1.5, this OS crashed more quickly than any other, and that includes some > of > the earlier builds in this sequence (number 8 didn't have these problems). The clipboard related issues are known and are being worked on. I believe we have had them for the whole development cycle, not just post build 8. They are introduced by the underlying technological shift to GTK3 technologies, so it is not a trivial fix or something that we can just revert to fix it. It will be fixed before the final release is made though - we're making progress. If you are seeing other problems, especially ones that have only appeared after build 8, we'd very much appreciate further emails describing them. > Switching over to the Gnome interface also failed to delight: I can't hide > the > bars at the top and bottom of the screen by right-clicking as I could in the > past, and choosing on "Change Desktop Background" after right-clicking on the > desktop did nothing. The customization of some GNOME components has indeed decreased a bit in the last few years, especially in the "GNOME fallback" mode that we run. Some of the panel customizations can be restored by holding Alt and right clicking. Perhaps not ideal, I know. I don't think we were aware of the "Change Desktop Background" problem, so I've filed http://dev.laptop.org/ticket/12399 to look at it later. As for the I and L issue on XO-1.5, we're aware and have almost fixed it. http://dev.laptop.org/ticket/12354 Thanks again for the feedback. If there are other problems that you've encountered but haven't described, please send followup emails letting us know. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] webgl in Browse
On Wed, Jan 23, 2013 at 4:43 PM, Daniel Narvaez wrote: > I haven't tried but I think it might work on Fedora 18, it sounds like > it's enabled by default in webkit 1.10. > > If someone has it installed, the easiest test would be to try it in > the epiphany browser. If it works it will hopefully work in Browse too > (or it should be easy to make it work anyway). Works in epiphany on F18 on my desktop after enabling it in gsettings. https://mail.gnome.org/archives/commits-list/2012-February/msg00660.html Tested with http://webglsamples.googlecode.com/hg/electricflower/electricflower.html For Browse, we need to explore the implications of clutter being used (as mentioned in the commit). Also having this working on the XO will probably present further challenges, if that was part of the question. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] webgl in Browse
On Thu, Jan 24, 2013 at 8:25 AM, Gonzalo Odiard wrote: > Is epiphany using webkitgtk2 or webkitgtk in F18? > In Browse we are using webkitgtk right now. I am pretty sure that would have no impact on WebGL. Both of those APIs share the same rendering engine. But to answer the question, it is using webkitgtk. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [sugar PATCH] "Proxy" feature. Wiki page: http://wiki.sugarlabs.org/go/Features/Proxy_Settings
On Tue, Feb 19, 2013 at 8:40 AM, Ajay Garg wrote: > Another thing to be cleared :: storing in "dconf" IS THE SAME AS storing in > "gsettings" . Not exactly. gsettings has a choice of backends, dconf is just one of them. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [support-gang] http://bugs.sugarlabs.org/ticket/4285#comment:7
On Fri, Feb 22, 2013 at 10:42 AM, Thomas Gilliard wrote: > My Settings/ Software Update is important to have for both fedora 18 > sugar-desktop and the fedora 18 Sugar on a Stick spin. Nobody doubts that its a bug worth fixing, but resources are limited, so we set priorities. Maybe you can help us reprioritise it by explaining why it is so important for these two use cases. To me this it is not of obviously high importance, since this software update component is not able to update any of the software shipped in those 2 platforms (they ship systemwide activities, and the updater in question cannot touch these). Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [record PATCH] sl#4442: Now, Copy-to-Clipboard works fine, after the recipient clicks on the thumbnail, and the complete-data is fetched.
On Mon, Feb 25, 2013 at 5:56 AM, Ajay Garg wrote: > > Signed-off-by: Ajay Garg > --- > button.py | 12 ++-- > 1 files changed, 10 insertions(+), 2 deletions(-) Thanks for the patch. It would be nice to have a commit message describing the bug and the fix, without having to go and load the ticket. After reading the ticket I can't immediately see how/why this patch solves the issue. What does the expose event have to do with receiving the data from the remote end? This should be explained in the commit message. Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Window handling for non-Python activities
Hi, There are a number of popular apps which have had a minimal Sugar launcher built around them so that they can be launched from Sugar. Examples include GCompris, Tux Paint and Tux Math. In recent versions of sugar (tested 0.96 and 0.98) the way these are launched is no longer working smoothly. The problem is that after using the apps, you see a "failed to start" pulsing launching screen error. This is causing confusion at schools in Nicaragua where Sugar-0.96 is currently being depoyed. This didn't happen on older versions of Sugar (haven't checked why, maybe the "failed to start" screen didn't exist before?) These launchers work as follows: They implement an Activity class, but they don't really do anything activity-like there. In __init__ they call os.system(foo), where foo is the app in question, which produces its own full-screen window. Then it calls self.close(). Note that os.system() is synchronous, so this Python launcher keeps running until the app is actually closed, then it reaches the next line of code (self.close()), then it returns from __init__. foo creates its own windows which are picked up by Sugar, however since they don't have any of the X properties set, Sugar isn't sure which activity they belong to. 90 seconds later, since the Python launcher has failed to create an identifiable window of any kind, Sugar decides that launch has failed. Then, when the user later finishes using the app, they close it, and then they see the confusing "Tux Paint has failed to start" message. This can be quickly reproduced on latest OLPC builds with Sugar-0.98: 1. yum install tuxpaint 2. Install this launcher: http://dev.laptop.org/~gonzalo/nicaragua/TuxPaint-6.xo 3. Run the Tux Paint "activity" 4. Let tux paint run for at least 90 seconds 5. Exit tux paint 6. Observe confusing "failed to start" screen. How can we solve this issue? Do we need to modify all of these activities? Or can we improve Sugar here? If Sugar can determine the PID of the new window, I guess it could observe that it is a child process of the python launcher (which it is tracking) and behave better here. That does sound a bit ugly though, maybe fixing the activities is nicer? Whatever we decide we should produce a quick wiki doc to explain how these launchers should/shouldn't work. Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Window handling for non-Python activities
On Mon, Feb 25, 2013 at 11:22 AM, Daniel Drake wrote: > How can we solve this issue? Do we need to modify all of these activities? > > Or can we improve Sugar here? If Sugar can determine the PID of the > new window, I guess it could observe that it is a child process of the > python launcher (which it is tracking) and behave better here. That > does sound a bit ugly though, maybe fixing the activities is nicer? > > Whatever we decide we should produce a quick wiki doc to explain how > these launchers should/shouldn't work. Without modifying Sugar, here's how I got such activities to behave (took a few tries to find a working solution). TuxPaintLauncher __init__ uses subprocess.Popen to launch TuxPaint, and then schedules a GTK+ exit to happen only after the launcher's window registration has happened. subprocess.Popen(options) gobject.idle_add(gtk.main_quit) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Window handling for non-Python activities
On Mon, Feb 25, 2013 at 11:46 AM, Daniel Narvaez wrote: > On 25 February 2013 18:22, Daniel Drake wrote: >> How can we solve this issue? Do we need to modify all of these activities? > > The way these activities are written seems sort of crazy but maybe I'm > missing something. I'm not sure why they are using a python activity > at all. Feel free to invent a new approach! Or maybe you just did, below. > Did you see my "Fallback to _NET_WM_PID to map windows to activities" > patch? I sent it a while ago so I don't remember for sure, but it > might be possible to make it work with child processes. If it's > possible cleanly, I think it would be a good addition, it would make > easier for people to write non python activities. > Alternatively you could still use that patch, but modify the > activities to pass the main executable to the activity.info directly. > Or for a smaller change I suppose os.execv might also work (?). I haven't tested it, but that seems like a good idea for the way forward. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Window handling for non-Python activities
On Mon, Feb 25, 2013 at 12:54 PM, Martin Langhoff wrote: > This patch seems related: > http://git.sugarlabs.org/sugar/mainline/commit/dc8f6ed7852f919fe7123d458706fb82430257e9 > > It was written to address a similar issue with a Flash Sugar app that > would swap windows around. It is (or should be) in current Sugar -- > was applied a while ago. The apps you mention perhaps use libsugarize? > Perhaps something broke it? In this case libsugarize is not used, and Sugar doesn't find any information available to link the app's windows to an activity, so it is not related to the logic shown in that patch. Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proxy Settings in Network Control Panel
On Wed, Mar 13, 2013 at 10:43 PM, Ajay Garg wrote: > For more details of the "http_proxy" interactions with GTK+, please see the > source-code of webkit, in particular > http://svn.webkit.org/repository/webkit/trunk/Tools/GtkLauncher/main.c GtkLauncher is not a part of WebKit (the library, as used by Sugar). It is a standalone test app. So unless you have another place truly inside webkit where $http_proxy is used, I am doubtful that webkit is using this. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES][DESIGN] Network proxy configuration
On Mon, Nov 21, 2011 at 2:27 PM, Anish Mangal wrote: > I'd like to propose "Network proxy configuration in Sugar" > > http://wiki.sugarlabs.org/go/Features/Proxy_configuration I would say that this feature does not fit particularly nicely with some items of our guidelines: http://wiki.sugarlabs.org/go/Features/Policy#Things_you_should_consider_when_proposing_a_feature In other words, I can't imagine every 6-12 year old student in a school going into the control panel and typing (without error) a load of proxy details. In my experience things like this are incredibly challenging especially because the users cannot relate to the task at hand (unless you want to teach them about computer networks first). A more sensible model would be that this is somehow automated by the deployer or by the school infrastructure, such that the user is not distracted and does not have to care. I'm aware that such generalizations can't be applied to all cases and that this feature is probably driven by some users where this indeed can't be applied. So I'm not in opposition to this feature (even though it would be nice to have the more automated approach designed as well), but I think we need to consider the implications on our more "regular" target userbase. For example, what happens if a user who is on a proxy-free network types "hello" into the proxy configuration textbox? Does that break all networking? One problem that I have seen in various places, children untick the "Radio enable" checkbox in Sugar's control panel and then return their laptop for repair because they can't get online. I fear that proxy configuration could become support headache like this. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES][DESIGN] Network proxy configuration
On Thu, Mar 14, 2013 at 2:08 PM, Alan Jhonn Aguiar Schwyn wrote: >>One problem that I have seen in various places, children untick the >>"Radio enable" checkbox in Sugar's control panel and then return their >>laptop for repair because they can't get online. I fear that proxy >>configuration could become support headache like this. > > Thinking in the same way, we must block the command "rm" from the > terminal because the childrens can remove important files. Or the > command "mv" because generates that an activity no works I can see why you might think that way. However, I have never experienced this being a problem, and I don't recall seeing other reports of this, so I would not argue for any blocking of terminal commands. The radio checkbox is a real headache that *actually happens* though. Taking a guess as to why we see the radio problem but not the terminal one in our field experiences, I would imagine the crucial difference is that the radio checkbox is presented in a way that it is easily accessible but commonly uncomprehendable to our regular user base. In comparison, those dangerous commands in the terminal are in their own world of inaccessibility... Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURES][DESIGN] Network proxy configuration
On Thu, Mar 14, 2013 at 2:31 PM, Gonzalo Odiard wrote: > About the network proxy configuration, I agree is better have a automatic > configuration _if_possible_, but there are times when is not possible, > then we should provide a solution. Has been a request for a long time, > and the development is already 90% done I would still appreciate the answer to this question: For example, what happens if a user who is on a proxy-free network types "hello" into the proxy configuration textbox? Does that break all networking? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] OLPC France 12.1.0 testing results
On Fri, Mar 15, 2013 at 4:03 PM, wrote: > We're currently preparing the 2013 mission to our Nosy Komba deployment: 150 > XO-1 + 50 XO-1.5. > > So, a team of volunteer have tested on 12.1.0/Sugar 0.96 our 63 activities > currently deployed there on OLPC 883/Sugar 0.94.1. > > I know it's a "hot topic" here :-) so following is the result of our test. Thanks a lot for the report. This kind of thing is always very interesting and useful. > · Fix the last issue regarding hulahop incompatibility on 3 > activities (Map, Madagascar, HelpFR), I'm sure you will find help here if this proves challenging. > · Do intensive testing on XO-1 to check the performance issue > mentioned here recently (most of our testing has been done on SoaS or > XO-1.5), According to testing within OLPC, 12.1.0 should not introduce significant performance issues here. 13.1.0 is where the significant slowdowns are introduced. We will try to work on this. > · Try to optimize the size of our bundle to adapt to the new size of > free space on 12.1.0, I'm sorry that the image has grown a bit. It is a battle that we haven't had enough resources to fight well enough. > · Find a new way to create our bundle. Until this year we've got a > customization key but unfortunately it's not supported now: we can't > deployed 63 activities, one by one on 200 XO! You probably already know, what we recommend here is http://wiki.laptop.org/go/OS_Builder Feel free to ask any questions on de...@lists.laptop.org If your laptops are secured, get in contact with OLPC (with a list of serial numbers) to help unlock them. I imagine for a project like yours, you will appreciate the simplicity added overall (i.e. removing the step where you have to use the customization stick), even though you will face a small learning curve first. Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH Etoys] Use ALSA sound backend if available
Extend the sound backend selection code to consider using ALSA. On XO-1.75 and XO-4 this fixes sound in etoys with squeak-vm-4.x. It also fixes XO-4 sound recording which was not working on any previous version. Index: etoys-5.0.2408/etoys.in === --- etoys-5.0.2408.orig/etoys.in2013-03-27 15:06:22.0 -0400 +++ etoys-5.0.2408/etoys.in 2013-03-27 15:06:33.0 -0400 @@ -6,6 +6,7 @@ VM="squeak" VMOPTIONS="-encoding UTF-8 -vm-display-x11 -xshm" +VMSOUND="" IMAGE="@prefix@/share/etoys/etoys.image" IMOPTIONS="" DOCUMENT="" @@ -85,18 +86,24 @@ # make Compose input methods work [ -z "$LC_ALL" ] && export LC_ALL="$LANG" -# if pulseaudio is running, use it if VM has the driver, or fall back to OSS +# if pulseaudio is running, use it if VM has the driver if pulseaudio --check 2>/dev/null ; then if "$VM" -help 2> /dev/null | grep -q vm-sound-pulse ; then -VMOPTIONS="$VMOPTIONS -vm-sound-pulse" +VMSOUND="-vm-sound-pulse" else -VMOPTIONS="$VMOPTIONS -vm-sound-oss" if padsp true 2>/dev/null ; then +VMSOUND="-vm-sound-oss" WRAPPER=padsp fi fi fi +# Otherwise use ALSA if available +[ -z "$VMSOUND" -a -e /proc/asound/cards ] && VMSOUND="-vm-sound-ALSA" + +# Fall back on OSS +[ -n "$VMSOUND" ] || VMSOUND="-vm-sound-oss" + # enable compositioninput case "$LANG" in bn* | gu* | hi* | kn* | ml* | mr* | ta* | te* | sa* ) @@ -110,5 +117,5 @@ # VM, Image, and Document are non-optional # Document has to be present even if empty for IMOPTIONS to work -$DEBUG $WRAPPER "$VM" $VMOPTIONS "$IMAGE" "$DOCUMENT" $IMOPTIONS -exec $WRAPPER "$VM" $VMOPTIONS "$IMAGE" "$DOCUMENT" $IMOPTIONS +$DEBUG $WRAPPER "$VM" $VMOPTIONS $VMSOUND "$IMAGE" "$DOCUMENT" $IMOPTIONS +exec $WRAPPER "$VM" $VMOPTIONS $VMSOUND "$IMAGE" "$DOCUMENT" $IMOPTIONS ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Music keyboard stuck keys
Hi, Some testers at the OLPC office in Nicaragua found that it's quite easy to break the shiny new piano. 1. Use one finger to play a note on the piano (and hold that finger down). 2. Use another finger to scroll up and down in the instrument selector above the piano. 3. Remove the instrument-scroll finger. 4. Remove the piano note finger. The piano note stays held down (shown in yellow, with the sound continuing). Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Music keyboard stuck keys
On Fri, Apr 5, 2013 at 5:20 PM, Gonzalo Odiard wrote: > I will try. > Is not the same issue we see in Paint with the mouse emulation? No, because there is no mouse movement involved. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Etoys] Use ALSA sound backend if available
Hi, On Wed, Mar 27, 2013 at 1:10 PM, Daniel Drake wrote: > Extend the sound backend selection code to consider using ALSA. > On XO-1.75 and XO-4 this fixes sound in etoys with squeak-vm-4.x. > It also fixes XO-4 sound recording which was not working on any previous > version. Ping, any news here? Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)
On Fri, Apr 12, 2013 at 6:42 PM, Daniel Narvaez wrote: > I might not have yet made explicit what a web application provides on the > top of an html page loaded in a browser, which is what we get with 1. Taking > a look to the Chromium documentation is a good way to get an idea of it. > > http://developer.chrome.com/trunk/apps/api_index.html Thanks, I was waiting for someone to succinctly explain the perceived benefit of using Chrome as a backend for this project, and this seems to be it. One way to think about this is that we are used to Python, which has a nice standard library. But javascript basically doesn't have that. And this Chrome API provides some kind of equivalent. For this discussion, we might divide the Chrome API into 2 different parts 1. General utility functions (e.g. i18n, events) 2. Integration with low level system functions (e.g. bluetooth) I would say we have multiple alternatives for #1. e.g. qooxdoo is one that I am familiar with. So the real benefit of the Chrome thing is the system integration? Is that something really needed for Sugar? It would be necessary if we were to port *all* Sugar activities to javascript, but I am not sure if that is our goal. There are certainly a lot of things that can be done without such system access. I also have some other concerns about using Chrome as a backend (please correct any inaccuracies): 1. We have to accept all constraints of Chrome - both present and future. We have found two already: the challenges of handling of multiple versions, and the challenges of making this system work without having chrome running in the background all the time. 2. From my limited understanding, Chrome/Chromium is technically an open source project, since code is made available, but does not fit under many more definitions of "open source project". It's not something that is developed in the open with decisions run past the community etc. That doesn't fit the Sugar model very well. 3. I see this project as a way of taking us closer to Sugar (in some sense) on Android. Can Chrome webapps work as first-class citizens on Android? > (Hopefully they will some day converge between browsers!). There is already convergence in the "utility function" part of such APIs - for example you can take qooxdoo and use all of its API on any browser. I think it is only a matter of time until some kind of system emerges that provides a browser-independent API to low level system functions as well. (or maybe we already have that: gobject-introspection, which can be used in javascript?) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Chromium integration inside the sugar shell (was Re: Kicking off HTML5 activities work)
On Wed, Apr 17, 2013 at 9:39 AM, Daniel Narvaez wrote: > But is WebKit so much better? For example the WebKit2 decision _seems_ to > have been made by Apple engineers without even talking to major > contributors. The gtk bits are maintained the way we would like them to > but... I'm not sure that applies to the rest of the codebase. I think WebKit is better, but I am no expert. I have seen extensive technical discussions on public mailing lists. I have gotten good and detailed responses on the public bug tracker. I've also benefitted from information posted on bug reports reported by other people. And the GTK guys have done a great job at catering to our immediate needs. There are other factors too. Chromium bundles a load of libraries, rather than using systemwide ones, which is not really the model that we expect on the open source desktop. I think this is the main reason why it is not in Fedora (Fedora has a guideline against that, and packaging Chromium is no easy task as a result). WebKit is much better there, and in being in general a good "open source desktop friendly" solution. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH Etoys] Use ALSA sound backend if available
On Mon, Apr 15, 2013 at 10:20 AM, Bert Freudenberg wrote: > On 15.04.2013, at 07:53, Daniel Drake wrote: >> On Wed, Mar 27, 2013 at 1:10 PM, Daniel Drake wrote: >>> Extend the sound backend selection code to consider using ALSA. >>> On XO-1.75 and XO-4 this fixes sound in etoys with squeak-vm-4.x. >>> It also fixes XO-4 sound recording which was not working on any previous >>> version. >> >> Ping, any news here? >> >> Thanks >> Daniel > > > Ah, I'm sorry, didn't get to it yet. Thanks for the reminder! Another quick reminder for this patch :) Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Prototype python <-> js IPC
On Thu, Apr 25, 2013 at 3:59 PM, Daniel Narvaez wrote: > Hello, > > I wrote a quick prototype for a possible python <-> js IPC. I am missing some background here. In what cases do we need such IPC? The two cases that spring to mind are journal and collaboration. > I think in an ideal world the javascript code would communicate directly > with system services. I agree. To me, gobject-introspectionis the obvious choice here, and it can be used from javascript (in some form at least). How hard would it be to make it available here? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Fallback to _NET_WM_PID to map windows to activities
Thanks, this can be used to fix the problem detailed in my mail "Window handling for non-Python activities" I have tested it. On Sat, Feb 2, 2013 at 6:18 AM, Daniel Narvaez wrote: > -def get_type(self): > +def get_bundle_id(self): > """Retrieve the activity bundle id for future reference""" > -if not self._windows: > -return None > -else: > -return SugarExt.wm_get_bundle_id(self._windows[0].get_xid()) > +self._bundle_id Missing return statement here? > diff --git a/src/jarabe/view/service.py b/src/jarabe/view/service.py > index 61b3d59..c7187c7 100644 > --- a/src/jarabe/view/service.py > +++ b/src/jarabe/view/service.py > @@ -80,9 +80,9 @@ class UIService(dbus.service.Object): > return False > > @dbus.service.method(_DBUS_SHELL_IFACE, > - in_signature='ss', out_signature='') > -def NotifyLaunch(self, bundle_id, activity_id): > -shell.get_model().notify_launch(activity_id, bundle_id) > + in_signature='ssi', out_signature='') > +def NotifyLaunch(self, bundle_id, activity_id, pid): > +shell.get_model().notify_launch(activity_id, bundle_id, pid) This is an API change. The toolkit calls this method so it must be updated as well, otherwise activity launch breaks. And I guess we might have broken compatibility with some other things like etoys. I wonder if we can avoid this API change - can the receiver of the dbus message look up the PID of the sender? Some possible clues here: http://lists.freedesktop.org/archives/dbus/2008-September/010403.html ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] Fallback to _NET_WM_PID to map windows to activities
On Wed, May 1, 2013 at 3:25 AM, Daniel Narvaez wrote: > It has been a while since I wrote this patch, hopefully I'm not > misremembering... I think NotifyLaunch is in practice private to the shell, > activities should have no need to use it (and are not supposed to be > importing activityfactory.py). When I tested it yesterday it did break activity launch until I fixed the toolkit for this API change. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH TamTam 1/2] Output to ALSA directly from csound
TamTam sound is crackly on some setups (e.g. XO-1.5 and newer with
dmix running at 48000Hz). http://dev.laptop.org/ticket/12651
Clooper seems to implement its own ALSA sample rate resampling,
as well as upsampling of the period rate to overcome any differences
in csound period size and ALSA period size. This code is the cause of
the crackles.
Switch to csound's internal ALSA backend, which works well, and does
not have these problems. Tested on XO-1, XO-1.5, XO-1.75 and XO-4.
---
common/Config.py| 5 -
common/Resources/tamtamorc.csd | 2 +-
common/Util/CSoundClient.py | 4 +-
common/Util/Clooper/Makefile| 2 +-
common/Util/Clooper/aclient.cpp | 122 ++---
common/Util/Clooper/audio.cpp | 237
6 files changed, 14 insertions(+), 358 deletions(-)
delete mode 100644 common/Util/Clooper/audio.cpp
diff --git a/common/Config.py b/common/Config.py
index b1c1318..bb9c3ff 100644
--- a/common/Config.py
+++ b/common/Config.py
@@ -55,13 +55,8 @@ for i in (INSTANCE_DIR, DATA_DIR, SNDS_INFO_DIR, TMP_DIR):
PLUGIN_DEBUG = os.getenv("CSOUND_LOGFILE", "")
PLUGIN_VERBOSE = DEBUG
PLUGIN_UNIVORC = join(FILES_DIR, "tamtamorc.csd")
-PLUGIN_KSMPS = 64
PLUGIN_RATE = 16000
-## PLUGIN ALSA PARAMETERS:
-PLUGIN_PERIOD = 1024
-PLUGIN_NPERIODS = 2
-
try:
from sugar3.graphics.toolbarbox import ToolbarBox, ToolbarButton
HAVE_TOOLBOX = True
diff --git a/common/Resources/tamtamorc.csd b/common/Resources/tamtamorc.csd
index f0a63f1..3adf81b 100644
--- a/common/Resources/tamtamorc.csd
+++ b/common/Resources/tamtamorc.csd
@@ -1,6 +1,6 @@
--n -m0 -W -s -d
+-n -odac -m0 -W -s -d
sr=16000
diff --git a/common/Util/CSoundClient.py b/common/Util/CSoundClient.py
index 3cf6794..c082137 100644
--- a/common/Util/CSoundClient.py
+++ b/common/Util/CSoundClient.py
@@ -47,9 +47,7 @@ class _CSoundClientPlugin:
def __init__(self):
sc_initialize( Config.PLUGIN_UNIVORC, Config.PLUGIN_DEBUG,
-Config.PLUGIN_PERIOD, Config.PLUGIN_NPERIODS,
-Config.PLUGIN_VERBOSE,
-Config.PLUGIN_KSMPS, Config.PLUGIN_RATE)
+Config.PLUGIN_VERBOSE, Config.PLUGIN_RATE)
self.on = False
#self.masterVolume = 100.0
self.periods_per_buffer = 2
diff --git a/common/Util/Clooper/Makefile b/common/Util/Clooper/Makefile
index 0f28366..eaefae9 100644
--- a/common/Util/Clooper/Makefile
+++ b/common/Util/Clooper/Makefile
@@ -23,7 +23,7 @@ all : aclient.so
mv aclient.so $(LIB_NAME)/
touch $(LIB_NAME)/__init__.py
-aclient.so : aclient.cpp audio.cpp
+aclient.so : aclient.cpp
g++ $(CXXFLAGS) -shared -o $@ $< $(LDFLAGS)
clean :
diff --git a/common/Util/Clooper/aclient.cpp b/common/Util/Clooper/aclient.cpp
index f238c36..f8ecaea 100644
--- a/common/Util/Clooper/aclient.cpp
+++ b/common/Util/Clooper/aclient.cpp
@@ -14,18 +14,7 @@
#include
#include
-static double pytime(const struct timeval * tv)
-{
-struct timeval t;
-if (!tv)
-{
-tv = &t;
-gettimeofday(&t, NULL);
-}
-return (double) tv->tv_sec + (double) tv->tv_usec / 100.0;
-}
#include "log.cpp"
-#include "audio.cpp"
int VERBOSE = 3;
@@ -510,52 +499,31 @@ struct TamTamSound
MYFLT tick_total;
/** the upsampling ratio from csound */
-unsigned int csound_ksmps;
snd_pcm_uframes_t csound_frame_rate;
snd_pcm_uframes_t csound_period_size;
-snd_pcm_uframes_t period0;
-unsigned int period_per_buffer; //should be 2
-int up_ratio; //if the hardware only supports a small integer multiple of
our effective samplerate, do a real-time conversion
log_t * ll;
-SystemStuff * sys_stuff;
-TamTamSound(log_t * ll, char * orc, snd_pcm_uframes_t period0, unsigned
int ppb, int ksmps, int framerate )
+TamTamSound(log_t * ll, char * orc, int framerate )
: ThreadID(NULL), PERF_STATUS(STOP), csound(NULL),
music(),
ticks_per_period(0.0),
tick_adjustment(0.0),
tick_total(0.0),
-csound_ksmps(ksmps),//must agree with the
orchestra file
csound_frame_rate(framerate), //must agree with the
orchestra file
-period0(period0),
-period_per_buffer(ppb),
-up_ratio(1),
-ll( ll ),
-sys_stuff(NULL)
+ll( ll )
{
-sys_stuff = new SystemStuff(ll);
-if (0 > sys_stuff->open(csound_frame_rate, 4, period0,
period_per_buffer))
-{
-return;
-}
-sys_stuff->close(0);
-up_ratio = sys_stuff->rate / csound_frame_rate;
-csound_period_size = (sys_stuff->period_size % up_ratio == 0)
- ? sys_stuff->period_size / up_ratio
- : csound_ksmps * 4;
-
csound = csoundCreate(NULL);
-int argc=3;
+int argc=4;
const char **argv = (const char**)malloc(argc*sizeof(char*));
argv[0
[Sugar-devel] [PATCH TamTam 2/2] Clooper: strip built library
This saves some disk space. The unstripped version can still be built with "make aclient.so" --- common/Util/Clooper/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/common/Util/Clooper/Makefile b/common/Util/Clooper/Makefile index eaefae9..8dfd624 100644 --- a/common/Util/Clooper/Makefile +++ b/common/Util/Clooper/Makefile @@ -20,6 +20,7 @@ LDFLAGS+= $(python-config --libs) \ all : aclient.so rm -rf $(LIB_NAME) mkdir $(LIB_NAME) + strip aclient.so mv aclient.so $(LIB_NAME)/ touch $(LIB_NAME)/__init__.py -- 1.8.1.4 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH TamTam 1/2 v2] Output to ALSA directly from csound
TamTam sound is crackly on some setups (e.g. XO-1.5 and newer with
dmix running at 48000Hz).
Clooper seems to implement its own ALSA sample rate resampling,
as well as upsampling of the period rate to overcome any differences
in csound period size and ALSA period size. This code is the cause of
the crackles.
Switch to csound's internal ALSA backend, which works well, and does
not have these problems. Tested on XO-1, XO-1.5, XO-1.75 and XO-4.
---
common/Config.py| 5 -
common/Resources/tamtamorc.csd | 2 +-
common/Util/CSoundClient.py | 4 +-
common/Util/Clooper/Makefile| 4 +-
common/Util/Clooper/aclient.cpp | 127 +++--
common/Util/Clooper/audio.cpp | 237
6 files changed, 17 insertions(+), 362 deletions(-)
delete mode 100644 common/Util/Clooper/audio.cpp
v2: totally remove dependency on ALSA header and library
diff --git a/common/Config.py b/common/Config.py
index b1c1318..bb9c3ff 100644
--- a/common/Config.py
+++ b/common/Config.py
@@ -55,13 +55,8 @@ for i in (INSTANCE_DIR, DATA_DIR, SNDS_INFO_DIR, TMP_DIR):
PLUGIN_DEBUG = os.getenv("CSOUND_LOGFILE", "")
PLUGIN_VERBOSE = DEBUG
PLUGIN_UNIVORC = join(FILES_DIR, "tamtamorc.csd")
-PLUGIN_KSMPS = 64
PLUGIN_RATE = 16000
-## PLUGIN ALSA PARAMETERS:
-PLUGIN_PERIOD = 1024
-PLUGIN_NPERIODS = 2
-
try:
from sugar3.graphics.toolbarbox import ToolbarBox, ToolbarButton
HAVE_TOOLBOX = True
diff --git a/common/Resources/tamtamorc.csd b/common/Resources/tamtamorc.csd
index f0a63f1..3adf81b 100644
--- a/common/Resources/tamtamorc.csd
+++ b/common/Resources/tamtamorc.csd
@@ -1,6 +1,6 @@
--n -m0 -W -s -d
+-n -odac -m0 -W -s -d
sr=16000
diff --git a/common/Util/CSoundClient.py b/common/Util/CSoundClient.py
index 3cf6794..c082137 100644
--- a/common/Util/CSoundClient.py
+++ b/common/Util/CSoundClient.py
@@ -47,9 +47,7 @@ class _CSoundClientPlugin:
def __init__(self):
sc_initialize( Config.PLUGIN_UNIVORC, Config.PLUGIN_DEBUG,
-Config.PLUGIN_PERIOD, Config.PLUGIN_NPERIODS,
-Config.PLUGIN_VERBOSE,
-Config.PLUGIN_KSMPS, Config.PLUGIN_RATE)
+Config.PLUGIN_VERBOSE, Config.PLUGIN_RATE)
self.on = False
#self.masterVolume = 100.0
self.periods_per_buffer = 2
diff --git a/common/Util/Clooper/Makefile b/common/Util/Clooper/Makefile
index 0f28366..4fddb2e 100644
--- a/common/Util/Clooper/Makefile
+++ b/common/Util/Clooper/Makefile
@@ -15,7 +15,7 @@ LIB_NAME = $(CSOUND_ARCH)_$(CSOUND_VERSION)
CXXFLAGS = $(shell python-config --cflags) \
-Wall -Werror -fPIC -O2 -finline
LDFLAGS+= $(python-config --libs) \
- -lasound -lcsound
+ -lcsound
all : aclient.so
rm -rf $(LIB_NAME)
@@ -23,7 +23,7 @@ all : aclient.so
mv aclient.so $(LIB_NAME)/
touch $(LIB_NAME)/__init__.py
-aclient.so : aclient.cpp audio.cpp
+aclient.so : aclient.cpp
g++ $(CXXFLAGS) -shared -o $@ $< $(LDFLAGS)
clean :
diff --git a/common/Util/Clooper/aclient.cpp b/common/Util/Clooper/aclient.cpp
index f238c36..e68b8cb 100644
--- a/common/Util/Clooper/aclient.cpp
+++ b/common/Util/Clooper/aclient.cpp
@@ -12,20 +12,8 @@
#include
#include
-#include
-static double pytime(const struct timeval * tv)
-{
-struct timeval t;
-if (!tv)
-{
-tv = &t;
-gettimeofday(&t, NULL);
-}
-return (double) tv->tv_sec + (double) tv->tv_usec / 100.0;
-}
#include "log.cpp"
-#include "audio.cpp"
int VERBOSE = 3;
@@ -510,52 +498,31 @@ struct TamTamSound
MYFLT tick_total;
/** the upsampling ratio from csound */
-unsigned int csound_ksmps;
-snd_pcm_uframes_t csound_frame_rate;
-snd_pcm_uframes_t csound_period_size;
-snd_pcm_uframes_t period0;
-unsigned int period_per_buffer; //should be 2
-int up_ratio; //if the hardware only supports a small integer multiple of
our effective samplerate, do a real-time conversion
+int csound_frame_rate;
+long csound_period_size;
log_t * ll;
-SystemStuff * sys_stuff;
-TamTamSound(log_t * ll, char * orc, snd_pcm_uframes_t period0, unsigned
int ppb, int ksmps, int framerate )
+TamTamSound(log_t * ll, char * orc, int framerate )
: ThreadID(NULL), PERF_STATUS(STOP), csound(NULL),
music(),
ticks_per_period(0.0),
tick_adjustment(0.0),
tick_total(0.0),
-csound_ksmps(ksmps),//must agree with the
orchestra file
csound_frame_rate(framerate), //must agree with the
orchestra file
-period0(period0),
-period_per_buffer(ppb),
-up_ratio(1),
-ll( ll ),
-sys_stuff(NULL)
+ll( ll )
{
-sys_stuff = new SystemStuff(ll);
-if (0 > sys_stuff->open(csound_frame_rate, 4, period0,
period_per_buffer))
-{
-return;
-}
-sys_stu
Re: [Sugar-devel] [PATCH TamTam 1/2 v2] Output to ALSA directly from csound
On Thu, May 2, 2013 at 7:44 AM, Gonzalo Odiard wrote: > Thanks Daniel. > Two questions: > when was the change done? I mean, what sugar version should we mark as > compatible > with a activity with this change? I don't think it affects sugar version compatibility. > The second is, if you already have the binaries compiled for every xo, > if you can send me the binaries, I don't need do it again. Would be best if you could compile them. Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] multiple home views
On Thu, May 2, 2013 at 8:15 AM, Walter Bender wrote: > [1] http://wiki.sugarlabs.org/go/Features/Multiple_home_views How is the teacher going to use the proposed functionality to ensure a consistent home view on all the XOs? Will he/she go to each XO one by one and mark the activities appropriately? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] New TuxPaint and GCompris wrapper activities
Hi,
The TuxPaint and GCompris activities on activities.sugarlabs.org don't
support ARM, and the solution taken by a few deployments is to add the
systemwide gcompris/tuxpaint packages (from Fedora) to the OS build
and use simple launcher activities from
http://dev.laptop.org/~gonzalo/nicaragua/
Unfortunately these have a small problem in new versions of Sugar,
after you use the activity for more than 90 seconds and exit, Sugar
brings up a confusing error, "TuxPaint failed to launch" even though
no problems actually occurred.
There is some progress in fixing this in Sugar ("[PATCH sugar]
Fallback to _NET_WM_PID to map windows to activities"), for now I have
published some activity versions wihch work around the issue for
existing versions of Sugar:
http://dev.laptop.org/~dsd/activities/TuxPaint-6.1.xo
http://dev.laptop.org/~dsd/activities/GCompris-3.1.xo
Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Music Keyboard failed to start
On Mon, May 6, 2013 at 2:23 PM, Petr Huf wrote: > I have found in aclient.cpp function sc_initialize (causing this error) and > here is: > > PyArg_ParseTuples(args, "ssii", &str, &log_file, &VERBOSE, &framerate) > > and "ssi" means clearly 4 arguments and not 7 how compiler says. I see > problem with Python, but where? All packages are updated. TamTam is not very good at picking the right binary so I would say delete them all apart from the one you compiled yourself. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Web activity example that uses html5 canvas
On Wed, May 1, 2013 at 8:36 PM, Manuel Quiñones wrote: > "Draw the simple background only when the widget resizes - SL #1959" > https://git.sugarlabs.org/clock/mainline/commit/5ec58d240ab99e3268f85ba31c1ed0ee99f78260 > > So the next release of Clock will be a more fair comparison. Can we have a new release of Clock, or a test .xo? James's initial test is quite interesting. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Github issue tracking
On Sat, May 11, 2013 at 4:15 AM, Daniel Narvaez wrote: > https://github.com/sugarlabs/sugar-toolkit-gtk3/issues/27 > > We should probably decide if we want to keep using trac instead and if so > turn the issue tracker on github off. > > Last time we discussed it, the idea was to keep using trac to not depend too > much on closed source github. What are people thoughts these days? I would prefer to stay with trac, to avoid a split/migration, to keep the info on the tickets directly under our control, and to keep with our open source ideals. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Advice request: XO sound recording
On 30 September 2010 23:33, Art Hunkins wrote: > The Record activity is a natural for recording audio, and I had thought it > would be the appropriate vehicle. I've recently discovered that it only > produces Ogg Speex files, not the higher-quality Ogg Vorbis variety. Please double check this. I'm pretty certain that it saves as vorbis and just confirmed that with a glance at the code. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Advice request: XO sound recording
On 3 October 2010 21:10, Art Hunkins wrote: > I was confused because I was working with previous versions - namely 66 and > 67, which do output Speex. This is because I have serious problems with 79 > on > all systems, 0.84 - 0.88 SoaS (as well as 0.84 on the XO-1.5). You should probably test the latest version of the activity, which is currently v86. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] changes in trac and others
On 4 October 2010 17:09, Frederick Grose wrote: > The SEETA Developer: field might better be adjusted to Developer:, and we > could use a convention to tag the developer's name, such as, [SEETA] Ishan On a community level, I don't think its right to assign a specific developer to the task. Anyone is welcome to come along and post a patch. If SEETA want to add their internal metadata to the tickets they should use the keywords field. e.g. add keyword seetadev:Ishan Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Proposal of dotted activity version number
On 4 October 2010 15:27, Gonzalo Odiard wrote: > What do others think about this approach? Packagers? A clearer way to discuss this would be to just send a patch. That way there is no doubt over the details of the implementation that you are proposing. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v3 sugar] Pulsing icon delayed by 5 seconds or so SL#2080
On 9 October 2010 12:51, Anurag Chowdhury wrote: > When we click on the icon of an activity we see a pulsing icon of that > activity > before the activity starts and usually there is a time delay between the > clicking of the icon and appearance of the pulsing icon This patch doesn't make sense and doesn't do what your description says... I also don't see how the solution described in the description would solve the problem. Surely the delay is the time needed to load the icon into memory and render the first frame. Altering the timing of when subsequent frames appear isn't going to affect the loading time of the first one, right? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SL Bug #2063
On 10 October 2010 20:14, Mukul Gupta wrote: > With reference to SL Bug # 2063 which deals with bringing some kind of > notification alert whenever an unhandled python exception occurs, I had a > few doubts. There are two approaches that I can think of. Neither of these sounds sensible. What's wrong with the obvious solution of popping up a dialog when the exception occurs? Technically the exceptions are not unhandled, if they were unhandled then sugar would crash. I guess we're referring to exceptions that are not handled gracefully and instead fall back to a catch-all handler which does not have the knowledge to act on them. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v5 sugar] Pulsing icon delayed by 5 seconds or so SL#2080
On 13 October 2010 16:28, Anurag Chowdhury wrote: > When we click on the icon of an activity we see a pulsing icon of that > activity before the activity starts and usually there is a time delay between > the clicking of the icon and appearance of the pulsing icon , where tha amount > of delay differs by the complexity of the icon i.e. more complex the icon is > larger is the delay. > So In order to minimise the delay we replaced the animation with its raw svg > image for the first frame of rendering Interesting idea. However, I'm not convinced that rendering a "raw svg" versus rendering a svg with a simple stroke/fill applied is going to result in much difference. I'm happy to be proven wrong - perhaps you could take an activity as an example and measure exactly how long the first self.update() call takes to complete? If you aren't already, it would be a good idea to use a profiler to identify with clarity the exact part of the code that is taking the most time. Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Read: focus after launching
On 13 October 2010 11:45, Simon Schampijer wrote: > Hi, > > when working on the issue in Read that the dpad keys do not work directly > when in ebook mode [1], I postulated that Read when it comes up should > always grab the focus on the view so scrolling using the arrow keys is > directly possible. Agreed. Activities should set a sensible focus on launch. For example Write focuses the text input area. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
On 14 October 2010 10:38, Peter Robinson wrote: > I think this should be an input event, I think in most cases this is > how input from lid switches and the like are handled across most > things now. It already is an input event, but I suspect that diving down into opening input devices is the wrong thing to do. Next sensible step would be to look at how GNOME does it. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Dbus signal when ebook switch is activated
On 14 October 2010 19:29, Gonzalo Odiard wrote: > I don't see Gnome doing anything with this event. > It's a very specific XO thing ... Oops. I meant to suggest that you look at how GNOME deals with the lid-closed switch. Since, from the kernel point of view, its exactly the same reporting mechanism (through an input device). Whatever interface GNOME is using to listen for lid closes, its very likely that you can listen for ebook mode the same way. > I probably don't are explaining well what I need. > I am reading the event with dbus, it's working. I think it's the wright way > to do this today. > But it's strange it send a array with two boolean values (lid and ebook > switchs) but ever with the value in False. Are you sure those 2 values are supposed to refer to the lid and ebook switches? > I want to check if the software who emit the dbus signal is checking in the > wright place for the switch state. Then you need to look closely at HAL, if you're tracking down that HAL message. I don't know anyone in the OLPC community who has instant expertise here; you need to dive into the docs and code and figure it out. > Also the devices are different: > in XO-1 cat /proc/bus/input/devices show the lid switch in event1 ant the > ebook switch in event2 > in XO-1.5 cat /proc/bus/input/devices show the lid switch in event2 ant the > ebook switch in event4 > in the XO-1 don't have the /proc/acpi directory That's to be expected, the XO-1 doesn't use ACPI and the XO-1.5 does. But the aim is of course for the events to appear similar enough that you don't have to care at the activity level. There may well be kernel issues to solve here. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH v5 sugar] Shutdown (and Logout) menuitems should activate
On 19 October 2010 02:08, Anurag Chowdhury wrote: > Show a busy cursor when shutdown, logout, or reboot options are > selected. Defer the selected action to an idle task so that the cursor > change is flushed to the display. You forgot to credit James and Aleksey who made major contributions to your work. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Request to review solution for SL #2464
On 19 October 2010 17:48, Gonzalo Odiard wrote: > Like I said previously to Gary, I don't think is a permissions problem, > because the .xo file is a zip, and zip ignores permissions. It doesn't actually. I was surprised too. Run a quick experiment (zip up a file with weird permissions then extract it). Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [IAEP] stepping down as maintainer
On 24 October 2010 05:42, David Farning wrote: > Sugar Labs lost its lead developer. It is unfortunate that no-one has > done a public review of the reasons and implications of Tomeu quiting. > Tomeu's leaving is significant enough that Sugar Labs should take a > hard look at what is working, what is not working, and how to fix the > pieces that are not working. I think a lot of contributors forgot to be nice to the maintainer. If I were in Tomeu's position I think I would have stepped down a while ago (I've been put in what I think are similar positions in other projects I've been involved in). Too much emails and not enough code, simple maintainers wishes being ignored, nobody stepping up to help the maintainer with the increasing workload, etc. A key part of contributing to an open source is keeping the maintainer engaged and motivated. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH V3] Copying files multiple times results in bogus names. (SL#2060)
On 12 November 2010 19:01, wrote: > From: Shanjit Singh Jajmann This is not your own work. You shouldn't put your name on it like this. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH V3] Copying files multiple times results in bogus names. (SL#2060)
On 13 November 2010 11:41, wrote: > From: Shanjit Singh Jajmann > > For every existing file copied to the location, the names are explicitly > changed to filename_copynumber.extension e.g. games_1.png, games_2.png, > games_3.jpg and so on. > > --- > v1 -> v2. Parenthesis idea removed, i initialised from 1. > Recommendations by Gonzalo Odiard, James Cameron and Martin Dengler added. You still missed my point. And anything after "---" gets removed in the commit message. My point is that this patch is written by Gonzalo Odiard. You can see it clearly in this email thread on November 10th. Therefore the first line of your patch should be: From: Gonzalo Odiard It's still OK for you to submit the patch even though you didn't write it, and Gonzalo would probably even appreciate you taking on the role of submission, but its important that you put the correct authorship. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Engineering Team
On 20 November 2010 02:53, Aleksey Lim wrote: > = The problem = > > > Current situation with stuck patches queue is dangerous. Deployments > have to support their own big branches (branches, by themselves, is not > bad but big ones), at last I know about Dextrose. Such splitting is > really bad, e.g., people who test Sugar need to keep in mind that there > are upstream, OLPC, Dextrose, etc. Sugars. OLPC has never shipped a downstream-patched Sugar in an official release in the last few years, and I can only think of a handful of examples where early development versions included downstream patches. To the best of my knowledge, SoaS, Debian, Ubuntu and SuSE do not ship downstream patches in their sugar distributions either. (unverified, but I've never heard of them doing this) Do you have any examples, other than Dextrose, of this problem existing? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Engineering Team
On 20 November 2010 14:38, Aleksey Lim wrote: > If OLPC doesn't shipp downstream patches thats relly good but I guess it > is because last stable OLPC sugar is 0.84 and that OLPC people are maints > of 0.84 branches. > > Dextrose has patches that are collected based on responce from the field. > This is a real problem to commit them to the trunk. OLPC also develops in response to field experiences, and every single patch that has gone into sugar-0.84 was committed to trunk (master) first. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Engineering Team
On 22 November 2010 00:02, James Cameron wrote: > I don't think this is true. Some patches, in particular my network > disconnect fix, are in 0.84 but not in trunk. Sounds like an oversight, do you know who committed it? The plan was for only upstream stuff: http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg10809.html Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Extending activity microformat spec to include optional olpc_activity_size
On 20 November 2010 05:59, Anish Mangal wrote: > I'm in process of developing an updater for sugar that reads urls (for > example [1]) which contain information in a format compliant with the > 'activity microformat specification' [2]. While writing the updater > code, I realized that I have to make lots of time and bandwidth > consuming http requests to ascertain activity bundle size; information > that can easily be included in the microformat embedded in the update > url. > > Thus, I propose to include an optional 'olpc-activity-size' tag in the > microformat specification, so as to rid the world of extra http > requests. If anyone has any concerns or suggestions, please speak up > :-) I don't buy it. The updater only has to make such a size query if the activity in question is an update to one that is installed (or if the activity is not present on the local system). Activities are generally megabytes in size, or at least hundreds of kilobytes. This transfer would follow the size query. Your proposal would just shave off a handful of bytes. Additionally: In my experience, even in OLPC deployments in wealthier nations, the latency on the internet connections (especially when split between hundreds of students in a school) is so high that its totally impractical to consider activities hosted on a remote server. Size querying or not, its just so painfully slow and unreliable. The only viable option is to host the activities (and activity group) locally on the school server. And OLPC provides good infrastructure to do this, which is in use in various countries. And when you're on the local school server, size querying delays become even more insignificant. If you're wanting to make efficiency improvements in activity updating, I would suggest tackling the bigger fish such as http://bugs.sugarlabs.org/ticket/1499 Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Extending activity microformat spec to include optional olpc_activity_size
On 29 November 2010 03:06, Bernie Innocenti wrote: > If the size were only needed at download time, then there would be no > need to perform a separate query: the size is already present in > Content-Length header. > > I think Anish wants to know the size beforehand to show it in the list > of update candidates. OK. If it's really important to save 1-2 seconds of update time (on a download thats then going to take probably more than a minute, perhaps substantially more) I'd suggest just dropping this part. > The schoolserver could cache the xo bundles. In Paraguay, this wasn't > happening for the largest ones due to size limits in the default > configuration of Squid. So we increased the maximum size for .xo. This would suggest that the size query time is really fast then, no need to change the microformat. No? > True, but distributing the bundles *to* the schoolservers is still on a > do-it-yourself basis, with rsync scripts, cronjobs, puppet and all the > associated complexity. Yet this is well documented and widely implemented practice. (There isn't another present day option that scales) > In the real world, most bundle downloads will probably come from sources > other than the deployment HQ. Think of Doom & Super Vampire Ninja Zero! > So the generic HTTP caching offered by squid is probably going to be a > better use of the school's bandwidth and disk space. But these activities aren't covered by the updater, right? The only ones that get covered in these queries would be the ones listed on the deployment-controlled activity group. Or is something changing? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Extending activity microformat spec to include optional olpc_activity_size
On 29 November 2010 09:16, Anish Mangal wrote: > In my little testing experience, this takes a lot more than 1-2 seconds for > a group of activities (such as this [1]). But the only case in which you'd have to run so many queries would be when you have *none* of those activities installed. > The updater works as > (1) checking and listing the updates > (2) the user selecting which updates to be installed > (3) downloading and installing selected bundles > > The delay in question happens at (1) while the user is waiting for the list > to appear (and that's why its important). I'd suggest dropping the size field from the listing then, if its really taking too long. (again, I feel the only realistic deployment scenarios make size querying quick: school server hosts activities, or school server webcache caches activities, so I'm not entirely convinced by your argument) > Your idea of only getting the size if the available bundle is newer or not > presently installed makes sense. I'll try and include this in the code. I assume your code of reference is the 0.84 updater - the last implementation of a microformat-based updater. If it's not, you should certainly examine it closely. This updater behaves in the way I have described. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [DESIGN] Extending activity microformat spec to include optional olpc_activity_size
On 30 November 2010 07:11, Bernie Innocenti wrote: > Each GET, even if content is in the squid cache requires a remote HTTP > query to check for stale data in the cache. With the typical ping times > of 500-1000ms, you end up waiting a couple of seconds. > > Sure, we could special-case .xo bundles in Squid to avoid the extra > check, since the bundle name changes when a new version of the bundle is > released. Yet another optimization kludge. > > Ah, forgot another important detail! On ASLO, query to files are being > redirected to the mirrors! So checking for the size would involve 2 > queries. > > >> > True, but distributing the bundles *to* the schoolservers is still on a >> > do-it-yourself basis, with rsync scripts, cronjobs, puppet and all the >> > associated complexity. >> >> Yet this is well documented and widely implemented practice. (There >> isn't another present day option that scales) > > Isn't the transparent web cache already a good enough solution for > activity distribution? Seems to me like you just made the argument "its not" It also doesn't work well for the first user who downloads the activities (especially when there are big ones like Scratch), stops working completely when the connectivity goes down even if everything is cached, and doesn't work at all with offline schools. It is easy to work with the XS here, just drop activity files in a directory or put them on a USB disk within a certain directory and plug it into the XS. It seems to me that this whole discussion is a bit bogus anyway, since (judging by later messages in this thread) Anish's code was querying all activity metadata (like size) even when it had nothing to do. So if you had 31 activities installed, and it queried the group page and discovred that 0 updates were available, the code would still query make 31 queries (determining file sizes) for no reason. I figure that if he corrects this behaviour then the problem is pretty much solved (or at least deserves re-evaluation). Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar] About my computer: use NetworkManager to acquire list of devices
On 1 December 2010 00:09, James Cameron wrote: > On XO-1 where there is one physical device, with one instance of > firmware, and two network interfaces (eth0, msh0), this may be > displayed as two devices with the same firmware version. According to that code, it won't show the mesh device, because its not NM_DEVICE_TYPE_WIFI. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Activities not compatible with Sugar-0.90
Hi, According to activities.sugarlabs.org, the following activities (amongst others, probably) are not compatible with Sugar-0.90: org.laptop.WebActivity org.laptop.sugar.ReadActivity org.laptop.TamTamSynthLab, org.laptop.TamTamJam, org.laptop.TamTamEdit, org.laptop.TamTamMini, org.vpri.EtoysActivity, org.laptop.MeasureActivity org.laptop.ImpodeActivity vu.lux.olpc.Maze com.garycmartin.Moon edu.mit.media.ScratchActivity org.laptop.Terminal org.laptop.Log If these activities do work on 0.90, please mark them as so. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities not compatible with Sugar-0.90
On 17 January 2011 21:07, Daniel Drake wrote: > Hi, > > According to activities.sugarlabs.org, the following activities > (amongst others, probably) are not compatible with Sugar-0.90: > If these activities do work on 0.90, please mark them as so. Found a few more: org.laptop.community.TypingTurtle org.sugarlabs.InfoSlicer org.laptop.community.Colors org.laptop.community.Finance org.laptop.StopWatchActivity ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities not compatible with Sugar-0.90
On 17 January 2011 21:17, Gonzalo Odiard wrote: > Daniel > I did a test with your image OS4, > http://wiki.laptop.org/go/User:Godiard/Activities_for_F14#Activities_test_in_OS4 Thanks, I assume you found some of the ones in my list to be working? If so, please mark them as 0.90 compatible on activities.sugarlabs.org Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities not compatible with Sugar-0.90
On 18 January 2011 13:06, Aleksey Lim wrote: > Also, in my mind, ASLO is primarily a doer/user tool, so ASLO editors > should not change existed uploads in the way they think is needed. I guess this means that my usage of activities.sugarlabs.org is not according to its design. Here's the task: I want to pull the latest activity version compatible with Sugar-0.90 for a specific set of activities from now until mid-April, several times a week. This is for their inclusion in development OS builds. What's your suggested approach to this? Right now I am querying http://activities.sugarlabs.org/services/update-aslo.php?id=ACTIVITY&appVersion=0.90 and parsing the resultant XML. Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities not compatible with Sugar-0.90
On 18 January 2011 19:58, Aleksey Lim wrote: > You can either do not use "appVersion" and update-aslo.php will return > recent versions or just create collection. The activity-testing.sl.o > implementation allows setting particular activity versions (it will be > pushed to production after testing within dextrose-2, that was the > purpose for this feature). In the last case, collection content will be > accessible via microformat page, eg: > > http://activities-testing.sugarlabs.org/services/micro-format.php?collection_nickname=fructose I don't think either of those is what I need: If I drop appVersion, I'd get activities that run only on Sugar-0.92 and are incompatible with Sugar-0.90 (none right now, but I forsee a couple appearing before mid-April arrives). I want activities that are compatible with Sugar-0.90. If I use a collection, the versions are fixed to the exact versions that I add to the collection, whereas (see last mail) I want the latest activity version compatible with Sugar-0.90. (please correct me if I've misunderstood what a collection is) I'm now feeling more confident that my current approach is correct. Thoughts? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities not compatible with Sugar-0.90
On 18 January 2011 22:00, Bernie Innocenti wrote: > This wasn't considered good for deployments enough because it doesn't > allow the pedagogical team to do any QA on updates before they hit the > users. Agreed. This is not for deployments, this is for development. > The downside of this approach is that development builds no longer get > the latest and greatest activities automatically. Is this what is > bothering you? Yes. > Perhaps we could add separate microformat URLs that > filter by Sugar version. This would be good, but is basically what we have now in a different format: http://activities.sugarlabs.org/services/update-aslo.php?id=ACTIVITY&appVersion=0.90 and I gathered from Aleksey that this isn't what activities.sugarlabs.org is designed for. (but judging from further responses, it's perhaps the only non-manual option that we have for now) Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activities not compatible with Sugar-0.90
On 18 January 2011 22:46, Bernie Innocenti wrote: > Originally, there was no way to pin particular versions in collections. > One would always get the latest version flagged to work on your browser. > Which is exactly what you're asking for. I'm not sure what's currently > missing server-side, but it shouldn't be hard to do. We already have that, in a different format, which works fine: http://activities.sugarlabs.org/services/update-aslo.php?id=ACTIVITY&appVersion=0.90 And it sounds like this (plus pestering of activity authors and/or use of admin power to correct compatibility info) is the best thing we have right now, even though both you and Aleksey don't fully see it as within the role of activities.sugarlabs.org (which I can understand too, but am left without somewhere else to turn). Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
