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

Dan Winship danw@novell.com
Fri, 03 Dec 2004 14:24:37 -0500


This is a brain dump on why I don't think we want to use
System.ComponentModel for Gtk# widget metadata (in particular, why we
don't want to use it *instead* of binding GParamSpec).

Reasons suggested for why we might want to use it, with rebuttals:

	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.

	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.

	   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

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

	   This isn't a very strong point. IMHO, it's like saying "we
	   should use XML so we can turn Stetic into a web service".
	   The amount of non-ComponentModel-related work that would be
	   needed in order to do this is so much larger than the
	   amount of ComponentModel-related work needed that I don't
	   even think it's worth thinking about until someone has at
	   least started working on it.

	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.

Rebuttals/comments/flames?

-- Dan