[Sugar-devel] HelloWorld documentation in sugarlabs wiki
Hi, do we have those resources available on the sugarlabs wiki already? http://wiki.laptop.org/go/Activity_tutorial http://wiki.laptop.org/go/Making_Sugar_Icons And I guess would be cool to get the hello-world example as well in git. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HelloWorld documentation in sugarlabs wiki
On Thu, Jul 2, 2009 at 10:13, Simon Schampijersi...@schampijer.de wrote: Hi, do we have those resources available on the sugarlabs wiki already? http://wiki.laptop.org/go/Activity_tutorial http://wiki.laptop.org/go/Making_Sugar_Icons And I guess would be cool to get the hello-world example as well in git. If we are asking, I would also like to have these ones: http://wiki.sugarlabs.org/go/Low-level_Activity_API http://wiki.laptop.org/go/Python_Style_Guide Regards, Tomeu Regards, Simon ___ 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] [Systems] Enabling https://translate.sugarlabs.org
[cc += sugar-de...@] On Thu, 2009-07-02 at 10:25 +0200, Sascha Silbe wrote: On Thu, Jul 02, 2009 at 06:31:13AM +0200, Bernie Innocenti wrote: And even then, rather than paying the pizzo (*) to the SSL mafia, we coul create our own Sugar Labs CA and install our certificate in the bundle used by Browse. IIRC, OLPC was also doing this. What about including the CACert one instead? Sure, they're having (organisational) trouble again, but to be honest I nevertheless trust them way more than any commercial CA. I used to trust them more, but many others are pulling the CACert certificate from their bundles because it finally got audited for security and *failed* to demonstrate sufficiently secure procedures for master key handling. Frankly, I'm very disappointed in CACert: this auditing saga has been going on for *ages* without good communication on their side. What's missing now? What's the ETA for it? By giving everybody the expectation they will become *the* free accredited CA soon, they're preventing others from doing the same for real. I'm sure they'd promptly help CACert if they needed money, hardware, voluteers, software development.. *anything!* I don't know what to think: SSL mafia conspiracy or CACert incompetence? BTW: Does Browse fall back to the system supplied CAs (/etc/ssl/certs)? Debian already includes CACert and IIRC some others as well. I'm pretty sure Firefox only uses its own separate bundle in Debian, because its strict branding policy certainly demands not altering the list of trusted CAs who have been going trough an expensive corrup^H^H^H^H^H^Hvalidation process demanded by the Mozilla Foundation. One can still choose any CA they like in the bundles used by Iceweasel or Browse. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On 02.07.2009, at 06:08, Sascha Silbe wrote: [1] contains my thoughts on a VCS based datastore rewrite - a bit fleshed out now, but still not finished. The most important part for now is that I'd like to change the find() API call to take two parameters instead of one. I'm slightly surprised you find this minor change the most important part. [1] http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html How do you intend transfer of file ownership to be handled? Have you though about interaction with Rainbow? The only way to access meta data for a given object seems to be find()? Is there metadata associated with the object in general or just in each version? How to access/distinguish those? In update() I assume you submit the old version_id and get back the new version_id? And since you do not care about compatibility you should change the spelling to follow the D-Bus naming conventions: http://dbus.freedesktop.org/doc/dbus-specification.html#naming-conventions - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] HelloWorld documentation in sugarlabs wiki
On 07/02/2009 11:45 AM, Tomeu Vizoso wrote: On Thu, Jul 2, 2009 at 10:13, Simon Schampijersi...@schampijer.de wrote: Hi, do we have those resources available on the sugarlabs wiki already? http://wiki.laptop.org/go/Activity_tutorial http://wiki.laptop.org/go/Making_Sugar_Icons And I guess would be cool to get the hello-world example as well in git. http://git.sugarlabs.org/projects/hello-world Done, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] playing w/ i18n
subzero, i have been having a lot of discussions about i18n w/ the ever patient sayamindu and reading a lot on the subject. However, I haven't accomplished much. Here is my current playground http://karma.sugarlabs.org/yes_no/ am currently wrangling how to generate a meaningful po file from an html page. -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] playing w/ i18n
I did a little tweaking of html2po to get http://pastebin.be/19509 The label tags need to be fixed - but apart from that I think the rest of that is OK. May be we can try and build upon html2po and see how it works out. Thanks, Sayamindu 2009/7/2 Bryan Berry br...@olenepal.org: subzero, i have been having a lot of discussions about i18n w/ the ever patient sayamindu and reading a lot on the subject. However, I haven't accomplished much. Here is my current playground http://karma.sugarlabs.org/yes_no/ am currently wrangling how to generate a meaningful po file from an html page. -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [ANNOUNCE] Feature proposal for 0.86
Dear Community, I created a Feature Template [1]. Please move your proposals in the Roadmap[2] and follow the process [3] for inclusion in the release. The process is based on the Fedora Feature policy - just (hopefully) simplified a bit. Please have in mind that this release cycle is rather short, so get your proposals in :) I hope that we can track down better the status of each feature and make our cycle even more successful. Thanks, Simon [1] http://wiki.sugarlabs.org/go/Features/Feature_Template [2] http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.86#Ideas [3] http://wiki.sugarlabs.org/go/Features/Policy ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] playing w/ i18n
i think it is key that we can mark strings as translatable without making the html invalid. I like the idea of picking up certain tags by default like title, meta tags, and then picking up h1, h2, etc. unless they have the lang= attribute specified. Then it would be nice to pick up everything else that belongs to the class=translate. What u think? I am looking thru src of html2po and it appears that the primary fault is that it uses the horrible HTMLParser.py webunit.HTMLParser.py instead of something more sane like lxml or beautiful soup it may be easier to swap out HTMLParser for lxml than improve html2po on top of HTMLParser I will play w/ lxml and html2po to see what i can work out. re: beautiful soup vs. lxml . My heart is w/ lxml, enjoyed working w/ it before and seems to have better css selectors than beautiful soup. tks again for your help sayamindu! On Thu, 2009-07-02 at 16:54 +0530, Sayamindu Dasgupta wrote: I did a little tweaking of html2po to get http://pastebin.be/19509 The label tags need to be fixed - but apart from that I think the rest of that is OK. May be we can try and build upon html2po and see how it works out. Thanks, Sayamindu 2009/7/2 Bryan Berry br...@olenepal.org: subzero, i have been having a lot of discussions about i18n w/ the ever patient sayamindu and reading a lot on the subject. However, I haven't accomplished much. Here is my current playground http://karma.sugarlabs.org/yes_no/ am currently wrangling how to generate a meaningful po file from an html page. -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to create a project on SugarLabs gitorious?
On Thu, Jul 2, 2009 at 6:13 AM, Bastien bastiengue...@googlemail.comwrote: Bastien b...@laptop.org writes: See this wiki page: http://wiki.sugarlabs.org/go/Activity_Team/Git_FAQ That's it, thanks. I have uploaded my id_dsa.pub key on my account. I have initiated the local git repo. Here is my .git/config file: , | [core] | repositoryformatversion = 0 | filemode = true | bare = false | logallrefupdates = true | [remote origin] | url = gitori...@git.sugarlabs.org:helpfr/mainline.git | fetch = +refs/heads/*:refs/remotes/origin/* | [push] | default = matching ` ~$ git push origin master ask for a password. Which is weird because afaik I didn't protect my public key with a password. Entering anything here results in an access denied or wrong path error I cannot escape. Any idea what I could try? Is it possible you got blacklisted? See the first question, which was recently added to the top of this list, http://wiki.sugarlabs.org/go/Activity_Team/Git_FAQ#Help.21_I_suddenly_can.27t_connect_to_Gitorious.21 . --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Datastore API changes (was: Re: Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting)
On Thu, Jul 02, 2009 at 11:52:01AM +0200, Bert Freudenberg wrote: [1] contains my thoughts on a VCS based datastore rewrite - a bit fleshed out now, but still not finished. The most important part for now is that I'd like to change the find() API call to take two parameters instead of one. I'm slightly surprised you find this minor change the most important part. Let's say the most important part that's not version related. :) I'm quite open about how much compatibility too keep, BTW - it's just that since we're breaking API in a significant way anyway we can also try to provide one that's more clear on what it does and less things for historical reasons. E.g. the activity_id, object_id, ... are not that well defined in general [3] and also named differently in different parts of the code (uid vs. object_id). Giving better names might help activity authors understand what's going on (I for one had a hard time doing so). Preferably we'd do such changes now rather than after calling a release 1.0 and having a manifold number of activity developers (= API users). [1] http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html How do you intend transfer of file ownership to be handled? checkout: * data store hardlinks entry into target directory * files read-only and directories read-write for activity (= ensure link-breaking) Commit is similar, now mentioned in the document as well. As to how exactly to implement the actual ownership setting, I need to talk to Michael about that. It might even get handled entirely within Rainbow (rainbow-sugarize to be exact), e.g. by creating directories with appropriate rights on startup. See also [2], Nr. 1. Have you though about interaction with Rainbow? For sure. :) I'd even like to run the data store isolated as well in the long run (principle of least privilege). The only way to access meta data for a given object seems to be find()? Yes, though we might keep get() as a wrapper for compatibility or easier understanding by activity authors. But technically get() is just a special case of find(), so no need to duplicate it. Is there metadata associated with the object in general or just in each version? For now with each version. We might choose to make some of it global later. In update() I assume you submit the old version_id and get back the new version_id? Exactly. The workflow already described that, now the API description does as well. And since you do not care about compatibility you should change the spelling to follow the D-Bus naming conventions: http://dbus.freedesktop.org/doc/dbus-specification.html#naming-conventions Will check them out, thanks for mentioning! [2] http://wiki.laptop.org/go/Rainbow/Current_Situation#Implementation [3] http://git.sugarlabs.org/projects/sugar-toolkit/repos/mainline/blobs/master/src/sugar/activity/activityhandle.py#line41 CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/ signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Trimming down ling wiki names
On Thu, Jul 2, 2009 at 7:45 AM, Simon Schampijer si...@schampijer.dewrote: Hi Fred, it might makes sense to trim down our long wiki names. As we heavily use categories now - this might not be an issue. How about we do: http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.84 - http://wiki.sugarlabs.org/go/0.84/Roadmap and http://wiki.sugarlabs.org/go/Development_Team/Release/Releases/Sucrose/0.84- http://wiki.sugarlabs.org/go/0.84/Notes same for 0.82 and 0.86. What do you think? Can you do this without breaking current links? Regards, Simon That should be possible and fits with the idea that DFarning reported of broadening the involvement in the platform development. I'll start with 0.82, http://wiki.sugarlabs.org/go/0.82, and leave wiki redirects to catch those linking from off-site links in blogs and other references. --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Trimming down ling wiki names
On 07/02/2009 03:06 PM, Frederick Grose wrote: On Thu, Jul 2, 2009 at 7:45 AM, Simon Schampijersi...@schampijer.dewrote: Hi Fred, it might makes sense to trim down our long wiki names. As we heavily use categories now - this might not be an issue. How about we do: http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.84 - http://wiki.sugarlabs.org/go/0.84/Roadmap and http://wiki.sugarlabs.org/go/Development_Team/Release/Releases/Sucrose/0.84- http://wiki.sugarlabs.org/go/0.84/Notes same for 0.82 and 0.86. What do you think? Can you do this without breaking current links? Regards, Simon That should be possible and fits with the idea that DFarning reported of broadening the involvement in the platform development. I'll start with 0.82, http://wiki.sugarlabs.org/go/0.82, and leave wiki redirects to catch those linking from off-site links in blogs and other references. --Fred Awesome. Thanks, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Datastore API changes (was: Re: Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting)
On 02.07.2009, at 14:52, Sascha Silbe wrote: On Thu, Jul 02, 2009 at 11:52:01AM +0200, Bert Freudenberg wrote: [1] http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html How do you intend transfer of file ownership to be handled? checkout: * data store hardlinks entry into target directory * files read-only and directories read-write for activity (= ensure link-breaking) Commit is similar, now mentioned in the document as well. That means the activity is responsible for deleting the file it committed once the DS is finished? That's a burden on activity developers the previous DS did care of. If at all possible, cleaning up should be left to the DS. Also activities should not submit new entries while the previously submitted one hasn't been fully committed yet would be another burden. If an activity needs to store a couple of items it would have to queue the write commits and issue them one by one? That would be a silly requirement, in particular since the DS needs to work on commits simultaneously anyway (because two activities might commit at the same time). - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] customizing activity launch (was Re: [IAEP] View Slides an alternative to PowerPoint?)
(moving to devel-list) Yes indeed, but we still have no obvious technical solution for this in Sugar. Adding a pre-made project to the Journal might work, but currently it would be resumed regularly and modified on stopping. It would need to be marked as a template so that when keeping it, a copy is saved by default. However, finding this template in the Journal would be hard. Making it into a separate activity bundle seems somewhat pretentious to me, it would just be Etoys under a different name, right? And it would suffer from the same resume-by-default problem like Etoys, in that the Sugar UI makes it not easy enough to launch a fresh instance. Ideas welcome. - Bert - On 02.07.2009, at 14:51, Walter Bender wrote: I still wish there was a launch-this-project-and-we'll-have-taken-care-of-steps-1–5-below-for- you Etoys bundle kicking around that we could just ship with the Journal. -walter On Thu, Jul 2, 2009 at 6:31 AM, Bert Freudenbergb...@freudenbergs.de wrote: Since this does not seem to be obvious: It's really simple to create nice presentations in Etoys, there is not even scripting involved: 0. Start a fresh Etoys copy (in Strawberry, right-click the Etoys icon and choose start rather than resuming the latest project) 1. click new project 2. From the supplies box in the toolbar, drag out a book. 3. Use the top-left button to toggle more book controls 4. Use the + button to add pages 5. Place text on a page by dragging out a Text from the supplies box, resize after right-clicking by dragging the yellow handle 6. Import images either via the clipboard or directly from the Journal (using the Journal icon in the top right) 7. Add annotations using the paint tool 8. Add visual and sound effects for turning pages in the book's menu. 9. Play with the options in the book's menu (like view pages full screen) etc. ... and of course you can place scripted objects / animations on the pages too if you like. Also, the Etoys QuickGuides (accessible from the left-most button in the toolbar) have an entire section on Books. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On 07/01/2009 03:48 PM, Eben Eliason wrote: On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Limalsr...@member.fsf.org wrote: On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: Hi, in this week we want to talk about the Journal and datastore [1] improvements planned for 0.86. The Library activity [2] has shown some interesting concepts as well. What are the common goals, how to move forward, where to invest? Just some thoughts before meeting. For new Journal we have: * action-centric view * object-centric view In my mind they are quite different, action-centric view relates to timelines when object-centric is more like a browsing of objects(sort, tag them etc). So, what about using Library's code base for object-centric view? I think Library and Scott's Journal 2 are both good sources to pull from. From a UI perspective, however, I think keeping to something very much like the existing mockups is the best course, both because this is a familiar ground for users (the initial vision for object view is nearly identical to the current Journal UI) and because it's important to keep it simple while finding intuitive ways to extend functionality. I think exposing tags, adding tag autocompletion, and improving the selection filters in the toolbar are good places to start. Adding the grid view to expose object previews would also be a great addition! I guess you mean this one with object preview? http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#10 For audio objects we might even be able to add a simple playback functionality here. I like the preview idea - as when skimming for pictures (when not associated with an activity and therefore having a thumbnail) is quite hard - you have to open it in Imageviewer first. Another mid hanging fruit would be the selecting of several objects and applying actions to them. http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#6 In general - I like the little improvements steps that has a lot of impact. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to create a project on SugarLabs gitorious?
Frederick Grose fgr...@gmail.com writes: Is it possible you got blacklisted? See the first question, which was recently added to the top of this list, http://wiki.sugarlabs.org/go/Activity_Team/ Git_FAQ#Help.21_I_suddenly_can.27t_connect_to_Gitorious.21. I don't think so, I tried from several different IP adresses. What can I do? -- Bastien ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] customizing activity launch (was Re: [IAEP] View Slides an alternative to PowerPoint?)
On Thu, Jul 2, 2009 at 15:26, Bert Freudenbergb...@freudenbergs.de wrote: (moving to devel-list) Yes indeed, but we still have no obvious technical solution for this in Sugar. Adding a pre-made project to the Journal might work, but currently it would be resumed regularly and modified on stopping. It would need to be marked as a template so that when keeping it, a copy is saved by default. However, finding this template in the Journal would be hard. Making it into a separate activity bundle seems somewhat pretentious to me, it would just be Etoys under a different name, right? And it would suffer from the same resume-by-default problem like Etoys, in that the Sugar UI makes it not easy enough to launch a fresh instance. Isn't this very similar to the site-specific-browser thing? Regards, Tomeu Ideas welcome. - Bert - On 02.07.2009, at 14:51, Walter Bender wrote: I still wish there was a launch-this-project-and-we'll-have-taken-care-of-steps-1–5-below-for- you Etoys bundle kicking around that we could just ship with the Journal. -walter On Thu, Jul 2, 2009 at 6:31 AM, Bert Freudenbergb...@freudenbergs.de wrote: Since this does not seem to be obvious: It's really simple to create nice presentations in Etoys, there is not even scripting involved: 0. Start a fresh Etoys copy (in Strawberry, right-click the Etoys icon and choose start rather than resuming the latest project) 1. click new project 2. From the supplies box in the toolbar, drag out a book. 3. Use the top-left button to toggle more book controls 4. Use the + button to add pages 5. Place text on a page by dragging out a Text from the supplies box, resize after right-clicking by dragging the yellow handle 6. Import images either via the clipboard or directly from the Journal (using the Journal icon in the top right) 7. Add annotations using the paint tool 8. Add visual and sound effects for turning pages in the book's menu. 9. Play with the options in the book's menu (like view pages full screen) etc. ... and of course you can place scripted objects / animations on the pages too if you like. Also, the Etoys QuickGuides (accessible from the left-most button in the toolbar) have an entire section on Books. - Bert - ___ 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] customizing activity launch (was Re: [IAEP] View Slides an alternative to PowerPoint?)
On 02.07.2009, at 15:36, Tomeu Vizoso wrote: On Thu, Jul 2, 2009 at 15:26, Bert Freudenbergb...@freudenbergs.de wrote: (moving to devel-list) Yes indeed, but we still have no obvious technical solution for this in Sugar. Adding a pre-made project to the Journal might work, but currently it would be resumed regularly and modified on stopping. It would need to be marked as a template so that when keeping it, a copy is saved by default. However, finding this template in the Journal would be hard. Making it into a separate activity bundle seems somewhat pretentious to me, it would just be Etoys under a different name, right? And it would suffer from the same resume-by-default problem like Etoys, in that the Sugar UI makes it not easy enough to launch a fresh instance. Isn't this very similar to the site-specific-browser thing? Regards, Tomeu Does that deal in any way with resuming? - Bert - Ideas welcome. - Bert - On 02.07.2009, at 14:51, Walter Bender wrote: I still wish there was a launch-this-project-and-we'll-have-taken-care-of-steps-1–5-below- for- you Etoys bundle kicking around that we could just ship with the Journal. -walter On Thu, Jul 2, 2009 at 6:31 AM, Bert Freudenbergb...@freudenbergs.de wrote: Since this does not seem to be obvious: It's really simple to create nice presentations in Etoys, there is not even scripting involved: 0. Start a fresh Etoys copy (in Strawberry, right-click the Etoys icon and choose start rather than resuming the latest project) 1. click new project 2. From the supplies box in the toolbar, drag out a book. 3. Use the top-left button to toggle more book controls 4. Use the + button to add pages 5. Place text on a page by dragging out a Text from the supplies box, resize after right-clicking by dragging the yellow handle 6. Import images either via the clipboard or directly from the Journal (using the Journal icon in the top right) 7. Add annotations using the paint tool 8. Add visual and sound effects for turning pages in the book's menu. 9. Play with the options in the book's menu (like view pages full screen) etc. ... and of course you can place scripted objects / animations on the pages too if you like. Also, the Etoys QuickGuides (accessible from the left-most button in the toolbar) have an entire section on Books. - Bert - ___ 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] How to create a project on SugarLabs gitorious?
On Thu, Jul 2, 2009 at 06:13, Bastien bastiengue...@googlemail.com wrote: Bastien b...@laptop.org writes: See this wiki page: http://wiki.sugarlabs.org/go/Activity_Team/Git_FAQ That's it, thanks. I have uploaded my id_dsa.pub key on my account. Please try again with RSA, use of DSA is discouraged. -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Thu, Jul 2, 2009 at 9:29 AM, Simon Schampijersi...@schampijer.de wrote: I guess you mean this one with object preview? http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#10 For audio objects we might even be able to add a simple playback functionality here. I like the preview idea - as when skimming for pictures (when not associated with an activity and therefore having a thumbnail) is quite hard - you have to open it in Imageviewer first. I think adding support for basic audio and video previews would be a fantastic addition! Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] CACert in Browse (was: Re: [Systems] Enabling https://translate.sugarlabs.org)
On Thu, 2009-07-02 at 12:44 +0200, Sascha Silbe wrote: On Thu, Jul 02, 2009 at 11:51:03AM +0200, Bernie Innocenti wrote: Sure, they're having (organisational) trouble again, but to be honest I nevertheless trust them way more than any commercial CA. I used to trust them more, but many others are pulling the CACert certificate from their bundles because it finally got audited for security and *failed* to demonstrate sufficiently secure procedures for master key handling. No, it didn't get audited. The audit got aborted due to lack of reaction from the board during the audit (at least that's my interpretation of what's been posted on the mailing list the last few days). Frankly, I'm very disappointed in CACert: this auditing saga has been going on for *ages* without good communication on their side. What's missing now? What's the ETA for it? What is still missing is people who _actively_ care for it. People to step up for the board. See the mailing list for all the gory details. By giving everybody the expectation they will become *the* free accredited CA soon, they're preventing others from doing the same for real. Personally I don't think having more than one community CA is a bad thing, so what's holding back others from doing it instead of stalling on CACert? I don't know what to think: SSL mafia conspiracy or CACert incompetence? I'd say severe lack of manpower, right from the beginning (when Duane was still chief). BTW: Does Browse fall back to the system supplied CAs (/etc/ssl/certs)? Debian already includes CACert and IIRC some others as well. I'm pretty sure Firefox only uses its own separate bundle in Debian, because its strict branding policy certainly demands not altering the list of trusted CAs who have been going trough an expensive corrup^H^H^H^H^H^Hvalidation process demanded by the Mozilla Foundation. Well, the branding policy is exactly the reason it's called Iceweasel in Debian instead of Firefox. Not sure it uses the system CA certificates, though - for one thing I've added CACert to Mozilla ages ago and for the other I'm using it very rarely anyway. Speaking of trust, my MUA says that your last message had a bad GPG signature: gpg: armor header: Version: GnuPG v1.4.9 (GNU/Linux) gpg: Signature made Thu Jul 2 12:44:37 2009 CEST using RSA key ID 4C1770DA gpg: using subkey 4C1770DA instead of primary key A13AC1B1 gpg: using PGP trust model gpg: BAD signature from Sascha Silbe sascha-...@silbe.org gpg: textmode signature, digest algorithm SHA1 Ok, the game is over. Now tell us who you are and what you did of the real Sascha! -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting
On Wed, Jul 1, 2009 at 1:42 PM, Aleksey Limalsr...@member.fsf.org wrote: On Wed, Jul 01, 2009 at 09:48:23AM -0400, Eben Eliason wrote: On Tue, Jun 30, 2009 at 6:22 PM, Aleksey Limalsr...@member.fsf.org wrote: On Tue, Jun 30, 2009 at 09:43:38PM +0200, Simon Schampijer wrote: Hi, in this week we want to talk about the Journal and datastore [1] improvements planned for 0.86. The Library activity [2] has shown some interesting concepts as well. What are the common goals, how to move forward, where to invest? Just some thoughts before meeting. For new Journal we have: * action-centric view * object-centric view In my mind they are quite different, action-centric view relates to timelines when object-centric is more like a browsing of objects(sort, tag them etc). So, what about using Library's code base for object-centric view? I think Library and Scott's Journal 2 are both good sources to pull from. From a UI perspective, however, I think keeping to something very much like the existing mockups is the best course, both because this is a familiar ground for users (the initial vision for object view is nearly identical to the current Journal UI) and because it's important to keep it simple while finding intuitive ways to extend functionality. I think exposing tags, adding tag autocompletion, and improving the selection filters in the toolbar are good places to start. I'm a bit concerned by having(many?) filter combo-boxes in toolbar[1], maybe having sidebar(like in Library[2]) could make more sense(btw user can hide sidebar to browse objects in full window mode), moreover we could use several views for entries in sidebar: list(tree) view, tag cloud[3]. I think a solution something like Scott's Journal2 mockups proposed could work nicely here, without the need to add a sidebar. Collapsing the text popup menus to simple icons (eg. an activity icon for the what filter, an XO for the who filter, etc.) would be a great improvement, both making the UI more visual, less cluttered, and also providing us with palettes instead of popup menus for adjusting the filters. These palettes could, as you suggest/show, even have grid or list views; the when palette could have a calendar or a timeline; we could have search fields in the palette for narrowing down long lists of tags, people or activities, etc. This is really just a rearrangement of what you're proposing, without eating up all the extra screen real estate for a persistent sidebar, because I think that space really is needed for looking at the contents of the Journal itself. Adding the grid view to expose object previews would also be a great addition! I also like that Library has started to support sharing. I think there have been a number of interesting proposals for how this might work in the Journal, and I'd love to see the feature added. Perhaps by selecting View Journal in the palette for a buddy it would be possible to see anyone's shared content. The original idea of Library in case of sharing was shared(common) collections of sugar objects i.e.: * user #1 creates collection(Library object), creation means choosing filter for local objects(user tags, properties like mime-type, another DS fields) * user #1 shares his collection(Library object) * user #2 can join #1's session and see(download) objects from his collection * user #2 can add his local objects to this shared collection(by setting filter for his local objects) so, all joined users can view all(from all users) shared objects in one place I see. Cool. Having View Journal option in buddy menu makes sense as well I agree. But in that case we should provide possibility to mark objects that can be shared(I guess sharing all local objects by default is not a nice idea). Right. This would be essential. There's definitely some thought that needs to be done here. Scott had an interesting proposal which basically exposed the Journal (or some subset of it) as an RSS feed. This was really neat, because it meant we could build a UI for someone else's Journal in Sugar, populating it with that data, but also that these feeds could be shared globally, for anyone with an RSS reader to benefit from. That's a really powerful approach in my mind, and there is some starter code lying around as a proof of concept already! Eben And Library's method doesn't fit well for this(since it uses filter and adding one particular object to collection(shared list) is a problem). I thought about this issue in context of Library.. and what about: Extend conception of Favorites to Pins. The idea is: - having implicit list of Library-collections/shared-collections means problem to support these lists(if user deletes some object, sugar should update all these collection lists implicitly) - contrariwise, having in object implicit list of all collection links that this object participates in, means also some odd implicit job to
Re: [Sugar-devel] Datastore API changes (was: Re: Journal --- Sugar-Developers meeting REMINDER (2 July, 2009 - 14.00 (UTC)) --- irc.freenode.net, #sugar-meeting)
On Thu, Jul 2, 2009 at 15:10, Bert Freudenbergb...@freudenbergs.de wrote: On 02.07.2009, at 14:52, Sascha Silbe wrote: On Thu, Jul 02, 2009 at 11:52:01AM +0200, Bert Freudenberg wrote: [1] http://git.sugarlabs.org/projects/versionsupport-project/repos/mainline/blobs/master/datastore-redesign.html How do you intend transfer of file ownership to be handled? checkout: * data store hardlinks entry into target directory * files read-only and directories read-write for activity (= ensure link-breaking) Commit is similar, now mentioned in the document as well. That means the activity is responsible for deleting the file it committed once the DS is finished? That's a burden on activity developers the previous DS did care of. If at all possible, cleaning up should be left to the DS. Also copying a file can be quite expensive, specially on the XO-1. If we are going to have a slow commit operation, we may need a way to get progress so we can expose it in the UI. Regards, Tomeu Also activities should not submit new entries while the previously submitted one hasn't been fully committed yet would be another burden. If an activity needs to store a couple of items it would have to queue the write commits and issue them one by one? That would be a silly requirement, in particular since the DS needs to work on commits simultaneously anyway (because two activities might commit at the same time). - Bert - ___ 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] SoAS Testing with XS
Hi Greg, good to hear from you again. That bug report is just a backtrace. No info on whether the Sugar client was actually using the Jabber server (via Gabble) or not. Or what action was taken, what results seen, or versions of things. Pretty hard to tell what's going on. Are you in touch with Caroline? Can you get her to flesh out the bug? It would also be interesting to get the logs from ejabberd on the server. cheers, martin On Thu, Jul 2, 2009 at 5:37 PM, Greg Smithgreg.sm...@envista.com wrote: Hi All, Has anyone tried testing Sugar on a Stick, Strawberry release with collaboration? That is, are there any examples of SoAS computers seeing other SoAS computers in the Network Neighborhood and then sharing Activities? I’m interested in Jabber examples (on XS or other Jabber server) and “local” examples where computers are on the same L3 network. Any links to documentation or test cases is appreciated. This looks to be an important topic for the Gardner School deployment. Caroline has already uncovered a bug in this area http://dev.sugarlabs.org/ticket/1014 If anyone is up for working on it, we can get more details and background on the bug report. Thanks, Greg S ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- 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] SoAS Testing with XS
From the terminal I could see it switching back and forth between gamble and salut No internet access for me now but if you need more infi Please put requests for more info on tickets with good directions and Tuesday I ahould have time in the school to debug Thanks Sent from my iPhone Caroline Meeks 617-395-7966 On Jul 2, 2009, at 8:51 AM, Martin Langhoff martin.langh...@gmail.com wrote: Hi Greg, good to hear from you again. That bug report is just a backtrace. No info on whether the Sugar client was actually using the Jabber server (via Gabble) or not. Or what action was taken, what results seen, or versions of things. Pretty hard to tell what's going on. Are you in touch with Caroline? Can you get her to flesh out the bug? It would also be interesting to get the logs from ejabberd on the server. cheers, martin On Thu, Jul 2, 2009 at 5:37 PM, Greg Smithgreg.sm...@envista.com wrote: Hi All, Has anyone tried testing Sugar on a Stick, Strawberry release with collaboration? That is, are there any examples of SoAS computers seeing other SoAS computers in the Network Neighborhood and then sharing Activities? I’m interested in Jabber examples (on XS or other Jabber server) a nd “local” examples where computers are on the same L3 network. Any links to documentation or test cases is appreciated. This looks to be an important topic for the Gardner School deployment. Caroline has already uncovered a bug in this area http://dev.sugarlabs.org/ticket/1014 If anyone is up for working on it, we can get more details and background on the bug report. Thanks, Greg S ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- 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
[Sugar-devel] On datastore object IDs
We've been talking a lot about how datastore version 3 (?) should be structured. I'd like to propose (purely to initiate discussion) that it be structured as follows: The datastore is a collection of objects, which are arranged into version trees. Each object has a tree_id, which is an arbitrary unique identifier (string) for the version tree. The datastore will generate a new tree_id each time a new tree is created. Each object also has a version_id, which indicates the object's place in the tree. The version_id could take the form of a dotted decimal string like 4.5.2.1. Some objects are Actions, and some objects are Documents. Each Action must retain a list to all Documents associated with that Action, each represented as a (tree_id, version_id) pair. Each Document must retain a reference to the Action with which it is associated, represented as a (tree_id, version_id) pair. Each Document is only associated with a single Action; a new Action that uses a Document must always make a new version. To implement the concepts present in the current datastore, activity_id would actually be the tree_id of an Action, and object_id would be the (tree_id, version_id) pair of a Document. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 12:35 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: We've been talking a lot about how datastore version 3 (?) should be structured. I'd like to propose (purely to initiate discussion) that it be structured as follows: The datastore is a collection of objects, which are arranged into version trees. Each object has a tree_id, which is an arbitrary unique identifier (string) for the version tree. The datastore will generate a new tree_id each time a new tree is created. Each object also has a version_id, which indicates the object's place in the tree. The version_id could take the form of a dotted decimal string like 4.5.2.1. This sounds great. tree_id is far more clear. Some objects are Actions, and some objects are Documents. Each Action must retain a list to all Documents associated with that Action, each represented as a (tree_id, version_id) pair. Each Document must retain a reference to the Action with which it is associated, represented as a (tree_id, version_id) pair. Each Document is only associated with a single Action; a new Action that uses a Document must always make a new version. I disagree with this last statement. Consider the following 2 actions: 1. Painted a picture of [a tree] 2. Sent [a tree] to [friend] Both of these actions refer to the same Document, and more specifically, to the same (tree_id, version_id) pair. It seems that a Document should retain a list of all actions which reference it. To implement the concepts present in the current datastore, activity_id would actually be the tree_id of an Action, and object_id would be the (tree_id, version_id) pair of a Document. Makes sense. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] customizing activity launch (was Re: [IAEP] View Slides an alternative to PowerPoint?)
On 02.07.2009, at 18:40, Eben Eliason wrote: On Thu, Jul 2, 2009 at 9:26 AM, Bert Freudenbergb...@freudenbergs.de wrote: (moving to devel-list) Yes indeed, but we still have no obvious technical solution for this in Sugar. Adding a pre-made project to the Journal might work, but currently it would be resumed regularly and modified on stopping. It would need to be marked as a template so that when keeping it, a copy is saved by default. However, finding this template in the Journal would be hard. Making it into a separate activity bundle seems somewhat pretentious to me, it would just be Etoys under a different name, right? And it would suffer from the same resume-by-default problem like Etoys, in that the Sugar UI makes it not easy enough to launch a fresh instance. Ideas welcome. That's hard. I think one point here is that there's often a tradeoff between flexibility and simplicity (though not always). Etoys is extraordinarily powerful, and can do all kinds of awesome things, but if someone really JUST wants a simple slideshow, a tool designed just for this, with a few really basic slide templates all ready to go the moment a new activity is started might be worthwhile as well. If you take the current discussion on IAEP into account you might start to see why that's not necessarily the case. Yes it should be simple to get started, but it should not be limiting the creativity. Here the activity focus of Sugar becomes limiting, IMHO, because if you have this simple slide show activity there is no way to pull in all the other cool things you could create in Sugar. For Etoys itself, maybe some of those steps could be collapsed. Perhaps instead of clicking on new project, there are simply a number of different primitive types of projects to choose from, one of which is a book. Maybe clicking on this can set up the UI as best it can for that project, revealing those tools, adding the first page, creating a sample slide with placeholder text, etc. This would reduce those first 5 or six steps to about 2 or 3, right? Sure we can do it in Etoys (although there is only so much we can put on the start screen). But this seems like a problem that's better tackled on the Sugar scale. Besides, have you even tried the steps? If you ever worked with Etoys before in Sugar the first steps I listed are not relevant, because you always have to do them. Even for a dumbed-down activity you would have to launch it, making sure to create a new instance rather than resuming an existing one, right? I don't buy that this is too hard. I guess I should not have listed each click because people aren't trying it anyway. - Bert - ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
Walter Bender wrote: Presumably the objects themselves have unique ids, a la git, so that we can refer to the same object from multiple trees and by multiple users? (e.g., when I share something with you, it still has the same name.) Hmmm. So there are two issues here: 1. blob uuid. Each object may own a blob, and if two objects own identical blobs, then there's no good reason to store them separately on disk. Something like this is used in git, I suspect. In our case, I cannot think of any reason to expose the uuid outside the datastore itself. It might be useful for accelerating various forms of object-sharing and backup, but those operations are still behind the curtain. 2. Some sort of object name. I think I agree with you that each object should probably have a user-editable name or title. We certainly need something like this for the Actions, and so it makes enough sense to extend it to objects. However, I think that we can keep this as it currently is: a metadata attribute like any other. When I share an object with you, it may get a new tree_id and a version_id of 1, but it keeps all its metadata, including its title. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Trimming down ling wiki names
On Thu, Jul 2, 2009 at 8:06 AM, Frederick Grosefgr...@sugarlabs.org wrote: On Thu, Jul 2, 2009 at 7:45 AM, Simon Schampijer si...@schampijer.de wrote: Hi Fred, it might makes sense to trim down our long wiki names. As we heavily use categories now - this might not be an issue. How about we do: http://wiki.sugarlabs.org/go/Development_Team/Release/Roadmap/0.84 - http://wiki.sugarlabs.org/go/0.84/Roadmap and http://wiki.sugarlabs.org/go/Development_Team/Release/Releases/Sucrose/0.84 - http://wiki.sugarlabs.org/go/0.84/Notes same for 0.82 and 0.86. What do you think? Can you do this without breaking current links? Regards, Simon That should be possible and fits with the idea that DFarning reported of broadening the involvement in the platform development. I'll start with 0.82, http://wiki.sugarlabs.org/go/0.82, and leave wiki redirects to catch those linking from off-site links in blogs and other references. Yes, this transition make sense now. The original idea behind the strict hierarchy was to introduce 'wiki discipline' Unmaintained wikis tend to sprawl into messes because some authors create pages without looking to see if other similar pages already exist. Once the sprawl starts, it quickly gets out of hand. Now that Fred is tending the wiki and the basic disciple is established, it makes sense to relax the rules a bit. Call for help - - If any new participants are interested in learning more about Sugar and Sugar Labs, a few hours helping Fred tend the wiki would be a great place to get involved:) david --Fred ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- David Farning Sugar Labs www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 1:06 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Walter Bender wrote: Presumably the objects themselves have unique ids, a la git, so that we can refer to the same object from multiple trees and by multiple users? (e.g., when I share something with you, it still has the same name.) Hmmm. So there are two issues here: 1. blob uuid. Each object may own a blob, and if two objects own identical blobs, then there's no good reason to store them separately on disk. Something like this is used in git, I suspect. In our case, I cannot think of any reason to expose the uuid outside the datastore itself. It might be useful for accelerating various forms of object-sharing and backup, but those operations are still behind the curtain. 2. Some sort of object name. I think I agree with you that each object should probably have a user-editable name or title. We certainly need something like this for the Actions, and so it makes enough sense to extend it to objects. However, I think that we can keep this as it currently is: a metadata attribute like any other. When I share an object with you, it may get a new tree_id and a version_id of 1, but it keeps all its metadata, including its title. --Ben I think I was getting at something simpler, as related to your (1) above. In git, an object is unique, whether or not I pulled it, as long as I don't modify it. So I can always refer to it, even if I wasn't the one who created it. So I'd like to be able to extend (1) to include objects I share. Use case: I send you a presentation that refers to objects in the datastore. I need to send you those objects too, but I would not like to have to use some additional layer of reference. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 6:35 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: We've been talking a lot about how datastore version 3 (?) should be structured. I'd like to propose (purely to initiate discussion) that it be structured as follows: Slightly OT: Sascha mentioned a plan in the git list of using git as a backend. I pointed out a few (serious IMHO) limitations in git. My general comment is: - apps will want to work on files larger than memory - apps will want to mmap files - apps will want to create/edit multi-file projects (ie: creating websites) those are complex constraints, but should be considered. /ot cheers, martin -- 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] customizing activity launch (was Re: [IAEP] View Slides an alternative to PowerPoint?)
On Thu, Jul 2, 2009 at 1:05 PM, Bert Freudenbergb...@freudenbergs.de wrote: On 02.07.2009, at 18:40, Eben Eliason wrote: On Thu, Jul 2, 2009 at 9:26 AM, Bert Freudenbergb...@freudenbergs.de wrote: (moving to devel-list) Yes indeed, but we still have no obvious technical solution for this in Sugar. Adding a pre-made project to the Journal might work, but currently it would be resumed regularly and modified on stopping. It would need to be marked as a template so that when keeping it, a copy is saved by default. However, finding this template in the Journal would be hard. Making it into a separate activity bundle seems somewhat pretentious to me, it would just be Etoys under a different name, right? And it would suffer from the same resume-by-default problem like Etoys, in that the Sugar UI makes it not easy enough to launch a fresh instance. Ideas welcome. That's hard. I think one point here is that there's often a tradeoff between flexibility and simplicity (though not always). Etoys is extraordinarily powerful, and can do all kinds of awesome things, but if someone really JUST wants a simple slideshow, a tool designed just for this, with a few really basic slide templates all ready to go the moment a new activity is started might be worthwhile as well. If you take the current discussion on IAEP into account you might start to see why that's not necessarily the case. Yes it should be simple to get started, but it should not be limiting the creativity. Sure. Some of this falls on Sugar (the Journal, the Clipboard, etc.) to allow more interaction between various activities, in terms of using sounds, images, text, and media from one in another. Not all tools need to do everything, and making a universal turing machine of an activity isn't generally a good idea unless (as in Etoys!) that's the whole point. There's certainly a lot of room to build an activity that's really good at one thing (say, making presentations), but allows a lot of creativity in the type and manner of presentations it is capable of making. Anyway, I agree that Etoys does this well, but narrowing the focus of an activity, and accordingly its UI, doesn't inherently put a limit on creativity. There can be plenty of features and room for growth within the context of the tool and its intended goal. Here the activity focus of Sugar becomes limiting, IMHO, because if you have this simple slide show activity there is no way to pull in all the other cool things you could create in Sugar. For Etoys itself, maybe some of those steps could be collapsed. Perhaps instead of clicking on new project, there are simply a number of different primitive types of projects to choose from, one of which is a book. Maybe clicking on this can set up the UI as best it can for that project, revealing those tools, adding the first page, creating a sample slide with placeholder text, etc. This would reduce those first 5 or six steps to about 2 or 3, right? Sure we can do it in Etoys (although there is only so much we can put on the start screen). But this seems like a problem that's better tackled on the Sugar scale. Yes, likely so. Besides, have you even tried the steps? If you ever worked with Etoys I have! And loved it. Though admittedly I haven't used it in a while, now. before in Sugar the first steps I listed are not relevant, because you always have to do them. Even for a dumbed-down activity you would have to launch it, making sure to create a new instance rather than resuming an existing one, right? I don't buy that this is too hard. Yes, that's true. The start vs. resume debate has been a big one. Christian and I believed that there should be a toggle for the view, so that users could choose which default made the most sense for them. I think we should add that. A plan of action for power users, like us, was supposed to be holding down a modifier key to switch the view on the fly, so that eg. alt-clicking an activity would start it from scratch, without needing the palette. Eben I guess I should not have listed each click because people aren't trying it anyway. - Bert - ___ 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] On datastore object IDs
Walter Bender wrote: Use case: I send you a presentation that refers to objects in the datastore. I need to send you those objects too, but I would not like to have to use some additional layer of reference. Heh. We don't support inter-object dependencies. It's amazing how we keep having the same discussion over and over, though: http://lists.laptop.org/pipermail/sugar/2007-April/002210.html Maybe this time we will come to the other conclusion? --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 1:06 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Walter Bender wrote: Presumably the objects themselves have unique ids, a la git, so that we can refer to the same object from multiple trees and by multiple users? (e.g., when I share something with you, it still has the same name.) Hmmm. So there are two issues here: 1. blob uuid. Each object may own a blob, and if two objects own identical blobs, then there's no good reason to store them separately on disk. Something like this is used in git, I suspect. In our case, I That sounds fine. cannot think of any reason to expose the uuid outside the datastore itself. It might be useful for accelerating various forms of object-sharing and backup, but those operations are still behind the curtain. 2. Some sort of object name. I think I agree with you that each object should probably have a user-editable name or title. We certainly need something like this for the Actions, and so it makes enough sense to Hmm, I think that only objects have titles and user editable metadata (tags/description, etc.). If I open Write, and name that Document in the usual way, that title should be associated with that object. The action will happen to read like: Wrote [My Story] And clicking on the icon next to My Story in the action should resume the activity, but the name is actually belonging to the object that the action refers to. extend it to objects. However, I think that we can keep this as it currently is: a metadata attribute like any other. When I share an object with you, it may get a new tree_id and a version_id of 1, but it keeps all its metadata, including its title. This seem fundamentally wrong to me, but perhaps that's because I'm not actually seeing how these 2 problems you bring up are problems. Why can't a given Document (tree_id, version_id) be referenced from any number of actions? Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 1:23 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Walter Bender wrote: Use case: I send you a presentation that refers to objects in the datastore. I need to send you those objects too, but I would not like to have to use some additional layer of reference. Heh. We don't support inter-object dependencies. It's amazing how we keep having the same discussion over and over, though: http://lists.laptop.org/pipermail/sugar/2007-April/002210.html Maybe this time we will come to the other conclusion? --Ben Maybe this time is exactly why I bring it up while we are considering a refresh. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 1:23 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Walter Bender wrote: Use case: I send you a presentation that refers to objects in the datastore. I need to send you those objects too, but I would not like to have to use some additional layer of reference. Heh. We don't support inter-object dependencies. It's amazing how we keep having the same discussion over and over, though: We do. We continually avoid it because it's hard, and because it's basically orthogonal to the both versions and to actions. Actions (which exist only within the Journal) reference other objects, but the inter-object linking you bring up is not required in this scheme. Importing an image into eg. Write can (and currently does) still just embed that image in the resulting write document, instead of referencing it. This is for similar reasons to the way activity bundles work. Objects are self-contained...for better or worse. Eben http://lists.laptop.org/pipermail/sugar/2007-April/002210.html Maybe this time we will come to the other conclusion? --Ben ___ 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] On datastore object IDs
On Thu, Jul 2, 2009 at 1:31 PM, Eben Eliasone...@laptop.org wrote: On Thu, Jul 2, 2009 at 1:23 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Walter Bender wrote: Use case: I send you a presentation that refers to objects in the datastore. I need to send you those objects too, but I would not like to have to use some additional layer of reference. Heh. We don't support inter-object dependencies. It's amazing how we keep having the same discussion over and over, though: We do. We continually avoid it because it's hard, and because it's basically orthogonal to the both versions and to actions. Actions (which exist only within the Journal) reference other objects, but the inter-object linking you bring up is not required in this scheme. Importing an image into eg. Write can (and currently does) still just embed that image in the resulting write document, instead of referencing it. This is for similar reasons to the way activity bundles work. Objects are self-contained...for better or worse. Incidentally, I'm not saying we should not do it. I'm just saying that it's a really hard topic to solve that may be bigger than it looks (and it looks big), and I'm not sure if it needs to be (or even should be) solved at the same time as the other problems we're tackling. It's just an order of added complexity, with a lot of interaction implications, that's all. =) Eben http://lists.laptop.org/pipermail/sugar/2007-April/002210.html Maybe this time we will come to the other conclusion? --Ben ___ 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] On datastore object IDs
Eben Eliason wrote: Hmm, I think that only objects have titles and user editable metadata (tags/description, etc.). If I open Write, and name that Document in the usual way, that title should be associated with that object. The action will happen to read like: Wrote [My Story] And clicking on the icon next to My Story in the action should resume the activity, but the name is actually belonging to the object that the action refers to. I think sessions can have names too. If I start an instance of the Chess activity and share it with the name Bedford Middle School Chess Club Summer Tournament, then that's the name of the entire session, even if it produces multiple Documents or no Documents. extend it to objects. However, I think that we can keep this as it currently is: a metadata attribute like any other. When I share an object with you, it may get a new tree_id and a version_id of 1, but it keeps all its metadata, including its title. This seem fundamentally wrong to me, but perhaps that's because I'm not actually seeing how these 2 problems you bring up are problems. What seems wrong? What problems? Why can't a given Document (tree_id, version_id) be referenced from any number of actions? It could be. It just seemed simpler to disallow it. If editing a Document's metadata produces a new Document, as befitting our Copy-on-Write model of versioning, then the process of editing the associated_actions field produces a new version. Therefore, every time an Action adds a Document to itself, the process of adding the back-reference would produce a new version of the Document, so only one Action would ever end up referring to one version of the a Document. If editing a Document's metadata doesn't produce a new Document, then we have a hilarious race condition in which two Activities, both referencing the same Document, edit the associated_actions field at the same time, and one of them ends up getting dropped, producing a corrupted datastore. If back-references aren't stored in the Document's metadata, then either the datastore has to maintain an inverted index of the references in the Actions, or it has to perform an enormously expensive search to find which Actions are associated with a given Document. This adds complexity. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 1:40 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Eben Eliason wrote: Hmm, I think that only objects have titles and user editable metadata (tags/description, etc.). If I open Write, and name that Document in the usual way, that title should be associated with that object. The action will happen to read like: Wrote [My Story] And clicking on the icon next to My Story in the action should resume the activity, but the name is actually belonging to the object that the action refers to. I think sessions can have names too. If I start an instance of the Chess activity and share it with the name Bedford Middle School Chess Club Summer Tournament, then that's the name of the entire session, even if it produces multiple Documents or no Documents. Well, I think that the session is defined by the name provided in the current name field, regardless of whether or not a Document is created. In write, that name would refer to the Document object. In most activities, this name will map to the object. In Record, the name refers to the roll of film, which is why I thought there might be a session object in some cases. I don't think it makes sense to name actions independently of their activity sessions/objects. extend it to objects. However, I think that we can keep this as it currently is: a metadata attribute like any other. When I share an object with you, it may get a new tree_id and a version_id of 1, but it keeps all its metadata, including its title. This seem fundamentally wrong to me, but perhaps that's because I'm not actually seeing how these 2 problems you bring up are problems. What seems wrong? What problems? I thought the two items you had brought previously up were problems with the idea of associating a single object with multiple actions. Why can't a given Document (tree_id, version_id) be referenced from any number of actions? It could be. It just seemed simpler to disallow it. If editing a Document's metadata produces a new Document, as befitting our Copy-on-Write model of versioning, then the process of editing the associated_actions field produces a new version. Therefore, every time an Action adds a Document to itself, the process of adding the back-reference would produce a new version of the Document, so only one Action would ever end up referring to one version of the a Document. Metadata is attached to the version, I believe. I don't think we should be versioning metadata, so I don't think that it makes sense to create a new version when changing the metadata. If editing a Document's metadata doesn't produce a new Document, then we have a hilarious race condition in which two Activities, both referencing the same Document, edit the associated_actions field at the same time, and one of them ends up getting dropped, producing a corrupted datastore. This seems like the most plausible case. Really, though, it should be the Journal (or DS) that's responsible for setting up all of these references, and not the activities. If activities want to destroy metadata, they can destroy metadata. But I don't think the race condition exists if the activities aren't expected to make the references themselves. Or, can we put a mutex wrapper around metadata changes? Eben If back-references aren't stored in the Document's metadata, then either the datastore has to maintain an inverted index of the references in the Actions, or it has to perform an enormously expensive search to find which Actions are associated with a given Document. This adds complexity. --Ben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] SoAS Testing with XS
On Thu, Jul 2, 2009 at 17:37, Greg Smithgreg.sm...@envista.com wrote: Hi All, Has anyone tried testing Sugar on a Stick, Strawberry release with collaboration? That is, are there any examples of SoAS computers seeing other SoAS computers in the Network Neighborhood and then sharing Activities? Hi Greg, this generally works but I'm pretty sure there are bugs in the Sugar layer that affect presence reliability. I want to work on this since a long time, hopefully this weekend will tackle it. I’m interested in Jabber examples (on XS or other Jabber server) and “local” examples where computers are on the same L3 network. Any links to documentation or test cases is appreciated. This looks to be an important topic for the Gardner School deployment. Caroline has already uncovered a bug in this area http://dev.sugarlabs.org/ticket/1014 If anyone is up for working on it, we can get more details and background on the bug report. That also interests me, will ask for more information when I get to it. Thanks, Tomeu Thanks, Greg S ___ 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] On datastore object IDs
Eben Eliason wrote:
On Thu, Jul 2, 2009 at 1:40 PM, Benjamin M.
Schwartzbmsch...@fas.harvard.edu wrote:
Eben Eliason wrote:
Hmm, I think that only objects have titles and user editable metadata
(tags/description, etc.). If I open Write, and name that Document in
the usual way, that title should be associated with that object. The
action will happen to read like:
Wrote [My Story]
And clicking on the icon next to My Story in the action should
resume the activity, but the name is actually belonging to the object
that the action refers to.
I think sessions can have names too. If I start an instance of the Chess
activity and share it with the name Bedford Middle School Chess Club
Summer Tournament, then that's the name of the entire session, even if it
produces multiple Documents or no Documents.
Well, I think that the session is defined by the name provided in the
current name field, regardless of whether or not a Document is
created.
I agree.
In write, that name would refer to the Document object. In
most activities, this name will map to the object. In Record, the name
refers to the roll of film, which is why I thought there might be a
session object in some cases.
I am suggesting that there _always_ be a session object, and that this
object be the Action. This object may or may not have an associated blob.
I don't think it makes sense to name actions independently of their
activity sessions/objects.
I am suggesting a model in which the Action of using an Activity is
represented in the datastore by an object representing the session.
When I share an object
with you, it may get a new tree_id and a version_id of 1, but it keeps all
its metadata, including its title.
This seem fundamentally wrong to me, but perhaps that's because I'm
not actually seeing how these 2 problems you bring up are problems.
What seems wrong? What problems?
I thought the two items you had brought previously up were problems
with the idea of associating a single object with multiple actions.
In this particular case, I'm referring to the case of pushing a Document
to a friend over the network. I am suggesting that the Document arrives
without any version history, and without any of its Action associations,
and so gets a new Action (whose title is 'Transferred $NAME from
$SENDER') a new tree_id, and a new version_id ('1').
Why can't a given Document (tree_id, version_id) be referenced from
any number of actions?
It could be. It just seemed simpler to disallow it.
If editing a Document's metadata produces a new Document, as befitting our
Copy-on-Write model of versioning, then the process of editing the
associated_actions field produces a new version. Therefore, every time
an Action adds a Document to itself, the process of adding the
back-reference would produce a new version of the Document, so only one
Action would ever end up referring to one version of the a Document.
Metadata is attached to the version, I believe. I don't think we
should be versioning metadata, so I don't think that it makes sense to
create a new version when changing the metadata.
I don't see such a big distinction between the data and metadata. In
fact, Activities whose state is easily represented as key:value pairs can
put their entire state into the metadata, instead of storing it in a blob.
If editing a Document's metadata doesn't produce a new Document, then we
have a hilarious race condition in which two Activities, both referencing
the same Document, edit the associated_actions field at the same time,
and one of them ends up getting dropped, producing a corrupted datastore.
This seems like the most plausible case. Really, though, it should be
the Journal (or DS) that's responsible for setting up all of these
references, and not the activities. If activities want to destroy
metadata, they can destroy metadata. But I don't think the race
condition exists if the activities aren't expected to make the
references themselves. Or, can we put a mutex wrapper around metadata
changes?
It sounds like you want case 3:
If back-references aren't stored in the Document's metadata, then either
the datastore has to maintain an inverted index of the references in the
Actions, or it has to perform an enormously expensive search to find which
Actions are associated with a given Document. This adds complexity.
--Ben
signature.asc
Description: OpenPGP digital signature
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Configuring the keyboard
Hello, I just uploaded a mock-up for the control panel section used for modifying the keyboard related preferences at http://dev.sugarlabs.org/attachment/ticket/407/keyboard_cpextension.png The relevant ticket is http://dev.sugarlabs.org/ticket/407 As Eben has mentioned in one of the comments in that ticket, we need to arrive at some sort of consensus regarding the options to expose via the controlpanel. I have proposed a list of options to be included : http://dev.sugarlabs.org/ticket/407#comment:7, and I think it would be great if we can have more feedback on this. Thanks, Sayamindu -- Sayamindu Dasgupta [http://sayamindu.randomink.org/ramblings] ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 2:21 PM, Benjamin M.
Schwartzbmsch...@fas.harvard.edu wrote:
Eben Eliason wrote:
On Thu, Jul 2, 2009 at 1:40 PM, Benjamin M.
Schwartzbmsch...@fas.harvard.edu wrote:
Eben Eliason wrote:
Hmm, I think that only objects have titles and user editable metadata
(tags/description, etc.). If I open Write, and name that Document in
the usual way, that title should be associated with that object. The
action will happen to read like:
Wrote [My Story]
And clicking on the icon next to My Story in the action should
resume the activity, but the name is actually belonging to the object
that the action refers to.
I think sessions can have names too. If I start an instance of the Chess
activity and share it with the name Bedford Middle School Chess Club
Summer Tournament, then that's the name of the entire session, even if it
produces multiple Documents or no Documents.
Well, I think that the session is defined by the name provided in the
current name field, regardless of whether or not a Document is
created.
I agree.
But I also think that that name will apply to the Document itself,
most of the time. When there's a 1-1 this is natural. When the
document produces more than one Document, as in Record, we both agree
there should be some representation of the session which is
resumable. For some activities, this session might actually have a
blob of data; in others it may not.
In write, that name would refer to the Document object. In
most activities, this name will map to the object. In Record, the name
refers to the roll of film, which is why I thought there might be a
session object in some cases.
I am suggesting that there _always_ be a session object, and that this
object be the Action. This object may or may not have an associated blob.
So I guess we both agree that the default single-title naming scheme
currently employed in the UI is fine as is. We just need to figure out
exactly how that maps onto actions and objects, and how session
objects are stored and represented. I was under the assumption that
this Action object in the DS would be managed solely by the Journal,
in which case an activity that wanted to store a blob for its session
would do this in a separate object.
So taking record again, and assuming that the roll of film had a
file format of its own, would we have:
[action object], [roll of film object], [[photo 1], ...]
or just:
[action object], [[photo 1], ...]
?
I don't think it makes sense to name actions independently of their
activity sessions/objects.
I am suggesting a model in which the Action of using an Activity is
represented in the datastore by an object representing the session.
Right. So the question, I guess, is whether or not that session object
is managed by the activity, and if it contains a blob.
When I share an object
with you, it may get a new tree_id and a version_id of 1, but it keeps all
its metadata, including its title.
This seem fundamentally wrong to me, but perhaps that's because I'm
not actually seeing how these 2 problems you bring up are problems.
What seems wrong? What problems?
I thought the two items you had brought previously up were problems
with the idea of associating a single object with multiple actions.
In this particular case, I'm referring to the case of pushing a Document
to a friend over the network. I am suggesting that the Document arrives
without any version history, and without any of its Action associations,
and so gets a new Action (whose title is 'Transferred $NAME from
$SENDER') a new tree_id, and a new version_id ('1').
Hmmm, I see. Well, I'm not sure which way I like this better. I agree
we send off the object without the history and action associations,
and basically lives as the root of a new tree (new tree_id), and
associated with an Received [object] from [friend] action. It's
unclear to me that the person who sent this should also create a new
object with a new tree_id. I think not, actually. I'd expect to see a
reference to the thing it was I sent them. This is because, for
instance, I might resume that object from the Sent [object] to
[friend] action expecting to continue working on it, simply because
the fact that I sent it to them recently was the easiest way for me to
find it. I wouldn't expect to be in a new history with new metadata in
this instance.
Why can't a given Document (tree_id, version_id) be referenced from
any number of actions?
It could be. It just seemed simpler to disallow it.
If editing a Document's metadata produces a new Document, as befitting our
Copy-on-Write model of versioning, then the process of editing the
associated_actions field produces a new version. Therefore, every time
an Action adds a Document to itself, the process of adding the
back-reference would produce a new version of the Document, so only one
Action would ever end up referring to one version of the a Document.
Metadata is attached to the version, I
Re: [Sugar-devel] On datastore object IDs
Eben Eliason wrote: I agree we send off the object without the history and action associations, and basically lives as the root of a new tree (new tree_id), and associated with an Received [object] from [friend] action. It's unclear to me that the person who sent this should also create a new object with a new tree_id. I think not, actually. I didn't mean to imply otherwise. My point is merely that the unique identifier (tree_id, version_id) is not a global identifier. It will not work for Walter's problem of maintaining inter-object references while transferring objects over the network, because the tree_id will be different on the other side. It sounds like you want case 3: If back-references aren't stored in the Document's metadata, then either The hypothetical in case 3 is that we don't store the info in the metadata. I'm suggesting that we still store it in metadata, but that the activity itself isn't the one in charge of handling it. Ok. Maybe we need some new vocabulary like read/write metadata vs. read-only metadata. Action-Document references would have to live in read-only metadata, managed by the Datastore. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 2:53 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Eben Eliason wrote: I agree we send off the object without the history and action associations, and basically lives as the root of a new tree (new tree_id), and associated with an Received [object] from [friend] action. It's unclear to me that the person who sent this should also create a new object with a new tree_id. I think not, actually. I didn't mean to imply otherwise. My point is merely that the unique identifier (tree_id, version_id) is not a global identifier. It will not work for Walter's problem of maintaining inter-object references while transferring objects over the network, because the tree_id will be different on the other side. Oh! Right, of course. Sorry for the confusion. Anyway, the subtler point here, just for the sake of stating it outright, is that sending an object to someone and sharing that activity with them are (as they should be) quite different actions. In the former case, they just get the object, and can use it as the starting point for their own modifications, with their own history. In the latter case, they will wind up with an object with the same tree_id (and even version_id, for that matter) as the person who shared it. It sounds like you want case 3: If back-references aren't stored in the Document's metadata, then either The hypothetical in case 3 is that we don't store the info in the metadata. I'm suggesting that we still store it in metadata, but that the activity itself isn't the one in charge of handling it. Ok. Maybe we need some new vocabulary like read/write metadata vs. read-only metadata. Action-Document references would have to live in read-only metadata, managed by the Datastore. That seems like a reasonable split, but I'm not sure it falls on the same line as versioned/un-versioned. The document references make sense in read-only/un-versioned, but I feel like tags and titles make sense in read-write/un-versioned. Only activity state makes sense to me in read-write/versioned. Eben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
Eben Eliason wrote: Anyway, the subtler point here, just for the sake of stating it outright, is that sending an object to someone and sharing that activity with them are (as they should be) quite different actions. In the former case, they just get the object, and can use it as the starting point for their own modifications, with their own history. In the latter case, they will wind up with an object with the same tree_id (and even version_id, for that matter) as the person who shared it. If version_id is meant to be preserved across shared sessions, then: 1. If I join someone else's shared session after it has been created, then I might have version 1.1.1 but no previous version. If I join again later, I might also get 1.1.1.3.2, with a gap in my version history. 2. Even weirder, if two people produce new versions independently, they will both get the same version_id, despite being entirely distinct objects. I conclude that either (a) version_id`s cannot be preserved or (b) version_id`s must be selected so as to be unique (e.g. based on large random numbers). Ok. Maybe we need some new vocabulary like read/write metadata vs. read-only metadata. Action-Document references would have to live in read-only metadata, managed by the Datastore. That seems like a reasonable split, but I'm not sure it falls on the same line as versioned/un-versioned. I agree; they are not the same. signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 3:23 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Eben Eliason wrote: Anyway, the subtler point here, just for the sake of stating it outright, is that sending an object to someone and sharing that activity with them are (as they should be) quite different actions. In the former case, they just get the object, and can use it as the starting point for their own modifications, with their own history. In the latter case, they will wind up with an object with the same tree_id (and even version_id, for that matter) as the person who shared it. If version_id is meant to be preserved across shared sessions, then: 1. If I join someone else's shared session after it has been created, then I might have version 1.1.1 but no previous version. If I join again later, I might also get 1.1.1.3.2, with a gap in my version history. Yes, this is possible, and I believe it's acceptable. Differential storage could pose a problem, but from an experience standpoint I think this is OK. 2. Even weirder, if two people produce new versions independently, they will both get the same version_id, despite being entirely distinct objects. I conclude that either (a) version_id`s cannot be preserved or (b) version_id`s must be selected so as to be unique (e.g. based on large random numbers). I thought about this. In fact, I almost suggested in my last email that they should be random/unique. However, I second-guessed that assumption based on the following scenario (assume all objects referenced share the same tree_id): 1. Kids A and B collaborate in v_2 (assume v_1 existed previously) 2. Kids A and B separate 3. Kid A modifies v_2 to produce v_3(a) 4. Kid B modifies v_2 to produce v_3(b) 5. Kids A and B come back together 6. Kid A opens v_3(a) At this point, kid B could open either v_1, v_2, or v_3(b) If kid B opens v_1 or v_2, I would NOT expect a merge attempt to happen; we should allow two different versions of the same object to be opened (so as to copy a small piece from an old version, for instance). If kid B opens v_3(b), I would expect a merge to be attempted. Having said all that, it now seems clear to me that what I'm actually concerned with is doing merges when v_x and v_y are the most recent versions belonging to the individual who resumes them. No matter how many new versions kids A and B make, a merge should be attempted between their newest versions, but only their newest versions. So, in the end, what matters is not (as I foolishly thought when I began to write this scenario) that we only want to merge when the version numbers are the same. Silly me. Unique version numbers are good. I'm glad I laid this out, though, because I think it's crucial to getting the merge stuff you want to work on done right. Do you agree with my thought process here? Eben Ok. Maybe we need some new vocabulary like read/write metadata vs. read-only metadata. Action-Document references would have to live in read-only metadata, managed by the Datastore. That seems like a reasonable split, but I'm not sure it falls on the same line as versioned/un-versioned. I agree; they are not the same. ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
Eben Eliason wrote: Having said all that, it now seems clear to me that what I'm actually concerned with is doing merges when v_x and v_y are the most recent versions belonging to the individual who resumes them. No matter how many new versions kids A and B make, a merge should be attempted between their newest versions, but only their newest versions. ... Do you agree with my thought process here? I think I understand what you're saying. From an interaction design standpoint, you're saying that if someone deliberately opened an old version, that's a good indication that they don't want the latest stuff, so the system shouldn't automatically connect them to the shared session and merge in everyone else's changes. I can't quite say I agree. For example, I may have made some changes to the document, but decide I'd rather keep those changes local, and only merge back in with the group using some older version. Conversely, I may decide that I want to edit the latest version privately, even though there's a shared session going on, with the understanding that once I'm ready I'll be able to join and merge in. I think your suggestion is a good heuristic, but it would be nice to be able to override it. --Ben signature.asc Description: OpenPGP digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] On datastore object IDs
On Thu, Jul 2, 2009 at 3:54 PM, Benjamin M. Schwartzbmsch...@fas.harvard.edu wrote: Eben Eliason wrote: Having said all that, it now seems clear to me that what I'm actually concerned with is doing merges when v_x and v_y are the most recent versions belonging to the individual who resumes them. No matter how many new versions kids A and B make, a merge should be attempted between their newest versions, but only their newest versions. ... Do you agree with my thought process here? I think I understand what you're saying. From an interaction design standpoint, you're saying that if someone deliberately opened an old version, that's a good indication that they don't want the latest stuff, so the system shouldn't automatically connect them to the shared session and merge in everyone else's changes. Right. I can't quite say I agree. For example, I may have made some changes to the document, but decide I'd rather keep those changes local, and only merge back in with the group using some older version. Conversely, I may This is an interesting use case. Perhaps an activity could have a Merge with others (Or Join with others?) option in the activity palette anytime that another version with the same tree_id is running. decide that I want to edit the latest version privately, even though The first part here, taken alone, could be satisfied by a create a copy button. As discussed before, there should be a way to take any object and make it the root of a new tree, with a new tree_id. Of course, this pulls you out of the history completely, meaning you'll never be able to merge that back into the old history (except manually, of course). there's a shared session going on, with the understanding that once I'm ready I'll be able to join and merge in. I don't have a good suggestion for this. However, that might be OK. We might take the stance that real-time collaboration the preferred model when it's possible. It seems like enabling async collaboration even when sync collaboration is possible is only worth even thinking about if all activities have support (and good support, at that) for automatic merge. Otherwise we're just inviting conflicts. If this is really wanted, I guess I could see adding a Work alone action which would be the inverse of Join with others. Eben I think your suggestion is a good heuristic, but it would be nice to be able to override it. --Ben ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Show Must Go On - SoaS for the XO-1
S Page wrote: On Wed, Jun 17, 2009 at 2:12 AM, Martin Denglermar...@martindengler.com wrote: I'd suggest you ask sdz to make the .iso that he used to create the .img file. On Wed, Jun 17, 2009 at 12:37 AM, Sebastian Dziallassebast...@when.com wrote: I'm very pleased to announce the first early preview of a new generation of SoaS XO-1 images. Sir, could you upload the .iso for this image somewhere, maybe in a subdirectory of http://download.sugarlabs.org/soas/xoimages/ ? Heh. Well, yeah, I usually would. But I don't have the .iso files around right now, so that we'd need to rebuild this. In the meantime, Martin Dengler has done some great work to incorporate more cool new stuff for the XO-1 into SoaS builds and I'd think there's a new build coming up soonish... ;) On Wed, Jun 17, 2009 at 3:24 AM, Martin Langhoffmartin.langh...@gmail.com wrote: Actually, a tool that's most of this smartly, it's called jigdo, http://atterer.net/jigdo/ is indeed cool. It's presented as a tool for delivering and updating pieces of a single big file and all examples are a .iso big file. So long as it can also/instead use the same pieces to create a different kind of big file such as a bootable Live USB, or a writable SD partition, or XO-1 NAND contents, then it is indeed a great solution. Do the developers who work on Live USB Creator know about jigdo? Cheers, -- =S Page ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] playing w/ i18n
i think it is key that we can mark strings as translatable without making the html invalid. agreed! I like the idea of picking up certain tags by default like title, meta tags, and then picking up h1, h2, etc. unless they have the lang= attribute specified. so, in this way we can have specific language text independent of the current localization. mm, interesting. in order to dice what to use, I'll play with both, it will be useful for counting up 10 activity :) felipe 2009/7/2 Bryan Berry br...@olenepal.org i think it is key that we can mark strings as translatable without making the html invalid. I like the idea of picking up certain tags by default like title, meta tags, and then picking up h1, h2, etc. unless they have the lang= attribute specified. Then it would be nice to pick up everything else that belongs to the class=translate. What u think? I am looking thru src of html2po and it appears that the primary fault is that it uses the horrible HTMLParser.py webunit.HTMLParser.py instead of something more sane like lxml or beautiful soup it may be easier to swap out HTMLParser for lxml than improve html2po on top of HTMLParser I will play w/ lxml and html2po to see what i can work out. re: beautiful soup vs. lxml . My heart is w/ lxml, enjoyed working w/ it before and seems to have better css selectors than beautiful soup. tks again for your help sayamindu! On Thu, 2009-07-02 at 16:54 +0530, Sayamindu Dasgupta wrote: I did a little tweaking of html2po to get http://pastebin.be/19509 The label tags need to be fixed - but apart from that I think the rest of that is OK. May be we can try and build upon html2po and see how it works out. Thanks, Sayamindu 2009/7/2 Bryan Berry br...@olenepal.org: subzero, i have been having a lot of discussions about i18n w/ the ever patient sayamindu and reading a lot on the subject. However, I haven't accomplished much. Here is my current playground http://karma.sugarlabs.org/yes_no/ am currently wrangling how to generate a meaningful po file from an html page. -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Karma: quadrilaterals + Surf it works!
Hi Andrés, I have tested it (quadrilaterals) under Ubuntu 8.10 I see the same I see on a non html5 enabled browser. , you're right, it seems the webkit-gtk isn't updated :S I've checked line 49: ctx.fillText ( Erase, 25, 245 ); I supposse the current webkit doesn't support this instruction :( On FFX 3.5preb4 it works great! yes, the problem is that ff in the XO has a poor performance and if you use quadrilaterals you will get a serious lag, using surf in the XO, it works really good One little comment: it doesnt recognize concave quadrilaterals properly. yes, It was how I solved, not the real code from flash. thanks for your comment, I'll fix it. felipe 2009/6/30 Andrés Ambrois andresambr...@gmail.com On Tuesday 30 June 2009 03:17:00 pm Felipe López Toledo wrote: hi guys I'm a little upset because during last week I was trying to optimize the Quadrilaterals activity: http://karma.sugarlabs.org/quadrilaterals/ Lucian recommend me (last week...or before) to try it using Surf, I was trying to compile it from source... mmm, no progress today Lucian gave me some links: the xo bundle: http://dev.laptop.org/~bobbyp/surf/http://dev.laptop.org/%7Ebobbyp/surf/ also read: http://wiki.laptop.org/go/Browse/WebKit thanks Lucian well, if you have a chance please test it, it works really good (performance) there is some work to do (stuff related to css and scale), but it works a lot better than with firefox :) Tried Quadrilaterals with Surf-106 on Jhbuild on Ubuntu Jaunty. I see the same I see on a non html5 enabled browser. The log ends with this line: console message: http://karma.sugarlabs.org/quadrilaterals/js/activity...@49: Value undefined does not allow function calls. libwebkit on Jaunty is v1.0.1 On FFX 3.5preb4 it works great! One little comment: it doesnt recognize concave quadrilaterals properly. -- -Andrés ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] ActivityTeam meeting on Friday June 26th - 17:00 UTC
Summary: For each activity migrated to activities.sugarlabs.org, the
best is to REMOVE all activity info from w.lt.o except
* {{Activity migrated to sl.o}} on its wiki page
* its activity version fragment(s) read by OLPC's Software update control panel.
What: ActivityTeam meeting
Sorry I was on holiday, but I read the minutes,
dfarning I make it part way through the list at
http://wiki.laptop.org/go/Activities/All add comments to the template
about which activities are on [a.sl.o]
dfarning I think those template should be modified to point directly
to the information on [a.sl.o]
Maybe. Stand back, what the heck is Activities/All for? I marked the
page obsolete and nobody has disagreed. Here's where it stands:
* incomplete and out-of-date
* is not used for activity update_urls or activity groups (they fall
back to the fragments transcluded by
http://wiki.laptop.org/go/Activities)
* uses yet another bloody activity template, different from the one
used by e.g. Activities/G1G1/8.2
* doesn't indicate what activity version works on what version.
So REMOVING stale information from Activities/All is better than hacking on it.
However, if there's evidence that Activities/All gets a lot of hits
and deserves some love, then yes I could dynamically query w.lt.o
activity pages (but not sugarlabs pages) to show info from them,
thereby avoiding yet more bloody repetition of stale info that needs
maintenance.
garycmartin dfarning, you mean the Activity Summary, the Facts
about ..., and the Olpcboxtop?
Those are on the individual activity's page. Likewise, REMOVE them as
stuff is migrated, as
http://wiki.laptop.org/go/Maintaining_activity_web_information urges.
{{Activity migrated to sl.o}} is all that's needed.
The only thing on w.lt.o that requires maintenance is the activity's
version fragment(s) for Software update, in your case
http://wiki.laptop.org/go/Activities/Moon-G1G1
dfarning not sure yet, I was hoping the engage spage he is a template master:)
garycmartin dfarning, yes getting spage would be good :-)
Awww ;-)
Cheers,
--
=S Page
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote: * additional types of filters for example Library has[2] several types to filter objects * user tags * object traits(additional columns from previous section) like author, genre, date for books * activity creators(grouping by activity_id field) * types of objects(like top section in filter palette)[3] * filter by participants * filter by sources(if we are in shared mode) I'm not sure that all of these modes are useful, but something could be(or another types) like http://wiki.sugarlabs.org/go/File:-5.png -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Journal feature request--more data in main display
On Fri, Jul 03, 2009 at 05:06:30AM +, Aleksey Lim wrote: On Fri, Jul 03, 2009 at 04:53:42AM +, Aleksey Lim wrote: On Fri, Jul 03, 2009 at 04:25:54AM +, Aleksey Lim wrote: * additional types of filters for example Library has[2] several types to filter objects * user tags * object traits(additional columns from previous section) like author, genre, date for books * activity creators(grouping by activity_id field) * types of objects(like top section in filter palette)[3] * filter by participants * filter by sources(if we are in shared mode) I'm not sure that all of these modes are useful, but something could be(or another types) like http://wiki.sugarlabs.org/go/File:-5.png use several types of view, list and cloud http://wiki.sugarlabs.org/go/File:-6.png I guess, having numbers of objects makes sense as well http://wiki.sugarlabs.org/go/File:-7.png -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] updated karma documentation
subzero, i have update the karma docs pls take a look when u get a chance http://wiki.sugarlabs.org/go/Karma -- Bryan W. Berry Technology Director OLE Nepal, http://www.olenepal.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
