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] 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
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] 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
[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
