Cura adds double .gcode (.gcode.gcode) when saving sliced file.

[horga83]

Cura, currently 4.0 under Linux

Saving an STL file after it has been slicedt as *.gcode, Cura fills the name in with .gcode.gcode at the end of the filename.

Example: open "my3dprint.stl", slice it and save file, Cura will offer the name as "my3dprint.gcode.gcode" instead of just "my3dprint.gcode"

[Ellecross]

Hey @horga83

Please next time use the template for reporting the bugs.

Can you please try on 4.1?

Here's what I'm doing: (I'm using Ubuntu)

1. Load an STL file or Gcode
2. Save File as Gcode

I get only one suffix of *.gcode.

Also,

[rburema]

I could not reproduce this under Mint 19 in 3.6, 4.0 or 4.1. Which flavour/version of Linux do you use?

[stelgenhof]

I can confirm this. Cura 4.0.0 running on Arch Linux.

[rburema]

Are you running from the AppImage?

[stelgenhof]

@rburema No. I installed Cura using Arch Linux' package manager (yaourt). (Package: https://www.archlinux.org/packages/community/any/cura/). This basically compiles Cura from source.

[rburema]

We've had some differences in behaviour before with that setup. (Cura needs some _very specific_ versions of dependencies, due to various convoluted reasons, which is understandably frustrating for external maintainers.) If it's not too much effort: Can you confirm or deny that the AppImage version does the same?

[stelgenhof]

Sure! Let me try the AppImage.

[stelgenhof]

With the AppImage the files are saved properly (no double .gcode extension). However the File Open and File Save dialog components are different (as in styling/UI) than the non-AppImage version. These dialogs don't seem to fit my standard OS UI widgets.

[horga83]

I can confirm this happens on Arch Linux. Cura installed from
community repository.

George

On Wed, 2019-06-05 at 05:36 -0700, Sacha Telgenhof wrote:

I can confirm this. Cura 4.0.0 running on Arch Linux.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[nallath]

Well, since we don't control the community repository, there is little we can do to fix this.

[stelgenhof]

@nallath As @horga83 there is indeed an Arch Linux User Repository (AUR) and Arch Linux Packages (https://www.archlinux.org/packages/) repository.

Arch Linux Packages are merely shell scripts that help installing software on the Arch Linux OS. Often these scripts use a Git repository for compiling and building the executable/application. This is the case for Cura as well.

Cura on Arch Linux uses the same source code from Github as you are using to build releases. No additional community changes are added.

[nallath]

They do, however, use different versions of Qt and other libraries. We explicitly pack certain versions as we test (and develop) with those. This is not the first time that the arch packaging has caused issues (previously it was with the rendering). Even with that version of Qt we couldn't reproduce it and using the appimage made it work for those users.

[stelgenhof]

Ah yes of course. I didn't think about Qt and libraries. So, need to teach the maintainer of that package to use the appropriate library versions then :)

[smartavionics]

Strangely, I am now seeing .gcode.gcode occurring in my master branch builds. I have not long ago merged Ultimaker's recent changes to the cura-build-environment repo so I wonder if something in there is causing this behaviour?

[smartavionics]

Furthermore, the Files of Type dropdown now has duplicate entries?

This is a master branch build on Linux.

[smartavionics]

It looks like getSupportedFileTypesWrite() is returning a list with duplicate entries.

[smartavionics]

OK, I think I know what's happening here. In my local installation of cura there's a symlink that makes lib and lib64 the same:

~/3dp/cura/Cura.git/build[mb-testing]$ ls -l /opt/cura/
total 56
drwxrwxr-x  2 markb markb  4096 Jun 18 19:58 bin
drwxrwxr-x  2 markb markb  4096 Jun 14 11:59 certs
drwxr-xr-x 60 markb markb  4096 Jun 14 13:19 include
drwxrwxr-x 14 markb markb 16384 Jun 14 13:20 lib
lrwxrwxrwx  1 markb markb     3 Jun 14 11:55 lib64 -> lib
drwxrwxr-x  6 markb markb  4096 Jun 14 11:58 man
drwxrwxr-x  2 markb markb  4096 Jun 14 11:59 misc
-rw-r--r--  1 markb markb 10835 Jun 14 11:59 openssl.cnf
drwxrwxr-x  2 markb markb  4096 Jun 14 11:59 private
drwxr-xr-x 17 markb markb  4096 Mar 15 12:00 share

But in CuraApplication.py it does this:

        if Platform.isLinux():
            lib_suffixes = {"", "64", "32", "x32"}  # A few common ones on different distributions.
        else:
            lib_suffixes = {""}
        for suffix in lib_suffixes:
            self._plugin_registry.addPluginLocation(os.path.join(QtApplication.getInstallPrefix(), "lib" + suffix, "cura"))

So it actually adds /opt/cura/lib and /opt/cura/lib64 so the plugins get loaded twice.

So how do I fix this?

[smartavionics]

As I suspected, the AppImage built from the same source doesn't exhibit the same behaviour because it only has bin, lib and share directories and no lib64.

[smartavionics]

And here's the change that introduced this problem...

https://github.com/Ultimaker/cura-build-environment/commit/434dae0395ecff1c0938b4ea312e23c23d737e36

Whaddyathink @LipuFei ?

[smartavionics]

FYI, I removed the lib64 symlink and this problem went away.

[stelgenhof]

@smartavionics Thanks for the detailed research! Makes quite sense now what happened :)