On Mar 28, 2006, at 12:18 PM, MenTaLguY wrote:
> On Tue, 28 Mar 2006 02:42:45 -0800, "Jon A. Cruz" <jon@...>
>> Next rough, kludgy update has been committed.
>> Now if objects have a "HOTFill" or "HOTStroke" attribute that matches
>> the color's index and palette name, those objects will get their
>> stroke and fill updated when the color changes.
> This isn't acceptable. Please revert the commit or at least move
> the attributes into our namespace.
> Do not knowingly commit stuff that is broken (in this case
> violating our SVG compliance policy) to trunk. Incomplete, fine,
> but not broken, and especially not violating core SVG practices.
Sorry about that.
I did drop the ball on the naming of the attributes. Of course, that
was literally a 3:00 am "what the heck do I call this" final minor
step. I was hoping to get feedback, and was able to correct that.
To give a quick run-down on things, especially for others, I wanted
to cover what I think were the most important points here.
* Top of all is communication. I was trying to get some stuff in, and
wasn't sure of all the details, so I sent mail out to let everyone
know what was going on. That did get me what I needed (extra eyes on
the details), and got me to be able to correct the main problem right
Then there are some details to what I did...
* First of all, the bulk of what I did was actual prototype code, not
just kludges. The main temporary code was in the "UI" of the two
attributes and the "magic strings" in the palette entry names. If
more had been experimental then it should have stayed local or gone
into a temporary branch. In this case, however, much of what I was
doing was code to support spot colors, ICC colors and others, and had
gone over some of with the Scribus guys and with LittleCMS's maintainer.
* Then the temporary code was very minimal and localized. Of the
files I'd changed, only two had contents that were 'kludged'. And on
the bad names, only one line in the first file and two lines in the
second file had to be changed to correct it.
* Changes I did would not cause any different behavior unless people
took proactive steps to turn it on. Specifically they would have to
hand-edit the .gpl files to have fairly specific strings to enable
anything to happen. By default, the change would not affect .svg
output at all.
* Questionable behavior was guarded. Aside from the code to prevent
accidentally turning things on, the aspect of "live color linking"
was potentially problematic. To help guard against issues there, I'd
added the extra 'L' item so that even if other things were "on", one
couldn't accidentally link colors, but would need to add that control
* The stuff I put it was fairly well tested. I'd stepped through code
in the debugger, and also ran things through several edge cases.
That's actually most of what took me a while to get to be able to
check things in. Many times I'll work through code, and then in final
testing end up deciding not to put it in (like my last multi-week
effort exploring switching to stock GTK+ toolbars). Nothing should go
in without good testing. The last time I had some main problems with
a commit (the splitter window for the embedded palettes) it was not
for lack of testing, but that two keys were "consumed", but on my
computer the function keys in question couldn't be tried. So testing
doesn't cover 100%, however it can get most things.
Overall, I'd say that things weren't as bad as they first seemed (and
the main objections seemed to be about the minor portions that would
not be staying long anyway), but that communication was key and
helped me finish addressing problems with things. And thanks, Mental,
your information was precise enough that I could address things
quickly, and correct the worst of what was wanting.
Of course... there's another complication, but that's for a different