[EMAIL PROTECTED] (Linas Vepstas) writes:
>> True. I was sort of thinking in terms of "g_object" (or gtk_object)..
>> Which sort of makes some basic level of sense to me.. *shrugs*
>
> Is this an explicit statement of support for g_objects? In the past,
> you've seemed allergic to them, and so we've developed this system thats
> sort of similar and sort of different. Should the qof guts slowly
> migrate to be tightly integrated to g_objects? Or maintain a loose
> affiliation? I certainly have the urge to start using the same
> naming conventions where possible.
>
> (Working on qof has helped me get a grip on where they're similar and
> where they're different, and I've enjoyed that...)
I have no object at this point in time to using g-objects -- except
we'd need to expidite the g2 port for you to use them. I.e., gobjects
are currently limited to use in the g2 port (see my previous concern
about mixing glib-1.2 and glib2).
So, if you want to work with glib2 and gobjects, you're welcome to
continue your work on the g2 branch and work from there... I'm hoping
that the port will get far enough along soon enough that we can merge
g2 into HEAD and go on from there... But that's still a few months away,
I suspect.
My previous issue with gobjects was the compatibility with glib-1.2.
I've been using gobjects for a number of things in the g2 port (e.g.
the generic druid infrastructure). I kind of like the concept. :)
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
