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

[Miguel de Icaza]

Hello!

> 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:

	http://www.nexus.hu/vargaz2/

> 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
mono-docs-list.

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.

Miguel