On Tue, Jul 28, 2009 at 05:14:57AM +0000, Aleksey Lim wrote:
* it can't upgrade activities if they were pre-installed from native packages; it makes process of upgrading activities from .xo impossible
Yeah, this is really a PITA.
That's being worked on, see bug #1042 [1] (patch available, but not merged yet) and #1053 [2] (fixed).* sugar can have only one activity version installed at the same time
That's not implemented yet, of course, and needs further design decisions (esp. regarding the UI).i.e. it could be useful to have several versions simultaneously e.g. to start proper version when join request arrived(activity version of arrived request could be different to installed version)
This sounds a lot like what I imagined as a solution for the first problem: represent system-installed activities as a virtual Journal object - inside Journal / shell only, not exposed to activities or the datastore. What I don't get is how this depends on your Object Bundles proposal [3]. AIUI the latter is only an on-the-wire format, similar to the way regular Bundles work now.[1] http://wiki.sugarlabs.org/go/Features/Activity_Objects
[1] http://dev.sugarlabs.org/ticket/1042 [2] http://dev.sugarlabs.org/ticket/1053 [3] http://wiki.sugarlabs.org/go/Features/Object_Bundles CU Sascha -- http://sascha.silbe.org/ http://www.infra-silbe.de/
signature.asc
Description: Digital signature
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
