Personal tools

HIDE/Design

From HaskellWiki

< HIDE(Difference between revisions)
Jump to: navigation, 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.

Contents

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

2 Base components

2.1 The bootup sequence

3 Project management

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

4 Editor

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

5 Dependencies, and plugin structure

Gtk2Hs:

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

Yi:

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

6 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

7 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"]