[MonoDevelop] Gtk# GUI Designer?

[Payton Byrd]

I think that using namespaces fixes the problems described.  You have a
basic namespace for "standard" widgets such as buttons and labels, and
then each targeted widget would reside in a targeted namespace.  Yes, it
creates dependencies.  It also allows interface designers to decide what
namespaces to support.  In the case of Microsoft, they probably won't
support GTK widgets directly, but that doesn't mean you cannot create a
user control to implement a GTK widget and then map that widget's
namespace node to your user control when the XML is parsed to the native
language.

Payton Byrd


-----Original Message-----
From: monodevelop-list-admin@lists.ximian.com
[mailto:monodevelop-list-admin@lists.ximian.com] On Behalf Of Martin
Probst
Sent: July 11, 2004 6:46 AM
To: Monodevelop Mailinglist
Subject: Re: [MonoDevelop] Gtk# GUI Designer?

Hi,

> Anyway; there has been a lot of research in making abstractions in
> user interface design. This has been successful in the design of
> websites (xhtml + css, xforms, device independence wg,...) but it did
> not make it into traditional user interface designers (yet).  This can
> be an excellent chance to think about these concepts.

I think the major problem is not the naming of properties, widgets or
whatever, you could navigate around that by using some kind of mapping,
as the vocabulary you mentioned.

The major problem is that you will run into big problems with advanced
widgets. xhtml+css works in a very platform independet manner only
because it has a *very* limited set of widgets/possibilities.

You can achieve a GUI toolkit independent way by limiting yourself to a
set of the very basic widgets like input fields, buttons, menus etc. But
you will run into major problems if you try to map something like the
various concepts for thins like list/tree views and other stuff. With
advanced widgets the concept of the programming model for these widgets
varies heavily between different toolkits.

Also in lots of toolkits there are widgets you just don't have in other
toolkits, so you'd have to write a mapping of a complex widget in
toolkit A to several widgets in toolkit B which would then achieve a
similar behaviour. Or you would even have to write a new widget for
toolkit B.

If you follow these thoughts you might find yourself nearly writing a
completely new windowing toolkit, and that kindof defeats the purpose.
You would have to write so many mappings etc. which you had to ship with
your applications that it gets bloated and you loose the "write here and
run on every GUI toolkit we support" because either your app would
nearly include a full windowing toolkit or the end user would have to
install your mapping software.

I don't think that this approach would really make things easier or is
feasible.

mfg
Martin

_______________________________________________
Monodevelop-list mailing list
Monodevelop-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/monodevelop-list