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

[Aleksey Lim]

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.

[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