Mono.Design Report

Ivan N. Zlatev <contact at i-nz.net>

Revision 3

Summary

Project Description

This project targets at implementing the .Net Design-Time stack for the Mono Class Library, mostly hosted in the System.Design assembly and the *.Design.* namespaces.


The stack consists of:

Timeline

28 May - Start
9 July - Mid-Term Review
20 August - End

Delivered

Planned
Extra

Schedule

Per-week tasks-based schedule with weekly reports.

Week
 Activity
 Report
1
 University Exams Link
2
 Cover the existing code with unit tests to verify matching behavior with MS.Net. Link
3, 4, 5, 6 Research on and implement the serialization stack: designer loaders, serialization manager, serializers and all the missing classes in Mono's class library required. Link
Link
Link
7
 Implement the deserialization. Link

8
 MonoDevelop integration work.
Revised to: "Port" to Mono - bugfixes in the class library, implementing missing classes.
Reason: Missing classes and bugs preventing the code form working on Mono.
Link

9
 Implement System.Windows.Forms.Design.Behavior.
Revised to: MWF-in-GTK integration work.
Reason: No transparency (WS_EX_TRANSPARENT) on X11, which is required for the implementation.
Link
10
 MonoDevelop Windows.Forms designer Addin. Link
11
 Vacation n/a

12
 MonoDevelop Addin improvement work.
Revised to: Standalone WinForms Designer.
Reason: Unexpected, unresolvable issues with MWF-in-GTK.
Link

Development Environment

Project managment: http://monodt.i-nz.net
Source code repository: http://svn.i-nz.net/monodt
Editor: SlickEdit
Testing: NUnit
OS: openSUSE 10.2 Linux
Virtualization: VirtualBox

Status

Mono.Design

Currently Mono.Design, but I hope the code will land in the Mono class library as soon as possible.

Implemented are:

MonoDevelop Addin

The few implementation approaches were broken in different ways.

The initial approach was to use a RemoteProcessObject to host the visual part of the designing process (just the UI) as provided by MonoDevelop and as utilized by the AspNetAddin. But my design involved design surface initialization (not loading) on the non-remote part and passing non-serializable objects to the remote part, which ended up being impossible as one can imagine.

The next approach was to drop remoting and run the editor process on a separate thread with it's own GTK+ and MWF loops. It took me two days to figure out that I can't have two gtk loops in one process, while wondering what is going badly wrong with the code.

The last approach utilizes remoting again, but the surface initialization and services logic will be completely redesigned. Unfortunately I stumbled upon DnD issues in MWF-in-GTK in MWF, which is not able to handle the specifics imposed by the XEMBED protocol. Also the last time I tried running the MWF-in-GTK code it wasn't working.

I finally gave up on wasting more time on that, so the monodevelop designer addin code in SVN is obsolete and deprecated.

MWF Designer

I have designed and developed a small standalone frontend to the Design-Time code. I have followed the KISS principle and I am quite happy with the resulting code - it's simple and works. It deals in terms of a Workspace with loaded Documents. The Workspace has a list of References (to e.g assemblies with custom components). A Document is a unit of a codebehind file, user code file and in the future (once resources serialization and deserialization is implemented) a resource file.

Currently the designer:

Tasks Left

An up-to-date list can be found on http://monodt.i-nz.net/wiki/Tasks

Surface

Serialization

Designer Frontend
mcs
Designers