Re: [Sugar-devel] Experimental work... updated.
On Tue, Apr 27, 2010 at 10:46:05PM -0400, Michael Stone wrote: I particularly like that I can test sugar*-0.88 directly on my XO by running something comparable to yum install git-core gcc glibc-devel make vim git clone git://dev.laptop.org/users/mstone/sugar; cd sugar make xo-builddeps env PREFIX=/usr ./configure make; make install All these steps worked on XO-1.5 os121, but the next step escapes me. At the moment, olpc-session starts, Sugar starts with the nickname prompt, but doesn't proceed beyond colour choice dialog. Looking at logs, presence service isn't sticking around once it is launched by D-Bus. I couldn't find any logs of the failure. Looking at an strace of a startx with .xinitrc containing olpc-session, the presence service isn't passing import decorator, so I'll look into that. Maybe it needs another package. Oh, and the colour choice XO icon wasn't there. Just the click to change message, back and forward buttons. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [SoaS] What application in f13 liveinst (Anaconda) takes the live, compressed, file system and converts it to a normal file system during a HD install?
On Tue, Apr 27, 2010 at 9:51 PM, Thomas C Gilliard satel...@bendbroadband.com wrote: I am curious: What application in the f13 liveinst Anaconda (Install to HD link on the live desktop of gnome) takes the live file system and converts it to a normal file system on HD install after the files are transferred to the HD during installation Can we use this to take the soas live file system and do a conversion to a real HD install? With in the sqashfs file system is a plain ext4 (I think) filesystem. I'm not sure whether they just write this out to disk and then extend it or whether they do some form of tar backup/restore to move things over. You'd have to look at the code. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] Remove the keep button from the default activity toolbar
On Fri, Apr 23, 2010 at 23:21, Walter Bender walter.ben...@gmail.com wrote: On Fri, Apr 23, 2010 at 2:52 PM, Daniel Drake d...@laptop.org wrote: On 23 April 2010 15:02, Sascha Silbe sascha-ml-ui-sugar-de...@silbe.org wrote: I like the proposal of renaming Keep to Copy and placing it in the palette of the Stop button. I was a bit worried about it getting confused with the clipboard action of the same name, but making it a secondary action of the Stop button should help with that. This sounds odd. To make a copy of my work I have to go to the Stop menu? I've never seen Keep used in the field -- I've only seen misuse. Does anyone have any experience-backed counter opinions? Well, I added a keep button in Turtle Art to the default menu because kids would throw away their projects to start new ones and lose all of their work. (This was in part because the stop button was hard to find in pre-0.86 and it was easier to resume an old project than to start a new one, which only will change for 0.90). Ideally, we'd have versioning and could get rid of keep as a concept altogether... What happened to Sascha's versioning prototype? Nobody could find time to test it and give feedback? Regards, Tomeu I still think removing the button altogether will be a big improvement until the more advanced Journal solutions are actually implemented, even though technically you could say it would cause a functionality regression. If someone really does want to do a bit of hacking on this, put the Copy/Duplicate option in the Journal details view... To me, this seems to be the proper place to put copy/dup. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Experimental work... updated.
On Tue, Apr 27, 2010 at 10:46:05PM -0400, Michael Stone wrote: I particularly like that I can test sugar*-0.88 directly on my XO by running something comparable to yum install git-core gcc glibc-devel make vim git clone git://dev.laptop.org/users/mstone/sugar; cd sugar make xo-builddeps env PREFIX=/usr ./configure make; make install All these steps worked on XO-1.5 os121. Good. but the next step escapes me. I was testing on os201; I haven't updated the XO yet. This may be the cause of the difference. At the moment, olpc-session starts, Sugar starts with the nickname prompt, but doesn't proceed beyond colour choice dialog. The color choice dialog doesn't load very much of the sugar codebase. The doesn't proceed beyond behavior strongly suggests that an exception is being thrown. Looking at logs, presence service isn't sticking around once it is launched by D-Bus. I couldn't find any logs of the failure. You couldn't find logs of the failure because olpc-dm is redirecting stdout and stderr to /dev/null. Fortunately, olpc-utils rebuilds easily on the XO as soon as its builddep, ConsoleKit-devel, is installed. (Just run make -f Makefile.build; make -f Makefile.build install.) Then you can redirect the stdout/stderr output to the log file of your choice or, as I do, you can run /etc/X11/prefdm manually. (To enable this, I usually tell /etc/event.d/prefdm to run /bin/true and to not restart, thereby dropping me off at the virtual terminals on each reboot.) Also, alternately, you can install Xephyr and use it from Gnome or raw X+metacity to find out what's going on. Looking at an strace of a startx with .xinitrc containing olpc-session, the presence service isn't passing import decorator, so I'll look into that. Maybe it needs another package. Entirely possible. Oh, and the colour choice XO icon wasn't there. Just the click to change message, back and forward buttons. Thanks for the report; I'll see if I can produce the same behavior. Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] _update_signal_match wasn't initialized
On Wed, 2010-04-28 at 09:56 +1000, James Cameron wrote: On Tue, Apr 27, 2010 at 09:43:21AM -0400, Raul Gutierrez Segales wrote: Looking at it with more detail, the problem is that self._update_signal_match is initialized in the wrong order (after a call to set_object_id that depends on it). No worries, now I understand, and approve. Reviewed-by: James Cameron qu...@laptop.org Great, what is the next step for inclusion? (I have no commit access to sugar-toolkit). Raúl ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.90 and migration from GConf to GSettings?
On Mon, Apr 26, 2010 at 11:53, Peter Robinson pbrobin...@gmail.com wrote: Hi All, Is there yet any plans for migrations from GConf to GSettings in the 0.90 development of Sugar? I'm not sure if there's even any requirements but I've noticed in maintaining of the packages there's a dep on it. Do we get this free when pygtk migrates or is this something we need to do. I'm just asking from the perspective that there will be a mass migration over the next 6 months for gnome 3 and it will help get rid of a number of old dependency chains. It would be nice to start using the new API, but I'm not sure how we would make regarding the backend. Would be possible to let downstreams deal with choosing the backend they prefer? We need to think about migration as well. Regards, Tomeu Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard navigability of the Sugar UI
On Tue, Apr 27, 2010 at 16:25, Bernie Innocenti ber...@codewiz.org wrote: Today I filed a bug to keep track of an issue that has been bothering me for a long time: There's interest from the people at La Rioja on this, how can we agree on a plan together and resource it? http://lists.laptop.org/pipermail/olpc-sur/2010-April/005849.html Regards, Tomeu http://bugs.sugarlabs.org/ticket/1969 Being an important UI issue, we'd need a good discussion with the design team. Unfortunately, we cannot always follow existing Gnome conventions for keyboard shortcuts. For example, rename cannot be done with F2 because it's already used for the buddy view. -8--8--8--8--8- The Sugar UI should be 100% navigable without using a mouse. Besides being an accessibility issue, it's important for quick navigation, especially for users stuck with a broken XO touchpads. Some proposed changes: * Favorites view * Search should be enabled in the shell view * A caret should appear when the user starts to type * Non-matching activities should be grayed out * TAB should cycle through possible completions * Cursor keys should cycle through the icons * Journal * Cursor up/down should scroll a caret on the list * ENTER should open the selected item (Linux/Windows style) * Rename item: TBD (just type something?) * Go to proprieties: TBD (cursor right?) * Change volume: TBD * Unmount all hot pluggable devices: TBD * Activities list view * Should behave like the journal * Network Neighborhood * Similar to favorites view * Toolbars * There should be a key to move the focus to the toolbars (alt-space?) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Sugar 0.90 and migration from GConf to GSettings?
On Wed, Apr 28, 2010 at 4:06 PM, Tomeu Vizoso to...@tomeuvizoso.net wrote: On Mon, Apr 26, 2010 at 11:53, Peter Robinson pbrobin...@gmail.com wrote: Hi All, Is there yet any plans for migrations from GConf to GSettings in the 0.90 development of Sugar? I'm not sure if there's even any requirements but I've noticed in maintaining of the packages there's a dep on it. Do we get this free when pygtk migrates or is this something we need to do. I'm just asking from the perspective that there will be a mass migration over the next 6 months for gnome 3 and it will help get rid of a number of old dependency chains. It would be nice to start using the new API, but I'm not sure how we would make regarding the backend. Would be possible to let downstreams deal with choosing the backend they prefer? We need to think about migration as well. I would think you would let the distribution choose the backend and that way you use what ever is supported on that platform. Then things like gnome/gstreamer/telepathy settings are shared between the various interfaces on that plaform which is useful for dual interface devices such as the XO-1.5 which can switch between gnome/sugar. For migration I presume we would be able to use the same strategy that gnome uses. Peter ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard navigability of the Sugar UI
Hi Bernie The proposed keyboard shortcuts sound good. Maybe we can chat about the TBD items? Christian Sent from my iPhone On Apr 27, 2010, at 7:25 AM, Bernie Innocenti ber...@codewiz.org wrote: Today I filed a bug to keep track of an issue that has been bothering me for a long time: http://bugs.sugarlabs.org/ticket/1969 Being an important UI issue, we'd need a good discussion with the design team. Unfortunately, we cannot always follow existing Gnome conventions for keyboard shortcuts. For example, rename cannot be done with F2 because it's already used for the buddy view. -8--8--8--8--8- The Sugar UI should be 100% navigable without using a mouse. Besides being an accessibility issue, it's important for quick navigation, especially for users stuck with a broken XO touchpads. Some proposed changes: * Favorites view * Search should be enabled in the shell view * A caret should appear when the user starts to type * Non-matching activities should be grayed out * TAB should cycle through possible completions * Cursor keys should cycle through the icons * Journal * Cursor up/down should scroll a caret on the list * ENTER should open the selected item (Linux/Windows style) * Rename item: TBD (just type something?) * Go to proprieties: TBD (cursor right?) * Change volume: TBD * Unmount all hot pluggable devices: TBD * Activities list view * Should behave like the journal * Network Neighborhood * Similar to favorites view * Toolbars * There should be a key to move the focus to the toolbars (alt-space?) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Experimental work... updated.
On 28 April 2010 11:57, Michael Stone mich...@laptop.org wrote: You couldn't find logs of the failure because olpc-dm is redirecting stdout and stderr to /dev/null. I don't think this is true. Fortunately, olpc-utils rebuilds easily on the XO as soon as its builddep, ConsoleKit-devel, is installed. (Just run make -f Makefile.build; make -f Makefile.build install.) Then you can redirect the stdout/stderr output to the log file of your choice but if I'm wrong, maybe we can improve this. Can you be more specific about the changes you're making before the rebuild? Thanks, Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Code Review process changes
Hi! Bernie, Tomeu and I had a nice discussion regarding the Code Review process on #sugar yesterday. To sum it up: Several contributors are hindered or even put off by the current process. It often takes more time to handle mere technicalities (save patch to file, create ticket in Trac, attach patch, wait for review, push) than it takes to fix the bug. We talked before of using XML-RPC to automate it, what happened to that? I'm using this for GNOME and Freedesktop projects and works very well: http://git.fishsoup.net/man/git-bz.html I also heard about a trac-email gateway, any news? In addition there's a large backlog because reviews are currently handled only by module maintainers. The latter issue turned out to be at least partly due to misunderstandings about who can do reviews. If we have such a thing as module peers is solely for helping out with reviews: http://wiki.sugarlabs.org/go/Development_Team/Release/Modules But we also should have more than one maintainer per module. We'd like to try a different approach that's used by many successful projects - both small and large ones. Patches are sent to sugar-devel for review. Every Sugar developer (*) can review patches (and multiple reviews are quite welcome). Since the number of developers with commit access is limited, we have a sufficient level of QA even without limiting who can do reviews. This seems to imply that the sole purpose of reviews is QA, but I think it has two more important purposes: transferring the burden of maintenance and sharing best practices and conventions. In practical terms, to me this means that reviews need to come from those who can appreciate the actual impact on maintenance of a patch, and that also have a direct interest in keeping the maintenance burden low. There are a number of systems to track the status of patches sent to the list (e.g. Patchwork [1]), but as this adds complexity (and yet another system to maintain) again we'd like to try without at first. I'm confused, how are these systems better than the patch review report we used to have? For those who weren't with us back then: http://lists.sugarlabs.org/archive/sugar-devel/2008-July/006903.html Personal note: Instead of using a patch tracker, we could also ask patch submitters to file tickets at bugs.sugarlabs.org if there has been no review for, say, 3 days. This gives a streamlined process for most patches while still ensuring nothing gets lost. So we need to look for patches in two places? Regards, Tomeu (*) We defined Sugar developer as anybody who has made at least one change that entered mainline. [1] http://patchwork.ozlabs.org/ CU Sascha ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] _update_signal_match wasn't initialized
On Wed, Apr 28, 2010 at 10:57:24AM -0400, Raul Gutierrez Segales wrote: Great, what is the next step for inclusion? (I have no commit access to sugar-toolkit). Please provide the updated patch (i.e. including Reviewed-By/Tested-By/... lines) as a separate MIME part (I don't care whether it's marked inline or attachment, but it needs to be a separate MIME part so it doesn't get munged by the MUA). Also I'll need to know which branches it should be applied to. Ideally, you'd also have an Ack-By from the maintainer of sugar-toolkit (IIRC that's Simon). CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Keyboard navigability of the Sugar UI
El Wed, 28-04-2010 a las 08:48 -0700, Christian Marc Schmidt escribió: The proposed keyboard shortcuts sound good. Maybe we can chat about the TBD items? Sure, ping me any time on #sugar. I'm in GMT+4 currently, same TZ as Boston. Or would you rather have a full-blown Design Team meeting? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] _update_signal_match wasn't initialized
El Wed, 28-04-2010 a las 19:33 +0200, Sascha Silbe escribió: Please provide the updated patch (i.e. including Reviewed-By/Tested-By/... lines) as a separate MIME part (I don't care whether it's marked inline or attachment, but it needs to be a separate MIME part so it doesn't get munged by the MUA). Also I'll need to know which branches it should be applied to. I've never had problems saving inline patches from either Evolution or Thunderbird and then applying them with git am. Mutt of course also works great. This is the regulard workflow to exchange patches by email: Alice: git format-patch -1 Alice: git send-email --to bob foo.patch Bob: (saves raw email body in MUA) Bob: git am foop.patch Ideally, you'd also have an Ack-By from the maintainer of sugar-toolkit (IIRC that's Simon). Hmm... sugar-toolkit is missing a MAINTAINERS file. It would be good to add it, or document the current maintainer mappings somewhere (gitorious, wiki...) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Experimental work... updated.
Thanks, Michael, this has been the first viable method for getting Sugar 0.88 working on an XO-1.5 ... I'd been needing that for some time; to check new bugs we find in 0.84 against 0.88, and to develop changes against 0.88 after I've done them on 0.84. The missing package was python-decorator. It's not in the build dependencies in the Makefile. See attached patch. The next stop was more interesting ... assuming that I would no longer need any of the existing Sugar packages, I had removed them prior to make install, using this command: rpm -e \ sugar-datastore-0.84.1-1.fc11.i586 \ sugar-toolkit-0.84.9-2.fc11.i586 \ sugar-artwork-0.84.1-3.fc11.i586 \ sugar-presence-service-0.84.0-2.fc11.noarch \ sugar-0.84.15-1.fc11.i586 \ sugar-base-0.84.1-1.fc11.i586 \ sugar-update-control-0.23-1.fc11.noarch \ olpc-library-2.0.3-1.fc11.noarch \ ds-backup-client-0.11.1.g71d2f16-1.olpc3.noarch \ olpc-switch-desktop-0.7-1.fc11.noarch The result was failure to render the home window; because the computer-xo icon could not be found. Log from /tmp/olpc-dm-client.log placed here: http://dev.laptop.org/~quozl/2010-04-29-olpc-dm-client.log I'm not sure why this has happened, but my guess is that there is a file used that isn't installed by make install, but left over from the RPMs. When I reinstalled the removed RPMs, it all began to work again. -- James Cameron http://quozl.linux.org.au/ From c770ffd7112b788a90fe35aad3ca227f6db99914 Mon Sep 17 00:00:00 2001 From: James Cameron qu...@laptop.org Date: Thu, 29 Apr 2010 14:42:19 +1000 Subject: [PATCH] add missing dependency on python-decorator --- Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index 576a8a8..581f1dc 100644 --- a/Makefile +++ b/Makefile @@ -268,7 +268,7 @@ DEBIAN_TOOLKIT_BUILDDEPS = libsm-dev libice-dev libasound2-dev libxml-parser-per debian-builddeps: aptitude install $(DEBIAN_MAIN_BUILDDEPS) $(DEBIAN_ARTWORK_BUILDDEPS) $(DEBIAN_BASE_BUILDDEPS) $(DEBIAN_PS_BUILDDEPS) $(DEBIAN_TOOLKIT_BUILDDEPS) -XO_MAIN_BUILDDEPS = pkgconfig perl-XML-Parser gettext python pygtk2-devel gtk2-devel GConf2-devel intltool libSM-devel alsa-lib-devel icon-slicer icon-naming-utils xorg-x11-apps pygtk2-codegen +XO_MAIN_BUILDDEPS = pkgconfig perl-XML-Parser gettext python pygtk2-devel gtk2-devel GConf2-devel intltool libSM-devel alsa-lib-devel icon-slicer icon-naming-utils xorg-x11-apps pygtk2-codegen python-decorator xo-builddeps: yum install $(XO_MAIN_BUILDDEPS) -- 1.7.0 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [PATCH] _update_signal_match wasn't initialized
On Thu, Apr 29, 2010 at 12:32:25AM -0400, Bernie Innocenti wrote: Hmm... sugar-toolkit is missing a MAINTAINERS file. +1 It would be good to add it, or document the current maintainer mappings somewhere (gitorious, wiki...) Only put it somewhere else if you don't want people to find it when they are looking at the source ... same can be said of dependencies ... I like what Michael Stone has done with the debian-builddeps and xo-builddeps targets. It makes the source more usable for developers, and therefore more accessible. -- James Cameron http://quozl.linux.org.au/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
