On Mar 28, 2006, at 12:18 PM, MenTaLguY wrote:
On Tue, 28 Mar 2006 02:42:45 -0800, "Jon A. Cruz" <jon@...18...> wrote:
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 away.
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 character.
* 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 message. :-)