> > Do we really need to retain backward compatibility here? > Yes, IMHO. I can think of several advantages (flexibility, pilot-link > regression testing, being able to test new features on 0.12 before > it's released without branching the code...), and the only > disadvantage is extra code maintenance for developers. I decided not to gut the code TOO deeply, partly because I can see the need for it to remain in the short term, but also because I realize you'll bear the burdon of the support/backporting if I do this. I'll see what I can do to fix this conundrum. I tend to build with some pretty pedantic CFLAGS, so I'm catching quite a bit, but even without, a stock tree will fail distclean, because the *-abs.c and friends haven't been ported to the new API (mostly pi_buffer_* stuff). There's some cleanup too, in the variable names that could help. I was wondering why pi_buf was in some places and piBuf in others: pi_buffer_t *piBuf = NULL; piBuf = pi_buffer_new (0xffff); Could just be expressed as: pi_buffer_t *pi_buffer = pi_buffer_new (0xffff); Minor stuff like that. Consistent names help tracking down some of the more-obvious buglets. I'll keep plowing through and send you a patch after I verify that I didn't inadvertently break anything. I'm not a GNOME person, but C is C, so that much I can grok. -- David A. Desrosiers desrod gnu-designs com http://gnu-designs.com
Attachment:
signature.asc
Description: This is a digitally signed message part