On Mar 28, 2006, at 12:16 AM, Jon A. Cruz wrote:

I just checked in a change to start some experimentation with linked colors.

There are various technical things this will let me play with internally, but the immediate visible effect is that palettes can be edited and can have linked colors.

To enable things, a .gpl palette file needs to have some 'magic' strings in its names.

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.

Also... drag-n-drop from the color swatches will set the "HOT" value.

Again, the mechanism here is a temporary kludge. However, this should allow some playing with the feature.

On 3/28/06, Jon A. Cruz <jon@...18...> wrote:

Again, the mechanism here is a temporary kludge.

There's a saying in Russian, "There's nothing so permanent as something temporary."

Honestly, the amount of work and elaboration you're putting into these "kludges" worries me. If you spend so much time on it, why not make it a permanent, well-thought-out, well-named and well-documented feature?

I think that kludges should be avoided in general, but a kludge may be acceptable to commit into the trunk if it is small, very isolated, and very easy to replace with something better. I may be wrong, but what you describe here sounds like it's way too complex and deeply embedded for a kludge. I'm afraid it might stay that way for much longer than anyone anticipates, keeping to annoy us (me, at least) with its kludginess.

Just like that "eek-" class name you committed more than a year ago. The joke has long since worn out, but it is still there as a stupid eyesore.

Sorry if I sounded harsh, but I'm genuinely worried.

-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

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.

Again, the mechanism here is a temporary kludge.

I'm going to be a little stronger than bulia: no more major kludges please. Try to stick to prototyping.

There is a difference between prototyping/scaffolding (which may be incomplete, but works as far as it goes and whose design is provisionally good [i.e. comitting may be needed to evaluate it]) and a kludge (which has severe known flaws from the beginning, with the advance expectation of backing it out later).

Despite your best intentions, you've got a history of comitting "temporary" stuff that you subsequently fail to clean up. I think you need to be realistic: when committing, take into account the possibility that you may get interrupted.

I do _not_ want to see yet another release blocked waiting for you to clean up something you comitted knowingly broken, only to eventually have to excise it myself and then get bug reports when people find lingering bits I missed removing.

-mental

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. :-)