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

[Aleksey Lim]

On Mon, Dec 07, 2009 at 01:24:14PM +0000, Aleksey Lim wrote:
> On Mon, Dec 07, 2009 at 02:01:16PM +0100, Sascha Silbe wrote:
> > On Mon, Dec 07, 2009 at 12:09:59PM +0000, Aleksey Lim wrote:
> > 
> > 
> > 
> > Sorry I didn't enter into the other discussions about your features yet; 
> > I'm having quite a hard time understanding most of what you write. Would 
> > be nice if you could try to be more elaborate and explain your use cases 
> > and goals in more detail as that is likely to increase my understanding.
> > 
> > 
> > > 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.
> > What did you copy most of the time? UI code or backend? If the latter, 
> > why? I.e. in which way was the data store API insufficient for your 
> > activity?
> 
> UI, since I had the same widgets(activity, stared icons, list widget
> etc), lazy model and shell code to launch objects, edit them etc
> 
> > > 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.
> > No, it will just raise exactly the same concerns again that were the 
> > reason for including such restrictions in Bitfrost/Rainbow, leading to 
> > exactly the same solutions (only certain combinations of rights granted 
> > by default; elevated privileges by using signed builds or explicit user 
> > configuration).
> > According to [1], those restrictions where never actually implemented. 
> > So when they are, we can take the use case "Data store explorer" into 
> > account and see whether there's anything we could do differently to 
> > address it. No need to design a new API to work around it, especially 
> > given it's a deliberate design decision.
> 
> as I said, we can improve shell API, it will let activities launch
> Journal objects, having default list widget, default propery dialog,
> model for lazy displaying, model could provide source abstraction as
> well(e.g. could be useful to browse remote Journal objects, not only
> local or having subset of local/remote objects)

another featrure whic could be useful is UI integration with shell,
ObjectChooser integration, having fast method to access to such
plugins/activities(not only from activity tray, could keys or so)


-- 
Aleksey