Contents

Almost the whole of hIDE will be dynamically loaded, except for a tiny static core which is responsible for bootstrapping the main application and providing a plugin loading service. You can read more about this application architecture in the paper Dynamic Applications From the Ground Up.

Plugins will be Cabal packages. This provides a number of advantages over simple object files:

Provides a build infrastructure

Allows plugins to depend on each other easily

Allows plugins to be built seperately or "out of tree"

Provides useful metadata like author, description, license etc

Big advantage: anyone who's written a cabalised library potentially has written a plugin for us. All they need then do is work out a gui wrapper (perhaps we should provide a skeleton for this).

Configuration pages. These can be a special case of general pages, possibly with a different UI style.

Project settings

The core GUI infrastructure must be flexible and extendable by other components. So for example we cannot have a fixed set of tool bar buttons or menu items. These must be added by other modules. So for each component that needs a GUI, that component will use functions exported by the main GUI to register itself as a provider of some feature or other. That may be as simple as adding a menu item or as complex as providing a new kind of browser view or editor page.

The core GUI infrastructure defines these interfaces that other components can implement, for example "BrowserView" and "EditorPage". The GUI then deals with them fairly generically.