In order to use your Windows Mobile 5 device as a Bluetooth modem for your Nokia N800 some extra effort is required. Blame Microsoft for that, because they are the ones who removed Bluetooth DUN (supported by all phones on the market?) and forced usage of Bluetooth PAN (only MS Windows Mobile devices and PCs?), which being a non-standard connection is not yet supported by the Maemo connection manager.

Get ssh and xterm from the Maemo Software Repositories. You might have to enable Red Pill Mode. The root password is “rootme”.

Firstly one has to create a dummy connection (required only once) via:
ssh root@localhost
gconftool -s -t string /system/osso/connectivity/IAP/DEFAULT/type DUMMY

From that point on one can use the following two commands to establish the connection with the Windows Mobile Device.

pand -Q10 -n
udhcpc -i bnep0

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:

• Design Surface, which includes a host and a list of design-time services
• Windows.Forms Designers
• ASP.Net Designers
• Serializers and Deserializers

Timeline

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

Delivered

Planned

• DesignSurface, host and core design-time services
• Windows.Forms core designers stack
• Design-Time serialization stack
• A simple frontend (the designer) to demonstrate how the above fit together. This includes drag and drop, resizing, selection, as well as source code serialization and deserialization.

Extra

• .Net 2.0 Updates
• MonoDevelop Addin

Schedule

Per-week tasks-based schedule with weekly reports.

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:

• DesignSurface and DesignSurfaceManager with all the documented in MSDN services offered.
• ComponentDesigner, ControlDesigner, ParentControlDesigner, ScrollableControlDesigner, DocumentDesigner, SplitContainerDesigner
• System.ComponentModel.Design.Serialization namespace

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

[[Image:software/mwf-designer.png|center]]

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:

• Can load (in tabs) souce code in .Net 2.0 form - partial classes with a .Designer codebehind file. It is also able to save changes back to source code.
• Has a PropertyGrid, a simple Toolbox and components dropdown list.
• Maintains a user-modifiable References list for the user to reference assemblies with custom components and other.

Tasks Left

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

Surface

• DesignerOptions, WindowsFormsDesignerOptionService
• Extender Providers - http://msdn2.microsoft.com/en-us/library/ms171835.aspx
• IDesignerHost.Activate is invoked after the root component is added to the host. This is just my guess. It has to be further investigated when, where and by what should that be invoked.
• Implement MenuCommandService : IMenuCommandService, MenuCommands, MenuCommand
• LicenseContext
• Transactions are not created - must be fixed before implementing the UndoEngine

Serialization

• Resources serialization and deserialization
• ControlCodeDomSerializer - Resume/SuspendLayout
• ContainerCodeDomSerializer - to serialize the container for the components and its disposing
• UndoEngine, ComponentSerializationService, CodeDomComponentSerializationService, CodeDomDesignerLoader.IDesignerSerializationService
• No creation expression is serialized for nested components by the ComponentCodeDomSerializer. I can’t think of a use case where this would be required.
• InheritanceService, InheritanceAttribute - what are those about?
• AmbientAttribute - no checks for that currently.
• Make use of the IUIService for reporting errors

Designer Frontend

• Doesn’t support multi-component selection, because it only handles the ISelectionService.PrimarySelection and not the GetSelectedComponents.
• Implement New -> *
• Implement Close Document
• Implement IUIService for user-friendly error reporting by the surface
• Implement Undo/Redo - make use of the UndoEngine
• Implement Copy, Paste, Cut, Delete - use the MenuCommandService
• Implement Format -> *

mcs

• Implement EventsTab and add EventsTab support in MWF’s PropertyGrid
• Update TypeDescriptor to .Net 2,0
• Implement WS_EX_TRANSPARENT for MWF’s X11 backend - http://bugzilla.ximian.com/show_bug.cgi?id=81135
• A lot of PropertyGrid Editors are missing in Mono and the PropertyGrid “dies” easily due to the exceptions thrown

Designers

• System.Windows.Forms.Behavior namespace to replace IUISelectionService. Requires transparency (WS_EX_TRANSPARENT), which is not yet supported by the MWF X11 backend.
• Implement ComponentTray
• Make use of the IUIService for reporting errors
• Menu has a designer in a Visual Studio assembly (Microsoft.VisualStudio.Windows.Forms.MenuDesigner) - fix that.
• Implement the stack of specialized WinForms designers
  • AxHostDesigner
  • BindingNavigatorDesigner
  • BindingSourceDesigner
  • ButtonBaseDesigner
  • ComboBoxDesigner
  • DataGridDesigner
  • DataGridViewColumnDesigner
  • DataGridViewComboBoxColumnDesigner
  • DataGridViewDesigner
  • DateTimePickerDesigner
  • FlowLayoutPanelDesigner
  • FolderBrowserDialogDesigner
  • GroupBoxDesigner
  • ImageListDesigner
  • LabelDesigner
  • ListBoxDesigner
  • ListViewDesigner
  • MaskedTextBoxDesigner
  • MonthCalendarDesigner
  • NotifyIconDesigner
  • OpenFileDialogDesigner
  • PanelDesigner
  • PictureBoxDesigner
  • PrintDialogDesigner
  • PropertyGridDesigner
  • RadioButtonDesigner
  • SaveFileDialogDesigner
  • ScrollableControlDesigner
  • SplitContainerDesigner
  • SplitterDesigner
  • SplitterPanelDesigner
  • StatusBarDesigner
  • TabControlDesigner
  • TableLayoutPanelDesigner
  • TabPageDesigner
  • TextBoxBaseDesigner
  • TextBoxDesigner
  • ToolBarButtonDesigner
  • ToolBarDesigner
  • ToolStripContainerDesigner
  • ToolStripContentPanelDesigner
  • ToolStripDesigner
  • ToolStripDropDownDesigner
  • ToolStripItemDesigner
  • ToolStripMenuItemDesigner
  • ToolStripPanelDesigner
  • TrackBarDesigner
  • TreeViewDesigner
  • UpDownBaseDesigner
  • WebBrowserBaseDesigner

Summary

I am pleased to announce that I have completed most of what I had planned for the first part of the Google Summer of Code program.

I have underestimated the complexity of the design-time framework in general. A lot of the internal behaviour (several classes) was hidden by one public interface or in some cases a lot of behaviour was spread among many interfaces, which had to work together. MSDN documentation was okay, but at the end of the day it is not meant to be an implementer’s guide and it wasn’t exactly helpful. This made implementation and testing more difficult. At a point I felt like if I was starring at the outside of a car, but I was supposed to write its internal behaviour.

Repository Data

Start of GSoC revision: 19 (/tags/gsoc-begin)
End of Midterm revision: 49 (/tags/gsoc-midterm)
Visual ChangeSet: http://monodt.i-nz.net/changeset?old_path=tags%2Fgsoc-begin&old=&new_path=tags%2Fgsoc-midterm&new=
Plain Text ChangeSet: http://monodt.i-nz.net/changeset?format=diff&new=49&old=49&new_path=tags%2Fgsoc-midterm&old_path=tags%2Fgsoc-begin

Details

I have been working on the following namespaces. The list below is a list of limitations and things that are not yet implemented. For everything else you can refer to MSDN.

• System.ComponentModel.Design
  • DesignSurfaceManager is fully implemented, but not fully tested yet
  • Transactions are not created.
  • UndoEngine not implemented.
  • No support for License contexts.
• System.Windows.Forms.Design
  • The current implementation of drag and drop and resizing (it’s part of the designer’s stack) is temporary, until I imlpementSystem.Windows.Forms.Design.Behavior.
  • Most of the stuff is 2.0 ready except for the dependancies on the Behavior namespace.
  • ComponentTray, DesignerOptions and WindowsFormsDesignerOptionService are not implemented yet.
  • Internal specific (cosmetic) designers are missing: e.g a PanelControlDesigner to draw a border around the panel it’s designing to make it visually recognizable.
• System.ComponentModel.Design.Serialization
  • Serialization not fully tested yet (in progress)
  • Serialization to Resources is not yet implemented
  • Deserialization is not yet implemented (in progress)
  • CodeDomComponentSerializationService not yet implemented (just stubbed)
  • EventBindingService is not implemented yet.
• Overall Limitations:
  • Extenders are not supported (there is an implementation of the ExtenderService though)
  • InheritanceService and inheritance is not supported. Not planning to support those, unless someone explains me what is meant with this inheritance.
  • ActiveX is not supported

Next Term

• Finish off and test the codedom serialization/deserialization. Use parts of SharpDevelop for testing.
• Implement the System.Windows.Forms.Design.Behavior namespace and finish off the drag and drop behaviour.
• Create a small frontend, based on SharpDevelop’s FormsDesigner Addin source code.
• More…

Yesterday I created a few macros to generate some C# code for me in my editor of choice SlickEdit . I have decided to start a page on my SlickEdit “hackings” , where you can download the C# helper macros and possibly more in the future.

For a given class:

public class Test
{
    public void SomeMethod (Type variableName)
    {
    }
}

cs_generate_property (_str access=”public”)

Generates a property from the variable under cursor. The property is placed just below the method body in which the variable is. This command also generates a class field just below the class signature. The command defaults to public properties, but the access could be set as an optional parameter.

public class Test
{
    private Type _variableName;

    public void SomeMethod (Type variableName)
    {
    }

    public Type VariableName {
        get { return _variableName; }
        set { _variableName = value; }
    }
}

cs_generate_argument_null_check ()

Generates a null check and ArgumentNullException throw for the method parameter under cursor in the beginning of the method body.

public class Test
{
    public void SomeMethod (Type variableName)
    {
        if (variableName == null)
            throw new ArgumentNullException ("variableName");
    }
}

cs_generate_field_from_local ()

Generates a class field from the variable under cursor just after the class signature in the form of “_variableName”

public class Test
{
    private Type _variableName;

    public void SomeMethod (Type variableName)
    {
    }
}

Introduction

That was one hell of a week and I am glad I have achieved all I had planned and even a bit more.

I have tested, fixed and refactored what I define to be the core designer and host code. This is everything but the visual user manipulation on the design-time surface. I am ready to proceed to the the design-time serialization, which is the 3rd very important component of the core code. Essentially as my first deliverable for the Mid-Term review I am planning on delivering the core code and as a second deliverable at the end of theGSoC I will deliver a basic frontend to it.

On the base of the work done this week I have refined my schedule.

Repository Data

Start of week revision: 19
End of week revision: 35
Plain Text ChangeSet (~5000 lines): http://monodt.i-nz.net/changeset?format=diff&new=35&old=35&new_path=trunk&old_path=tags%2Fgsoc-begin
Visual ChangeSet: http://monodt.i-nz.net/changeset?old_path=%2Ftags%2Fgsoc-begin&old=&new_path=%2Ftrunk&new=

Details

0.) In the beginning of the week I have spent some time to create an infrastructure for design-time testing and mainly to make my life easier. It has been implemented in the form of a DesignerTestHelper class, which allowed me to easily setup tests’ SetUp/TearOff, initialize a design surface and use helper methods to interact with it. Most importantly it allowed me to do some hacks to test on 1.1 as well (All of the hosting/services code is 2.0, where as the designers are 1.1+2.0).

I have stumbled upon a number of problems with testing the design-time code in the NUnit environment.

• Drag and drop registration on win32 required running the test in a STA “environment”, which took me a while to figure out how to do.
• Multi-Threaded tests - I had a lot of problems with that in NUnit and ended up refactoring to single-threaded based tests. I suspect I will have to give the issue a bit of more thought when it comes up to testing the visual behaviour (e.g win32 message routing), if I have to.
• I get some exceptions on TearDown of some tests (I think 2), more than likely due to some internal MS design-time behaviour, of which I am not aware.

1.) I have covered the core winforms designers stack with unit tests:

• ComponentDesigner (ITreeDesigner, IDesignerFilter)
• ControlDesigner
• ParentControlDesigner
• ScrollableControlDesigner
• DocumentDesigner

2.) I have covered the design surface (host) and its services (listed by interface name) with unit tests:

• DesignSurface (IServiceContainer)
• IDesignerHost
• IContainer
• ISite
• INestedSite
• INestedContainer
• IDictionaryService
• ITypeDescriptorFilterService

3) The following are new implementations:

• NestedContainer
• NestedContainerTest.cs
• DesignModeNestedContainer and DesignModeNestedSite
• ReferenceService
• ComponentDesignerTest.cs
• ControlDesignerTest.cs
• DesignSurfaceTest.cs
• DocumentDesignerTest.cs
• ParentControlDesignerTest.cs

4) The tests resulted:

• A lot of refactoring and a lot of MS behavioural compatibility fixes.
• I have found that bits of information from MSDN2 on different classes is wrong and fixed that.
• Complete code review.
• A very nice way to get my head around a lot of different small bits that were not clean before.
• They all pass on Mono and MSNET.

5) On the base of the work done this week I have refined my schedule.

Next Week

I won’t have as much time to spend on the project next week, due to personal stuff, which hopefully will take about 2 days. On top of everything today I passed out and hit my head while falling of the chair in a lab, where I went for a blood probe. I’ve been having a terrible headache and haven’t been feeling very well today (Monday), so I haven’t managed to achieve anything but write this report .And no, I do not get sick from seeing mine or others blood, so passing out today was something I wasn’t expecting to happen.

• Research on Design-Time Serialization and more specifically on the:
  • Interaction between SerializationManager - DesignerLoader - Serializer
  • Code reuse in the specialized serializers (ImageListCodeDomSerializer, CollectionCodeDomSerializer, etc)
• Classes to look at:
  • DesignerSerializationManager
  • DesignerLoader
  • BasicDesignerLoader
  • CodeDomDesignerLoader
  • CodeDomSerializerBase
  • CodeDomSerializer
• Begin writing unit tests for the above.