Multicolumn combobox [SOLVED]

[wp]

I spent a long time today on installing Ubuntu 16.04, 18.04 and 20.10 in virtual machines, and now I can verify the issue and understand what you mean. Unfortunately, the problem is extremely difficult to solve because there are other Linux distributions where the issue does not occur (all having the same widgetset gtk2).

Since the Ubuntu 16.04 and 18.04 situation of black text on black background is not acceptable, I decided to activate the background painting again. By default, the background color is clWindow, the text color is clWindowText, and the selected colors are clHighlight and clHightlightText. In these Ubuntus, this means: black text on white background, opposite to the behaviour of the standard non-customdrawn combobox. I cannot get consistent appearence of both. However, there is no reason why the user should not be able to change the background and text colors. So, in order to get consistent appearance you can change the default background and text colors by the standard properties Color and Font.Color, and I added new properties SelectedColor and SelectedTextColor for the selected items.

Please test this. If it works I can also modify the TColorBox in the same way. I will not touch the standard TCombobox, however, because this is drawn by the widgetset, and I do not have much experience in this field.

[Sieben]

Thanks for looking into this once more, and glad that you can verify it now. I agree that this issue is weird and difficult, and mixing bright and dark (it's not actually black btw but the color of clWindowText, or clMenu) backgrounds on certain desktops might not have been a really good idea in the first place. But:

In these Ubuntus, this means: black text on white background, opposite to the behaviour of the standard non-customdrawn combobox. I cannot get consistent appearence of both.

if by 'consistent appearance of both' you mean dark text on a bright background for combo dropdowns as well that would be sort of a 'violation' of the look of the these desktops. I think the combo drawn by the widgetset (non-ownerdrawn styles) should be the goal here.

I will not touch the standard TCombobox, however, because this is drawn by the widgetset, and I do not have much experience in this field.

It's only drawn by the widgetset with csSimple and csDropDown/List (where the bug doesn't show), but with ownerdrawn styles it is drawn by LMDrawListItem / DrawItem (and exposes the same dark text on dark bg bug as eg TColorBox).

Please test this.

Just downloaded r7943 and will do...

[wp]

I think the combo drawn by the widgetset (non-ownerdrawn styles) should be the goal here.

Surely. But this is not possible here without breaking the control in those cases where the issue does not occur. The ownerdrawn styles are based on the color pairs clWindow/clWindowText and clHighlight/clHighlightText. Put two TShape controls on a form and set the Brush.Color of the first one to clWindow and that of the other one to clWindowText. You'll see in Ubuntu 16.04 and 18.04 that clWindow is bright, and clWindowText is dark - just the opposite as used by the standard comboboxes. So, Ubuntu 16.04/18.04 paint the combobox background with clWindowText and write the text with clWindow. Flipping the colors in DrawText would fix the issue is Ubuntu 16.04/18.04, but introduce the same issue in all (?) the other Linuxes and even in Windows, macOS, qt etc.

[Sieben]

I'm aware of that. But would explicitely setting color values to SelectedText and SelectedTextColor otoh have a similar effect in breaking the 'corporate identity' of these desktops? Or force you to include setting facilities for these in all your apps to keep it?

As I said earlier I think it should be possible to somehow detect the 'brightness' of the background that is (going to be) painted and to decide on the text color accordingly.

[Sieben]

I did a bit of testing now and I'm afraid it doesn't really help with my desktop here. The appearance is exactly the same as with r7939 and I can't get it to look like any other combo on this desktop with those new properties. It would need sth like DroppedDownNonSelectedItemTextColor and no painting of the background as this is already 'prepainted' when DrawItem is entered and thus this FillRect:

Code: Pascal  [Select][+][-]

1. if not (odBackgroundPainted in State) then
2.   Canvas.FillRect(ARect);

(from InternalDrawItem again) will not execute while Canvas.Brush.Color at this moment is indeed clWindow. You can however obtain the actual color of the background by Canvas.Pixels[x,y] or Canvas.Colors(x,y) - but being a noob in graphics I don't know how to compare this to clWindowText. None of the conversion procs from Graphics unit I tried so far does seem to be of much help here.

[winni]

Hi!

Whatever you try to do with the system colors - they are often the source of trouble.

Convert them to real RGB values of a TColor. That's easy:

Code: Pascal  [Select][+][-]

1. Var C, syscol : TColor
2. ...
3.  c := ColorToRGB(syscol);
4.  

Now you can compare them, invert them - whatever you like.
Now the 4th byte is unused and you got BGR (!!)

Winni

[wp]

There should be a third color, at least for text in the non-dropped case which is black again... What a nonsense, to fix a broken desktop theme! I am giving up.

[Sieben]

I don't... Winni, unfortunately this doesn't work either:

Code: Pascal  [Select][+][-]

1. ColorToRGB(Canvas.Pixels[1,1]) = ColorToRGB(Canvas.Font.Color)

   

returns False although they are apparently the same. Is there a method to somehow check for 'brightness' with standard Lazarus units...?

[winni]

Hi Sieben!

No. Delphi/Lazarus are poor with colors.
They are treating just RGB colors and those awful system colors.
The alpha channel was - and still is - forgotten.

Brightness (and hue, saturation, gamma .....) are only available with graphic libraries like BGRAbitmap.

But you can do simply this as TColor is nothing but a longint:

Code: Pascal  [Select][+][-]

1. showMessage (IntToHex (ColorToRGB(Canvas.Pixels[1,1]) , 8) + ' / ' +
2.                          IntToHex(ColorToRGB(Canvas.Font.Color), 8)   );
3.  

This should show you the two hex color in the order
ZeroZeroBBGGRR

Maybe that helps you.

Winni


 

[winni]

Hi Sieben!

There is the strange unit GraphUtil.
Maybe that helps you.
If you don't want to dive deep in a graphic library.

a) It breaks the identifier name.

Allways used is Hue-Saturation-Lightness.
They name it HLS.  So take care with the wrong order of the parameters.

b) They use the HSL values as byte.
Default is that they are treated as word.

Code: Pascal  [Select][+][-]

1. procedure RGBtoHLS(const R, G, B: Byte; out H, L, S: Byte);
2. procedure HLStoRGB(const H, L, S: Byte; out R, G, B: Byte);
3.  

If you don't want to be very exact you can convert the TColor to R G B bytes.
Then convert R G B bytes to H L S bytes.
Change  the Lightness. Perhaps also the saturation.
Convert H S L back to R G B   bytes.
Convert the R G B byes back to TColor.

Put  that into one function where you change the lightness with a percentage. That is the easiest way.

Winni

[Sieben]

Thanks, will play around with that a bit...