Help wanted

You can help to improve this project in various ways. The time you have to invest is anywhere between a few minutes and a few years depending how deep you want to get involved with the project. Here are some ways you can help to improve Emonic:

Feel free to submit feature requests to the Emonic tracker. Naturally, we don't guarantee that they will all be implemented, but it helps us determine what is important to the project.

Please do not be shy about reporting bugs to Emonic's bug tracking system! This is the only venue that we will be informed about bugs in Emonic beyond our own testing. Unfortunately, you should not expect that the bugs are fixed in a quick manner as the development speed of Emonic is not as fast as we'd like.

If you have a (small) feature request or find a bug that you know how to implement or fix, feel free to work on it! This requires experience in Java, possibly C#, and Eclipse plug-in development. To do this, please:

• open a ticket in the feature request or bug tracker, describe the problem and mention that you want to solve this problem yourself.
• check out the newest Emonic source code via anonymous CVS
• implement the code
• test the code in the Eclipse runtime environment
• attach a patch to the ticket you opened (you need a SourceForge account for this step)
• we will integrate the code in the official release and add your name to the our Hall of Fame for contributors
• if you do this more than twice I'll add you to the project developers so that you can merge the code directly into the release

There are various themes Emonic addresses which are so large that they should be implemented as extra plug-ins based on the Emonic architecture. We need people who feels ownership over these plug-ins and will take the time to implement them. In our opinion, each feature will demand experience in Java, Eclipse, and C# as well as at least half a man-year of working time. So, think twice before volunteering to take responsibility for one of these features. Please contact Bernhard (bernhardbrem) via SourceForge's email mechanism or post a message on the 'Developers' forum if you are interested. The following features are "open" and will probably not be implemented by us given our resource and time constraints:

Debugger support

Since there is an excellent tutorial on the Eclipse homepage on debuggers for Eclipse, it may seem like this is quite easy to implement. The problem in this case is the control of the C#/.NET debugger. We see two possible ways to do this:

• Communicate with the command line debugger via std-io. Advantage: Should be possible with Mono and Microsoft .NET. Problems: Not very elegant. Debugging output and std-out are presented at the same console. From our experiments, some lines of the debugger output is not being captured when the debugger is launched from within Eclipse.
• Communication via a network. Advantage: Better control of the debugging messages, remote debugging possible. Drawback: A .NET debugger frontend has to be written. Since the Mono debugger backands are still very much at a beta (if not alpha) level, this frontend might change from version to version. A lot of work is required to implement this.

Visual Basic .NET support

We don't feel that one needs to be an Eclipse guru for this as you can pretty much copy a lot of the C# code and adapt it for VB.NET (although we should see which classes can be used for both). The most difficult work is probably going to be proper syntax highlighting and a parser to create a syntax tree of the code. Even if it is not too difficult, writing the plug-in will take a lot of time.

NUnit support

This would be really nice and should not be too hard to implement. We may have to change the Emonic base a little bit so that the tests are run after every build. However, the core functionality of NUnit should be separated out as another plug-in.

Surface builder

We don't know whether this is possible at all, with regards to the displaying of a .NET forms surface or a surface described in XAML via Eclipse and in a way so that it is portable to on all platforms that the .NET framework runs on and looks in the designer (Windows, Linux, Mac, etc.). Ideas and implementations are very welcome!