[Mono-list] Re: avalon development

[Miguel de Icaza]

Hello,

> Have we any plans of writing  _avalon / clone at present?
> It seems that no developer is currently woking on this.

Given that Avalon's API is known to have changed extensively since it
was first released, and that various pieces will be changed, working on
implementing Avalon today might be a waste of resources.

The namespace is large, and starting with the fact that the namespaces
are changing and objects will be moved, it will make the work of merging
those efforts later a painful exercise. 

Avalon today also suffers from a few design problems: they use the
Canvas model for rendering graphics which is fantastic for a few
objects, but once you hit millions of objects (like we painfully learned
with GnomeCanvas and its user GnomePrintPreview) is not a trivial
problem.

We speculate from the blog posts that things are being changed
architecturally as well.

> Now my understanding of the this  system goes like this -
> correct me if i am wrong :=)

Your list of steps matches my thinking on how to implement it.

Cairo is sufficient and can be hardware accelerated (today with OpenGL
or with the XRENDER extension).

I think what matters the most at this point is to get the foundation
right: Mono JIT engine, fine-tune the generics (both in the compiler,
the libraries and the runtime) and our Mono.Cairo bindings (update them
to the latest API).

I like the idea of Avalon, but I think it can be improved upon, if I
were you, I would wait for the beta release which will have a more
solid API to base your work on.

That being said, another thing I would love to see is a C#, Cairo-based
lightweight toolkit.   There are some amazing tiny toolkits written for
Java in 60k of jar files, something like that would be fantastic to
have for C#.

For instance, today we know that all you need for complex layout are
the equivalent of GtkTable()s, anything else can be build with that, so
I would only support that container model.  Also we know that
composition-based widgets are the way to go (Gtk, Avalon-like model
again).

You want to expose the Cairo API as the rendering API.

And finally, if you like Avalon, and you want to make the life of your
users simpler, you use a persistent graphics model, very much like the
GnomeCanvas (or whatever the name in Avalon is, I forget it) so the
"render" method only places persistent objects that the toolkit redraws.

I think that building such a toolkit might not only be fun, but
focusing on a tiny architecture will give you a lot of latitude.

Once you have a tiny toolkit built, you can start adding things that
people ask, like Accessibility and Localization (notice that in .NET
you can use conditional attributes to strip out these if you want to).

Miguel.