Re: [sugar] Another pass through some basic Activity test results
On Sun, Sep 28, 2008 at 2:32 AM, Gary C Martin [EMAIL PROTECTED] wrote: On 26 Sep 2008, at 19:31, Arjun Sarwal wrote: Hi, 2008/9/26 Gary C Martin [EMAIL PROTECTED]: Here's a set of basic Activity test results for build 8.2-763, hope the ASCI art doesn't get too mangled by the list server (need to view with a fixed Measure-20 . . - . x x x . x Doesn't sleep when Activity is in the background (eats 75% cpu). Can't seem to record anything. Keep error when -- When Measure is in background and some other Activity comes in foreground, then Measure releases sound device - you can record sound using any other program/application. In this state Measure also doesn't hog CPU. Just testing with Measure-21 and 8.2-765, yes I see this now. However switching to any of the Neighborhood/Group/Home views does not seem count as putting Measure into the background, it still consumes the cpu and claims the sound input device. I'm guessing this is a Sugar behaviour? Is this a bug or a feature (feels like a Sugar bug that would make the UI sluggish for no go reason)? In Sugar, there's always one and only one active activity. You can see which it is by looking at the icon below the XO in the favorites view or by looking at the selected activity button in the top frame. This is the activity that will be brought to the front when you go to the Activity zoom level. I'm guessing Measure uses its active activity status to decide if it should update itself or not, but from earlier emails I think the desired behavior is rather to stop updating while the activity window is not visible. For this, the activity author can use the information that the window manager (or is it X?) provides to each top level window, in pygtk: http://pygtk.org/docs/pygtk/class-gtkwidget.html#signal-gtkwidget--visibility-notify-event Just listen for that signal and check the value of event.state, it can be one of gtk.gdk.VISIBILITY_FULLY_OBSCURED, gtk.gdk.VISIBILITY_PARTIAL or gtk.gdk.VISIBILITY_UNOBSCURED. You will want to stop updating the screen when fully obscured and update it otherwise. Faisal, could you please update the almanac with this info? Thanks, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Feedback on Measure (was Re: Another pass through some basic Activity test results)
2008/9/29 Erik Blankinship [EMAIL PROTECTED]: On Sun, Sep 28, 2008 at 6:02 AM, Gary C Martin [EMAIL PROTECTED] wrote: On 26 Sep 2008, at 19:31, Arjun Sarwal wrote: 2008/9/26 Gary C Martin [EMAIL PROTECTED]: Here's a set of basic Activity test results for build 8.2-763, hope the ASCI art doesn't get too mangled by the list server (need to view with a fixed Measure-20 . . - . x x x . x Doesn't sleep when Activity is in the background (eats 75% cpu). Can't seem to record anything. Keep error when -- When Measure is in background and some other Activity comes in foreground, then Measure releases sound device - you can record sound using any other program/application. In this state Measure also doesn't hog CPU. Just testing with Measure-21 and 8.2-765, yes I see this now. However switching to any of the Neighborhood/Group/Home views does not seem count as putting Measure into the background, it still consumes the cpu and claims the sound input device. I'm guessing this is a Sugar behaviour? Is this a bug or a feature (feels like a Sugar bug that would make the UI sluggish for no go reason)? See #7856. Seems like a Sugar related issue to me. I had borrowed the code and concept from Record activity, which now apparently uses some other method to determine switch of view/context/activity.( I think they detect whether one of the main gtk widgets is the topmost or not etc. not sure) I should try exploring that. Any help on this would be great. Record listens for visibility-notify-event: self.playOggWindow.add_events(gtk.gdk.VISIBILITY_NOTIFY_MASK) self.playOggWindow.connect(visibility-notify-event, self._visibleNotifyCb) Because Record has many different windows, we listen on each window and run through a series of checks on the callback to determine if it is the active activity anymore. Oops, just replied with similar information to the old thread, sorry. Do you need to do that for each window? Why don't you just listen for that signal in just the main activity window and stop everything when gtk.gdk.VISIBILITY_FULLY_OBSCURED and resume when otherwise? Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Feedback on Measure (was Re: Another pass through some basic Activity test results)
Do you need to do that for each window? Why don't you just listen for that signal in just the main activity window and stop everything when gtk.gdk.VISIBILITY_FULLY_OBSCURED and resume when otherwise? Full screen modes in Record completely obscure the main activity window. We don't just listen for visibility events on the video windows because sometimes these are fully obscured (when transcoding, for example). Therefore we listen on both the main activity window and the video windows, and in consultation with the activity's current state (fullscreen, normal, transcoding), decide if Record is the current activity. I've never fully understood the rationale for why the sugar api does not alert activities as to when they are active or not, thereby saving all activity authors these hassles. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Another pass through some basic Activity test results
In Sugar, there's always one and only one active activity. You can see which it is by looking at the icon below the XO in the favorites view or by looking at the selected activity button in the top frame. This is the activity that will be brought to the front when you go to the Activity zoom level. I'm guessing Measure uses its active activity status to decide if it should update itself or not, but from earlier emails I think the desired behavior is rather to stop updating while the activity window is not visible. For this, the activity author can use the information that the window manager (or is it X?) provides to each top level window, in pygtk: http://pygtk.org/docs/pygtk/class-gtkwidget.html#signal-gtkwidget--visibility-notify-event Just listen for that signal and check the value of event.state, it can be one of gtk.gdk.VISIBILITY_FULLY_OBSCURED, gtk.gdk.VISIBILITY_PARTIAL or gtk.gdk.VISIBILITY_UNOBSCURED. You will want to stop updating the screen when fully obscured and update it otherwise. Faisal, could you please update the almanac with this info? The basics of this idea are in the almanac: http://wiki.laptop.org/go/Sugar_Almanac#How_do_I_know_when_my_activity_is_.22active.22_or_not.3F ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Feedback on Measure (was Re: Another pass through some basic Activity test results)
On Mon, Sep 29, 2008 at 2:47 PM, Erik Blankinship [EMAIL PROTECTED] wrote: Do you need to do that for each window? Why don't you just listen for that signal in just the main activity window and stop everything when gtk.gdk.VISIBILITY_FULLY_OBSCURED and resume when otherwise? Full screen modes in Record completely obscure the main activity window. We don't just listen for visibility events on the video windows because sometimes these are fully obscured (when transcoding, for example). Therefore we listen on both the main activity window and the video windows, and in consultation with the activity's current state (fullscreen, normal, transcoding), decide if Record is the current activity. I've never fully understood the rationale for why the sugar api does not alert activities as to when they are active or not, thereby saving all activity authors these hassles. Well, the Sugar API alerts activities when they are the active activity (SetActive method in the dbus service), but it has a different meaning that being visible (see my earlier email from today). For visibility, the X stuff already provides all that is needed and though we would like to make activity author's life as simple as possible, properly maintaining an API is something very expensive and we just don't have the resources for now. Faisal's work is the best that we have right now regarding activity author support. Regards, Tomeu ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Feedback on Measure (was Re: Another pass through some basic Activity test results)
On Mon, Sep 29, 2008 at 08:47:36AM -0400, Erik Blankinship wrote: Do you need to do that for each window? Why don't you just listen for that signal in just the main activity window and stop everything when gtk.gdk.VISIBILITY_FULLY_OBSCURED and resume when otherwise? Full screen modes in Record completely obscure the main activity window. We don't just listen for visibility events on the video windows because sometimes these are fully obscured (when transcoding, for example). Therefore we listen on both the main activity window and the video windows, and in consultation with the activity's current state (fullscreen, normal, transcoding), decide if Record is the current activity. I've never fully understood the rationale for why the sugar api does not alert activities as to when they are active or not, thereby saving all activity authors these hassles. Is there any particular reason why Record does not use a single window? Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Feedback on Measure (was Re: Another pass through some basic Activity test results)
Is there any particular reason why Record does not use a single window? Record's GUI overlays widgets on top of video windows. This is how we create the picture in a picture effect (using XV in a window) and also how we add the fullscreen toggle button. GTK doesn't play well with overlapping widgets -- gtk.Fixed() doesn't guarantee Z-order. So we use a stack of gtk.Windows without decoration. Unfortunately, when we put xv video into a widget (e.g. gtk.DrawingArea with a gstreamer xvimagesink) into a gtk.Fixed, that widget's video always displays on top of other widgets, regardless of its z-order. It was recommended at one point to create a new version of gtk.Fixed that guarantees z-order, but the use of gtk.Window was well underway and works. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Feedback on Measure (was Re: Another pass through some basic Activity test results)
(have changed the subject line since we are drifting off topic from the previous subject ) Hi, On Sun, Sep 28, 2008 at 6:02 AM, Gary C Martin [EMAIL PROTECTED] wrote: On 26 Sep 2008, at 19:31, Arjun Sarwal wrote: 2008/9/26 Gary C Martin [EMAIL PROTECTED]: Here's a set of basic Activity test results for build 8.2-763, hope the ASCI art doesn't get too mangled by the list server (need to view with a fixed Measure-20 . . - . x x x . x Doesn't sleep when Activity is in the background (eats 75% cpu). Can't seem to record anything. Keep error when -- When Measure is in background and some other Activity comes in foreground, then Measure releases sound device - you can record sound using any other program/application. In this state Measure also doesn't hog CPU. Just testing with Measure-21 and 8.2-765, yes I see this now. However switching to any of the Neighborhood/Group/Home views does not seem count as putting Measure into the background, it still consumes the cpu and claims the sound input device. I'm guessing this is a Sugar behaviour? Is this a bug or a feature (feels like a Sugar bug that would make the UI sluggish for no go reason)? See #7856. Seems like a Sugar related issue to me. I had borrowed the code and concept from Record activity, which now apparently uses some other method to determine switch of view/context/activity.( I think they detect whether one of the main gtk widgets is the topmost or not etc. not sure) I should try exploring that. Any help on this would be great. -- For recording the waveforms, within 'Sound' in toolbar, if 'Now' is selected and the record button next to it is pressed, it will capture the current displayed waveform. If you select an interval and then press the record button, it will start saving waveforms at the specified interval and the record button will change to a 'stop' button. It will record a maximum of 10 waveforms. You will be able to see the waveforms as picture files in the Journal Ahhh, thanks Arjun, so that's where they go to. I was expecting some visual representation within Measure, perhaps like Record does, where there is a tray at the bottom of the screen, or Browse and its bookmark thumbnails. Thats very much on my list for the next set of TODOs. I am however not sure from the UI point of view where this tray could go, and where this textbox could go...or if there is an alternate replacement for both ? Is there a way to capture waveform images without the entire UI also appearing in the screen shot? There is and I thought about that. But then I figured that along with the waveform one would also need to know things like, what was the timebase scale when the waveform was being displayed, was it in time mode or fft mode etc. So I took the whole screen shot that would also have all other information included. Maybe just the waveform area saved along with some meta-data stored in the journal entry might be an idea to consider ? --For recording sensor values, within the 'Sensors' context , when one presses the record button it will start writing the sensor values (of the sensor connected at Analog Input) at the specified interval. You can have multiple recording sessions,i.e. stop it and then resume it and stop it again and resume it. You can see the logged sensor values in the Journal. They are saved in csv format. (I am waiting for the spreadsheet activity to come soon! :) ) Thanks, I understand this now as well. I had not noticed that new entries were silently being entered in to the Journal. BTW: you can resume the CSV file and Write will display the list of values. I also tried copying the CSV to the clipboard, but it generated a blank clipboard icon and would not paste anywhere (probably a Sugar issue, the clipboard isn't very robust yet). I tried that too. It didn't work - Write doesn't copy anything on the clip-board if one is viewing a csv file. Seems like a bug? Some quick suggestions: - The Start Recording text could say Start Recording to Journal, that would have pointed me to check in the Journal after clicking record. Agreed, good idea. - The time section menu could say Every 30 seconds, Every 2 minutes etc. Before you explained, I believed that the times were the duration of the sample to be recorded, not the interval between each sample. The little toolbar interval icon makes more sense now that I know what the menu does ;-) Hmm...so the interval needs to be made more intuitive... Lastly, thanks for the feedback, its really useful. It helped me figure out a minor problem in sensor values recording (#8683) and I released ver21 that corrects that! Glad it was of use! I'm a bit of an electronics type, so I'm really glad Measure is up and working again. Please keep the feedback coming! One of the things that I want to do is to display the logged values in the small textbox
Re: [sugar] Another pass through some basic Activity test results
Gary, this is a very helpful analysis. Thanks. Arjun, I wonder if Measure isn't exceptional in regard to when it is not in the foreground. I can imagine wanted to log data while doing other things: It isn't clear it should go idle when not visible. My naive guess would be to assume that a timer were enabled, Measure always behave as if it had focus, but otherwise sleep. That said, I imagine it would be difficult to algorithmically determine the user's intention. -walter ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Feedback on Measure (was Re: Another pass through some basic Activity test results)
On Sun, Sep 28, 2008 at 6:02 AM, Gary C Martin [EMAIL PROTECTED] wrote: On 26 Sep 2008, at 19:31, Arjun Sarwal wrote: 2008/9/26 Gary C Martin [EMAIL PROTECTED]: Here's a set of basic Activity test results for build 8.2-763, hope the ASCI art doesn't get too mangled by the list server (need to view with a fixed Measure-20 . . - . x x x . x Doesn't sleep when Activity is in the background (eats 75% cpu). Can't seem to record anything. Keep error when -- When Measure is in background and some other Activity comes in foreground, then Measure releases sound device - you can record sound using any other program/application. In this state Measure also doesn't hog CPU. Just testing with Measure-21 and 8.2-765, yes I see this now. However switching to any of the Neighborhood/Group/Home views does not seem count as putting Measure into the background, it still consumes the cpu and claims the sound input device. I'm guessing this is a Sugar behaviour? Is this a bug or a feature (feels like a Sugar bug that would make the UI sluggish for no go reason)? See #7856. Seems like a Sugar related issue to me. I had borrowed the code and concept from Record activity, which now apparently uses some other method to determine switch of view/context/activity.( I think they detect whether one of the main gtk widgets is the topmost or not etc. not sure) I should try exploring that. Any help on this would be great. Record listens for visibility-notify-event: self.playOggWindow.add_events(gtk.gdk.VISIBILITY_NOTIFY_MASK) self.playOggWindow.connect(visibility-notify-event, self._visibleNotifyCb) Because Record has many different windows, we listen on each window and run through a series of checks on the callback to determine if it is the active activity anymore. Be sure to look out for #5500 when trying to get access to a resource like the camera or microphone. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Another pass through some basic Activity test results
On 26 Sep 2008, at 19:31, Arjun Sarwal wrote: Hi, 2008/9/26 Gary C Martin [EMAIL PROTECTED]: Here's a set of basic Activity test results for build 8.2-763, hope the ASCI art doesn't get too mangled by the list server (need to view with a fixed Measure-20 . . - . x x x . x Doesn't sleep when Activity is in the background (eats 75% cpu). Can't seem to record anything. Keep error when -- When Measure is in background and some other Activity comes in foreground, then Measure releases sound device - you can record sound using any other program/application. In this state Measure also doesn't hog CPU. Just testing with Measure-21 and 8.2-765, yes I see this now. However switching to any of the Neighborhood/Group/Home views does not seem count as putting Measure into the background, it still consumes the cpu and claims the sound input device. I'm guessing this is a Sugar behaviour? Is this a bug or a feature (feels like a Sugar bug that would make the UI sluggish for no go reason)? -- For recording the waveforms, within 'Sound' in toolbar, if 'Now' is selected and the record button next to it is pressed, it will capture the current displayed waveform. If you select an interval and then press the record button, it will start saving waveforms at the specified interval and the record button will change to a 'stop' button. It will record a maximum of 10 waveforms. You will be able to see the waveforms as picture files in the Journal Ahhh, thanks Arjun, so that's where they go to. I was expecting some visual representation within Measure, perhaps like Record does, where there is a tray at the bottom of the screen, or Browse and its bookmark thumbnails. Is there a way to capture waveform images without the entire UI also appearing in the screen shot? --For recording sensor values, within the 'Sensors' context , when one presses the record button it will start writing the sensor values (of the sensor connected at Analog Input) at the specified interval. You can have multiple recording sessions,i.e. stop it and then resume it and stop it again and resume it. You can see the logged sensor values in the Journal. They are saved in csv format. (I am waiting for the spreadsheet activity to come soon! :) ) Thanks, I understand this now as well. I had not noticed that new entries were silently being entered in to the Journal. BTW: you can resume the CSV file and Write will display the list of values. I also tried copying the CSV to the clipboard, but it generated a blank clipboard icon and would not paste anywhere (probably a Sugar issue, the clipboard isn't very robust yet). Some quick suggestions: - The Start Recording text could say Start Recording to Journal, that would have pointed me to check in the Journal after clicking record. - The time section menu could say Every 30 seconds, Every 2 minutes etc. Before you explained, I believed that the times were the duration of the sample to be recorded, not the interval between each sample. The little toolbar interval icon makes more sense now that I know what the menu does ;-) Lastly, thanks for the feedback, its really useful. It helped me figure out a minor problem in sensor values recording (#8683) and I released ver21 that corrects that! Glad it was of use! I'm a bit of an electronics type, so I'm really glad Measure is up and working again. --Gary P.S. Any chance of solving the keep error bug every time Measure is closed? I'm not quite sure what causes them. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Another pass through some basic Activity test results
Hi Gary Thanks for this excellent testing! 2008/9/26 Gary C Martin [EMAIL PROTECTED]: Here's a set of basic Activity test results for build 8.2-763, hope the ASCI art doesn't get too mangled by the list server (need to view with a fixed width font). The Activities are in no specific order, and sorry if I missed out yours, but I wanted to post today incase it helps with looming/ongoing release decisions. I do want to note something I think is new in 8.2-763 since my previous tests, 5 times during the run through below the XO became extremely sluggish, initially I just thought it was the poorly performing Activity, but checking top in 4 cases I could the sugar shell process eating 30-50% of CPU but apparently doing nothing (was not connected to a jabber server), and in the other case I had 2 rainbow processes eating up 45% cpu each (though the Sugar UI showed no Activity instances were running). I am now retesting to try and catch the bad behaviour as it happens. Just wanted to warn testers to keep an eye on top, if things feel slow, you might have a hung-up process burning cycles and need to ctrl-alt-escape. Your diagram looked OK to me, but my comments will probably mangle it, so I'll try to make it clear what I'm commenting on... build 8.2-763 Activity name | Could start . = success | | Could stop (all must work ctrl-q alt-esc, toolbar, Frame) - = N/A | | | Sound x = fail| | | | Journal entry ? = unknown | | | | | Useful resume * = see note| | | | | | Picks-up Journal entry name change while active | | | | | | | Names Frame palette to match the resumed title | | | | | | | | License entry in activity.info | | | | | | | | | Using bundle_id in activity.info | | | | | | | | | | | | | | | | | | | | Browse-98 . . . . . x x . x The first x is for Picks-up Journal entry name change while active - almost every activity failed this, so it's likely to be a Sugar (activity API) bug, not an activity bug. I logged #8678. The Names Frame palette to match the resumed title is also probably a Sugar issue, but I'm not sure what you mean exactly. If I change the title of an activity and stop it, then resume it, the frame palette does show the new name for me, for Chat, which you marked as a failure. However if I change the name of the activity while it is running, the frame palette doesn't update to the new name *unless* I stop and resume. Is that what you meant? The switch from service_name to bundle_id isn't yet critical, but needs to be clearly and widely communicated. I'm getting together a list of such issues to write up and publicize. Chat-47 . . - . . x x . . Some subtle sound for arival and departure would be very useful. Sound would be a nice enhancement - I logged #8679. Bounce-6 . . * . . x x x * No sound, not sure if that's a bug or is as intended. Incorrect bundle_id string. Sound was broken in pygame and SDL - #8307, should be fixed in 765. Regards Morgan ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Another pass through some basic Activity test results
Hi, 2008/9/26 Gary C Martin [EMAIL PROTECTED]: Here's a set of basic Activity test results for build 8.2-763, hope the ASCI art doesn't get too mangled by the list server (need to view with a fixed Measure-20 . . - . x x x . x Doesn't sleep when Activity is in the background (eats 75% cpu). Can't seem to record anything. Keep error when -- When Measure is in background and some other Activity comes in foreground, then Measure releases sound device - you can record sound using any other program/application. In this state Measure also doesn't hog CPU. -- For recording the waveforms, within 'Sound' in toolbar, if 'Now' is selected and the record button next to it is pressed, it will capture the current displayed waveform. If you select an interval and then press the record button, it will start saving waveforms at the specified interval and the record button will change to a 'stop' button. It will record a maximum of 10 waveforms. You will be able to see the waveforms as picture files in the Journal --For recording sensor values, within the 'Sensors' context , when one presses the record button it will start writing the sensor values (of the sensor connected at Analog Input) at the specified interval. You can have multiple recording sessions,i.e. stop it and then resume it and stop it again and resume it. You can see the logged sensor values in the Journal. They are saved in csv format. (I am waiting for the spreadsheet activity to come soon! :) ) Though, without a sensor you will either be seeing a value around 16000 if you are in 'resistive sensor mode' (which turns on internal bias voltage) and -32768 if you are 'voltage sensor mode' (which turns off internal bias voltage) Lastly, thanks for the feedback, its really useful. It helped me figure out a minor problem in sensor values recording (#8683) and I released ver21 that corrects that! Best, Arjun ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Another pass through some basic Activity test results
Here's a set of basic Activity test results for build 8.2-763, hope the ASCI art doesn't get too mangled by the list server (need to view with a fixed width font). The Activities are in no specific order, and sorry if I missed out yours, but I wanted to post today incase it helps with looming/ongoing release decisions. I do want to note something I think is new in 8.2-763 since my previous tests, 5 times during the run through below the XO became extremely sluggish, initially I just thought it was the poorly performing Activity, but checking top in 4 cases I could the sugar shell process eating 30-50% of CPU but apparently doing nothing (was not connected to a jabber server), and in the other case I had 2 rainbow processes eating up 45% cpu each (though the Sugar UI showed no Activity instances were running). I am now retesting to try and catch the bad behaviour as it happens. Just wanted to warn testers to keep an eye on top, if things feel slow, you might have a hung-up process burning cycles and need to ctrl-alt-escape. build 8.2-763 Activity name | Could start . = success | | Could stop (all must work ctrl-q alt-esc, toolbar, Frame) - = N/A | | | Sound x = fail| | | | Journal entry ? = unknown | | | | | Useful resume * = see note| | | | | | Picks-up Journal entry name change while active | | | | | | | Names Frame palette to match the resumed title | | | | | | | | License entry in activity.info | | | | | | | | | Using bundle_id in activity.info | | | | | | | | | | | | | | | | | | | | Browse-98 . . . . . x x . x Words-3 . . . . x x . x . Could keep a history of words searched for Chat-47 . . - . . x x . . Some subtle sound for arival and departure would be very useful. Firefox-6 . . - x x x x x x Sugar icon times out, left with grey circle in the Frame activity instance area. Log-14 . . - . x x x . x Scratch-11 . . . x x x x * x Missing bundle_id, and license .info entry is some text that points to some URL. Bounce-6 . . * . . x x x * No sound, not sure if that's a bug or is as intended. Incorrect bundle_id string. Bridge-2 . . x . x x x . . Moon-6 . . - . . x x . . News Reader-24 . . - . x x . x x Feeds not remembered between sessions. Record-58 . . . . . x . . x Implode-5 . . - . . x . . x EToys-94 . . . . . . x . x Frame palette name is a rather unfriendly string /usr/share/etoys/ etoys.image. Colors!-4 . x - . . x x x x Needs to resume showing painting end state, not blank page at time zero. Toolbar stop and ctrl-q fail to stop activity, only alt-esc and Frame instance palette work. Speak-9 . . . . . x x . . Paint-23 . . - . . x . . x Some other tools could use cursor event fix. PlayGo-4 . . - . . x . . x Would be good if gnugo was included in .xo x2o-5 . . - . . x x x x Main activity tool bar too full, keep and stop icons end up in a hidden mini menu. Read-52 . . - . . x . . x Should default to setting input focus on the document, not in the toolbar. Geoquiz-3 . . - . x x x x x Would be nice if you could resume from where you last left off. Needs a winning screen with best times (auto quits currently). TurtleArt-10 . . - . . x . . x Memorize-28 . . . . * x . . x Game state is not saved to Journal, but can create custom tile sets and save separately to Journal. Xo IRC-4 . . - . x x x x x Perhaps remember open room tabs in Journal state, nickname and IRC logs as well? Analyze-5 . . - . x x x x x StarChart-4 . . - . . x x x x Model-8 . . - . * x . x . Stores incomplete diagram state to Journal. Terminal-18 . . - . x x x . x TamTamSynthLab-51 . . . . . x x . . TamTamMini-49 . . . . x x x . . Resuming does not restore the setting you were using during the previous session. TamTamJam-51 . . . . . x x . . TamTamEdit-50 . . . . . x . . . Pippy-27 . . . . . X . . . Easy to accidently wipe all your code by clicking on example code, no warning given. Measure-20 . . - . x x x . x Doesn't sleep when Activity is in the
Re: Another pass through some basic Activity test results
It seems that mangling occurred; however, I repaired it and have temporarily published the results here: http://teach.laptop.org/~mstone/gary.txt Michael ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Another pass through some basic Activity test results
Testing gg-763-1 earlier today, running a number of activities for an hour. I later found that I could not restart or reboot via sugar; it would let me select the option from the right menu, but then a gray-circle process appeared in the top frame and nothing would happen. If I quit that process and tried again, the same result. I haven't been able to reproduce on systems that haven't been using activities for a while. SJ On Thu, Sep 25, 2008 at 6:26 PM, Michael Stone [EMAIL PROTECTED] wrote: It seems that mangling occurred; however, I repaired it and have temporarily published the results here: http://teach.laptop.org/~mstone/gary.txt Michael ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
