On Sat, 2004-10-02 at 15:25, Bryce Harrington wrote:
I think the text rewrite has not received very much attention.
Unfortunately we'd need to finish it or roll it back for a release, as it's pretty broken in its current state.
Bulia mentioned you were 25% along with layers?
That's about right, yes. I think layers are required (lots of users keep pinging me about it and are expecting it for our next release), but fortunately they are pretty doable. My main limitation is free time.
Gtkmmification is making progress but it's a huge task; I'd estimate it's only ~10% done.
With gtkmmification, if we pushed that one off, would we possibly be able to back off of the Gtkmm 2.4 libs and go back to Gtkmm 2.2? If so, that could eliminate that dependency worry.
I'm not sure -- wasn't part of the move to 2.4 for the sake of the newer version of sigc++ (or vice-versa)?
The garbage collector work sounds like it's fairly far along but it sounds like there are issues still to be worked out (dependency trouble if nothing else). A 0.39.5 release would be useful here, in that it would help shake out and expose some of these problems, and let us get it completed.
I think I've taken the garbage collector stuff as far as I want to for this release cycle, sans some additional debugging. I think the only additional garbage collector use for a while would be from the addition of new code.
I don't know where AST is at, but it doesn't sound like it's gotten very widespread review yet; since that is going to be a pretty intensive change, it's probably not something we want to rush. I'd favor giving that the additional development time of putting off to a future milestone.
Definitely. I'm not going to be ready for AST proper for a while yet.
Actually, I think the current state of the text code underscores the perils of doing out-of-tree development in a separate environment and then trying to merge a whole lot of work into the tree at once. As a result, I've been reconsidering my approach for AST implementation.
The AST code I've written so far was at least valuable as a draft and a learning experience, but at this point I don't think we're going to end up using it.
Rather than a revolutionary change I think we can get there from incremental changes to SPRepr, and for much of AST development without disturbing the existing SPRepr API very much.
I'm wondering if we may also want to re-examine our approach to gtkmmification along similar lines...
Bulia says there's a significant amount bug fixing needed. Releases are effective ways of focusing efforts towards getting bugs fixed. Delaying a release only helps if accompanied by a freeze; given how much development is still needed to achieve goals, an extended delay doesn't seem like the ideal approach for the present - we'll be more likely to keep atop the bugs if we focus on releasing sooner rather than later.
Agreed.
So I guess the real question is, aside from whether we've met our goals or not, has enough new stuff been implemented to make a release worth the trouble for users to upgrade? Keep in mind that with the new Gtkmm, boehm, etc. libs, this will be a more challenging release for users to install than we've had before. If we are able to back off of the Gtkmm 2.4 lib back to 2.2, that'd lessen that concern quite a bit.
I think layers, text-on-path, and bitmap tracing count as "killer features" for our userbase, and should be enough to justify a release, as far as that goes.
-mental