Bug in the Select Color dialogue

Post here for help on using FreeCAD's graphical user interface (GUI).
Forum rules
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help

Also, be nice to others! Read the FreeCAD code of conduct!
Batucada
Posts: 213
Joined: Mon Jul 18, 2022 9:03 am

Bug in the Select Color dialogue

Post by Batucada »

The color selection dialogue contains a bug, actually there are two bugs, but they are obviously based on the same faulty mechanism. The occurrence of the bug depends on the selected language. In the setting for English the bug is not visible, but in the setting for German and various other languages. In the German setting, the box is widened by about 80 pixels compared to the English setting. This creates free spaces to the right of the color palettes, which are marked with dashed rectangles in the second illustration. These marked areas react to MouseDown-Events, which leads to a faulty reaction of the dialogue, in which the presettings taken over when opening the dialogue are destroyed - see Farbauswahl deutsch (2). This error is obstructive and irritating.

Eliminating this error is also important because otherwise it leads to the unintended reaction when changing the application focus.
.
Farbauswahl englisch.png
Farbauswahl englisch.png (107.11 KiB) Viewed 1068 times
.
Farbauswahl deutsch (1).png
Farbauswahl deutsch (1).png (119.71 KiB) Viewed 1068 times
.
Farbauswahl deutsch (2).png
Farbauswahl deutsch (2).png (114.65 KiB) Viewed 1068 times
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Bug in the Select Color dialogue

Post by adrianinsaval »

the widening evidently happens due to the ridiculously long translation for the "Add to custom colors" button, if you can think of a shorter translation for this please propose it on the crowdin page for freecad.
Batucada wrote: Sun Aug 07, 2022 10:31 am These marked areas react to MouseDown-Events, which leads to a faulty reaction of the dialogue, in which the presettings taken over when opening the dialogue are destroyed - see Farbauswahl deutsch (2)
Can you explain this part better? I don't understand what you are describing.
Batucada
Posts: 213
Joined: Mon Jul 18, 2022 9:03 am

Re: Bug in the Select Color dialogue

Post by Batucada »

adrianinsaval wrote: Sun Aug 07, 2022 11:38 pm the widening evidently happens due to the ridiculously long translation for the "Add to custom colors" button, if you can think of a shorter translation for this please propose it on the crowdin page for freecad.
Well, the translation may require further discussion, but it is not an accurate explanation for the bug in the event filter of the dialogue, it is merely a reason why the latently existing bug became visible. BTW for "Add to Custom Color" could be used in German "Vorzugsfarbe ergänzen".
Batucada wrote: Sun Aug 07, 2022 10:31 am These marked areas react to MouseDown-Events, which leads to a faulty reaction of the dialogue, in which the presettings taken over when opening the dialogue are destroyed - see Farbauswahl deutsch (2)
Can you explain this part better? I don't understand what you are describing.
I don't know exactly how the palettes in the event filter are handled in the existing implementation, so my explanations are only conjecture. It seems to me that the size of an area is also calculated here that is supposed to cover the area of the palettes. This area is obviously used to recognise the MousDown event when the palette is under the mouse pointer. This can be done if you like, but actually the performance of the QPalette lib should be sufficient. In any case, it is certain that the width and length of the palettes can never change by adapting to the local language. The additional calculation at runtime is therefore unnecessary, because this area results from the parameterisation of the palettes, which has long been determined at the time of the design of the dialogue - there is no change at runtime.

In the current implementation, it obviously boils down to the fact that in addition to the areas that are actually occupied by the palettes, another area to the right of it is considered a palette area, but this is erroneous because the width and length of a palette will never change at runtime. However, a MousDown event in this area to the right of the palettes is recognised by the event filter as belonging to a palette, but the QPalette-Lib cannot deliver a result, since there is no palette under the mouse pointer at this time. As a result, all previously existing presettings of the RGB values are destroyed.
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Bug in the Select Color dialogue

Post by adrianinsaval »

Ok so when you click there the color is set to #ffffff, that's the symptom right? This dialog is probably just inherited from qt so I don't know if there's anything we can do on the FreeCAD side to fix the underlying bug so IMO the best course is to change the translation to something shorter.

Also, please follow the guidelines in the big red banner above and post your full freecad info, since this might be a bug in qt itself the version of qt that you are running is relevant.
Batucada
Posts: 213
Joined: Mon Jul 18, 2022 9:03 am

Re: Bug in the Select Color dialogue

Post by Batucada »

No, I don't think this is a heritage of qt. It would not make sense to assume that it is. The function of the palette as such has no error, it works perfectly. No matter with which width the dialogue window is opened according to the set language. The "sensitive" width always has the same extension as the width of the underlying button for the custom colour, and this is obviously calculated for the text extension of the buttons. Qt always calculates the palette according to the specifications in the parameters for the rows and the columns, qt does this on its own and it is independent of the width of the button.

Since not only palette elements are used in the dialogue but also other system elements that have nothing to do with each other in normal life, a specific event filter must be present at some point. But since this is not a purely Apple event because of the cross-platform, I lack deeper insights into the details. Do you have a hint for me, which files come into question for this area? I would then look and try to understand the system behind it.

Code: Select all

OS: macOS 10.16
Word size of FreeCAD: 64-bit
Version: 0.20.29177 (Git)
Build type: Release
Branch: (HEAD detached at 0.20)
Hash: 68e337670e227889217652ddac593c93b5e8dc94
Python 3.9.13, Qt 5.12.9, Coin 4.0.0, Vtk 9.1.0, OCC 7.5.3
Locale: C/Default (C)
Installed mods: 
  * Assembly4 0.12.3
User avatar
adrianinsaval
Veteran
Posts: 5541
Joined: Thu Apr 05, 2018 5:15 pm

Re: Bug in the Select Color dialogue

Post by adrianinsaval »

qt provides a full dialog just like that: https://doc.qt.io/qt-5/qcolordialog.html#details so I don't know why you say it doesn't make sense, IMO it wouldn't make sense for FreeCAD to implement it's own dialog. And from what I can see in at least one instance it is just called as is without setting any additional event filters: https://github.com/FreeCAD/FreeCAD/blob ... s.cpp#L234
I don't expect other instances in the code would be different. Is this bug present in ay color dialog opened inside FreeCAD or is it specific to some of them?
User avatar
mfro
Posts: 663
Joined: Sat Sep 23, 2017 8:15 am

Re: Bug in the Select Color dialogue

Post by mfro »

Batucada wrote: Mon Aug 08, 2022 1:40 pm No, I don't think this is a heritage of qt.
It is.

The ColorDialog is a basic QColorDialog. The fact that the open space between the base colors and the color spectrum selector is selectable (and screws up the settings if it is selected) is Qt's fault.

If you want to blame FreeCAD, its fault is certainly the length of the translated strings that makes Qt's one apparent.
Cheers,
Markus
Batucada
Posts: 213
Joined: Mon Jul 18, 2022 9:03 am

Re: Bug in the Select Color dialogue

Post by Batucada »

adrianinsaval wrote: Mon Aug 08, 2022 2:43 pm qt provides a full dialog just like that: https://doc.qt.io/qt-5/qcolordialog.html#details so I don't know why you say it doesn't make sense, IMO it wouldn't make sense for FreeCAD to implement it's own dialog. And from what I can see in at least one instance it is just called as is without setting any additional event filters: https://github.com/FreeCAD/FreeCAD/blob ... s.cpp#L234
I don't expect other instances in the code would be different. Is this bug present in ay color dialog opened inside FreeCAD or is it specific to some of them?
OK, from the point of view of this information, you are absolutely right. As I said at the beginning of the thread, I have very little information about Qt. I only looked into QPalette a bit more because I know Apple's earlier Palette lib from before OSX quite well. What is surprising for me is the complete color diologue of Qt, which I did not expect. This naturally leads to the conclusion that there is not much left to do for FreeCAD, namely nothing at all.

But for the fact that Qt boasts of worldwide business, the product does not shine enough. Thanks to the reference to the detailed description of the Qt-Color dialogue, I first got to know the full range of functions of the lib. Now that I have a better understanding of this lib, the thread should be closed at this point. The troubleshooting is thus in the hands of Qt. And yes, the bug has occurred on all calls to the dialogue so far. There are still side effects, but they are not part of the topic of this thread.

It was nice to have discussed with you, which has greatly improved my understanding of FreeCAD internals.
Batucada
Posts: 213
Joined: Mon Jul 18, 2022 9:03 am

Re: Bug in the Select Color dialogue

Post by Batucada »

mfro wrote: Mon Aug 08, 2022 5:44 pm If you want to blame FreeCAD, ....
Please don't talk like that, it is not my intention. I am honestly trying to work on improvements for FreeCAD.
For me, it is a learning process that my knowledge of Apple's and Microsoft's GUI, which goes back 20 years, is no longer valid today in times of cross-platforms. Is that really the case? Or are the cross-platforms not so good after all? I actually only wanted to be a user, that's why I came to FreeCad. Perhaps the call to "stop whining, start coding!" that was held out to me should be reconsidered after all.
User avatar
mfro
Posts: 663
Joined: Sat Sep 23, 2017 8:15 am

Re: Bug in the Select Color dialogue

Post by mfro »

Batucada wrote: Mon Aug 08, 2022 6:32 pm
mfro wrote: Mon Aug 08, 2022 5:44 pm If you want to blame FreeCAD, ....
Please don't talk like that, it is not my intention. I am honestly trying to work on improvements for FreeCAD.
For me, it is a learning process that my knowledge of Apple's and Microsoft's GUI, which goes back 20 years, is no longer valid today in times of cross-platforms. Is that really the case? Or are the cross-platforms not so good after all? I actually only wanted to be a user, that's why I came to FreeCad. Perhaps the call to "stop whining, start coding!" that was held out to me should be reconsidered after all.
Apologies, I didn't want to blame you for anything. Sloppy speech, nothing else.
Cheers,
Markus
Post Reply