Talk:Features/Content support: Difference between revisions

(2 intermediate revisions by one other user not shown)

Line 1:

I'd argue for a somewhat different approach to achieving the same goals. Instead of introducing yet another modal dialog, why not eliminate the list view and replace it with the star function in the Journal itself. Any object that is starred will show up on the Home View. (Ideally, there would be multiple stars corresponding to multiple Home Views, e.g., one for school, one for home...)

Note that most of the discussion below refers to parts of the proposed feature which are no longer being proposed now (for the time being at least).

----------

I'd argue for a somewhat different approach to achieving the same goals. Instead of introducing yet another modal dialog, why not eliminate the list view and replace it with the star function in the Journal itself.

Any object that is starred will show up on the Home View. (Ideally, there would be multiple stars corresponding to multiple Home Views, e.g., one for school, one for home...)

Features of this approach:

Line 57:

Line 64:

#* Offering hints as to the number of updates available for content already stored locally

#*: <small>(as the current Activity Update interface offers. the default hint should probably be less bold; rather than a page listing the updates in detail and asking you to click "go!")</small>

== Browse can handle content bundles directly ==

''The widely-deployed .xol content bundles only have minimal support (they can only be launched from the journal).''

: Not true, you can view .xol (or any ZIP file) contents in Browse ''without installing or unpacking'' using the jar: protocol ({{bug|1258}}).

Copy and paste the following into your browse bar , including the "jar:" on the front.

jar:http://wiki.laptop.org/images/3/3e/Biology-9.jar!/Biology/index.en.html

This has some interesting implications.

* Sugar code doesn't have to keep a .xol and a Library directory in sync, installing and uninstalling the latter as .xols are opened and erased.

* The file system determines if a content bundle conflicts with another.

* Instead of making web pages telling readers how great some content is, they can view it for themselves before they download.

There are limitations to this:

* Some collections have an index.html that does a meta http-equiv refresh to a path in file:///home/olpc/Library , this won't work (and I think breaks anyway in other Sugar environments)

* Some collections (Biology, NatureImages, TranslationDictionary) reference a /usr/share/library-common/css/master.css). This won't work if you browse them remotely.

* I don't know what the performance implications are. I know Firefox 3.6 has additional performance boosts as Mozilla moved more files into a single runtime .jar file.

-- [[User:Skierpage|Skierpage]] 06:40, 4 September 2010 (EDT)

@@ Line 1: / Line 1: @@
-I'd argue for a somewhat different approach to achieving the same goals. Instead of introducing yet another modal dialog, why not eliminate the list view and replace it with the star function in the Journal itself. Any object that is starred will show up on the Home View. (Ideally, there would be multiple stars corresponding to multiple Home Views, e.g., one for school, one for home...)
+Note that most of the discussion below refers to parts of the proposed feature which are no longer being proposed now (for the time being at least).
+----------
+I'd argue for a somewhat different approach to achieving the same goals. Instead of introducing yet another modal dialog, why not eliminate the list view and replace it with the star function in the Journal itself.
+ Any object that is starred will show up on the Home View. (Ideally, there would be multiple stars corresponding to multiple Home Views, e.g., one for school, one for home...)
 Features of this approach:
@@ Line 57: / Line 64: @@
 #* Offering hints as to the number of updates available for content already stored locally
 #*: <small>(as the current Activity Update interface offers. the default hint should probably be less bold; rather than a page listing the updates in detail and asking you to click "go!")</small>
+== Browse can handle content bundles directly ==
+''The widely-deployed .xol content bundles only have minimal support (they can only be launched from the journal).''
+: Not true, you can view .xol (or any ZIP file) contents in Browse ''without installing or unpacking'' using the jar: protocol ({{bug|1258}}).
+Copy and paste the following into your browse bar , including the "jar:" on the front.
+ jar:http://wiki.laptop.org/images/3/3e/Biology-9.jar!/Biology/index.en.html
+This has some interesting implications.
+* Sugar code doesn't have to keep a .xol and a Library directory in sync, installing and uninstalling the latter as .xols are opened and erased.
+* The file system determines if a content bundle conflicts with another.
+* Instead of making web pages telling readers how great some content is, they can view it for themselves before they download.
+There are limitations to this:
+* Some collections have an index.html that does a meta http-equiv refresh to a path in file:///home/olpc/Library , this won't work (and I think breaks anyway in other Sugar environments)
+* Some collections (Biology, NatureImages, TranslationDictionary) reference a /usr/share/library-common/css/master.css).  This won't work if you browse them remotely.
+* I don't know what the performance implications are.  I know Firefox 3.6 has additional performance boosts as Mozilla moved more files into a single runtime .jar file.
+-- [[User:Skierpage|Skierpage]] 06:40, 4 September 2010 (EDT)