fieldOfView / Cura-MeasureTool

Cura plugin which adds a tool for measuring parts of models
GNU Affero General Public License v3.0
42 stars 8 forks source link

[cura 4] UM.Label is not a type #21

Closed smartavionics closed 2 years ago

smartavionics commented 2 years ago

Hi, just installed this plugin in my cura 4 world and it doesn't appear to work. I also see messages like the following in cura.log...

2022-05-20 15:52:14,087 - ERROR - [MainThread] UM.Controller.getTool [263]: Unable to find  in tools
2022-05-20 16:00:10,554 - WARNING - [MainThread] UM.Qt.QtApplication.__onQmlWarning [424]: file:///home/markb/.local/share/cura/master/plugins/MeasureTool/MeasureTool/resources/qml/MeasureTool.qml:58:9: UM.Label is not a type

Thoughts?

5axes commented 2 years ago

Hello @smartavionics

It's because you don't follow the rules concerning the version information in your Master release. And this is realy a problem for the other developpers, including me (Even if I can't call myself a developer).

As all your Cura Version are only unditified by Cura Master (Major = 0 Minor =0) we cannot have the information at what "Level" of devellopement you are. And in this case as @fieldOfView is apparently not a user of your Cura Master release he haven't manage this particular point.

So when in the Init.py he made the test to determine which version of QT, cura is using the plugin made the error to switch to QT6 where we can use the QT6 UM.Label type , A type not reconized in version 4.X

Solution number 1 : ( refereing to this discussion https://community.ultimaker.com/topic/40380-advice-to-update-a-tool-qml-plugin-file/ Thanks again for your help @fieldOfView ) I take the decision to test directly the validity of the QT version.

Or Solution number 2 and It would simplify the code of many of my plugins, give the information on the Major and Minor indentification of your Cura Master (and not 0.0 as we have now, why not use 4.14, 4.15, 4.16 etc. since Ultimaker should not increment these numbers in the future )

And I take this opportunity to thank you for the work you have done on your CURA versions. Which is still my working version.

fieldOfView commented 2 years ago

Thanks @5axes, I could not have said it better.

This is a problem with diverging forks. Before Ultimaker releases a non-master version of a new release (with a numbered application version), I have to assume that someone running a master version (like me, running the Ultimaker master release) is using the latest and greatest Ultimaker master. If your master branch diverges from their master branch, then that is a problem for me (and/or you).

smartavionics commented 2 years ago

Thanks @5axes , that's all understood. I'll give some thought to providing version numbering.

smartavionics commented 2 years ago

OK, I'm thinking that I will give my releases major/minor version number 4.20 and will increment the patch level for each subsequent release. i.e. the releases will be numbered 4.20.1, 4.20.2, etc. They will all be installed in the tree at 4.20 and not in separate directories. In the unlikely event of me producing a release that is markedly different, I can always move to 4.21, etc. If you folks have any objections to that scheme or a better idea, please open an issue at https://github.com/smartavionics/Cura/issues so we can discuss it.