<div dir="ltr">I see. Yes, I think that works.<div><br></div><div>- Eben</div><div><br><br><div class="gmail_quote">On Thu, Jul 17, 2008 at 10:58 AM, Tomeu Vizoso <<a href="mailto:tomeu@tomeuvizoso.net">tomeu@tomeuvizoso.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="Wj3C7c">On Thu, Jul 17, 2008 at 4:50 PM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>> wrote:<br>
><br>
><br>
> On Thu, Jul 17, 2008 at 5:31 AM, Tomeu Vizoso <<a href="mailto:tomeu@tomeuvizoso.net">tomeu@tomeuvizoso.net</a>> wrote:<br>
>><br>
>> On Thu, Jul 17, 2008 at 3:19 AM, Eben Eliason <<a href="mailto:eben.eliason@gmail.com">eben.eliason@gmail.com</a>><br>
>> wrote:<br>
>> > Yeah, I'm not sure that this is expected behavior (I would expect not).<br>
>> > The<br>
>> > intent is that a "customization" upgrade would allow additive changes to<br>
>> > the<br>
>> > favorites ring, for instance to allow a school to ensure that every kid<br>
>> > has<br>
>> > brand new activity X in the ring on the first day of class (if the kids<br>
>> > later remove it, that's up to them, of course). The question, then, is<br>
>> > if/why installing that RPM behaved in the manner of a customization<br>
>> > instead<br>
>> > of a basic software update.<br>
>> > Tomeu, do you know how this is expected to work?<br>
>><br>
>> When kids update to a version that has the notion of favorites, we<br>
>> don't want to show the favorites screen empty. That's why we added<br>
>> code for adding the activities mentioned in activities.default.<br>
><br>
> I'm OK with this if it's a one-time change. In other words, it should check<br>
> for an empty favorites list and apply the defaults if none exist.<br>
><br>
>><br>
>> Also, when you update to a newer version, favorites.default might<br>
>> change so we merge it again with the users favorites. We don't know if<br>
>> an activity present in activities.default but not in the favorites was<br>
>> removed by the user or added by the school/deployer.<br>
><br>
> Well, it depends on the use case. Is editing favorites.default the intended<br>
> way for a country or school to manage updates? If so, then I suppose that<br>
> this is correct. If not, then we should really only be setting the<br>
> favorites from the default file when no favorites are set at all (should<br>
> only happen once), and otherwise do a merge from a favorites list on a<br>
> customization key instead.<br>
<br>
</div></div>What I understood is that the customization key would install some<br>
activities and a activities.default file. When Sugar starts up, it<br>
checks if activities.default has changed since last time we merged it,<br>
and if so, we merge it again. Is this right?<br>
<br>
Regards,<br>
<font color="#888888"><br>
Tomeu<br>
</font></blockquote></div><br></div></div>