On Gnucash, G2,
and Architecture (was Re: [Gnucash-changes] Eliminate a double free
warlord at MIT.EDU
Fri Jun 3 16:31:03 EDT 2005
Chris Shoemaker <c.shoemaker at cox.net> writes:
>> > It's better to design out a bug than to patch it out.
>> Normally I would agree with you. In this particular case, I tried to do
>> that three years ago and ended up throwing up my hands and declaring
>> that I had better things to do.
> I can sympathize.
For the record, I looked at this a long time ago as well. At the time
I concluded that all destruction of data should happen in the GTK
"destroy" callback, because not all dialogs use the component manager.
This way all dialogs are consistent. You see, all of them DO use
This means that all the component manager callback needs to do it
destroy the widget (call gtk_widget_destroy() on the dialog) and
Consistency is a good thing.
>> > BTW, I'm _really_ not a design nazi. I just _look_ like one next to
>> > you. :) You seem to think that anything in GC that works must be a good
>> > design.
>> That's unfair Chris. I don't think I've ever heard Derek say that its a
>> good design, only that it works so why change it.
> I certainly don't mean to be unfair, and I apologize if Derek thinks I
> was. Derek didn't say it was a good design, but it's pretty hard to
> get him to say anything in GC is a _bad_ design. I really think that
> he's just spent so long with GC code, that almost everything there
> looks reasonable to him, even stuff that, IMHO, isn't very reasonable.
Um, you clearly haven't read my posts over the last, oh, five years.
I'm always the FIRST to stand up and list the things wrong with gnucash.
David listed a few. A few more on my list:
- the half-assed modularization effort
- the poor distinction between shared library and loadable module
- the fact that gnucash is fragile in the face of "/usr/bin/guile"
- too much logic in the UI
- too many "gpointer" apis without real runtime type checking
(it would be better to have compile-time type checking, but
that's even HARDER is C).
I *AM* an architecture purist, even if you haven't been able to
notice. On the other hand, I'm also a realist, and truly believe that
"The Perfect is the enemy of The Good". I'd much rather have
something less than perfect but still "good enough" and get it out the
door than not have anything (because I haven't reached that nirvana of
I think David hit the nail on the head when he said that we need to
get the g2 port out the door and there are many real issues now that
need to be fixed, places where the code crashes or just plain doesn't
work... And THOSE are IMHO orders of magnitude more important to
fix/replace/repair than replacing code that might not be
architecturally pure but still happen to work just fine.
In an idea world with unlimited resources, sure, I'd LOVE to
completely re-architect gnucash from the ground up. I'd probably go
with C++ and Qt as my building blocks, but that's just a side note.
We don't live in an idea world, and we don't have unlimited resources.
Therefore, we need to take the resources we have and apply them in the
most beneficial way.
Which do you think is more beneficial to the project in the next six
a) Taking a piece of code that might be architecturally questionable
but doesn't crash, doesn't corrupt data, and doesn't cause any
visual problems and spend time to fix the architecture and rototill
the code to change how it works?
b) Take some code that causes the program to crash, corrupts data, or
visually misbehaves and spend the time to fix those issues?
>> You've clearly taken offense that he doesn't agree with you
>> that this is a heinous design issue that needs to be fixed immediately.
> That's not really true. "Offense" is too strong; It'd be more
> accurate to say that I'm "concerned" that he doesn't agree with me
> that this is a design issue _at_all_, and furthermore, (actually this
> is more of the real concern:) that this is just one example
> representative of a rather long list of (IMO) design "weaknesses"
> about which we disagree.
In the grand scheme of things (or at least the grand scheme of gnucash
[no pun intended]) I don't think this is a heinous architectural flaw.
I can certainly point out a half dozen or more significantly more
heinous archictectural flaws in gnucash.
Yes, you and I certainly disagree on the magnitude of the issue. I
tend to focus on what I consider the larger ones, those that have
caused lots of user pain and angst over time; those that represent
potential problems going forward. I listed a few of them earlier.
Feel free to look at my posts over the last five years for a bunch of
other complaints. Also take a look at bugzilla for a list of users'
Frankly, I want to spend my time gaining the most bang for my buck. I
don't want to spend 10 hours writing code that will save me 20 minutes
every five years; I want to spend 20 hours writing code that will save
me from answering 5 user help emails every day.
>> I can't speak for Derek, but I'm willing to look at any changes you
>> propose for this area. They just have to be thoroughly tested (e.g.
>> normal close, window manager close, CM close, application killed, etc.)
>> before I will spend much time on them. I'm still overwhelmed with gtk2
>> changes/cleanups, and I've barely even cracked the new "Human Interface
>> Guidelines" document.
Personally I'd rather see you work on fixing code that's actually
broken (read: doesn't work, causes crashes, causes data corruption,
etc.) than spending time re-architecting code that works, albeit in a
weird way. Do I think the current code is the best possible way it
could be done? Hell no! Could it be done better? Hell yea!
But honestly.. How does changing the CM/Gtk interaction help us
release the g2 port any sooner? Shouldn't we make getting the g2 port
out the door our #1 concern?
Assuming you answer "yes" to my final question (and I really hope you
DO answer "yes")... what do you feel are the steps necessary to get
the g2 port "finished" and out the door? What do YOU think is missing
or still needs to be done before it's ready to package up and pass on
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
warlord at MIT.EDU PGP key available
More information about the gnucash-devel