[Gtk-sharp-list] Future Direction of GTK#

[Miguel de Icaza]

Hello,

> What problems need to be fixed?

I think there are two areas:

	* Missing or incomplete features.

	* Show-stopper bugs.

We know of some bugs and feature requests (they are logged on bugzilla),
but some others we do not know.  It is hence very important that we
finish porting all the samples and tutorial programs from Gtk, Gnome,
GConf, to make sure that we have covered all the bits.

For example, Vlad recently ran into problems when trying to use the
clipboard APIs, and he had to do a lot of work to get it to work, but it
was not immediately obvious that changes were needed.

The other moderately interesting issue I remember is that we need to
track down points in the API where we return an internal object and do
not reference it before returning it to the user.

This should ideally be done by source code inspection of every entry
point (not hard), but someone has to do it. 

> What features would you like to see in gtk#?

I have logged a few of my favorite ones in Bugzilla, like ToString
methods for most objects to render something interesting about
themselves.

But on top of that, it would be nice to have "utility" methods in Gtk#
for common operations, but doing these is probably best done by looking
at the emerging samples and ported programs for simplification.

We should add helper methods where it makes sense for C#-ish reasons for
example.

> Should it have a model similar to System.Windows.Forms and/or
> System.Web.UI.WebControls?
> If so, what would this model look like?

Can you give more details of what you have in mind here?

> Are there any other GLib, GTK+, or GNOME libraries/applications which will
> have bindings in GTK#?

It would be nice to have Bonobo and NautilusViews bindings point.  Or
even EvolutionViews.

> What kind of applications would you like to see working with GTK#?

I would personally like to see Gtk# mature to the point where we can use
it to develop "plugins" for existing Gnome applications (ie, not rewrite
the applications, but host the Mono runtime in the applications, and
extend them through the embedded runtime).

Also, native applications like mPhoto would be nice to have.  More nice
and interesting applications.  In particular, we will need a good and
solid documentation browser that is as good, and better than the MS
documentation browser. 

I also think that we are not yet taking full advantage of .NET, even in
applications like SharpDevelop.  For instance, I would like GUI apps
like SharpDevelop or mPhoto to have a "console" available to type in
commands, or to load scripts.

I would like to see in the long run the MCS compiler support an
interpreted mode, so we can embed it, or use another interpreter that we
can embed into applications easily, to move the gadgetry out of the core
of the application, and up to the scripting layers.

> Will GTK# ever be able to interoperate with Mozilla's XPCOM/XPConnect?

What do you have in mind?  We could create a bridge that links the
XPConnect and Mono worlds relatively easily. 

Miguel