2007/4/12, Derek Atkins <[EMAIL PROTECTED]>: > "Daniel Espinosa" <[EMAIL PROTECTED]> writes: > > >> I think we have a major communication issue here... > > > > Yes we do... > > Well, we should work on that. >
Ok great! > >> 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] I'll see your code and make comments or propouse a PATCH if apply. > > 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. > That's why I started a new branch. > > 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. > I'm not sure that convert QOF to GObject is the better way, but Ok if I can help, I'll do. > [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] Anjuta was just a tool to get the templates; I don't use it. You can see at: http://svn.gnome.org/viewcvs/libgda/trunk/libgda/gda-data-model-hash.h?revision=2593&view=markup and http://svn.gnome.org/viewcvs/libgda/trunk/libgda/gda-data-model-hash.c?revision=2863&view=markup > > 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". > I can understand why you feel that; the reason is that I don't think that convert QOF to GObject will be a good idea because its implementation doesn't allow it, you'll never have a full GObject system if you insist to use QOF. > 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". > Have you merged with trunk? I want to test a build, see the code and help when needed. > > 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). > Phil is creating a backend, using QOF as is. Maybe GnuCash doesn't need GDA at all, except for a backend, but if you want to access the data in GC you have a library, called actually Engine, but if we can create an "standard" interface using GDA, this will allow: - Get access from Gnumeric, to create powerfull analisys of the data - Data interchange with other applications - Import and export data using a CVS file, XML (like QSF does), in a standard way (some other software are using GDA today) - Easy data insert/update from other applications, like applets Of course that the GDA interface *must* use all the GC procedures to ensure the data integrity and consistency. -- Trabajar, la mejor arma para tu superación "de grano en grano, se hace la arena" (R) (entrámite, pero para los cuates: LIBRE) _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
