[Sugar-devel] [FEATURE] [DESIGN] for Journal Plugins feature
alsroot at member.fsf.org
Mon Dec 7 08:27:07 EST 2009
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 , 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)
More information about the Sugar-devel