[Gtk-sharp-list] Possible improvements to gtk#

Miguel de Icaza miguel@ximian.com
03 Jan 2003 23:29:14 -0500


> Comments within.
> On Fri, 2003-01-03 at 19:48, Miguel de Icaza wrote:
> > I read the following comment on the GUI tool for the Mono coverage
> > analysis tool, it seems like a nice starting point to add some
> > customizations to Gtk#:
> > 
> I'm not sure what you're referring to. Is there a URL where I could view
> this?

The comments come from the source code to the Gtk version of Zoltan's
coverage tool:


> Given Gtk+'s geometry management, I don't think (parent) would ever
> work. But there are other convenience functions that could be written.
> GLib.Value overloads come to mind.

Yes, I agree there.  

> > //  - the generated sources are hard to read because the API functions are
> > //    mixed with internal functions, export directives etc.
> > //  - the app is slow to start up, slower than Qt#. Afterwards, it is faster.
> Outside of combining everything into a single assembly, there's very
> little that could be contributing to this in Gtk# (as opposed to Gtk+).

We should still dig into this problem and find what is slower.  Multiple
shared libraries?  Multiple assemblies?  Atk/Pango startup time?  gtk
startup time?  The issue might not even be related to the binding.

> I would be wary of an entirely new API (since there will be a new
> filesel, with filters, in Gtk+ 2.4), but it'd be easy to add a few
> static methods that run the fileselector internally:
>  public static bool GetFileName (out filename, FileMode mode);
>  public static bool GetFileName (out filename, FileMode mode, string
> suggested, string[] extensions);
>  public static void GetFileNameAsync (FileCallback cb, FileMode mode);
>  public static void GetFileNameAsync (FileCallback cb, FileMode mode,
> string suggested, string[] extensions);

Yeah, agreed with you.

We could have the filters as a params (like Qt does), and for now just
ignore them.

> What tools did you have in mind? I have some ideas as how to merge in
> gtk-doc sources, but I'd like to hear what you've thought up.

Well, we have Monodoc which is used to document assemblies from a
"reference" assembly.  The tool is not finished, and needs some
polishing, but it implements what we have discussed in the past in

The browser tool is designed to be like the MS .NET Framework
documentation browser and will cope with merging multiple documentation
trees in a single hierarchy.  I have not finished it, but will check
something this week.

There are certain pieces of the Gtk documentation that can be reused:
most of the explanatory text in it;  But the individual API calls is not
as well documented as the .NET documentation, so I would like to take
this opportunity to improve upon it.