Re: [sugar] notes from the field - Mongolia
Mikus Grinbergs [EMAIL PROTECTED] writes: Tagging isn't as much of an issue as being able to save files to a USB key easily. I'm trying to think of why a kid would want to save files to a USB key. Normally, except for off-loading objects to a school repository (a process about which I know nothing), 'files' would be kept at the XO itself, and not on removable storage devices. Maybe we should not only think in terms of purposes, but also in terms of causes: what makes children want to save files to USB stick? What I've seen is that children wants to save to a USB stick because they are told so by teachers, and teachers wants to save to a USB stick because they often lost files and are afraid of losing more... (I've not seen a school server in action, so I cannot discuss whether saving to a USB looks safer for teachers/children than saving to a USB stick.) -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] notes from the field - Mongolia
Marco Pesenti Gritti [EMAIL PROTECTED] writes: On Mon, Oct 6, 2008 at 6:33 PM, Erik Garrison [EMAIL PROTECTED] wrote: In my mind the fundamental problem is that users aren't required to fully qualify names for their work. Doing so seems to lie outside of one of the core points of Sugar's design (There are no files, folders, or applications. -- http://sugarlabs.org/go/Main_Page). Is it conceivable that we could change this feature of the system in future releases to clarify data management on Sugar-running XOs? You keep repeating this and it makes no sense. As Eben said we need to encourage people to tag and name things. Saying that it's outside the Sugar philosophy is nonsense. I think we could have two modes: the one Sugar currently uses, where no specific name is required to store a journal entry, and one in which the user is required to name the journal entry when the activity is storing it for the first time. For example, in the first mode Atl-1 would do a screenshot as it does right now. In the second mode Alt-1 would bring up a window querying for the name of the screenshot. Whether users are encouraged or not to actually name and tags things on the XO can be influence by such UI features - no? -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Image Viewer Activity
Sayamindu Dasgupta [EMAIL PROTECTED] writes: 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 Nice! Here is a fr.po file for it. ImageViewer.fr.po Description: Binary data -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [RELEASE] PlayGo 5
Andrés Ambrois [EMAIL PROTECTED] writes: - Improved exception handling when starting GnuGo - Updated Spanish translation Here is a french translation. fr.po Description: Binary data -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] LiveCD LiveUSB
Hi David, are the LiveCD and LiveUSB already uploaded somewhere? Thanks, David Farning [EMAIL PROTECTED] writes: Thanks for your support on the LiveCD and LiveUSB. We now have a script that builds liveCDs and LiveUSBs. The script pulls the latest packages from the SugarTeam PPA and addeds it to the 8.4 liveCD. Where do you think we should host the build scripts and the isos? -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] PlayGo v2 and v3
Andrés Ambrois [EMAIL PROTECTED] writes: I have put up the xo bundle for PlayGo version 3. I didn't announce v2 cause it was still lacking some features (like scoring at game end), which it now has. I *love* it! Thanks a lot for this work. I posted a small blog entry on OLPC France blog: http://olpc-france.org/blog/?p=25 -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] #8041 HIGH 9.1.0: Sugar lacks a Trash/Recycle bin system
Eben Eliason [EMAIL PROTECTED] writes: The issue of deletion confirmation is covered under ticket http://dev.laptop.org/ticket/7859. I flagged it as blocks?:8.2.0, but I don't think it is going to be nominated as a blocker at this point unless there is a strong push for it. I'm not fond of confirmation alerts, no problem if this is not in 8.2.0! This is, at least for now, independent of the trash can issue itself. To me it's not completely independant: a trashbin (or an equivalent) feature) functions as a virtual confirmation system. I think having a trashbin somehow spares the cost of confirmation alerts. The Journal should be following a lazy-deletion strategy, making it really no different from the trash can you speak of. Ok, fair enough The only difference is how the erased but not yet truly gone files get represented to the user. Yes, that the difference I'm interested in :) I do recognize this. The one detail we could add to potentially solve this argument is a button which turns on/off visibility of erased entries. Let me guess: this button is usually what the trashbin icon does? That is, a button which basically shows and hides trashed files by toggling their visibility inline within the Journal, in addition to a way to view only those files as well. Ok, good. The button itself would be visible. The trashed files wouldn't be visible until the button pressed. When the button is pressed, only trashed entries are listed. 3. Lazy-erased: file stored locally on the XO, but rendered differently to indicate transient state Ok, great - for me lazy-erased files should not be displayed unless the trashbin button is pressed (in which case only trashed files are listed. Sorry to repeat myself...) If we want, we can be a bit more clever about which cases require deletion confirmation (based upon whether or not the action results in a recoverable state), but we could simply ask for confirmation all the time for consistency. Or, never. Never :) (never as a default - maybe this could be customisable.) If the default is to rely on confirmation, this will not encourage users to lazy-erase their files. With no backup system, it's becomes more important to encourage them to be selective about what they keep, encouraging regular cleaning up. I hope this clarifies my position on this subject a bit, and paints a picture which is really just a different perspective on the usual trash can metaphor, rather than an abandonment of it. Ok, great - things are very clear now. Can't wait for it to be implemented :) -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] [OLPC Security] P_READ_LOGS
Mikus Grinbergs [EMAIL PROTECTED] writes: The easiest way to present logs, especially failure logs, is to make them available through the standard Journal/Datastore interface. For example, we have some agreement that when an Activity fails to launch, the failure should appear as such in the Journal time-view, connected to an object representing the log file for that failure. This log object has a text type, and so can naturally be opened by any Activity that accepts this type. No additional permissions are required. The user is responsible for determining when to provide both sensitive data and P_NETWORK to the same Activity. I find the Journal interface to be cumbersome. I also do not believe the Journal ought to be cluttered up with footprints a kid would probably not be able to do anything about. -1. I also think failure logs don't naturally fit into the current Journal. They are a non-desirable side-effect of an activity, not an activity per se. But it could fit okay into the next versions of the Journal, where some kind of pre-filtering would let the user see only the most important entries for him. Failure logs would then be low-level entries, along with other logs (particularily mail logs, when we'll have a native mail client on the XO.) -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Question about write from Niue -OLPC training
Martin Sevior [EMAIL PROTECTED] writes: Think that write might not allow the image to be imported if it is too big. Can you tell me how large the images are? What are their dimensions in pixels? We've had had the same issue in Haïti, with both 656 and 703 builds, and with images as taken with the Record activity (I don't know ths size and dimensions.) Is this fixed in newer (stable) builds? -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Proposal: Activity developers mailing list
Another simplement argument: this will be clearer for users to know where to send feedback. If you have a question about a particular activity, ask on the activity list. For other questions ask on the Sugar list. -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Proposal: Activity developers mailing list)
Martin Langhoff [EMAIL PROTECTED] writes: FWIW, Sugar + activities are still somewhat tightly coupled, as Sugar and the underlying OS API are changing. As long as that is true, to maintain an activity to a good standard, you have to keep an eye on devel@ and/or [EMAIL PROTECTED] My rule of thumb is to try and keep people together -- recommending filters sometimes -- until the traffic gets so heavy *and* a distinct subcommunity can be split off. IMHO neither is true here (yet!). (Fair enough. In any case, my awareness about Sugar and the activities development is not strong enough to dispute about the relevance of such a list -- 'was just dropping a few opinions.) -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
[sugar] Framework for managing the activities (= symfony project)
Sébastien Adgnot just pointed me out that the guys behind the symfony project have developed a plugin management framework for they own needs: http://www.symfony-project.org/ http://www.symfony-project.org/plugins/ http://www.symfony-project.org/blog/2008/07/31/plugins-have-a-new-home The structure looks pretty neat, and maybe something like that could be useful on top of the git page for the activities. FWIW. -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] specifying what services Activities may use
Erik Garrison [EMAIL PROTECTED] writes: Maybe what I'm suggesting boils down to integrate this core activities in the environment so that people installing Sugar won't have to install them separatly. Just the same way that installing a standard Fedora will install Gnome (will install evolution (etc...)). What I'm suggesting is that this step requires global optimization wrt which activities are 'core'. This is difficult, as various deployments have different usage patterns and require different sets of software. Yes, I understand this, but it's quite reasonable to assume that each deployment will like the list of activities that is listed in the Core category (cf. http://wiki.laptop.org/go/Category:Core) I have often built debian systems using debootstrap to pull in the most minimal typically used system components. On top of such a system customization is easy. I am suggesting that we may wish to develop a similar system so that our downstream developers can have more flexibility in customizing their systems. Activites could be Sugar-core and not XO-system core. Agreed. We could have something like: ~$ apt-get install sugar = Install Sugar with a default set of activities ~$ apt-get install sugar-extra-activities = Install a set of extra activities ~$ apt-get install sugar-nepal-activities = Install a specific bundle with extra activities If Sugar installation takes this route, then there is something else that has to be defined: the default favorite activities. Each deb package above should define the default set of favs. And maybe there could be a way of importing someone's favs easily, whatever the extra package people installed. My 2 cents... -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] specifying what services Activities may use
Benjamin M. Schwartz [EMAIL PROTECTED] writes: Jerry Williams wrote: | Seems like this problem for linux was solved with RPM. | With rpm if something is missing for something you want to install, it | complains and won't let you install it. That's not really the problem we're discussing. We're talking about the case in which you try to install an old bundle onto a new build, or vice versa. Another reason why each build should come with a default bundle. If countries develop their bundles independantly from Sugar evolution, then the problem will just be more painful. If countries have a default bundle to refer to when developing their own, it could help solving dependancy issues indirectly. The default activities could be selected so that 90% of the dependancies for other (known) activities are satisfied. At least, a default bundle combined with a nice GUI for xo-get.py would discourage installation of old bundles on newer builds. And you guys could get rid of the scary red warning on the wiki :) -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Design Question
Marco Pesenti Gritti [EMAIL PROTECTED] writes: On Fri, Jul 18, 2008 at 11:17 PM, Martin Dengler [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2008 at 04:53:31PM -0400, Greg Smith wrote: [...] The new Home View in 8.2.0 will have three available styles. We need to pick one to default on first upgrade or install. [...] http://wiki.laptop.org/go/Image:Home_Ring_View8.2.png +1 +1 +1 for the ring view! -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Home Design: Free Layout View
Martin Dengler [EMAIL PROTECTED] writes: A ring of 50 icons is a better organization than a free-form desktop of 50 icons. I have a vision: keep the ring and let the user open it and turn it into a worm (or a necklace, the icons being the perls)... then several worms? Worms close together could form a ring again and bigs rings would easily split into big worms. ... Introducing TLR: The Liquid Ring ! ... Thus you would have macro-manipulation, flexibility, etc. I know, easier to imagine it rather than implementing it, sorry. But please don't go for The Lost of The Ring! -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Home Design: Free Layout View
Wade Brainerd [EMAIL PROTECTED] writes: I have a vision: keep the ring and let the user open it and turn it into a worm (or a necklace, the icons being the perls)... then several worms? Worms close together could form a ring again and bigs rings would easily split into big worms. Wow, now that's an idea, totally original! I could see tags or activities as the heads of the worms... (And quite frankly, Worm has always been the best computer game ever!) -- Bastien ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
