On Tue, Jan 05, 2010 at 08:37:09AM +0000, Aleksey Lim wrote: > On Sun, Jan 03, 2010 at 12:56:28PM +0100, Tomeu Vizoso wrote: > > On Sun, Dec 6, 2009 at 03:20, Aleksey Lim <alsr...@member.fsf.org> wrote: > > > (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. > > > > IMHO, instead of proposing (apparently out of the blue) new features > > that change everything including the development and deployment > > models, would be better to start from a stated need and then propose > > solutions for those. > > > > In the particular case of the Journal, we know from the 0.86 cycle > > that the current list widget is not the best we could use. Users are > > also demanding a way to select multiple items and perform operations > > on them. Sorting has also been requested. Do we really need to decide > > on the plugins thing before we solve these simpler issues? > > Just to make clear what I had(and have) in mind, our current development > model(not core team but in wide sense) seems to me not adequate to sugar > original purposes, we don't have essential and convenient way for casual > doers to hack sugar, ok we can say - "there is git.sl.o and you can fork > any sugar project", but is it fair? There is no convenient ways to share > doer's hacks, should be suggest "git clone && configure && make install" > for any user who wants to test new hack? > > So, in my mind having such infrastructure which stimulates sugar > hacks(by giving simple and convenient tool to hack and deploy them) is > more important(at least doing explicit steps on that way is more > important) then fixing current sugar. > > I had all these in my mind then I proposed plugins to sugar shell, now > the full evolution of this idea is: > > shell-plugins -> Sugar-Services -> Saccharin-distribution[8] > > Back to discussion about what has prime priority, deployment needs or > something else.. I guess answer here is simple, developers who > represent deployment organisations like OLPC have more centralized > focus and any casual contributor has his own view. We can make this > difference smooth by creating needs.sugarlabs.org site with convenient > database of deployment(and from individuals) needs but I don't see > any progress on that way, I think answers like "ask google" don't play here.
btw such needs(or something else).sl.o could not only contain inforation about needs(and pyed needs) but be central point of colaboration work - schedules, involved developers to particular project(need) etc. it can leverage sugar infrastructure in wide sense. > > [8] http://wiki.sugarlabs.org/go/Community/Distributions/Saccharin > > > > > Regards, > > > > Tomeu > > > > > 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 Labs is anyone who participates in improving and using Sugar. > > What Sugar Labs does is determined by the participants.» - David > > Farning > > > > -- > Aleksey -- Aleksey _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel