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
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.
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/
Which you could then request at, say:
==| 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:
==| 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:
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:
==| _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/
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:
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:
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.
- dmedia Dev: Pending requested 2011-09-26
Diff: 998 lines (+184/-697)16 files modifiedcouchdb-latency.py (+80/-0)
|Changed in dmedia:|
|status:||Triaged → In Progress|
|Changed in dmedia:|
|status:||In Progress → Fix Committed|
|Changed in dmedia:|
|status:||Fix Committed → Fix Released|