thopiekar

Oops, play on words again. ? But seriously now.. Are there reasons why a community version would require a different name? Cura is no (TM) in any way, right? ?

Meh, a simple unbranding of Cura-vuild-environment would be enough. On the splash screen it would be enough to call it either simply Cura CE or Cura Community Edition. Would rename CuraVersion.py.in into CuraConstants.py.in and set there the default theme. So within CMake and buildtime we can choose the community theme. From my point of view this is done. Already had unbranding in mind for my PPA, because people might think it is UM driven, but it is not. So how many people do you think could we get together?

I know. I never said that a lot of effort is needed for it. It really depends on how much the community is willing to do in terms of development and testing. Ultimaker does a lot to test their software and the people employed are doing very good. However, it seems from the feedback here that this is too less. Building an infrastructure, like @smartavionics and I already brainstormed on, really need more people to keep it up. I can also imagine that UM could jump on and help out with computing resources, but first, it needs a proof of concept and this again needs human resources. This is finally from my experience, what will fail in the community I guess - there are simply too few people, who want to get active and get (big!) things moving. That is, by the way, the reason, why I'm stepping back from community work (very) slowly.

Well, the solution I had in mind is again a bit over complexed, but if you have the resources, then it is the most elegant way I think. I would personally never merge inthings into -next too early because if something is going wrong you need to get the code out of those -next branches, before they get merged into newer releases and consequently master. Well, the community can either wait for a solution by UM or just kick asses, set such an infrastructure up and prove this kind of CI setup is really needed Of course, you can wait for a solution, but do not complain that nothing is happening (or seems so). . People in the community often underestimate the power they have to influence. Only thing to do is finding people with the same interest and push hard to what you want. However, that is my impression.

I think basically all people are the same. Beginners are quite the same as business customers. Once they get disappointed you are losing them (worst case) forever, because of the disappointment which gets associated with the product based on their experience. Actually everyone wants stable software, but most people get tempted by new features. I'm the best example: everytime I f**k up my computer (oh, that's already a while ago) I tell myself: I have to use an LTS or Debian stable. But it takes around 1 week until I begin to upgrade again. Yesterday night I took some time before sleep to think about it. I branch layout I have in mind is even more complex then you suggested. Together with CI I would create for every minor version (eg. 3.2 and 3.3, etc.) a branch with a -next suffix where every change is included, which is not well tested and release. Whenever a serious bug is there, I would create a branch, eg. 3.2-CURA{ticketnumber} or *-GITHUB{issuenumber}. Whenever something is pushed there, a new build is triggered, which builds a new installer for windows or AppImage for Linux. To ease people to report is has been fixed there, we could add an plugin, which adds an button below the toolbox area. This one could have too selections, eg. ? and ?. Culture-wise I doubt there are many people who don't know what it means. As soon as a test build hits more than 10 tests, with a ratio of more than 9:1 successful fixes, the branch could be automatically merged into the brnach of the minor version. The art of all of this is to care about finding the bug at the oldest version. Then all versions upwards can benefit of it. At this point your suggestion of defining what a LTS is could kick in and define that eg. 3.2 is the current LTS. @Anders Olsson No, the question was not meant for you but still interesting to hear about your impressions how the Cura development does recently. Regarding your quality problems, I would recommend to slice your model and compare the GCode, highlight the changes and differences and report it on GitHub or the forum here, so someone can help. As a conclusion I see understand now, why the development goes too rapidly for you. Currently I don't have much time anymore to help out, but maybe I can help somehow in a different way.

Good point. The few people are then maybe also not so sensitive to errors.. So when thinking of the workflow when fixing bugs or adding new features. What would you change? Do you already have a strategy in mind? I wouldn't differentiate between the community and business/end-users. What actually counts here the most, is that your suggested stable/beta/dev flavours need to be deployed to the users more easily and I think this can be easily done(!).

Hmm, I understand the benefits, but it is always a question of time, whether it is worth the effort - just like @nallath mentioned before. Because I know him a better, I'm sure he has a good estimation based of his work experience of how much time in addition it would take. Is your experience of disappointments around Cura based on other people, too? I personally don't hear much of this kind of feedback. (Maybe the question should be asked whether we couldn't make bug reporting easier, so we get more and earlier feedback on found bugs?)

I personally don't think an LTS makes sense. The reason why there are LTS versions in Ubuntu is that packages are maintained for a long time while having stability and security in mind. So in my opinion, if someone likes to have an LTS-ish feeling while using Cura, she/he should simply pick the last release with a patch version >= 0. Security-wise Cura is not that much connected to internet services, that you need to worry about breaks there. From my feeling stability issues are taken always serious at Ultimaker, so it is always a question of time until a fix is there and until then you can always redownload the previous version from the website. If people (or the community itself) think it is not stable enough, then they can also bake their own version and cherry-pick the fixes only. But I doubt that there is a group (large enough), which has time and the capacity for it. @Anders Olsson: * Fixing bugs is not always as trivial as it sometimes seems. In my opinion, you need to find a red line and skip fixing bugs from a prioritised list, because the fixes, which have been found, need to be shipped to. Therefore I think it is fine just to wait for the next patch version or major release. * The default is the simplified view, which does not provide access to all the features. I personally wouldn't like to add more buttons there. Once people will decide to add more options there, then all the other use-cases will come up and the simplified view will get the new advanced view. Comparing Cura to other professional software, I would say that once people want to print more complex things like this, they simply need a training in using Cura. Cura is a professional 3D-slicing software and giving up all the great parameters and options it has would be stupid. I can imagine a lot of effort would be invested into finding relations between the settings, a lot of assumptions would be done on the customer, which maybe don't happen or fit, and, finally, the end-user would be disappointed, because something is not printable. The only thing I agree about is something that @smartavionics kind of mentioned: longer beta/test cycles. I think it is no secret anymore that Ultimaker creates daily nightly builds. I see no reason why releasing them in public (excluding internal secrets) would be an issue. The sources (cura-build-*) to build Cura are already public. In theory, everyone could build a nightly version on their own, but that is less comfortable, so most potential testers keep using either the last release or go for the early beta. (Guess that is enough from my side for now ?)

Haha, thanks @tetrahedron Just let me know if something does not work. If I don't get any feedback from someone, I can still overlook something. The better the documentation of the symptoms of the bug and the stronger the argumentation why fixing it counts (for all people), the earlier I'll take some time on it. Again, thank you for your efforts, because it seems you only registered for the forums here to join this thread! ?

Great! I'm in talks currently to get this plugin into the plugin browser, too. https://thopiekar.eu/download/CuraInventorPlugin-0.2.2.curaplugin There are no big differences regarding features, but some stability fixes inside. @StS Do you (still) face the issue with 3.3.1? When doing my own tests here with the package above (v0.2.2) I didn't noticed any issues using 3.2.1 and 3.3.1. Or do @tetrahedron and you belong together and the issue has been solved? Regards and thank you for giving feedback here!

Yes, but more advanced. Checks whether the JSON is valid, whether there is a __init__.py in the root directory of the plugin, etc. thopiekar@home:~$ python3 cpo.py -h usage: cpo.py [-h] [--source SOURCE] [--exclude EXCLUDE] [--downloaddir DOWNLOADDIR] [--build BUILD] [--destination DESTINATION] [--variant {binary+source,binary,source}] [--compression {none,zlib,bzip2,lzma}] [--optimize {0,1,2}] [--gitargs GITARGS] optional arguments: -h, --help show this help message and exit --source SOURCE, --src SOURCE, -s SOURCE Location of the source folder --exclude EXCLUDE, --excl EXCLUDE, -e EXCLUDE Location of the source folder --downloaddir DOWNLOADDIR, --dldir DOWNLOADDIR, -dd DOWNLOADDIR Location of the download folder --build BUILD, --bld BUILD, -b BUILD Location of the build folder --destination DESTINATION, --dest DESTINATION, -d DESTINATION Location, where to place the resulting package --variant {binary+source,binary,source}, --var {binary+source,binary,source}, -v {binary+source,binary,source} Variant of build --compression {none,zlib,bzip2,lzma}, --comp {none,zlib,bzip2,lzma}, -c {none,zlib,bzip2,lzma} Package compression --optimize {0,1,2}, --opt {0,1,2}, -o {0,1,2} Location of the build folder --gitargs GITARGS, -ga GITARGS git arguments I'm close now to build a plugin package using GitLab on each commit I do. This way it is easy to distribute these packages to testers.

@gr5: Good catch! Just posted the wrong URL. The correct one is: https://thopiekar.eu:5443/Cura/cura-build-environment/pipelines @ahoeben: By "building" I meant creating a .{cura, um}plugin file. Also have a script lying around here called "CuraPluginOven", short CPO. It is a full command-line tool, so you can either pass a local or a remote git repo and it builds a plugin file. Also comes with come checks, whether all conventions are met. This could be added in theory, too. By when writing the first post I had the situation in mind when you need additional (3rd party) Python modules (C-extensions). Also as far as I remember, I managed to rebuild Numpy and SciPy in the early days (approx 3 months before). So Cura could be fully OpenSource *without* Intel MKL blobs. In short: The bundle you can download is a rootstrap, which is fully usable with user-rights. Had yesterday a talk at the booth in Hannover and got feedback, that people might be interested in this here.

Hello everybody, while working on Cura plugins, I worked for myself on a solution to make developing and building plugins as easy as possible. So I took cura-build-environment and expanded it with many dependencies, which are normally not built and need to be installed before. Also to be able to build plugins automatically on mid-class[2] network-attached-storages (NAS), I was looking for a hassle-free way to build plugins or Cura itself there, too. Now I ended up with a full prefix with all dependencies except a C/C++ compiler for Linux. Once built, the development flavour comes with Git and CMake. On Linux, it comes with AppImageKit, like in cura-build-environment at the moment, but on Windows, it comes with dependencies you normally need to install or build yourself, like NSIS. All you should need to start Cura from source or your development at all is using one of the scripts to dive in. Features (and already done): * Comes with all dependencies needed to run Cura * Provides possibility to compile different flavours (minimal, development, proposed) * Allows overriding all download URLs with a local cache, so changed URLs won't break builds. What is going to be done soon: * Adding GCC or LLVM for compiling * Adding scripts to fetch Cura from GitHub and run it directly. At the moment there are no instructions and this thread is only meant for brainstorming basically. Before putting any further efforts into this and releasing any code, I would like to know what your overall thoughts are. However, anyone who is curious can download it builds from the link below [1]. -------------------------------------------------------------------------------------------------------- [1]: https://thopiekar.eu:5443/Cura/cura-build-environment/pipelines [2]: Which performance I define around: 2-Core CPU and >= 2GB RAM

@SandervG & @Ultimaker: Thank you for the credits again! Was great to see you at your booth at the Hannover Messe yesterday again! ?

Interesting bug. Looks like both environment variables are not set on your computer.

Many thanks for your kind words! Hope I will find a way to get direct access to SolidWorks soon again. There is much to do, like replacing the macro with an addon. So the installation of the button could be replaced with an installer and therefore no additional (manual) setup would be needed. It also opens drawings Ok, not truly. It looks up, which part or file is used inside the drawing and opens this file instead. Together with Ultimaker's QA all remaining issues inside the plugin have been fixed. Only thing that is left is a bug in Cura, which does not properly unload system libraries, which are included in the plugin. Therefore it can't uninstall the plugin, which is a new feature that will come with Cura 3.3.x. Hope there will be a solution soon.

Yes, it is possible. And since you both mentioned it already, it seems like this feature is something that is really needed. I'm planning to commonize the configuration dialogs for all plugins. This way I save again time on mantaining the SolidWorks and Inventor plugin (which has at the moment no UI at all).

With additional info by Ultimaker, I could reproduce it and fix the issue. Therefore: 0.5.5 is out!

Today I got feedback from Ultimaker's QA about the plugin. They reported the following error and it would be nice if someone of you could try to reproduce it. According to them the "Next" button in the macro guide does not respond to clicks after opening it for the second time. For me, all buttons work just fine and it does not matter whether I close the window in between or not. I'm wondering whether you noticed the same. Thanks! -----------------------

Hey, and you can confirm the file exists: ? I can try to take some time today and explain to you how to use a "dependency walker". As many other Windows libraries (*.dll-files) also this module probably depends on a file, which is not installed on your computer. (For a reason I don't know.) The dependency walker will recursively check what is missing. Regards

@AbeFM : Yes, this is in a good range. Well, as I said before, just change the values in the .py files and feel free to experiment. In general: Are there any crashes so far? Anything not working or any other feedback? I'm planning to let Ultimaker know of this version, so it gets into their plugin server. I guess having it tested under SWX 2016..2018 and no crashes for a week are a good reason to do that.

Also meine Erklärung ist, dass man in dem Material irgendwelche Unreinheiten hat (beispielsweise Nebenprodukte der Polymerisation) die nicht durch die Düse durchdringen können. Man darf sich aber diese Unreinheiten nicht wie ein Weinkorken vorstellen, der die Düse exakt verstopft, oder wie der Stopfen im Waschbecken. Die Verunreinigung ist vielmehr wenn du die Hand an den Abfluss hälst. Die Flüssigkeit findet immer einen kleinen Spalt an dem es vorbei kann und wo der Druck (Umgebungsdruck) geringer ist als in dem Extruder. Gratualtion! Auch ein Ärgernis das ich mal erlebt hab, aber jetzt nicht erwartet hätte. Find ich auch ziemlich fieß, wenn man einen lockeren Knoten macht, es nicht merkt und während des Drucks sich dieser festzieht. Wünsche dir weiterhin viel Erfolg beim Drucken

Please tell us more about your system. Windows version, graphics card incl. driver, etc...

Well, if you want to experiment with these values, then you can modify the plugin since it comes with the source code. You just need to edit the SolidWorksReader.py and change the values. I personally have the fear that if I set these values too fine, then it might blow up your hard drive (because STL and 3MF files are saved into your temporary directory) and loading this file will take unnecessarily more time. After you changed these values you can see in the log how big the temporary file was after conversion. So if you have some time left, then modify the values and observe how the filesize is behaving. I totally agree, that there is room for improvements, but there must be a balance between three points: total time of the process, needed space on the harddrive and the fineness of the final mesh in Cura. Yeah, I agree there should be a way to set custom values. My current goal is commonizing more code across the different plugins. So eg. the Inventor plugin is also benefiting from it. This should decrease the needed amount of time to maintain these plugins, so I will find more time for more valuable things.