ahoeben

I have made some progress in detecting the issue, and made a "pull request" here: https://github.com/Ultimaker/Uranium/pull/478 Unfortunately this needs to be fixed in a place in the Cura code that is not easily accessible. So it needs to be integrated into (test-)builds before it can be tested on affected OSX machines.

In that case I did not understand your question. I though you did not have a buildplate model at all.

"deprecated" does not mean it will no longer work. Cura does not talk directly to the GPU or to OpenGL. It uses a cross platform GUI framework named Qt. We're going to have to see how Qt will handle the deprecation of OpenGL.

This is only possible with printer definitions, like the ones listed when you Add a printer to Cura.

In Marketplace there is an “Installed” tab. You can disable plugins there. You still have to restart Cura.

It means I am still trying time to work on it in my spare time. Even if I or someone else fix it, you will have to wait until the next release of Cura.

Perhaps making a set of links (shortcuts) in a folder that you can reach with the dialog is a viable workaround.

I don't understand the question.

It could be that your GPU does not support the features needed for the full layer view and reverts back to “compatibility mode”. Then there is no animation slider.

A better place to install you script is in the "scripts" folder of the configuration folder (Help->Show configuration folder). That way it should migrate survive installing a newer Cura version. Also on OSX and on Linux, putting the file inside the application bundle may not be possible.

You would rather have no people putting their time in to fixing this issue? Ok, I guess.

@hoegge you might like the Sidebar GUI plugin that is available in the Marketplace. It reverts some of the UI changes and rearranges some functionality for those who think the sidebar interface is superior.

Actually, it gives you exactly what you ask for. You ask for a 4.1 context, you get a 4.1 context. It is unfortunately that you can not ask specifically for a hardware accelerated 4.1 context. I had a look. The problem is that you need a window to query the gpu_type (or gl.initializeOpenGLFunctions will fail and subsequent gl.glGetString calls will segfault). So OpenGLContext would need to open a (small, invisible) window to check the gpu_type of the context. I'll try to continue this train of thought later today.

Note that the same can also happen on Linux if you run Cura in a virtual machine (depending on the VM).

I would consider such a preference a workaround. This can be detected by looking at the opengl context description. It is just not something that needed to be done before. This is what happens on other Windows and on Linux (and on older versions of Cura, which used an older version of Qt) with a GPU that does not support the advanced opengl features): Cura: Hey OS, can I have an advanced rendering context? OS: No, sorry, the GPU does not support that Cura: Ok, can I have a simpler rendering context? OS: No problem, this GPU can handle that just fine Cura: Ok, awesome! I'll just use the simplified layerview. On OSX, with the same hardware, the following happens: Cura: Hey OS, can I have an advanced rendering context? OS X: Sure thing, here's your context (it uses software rendering, but you don't mind, right?) Cura: Ok, awesome! I'll use that context for everything! That last "Ok" from Cura is the problem. Cura should not accept software rendering when asking for an OpenGL 4 context at the start of Cura.

As a direct answer to why Cura is so slow on your computer: Instead of drawing the interface and the gcode using hardware acceleration, everything is being drawn using a software renderer. This happens because your hardware renderer does not support OpenGL 4.x. But instead of OS X saying "sorry, I don't support that" (in which case Cura would use OpenGL 2.x which your computer does support and everything would work ok), OS X says "sure, I can do that" but then proceeds to do everything really slowly. In a future version of Cura, this oddity must be detected and worked around.

It should be unchecked.

In Machine Settings, is the "Origin at center" box checked? It shouldn't be (unless you have a Delta-style printer).

There are literally hundreds of issues with all versions of Cura. Missing features and things that don’t work correctly. See https://github.com/ultimaker/issues. Each new version of Cura has fixes for some issues, but new issues get reported constantly (many of which are issues with previous versions too). The release notes contain a list of fixes in 4.0. Most of these fixes are issues with 3.6. Does that mean you cannot use 3.6 if you prefer it? No. Use what you like. But be aware that there are issues with it that are fixed in Cura 4 that will not be fixed in Cura 3.6. One example is that supports have a tendency to extend all the way to the buildplate, even if they encounter a piece of the model that does not need support. PS: if you are asking this because you don’t like the new UI, try the Sidebar GUI plugin from the Marketplace.

I am sorry, I thought you were asking us how Cura works.

It is more like insisting to be able to drive with wheels without profile, because you don’t want to have the choice between summer- or wintertires. Most settings in Cura intrinsically affect slicing, whether you want to be able to change their value or not. You cannot print without a print speed; there HAS the be a speed. You can hide the setting, but there is still a value.

No, there is no way to make start gcode snippets conditional.

That is a default tooll (Support Blocker). It does have a tooltip, but only when it is enabled (and these “tools” are not enabled when there is no model selected)

Could you show a screenshot? Given that most of Cura is implemented as a plugin, I don’t think it is a good idea (or even feasible) to force plugin controls to look differently.

This is why I cringe when people instruct new users to make all settings visible as a first step. Don't do that. Stick with the basic set, use the search field for options that you heard about, and if you end up using them a lot you can make them visible. To answer your question: settings that are not visible still have a value, and affect your print. Most settings have a "sane" default value, especially if you use a printer that has specific profiles (that someone tweaked from the default defaults). But if you enable supports and then make the Enable Supports setting invisible, supports will still be printed.