Difference between revisions of "HIDE/Design"

From HaskellWiki
Jump to navigation Jump to search
(→‎Dependencies, and plugin structure: that's an outdated link)
 
(6 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
This page is primarily for recording the conclusions of ongoing design discussions. That is for documenting the internal design of hIDE.
  
This page is primarily for recording the conclusions of ongoing design discussions. That is for documenting the internal design of hIDE.
   
−
= Plugins in General =
 +
== 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 [http://www.cse.unsw.edu.au/~dons/papers/SC05.html Dynamic Applications From the Ground Up].
  
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 [http://www.cse.unsw.edu.au/~dons/papers/SC05.html Dynamic Applications From the Ground Up].
Line 12: Line 12:
 
* 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).
  
* 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 =
 +
== Base components ==
   
−
== The bootup sequence ==
 +
=== The bootup sequence ===
   
  +
== GUI ==
⚫
= Project management =
  
   
  +
* Error messages from CommonSense.
−
Desired features:
  
  +
* 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.
−
* 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.
  
−
* GUI independance. That is the project management API exposed to other hIDE components should not depend on the GUI.
  
   
  +
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.
−
= Editor =
  
   
−
== Yi ==
 +
== 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.
  
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 =
 +
== Dependencies, and plugin structure ==
   
 
[[Gtk2Hs]]:
  
[[Gtk2Hs]]:
 
darcs get --partial http://darcs.haskell.org/gtk2hs/
  
darcs get --partial http://darcs.haskell.org/gtk2hs/
   
  +
See [[Yi]] for up to date Yi repo locations
−
Yi:
  
−
darcs get http://scannedinavian.org/repos/yi/
  
   
−
= Desirable Plugins =
 +
== Desirable Plugins ==
   
 
Add more as you think of them:
  
Add more as you think of them:
Line 66: Line 74:
 
* Harmonia (http://harmonia.cs.berkeley.edu/harmonia/index.html), which gives advanced language-aware facilities
  
* Harmonia (http://harmonia.cs.berkeley.edu/harmonia/index.html), which gives advanced language-aware facilities
   
−
= Division of labour =
 +
== Division of labour ==
   
 
Notes on who is doing what, and anything that is unassigned:
  
Notes on who is doing what, and anything that is unassigned:
Line 86: Line 94:
 
** pugs plugin for perl scripting?
  
** pugs plugin for perl scripting?
 
** look at darcs plugin
  
** look at darcs plugin
−
 
   
 
* lemmih
  
* lemmih

Latest revision as of 19:45, 22 February 2008

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

GUI

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

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/

See Yi for up to date Yi repo locations

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"]
Retrieved from "https://wiki.haskell.org/index.php?title=HIDE/Design&oldid=19287"