On Mon, Mar 28, 2011 at 6:27 PM, Kevin Cozens <ke...@ve3syb.ca> wrote:
> It's a good thing I asked that we clarify the problem as I was thinking it
> was something else entirely. Pointers to a couple of files that show the
> issue of a lot of boilerplate code would be good so we can all see the
> extent of the problem.
> If the problem really is with gObject and the need for a lot of boilerplate
> code there are several options.
> 3. Create template file(s) with all the typical boilerplate code.
> If people are copying from existing files it might be easier to just create
> some template files that can be used as the starting point.
> 4. Write a program to generate the boilerplate code.
> If template files could not be made to handle the typical use cases, a
> program could be made where a person could answer questions or set options
> and have it generate a file with all the required boilerplate code.
> 5. Use a "chanting" system similar to what is used in BABL and GEGL.
> The chanting system in BABL/GEGL seems to work well in that it makes it easy
> (or easier) to work with things like the GEGL operation files without the
> need for a deep understanding of gObject.
As one of the supporters for the Vala suggestion, I am willing to
"give up" the vala option, for options 4 and 5 (3 is sort of what many
of us already do - copy paste).
I don't know how "easy" is option 5 to write, but option 4 does seem
more or less possible. also, the fact is that most work with gobject
code is writing it in the first time, so I do think that a generate
once tool would solve my problem. Again, I'm speaking just for myself.
We have a meeting today, and we can *try* and sort this out then. I do
agree that introducing another language isn't such a good idea, and
what Simon showed doesn't increase my trust in vala (even if I like
Gimp-developer mailing list