Revision as of 07:08, 21 September 2010

Blur (my Honours project)

Project Summary

My Honours project, nicknamed Blur, is a program that provides a global command line interface which mirrors the functionality of the GUI in any application. It uses self-demonstration to encourage users to transition from the GUI to the command line. In other words, whenever the user invokes a command with the GUI, Blur pops up showing the command line text that will perform the equivalent action.

Examples of the auto-complete in action

An example of the self-demonstration feedback

Design Goals

• Provide a text interface to commands
• Provide intuitive typeahead and auto-complete suggestions
• Create a reusable autocomplete component (i.e. not coupled to Blur-specific functionality)
• Command suggestions should be unambiguous (not currently the case)

Initial Design

The following UML diagram shows my initial system design, with some details omitted (such as utility classes that wrap the Win32 functionality, and the class hierarchy containing all the different Commands). In this study I will focus mainly on the auto-complete functionality.

Tour of the design

The CommandForm class constitutes the main GUI of Blur. It follows the Singleton pattern with a minor modification: it is not lazily loaded. This is because I need to be able to manually initialise the GUI when the program starts. After that, there can only be one instance of the CommandForm, and it can be accessed by the static CommandForm.Instance property.

The CommandForm contains one control - the AutoCompleteCommandLine. This class contains most of the logic for the auto-complete functionality, and is responsible for drawing the command line prompt, user input, typeahead and other feedback on the form. Whenever the user inputs some text to the command line, it generates a new AutoCompleteResultSet. This is essentially a collection of AutoCompleteEntries, with some custom logic. It needs to be able to order AutoCompleteEntries in order of relevance, by sorting them into three categories: exact matches, where the user's input exactly matches a valid command, prefix matches, where the user's input matches the beginning of a valid command, and substring matches, where the user's input matches some inner substring of the command. Internally, it uses three separate lists to achieve these (res_exact, res_start, and res_include), and each of these lists is sorted in order of the frequency of use. The AutoCompleteSet also contains the logic to populate itself, given a search string and a list of possible command strings.

AutoCompleteEntries, which represent the command suggestions that show up beneath the command line, are internally represented as strings. An AutoCompleteEntry stores a ListText string, which is displayed in the suggestion list, an AppendText string, which is appended to the user's input, and a GetStartIndex() method that figures out where the AppendText should be appended, given a user input string.

The AutoCompleteCommandLine searches for commands from an ICommandSource, which is set externally via the CommandSource property. The ICommandSource interface has a single method called GetCommands(), which returns a dictionary of available commands, indexed by their names. The interface should enable reuse of the AutoCompleteCommandLine component, by allowing clients to define their own command sources. The AutoCompleteCommandLine takes all of the names from GetCommands() and uses them to construct an AutoCompleteResultSet.

ICommand provides a minimal interface to commands, that exposes only the functionality required by the AutoCompleteCommandLine. Implementing this interface is an abstract Command class, which provides the functionality common to all Blur specific commands. Command has a bunch of subclasses (not shown) which implement the individual command functions.

Critique

Ideally, I would like the AutoCompleteCommandLine, AutoCompleteResultSet, AutoCompleteEntry, ICommandSource and ICommand to be completely decoupled from the rest of the design. This is mostly true, but not completely. For example, the AutoCompleteCommandLine is hardcoded to search for a "switch" command in the ICommandSource dictionary, and if it exists, to autocomplete on its parameters without having to have the "switch" keyword present (an example of this kind of autocomplete entry is shown in the 3rd screenshot at the top of the page).

The other large issue that I see with the design is with the AutoCompleteEntries. It exposes public data directly (violating

TODO: Split up class diagram into a more meaningful sequence Model the real world Meaningful class names Keep data private (is AutoCompleteEntry a data class?) Command pattern Mention that autocomplete entries are string-based rather than command-based Mention requirements of being able to complete on commands, parameters or both at the same time (e.g. switch parameters with no command) Review Josh Bloch's stuff about APIs

Design maxims followed

blah blah blah

Design maxims violated

blah blah blah