[Gtk-sharp-list] why we don't want to use ComponentModel for Gtk# (I think)
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
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,
3. It might make it easier for us to integrate Gtk# stuff into
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.