Alexandre Prokoudine wrote:
> It has *something* to do with too much gobject boilerplate code.
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.
1. Don't use gObject.
Just including this for completeness since it is very unlikely to happen.
2. "Fix" gObject.
Update/improve gObject so it doesn't require so much (or any?) boilerplate
code. I've been looking at two other OOP languages and haven't seen the need
for boilerplate code. If its needed with gObject its either a design issue
of gObject or due to the complexity of GIMP objects.
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.
6. Use some other programming language to avoid having to write boilerplate
This option is really just another way to avoid having to write boilerplate
code by hand.
If vala (or language x) is used to avoid the need for all the boilerplate
code there are still a number of issues:
1. Time to learn gObject vs. time to learn vala
2. Time to change code to be vala based instead of raw gObject.
- Need to know both system while migration is taking place
3. How many GIMP developers can write code in vala?
4. How many GIMP developers who know vala are free to work on the migration?
5. How much of GIMP would need to be updated/modified/rewritten in vala?
I think throwing another language in to the mix is the wrong way to address
the boilerplate issue.
Gimp-developer mailing list