Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

README: Create a section on how to create a Workbench #104

Open
luzpaz opened this issue Sep 29, 2018 · 13 comments
Open

README: Create a section on how to create a Workbench #104

luzpaz opened this issue Sep 29, 2018 · 13 comments

Comments

@luzpaz
Copy link
Collaborator

luzpaz commented Sep 29, 2018

Relevant links:

@luzpaz
Copy link
Collaborator Author

luzpaz commented Dec 4, 2018

CC @looooo

@looooo
Copy link
Contributor

looooo commented Dec 4, 2018

@luzpaz the starter-workbench is not really related to FreeCAD-addons. I guess it should be possible to also integrate pip-installable modules in the addon-manager but I did not had the time to think about this. Something to think about in the next year.

@luzpaz
Copy link
Collaborator Author

luzpaz commented Dec 4, 2018

It's not related ?
Isn't it a template for a workbench ?
Addons are workbenches, modules, and macros... seems related to me.

@looooo
Copy link
Contributor

looooo commented Dec 5, 2018

yes it's a template for a work-bench / module. But I don't want to mix this with the old way of creating workbenches, as this will lead to misunderstandings. Currently both ways are supported, but I guess we should think about how to make both ways more compatible as the old-style workbenches won't go away. Also most users that trying to code something for freecad have not enough python background to understand why new way of creating workbenches is better.
But yes, I will try to work on documentation if time allows.

@pierrard
Copy link

pierrard commented Dec 5, 2018

Many thanks Lorenz (Loooo) and other contributors for all you do for the community !!
I am slowly building a DIY router, 5 axis milling, and will very much appreciate the use of FreeCAD for the CAD and CAM once my hardware is ready (slow down by the cost of the parts now).
MANY THANKS!

@luzpaz
Copy link
Collaborator Author

luzpaz commented Dec 5, 2018

@looooo I see, thanks for explaining that. I didn't understand there was a 'better' preference. IMHO, we could create documentation for this pre-0.18 so any of the users that 'come in to the fold' of FreeCAD can make a more educated decision.

@looooo
Copy link
Contributor

looooo commented Dec 5, 2018

@pierrard I am only doing what I need / like to work at. There are others like @luzpaz who try to move FreeCAD in the right direction. Best to thank the whole community, which include a lot of smart people fighting for a great project ; ).

@luzpaz yes you are right. I always underestimate the impact of docs : ).

@luzpaz
Copy link
Collaborator Author

luzpaz commented Sep 16, 2019

@joelgraff perhaps you could weigh in on workbench creation as well at some point ? (i know your todo list is yuuuuge but nonetheless, please consider thanks!!!)

@joelgraff
Copy link

@luzpaz - Thanks for mentioning this. Currently, I've forked the starter kit and am, a little bit at a time, trying to build out a general layout that is maintainable and scalable for small to mid-sized Python workbenches. Specifically, I feel a workbench's functions are best divided across individual "Tasks" and code needs to be organized to reflect that.

For example:

  • init_gui.py should never have anything more than the command class imports and toolbar / context menu / menu layout code.
  • A command class should only setup a task and clean up after it
  • A base task class should do two things: initialize the task panel ui, and kick off the task-specific subclasses, where all of the custom code really belongs.

Of course, there are exceptions (like a command that simply executes an external program, or just opens a file), but for more complex tasks, I really think that sort of structure should be encouraged / enforced where possible.

Without a clear structure in place to mange the various workbench command / task use cases, we cannot write clear, useful developer documentation. I realize it's no good trying to enforce absolute standards, but the goal is to provide a clean and well organized picture of how everything fits together rather than leave new devs to their own devices to hack together something that works, but may become unmaintainable as the workbench scope scales.

@luzpaz
Copy link
Collaborator Author

luzpaz commented Sep 16, 2019

@joelgraff
I resonate with everything you wrote and I'm very glad this discussion is progressing. Especially:

Without a clear structure in place to mange the various workbench command / task use cases, we cannot write clear, useful developer documentation. I realize it's no good trying to enforce absolute standards, but the goal is to provide a clean and well organized picture of how everything fits together rather than leave new devs to their own devices to hack together something that works, but may become unmaintainable as the workbench scope scales.

I think I'll pin this issue so it's of priority.

@luzpaz luzpaz pinned this issue Sep 16, 2019
@luzpaz
Copy link
Collaborator Author

luzpaz commented Mar 10, 2021

yikes, got to get around to doing this.

@joelgraff
Copy link

joelgraff commented Mar 10, 2021 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants
@joelgraff @pierrard @luzpaz @looooo and others