2007/4/13, Josh Sled <[EMAIL PROTECTED]>: > On Thu, 2007-04-12 at 17:42 -0500, Daniel Espinosa wrote: > > 2007/4/12, David Hampton <[EMAIL PROTECTED]>: > > > On Thu, 2007-04-12 at 14:06 -0500, Daniel Espinosa wrote: > > > > 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. > > > > > > You keep making that statement, but you haven't explained what you mean > > > by it. Why can't we eventually migrate to a full GObject, what will be > > > missing, and what will that mean to the project? Please either explain > > > yourself, or stop spreading what (at this point) I can only call FUD. > > > > > > David > > > > I don't want to create FUD, sorry. But you're right, I need to explain > > in more details: > > I will point out that nothing you said or the responses you've received > indicate that: > > - gnucash can never have a full GObject system
My point is QOF not GC. > - anyone is insisting to use QOF (in its current form) My point is the work to make QOF to be *FULL* GObject, and try to find ways to speedup the migration. > - anyone does not want to migrate to GObject features I know. > > The issue has always been one of timing and planning, that the changes > are made as a set of small, stable, understandable, auditable changes. > That's my objective, try to do the less work and try not to re-implement the actual QOF way. I insist to wrap QOF and step by step migrate QOF into a new pure GObject implementation (move the code from QOF to the new) -- 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
