[Sugar-devel] [FEATURE] [DESIGN] Journal Reload a new attempt

[Aleksey Lim]

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 <alsroot at 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 at 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