TEdit background color and gtkrc experiements (is it worth it?)

[maxerist]

Hi,
I recently met a well-known problem that gtk sometimes ignores different styling customizations for particular widgets, the posts about it can be found not only in lazarus-related communities, but many others as well. In my case it was about TEdit background color (in current Almalinux 9). I tried to play with gtkrc file for my application and nothing seemed to work except one peculiar case.

The following gtkrc file (the trick with disabling engine was borrowed from https://github.com/picoe/Eto/issues/382)

style "noengine" {
  engine "" {}
}
widget_class "*" style "noengine"

freed the TEdit from the "always while" life and started coloring it. But with caveats. So it basically became

• blue for the active state (no blue in any color-related properties of the control)
• the color from the TEdit.Color property I chose when the edit is in the inactive state.

I felt lucky because at least the chosen color reveal itself in some circumstances (inactive). So  is it worth it trying to make some additional calls for custom colors in order for it to accept the Color property as a whole? Sure I try to solve my problem, but who knows, maybe this trick will allow managing linux gtk-based controls for other cases.

Thanks

[maxerist]

Replying to myself after some experiments

It looks like the trick with disabling gtk engine is really working and helps overcome TEdit background color limitation. 
The syntax to apply it only to GtkEntry is a little modified fragment I posted earlier

style "noengine" {
  engine "" {}
}
widget_class "*.GtkEntry" style "noengine"

The different colors I mentioned previously that unexpectedly reveal after such a change is actually correspond to each of the known widget states (in lazarus constants GTK_STATE_NORMAL, GTK_STATE_ACTIVE,GTK_STATE_PRELIGHT,GTK_STATE_SELECTED). I suspect that the gtk+ developers intentionally made them different to be noticed when the engine is off but it's just a guess. The problem with lcl is that  the code only tries to affect a single state, the code fragment below shows it
(lcl\interfaces\gtk2\gtk2wsstdctrls.pp)

Code: [Select]

class procedure TGtk2WSCustomEdit.SetColor(const AWinControl: TWinControl);
var
  AWidget: PGTKWidget;
begin
  if not WSCheckHandleAllocated(AWinControl, 'SetColor') then Exit;
  AWidget := {%H-}PGtkWidget(AWinControl.Handle);
  // don't change selected state
  Gtk2WidgetSet.SetWidgetColor(AWidget, clNone, AWinControl.Color,
    [GTK_STATE_NORMAL, GTK_STYLE_BASE]);
end;
probably for some reason (the comment is very scary in this respect),but changing the set to

[GTK_STATE_NORMAL, GTK_STATE_ACTIVE,GTK_STATE_PRELIGHT,GTK_STATE_SELECTED, GTK_STYLE_BASE] allows TEdit fully obey the color set. Also the same can be achieved by creating a style in gtkrc file when all four base colors are chosen, but this will be applied to all edits in the project. 

The first trick (with engine disabling and patching) was used in my project with plenty of light on dark edits and it works at least for now.

But I should mention that for controls that has clNone for Color the rainbow effect of noengine colors will be persistent since TGtk2WidgetSet.SetWidgetColor just ignores calling gtk routines in this case. When engine is on, the default theme colors working so no negative visible change exist. In my case I was sure that no default color edits exist in the project so this wasn't a problem


I noticed that TComboBox with editable field seems like also behaves similar to TEdit and the code about setting color also lacks three other states. This fix seems like also working, but I didn't test it carefully. But there's another problem with TComboBox. This time the TComboBox in drop down only mode (without editable field) doesn't listen to background color changes no matter what. I thought that it may be due to the fact that GTK_STYLE_BASE also passed unconditionally so gtk_widget_modify_base is called instead of (more logical) gtk_widget_modify_bg, but this change didn't help. Googling probably shows different examples of "always gray" combobox, but I'm not sure

[MarkMLl]

Even if nobody's commenting, that doesn't mean that nobody's reading :-)

MarkMLl