ahoeben

Sure: * Change the drive letter * Put a disk/card in the drive/cardreader

I would guess VMWare Tools (or similar on other vm software)

These are typically added in a "Pull Request" on Github. * clone the master branch of the Cura repository, * create a new branch on your cloned repository * add your files to that branch * use the Github interface to create a pull request of your branch against the origin master branch https://github.com/ultimaker/cura

Though the new versions of the plugins have been approved for the Marketplace, availability has been further pushed back. It turns out that if I were to publish them to the Marketplace, they will become unavailable for Cura 3.6; there currently can only be a version for Cura 3.6 OR for Cura 4.0 in the Marketplace of any given plugin. I'm told the Cura team is working on a solution.

Wait, did you change the "Mesh type", or did you add a setting using the "Add settings" button?

Check the slice in Layer view. Does the model show there?

Currently there is only a beta version of Cura 4.0. The plugin will work both with the upcoming second beta and with the final/stable version of Cura 4.0.

Huh, that's an interesting one. The "thing" that you see is indeed the layer number box. Clicking and dragging the slider area between two top and bottom nubs lets you drag them both at the same time. The layer number box behaves correctly in the current code-base (which will become Cura 4.0 BETA 2), so I think I will let this one slide for now; it will fix itself for once ;-). Thanks for noticing it though. Don't be sorry, it is exactly why I post a beta before publishing the plugin.

A new version fixes both issues raised by @Alfsoft: http://files.fieldofview.com/cura/SidebarGUIPlugin-v6.0.0-2019-01-08T17_26_30Z.curapackage

That would be great. I would love for this plugin to become redundant in a couple of releases.

That space is supposed to be used by the sidebar. In the words of Bill Gates: "That must be why we're not shipping it yet". I think it is because of a change that happened after the Cura beta was created. I'll investigate.

I have written a plugin that adds an alternative interface to the Cura 4.0 beta. A beta version of that plugin can be downloaded here:

A prerelease version of the plugin is now available: http://files.fieldofview.com/cura/SidebarGUIPlugin-v6.0.0-2019-01-08T12_09_37Z.curapackage After downloading, you can install the plugin by dropping it into a running Cura 4.0 BETA window. Restart Cura, and you should get a sidebar in Cura 4.0 beta. Needless to say, installing the plugin in Cura 3.6 does not work. I have some more changes planned before submitting the plugin to the marketplace. There are still some alignment issues, and I want to move the two elements in the lower right corner into the sidebar. I'm also open for suggestions, but note that the aim of this plugin is not to add new functionality but to carefully rearrange existing elements and functionality. Finally, I want to mention that this plugin is not meant to undermine the work that's been done by the Cura UX designers. While their work has been user-tested at the wireframe level, mine's just what I think works better. I am cheating by offering you something more familiar looking. I like the "summaries" provided in the top bar of the 4.0 UX, but for me there are too many little issues with the collapsible panels. I think the new 4.0 UX will eventually evolve into a productive interface, but until it is, here's an alternative.

A pre-release is imminent; There are still some alignment issues to work out, and there's certainly still room for improvement, but the plugin now provides a fully functioning UI. I'll post a version to test with the Cura 4.0 beta tomorrow later today.

You can make layer view a lot faster by turning on the "Force compatibility mode in layerview" (or something similar) setting on General pane of the preferences. A real fix will have to be made in Cura (rather Uranium) in Cura 4.1 I think.

Thanks, this confirms it: - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [99]: Initialized OpenGL subsystems. - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [100]: OpenGL Version: 4.1 APPLE-16.7.4 - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [101]: OpenGL Vendor: Apple Inc. - DEBUG - [MainThread] UM.View.GL.OpenGL.__init__ [102]: OpenGL Renderer: Apple Software Renderer

There lies the problem. It should only be able to show compatibility mode, because your hardware does not support the normal mode. Can you post a cura.log (Help -> Show configuration folder)? I would like to see if it is possible to detect the software rendering. @nallath, perhaps there should be a way to force an OpenGl 2.0 context on OSX. Apparently with the currently used Qt version, OSX will create a software backed OpenGl 4.1 context, instead of failing to create that context.

What @Steverc1572 and @PatK say together just about describes an issue. I'm guessing it's the same issue. PSA: please be a bit more descriptive when reporting something. What did you do (step-by-step), what did you think would happen, and what happened instead. Especially that step-by-step description is often important to be able to reproduce a bug. A bug that cannot be reproduced often can not be fixed. Finally, it is very helpful if you mention what printer type you added in Cura.

Could you check something for me? Does the Layer View legend show "Compatibility mode"? Both the 2007 iMac 2.8 Ghz and the mid-2010 Macbook Pro 2.66 Ghz seem have GPUs that don't support OpenGl 4.1. Whereas Cura 3.4 used to fall back to OpenGl 2 in such cases, it may be that the newer version of Qt that Cura uses (the UI framework, not QuickTime), results in a software-emulated OpenGl 4 context which would definitely explain the slowness of the user interface. This is just a hunch though, based on seeing something similar happen in a virtual machine.

Unfortunately you give us very little to go on to help you. We don’t know what printer you use, let alone what settings. I can only guess you incorrectly set the “Origin at Center” option in the Machine Settings dialog. It should only be used for delta-style printers.

I think that would be outside the scope of this plugin. When I implemented the Setting Visibility presets menu (the hamburger menu next to the search), it was always my intention to add the possibility to create custom sets (ie: save your current visible settings in a custom preset, and be able to switch to/from that). Would that satisfy your request?

I'm not sure. It is the account that works on https://account.ultimaker.com/ I think that's the same account you use for the Cura Backup plugin.

The most reliable way of creating a curapackage is to create an account at https://contribute.ultimaker.com That is the portal to submit a plugin to the Marketplace, and its backend actually creates the curapackage from your sources (which you upload as a zip) and some metadata you fill in to a form. Before you "submit" the package for inclusion in the Marketplace, you can download and test your curapackage.

Pieces are slowly falling into place. It is all a bit fiddly to do, because I am pushing the plugin system a bit further than it was designed to go. I think I might use the now empty space below the Prepare/Preview/Monitor menu for a print-settings-summary like the header for the settings view in the normal interface. Thoughts? Still to do before I release a test-version: extruder-tabs and material/print core selection in the sidebar fix layerview slider positions