[MonoDevelop] Gtk# GUI Designer?

[Martin Probst]

Am So, den 11.07.2004 schrieb Richard Hendershot um 16:14:
> > Yes, but that wont help you with the problems complex widgets will give
> > you. What if we have two toolkits and the mentioned listviews, and in
> > one toolkit the concept is like
> > > ListView mlv = new ListView();
> > > mlv.add("This is a line");
> > but in the other one you would have to implement full MVC pattern for
> > it, eg.
> > > ListContentModel mlc = new ListContentModel();
> > > ListView mlv = new ListView(mlc);
> > > ListController lc = new ListController(mlv);
> > and the add elements to the content model. This is only an example, but
> > how would you map this together? Your mapper would have to be really
> > smart to sort such things out.
> 
> the MVC controller would be a shell above the listview controller which
> would be a shell above the (possibly native) text control that actually
> recieves the message.  setText in this case I think.
> 
> MVC would provide a good abstraction layer for these shells, I think.
> 
> Hey, I'm not saying the necessary resultant XML files would be any
> simple, quick, nor easy.  But thinking in the abstract... well, there's
> enough indication that it would be a good thing ;-)

What I'm actually questioning is if this is really useful. It would be a
hell of a lot of work, close to something like writing a complete GUI
toolkit. And in the end, this "XML description of a GUI to native
Toolkit" thing would result in
a) different binaries for different GUI toolkits used 
   (mapping done before deployment)
b) the need to ship the application together with the library
   (mapping done on the client)
Case a) kind of defeats the whole .NET thing (different binaries once
again) and case b) would not really be that different from shipping the
application with a GUI toolkit like GTK+ included.

So the benefit would IMHO only occur in a) by using native widgets
everywhere with reduced effort for the programmer. But the effort to
provide this might be tremendous.

mfg
Martin