Re: Color palettes services...

Dave Leigh schrieb:
> 
> I may have misunderstood your intention, but if so, my reply should make it
> clear how I've misunderstood you, and you can correct me.

Well, blaim it on my problems to use the english language correctly,
missing the right terms :(

> On Sunday 14 July 2002 04:40, Friedrich W. H. Kossebau wrote:
> > Hi!
> >
> > This is just for the record, don't have any time to code it, but in
> > these days where patents are given for anything I wanted to spread this
> > idea, maybe you even would like to discuss it :):
> 
> Actually, the idea's nearly as old as color displays, so it's probably safe
> from patents. It's simply the way palettes work. The only patent you'd have
> to worry about is a application patent, and those are crap.

So say you, and do think I, but who knows... 

> Getting past the originality of it all, I sense a couple of things about what
> you're saying that go beyond regular use of a color palette. There can also
> be confusion of scope in this discussion, since "palette" could mean the
> colors assigned to the display as a whole, or simply the subset of colors
> I've chosen to use in my document or widget set. These should be discussed
> separately,

If I had not meet some old unix machines at university I would not have
understood what you are talking about, in the times of true color
displays ;) 

No, I was not referring at any point to the 256 (or whatever) color
display palette. When I talked about widget colors I thought of the
colors you can assign in KDE's control center, the "real" colors. 

Think of color palettes used in Gimp, in the KDE Color selection dialog,
whereever.

> It doesn't do to change the palette in an attempt to "spread this
> information... to already created documents." because unless the palette's
> absolute values are included in the document, MY palette isn't YOUR palette.
> You'd STILL have to edit every doc to "spread the information." A palette
> (meaning color references, as opposed to a table of colors actually used)
> gives you no benefit over, say, searching for "#FFFFFF" and replacing all
> instances with "#AAAAAA". Now THAT could be done with a "color replacer" that
> could be included in any KDE app. It could even be done with an external
> applet that works on groups of files. I think this is more useful from an
> authoring standpoint because it eliminates the chance of unintended changes
> to existing work. Anybody who's worked extensively with Microsoft Word's
> paragraph styles knows exactly what I mean.
> 
> Speaking of such things... I don't think it's necessary to return both the
> palette_id and color_id. Since the whole point of a palette is to "abstract"
> the color selection, any application requestion a palette_id is not going to
> care what value is assigned to it. If you want a color_id, then actual value
> can be retrieved separately. For example, I want to change my widget colors.
> I call the color palette service, which displays the color picker dialog and
> returns a palette_id. I'm editing a document, I call the same service with a
> parameter that tells it to return the absolute value instead.

I was thinking of this: 

CASE A: You select color "company's red" of the palette "corporate
colors" to be the color of the background of a company's flyer. In the
meantime your company's stylist has to make sense to him being enganged
and presents a slightly modified corporate identity, making the
company's red a little more red. 

No need to rework your flyer (in case of colors), it would automagically
get the new red via the palette's and color's id.

Two weeks later you want to print some flyer's. But - what the heck -
the company's main server with the palette is unreachable. Now you
cannot synchronize to perhaps again modified colors. But you at least
have the color values of the last request stored so there is a default
to rely on. So _both_ palettes and color ids and the real values have to
be stored. 

Of course one should be able to cut the binding to a palette entry for
each certain setting of a color.

CASE B: You are really enthusiatic about your company and want your
widgets colors be the one of the corporate design. You open the widgets
color dialog and set each widget element to a color of the palette
"corporate colors", e.g. the text background to the color "company
white". As you want the text to be black, your company has no dark
corporate color, you select palette "kde-defaults" and select "black",
perhaps this time by value, cutting a relation to the origin. And as you
are funky for the window background you choose the color "stocks
tendency" in the dynamic palette "company's value" that (the palette)
updates hourly to set the color "stock's tendency" to show a dark color
for falling share price and a light one for a rising  =ßo) (or the color
"boss in house" or...)

Now your text color will always stay the same, the other colors
adjusting to the colors in the used palettes... 

Now got what I mean? :)

Friedrich