Lazarus
Programming => Graphics and Multimedia => Graphics => Topic started by: polpero on August 19, 2015, 01:01:58 pm
-
Hi
Has anyone experimented with TColorPalette?
I'm looking for examples of picking a color on the palette, adding colors, saving and loading a palette etc...
I'm on windows8 but it shouldn't matter here it think
thanks!
-
http://wiki.lazarus.freepascal.org/ColorPalette
-
yes i know this page
thanks
but it's not really an example
those lines are also in the source code of the component
and couldn't serve as usage example as asked previously
thanks anyway
-
... adding colors, saving and loading a palette etc...
I've never used that component, but looking at the code, you load a new palette by calling LoadPalette(AFilename). Custom palette colours are defined in an external file [I think that's a strange design choice]. The code supplies such an example in the file default.pal. Hope that helps.
-
I added a demo project showing the main usage of the component. Since, as Graeme mentioned, defining colors by means of a file is really not the most versatile way I added two methods, "AddColor(AColor: TColor)" and "DeleteColor(AIndex: Integer") as well as a property "ColorCount" for better handling of the colors. There is a new method "SavePalette" for writing the modified palette to a file compatible with "LoadPalette". Finally, there is also a new "ColumnCount" property.
All these new features are covered in the demo as well. You'll need svn to get access to these changes in TColorPalette (r4275).
I hope the original author of the component does not object against me hijacking his project in CCR, but his last contributions in the forum date back to 2008, and therefore I thought a standard bug report would just be a waist of time.
-
Exactly...
those is where the points i was addressing (adding col, loading and saving palette, colors count)
thanks i'll have a look at your demo
-
wp
Thanks for the demo
i've been exploring and updating it a bit...
using a curColorIndex integer, i added a few utilities
- delete colors[curIndex]
- edit curcolor
- update palette
- and a TShape showing the pickedColor
I wonder if that colorIndex shoudn't be at the component's level ?
any way the new demo is here as attachment (PaletteDemo.zip)
-
One thing is confusing with the component: If I press the left mouse button down and move the mouse by a few pixels (as it can easily happen) then the ColorPick event does not fire. This is because in "MouseUp" there is a check against the original mouse-down position. This seems to be necessary because the picked color is calculated in "MouseDown", and it would be confusing if the user moves the mouse into a neighboring square and does not get the color underneath the mouse at mouse-up.
To me personally, this behavior is a bit confusing. The component would feel more practical if the ColorPick would occur at "MouseDown"; in MouseMove, there could be code to track the PickedColor.
To keep the old behavior I could add a new enumerated property, something like "PickEvent": TPickEvent = (peMouseDown, peMouseMove, peMouseUp). The current behavior corresponds to peMouseDown which should be the default to avoid breaking existing projects. peMousedown would allow dragging the mouse across the palette - the color box in your demo would immediately respond while dragging. peMouseUp picks the color from the position where the mouse button is released.
Polpero, since you seem to be the only person working with the TColorPalette, what is your opinion?
-
wp
Your suggestion looks good.
It doesn't seem to break what is already there
and might help using popupmenus
(i had trouble trying to put the updatePalette in it
as it erased the previous editColor operation )
-
There's a new version in svn with new properties "PickMode" and "PickShift":
PickMode:
- pmDefault (default value): current behavior, i.e. color is selected from the square in which MouseDown occurs, but the OnPickColor event fires later when the mouse is released, but only if this happens at the same location.
- pmImproved: color is selected at MouseDown, and OnPickColor fires also at this time; location can be different
- pmContinuous: color selection and event generation occur while the mouse button is down; the mouse can be dragged.
PickShift:
a set with the TShiftState elements ssLeft, ssRight and ssMiddle to define the mouse buttons to which the ColorPalette reacts. Default is ssLeft. If a context menu is used like in the demo then it is advantageous to add ssRight to the set as well.
@polpero: I uploaded your modified demo.
-
A couple of new changes:
- The component does bookkeeping of the selected color index itself now (property SelectedIndex), no need for a "curIndex" in the application any more.
- OnColorPick has been reverted to no longer check for the correct shift state, and behaves now just like in the original version again.
- New event OnSelectColor which is the same as OnColorPick, but checks whether the shiftstate matches on of the TPickShift states.
- Popup hints showing information on the color over which the mouse hovers.
-
Great!
I'm working on implementing three other properties
reading your code i thought i'd be better to share before:
i want a fShowGrid (boolean) property
which when true activates fGridColor (TColor) the grid color
and fGridWidth (integer) the canvas.pen.size
what do you think of it?
what confuses me a bit is your insertion of
if FShowSelection and (FSelectedIndex = I) in the Paint event, that seem to take the place i thought for if fShowGrid...
what do you think?
-
With "grid" you mean the border of the color boxes? This is currently on. To turn it off we could replace in the Paint method the "Canvas.Rectangle" by a "Canvas.FillRect" which does not paint the border. The color and line width of the border are determined by the pen of the canvas - normally they are "clBlack" and "1". If the currently selected color is drawn (that's the "if" you mention) then I though it would be good to increase the line width to 3 and to select a high-contrast opposite color - white border for "dark" colors, black border for "bright" colors.
Or do you want a gap between the boxes, like in Delphi's TColorGrid? In this case, it would also be possible to paint a sunken 3d frame around the color boxes. But how to highlight the selected color? By means of a raised box?
-
Yes
the grid is the boxe's borders...
in the test i've done i painted all in fill rect to wich a rect was over 'drawn' when grid was on... I effectively think it more as a gap (especially when grid is off) ... see attachment
i wasn't too much concerned about the selected box. Although i'd prefer the 'flat' look, it could be an option... The "focusCell" would really stand out in the gridless mode...
-
Now with BorderColor and BorderWidth.
-
Very nice!
I see that i really didn't need the showGrid variable.
PickMode is a little annoying in default mode in regard to the response on the colorSample shape. It won't pick the color when mouse moves between mouse Down and Up
Your selection frame is great.
Do you think that adding a color sniffer implies many lines of code?
it could show it's color in the colorSample and an addSniffedColor btn would add it to the palette... What do you think?
I've got also a webPalette, made of webSafeColors (named colors) ...
Do you think adding it as another default palette would be a good idea?
-
I'm currently working at providing built-in palettes: the 16 Delphi standard colors, plus (optionally) the 4 extra Delphi colors, plus (optionally) the system colors, plus (optionally) the color gradient in "Default.pal". A "websafe" palette would fit in very nicely. Adding color names would require some restructuring because the color names have to be combined with the rgb color values.
I think it is not a good idea to pack a color picker into the component because it would be useful for other color pickers as well, or it could do a fine job as a standalone component. It would require just a few lines of code to transfer the picked color to the ComponentPalette.
-
Good... built-in palettes was exactly what i was thinking of.
I don't know if this could help you (if it's not too messy...), i assembled it a decade or more ago (see attachment)
Would you have a hint (or an example) on the color sniffer?
-
Where is this unit from? What is its license?
-
no unit
just a library... i couldn't remember where i found the source...
I was working with Delphi3 and mwSynEdit, at that time...
I found the colorNames (aren't they public?) and rearranged it all to fit my needs...
It is actually part of my HTMEdit editor: polpero.ca/tools/HTMed5.zip which i am slowly porting to Laz.
-
Got the palettes in now. See property "PaletteKind". The gradient palette is furthermore controlled by "GradientSteps" - a bit confusing, but I did not find a better name: Each gradient row has a "root" color in the middle and begins at clWhite and ends before clBlack; there are "GradientSteps" boxes between the root color and the begin/end of the bar, plus the root color box itself, i.e. in total, there are GradientSteps*2+1 boxes in a row.
I added two "websafe" palettes. The first one is from the wikipedia article (https://en.wikipedia.org/wiki/Web_colors#Color_table (https://en.wikipedia.org/wiki/Web_colors#Color_table)) because there is a simple algorithm to construct it. The second one is the series of colors defined in your previously posted unit. In the latter case the colors are in the order corresponding to the color names that you have in that unit as well. The palette looks a bit scattered, it would be better to have the colors sorted per hue. I see in your unit that you added an "Index" to the TWebColor objects, but I get the impression that this is just the index in the color name array.
How important are the color names? They require some restructuring of the color list to store the strings along with the colors. But the main reason why I am a bit hesistant is that the color names are very close to the user interface, and this would mean that they should be translatable strings, and this opens another box of things to do...
PickMode is a little annoying in default mode in regard to the response on the colorSample shape. It won't pick the color when mouse moves between mouse Down and Up
Yes, I think it is annoying too, and this is the reason why I implemented the other modes. But that's the way the component had been working before I touched it. I don't know how many people have used it. If I change this default behavior I will break their code. But let me think about it a bit: There is a wiki page where I could document the changed behavior.
-
Would you have a hint (or an example) on the color sniffer?
http://forum.lazarus.freepascal.org/index.php?topic=23016.0 (http://forum.lazarus.freepascal.org/index.php?topic=23016.0)
-
I love the gradient palettes...
it looks real good with 8 steps and over...
I've been doing some thinking...
NAMED COLORS
The color names are more useful than the colors themselves... I mean that they offer a better memorization system. Those names get remembered more easily, that's why i keep them... and probably out of habit... Later on, on the process of refining a web page design, those named colors may be replaced by subtler shades and non-named colors but the names prove handy for quick reference... So on that plane, the palette is used rather as a memorization device to help remember and learn the names, making it possible to gradually type the names without consulting the palette...
I do not think that those colors are meant to be sorted in their alphabetical names order. (too scattered as you said). On that level they are just names with no valuable link to the color's hue progression. I've attached two sorted colors palettes, one from the wikipedia page ( thanks, this was a useful ref.) and the other is my own sorting (from uWebCol unit) as i've been using in the HTMLEditor. If you open the palette file you will see that i've apposed to each rgb color line the color's name, which could give an idea of how to retrieve it later for providing the selected colors information...
SAFE COLORS
I should not confuse safe colors with named colors. I understand that they are two different systems. So the palette should probably be named accordingly?
THTMLColorPalette?
Maybe the TColorPalette should remain simple and serve as a base component for a HTMLColorPalette? Since NamedColors are not new colors, only a semantic layer added to the assigned color... This way, access to colors' names and/or HexValues would be separated and (eventually, for named colors) easily accessible for localization although i haven't heard that they were translated yet...
TColorPalette as a base component could also be accompanied by a PaletteMaker to produce custom palettes. It could offer a RGB editor, drag and drop fonctionalities between 2 palettes (the referenced one and one on the making), aPalette manager where could be moved ranges from one palette to the other... Custom palettes could be used as Themes...
-
Colors are named now. In the palette file, just add the color name to the line with the three rgb values, separated by a space. No hash character like in your files - this is reserved for comments (which do not need to start at the first character now) - see attachment. The method "AddColor" supports an optional second parameter to specify the color name. If the color name is empty then the color names of the graphics uinit are used as a replacement.
In the long term, we should try to extend the graphics unit with "web colors"; this would also solve localization.
I also replaced the built-in "pkWebSafePalette2" by a "pkHTMLPalette" which corresponds to the "WikipediaSort.pas" of your recent attachment.
The default of the PickMode is pmImmediate now, which is much more comfortable. The change is documented in the wiki page which was greatly extended to describe the recent changes (not finished yet). An offline version of the wiki page is included in the distribution.
Once activities have settled here I will upload a "release" zip file to sourceforge, version will be increased to 0.2
-
much thanks
very fine and inspiring work
I had this question...
Wouldn't a more condensed form (using only 2 lines) be appropriate in the hints message?
something like:
aColor
rgb(0,0,0) (all on one line)
but i think that your custom hintText is exactly for this purpose right? (I like it)
/////
i've got an issue with colorName on mouseMove...
Let's say i've got a previewShape that shows the mouseMove color changes
and a previewLabel that should show the associate namedColor...
(The previewShape is larger than the colorBox and acts as a ZoomIn field)
Could there be an access to the the named color on mouse move
or a curIndex that would be different from the selectedIndex to get access to colorNames[curIndex];
This index is already defined in the mouseMove procedure but is not public...
An other method would be to capture the colorPalette's hint
(previewLabel.caption := colorPalette.hint
but what if we do not want to showColorHints?
Once again
Thanks for everything
a very nice evolution
-
There's now a "MouseIndex" and a "MouseColor", good for OnMouseMove event handler and some kind of "MouseOver" color panel (see second color display box in the demo).
I re-thought the names of the "BorderColor" and "BorderWidth" properties and found them a bit confusing. "BorderWidth" is now called "ButtonDistance". "BorderColor" was renamed to "ButtonBorderColor" and acts as a thin border line around the color buttons; use "clNone" to hide it. The gap between the buttons, instead, is colorized by the components standard "Color"; again, use "clNone" to skip the background color.
-
I'm still wondering if it's right to include the NamedColorsPalette in the built-in palettes.
If we take an overall look at all of them it really stands out as an exception. Demanding modification to the general structure design by it's unique names property. Should an exception rule over the design of such a structure? Wouldn't it be more sensible to have a HTMLPalette class inherit prom the TColorPalette? The funtionalities would all be there without overcharging the base component?
Tell me what you think.
I'll have a look at the latest update.
-
The named palette got into TColorPalette rather naturally because the internal list which stores the colors was changed from a TList to a TStringList. Therefore, there is automatic storage for the color names along with the color values, and this is the reason why that change could be done so easily. However, except for the pkHTMLPalette, no strings are passed as color names because the corresponding colors are either known by the graphics unit which allows to extract their names by calling ColorToString(), or I don't know any good color names as in the case of the pkGradientPalette. But the user of the component has the possibility to add the color names (ColorPalette.ColorNames:= 'something').
Going through an inherited component, however, would make things more complicated (because a TStringList cannot inherit from a TList), and nobody would understand why there are two such similar components on the component palette.
-
Yes, i get your point... and since everything seems like flowing quite naturally i'll get used to it (although i still see that list as a stranger)
There's something wrong in the demo.
The mouse colors are ok, That Panel does exactly the job i had in mind but.. .the names don't folllow... can you confirm?
-
Fixed in r4290
-
hmmm...
Did something happen to the selection rect?
The line looks thicker than it was before...
And couldn't we have a fixed color?
-
Yes, I changed the selection rect. It is 3 pixels wide now and has the opposite color of the color button. The 1-pixel wide border was not always seen very well. Using a fixed selection color is not very safe because it may have a color too close to the button.
-
well...
i prefered it before
i find it a bit ... aggressive
has too much importance on a 1px distance
with a clForm buttonColor
but this is personal taste i admit
everything seems to work good
-
There was a 1-pixel calculation error which became quite evident for the 1-pixel button distance. Fixed. Maybe better now?
-
hmm... not really...
maybe we could have a fSelectionType of [fSNone, fSLight, fSMedium and fSHeavy]
where fSNone with a 0px width would replace fShowSelection := false?
-
Done in r4293 (with modifications). Added also SelectionColor (which is ignored if SelectionKind is pskThinInverted or pskThickInverted - ok not quite: SelectionColor is used also for SelectionKind=pskThinInverted if the inverted color matches the bordercolor).
-
Now with optional vertical orientation of the palette. New demo showing the ColorPalette in a toolbar.
-
Hey... that last demo is pretty cool!
but
shouldn't the palette, on Flip,
be extended to all it's length?
(i only get a 3x3 grid)
-
Going back and forth...
When writing the Toolbar demo I realized that it would be quite useful to know which mouse button had clicked on a color button. This is exactly what the old OnMousePick was designed for - and I had deprecated this event!
Therefore, the recent commits were rather destructive: I removed the OnSelectColor event to fully bring back the OnMousePick, replaced the SelectedColor and SelectedIndex by the PickedColor and PickedIndex. Also, the "PickShift" property is no longer needed.
And I saw that the form is not notified when the mouse leaves the entire colorpalette - now the OnColorMouseMoveEvent fires at this moment. And I saw that I had introduced an incompatible change into the emitting ColorMouseMove procedure because I had fired the event had only when the mouse had entered a different tile of the palette. Now, as in the original version, the OnColorMouseMove fires with every mouse movement. Although the standard OnMouseMove event can be used for tracking the mouse color as well I'd prefer to use the OnColorMouseMove because then the MouseLeave is handled correctly.
but
shouldn't the palette, on Flip,
be extended to all it's length?
(i only get a 3x3 grid)
Yes, it is fixed now. Working with Coolbars is still a pain (but 1000x better than in Delphi)...
-
Therefore, the recent commits were rather destructive
hmm... that's bad :(
but it explains a few annoying messages on compiling
...
Since we're still in the process of going back and forth :) what would you think of changing the TPaletteSelectionKind to: "none, thin, normal, thick" and of modifying the selection color to fixed or auto ? Auto being the inverted colors... I'm still looking for the right calibration here... what do you think?
On the subject of questioning, why is it that we need a mouseColorMove and a MouseMove? Since we are here in a colorPalette, isn't it self-descriptive that the mouseMoves will be mouseColorMoves? ... just trying to simplify...
Finally
i'm working on a merge of my former colorpalette to this one and am preparing a new demo. I'm not ready to send it right away, i need a few hours more... but in the process i've got an issue on loading and saving that you might be simplify. If i show you the code you'll probably understand immediatly so here are the saving and loading procedures:
procedure TmainForm.doSavePalFile;
var pStr, fName, tmp: string;
i: word;
outFile: tStringList;
begin
try
outFile := tStringList.create;
with colPalet do
begin
fName := mainPath+'tmp.pal';
savePalette(fName); //TColorPalette save
outFile.LoadFromFile(fName);
tmp := outFile.text;
// prepare properties
pStr := '# ' + PalName + #10
+ '#<PROPS>' + #10
+ '##########################################' + #10
+ '# PALETTE PROPERTIES ( Should/Could be unHashed? ) ' + #10
+ '#$BTNSIZE ' + intToStr(ButtonWidth) + #10
+ '#$BTNCOLOR ' + colorToString(ButtonBorderColor) + #10
+ '#$BTNDIST ' + intToStr(ButtonDistance) + #10
+ '#$SELKIND ' + intToStr(ord(SelectionKind)) + #10
+ '#$SELCOLOR ' + colorToString(SelectionColor) + #10
+ '#' + #10
+ '#</PROPS>'
+ #10
;
end;
finally
outFile.text := pStr + tmp ;
fName := filePath + palName;
outFile.SaveToFile(fName);
outFile.free;
FListBox.UpdateFileList;
lastFileName := fName;
end;
end; {doSavePalFile}
procedure TmainForm.doLoadPalFile(fName: string);
var pBuff: string;
inStr: TStringList;
function getValue(aKey: string):string;
var ...
begin
sKey := '#$'+aKey;
...
result := //the corresponding value
end;
end;
begin
if not fileExists(fName) then exit;
inStr := TStringList.create;
inStr.LoadFromFile(fName);
pBuff := copy(inStr.text,1,pos('#</PROPS>',inStr.text));
with ColPalet do
begin
if pBuff <> '' then
begin
ButtonWidth := strToInt(getValue('BTNSIZE'));
... etc
end;
loadPalette(fName);
EdColCount.Value := columnCount ;
end;
inStr.free;
end; {doLoadPalFile}
Could we extend the TColorPalette syntax to include a few properties? Although those procedures work well, - hidden behind the hashes could be inserted a second level of instructions that don't trouble the colorPalette - but it would be much simpler if it was integrated...
I don't think all the properties have to get there but some might be quite convenient: a palette with numerous entries might be better served with small buttons and inversely few entries better served with large buttons...
-
Sorry I missed the time while your post was "Recent"...
changing the TPaletteSelectionKind to: "none, thin, normal, thick"
"thin" is 1px, "thick" is 3px, therefore "normal" must be be 2px. Unlike the odd pixel counts, 2px is not symmetrical to the reference points, and it is not clear whether the second line will be inside or outside the shape. This, furthermore, may depend on widgetset. I do not want to go through the additional complexity of implementing the component in various widgetsets for an almost invisible additional feature.
modifying the selection color to fixed or auto ? Auto being the inverted colors...
No, this would add another property which is not needed if the selectionkinds contain this information...
Could we extend the TColorPalette syntax to include a few properties?
OK, i'll add properties to the file format. But there'll be an optional parameter "ColorsOnly" for the "LoadPalette" method because I could imagine cases where the properties embedded in the file could be disruptive to an existing layout.
-
I've been carried away by other business too...
Hey
why is it that the PaletteSelectionKind order is different in the declaration
than in the properties palette (in the explorer)?
... this would add another property which is not needed
Yeah ok...
(although it would give more unity to the enumeration
if the color aspect wasn't mixed throuth it...
but the list is short... one or the other,
it doesn't really matter)
... because I could imagine cases where the properties embedded in the file could be disruptive to an existing layout.
Example?
-
Uploaded a version in which some new keywords can be used in the palette file:
- $BTNDIST value
- $BTNWIDTH value
- $BTNHEIGHT value
- $BTNBORDER r,g,b
- $FLIPPED TRUE (or FALSE)
- $SELKIND NONE (or THIN or THICK or THIN-INV or THICK-INV)
- $SELCOLOR r,g,b
LoadPalette has a new (optional) parameter "AItems" which is a set of TPaletteItem = (piColors, piColumnCount, piFlipped, piButtonBorder, piButtonSize, piButtonDistance, piSelKind, piSelColor) to identify which parameters will be loaded. The default is [piColors, piColumnCount] as it was before; use piAll to load everything.
SavePalette writes a palette with all the properties.
Example?
Suppose I send you a palette file, I like SelectionKind piThickInverted, no button distance, you like piThin with some particular SelectionColor, and 4 pixels button distance. You would not be happy I you load my palette...
why is it that the PaletteSelectionKind order is different in the declaration
than in the properties palette (in the explorer)?
This is done by Lazarus' property editor for enumerations which sorts the enumerated elements alphabetically.
why is it that we need a mouseColorMove and a MouseMove?
Probably we don't. I got carried away because I wanted to call an existing method in the MouseExit procedure and did not want to call MouseMove - ColorMouseMove looked right. Probably I'll make them equivalent and deprecate OnMouseColorMove.
-
Uploaded a version in which some new keywords
Thanks!
I'll update my stuff here
( still working on that demo...
that was supposed to be a few hours away...)
Suppose I send you a palette file, ... You would not be happy I you load my palette...
Hmmm clever!
hadn't thought about that
(But i wouldn't be that unhappy
since i already knew about your prefs... : ) )
///////////////////////
THOUGHTS...
... on clearing...
clearColors needs a refresh should it be included?
clearColors clears the colors but leaves the buttons...
why would we want the colors gone but not the buttons?
Should we have a 'clear' procedure that clears the colors
and resets columnCount to 0?
-
clearColors needs a refresh should it be included?
In principle, yes, but who prevents you from setting ColumnCount=0 explicitly? Anyway, ClearColors by itself is rather useless - who wants to work with an empty palette? It is only an intermediate step to create a palette from code, and the layout can be created when everything is set.
-
wp
i'm having an issue with properties
they are saved to file accordingly
but aren't assigned on load
Try this loadPaletteTest (attachment)
and confirm when you can...
thanks
-
_colorPal.LoadPalette(curPal, piAll);
Also add:
procedure TmainForm.fNameEditChange(Sender: TObject);
begin
FileListBox.FileName := fNameEdit.Text;
end;
-
_colorPal.LoadPalette(curPal, piAll);
arrgh!
i forgot about this one!
(
i thought it was the default...
--still think it should be... : )
)
Thanks!
-
For those who do not work with svn: I just uploaded the current code of the ColorPalette component as zipped release version 0.2 to sourceforge (http://sourceforge.net/projects/lazarus-ccr/files/ColorPalette/ColorPalette%200.2/LazColorPalette-0.2.zip/download (http://sourceforge.net/projects/lazarus-ccr/files/ColorPalette/ColorPalette%200.2/LazColorPalette-0.2.zip/download))
-
And days became weeks...
Here is a Palette Maker Demo
it explores other usages of the TColorPalette.
There might be better ways to do what it does
feel free to suggest
-
Looks nice. But I cannot compile the demo because some units are missing (global.pas plus maybe what is used in there)
-
Sorry...
that file is not used anymore
just remove the reference to the project
here'a an update of the zip File