Colin Bennett wrote:
Quoting Daniel Rogers <daniel@xxxxxxxxxxxxxxxxx>:
Ok . .. Great! Have you done JAI programming. I am taking some
inspiration from that particular library.
I've read about JAI and considered using it on a project but ended up deciding
against it because of the non-open nature of the license and because it was a
bit overkill for the small tasks we needed it for. So I have a little
understanding of JAI's way of doing things.
... I've spent some time since I first started looking at GEGL trying to
understand the GObject system, since I've never used it before, and have come
to the sad conclusion that it is N.A.S.T.Y.
I also don't like the gobject system. I despise it really.
go figure. There are other people who are more interested in the
language bindings, etc, but, I have dreamed of moving away from GObject
for a while (or at least the C incarnation of it), for a while. There
are aparently other people who strongly feel that gegl should be plain C
w/GObject, and I've not had the will to argue with them. I've
considered the possibility of moving to C++, D, python+C code, java + C
code, and even sat down and tried to write out a D port, but gave up,
because I didn't want to abandon this project, and it seemed like so
much work. However, true mutidimenstional arrays, garbage collection,
versioning, macros, paramaterized types, first class array objects, and
inline assembly struck me as a beautiful language to build an image
processing system in.
Anyway, if it would attract more developers than it would reject, I
would be more than happy to consider a move away from the horrid mutant,
psycho space monkey that is gobject.
--
Dan
P.S. It seems silly that one of the biggest attractions of GObject is
that you can make all kinds of fancy language bindings for it, yet there
are still only a handful and think of this: one of the goals of GObject
is to be able to write language bindings so that one does not need to
use GObject. . .
