Ben Galbraith's Blog

Greasemonkey Goodness

If you haven't already taken a look at Greasemonkey, you really ought to. Maybe even right now (note: Firefox required).

Greasemonkey is a Firefox extension that enables folks to modify the contents of a website in realtime. For example, if your favorite blog's comment textarea is too small, make it larger yourself. Forced to manually click a bunch of checkboxes? Automate it. A bunch of Greasemonkey scripts are available to fix general website problems, and a bunch more to add new functionality to popular websites.

This is huge. We've had to put up with poor user experiences in applications ever since the dawn of the desktop computer (some more than others). Being able to fix annoying website UI glitches is a wonderful experience.

But I want more. Some of my most frustrating experiences involve desktop applications (such as a certain personal finance software package); what's the equivalent of Greasemonkey for such apps? More relevant to this discussion, what's the equivalent for Java desktop apps? Could it be something like exposing the Swing component hierarchy to power users for manipulation through some sort of general tool?

Yikes. The web's innate separation of client and server tiers makes this kind of thing seem much safer to me. You can't use Greasemonkey to manipulate moving parts that aren't exposed to the UI tier; having somehow directly interface with the business logic tier of a desktop application scares me to no end.

If not a general Java state manipulator (a la modern debuggers), is it external scripting against a published API, like AppleScript or ActiveX? The general problem with this approach is that these APIs are often too coarse-grained to enable the type of powerful modifications that Greasemonkey make's simple. Automator on OS X is nice, but its not nearly powerful enough for this kind of interaction.

Maybe the equivalent could be a light-weight automation/user interaction API on top of Swing... a scripting interface that integrates with the new Rhino/JavaScript engine in Mustang? Interesting...

Regardless of the specific implementation, the notion of empowering users to customize the UI in ways the designer never intended seems so compelling as to be a feit accompli in the future of application development.

Comments

• If you're posting to forum.java.sun.com, there's a modification of the Linkify script that works around the lack of link tags, see this thread.

  Now we need something that will counteract the bugs in the edit form when you use preview on these blogs.
  

  Posted by: pete_kirkham on June 16, 2005 at 05:23 AM

• It seems like some equivalent of CSS for Swing should be possible; I know there are people who have been working on this, but don't know the status. You could, at the least, set fonts, minimum font size, colors, and so on. With a simple properties editor it could be made pretty safe (and restricted). Patrick

  Posted by: pdoubleya on June 16, 2005 at 06:36 AM

• pdoubleya: I've thought a bit about that, too. Eitan Suez has been known to call CSS "aspect-oriented styling." That's not a bad way to recast it. Synth introduces the notion of Style instances that paint Swing widgets; such instances could be pooled and configured in a meta fashion. Sounds like Synth 2 could consider a more granular API that would enable meaninful runtime interaction with the Style instances. That would actually be really cool... I'll have to put a bug in Scott's ear.

  Right now, of course, the Style API is tremendously coarse, and all the XML implementation of Synth does is allow the Styles to be configured statically. I guess someone could expose the DOM representation of the XML Synth configuration file and rewire Synth to create new Style instances when the DOM changes... that could be interesting, too.

  Posted by: javaben on June 16, 2005 at 07:55 AM

• The previous two comments seem to be synergistic with one of Ben's earlier posts about re-casting Swing to use a container metaphor. If Swing were changed to use a container model to deal with all of those nasty threading issues, then it would also provide the kind of decoupling that would make something like GreaseMonkey more viable in desktop applications without the fear of messing with the inner business logic.

  So, maybe these two separate ideas (Swing Container and Scriptable Desktop UI's) actually bolster the case for each other.

  Posted by: mcrocker on June 16, 2005 at 11:19 AM

• At first I thought "this really cannot be done in any practical sense, other than using some sort of super-duper AWT Robot class, linked to a scritping engine." It's just too mammoth a task, there are too many Swing components, and their interactions are too complex to expose all their behaviours with completeness. And besides many applications use at least one bespoke component or layout manager, and these too will have to be written to subscribe to our 'greasemonkey' technology, which I suspect developers will be reluctant to do (as nobody likes to admit their baby is less than perfect!)

  Then it struck me that there might be a way in... Swing is built around a variation of the infamous MVC pattern. We don't have to manipulate the UI - with its large and sprawling list of components and functionality - but instead we should target the points of contact between model and view/controller ('delegate'). These are limited to a handful of concise interfaces - *Model, *CellRenderer, *DataListener, etc. By inserting our scripts at this point we can generate fake events to a model, and manipulate how Swing views the model.

  Then another route occured to me... One of the touted benefits of Model View Controller is that it allows views and controllers (output and input) to be replaced (or supplimented, via a compound PLaF which can wrap the user's choosen PLaF?). One obvious application of this is to allow for accessibility, for example. And Swing does claim to have accessibility support (although I have to plead guilty, along with a lot of other Java desktop developers I suspect, to never having really paid much attention to it.). 'Greasing up' Swing could be as simple as exploiting the existing PLaF/Accessibility architecture to slip scripting into the UI. This would mean existing applications could be 'greased up' without modification.

  I think the first solution is more managable (and ultimately less of a headache to the end-user, as it cuts out all the complexity of manipulating the UI and cuts straight to the low-level stuff of manipulating a component's underlying data model), but I don't know how it could be injected into existing applications without said application being modified to support it. The second solution exploits an existing feature of Swing (PLaF and Accessibility) and therefore could be plugged into any PLaF-friendly desktop application without modification, but it effectively amounts to creating another look and feel - and we all know how fiddly and time consuming that can be.

  Posted by: javakiddy on June 17, 2005 at 02:42 AM

• mcrocker: Interesting comment... the container would certainly give you someplace to hang the functionality.

  
  javakiddy: I had the same thoughts about the accessibility stuff, because, like you, I'm utterly unfamiliar with it but it seems relevant ;-). Yeah, I'm not sure that interacting with the UI/model adapters gives sufficient granularity. But some combination of interacting with the component tree (including models/adapters), event listeners, and AOP techniques (adding before/after handlers to listeners, for example) might be the ticket.

  
  Ultimately, I'm not sure the Greasemonkey concept can make the leap to Java clients (or desktop apps in general). The contract is just too loose. Web guarantees a barrier between presentation tier and server tier. Most you can do is muck around with the end-points. But, with desktop apps... the things you can do get scary. There's a culture of discipline in the web that says you must assume that the user may modify the way in which end-point services are invoked, but in desktop-land... how does that translate for a thick client? It's complex enough if you actually have a multitier app, but if you don't (concerns are all mashed together)... brittle stuff.

  
  I'm rambling at this point, but it seems to me that enabling users to modify the application UI at run-time needs a new semantic layer and contract enforcement mechanism -- or at least a new discipline -- before it can be trusted to work. And, something like a Swing container could manage such a contract and provide such a discipline. ;-)
  

  Posted by: javaben on June 17, 2005 at 12:07 PM

This work is licensed under a Creative Commons License.