[sugar] Sugar adds favorite activities to ring

[Eben Eliason]

On Thu, Jul 17, 2008 at 5:31 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:

> On Thu, Jul 17, 2008 at 3:19 AM, Eben Eliason <eben.eliason at gmail.com>
> wrote:
> > Yeah, I'm not sure that this is expected behavior (I would expect not).
>  The
> > intent is that a "customization" upgrade would allow additive changes to
> the
> > favorites ring, for instance to allow a school to ensure that every kid
> has
> > brand new activity X in the ring on the first day of class (if the kids
> > later remove it, that's up to them, of course).  The question, then, is
> > if/why installing that RPM behaved in the manner of a customization
> instead
> > of a basic software update.
> > Tomeu, do you know how this is expected to work?
>
> When kids update to a version that has the notion of favorites, we
> don't want to show the favorites screen empty. That's why we added
> code for adding the activities mentioned in activities.default.
>

I'm OK with this if it's a one-time change.  In other words, it should check
for an empty favorites list and apply the defaults if none exist.


>
> Also, when you update to a newer version, favorites.default might
> change so we merge it again with the users favorites. We don't know if
> an activity present in activities.default but not in the favorites was
> removed by the user or added by the school/deployer.
>

Well, it depends on the use case.  Is editing favorites.default the intended
way for a country or school to manage updates?  If so, then I suppose that
this is correct.  If not, then we should really only be setting the
favorites from the default file when no favorites are set at all (should
only happen once), and otherwise do a merge from a favorites list on a
customization key instead.

- Eben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20080717/c4c24941/attachment.htm