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 _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel