When adding new C++ projects into a VS2005 solution containing C# projects the output folder is always set to a $(SolutionDirector)$(Configuration) which is a bit uncomfortable. It sounds good to change in to the same notation used for all C# libraries, e.g. change to $(ProjectDir)\bin\$(ConfigurationName)
Make sure that you have All Configurations selected on top.
I created a Basic Main Window implementation. I still have some errors in the configuration part of the application. The way .net applications are configured is still not very well designed. It is however a lot better than old windows applications did with the registry. Without configuration I get the window below, but the log window is not hooked into the logging system. Im gonna try and see how to fill up the menu bars and the menu.
|
|
|
|
First version of the BasicMainWindow
|
OpenMI running under mono
|
Properties working
|
|
||
|
Using mozembed
|
I extracted the interface from the main window so I was able to add another more basic main window. This one should be suitable for linux users and should work on a pure mono implementation. The seperation between IMainWindow and IGui is a bit vague. For more details see the sourcecode.
Habitat plug-in implementation needs some major review and refactoring for the future versions.
- File management should be improved, actually only GridCoverage class and it's UI forms should know about image File path but it has a lot of messy code which is used inside HabitatModelBase
- Save(string path, bool , bool) inside DelftTools.IModel should be removed in the future because it exposes knowledge about file path of the Habitat.GridCoverage, see
Unknown macro: {jiraissue}
- We should create some workaround for PCRaster to move its dlls out of the DelftShell bin folder. These dll's should be put into Habitat plugin folder instead
Unknown macro: {jiraissue}
- I did not manage to run DemisMap on my laptop - RegAsm.exe <dll> on all Demis libraries available in the Plugins/Habitat is not sufficient, probably some ActiveX / COM libraries are missing. Everything required to run it must be included into the project.
After some cleanup we got the first screenshots of DelftShell running on linux. This works against the 1.2.3 version of mono which is default in ubuntu. It should run better with mono 1.2.4 and with the subversion HEAD version.
|
|
Next things
- The mainwindow needs some redesigning.
- Make a mainwindow interface IMainWindow
- Further split-off dotnetbar
- Find out how to configure MonoDevelop with different mono versions
- Make mono.windows forms work on windows so we can automaticly test it under windows as well.
Tools
The following tools are available to analyze mono compatibility:
The Mono Migration Analyzer (MoMA) tool reports compatibility of a clr assembly with the Mono platform
Mono add-in for visual studio can be used to compile your source with mono from within visual studio 2005
quick reference for add in
To integrate DelftShell functionality in ArcMap the following steps were performed:
- Created a plugin class "DelftShellExtension" to extend ArcMap functionality
- Subdived DelftShell into two components: DelftShell and DelftShell.Loader
Three classes implementing IDockableWindowDef were created to display projectexplorer, messagewindow and propertygrid
DelftShellExtension.cs was created public from DelftShell.cs to be implement some logic specific to ArcMap, but most methods remain.
DelftShellToolbar class wass created to show buttons to open each of the three windows separately
To show each of the dockable windows three classes where hard-coded. This needs to be refactored!
Challenges
Two options where tried (without success upto now) to avoid hard-coding each command and each dockable window
-one of the options was to create assemblies at runtime for IToolWindow implementations in DelftShell in and adding them to the registry
-the other option was to have one class for IToolWindow implementations and registering it several times to com with different GUID
the second option failed because ArcMap doesnot show the GUID of the dockable window it instantiates based on the registry info but it shows the GUID of mscorii.dll instead. So if ArcMap instantiates three dockable windows they all have the same GUID.
GUID- identifier used in COM to register classes for COM interoperability
Demo
ArcMap automatically detects the plugin from the registry, so no coding in VBA was needed to extend ArcMap. The resulting implementation is shown below:
For creating a linux compatible version of DelftShell/DelftTools the following steps were required:
- Setup a up to date mono environment.
- Get DelftTools/DelftShell compiled under mono
- Make sure all unit tests work
- Review non working parts of the software
- Setup a linux mono build agent
Setup a mono environment.
A seperate linux pc using the latest ubuntu version was installed. Unknown User (don) and Fedor Baart have administration rights. The system runs ubuntu 7.10, xgl, beryl, mono 1.2.3 and the latest monodevelop version. Several relevant libraries are installed. Most sources can be found under /home/baart_f/checkouts.
You can login using a local xserver and putty after you get an account from Fedor Baart.
Also available are a teamcity agent and a sourcecode browser webserver
Get DelftTools/DefltShell compiled.
This went pretty smoothly. DelftTools compiled without alteration, DelftShell had some references to the webbrowser. This wasnt implemented in 1.2.3 and only partially in 1.2.4. Currently someone from novell is working on getting libmozembed working as a system.windows.forms. webbrowser. Seems to be going well. I used precompile statements to filter out code not working in mono yet.
Make sure all unit tests work.
Some unit tests did not work at first. These were all errors which could easily be resolved. Most off them were due to some post build events with windows bat commands. One bug in log4net was found and not further examined. Code could be easily refactored to work.
//old
Log.InfoFormat("message {0}", "parameter");
//new
Log.Info(String.Format("message {0}", "parameter"));
Review not working parts.
The only part which is not working currently is the DotNetBar. I checked through the source code of DotNetBar and found it to be somewhat messy. It is not going to work on linux because it has P/Invoke calls and references to user32.dll all over the place. It is possible to send these calls to wine but that's probably to much of a hack.
Since linux users are not accustomed to using dockable windows my first approach will be to create a non docking version of the following files:
- mainwindow.cs
- tabviewmanager.cs
- statusdisplay.cs
- viewlist.cs
- splashscreen.cs
This is were all the references to the dotnetbar are located.
Another option we took into consideration was to use a GTK# docking frontend and to load the System.Windows.Forms control in there. There are three main reasons why this option is not the first choice:
- We are trying to limit the number of windowing toolkits. Gtk+ is currently not used so we would increase the number of windowing toolkits if we did.
- Using Gtk+ as the default windowing toolkit is not an option as it is not very native looking under windows.
- Using two concurrent windowing toolkits requires two concurrent main event loops, not a good idea.
Setup a linux mono build agent.
The buildserver has DelftShell working under windows thanks to Unknown User (don). Im not sure how to build the linux version from the command line. I can build projects using the xbuild command. I couldnt yet find a way to build whole solutions. I'll check further next week.
what's next?
Next up is creating a nondocking mainwindow and finishing the mono build agent so people will get a message when they break things under linux.