[Sugar-devel] Activity as regular objects proposal
Tomeu Vizoso
tomeu at sugarlabs.org
Tue Jul 28 06:18:58 EDT 2009
On Tue, Jul 28, 2009 at 12:14, Sascha
Silbe<sascha-ml-ui-sugar-devel at silbe.org> wrote:
> 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.
As discussed in #sugar, deployers can choose between putting
activities in /usr/share or in ~/Activities depending on whether they
want to give users an easy way to uninstall and update activities.
To avoid space duplication in LTSP environments, ~/Activities can
contain symlinks to somewhere in /usr if the deployer wants users to
be able to uninstall and upgrade activities.
Regards,
Tomeu
>> * sugar can have only one activity version installed at the same
>> time
>
> That's being worked on, see bug #1042 [1] (patch available, but not merged
> yet) and #1053 [2] (fixed).
>
>> 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)
>
> That's not implemented yet, of course, and needs further design decisions
> (esp. regarding the UI).
>
>> [1] http://wiki.sugarlabs.org/go/Features/Activity_Objects
>
> 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://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/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iQEcBAEBAgAGBQJKbs+bAAoJELpz82VMF3DafE4H/3tMOMuT0Rb/n2BNxtR/nT0T
> RqUXQjNDTK0eFgL5Y5ZgslBWszxf7SmronfKEayTXhthtzATsbwAtNxTt326Cv55
> nlDL8mOaFYohM8d8xT2j0ezOlukkK2FnK0Tmj3v3em388Ge54uJyKczAXC+LUY7K
> BN6y/GCFQQCD4n1L9AnkVwv3xMSobAbaUvduYQj5CrgxOIXYvMXOGxxpZNR9eFSW
> PdvDxACNeaejjNvGI+oAc/mCPlEx8bIDH4gJaQ5oMBg0RMo2T4sunmialsuw4NQ9
> XzDZOHHo41HnBWZX0vE2RMnTbTnc02ofR6k2za4xArhbbE4WYj8WwNRiBKCuW5I=
> =B498
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> Sugar-devel mailing list
> Sugar-devel at lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
More information about the Sugar-devel
mailing list