(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