"Daniel Espinosa" <[EMAIL PROTECTED]> writes:
>> I think we have a major communication issue here...
>
> Yes we do...
Well, we should work on that.
>> qof_instance_release()
>> really doesn't do all that much interesting, and I don't understand
>> why that work can't be done in the QofInstance dispose() and finalize()
>> class functions.
>>
>
> It's clear that you can move the code to dispose() and finalize()
> functions, but you need to be shure that other derived objects (not
> GObject jet) finalize correctly its base class. Are you sure your
> branch do this correctly?
Of course I'm sure. See lib/libqof/qof/qof-gobject.h. The base
type definition always call the local dispose() or finalize() and
then chain up to the parent object's dispose() or finalize().
Contrary to popular belief, I /DO/ understand how gobject works
in general. I admit that I might not be completely familiar
with every last detail, but I do understand the high level
concepts. And I HAVE written GObject-based types before.
[snip]
> If you read my comment: YOU don't want to change too much then that's
> why I sugest to keep this functions; the thinks you are done in your
> branch more or less is the SAME I've done in gobject-engine-dev
> branch: move the init process to init and dispose functions. But the
Well, it's a lot less than what you did.. And the tree continues to
work build and actually work. THAT was the goal for step 1. Get the
initialization moved over and GET IT WORKING. Your branch still
doesn't compile, let alone work. The reason it fails: you tried to do
too much at once. Not only did you move the base initialization, you
tried to move the init/dispose/finalize code and add properties all at
once, instead of doing each step separately.
> problem is that this functions you can't send parameters like the
> QofBook, then the initialization process doesn't work, that's why you
> still need to call qof_instance_init_data (in your branch) to call
> qof_entity_init(). In my branch, I've created a "QofBook" property and
> when you create a new derived object you call g_object_new
> (GNC_object_TYPE, "book", book), then the init process is done as you
> have in your branch and the book property is set inmediatly. When you
> set the book you set the GUID's object.
Yes, I understand. And adding that property is another step in the
process. But it's a SEPARABLE step. It didn't have to be done
the first time through like you did. Yes, it's something that DOES
need to happen, but it didn't have to happen in the first step.
> But don't lose in my details, do the thinks as you think is the better.
I think we both want the same thing in the end. I think you need
to take much smaller steps to get there, steps like I took. I was
HOPING that showing you by example would help you understand what
I meant by small steps. I was hoping that you'd see "oh, THIS is
what you meant by small steps" and be able to work from there
taking similarly small steps along the path to the end that we
both seem to want.
[snip]
> See other projects use Anjuta to create GObject templates, and you'll
> see what I mean.
None of the gnucash developers use Anjuta, so that's not a useful
statement. I'll point out that Anjuta isn't the only way to
develop, and I think that the current GnuCash code conventions
trump Anjuta. Still, can you point me to a sourcefile that
shows what you mean?
[snip]
> I can write you in Chinese, but it's too rude. >:-()
Well, I know your first language is Español so I was trying to
help explain in your native tongue to try to get over this
communication problem that we seem to have.
[snip]
> I'm trying to help, but that's your opinion, and again WE have a big
> communication problem.
I realize you're trying to help, but you don't seem to be listening
to what Chris, David, Josh, and I are trying to tell you. Every
once in a while it FEELS like you understand, but then you go off
and take these huge leaps instead of small steps, or you go off in
a different direction than what we thought you were going to do.
Again, that's why I was trying to show you, by example, exactly what
we meant. Indeed, even *I* got admonished for actually doing a global
rename of QofEntity, QOF_ENTITY, and qof_entity to QofInstance,
QOF_INSTANCE, and qof_instance instead of just using #defines. Still,
the rest of my branch should show you, by example, what we meant
(and STILL mean) by "small steps".
As I said earlier, yes, there's much more work to be done:
- Properties
- Moving the create/destroy code into _init(), _dispose() and _finalize()
- Signals
- Much more....
And even THESE can be broken down into smaller tasks. They should
NOT be done at one time, and after each step the tree should build
and continue to work (which means it should pass "make check").
[snip]
> I'll help if you want, if you take this process in your hands, I'll be
> realy happy, and may I can add, suggest or send patchs.
We would love to have your help.
> I want to see your plan.
My plan: work in small steps. I honestly don't have a full plan
any more detailed that what I've been saying all along:
* merge QofEntity into QofInstance <DONE>
* get QofInstance to be based on Gobject <DONE>
* move code into init/dispose/finalize <Each object can be done separately>
* add properties <Each property can be done separately>
* add signals <each signal can be done separately>
* (more)?
I think we're at the point where each object, or even each feature,
can be done separately. The separability is important, because it
means you can commit a small change that doesn't break the tree.
Granted, some changes will be larger than others (like my QofEntity
renaming). Some changes will be much smaller. But the tree should
continue to work after very few changes. Like I said in my original
announcement, I spent only about 6 hours to get everything using
GObject in a very rudimentary way. But it still works, and now we
can spend more time getting more code migrated over to the "new way".
> But realy want your comments about my e-mail about to create a library
> to allow other applications to access the GC's data.
I think such a library is not necessary. We already HAVE that library.
It's called "The Engine". And once the gnucash engine is migrated
to gobject, well, it'll even be a gobject-based library. Using the
engine one CAN access GC's data. It's even a C library!
> I have some ideas, to add this feature:
>
> - Add a GdaDataModel interface to QofCollection object
> - Try to create a GdaServerProvider for the actual XML file
> - Create a wrapper library to allow other applications access the XML
> file (or even the GDA backend) using GDA
Again, I dont think we need any of this, because we already HAVE
all of this. (well, except for GDA, but Phil Longstaff is working
on that in the gda-dev branch).
-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
