Make UI development not suck

[Jason Gerard DeRose]

Okay, this has been a long time coming.

desktopcouch pioneered having desktop apps talk to a locally running, per-user CouchDB, and using CouchDB's rather amazing multi-master replication to sync these apps to the cloud. This is kick ass stuff, and I think something highly valuable for the Ubuntu + UbuntuOne platform, because it's quite unique.

desktopcouch was really designed around the idea that apps shouldn't have to talk to CouchDB directly, because if you're building, say, a Gtk or Qt app, it's a bit awkward. So desktopcouch provides things like libdesktopcouch-glib, which I assume provides a quite nice experience if you're building a Gtk app. (I haven't personally used it, read on...)

However, the Novacut components need to talk to CouchDB directly, largely because we're using embedded WebKit for as much of our UI as possible. So in our case, it's far easier to talk to CouchDB directly.

One of the rationales for using WebKit was to allow a high rate of innovation on the UI by using tools that the largest number of people are familiar with. We want the UI to be a collection of html, css, and js files, and for people to be able to open these files in their text editor of choice, make some changes, and basically hit reload to see the result.

But right now, this process totally sucks as in order to be able to request the html pages from CouchDB (which is by far the best thing for us to do), we save all the html, css, and js files as attachments in the special /dmedia/app document. Each time the DBus service starts, it checks the WebUI files and makes sure they match the attachments in /dmedia/app. But this is silly to do as these files are not user data, they're package data, and saving them into CouchDB just for the sake of making the UI development more natural is a pain.

Another issue is that we need it to be easy for one app (say Novacut) to utilize at least JavaScript shipped by another app (say dmedia). And we want to make it easy to use your in-tree files for one app as you work on the UI, while using packaged files shipped in other apps at the same time. After a lot of thought, I finally have what I think is a good solution. It's at least a good solution for UI designers, and at this point, that's my only concern.

Ah, and we don't want to rely on templates to fix the paths to html, css, and js files... that's part of the existing sucky solution, but it hasn't been well received by UI designers. [Pro tip: keep your UI designers as happy as possible.] There are 4 parts to the new solution:

==| _apps handler |==

First, we're adding a CouchDB HTTPD handler for /_apps/* that serves static files from /usr/share/couchdb/apps/*. So the couch.js file that currently ships with dmedia will be installed as:

  /usr/share/couchdb/apps/dmedia/couchdb.js

Which you could then request at, say:

  http://localhost:39846/_apps/dmedia/couch.js

==| Request external assets with absolute paths |==

Now say a UI designer working on Novacut wants to include the dmedia couch.js file in a Novacut UI page. They should always use an absolute path like this:

<script type="text/javascript" src="/_apps/dmedia/couch.js" />

==| Request internal assets with relative paths |==

On the other hand, say the same UI designer also needs to include a novacut.js file that ships in the Novacut component. They should always use a relative path like this:

<script type="text/javascript" src="novacut.js" />

When you launch `novacut-gtk` from the installed package, there will be Python smarts behind the scenes that figures out the desktopcouch (or dc3) environment and point embedded WebKit to, say:

  http://localhost:39846/_apps/novacut/novacut.html

==| _intree handler |==

It would be a pain to have to build and install Novacut just to see a UI change. It would also be a pain to edit the files in /usr/share/couchdb/apps directly. We want UI designers to be able to edit files directly in the source tree, because that's what's natural for web development.

So there will be a special command in my experimental dc3 (a desktopcouch alternative) like this:

  dc3-control InTree webui/

Which would add a CouchDB HTTPD handler for /_intree/* that serves static files from within the source tree you're working in! There will be a another special command for launching an Window with embedded WebKit and pointing it to, say:

  http://localhost:39846/_intree/novacut.html

The special embedded webkit tool will understand the desktopcouch (or dc3) environment and will transparently take care of stuff like figuring out the port and OAuth signing the requests.

Now because you use relative paths for internal components, this will all work fine and dandy with no modification to the html files. Which means this is pretty darn close to as easy as normal web development... which is the goal.

I actually discussed this with the desktopcouch folks at the last UDS, but they weren't convinced:

https://wiki.ubuntu.com/DesktopCouchWishList#Standard_location_for_static_webUI_files

Hopefully they change their minds after seeing it in action. This may seem like an "impure" solution, but I don't care. It's a pragmatic way to make life easier for UI designers. I've already laid the ground work in dc3, and will shortly make the corresponding changes in dmedia. I hope this design gets adopted by desktopcouch, but right now we need to quickly get Novacut usable, so I'm doing the work in dc3 where I don't have to worry about breaking things that depend on desktopcouch, nor first convince the destkopcouch folks this is the right approach.

[Jason Gerard DeRose (jderose)]

Okay, time to blast away on this. For anyone who might have noticed, I quietly added the above non-sucky UI dev process already in novacut, so I'm going to base it on that.

For now, I'm copying and pasting and experimenting till I get the pattern right, and will then move it to a standalone component.

Oh, and there is another feature I'm adding, a very exciting one... I'll give you a hint, for those of you running Oneiric with the Novacut Daily PPA:

Run `novacut-gtk` and then right click and "Inspect Element"