Web   ·   Wiki   ·   Activities   ·   Blog   ·   Lists   ·   Chat   ·   Meeting   ·   Bugs   ·   Git   ·   Translate   ·   Archive   ·   People   ·   Donate
diff options
authorDaniel Narvaez <dwnarvaez@gmail.com>2013-02-06 12:33:34 (GMT)
committer Daniel Narvaez <dwnarvaez@gmail.com>2013-02-06 12:33:34 (GMT)
commitc110fb485b3af0066c6df7aeac8c055e9d767efa (patch)
parentb4216422fa628adc23f4f472975915196f694432 (diff)
Move docs to their own dir
-rw-r--r--docs/Makefile (renamed from Makefile)0
-rw-r--r--docs/README.md (renamed from README.md)0
-rw-r--r--docs/TODO (renamed from TODO)0
-rwxr-xr-xdocs/markdown (renamed from markdown)0
-rw-r--r--docs/markdown.css (renamed from markdown.css)0
7 files changed, 1 insertions, 114 deletions
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 0000000..3bedf6b
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1 @@
diff --git a/README.html b/README.html
deleted file mode 100644
index f1bbff7..0000000
--- a/README.html
+++ /dev/null
@@ -1,114 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
- <head>
- <link href="http://fonts.googleapis.com/css?family=Droid+Serif"
- rel="stylesheet"
- type="text/css"/>
- <link href="http://fonts.googleapis.com/css?family=Droid+Sans"
- rel="stylesheet"
- type="text/css"/>
- <link href="markdown.css" rel="stylesheet"></link>
- </head>
- <body>
-<h1>HTML activities - Draft 1</h1>
-<p>XXX Improve the Sugar OS developer experience</p>
-<p>XXX Cross platform sugar activities -> future</p>
-<p>XXX What is Sugar.</p>
-<p>The framework is composed of various libraries, initially</p>
-<h3>Interface description</h3>
-<p>Each module provides one or more interface descriptions which are language
-independent. A subset of object-oriented languages should be chosen, so that
-it's possible to implement these from all the languages we are interested
-to support. The description uses the Java syntax because unlike, for example,
-python and JavaScript it's explicit about types.</p>
-<p>For example, the datastore interface could look like</p>
-<pre><code>class Datastore {
- DatastoreObject load();
- void save(DatastoreObject object);
-<p>XXX The interface is totally made up!</p>
-<p>XXX What about IDL? Even if we don't use them initially the tools might be
-useful at some point.</p>
-<p>The implementation should be written as much as possible using web languages.
-But of course we will have the necessity to interact with native system
-components. The multi language nature of the interfaces will be useful here
-because it will allow to provide system specific implementation of certain
-interfaces and generically bridge to them from JavaScript. All the modules
-should provide a web fallback, which will allow to run the activity everywhere
-even if with degraded functionality.</p>
-<h3>Code style</h3>
-<p>View source is a core part of the sugar experience, so any kind of code
-obfuscation should be avoided. This includes languages that compiles to
-JavaScript, like CoffeeScript.</p>
-<h3>Namespacing and package management</h3>
-<p>We are using <a href="http://volojs.org">volo</a> for namespacing and package management,
-both in the libraries and in the documentation.</p>
-<p>Activities are <a href="https://developer.mozilla.org/en-US/docs/Apps">open web apps</a>,
-their only specificity is that can make use of our libraries framework. On some
-platforms (Sugar OS for example) it might be necessary to generate boilerplate
-code, configuration or to package the app in a certain way to have it integrate
-with the system flawlessly. We will provide scripts to fully automate those
-<h2>Implementation notes</h2>
-<h3>Sugar OS</h3>
-<li>We should probably use firefox, as provided by upstream, to run activities.
-Chrome would probably be an equally good alternative. At some point we could
-just support both.</li>
-<li>We should be able to customize it to look like a native activity without
-patching the code. We need to avoid showing any chrome UI (toolbar, menubar,
-etc) and to provide the X properties Sugar expects from an activity.</li>
-<li>We can generate activity.info from the webapp manifest when building a .xo.</li>
-<li>The svg icon might be provided in a native/sugar-os directory of the web
-activity or something.</li>
-<li>Communication between JavaScript and native code will be handled by a firefox
-extension and it will most likely go through DBus. pythonext might be an
-alternative but I'm not convinced we should get into pyxpcom again. We can use
-dom events to communicate between content and extension.</li>
-<li>Icons should be shipped as part of the graphics library, we can write a
-script to sync them with the sugar-artwork repository.</li>
-<li>The datastore interface should probably make use of HTML files support. I
-hope using local paths will work in a web activity.</li>
-<li>To get full permission I suspect a web app needs to be installed. We will
-have to figure out if/how we can avoid that.</li>
- </body>
diff --git a/Makefile b/docs/Makefile
index 3c2ad2f..3c2ad2f 100644
--- a/Makefile
+++ b/docs/Makefile
diff --git a/README.md b/docs/README.md
index 6192f64..6192f64 100644
--- a/README.md
+++ b/docs/README.md
diff --git a/TODO b/docs/TODO
index d7c00cf..d7c00cf 100644
--- a/TODO
+++ b/docs/TODO
diff --git a/markdown b/docs/markdown
index 3afb7b8..3afb7b8 100755
--- a/markdown
+++ b/docs/markdown
diff --git a/markdown.css b/docs/markdown.css
index 5ae7cbc..5ae7cbc 100644
--- a/markdown.css
+++ b/docs/markdown.css