PR #4942 new option to show/hide sketcher constraints

Post here if you have re-based and finalised code to integrate into master, which was discussed, agreed to and tested in other forums. You can also submit your PR directly on github.
User avatar
uwestoehr
Posts: 2914
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany

Re: PR #4942 new option to show/hide sketcher constraints

Post by uwestoehr »

abdullah wrote: Mon Oct 11, 2021 2:55 pm I have just merged the UI revamp of the Constraint Widget and the new Associated Constraints Filter.
Many thanks for al these improvements!

Nevertheless, I asked that you make a PR to test before you merge.
For example I use master for real-life documents because I want to benefit from your recent new features. Therefore it would really be good to have PRs to test and play with new features before they are merged.

Now I see that the dimension numbers appear upside down:
OTOjjS0PQu.gif
OTOjjS0PQu.gif (108.46 KiB) Viewed 877 times

I cannot test right now if this behavior was also with FC 0.19. I noticed it the first time today with a fresh build from 2 hours ago.
chrisb
Posts: 37776
Joined: Tue Mar 17, 2015 9:14 am

Re: PR #4942 new option to show/hide sketcher constraints

Post by chrisb »

Did you inadvertently turn the view of the sketch? Is the sketch mapped reverse?
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
abdullah
Posts: 4292
Joined: Sun May 04, 2014 3:16 pm

Re: PR #4942 new option to show/hide sketcher constraints

Post by abdullah »

uwestoehr wrote: Tue Oct 12, 2021 6:37 pm Nevertheless, I asked that you make a PR to test before you merge.
I read your request. I made my decision. I have kindly refused to follow your request, as I judged it would serve no valid purpose.

It is for you to continue insisting on such requests if you so wish, and for me to judge and decide, on a case by case basis, what is more appropriate.

On one side, I am generally against wasting resources where they are not needed, so that they are available where they are needed. This stance is unlikely to change.

On the other side, having the functionality in master allows the whole community to contribute with their ideas to polish the features. I am interested in community-wide feedback to make the functionality match the needs of our diverse community as a whole, rather than the very specific needs of a narrow amount of users. The needs of the latter need to be considered in the light of the community as a whole, as opposed to shaping the features to match the needs of the latter to the detriment of those of the community as a whole.

This is not going to change insofar as it relates to the features I code. Great ideas come from the wide spectrum of users of our community. This "whole community" principle is something I consider to be the basis of development in FreeCAD, and insofar as I have seen, all core developers in FreeCAD work this way. I can only hope peer and future developers and integrators will continue to act accordingly, so that we can keep the culture that has made FreeCAD the success it is. I would have strong issues working with peers systematically failing to abide themselves of these basic principles.

FreeCAD is not a company with a CEO blindly executing a strategy to match the target of the best paying customers, but a lively community willing to share to a common success.

Of course, as always, you are welcome to judge on the quality of my commits code-wise or functionality-wise, if you so wish. I already told you I would consider any UI improving PR from your side. I will do so in the light of the needs of the whole community as I have always done.
uwestoehr wrote: Tue Oct 12, 2021 6:37 pm For example I use master for real-life documents because I want to benefit from your recent new features. Therefore it would really be good to have PRs to test and play with new features before they are merged.
You, as many other users including myself, use master and this is great because it helps development. This may include hobbyists and corporate users. To me corporate users are not more prominent members of the community than hobbyists. Every single user is equally important to me. All deserve an stable master. None is more entitled than the other. We all are FreeCAD.

Using master allows us to have access to the latest features. We all know that using master involves risks. FreeCAD can boost of having one of the most stable masters. This, in my personal opinion, should continue being like this.

It has come to my attention that your requests target me systematically, apparently implying that "my" features break "your" master. It could be the case in the future. It has not been the case in this instance to my knowledge. I doubt you have historical claims to make.

There is a risk associated to every merge. When merging to master there is always a trade off where we try to minimize risks and maximize the use of the resources. Confidence in merging is built up on experience. I would not directly merge something with a reasonable potential to break master, but I would do a PR. The decision of what to do, on a case by case basis, lies with me. As it should not be otherwise, the consequences of a bad decision also lie with me, as I am responsible and accountable for every commit I merge, mine or as Integrator.

This very same principle is mirrored by new Integrators who feel that a given commit or PR might have consequences and request reviews by more experienced developers instead of assuming an unnecessary risk. The general idea is that they will learn from these cases and build up experience, enabling them to make better future decisions. Experience optimises the decision whether additional resources are necessary or not.

That said. You need to assess the risk you are willing to take when using master for your (corporate) work. If you can't live with this constrained risk, you should consider not to use master, or thoroughly check new functionalities every time you download master before your (corporate) use. FreeCAD development cannot adapt to specific risk levels of single individuals or corporations.
uwestoehr wrote: Tue Oct 12, 2021 6:37 pm
Now I see that the dimension numbers appear upside down:

I cannot test right now if this behavior was also with FC 0.19. I noticed it the first time today with a fresh build from 2 hours ago.
It is always good to raise awareness of bugs. This is something you do very well and I trust you will continue doing.

On one side, a quick look to the scope of my merged commits should immediately lead to the conclusion that it is unrelated. My commit relates to a GUI task panel and it does not involve any drawing or camera position.

On the other side, this bug is documented in the tracker:
https://tracker.freecadweb.org/view.php?id=4292

so it preexisted the relevant commits.
User avatar
uwestoehr
Posts: 2914
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany

Re: PR #4942 new option to show/hide sketcher constraints

Post by uwestoehr »

abdullah wrote: Wed Oct 13, 2021 7:44 am I read your request. I made my decision. I have kindly refused to follow your request, as I judged it would serve no valid purpose.
Hi Abdullah,

I am surprised about this post. We had a developer meeting to which you were invited. The people there pointed out that master is used by many for real-life documents and this does not mean, only commercial projects.
And this statement did not came from me but from Yorik and Brad. And then it turned out the same is e.g. for Bernd. However, the same is for me. For example I am planning fixtures for a private solar system at the moment.

Then we spoke about new mergers and the agreement was to work with PRs. As you have seen, Chris is only merging his PRs after others had a look. Then we also agreed, that the existing mergers like you can directly merge since they have the experience what could break master and what is safe. So you did nothing wrong and I never stated this.
I sent you a protocol of the meeting. So I am not attacking anyone. I was just the organizer of the meeting and I made the protocol to inform everybody what we spoke about. What else should I have done?

Back to the topic: FC is a community project and I have more than a decade contributed to different projects. When I started, SVN was used the most and we all committed directly to master. Over the years many projects changed their development that branches are made to test and discuss on a PR before it is merged. At first I was opposed to this since it broke my workflow. (You can e.g. google some of my statements in the lyx.org mailing lists when the LyX devel community changed to working with PRs and Git.). I meanwhile learned how useful this workflow is. We are not a company, thus we have time, and if a feature makes it into master a week earlier or not, does not matter.

So all I requested is to make a PR when you change UI stuff. Not because it is only my personal wish, but for every interested person to be able to try it out, comment etc. You request the followers of this thread to test. So I don't see what is problematic of making a PR with the features you plan. We check it out and report back. And for example also Werner does this when he changes UI and want to get feedback from the community.
So when I request you to make a PR has absolutely no personal aspect, it is just a request for a different workflow which I think is a benefit and from the meeting I understood that the core developers want to use this more in future too.

And to my person: I am an engineer, no programmer. I am not working in the software business. I use FC for private projects, teach it to friends and colleagues and even students. My main use case is to model objects I 3D print for work and private projects. At the moment I use FC the first time to laser-cut photomasks. Therefore I was faced with complex sketches.

abdullah wrote: Wed Oct 13, 2021 7:44 am On the other side, this bug is documented in the tracker:
https://tracker.freecadweb.org/view.php?id=4292
Thanks. Yes, this is the bug I see. So it is not related to your recent changes.

EDIT: This issue is a good example why a PR would be a benefit - I can take my file, start master, see the issue is there, so the PR is independent of this.
The cool thing with the PRs that one does not need to know the code, but can just focus on playing around with the feature and always cross-check with master.
abdullah
Posts: 4292
Joined: Sun May 04, 2014 3:16 pm

Re: PR #4942 new option to show/hide sketcher constraints

Post by abdullah »

I think you are over-reacting, but let's clarify things:
uwestoehr wrote: Wed Oct 13, 2021 9:18 am I am surprised about this post. We had a developer meeting to which you were invited. The people there pointed out that master is used by many for real-life documents and this does not mean, only commercial projects.
And this statement did not came from me but from Yorik and Brad. And then it turned out the same is e.g. for Bernd. However, the same is for me. For example I am planning fixtures for a private solar system at the moment.
I do not see the relevance of mentioning the developer meeting here. You are stating the same as me regarding to master. You are quoting others as saying the same. You are only reinforcing my point: We aim for a stable master for the whole community.

I am telling you that I chose to merge directly because I know the sketcher code, and it is almost impossible that this change would negatively impact anybody's work. This includes your work.
uwestoehr wrote: Wed Oct 13, 2021 9:18 am Then we spoke about new mergers and the agreement was to work with PRs. As you have seen, Chris is only merging his PRs after others had a look. Then we also agreed, that the existing mergers like you can directly merge since they have the experience what could break master and what is safe. So you did nothing wrong and I never stated this.
I sent you a protocol of the meeting. So I am not attacking anyone. I was just the organizer of the meeting and I made the protocol to inform everybody what we spoke about. What else should I have done?
I have never asked you to do anything else. I do not ask for anything now.

You state that I did nothing wrong. I agree. You state that you never stated that I did anything wrong. I agree. Yet your post, second line, states "Nevertheless, I asked that you make a PR to test before you merge.". I have tried to explain you why I did not and why I am unlikely to follow such requests in the future, unless I judge it should be that way. I have further explained what I consider when I make my judgement. This, I believe, is fully in line with other core developers, and is in fact part of my learning in this project. It is also information that I would like to convey to future integrators and core developers.

For the rest, you are mostly reinforcing what I have said. There is a level of experience, not only in the project, but also in a specific scope or part of a workbench, which determines the level of reviews new code needs to undergo before merge. This is understood by most contributors and core developers.

Insofar as you mention Chennes, he has good programming skills and a very good understanding of the project as a whole, specially having regard the relative short time he is involved with us. He exercises high levels of caution. He asks help and review where needed on his own motion. It is highly exceptional that somebody with his project experience is allowed to merge over the whole scope of the project, including in the core part. But he has a good sense to stay away from problematic PRs (and politely doing so), while helping out in PRs that are reasonably right. He is IMO doing great. All this said, he is still a new integrator and does PRs.

You have an unmet expectation about me. You understand that it is not only my own perception, but also that of others, that I should continue deciding what to do as I have been doing in the past.
uwestoehr wrote: Wed Oct 13, 2021 9:18 am Back to the topic: FC is a community project and I have more than a decade contributed to different projects. When I started, SVN was used the most and we all committed directly to master. Over the years many projects changed their development that branches are made to test and discuss on a PR before it is merged. At first I was opposed to this since it broke my workflow. (You can e.g. google some of my statements in the lyx.org mailing lists when the LyX devel community changed to working with PRs and Git.). I meanwhile learned how useful this workflow is. We are not a company, thus we have time, and if a feature makes it into master a week earlier or not, does not matter.
I think you are missing the point. This is not a discussion of professional background. Code reviews exist in the corporate and open source arenas. You understand how we work. We could talk about the old times, of whether we started with Microsoft proprietary systems, then moved to CVS, then to SVN. But it is simply irrelevant to the matter before us.
uwestoehr wrote: Wed Oct 13, 2021 9:18 am So all I requested is to make a PR when you change UI stuff. Not because it is my personal wish, but to be able to try it out, comment etc. You request the followers of this thread to test. So what is so problematic of making a PR with the features you plan, we check it out and report back? And for example also Werner does this when he changes UI and want to get feedback from the community.
So when I request you to make a PR has absolutely no personal aspect, it is just a request for a different workflow which I think is a benefit and from the meeting I understood that the core developers want to use this more in future too.
Sorry, but I disagree. You requested to make a PR because of your personal wish.

I want everybody to test a fully functional feature. This is not achievable with a PR. I already know the opinions and ideas of those who can compile the code by themselves, as this started some weeks ago. As I told you I want global feedback. Not local feedback. I know I cannot get global feedback until the feature is merged into master.

There is nobody I look up more to here than Werner. He is well over my function here. He has merged tons of UI functionality without asking (and for good reason). He has the same right as anybody else to create a PR have it reviewed. The reasons behind his decision are known to him.

I have explained why I disagree with your arguments for a PR in this case. I will not repeat them here.
uwestoehr wrote: Wed Oct 13, 2021 9:18 am And to my person: I am an engineer, no programmer. I am not working in the software business. I use FC for private projects, teach it to friends and colleagues and even students. My main use case is to model objects I 3D print for work and private projects. At the moment I use FC the first time to laser-cut photomasks. Therefore I was faced with complex sketches.
I feel no urge to compete. I am a hobbyist programmer and a hobbyist maker. I have a 3D printer and a MPCNC. I am just a regular guy.
User avatar
uwestoehr
Posts: 2914
Joined: Sun Jan 27, 2019 3:21 am
Location: Germany

Re: PR #4942 new option to show/hide sketcher constraints

Post by uwestoehr »

abdullah wrote: Wed Oct 13, 2021 10:41 am Sorry, but I disagree. You requested to make a PR because of your personal wish.
I want everybody to test a fully functional feature. This is not achievable with a PR.
There was a meeting to share different points of view etc. Meetings are there to check if the own way can be improved. I try to communicate to avoid misunderstandings. So maybe I misunderstood the others then in the meeting. Let's discuss this the next meeting please and I hope you can join this.

Personal opinion: Concerning it is not achievable with a PR, I disagree. The PR provides exactly this - a fully featured master plus the new feature. That is ideal for testing the feature, see below.

And my duplicate bug report is a nice case how a PR would have been a benefit:

uwestoehr wrote: Wed Oct 13, 2021 9:18 am EDIT: This issue is a good example why a PR would be a benefit - I can take my file, start master, see the issue is there, so the PR is independent of this.
The cool thing with the PRs that one does not need to know the code, but can just focus on playing around with the feature and always cross-check with master.
abdullah wrote: Wed Oct 13, 2021 10:41 am I already know the opinions and ideas of those who can compile the code by themselves, as this started some weeks ago. As I told you I want global feedback. Not local feedback. I know I cannot get global feedback until the feature is merged into master.
This argumentation does only work for developers with merging rights. All other developers have to make PRs and need people who can compile to give feedback.
For example chrisB is a great help of getting feedback but he cannot compile. So he needs a master build.
So as it works for all devels without merging rights, there is a PR, people who can compile give feedback, the code can be optimized if necessary, then it is merged. We provide frequently master builds and then get feedback of the full audience.

abdullah wrote: Wed Oct 13, 2021 10:41 am There is nobody I look up more to here than Werner. He is well over my function here. He has merged tons of UI functionality without asking (and for good reason). He has the same right as anybody else to create a PR have it reviewed. The reasons behind his decision are known to him.
I worked with him for some Part and PartDesign features and he started to make PRs, exactly for the reason that others can test and give feedback.
This is now my personal opinion: I don't think it is good that certain decisions are only known to one person. I contributed for example the first year mostly to TechDraw and could ask wandererfan. Now he is no longer available and unless there are proper code comments, it is sometimes not clear why some things are made they way they are.

I get the feeling that you feel personally offended because I want you to consider to change your workflow when it comes to UI. That is sad, since I appreciate you very much, like your work and use it with joy. So let's please put aside the personal level.
However, the environment around us changes. That's why I wrote about my experiences wit the change from SVN -> Git. I know myself how I can sometimes react on something that changes my workflow. So I hope you take some days to consider if making here an there a PR than directly merging could suit you and the community. And of course not for every simple case a PR is necessary

abdullah wrote: Wed Oct 13, 2021 10:41 am I feel no urge to compete.
I don't understand this statement. I wrote it that you know something about me, just to know each other. I find such info useful because for example knowing the background of a person helps to understand each other better. A natural scientist (I studied physics) acts different than e.g. a linguist. A professional coder works different than a hobbyist etc. So knowing each other does never harm and I am surprised that I when make a neutral description about me you write about competition.
abdullah
Posts: 4292
Joined: Sun May 04, 2014 3:16 pm

Re: PR #4942 new option to show/hide sketcher constraints

Post by abdullah »

And again:
uwestoehr wrote: Wed Oct 13, 2021 11:15 am
abdullah wrote: Wed Oct 13, 2021 10:41 am Sorry, but I disagree. You requested to make a PR because of your personal wish.
I want everybody to test a fully functional feature. This is not achievable with a PR.
There was a meeting to share different points of view etc. Meetings are there to check if the own way can be improved. I try to communicate to avoid misunderstandings. So maybe I misunderstood the others then in the meeting. Let's discuss this the next meeting please and I hope you can join this.

Personal opinion: Concerning it is not achievable with a PR, I disagree. The PR provides exactly this - a fully featured master plus the new feature. That is ideal for testing the feature, see below.

And my duplicate bug report is a nice case how a PR would have been a benefit:
EDIT: This issue is a good example why a PR would be a benefit - I can take my file, start master, see the issue is there, so the PR is independent of this.
The cool thing with the PRs that one does not need to know the code, but can just focus on playing around with the feature and always cross-check with master.
You are arguing in circles:
- This has nothing to do with the meeting. You have agreed that it is the common understanding that I can directly merge to the branch. This does not need yet another meeting for clarification.
- You disagree that I cannot get a large audience via PR. Your argument is self-defeating.
- You exemplify you reporting a bug in unrelated code as how a PR would have been a benefit. If it were a PR you would also have reported the same. It is simply immaterial to be in a PR or in master for you to report a bug.
- You appear to claim that you cannot compile a previous commit of the master branch and test, or use the master from the previous day.
uwestoehr wrote: Wed Oct 13, 2021 11:15 am
abdullah wrote: Wed Oct 13, 2021 10:41 am I already know the opinions and ideas of those who can compile the code by themselves, as this started some weeks ago. As I told you I want global feedback. Not local feedback. I know I cannot get global feedback until the feature is merged into master.
This argumentation does only work for developers with merging rights. All other developers have to make PRs and need people who can compile to give feedback.
For example chrisB is a great help of getting feedback but he cannot compile. So he needs a master build.
So as it works for all devels without merging rights, there is a PR, people who can compile give feedback, the code can be optimized if necessary, then it is merged. We provide frequently master builds and then get feedback of the full audience.
No. Read again the minutes of your meeting. It does not work for all developers with merging rights. It does not apply to new Integrators, who do have merging rights. It only applies to more experienced core developers.

I find problems following the logic behind your statements: You acknowledge that ChrisB would be great to have as tester and for feedback (which I can only agree). You acknowledge that he would only be fully enabled when he gets a master build. Yet you want me to undergo a PR which will only delay his feedback. This, I should do, because developers without merging rights need to go that path (for good other reasons). But I want his feedback. Sometimes it appears that your feedback is more valuable than his. No offense here. If I had to choose a single tester for sketcher features, it is highly likely that I would choose ChrisB (he is not the only very capable power user, he is certainly a very capable one). Thankfully, I can get several other power users who are brilliant and are in the same situation as ChrisB. And, by merging it to master, I can also get your feedback and the one from other developers. I am not preventing you from giving your feedback. I am certainly not prioritizing your feedback over theirs. Do not ask me that. I won't comply.

There is yet another reference to the need for "optimizing" code. If for any chance, at any moment, you have problems with my code, come forward. I do not shy away from my mistakes. I may learn yet another way how not to do something.
uwestoehr wrote: Wed Oct 13, 2021 11:15 am
abdullah wrote: Wed Oct 13, 2021 10:41 am There is nobody I look up more to here than Werner. He is well over my function here. He has merged tons of UI functionality without asking (and for good reason). He has the same right as anybody else to create a PR have it reviewed. The reasons behind his decision are known to him.
I worked with him for some Part and PartDesign features and he started to make PRs, exactly for the reason that others can test and give feedback.
This is now my personal opinion: I don't think it is good that certain decisions are only known to one person. I contributed for example the first year mostly to TechDraw and could ask wandererfan. Now he is no longer available and unless there are proper code comments, it is sometimes not clear why some things are made they way they are.

I get the feeling that you feel personally offended because I want you to consider to change your workflow when it comes to UI. That is sad, since I appreciate you very much, like your work and use it with joy. So let's please put aside the personal level.
However, the environment around us changes. That's why I wrote about my experiences wit the change from SVN -> Git. I know myself how I can sometimes react on something that changes my workflow. So I hope you take some days to consider if making here an there a PR than directly merging could suit you and the community. And of course not for every simple case a PR is necessary
I cannot emphasise the following enough: You know UIs better than I do and I welcome you improving UIs (I do have issues when it appears that your decisions do not take into account other classes of users. We have an open issue with one dialog size, which I have not forgotten. It is waiting for decisions that I want made with global feedback, thus the merging.). I treat all users the same.

What I totally fail to understand, is why you cannot make a PR for a UI change after the functionality is merged. Which dark force may prevent you from doing so. May my UI be so abhorrent that you cannot bear with it until your PR is merged?

Let's work out those circular references again:
- Werner started doing PRs for UI things when working with you. I am ok with that. I do not know the background. It could be that the PR was mostly about UI and that functionality needed to be adapted to the UI, so it made more sense to get the right UI first. If Werner did it, it was the right choice. This has however nothing to do with the following lines.
- It is not good that certain decisions are known to only one person. I fully agree. Please ask. It is not that I am ignoring you. I am always open to explain my decisions. Nobody prevents you from looking at my code and asking. You are not going to do anything else if I do a PR. You are going to read the code. If the code prompts questions, you will make them. If it does not you won't. It is not as if I were concealing the code from you. I try to comment every non-obvious decision in the code. If something is not clear, do come forward. If I died tomorrow, it would not matter that I did many PRs in the past.
- It is not really about changing the workflow. It is about whether it is meaningful. Here we do have a big disagreement. When I evaluate your reasons why you want to change it, they are not sound enough to outweigh the reasons why I want to follow it. More precisely, I cannot make logic out of them.
- I do not consider mine an overreaction. But a necessary reaction so settle a source of dissonance. I always consider the community before myself when taking my actions in this forum and the repository. I still think that my actions follow this consideration in full.

uwestoehr wrote: Wed Oct 13, 2021 11:15 am
abdullah wrote: Wed Oct 13, 2021 10:41 am I feel no urge to compete.
I don't understand this statement. I wrote it that you know something about me, just to know each other. I find such info useful because for example knowing the background of a person helps to understand each other better. A natural scientist (I studied physics) acts different than e.g. a linguist. A professional coder works different than a hobbyist etc. So knowing each other does never harm and I am surprised that I when make a neutral description about me you write about competition.
I have a different opinion based on my own experience.

I do not like to be biased when I make my decisions. I should treat you (and any other) the same regardless of whether you are a physicist or an engineer. Whether you dedicate to software development professionally or you design structures. Whether you are a lawyer or an English teacher at school.

I purposefully omit my background, because similarly, I do not want others to be biased by what I am or I am not. If I am wrong, I am wrong. If I am right, I am right. I believe in the power of words, not in the power of the speaker. I can easily change my mind with compelling arguments. It is unlikely I will change it in the absence of arguments.

I matter what the people say. Their ideas. What they want to achieve. When it comes to this community, I enjoy enabling people to achieve their goals. I am not a professional coder, but I do like to code a lot. I am always striving to improve my skills. The FreeCAD community is for me, what for others is watching a football game at the local pub, only that with coding instead of football and worldwide written social interaction instead of chatting.
chrisb
Posts: 37776
Joined: Tue Mar 17, 2015 9:14 am

Re: PR #4942 new option to show/hide sketcher constraints

Post by chrisb »

I am very grateful for Abdullah providing his improvements in master. I aplogize for currently not being able to pay the attention to them which they deserve. For personal reasons I scan the daily posts only roughly and do some basic help; but I hope to be able to invest more time in thorough tests which require bigger time slots soon.
Meanwhile it would be great if other power users could have a look at the new sketcher stuff
drmacro wrote: pinged by pinger macro
openBrain wrote: pinged by pinger macro
Shalmeneser wrote: pinged by pinger macro
The way I understand it, PRs are used in a twofold manner
1) To provide code changes from people who cannot merge their changes directly to the code.
2) To provide code changes to (a single or few) other developers for what reason so ever.

None of these holds here for Abdullah's changes.

Uwe, you repeatedly refer to the lyx project. To be honest: it is a different project and follows its own principles. I will not investigate how things are done there, but this is how the master branch works since years - and this works well:

Master is not something experimental, it is a very stable version, and can usually very well be used in a professional environment. In that light I can understand your concerns, but after all it it is a devlopment version.

An important aspect is, that Abdullah has proven in the past that his way of contributing is highly appreciated. We all - including Uwe from what I understand - agree on the high quality of his contributions. He is listening very well to the community and doesn't hesitate to make serious changes to what he has committed, so it is not at all the behaviour sometimes seen in other cases of "what is in remains in".
The recent improvements where well discussed here in the forum, and the new filter functions don't affect anything else, so I appreciate to provide them to the whole community.

Uwe, instead of requiring a PR, you could offer to review PRs. Then can Abdullah decide if it is something experimental which shouldn't go to master before a second look or if it can well be merged directly into master.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
User avatar
-alex-
Posts: 1012
Joined: Wed Feb 13, 2019 9:42 pm
Location: France

Re: PR #4942 new option to show/hide sketcher constraints

Post by -alex- »

Hi there, thanks a lot for the great job done here.
I've git pull master and compiled this night on my Raspberry PI4 then took a quick look at sketcher in early morning.
I don't know if it's related but I'm now not able to resize the sketcher task panel, I can't enlarge it, it always go back to the previous width.
I'll give it more try this evening, for now it's workday ;-)

Compiled Py3.7.3/Qt5.11.3
abdullah
Posts: 4292
Joined: Sun May 04, 2014 3:16 pm

Re: PR #4942 new option to show/hide sketcher constraints

Post by abdullah »

-alex- wrote: Thu Oct 14, 2021 5:59 am I don't know if it's related but I'm now not able to resize the sketcher task panel, I can't enlarge it, it always go back to the previous width.
Thank you.

It can indeed be my deed. However, I am not sure I understand. Can't you do this?
Peek 14-10-2021 14-50.gif
Peek 14-10-2021 14-50.gif (272.34 KiB) Viewed 433 times
Locked