[Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature

[Simon Schampijer]

On 12/07/2009 01:09 PM, Aleksey Lim wrote:
> On Mon, Dec 07, 2009 at 10:57:01AM +0100, Simon Schampijer wrote:
>> On 12/07/2009 05:58 AM, Aleksey Lim wrote:
>>> On Sun, Dec 06, 2009 at 11:56:09PM +0000, Gary C Martin wrote:
>>>> On 6 Dec 2009, at 21:19, Tomeu Vizoso wrote:
>>>>
>>>>> 2009/11/27 Aleksey Lim<alsroot at member.fsf.org>:
>>>>>> On Fri, Nov 27, 2009 at 06:13:55AM +0000, Aleksey Lim wrote:
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Want to know what people think about Journal Plugins feature[1]
>>>>>>> and particularly that design team think about UI changes[2] involved
>>>>>>> in this feature.
>>>>>>>
>>>>>>> [1] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#
>>>>>>> [2] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#UI_changes
>>>>>>
>>>>>> I tweaked "Benefit to Sugar" section a bit
>>>>>>
>>>>>> * browsing different types of sugar object looks the same in many cases (search, tagging etc.). So, keep unified code base and do not split it could be useful idea.
>>>>>> * for now, some activities have similar functionality(browsing Journal entries), so having plugins, we will use the same theme for browsing features in sugar
>>>>>> * encourage developers create new view for different purposes(books, media etc.)
>>>>>> * having plugins we don't stick to sugar releases, deployers could create/change plugins that support not only last sugar but version which is in deployment
>>>>>> * having bookmarks, users can have fast access to his books/media-files/etc in the Journal(and using proper view plugin to browse them)
>>>>>> * shared bookmarks is more powerful and useful method of network sharing(in comparing with "Send to" option)
>>>>>
>>>>> Can anyway relate these benefits from actual requests from deployments?
>>>>>
>>>>> I think this is something that would be good to do in Sugar at some
>>>>> point, but I'm not convinced we are yet in the best moment for that.
>>>>
>>>>
>>>> I can't see us finding the right solution for the whole action/object view concept/requirements in the next few months. The Journal_Plugins idea seem rather scary to me at the moment, and has a very broad effect that would need much design work (security, UI confusion, documentation issues). Now I admit I was hoping we had another shot at including the thumbnail view for 0.88 (thumbnails would seem to be a genuine improvement for finding/browsing many Journal entry types, and likely the default view for kids)... Perhaps just adding the thumbnail image (if available) to the Journal hover palette could be a low risk improvement we could agree on? The design intent seems to go way back in Sugar history, so lightly has plenty of supporters.
>>>
>>> The core idea of plugins is exactly to avoid situation when we have to
>>> release fat UI change set, plugins let us decentralize existed scheme
>>> when entirely sugar design(not only UI) depends on what core team
>>> thinks. We just provide usable toolset developers cold use to implement
>>> what they think.
>>>
>>> [1] proposes UI changes in [2] but plugins API could be implemented w/o
>>> any UI changes at all - user will see the same Journal(but it will be
>>> Journal plugin). The idea is let developers make plugin out of sucrose
>>> release cycle, yeah developers could do it in pure activities(but see
>>> [3]) and even out of sugar at all, but imho it will be useful(in all
>>> cases, not only technical) to initiate/support/organize such process
>>> from core.
>>>
>>> [3] http://wiki.sugarlabs.org/go/Features/Journal_Plugins#Detailed_Description
>>
>> Generally the idea of plugins is interesting - it always adds
>> extensibility and make parts exchangeable. In the Journal case it is the
>> support for different pluggable views. Looking just at the idea: great!
>>
>> Let's take a concrete example of a scenario with different views that is
>> floating around: the action/object view. While there have been some pros
>> for the change to have these two views, the implementation could be done
>> using plugins or not. From a technical point of view: while having to
>> change code it might be a good moment to add a plugin structure.
>
> Well, I guess there are two obvious ways, coding pure activities or
> having several views(somehow) in core. I tried 1st way while developing
> Library activity in 0.84 release cycle and, at the end, I realized that
> I copy/pasted much code from the shell, so tried to reimplement shell.
>
> So, we can just extend shell public API but there could be another
> issue - security reasons. I heard about plans to restrict activities in
> case of searching/changing/removing objects that were not created by
> this activity. Having special API(and plugins) could soften situation
> then.

I prefer to have a plugins over activities - here I agree. Do you have a 
layout of the plugins structure already? How much code/how invasive is it?

>> I agree with Tomeu in the question: "has this Feature of pluggable views
>> been asked by the community?".
>
> well, this feature is not final users targeted, it's just about making
> development process more flexible.

Ok, then we should make this more clear in the proposal then.

>> In the arguments we list: "encourage developers to create new views".
>> How many deployments will write their own view because they miss a
>> Feature? As a deployer I would ask myself: "When writing my own view I
>> am off the mainline track. No support from the community etc." It might
>> be interesting for testing purposes. I can modify/add a new view and it
>> can be easily distributed for testing.
>
> deployments won't be direct users of such possibility but indirectly
> e.g. someone could start implementing actions view plugin right now
> and it will regular activity development workflow.
>
>> Furthermore we say: "having plugins we don't stick to sugar releases,
>> deployers could create/change plugins that support not only last sugar
>> but version which is in deployment". Are deployments really blocked by
>> the Sucrose release cycle to see changes in the Journal views happen?
>
> so, here we are not blocking deployers but potential wishful developers.
>
> At the end the question is about which way we are choosing. It could be
> walled scheme when potential developer(kid who is willing to hack
> Journal?) have to be "adult" professional who followed all
> rules/reviews/git-expert/etc to share his Journal hack. Or we should
> encourage every kid to hack our code(Journal) and share his code w/o
> following "adult" procedures in core team.

Ok, until a kid gets to hack on things like the Journal or writing a new 
activity from scratch there will pass some time.

Anyhow, we started to allow for different views in the home view (ring), 
we aimed at diferent views in the neighborhood view, too and we made the 
CP and Frame device extensible, too. I guess it could work out for the 
Journal as well.

Tomeu, what do you think?

Regards,
    Simon