[MonoDevelop] General purpose Toolbox and PropertyGrid

Lluis Sanchez lluis at ximian.com
Tue Apr 18 11:12:20 EDT 2006


El vie, 14-04-2006 a las 01:05 +0100, Michael Hutchinson escribió:
> Hi All,
> 
> I've been working on the Toolbox and PropertyGrid I developed for the
> ASP.NET Graphical Editor. Due to academic commitments development has
> been very slow, so no-one's seen any of the code yet, nor will for a
> while! The most obvious change is porting them to GtkTreeView, and the
> lack of GInterface support in GTK# has made this quite challenging.
> 
> However, I think the most important thing I've been considering is how
> these two components will be able to integrate with other designers in
> MonoDevelop, particularly Stetic but also anything else that might
> appear in the future. The PropertyGrid might also be useful coupled
> with the project browser as in Visual Studio.
> 
> The main question is: is anyone else interested in a generalised
> PropertyGridService and ToolboxService for MonoDevelop? 

I think it might be useful.

> Does anyone
> have any ideas how it could fit into the architecture? I'm not very
> familiar with MonoDevelop at all, but this appears quite challenging
> to me.
> 
> In AspNetEdit I use the .NET ComponentModel's ISelectionService and
> IComponentChangeService etc to allow the PropertyGrid to respond to
> changes of selections automatically and to update when the properties
> change value. It registers as a consumer of the events they generate,
> and the events are fired by the ASP.NET controls and their designers
> and PropertyDescriptors, which acquire a reference to these services
> through their ComponentModel containers. As far as I can see, this
> model does not map well to Stetic and MonoDevelop.
> 
> I think the best solution would be to implement a MonoDevelop
> ISelectionService that uses the ComponentModel. This allows us to take
> advantage of the property descriptors and visibility, description and
> categorisation attributes that already exist. I absolutely rely on
> these for AspNetEdit. Stetic would have to pass proxy objects to this
> service, wrapping its own functionality, but that's probably easier
> than mapping IComponents and their attributes to a completely new
> model. I'm happy to get involved on the Stetic side if necessary (and
> when I have time).

I don't know much about ISelectionService and related stuff, so I can't
tell if it is possible or not. However, there are some Stetic features
which AFAIK are not supported by System.ComponentModel, such as custom
cell editors (I'm talking about real tree cell editors, not editors
shown when pressing a button), or hiding/disabling properties depending
on the values of other properties. How could we fit those features in a
property grid based on System.ComponentModel?

> The toolbox would be a bit easier. Although AspNetEdit's
> implementation depends on a ComponentModel Host host, Stetic would
> simply have to implement a trivial skeleton host to which created
> objects could be added. Or a custom ToolboxItem derived class for GTK#
> widgets could call into Stetic directly. Drag-n-drop etc would still
> be tricky, but I haven't worked out a reliable way to do that with
> Mozilla yet either for anything except plain text.

Yeah, the toolbox should be easy to integrate.

> 
> Something to consider: both of these pads might find a use in the text
> editor, especially for ASP.NET pages.
> 
> Anyway, I know I've been rambling, but basically I want to hammer out
> a design with which everyone will be happy  as I'd like to avoid
> duplication of effort on Toolbox-like and ProperyGrid-like widgets.
> I'm writing these already for AspNetEdit, and it would be great if
> they could become generic MonoDevelop IDE services.
> 
> 
> Michael
> _______________________________________________
> Monodevelop-list mailing list
> Monodevelop-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/monodevelop-list



More information about the Monodevelop-list mailing list