[MonoDevelop] Some questions/suggestions

[Mike Krüger]

Hi

> > The same for the Forms Designer ... consider using the Microsoft
> > services infrastructure and you only need to implement the missing
parts
> > ... the other parts are inside #D. Another point using the MS
> > infrastructure is that it IS inside .NET (and in mono) ... people
know
> > how to make components for .NET and then components will work on
mono
> > and MS .NET the same way.
> Well, I am not sure how much this could work. The design model for
Gtk#
> is so different than the one for SWF, i am not sure how we could make
> this work. For example, swf has no concept of a box model.
>

This is something that the infrastructure doesn't care about. MS next
generation UI toolkit won't have the same model than SWF too and the
designer infrastructure was build with this in mind. The guys there
worked for not doing this work twice.
The basic component model and most forms designer services will work
with GTK# or any other gui library. The thing you mention is mostly a
designer surface issue and this needs to be rewritten (for sure). And it
will act different. But it will need some basic infrastructure.

-------------------------------------------------------------------------
Now look at the services step by step:

CodeDomDesignerSerializationManager.cs

- Do you think GTK# shouldn't be serialized/deserialized as code ?

HelpService.cs

- Isn't GTK#/Mono documented?

ComponentChangeService.cs               

- Can you add/remove/rename components in a GTK# forms designer model?

MenuCommandService.cs

- Do you think a context menu for GTK# components might be useful ? If
so then this service will do the job.

NameCreationService.cs

- This service will give each component a default name. Aren't GTK#
components objects?

DefaultServiceContainer.cs

- This thing will contain the services ... 

DesignerEventService.cs

- This handles designer creation. I think that the designers will work
for Gtk# too ... they add menu commands for example. In fact designers
do only high level stuff and not SWF. They give context menu commands
like 'add tab bar' and they do have a 'default' action which can be used
for creating a default event method on double click using the
EventBindingService ... I see you can't double click on GTK# components
because they're invisible.

DesignerOptionService.cs

- With this service you can set options for the designer surface.

SelectionService.cs

- Contains selected components. Do you think that the designer surface
will be able to select/deselect components ?

DesignerResourceService.cs

- Handles 'resource' files. Is it possible to localize, use images in
GTK#? If so this service will work.

ToolboxService.cs

- Do you plan a 'collection' of components which the user may create
inside the designer ? (For example the toolbox) If it is possible in the
GTK# model this service will wrap your GUI and work with any model.

DesignerSerializationService.cs

- Is used for object serialization. Do you think gtk# components can't
be serialized ? (for example for cut & paste ?)

TypeDescriptorFilterService.cs

- That service takes care of filtering out unwanted properties/events
for example. This is something the mysterious 'Designers' do ... 

DictionaryService.cs

- This is only a wrapper for a 'hashtable' ?!?! Ok I see this one is
incompatible with the GTK# model.

TypeResolutionService.cs

- When GTK# components have type names this service will resolve the
type to the components ...

EventBindingService.cs

- Ok this service IS critical with GTK# ... but only if you use an event
model OTHER than delegates ... 

UIService.cs

- This is used for displaying messages but contains some 'windows.forms'
references (like owner window). But you could just leave this out and
create a GtkUIService ...

ExtenderService.cs

- This is used to 'extend' the properties of a component. For example
with the 'Name' property which doesn't exist in the components it is
just the name of the field in general.

Ok but that are only the services ... the designers and the ui surfaces
may use them or not the core is the Designer Host. But I can't find
anything critical there it can create 'transactions', holds the
components (in form of a design container) and gives access to a 'root
component'. Oh! Thats it GTK# components don't have a root component!
They have circular references which leads to infinite UIs ... thats
tricky!

... but I see all this is compatible only with SWF but NOT with GTK#.
You have to do it against the basic infrastructure because it is a Swing
vs. native GUI example, right?

-------------------------------------------------------------------------
Ok now back to reality. I've worked with GUI libraries before SWF and it
is clear to me that you can't use their designer UI. But I've spoken of
the forms designer infrastructure. 

For the real GTK# designer you can add or remove services as you wish.
All is possible. 

But you will have something you can work with and don't start by zero
and you'll be compatible with the .NET component model (thats a great
plus because it can be used for non gui components too and these non gui
components might be useful for GTK# too ... for example the FileWatcher,
Process or DirectorySearcher work with this model). This is a reuse vs.
recreate issue.

> However, in terms of things like the [Description] attribute, or
> attributes to say `this is a color, show a color picker', we might be
> able to do. We have yet to truely start working on a Gtk# designer.
One
> of the Ximian guys is going to work on that in a few months.

[Description] is only one thing. Take the complete PropertyGrid
infrastructure ... (its already there in System.ComponentModel).

Regards
Mike