On Tue, Dec 08, 2009 at 10:05:30AM +0100, Simon Schampijer 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: > >>> 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?
iiuc, new feature should be included to new release cycle before starting development process, so I don't have detailed plan for plugins structure, but I guess it should mean at least refactoring of existed Journal code and I also think to include remote objects to model abstraction. -- Aleksey _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel