ahoeben

For the record: setting a compatibility mode, or running as administrator should not be necessary. At this point it is still a mystery why this is needed on some systems, and not on (most) others.

If you create a feature request at github, it will be marked as a duplicate of this issue: https://github.com/Ultimaker/Cura/issues/2779 You could add your 2 cents there, but also read why this feature is more complicated than it may seem.

Then you would have 3 parts written in 3 languages communicating with eachother. I don't think that would result in fewer edge-case issues. One of the major issues on windows is that CuraEngine sets up a server for communication with the frontend; some anti-virus applications either block CuraEngine for it, or at least the communication between the two parts. I am not a fan of full rewrites, and much more in favor of incremental refactoring. If you remember legacy Cura (15.04 and older) and the painful releases of the first, totally rewritten 2.x versions, you know how much a rewrite can break or how much of your workflow can just vanish in a rewrite. There's a lot that does work in Cura, a total rewrite will mean that those parts also have to be redone. I don't entirely agree with your sentiment about the "PyQt nightmare". I don't think PyQt is the problem. Trying to support a wide variety of systems and platforms is. There will always be systems that have issues running sufficiently complex software, and those users will complain. But you won't hear the masses of people for which the software does work. Handling massive polygon count objects in a browser engine doesn't magically solve issues it means that there is a harder cut-off of what computers will be supported.

Cura comes with firmware for both the UM2 and UM2+. Try those.

Cura is bound to Python in much more than just its GUI. Even profiles and printer definitions contain Python code to specify relations between settings. If you want to handle these profiles and definitions in the browser, you would either need a Python interpreter in the browser, or accept that there will be no backwards compatibility.

You have probably flashed the wrong firmware, ie the firmware for the UM 2+ instead of the UM 2. Flash the proper firmware for your printertype and it should work correctly again. edit: @gr5 beat me to it.

You can disable highlighting the overhang on the General pane of the preferences.

The plugin is now available in the Marketplace. Quite a bit more work needed to be put in this plugin, to get the Print settings in the Material preferences to accept valid values for additional settings. In fact, the plugin now replaces the whole Materials pane of the preferences with a "fixed" version. There is a cosmetic sideeffect to this: the print settings tab now uses the Cura theme, ie if you use a dark theme for Cura, that part of the preferences will now also display using dark theming. I hope you find this plugin useful.

If Cura for the Mac would be written in OSX-specific code, the WWDC announcement would help for an iPad version. However, Cura is written for a large part to be cross-platform between Windows, Linux and OSX. That makes Cura not entirely OSX-specific. Case in point, the Cura GUI is based on a programming language - Python - that is not available on iOS. In other words: don't get your hopes up.

Impressive!

CreawsomeMod is currently being integrated into what will become Cura 4.2. Edit: thanks for the likes, but the work has being done by Eric Ptak and @ghostkeeper here: https://github.com/Ultimaker/Cura/pull/5961

That is not necessarily true. A profie *can* be filament specific, but you can also create profiles ("definitions") that can contain all the same settings that a per-material profile would have, eg if your printer only supports one filament type.

@derei, you don't need to write a printer definition to use Cura if your printer make/model is not listed. You can add your printer as a "Custom FFF Printer" and then fill in the details (dimensions, number of extruders, nozzle diameter) of your printer. Then you can explore all the settings in the Cura interface. Writing a printer definition would normally be done by a printer manufacturer, or an experienced community member and added to the Cura download so it is easier for other users of the same printer to start using Cura. But before you start doing that I would suggest you first get more experienced using Cura and your printer. If you do continue on your effort of writing a definition (and quality profiles) for your printer (which - again - is not necessary to use Cura with your printer), get comfortable with reading the logs (cura.log). If your printer definition does not show up in the list, the logs should tell you why. Don't start with fdmprinter.def.json, but inherit from it. Take a simple definition like the 101Hero and learn from that. Note that you also need to create an extruder definition. https://github.com/Ultimaker/Cura/blob/4.1/resources/definitions/101Hero.def.json https://github.com/Ultimaker/Cura/blob/4.1/resources/extruders/101Hero_extruder_0.def.json

CuraEngine does not use the surface normals. These can often be incorrect (or missing altogether). Instead CuraEngine first slices the model into layers (from the bottom up), and then does a pass over each layer from top to bottom to see if the layer underneath it properly supports it. If not, additional support structures are added.

The “add network printer” functionality is limited to Ultimaker printers at the moment. Someone would have to contribute a plugin to have Cura talk to smoothieboards over the network.

There is no way to print from OctoPrint to an Ultimaker 3 or S5. Connecting the printer directly to your raspberry pi is unlikely going to be useful; the printer expects a DHCP server on the network it is connected to, and the raspberry pi is not normally configured to include a DHCP service. If you want them to be able to "talk" to eachother, it is best to connect them both to the same network instead of directly to eachother. Edit: But this will in no way help OctoPrint control the Ultimaker 3 or S5/S3. You can find the documentation for Cura Connect (now Ultimaker Connect) on your printer: http://(address of your printer)/docs/api/

So, do like @P3D suggested:

There don't seem to be any printers using this feature in Cura 4.1. It seems this feature has not yet been implemented in CuraEngine for Cura 4.1.

Have you tried with (appimagename).config instead of (appimagename).home? Cura should respect the $XDG_CONFIG_HOME environment variable. https://github.com/Ultimaker/Uranium/blob/4.1/UM/Resources.py#L339

@shakeNbake444 does have a good point that there is no *menu* at the moment though. Menus are more (keyboard-)accessible than onscreen buttons. So maybe it is a good idea to have a way to open the Marketplace from a menu-item in addition to the onscreen button.

This is correct. The first line tells the bed to go to 0.1mm. The second line tells the printer to from now on (until the z axis is homed) consider that position as 0mm. So effectively every following Z coordinate will be 0.1 mm further away from the bed then after homing the z axis.

In Cura 4.1, the place to get plugins is named “Marketplace”, and you can access it through a button in the top right of the window (not through a menu). Some people seem to think it is a good idea to change this every other version of Cura. So any menu, plugin browser or toolbox would be from an older version of Cura.

You can not do arithmetic in Gcode snippets in Cura, sorry.

Sure, see the Cura downloads page. But it is also really easy to just set that Maximum Z Speed to a non-0 value.

I don't think it is a hardware problem at all. It sounds like a (known) Cura 4.1 issue. Cura 4.0 is not affected, and the issue is reportedly fixed in (the sofar not yet released) Cura 4.2. If you have Z-Hop enabled, this could also happen mid-brim. Please try setting the Maximum Z Speed value to 5 (or so), instead of 0.