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

[Tomeu Vizoso]

On Tue, Dec 8, 2009 at 07:05, Simon Schampijer <simon at schampijer.de> wrote:
> 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?

I think I pretty much shared your opinion on the thread about frame panels.

Regards,

Tomeu

> Regards,
>   Simon
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning