[sugar] Sugar adds favorite activities to ring

[Tomeu Vizoso]

On Thu, Jul 17, 2008 at 4:50 PM, Eben Eliason <eben.eliason at gmail.com> wrote:
>
>
> 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.

What I understood is that the customization key would install some
activities and a activities.default file. When Sugar starts up, it
checks if activities.default has changed since last time we merged it,
and if so, we merge it again. Is this right?

Regards,

Tomeu