Write throw-away, prototype code

I don't think I do enough quick prototyping. So to help me change that, I'd like to start putting together a "short list" of things I think should be explored. I'm not talking about a full fledged project with mailing lists and forums like typically happens. Just some code showing how things could be; allowing us to see if we like it. And of course, be willing to throw it all away at the end of the day.

1) A FUSE filesystem driver for installing applications. The end result would be where I can drag an application (a .deb, .rpm, or whatever an ISV wants to ship) onto an "Applications" folder that is nothing more than a FUSE driver to hook into package-kit. For extra credit, allow shoving some html/css/js/svg into a .deb or .rpm so that when it is "opened" it shows neat little backgrounds with drag-n-drop support for installation (I'm thinking nautilus+webkit). The .deb/.rpm could even include a meta file for where the upstream source is so the package manager can maintain application updates.

2) Compiz (or Mutter) plug-in that allows applications to alter their state during run-time. It want it to be as simple as:

win = gtk.Window()

Also, if we go beyond this and allow some of the GL animations to be pushed onto a thread within the application, it will be possible for apps to provide effects that make sense within the context of the task at hand. For example, I'd love gnome-do to have some sort of cute animation when leaving the screen rather than just gtkwidgethide().

3) Compiz (or Mutter) plug-in that shows Modal windows similar to "sheets" on OS X. As I've been playing with this the last few days (from my gtk+ patch), it's become pretty obvious to me that it's good from a usability perspective.

4) Performance tuning is always a pain in the ass. So I'd like to have a "perfkit" that can encapsulate all the tuning utilities out there. Whether its strace, ltrace, oprofile, systemtap, or some python script your co-worker wrote. This would also give us somewhere to store application-level counters in a sane way. Imagine being able to record input events from GDK and then play them back on subsequent profile runs while you then profile other aspects of the application. Strangely enough, if you slow down the sample rate, you basically have kick ass remote monitoring sans-snmp.

FWIW, I've already started hacking on this but got side-tracked by a few other things (including up some contract work so I can continue to ... you know ... eat).

5) Rails, sea-side, and other pioneering web-frameworks focused a lot on input validation. This sort of thing is missing from the gtk+ toolkit and would be a lovely addition to 3.0. I started on a quick idea around this using two concepts; validators and modifiers. Validators give us a way to check validity of content, and modifiers will modify a series of widgets upon validation failure or success. Source.


6) The future of web-squared (or whatever they call it now) is all about data. That's quite obvious I'm sure. However, why do I need to retrieve various bits data from a service just to transform it into some other format I want to display. These Web-Services seem arbitrarily limited. Why can't we push small snippets of code to the service to run within a sandbox to format the data as I want. It's really not any different from map/reduce I guess.

So how about server side java-script? It provides a simple language that could have "lazy-loaded" data within the scope of the script. It could be multiplexed into a co-routine framework for time-slice enforcement. The scripts could be pushed as simple HTTP POST's. And even more-so, it's a language that web-geeks already know.

For example, I could have access to all my personal info via a webservice on my server. And within it, "user" would be a lazy loaded variable. Maybe I want to get access to my email inbox with "user.email.inbox.each(function(m) {});".

I'm curious how much bandwidth this would save too.

-- Christian Hergert 2009-08-02

Back to Index