2009/8/11 Tomeu Vizoso <to...@sugarlabs.org>: >>> You mean that you cannot open that library bundle by clicking on its >>> journal entry? >> >> Correct me if I'm wrong, but none of the methods that could be used by >> deployments to distribute materials this way in mass would result in a >> journal entry appearing for their users. These methods are installing >> through a package into /usr/whatever/library or unzipping into >> ~/Library. > > Didn't thought about pushed updates, can they execute post-install > scripts? If so, they could use copy-to-journal.
This only works when there is a journal created, so deployers would have to hook into the exact moment after the user types in their name and chooses colours as this is the earliest time when the journal is created. Doesn't sound sensible. This also wastes disk space as it results in 1 copy of the library bundle in the journal, and another copy uncompressed on disk. And am I the only one who feels like this is a role for the Sugar shell and not for the journal? I've seen this kind of Journal-based solution proposed for a couple of problems now, and I'm not keen on it. At least until this point, the journal has been for recording what the user has done, created, or accessed. With this kind of approach, we'd now be going into classrooms asking users to look for something in their journal which they've never seen before, and has never been a part of their interactions. I much preferred the previous trail of discussion which was that content would be treated as the same class as activities -- i.e. we'd be extending the home screen somehow, to deal with potentially lots of activity icons, or to become additionally a hub for opening any books that are saved on the system, or something like that. In other words, moving the functionality of olpc-library directly onto the home screen. Daniel _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel