[Sketcher] Tweaking the Constraint label

[abdullah]

Did not try it. Looked at the code very fast. Looks good.

If I am not mistaken, with this PR, information about the solver failing while dragging will be gone. If this is undesired, I am sure Chennes will appreciate some user feedback about how this should work.

[chennes]

If I am not mistaken, with this PR, information about the solver failing while dragging will be gone.

Yes, that is true. I could switch it so that during the drag with the failed solution that string shows, instead of whatever constraints message would otherwise be showing. I don't run into the failed solution during drag very often in my CAD work, I don't feel strongly either way about which solution we choose.

[abdullah]

If I am not mistaken, with this PR, information about the solver failing while dragging will be gone.

Yes, that is true. I could switch it so that during the drag with the failed solution that string shows, instead of whatever constraints message would otherwise be showing. I don't run into the failed solution during drag very often in my CAD work, I don't feel strongly either way about which solution we choose.

For this, I think power users of the help forum have seen "everything" (and worse) and will be able to tell you what may be required. I was trying to "trigger" them, but my innuendo has obviously failed... they are so calm lately...

[chrisb]

Sorry for being a bit lazy lately, I had other things to do. I am not aware of issues concerning dragging in Sketcher.

[chennes]

@abdullah, what do you think about merging this and taking feedback once it's in the main dev branch? I think the core change is a good one, and we can always tweak the exact wording and behavior based on feedback we get going forward. And then I can use this new styleable label elsewhere where FreeCAD has hardcoded colors .

[abdullah]

@abdullah, what do you think about merging this and taking feedback once it's in the main dev branch? I think the core change is a good one, and we can always tweak the exact wording and behavior based on feedback we get going forward. And then I can use this new styleable label elsewhere where FreeCAD has hardcoded colors .

I look into it now.

@ does not work for quoting. I have just seen this.

[chennes]

@ does not work for quoting. I have just seen this.

I was not in a hurry, and you are allowed to take some days off

[abdullah]

@ does not work for quoting. I have just seen this.

I was not in a hurry, and you are allowed to take some days off

Unfortunately I had taken many days "off" this year. Never mind!

Code is ok in my view. The approval in GitHub reflects this point.

I decided to give you some time to resolve the conflict before the actual testing.

The actual testing however, in my system, appears not to follow the coded colors (royalblue, orangered, ...):

Screenshot_20211011_185409.png (31.72 KiB) Viewed 3278 times

OS: Ubuntu 20.04.3 LTS (MATE/mate)
Word size of FreeCAD: 64-bit
Version: 0.20.25943 +6 (Git) AppImage
Build type: Debug
Branch: sketcherMoveColorsToPrefs
Hash: 6858d938cc6b0899fb3e55e55d29875a203fd4fe
Python version: 3.8.10
Qt version: 5.12.8
Coin version: 4.0.0
OCC version: 7.5.2

[chennes]

There's no way of knowing that your stylesheet doesn't set those label colors: if there's a stylesheet the new label just throws up its hands and figures the author should have set something. I have not yet gone back through and added it to the built-in stylesheets.

[abdullah]

There's no way of knowing that your stylesheet doesn't set those label colors: if there's a stylesheet the new label just throws up its hands and figures the author should have set something. I have not yet gone back through and added it to the built-in stylesheets.

Yup! I read the code, so I am aware of that stylesheet wins over other preferences and defaults. What I was not aware of, is that I had selected a theme in the preferences "Dark-Green". This was causing the unwanted effect, because as you say built-in stylesheets do not have this information defined.

I am not a UI/UX person. However, I think that the meaning of these colors is important. Although I obviously want a dark theme (by my own choice), I would still like to see the default colours for these error messages. This may well reflect my personal choice/expectation. I somehow think it might be misleading to use other colours in built-in themes.

I see one clear functional exception in my primitive understanding of UI/UX. If we had built-in themes for the different types of color-blind people, then it may only make sense to choose colours that are adapted to the specific color blindness.

That said, I also understand that people designing a theme may have other goals in mind, which might collide with my primitive UI thinking. This people should probably be the ones ultimately deciding the colours, preferably taking into account what kind of information we want to convey.

As an intermediate solution until the UI/UX people decide if they want to go other path and for which specific theme, it might make sense to modify the built-in stylesheets to reflect the default colours currently used in master.

What do you think?