[Gtk-sharp-list] why we don't want to use ComponentModel for Gtk# (I think)

[Miguel de Icaza]

Hello,

    My comments:

> 	1. "It's in System.dll; it's there whether or not we use it."
> 
> 	   This is pretty much true, although some parts of
> 	   System.ComponentModel.Design are actually in
> 	   System.Design.dll.
> 
> 	   However, we currently have 10 MonoTODOs, 9 FIXMEs and 13
>            LAMESPECs in our System.ComponentModel implementation, and
>            System.ComponentModel.Design is even shakier.

Having bugs in the Mono libraries, TODOs or FIXMEs should not be the
metric for not using a technology.  If we follow this route we might as
well not write any software at all.

We need to fix those nonetheless for Windows.Forms and ASP.NET if they
are important. 

> 	2. "It works for both SWF and ASP.NET, we ought to be able to
>            make it work for us too."
> 
> 	   Dubious. I think it really only works for them because SWF,
> 	   ASP.NET, and ComponentModel were all designed together.
> 
> 	   The widget-annotating attributes are well-adapted to SWF,
>            but not so well-adapted to Gtk. For instance, GParamSpecs
>            let you specify upper and lower bounds for a numeric
>            property, but ComponentModel doesn't. Gtk's container/child
>            model is very different from SWF's. ComponentModel doesn't
>            seem to have anything a11y-related. Etc.

If we dissect each problem individually, all of those issues have
solutions, and I would definitely not arrive to the same conclusion that
you did based on a couple of small problems:

        * Upper/lower bounds for numeric values: 
        
          There is nothing stopping us from defining a new attribute to 
          control these values and populate the attribute from the
          underlying GParamSpec boundaries.
        
        * We really need to hear more about the issues with Gtk's
          container/child model in relation to System.ComponentModel,
          you mention it, but I do not see why this is a major
          impediment, and I would like to know more.
        
        * Accessibility: What is it that you have in mind?
        
          Windows.Forms does have accessibility support built on top
          of this framework, so more details on this area would be good
          to have, because SWF seems to have no problems with it.
        
> 	   More specifically, ComponentModel and ComponentModel.Design
> 	   are not APIs for interacting with a generic design
> 	   environment, they're APIs for interacting with *Visual
> 	   Studio* specifically. Two really bad examples are
> 	   S.CM.D.StandardToolWindows and S.CM.D.StandardCommands
> 	   which enumerate portions of the "design-time interface"
> 	   like the "Related Links" frame and the "Send to Back" menu
> 	   command. The widget-annotating attributes let you specify
> 	   context-menu commands and double-click actions to provide
> 	   when editing a widget, but not drag-and-drop behavior or
> 	   any other sort of interaction that VS doesn't support. Etc,
> 	   etc, etc

Again, we can define as many properties as we want using the
System.ComponentModel framework, we are not limited to supporting what
they have in any way.

If some things are specific to VisualStudio, then we do not have to
implement those, we can safely ignore and not use them at all. 

> 	3. It might make it easier for us to integrate Gtk# stuff into
> 	   Visual Studio?

Agreed, not a priority.

> 	4. It might make databinding support easier/better?
> 
> 	   This seems to be a red herring. AFAICT, SWF databinding
> 	   does not make use of ComponentModel at all. It just uses
> 	   System.Reflection and SWF-specific stuff.

Not at all.

Data binding is done with the IList (in System.Collections, so this is
easy), but tight integration is done with IBindingList and
IEditableObject.

The section to read on in the documentation is: `Windows.Forms Data
Architecture' [1], the section contains all the details, in particular
`Interfaces Related to Data Binding' [2].  It is in particular
interesting to look at the samples.

The database functions in System.Data implement the interfaces described
above in System.Data, and hence the value of supporting this is very
high.

In my opinion, GParamSpec is one of those systems that we should hide
from the user.   And given that if we want to support databinding we
will have to support System.ComponentModel *anyways*, we might as well
only expose one system instead of two.

[1] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconinterfacesrelatedtodatabinding.asp

[2] http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconinterfacesrelatedtodatabinding.asp