Re: [sugar] Google Summer of Code: sugarbot Screencast
On Sat, 2008-07-12 at 12:23 -0400, Zach Riggle wrote: > Hi Riccardo, thanks for the interest. > > > - Not yet. This is more of a limitation of the SimpleXMLRPCServer > implementation than that of sugarbot. Adding an argument to the rpc-functions should do it; what am I missing ? > - Not yet. I am looking at using either DBUS or encapsulating the > Sugar scripts to run inside a process I control. Please ping me when you arrive at the point of engineering this part; I'll do the same if that's ok for you. I'd like to write/have a tool like this anyway in the next weeks; so, it would be cool to do it together ! ;) > - No, but it would be quite trivial to implement. In fact, since the > scripting functionality is moving to native Python code, you could do > it in whatever manner you prefer. > > > Zach > > On Sat, Jul 12, 2008 at 4:14 AM, riccardo > <[EMAIL PROTECTED]> wrote: > > > > On Fri, 2008-07-11 at 18:14 -0500, Zach Riggle wrote: > > Thought some of you might be interested to see how sugarbot > is coming > > along. I've posted about it a few times in the mailing > list. It's > > Google Summer of Code mid-summer evaluation time, and I've > just posted > > a screencast that demo's some of sugarbot's features. > > > > Link: > > > http://gsoc-sugarbot.blogspot.com/2008/07/mid-summer-screencast.html > > > Hi Zach, > > Your work is very interesting ! > > I couldn't find a more detailed introduction/manual for > sugarbot; > is there any ? > > - Does sugarbot supports working over more activities at the > same time? > - Can it automate the shell itself ? > - Can it exec any arbitrary command (from a sb script), ie > without needing to write them on the terminal activity? > - If not yet, are these features planned ? > > Thanks, > riccardo > -- > Zach Riggle cheers, riccardo ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Feature/string freeze exception: uninstall activities from the shell
On Sun, Jul 13, 2008 at 1:14 AM, Eben Eliason <[EMAIL PROTECTED]> wrote: > Yeah, seems fine to me. Tomeu, I'd suggest to request the exception as soon as you have a patch for it. I'm favourable to this as long as the code is not too complex and we don't risk to introduce tricky issues. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] SugarLabs and OLPC
Hello, there has been a bit of confusion on how the OLPC and SugarLabs schedules relates, in particular regarding translation and string freeze. http://lists.laptop.org/pipermail/localization/2008-July/001139.html I'm trying to think more in general about how to shape up the upstream/downstream relation. My goals are: * Gradually turn Sugar into a real upstream project. It should be easy to distribute outside the OLPC context. And it should be easy for non-OLPC developers to participate. * Do not make the life of OLPC developers and testers harder. Make responsibilities clear and transparent. Keep duplication at minimum. Here are some concrete proposals. == Schedule == Sugar has his own roadmap and schedule: http://wiki.sugarlabs.org/go/ReleaseTeam/Roadmap We need to ensure that this schedule is compatible with OLPC needs. Given that OLPC committed to time based releases, I don't expect any issue on this front. We will need to know with some advance the target date of the OLPC release though, to do it properly. It didn't happen for 8.2.0, because the whole process is still being defined, but I expect it will happen in the future. == Localization == Localization of Glucose and Fructose should happen upstream, following the Sugar schedule. Ideally pootle would be hosted by SugarLabs, but even just creating separate groups on dev.laptop.org/translate would be a good start. There is the issue of how to handle activities which are not included in Fructose. My gut feeling is that we should: 1 Encourage as many activities as possible to follow the Sugar schedule (not necessarily by being included in Fructose). 2 Work upstream for the rest of the activities. We could create the following groups in pootle: * Glucose * Activities (following the Sugar schedule) I'm not sure it make sense to have a group for activities which doesn't follow the schedule. Perhaps we should offer pootle for these projects anyway to make their life easier, but without including them in any official group. We need to setup a Localization team on wiki.sugarlabs.org . I'm actually surprised we don't have one already. I will start a separate thread about that. == Source code == Source code repositories for Glucose and all the activities should be hosted at SugarLabs. We are going to provide something like http://trac-hacks.org/ , where each project has his own code repositories, trac instance, wiki etc. I'm not sure yet if Fructose activities should have each one their own project space, or if they should be part of a Fructose project, or if Glucose+Fructose should all be under a Sugar project. Anyway that will not impact OLPC much, it can be discussed separately. == Mailing lists == [EMAIL PROTECTED] should become [EMAIL PROTECTED] . OLPC specific issues should be discussed on [EMAIL PROTECTED] . == Trac == This is probably the most tricky one. I propose that tickets reported by OLPC clients and OLPC QA team (or issues which affect OLPC clients as gathered by Greg and the OLPC learning team) keep being tracked at dev.laptop.org for the time being. It's a little unusual compared to other distributions, where people are generally asked to report bugs upstream, but OLPC is currently the only real Sugar deployment and it would *very* impractical to introduce overhead to escalate tickets upstream. SugarLabs will have his own trac instance(s) to cover: * TODO like issues opened by developers. Ex: "Refactor the messy code in sugar.shell.something" * Issues which affects non-OLPC clients. Ex: "Sugar is broken on a 800x600 screen" * Issues which affects activities *not* supported by OLPC. (It's not yet clear which of them will be supported if any.) How does it sound? Can you think of important pieces of infrastructure/process which are *not* covered here? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Localization team
Any reason we don't have a localization team in the wiki? Any volunteer to set it up? Translations should really be handled upstream, so it's an area where SugarLabs have to be very active. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Reviews report
= New requests = Do not decorate the object chooser http://dev.laptop.org/ticket/7487 ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On Thu, Jul 10, 2008 at 8:39 AM, Erik Garrison <[EMAIL PROTECTED]> wrote: > Sugar devs: > > This is a copy of my bug report for #447. I have completed a first pass > of the grab key implementation. Have you considered implementing this at the X level? If so, why did you decide to go for a Sugar specific solution? I have no idea if/how that's possible but I see that the synaptic driver has a TwoFingerScrolling option and I've seen something similar for thinkpads a while ago. Eben, could you give it a try and comment on the user experience? Cheers, Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
Brilliant work, Erik! I had a chance to play with your first working hand scroll, and it's beyond explanation how fun it is to be able to scroll around using the touchpad without aiming for a gtkScrollBar. For all to consider: there are two grab buttons. What if one tended to grab + move *objects*, and the other grabs + moves *scenes/backgrounds*? From what I've heard, kids tend to have a hard time left-clicking and dragging with their same hand (as with the touchpad). So, for applications like Browse, both grab buttons could still just scroll up/down. But for graphical editors (e.g., layout programs, Physics, Model, anything with a scene and objects), this UI behavior may be a real time saver and fun to use. This would require giving applications the ability to process events from these two scroll buttons in a way that identifies them separately. Bravo, sir, Brian On Thu, Jul 10, 2008 at 2:39 AM, Erik Garrison <[EMAIL PROTECTED]> wrote: > Sugar devs: > > This is a copy of my bug report for #447. I have completed a first pass > of the grab key implementation. > > -Erik > > > Summary: > > I used the grab keys to convert the touchpad into a virtual > mouse scrollwheel. Holding down the grab key and moving the mouse a > small number pixels causes a fake mouse button 4/5/6/7 press, depending > on the direction of motion. This approach works in all applications > which support mouse scroll buttons. > > Patches: > > The attached patch to sugar-toolkit adds glib/C-side hooks to grab an > ungrab the mouse, and pass motion-notify events to the python side of > the Sugar shell. I have packaged this patch in an rpm which should be > installable on an XO running a recent joyride (tested on joyride-2123). > > (RPMS: tested but slightly older git snapshot: > http://dev.laptop.org/~erik/rpms/sugar-toolkit-debuginfo-0.81.5-4.20080705gitab8c054dfb.fc9.i386.rpm > or, untested but slightly newer git snapshot: > http://dev.laptop.org/~erik/rpms/sugar-toolkit-0.81.6-1.fc9.i386.rpm) > > The attached patch to sugar (specifically keyhandler.py) adds the > python-side hooks required to enable the grab/scroll button > functionality. > > The patches work in the following manner: > >When the left or right grab buttons are pressed, XGrabPointer is >called. Subsequently, we capture all of the motion-notify events >which occur when the user moves the mouse, and each event hits >KeyHandler._motion_notify_cb() with the coordinates of the mouse. >After we move N pixels (currently 10) we issue a fake mouse scroll >button press corresponding to the direction of motion of the mouse >(4/5/6/7). To issue the fake button press I have found it is >necessary to ungrab the mouse, issue the press, and then re-grab. > > Known issues: > >In some cases key-releases are not registered. This is problematic >because without the release signal the mouse grabbing does not >stop and Sugar becomes entirely unusable. I have not been able to >establish why, but have noticed that hitting the journal view key >after Sugar startup before any of the other special keys >(registered in keyhandler.py) tends to resolve the issue for the >Super_L and Super_R keys (the grab buttons). > >The mouse still scrolls around the screen, and the cursor is >visible during the grab. Solution: Hide the mouse; When a grab key >press is registered, hide the mouse by setting the cursor pixmap >to a blank map (and set it back when the grab key release is >registered). > >Eventually, after scrolling in one direction, the mouse can move >out of or to the edge of the scrolling window and the scrolling >stops. Solution: Every time we issue a fake button press, warp the >mouse back to the position it was at when we first pressed the >grab key. > > > > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #7205: fix_manifest command for bundlebuilder
Really this is a convenience function, but since we're now being picky about MANIFEST, I think that not having a way to fix the MANIFEST counts as a regression. Thus I do nominate this for 8.2 . fix_manifest.patch is just these changes, but it collides with the other patch I submitted. combined.patch is both patches together. diff --git a/src/sugar/activity/bundlebuilder.py b/src/sugar/activity/bundlebuilder.py index 2480b03..52cd3e5 100644 --- a/src/sugar/activity/bundlebuilder.py +++ b/src/sugar/activity/bundlebuilder.py @@ -192,6 +192,8 @@ setup.py uninstall [dirname] - uninstall the bundle \n\ setup.py genpot - generate the gettext pot file \n\ setup.py release - do a new release of the bundle \n\ setup.py help- print this message \n\ +setup.py fix_manifest- fix the MANIFEST file to list all files in directory \n\ + except dist/* .git/* .gitignore MANIFEST *.pyc *~ *.bak \n\ ' def cmd_dev(config, options, args): @@ -361,6 +363,10 @@ def cmd_build(config, options, args): builder = Builder(config) builder.build() +def cmd_fix_manifest(config, options, args): +buildpackager = BuildPackager(config) +buildpackager.fix_manifest() + def start(bundle_name=None): if bundle_name: logging.warn("bundle_name deprecated, now comes from activity.info") diff --git a/src/sugar/activity/bundlebuilder.py b/src/sugar/activity/bundlebuilder.py index 2480b03..7744f0b 100644 --- a/src/sugar/activity/bundlebuilder.py +++ b/src/sugar/activity/bundlebuilder.py @@ -81,6 +81,10 @@ class Builder(object): def build_locale(self): po_dir = os.path.join(self.config.source_dir, 'po') +if not self.config.bundle.is_dir(po_dir): +logging.warn("Missing po/ dir, cannot build_locale") +return + for f in os.listdir(po_dir): if not f.endswith('.po'): continue @@ -192,6 +196,8 @@ setup.py uninstall [dirname] - uninstall the bundle \n\ setup.py genpot - generate the gettext pot file \n\ setup.py release - do a new release of the bundle \n\ setup.py help- print this message \n\ +setup.py fix_manifest- fix the MANIFEST file to list all files in directory \n\ + except dist/* .git/* .gitignore MANIFEST *.pyc *~ *.bak \n\ ' def cmd_dev(config, options, args): @@ -214,6 +220,10 @@ def cmd_dist_xo(config, options, args): packager = XOPackager(config) packager.package() +def cmd_dist(config, options, args): +logging.warn("dist deprecated, use dist_xo.") +cmd_dist_xo(config, options, args) + def cmd_dist_source(config, options, args): packager = SourcePackager(config) packager.package() @@ -361,6 +371,10 @@ def cmd_build(config, options, args): builder = Builder(config) builder.build() +def cmd_fix_manifest(config, options, args): +buildpackager = BuildPackager(config) +buildpackager.fix_manifest() + def start(bundle_name=None): if bundle_name: logging.warn("bundle_name deprecated, now comes from activity.info") diff --git a/src/sugar/bundle/bundle.py b/src/sugar/bundle/bundle.py index 9e876c2..eccbe9a 100644 --- a/src/sugar/bundle/bundle.py +++ b/src/sugar/bundle/bundle.py @@ -132,7 +132,18 @@ class Bundle: zip_file.close() return True - + +def is_dir(self, filename): +if self._unpacked: +path = os.path.join(self._path, filename) +return os.path.isdir(path) +else: +zip_file = zipfile.ZipFile(self._path) +path = os.path.join(self._zip_root_dir, filename, "") +for subfile in zip_file.namelist(): +if subfile.startswith(path): +return True +return False def get_path(self): """Get the bundle path.""" ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On Sun, Jul 13, 2008 at 11:03 AM, Brian Jordan <[EMAIL PROTECTED]> wrote: > Brilliant work, Erik! I had a chance to play with your first working > hand scroll, and it's beyond explanation how fun it is to be able to > scroll around using the touchpad without aiming for a gtkScrollBar. Great to hear! I can't wait to give it a try myself...it's been a long time in coming. > For all to consider: there are two grab buttons. What if one tended to > grab + move *objects*, and the other grabs + moves > *scenes/backgrounds*? From what I've heard, kids tend to have a hard > time left-clicking and dragging with their same hand (as with the > touchpad). So, for applications like Browse, both grab buttons could > still just scroll up/down. But for graphical editors (e.g., layout > programs, Physics, Model, anything with a scene and objects), this UI > behavior may be a real time saver and fun to use. This would require > giving applications the ability to process events from these two > scroll buttons in a way that identifies them separately. That's an interesting idea. However, the reason there are two keys is so that interaction works well for both left- and right-handed users, without the need for them to cross their arms to scroll around. What we might be able to do, though, is map an SHIFT-HAND shortcut to a drag/drop action instead. (I suggest shift because it's the only modified which is present on both sides of our keyboard, for the same reason as above.) To make that work well, I think we'll need to manage the display of the cursor appropriately. perhaps we can use the horizontal/vertical/fleur arrows to indicate scrolling options, switch to the open hand when shift is pressed to indicate drag mode, and switch to a closed hand after a drag has been started. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
brian wrote: > Brilliant work, Erik! I had a chance to play with your first working > hand scroll, and it's beyond explanation how fun it is to be able to > scroll around using the touchpad without aiming for a gtkScrollBar. > > For all to consider: there are two grab buttons. What if one tended to > grab + move *objects*, and the other grabs + moves > *scenes/backgrounds*? From what I've heard, kids tend to have a hard > time left-clicking and dragging with their same hand (as with the > touchpad). adults too. recently while demoing one of the tamtam's, it was startling to see how much click-and-dragging was necessary (e.g., for a volume slider). i suppose that would quickly become a two-handed operation. and i have no idea how or whether the grab buttons could help this. they probably can't. paul > So, for applications like Browse, both grab buttons could > still just scroll up/down. But for graphical editors (e.g., layout > programs, Physics, Model, anything with a scene and objects), this UI > behavior may be a real time saver and fun to use. This would require > giving applications the ability to process events from these two > scroll buttons in a way that identifies them separately. > > Bravo, sir, > Brian > > On Thu, Jul 10, 2008 at 2:39 AM, Erik Garrison <[EMAIL PROTECTED]> wrote: > > Sugar devs: > > > > This is a copy of my bug report for #447. I have completed a first pass > > of the grab key implementation. > > > > -Erik > > > > > > Summary: > > > > I used the grab keys to convert the touchpad into a virtual > > mouse scrollwheel. Holding down the grab key and moving the mouse a > > small number pixels causes a fake mouse button 4/5/6/7 press, depending > > on the direction of motion. This approach works in all applications > > which support mouse scroll buttons. > > > > Patches: > > > > The attached patch to sugar-toolkit adds glib/C-side hooks to grab an > > ungrab the mouse, and pass motion-notify events to the python side of > > the Sugar shell. I have packaged this patch in an rpm which should be > > installable on an XO running a recent joyride (tested on joyride-2123). > > > > (RPMS: tested but slightly older git snapshot: > > > http://dev.laptop.org/~erik/rpms/sugar-toolkit-debuginfo-0.81.5-4.20080705gitab8 > c054dfb.fc9.i386.rpm > > or, untested but slightly newer git snapshot: > > http://dev.laptop.org/~erik/rpms/sugar-toolkit-0.81.6-1.fc9.i386.rpm) > > > > The attached patch to sugar (specifically keyhandler.py) adds the > > python-side hooks required to enable the grab/scroll button > > functionality. > > > > The patches work in the following manner: > > > >When the left or right grab buttons are pressed, XGrabPointer is > >called. Subsequently, we capture all of the motion-notify events > >which occur when the user moves the mouse, and each event hits > >KeyHandler._motion_notify_cb() with the coordinates of the mouse. > >After we move N pixels (currently 10) we issue a fake mouse scroll > >button press corresponding to the direction of motion of the mouse > >(4/5/6/7). To issue the fake button press I have found it is > >necessary to ungrab the mouse, issue the press, and then re-grab. > > > > Known issues: > > > >In some cases key-releases are not registered. This is problematic > >because without the release signal the mouse grabbing does not > >stop and Sugar becomes entirely unusable. I have not been able to > >establish why, but have noticed that hitting the journal view key > >after Sugar startup before any of the other special keys > >(registered in keyhandler.py) tends to resolve the issue for the > >Super_L and Super_R keys (the grab buttons). > > > >The mouse still scrolls around the screen, and the cursor is > >visible during the grab. Solution: Hide the mouse; When a grab key > >press is registered, hide the mouse by setting the cursor pixmap > >to a blank map (and set it back when the grab key release is > >registered). > > > >Eventually, after scrolling in one direction, the mouse can move > >out of or to the edge of the scrolling window and the scrolling > >stops. Solution: Every time we issue a fake button press, warp the > >mouse back to the position it was at when we first pressed the > >grab key. > > > > > > > > ___ > > Sugar mailing list > > Sugar@lists.laptop.org > > http://lists.laptop.org/listinfo/sugar > > > > > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On Sun, Jul 13, 2008 at 11:20 AM, <[EMAIL PROTECTED]> wrote: > adults too. recently while demoing one of the tamtam's, it was > startling to see how much click-and-dragging was necessary (e.g., > for a volume slider). i suppose that would quickly become a two-handed > operation. and i have no idea how or whether the grab buttons could > help this. they probably can't. The behavior of GTK "sliders" has bothered me. I'd expect to be able to click anywhere on the slider to immediately set it's value to the location I clicked, or click on the handle to drag it. Unfortunately, GTK doesn't behave this way, and instead moves the handle by small increments each time you click. Does anyone know if there is a way to change this? I love drag'n'drop, but I'd strongly prefer not to /require/ it. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Localization team
On Sun, 2008-07-13 at 12:18 +0200, Marco Pesenti Gritti wrote: > Any reason we don't have a localization team in the wiki? Any > volunteer to set it up? > Translations should really be handled upstream, so it's an area where > SugarLabs have to be very active. > Currently, Sayamindu Dasgupta is putting together an outstanding group of localizers at OLPC. We have enough work for our limited personal fixing what is broken without messing around with the bits that work;) Eventually, when organization outside of OPLC start localizing, Sayamindu might want to consider moving his project upstream. The turning point will likely be when Ubuntu starts shipping Sugar as a first class desktop. When that happens our localizers will double overnight. I'll set up a team, but point translators to Sayamindu. Sound reasonable? thanks Dfarning ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On 13 Jul 2008, at 16:19, Eben Eliason wrote: > On Sun, Jul 13, 2008 at 11:03 AM, Brian Jordan <[EMAIL PROTECTED]> > wrote: >> For all to consider: there are two grab buttons. What if one tended >> to >> grab + move *objects*, and the other grabs + moves >> *scenes/backgrounds*? From what I've heard, kids tend to have a hard >> time left-clicking and dragging with their same hand (as with the >> touchpad). So, for applications like Browse, both grab buttons could >> still just scroll up/down. But for graphical editors (e.g., layout >> programs, Physics, Model, anything with a scene and objects), this UI >> behavior may be a real time saver and fun to use. This would require >> giving applications the ability to process events from these two >> scroll buttons in a way that identifies them separately. > > That's an interesting idea. However, the reason there are two keys is > so that interaction works well for both left- and right-handed users, > without the need for them to cross their arms to scroll around. What > we might be able to do, though, is map an SHIFT-HAND shortcut to a > drag/drop action instead. (I suggest shift because it's the only > modified which is present on both sides of our keyboard, for the same > reason as above.) SHIFT-HAND would be a good direct alternative to the trackpad left button. It would then be useful in many existing places/activities for drag'n'drop operations while leaving the primary HAND use for scrolling. I'd probably use SHIFT-HAND instead of the trackpad button for clicking – it's already usually a two handed operation for me to avoid confusing the touch pad. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] SugarLabs and OLPC
On Sun, 2008-07-13 at 12:15 +0200, Marco Pesenti Gritti wrote: > Hello, > > there has been a bit of confusion on how the OLPC and SugarLabs > schedules relates, in particular regarding translation and string > freeze. > > http://lists.laptop.org/pipermail/localization/2008-July/001139.html > > I'm trying to think more in general about how to shape up the > upstream/downstream relation. My goals are: Marco, All of your suggestions are good. Instead of attempting make these decisions now, we should wait until OLPC has shipped 8.2 to continue this discussion. OLPC is busy trying to meet a hard deadline for their 300,000 users that is quickly approaching. Michael Stone and Gregorio are make good progress setting up the release process for OLPC at http://wiki.laptop.org/go/Release_Process_Home . thanks dfarning ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Localization team
On Sun, Jul 13, 2008 at 6:42 PM, David Farning <[EMAIL PROTECTED]> wrote: > On Sun, 2008-07-13 at 12:18 +0200, Marco Pesenti Gritti wrote: >> Any reason we don't have a localization team in the wiki? Any >> volunteer to set it up? >> Translations should really be handled upstream, so it's an area where >> SugarLabs have to be very active. >> > Currently, Sayamindu Dasgupta is putting together an outstanding group > of localizers at OLPC. > > We have enough work for our limited personal fixing what is broken > without messing around with the bits that work;) > > Eventually, when organization outside of OPLC start localizing, > Sayamindu might want to consider moving his project upstream. The > turning point will likely be when Ubuntu starts shipping Sugar as a > first class desktop. When that happens our localizers will double > overnight. > > I'll set up a team, but point translators to Sayamindu. Sound > reasonable? Well, part of the translation process must be upstream. We are checking in the translation in the upstream git and hence we need to respect the upstream schedule. I would personally encourage Sayamindu to start working upstream already, for example by providing docs on how to translate Glucose/activities on the sugarlabs wiki and by matching the pootle groups with Glucose/Fructose modules list. Do you see any downside with that approach? I'm *not* suggesting to host pootle on sugarlabs.org yet. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] SugarLabs and OLPC
On Sun, Jul 13, 2008 at 7:55 PM, David Farning <[EMAIL PROTECTED]> wrote: > On Sun, 2008-07-13 at 12:15 +0200, Marco Pesenti Gritti wrote: >> Hello, >> >> there has been a bit of confusion on how the OLPC and SugarLabs >> schedules relates, in particular regarding translation and string >> freeze. >> >> http://lists.laptop.org/pipermail/localization/2008-July/001139.html >> >> I'm trying to think more in general about how to shape up the >> upstream/downstream relation. My goals are: > > Marco, > > All of your suggestions are good. > > Instead of attempting make these decisions now, we should wait until > OLPC has shipped 8.2 to continue this discussion. OLPC is busy trying > to meet a hard deadline for their 300,000 users that is quickly > approaching. > > Michael Stone and Gregorio are make good progress setting up the release > process for OLPC at http://wiki.laptop.org/go/Release_Process_Home . The reason I posted this now is that there is already confusion about the upstream/downstream relation, as showed by the localization mailing list thread I referenced. Obviously we are not going to take any action until 8.2.0 is out, but I don't see any reason to not start thinking and discussing the direction we are taking. Mainly because having a direction helps informing the short time decisions. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Localization team
On Sun, Jul 13, 2008 at 8:52 PM, Chris Leonard <[EMAIL PROTECTED]> wrote: > I would say that Sayamindu is already doing exactly that sort of working > with upstream in the form of trying to coordinate translation efforts into > release schedules. Sure, he is! Just to make it clear in case that it isn't, I'm not criticizing Sayamindu work in *any* way. I just proposed a couple more ways to work with upstream, to try and address the confusion which has been raised recently on the localization list. Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Joyride shutdown flaky
Running recent Joyride on my G1G1. When I request a shutdown, it sometimes proceeds "hands off". But sometimes, after the Sugar shell has closed - nothing further seems to happen. On those occasions, sometimes the ending-picture (with the "don't do this" icons) is presented if I press alt-ctl-F2 (the Sugar shell was on alt-ctl-F3). If I can get to the ending picture, the shutdown completes by itself after what seems like a LONG time. But if I don't get to the ending picture, I'm left to complete the shutdown process by holding down the power button for more than four seconds. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Drop activity launch limitation?
Hello, we have logic in the shell to limit launching activity of the same type at the same time (i.e. before the first activity launch has been completed). It seem to be that this is obsoleted by the new launch feedback. Should we drop it? Marco ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] ssl authentication [was (another) WebKit port of Browse]
On Jul 12, 2008, at 11:59 PM, Dirk-Willem van Gulik wrote: > Which IDMR - the sun one with all the usual/heavily standardized > industry protocols - or something OLPC specific ? It's not a protocol, just a small Python script that does some XML-RPC nonsense from what I recall. -- Ivan Krstić <[EMAIL PROTECTED]> | http://radian.org ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Localization team
On Sun, 2008-07-13 at 20:59 +0200, Marco Pesenti Gritti wrote: > On Sun, Jul 13, 2008 at 8:52 PM, Chris Leonard <[EMAIL PROTECTED]> wrote: > > I would say that Sayamindu is already doing exactly that sort of working > > with upstream in the form of trying to coordinate translation efforts into > > release schedules. > > Sure, he is! Just to make it clear in case that it isn't, I'm not > criticizing Sayamindu work in *any* way. > > I just proposed a couple more ways to work with upstream, to try and > address the confusion which has been raised recently on the > localization list. > I have create the LocalizationTeam page stubs on w.s.o. When we get feed back from Sayamindu we can start populating them. dfarning ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] ssl authentication [was (another) WebKit port of Browse]
On Mon, Jul 14, 2008 at 10:44 AM, Ivan Krstić <[EMAIL PROTECTED]> wrote: > On Jul 12, 2008, at 11:59 PM, Dirk-Willem van Gulik wrote: >> Which IDMR - the sun one with all the usual/heavily standardized >> industry protocols - or something OLPC specific ? > > > It's not a protocol, just a small Python script that does some XML-RPC > nonsense from what I recall. Was there a better design described somewhere? The server-side code for idmgr needs a rewrite, so the opportunity is there if you can point me to an outline of a saner protocol. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Control Panel Buttons ?
Whatever else, when dealing with non-computer-literate persons, I believe that EACH visual icon __must__ universally convey only a __single__ meaning. That is why I find the buttons in the Control Panel inconsistent. Within the sub-functions, the 'X' button (labeled 'Cancel') appears to convey the concept: "Throw away whatever it is that you have done." I personally would wish this button to be modal - and have it be 'grayed out' in the header until the kid makes a change. [I would expect a kid to understand (for 'X'): "I'm through. Let me out of here, but wipe clean all materials that I worked with".] Within the sub-functions, slightly more problematic is the 'check' button (I would label it 'Apply') which appears to convey the concept: "I approve.". I personally would wish this button to be modal - and have it be 'grayed out' in the header until the kid makes a change. [I would expect a kid to understand (for 'check'): "I'm done. Let me out of here, as soon as you have changed the settings within the system to what I've specified here".] That leaves the situation where the subfunction was called to look at the values, not to change them. I personally would want the sub-functions to have a (third) 'left-pointing triangle' button (labeled 'Back') in the header, active to begin with. This button would be modal - when any change gets made using the facilities of the sub-function, the 'Back' button gets 'grayed out', but the 'X' and 'check' buttons get activated. [I would expect a kid to understand (for 'left-pointing triangle'): "I didn't do anything. Let me out of here." ] This is why I am upset to find (in current Joyride) in the main 'Control Panel' pane an 'X' button labeled 'Done'. The __universal__ symbolism of 'X' ought to be "Forget it". Why confuse me (and the kids) by using an 'X' here for "simple exit". [The kid doesn't want to have the system "throw away" something he did in s sub-function of the Control Panel.] What is appropriate to use on the main 'Control Panel' pane (since nothing got changed ON THAT PANE) is a 'left-pointing triangle' button labeled 'Back' (i.e., back to the Home View icon). All uses of an 'X' button should convey the same concept: "Forget it". Turns out the Journal 'details view' pane employs the special interpretation that its buttons apply to the Journal_entry [instead of to the pane in which that 'X' is shown]. Thus the 'X' button in the 'details view' pane header is used to 'Erase' the Journal_entry itself, whereas all exiting (in the current Joyride implementation) from the 'details view' pane [whether or not the kid made changes to the (text) content of that pane] is handled by an "active line" located below the pane header [that active line is "identified" by a 'left-pointing triangle' icon ('Back') drawn within that line]. In 'Develop', the functions of the 'X' button and the 'check' button seem to be reversed -- 'check' throws away what was done, and exits. I would say: "NO No no -- visual symbolism __must__ be consistent". mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] after an Activity stops
In Joyride 2146, when I 'stop' an Activity (by clicking on the octagonal 'Stop' icon in the Activity screen's header), what gets shown next on my screen is the last "throbber" page from whatever Activity is now at the top of the Activity stack. My XO just sits there at that nearly-blank blank page (with the icon of that uppermost Activity in the center of the page) until I press keys to show me something (for instance, I can press F4 to show me the Activity View). I don't expect that an Activity which is already on the stack needs to be re-initialized -- even if it did, I would expect the system to "automatically" proceed to a "real" screen (instead of getting "stuck" on that uninformative "blank" screen). mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] after an Activity stops
Yup, known bug: http://dev.laptop.org/ticket/7354 =) - Eben On Sun, Jul 13, 2008 at 8:47 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: > In Joyride 2146, when I 'stop' an Activity (by clicking on the > octagonal 'Stop' icon in the Activity screen's header), what gets > shown next on my screen is the last "throbber" page from whatever > Activity is now at the top of the Activity stack. My XO just sits > there at that nearly-blank blank page (with the icon of that > uppermost Activity in the center of the page) until I press keys to > show me something (for instance, I can press F4 to show me the > Activity View). I don't expect that an Activity which is already > on the stack needs to be re-initialized -- even if it did, I would > expect the system to "automatically" proceed to a "real" screen > (instead of getting "stuck" on that uninformative "blank" screen). > > mikus > > ___ > Sugar mailing list > Sugar@lists.laptop.org > http://lists.laptop.org/listinfo/sugar > ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Drop activity launch limitation?
> we have logic in the shell to limit launching activity of the same > type at the same time (i.e. before the first activity launch has been > completed). It seem to be that this is obsoleted by the new launch > feedback. Should we drop it? My opinion - yes, you should. But I've encountered a more pernicious "hurdle". Suppose an Activity launch fails (for instance, if a file happens to be missing, or if the Activity experiences an incompatibility against Rainbow). In current Joyride, the new launch feedback will keep blinking until something times out -- this seems to take several minutes (far too long for my patience). I have to go through hoops to "escape" from that (unhelpful) new launch feedback. I don't know what would be a decent solution, but leaving a kid (or adult) staring at the new launch feedback for possibly minutes on end seems icky. mikus ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Drop activity launch limitation?
On Sun, Jul 13, 2008 at 9:44 PM, Mikus Grinbergs <[EMAIL PROTECTED]> wrote: >> we have logic in the shell to limit launching activity of the same >> type at the same time (i.e. before the first activity launch has been >> completed). It seem to be that this is obsoleted by the new launch >> feedback. Should we drop it? > > My opinion - yes, you should. > > But I've encountered a more pernicious "hurdle". Suppose an > Activity launch fails (for instance, if a file happens to be > missing, or if the Activity experiences an incompatibility against > Rainbow). In current Joyride, the new launch feedback will keep > blinking until something times out -- this seems to take several > minutes (far too long for my patience). I have to go through hoops > to "escape" from that (unhelpful) new launch feedback. I agree the current timeout is far from optimal...it can really try your patience, and often makes you think that it will never timeout. That aside, though, is the act of leaving the view really that out-of-the-way? The Frame is purposely left available, so once can navigate back to Home via the Frame or Home key on the keyboard. > I don't know what would be a decent solution, but leaving a kid (or > adult) staring at the new launch feedback for possibly minutes on > end seems icky. Yeah, I'm unsatisfied, too. Perhaps we can shorten the interval, but better than that we should be actively attempting to detect failure (how can we do this?) so that when a launch fails "hard" for some reason, we can immediately indicate that. - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] OLPC/Sugar related MIME Types...
I am going to add some MIME types for Apache on the XO - application/vnd.olpc-sugar xo - application/vnd.olpc-content xol - application/vnd.olpc-journal-entry xoj The above list comes from a bit of Googling about. Are there any other mime types that we care about? cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] #447: grab/scroll key
On Sun, Jul 13, 2008 at 11:19:46AM -0400, Eben Eliason wrote: > On Sun, Jul 13, 2008 at 11:03 AM, Brian Jordan <[EMAIL PROTECTED]> wrote: > > Brilliant work, Erik! I had a chance to play with your first working > > hand scroll, and it's beyond explanation how fun it is to be able to > > scroll around using the touchpad without aiming for a gtkScrollBar. > > Great to hear! I can't wait to give it a try myself...it's been a > long time in coming. > I'll give you a demo tomorrow. > > For all to consider: there are two grab buttons. What if one tended to > > grab + move *objects*, and the other grabs + moves > > *scenes/backgrounds*? From what I've heard, kids tend to have a hard > > time left-clicking and dragging with their same hand (as with the > > touchpad). So, for applications like Browse, both grab buttons could > > still just scroll up/down. But for graphical editors (e.g., layout > > programs, Physics, Model, anything with a scene and objects), this UI > > behavior may be a real time saver and fun to use. This would require > > giving applications the ability to process events from these two > > scroll buttons in a way that identifies them separately. > > That's an interesting idea. However, the reason there are two keys is > so that interaction works well for both left- and right-handed users, > without the need for them to cross their arms to scroll around. What > we might be able to do, though, is map an SHIFT-HAND shortcut to a > drag/drop action instead. (I suggest shift because it's the only > modified which is present on both sides of our keyboard, for the same > reason as above.) > I like Brian's idea but felt similarly about the difficulty in deciding which hand button executes which function. SHIFT-HAND is a good solution, and relatively easy to implement. > To make that work well, I think we'll need to manage the display of > the cursor appropriately. perhaps we can use the > horizontal/vertical/fleur arrows to indicate scrolling options, switch > to the open hand when shift is pressed to indicate drag mode, and > switch to a closed hand after a drag has been started. > How is the cursor pixmap currently set? Is there an existing function in the sugar codebase to set the cursor pixmap? Erik ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] profile information
Hi, Is it possible for Sugar users to have an extensible profile? Currently, this only encompasses nickname and colors, but are there plans to extend this somehow? I propose using a dictionary to represent an extensible list of key/value pairs, some of which will be mandatory, like nickname, colors, key (countries may want to enforce other mandatory fields, like grade, class etc). This dictionary would be loaded from storage on boot and saved on every change. As a result, the control panel would be extended to accomodate a table so that users can append more info about themselves. Not to mention that all profiles should be shared and locally indexed on each XO to look for specific users. Comments? Pol -- Polychronis Ypodimatopoulos Graduate student Viral Communications MIT Media Lab Tel: +1 (617) 459-6058 http://www.mit.edu/~ypod/ ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] profile information
Hi Pol, > I propose using a dictionary to represent an extensible list of > key/value pairs, some of which will be mandatory, like nickname, > colors, key (countries may want to enforce other mandatory fields, > like grade, class etc). This dictionary would be loaded from > storage on boot and saved on every change. The control panel code already extends the profile in this way; the data from control panel entries are saved into the profile on change and loaded from it at startup. So, we're most of the way there already. We don't have a UI for the arbitrary keystore you mention, though, and loading entries from the profile is done manually in profile.py: we pull out key-value pairs that we're interested in, instead of just throwing every entry into the profile directly. I think we should switch over to importing every key-value pair we find into the running profile, as you suggest. - Chris. -- Chris Ball <[EMAIL PROTECTED]> ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar