Difference between revisions of "HIDE/Design"

From HaskellWiki
Jump to navigation Jump to search
Line 17: Line 17:
   
 
= Project management =
 
= Project management =
  +
  +
== Core API ==
   
 
Desired features:
 
Desired features:
Line 22: Line 24:
 
* No import overhead. Must work with all Cabal projects without any user interaction.
 
* No import overhead. Must work with all Cabal projects without any user interaction.
 
* Nice interface for running Cabal commands like 'build', 'haddock' and 'test'.
 
* Nice interface for running Cabal commands like 'build', 'haddock' and 'test'.
** Menu items: Project/Cabal/[Configure|Build|...]. These commands needs to print their output in some window.
 
 
* Management of the meta info in *.cabal.
 
* Management of the meta info in *.cabal.
 
** Menu item: New Cabal Project
 
** Menu item: New Cabal Project
  +
** Custom editor for each GUI to edit .cabal files and report changes back to the main project management API.
  +
* The .cabal file should be validated using the GHC api.
  +
* Files displayed in the file browser should show whether or not they're included in the current project.
  +
* The file browser should allow easy inclusion/exclusion of files from the current project.
 
* GUI independance. That is the project management API exposed to other hIDE components should not depend on the GUI.
 
* GUI independance. That is the project management API exposed to other hIDE components should not depend on the GUI.
   
Line 88: Line 93:
 
** pugs plugin for perl scripting?
 
** pugs plugin for perl scripting?
 
** look at darcs plugin
 
** look at darcs plugin
 
   
 
* lemmih
 
* lemmih

Revision as of 16:36, 22 January 2006

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).

Base components

The bootup sequence

Project management

Core API

Desired features:

  • No import overhead. Must work with all Cabal projects without any user interaction.
  • Nice interface for running Cabal commands like 'build', 'haddock' and 'test'.
  • Management of the meta info in *.cabal.
    • Menu item: New Cabal Project
    • Custom editor for each GUI to edit .cabal files and report changes back to the main project management API.
  • The .cabal file should be validated using the GHC api.
  • Files displayed in the file browser should show whether or not they're included in the current project.
  • The file browser should allow easy inclusion/exclusion of files from the current project.
  • GUI independance. That is the project management API exposed to other hIDE components should not depend on the GUI.

Editor

Yi

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

Gtk2Hs:

   darcs get --partial http://darcs.haskell.org/gtk2hs/

Yi:

   darcs get http://scannedinavian.org/repos/yi/

Desirable Plugins

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
  • Hoogle
  • 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:

  • dcoutts
    • develop the UI
    • help with misc gtk issues
    • config subsystem
  • dons
    • 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
  • lemmih
    • CommonSense
    • project management / build support / cabal integration
  • unassigned
    • win32 support. See ["hIDE/Win32"]