Editing HIDE (section)

== Development issues ==

Feel free to extend any of these with your own opinions.

There is now a [[hIDE/Design]] page for documenting the internal design.

=== The Windows question ===

ie "''will it run on Windows?''"

I don't see any reason why it shouldn't. All the basic parts we are using are cross-platform. Gtk2hs and hs-plugins run on Unix, Windows and Mac OS X.

That's not to say that every plugin will necessarily build on every platform. In fact we can use the plugin architecture to our advantage here to use different technologies to implement components on different platforms and to get better platform integration. For example consider the configuration subsystem; we might want to use GConf when using the Gnome platform but the Windows registery on Windows (or a simple file based implementaion on Windows and non-Gnome Unix platforms if people hate those sort of technologies).

However I don't expect that the plugability would extend to the basic graphical toolkit that is used. Though I do expect that many plugins would not need to be directly linked to a GUI toolkit if they do not need complicated user interaction.

BulatZiganshin: if using GTK will lead to need of installing additional software for Windows users of IDE, then it will be better to use wxWindows?

Piotr Kalinowski: I don't expect IDE to be such sort of software that you would frown at a single additional install of GTK libs. Would you?

Jeremy O'Donoghue: Agree that look and feel is not primary for IDE. However, wide acceptance will require that a Windows/Mac Installer be created, and this really needs to include all necessary libs to run.

For wxHaskell this is easy (2 DLLs in same directory as application, totalling ~4MB, and no registry entries needed). I've created several applications this way using Inno Setup - it's very easy to do.

For GTK it is harder - my Windows GTK directory contains 1850 files and 47MB (I assume similar problem for native Mac port - but I've never even tried: GTK was just too painful (and ugly) on Windows). You'll also need to create a few registry entries (HKLM/SOFTWARE/GTK/2.0/DllPath, Path and Version last time I looked).

It took me a week of part-time hacking to get a GTK+ developer install which worked, and I've never succeeded in packaging it into a single installer with a Windows app which reliably works. While GUI lib used for an IDE doesn't necessarily matter, packaging is a very big deal for a 'killer app' - it really does need to have a simple installation mechanism, so someone should look into this right from the start.

For me personally, I'd much prefer native look and feel on all platforms, but I'd live without it if HIDE was really a 'killer app'. However, failing to create a simple installation mechanism and/or hundreds of library dependencies mean that I'd probably never even try it to find out (life's too short).

Piotr Kalinowski: I suppose it is possible to use a separate installer for GTK+. How about the one from http://gladewin32.sourceforge.net ? There's runtime environment and development version. Personally I never had problems with GTK under windows at looks very well for me.

=== The GHC question ===

ie "how much GHC integration?"

The concern here is about a potential tradeoff between advantages of integration well with GHC (eg using it's API to get lots of info) and the disadvantage that it might become too hard to use anything other than GHC for the build.

It think that its clear that hIDE itself will require GHC to build because at the moment hs-plugins and Gtk2Hs do not support any other Haskell system. However if we can use different build systems or Cabal then it should be quite possible to target other Haskell systems like hugs,nhc,jhc etc. It may well be that we rely on GHC for some of the IDE features like error reporting and jump to definition etc.

[[Yhc]] is in the process of defining a [[Yhc/API/Compiler|Yhc API]], if the list of features required was specified somewhere, perhaps with some abstract API that meets HIDE's needs, I'm sure Yhc could support it too (in time).

BulatZiganshin: there must be standard interface to compilers with one implementation using GHC, another - HUGS and so on

=== The license question ===

ie "What license? GPL? LGPL? Other?"

Personally I would normally pick GPL for applications, however this would not be a normal application.

In this instance I would suggest LGPL for the core components since we want people to contribute extensions for their favourite tools. This may necessitate linking against existing code under other licenses. Authors may be reluctant to effectively relicense any code they include as GPL. IANAL but I believe LGPL would allow combining plugins with different licenses.

However of course we can only accept plugins in the official collection/distribution that are Free Software (since otherwise of course we cannot legally distribute them).

BulatZiganshin: are BSD license not appropriate?

Jeremy O'Donoghue: I don't see how HIDE can be anything except LGPL or GPL, given GTK licensing (it is would be hard to argue that it is not a derived work of GTK). This is another (big) difference of wxHaskell where license is more liberal, and would allow open or closed source plug-ins etc (whether this is an advantage depends on point of view).

Without getting into 'license' war, BSD or MIT license should be OK for a plug-in to LGPL/GPL licensed application. Release a closed source plug-in at your own risk (I wouldn't do it, for example, based on the legal advice I have received, but your legal advice may vary).

Piotr Kalinowski: Actually it is just an application linked against GTK+ and not a GUI library based on it. Since GTK+ is licensed under LGPL, that should impose no restrictions on HIDE license. Personally, I don't care as long as it is open source.

=== Plugins ===

Record of a stuff from #haskell. TODO: Format this better as issues get worked out.

 <Lemmih> dcoutts: Do we need to handle editor plugins differently from non-editor plugins
          or can we device some universal plugin API which handles both? Can plugins depend
          on each other? Can two editor plugins be loaded at the same time?
 <dcoutts> Lemmih, I don't think there is  single plugin API, there is a set of plugin
           interfaces. Some plugins will provide interfaces that other plugins can use. Yi
           would be one such example. The IDE shell would be another
 <dcoutts> plugins must be able to depend on each other
 <dcoutts> wether more than one plugin of the same variety can be loaded at once depends on
           the provider of the interface
 <dcoutts> eg how does an editor plugin hoist itself in? probably by registering itself with
           the IDE shell. So if the IDE shell allows more than one they yes.
 <dcoutts> I expect that for some kinds of plugins it'll make perfect sense to have multiple
           ones loaded at once, others it might be only one at once with a user preference
           to select which and others might be fixed (eg core plugins, or platform support
           plugins)
 <dcoutts> Lemmih, so the whole thing is a bunch of modules, there's no base app with a
           single unified plugin interface. The whole thing is plugin modules.
 <dcoutts> plugins can be linked against each other so they canprovide interfaces to each other
 <dcoutts> each plugin gets an initialisation function. That allows it to register with any
           interfaces it intends to implement
 <dcoutts> eg the core IDE shell plugin will provide interfaces for adding menu items and such
           like other plugins will linkagainst the IDE shell plugin and use it's public
           interface to register hooks like menu items

BulatZiganshin: see FreeRIDE below, they already developed powerful and flexible plugin architecture

=== UI ideas ===

Most IDE user interfaces look pretty similar these days. That's no bad thing particularly. It certainly gives us a good place to start and plenty of suggestions to think about. Here's a breif list of other IDEs that it would be worth gathering ideas from:

 * Eclipse - a highly extendable IDE for Java and other language. There is a detailed and interesting [http://www.eclipse.org/articles/Article-UI-Guidelines/Contents.html UI design document] available.
 * [http://anjuta.sourceforge.net/screen-shots Anjuta] - a Gtk/Gnome IDE for C/C++
 * [http://www.kdevelop.org/index.html?filename=3.2/screenshots1.html KDevelop] - a KDE IDE for C/C++
 * [http://haste.dyndns.org:8080/screenshots.php Haste] - a Haskell IDE developed for a university student project. (Dead link)
 * MS VisualStudio - many people swear by it. Can't find many screenshots however.
 * [http://slickedit.com/ SlickEdit] - apparently is quite good
 * LEO [http://webpages.charter.net/edreamleo/front.html] - User definable outlines and views to code. Not mainstream but good for ideas. See below for a mockup.
 * [http://pida.berlios.de/index.php/Main_Page PIDA ] - Python Integrated Development Application - this one looks interesting sharing some of our hIDE ideas 
Feel free to add more to this list.
 * [http://freeride.rubyforge.org/wiki/wiki.pl FreeRIDE] - Ruby IDE, useful because of similar architecture and motivation, reasonably well designed plugin architecture.
 * [Leksah] - Early stage haskell ide built in haskell. The "source candy" feature (giving nice symbols for lambdas, etc) is very nice. 
 * [http://squeak.org Smalltalk] - Different from all other IDEs as it does not work with files at all. Instead the IDE 
 works with the languange primitives - classes and methods. Why do we need files anyway? In Haskell IDE, 
 where files would (or could) be abstracted, the developer could focus on functions, types and type-classes. 
 Such IDE would be superior to all current technology.


The Eclipse example is particularly interesting because it is also a highly plugable IDE. They can't fix upon a single static UI design because it mught be extensable by many plugins. So it has to pick UI concepts and abstractions that many plugins can fit into. At least the first part of the [http://www.eclipse.org/articles/Article-UI-Guidelines/Contents.html eclipse UI design document] is well worth a read.

Let me (DuncanCoutts) now note down some of my UI ideas:

First of all, here is a little UI mockup.

http://haskell.org/~duncan/hIDE/hIDE%20main%20window.png

Yep is looks much like many other IDEs.

So we have 3 pannels and a menu and toolbar. The main focus is of course the editor pane. The other two can be hidden away to get the maximum screen space for the editor  (which is a common IDe problem, that they take up too much screen space).

The left hand pane is a collection of views of pages, or rather a way of navigating between pages. So they are lists or trees of pages. Selecting a page opens that page in the main editor pane. The reason for having several tabs of these views is that sometimes we need different views. For exaple, in the UI mockup above we've got a modules and files view. The files view would list all files in the project directory tree, selecting any of the would allow you to edit the file. The modules view on the other hand  lists just the Haskell modules rather than all files. This is probably more useful when doing ordinary coding. The modules view would list all files that are the primary source, so for example when using a module that needs pre-processing, eg a .hsc .chs. .y or .x file, then the modules view would show only that file and not the generated .hs file - the generated file would be visible through the files view.

The intention is that plugins could register their own views. What I am describing is an example of a possible default configuration. To make the vies/pages system quite flexable one idea is that all pages should exist in a singe rooted tree and that the tab are multiple views into that tree. For example the configuration in the mockup could be described as having four views, rooted at /files, /modules, /open, /tools respecvely. That would allow the user to configure it with one single tree view rather than having multiple tabs. It would also allow a view to show only a subtree, which might be useful perhaps in a very large code base. So in that scheme, plugins could register pages or whole subtrees of pages and setup views to look into them.

The third pannel is for tools to display a UI to interact with the user. Examples of these tools could include things like search, interactive window, error messages etc. anything which you might want to have open at the same time as an editor page.

-----

Another vision for hIDE is
http://www.cc.jyu.fi/~aleator/yide.png. (how do I get a link
instead of picture?)

On the left there is user editable treeview which can contain different types of nodes. Some nodes will become
modules and others are there for documentation. 
Some nodes can contain interpreters that have other
modules loaded or other dynamic output. Nodes can be
cloned so same node can appear at multiple places in
the tree.

Point is that the whole tree is user built. (Though you can provide templates for lazy.)

Right side is normal splittable editing panel.

The point is that everything is in the outline. You (user) can make different nodes for different things and organize your workflow as you like. You could build different
views, for say, bugs. Just collect all things related to a bug (tests, code, documentation) into single outline for easy manipulation and reference.

Different types of nodes is the main extension direction of this plan (besides editor interface with type checking etc).
You could even make nodes that contain extension code that 
dynamically produces the node contents so as to make extending
easy.

You could start with simple @module node that reflects a haskell module. Then Ordinary node that will be just documentation. Then perhaps ghci node, build log node, timetable node, project management node.. (see pivotal for
great inspiration)