Precision Drawing Tools (PDT) #70238

New Issue

Alan Odom · 2019-09-25T12:39:40+02:00

Alan Odom commented

2019-09-25 12:39:40 +02:00

A set of Precision Drawing Tools, displayed in the N Panel under its own tab, to assist with precise modelling in Blender.

This set includes options to place the cursor and other features, by Absolute, Delta and Direction inputs, along with other options including Normal & Convergence Intersection and Percentage between selected features.

There is a Pivot Point toolset to provide an alternative location for geometry manipulation, this is displayed optionally as a 3-Axis graphic in the 3D View.

There is also a primitive Parts Library section, still in its infancy, that will be developed over time into a capable repository for standard parts to be used frequently in modelling projects, for example sets of gears, or windows for architecture, etc.

This is my first attempt at a Blender Add-on so I am open to advice and guidance, not only on the design of the code, but also in the procedures for getting an Add-on accepted. I have also opened a GitHub project for this Add-0n here:

https://github.com/Clockmender/Precision-Drawing-Tools

And my website below, contains much more information and help facilities, I know I have to do more work here, but this is going to take time.

https://clockmender.uk/blender/precision-drawing-tools/

Zip file below, I hope I have put this in the right place!

clockworxpdt.zip

A set of Precision Drawing Tools, displayed in the N Panel under its own tab, to assist with precise modelling in Blender. This set includes options to place the cursor and other features, by Absolute, Delta and Direction inputs, along with other options including Normal & Convergence Intersection and Percentage between selected features. There is a Pivot Point toolset to provide an alternative location for geometry manipulation, this is displayed optionally as a 3-Axis graphic in the 3D View. There is also a primitive Parts Library section, still in its infancy, that will be developed over time into a capable repository for standard parts to be used frequently in modelling projects, for example sets of gears, or windows for architecture, etc. This is my first attempt at a Blender Add-on so I am open to advice and guidance, not only on the design of the code, but also in the procedures for getting an Add-on accepted. I have also opened a GitHub project for this Add-0n here: https://github.com/Clockmender/Precision-Drawing-Tools And my website below, contains much more information and help facilities, I know I have to do more work here, but this is going to take time. https://clockmender.uk/blender/precision-drawing-tools/ Zip file below, I hope I have put this in the right place! [clockworxpdt.zip](https://archive.blender.org/developer/F7774428/clockworxpdt.zip)

Alan Odom commented

2019-09-25 12:39:40 +02:00

Added subscriber: @clockmender

Brendon Murphy commented

2019-09-26 02:12:16 +02:00

Added subscriber: @BrendonMurphy

Brendon Murphy self-assigned this 2019-09-26 02:12:16 +02:00

Brendon Murphy commented

2019-09-26 02:12:16 +02:00

Hi, thanks very much for your Interest and hard work. We will look at this shortly. KI think certainly this is a good target for 2.82. We will need to organize commit access for you. we would be able to add this right after 2.81 release and iron out any issue during the pre-release stage. Thanks again. Aweosme work.

Alan Odom commented

2019-09-26 15:53:43 +02:00

Thank you for the support, just keep me informed of what I need to do and when, I am very new to this...

Janne Aliu commented

2019-09-26 23:07:55 +02:00

Added subscriber: @Jaydead

Nathan Letwory commented

2019-09-27 09:23:40 +02:00

Added subscriber: @jesterking

Nathan Letwory commented

2019-09-27 09:23:40 +02:00

@BrendonMurphy , @clockmender if all goes well you probably can start working on that after stabilizing branch is created. We'll see how that pans out in a few weeks time.

Juan commented

2019-09-27 13:12:11 +02:00

Added subscriber: @jc4d

Rune Morling commented

2019-09-28 14:36:02 +02:00

Added subscriber: @ermo

Alan Odom commented

2019-10-06 13:48:54 +02:00

Added subscriber: @tetha.z

Alan Odom commented

2019-10-06 13:48:54 +02:00

Latest Version (Release 1.1.4) is now on our GitHub:

https://github.com/Clockmender/Precision-Drawing-Tools/releases

I am now getting help from @ermo to get the code up to standard, thanks to him for his work.

I have incorporated 3 functions from TinyCAD, with @tetha.z permission for the next release.

We are also working on the Error messages to be able to have multi-language support.

Latest Version (Release 1.1.4) is now on our GitHub: https://github.com/Clockmender/Precision-Drawing-Tools/releases I am now getting help from @ermo to get the code up to standard, thanks to him for his work. I have incorporated 3 functions from TinyCAD, with @tetha.z permission for the next release. We are also working on the Error messages to be able to have multi-language support.

B.E. commented

2019-10-07 00:00:48 +02:00

Added subscriber: @jiku

Alan Odom commented

2019-10-08 15:04:14 +02:00

@ermo and I have been busy with the code. We have added Docstrings and run "Black" https://black.readthedocs.io/en/stable/ on the code to get the formatting from my amateur mess to his professional look, brief example below:

We have also changed all the messages so they are now in a messages file and called by their names, this means that messages can be translated, we have also done same for input descriptions:

This is for the next release, 1.1.5, which also has a new Fillet Tool.

Cheers, Clock.

@ermo and I have been busy with the code. We have added Docstrings and run "Black" https://black.readthedocs.io/en/stable/ on the code to get the formatting from my amateur mess to his professional look, brief example below: ![Screen Shot 2019-10-08 at 13.55.51.png](https://archive.blender.org/developer/F7796599/Screen_Shot_2019-10-08_at_13.55.51.png) We have also changed all the messages so they are now in a messages file and called by their names, this means that messages can be translated, we have also done same for input descriptions: ![Screen Shot 2019-10-08 at 13.59.06.png](https://archive.blender.org/developer/F7796602/Screen_Shot_2019-10-08_at_13.59.06.png) ![Screen Shot 2019-10-08 at 14.00.12.png](https://archive.blender.org/developer/F7796605/Screen_Shot_2019-10-08_at_14.00.12.png) This is for the next release, 1.1.5, which also has a new **Fillet** Tool. Cheers, Clock.

Rune Morling commented

2019-10-08 22:15:04 +02:00

For maintainability's sake, we've gone with Google-style docstrings for now.

I haven't (yet) been able to figure out which docstring format Blender officially recommends, but links/pointers/tips are most welcome.

EDIT: Oh and the choice of black as THE code formatting tool was deliberate. If someone decides to create a PR, they are expected to run the code through black -l100. Manually turning off blackening of a section is only acceptable for math stuff, otherwise not.

For maintainability's sake, we've gone with [Google-style docstrings ](https://www.datacamp.com/community/tutorials/docstrings-python#sixth-sub) for now. I haven't (yet) been able to figure out which docstring format Blender officially recommends, but links/pointers/tips are most welcome. EDIT: Oh and the choice of black as THE code formatting tool was deliberate. If someone decides to create a PR, they are expected to run the code through `black -l100`. Manually turning off blackening of a section is only acceptable for math stuff, otherwise not.

Brendon Murphy commented

2019-10-09 13:58:25 +02:00

hi, thanks very much for the updates, I've been speaking with @ermo and I think the plans are to move this forward after 2.81 release. I'll get back here in a week or so and we can discuss starting the review process. Thanks again, you guys are doing a great job here.

Alan Odom commented

2019-10-11 15:56:46 +02:00

I have a question:

Rather than have a command line input like this:

Could I trap a keyed input of say pdt-fg0.1,4,0.5 and get that interpreted as the PDT command line, so users don't have to key into the command line input, just type the input?

Thanks, Clock.

I have a question: Rather than have a command line input like this: ![Screen Shot 2019-10-11 at 14.54.08.png](https://archive.blender.org/developer/F7806265/Screen_Shot_2019-10-11_at_14.54.08.png) Could I trap a keyed input of say `pdt-fg0.1,4,0.5` and get that interpreted as the PDT command line, so users don't have to key into the command line input, just type the input? Thanks, Clock.

Rune Morling commented

2019-10-15 20:43:20 +02:00

@BrendonMurphy :

We would like to prepare a manual for PDT. Should we be using the official Blender wiki or ...?

@BrendonMurphy : We would like to prepare a manual for PDT. Should we be using the official Blender wiki or ...?

Brendon Murphy commented

2019-10-16 00:31:08 +02:00

hi @ermo the best option at this time is to create a wiki on your github. I'm still working on the Add-ons Manual, we have already accepted docs from github wiki or/and linked into github wiki via the addon. Later down the track I can look at the Blender Manual page and either transfer your work or link to your git.

Brendon Murphy commented

2019-10-16 00:53:44 +02:00

@ermo @clockmender hi, the following is a template about access to the blender addons project. I think it's a good time now to start the review process.

hi, if you can join this mailing list: bf-committers@blender.org and mail:
Subject:

Re: Commit Access to Addons Repository: ATT: @ideasman42

Content:

Hi my name is: "your name/s"
My user name on developer.blender.org is: "your user name/s here"
I would like commit access to the addons repository.
I am the maintainer of/my addon is:
Make mention of https://devtalk.blender.org/t/making-an-add-on-for-precision-modelling-cad-tools/8637 as many discussion were had and it's a great example of the addons design process.
New to Blender and it's task is here: "inset addon name and task name".
or I'm the Author of an addon in Blender and I wish to update the addon: "inset addon name and task name if applicable".
or I'm a new maintainer of an addon in Blender and I wish to update the addon/s "inset addon/s name/s and task name/s if applicable".

I'm familiar with git usage and my repo is here: "your git hub" *not needed but why not if you have one. It's important to know git usage before committing to the Blender addons repo.

It's also useful to join this mailing list: bf-extensions-cvs@blender.org as this list mails out the commits.
https://wiki.blender.org/wiki/Developer_Intro/Overview is a good read.
https:*blender.chat/channel/python and https:*blender.chat/channel/blender-coders provide a good place to discuss your addon or issues if needed. It's good also to drop in and say hi and meet other developers and provides a good communication platform.
Final note: Addons in the Blender repository are updated by addons devs and Blender core devs help with api updates/fixes. As there's multiple people committing it's important to make sure your local folders are updated to current before committing yourself.

Any issues please let us know.
Thanks for your interest and support. Brendon.

@ermo @clockmender hi, the following is a template about access to the blender addons project. I think it's a good time now to start the review process. hi, if you can join this mailing list: bf-committers@blender.org and mail: Subject: > Re: Commit Access to Addons Repository: ATT: @ideasman42 Content: > Hi my name is: "your name/s" > My user name on developer.blender.org is: "your user name/s here" > I would like commit access to the addons repository. > I am the maintainer of/my addon is: > Make mention of https://devtalk.blender.org/t/making-an-add-on-for-precision-modelling-cad-tools/8637 as many discussion were had and it's a great example of the addons design process. > New to Blender and it's task is here: "inset addon name and task name". > or I'm the Author of an addon in Blender and I wish to update the addon: "inset addon name and task name if applicable". > or I'm a new maintainer of an addon in Blender and I wish to update the addon/s "inset addon/s name/s and task name/s if applicable". > I'm familiar with git usage and my repo is here: "your git hub" *not needed but why not if you have one. It's important to know git usage before committing to the Blender addons repo. It's also useful to join this mailing list: bf-extensions-cvs@blender.org as this list mails out the commits. https://wiki.blender.org/wiki/Developer_Intro/Overview is a good read. https:*blender.chat/channel/python and https:*blender.chat/channel/blender-coders provide a good place to discuss your addon or issues if needed. It's good also to drop in and say hi and meet other developers and provides a good communication platform. Final note: Addons in the Blender repository are updated by addons devs and Blender core devs help with api updates/fixes. As there's multiple people committing it's important to make sure your local folders are updated to current before committing yourself. Any issues please let us know. Thanks for your interest and support. Brendon.

Alan Odom commented

2019-10-16 18:43:03 +02:00

@BrendonMurphy We are both signed up and will send the email as soon as we have prepared it thoughtfully.

Thank you for this, we have studied the links you gave us.

EDIT:

Application submitted 19/10/2019.

@BrendonMurphy We are both signed up and will send the email as soon as we have prepared it thoughtfully. Thank you for this, we have studied the links you gave us. EDIT: Application submitted 19/10/2019.

Alan Odom commented

2019-10-21 18:10:51 +02:00

@BrendonMurphy We have started to produce a Wiki:

https://github.com/Clockmender/Precision-Drawing-Tools/wiki

I should very much appreciate some comments as to whether you think this good enough for purpose.

Thanks Alan.

@BrendonMurphy We have started to produce a Wiki: https://github.com/Clockmender/Precision-Drawing-Tools/wiki I should very much appreciate some comments as to whether you think this good enough for purpose. Thanks Alan.

Alan Odom commented

2019-10-26 16:22:50 +02:00

@ideasman42 Did you get my email re repo access? it was sent on 19th October. I am going to be away from 1st to 30th November and in my absence can you communicate with @ermo please. I will have email and internet some of the time, but there is not very good access in Antarctica!

thanks, Alan.

@ideasman42 Did you get my email re repo access? it was sent on 19th October. I am going to be away from 1st to 30th November and in my absence can you communicate with @ermo please. I will have email and internet some of the time, but there is not very good access in Antarctica! thanks, Alan.

Campbell Barton commented

2019-11-12 02:10:01 +01:00

Added subscriber: @ideasman42

Campbell Barton commented

2019-11-12 02:10:01 +01:00

@clockmender from looking at the add-on, it includes a blend file, which we normally try to avoid.

This used to be documented as a requirement, however checking https://wiki.blender.org/wiki/Process/Addons/Guidelines - it seems this wasn't kept, it's since been updated.

Looking at it's contents it has primitive shapes (cone, torus, cylinder), and basic colored materials.

These primitives can be generated at run-time.

@clockmender from looking at the add-on, it includes a blend file, which we normally try to avoid. This used to be documented as a requirement, however checking https://wiki.blender.org/wiki/Process/Addons/Guidelines - it seems this wasn't kept, it's since been updated. ---- Looking at it's contents it has primitive shapes (cone, torus, cylinder), and basic colored materials. These primitives can be generated at run-time.

Alan Odom commented

2019-11-12 07:22:35 +01:00

@ideasman42 If you look at the latest release, v 1.1.5, we have removed this blend file. Sorry for brevity of reply, I am on holiday and just using my phone!

Campbell Barton commented

2019-11-12 07:30:08 +01:00

I was looking at the git repository: https://github.com/Clockmender/Precision-Drawing-Tools/tree/master/clockworxpdt

Both the master branch and clockworxpdt.zip linked in this task contain blend files.

Which repository/branch should I checkout for the latest version being proposed for Blender?

I was looking at the git repository: https://github.com/Clockmender/Precision-Drawing-Tools/tree/master/clockworxpdt Both the master branch and `clockworxpdt.zip` linked in this task contain blend files. Which repository/branch should I checkout for the latest version being proposed for Blender?

Rune Morling commented

2019-11-13 13:17:26 +01:00

In #70238#809453, @ideasman42 wrote:
I was looking at the git repository: https://github.com/Clockmender/Precision-Drawing-Tools/tree/master/clockworxpdt

Both the master branch and clockworxpdt.zip linked in this task contain blend files.

Which repository/branch should I checkout for the latest version being proposed for Blender?

The code in the v1.1.5 branch is what we intend to propose for inclusion.

Note that the pdt_command functionality still needs to be re-implemented since it currently duplicates code unnecessarily.

> In #70238#809453, @ideasman42 wrote: > I was looking at the git repository: https://github.com/Clockmender/Precision-Drawing-Tools/tree/master/clockworxpdt > > Both the master branch and `clockworxpdt.zip` linked in this task contain blend files. > > Which repository/branch should I checkout for the latest version being proposed for Blender? The code in the [v1.1.5 branch](https://github.com/Clockmender/Precision-Drawing-Tools/tree/v.1.1.5) is what we intend to propose for inclusion. Note that the pdt_command functionality still needs to be re-implemented since it currently duplicates code unnecessarily.

Rune Morling commented

2019-11-18 20:54:17 +01:00

@ideasman42 :

I'm guessing you're quite busy so this is just meant as a heads up that we feel that the v1.1.5 code is ready for serious review as we don't expect any more significant churn in the v1.1.x branch.

Let me know if we need to change anything and thanks for taking on the task of whipping us into shape! =)

Once we implement the changes you suggest, the goal is to tag the final RC and advertise it on devtalk. Any issues will be tackled in further RCs.

If no issues pop up, we'll merge the v.1.1.5 branch to master and from there, push it to the blender add-on repo (possibly in the contrib area to begin with?). Guidance welcome.

@ideasman42 : I'm guessing you're quite busy so this is just meant as a heads up that we feel that the [v1.1.5 code ](https://github.com/Clockmender/Precision-Drawing-Tools/tree/v.1.1.5) is ready for serious review as we don't expect any more significant churn in the v1.1.x branch. Let me know if we need to change anything and thanks for taking on the task of whipping us into shape! =) Once we implement the changes you suggest, the goal is to tag the final RC and advertise it on devtalk. Any issues will be tackled in further RCs. If no issues pop up, we'll merge the v.1.1.5 branch to master and from there, push it to the blender add-on repo (possibly in the contrib area to begin with?). Guidance welcome.

Campbell Barton commented

2019-11-19 05:57:49 +01:00

Went over the v.1.1.5 branch (sha1, d69431959af14e720e382b1620bf23777a541ded).

Review for Inclusion

Changes which I think are reasonable to do before inclusion:

Don't use globbing with imports (violates pep8, makes refactoring harder).
Use a bpy.types.PropertyGroup for instead of adding all properties directly into the scene.

Then assign a single property group to the scene, and remove the `pdt_` prefix off all those properties.

Unless there is a good reason to separate variables, use bpy.props.FloatVectorProperty for XYZ delta/rotation.
Avoid unicode symbols © in this case, (c) serves just as well.
Remove unused imports (use pylint to check for these, noticed a few)
Remove print calls from pdt_cad_module.py, these look like they're for debugging and add noise to the output.

If you want to keep them, suggest to assign a top-level debug variable:

DEBUG_LOGGING = bpy.app.debug, then check this before printing debug info.

Suggestions

Assign layout = self.layout, avoids some repetition, especially for large blocks with many labels.
Use static sets for checks like: if mode not in ["a", "d", "i", "p"]:.

Python added static sets for this purpose.

See no reason to use more cryptic names than the current defaults:

from mathutils.geometry import intersect_line_line as LineIntersect
from mathutils.geometry import intersect_point_line as PtLineIntersect

This function seems quite cryptic for what it actually does, could be renamed.

def duplicates(indices):
    return len(set(indices)) < 4

Went over the `v.1.1.5` branch (sha1, `d69431959af14e720e382b1620bf23777a541ded`). ### Review for Inclusion Changes which I think are reasonable to do before inclusion: - Don't use globbing with imports (violates pep8, makes refactoring harder). - Use a `bpy.types.PropertyGroup` for instead of adding all properties directly into the scene. ``` Then assign a single property group to the scene, and remove the `pdt_` prefix off all those properties. ``` - Unless there is a good reason to separate variables, use `bpy.props.FloatVectorProperty` for XYZ delta/rotation. - Avoid unicode symbols `©` in this case, `(c)` serves just as well. - Remove unused imports (use pylint to check for these, noticed a few) - Remove `print` calls from `pdt_cad_module.py`, these look like they're for debugging and add noise to the output. ``` If you want to keep them, suggest to assign a top-level debug variable: ``` `DEBUG_LOGGING = bpy.app.debug`, then check this before printing debug info. ----- ### Suggestions - Assign `layout = self.layout`, avoids some repetition, especially for large blocks with many labels. - Use static sets for checks like: `if mode not in ["a", "d", "i", "p"]:`. ``` Python added static sets for this purpose. ``` - See no reason to use more cryptic names than the current defaults: `from mathutils.geometry import intersect_line_line as LineIntersect` `from mathutils.geometry import intersect_point_line as PtLineIntersect` - This function seems quite cryptic for what it actually does, could be renamed. ``` def duplicates(indices): return len(set(indices)) < 4 ```

Alan Odom commented

2019-12-01 21:40:39 +01:00

@ideasman42 - this bit here:

def duplicates(indices):
    return len(set(indices)) < 4

was some legacy code taken from TinyCAD - it does not need to exist, so I have removed it completely, it was only used once and seems to have no useful purpose as a defined function.

We have now implemented all your requirements and suggestions, in a new branch that is currently undergoing extensive testing. Once this is complete we will advise you here and move to a new release.

The only thing we should like to discuss is the need to import all maths functions into the pdt_command.py file as the user may enter any valid mathematical expression to calculate values, via maths expressions, into input fields. so for example a command of:

mxsqrt(45) puts the square root of 45 into the X coordinate input (now a FloatVectorProperty).

There are no restrictions on which maths functions the user may use, so we must import all maths functions. If there is a better way of doing this that we are not aware of, please advise and we can change it. All other "globbings" have been sorted.

@ideasman42 - this bit here: ``` def duplicates(indices): return len(set(indices)) < 4 ``` was some legacy code taken from TinyCAD - it does not need to exist, so I have removed it completely, it was only used once and seems to have no useful purpose as a defined function. We have now implemented all your requirements and suggestions, in a new branch that is currently undergoing extensive testing. Once this is complete we will advise you here and move to a new release. The only thing we should like to discuss is the need to import all maths functions into the *pdt_command.py* file as the user may enter any valid mathematical expression to calculate values, via maths expressions, into input fields. so for example a command of: mxsqrt(45) puts the square root of 45 into the X coordinate input (now a FloatVectorProperty). There are no restrictions on which maths functions the user may use, so we must import all maths functions. If there is a better way of doing this that we are not aware of, please advise and we can change it. All other "globbings" have been sorted.

Campbell Barton commented

2019-12-02 11:41:37 +01:00

@clockmender you can still remove import globbing.

pdb_commands.py would be cleaner to define a name-space to pass to eval, otherwise the user may access cmd or oper or any of the other variables.

Then it's clear which variables are intended for command access and which are needed for command execution.

@clockmender you can still remove import globbing. `pdb_commands.py` would be cleaner to define a name-space to pass to `eval`, otherwise the user may access `cmd` or `oper` or any of the other variables. Then it's clear which variables are intended for command access and which are needed for command execution.

Rune Morling commented

2019-12-02 12:48:25 +01:00

In #70238#822333, @ideasman42 wrote:
@clockmender you can still remove import globbing.

pdb_commands.py would be cleaner to define a name-space to pass to eval, otherwise the user may access cmd or oper or any of the other variables.

Then it's clear which variables are intended for command access and which are needed for command execution.

Re. input globbing: Are you suggesting that we maintain a list of valid mathematical functions from the math module instead?

We're currently looking for examples of supplying namespaces to eval().

> In #70238#822333, @ideasman42 wrote: > @clockmender you can still remove import globbing. > > `pdb_commands.py` would be cleaner to define a name-space to pass to `eval`, otherwise the user may access `cmd` or `oper` or any of the other variables. > > Then it's clear which variables are intended for command access and which are needed for command execution. Re. input globbing: Are you suggesting that we maintain a list of valid mathematical functions from the math module instead? We're currently looking for examples of supplying namespaces to eval().

Campbell Barton commented

2019-12-02 14:40:19 +01:00

You don't have to maintain a list, you can do something like this.

namespace = {
    "__builtins__": __builtins__,
    **vars(math),
}
eval(expression, namespace, namespace)

You don't have to maintain a list, you can do something like this. ``` namespace = { "__builtins__": __builtins__, **vars(math), } eval(expression, namespace, namespace) ```

Rune Morling commented

2019-12-02 16:18:42 +01:00

@ideasman42 :

Thanks. I'm afraid that I accidentally mistyped 'import' and wrote 'input' instead, so it was really two questions -- the first of which was intended to be:

Re. import globbing: Are you suggesting that we maintain a list of valid mathematical functions from the math module instead?

Thanks for the namespace example. We'll have a good look.

@ideasman42 : Thanks. I'm afraid that I accidentally mistyped 'import' and wrote 'input' instead, so it was really two questions -- the first of which was intended to be: Re. **import** globbing: Are you suggesting that we maintain a list of valid mathematical functions from the math module instead? Thanks for the namespace example. We'll have a good look.

Alan Odom commented

2019-12-02 20:38:19 +01:00

@ideasman42 We have investigated this now and are testing some new code. We will advise once the testing is complete, but early indications are that we have a solution.

The code you posted earlier caused a syntax error (it didn't like the * for some reason), but I think we have it sorted. This will conclude all the points you raised for inclusion and suggestions. Thanks for all your help.

Example:

This command (mzsin(pi/5)*sqrt(64)) set the Z input to 4.70228.

This command (mxhypot(3,4)) will set the X input to 5.

@ideasman42 We have investigated this now and are testing some new code. We will advise once the testing is complete, but early indications are that we have a solution. The code you posted earlier caused a syntax error (it didn't like the * for some reason), but I think we have it sorted. This will conclude all the points you raised for inclusion and suggestions. Thanks for all your help. Example: ![Screen Shot 2019-12-02 at 19.52.16.png](https://archive.blender.org/developer/F8185392/Screen_Shot_2019-12-02_at_19.52.16.png) This command (mzsin(pi/5)*sqrt(64)) set the Z input to 4.70228. This command (mxhypot(3,4)) will set the X input to 5.

Rune Morling commented

2019-12-02 21:42:43 +01:00

@ideasman42

We believe that we have fixed all the review nits you have mentioned, including suggestions. We've done our best to reference the relevant review nits in the commit logs.

@clockmender is doing a final testing pass of the functionality, but I thought it prudent to give you a heads up before we run into time constraints re. the 2.82 cut-off date. So if you have any further nits (or if our changes prove to be insufficient) please let us know and we will do our best to address them.

The newest commit lives on the github PDT propertygroup branch at revision 9ebd5d7.

Since we've force pushed to the propertygroup branch on github, you may need to re-clone.

@ideasman42 We believe that we have fixed all the review nits you have mentioned, including suggestions. We've done our best to reference the relevant review nits in the commit logs. @clockmender is doing a final testing pass of the functionality, but I thought it prudent to give you a heads up before we run into time constraints re. the 2.82 cut-off date. So if you have any further nits (or if our changes prove to be insufficient) please let us know and we will do our best to address them. The newest commit lives on the [github PDT propertygroup branch at revision 9ebd5d7](https://github.com/Clockmender/Precision-Drawing-Tools/commit/9ebd5d739ad6fed437424f08903ae10747d8cc70). Since we've force pushed to the propertygroup branch on github, you may need to re-clone.

Campbell Barton commented

2019-12-02 21:46:58 +01:00

The code you posted earlier caused a syntax error (it didn't like the * for some reason).

My mistake it should have been two **, I see you're using update method which works too.

> The code you posted earlier caused a syntax error (it didn't like the * for some reason). My mistake it should have been two `**`, I see you're using update method which works too.

Campbell Barton commented

2019-12-02 21:58:57 +01:00

As mentioned in my review some posts back, there are unused imports.

Going over the code with pylint, there are still quite some unused imports & variables being defined.

pdt_cad_module.py:27:0: W0611: Unused geometry imported from mathutils (unused-import)
pdt_design.py:27:0: W0611: Unused FloatProperty imported from bpy.props (unused-import)
pdt_design.py:28:0: W0611: Unused Panel imported from bpy.types (unused-import)
pdt_design.py:28:0: W0611: Unused PropertyGroup imported from bpy.types (unused-import)
pdt_design.py:29:0: W0611: Unused Quaternion imported from mathutils (unused-import)
pdt_design.py:31:0: W0611: Unused acos imported from math (unused-import)
pdt_design.py:32:0: W0611: Unused euler_to_quaternion imported from pdt_functions (unused-import)
pdt_library.py:26:0: W0611: Unused FloatProperty imported from bpy.props (unused-import)
pdt_menus.py:27:0: W0611: Unused Path imported from pathlib (unused-import)
pdt_menus.py:28:0: W0611: Unused debug imported from pdt_functions (unused-import)
pdt_pivot_point.py:26:0: W0611: Unused Panel imported from bpy.types (unused-import)
pdt_pivot_point.py:26:0: W0611: Unused PropertyGroup imported from bpy.types (unused-import)
pdt_pivot_point.py:29:0: W0611: Unused draw3D imported from pdt_functions (unused-import)
pdt_view.py:26:0: W0611: Unused FloatProperty imported from bpy.props (unused-import)

__init__.py:141:63: W0612: Unused variable 'data_to' (unused-variable)
__init__.py:173:63: W0612: Unused variable 'data_to' (unused-variable)
__init__.py:205:63: W0612: Unused variable 'data_to' (unused-variable)
pdt_command.py:223:12: W0612: Unused variable 'number' (unused-variable)
pdt_command.py:622:16: W0612: Unused variable 'nEdge' (unused-variable)
pdt_design.py:182:16: W0612: Unused variable 'nEdge' (unused-variable)
pdt_design.py:321:20: W0612: Unused variable 'nEdge' (unused-variable)
pdt_design.py:419:20: W0612: Unused variable 'a3' (unused-variable)
pdt_design.py:506:20: W0612: Unused variable 'nEdge' (unused-variable)
pdt_design.py:652:20: W0612: Unused variable 'nEdge' (unused-variable)
pdt_design.py:772:20: W0612: Unused variable 'nEdge' (unused-variable)
pdt_design.py:891:24: W0612: Unused variable 'nEdge' (unused-variable)
pdt_design.py:1072:24: W0612: Unused variable 'nEdge' (unused-variable)
pdt_design.py:1140:8: W0612: Unused variable 'pg' (unused-variable)
pdt_design.py:1146:16: W0612: Unused variable 'nEdge' (unused-variable)
pdt_design.py:1275:20: W0612: Unused variable 'a3' (unused-variable)
pdt_design.py:1317:8: W0612: Unused variable 'plane' (unused-variable)
pdt_design.py:1463:8: W0612: Unused variable 'a1' (unused-variable)
pdt_functions.py:545:16: W0612: Unused variable 'a3' (unused-variable)
pdt_functions.py:575:4: W0612: Unused variable 'scene' (unused-variable)
pdt_library.py:157:16: W0612: Unused variable 'obj_names' (unused-variable)
pdt_menus.py:83:8: W0612: Unused variable 'cursor' (unused-variable)
pdt_menus.py:241:8: W0612: Unused variable 'cursor' (unused-variable)
pdt_menus.py:287:8: W0612: Unused variable 'cursor' (unused-variable)
pdt_menus.py:323:8: W0612: Unused variable 'cursor' (unused-variable)
pdt_pivot_point.py:303:8: W0612: Unused variable 'obj_loc' (unused-variable)
pdt_view.py:236:8: W0612: Unused variable 'scene' (unused-variable)
pdt_xall.py:127:8: W0612: Unused variable 'old_edge' (unused-variable)

If you need to define variables that aren't used (data_to for example), use _ prefix to quiet the warnings.

These were generated from running:

pylint *.py | pcregrep "Unused.*(variable|imported)"

As mentioned in my review some posts back, there are unused imports. Going over the code with pylint, there are still quite some unused imports & variables being defined. ``` pdt_cad_module.py:27:0: W0611: Unused geometry imported from mathutils (unused-import) pdt_design.py:27:0: W0611: Unused FloatProperty imported from bpy.props (unused-import) pdt_design.py:28:0: W0611: Unused Panel imported from bpy.types (unused-import) pdt_design.py:28:0: W0611: Unused PropertyGroup imported from bpy.types (unused-import) pdt_design.py:29:0: W0611: Unused Quaternion imported from mathutils (unused-import) pdt_design.py:31:0: W0611: Unused acos imported from math (unused-import) pdt_design.py:32:0: W0611: Unused euler_to_quaternion imported from pdt_functions (unused-import) pdt_library.py:26:0: W0611: Unused FloatProperty imported from bpy.props (unused-import) pdt_menus.py:27:0: W0611: Unused Path imported from pathlib (unused-import) pdt_menus.py:28:0: W0611: Unused debug imported from pdt_functions (unused-import) pdt_pivot_point.py:26:0: W0611: Unused Panel imported from bpy.types (unused-import) pdt_pivot_point.py:26:0: W0611: Unused PropertyGroup imported from bpy.types (unused-import) pdt_pivot_point.py:29:0: W0611: Unused draw3D imported from pdt_functions (unused-import) pdt_view.py:26:0: W0611: Unused FloatProperty imported from bpy.props (unused-import) ``` ``` __init__.py:141:63: W0612: Unused variable 'data_to' (unused-variable) __init__.py:173:63: W0612: Unused variable 'data_to' (unused-variable) __init__.py:205:63: W0612: Unused variable 'data_to' (unused-variable) pdt_command.py:223:12: W0612: Unused variable 'number' (unused-variable) pdt_command.py:622:16: W0612: Unused variable 'nEdge' (unused-variable) pdt_design.py:182:16: W0612: Unused variable 'nEdge' (unused-variable) pdt_design.py:321:20: W0612: Unused variable 'nEdge' (unused-variable) pdt_design.py:419:20: W0612: Unused variable 'a3' (unused-variable) pdt_design.py:506:20: W0612: Unused variable 'nEdge' (unused-variable) pdt_design.py:652:20: W0612: Unused variable 'nEdge' (unused-variable) pdt_design.py:772:20: W0612: Unused variable 'nEdge' (unused-variable) pdt_design.py:891:24: W0612: Unused variable 'nEdge' (unused-variable) pdt_design.py:1072:24: W0612: Unused variable 'nEdge' (unused-variable) pdt_design.py:1140:8: W0612: Unused variable 'pg' (unused-variable) pdt_design.py:1146:16: W0612: Unused variable 'nEdge' (unused-variable) pdt_design.py:1275:20: W0612: Unused variable 'a3' (unused-variable) pdt_design.py:1317:8: W0612: Unused variable 'plane' (unused-variable) pdt_design.py:1463:8: W0612: Unused variable 'a1' (unused-variable) pdt_functions.py:545:16: W0612: Unused variable 'a3' (unused-variable) pdt_functions.py:575:4: W0612: Unused variable 'scene' (unused-variable) pdt_library.py:157:16: W0612: Unused variable 'obj_names' (unused-variable) pdt_menus.py:83:8: W0612: Unused variable 'cursor' (unused-variable) pdt_menus.py:241:8: W0612: Unused variable 'cursor' (unused-variable) pdt_menus.py:287:8: W0612: Unused variable 'cursor' (unused-variable) pdt_menus.py:323:8: W0612: Unused variable 'cursor' (unused-variable) pdt_pivot_point.py:303:8: W0612: Unused variable 'obj_loc' (unused-variable) pdt_view.py:236:8: W0612: Unused variable 'scene' (unused-variable) pdt_xall.py:127:8: W0612: Unused variable 'old_edge' (unused-variable) ``` If you need to define variables that aren't used (`data_to` for example), use `_` prefix to quiet the warnings. These were generated from running: ``` pylint *.py | pcregrep "Unused.*(variable|imported)" ```

Rune Morling commented

2019-12-03 09:42:06 +01:00

In #70238#822747, @ideasman42 wrote:
As mentioned in my review some posts back, there are unused imports.

Going over the code with pylint, there are still quite some unused imports & variables being defined.

(...)

These were generated from running:
pylint *.py | pcregrep "Unused.*(variable|imported)"

With commit 2b2c1ae the remaining Unused (import|variable) foo warnings should be fixed. This was checked with pylint -j0 -d all -e W0611,W0612 *.py which gave the output:

--------------------------------------------------------------------
Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00)

We apologise for you having to cover the same ground twice. We're still trying to get in the habit of using pylint before each commit.

pylint version info on my box:

$ pylint --version
pylint 2.4.4
astroid 2.3.3
Python 3.7.5 (default, Nov  8 2019, 03:33:56) 
[GCC 9.2.0]

> In #70238#822747, @ideasman42 wrote: > As mentioned in my review some posts back, there are unused imports. > > Going over the code with pylint, there are still quite some unused imports & variables being defined. > > (...) > > These were generated from running: > > ``` > pylint *.py | pcregrep "Unused.*(variable|imported)" > ``` With [commit 2b2c1ae ](https://github.com/Clockmender/Precision-Drawing-Tools/commit/2b2c1ae13fa0efd0ad7d12ef41461fa89599efa9) the remaining `Unused (import|variable) foo` warnings should be fixed. This was checked with `pylint -j0 -d all -e W0611,W0612 *.py` which gave the output: ``` -------------------------------------------------------------------- Your code has been rated at 10.00/10 (previous run: 10.00/10, +0.00) ``` We apologise for you having to cover the same ground twice. We're still trying to get in the habit of using pylint before each commit. pylint version info on my box: ``` $ pylint --version pylint 2.4.4 astroid 2.3.3 Python 3.7.5 (default, Nov 8 2019, 03:33:56) [GCC 9.2.0] ```

Campbell Barton commented

2019-12-03 12:05:13 +01:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2019-12-03 12:05:13 +01:00

Campbell Barton commented

2019-12-03 12:05:13 +01:00

@ermo thanks for resolving these issues, as far as I an see the add-on is ready.
I've emailed @clockmender, adding him as a committer to the add-ons project.

@ermo thanks for resolving these issues, as far as I an see the add-on is ready. I've emailed @clockmender, adding him as a committer to the add-ons project.

Rune Morling commented

2019-12-03 12:54:09 +01:00

@ideasman42

Thank you very much for your patience and input during the review phase.

We shall endeavour to keep improving the quality of the add-on (re. pep8 compliance and pylint warnings) as we develop it further in the future.

@ideasman42 Thank you very much for your patience and input during the review phase. We shall endeavour to keep improving the quality of the add-on (re. pep8 compliance and pylint warnings) as we develop it further in the future.

Peter MOUEZA commented

2020-04-19 11:11:19 +02:00

Added subscriber: @PeterMOUEZA

Sign in to join this conversation.