[MonoDevelop] General purpose Toolbox and PropertyGrid
lluis at ximian.com
Tue Apr 18 12:45:13 EDT 2006
El sáb, 15-04-2006 a las 14:57 +0100, Michael Hutchinson escribió:
> On 4/14/06, Alexandre Miguel Pedro Gomes <alexmipego at gmail.com> wrote:
> > Something I've been thinking for a while is that Gtk# objects should be
> > extended to make use of .Net ComponentModel's model. Not just because it is
> > supposed to be the way things work in .Net but because it provides support
> > for somethings like Databinding and other things like the case of the
> > PropertyGrid.
> Yeah, that idea does have merit. There's a whole infrastructure
> architecture already designed and built that can easily be used. But
> remember that IComponent is not the perfect solution, and Microsoft
> themselves have dropped it for WPF/Avalon and the Cider designer, and
> written a simpler component architecture
> The ideal solution for the designer services would be something
> designed specifically for Monodevelop, but ComponentModel-aware. Maybe
> an abstract ComponentModelDesignerDisplayBinding could wrap these with
> ComponentModel services? These then could consume a more generic
> ToolboxService and PropertyGridService that could be used by text
> editors and Stetic and the project pad and anything else. The
> PropertyGrid could be aware of IComponents, description attributes and
> change services etc, but use a MonoDevelop alternative if they're not
> Lluis, how would this fit in with Stetic? Is this an approach you'd be
> interested in?
So, there are two goals here: one is avoid having one toolbox pad and
one property grid pad for each component model used by MonoDevelop
(Stetic, ASP.NET, UML, etc). The other goal is to provide a generic way
of editing properties for any object of the IDE (projects, solutions,
For the first goal: I think we can implement in MD a toolbox generic
enough to be useful for ASP.NET, Stetic or any other designer. I don't
see a big problem here. The property grid is a more complex subject,
since different component models may have very different needs. The most
simple solution here is to provide a way of setting the property grid
widget to be shown in the properties pad. When a component is selected
in a designer, the designer just will need to make sure to display its
own property grid in the pad.
About the second goal, we need to define a component model to use, and
an API for setting the currently selected object. I think it is not
necessary to create a new component model for this, since
System.ComponentModel would be enough for editing arbitrary objects.
Maybe something like this:
// To be used by different component models
void SetPropertyGridWidget (Gtk.Widget w);
// To be used by System.ComponentModel users
void ShowComponentProperties (object obj);
> I'm going to be applying for the Google SoC this year
> with a view to properly integrating AspNetEdit into MonoDevelop, and I
> would really like to be able to share some designer infrastructure.
That would be awesome!
> > IMHO we'll never have databinding support as for MWF or ASP.Net in Gtk#
> > because of this.
> I heard it would become a priority after finishing MWF. It doesn't
> necessarily have to work the same way; there are better databinding
> models out there.
> Monodevelop-list mailing list
> Monodevelop-list at lists.ximian.com
More information about the Monodevelop-list