Re: [Sugar-devel] Planning for the future (Samuel Greenfeld)
On Wed, Feb 25, 2015 at 1:20 PM, Jerry Vonau wrote: > I know this is not a sugar issue directly, more of an OLPC issue but since > Fedora F12 the entire i686 platform's userland is being compiled with > -mtune=atom[1] which would use sse[2]. -mtune is designed not to break any compatibility. So -mtune=atom means that generated code is optimized for atom but *no compatibility with other CPUs is broken*. So -mtune=atom does not imply that gcc will spit out sse instructions because it feels like it. In fact, it will actively avoid generating sse instructions in order to maintain compatibility. (-march is probably what you are thinking of) > This causes problems for some parts > of sugar[3] now that java[4] is being used more and the XO-1 lacks sse. The WebKit issue happened because it generates its own machine code at runtime (not using gcc). It's definitely a bug that it dropped sse instructions in there without properly checking if the CPU can do sse, but not a common case that you will see throughout the distro. I assume you mean javascript there, and bug #4785 does not look like a sse-related issue to me. That issue shows a SIGSEGV whereas if code is using sse instructions you would instead expect a SIGILL. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Error on Write activity: no module named abiword
On Thu, Jul 17, 2014 at 9:21 PM, Gonzalo Odiard wrote: > > Do you have a abiword rpm with introspection enabled? > Hint: we use a custom rpm > > http://harvest.one-education.org/public/au1b-updates/RPMS/abiword-2.9.3-1.git20121011.fc18.olpc12.armv7hl.rpm The error that he's seeing suggests that the activity isn't trying to use introspection from abiword import Canvas so maybe the problem is that the Write version is too old? ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] XO on Fedora 20 (was Re: [GSoC] Porting To Python3)
On Wed, May 7, 2014 at 9:01 PM, Daniel Narvaez wrote: > On 7 May 2014 01:44, James Cameron wrote: >> >> On Tue, May 06, 2014 at 04:24:39PM +0200, Daniel Narvaez wrote: >> > [...] And with the XO stuck on Fedora 18 we might not have good >> > enough introspection to make the port compatible with it. >> >> If anybody would like to work on moving olpc-os-builder to something >> more recent, feel free. It isn't something OLPC is looking at right >> now, but it would be helpful to the users. >> >> Not the die hard 0.98 users, of course. ;-) > > > I'm giving that a try. I was able to build a Fedora 20 image for XO 1.5 > > https://github.com/dnarvaez/olpc-os-builder olpc-os-builder git master also has F20 support, as of a few months ago. Can't remember how good the result was. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Using a new keyboard layout for XO4
Hi Basanta,
On Thu, Nov 21, 2013 at 4:27 AM, Basanta Shrestha
wrote:
> Dear all,
> We are planing on using a different keyboard layout for XO4. The new layout
> we think is phonetically based and easier for children. I simply switched the
> /usr/share/X11/symbols/np file with a new one but did not work. I guess there
> are some other works that needs to be done before we can use this file. Can
> you suggest what needs to be done?
Yeah, it's not quite that simple. You need to leave the interaction
with the OLPC mode/variant in place. Add the following lines to the
end of the file:
partial alphanumeric_keys
xkb_symbols "olpc" {
include "np"
include "group(olpc)"
};
Now it should work.
Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking help to enable nepali keyboard input for XO-4
On Tue, Nov 12, 2013 at 10:14 PM, Basanta Shrestha wrote: > Amazingly changing the manufacturing data didn't do the job but changing > /etc/sysconfig/keyboard did. Wow! Now I have Nepali input system. Thank you > all. > > Now I need to find a place to change default locale to ne_NP, so that the > default interface is in Nepali. There is an option to do this in > manufacturing data but it would be better if it can be done using file. If all you want to do is change default keyboard and language, you can avoid doing any manufacturing data changes, and just do the [base] olpc-os-builder configuration I mentioned in my last email. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Performance: activities start up time
On Fri, Nov 8, 2013 at 12:44 PM, Gonzalo Odiard wrote: > One of the arguments of the dynamic bindings was a better startup time due > to not need initialize all the libraries until is needed use them. Then the > import should > be lighter than before. Looks like that is not so true. You should look in the last few months of archives of the pygobject list, the discussions that I was involved in. pygobject is not doing much lazy-loading, the overrides are really heavy, etc. Lots of improvements to be made. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking help to enable nepali keyboard input for XO-4
On Sun, Nov 10, 2013 at 5:18 PM, James Cameron wrote: > If you need to scale up this change to many laptops, contact > reu...@laptop.org or myself. I must know the SKU number. In the particular case of changing language/keyboard defaults as we are discussing, instead of changing manufacturing data I would recommend doing it via olpc-os-builder, configuration for [base], see http://dev.laptop.org/git/projects/olpc-os-builder/tree/modules/base/README#n46 Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] seeking help to enable nepali keyboard input for XO-4
On Thu, Nov 7, 2013 at 11:23 PM, Basanta Shrestha wrote: > But for XO-4 we will just be getting ones with English layout. I was > wondering how we can enable nepali keyboard input on it. Are these keyboards hard/clicky/high-school style, or soft/membrane? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] KukuAnakula: handle quit event
Hi, We are looking at deploying Kuku Anakula in Nicaragua, thanks for writing this activity. One problem is that the stop button doesn't actually cause the process to terminate. Notably, the music keeps playing and never stops, even though the activity has disappeared. Here's a hack patch to make this work. I think the more normal approach is to write the app more like a state machine, with only one place that handles and swallows pygame events, leading to just one place where this event could be neatly handled. --- kuku.py 2012-05-27 06:21:36.0 + +++ /home/olpc/kuku.py 2013-10-15 18:34:17.174872806 + @@ -595,7 +595,9 @@ gtk.main_iteration() events = pygame.event.get() for evt in events: -if evt.type == pygame.KEYDOWN: +if evt.type == pygame.QUIT: +sys.exit(0) +elif evt.type == pygame.KEYDOWN: qa,num_players,score,time_clock = self.game_start(screen,gridsize,font) return (qa,num_players,score,time_clock) @@ -616,7 +618,9 @@ gtk.main_iteration() events = pygame.event.get() for evt in events: -if evt.type == pygame.KEYDOWN: +if evt.type == pygame.QUIT: +sys.exit(0) +elif evt.type == pygame.KEYDOWN: qa,num_players,score,time_clock = self.game_start(screen,gridsize,font,started=1) score.set(state.score) return (qa,num_players,score,time_clock) @@ -653,7 +657,9 @@ gtk.main_iteration() events = pygame.event.get() for evt in events: -if evt.type == pygame.KEYDOWN: +if evt.type == pygame.QUIT: +sys.exit(0) +elif evt.type == pygame.KEYDOWN: qa,num_players,score,time_clock = self.reset_board(screen,gridsize,font) return (qa,num_players,score,time_clock) else: @@ -824,8 +830,9 @@ events = pygame.event.get() for evt in events: - -if evt.type == pygame.KEYDOWN: +if evt.type == pygame.QUIT: +sys.exit(0) +elif evt.type == pygame.KEYDOWN: # elif evt.key == pygame.K_SPACE: if not evt.key in move_keys: x = player.grid_position[0] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] GeoGebra on 13.2.0
On Tue, Oct 15, 2013 at 11:40 AM, Daniel Drake wrote: > Has anyone succeeded with the GeoGebra activity on OLPC OS 13.2.0? > > Using the activity from > http://dev.laptop.org/~gonzalo/activities/GeoGebra-5.1.xo > > Testing on XO-1.75 after "yum install java" > > The app usually fails to launch, with an exception that seems to > change slightly each time. Updated to the latest geogebra jar files. Now it works. http://dev.laptop.org/~dsd/activities/GeoGebra-5.2.xo Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] GeoGebra on 13.2.0
Hi, Has anyone succeeded with the GeoGebra activity on OLPC OS 13.2.0? Using the activity from http://dev.laptop.org/~gonzalo/activities/GeoGebra-5.1.xo Testing on XO-1.75 after "yum install java" The app usually fails to launch, with an exception that seems to change slightly each time. One example: Exception in thread "AWT-XAWT" java.lang.NullPointerException: at java.util.concurrent.locks.AbstractQueuedSynchronizer.compareAndSetState(AbstractQueuedSynchronizer.java:566) at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:211) at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290) at sun.awt.SunToolkit.awtLock(SunToolkit.java:244) at sun.awt.X11.XBaseWindow.ungrabInput(XBaseWindow.java:883) at sun.awt.X11.XToolkit.run(XToolkit.java:675) at sun.awt.X11.XToolkit.run(XToolkit.java:591) at java.lang.Thread.run(Thread.java:724) java.lang.ExceptionInInitializerError at sun.awt.X11GraphicsConfig.getColorModel(X11GraphicsConfig.java:205) at java.awt.GraphicsConfiguration.createCompatibleImage(GraphicsConfiguration.java:177) at geogebra.e.c.a(Unknown Source) at geogebra.e.c.a(Unknown Source) at geogebra.e.c.a(Unknown Source) at geogebra.c.o.b(Unknown Source) at geogebra.c.o.a(Unknown Source) at geogebra.gui.f.i.a(Unknown Source) at geogebra.gui.f.j.a(Unknown Source) at geogebra.gui.f.j.a(Unknown Source) at geogebra.gui.aQ.o(Unknown Source) at geogebra.c.o.K(Unknown Source) at geogebra.c.o.a(Unknown Source) at geogebra.gui.e.b.a(Unknown Source) at geogebra.gui.e.b.a(Unknown Source) at geogebra.GeoGebra.a(Unknown Source) at geogebra.GeoGebra.main(Unknown Source) Caused by: java.lang.IllegalMonitorStateException at java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:155) at java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1260) at java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:460) at sun.awt.SunToolkit.awtUnlock(SunToolkit.java:252) at sun.awt.X11.XToolkit.nativeLoadSystemColors(Native Method) at sun.awt.X11.XToolkit.loadSystemColors(XToolkit.java:247) at java.awt.SystemColor.updateSystemColors(SystemColor.java:468) at java.awt.SystemColor.(SystemColor.java:460) ... 17 more Exited with status 10, pid 1936 data (None, ', mode 'w' at 0x11ab3e8>, 'ad32ad64c55039e6656169fa76baef9ca9a63d4d') But if you try enough times, it does successfully open. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Translating etoys home screen
On Tue, Oct 8, 2013 at 4:09 PM, Chris Leonard wrote: > Just a quick question Daniel, > > The Armenian translations are relatively new and may not have been > committed. Are you working directly from the PO files in Pootle or > the EToys repo? The PO files I can manage myself. The translations I'm worried about (the home screen, tutorials, etc) are done outside of PO files :( Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Translating etoys home screen
Hi Bert, Could you advise on how we could translate the etoys home screen to Armenian? I see: http://forum.world.st/How-to-translate-strings-in-Home-pr-td3527757.html However the crucial "how to translate" link there is broken. The first step in this translation would be to generate a list of strings so that I can pass them on for translation. Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Are we ready for code freeze?
On Mon, Sep 2, 2013 at 12:21 PM, Daniel Narvaez wrote: > I propose we don't freeze and instead we keep releasing 0.99.x every four > weeks, until we feel we have done enough testing and bug fixing. This is not > what you are supposed to do with time based releases but I'd rather delay > than release something we can't be proud of. Just as something to keep in mind, I would say that recent Sugar release cycles have also had a certain amount of uncertainty around this time. In previous cases we have just stuck to the timeline (more or less) and released anyway, especially when it is unclear how long the delay would otherwise need to be. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] sugar-build won't start
Hi,
Trying to use sugar-build for the first time in a while on F19. I want
to avoid creating a F19 chroot inside a F19 install.
prefs.json is:
{"use_broot": false, "use_chroot": false}
./osbuild clean
git clean -fdx
git pull
./osbuild shell
Last command fails with:
Traceback (most recent call last):
File "/home/dsd/projects/sugar-build/build/commands/broot/shell",
line 4, in
common.run("shell")
File "/home/dsd/projects/sugar-build/build/commands/common.py", line
77, in run
if not getattr(main, "cmd_%s" % command)():
File
"/home/dsd/projects/sugar-build/build/out/sandbox/install/lib/python2.7/site-packages/osbuild/main.py",
line 78, in cmd_shell
shell.start()
File
"/home/dsd/projects/sugar-build/build/out/sandbox/install/lib/python2.7/site-packages/osbuild/shell.py",
line 35, in start
with open(bashrc_path, "w") as f:
IOError: [Errno 2] No such file or directory:
'/home/dsd/projects/sugar-build/build/out/install/etc/bashrc'
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] debugging weird Activity startup errors
On Tue, Aug 27, 2013 at 5:43 PM, Peter Robinson wrote:
> Hi All,
>
> I'm testing locally a scratch build of Abiword 3 with the intent of having
> it in Fedora for F-20 and hence SoaSv10 but I'm getting a near useless error
> in the Activity log of:
>
> Terminated by signal 11, pid 1142 data (None, ', mode
> 'w' at 0x251bd20>, dbus.ByteArray('ef47d2e4dc6551ba96f6ceded9023243ea4ee519'
> , variant_level=1))
Signal 11 is a segmentation fault, i.e. a hard crash.
Run it in gdb with:
sugar-launch -d org.laptop.AbiWordActivity
(not sure if I have the activity ID correct there)
When it crashes soon after, run "bt" at gdb prompt.
The output will give us some idea of what is going wrong.
Daniel
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] clipboard error with actual sugar
On Fri, Jul 19, 2013 at 9:59 AM, Gonzalo Odiard wrote: > The sugar ticket is http://bugs.sugarlabs.org/ticket/4483 > > Have links to: > https://bugzilla.gnome.org/show_bug.cgi?id=692844 > and > https://bugzilla.gnome.org/show_bug.cgi?id=656312 > > In the first one, requested include the patch in the 3.6 branch too, > but didn't received a reply. > Should we ask again, or we will use our patched rpm? > What about SoaS users? I would ask again, reminding them of the importance of this bugfix for Sugar. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-terminal] Use json instead of simplejson
On Fri, Jul 19, 2013 at 5:39 AM, Gonzalo Odiard wrote: > Probably my mistake. > Tell me if you need a new release. That would be useful, thanks. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-terminal] Use json instead of simplejson
On Wed, Jul 17, 2013 at 3:00 PM, Daniel Drake wrote: > Hi, > > On Sat, May 18, 2013 at 5:41 PM, Daniel Francis wrote: >> This code isn't used at the moment due some regressions with the Vte dynamic >> bindings. I know it breaks the buildbot, so I applied it as >> 74097db3becc980b68b29b2c51a740934e85adc5 > > Any chance of this being applied in a new release on activities.sugarlabs.org? Strange, according to git it is included in v42, but the v42 downloaded from activities.sugarlabs.org definitely uses simplejson. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH sugar-terminal] Use json instead of simplejson
Hi, On Sat, May 18, 2013 at 5:41 PM, Daniel Francis wrote: > This code isn't used at the moment due some regressions with the Vte dynamic > bindings. I know it breaks the buildbot, so I applied it as > 74097db3becc980b68b29b2c51a740934e85adc5 Any chance of this being applied in a new release 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] clipboard error with actual sugar
On Mon, Jul 15, 2013 at 1:18 PM, Gonzalo Odiard wrote: > Can anybody confirm this? > > In sugar-build (F18), when I want copy a object from the journal to the > clipboard, > using the copy menu in the object palette, nothing is copied in the > clipboard, > and i get the following error in shell.log: On the XO we ship our own pygobject3 version with some patches. The patches are upstream but from later versions/branches. I seem to remember that the most recent patches we added were for clipboard stuff. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [sugar-build] Landing the chroot branch
On Wed, Jul 10, 2013 at 6:10 AM, Daniel Narvaez wrote: > I'm planning to merge the chroot branch on master. Though, since it's a > major change, I'm trying to avoid disruption as much as possible. > > As a first step, I'm switch the build infrastructure to use that branch. > > I encourage people to switch to the branch too when they have a chance > (perhaps without throwing away the master build until they have a working > chroot build) and to report any issue they run into. Just personal preference, but I would prefer to keep working in a non-chrooted environment. One less layer, one less thing to go wrong or offer some kind of irritation. Of course it is up to you if you want to support that, but I think it has value as it is much closer to the environment that Sugar will be deployed in. I would have no problem with you picking a lone distro/version where this works, perhaps matching what is run as a chroot on the other distros, i.e. in this case you could say "OK, no chroot, but only if you're running F19" Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Sugar fails to launch in rawhide, missing gwebsockets
Hi, Sugar-0.99.0 fails to launch in rawhide. jarabe.main imports apisocket which imports gwebsockets. gwebsockets is a new library developed by us (right?) What are the plans for tarballs, packaging, etc for gwebsockets? Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC] Content support
On Tue, Jul 2, 2013 at 8:44 PM, Manuel Quiñones wrote: > I see. So I agree with you Gonzalo, let's not complicate it. Daniel > patch is good enough. Yes, I like the simplicity as well. I updated my old feature page with the new version to do this 'officially': http://wiki.sugarlabs.org/go/Features/Content_support I know we're past feature freeze, but maybe this can be considered. As the code is already written, I posted it in pull requests. Might help when considering it. https://github.com/sugarlabs/sugar/pull/50 https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/19 Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Bug in Sugar-Emulator
On Wed, Jul 3, 2013 at 3:58 PM, Ignacio Rodríguez wrote: > Trying to run an activity (Jukebox) in GTK3... > (Os: Ubuntu 13.04 Raring, 32bits) You need to update your sugar-toolkit-gtk3 for compatibility with the new pygobject3 version you are running. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [RFC] Content support
On Sun, Jun 30, 2013 at 7:34 PM, Chris Leonard wrote: > One of the things that would be needed to fully support content bundles > (which I have experimented with creating), would to be able to host them in > ASLO, it would also be important to clarify the process of deleting a > content bundle, which used to require a manual editting of some file to make > it go away from the OLPC Library section in Browse. The ASLO maintainers were resistent to the idea of content bundle support in the past. In practice this does not seem to be a problem for the field though. Deletion of content bundles is also solved by this patch - previously that was a strange process, now you just remove them like activities. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RFC] Content support
Hi, Content bundles have long been both a crucial part of the OLPC-Sugar offering, and a pain through having some deficiencies. http://wiki.laptop.org/go/Creating_a_collection They are important because it is the only easy way for a deployment to add pre-made content to Sugar (e.g. books). The strong point of the design here is that beyond a not-too-strange library.info metadata file, you do not have to interact with anything too technical (e.g. python) beyond the HTML content itself. It is something that seems to fall within capabilities of deployment teams without much difficulty, whereas activity development is often a painful step up. They are quite widely used and in my experience visiting deployments "how do we add our content to the laptop" is a very frequent question - I always ran training sessions on content bundles in response. However they are a pain because Sugar never really supported them very well. Sugar can launch them from the Journal, but shipped content that the user has never opened before does not exist in the Journal, so there was something missing here. To fill the gap, OLPC added a system (olpc-library) to produce a HTML index of content bundles and this is the Browse homepage, but that isn't great either - it's not part of Sugar where it should be, and users have to open the web browser as if they are going online when they are just looking to open some preinstalled content. With my recent work on automatic activity updates, we had to add content bundles to the bundle registry so that they will be updated appropriately. Now that this is done, it is very easy to remove this deficiency. The small patch below makes content bundles appear alongside activities, in the list and favourites views. They are launched as expected with a click. It does need some uninteresting tweaks in the bundle classes in sugar-toolkit-gtk3 as well, but the real bulk of the change is here. Any thoughts/comments? --- src/jarabe/desktop/activitieslist.py | 3 --- src/jarabe/desktop/favoritesview.py | 7 --- src/jarabe/journal/misc.py | 25 - src/jarabe/model/bundleregistry.py | 2 -- 4 files changed, 12 insertions(+), 25 deletions(-) diff --git a/src/jarabe/desktop/activitieslist.py b/src/jarabe/desktop/activitieslist.py index 02e5f01..e369dd4 100644 --- a/src/jarabe/desktop/activitieslist.py +++ b/src/jarabe/desktop/activitieslist.py @@ -32,7 +32,6 @@ from sugar3.graphics.icon import Icon, CellRendererIcon from sugar3.graphics.xocolor import XoColor from sugar3.graphics.alert import Alert from sugar3.graphics.palettemenu import PaletteMenuItem -from sugar3.bundle.activitybundle import ActivityBundle from jarabe.model import bundleregistry from jarabe.view.palettes import ActivityPalette @@ -227,8 +226,6 @@ class ListModel(Gtk.TreeModelSort): return def _add_activity(self, activity_info): -if not isinstance(activity_info, ActivityBundle): -return if activity_info.get_bundle_id() == 'org.laptop.JournalActivity': return diff --git a/src/jarabe/desktop/favoritesview.py b/src/jarabe/desktop/favoritesview.py index dbdcf87..5f3bc65 100644 --- a/src/jarabe/desktop/favoritesview.py +++ b/src/jarabe/desktop/favoritesview.py @@ -35,7 +35,6 @@ from sugar3.graphics.xocolor import XoColor from sugar3.activity import activityfactory from sugar3 import dispatch from sugar3.datastore import datastore -from sugar3.bundle.activitybundle import ActivityBundle from jarabe.view.palettes import JournalPalette from jarabe.view.palettes import CurrentActivityPalette @@ -158,8 +157,6 @@ class FavoritesView(ViewContainer): self.set_layout(self._layout) registry = bundleregistry.get_registry() for info in registry: -if not isinstance(info, ActivityBundle): -continue if registry.is_bundle_favorite(info.get_bundle_id(), info.get_activity_version()): self._add_activity(info) @@ -292,8 +289,6 @@ class FavoritesView(ViewContainer): registry = bundleregistry.get_registry() for info in registry: -if not isinstance(info, ActivityBundle): -continue if registry.is_bundle_favorite(info.get_bundle_id(), info.get_activity_version()): self._add_activity(info) @@ -312,8 +307,6 @@ class FavoritesView(ViewContainer): icon.show() def __activity_added_cb(self, activity_registry, activity_info): -if not isinstance(activity_info, ActivityBundle): -return registry = bundleregistry.get_registry() if registry.is_bundle_favorite(activity_info.get_bundle_id(), activity_info.get_activity_version()): diff --git a/src/jarabe/journal/misc.py b/src/jarabe/journa
Re: [Sugar-devel] Bundle builder changes broke gtk2 activities
On Sat, Jun 29, 2013 at 4:30 AM, Daniel Narvaez wrote: > see this bug for a log > > http://bugs.sugarlabs.org/ticket/4527 > > sugar-activity imports sugar3 stuff, so far that didn't cause gi to be > imported I think, but with Daniel changes that's now the case. I didn't change bundlebuilder and I can't immediately think what would have broken this. The log doesn't say much, as far as I can see. Have you investigated further? Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unstable releases
On Wed, Jun 26, 2013 at 5:47 PM, Daniel Narvaez wrote: > If people are fine with that, I will try to make the 0.99.0 release myself, > automating things a little, with the goal of reducing at a minimum the work > involved. I'm not going to be able to write per module release notes and > such, but I guess having the tarballs is better than nothing. Yes, no need for release notes. There is already a release script somewhere that makes the rest almost effortless - ask Manuel. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unstable releases
On Wed, Jun 26, 2013 at 11:06 AM, Daniel Narvaez wrote: > Thanks. I would appreciate pointers about SoaS development builds. How > frequently they are built, what they are based on (F19/F20) etc. I believe they are built automatically, on an almost-nightly basis, for the current development version of Fedora. That is F19 right now but will soon be F20. http://alt.fedoraproject.org/pub/alt/nightly-composes/ > Is OLPC going to do build this cycle? We have not yet reached planning stages for the next release, but it is likely that someone will produce a couple of F20 developer-only images or something, to see where things are at. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Unstable releases
On Wed, Jun 26, 2013 at 10:55 AM, Daniel Narvaez wrote: > we was supposed to release 0.99.0 today but we have not tarballs to ship > because the maintainers have been to busy to deal with that. > > I already brought this up when we came up with the 0.100 roadmap but let me > try again. Assuming we find resources to release, who is going to test that > code? I suspect no one is going to, which makes releasing a waste of > precious maintainers time. There might not be a lot of testing, but some does happen. Here is one example: these unstable tarballs will be built in Fedora (thanks Peter) and then included in SoaS development builds, which are frequently tested by satellit. In the past such releases have also been shipped in OLPC development builds. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Automatic activity updates
On Sat, Jun 15, 2013 at 6:42 PM, Daniel Narvaez wrote: > Cool. I'd say it's in then... Added a feature page > > https://github.com/sugarlabs/roadmap/issues/9 Thanks for being open to this. The implementation is ready for review. https://github.com/sugarlabs/sugar-toolkit-gtk3/pull/11 https://github.com/sugarlabs/sugar/pull/40 Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Automatic activity updates
On Wed, Jun 12, 2013 at 2:10 PM, Daniel Narvaez wrote: > Hi, > > we are going to code freeze on Sep 4, and that's when it would also probably > make sense to branch master. Which is a bit later than you would like to > land it. > Though I wonder if we should consider this feature for 0.100 since > > * There is still a considerable amount of time left. Freeze dates seems to > be compatible with your goals. > * Part of the work seems to be cleaning up the existing mess. > * A few of the features we planned for 0.100 seems a bit stalled (3g modems, > multiple journal selection, multiple home views). > * The web activities work, which is where most of the changes are going, is > not affecting much the existing code. Glad to hear that you are interested. I had mentioned August previously in order to not be too demanding! I expect to submit quite a bit sooner and if speedy feedback is possible then this could hopefully be closed quickly. If the maintainers are happy to merge it into 0.100 I have no objections of course. Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] Automatic activity updates
Hi, Over the last few months I have been slowly developing a much needed field feature, the final piece in the "automatic system upgrade" puzzle. Now I am getting close, I would like to open the formalities... http://wiki.sugarlabs.org/go/Features/Automatic_activity_updates At this point I've iterated the design once or twice and implemented most of this locally. I will hopefully publish the full patch series in the next couple of weeks. I understand this is too late for 0.100. What I would hope for is a review and (after feedback) merge into a master branch before the end of August. Then I will run a live field test and send in any necessary refinements. This would then likely be deployed large scale in Nicaragua at the end of the year or the start of the next. Comments welcome. Thanks Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Install Firefox
On Wed, May 29, 2013 at 11:50 PM, Peter Robinson wrote: > Firefox and xulrunner 17 are the late known good (and matching) builds > for Fedora 17, you need the major versions to be matching (so > 12/13/17) but if you were pulling in all the latest stable updates > into the build you would have matching ones AFAICT from koji so > there's some other issue. Ah yes, you are right, the latest available versions on koji are matching (v17) and built OK. I didn't spot them in the mass of failed builds. So the Fedora situation is OK. > I'm not sure what the following lines translate to but you should > never use the koji repositories as repos as they contain all sorts of > randomly tagged bits that the release repos don't. > > olpc_frozen_1=0,koji.dist-f17-armv7hl > olpc_frozen_2=0,koji.dist-f17-armv7hl-updates-12.1.0 Don't worry, these are not the koji repos you are thinking of. They are OLPC's frozen versions of fedora repos from the release's freeze date and are not directly from koji - really we should change the naming scheme. And this is the cause of the problem - upon release freeze date, the firefox/xulrunner situation was in inconsistent state; this problem has been frozen in our repos. Basanta, I would advise against adding the official fedora-updates repo into your build as has been suggested in this thread - while this will result in a well matched firefox/xulrunner combination, it will bring in a lot of untested package updates that were not part of the release and have probably not been tested on OLPC XO. Instead, create a local repo with these 2 packages and add it to your build config: http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=109570 http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=116355 Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to deploy the webactivity libraries
Thanks for starting this thread - it is something that needs to be carefully discussed and considered. Just one comment to add for now: On Wed, May 29, 2013 at 4:29 AM, Simon Schampijer wrote: > ===Include a copy of the library in each webactivity=== > Each activity carries a copy of the libraries it uses. For example > sugar-html-activity and sugar-html-graphics. This has the advantage that the > activities are self contained. The downside is that for a change in the > library each activity has to be updated. I would imagine that that making the assumption that we can have "self contained" activities is dangerous. By this, I infer that we envision the possibility (perhaps in addition to other possibilities) that an activity can be bundled up and run on any version of HTML-enabled Sugar, older or newer than the one it was developed against. While it may work in some cases, I am not convinced that this is truly achievable. While the web browser environment works as a self-contained virtual machine for many, many things, once we get adventurous I think it is inevitable that activities will start depending on specific, new features of the underlying web browser, and/or specific features/API implemented by the underlying Sugar shell, and/or specific features/API of the underlying operating system. For example, I'll invent a situation that I am not sure is true or not, but would reflect something that seems perfectly realistic and could bite in a number of cases: Our initial stable "Sugar HTML" release doesn't support webcam use, because there is no API or anything that activities can use to access the webcam. A couple of releases later, time has passed and HTML5 expands to include a brand new tag, which activities start to use as it becomes supported in the brand new webkit version that appears in Fedora. An activity starts to use this. It bundles all the stuff it can, but it is *not* truly self contained. It will not work on older platform releases because it relies on a specific new feature in the web engine - and the web engine is part of the system, it is not something bundled in the activity. An alternative situation: instead of such funtionality being added to HTML5, we add functionality to the underlying Sugar shell which somehow provides some access to V4L2 devices (i.e. webcams) from javascript, for use by activities. Activities can start using that and bundle loads of stuff, but they will not be truly self contained because at some point they will have a dependency on something system-specific which will not work on older releases of the platform. In other words, I imagine that for activities that meet a certain level of complexity/functionality, there will commonly be some point at which they cross the line and start depending something specific in the underlying system, which breaks any dreams of self contained activities. If I'm right, maybe we should consider dropping that as a realistic possibility for a reliable experience. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Install Firefox
On Tue, May 28, 2013 at 9:40 PM, Basanta Shrestha wrote: > Adding firefox did install firefox but gave following error while trying to > execute on XO: > > $ firefox > Error: Platform version '13.0' is not compatible with > minVersion >= 12.0 > maxVersion <= 12.0 > - Looks like an incompatibility with xulrunner, which hasn't been successfully built on F17 in a while: http://arm.koji.fedoraproject.org/koji/packageinfo?packageID=10131 Maybe Peter has some comments. You could try an older version of firefox to match the latest (old) version of xulrunner available. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [PATCH Portfolio] Fix position and duration query
The API changed slightly in gstreamer-1.0. This fixes audio recording. --- grecord.py | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) Now that we are on gstreamer-1.0 it may be worth revisiting if the "EOS stopped advancing" workaround is needed. I'm suspicious of that code and in this case it was the item that was being confused by the API change. diff --git a/grecord.py b/grecord.py index 92a4a75..05ccacb 100644 --- a/grecord.py +++ b/grecord.py @@ -212,14 +212,12 @@ filesink name=audioFilesink' return True def _query_position(self, pipe): -try: -position, format = pipe.query_position(Gst.Format.TIME) -except: +result, position = pipe.query_position(Gst.Format.TIME) +if not result: position = Gst.CLOCK_TIME_NONE -try: -duration, format = pipe.query_duration(Gst.Format.TIME) -except: +result, duration = pipe.query_duration(Gst.Format.TIME) +if not result: duration = Gst.CLOCK_TIME_NONE return (position, duration) -- 1.8.1.4 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Install Firefox
On Wed, May 22, 2013 at 10:36 PM, Basanta Shrestha wrote: > Hi there, > I use fedora ARM to build OS for XO1.75. I have recently successfully built > OS12.1.0 using olpc-os-12.1.0-xo1.75.ini. Now I am in need of preparing a > build with firefox and flashplugin. Is it possible? If yes, what addition do > I need to make on which files? Please suggest. You can use the olpc-os-builder custom_pkgs module to add firefox, and the adobe_flash module to add the flash player plugin for ARM which you presumably already have stored separately. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] About web activities, webkit2 and backward compatibility
On Tue, May 21, 2013 at 2:02 PM, Gonzalo Odiard wrote: > >> webkitgtk3 > > > I think that is webkit, no webkit2 How are you coming to that conclusion? I just checked the spec file, webkit2 compilation is enabled, and the lib appears installed as /usr/lib/libwebkit2gtk-3.0.so.18.0.5 It is not as new as the version in F19 of course, but as far as I know nobody has investigated as to whether that really matters. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] About web activities, webkit2 and backward compatibility
On Tue, May 21, 2013 at 1:44 PM, Gonzalo Odiard wrote: > >> webkit2 is included in F18 and is in OLPC builds. Has anyone checked >> if it is good enough to run the latest webapp stuff? There may be no >> need to go back to webkit1 if you want to continue on this path. >> > > I can'see webkit2 installed in 13.2.0, what is the package? webkitgtk3 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] About web activities, webkit2 and backward compatibility
On Tue, May 21, 2013 at 12:31 PM, Gonzalo Odiard wrote: > Question for the sugar-web-activities framework developers: > > * With the actual implementation, do we _really_ need webkit2? > > You can say, why? We already decided that! > > I know, but thinking in the following months: > > * If we continue going with webkit2, the only way to develop web activities, > will be sugar-build. No real users can use that activities in a xo with > sugar for at least 6 months more. webkit2 is included in F18 and is in OLPC builds. Has anyone checked if it is good enough to run the latest webapp stuff? There may be no need to go back to webkit1 if you want to continue on this path. 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] 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] 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
[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] [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
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
[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
[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] 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
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
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] 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 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] 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] 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] [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] 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
[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
[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
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
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] [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 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] 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] 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] 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 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
[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] [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
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] [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] 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] 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] 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] [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] 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
[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] [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
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] [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] [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] 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.
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
[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
[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
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
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] [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 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 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 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
[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
[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] 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
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] [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
[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] 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
