I don't think we can, introducing a dependency like OCL this late in the release cycle is a no-go in my book. The most important thing right now is to stabilize and ship 0.19 so it makes the Debian release.
thread milling?
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: thread milling?
Re: thread milling?
Got it!
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: thread milling?
Interesting, I was actually thinking the opposite. Version 0.19 is about to be "cast in stone" for the next year or two. Do we want the "experimental" ops to remain hidden for that release?
Sliptonic has mentioned a number of times that he would like to see more testing of changes and new ops. Keeping some of the cutting edge stuff buried a bit may not help in this quest.
I am not arguing, just observing. Clearly we do not want to bake in a problem with dependencies such as OCL. At the same time we do not want to restrict things that no longer need to be restricted.
What to do????
Gene
Re: thread milling?
I don't have a strong opinion and would safely let sliptonic and mlampert decide.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: thread milling?
At what point does it become a dep of FC? Surely at some point this has to happen, isn't a new major release a good time?
Are there distros for which this is a problem?
Ah. Just about all of them !
https://repology.org/project/opencamlib/versions
Since that master source for OCL does not seem to have moved in a couple of years, isn't the best solution to fork it into FreeCAD and stop worrying about deps ?
It could always be synced up if it changes but it does not look that is going to introduce a lot of maintenance work
https://github.com/aewallin/opencamlib/issues/56
In practice I don't have much time to do maintenance work, and no time to do development work on opencamlib. It would be good if there is a volunteer maintainer who wants to take over.
- sliptonic
- Veteran
- Posts: 3460
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: thread milling?
I don't really like the idea of just making it a preference flag. These aren't advanced features, they're experimental. We don't want users to think that these features will eventually become a real part of Path or that jobs that use them won't break or crash their machine.GeneFC wrote: ↑Sun Feb 07, 2021 12:26 amThat hurdle has probably outlived its usefulness.chrisb wrote: ↑Sat Feb 06, 2021 4:44 pm You have to enable Path experimental to get it in the regular menu.
Gene
If the distinction between experimental and mainline functionality has outlived its usefulness, than let's just put everything up front. The entire point is that it _should_ be difficult to get access to them because we want users taking responsibility for turning them on.
My opinion is put the dangerous stuff on a high shelf. Not everything needs to be easy.
Re: thread milling?
Yep, keep the guns and narcotics away from the children ( especially Hunter) !My opinion is put the dangerous stuff on a high shelf. Not everything needs to be easy.
Oh, best hide the rotation feature too.
-
- Posts: 258
- Joined: Sat Nov 14, 2020 9:16 pm
- Location: Bargara, Queensland, Australia UTC+10
Re: thread milling?
I have a Macro to generate thread milling paths for Internal and External threads (attachments)
Went my own way with the code as I have used this method before (used to be in the Iscar catalogues/manuals long ago, before they made the online calculator based on their catalogue product numbers)
Could not get my head around the module interactions in the Experimental Feature Code to expand to include external.
My code needs a bit of a tidy up but is still an ongoing project.
My question at the stage is:
Is it possible to interact with the inbuilt ".ui" via a custom ".....Gui.py" file? Can't do local builds yet.
I can create a Task Panel type UI dialog to interact with the macro, but am wondering if more integration can be achieved locally. The Custom OP and the macro work fine but would like to learn more of the integration. Have had a bit of a play with an unpacked AppImage but no joy as yet.
EDITED: ORIGINAL "ThreadPathMacro.py" incorrectly named module i.e., second "ExtRHclimb()" should have been "ExtRHconventional()".
File replaced.
Update Edit: Corrections to X, Y, centre positioning : errors existed when position was not '0, 0'
Went my own way with the code as I have used this method before (used to be in the Iscar catalogues/manuals long ago, before they made the online calculator based on their catalogue product numbers)
Could not get my head around the module interactions in the Experimental Feature Code to expand to include external.
My code needs a bit of a tidy up but is still an ongoing project.
My question at the stage is:
Is it possible to interact with the inbuilt ".ui" via a custom ".....Gui.py" file? Can't do local builds yet.
I can create a Task Panel type UI dialog to interact with the macro, but am wondering if more integration can be achieved locally. The Custom OP and the macro work fine but would like to learn more of the integration. Have had a bit of a play with an unpacked AppImage but no joy as yet.
EDITED: ORIGINAL "ThreadPathMacro.py" incorrectly named module i.e., second "ExtRHclimb()" should have been "ExtRHconventional()".
File replaced.
Update Edit: Corrections to X, Y, centre positioning : errors existed when position was not '0, 0'
- Attachments
-
- ThreadPathMacro.py
- (22.16 KiB) Downloaded 72 times
-
- ThreadMacroPath.FCStd
- (44.13 KiB) Downloaded 90 times
Last edited by bmsaus4ax on Sun Sep 19, 2021 10:12 am, edited 2 times in total.
Re: thread milling?
Interesting, I'll try to find time to look at this later.
I would really suggest you get set up for doing a full local build. Getting a clone of the source code tree and building is relatively simple. It just means pulling in the relative devel packages ( header files ) for your platform.
Use qt5 Designer for creating and editing .ui files for manipulating dialogues etc.
What sort of tool is this designed to use?
I would really suggest you get set up for doing a full local build. Getting a clone of the source code tree and building is relatively simple. It just means pulling in the relative devel packages ( header files ) for your platform.
Use qt5 Designer for creating and editing .ui files for manipulating dialogues etc.
What sort of tool is this designed to use?
- sliptonic
- Veteran
- Posts: 3460
- Joined: Tue Oct 25, 2011 10:46 pm
- Location: Columbia, Missouri
- Contact:
Re: thread milling?
You want to use the existing threadmill .ui file but with your own macro code?bmsaus4ax wrote: ↑Sat Jul 10, 2021 11:30 am My question at the stage is:
Is it possible to interact with the inbuilt ".ui" via a custom ".....Gui.py" file? Can't do local builds yet.
I can create a Task Panel type UI dialog to interact with the macro, but am wondering if more integration can be achieved locally. The Custom OP and the macro work fine but would like to learn more of the integration. Have had a bit of a play with an unpacked AppImage but no joy as yet.
Yes, it's possible. The .ui file contains no logic of its own so you can just load it and get a reference and then do anything you want with it.
Simple example:
Code: Select all
form = FreeCADGui.PySideUic.loadUi(":/panels/PageOpThreadMillingEdit.ui")
form.show()
That said, I agree with freman. Getting a local build set up isn't too difficult.