Re: [sugar] Speech Synthesis Integration - User Interfaces and other Implementation Considerations
Hi Hemant, On 1 Mar 2008, at 17:48, Hemant Goyal wrote: > 4. Speak out a welcome message to the child when the XO boots up? > (Hello xyz welcome to sugar or something like that?) Playing with fire there - I think for a teacher with a class full of XOs the novelty will wear off pretty quick. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] storing Activity parameters
I'm having some indecision about my own (very simple) activity state saving. Just had a though that may add another possibility to this thread. What if both journal and file-system were used to store the activity state, with the journal settings overriding the file-system settings. This way a new activity start-up could inherit the last used activity settings, and a specific journal start-up would inherit the settings used for that specific entry. So in the case of Speak I could have separate favourite journal entries for '3 eyed alien' and another for 'Mr square eyes', then if I also just started the activity from fresh I'd pick-up whatever the last used setting were (picked up from the FS). My Moon activity isn't complicated enough (just 2 key/value pairs so far) to make this much of a time saver, but for my planned Earth activity (a port of EarthGlobe, a Mac desktop app I wrote a few years back), I'd want to make use of shared location tagging (basically lon/ lat markers attached to some metadata) and some more detailed custom user settings that a user would not want to make each time. So the more detailed user settings (default location, some basic info/notes, viewing preferences) would be best going to the FS, and any tagged locations would go to the journal (so you could have different sessions for making different sets of geotags). I guess in this Earth case though there is a more clear separation between settings, and activity data. You'd (likely) want just one set of global settings for your details, while using the journal to store separate sets of tags - though I guess if you change location frequently you might want a journal entry for each location* Hm *probably a low usage case for our target audience. On 2 Mar 2008, at 01:29, Joshua Minor wrote: > I implemented the save/load feature of Speak without fully > understanding the other options. Now that I've seen the recent > discussion about data vs instance vs the journal I think it would make > more sense to have Speak save its state in a different way. > > On the other hand, the new frame redesign makes it much easier to > resume an Activity, which would mean that parameters saved to the > Journal, like Speak does now, would naturally be restored when you > resume the Activity. > > A nice "best practices" document would be very handy. > > -josh ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Feedback item on new shell design (Make Journal integral to shell metaphor)
I added this last week to the wiki, but just thought I should mail this to the list incase no one is actually looking there :-) My input so far is the mock-up image and the text about making the Journal a core part of the shell metaphor, rather than the "I'm a non-standard super activity type thing" that we currently have – and look to still have in the new designs (BTW: I think the whole switch about for launching vs. already running is going to be a real usability improvement). http://wiki.laptop.org/go/Talk:Designs/Activity_Management I'm sure there have been design wars over this in the past, but I seem to have missed them... ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Installing new non-core designated activities
Hi List, I'm sure the sudden, poorly communicated, policy change regarding what is and isn't a default installed activity anymore (in build 696 and up) has given many developers/testers a very unpleasant surprise. What is the official method to re-installing these activities if we want to continue to test and work with the newer builds right now? And before any one say, "use browse, visit the activity page and click the .xo bundles you want", that's not an option for the majority of activities that just got dropped, as their developers probably didn't realise they were about to fall out the loop, there are no browser installable .xo files for most. The XO get, gui just hangs, so no luck there, and xoget command line only seems to work from the Terminal activity (which was dropped) as the hidden command prompt doesn't have the right environment (DBus complains about accessing X for some reason). Only other thing seems to check out the source on another machine using GIT, building your own .xo bundles, and hosting them somewhere browse can get to... Or are we all meant to start building our own auto package installer custom USB sticks? Hopefully I'm just missing something really obvious here. Thanks for any pointers, Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] icon assistance/validation
Hi Paul, Hmmm, maybe I should adding to the SVG pages of the wiki. I've gone through much the same as you however decided to take another route as I didn't want the bloat of Inkscape files. I'm using a Mac so your milage may vary: 1) Have a dig around http://dev.laptop.org/git?p=artwork;a=tree to get an idea of the existing sugar icons, or look inside the source directories of existing activities. Toolbar icons and activity icons are slightly different so look for an example you like of the right type. If your browser supports SVG (Safari does) you can view some directly, but most are set with a white ink, so will be invisible viewed directly. Just download the svg file, edit with a text editor (I use Xcode but anything with syntax colouring will be helpful) to change the colour and try viewing it in your web browser again. 2) Use the docs at http://www.w3.org/TR/SVG/index.html#minitoc You don't need to read it all, but having a shimmy through the examples in Basic Shapes, and Paths should get you upto speed with the required xml. Probably also worth taking a look at the Mask section later on as it's pretty handy for a whole bunch of techniques. 3) Start with a working example SVG, and code up your icon step by step, using your browser to view changes as you go. You should still test the SVG from time to time in Sugar, it helps to see the artwork in context along with other sugar icons. If you're using a browser to preview, remember to change the colours temporally so you can see what you're doing. Why do I like this approach? It keeps SVG files small and consistent with the Sugar fill/stroke requirements, and it forces you to design clean, simple and un-fussy icons. I used this approach for my Moon activity (activity icon and a couple of simple toolbar icons), and a full set of toolbar icons for the Calculate activity by Reinier Heeres, to replace the text he had been using. Gary On 12 Mar 2008, at 02:55, Paul Fox wrote: > so, in no particular order, are there any linux tools to: >- "sugar validate" an icon? i'm thinking of things like > making sure all strokes are the same, all fills are the > same (or unset), making sure that non-closed objects > don't have a fill set, etc. >- display sugary previews of the icon, in its various colored > and b/w renditions, and various sizes? >- automatically do the variable substitution required to make > fill_color and stroke_color "animatable"? ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] storing Activity parameters
On 3 Mar 2008, at 10:44, Tomeu Vizoso wrote:
> On Sun, Mar 2, 2008 at 1:51 PM, Gary C Martin <[EMAIL PROTECTED]>
> wrote:
>
>> What if both journal and file-system were used to store the
>> activity state, with the journal settings overriding the file-system
>> settings. This way a new activity start-up could inherit the last
>> used
>> activity settings, and a specific journal start-up would inherit the
>> settings used for that specific entry. So in the case of Speak I
>> could
>> have separate favourite journal entries for '3 eyed alien' and
>> another
>> for 'Mr square eyes', then if I also just started the activity from
>> fresh I'd pick-up whatever the last used setting were (picked up from
>> the FS).
>
> I like this idea a lot. Thanks for sharing.
I just wanted to follow up on this activity preference storage idea
from a few weeks ago, with some working code, as I've finally got
around to writing/testing and all appears to work well. Feedback
appreciated if I'm doing something dubious here. Activity defaults are
hard coded, then overwritten by a persistent file (if it exists), then
overwritten by a call to read_file (if the activity was started from
the journal):
class MyActivity(activity.Activity):
"""MyActivity main class."""
def __init__(self, handle):
activity.Activity.__init__(self, handle)
self._name = handle
self.set_title(_("MyActivity"))
# Defaults (Journal resume priority, default persistent file
secondary, fall-back hardcoded values)
self.preferenceOne = 'foo'
self.preferenceTwo = 'bar'
self.activityState = {}
self.activityState['preferenceOne'] = self.preferenceOne
self.activityState['preferenceTwo'] = self.preferenceTwo
self.parse_preferences(os.environ['SUGAR_ACTIVITY_ROOT'] +
'/data/
defaults')
#
# Rest of MyActivity init code
#
def parse_preferences(self, file_path):
"""Parse and set preference data from a given file."""
try:
f = file(file_path, 'r')
self.activityState = cPickle.load(f)
f.close()
if 'preferenceOne' in self.activityState.keys():
self. preferenceOne =
self.activityState['preferenceOne']
if 'preferenceTwo' in self.activityState.keys():
self. preferenceTwo =
self.activityState['preferenceTwo']
except:
print "preference data %s not available" % (file_path)
def read_file(self, file_path):
"""Read state from datastore."""
self.parse_preferences(file_path)
#
# Update state of MyActivity interface if necessary
#
def write_file(self, file_path):
"""Write state to journal datastore and to persistent file
system."""
self.activityState['preferenceOne'] = self. preferenceOne
self.activityState['preferenceTwo'] = self. preferenceTwo
toJournal = file(file_path, 'w')
cPickle.dump(self.activityState, toJournal)
toJournal.close()
toPersistentFs = file(os.environ['SUGAR_ACTIVITY_ROOT'] +
'/data/
defaults', 'w')
cPickle.dump(self.activityState, toPersistentFs)
toPersistentFs.close()
So... just to recap, when you first launch an activity, the hard coded
settings are used. If you make changes and exit, they become the new
defaults if you launch another. If you resume from a previous Journal
entry its settings are honoured (and will become the new defaults when
you exit). If your activity has lots of complicate preferences you
might want to provide an option for resetting preferences back to hard
coded defaults, but having lot's of complicated settings needing reset
suggests you might need to simplify things a little for the target
audience ;-)
If this looks like is might be useful/stable approach for some others
to use in activities, let me know and I'll find somewhere on the wiki
to document it more permanently.
G
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Update.1 activities download script
On 15 Mar 2008, at 00:34, Ixo X oxI wrote: > Another great program to use to install .xo bundles. is 'xo- > get'. Has > both a console/terminal and Sugar/GUI interface. > > http://wiki.laptop.org/go/Xo-get > > Currently under going testing, but pretty darn close with only a > handful of > 'un-documented features left'. :-) > > -iXo > > p.s xo-get also has one of the most extensive collections of > available .xo > activities to install . Yea, I use xo-get quite a bit previously very useful. However the GUI version has failed to work on any recent xo builds for quite some time (using a B4 here), and you do have to have already somehow installed a working terminal activity before you can use the command line version of xo-get, as it seems to have sugar dependancies that prevent it from running in the hidden command line. Maybe there are new versions that work under these situations? So not too great a fix just now for the activity bloodletting going on in the latest update-1 candidates ;-) G ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] storing Activity parameters
>> I just wanted to follow up on this activity preference storage idea >> from a few weeks ago, with some working code, as I've finally got >> around to writing/testing and all appears to work well. Feedback >> appreciated if I'm doing something dubious here. Activity defaults >> are >> hard coded, then overwritten by a persistent file (if it exists), >> then >> overwritten by a call to read_file (if the activity was started from >> the journal): >> > Yes, I like it a lot. Just would suggest using json instead of > cpickle. It should be as easy but would give you human readable files > that can also be read easily from other languages. > > Thanks, > > Tomeu Thanks Tomeu. OK. almost there with the json change (just need to test the changes properly). I must admit to just trusting your wise and noble intentions on this one ;-) json seems kind'a darkmatter from where I'm sitting, not standard in the official Python distributions (though it has been included in the default sugar python modules), close to zero useful documentation out there (other than a few pretty pictures) and few actual python examples (thank goodness for the ability to reverse engineer web activity and some rather obscure class docs in pydoc). I guess because it's so trivial to those who already use it, no one's written much about it (I think some wiki time is approaching). Probably an irrelevant change for my current usage, but may make sense if someone with larger, potentially valuable, data storage copies from my source. ~1hr less beer time tonight, I'm sure my liver will thank you later :-) G ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] icon assistance/validation
Hi Eben, While you at the wiki, could you make a distinction between activity icons (dual colour + transparency), and activity toolbar icons (1 colour plus transparency) – or maybe I'm wrong on the toolbar interpretation. I kinda get a little narky when I see toolbar icons with white fill and then cheat with some black stroke to try and fake some detail that should actually be transparency (should be a mask). Thanks, Gary On 17 Mar 2008, at 20:01, Eben Eliason wrote: > I'm attaching a new version of the script. Tomorrow I'll have a > chance to dive into the wiki, post it there, and add some examples and > guidelines. Please give me any feedback you have on your experiences > using it. The key changes in this new version are: > > - gracefully handles running the script on an icon multiple times > - adds stroke_opacity and fill_opacity entities, for potential future > use in sugar > - fixes a bug with the replacement of the default stroke color on > inkscape SVGs > - better feedback and error handling > > I look forward to hearing what everyone thinks! > > - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] icon assistance/validation
On 18 Mar 2008, at 14:40, Eben Eliason wrote: > Perhaps we could even remove "strokes in the fill color" from the > ruleset, as I don't believe I myself nor anyone else thus far has used > them. If I understand your description here, I'm pretty sure I'm using them to get crisp icon detail within the current design constraints – the effect in the home ring was particularly poor without, if I remember correctly (no doubt some other hack to get a strobe** working there): http://dev.laptop.org/git?p=activities/moon;a=tree;f=activity And I must admit I have the same concerns as Bert about using alpha on the vector artwork, I've seen a bunch folks do this in Flash UI's and effects, and they usually look like [EMAIL PROTECTED] on a stick. ** Much as I like a SMOOTH strobe effect, the XO as I understand it is really poor at transparency processing (HW can support it, but like so many things, the SW support isn't there yet). So it's slow to the point that the strobe effect had to be dialled down to the current jerky flick book effect, making the machine look even slower (though activities do launch slightly faster for the change). Is there perhaps a more efficient, less hacky way to provide a 'launching' visual metaphor (at least until sugar gets HW transparency and a compositing API). Is a simple blinking effect at 1 or 2Htz between un-launched and launched colours a possibility? Or is that too much like a potential activity attention/notification type effect (say a person joins a non- front chat session, or someone takes a new photo in a non-front shared record session)? > In that case, would you mind testing it out a bit (even should you > remain one who wants to create them by hand in the future), just so I > can get some practical feedback on the performance, robustness, and > usability of the tool? Thanks! I'll also take a look at some point, though so far I prefer hand coding these simple shapes given the design spec. I used to be a fan of Illustrator but it's just too expensive to justify unless you're a heavy user, and Inkscape is feature rich but is borderline too clunky and lumbering to work with. I'm sure I spotted, in some dusty part of the wiki, someone writing a simple SVG drawing activity – at the time I thought it was to aid drawing shapes for activity icons, but I may have misread. Any one know the status of it? G ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] icon assistance/validation
On 18 Mar 2008, at 20:13, Eben Eliason wrote: > I can remove the stroke-opacity altogether. As mentioned before, I > don't have any particular goal in mind with respect to that > property...I just implemented it at the same time as fill-opacity > because it was easy to add. I do want to keep the fill-opacity so we > can take advantage of it in the future, though. It is something that > may not be implemented immediately, but would make the code much > cleaner once we are able to support it. What would happen to overlapping fill areas if opacity starts getting fiddled with? My understanding is that the overlap areas will be additive and there for more opaque than non-overlapping areas leading to fuggly shapes appearing. Icon designers would need to always build all non trivial fill shapes out of little bits of non-overlapping primitives. That's quite a tall order. If there really is some great feature that needs alpha, can the SVG not just be rendered in to a pixbuff, and then the pixbuff be composited into a widget with alpha. This way the SVG is 'flattened' so that you can dial up/down the transparency across the whole image without fuggly bits appearing. I'm currently using transparency like this in moon activity – I just happen to be starting with a jpg image (that I need transparency effects on), rather than an SVG resource. I then do some compositing to form the dark and light sides of the Lunar phase, out of one full bright jpg image. Now it's not too quick on XO hardware (about 1sec all said and done), but then again it is a 726x726px image going through several alpha/masking composite stages, you should be able to composite 55x55px oooh ~170 times faster. It's currently all pure GTK+ at the moment, but planning a move to Cairo for more transparency control (would like soft shadows at least) and perhaps better performance. Do you want me to make a pulsing SVG like this as a little test activity? See what the load is like or if there are technical bumps preventing it? Regards, G ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] icon assistance/validation
On 18 Mar 2008, at 18:20, Eben Eliason wrote: >> ** Much as I like a SMOOTH strobe effect, the XO as I understand it >> is >> really poor at transparency processing (HW can support it, but like >> so >> many things, the SW support isn't there yet). So it's slow to the >> point that the strobe effect had to be dialled down to the current >> jerky flick book effect, making the machine look even slower (though >> activities do launch slightly faster for the change). Is there >> perhaps >> a more efficient, less hacky way to provide a 'launching' visual >> metaphor (at least until sugar gets HW transparency and a compositing >> API). Is a simple blinking effect at 1 or 2Htz between un-launched >> and >> launched colours a possibility? Or is that too much like a potential >> activity attention/notification type effect (say a person joins a >> non- >> front chat session, or someone takes a new photo in a non-front >> shared >> record session)? > > Valid concerns. This is mostly a subjective decision. Mostly, we > designers refuse to believe that we can't find an efficient way to > pulse a 55px square...and so we haven't given up hope there yet. Not that I'm an expert on X windows and GTK+, but working on moon activity I got the distinct impression that the views were all using allocated colour palettes (a blast from the past to the days before we all had 24bit colour displays). Could an old school colour cycle effect be used for a cpu efficient pulse (though that would make transparency a no go area, and you'd need to cycle you antialiased colours also)? G ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] icon assistance/validation
On 19 Mar 2008, at 03:19, Eben Eliason wrote: > I suppose, however, that you could easily use > the entities to paint strokes white and fills black, render it to a > pixbuff, > and apply it as a mask to a solid of the desired color. That would > certainly do the right thing. Yep. > Of course, in order for this to serve the purpose we're after, you > have to > be able to create the pixbuff with the fill at various levels of > gray, and > treat the result as a true alpha channel, and not as a bitmask. If > you want > to take a stab at this approach, feel free. I'll take a look later tomorrow pm and see how far I get. Just to confirm, I'll take an activity SVG icon and create an image with alpha chanel, containing just the icon stroke details... and fills that are in stroke colour, and not strokes that are in fill colour – happy, happy, joy, joy :-) Now do you want the transparency to strobe with a fixed colour, or do you want a fixed transparency (say 30%) with a colour strobe (black to white ping-pong)? Regards, G ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] icon assistance/validation
Hi Eben, Quick question. What are you needing to composite the SVG over? Just a solid colour of some kind (frame grey), or is it more complicated than that? Just that in my test code I'm currently erasing the base Pixmap before each alpha Pixbuf composite of the SVG, and I suddenly wondered if i needed to buffer the original background content before I start messing with it. FYI: My current alpha strobe loading for a 55x55 px SVG on XO hardware is: @ 100ms (10fps), about +9% to X process @ 50ms (20fps), about +19% to X process @ 33ms (30fps), about +17% to X process** @ 10ms (100fps), about +37% to X process ** wierd, it was actually slightly faster at 30fps than 20fps, perhaps a screen refresh side-effect? Maybe worth graphing across a finer range of frequencies to see if there is a sweet spot somewhere. Gary On 19 Mar 2008, at 12:56, Eben Eliason wrote: >> >> colour – happy, happy, joy, joy :-) Now do you want the transparency >> to strobe with a fixed colour, or do you want a fixed transparency >> (say 30%) with a colour strobe (black to white ping-pong)? >> > > The former. I look forward to hearing your results, > > - Eben ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)
On 25 Mar 2008, at 15:47, Eben Eliason wrote: > Taking these concerns to heart, I'd like to propose an alternate to > the tabbed toolbar design which attempts to address these new concerns > with the current design, again making some tradeoffs but hopefully > coming out on top in the end. The core component of the new approach > is the introduction of the "toolbar button", which you can see mockups > of at http://wiki.laptop.org/go/Designs/Toolbars. There is no text > with the mockups yet, but I'll add it later. In the meantime, please > consider the following advantages: Yes, I do like the idea a lot. The main issue I see not covered in your list (and it's quite a whopper), is that the extra tool-bar strip shifts the top of the main activity canvas down, resizing it in the process. Problems: 1) As you mouse over, the main canvas content will jerk up and down like a pneumatic road drill. 2) The window resize is going to trigger the contained widgets to redraw/re-scale/re-align. This may be fine for a trivial activity with minimal UI complexity, but if any of those widgets require some processing to regenerate their visual appearance or content flow... ouch. 3) Activity developers should already be using flexible layouts to cope with potential screen rotations, however the added potential for a reduction in main canvas size will add to the UI design/testing complexity, with designers making a little less use of the space by default so they leave some vertical space to prevent things getting cropped. Can't see a practical solution to this just now, the only other option seems to be to have the revealed tool-bar strip appear over the activity, but that would cause even more UI issues as parts of activity real-estate get obscured. I guess (1) is the UI design flaw, (2) and (3) are technical issues that would need to be resolved and/or require developers to redesign their activities (other than just adding some pretty SVGs to their old tabs). Regards, Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Choosing "defaults" for the activity ring
Hi Eben, On 4 Apr 2008, at 17:46, Eben Eliason wrote: > We'd like some > feedback on which perspective is the most rational so we can implement > the solution as soon as possible to prevent the "empty ring" > phenomenon. Another slightly different option for a 'fallback' mode – for when no favourites have been set – could be simply to default the home view to the list mode when no favourite activities are set. It would also be good if the 'favourites activities appear in ring mode' concept were a little more visually discoverable. I guess either the ring view frog's egg icon could be more favourite icon like (perhaps circle with are small star inside?). Or the frog's egg ring view icon could be used instead of the favourite star icon used in list view (make 'add to ring' the explicit function). Also a few quick misc. observations: - The ring of activities appears vertically unbalanced with the XO + activity icon. Lot's of white space above the XO, cramped space below. Potential improvement would be to move the XO and activity icon up by 50% height of the below activity icon. Would likely need a similar small upward shift to the other two zoom mode XO icons so they align when switching zoom views. - I vote for making the ring activity icons much larger when they are few in number. Start with them really rather large (and with a larger starting radius circle layout). Icons scale down as number increases, as you have already. Might as well use that screen space, and make the click targets as large as is within reason, given all the feedback about twitchy track pads and lack of fine motor control for young kids. - When in Neighbourhood, Group, or Home view, the new frame activity icon for the current activity is no longer clickable (you can't click it to switch back from a zoom view). Feels like a bug or omission rather than intention, though this does make the Activity zoom level frame icon feel almost redundant now. Just thinking out loud, it is really nice to see the Sugar UI moving onwards! Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] XO experience in the classroom - Carol Lerche's daughter
On 5 Apr 2008, at 03:18, Carol Lerche wrote: > They were so excited when they went to use > them, they couldn't wait until they started up to start pressing all > the > buttons. Each group had four kids at a time, and my mom was constantly > supervising them so if they had any problems, she could > troubleshoot. Which > happened quite a lot, as they are very impatient. Their main problem > was > that they didn't want to wait for the programs to come up; when it > didn't > pop up immediately, they would click on something else to try it, > which of > course made it start even slower, and so they got very frustrated > and my mom > had to close out everything before they would be able to try again. Thanks for taking the time to write this up Robin – I've heard very little front line feedback like this so far so it's great to read. So... a suggestion to improve the new Sugar UI launching behaviour: When an activity is launched, immediately take over the full display with 'fake' activity placeholder, while the real activity is launched. The display would be a plain white (or black maybe), with a large, pulsing icon for the activity in its centre (large XO icon size as you're now at a close-up activity zoom level). No other buttons immediately visible to click, though the frame would continue to be accessible if a user really needed to switch away and do something else. If we do get to have an efficient compositor at some point, sugar could do a lovely icon zoom transition, from where ever it had been launched from, to the large centred display, and fade out the rest of the display content. Think that extra eye candy can wait a while for now though ;-) Regards, Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Choosing "defaults" for the activity ring
Hi Eben, On 5 Apr 2008, at 07:16, Eben Eliason wrote: >> Another slightly different option for a 'fallback' mode – for when no >> favourites have been set – could be simply to default the home view >> to the >> list mode when no favourite activities are set. It would also be >> good if the > > I personally feel that the ring view will be both a friendlier > interface, as well as a more welcoming one for kids just starting out. > Additionally, I absolutlely want to make sure that the XO remains in > the center up front, since this is the first thing a child will see > when booting her laptop for the first time. > > Additionally, I anticipate that having both starred and unstarred > activities to begin with may help make the favorites system easier to > grasp. Empty views are often confusing. Yes, I agree about the ring view being potentially more welcoming – this was just a fallback suggestion so that no one would ever be presented with a blank home – some decision on default favourites during updates/installs would be needed. Talking of favourite defaults, why not have all activities initially installed, or manually installed, appear as favourites by default. If I went to browse and downloaded an .xo or .xo pack, I'd definitely expect to see the home ring updated with the new downloads. Regards, Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Copy/Paste icon colour (Re: A Sugar TODO List, of Sorts)
On 7 Apr 2008, at 20:00, Tomeu Vizoso wrote: >> • Color copy/paste buttons in activities > Which colors should take? Just the local colors? I've always been unclear about the purpose of this, and have not seen an explanation – always thought the coloured icon looked out of place in the toolbar. Anyone know the reason/metaphor that makes colouring it so important? Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Mini-Conference Proposal: Toolbars & Tabs (or lack thereof)
On 5 Apr 2008, at 16:44, Tomeu Vizoso wrote: > What if on rollover would appear a normal palette with all the buttons > that would be in the subtoolbar? This palette would have an option for > pinning it, and that would mean inserting a subtoolbar between the > toolbar and the canvas like in the mockups. > > Benefits: > > - palettes don't disturb the layout of the underlying window, > - existing UI component, > - buttons are grouped closer to the main button, requiring less > mouse travel, > - buttons are in an area not as thin, making easier to move the mouse > without going out (thus hiding the palette), > - we could keep the toolbar label. > > Thoughts? Hmmm, a regular palette pop-up will often end up being way too tall, with the (usual) screen orientation a full row of buttons would not fit. And it gets messy when the buttons are not simple square icons, say like in Write where font size is represented by two element (an icon and a pop-up size list), or the font family picker (a wide pop-up text list). Trying to arrange these vertically in a pallet is going to fill up a good chunk of the display with mainly empty black space padding. After much musing, I think Eben's designs at http://wiki.laptop.org/go/Designs/Toolbars are a good compromise, but they would need to (as mentioned by another list member): A) On mouse hover over a tab button, float the new toolbar over the existing activity canvas (obscuring some content), and not moving/ resizing the activity canvas area. B) A click on a tab icon would lock it in place (pinning), and than cause the main canvas to reflow/resize. Sub toolbar buttons still get to have their mouse over textual hints, but the top level tab buttons have none – I know this is an issue for some folks... I guess, and it's a flakey guess, with the above A&B alteration, you could; during hover state A, show an extra horizontal strip with the tab name below the new toolbar strip; then after click state B, you'd just insert the new toolbar strip and loose the extra text row to save space. Does anyone build working prototypes of these kind'a interactions? makes all the difference (usually a pretty instant, yuck or fine reaction). Would be quick to do, Eben is that me I hear you volunteering?? Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Clipboard Notification
On 14 Apr 2008, at 15:04, Mikus Grinbergs wrote: > Personal note: Been running the "new look" Sugar/Joyride for a > while. [It does what you describe when an Activity is launched.] > > I've now trained myself to notice the pulsing icon in the top left > hand corner -- but I think that is an easily-overlooked location > (particularly since current notification icons have the same > background color as the "border" in which they sit). I also find the new 'activity launch notification' less than satisfying. Launching an activity is a very distinct action taken by a user, and the current pulsing notification is not enough of an indication of the result. It's also odd if you do happen to have the frame open as you see 2 pulsing icons for the launching activity (one the notification and one in the actual frame). I'd like to suggest, again, that the activity launching metaphor be one where: 1) Kid clicks on activity icon to launch 2) Sugar immediately opens a fullscreen canvas with just the large pulsing icon (i.e a activity zoom view) 3) Canvas is occupied by the activity once it has loaded This provides: - immediate and clear feedback to the kid that an activity is indeed launching - prevents casual/impatient clicks on other activity icons while the first loads - allows access to the frame, and for the kid to switch back to neighbourhood/group/home if needed - if the kid does intentionally switch away, the background activity launch does not suddenly drag them back once complete - the slide out launch notification is not needed, but the pulsing frame activity icon would stay If at some future point we get usable Sugar compositing, a nice zoom animation could be added to the launched activity so that from where ever it was clicked, it scales up and into the centre of the screen and starts to pulse, while the rest of the screen content fades out. Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] VoiceThreads ... a very interesting education service
Wow, thanks for posting that link – what a lovely site. It actually already feels pretty close to a possible Sugar activity, and would fit right in with the XO's hardware features. Actually, I think Record is already pretty close to a whole bunch of these features** with its shared and annotated images/audio/movies, it could be used in a similar way***. ** except for the (my opinion) design flaw where you can't share existing recordings, only ones you record after someone else joins a shared session – so no point taking a bunch of photos of things and then clicking share – no one sees anything. For a test, a while back, I set up a Record session, named it 'View out your window', took a couple of photos, and turned sharing on. A bunch of folks joined over an hour or so and left photos of their view, but they couldn't see my photos, and I could only see a thumbnail of their photos (gave a network time-out error if I tried to click a thumb). Still a fascinating exercise even if it didn't quite go to plan (showed the potential). *** If you could resume a pre-recorded Record activity *AND* then share it out, it could be a good way to do photo journal type homework or research. Perhaps needs a better playback mode (text notes and images shown at once; ability to reorder the items in the bottom pane; ability to take a photo, then record audio associated with it). Maybe if Journal item sharing arrives as some point, this will be a practical way of generating and sharing similar content. Gary On 16 Apr 2008, at 03:00, Carol Lerche wrote: > http://voicethread.com/ > > Check out the educational community...http://ed.voicethread.com/ It > is > described in their blog link. There ought to be synergy here, or at > least > we could learn from what they are doing and create an open version, > if they > aren't interested in collaboration. The UI seems to fall into the > request > made for blogging software in a sideways kind of way. Wouldn't it > be neat > to collaborate either just with XOs or on the school server with a > function > like this? > > Carol Lerche > ___ > Devel mailing list > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Copy/Paste icon colour (Re: A Sugar TODO List, of Sorts)
On 22 Apr 2008, at 17:56, Eben Eliason wrote: > On Mon, Apr 7, 2008 at 10:47 PM, Gary C Martin > <[EMAIL PROTECTED]> wrote: >> On 7 Apr 2008, at 20:00, Tomeu Vizoso wrote: >> >>>> • Color copy/paste buttons in activities >>> Which colors should take? Just the local colors? >> >> I've always been unclear about the purpose of this, and have not seen >> an explanation – always thought the coloured icon looked out of place >> in the toolbar. Anyone know the reason/metaphor that makes colouring >> it so important? > > When a clipping is made, it appears in the Frame as an icon, rendered > in a specific XO color pair. Having clippings in various colors can > help to make the clipboard a bit more engaging, and aid in identifying > the correct one in the absence of (much needed) previews. The basic > approach to coloring would be to color the copy button in the color of > the activity it resides in, and color the paste button the color of > the currently selected clipping in the Frame. > > However, the greater potential is reached when activities support it > directly. For instance, the Record activity might turn the copy > button to the colors of the currently selected photo. Should the > Write activity ever keep track of exactly who wrote what, it could > color the icon the colors of the person who wrote the selected block > of text. In the case of a "multiple selection", the colors would > revert back to those of the activity. It might also be useful to > return the button to white when there is no selection at all... H, you haven't really sold me the real end utility for all the effort needed to make that feature work reliably :-) It would need to be consistent across all activities to be discoverable, and even then perhaps 90%+ of the time the clipping will default to your local XO colour. So – just to check I understand – if I join a record activity with 2 others, the activity icon I see will be the colour of whoever's XO started the activity; copy will be the colour of whoever's media I currently have selected; and paste would be the colour of the last clipping made. If the plan was to also support sharable** clippings, I would understand the extra need for colorising – but that's probably just another feature to slow down other much more critical dev work. **hovering over a clipping could reveal an option for "share with..." could act as a way to transfer all kinds of things depending on what Sugar allowed you to clip (perhaps even an activity or an activity bundle from the Journal***). ***question, will .xo bundles continue to appear in the new Journal Design like they used to (always though that looked a little messy), or will downloaded .xo bundles only appear in the Home view ring/list? - Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] On improving Sugar performance
First, thanks Tomeu (and others involved), that's a fab list that may be coming down the pipe. I'd followed some of those items through joyride, but others were silent runners for me. Great to hear about them! On 28 Apr 2008, at 17:09, Tomeu Vizoso wrote: >> Anyone is of course welcome to join us with questions, answers and >> proposals. To keep the discussion relaxed, we do not require backing >> each and every idea with benchmark results, which in some cases are >> hard to obtain. Nevertheless, measuring is a useful tool, especially >> when there there's disagreement on how effective each solution >> might be. > > Sure, but rather than a useful tool, I would call measuring as the > only possible base on which decide actual work that needs to be done. > We could be refactoring and recoding for years and don't get any > noticeable improvement, if we don't measure. Not that I want to start a CS grad war here, but with more than one foot in the UI camp, I just wanted to request that more than just 'clock watching' is done when selecting/implementing optomisations – though 'clock watching' is a very good place to start. http://www.codinghorror.com/blog/archives/001058.html Catering for subjective human response is tricky, but once you've passed some minimum threshold for utility** you can often win more hearts and minds going for the subjective. A concrete example I'd point to is smooth animation; activity switching with no nasty redraw flicker; pulsing icons with no visible strobe; and frame/notification transitions that glide smoothly onto the display giving the illusion of effortlessness. **how many hours must I have spent as a kid, excitedly waiting for some software to load up off a magnetic tape, only to have it fail a fair portion of the time and have to start the tape over again... and some folks here moan about a ~6sec launch time for an activity. Though it's true to argue that those old machines did have instant on, even if you were left to ponder a BASIC prompt and spend the next 5min trying to tune your TV in to get a clear signal :-) - Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On 1 May 2008, at 16:24, Albert Cahalan wrote: > For other reasons (GUI complexity and the OOM killer), the ability > to launch multiple activities should be disabled by default. Do you mean 2+ instances of one activity, or multiple activities? I do agree that UIs that support multiple activities (and switching) will be more complex than one that is completely modal. The iPhone and iPod Touch are the best current examples I can think of, though they clearly have some areas still to solve in terms of using several applications together to achieve something no single one could alone. Current lack of Copy/Paste is a well cited complaint (but I can see Apple solving/fixing that at some point, at least I hope so). There's also the whole conversation going on about will Apple allow developers to create background applications. These devices are currently more about accessing than creating, the XO is about creating and accessing – I think that changes the UI game enough to warrant activity instance switching. Preventing multiple activities on the XO would be too extreme, I think, though it would be the next logical step down for UI simplification. For the younger end of the target audience I can see this being a positive (an assumption, I have no proof), but it would reduce the utility of the XO over a range of learning usage scenarios for everyone else. You loose much of the combinatorial effect of using several activities to achieve an end goal – can you imaging trying to write homework that need a photo added, images from the web, reading a pdf with the homework assignment/questions, or how an invitation to participative in another's activity would be very disruptive (say a friend wanted to use chat and ask you something about the homework assignment you were doing). Preventing 2+ instances of the same activity would be less disruptive, but would not solve kids launching multiple other activities as they click about with the interface. Devils advocate: Now if activity launch + state restoration, and activity closing + state saving, was as fast as iPhone/iPod Touch, then my opinion could** start to swing in favour of a UI that presented a, one activity running at a time, view. You wouldn't so much quit an activity, as return to the Home view. Switching via the frame would be gone, you'd just return to the Home view. ** I say 'could' because some actions that require two or more activities to complete would still be sub optimal relative to a UI that allowed instant switching between running instances (example, trying writing an essay about a Shakespeare play you have in pdf format, lot's of back and forwards referencing and copy/paste). --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] perceived sugar performance
On 2 May 2008, at 10:57, Samuel Klein wrote: > SJ, > who still wants the "hand" buttons to be mapped to the right and left > mouse-clicks in addition to any other keymapping. Sorry, not me – I **really** want the hand keys implemented with the original intended scrolling behaviour. Perhaps once the Sugar GUI control panel is fully implemented you could submit a patch for this as an alternate behaviour. I do agree that the current 2 trackpad buttons** are less than great, but easy scrolling/panning of documents is a bigger win I think especially given the jumpy trackpad issues. Perhaps for XO-2 hardware the trackpad buttons could be dropped and replaced with new real keys? I find I usually need to use two hands already with the current set- up, especially for drag'n'drop operations, or when testing paint type 'hold the button down and move at the same time'. Maybe it's just my adult size hands/fingers, would be good to get some real kids feedback here from some of the live sites – but I'm guessing kids are having the same problem as me. ** what was the decision behind having 2 buttons considering the available physical space and additional UI complexity? It's not like there are legacy educational applications that require 2 buttons. Regards, G ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] An OLPC Development Model
On 9 May 2008, at 00:42, Samuel Klein wrote: > On Thu, May 8, 2008 at 11:55 AM, C. Scott Ananian > >> ps. SJ, there are no 'core activities' that we ship. There is only >> one security-privileged activity (Journal), which we currently ship >> in the >> core build because (a) Sugar breaks otherwise, and (b) Rainbow's >> activity-signing stuff is incomplete. I hope we can fix both of >> these >> in time, and stabilize the APIs enough that we can eventually >> unbundle even >> Journal. > H, sorry, run that past me again. I thought the intention was that the Journal was an integral part of the Sugar UI, and the plan was that the Journal code was going to be integrated to the Sugar Shell for (I think) security and performance – or did the world just turn around yet again while I was looking the other way? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] (Incomplete) Activity Launch Feedback
Hi Eben/Tomeu, On 18 May 2008, at 15:37, Eben Eliason wrote: > Attached,with launchbox.py included. > > - Eben I'm trying to apply you patch directly to an Xo with joyride 1946 (I don't have access to any other build environment so my tests are limited to patching an Xo B4). The patch seems to be mainly happy, except a few of failed hunks in model/homemodel.py and view/frame/ activitiestray.py. Now I'm pretty sure you don't work on like this on an Xo, but any suggestions? I didn't notice any relevant changes between joyride 1946 and the most recent 1950, or have I misunderstood the source stream you guys work from? Is the git source and a custom Fedora build server the only way to be involved? I'm hoping it's just that joyride has got a little behind the git source due to the current missing builds due to disk space. Thanks for any help.. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Report on OLPC in Ethiopia
Hi Yamandu, I fed this into my self organising map (SOM) code. Here's the summary map generated for the report content: http://garycmartin.com/som/ethiopiareport_080227a-mh.jpg Oh, I was asked for a legend (on another list): http://garycmartin.com/som/SOM_legend.jpg --Gary On 9 May 2008, at 19:34, Yamandu Ploskonka wrote: > AFAIK this is the first published report in a format somewhat akin to > what people want to see when they ask for documented proof on how OLPC > is actually operating in the field. I contrast that to blogs and PR > efforts around the day of distribution of XOs. > > http://www.eduvision.ch/en/meta/documents/ethiopiareport_080227a- > mh.pdf > > The producer is a for-profit (?) consulting firm in Switzerland. > > Ed Cherlin has mentioned he has access to some other unpublished > reports > that might give a more complete picture > > Yama > ___ > 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] Report on OLPC in Ethiopia
On 20 May 2008, at 08:46, Tomeu Vizoso wrote: > what about stemming the words? You may be able to use an english > stemmer from xapian using the python bindings (not sure though). Thanks Tomeu, Yes, I was doing some very rudimentary stemming in my text parsing for specific cases, but I was still undecided as some of the other texts I've mapped have interesting usage patterns with the stems left as is. I've just had a quick google and found the standard Porter Stemming Algorithm written in Python by Vivake Gupta, I'll plug it in and see how it goes – mail list and wiki type texts are probably less 'edited' and more noisy than the other texts I've been experimenting with :-) --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Journal 89 released
On 21 May 2008, at 21:11, Bert Freudenberg wrote: > On 21.05.2008, at 20:23, Tomeu Vizoso wrote: > >> Hi, >> >> a new version of the journal has been released: >> >> http://dev.laptop.org/pub/sugar/sources/journal-activity/journal-activity-89.tar.bz2 > > Looks like I missed a change in development policy again. So > activities are now released as tar.bz2 on some web page? > > - Bert - :-) Well seeing that the blasted joyride and faster builds have been off air now almost a week!!! Thank goodness I say (thanks Tomeu, I rsynch'ed the changes to my Xo B4 to have a test). --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Browse v86 rainbow issue on update 1-706?
On 28 May 2008, at 05:18, Michael Stone wrote: > build 706 (which everyone ought to > test; olpc-update -f update.1-706) Hi Michael, Just a quick heads up. Just did an insecure usb update on an XO B4 (the olpc-update command is not usually reliable enough for me). I notice that Browse (v86) is failing to launch, though (a random selection of) other activities seem to run fine so far. Looking at the log for Web activity seems to point to rainbow/service.py, but it's hard to tell as the log is mainly full of junk console formatting characters/escape codes. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Browse v86 rainbow issue on update 1-706?
On 28 May 2008, at 18:55, Martin Dengler wrote: > - original message - >> Subject: Browse v86 rainbow issue on update 1-706? >> From: Gary C Martin <[EMAIL PROTECTED]> >> Date:2008-05-28 17:42 >> Looking at the >> log for Web activity seems to point to rainbow/service.py, but it's >> hard to tell as the log is mainly full of junk console formatting >> characters/escape codes. > > Is this rainbow racing with X, or is that in joyride only? Sorry, not sure. I'm back on joyride now and Browse seems quite happy there. > If I cat rather than more the logs the formatting gets in the way > less. Thanks for the tip, I usually just use the Log viewer activity. I'll go try cat next time I see crufty log content. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Browse v86 rainbow issue on update 1-706?
On 29 May 2008, at 03:58, Martin Dengler wrote:
> On Thu, May 29, 2008 at 03:42:55AM +0100, Gary C Martin wrote:
>> On 28 May 2008, at 18:55, Martin Dengler wrote:
>>> Is this rainbow racing with X, or is that in joyride only?
>>
>> Sorry, not sure. I'm back on joyride now and Browse seems quite happy
>> there.
>
> I was away from the web earlier and couldn't look up the trac for what
> I was referring to: http://dev.laptop.org/ticket/6797 (in case it
> happens again).
Martin, thanks for your suggestion.
OK, I've just gone back and re-installed 706 again on the B4 I have
here to give this another try.
Browse v86 is still failing to launch after repeated reboots. I've
added the content of its log file to the end of this email. BTW: using
cat on the file was a good hint as you get to see its content color
coded, pity Log activity doesn't interpret them the same way (Log
shows all the nasty console escape codes).
No idea if "rainbow racing with X" was a red-herring or not, ticket
6797 didn't say what to expect to see from such a condition, or how to
test for it. Seeing as Browse consistently fails to launch, a race
condition seems less plausible to me, I'd expect a race condition to
occasionally have a different outcome.
Couple of quick notes/questions:
1) Who is 706 actually targeted at? G1G1? One of the country installs?
I can't find any public description of who this is meant for, or what
set of base activities to test against. No reference to 706 on the
wiki or where to post test results (hence me blindly emailing the list).
2) Could someone clarify version naming. Is the 706 build leading to
"update-1.1" and how does this tie in with the upstream 81.x and 82.x
work from the SugarLabs side? Does the roadmap at http://dev.laptop.org/roadmap
still have any worth? It seems a fairly random collection of slipped
dates and misc features these days.
3) Did update-1 ever formally happen? It never seemed to get
announced, there was a request for testing 703, and then it all went
quiet.
Apologies if I'm raining on someone's parade here.
--Gary
P.S. Here's the failed WebActivity log for 706:
groupadd: group 10001 exists
useradd: warning: the home directory already exists.
Not copying any file from skel directory into it.
---
Traceback (most recent call
last)
/usr/lib/python2.5/site-packages/rainbow/service.py in
CreateActivity(self=,
log_path=dbus.UTF8String('/home/olpc/.sugar/default/logs/
org.laptop.WebActivity-1.log'),
env=dbus.Dictionary({dbus.UTF8String('LANG'):
dbus.U...c/.Xauthority')}, signature=dbus.Signature('ss')),
argv=dbus.Array([dbus.UTF8String('sugar-activity'),
d...f6c06344ec478b')], signature=dbus.Signature('s')),
bundle_path=dbus.UTF8String('/home/olpc/Activities/Web.activity'),
bundle_id=dbus.UTF8String('org.laptop.WebActivity'),
success_cont= at 0x82fef7c>, error_cont= at 0x82fefb4>)
58 ret = inject.run(log, SPOOL, env, argv,
env['SUGAR_BUNDLE_PATH'], (1, 2),
59 env.get('RAINBOW_STRACE_LOG'),
500, 500, bundle_path, bundle_id,
---> 60 env.get('RAINBOW_CONSTANT_UID'))
env.get =
61 except Exception, e:
62 util.trace()
/usr/lib/python2.5/site-packages/rainbow/inject.py in
run(log=, spool='/home/olpc/isolation/1',
env=dbus.Dictionary({dbus.UTF8String('LANG'):
dbus.U...c/.Xauthority')}, signature=dbus.Signature('ss')),
argv=dbus.Array([dbus.UTF8String('sugar-activity'),
d...f6c06344ec478b')], signature=dbus.Signature('s')),
cwd=dbus.UTF8String('/home/olpc/Activities/Web.activity'),
safe_fds=(1, 2), strace_hint=None, owner_uid=500, owner_gid=500,
bundle_path=dbus.UTF8String('/home/olpc/Activities/Web.activity'),
bundle_id=dbus.UTF8String('org.laptop.WebActivity'),
constant_uid=dbus.UTF8String('yes'))
267 check_home_dirs(uid, gid, home)
268 check_home_dirs(owner_uid, owner_gid, home)
--> 269 check_home(uid, gid, home)
global check_home =
uid = 10001
gid = 10001
home = '/home/olpc/isolation/1/uid_to_home_dir/10001'
270 check_bundle_path(uid, gid, bundle_path)
271
/usr/lib/python2.5/site-packages/rainbow/inject.py in
check_home(uid=10001, gid=10001, home='/home/olpc/isolation/1/
uid_to_home_dir/10001')
246 ck = Checker(home, uid, gid)
247 assert ck.positive(R_OK | X_OK, S_IFDIR)
--> 248 assert ck.negative(W_OK, 0)
ck.negative = >
global W_OK = 2
249
250 def run(log, spool, env, argv, cwd, safe_fds, strace_hint,
:
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame activation
On 10 Jun 2008, at 11:15, Tomeu Vizoso wrote: > do we have any feedback regarding frame activation and the new control > panel option? > > Is it ok to ship with hot corners on by default and let the users > change it if they wish? Have settled for about 500ms for the corners. I found warm edges too obtrusive even with a max delay, specifically scroll bar interaction was the main false activation. I could see me enabling specific warm edges (top being most useful). OT: Also trying to keep in the back of my mind a possible future UI metaphor where the whole input may be touch screen based, but as a well known tech put it recently, most existing UI's with a touch input layer added are like lipstick on a pig. It'll need to be an extensive redesign at that stage (sorry Eben). I guess Apple with their UI fork have more than a clue for us here. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Graphical Sugar Control Panel
On 10 Jul 2008, at 17:39, Simon Schampijer wrote: > Chris Ball wrote: >> Hi Greg, >> >>> I'm looking for a list of what can be set in it and any screen >>> shots or other background on what it provides for end users. >> >> Have you considered running it? It's been in Joyride for a few >> weeks. >> That's no good if you want formal documentation, of course, but it >> would answer your questions about what's there. >> >> - Chris. > > I put on my todo list to extend the wiki pages. Just added screen shots of all the current Joyride control panels, hope that helps. http://wiki.laptop.org/go/Release_Notes/8.2.0#Graphical_Sugar_Control_Panel --Gary ___ 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] Activity versioning schema
On 15 Jul 2008, at 20:15, Eben Eliason wrote: > On Tue, Jul 15, 2008 at 2:57 PM, C. Scott Ananian > <[EMAIL PROTECTED]> wrote: > >> 2008/7/15 Jameson Chema Quinn <[EMAIL PROTECTED]>: >>> If you have a better idea of how Glucose should handle these issues, >> please >>> share it. Simplifying assumptions are good, even if they're not 100% >> valid. >> >> Versions in activity.info files are either plain integers, or >> RPM-standard version strings, with no pretense that these correspond >> in any way to sugar major releases or anything at all, except that >> they are ordered: if the activity updater sees that you have version >> N, and there is a version M announced[*] as compatible with your >> build >> where M > N, then it will suggest that you upgrade to M. All other >> meanings are encoded with other mechanisms. >> --scott >> > > How can you argue this and still argue that we can get away with > integer > version numbers? According to this logic, a when brand new > activity(x) for > OS(y) is released at time (t) and a bugfix activity(x+1) for OS(y-1) > is > released at time (t+1), anyone on OS(y) is going to try to update to > the > "newer", larger, activity(x+1) version, with none of the new features. Random thought, should there be an additional .info line in addition to version, related just to release build compatibility? Version (activity_version) is just some sortable entity to be agreed, integer is fine with me (indicating the developers best and shiniest release effort to date). A new .info entry for release compatibility would be added (release_version) holding the Sugar version last tested against. Sugar auto updaters would assume compatibility based on >= release_version. Release_versions could be (more) easily extracted for auto update scripts (control panel) so as to download the best and latest compatible code. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity versioning schema
On 16 Jul 2008, at 00:03, Martin Langhoff wrote: > On Wed, Jul 16, 2008 at 10:51 AM, Gary C Martin > <[EMAIL PROTECTED]> wrote: >> Version (activity_version) is just some sortable entity to be agreed > > Please do read back on this - now lenghty - discussion. Unfortunately, > any monotonically increasing version does _not_ work, thanks to the > magic of maintenance releases. Let us bow collectively to the wisdom > of distro maintainers who are smart and have been doing this job for > far longer than us. > > In other words, let us do the same thing that rpm and dpkg do. > > It gives you both more expressive power, and a stupid "1.1.0.9z is > older than 2.0-alpha" cmp function for whenever you need it. OK, sorry, I've clearly accidentally wandered in to a room full of hardcore gun toting bit heads – I'm now backing slowly towards the exit, my hands clearly raised. Please do be sure to post whatever (I'm sure excellent) final outcome is, clearly and somewhere public (perhaps http://wiki.laptop.org/go/Activity_bundles *** would be a start), so us external activity developers don't have to be part of this bit punk talk. *** Salient quotes: "Each activity.info file must have a "activity_version" key. The version is a single positive integer. Larger versions are considered "newer". The value assigned to this key should be considered opaque to the activity; the only requirement of the activity is that it must be larger for new activity builds." And: "Each activity.info file must have a "host_version" key. The version is a single positive integer. This specifies the version of the Sugar environment which the activity is compatible with. (fixme: need to specify sugar versions somewhere. Obviously we start with 1.)" if this is incorrect, please, PLEASE (!!) remove it from the f$# %ing bit rot wiki! --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 8.2.0 Release Notes
On 17 Jul 2008, at 14:33, Greg Smith wrote: > I need the latest, final, definitive screen shots and documentation on > new Sugar GUI planned for 8.2.0 in the release notes ASAP. > > I plan to send release notes to deployment leads to see if they are > interested in using 8.2.0. I will say that the release notes are > subject > to change but it should be as correct as possible. > > I especially want to remove incorrect info and ideas that didn't make > the release. > > See the GUI section of the release notes at: > http://wiki.laptop.org/go/Release_Notes/8.2.0#GUI_and_Usability_Improvements > > I believe the control panel section is correct except for the Software > Updates section. > Please confirm. > > Scott, can you write a brief blurb on software updates? > > I need a link to additional approved documentation on the control > panel. > If we don't have one, this release notes will be all you get! > > The big gap is Home View and Frame Redesign > > Who can give me final screen shots and blurbs on all the elements in > that? I've uploaded some current Joyride screen grabs and min notes on the new Home ring/freeform/list view. Just a start, and I am no authority on what will be shipping in 8.2 other than what I see in Joyride (I realise the 8.2 stream was split off a ~week ago with an eye on only pulling in happy/shiny changes). > I posted the links I have but they may include features which will not > make the release. > > I want to send pre-release Release Notes out at the beginning of next > week so please respond ASAP. > > Let me know if you have any questions. I'll do whatever leg work is > needed if I know who/where I can get verified information. I was about to upload a screen shot of the brand new 'erase' activity feature (so kids can free up space taken by unused activities), anyone confirm if the intention is still to ship this in 8.2? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Write needs your help (was Re: Programming environments on the XO)
On 17 Jul 2008, at 20:37, C. Scott Ananian wrote: > $0.01: we shouldn't feel like shipping unsugarized apps is a failure: > better an working app w/ crappy UI than no working app at all! Sorry to disagree Scott. I'm not so sure... One 'crappy' UI or weak security riddled activity, leads to a dozen more, and then suddenly no one bothers and it's just a rush to slam in every random feature under the sun – I see a bunch of deviants creeping in and drifting from the Sugar spec already (won't mention names). I understand many hard core developers don't have much interest UI wise, that they think it just visual 'fluff' around their efficient set of classes (I blame badly taught CS classes and different personality types), but UI has a very large impact on user experience, and it is a good chunk of the reason that most *nix desktops have taken __SO__ damn long to get to mainstream (and perhaps why Apple are riding such a good wave just now). As they say, one rotten apple can put you off the rest of the basket. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Display warnings in sugar
On 17 Jul 2008, at 20:39, Michael Stone wrote: > On Thu, Jul 17, 2008 at 10:27:21AM -0300, Emiliano Pastorino wrote: > > Emiliano, > > I'm not sure of the right way to help you in the long term, but if you > want a quick hack, you might try something like: > > 1. Install a cronjob that runs every few minutes. > 2. When it runs, it should check the available space. > 3. If it concludes that space is low, pop up a warning. > > Warnings can be simple X or pygtk programs (see the 'dialog' > Linux > scripts for ideas). To get this hooked up to the running X > display, > you'll need to set some environment variables: > > DISPLAY=:0 > XAUTHORITY=/home/olpc/.Xauthority > > Ask if you need more help. Just out of interest, where is the code that raises the AP network authentication name/pass request? That feels like a pretty close template fit to such a critical warning. I must just say I'm not 100% convinced about how successful a warning will be (but it is better than nothing). I've hit the issue a couple of times and it was not some slow incremental case where I could take sensible action. Both times, as I recall, I was downloading some ~large library or binary which maxed out the space in one go before I realised the size. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Programming environments on the XO
On 18 Jul 2008, at 02:25, Martin Sevior wrote: >> On Thu, Jul 17, 2008 at 11:28 AM, Benjamin M. Schwartz >> <[EMAIL PROTECTED]> wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Chris Ball wrote: >>> | Another useful feature would be for >>> | Write to have unique background colors for collaborators, as >>> Gobby does. >>> | I wonder if that would be a small enough task for someone to >>> take on. >>> >>> See also #7447. Currently, Write doesn't support background >>> colors at all. >>> > > Hi Folks, >Just so you know. The only reason for #7447 is because we > haven't put the UI in to enable it. libabiword supports background > colors. If the Powers That Be decide that this is an important feature > for children it is very easy to implement it. Every feature of AbiWord > is present in libabiword, say the word and we'll implement it for > Write. > > I'm not sure different colors for different users is such a good idea > though. The document will quickly become a mess. Though if the kids > want to do this they can. The codingmonkeys with their great SubEthaEdit also made very good use out of background colour tints to indicate authorship. Works really well: http://www.codingmonkeys.de/subethaedit/images/sessionbig.png As I remember, there is a button to toggle the background colours on and off depending what you want to see (and I think mouse over pop-ups in addition to show the authorship of a text block). Now if I actually had other friends to work with, SubEthaEdit, would have been my editor of choice ;-) --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Design Question
On 19 Jul 2008, at 00:18, Walter Bender wrote: > (Now that we have a reasonably stable joyride-with a working Record > activity again-I'll try to get a quick user study pulled together in > Peru on this topic by someone less bias than myself.) Hmmm, not convinced Record-55 is working well enough yet (Joyride-2174), unless it's just failing on my B4 hardware. I get everything from a black feed, to a green/purple stripy feed. Not managed to actually record anything with it yet. Doesn't seem to help launching Record first after a reboot and with no other activities (think that was one of the open bugs). --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Record-55 issue was B4 hardware failure (Was: Design Question)
On 20 Jul 2008, at 13:40, Bobby Powers wrote: > On Sat, Jul 19, 2008 at 7:19 AM, Tomeu Vizoso > <[EMAIL PROTECTED]> wrote: >> Works quite well here in a MP with last joyride. Just did some light >> testing, though. > > I've also tested it (lightly) on 3 machines running Joyride ~2170. > >> Tomeu >> >> On Sat, Jul 19, 2008 at 1:06 PM, Walter Bender <[EMAIL PROTECTED] >> > wrote: >>> Not good news. I don't recall that anything should have changed >>> between B4 and the C series that would have impacted Record. I'll >>> have >>> to check it out on more machines... >>> >>> -walter >>> >>> On Sat, Jul 19, 2008 at 1:14 AM, Gary C Martin >>> <[EMAIL PROTECTED]> wrote: >>>> On 19 Jul 2008, at 00:18, Walter Bender wrote: >>>> >>>>> (Now that we have a reasonably stable joyride-with a working >>>>> Record >>>>> activity again-I'll try to get a quick user study pulled >>>>> together in >>>>> Peru on this topic by someone less bias than myself.) >>>> >>>> Hmmm, not convinced Record-55 is working well enough yet >>>> (Joyride-2174), >>>> unless it's just failing on my B4 hardware. I get everything from >>>> a black >>>> feed, to a green/purple stripy feed. Not managed to actually >>>> record anything >>>> with it yet. Doesn't seem to help launching Record first after a >>>> reboot and >>>> with no other activities (think that was one of the open bugs). > > just did that (boot then launch record) and it worked alright for me > (on a MP machine). > > bobby Thanks for all the feedback. OK, after a lot of testing and looking through logs I finally accidently stumbled on the problem. It seems to be a HW fault on my B4. Perhaps a dry solder joint, cracked pcb or camera component not seated correctly. If I squeeze the right side of the screen, just below the camera lense, Record-55 starts displaying the video image, sometimes blank, sometimes green/purple, sometimes back to normal. Managed to successfully recorded a video clip while the image was good. I'm reasonably handy with a soldering iron so I'll open up the unit and see if I can see the specific cause. Is there a specific place I should report this HW issue incase it is more than single an unlucky occurrence? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Joyride 2201 blocker
Just added a ticket for this myself: http://dev.laptop.org/ticket/7617 Seems to affect quite a number of keys – at least on my XO B4 with Spanish overlay (worked fine in 2174). I'd previously added ticket (Journal search and frame key have no effect): http://dev.laptop.org/ticket/7616 But am now assuming some keyboard mapping has gone wonky in the latest Joyrides (it's been about a week since Joyride was available to the non-hardcore dev so 2174 was last I could install). --Gary On 24 Jul 2008, at 01:28, Daniel Drake wrote: > On Wed, 2008-07-23 at 19:20 -0400, Mikus Grinbergs wrote: >> I do most of my work with CLI from the Terminal. >> >> On my XO with Joyride 2201 there is no "bash history" accessible in >> Terminal -- hitting up-arrow at the prompt does NOT call up what had >> been previously entered at the prompt. ["bash history" is >> accessible from the text console (alt-ctl-F1).] > > Please file a ticket, and also let us know which joyride version this > did work with (if known). > > Thanks, > Daniel > > > ___ > Devel mailing list > [EMAIL PROTECTED] > http://lists.laptop.org/listinfo/devel ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] specifying what services Activities may use
Hi Mikus, On 29 Jul 2008, at 22:09, Mikus Grinbergs wrote: >> Please ensure that you have filed tickets for each and every one of >> them > > What good will that do? > > At the beginning of this year, I wrote a ticket saying an Activity > would not start. Without notifying me, someone re-assigned *me* as > the owner of that ticket -- presumably making it my responsibility > to fix that Activity so it would start. Just assign the damn things back if that happens and hope you get a better triage next time around. I've not had this happen to me yet, but as mstone enjoys saying, "be bold"... I must say there is quite some guilt filing bugs this close to a release knowing the lack of resources, but reporting is kind'a the whole point close to release I guess. Very satisfying when you can catch something reproducible and one of the team can get the bug squished. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] joyride-weekly: joyride-2230
On 31 Jul 2008, at 14:44, Bert Freudenberg wrote: > On 31.07.2008, at 15:14, Bert Freudenberg wrote: > >> On 31.07.2008, at 02:41, Michael Stone wrote: >> >>> Dear world, >>> >>> This week's 'please test this joyride' is joyride-2230. Test group >>> release notes, care of Charlie, are available at >>> >>> http://wiki.laptop.org/go/ >>> Test_Group_Release_Notes#Build_Joyride_2230 >> >> >> olpc-update thinks that build does not exist. > > > The error actually is "unexpected server greeting: fakeroot" Glad it's not just me then. I thought I had some random intermittent network issue (for the last week or two) so had given up with olpc- updates rsync attempts to the server. I defaulted back to manually downloading the .toc and .usb files from the web server, sticking them on a USB stick and using olpc-update --usb. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] SOM posted for July Sugar list activity
For those curious, I just posted the Sugar Self Organising Map (SOM) for the month of July: http://sugarlabs.org/go/Community/SOM#Sugar_Mailing_List --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] How do I connect to a Jabber server ?
On 4 Aug 2008, at 23:40, Mikus Grinbergs wrote: > My _wish_ is simple: I want a chance to contact (for Chat, or for > collaboration) another XO at a different location. Basically, for > me to initiate that, that other XO's icon needs to be shown in my > Neighborhood view. > > Currently, only icons from the LOCAL mesh to which I am connected > will show up in my Neighborhood view. My question in this topic is: > "What do I need to do to have icons from REMOTE locations show up ?" If gabble fails to get to a named jabber server (set in the control panel) it defaults to salute. This may be via an access point (if you've attached to one) or via the mesh (if it has no luck with an AP). Once it's looking at the mesh it tries each of the 3 slices of spectrum available (1, 6 & 11) looking for a school server. If it find none it seems to default to go sit on mesh, channel 1, hoping to meet another XO there (though it may re-scan occasionally). Now the scanning sequence used to be as stated above (previous official releases), but in recent joyrides I find my XO immediately attaches to my preferred AP and doesn't waist time sniffing the mesh (I like this, but 3 kids under a tree may not). The xochat.org jabber server is the one I seem to reliably attach to for my XO testing, though I'd love to see an official developer jabber server, so as not to pester real G1G1 users with my tests, and so we can 'eat our own dogfood' in a dev environment**. Connecting to a remote jabber server is currently the way to see and share with other remote users*** in the neighborhood. ** perhaps Sugar Labs could run such an environment? *** recently, can even work with non XO jabber clients, though I've not been able to test properly yet. Note: current joyrides past 2241seem to have a broken eth0 networking, allegedly the (local) msh0 is still working but I have no way to test that side of things with a single XO. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] How do I connect to a Jabber server ?
On 5 Aug 2008, at 09:46, Morgan Collett wrote: >> The xochat.org jabber server is the one I seem to reliably attach to >> for my XO testing, though I'd love to see an official developer >> jabber >> server, so as not to pester real G1G1 users with my tests, and so we >> can 'eat our own dogfood' in a dev environment**. Connecting to a >> remote jabber server is currently the way to see and share with other >> remote users*** in the neighborhood. >> >> ** perhaps Sugar Labs could run such an environment? > > Collabora run a server which is the default setting for jhbuild: > olpc.collabora.co.uk That's good to hear re-confirmed, but I've not seen any buddies/ activities shared on olpc.collabora.co.uk for weeks/months. I'd just assumed your server was always borked by lots of connections, or in some unstable dev status, so I had switched over to xochat.org which always seems to respond and have buddies showing. Using your recent "nc olpc.collabora.co.uk 5222" trick I can now see olpc.collabora.co.uk is responding with some xml just fine. So, is no one else using it, or should I do some debugging? Are you running a dev version of a jabber server that's doing something different? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Question about clipboard service
On 5 Aug 2008, at 16:50, Eben Eliason wrote: > On Tue, Aug 5, 2008 at 3:44 AM, Greg Smith <[EMAIL PROTECTED]> > wrote: >> 7 - Is cut supported? How do you remove things from the clipboard? >> How >> many items can it hold? > > Cut is definitely supported, and will remain mapped to the Ctrl-X > shortcut familiar to many, however it will not retain the same name. > Instead, we've applied the notion of "cut" as "copy and erase", which > makes clear that the result of the action is twofold: first it > performs a copy action, and second it erases the item selected. Since > these semantics make "cut" an alternate form of the copy action, "copy > and erase" will actually appear as a secondary option in the palette > for the "copy" button itself. Random though; could there also be potential for a "paste and erase"? The intention being I could be reading a web article, perform several copy actions of separate text paragraphs I want to quote, then switch to write and perform several "paste and erase" actions to pop the clippings off the stack. Basically an easy way of unwinding the clipboard stack into another Activity. This could also go hand in hand with a potential keyboard modifier (Alt?) to allow a drag and erase of an clipping out of the clipboard in one step** **usually you only paste an item once, so this extra function would reduce the management steps a kid needs to do to erase each used clipping. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] New joyride build 2258
On 6 Aug 2008, at 14:47, Eben Eliason wrote: > On Wed, Aug 6, 2008 at 7:10 AM, Build Announcer v2 > <[EMAIL PROTECTED]> wrote: >> --- Changes for sugar 0.81.8-2.20080806git0fc57309f3.olpc3 from >> 0.81.8-1.fc9 --- >> + 7495 open cp software-updater on first boot after an update > > I don't want this! I keep shouting about it and no one seems to be > listening! Home absolutely needs to be home base, especially after an > update. I'm fine with tossing up a non-modal alert at boot which > prompts the user to update right away, with a button which reveals the > software update control panel module, but I'm NOT OK with anything > which, unbeknownst to the user, flits them away to some other part of > the system without his/her consent. +1 Just installed 2258 here, my first impression was that home page had hung/locked-up, noticed no Journal, tried to click an activity to launch something and then was dragged away into the control panel auto update. One of those non-modal alerts (horizontal black strip that pops out from below the toolbar) would be more friendly. The XOs been downloading updates for 10+min now. BTW: I do really like the standard updater (progress bar still needs some tweaking so it keep a grey outline and isn't all white fill), just would be nice to alow the user to trigger it*** ***I also felt the the behaviour where software update starts as soon as you click on the control panel icon was a little off. Would be more user friendly to display the updater interface with a button to clearly initiate the update process. Currently, if a kid goes poking about the control panel UI (a good thing), they are going to be triggering unintended update attempts for sure – on all kinds of slow network topologies... --G ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Question about write from Niue -OLPC training
Hi Greg,
On 7 Aug 2008, at 12:16, Greg Smith wrote:
> For the list, I don't know what version of Write or Browse I have on
> this XO. How do I determine that?
Hmmm, no one else seems to have answered you here yet, so here's an
old (and quite long) single line Terminal command I had generated a
while back to list all Activity versions installed anywhere on an XO,
hope it's of help (feel free to post it to a wiki somewhere if you
think it may be useful to others, though obviously not needed on newer
os images thanks to the home page list view):
sudo find / -name activity.info -exec grep -H activity_version {} \;
2> /dev/null | sed 's/\.activity\/activity\/activity
\.info:activity_version = /-/' | sed 's/.*\///' | sort
This will show something like the below output; note that you may see
some duplicate activities when they are stored out of the olpc home
directory (i.e down in /usr/share/sugar/), this is due to the run and
pristine file system hard link alternate boot image trickery, see
http://wiki.laptop.org/go/Filesystem
for some pretty pictures.
AcousticMeasure-12
Analyze-5
Bounce-5
Browse-95
Calculate-23
Chat-45
Colors-3
Develop-34
Etoys-87
Journal-96
Journal-96
Log-13
Maze-5
Measure-17
Model-8
Moon-3
NewsReader-24
Paint-19
Pippy-25
Read-49
Record-56
Speak-5
StarChart-4
TamTamEdit-49
TamTamJam-50
TamTamMini-48
TamTamSynthLab-50
Terminal-15
TurtleArt-7
Words-2
Write-57
--Gary
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] Please help test our new 8.2.0 weekly beta, joyride-2263!
On 8 Aug 2008, at 16:21, Daniel Drake wrote: > On Fri, 2008-08-08 at 15:45 +0200, NoiseEHC wrote: >> Speak cannot be started (the icon blinks for a long time and then the >> application stops starting). > > Please file a ticket. Already there, this one is down to package changes (Numeric in this case). There was some talk about a trivial one line fix in these broken activities (numpy related I vaguely remember). Did anyone making these package changes actually officially email the activity owners to let them know? http://dev.laptop.org/ticket/7852 --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Reviews report
On 11 Aug 2008, at 13:15, Release Team wrote: > = Rejected requests = > > Palette persist over zoom levels > http://dev.laptop.org/ticket/4084 > > GTK stock icon problems (has patch) > http://dev.laptop.org/ticket/7641 > > Greyscreen on home view after looking at list view > http://dev.laptop.org/ticket/7836 > > HippoCanvas does not support RTL rendering in RTL locales > http://dev.laptop.org/ticket/3108 > > Presence Service should start even with no interfaces up > http://dev.laptop.org/ticket/7451 > > Updates to Browse-92 fail. > http://dev.laptop.org/ticket/7494 > > Zoom toolbar button should have a fixed order > http://dev.laptop.org/ticket/6643 > > Default home view should be Ring, not Freeform > http://dev.laptop.org/ticket/7759 > > Safer to always install, rather than comparing versions > http://dev.laptop.org/ticket/7534 > > alt+tab switching is slow because activities are notified unneccessary > http://dev.laptop.org/ticket/7625 > > Journal with time filters (most commonly 'past week') scrolling > behaviour anomaly > http://dev.laptop.org/ticket/7234 > > Sugar shell crashes when threads used. > http://dev.laptop.org/ticket/7486 > > ohm and sugar should cooperate to unfreeze dcon > http://dev.laptop.org/ticket/7357 > > sugar-shell enters in infinite loop after a failed shutdown > http://dev.laptop.org/ticket/7566 > > cp: Inconsistent behavior after changing the xo color > http://dev.laptop.org/ticket/7560 > > No feedback from 'register' request. > http://dev.laptop.org/ticket/6136 > > Speaker device has inconsistent behavior > http://dev.laptop.org/ticket/7248 > > react gracefully to dbus services being restarted > http://dev.laptop.org/ticket/7740 H, all the review reports upto now seemed to make sense (and was useful to see), but this one's got me confused... I recognise quite a few of these rejected request as items already fixed, tested and working in the joyride builds. Are we just down to release timing cuts now to try and make the 8.2.0 official branch? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] new 8.2.0 beta joyride - upgrading via control panel ?
On 11 Aug 2008, at 15:13, C. Scott Ananian wrote: > Please send me sugar logs for any activity update control panel > failures, along with details on what activity it was attempting to > download at the time. Please be sure you are using joyride-2266 or > later, and that you have suspend turned off. OK, will do. Can you hint where update control panel will be logging? I looked for them in vain when I was having problems with it. > On Mon, Aug 11, 2008 at 6:59 AM, Walter Bender <[EMAIL PROTECTED] > > wrote: >> then one day, it just worked. The usual behavior seems to be that it >> will succeed to upgrade most of the activities and report failures on >> a handful, offering to try again (although it is not clear that that > > I am not terribly interested in bug reports on this particular > behavior: Yea Scott, this really shows, it's hard to know what's at fault when things just stop for no obvious reason – but I know you core folks are real busy, so I don't take offence and hope the rest of the Activity developers don't either. > this is caused by activity authors giving inconsistent > information on the Activities wiki page and/or their update url. > Please file those bugs against the individual activities; I don't > particularly want to hear about them. Has any one oficially put out a clear heads message for the Activity authors, documenting the change for future release? Or are we all meant to go geek through the updater source and try and work out what's going on. I read the lists and track pretty closely, I'm sure most don't, I think I saw a single paragraph kicking around the wiki.laptop.org somewhere – h – OK found it, so this is now the official request and we (Activity developers) should pick it up and run? http://wiki.laptop.org/go/Activity_bundles#.info_File_Format info File Format update_url = ... URL to retrieve update information; implemented in #4951. The software update control panel will attempt to look for information about the latest version of the activity by fetching the given url with first the core OS build number, then the release number, then the release major version number appended, then finally as-is. (For example, if your update URL tag has the value 'http://host.net/bundles/FooBar'and you are currently running release 8.1.1 (core OS 708), the following URLs will be tried, in this order:http://host.net/bundles/FooBar/708, http://host.net/bundles/FooBar/8.1.1 , http://host.net/bundles/FooBar/8.1,http://host.net/bundles/FooBar .) The contents of the URLs should be in the activity microformat. If no update_url is specified, http://wiki.laptop.org/go/Activities will be used. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Journal view "flips" topmost entries
On 11 Aug 2008, at 18:50, Mikus Grinbergs wrote: > One problem I have with my XO is that it sometimes is too SLOW for > my reactions. Just now had been trying out an Activity. Ended it. > Went to the Journal, with the intention of erasing the entry that > Activity logged there. Saw that entry at the very top, clicked on > the little arrow at the right end of the top entry, went to the > toolbar and clicked on 'Erase', got put back in Journal -- and saw > the entry I wanted to erase still being shown on the Journal screen. Mikus, random thought: Did you have any activities shared at the time? I've noticed quite a lag when switching between activities or to sugar views once you're sharing something. The lag seems to be a long pause that ends once the buddy icons in the right frame get updated. I haven't filed a ticket yet as I only have one XO for testing and it's hard to catch folks to share (xochat.org seems down just now). --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] non-colored activity icons in frame
On 14 Aug 2008, at 13:17, Mikus Grinbergs wrote: > Just tried faster-2301. In the top bar of the Frame, the icons for > the currently active Activities were being shown in black-and-white. > Looked more aesthetic when they were shown in the user's colors. Just testing joyride-2301 here: Activity instance icons in the Frame top section are correctly appearing in my XO user colours, so perhaps it's just something in the faster stream that's being tweaked. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 0.84 goals
On 14 Aug 2008, at 22:08, Marco Pesenti Gritti wrote: > Here is what I have so far. > > * Next generation journal > * File sharing > * Collaboration scalability > * Responsive UI > * Stable activities API > * Official Sugar LiveCD > * Compatibility with desktop applications Well regarding that last one, my experiences with the latest Firefoxs in Joyride on a real XO, have been horrific to say the least, system lockups, UI so slow it took 5min+ to show the frame, not able to quit (usually have to hard power off). So I'd rather folks focus on elegant and needed sugar activities, that are designed for the environment and audience, rather than some hard core, geek hacker driven, Linux workstation. > * Quality and reliability --- snip --- > I know it's very vague for now. But if something is obvious missing > please let me know or edit directly. I'm not sure where this one goes, but I'd love to see the home views activity icons and palettes represent the latest N journal entries for said activities. I think this will be a great way to leverage the Journal benefits by reducing new activity cruft, encouraging folks to resume using the home views: http://wiki.laptop.org/go/Image:Activity_management-07.jpeg --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 0.84 goals
On 15 Aug 2008, at 15:57, Mikus Grinbergs wrote: >>> Why not let accessing of *deferred* Activities be handled by >>> Journal ? >> >> Because it involves an extra step or two that in practice people >> don't >> take. Personally, I would even go to the extreme that the Home View >> should by default open the most recent Journal entry. > > I'll be the first to admit that the current implementation of > Journal is cumbersome. But if it is possible to add palette entries > to Activity icons on Home view (for resuming something), it ought to > be possible to add similar "short cuts" on the Journal screen. > > I can get to the Home view by pressing the 'Home view' key on the > keyboard. I can get to Journal by pressing the 'Journal' key on the > keyboard. For me, going to the Journal takes no more steps than > going to Home View. [And since Home view provides alternate ways of > presenting its information, why oughtn't Journal provide alternate > ways of presenting *its* information (including a clickable "short > cut" listing of the most recently saved Activities) ?] > > I was speaking from the point of view of *defining* the purpose of > the Home view. If 'resume' is there, should 'erase' be there also > -- what if the user mis-positions his click ? > > > > I'm a procedure-oriented person, not an object-oriented person. So > it has taken me effort to mentally construct a role for the Journal. > If "short cuts" to the most-recent uses of the Activities are > provided elsewhere, why bother having a Journal in the first place ? OK, how about... Think of an iceberg, where the home view will expose just the tip of recent activity; it's the working set of recent work. The journal then provides a deep, below the waterline, historical view/context for when you need to find that photo/assay/painting from a few days to months back; The journal can have the extra UI details needed to perform these deep search/filtering, and maintenance activities (add tags, description, rename, star, copy to flash mem stick, erase). The home view can then keep a clean UI focus on your recent*** working set. ***with the top frame being the immediate view of 'right now'. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Please help test our new 8.2.0 weekly beta, joyride-2301!
On 15 Aug 2008, at 09:49, S Page wrote: > The Firefox icon in Software update and Home view is mysterious ;-) From my testing on XO B4 hardware can I courteously suggest you at least be wary of running it. It will randomly eat your available CPU cycles and available memory. If you watch cpu load with it even open on the default mainly blank page you will see it surging resources from the system every now and again, for no obvious reason, and if you actually use it to start surfing, say perhaps the activities page, with perhaps some other activity running, you're fairly sure to bring the whole system to a grinding halt; stuttering cursor; and a forced reboot. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] commanding the movement of things on the screen
On 21 Aug 2008, at 20:22, Mikus Grinbergs wrote: > I use an external USB trackball, and do most of my work in Terminal. > On numerous occasions, when I have moved the cursor to a scrollbar > location above the slider, and have left-button clicked ONCE (to > scroll up one screen's worth) -- the XO has spontaneously scrolled > up many many screen's worth. > > The best explanation I can come up with is that instead of > "interpreting" a _single_ button-click command, the XO behaved as > though a whole _series_ of such commands had been presented. > [I have no reason to believe that the trackball is at fault.] Yes, I've seen something like this also, specifically while trying to scroll one page in the Log activity (XO B4 trackpad, joyride 2301, Q2E13), perhaps 4 or 5 times now. I'd assumed I might have been trying to scroll at the same moment that 10's of pages of log entries may have suddenly arrived, but I'm beginning to doubt that. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [PATCH] New Activity Launcher
On 22 Aug 2008, at 20:45, Eben Eliason wrote: > My recent interactions with the launcher have led me to frustration. > I updated a number of tickets on the subject, and also created an > aggragator to track them all (http://dev.laptop.org/ticket/8090). The > attached patch is an attempt to solve nearly all of the known > problems. Testing would be very much appreciated. > > The only known issue I've found with this patch is that you can't > click on the activity level button (in the Frame) while a launcher is > the selected activity (though you can click on the launcher icon > directly). Marco understands this issue, but feels we might be better > off working in a fix separately, since it could be more invasive. > Apart from that know bug, I believe that this new launcher yields > expected behavior everywhere; if you disagree, or find other bugs, let > me know! Hi Eben, I applied this to a joyride-2330, on an XO, and initially it feels _much_ better. However, I've also noticed, particularly when test launching Calculate-23, if you reveal the frame (mouse corner or key), after letting the icon pulse get going, Calculate will fail to start (it's logs complain about rainbow**). I've also managed it with Pippy-25 though not yest with other activities, so it might be a timing issue. When the frame is invoked and the activity fails to launch, there's quite a bit of screen redraw/flicker, wonder if the frame arrival is overlapping the time that the activity is redrawing and focus is going astray mid way through. (email if you want some specific testing from me) ***The program 'rainbow-daemon' recieved an X Window System error (both pippy and calculate logs had this during a launch fail) Regards, --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Activity testing on current 8.2 build 759
In no particular order, here's a list of basic activity test results for the current 8.2 build 759 on a B4 XO. I've included both success and failure so folks know what was tested. I was a little surprised to see quite how many activities don't actually keep any useful state in the Journal for resuming – though I'm also an offender here if you don't count a version in git I haven't .xo bundled yet :-) == Log-14 Could start? Yes Could stop? Yes Sound: N/A Activity resume: No useful state Note: What would be a useful state to keep? == Scratch-7 Could start? Yes Could stop? Yes Sound: Works Activity resume: No journal entry!! == Bounce-6 Could start? Yes Could stop? Yes Sound: Broken Activity resume: No useful state == Bridge-1 Could start? Yes Could stop? Yes Sound: Broken Activity resume: No useful state == Moon-4 Could start? Yes Could stop? Yes Sound: N/A Activity resume: No useful state == News Reader-24 Could start? No Note: Has hard-coded path to old isolation directory that no longer exists == Record-57 Could start? Yes Could stop? Yes Sound: N/A Activity resume: Useful state is restored == Implode-4 Could start? Yes Could stop? Yes Sound: N/A Activity resume: Useful state is restored == EToys-89 Could start? Yes Could stop? Yes Sound: Works Activity resume: Useful state is restored == Browse-96 Could start? Yes Could stop? Yes Sound: N/A Activity resume: Useful state is restored == Words-3 Could start? Yes Could stop? Yes Sound: N/A Activity resume: No useful state == Chat-46 Could start? Yes Could stop? Yes Sound: N/A Activity resume: Useful state is restored == Firefox-6 Could start? Yes Could stop? Yes Sound: N/A Activity resume: No journal entry!! == Colors!-4 Could start? Yes Could stop? Alt-esc only (toolbar stop icon has no effect) Sound: N/A Activity resume: Useful state is restored Note: Needs to resume showing the painting end state, not a blank page at time zero. == Speak-7 Could start? Yes Could stop? Yes Sound: Works Activity resume: Useful state is restored == Paint-20 Could start? Yes Could stop? Yes Sound: N/A Activity resume: Useful state is restored Note: Very laggy when you try to draw, perhaps 1 to 2 seconds behind mouse movement! Currently quite unusable on XO hardware. == PlayGo-3 Could start? Yes Could stop? Yes Sound: N/A Activity resume: Useful state is restored == x2o-5 Could start? Yes Could stop? Yes Sound: N/A Activity resume: Useful state is restored Note: Main activity tool bar too full, keep and stop icons end up in a hidden mini menu. == Read-50 Could start? Yes Could stop? Yes Sound: N/A Activity resume: No useful state Note: Expected previous pdf page number to be displayed after a resume. Starting an empty read activity from a home view should invoke the journal object picker to allow pdf selection. == Geoquiz-3 Could start? Yes Could stop? Yes Sound: N/A Activity resume: No useful state Note: Would be nice if you could resume from where you last left off, also a winning screen with your top time scores would be good (currently the activity just auto quits on success). == TurtleArt-9 Could start? Yes Could stop? Yes Sound: N/A Activity resume: Useful state is restored == Memorize-27 Could start? Yes Could stop? Yes Sound: Works Activity resume: No useful state Note: Current active game state is not saved to journal, though you can create custom tile sets and save them separately to the journal for later use. == Xo IRC-4 Could start? Yes Could stop? Yes Sound: N/A Activity resume: No useful state Note: Perhaps remember any open IRC room tabs in journal state, nickname as well? == Analyze-5 Could start? Yes Could stop? Yes Sound: N/A Activity resume: No useful state == StarChart-4 Could start? Yes Could stop? Yes Sound: N/A Activity resume: Useful state is restored == Model-8 Could start? Yes Could stop? Yes Sound: N/A Activity resume: Stores an incomplete diagram state to journal == Terminal-15 Could start? Yes Could stop? Yes Sound: N/A Activity resume: No useful state == TamTamSynthLab-50 Could start? Yes Could stop? Yes Sound: Works Activity resume: Useful state is restored
Re: [sugar] Activity testing on current 8.2 build 759
On 9 Sep 2008, at 04:09, Erik Garrison wrote: > On Mon, Sep 08, 2008 at 03:18:29AM +0100, Gary C Martin wrote: >> >> == >> >> Paint-20 >> Could start? Yes >> Could stop? Yes >> Sound: N/A >> Activity resume: Useful state is restored >> >> Note: Very laggy when you try to draw, perhaps 1 to 2 seconds behind >> mouse movement! Currently quite unusable on XO hardware. >> >> == >> > > I've noticed this on 2263. Perhaps it's a result of mouse driver > changes? Yea, pretty high possibility. It was suggested that with the new improved (higher frequency) of mouse tracking event messages, Paint is now unable to keep up it's drawing rate. The suggestion being Paints design needs a tweak so that it doesn't try to respond to every single mouse event. Oh dear I'm now really badly paraphrasing Jim Gettys, of all people, so I'll just stand back and point to his email earlier in the week incase you missed :-) http://lists.laptop.org/pipermail/sugar/2008-September/008100.html --G ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Activity testing on current 8.2 build 759
On 9 Sep 2008, at 21:07, Morgan Collett wrote: > On Tue, Sep 9, 2008 at 18:11, Sayamindu Dasgupta > <[EMAIL PROTECTED]> wrote: >> On Tue, Sep 9, 2008 at 8:39 AM, Erik Garrison <[EMAIL PROTECTED]> >> wrote: >>> On Mon, Sep 08, 2008 at 03:18:29AM +0100, Gary C Martin wrote: >>>> >>>> == >>>> >>>> Paint-20 >>>> Could start? Yes >>>> Could stop? Yes >>>> Sound: N/A >>>> Activity resume: Useful state is restored >>>> >>>> Note: Very laggy when you try to draw, perhaps 1 to 2 seconds >>>> behind >>>> mouse movement! Currently quite unusable on XO hardware. >>>> >>>> == >>>> >>> >>> I've noticed this on 2263. Perhaps it's a result of mouse driver >>> changes? >>> >>> Erik >> >> >> http://dev.laptop.org/ticket/8285 >> I added a few workarounds to make it usable. Morgan will probably >> make >> a new release (v21) soon with those patches. Once that is out, please >> provide feedback on how it works. >> Thanks, >> Sayamindu > > Paint-22 has both of Sayamindu's patches for this, and is definitely > better. Wow, absolutely! Just retested Paint-22 on an XO with 8.2-759 and it's a whole world of difference. Control actually now feels more responsive than in previous release builds. Really good fix :-) --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Any idea why ./setup fix_manifest should auto delete my locale directory?
Any idea why running "./setup fix_manifest" should be auto deleting my locale directory? Seems a little mean spirited of it - doesn't warn me or anything. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
On 19 Sep 2008, at 00:13, Douglas Bagnall wrote: > (AFAICT) we're limited to: > > XaoS - org.codewiz.XaoS > Sokoban - de.hpi.swa.Sokoban > Pipes- de.hpi.swa.Pipes > Bounce - bounce > Chat - org.laptop.Chat > DrGeoII - org.ofset.DrGeoII > Breakout - de.hpi.swa.Breakout > Funtowers- de.hpi.swa.Funtowers > DiceWars - de.hpi.swa.DiceWars > X activity - org.laptop.wiki.XActivity > StackAttack - de.hpi.swa.StackAttack > Joke Machine - org.worldwideworkshop.JokeMachineActivity > Sokobaenle - de.hpi.swa.Sokobaenle > BlockAttack - de.hpi.swa.BlockAttack > Abalone - de.hpi.swa.Abalone > SameGame - de.hpi.swa.SameGame > > > Not that it really matters, of course. Meow, ooh ouch ;-) > Most activities fail by having no bundle_id, and only 36/115 have > host_version. Perhaps correcting http://wiki.laptop.org/go/Activity_tutorial would help? I'm showing my age here, but is bundle_id a replacement for service_name? Seem to be identical. OK, well... I 'think' Moon-5 can now go on your shiny happy list – available from the the Activities wiki page or get it fresh via the Control Panel software updater if you already have a previous version. However, any hints would be much appreciated as to what this last remaining setup.py WARNING is trying to tell me? WARNING:root:bundle_name deprecated, now comes from activity.info I've not had much luck tracking it down, and I make no reference to bundle_name in my code. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
On 19 Sep 2008, at 09:15, Marco Pesenti Gritti wrote: > On Fri, Sep 19, 2008 at 4:01 AM, Gary C Martin > <[EMAIL PROTECTED]> wrote: >> I'm showing my age here, but is bundle_id a replacement for >> service_name? Seem to be identical. > > Yeah, service_name is deprecated but they are basically the same > thing. bundlebuilder should probably warn about it. > > Marco So I should keep both in my activity.info for backwards compatibility with early builds? Thanks for all the responses, I obviously haven't quite understood the way string translations** are designed for yet, will go have another read and poke about. **basically trying to absorb the Moon.activity/locale/es/ activity.linfo that was added to Moon-4 for the Peru deployment bundle. I'm now assuming this file is being generated (or prevented from auto deletion) by something in po which I'm missed. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Keeping Trac(k)
Hi Bert, On 19 Sep 2008, at 13:27, Bert Freudenberg wrote: > For keeping up with new Trac tickets I discovered this RSS feed: > > http://dev.laptop.org/timeline?ticket=on&max=50&daysback=7&format=rss > > ... which only has entries for opened and closed tickets. This is much > more bearable than subscribing to the bug notify list. > > Even better would be if I could filter that by component :) I think you can, I just made up a quick track query and my browser (Safari) indicates an RSS feed is available, can then subscribe. Here's the URI it gave me for new+reopened and Action is test in build: feed://dev.laptop.org/query?status=new&status=reopened&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component&next_action=test+in+build&format=rss --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
On 19 Sep 2008, at 03:49, Douglas Bagnall wrote: > Gary C Martin <[EMAIL PROTECTED]> wrote: > >> Perhaps correcting http://wiki.laptop.org/go/Activity_tutorial would >> help? > > Good point -- done, at least for host_version and bundle_id. As it > happens the actually published HelloWorld activity is one of the > worst offenders, having no activity_version. That might even break > things. Fab, thanks. I guess the trick is to flag wave about the activities that do things 'right', the only way I got things going was by rooting around in some of the existing activity source code, probably picking up all sorts of bad habits. Perhaps it could be worth linking to a few Activity source trees in git that folks think are a good next steps to investigate (for after someone has passed the 'hello world' type level stage)? >> OK, well... I 'think' Moon-5 can now go on your shiny happy list – > > Yes! :-) --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1 Pre-installed Activities Request for Help Testing
On 20 Sep 2008, at 01:42, jean piche wrote: >> The only significant change from the original G1G1 set is the >> TamTam. I think we should include 2 not 4 so as not to over weight >> them against other activities. >> >> Let me know if anyone has comments on that (Jean can you live with >> that?). > > Yes. However, I think Mini and Edit would be my picks. Your call. Oh I think Synthlab is great! Think of all those budding sound engineers! I know it currently (using ~8.2) starts to stutter if you hit more than a few keys at once and wave the mouse about, but it's makes some great sounds through an amp if your gentle on the keys. :-) --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] G1G1v2 Activities
On 19 Sep 2008, at 22:50, C. Scott Ananian wrote:
> On Thu, Sep 18, 2008 at 10:01 PM, Gary C Martin
> <[EMAIL PROTECTED]> wrote:
>> However, any hints would be much appreciated as to what this last
>> remaining setup.py WARNING is trying to tell me?
>>
>> WARNING:root:bundle_name deprecated, now comes from
>> activity.info
>>
>> I've not had much luck tracking it down, and I make no reference to
>> bundle_name in my code.
>
> When you call BundleBuilder in setup.py, don't pass in a string in the
> constructor, leave it empty. It interprets the argument as a
> 'bundle_name' and is complaining that it's going to ignore what you
> passed in and use the name specified in activity.info instead.
>
> Yes, it took me a *long* time to finally realize this.
> --scott
And just like magic, the warning has gone. Thanks scott!
Does anyone disagree with me modifying pages I find on the wiki that
show this (incase there is some side effect I am unaware of)? So where
I see:
bundlebuilder.start("HelloWorldActivity")
I'd edit to:
bundlebuilder.start()
--Gary
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] [RELEASE] Calculate 24
Hi Reinier, On 21 Sep 2008, at 21:50, Reinier Heeres wrote: > I released a new version of Calculate, it's available at: > > http://dev.laptop.org/~rwh/calculate/Calculate-24.xo I notice the various wiki Activities links don't point to the new version (so the new SW update process doesn't currently see your update yet). Is it ok for me to go update the wiki links? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame gets in the way when alt-tabbing
On 23 Sep 2008, at 15:08, Bert Freudenberg wrote: > > Am 23.09.2008 um 06:21 schrieb Erik Garrison: > >> Both Joyride and 8.2 streams have composition enabled by default. >> >> You can test composition by running "xcompmgr -d :0.0" in the >> terminal. > > > It is available, but the window manager does not use it, afaik. > > - Bert - Not that I could find the "xcompmgr" command anyway, but if you run "matchbox-window-manager -?" it lists its compile time options, and there is a definite "composite support no" line in there. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On 24 Sep 2008, at 16:12, Erik Garrison wrote: > On Wed, Sep 24, 2008 at 11:03:01AM -0400, Chris Ball wrote: >> Hi Erik, >> >>> Hello all, On tabbing we are currently auto-toggling the frame. >>> Are we sure that this is necessary? Could we include a >>> configuration option to change this? >> >> Sounds good, I'd agree with just removing it completely. > > Me too. I thought there was a bug with the current implementation that has slipped this release cycle. I understood the Frame was to reveal and then as you alt-tabbed you could see the focus move between the Activity instances (i.e. no switching has yet happened), and when you finally release the alt key (on the instance you are really after, not the Journal ;-b ), that instance is then focused. I agree if you are just tabbing between 2 instances the frame reveal is an unnecessary burden, but with 3 activities you'll probably be focusing on something you don't want 50% of the time (at least most kids will). More than 3 and you really are just ploughing the XO through a heap of Activity redraws. I couldn't find the original trac ticket for this, anyone remember (wanted to go see where dev stalled)? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On 24 Sep 2008, at 16:34, Gary C Martin wrote: > I thought there was a bug with the current implementation that has > slipped this release cycle. I understood the Frame was to reveal and > then as you alt-tabbed you could see the focus move between the > Activity instances (i.e. no switching has yet happened), and when you > finally release the alt key (on the instance you are really after, not > the Journal ;-b ), that instance is then focused. Sorry, didn't describe that well on second read, and I just noticed that if you hit the alt-tab like some 1980 track'n field game in the arcades, you can select a different activity with out focusing all the others on the way there. This IMO is the wrong behaviour, even with a longer delay to allow less frenetic tab key hitting, the behaviour should be to focus ON RELEASE of the alt key. That way you can take all the time in the world scanning the icons and choosing where you need to get too. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] frame auto-visibility configuration
On 24 Sep 2008, at 18:25, Eduardo H. Silva wrote: > Wow, just tried Erik's instructions for using xcompmgr, and it's > amazing how swift the frame slides, and how I don't see any screen > redraws. The experience is totally more fluid. Does it degrade overall > performance? If not much, and if that performance degradation could be > recovered in another area in Sugar (general performanfe improvements), > I'd vote for this to exist in joyride and even part of future stable > builds. Just curious, you guys running on XO hardware? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [RELEASE] Calculate 25
Hi Reinier, On 24 Sep 2008, at 22:20, Reinier Heeres wrote: > Hi, > > I released a new version of Calculate, it's available at: > > http://dev.laptop.org/~rwh/calculate/Calculate-25.xo > > Sources are at: > > http://dev.laptop.org/pub/sugar/sources/calculate-activity/Calculate-25.tar.bz2 > > NEWS entries: > > * Spell 'license' correctly > > Regards, > > -- > Reinier Heeres Not sure why but for me SW update is not picking up v25 (I have v24 installed). I checked the wiky Activities page but you seem to have that set fine (SW update looks there by default). I'm wondering if your update_url = http://dev.laptop.org/~rwh/calculate content is working correctly. I've not tried that mechanism yet, I've just been playing it safe and relying on the default Activities page search. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] 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
[sugar] Secrete hidden Home view styles
I was hoping the extra view types would have made it into the new release, but looks like some official decision to hide them has been made. Pitty. I just tested with 50 activities I've been testing, set as favourites, and the only 2 views that are usable are SUNFLOWER_LAYOUT and the less pretty but still usable RANDOM_LAYOUT. In both these views you get icons at full size. RING_LAYOUT, BOX_LAYOUT and TRIANGLE_LAYOUT all seem to have suffered some recent huge allergic reaction to the previous complaint that, with many icons, they overlapped a little. Icons are now so small and far apart that each seems it could be at least +50% or more in size and still not touch each other. Oh well. Swings and roundabouts. SUNFLOWER_LAYOUT just made it as my fav hack, pity the children of the world. --Gary P.S. For those kids willing, try http://wiki.laptop.org/go/ Hacking_Sugar and get the new builds most usable Home layout enabled :-) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [RELEASE] Moon 6
Hi, Just released a new version of Moon, main change is the inclusion of Spanish language. Thanks go to Gabriel Menini for volunteering her skills! NEWS * Now has a Spanish locale by Gabriel Menini (many thanks!) * Removed service_name from .info, that spec went away a long time ago. * Change methods from camelcase to make pylint happier... If you have Moon already and are testing a recent build, Software Update will get you a fresh copy. The direct bundle link is: http://wiki.laptop.org/images/b/b9/Moon-6.xo --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [RELEASE] Moon 6
On 26 Sep 2008, at 10:45, Bastien wrote: > Gary C Martin <[EMAIL PROTECTED]> writes: > >> Just released a new version of Moon, main change is the inclusion of >> Spanish language. Thanks go to Gabriel Menini for volunteering her >> skills! > > And here is french. > > > -- > Bastien Hi Bastien, wow, many thanks. I'll make sure this is into the next Moon build! --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [RELEASE] Moon 7
Hi, Just released (yes I know, another) new version of Moon, main change is the inclusion of French language. Thanks go to Bastien Guerry for this! NEWS * Added French locale by Bastien Guerry (thanks!) * Reduced frame padding to allow more space for longer French strings. * Fixed encoding issue affecting one string in the po file for both FR and ES. * Corrected missing newline from Juliana ES translation string. If you have Moon already and are running a recent build, Software Update will get you a fresh copy. The direct bundle link is: http://wiki.laptop.org/images/c/c5/Moon-7.xo --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] 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. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Any idea why ./setup fix_manifest should auto delete my locale directory?
On 19 Sep 2008, at 08:20, Simon Schampijer wrote: > Gary C Martin wrote: >> Any idea why running "./setup fix_manifest" should be auto deleting >> my locale directory? Seems a little mean spirited of it - doesn't >> warn me or anything. >> --Gary > > Hi Gary, > > it does it because the builder removes the dir before creating the > locale again. > http://dev.laptop.org/git?p=sugar-toolkit;a=blob;f=src/sugar/activity/bundlebuilder.py;h=baeb8b63a79fa57b17197e8561d8179e3357b57e;hb=6a5d0c837beb06e34493b809fab58a568fbf2051#l94 > > We needed it to get rid of the pseudo.po in the locale. Are there > any problems with it besides being bit ugly? Thanks, I'm getting a better understanding now. What caught me out was trying to pick-up the quick fixes made for the Peru bundle, where the locale (I now understand) seems to have been manually created for a .linfo file to live in – so Activity names were at least in Spanish. Now that I have a real po/es.po file, locale structures are auto generated and I can pretend the locale files don't exist from a development point of view (I think) :-) The only other curiosity is the "./setup install" it seems to want to install in /usr/share/sugar/activities/ which seems a old (?) choice these days. I've just switched to using dist_xo to get a .xo, and then sugar-install-bundle. Ooh, I guess there are another couple of queries I still have :-) 1) I used the "./setup dev" to try the syn link for testing, for a while, but found it a risky approach. Several times the Sugar UI wouldn't allow me to erase said Activity (no errors, just the activity icon never went), at least once the UI wiped out all my source, and the rest of the time the UI correctly removed just the sym link . I just sugar-install-bundle now, it's safer :-) 2) I'm a git beginner, so "./setup release" has done 'wierd' things given my current level of understanding. Apart from failing early due to git, as I seem not to have told it correctly what branch I want to merge from, even though I only have master so far and have nothing to merge anyway (why is it doing a pull?). It 'kindly' auto created me an unstable branch (which took me a while to realise and remove). So I'm back to a manual workflow. It is nice that "./setup.py" on it's own gives some hints: Available commands: buildBuild generated files dev Setup for development dist_xo Create a xo bundle package dist_source Create a tar source package release Do a new release of the bundle fix_manifest Add missing files to the manifest genpot Generate the gettext pot file install Install the activity in the system But the help goes no deeper, so it's just been trial and error from here on :-) Is there any more documentation/cheat-sheet hiding somewhere on this other than grokking the source code? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Any idea why ./setup fix_manifest should auto delete my locale directory?
On 29 Sep 2008, at 09:41, Marco Pesenti Gritti wrote: > On Mon, Sep 29, 2008 at 5:58 AM, Gary C Martin > <[EMAIL PROTECTED]> wrote: >> 1) I used the "./setup dev" to try the syn link for testing, for a >> while, but found it a risky approach. Several times the Sugar UI >> wouldn't allow me to erase said Activity (no errors, just the >> activity >> icon never went), at least once the UI wiped out all my source, and >> the rest of the time the UI correctly removed just the sym link . I >> just sugar-install-bundle now, it's safer :-) > > Ouch, we should fix that. Can you open a ticket please? OK, will retrace my steps and file. > The advantage of dev is that changes "autoapply". Obviously stuff like > the locale is not autogenerated, but it still it seem to be an useful > option. Is 'autoapply' a git thing? >> 2) I'm a git beginner, so "./setup release" has done 'wierd' things >> given my current level of understanding. Apart from failing early due >> to git, as I seem not to have told it correctly what branch I want to >> merge from, even though I only have master so far and have nothing to >> merge anyway (why is it doing a pull?). It 'kindly' auto created me >> an >> unstable branch (which took me a while to realise and remove). So I'm >> back to a manual workflow. > > Weird I'm not sure how release would create a branch. How was the > branch named? Before trying './setup release', 'git branch' listed just 'master'. After, it then started listing 'master' and 'unstable', and it had moved me to the 'unstable' branch (i.e. had a * next to unstable). Luckily I'd only made small code tweaks and not committed anything before I noticed, so I just killed the unstable branch and went through a commit, push cycle, then elsewhere, cloned and re-checked nothing had been borked. > But yeah, release needs love, it has been sort of abandoned for a > while. It's one of the things I plan to do before the first 0.83 > release. OK, understood. Will keep avoiding for now :-) >> It is nice that "./setup.py" on it's own gives some hints: >> >> But the help goes no deeper, so it's just been trial and error from >> here on :-) >> >> Is there any more documentation/cheat-sheet hiding somewhere on this >> other than grokking the source code? > > Nope :( This is one of the pieces of documentation that we really need > to write. A ticket to remind about it would be great. OK done, #8713. Thanks, --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Image Viewer Activity
On 29 Sep 2008, at 17:13, Sayamindu Dasgupta wrote: > Hello, > > I was a little annoyed with having to start up Browse to view images, > and since I had done a small toy PyGTK based image viewer widget > sometime back, I decided to put that in an activity over the weekend. > You can download it from > http://dev.laptop.org/~sayamindu/bundles/imageviewer/ImageViewer-1.xo > It can zoom and rotate images. However, it cannot put anything in the > journal, since a workaround for #8155 would mean eating up a lot of > storage space (as I would have to create copies of the images for each > journal entry). > A screenshot is at > http://dev.laptop.org/~sayamindu/Captura%20de%20pantalla_1.png > The code lives in Git: > http://dev.laptop.org/git?p=users/sayamindu/imageviewer- > activity;a=tree > > Comments, patches and brickbats are welcome :-). > Thanks, > Sayamindu Hey, fantastic, thanks! :-) --Gary P.S. Any hints on changing the default activity that takes charge of a mime type? ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Image Viewer Activity
On 29 Sep 2008, at 19:49, Bert Freudenberg wrote: > > Am 29.09.2008 um 11:46 schrieb Sayamindu Dasgupta: > >> On Mon, Sep 29, 2008 at 11:57 PM, Gary C Martin >> <[EMAIL PROTECTED]> wrote: >>> On 29 Sep 2008, at 17:13, Sayamindu Dasgupta wrote: >>> >>>> A screenshot is at >>>> http://dev.laptop.org/~sayamindu/Captura%20de%20pantalla_1.png >>>> The code lives in Git: >>>> http://dev.laptop.org/git?p=users/sayamindu/imageviewer-activity;a=tree >>>> >>>> Comments, patches and brickbats are welcome :-). >>>> Thanks, >>>> Sayamindu >>> >>> Hey, fantastic, thanks! :-) >>> >>> --Gary >>> >>> P.S. Any hints on changing the default activity that takes charge >>> of a mime >>> type? >>> >> >> No clue on how to set the default activity associated with a mimetype >> :-(. If anyone has any ideas, please let me know :-). > > > /usr/share/sugar/data/mime.defaults Thanks Bert, that trick works a treat. I guess this needs to be exposed at some future point in the Control Panel UI, or at least something that can be over-ridden by a local deployment with a customisation key. Imave viewing workflow with the Journal just got a whole bunch smoother! --Gary P.S. Sayamindu, want an SVG icon to go with it? Or do you have something planned? I was thinking just a rectangular picture frame with a very simple mountain/sun/cloud type thing. ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Image Viewer Activity
On 30 Sep 2008, at 15:58, Sayamindu Dasgupta wrote: On Tue, Sep 30, 2008 at 7:57 PM, Gary C Martin <[EMAIL PROTECTED]> wrote: P.S. Sayamindu, want an SVG icon to go with it? Or do you have something planned? I was thinking just a rectangular picture frame with a very simple mountain/sun/cloud type thing. Yeah - an SVG icon would be awesome. My inkscape skills are horrible, so I did not dare try to modify the icon of the the helloworld activity ;-). -sdg- Just mock-ups for review, these are not svg format yet (I usually hand code the svg to keep cruft to a minimum). Any strong opinions out there regarding the design? One thing I am on the fence about is inclusion of a spy-glass, hanging over the bottom right of frame. That would say more 'viewer activity' and less 'image file', which is where this is closer to just now. However, adding a spy-glass would make the icon more fussy and require I ditch most of the picture detail (ending up more of a rectangle + spy-glass and maybe corner of a mountain/sun/ something). <><><> Feedback welcome (as I don't see much Sugar related visual design discussed going on around here). --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Image Viewer Activity
On 29 Sep 2008, at 17:13, Sayamindu Dasgupta wrote: > A screenshot is at > http://dev.laptop.org/~sayamindu/Captura%20de%20pantalla_1.png > The code lives in Git: > http://dev.laptop.org/git?p=users/sayamindu/imageviewer- > activity;a=tree > > Comments, patches and brickbats are welcome :-). No brickbats (or patches), but just wanted to report one (very minor) Image Viewer misbehaviour. I noticed today that if I open an image, and then rename it within Image Viewer, it generates one of those "Keep Error" warnings about loosing all changes. The new name does actually change correctly. This error seems to crop up on a number of activities so I'm not sure if it's a Sugar bug or some common issue catching out Activity authors. Regards, --Gary P.S. No one seems to have raised any issues yet with the icon sample I posted, so if you're happy with it, and I get no other feedback, I'll turn it into a SVG at end of tomorrow (though I may also try a version with a looking-glass partially over the image frame). ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] another response time
On 1 Oct 2008, at 13:49, Mikus Grinbergs wrote: >> as you probably installed previously the Wikipedia activity, my guess >> is that the jffs2 gc thread was taking most of the CPU. > > If I understand correctly, this raises the possibility that other > actions performed *prior* to the launching of an Activity can > noticeably affect the time it takes to launch that Activity. > > Would someone else please launch XaoS, and see what kind of > "response time for the launch" they get? > > Tried it again, after the XO had sat there overnight (having now > hopefully done everything it needed to, for jffs2 housekeeping). > For me, the "launch screen" for XaoS pulsed for 100 seconds before > the "activity screen" was drawn. [My guess is that it is > calculating the fractal picture before showing it.] Hi Mikus, XaoS on my XO B4, launches instantly. No seriously, it's absolutely the fastest launching activity. Here's the rub, because its so quick, it even beats the launcher window getting going, the working activity is hidden behind the launcher pulse effect window, which now can't tell that the activity is actually already running so does its blind 'I'll sit here and strobe for a fixed time-out because I have no idea what happened.' Take a look in the frame and you'll see the default grey circle that you can switch to. Worth a ticket if there's not one already, it's an interesting case in how quick XO-1 HW really is with the right software (must be and absolutely massive price being paid currently for having the Pyhton environment I'd guess, but I'm sure there is a whole heap of optimisation to be made if/when made a dev cycle focus and team resources made available). Made some great strides for 8.2, fingers crossed for 9.1. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] content bundle development
On 5 Oct 2008, at 17:48, Walter Bender wrote: > You should only need an index.html file that points to your PDF. > > > content="0;url=file:///home/olpc/Library/[bundle name]/[PDF > name].pdf"> > > > In the library/library.info file, there should be an activity_start > entry as per: > > activity_start = index.html > > In theory, make_index.py reads this line from the info file when > generating its index. Philippe, why not just distribute the pdf, as a pdf? What benefit is there in making a single pdf into Library bundle (unless you're just testing the process)? I must admit to not liking some of the old Library content, much of it Browse just copies into the Journal, then you have to resume the new pdf entry with Read, if you forget something is a pdf and have already viewed it, you end up with multiple copies in the Journal. Seems a bit backwards to me, I guess it makes the Library interface a zip archive utility for installing pdfs into the Journal. Apologies if you were just testing the bundle process. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Question from Uruguay
On 6 Oct 2008, at 15:27, Walter Bender wrote: > I agree that it isn't very obvious from the Activities page how to > find the Actvities/All page. I can imagine a > non-native-English-speaking child not having an easy time of it > either. Seems the pendulum has swung pretty far towards G1G1 and away > from kids. > > -walter Yea, as an Activity developer it confused me too. Took me a while to spot the All link (usually skip past all the -now out of date - noise at the top of the Activities page). Still also some what confused about where I can edit wiki Activity release versions, as there seem to be even more pages with links now, and many are now locked. I guess we're in lock-down/panic mode for a while until G1G1v2 details/ workflow clears through. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] alt-tabbing to the Journal
On 7 Oct 2008, at 16:31, Eben Eliason wrote:
> On Tue, Oct 7, 2008 at 7:43 AM, Martin Dengler <[EMAIL PROTECTED]
> > wrote:
>> On Tue, Oct 07, 2008 at 12:21:23PM +0200, Tomeu Vizoso wrote:
>>> have we reached any consensus on [alt-tabbing to the Journal]?
>>
>> No, based on http://dev.laptop.org/ticket/6251
Clearly a contentious issue :-) apparently split somewhat between
Sugar running on the OLCP XO-1 hardware, vs. running on vanilla PC
hardware.
>>> Perhaps someone that cares about changing the current behavior could
>>> do a summary of the arguments on each side?
>>
>> *Perhaps* there are only two opposing views; I am biased but will
>> attempt to summarize the pro (removing-from-alt-tab-list) and the
>> con (keep-it-as-is-now) views:
>>
>> Pro:
>>
>> 1. One never wants to Alt-Tab to the journal
>> 2. there is a dedicated key for getting to it
>> 3. the journal should be treated more like a zoom level ("lower" than
>> the home view).
>> 4. Unnecessarily makes itself the active activity when focused, so
>> now
>> the Activity/F4 key as well as the search key are dedicated to it.
>>
>> Cons:
>> 1. One sometimes wants to Alt-Tab to the journal
>> 2. The journal is positioned like an activity in the Frame and UI
>
> You missed one of my biggest reservations in the cons:
>
> 3. The Journal wouldn't appear beneath the XO at boot.
>
> It's important to me that the Journal be one click (yes, click; not
> just keystroke) away when the child boots the laptop. The current
> activity gets positioned here under the XO, so in the current paradigm
> this happens implicitly. I suppose you could argue that the Journal
> still gets shown here if no activities are open at all, but then we're
> special casing it a bit. There may be other ideas for exposing the
> Journal in Home as well, but nothing brought up so far as really dealt
> with this dilemma.
-- snip --
> I'll just toss one more idea out there, for argument's sake. The
> Journal, as a "place for storing things", might actually be related to
> a device instead (since it's UI may be the same or similar to that for
> USB/SD/etc.). We could put it down there to meaningfully distinguish
> it. This still leaves problem 3, of course.
As someone who thinks the Journal is part of the system and NOT and
Activity, I just wanted to throw yet another idea out there: Make what
we now call Journal, another view of the Home view. There, darn, now I
said it out loud...
Some musings:
1) Ideally, the Home view should soon inherit the behaviour that you
can resume recent Journal entries by default, so cutting away a _lot_
of the Journal entry cruft that gets added accidently when starting
fresh activities. This behaviour would be a little like a recent, per
Activity, activity filter for the Journal, so why not make the current
full Journal view just another home view? You could think of the
current Home view as a Journal filtered view of available new
Activities (supporting some pretty icon layouts).
2) The search key would still switch to Home journal view automatically.
3) It would be one click from boot up (as a new toolbar icon next to
favourites, and list view). Or could even become the users default
home view, and be zero clicks away if that's what the kid likes.
4) Current behaviour is a little wired regarding what you are left
looking at when stopping an Activity. I seem to end up staring at
either a Home view, the Journal, or some other running Activity.
Making Journal be a Home view would at least cut down that randomness
by one ;-)
5) Journal would be off the alt-tab list :-b
6) Journal would be a more core part of the Sugar UI, rather than its
current special case Activity status sitting among a potential crowded
top frame.
7) Want to an Activity? Goto the Home view, all (past and future)
Activities are there.
--Gary
___
Sugar mailing list
Sugar@lists.laptop.org
http://lists.laptop.org/listinfo/sugar
Re: [sugar] alt-tabbing to the Journal
On 8 Oct 2008, at 03:51, Walter Bender wrote: > The bottom line is that, at least as far as the XO is concerned (and > other machines with limited memory and no swap) the list of activities > to tab through, with or without the Journal, is going to be a short > list, so is it really such a pressing issue? For tabbing, I think one frustration here is the current issue with tabbing where the delay is way too short before an Activity you're tabbing past is pulled into focus (I'd argue there should be no auto delay focus, only focus when alt key is lifted, allowing you to easily skip items in the stack). Currently in 8.2, accidentally tabbing the 'wrong way' through the active instances on the XO and getting shown the wrong thing (usually Journal given only having a few activities running) is painful enough time wise to distract you from whatever goal you had in mind. Example: TurtleArt, and 2 x ImageViewers showing some screen shots of different brick code you want to reference. Tabbing between TurtleArt and the images you trying to reference is constantly intruded upon by the redraw, and update of Journal – if you're just mucking around, it's less of a pain, but if you're actually trying to 'get stuff done' it can get quite annoying pretty quickly. > I'd love the same passion developed to some of the issues/topics that > impact the learning. How can we make the Journal better, regardless of > how we open it and regardless of whether we consider it an activity or > part of Sugar core? I guess most interested parties on the sugar list are more technical than pedagogical types. Both my parents were teachers, and when computers started to make their way into some of their lessons/labs, way back when, I seem to remember they would come home somewhat bemused, having been handed boxes of cables and computer kit. As an ~11yr old I would set it up, get things going, and show them how to load-up and use the software. It's an interesting generational shift, I wonder what new idea is going to come along and be so far from our expectations that we'll be too inflexible as adults to really pick it up well (here already?). Maybe it's just a personality trait thing and not age at all; I guess I know enough people my age who I wouldn't trust to safely 'shut down' an operating system without being given a lesson or two first ;-) OK. Journal, and its related use, have some UI improvement possibilities that could be targeted (and I think a few might be targeted already for work), without having to solve the big 'impact on learning' type wider research/study goals. Some things that come to mind just now (in no special order and I'm sure most have been discussed already at some point): - Sort view by creation date, not just by last modification date. Currently when you resume something, even just to take a look, it pulls it out of the time context of other entries it was created alongside. One click, and last weeks essays narrative/reflection is lost (the photos you took, the chat discussions you had with classmates, the audio you recorded, the picture you painted etc). - Filter view for starred items only, a single click way to quickly hide the unwanted. - Improve the 'Anything' pop-up UI. It takes me about 4-5sec of scrolling to get to the bottom of the Activity and mime file type list. And worse, if you do scroll way down, it takes just as long to get the Journal back to default after your search. I guess ideally this would become a custom palette grid of some kind, perhaps with just icons and mouse over text for the full names to save space. Another option could be for a short list of the most frequently used N activities (or the current Home view favourites), and then a 'more...' end item that would reveal a large slide-out, below toolbar dialogue with all installed activities and file types listed. Actually, you could cut to the chase and have an 'Anything' button that just triggers a slide down alert panel with all installed activities. - Realtime scrolling so you can just grab, drag, and look as it goes past. Currently, if what I'm after is not on the first page, and I think it's more than a page or two away, it might as well be infinitely far away. It's then time to try and remember the activity object type, or some text/metadata and start typing until it (hopefully) makes it onto page one. - Text search works reasonably well for me, but as mentioned already, some kind of slide-out alert to prompt for an Activity title, tags, star, possibly description (though I can't say I've ever meaningfully used the description field) would make a large difference in Journal entry quality. Think the dialogue will need to auto countdown and dismiss with sensible default values where ever possible. This feature could be really tough to make work without annoying everyone. Perhaps could also do with a "don't
Re: [sugar] journal is hard (was Re: notes from the field - Mongolia)
On 9 Oct 2008, at 19:57, Mikus Grinbergs wrote: > Elana Langer wrote from Mongolia: >> basically when teachers and students try to find their work (write, >> record, etoys) in the journal it is hard for them to locate it - >> especially if it is more than a few days old. This is why everyone is >> desperate to save their projects on USB keys. > > My perception of the above statement is that it is an indictment of > the ability of Sugar (vs. traditional computing) to be a convincing > tool for teachers (and for the students those teachers influence). > > When users are "desperate to save their projects on USB keys" > (something that was not a principal intent of Sugar), there is > something out of whack. Yes, this is an interesting custom getting started. I've been installing and running both release and development builds on an XO B4 since January. Managed to loose my Journal content just once, and that was a development build while I was jumping between old- data store and new data-store changes. I still had all the individual files but (my best guess), some other necessary custom magic index file for the DS had been damaged. With that said, I've not knowingly lost a Journal entry in all that time. I'm tempted to think that in these reported cases, the entries are all still in the Journal, and it's the difficulty in locating them again that is the primary issue. Given that assumption, making sure both teachers and students give their work meaningful titles may make a world of difference for them. One thing I like to do is use the title to help group entries logically together. Example: Turtle lesson plan question 1 Turtle lesson plan question 2 Turtle lesson plan question 3 Turtle lesson plan question 4 ... etc Turtle lesson plan question notes Turtle lesson plan screenshots I can then switch to Journal and type 'turtle lesson plan' for all of this to appear, or 'lesson 2' just for that lesson plan etc. You could also use the tag field, and/or the description field, but they are currently hidden away in the Journal and not quick enough to get to or find. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [IAEP] Narrative.
On 10 Oct 2008, at 14:26, Tomeu Vizoso wrote: > On Fri, Oct 10, 2008 at 3:02 AM, Bill Kerr <[EMAIL PROTECTED]> wrote: >> On Fri, Oct 10, 2008 at 12:27 AM, Michael Stone >> <[EMAIL PROTECTED]> wrote: >>> >>> Bill, >>> >>> Here's a short dialogue between myself, Ben Schwartz, Martin >>> Dengler, >>> and Bobby Powers on my interpretation of "narrative" as it might >>> apply >>> to a user interface designed for "engaging children in the world of >>> learning": >>> http://wiki.laptop.org/go/User:Mstone/Commentaries/Sugar_2 > > Do we have any proposals of changes to Sugar so it better supports > learning in light of the reflections on "narrative"? One random thought that overlaps with some ideas on Activity help... What if Activity and Content bundles were one and the same. You could have bundles that just hold an Activity to install, or just have Content for the library, or more interestingly have it hold both an Activity and library Content. For a concrete example, I could see myself writing a handful of web pages as part help, and part guide, to viewing and understanding the Moon, it's phases, some traditions, stories etc. I do not want to bloat out the Moon Activity UI with help tabs, buttons, and pages of text and images formatted in some weird GTK encoding. The Activity should be clean and light and focused on it's function. All the 'narrative' material should go into the library as html web content (pdf's can be nice but are resource intensive and have interaction issues of their own). It would be great if by installing Moon.xo, the bundle could also contain some library content. Actually this is what the Mac OSX does. Applications contain what is pretty much some indexed html help files that the system auto adds to it's help engine when you install an Application. My MoonDock app uses this to provide a page or two of instruction about the Moon. I guess I could provide something similar today by making two bundles, one of html library content, and one of the Activity bundle. Maybe there are benefits to this dual bundle arrangement (separate the Activity from documentation translation tasks; only install what you need to preserve nand space)? --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] [RELEASE] Moon 8
Hi all, Just released Moon-8, available from: sources (thanks to Simon for uploading): http://dev.laptop.org/pub/sugar/sources/moon-activity/Moon-8.tar.bz2 bundled: http://wiki.laptop.org/images/5/59/Moon-8.xo NEWS * Updated empty NEWS file with actual news * Added pt_BR.po translation (from Gabriel Menini). * Corrected some word translations for Spanish. * Added some revised Spanish translation changes from Gabriel Menini. --Gary ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
