[Merged] Refactoring ViewProviderSketch
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Refactoring ViewProviderSketch
Sorry for the confusion, I had googled ascii tab and found this code in the extended range between 128-255 . Let's hope it is not locale dependent, but as unicode it should be robust.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Refactoring ViewProviderSketch
It is locale specific. Only the characters of the range [0, 127] are equal on all systems.
Re: Refactoring ViewProviderSketch
Just to be clear with everybody, the [128,255] range of extended ASCII is locale specific (or actually is changing depending on the used codepage).
But here in my PR (and generally as Unicode), it isn't locale specific.
Re: Refactoring ViewProviderSketch
I am not familiar with Vulkan. But if Vulkan is a substitute for Coin3D it should help.
Re: Refactoring ViewProviderSketch
If it is locale independent, I have not problem at all with a PR.
Eventually your code will move with the refactor, but the essence will stay
Solving problems is never clutter. I have no problem at all with it. No need to split.
Re: Refactoring ViewProviderSketch
Thanks for your opinion.
Yes, maybe I make some confusion here because AFAIK Coin3D deals with Openiventor which deals itself with openGL so...
But Coin3D is maybe not the level to consider, I'm not an expert though, just an end user, so maybe I miss the point here.
Anyway, that's pretty offtopic, so if ones want talk about that we should do it elsewhere to not hijack this thread
Re: Refactoring ViewProviderSketch
Today's progress report is as follows:
EditData (the pimpl structure that stored all types of parameters relating to edit mode) has undergone a severe diet. Different responsibilities have been assumed by ViewProvider and CoinManager. What is left there at the moment is Preselection and Selection.
Preselection and Selection are spread over ViewProvider and CoinManager. This splitting of responsibilities is a very important part of this refactor, as geometry layers will change the coin part of it, and the refactor should make sure the separation of responsibilities is right, so that when layers are coded, this does not affect ViewProvider selection and preselection. Ideally, any change to layers in coin should not affect a single line of code of how ViewProvider handles selection and preselection.
This is the challenge I am facing now. It is also the last item in my list regarding separation of responsibilities between ViewProviderSketch and CoinManager. After that, ViewProviderSketch will be finished and refactoring work will only remain on the CoinManager part of it.
EditData (the pimpl structure that stored all types of parameters relating to edit mode) has undergone a severe diet. Different responsibilities have been assumed by ViewProvider and CoinManager. What is left there at the moment is Preselection and Selection.
Preselection and Selection are spread over ViewProvider and CoinManager. This splitting of responsibilities is a very important part of this refactor, as geometry layers will change the coin part of it, and the refactor should make sure the separation of responsibilities is right, so that when layers are coded, this does not affect ViewProvider selection and preselection. Ideally, any change to layers in coin should not affect a single line of code of how ViewProvider handles selection and preselection.
This is the challenge I am facing now. It is also the last item in my list regarding separation of responsibilities between ViewProviderSketch and CoinManager. After that, ViewProviderSketch will be finished and refactoring work will only remain on the CoinManager part of it.
Re: Refactoring ViewProviderSketch
It turned out that there was some dead code in VPSketch. After refactoring it, I realised it was not used at all (it is not used in master either).
I believe to be close to the end. The bit that I do not like yet relates to selection/preselection indexing. Because this has to refactor in the right direction, I hacked some code to show two layers. So this is an example of one geometry in another layer, which has a different drawing style for lines:
This is not production code. It is a hack for me to test that the selection/preselection mechanisms would work on any layer.
I believe to be close to the end. The bit that I do not like yet relates to selection/preselection indexing. Because this has to refactor in the right direction, I hacked some code to show two layers. So this is an example of one geometry in another layer, which has a different drawing style for lines:
This is not production code. It is a hack for me to test that the selection/preselection mechanisms would work on any layer.