[maybe SOLVED] BUG in InputQuery if default colour for TForm and TPanel differ

[robert rozee]

i was recently adding an InputQuery to a project, and noticed that there was a rectangular box of slightly different colour to the left of the "OK" and "Cancel" buttons. from a previous problem i realized that these buttons must be sitting within a panel and that the panel was not correctly picking up the colour of its parent. here is a capture of the InputQuery from my project, see image at end of post.

now bear in mind, i'm running Linux, and using the GTK2 widgetset. chances are this problem will not arise under Windows.

the problem is created in the function DefaultInputDialog, which is where InputQuery finally ends up - that took quite a bit of digging to find out! DefaultInputDialog creates the two buttons at the bottom-right of the form using the following code:

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

1.     with TButtonPanel.Create(Form) do
2.     begin
3.       Top := Edit.Top + Edit.Height;
4.       Parent := Form;
5.       ShowBevel := False;
6.       ShowButtons := [pbOK, pbCancel];
7.       Align := alTop;
8.     end;

now, what is MISSING is a single line:

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

1.     with TButtonPanel.Create(Form) do
2.     begin
3.       Top := Edit.Top + Edit.Height;
4.       Parent := Form;
5.       ShowBevel := False;
6.       ShowButtons := [pbOK, pbCancel];
7.       Color:=Parent.GetDefaultColor(dctBrush);   // fix for wrong background colour
8.       Align := alTop;
9.     end;

issues around parent colour and the likes is discussed here:
https://forum.lazarus.freepascal.org/index.php/topic,69921.msg544288.html
many thanks to wp for explaining how "The color "clDefault" may be different for each control".

attached below is a sample project demonstrating the issue, and application of the fix. Button1 displays a ButtonPanel using the first set of code from above, while Button2 displays a ButtonPanel using the second set of code (with the extra line). each time you click one of the buttons another ButtonPanel is added; double-clicking on the form anywhere toggles the form's colour setting between clDefault and pale green, which may help i seeing what is going on.

i believe this fix should be applied to DefaultInputDialog and anywhere else TButtonPanel is used in creating a set of buttons on a form whose colour has been left as clDefault. i don't think the fix should be applied within TButtonPanel, as there are cases where a user may wish to retain the current behavior.


cheers,
rob   :-)

[Bart]

Shouldn't ParentColor := True do just that?

Bart

[robert rozee]

Shouldn't ParentColor := True do just that?

i've found not, as the colour of both controls is clDefault... the problem is that clDefault may mean 'different things' to different components. see wp's comments in the other thread.


cheers,
rob   :-)

[Bart]

But, ParentColor := True, should override the Color := clXXXX?
Did you try adding this instead of you fix?

Bart

[robert rozee]

But, ParentColor := True, should override the Color := clXXXX?
Did you try adding this instead of you fix?

i did, and just tried it again. the colour of the form is clDefault. the colour of the panel is clDefault. so as far as everyone is concerned, they are the same. HOWEVER, the paint routine for the form and the paint routine for the panel each retrieve the RGB meaning of clDefault from different places.

the sun is about to rise here, so i need to head off to bed before i turn to dust!


cheers,
rob   :-)

[Bart]

Maybe file a bugreport about this?

Bart

[dsiders]

But, ParentColor := True, should override the Color := clXXXX?
Did you try adding this instead of you fix?

i did, and just tried it again. the colour of the form is clDefault. the colour of the panel is clDefault. so as far as everyone is concerned, they are the same. HOWEVER, the paint routine for the form and the paint routine for the panel each retrieve the RGB meaning of clDefault from different places.

Then that must be a GTK quirk. There have the same color in QT6.

[robert rozee]

Then that must be a GTK quirk. There have the same color in QT6

i suspect it is more a product of your desktop theme.

i've modified my test program so that it now displays the RGB values for clBackground and clForm, see below for screen capture and a updates source code. it looks like all of the main Lazarus *nix widgetsets (QT, QT5, QT6, GTK2, GTK3) use clBackground as the default background colour for a TPanel, whereas the default background colour for a TForm is clForm. what i do NOT yet know is how/where a Lazarus application obtains the actual RGB colours to associate with these constants. given that different themes have different sets of colours (light themes, dark themes, halfway-inbetween themes), it stands to reason that the desktop theme manager (whatever exactly that happens to be) has to be queried by the application for the information.

i don't think it is a 'bug' as such in the choice of using clBackground instead of clForm for the background colour of a TPanel, nor do i think that the way ParentColor operates is a 'bug' either; my guess is that the behavior is the same as with Delphi. but i DO think the fact that DefaultInputDialog does not take account of the possibility of clBackground and clForm differing in the RGB colour they each resolve to is a style bug.

it would be great if a few of those reading this thread could compile the project provided and verify what i am seeing - btw, i'm running Linux Mint 22 with an XFCE desktop.


cheers,
rob   :-)

[robert rozee]

bug report raised:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41423

[robert rozee]

have tried to add this change as an edit to file /usr/share/lazarus/3.6.0/lcl/include/inputdialog.inc on GitLab, see:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/443
and
https://gitlab.com/freepascal.org/lazarus/lazarus/-/merge_requests/445

the second one is there because i think i may have accidentally broken the first one! but i'm really not sure - the whole GitLab process is entirely confusing   

i kinda expected there to be meaningful postings to the above merge request, or to the earlier issue i raised. instead, one fellow said he 'don't see this on [his] system' and pretty much left it at that, and another said "This fix does not seem to be right" with no explanation as to why he thinks this.

have i inadvertently sent my GitHub submissions to the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard”? or is it just par for the course that bug reports and fixes are ignored? if ignored, i'd be fine with that - and could then avoid wasting my time in finding/fixing bugs.


cheers,
rob   :-)

[TRon]

@robert:
For a tl;dr see https://www.youtube.com/watch?v=aRcY5do4MRw 

When posting a merge request it sometimes can take a couple of (pick your choice) minutes, hours, days, weeks, months, years or never for it to get feedback or getting accepted.

What at least should not be done is post the same MR twice. The first one seem to have landed ok (though the pipeline says it is not able to apply the changes).

The people that do respond to a MR usually do this with the best of intention. It is expected to have at least some back-ground knowledge on the matter of a MR so that you are able to interpret the/a response when given. You did not understand (which you wrote/explained, which is perfect fine) but not everyone has a schedule that allows to respond/explain.

The 'problem' with the MR as hinted by others is that it is a generic 'patch' to the issue while the issue itself seem bound to a particular widgetset, window manager and/or theme. As such it is able to impact many different configurations/setups. Hence the reservation in the answers to accept such a MR. Also known as a possible invasive MR.

[robert rozee]

when i saw the merge queue had less than two dozen items in it, i assumed that things moved along quite quickly. i guess i need to be more patient   

i'm not convinced that what i'm seeing is bound to a specific widgetset, but instead bound to a specific desktop theme - that is a theme configured outside of the widgetset. it just happens that, at the moment, most desktop themes tend to have windows and panels defaulting to the same colour. using the same colour for both would make sense for a desktop theme, but can not be guaranteed - as i have discovered.

i shall sit back and patiently wait . . . . . . . . . . . . . . .


cheers,
rob   :-)

addendum: someone has gone and removed the duplicate merge - my misdeed has been hidden!

[TRon]

Note that when you are convinced that to be the case you could try persuade others to lean towards that same conviction when there is actual (reproducible/solid) proof. Also for the opposite case of the hints warning that it might influence other platforms/widgetsets.

Sometimes it is worth it, other times you might perhaps think to yourself the heck with it I do not want to waste any more time on the topic 

You have encountered the issue, added an issue to the bugtracker, asked for help on the forums fixing it and finally added a possible fix with a MR. Sometimes that is all that you can do (it is much more than the average person is able to accomplish).

[robert rozee]

[...] ParentColor means to use the "resolved" color of the parent. Even if that is not the default of the child (in case of clDefault for the parent) [...]

all i can say is that, on the computer i am sitting in front of now, the statement "ParentColor means to use the "resolved" color of the parent" is FALSE.

ParentColor=true for a TPanel seems to mean:
1. take the numeric value of whatever the parent's Color is set to - do NOT resolve this to an RGB value, so if it is clDefault then use this value unchanged/unresolved in the next step.
2. load the panel's Color with the above (unresolved) value.

the end result - if clDefault for a TPanel happens to resolve to a different RGB colour than clDefault for a TForm, then then panel will be a different colour to the form it is sitting on.

i'm not sure how many different ways i can explain this. there is no theory involved, it is just what i am SEEING in front of me on the screen.


cheers,
rob   :-)

addendum: what happened to the posting by the Administrator, Martin_fr???

[Martin_fr]

addendum: what happened to the posting by the Administrator, Martin_fr???

A matter of the wibbly wobbly time continuum... It was based on memory of mine, which shortly after was refreshed and thereby established as false. Thus the content of the missing contribution had been less than meaningful in the context of the matter. Realisation of the fact let to dissolution of the word: I removed it.