[sugar] Sugar adds favorite activities to ring

[Eben Eliason]

Actually, I have one more concern.  It seems to me we might be better off
checking against a hash of the file, instead of a timestamp. We don't want
to continually merge new favorites with every OS update, but that's exactly
what we'll do if we only check the timestamp on the favorites.default file,
right?  By checking a hash, we ensure that someone (either us, by "shipping"
a new favorites.default, or the country, via a customization key) intended a
new merge to happen.

- Eben


On Thu, Jul 17, 2008 at 11:04 AM, Eben Eliason <eben.eliason at gmail.com>
wrote:

> I see. Yes, I think that works.
> - Eben
>
>
> On Thu, Jul 17, 2008 at 10:58 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net>
> wrote:
>
>> 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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20080717/251fae6e/attachment.htm