[MonoDevelop] General purpose Toolbox and PropertyGrid

Alexandre Miguel Pedro Gomes alexmipego at gmail.com
Fri Apr 14 15:27:27 EDT 2006

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

IMHO we'll never have databinding support as for MWF or ASP.Net in Gtk#
because of this.

On 4/14/06, Michael Hutchinson <m.j.hutchinson at gmail.com> wrote:
> 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? 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).
> 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.
> 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

Alexandre Gomes, Portugal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/monodevelop-list/attachments/20060414/e6d8e2a9/attachment.html

More information about the Monodevelop-list mailing list