This page is primarily for recording the conclusions of ongoing design discussions. That is for documenting the internal design of hIDE.
Plugins in general
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).
The bootup sequence
- Error messages from CommonSense.
- Menu items from various plugins.
- Editor abstraction.
- Model/view split so that the same file can have multiple views.
- Mouse gesture handling. (how will this work with ncurses?)
- Page browsing
- By files
- By module name space
- By module dep graph
- 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.
The core editor functionality will be provided by Yi, which provides both a standalone editor along the lines of vi or a stripped down emacs, and also a plugin interface.
Dependencies, and plugin structure
darcs get --partial http://darcs.haskell.org/gtk2hs/
See Yi for up to date Yi repo locations
Add more as you think of them:
- The GHC api.
- TeX typesetting (Easier if you have syntax tree available)
- HaRe ( automatic refactoring )
- Darcs ( revision control )
- Pugs ( perl scripting )
- GHCi ( haskell scripting )
- On-the-fly haddockizing?
- Cabal management, a la VH
- Pointless ( Thomas Jaeger's pointfree refactorer)
- Support for construction of QuickChecks
- Ginsu? (very emacs-ish ;)
- Jump-to-definition in standard library
- Spell checking comments
- auto indenting based on pretty printing the syntax tree
- module dep graph as a module browser view
- compilation via ghc-api (with -fasm)
- automatic insertion of type declarations for expressions
- automatic handling of minimal module imports
- talking to external theorem provers, for example, a la ProofGeneral
- alternating background colour based on bracket level as part of syntax highlighting (syntax backlighting?)
- Harmonia (http://harmonia.cs.berkeley.edu/harmonia/index.html), which gives advanced language-aware facilities
Division of labour
Notes on who is doing what, and anything that is unassigned:
- develop the UI
- help with misc gtk issues
- config subsystem
- get yi back into 100% functionality (fill out the broken Yi.Core)
- complete yi gui based on gtk (i.e. minibuffers, window splitting etc)
- indenting plugin based on Ppr
- embed ghci
- clean interface to syntax highlighting in Yi,
- get quickcheck tests working with new gtk buffer
- plugin/standalone-neutral access to ui
- Reducing dependences
- pugs plugin for perl scripting?
- look at darcs plugin
- project management / build support / cabal integration
- win32 support. See ["hIDE/Win32"]