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

[Simon Schampijer]

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.

I agree with Tomeu in the question: "has this Feature of pluggable views 
been asked by the community?".

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.

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?

Putting my deployment head on, updating is a non-trivial task. I have 
only 30 machines running Sugar - but I do not change/tweak them 
constantly as it is just quite some work to do. And from my technical 
background I would be able to. I still run 0.84 just because it takes 
effort and time to update.

I am a bit torn. Maybe the arguments are just not the right ones and 
from a technical point of view for supporting different views it might 
make sense to have a plugin structure (if not a lot of overhead).

Regards,
    Simon