Color functions

[Darkoni]

I am curious - why there two Scribus scripting functions:

defineColorCMYK("name", c, m, y, k)

changeColorCMYK("name", c, m, y, k)

I think the defineColorCMYK should be enough.

Please, see it for yourself:

defineColorCMYK("name", c, m, y, k)
changeColorCMYK("name", c, m, y, k)

defineColorCMYKFloat("name", c, m, y, k)
changeColorCMYKFloat("name", c, m, y, k)

defineColorRGB("name", r, g, b)
changeColorRGB("name", r, g, b)

defineColorRGBFloat("name", r, g, b)
changeColorRGBFloat("name", r, g, b)

defineColorLab("name", L, a, b)
changeColorLab("name", L, a, b)

defineColor("name", c, m, y, k)
changeColor("name", c, m, y, k)

And we do not need defineColor and changeColor at all - as we easily could have only defineColorCMYK

At total, 7 functions that are not needed at all.

[a.l.e]

well, what about an even more extreme proposal?

Code Select Expand

defineColor("name", ...[, colorModel=None)
which would:

• create an RGB color when given three values
• create a CMYK color when given four values
• create a lab color when given three values and colorModel='lab'
• colorModel can have three values: cmyk, rgb, lab (and the color model is only automatically picked when no colorModel is specified; if there is a mismatch between the number of values and the model, an exception gets triggered).

such an implementation would be compatible with the existing function and, i think, by default do what most (or evern every) user expects.

but your proposition is also a good one (if indeed all "similar" functions do indeed the same thing)!

[Darkoni]

Why insist on an additional colorMode parameter?

The script author knows how he wants to create the color, and will call that function.

Isn't it simpler to have five functions than to call one function with an additional colorMode parameter?

defineColorCMYK("name", c, m, y, k)
defineColorCMYKFloat("name", c, m, y, k)
defineColorRGB("name", r, g, b)
defineColorRGBFloat("name", r, g, b)
defineColorLab("name", L, a, b)

against

defineColor("name", (c, m, y, k), "CMYK"      )
defineColor("name", (c, m, y, k), "CMYKFloat" )
defineColor("name", (r, g, b)   , "RGB"       )
defineColor("name", (r, g, b)   , "RGBFloat"  )
defineColor("name", (L, a, b)   , "Lab"       )

[a.l.e]

i don't insist, it's just an "extreme" idea:

Code Select Expand

defineColor("red", 255, 0, 0) # creates a rgb red
defineColor("red", 0, 92, 48, 0) # creates a cmyk red
defineColor("red", 51, 53, 71, colorModel="lab") # creates a lab color
defineColor("red", 255, 0, 0, colorModel="rgb") # creates a rgb red
defineColor("red", 0, 92, 48, 0, colorModel="cmyk") # creates a cmyk red
if you set three values, you get an rgb color.
with four values, you get a cmyk one.
and you can always specify the color model (to be clearer?), but you still need to pass the correct number of parameters.

i think that most people will use the first two version and they will be happy with what they get.

but, as i said, it's an extreme proposal and it's possible that yours is better.

[Darkoni]

Hi a.l.e

What about a float?

defineColorCMYK("name", c, m, y, k)
Defines a new color "name".
The color Value is defined via four components: c = Cyan, m = Magenta, y = Yellow and k = Black.
Color components should be in the range from 0 to 255.

defineColorCMYKFloat("name", c, m, y, k)
Defines a new color "name".
The color Value is defined via four components: c = Cyan, m = Magenta, y = Yellow and k = Black.
Color components are floating point values between 0 and 100.

[AdmFubar]

While on the subject of colors...can the color and fill window be made dock-able? Would like to see a one window to a selected set of colors and another that is for colors being used in a document, with drag and drop to add colors to you current document.

[a.l.e]

personally, i think that we should rather make it possible to add colors in the palettes, at the same place where you can pick a color.

i think that this is might be a future goal of the indigo UI project.

[a.l.e]

sorry, i did not check what the ...Float variants do.

now that i've read your explanation, i think that the name is terrible.
i (wrongly) understood that you wanted to get rid of them (i naively assumed that the "normal" function passes the values as int and the float ones as... float, numbers with decimals).

well, in my extreme proposal, we would then need a second function or a second named argument in the unique function (with a better name than "Float").

i still think that the basic form

Code Select Expand

defineColor(name, r_or_c, g_or_m, b_or_y[, k = None])
will cover most usages (since we don't have RGBA) and the named argument offer access to all previous features in a "self-documenting" way.
it would even be possible to add support for HLC colors in the scripter, without adding a new function : - )

but, as said, it's an extreme proposal and i will not fight to get it through.

[Darkoni]

And what about a hex color values, like "#ff8800" or shortly "#f80"...

[a.l.e]

for what i'm concerned, the function could also accept the case where one single parameter is given:

Code Select Expand

defineColor(name, r_c_rgb)
: - )

starting with a # and having four or seven chars...

the more i write about it, the more i start believing that it could be a nice simplification.

the problem is that currently, one has not really an overview of what is possible. you pick a function that somehow fits your need and then look for a website that converts the values you have into what you think scribus is requesting.
having a good documentation in one place might be longer to read, but at the end one should know about all the available options.

[Darkoni]

having a good documentation in one place might be longer to read, but at the end one should know about all the available options.

Even better is when you have a documentation with a list of functions that defines colors for different color modes.

From function name, user knows what function needs as parameters and what particular function does.