I've published a version of LinkuisticsLAF that loads into VW 7.7, sep09.4. There are a few minor issues, but it's usable. Note that version won't work for 7.6.

My initial adaptation of LinkuisticsUI to enable it to load in VW 7.7 (sep09.3) has worked. It still works in 7.6. Not yet available in the public store, but soon.

It has some visual glitches - font baselines seem slightly different, the splitters are unusably slow, the tab control overflow arrow mechanism has changed, and the icons don't play nice. I'm planning on retaining my icons for the lists, except maybe the package tree. Primarily because matching the new icons is an unrealistic amount of work. This is the main reason my iconography looks like it does - people without artistic ability/tools can extend my icon set without it looking like a dogs breakfast. This seems to me to be an absolute requirement in a user-extensible environment such as Smalltalk, which isn't feasible with the more usual icons that VW used/uses. I coincidentally find the less in-your-face design more attractive and usable.

I've been distracted from writing a MirrorImage walkthrough by a discussion on vwnc about Pragmas. One of the final entries was this blog post by Michael. Apart from his surprising advocacy for text as UI - why not extend that argument from a single method to multiple methods, and then to the class - the comment that stood out for me was "Is it easier to pull down a menu to define an attribute on a method, or easy enough just to write some code...". Quite true. VW requires that just about everything is done with the mouse. On OSX at least, the very few keyboard shortcuts only partially work, and in any case you can't use the command key for anything but C/C/P. So all of my muscle memory on my wonderfully uniform (and configurable so) OSX works against me when using VW.

As an aside, text editing in in VW is not just poor, it's appalling. The code editor completely blows. And the implementation of error messages being inserted in the text is IMO not only a crappy idea, it's a complete PITA as implemented. In a recent vwnc thread about this it was asserted that the error message was always selected so you could just hit delete immediately after accepting in order to clear the message. Not so. I started monitoring this after being told about this 'convenience'. Most of my errors leave part of the message selected, and part not, so it's no wonder I hadn't noticed the 'convenience'.

All of this means that whilst on a macro level VW is wonderfully productive, on a micro-level it is anti-productive. The reverse of this situation is something like TextMate. TextMate is optimized for entering and editing text, and is amazingly, beautifully tuned for this task. What I'd like is TextMate micro-convenience and slickness in a Smalltalk environment.

All of that got me thinking about how to achieve some TextMate goodness in VW. And you know what? It's neither difficult nor a lot of work. Unless of course you need to maintain 100% compatibility with customers with a gazillion of mission critical GUI screens dependent on extensions and monkeypatching of the GUI framework.

I decided to start with command invocation, which I've implemented and published in the LinkuisticsUI-Commando bundle.

I've done a screencast showing the system in action. Instructionally its useful to watch both before you read the rest of this post, and afterwards. It's a bit cheap, especially the audio, but I'm not feeling well enough to walk to my studio and do a pro job. Also it's h.264 to lower the file size, so please forgive any minor artifacts.

What is a command?

In abstract, a command is the thing behind menu items, shortcut keys, text snippets, and non-semantic tab completions. The most obvious characteristic of a command is that it does something when it is invoked. Commands are applicable in a particular context e.g. 'Delete Class' might be applicable only if a class is selected. Or maybe that command could also operate without a selection by raising a class selector if there is no current selection. Commands execute in a certain context and may require information from that context (such as the currently selected class) in order to execute. The enablement of e.g. a menu item, is an indication of whether the command is applicable in the current context. Commands can be invoked in a number of ways: from a menu, or via a shortcut key, or by pressing tab at the end of a given text string in an editor, or from a list as in TextMate, which uses a nice filtering mechanism to allow commands to be quickly and concisely selected. Another benefit of list-of-commands UI is that you can easily discover all of the commands available in a given context, and check their shortcut invocations. It also allows you to disambiguate control-key shortcuts with multiple resolutions, and provides an obvious source for task/command-specific linking to help.

The implementation

There is a global registry of all commands known to the system in Commando.Commands. Commands are registered in getLUICommands class methods, which are discovered via reflection. There is currently no mechanism to monitor changes, so you have to manually invoke Commando.findAllCommands to (re-)install them, or you can use the command UI - there are commando commands registered. Each command has a name, which can be constructed from a hierarchical path. The use of a path means that the command is easier to filter and the name doesn't have to jump through linguistic hurdles to include it's context. It's also the basis for replacing the menu system by a filtered view of extant commands, which is my intention. A command can have a shortcut, which is either a control key shortcut or a tab-triggered prefix for text-based snippets. Finally, a command has to implement applicableInContext: aContext and executeInContext: aContext, the meaning of which should be obvious.

I haven't implemented the tab-completion mechanism yet, partly because to be be as good as TextMate it requires more extensive changes to the text editor. For example, when inserting a fragment that has placeholders you should be able to tab between the placeholders to fill them, including tabbing backwards which on my system triggers the emergency evaluator :(. Improving the text editor is on my list of things to look at.

What is a context?

My implementation handles all invocation in the KeyboardProcessor, whose currentConsumer is regarded as the source of the context. The context that is used is a list of objects which are created by visiting the source, it's components and it's parent in a (potentially) recursive manner. It's a trivial mechanism, but it works. You can end with VisualParts, models/applications, windows and controllers in the list.

My original plan was to have objects such as the BrowserNavigator decompose their state so that you would have individual context entries for each of the types of code model objects e.g. Classes/Protocols/Pundles etc. Commands applicable to a given code model object could then trivially operate in any UI which exposes the code model. This is related to the idea of more directly reifying the code model in the interface. It turns out that a lot of the existing UI uses BrowserNavigator, and given that I automatically include the RB commands, which naturally integrate with a BrowserNavigator context, I decided not to do any further decomposition unless I actually build a code-model-reifying UI.

Menu itegration

I have a rough plan for how to build menus from commands, thus replacing the menu system. It's particularly obvious when considering the OSX situation, which for native integration wants a single menu bar, but it's also applicable to menu-per-window model, and trivially replaces existing popup-context-menu systems - it is after all a generaisation of the concept of a context menu.

The published version includes code that processes the RB's menus to create code model commands. The RB already has a command-based system, although that model is somewhat more declarative, which reflects the fact that RBCommands are manipulated by a command definition UI.

But ...

The UI for this works well, but unfortunately the rest of VW isn't really setup to deal well with keyboard navigation, so often you can invoke a command using the keyboard and then you have to switch to the mouse to navigate the result. And as you can see in the screencast, even the mouse behaviour is sometimes annoyingly wrong, particularly in list selection.

I'd like to do something about keyboard view manipulation, and add a similar interface for navigating both to and within code model elements, but that's probably best done in the context of a different type of browser.