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.
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
- 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
- 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.
- Adapt syntax coloring and make it configurable in the preferences
- Let user switch interactive behaviour of the current ApCoCoA editor window
- Beautify autocompletion presentation
- 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
- 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"
Quick and dirty notes for myself, thought as a basis for extending to a proper developer documentation ....
- http://www.eclipse.org/articles/Article-UI-Guidelines/Index.html and http://wiki.eclipse.org/User_Interface_Guidelines
Developing the ApCoCoA Plug-ins for Eclipse within Eclipse
- Get Eclipse for RCP/Plug-in Developers from . 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
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 >
- 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.
- In the Eclipse package explorer: Right click >
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.
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
- 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
IContextService contextService = (IContextService) getSite().getService(IContextService.class); contextService.activateContext("org.apcocoa.eclipse.contexts.ApCoCoA");
Using the Eclipse Help System for ApCoCoA Help
- 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:
Preparing a new release
Building the standalone product
- Create a directory
- 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
- Now you should have two directories, eclipse and delta-pack within the directory
- 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
- 2009/07/16: Moccha 0.1.2, the beta release.