Difference between revisions of "ApCoCoA-1:Eclipse GUI"

From ApCoCoAWiki
 
(23 intermediate revisions by 3 users not shown)
Line 1: Line 1:
−
==The Eclipse GUI Project==
+
=The Eclipse GUI Project: Goal of the Project=
−
 
 
−
===Goal of the Project===
 
 
The overall goal of the project can be described as follows:
 
The overall goal of the project can be described as follows:
  
 
   To create a state of the art, platform independent Graphical User Interface for faster CoCoAL program and prototype development.
 
   To create a state of the art, platform independent Graphical User Interface for faster CoCoAL program and prototype development.
  
−
===Project Plan===
+
 
 +
 
 +
=Project Plan=
 +
Phase 1: Introduce a comfortable Editor covering as much features as provided by the Emacs interface.
 +
 
 +
==Currently in Progress==
 +
* Test if Xtext is suitable for generating a comfortable CoCoA Language editor.
 +
* Add autoformatting / indentation
 +
* Make a downloadable Eclipse+ApCoCoA bundle
 +
* Create splash screen and icons
 +
 
 +
==ToDos==
 +
''P1''
 +
* Show documentation when hovering over functions
 +
* Complete ApCoCoA perspective (open two consoles, set console preferences like "Show...when...changes")
 +
* Add packages-representation node to the project view (make packages files available easily)
 +
* Error annotation, link the error message to the corresponding part in the editor
 +
* Save history contents
 +
 
 +
''P2''
 +
* Provide an outline of the files being edited
 +
* Provide a view on the history
 +
* Add cheat sheets.
 +
* Add autocompletion icons
 +
* Add in Preferences the possibility to point to "own ApCoCoA folders" and save these in userinit.coc.
 +
 
 +
''P3''
 +
* Adapt syntax coloring and make it configurable in the preferences
 +
* Let user switch interactive behaviour of the current ApCoCoA editor window
 +
* Beautify autocompletion presentation
 +
 
 +
''To discuss''
 +
* Refactor console views and communication to CoCoA process (relate to Eclipse launching mechanism)
 +
* Wishlist: Parsing of the CoCoA instream (the results) to provide flexible representation of the results
 +
* Hint / error message, when in interactive mode and apcocoa is not started
 +
* Search the system PATH for already installed ApCoCoA
 +
* Use dltk for communication with cocoa processor
 +
 
 +
==Done==
 +
* Move project from CVS to subversion (2009-04-03)
 +
* Add autocompletion
 +
* Template mechanism + Toggeling
 +
* Add Plugins for the external binaries ApCoCoA uses
 +
* Open files not in the workspace
 +
* Send only the selected part of the editor window to the interpreter
 +
* "Save output as"
 +
 
 +
=Scratchpad=
 +
Quick and dirty notes for myself, thought as a basis for extending to a proper developer documentation ....
 +
 
 +
==General Links==
 +
* http://help.eclipse.org/ganymede/index.jsp
 +
* http://www.eclipse.org/articles/Article-UI-Guidelines/Index.html and http://wiki.eclipse.org/User_Interface_Guidelines
 +
* http://blog.eclipse-tips.com/
 +
* http://wiki.eclipse.org/index.php/Eclipse_FAQs
 +
 
 +
 
 +
==Developing the ApCoCoA Plug-ins for Eclipse within Eclipse==
 +
* Get Eclipse for RCP/Plug-in Developers from [http://www.eclipse.org/downloads/]. If you also develop ApCoCoALib, install the CDT features on top of it.
 +
* Create a new workspace directory (e.g. <code>moccha</code>). This will be convenient since you will have several plug-ins open to learn from (see below).
 +
* Install the Subclipse Plug-in by adding the site http://subclipse.tigris.org/update_1.4.x under <code>Help > Software Updates... > Available Software</code>.
 +
* Using the repository from <code>svn://apcocoa.org/</code>, check out the following directories under <code>Moccha</code> (<code>File > New > Other... > SVN > Checkout Projects from SVN):
 +
** <code>Moccha/org.apcocoa/trunk</code> (the feature we deliver)
 +
** <code>Moccha/org.apcocoa.eclipse/trunk</code> (the plug-in related Java sources)
 +
** <code>Moccha/org.apcocoa.eclipse.doc/trunk</code> (the HTML documentation plug-in)
 +
* You can browse the code of other plugins (which is a great way to learn to know the Eclipse internals) as follows:
 +
** In the Eclipse package explorer: Right click > <code>Import...</code>
 +
** Plug-in development > Plug-ins and Fragments. Next.
 +
** Select 'Binary projects with linked content' in the 'Import As' section. This is a resource friendly way to import the Plug-in code. Next.
 +
** Select the plugins you would like to explore and browse. Finish.
 +
 
 +
===Issues with Eclipse===
 +
There is this whole discussion concerning if to put the project specific .*-files under version control or not.
 +
We decided to put them under version control in order to have a consistent build process across the team.
 +
I will add some more comments on the pros and cons of the different approaches and in particular our experience as the project goes on.
 +
 
 +
==Commands==
 +
Examples in our GUI: Starting external ApCoCoA process, sending CoCoAL code to esternal ApCoCoA process, history forward/back, starting Server.
 +
 
 +
To add a command, extend these extension points in the plugin.xml:
 +
* org.eclipse.ui.commands: here just an ID together with other attributes (name, category,...) for a certain command is defined.
 +
* org.eclipse.ui.handlers: this is the link between the command ID and an actual handler, ie. a class that does something when the command is called. It is possible to implement more than one handler to a certain command and to determine certain conditions when to use which handler (elements <code>activeWhen</code> and <code>enabledWhen</code>
 +
* org.eclipse.ui.menues: here the actual visible menu and toolbar contributions are defined along with declarations, when they are visible, eg. they are visible when, say, an editor "is in a certain context".
 +
* org.eclipse.ui.contexts: this defines a context which is referenced by the visibility check of the menus, toolbars,... The context is set by the following code snippet in the class <code>ApCoCoAEditor</code>.
 +
  IContextService contextService = (IContextService) getSite().getService(IContextService.class);
 +
  contextService.activateContext("org.apcocoa.eclipse.contexts.ApCoCoA");
 +
 
 +
===Using the Eclipse Help System for ApCoCoA Help===
 +
* http://www.ibm.com/developerworks/opensource/library/os-echelp/
 +
 
 +
===Links===
 +
* Good starting point: http://richclientplatform.blogspot.com/2007/07/new-menu-contribution-extension.html
 +
Just for redundancy, the previous link mentions among others the following links:
 +
* http://wiki.eclipse.org/Command_Core_Expressions
 +
* http://wiki.eclipse.org/Menu_Contributions
 +
* http://wiki.eclipse.org/Platform_Command_Framework
 +
 
 +
==Preparing a new release==
 +
===Building the standalone product===
 +
* Create a directory <code>eclipse-builder</code>
 +
* In this directory, unzip a new and fresh Eclipse Galileo installation from http://www.eclipse.org/downloads/
 +
* Get the delta pack for cross-platform building http://download.eclipse.org/eclipse/downloads/ > Latest releases > (eg. 3.5.1) > Delta Pack. Unzip it in <code>eclipse-builder</code>.
 +
* Now you should have two directories, eclipse and delta-pack within the directory <code>eclipse-builder</code>.
 +
* In a third directory, say <code>apcocoa_prjs</code>, check out all the apcocoa gui projects.
 +
* From a command line, execute
 +
  java -jar eclipse/plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar -application org.eclipse.ant.core.antRunner -buildfile <apcocoa_prjs>/org.apcocoa.build/buildProduct.xml -Dbuilder=<apcocoa_prjs>org.apcocoa.build
 +
*
 +
 
 +
=History=
 +
 
 +
* 2009/07/16: Moccha 0.1.2, the beta release.
 +
** ...

Latest revision as of 14:36, 29 September 2009

The Eclipse GUI Project: Goal of the Project

The overall goal of the project can be described as follows: 

 To create a state of the art, platform independent Graphical User Interface for faster CoCoAL program and prototype development.


Project Plan

Phase 1: Introduce a comfortable Editor covering as much features as provided by the Emacs interface.

Currently in Progress

  • Test if Xtext is suitable for generating a comfortable CoCoA Language editor.
  • Add autoformatting / indentation
  • Make a downloadable Eclipse+ApCoCoA bundle
  • Create splash screen and icons

ToDos

P1

  • Show documentation when hovering over functions
  • Complete ApCoCoA perspective (open two consoles, set console preferences like "Show...when...changes")
  • Add packages-representation node to the project view (make packages files available easily)
  • Error annotation, link the error message to the corresponding part in the editor
  • Save history contents

P2

  • Provide an outline of the files being edited
  • Provide a view on the history
  • Add cheat sheets.
  • Add autocompletion icons
  • Add in Preferences the possibility to point to "own ApCoCoA folders" and save these in userinit.coc.

P3

  • Adapt syntax coloring and make it configurable in the preferences
  • Let user switch interactive behaviour of the current ApCoCoA editor window
  • Beautify autocompletion presentation

To discuss

  • Refactor console views and communication to CoCoA process (relate to Eclipse launching mechanism)
  • Wishlist: Parsing of the CoCoA instream (the results) to provide flexible representation of the results
  • Hint / error message, when in interactive mode and apcocoa is not started
  • Search the system PATH for already installed ApCoCoA
  • Use dltk for communication with cocoa processor

Done

  • Move project from CVS to subversion (2009-04-03)
  • Add autocompletion
  • Template mechanism + Toggeling
  • Add Plugins for the external binaries ApCoCoA uses
  • Open files not in the workspace
  • Send only the selected part of the editor window to the interpreter
  • "Save output as"

Scratchpad

Quick and dirty notes for myself, thought as a basis for extending to a proper developer documentation ....

General Links


Developing the ApCoCoA Plug-ins for Eclipse within Eclipse

  • Get Eclipse for RCP/Plug-in Developers from [1]. If you also develop ApCoCoALib, install the CDT features on top of it.
  • Create a new workspace directory (e.g. moccha). This will be convenient since you will have several plug-ins open to learn from (see below).
  • Install the Subclipse Plug-in by adding the site http://subclipse.tigris.org/update_1.4.x under Help > Software Updates... > Available Software.
  • Using the repository from svn://apcocoa.org/, check out the following directories under Moccha (File > New > Other... > SVN > Checkout Projects from SVN):
    • Moccha/org.apcocoa/trunk (the feature we deliver)
    • Moccha/org.apcocoa.eclipse/trunk (the plug-in related Java sources)
    • Moccha/org.apcocoa.eclipse.doc/trunk (the HTML documentation plug-in)
  • You can browse the code of other plugins (which is a great way to learn to know the Eclipse internals) as follows:
    • In the Eclipse package explorer: Right click > Import...
    • Plug-in development > Plug-ins and Fragments. Next.
    • Select 'Binary projects with linked content' in the 'Import As' section. This is a resource friendly way to import the Plug-in code. Next.
    • Select the plugins you would like to explore and browse. Finish.

Issues with Eclipse

There is this whole discussion concerning if to put the project specific .*-files under version control or not. We decided to put them under version control in order to have a consistent build process across the team. I will add some more comments on the pros and cons of the different approaches and in particular our experience as the project goes on.

Commands

Examples in our GUI: Starting external ApCoCoA process, sending CoCoAL code to esternal ApCoCoA process, history forward/back, starting Server.

To add a command, extend these extension points in the plugin.xml:

  • org.eclipse.ui.commands: here just an ID together with other attributes (name, category,...) for a certain command is defined.
  • org.eclipse.ui.handlers: this is the link between the command ID and an actual handler, ie. a class that does something when the command is called. It is possible to implement more than one handler to a certain command and to determine certain conditions when to use which handler (elements activeWhen and enabledWhen
  • org.eclipse.ui.menues: here the actual visible menu and toolbar contributions are defined along with declarations, when they are visible, eg. they are visible when, say, an editor "is in a certain context".
  • org.eclipse.ui.contexts: this defines a context which is referenced by the visibility check of the menus, toolbars,... The context is set by the following code snippet in the class ApCoCoAEditor.
 IContextService contextService = (IContextService) getSite().getService(IContextService.class);
 contextService.activateContext("org.apcocoa.eclipse.contexts.ApCoCoA");

Using the Eclipse Help System for ApCoCoA Help

Links

Just for redundancy, the previous link mentions among others the following links:

Preparing a new release

Building the standalone product

  • Create a directory eclipse-builder
  • In this directory, unzip a new and fresh Eclipse Galileo installation from http://www.eclipse.org/downloads/
  • Get the delta pack for cross-platform building http://download.eclipse.org/eclipse/downloads/ > Latest releases > (eg. 3.5.1) > Delta Pack. Unzip it in eclipse-builder.
  • Now you should have two directories, eclipse and delta-pack within the directory eclipse-builder.
  • In a third directory, say apcocoa_prjs, check out all the apcocoa gui projects.
  • From a command line, execute
 java -jar eclipse/plugins/org.eclipse.equinox.launcher_1.0.200.v20090520.jar -application org.eclipse.ant.core.antRunner -buildfile <apcocoa_prjs>/org.apcocoa.build/buildProduct.xml -Dbuilder=<apcocoa_prjs>org.apcocoa.build

History

  • 2009/07/16: Moccha 0.1.2, the beta release.
    • ...
Retrieved from "http://apcocoa.uni-passau.de/wiki/index.php?title=ApCoCoA-1:Eclipse_GUI&oldid=10063"