On 1/24/07, MenTaLguY <mental@...3...> wrote:
I think it's only practical to conduct the process incrementally, but when it's complete I don't expect any of the original code to be left.
I very much doubt that. Your goals are good, but I don't see how they could lead to replacing _all_ of the current code. Refactoring and simplifying, probably. But there's a lot of code there which cannot and should not be replaced. Take sp_style_merge_from_dying_parent and its helpers, for example. It's a huge piece of code which painstakingly implements (and documents!) the merging of all supported properties. You cannot make it much simpler than it is, because there is in fact a lot of variants of doing merging depending on whether a property is inherited, whether it accumulates (as opacity), whether it allows relative specification, whether it's numeric, etc. etc. It's still incomplete and may be buggy, but I see no other way to approach this. Please let's not try to fix what isn't broken.
On the outside, it should present a simple set of accessor methods for getting/setting properties by name, and propagating to/from repr.
Agreed
- a concise list of property names with the expected domain of values
in CSS and the associated Inkscape data type
This is pretty much how it's done already. We have types for lengths, paint, filters, etc.
- a concise list of property aliases which represent one or more
properties combined, each with the rule used to combine
This is perhaps where some refactoring is indeed necessary (though I haven't looked at it closely)
- definitions of the aforementioned rules and value domains
All string-valued properties already have their accepted values listed in enums.
- some generic code (not tied to any one property) implementing the
needed behavior
We already have a lot of generic code there - for reading/writing paint properties, for example. Perhaps more functions like this can be added, and existing ones can be streamlined, but I don't think it's going to be something too drastic.
Just an example, when Peter Moulder added support for libcroco and document-wide style specifications, it was a solid piece of new code, but it didn't require rewriting any significant portion of style.cpp. It was reasonably neatly slapped on top of it and works fine. Which shows that for all its incompleteness, style.cpp is not so really bad by itself.
So, per above, I propose that we stop talking about "replacing style.cpp" and remove that phrase from the roadmap. "Refactoring/streamlining style.cpp" sounds much closer to what we really need and, unlike "replacing", will not have the chilling effect on developers who might want to hack on that file.