Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
Hi Aleksey others, just a quick note on the Feature process. This feature does not change or add new UI but is a huge change on the workflow. In these cases you should add the [DESIGN] flag, too. While thinking about it, I guess we nearly need design team feedback on all Features... ;) Eben jumped on it already, so everything is good. I updated the Policy page [1] to make this clearer. Thanks for the great discussion on this feature. That is what I envisioned when adding the policy, Simon [1] http://wiki.sugarlabs.org/go/Features/Policy#Propose_a_feature_for_addition_into_the_release_cycle ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On 11/30/2009 08:54 PM, Daniel Drake wrote: 2009/11/30 Walter Benderwalter.ben...@gmail.com: This isn't quite accurate. We've been adding some pre-loaded content to the Journal for quite some time now, Are you sure? Or are you referring to a manual process that you do in certain deployments? I have yet to see a sugar installation that comes with a non-empty journal. And also I can't think of any non-horrible way that you'd be able to hook into the sugar profile creation stages to pre-provide the content, even if I did like the idea. So far we have been doing it in Soas with the copy-to-journal script. Of course it would be nice to have a simple way for a deployer to pre-install content into the Journal. But this is scope of another Feature ;p and some activities (as you noted, Turtle Art) have been adding content to the Journal as well. This is the only one I'm aware of, and it was a big surprise, to the extent that I filed bugs upstream and downstream that were confirmed by other people who also didn't realise this. I also got the impression from you that you don't feel like it is the appropriate place to put it, you just did it because it is the only option. Ok, if you think of the Journal only in the sense of an action view, having pre-installed content in it can be confusing. That is why the differentiation of object and action view would make sense, I guess. http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#1 http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#2 http://wiki.sugarlabs.org/go/Design_Team/Designs/Journal#3 Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On 12/03/2009 06:23 AM, Eben Eliason wrote: On Tue, Dec 1, 2009 at 5:54 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Nov 30, 2009 at 9:40 PM, Wade Brainerdwad...@gmail.com wrote: When deleting an object from the Journal that is an activity bundle, we ought to display an alert with a scary icon. The alert should clearly state that Journal entries will no longer be able to be opened until the activity is reinstalled. Majority of 6 year old will not understand that. The best way to handle this, I think, is to let kids delete activities but also keep a reference to the source in the form of an update URL or similar, so that fetching the activity automatically when an instance of it is resumed can be done. There's additional UI work there, and we can't guarantee connectivity, etc., but it would help reduce the overhead involved. (I'm not suggesting we shouldn't find ways to make it clearer when a deletion is happening, either, but as noted, the dialog may not work in practice with the target audience.) Actually, one HI guideline was, that you can undo things. This currently applies to simple actions in activities (paste, copy etc). There are no ways to undo deleting a Journal entry (or object). For activity instances your proposed idea to provide a download link could be one option. This does not work for other entries though. Maybe a bin that caches the objects would work? You can empty it on demand and it is emptied automatically when shutting down Sugar. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
On 12/03/2009 06:37 AM, Aleksey Lim wrote: On a more general note, this discussion has many hints of the action/object views that have been tossed around for some time now. This specifically addressed the conflict between the desire to manage all objects and the desire to have the Journal reflect only the actions of the child. In this split, the action view shows actions, which reference one or more objects (activities, people, devices, etc.) This would contain only references to things the children have done themselves. The object view shows objects, which is a more traditional view of everything that's around to be manipulated. Any preinstalled activities would appear in the object view by default, and thus be accessible by kids to copy, share, modify, etc. (and as they do, new actions will be created to record that). Ultimately, the object view would look much like the current Journal view does, and the actions view would be a bit friendlier. One benefit of this is that young kids need only look at the actions view, while those that wanted more control could dig into the objects directly. Good catch, what about more explicit following user works all time with the same objects but from different views and add Action view as a Journal plugin(and maybe make it default) to [1](technically we need addition data to form actions view but for users it could be the same (as in objects view) objects but organized to actions. [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins Yeah, this discussion came already up in 0.86 but we did not have the time. There would quite a bit UI work needed, I think. But interesting indeed. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Blueberry launch prep - new eBooks wiki page - translators for PR?
The press release was completed last night! Can anyone help with German and Dutch? We hope to get these up during the day Monday, and send to our press/education contacts mailing list on Tuesday when PR Newswire will carry it in English thanks! Sean On Tue, Dec 1, 2009 at 11:56 PM, Sean DALY sdaly...@gmail.com wrote: Preparations are underway for the Sugar on a Stick v2 Blueberry release media launch which will take place on Tuesday the 8th at Netbook World Summit in Paris. More information in today's marketing meeting (http://wiki.sugarlabs.org/go/Marketing_Team/Meetings). In this holiday season, we want to remind teachers and parents that eBooks are not just pricey ebooks for fancy gadgets, but part of the open access to learning movement. We believe teachers and parents can benefit from step-by-step advice about getting eBooks into Sugar and so have started a wiki page called eBooks: http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/ebooks Can anyone help with this page? Please add links to sources of children's ebooks! preferably downloadable ebooks (readable offline). By launch date, we will want to have a section on this page describing (for newcomers to Sugar) how to find, obtain and read eBooks with Sugar's reading Activities. And, a section explaining common formats maybe even with conversion tips. If you have a suggestion for an illustrated eBook to serve as an example, please let us know, preferably with link and license information. We hope to be able to include some eBooks with Blueberry, if for licensing reasons we can't we will set up online access to those ebooks through the default Browse page. We will also need translators for our press release which will be ready on Thursday. Volunteers greatly appreciated, there is a direct correlation between the language versions of our PR available and the coverage we bring to Sugar Labs in that language. If we are lucky enough to make a media splash as we did last June (alas! never guaranteed), we will organize the news monitoring as follows: [SoaS in the news] in the subject line, sent to Marketing and SoaS lists, digested so no more than 4 messages per day (exceptions for broadcast media if any). We're excited about this launch and hope everyone can help spread the word about Sugar to teachers and parents! thanks Sean Sugar Labs Marketing Coordinator ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar master will depend on simplejson again
On Fri, Dec 04, 2009 at 01:41:17PM +0100, Sascha Silbe wrote: On Fri, Dec 04, 2009 at 01:17:49PM +0100, Simon Schampijer wrote: [Debian] could it be that 2.5 is only the default and that it is fine for a package to depend on python 2.6? No, that's not the case. Python 2.6 is only available in experimental, not in unstable or testing. Even when Python2-6 appears in unstable, it is most probably a problem still as long as not being the default, due to some Python modules only compiled for the default Python version (multi-version Python module support is optional and raise packaging complexity considerably except when using CDBS, which is discouraged for other reasons by some developers). Kind regards, - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] User workflow sharing Journal Entries over USB sticks
On Thu, Nov 12, 2009 at 12:44 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Thu, Nov 12, 2009 at 12:33 PM, Martin Langhoff martin.langh...@gmail.com wrote: On os34, if I Filed it as http://dev.laptop.org/ticket/9657 - can't find anything on this topic on the SL trac; apparently the usage on SoaS has seen other bugs when saving to a USB stick (like http://dev.sugarlabs.org/ticket/995 ) so maybe it hasn't been used/tested. Been workingon this, I have a solution for the backend problem, but need help with a couple of UI glitches where I cannot understand how the inter-widget-object messaging is supposed to go. I have 4 patches that fix this up so that we DTRT - attached in http://dev.laptop.org/ticket/9657 * 0001-Removable-disk-Save-metadata-and-preview-dlo-9657.patch * 0002-Removable-disk-read-json-formatted-.metadata-and-.pr.patch * 0003-Removable-disk-Handle-renames-dlo-9657.patch * 0004-Removable-disk-delete-preview-and-metadata-dlo-9657.patch With this * We save the files with their correct metadata * Read the metadata back, display it, copy it correctly into the DS, and search descriptions/tags if the user runs a search * Renames and removes are handled correctly on-disk (metadata/preview files are renamed or removed The results are not perfect, as we have UI glitches -- on delete the file listing doesn't remove the file 'collapsedentry'; on rename, the new name is shown until you touch the scrollbar, there it reverts to the old name. To fix those UI glitches we need to issue a message to the InplaceResultSet instance somehow... except that we don't have a handle to it. I also attempted to do something like http://git.sugarlabs.org/projects/sugar/repos/mainline/commits/b0113bf67c31dbeaa08cf0f1710c1be8d02a9b25 which sure looks right, but didn't work for me. Triggering these actions from the UI widget objects makes it all overly confusing to a newcomer like me. The ocassional dbus message makes it even more entertaining. In any case, the patches bring the backend behaviour to correctness. With some help we can also address the UI glitches (or punt and deal with them with later). cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] [DESIGN] Actions request for inclusion to 0.88
Hi all, I've created a stub feature page[1] for actions metaphor. Could someone, who are original initiators(or have ideas) of this feature, tweak wiki page to cover all workflows that they have in mind for Actions in Journal. [1] http://wiki.sugarlabs.org/go/Features/Actions -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] Activity as a regular Journal Object request for inclusion to 0.88
Hi all, This post is not about particular feature but about proposed to 0.88 features that can be composited to one set. Some of them could be implemented in 0.88 partially, some are invasive, some not. We lost possibility to push several such features in 0.86 and we have a chance to do it once more in 0.88 release cycle. But in my mind, start to fix followed issue could be useful even in 0.88. * Reinforcing the storage metaphor in sugar (w/o loosing dairy component). Since in sugar we have only datastore(existed Journal from users POV) as a data storage(excluding external sources), we have *very* poor instruments to treat sugar object from users POV - user has to face to the whole list of objects from begging(there is not way to keep query - should look like replacement of regular directories), user even can't manually sort Journal objects. Could be fixed by: * [5] having sugar directories - bookmarks * [6] several views that could provide most useful browsing features * Having extended storage metaphor, we should save dairy component, so we can start implementing of long discussing Actions feature Could be fixed by: * [2] its only a stub, so any ideas are welcome * Make existed work flows more consistent (activities vs. objects-that-could-be-treated-as-activities, activities vs. activity bundles) Could be fixed by: * having [5], there is simple behaviour, all sugar objects are accessible from one place but from different views e.g. Hove view is just a special view that contain only activities(but could contain other objects too to speed up access) or new Actions view is a dairy view * Encourage activity developers make custom objects views, (having only one object view we either have complicated view or feature less one) Could be fixed by: * [1] These features are: [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins the name could be confusing but [1] should provide all features that are mentioned here How its invasive: * except [7], non of UI should be changed in default sugar distribution * code will be refactored to support plugins API [2] http://wiki.sugarlabs.org/go/Features/Actions this page just a stub, so who are original initiators (or have ideas) for this feature, please tweak wiki page to cover all workflows How its invasive: * the full implementation of this feature could be too invasive for UI and codebase, but we can just initiate this feature in 0.88 and collect users feedback to improve it in 0.90 [3] http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object How its invasive: * adds another confusion when user deletes activity instead of activity objects but having [5], by default, all object sets could not contain activity object except special activity views that can make activity removing more explicit for users * shouldn't be invasive in case of codding [4] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles How its invasive: * codding shouldn't be invasive Summarising above text, I think we can start implementation of these features in 0.88 release cycle(but we shouldn't implement the final workflows and make only initial steps e.g. in case of Actions). So, what community thinks about how such features could be invasive to users workflows and codebase and how it could(invasive changes) be reduced. [5] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model [6] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#View_model [7] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_Design -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] [FEATURE] [DESIGN] Journal Reload a new attempt
(oops, wrong subject) Hi all, This post is not about particular feature but about proposed to 0.88 features that can be composited to one set. Some of them could be implemented in 0.88 partially, some are invasive, some not. We lost possibility to push several such features in 0.86 and we have a chance to do it once more in 0.88 release cycle. But in my mind, start to fix followed issue could be useful even in 0.88. * Reinforcing the storage metaphor in sugar (w/o loosing dairy component). Since in sugar we have only datastore(existed Journal from users POV) as a data storage(excluding external sources), we have *very* poor instruments to treat sugar object from users POV - user has to face to the whole list of objects from begging(there is not way to keep query - should look like replacement of regular directories), user even can't manually sort Journal objects. Could be fixed by: * [5] having sugar directories - bookmarks * [6] several views that could provide most useful browsing features * Having extended storage metaphor, we should save dairy component, so we can start implementing of long discussing Actions feature Could be fixed by: * [2] its only a stub, so any ideas are welcome * Make existed work flows more consistent (activities vs. objects-that-could-be-treated-as-activities, activities vs. activity bundles) Could be fixed by: * having [5], there is simple behaviour, all sugar objects are accessible from one place but from different views e.g. Hove view is just a special view that contain only activities(but could contain other objects too to speed up access) or new Actions view is a dairy view * Encourage activity developers make custom objects views, (having only one object view we either have complicated view or feature less one) Could be fixed by: * [1] These features are: [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins the name could be confusing but [1] should provide all features that are mentioned here How its invasive: * except [7], non of UI should be changed in default sugar distribution * code will be refactored to support plugins API [2] http://wiki.sugarlabs.org/go/Features/Actions this page just a stub, so who are original initiators (or have ideas) for this feature, please tweak wiki page to cover all workflows How its invasive: * the full implementation of this feature could be too invasive for UI and codebase, but we can just initiate this feature in 0.88 and collect users feedback to improve it in 0.90 [3] http://wiki.sugarlabs.org/go/Features/Activity_as_a_regular_Journal_Object How its invasive: * adds another confusion when user deletes activity instead of activity objects but having [5], by default, all object sets could not contain activity object except special activity views that can make activity removing more explicit for users * shouldn't be invasive in case of codding [4] http://wiki.sugarlabs.org/go/Features/Sugar_Bundles How its invasive: * codding shouldn't be invasive Summarising above text, I think we can start implementation of these features in 0.88 release cycle(but we shouldn't implement the final workflows and make only initial steps e.g. in case of Actions). So, what community thinks about how such features could be invasive to users workflows and codebase and how it could(invasive changes) be reduced. [5] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Data_model [6] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#View_model [7] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_Design -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [FEATURE] [DESIGN] Journal Reload a new attempt
..to continue summarising.. In fact, all proposed features are not about increasing complexity but about decreasing for floor level - user all time works with sugar objects(activities, activity objects, foreign object etc) but from different views. And let developers/deployments/teachers increase/localize complexity for their needs - coding/forking/tweaking existed/new view plugins. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity Versioning - Dotted Scheme
On Wed, Dec 02, 2009 at 04:38:56PM +0100, Bert Freudenberg wrote: On 30.11.2009, at 21:24, Bert Freudenberg wrote: On 30.11.2009, at 20:02, Aleksey Lim wrote: On Mon, Nov 30, 2009 at 07:49:15PM +0100, Simon Schampijer wrote: On 11/30/2009 10:00 AM, Bert Freudenberg wrote: On 29.11.2009, at 20:50, Simon Schampijer wrote: Well, if an activity will work for an older release is not only determined by the activity version number. For example, activities that moved to the new toolbar design are not working for older releases 0.86. I don't think we can always avoid breaking backwards compatibility. But so far we have managed to make is at least *possible* for an activity author to have a single activity version run under all Sugar versions. This would be the first instance where the author would not have that chance. I'm pretty sure we can find a scheme that both allows a single activity bundle to provide dotted version numbers for new Sugar, but keep working in old Sugar. E.g., we do not have to re-use the activity_version field if that breaks the parsing in older versions. It could be a new field named dotted_activity_version or simply version or something else. An activity author who cared could then provide both, a decimal and a dotted activity version. - Bert - Sorry, for the mixup. Yes we could add a way for the dotted version number, and your idea sounds good. How does Bert's idea from above sounds to others? +1, but maybe use activity_release(or so) instead of dotted_activity_version, the full version in 0.88+ will be activity_version.activity_release? That would link the old and new version field - I thought of them as being independent. Basically, the old activity_version field would be a like a build number, increasing for every build, as we did before. It would be optional in Sugar 0.88. The real user-visible version number would be the dotted one in a different field. An activity author who wants to support both could keep incrementing activity_version, and assign dotted version numbers independently. - Bert - Thinking about this, for Etoys it doesn't really make a difference. We can as well switch to the dotted-only scheme. So unless other activity authors feel backwards compatibility is needed, just use whatever is simplest. Is this already written up as a feature? Couldn't find it. I've created http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions and wrote several options of your proposal(how I understood it) in http://wiki.sugarlabs.org/go/Features/Dotted_Activity_Versions#Detailed_Description Also I pushed it to Feature Ready for Release Manager group though this feature doesn't meet all requirements(there is no owner, I guess it will be trivial to code it) but it let us do not forget about this feature. -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Foodforce2 Release
Hi, We are pleased to announce the new release of Foodforce2 game which we are naming as the first stable release version after the successful launch of beta earlier in the year. Thanks for all the love and support accorded to the beta version with more than 113 thousand downloads from the Google Code page and over 29 thousand downloads from the Sugar activities page. There have been many improvements in the game UI to make the look and feel of the game better. Specifically, these are some of the new things: 1. A better and fast-paced storyline with snappier dialogues 2. Bigger buttons and easy clickablility of buttons and other UI elements of the game. 3. Ability to place your own buildings in the village canvas. 4. Ability to save and resume at various check point within the game. 5. Performance imporved and bugs solved with testing being done by a gaming testing company: Chakkilam Infotech Limited 6. New site for the game now present at : www.foodforce2.com 7. A setup package now available for macintosh operating systems also. 8. The new version works on SoaS and XO 1.5 systems also. You can download the game from : foodforce2.com or from the activities sugar page if you want to download the xo package. Looking forward to feedback on the game. You can leave the feedback on the game at:http://foodforce2.com/index.php?option=com_qcontactsview=contactid=1Itemid=59 Thanks, Foodforce 2 Team ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
