On 1/23/07, Bryce Harrington <bryce@...961...> wrote:
* Implement gradient UI "release" handler to deal with gradient garbage collection (see bug 984854)
Looks like that bug concerns the gradient editor dialog which, with the current advances in on-canvas editing, is planned for removal. If anyone can think up a good reason to still have that dialog after we can add/move/remove/recolor intermediate gradient stops on canvas, please speak up.
* Replace style.cpp entirely, with a clearer and cleaner version.
Mental or anyone, can you please elaborate on what is fundamentally wrong with style.cpp? Yes, it's huge and messy, but so is CSS specification. Megatons of work went into testing and debugging this piece of code over the years. Is there no chance it could be improved gradually rather than replaced wholesale?
One problem I'm very aware of is that SPStyle does not use URIReferences for tracking stuff in defs. A lot of documented bugs stem from this. However I don't think it would be such an unsurmountable task to fix this within SPStyle. And yet I'm not doing this - mostly because of this plan to "replace style.cpp altogether" which seems to be in our TODOs since forever: why spend time on code which will be replaced? So, I'd like to discuss this now to make sure we know what we're going to do.
* Convert use of gboolean to bool where feasible * Switch from use of TRUE/FALSE to true/false
I think it's mostly done by now. The remaining gbooleans cannot be changed because they are used for GTK APIs.