Re: Thoughts on mm-common and gmmproc

[Krzesimir Nowak <qdlacz gmail com>]

On Tue, 2010-01-19 at 15:56 +0100, Murray Cumming wrote:
> On Tue, 2010-01-19 at 14:16 +0100, Krzesimir Nowak wrote:
> > And so I did, but it a still work in progress though, some more detailed
> > informations should be added.
> > 
> > http://live.gnome.org/gtkmm/mmproc
> 
> Looks good. Some thoughts:
> 
> 1. I'd use call it gmmproc3. That's simpler.

Or gmmproc5 if looking at header of gmmproc.in:

######################################################################
# gmmproc (version 4)
######################################################################

> 
> 2.
> "
> * Rework defs and xml parser to use gir files. Xml documentation file
> would stay, because gir contains all information about C API, but not
> all documentation. 
>   * Rewrite gmmproc itself to use only one language - perl or python."
> 
> I imagined that it would be easier the other way around. Then again,
> it's hard to say why.
> 
> 3. I would personally veto any attempt to use Perl. I hate its syntax
> more the more I use it. I'd still dislike working on gmmproc if it had
> any perl. python is much less obscure.
> 

I thought about adapting current gmmproc to use gir (which would just be
a rewrite of GtkDefs.pm into something like GtkGir.pm) and then
rewriting the rest, so the complete rewrite could use features in gir
files like description of function parameters (whether they are in, out
or inout or NULL is allowed). But if perl is declined, a rewrite will
hardly be a two stage process. In this case I won't touch old gmmproc,
but rather start new from scratch. Seems also like a good opportunity to
dive in python.

> 4.
> For now, I'd keep gmmproc in glibmm (well, a branch) for now. That makes
> it much easier to play with, because you can change it and use it all in
> one module.
> 

Ok.

Also, a rewrite rather could be targeted at gtkmm-3. Maybe gtkmm-2.x
could be later ported, if possible.