[Sugar-devel] [RELEASE] sugar-0.84.8
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar/sugar-0.84.8.tar.bz2 == News == * intro screen doesn't unfreeze dcon #1601 * font configuration through gconf #1584 * Journal list view: jumping back to first page when popping up a palette #1235 * Process non-ds object in the right way in Journal #1262 * multiple copies of activity opened upon resume #1276 * ObjectChooser does not show file content of external USB devices #881 * Several Access Points with the same essid #330 * add star badge to APs that are in our connections #19 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [RELEASE] sugar-toolkit-0.84.6
== Source == http://download.sugarlabs.org/sources/sucrose/glucose/sugar-toolkit/sugar-toolkit-0.84.6.tar.bz2 == News == * font configuration through gconf #1584 * multiple copies of activity opened upon resume #1276 * ObjectChooser displays USB media files, but fails to access file (datastore traceback) #1241 * Telepathy doesn't create log files #1178 * Do not fail while displaying activity icon for bundles in Journal #1175 ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] adding 3G devices support to sugar
On Wed, Dec 2, 2009 at 3:04 AM, Martin Abente mabe...@paraguayeduca.org wrote: I have successfully extended jarabe/model/network.py, so we can load-in a gsm connection, tested it with my app (gsmbridge) and it works, tomorow ill clean up the code, add the control panel and the device icon part. Cool. Can you give us a list of kernel modules that will work with this, so we can look at building them for the XO1/1.5 kernels? They'll probably be split off in a separate rpm, but easily installable. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] adding 3G devices support to sugar
In Uruguay we need USB_SERIAL_OPTION for 3G Modems. Martin, I could test your work using 3G Modems. I could help programming the control panel and the device icon too. On Wed, Dec 2, 2009 at 10:31 AM, Martin Langhoff martin.langh...@gmail.comwrote: On Wed, Dec 2, 2009 at 3:04 AM, Martin Abente mabe...@paraguayeduca.org wrote: I have successfully extended jarabe/model/network.py, so we can load-in a gsm connection, tested it with my app (gsmbridge) and it works, tomorow ill clean up the code, add the control panel and the device icon part. Cool. Can you give us a list of kernel modules that will work with this, so we can look at building them for the XO1/1.5 kernels? They'll probably be split off in a separate rpm, but easily installable. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] adding 3G devices support to sugar
Very sorry for the late response Martin, Yeah we need OPTION module first, because its works with most of the modems we tested, but i believe theres still other modules we would need for ZTC modems that are very common also, if anyone can help me finding this would be great, :) On Wed, 2 Dec 2009 13:31:17 +0100, Martin Langhoff martin.langh...@gmail.com wrote: On Wed, Dec 2, 2009 at 3:04 AM, Martin Abente mabe...@paraguayeduca.org wrote: I have successfully extended jarabe/model/network.py, so we can load-in a gsm connection, tested it with my app (gsmbridge) and it works, tomorow ill clean up the code, add the control panel and the device icon part. Cool. Can you give us a list of kernel modules that will work with this, so we can look at building them for the XO1/1.5 kernels? They'll probably be split off in a separate rpm, but easily installable. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On 30.11.2009, at 21:24, Bert Freudenberg wrote: On 30.11.2009, at 20:02, Aleksey Lim wrote: On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote: On 11/30/2009 10:00 AM, Bert Freudenberg wrote: On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - Sorry, for the mixup. Yes we could add a way for the dotted version number, and your idea sounds good. How does Bert's idea from above sounds to others? +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? That would link the old and new version field - I thought of them as being independent. Basically, the old activity_version field would be a like a build number, increasing for every build, as we did before. It would be optional in Sugar 0.88. The real user-visible version number would be the dotted one in a different field. An activity author who wants to support both could keep incrementing activity_version, and assign dotted version numbers independently. - Bert - Thinking about this, for Etoys it doesn't really make a difference. We can as well switch to the dotted-only scheme. So unless other activity authors feel backwards compatibility is needed, just use whatever is simplest. Is this already written up as a feature? Couldn't find it. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [ANNOUNCE] GetBooks version 4
Sayamindu, Last night I ran the same test on the same XO, no changes to anything, and I was able to find every word I searched for and download PDFs successfully. I can't account for why the other test failed. There was nothing in the log to suggest anything. I *did* notice some odd search results, though. In addition to the books I was searching for (by author's last name, usually), I'd find some that I couldn't explain. I didn't have a chance to write down these results, so I have to rely on my memory, but in this case the results were similar whether I used your latest Get Books or the first one I checked out of the git branch. When searching for burton I also got a bunch of Andre Norton novels. When searching for mars I also got Mrs. Dalloway by Virginia Woolf. When searching for griffith I think I also got some H.G. Wells titles. There was nothing in the metadata you show for these books to suggest how these got matched. James Simmons On Tue, Dec 1, 2009 at 1:16 PM, Sayamindu Dasgupta sayami...@gmail.com wrote: Hi, I just tried it and it works fine for me. Could you take a look once again, and also check the log. Thanks, Sayamindu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Tue, Dec 1, 2009 at 5:54 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Nov 30, 2009 at 9:40 PM, Wade Brainerd wad...@gmail.com wrote: When deleting an object from the Journal that is an activity bundle, we ought to display an alert with a scary icon. The alert should clearly state that Journal entries will no longer be able to be opened until the activity is reinstalled. Majority of 6 year old will not understand that. The best way to handle this, I think, is to let kids delete activities but also keep a reference to the source in the form of an update URL or similar, so that fetching the activity automatically when an instance of it is resumed can be done. There's additional UI work there, and we can't guarantee connectivity, etc., but it would help reduce the overhead involved. (I'm not suggesting we shouldn't find ways to make it clearer when a deletion is happening, either, but as noted, the dialog may not work in practice with the target audience.) Some of the other operations Aleksey mentioned, like upgrading activities, ought to display similar alerts. Gentlemen, alerts do not work with young users. We have to just DTRT, or provide actions that are very clearly different (and even then...). On a more general note, this discussion has many hints of the action/object views that have been tossed around for some time now. This specifically addressed the conflict between the desire to manage all objects and the desire to have the Journal reflect only the actions of the child. In this split, the action view shows actions, which reference one or more objects (activities, people, devices, etc.) This would contain only references to things the children have done themselves. The object view shows objects, which is a more traditional view of everything that's around to be manipulated. Any preinstalled activities would appear in the object view by default, and thus be accessible by kids to copy, share, modify, etc. (and as they do, new actions will be created to record that). Ultimately, the object view would look much like the current Journal view does, and the actions view would be a bit friendlier. One benefit of this is that young kids need only look at the actions view, while those that wanted more control could dig into the objects directly. Eben cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On Thu, Dec 03, 2009 at 12:23:37AM -0500, Eben Eliason wrote: On Tue, Dec 1, 2009 at 5:54 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Nov 30, 2009 at 9:40 PM, Wade Brainerd wad...@gmail.com wrote: When deleting an object from the Journal that is an activity bundle, we ought to display an alert with a scary icon. The alert should clearly state that Journal entries will no longer be able to be opened until the activity is reinstalled. Majority of 6 year old will not understand that. The best way to handle this, I think, is to let kids delete activities but also keep a reference to the source in the form of an update URL or similar, so that fetching the activity automatically when an instance of it is resumed can be done. There's additional UI work there, and we can't guarantee connectivity, etc., but it would help reduce the overhead involved. (I'm not suggesting we shouldn't find ways to make it clearer when a deletion is happening, either, but as noted, the dialog may not work in practice with the target audience.) Some of the other operations Aleksey mentioned, like upgrading activities, ought to display similar alerts. Gentlemen, alerts do not work with young users. We have to just DTRT, or provide actions that are very clearly different (and even then...). On a more general note, this discussion has many hints of the action/object views that have been tossed around for some time now. This specifically addressed the conflict between the desire to manage all objects and the desire to have the Journal reflect only the actions of the child. In this split, the action view shows actions, which reference one or more objects (activities, people, devices, etc.) This would contain only references to things the children have done themselves. The object view shows objects, which is a more traditional view of everything that's around to be manipulated. Any preinstalled activities would appear in the object view by default, and thus be accessible by kids to copy, share, modify, etc. (and as they do, new actions will be created to record that). Ultimately, the object view would look much like the current Journal view does, and the actions view would be a bit friendlier. One benefit of this is that young kids need only look at the actions view, while those that wanted more control could dig into the objects directly. Good catch, what about more explicit following user works all time with the same objects but from different views and add Action view as a Journal plugin(and maybe make it default) to [1](technically we need addition data to form actions view but for users it could be the same (as in objects view) objects but organized to actions. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [Please Read] SoaS v2 RC Issues
Hi all, this is a very quick update on the current state of SoaS v2. We discovered on Tuesday that we wouldn't be able to ship content due to legal concerns that was originally intended to be included and discussed how to proceed in the last two days. Specifically, we won't include anything that contains a CreativeCommons NC or ND clause, or any equivalent license. Hence, we're going to ship only books from Project Gutenberg. I've taken the task of replacing all books in question with adequate alternatives. Please speak up if you've any book suggestion that: * is illustrated * comes from Project Gutenberg * is preferably in a language other than English (not required) On the other hand, while testing another RC locally in a VM, I figured that Read crashed when attempting to *scroll* through an .epub file. Additionally, one isn't able to open the content afterwards. This is almost certainly a blocker, but we *will* need to create the master image this afternoon (Central European Time). If you've a spare minute, please help us out here! Thanks, --Sebastian ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
