The table name is used as the container type in the resulting metadata, so we need to use the container type string as table name correctly, or none of the profiles can be found.
Contributes to issue CURA-6096.
This mistake caused all of the container types to end up as either None or the actual instance itself, which was causing crashes.
Contributes to issue CURA-6096.
Needed to add a Filter possibility to facilitate that
Created a Simple UserString class which can be used as:
```py
sql_filter = SQLFilter(f"SELECT {{}} FROM table_name WHERE id = ?")
cursor.execute(sql_filter) # Will execute: SELECT * FROM table_name WHERE id = ?
cursor.execute(sql_filter["id", "name"]) # Will execute: SELECT id, name FROM table_name WHERE id = ?
```
Contributes to CURA-6096
This greatly reduced the amount of duplicate code in the DataBaseHandlers
Not sure how secure this is SQL injections. Need to check that and maybe
put in some guards. Using double underscores for now and only provide a
getter. But then again why bother with an SQL injection as
you can just as easily modify the Python code, and we still have the old
Containers to fallback to if the Database gets corrupted.
Contributes to CURA-6096
Revert "Change file extension to .umm"
This reverts commit 56db7f7144083df4bca77746d7ee30f2a54fda36.
Revert "Re-enable compression"
This reverts commit 62bc9be22bbc5595dbfce69893163c3a0ebc4415.
Revert "Add documentation"
This reverts commit e9031f1aff5d40f3c69ac625edf11963a3253eb8.
Revert "Fix writing bytes to string-stream"
This reverts commit 66b2825a667f9aa9618005d2a5875383a3658f4f.
Revert "Hide button entirely if no export is available"
This reverts commit ec727e1068c3ac2cab7f95fb88c5d4d101e28e17.
Revert "Basic implementation of exporting all materials in a .zip archive"
This reverts commit bdcaef134f556f455f352786123476ec40e3ae4c.
Revert "Implement default path for exporting all materials"
This reverts commit e66783664bf73dd9b1e3c6af6f01321763470d2e.
Revert "Implement a sync button and file dialogue to export all materials"
This reverts commit abba3bdd10a994a1b38bcb426a27ba379febeac7.
Revert "Add notion of whether printers support the material export archive"
This reverts commit f436cb8e7b879a8913b25f2a049413ec0721f1c5.
We encountered an issue yesterday that we had to find in a log file when a user was importing a material. Nothing is shown in the log when importing a material, so it was impossible to find.
Now we'll log this action. It is a direct user action, so info is a good log level.
It's possible that a profile is no longer in the registry by the time it gets to that point in the list if this clean-up is triggered by the very action of deleting a profile.
Fixes Sentry issue CURA-1T5.
If for some reason the print sequence is set to one-at-a-time be default in the printer definition
and the number of extruders of the printer is set to >=2, then the print_sequence won't show up in
neither the quality changes nor the user changes, yet it will still have "one-at-a-time" as a
value. In a such case, it will still need to be set to "all-at-once" in the user changes.
This is a theoretical case, as it is very unlikely for a printer to have "one-at-a-time" set by
default in its definition (.def.json) file and still be able to support more than one extruders.
But it is a world full of possibilities out there, so you never know...
CURA-7827
Previously, the print sequence would be always set to all-at-once in the user container whenever
the second extruder would be enabled. This was causing an interface issue, where the circular
reset-setting arrow would appear next to the setting, even if the quality changes already had the
correct value ("all-at-once").
This is now fixed by checking the following:
- If print_sequence == "one_at_a_time" in the quality (so it is already saved in a quality profile)
then set the print_sequence to "all_at_once" in the user changes so that it will be displayed as
an unsaved change
- If print_sequence == "one_at_a_time" in the user changes container only, meaning that it is not
saved in any quality profiles, then just reset the print_sequence in the user changes, so that it
will have the correct value ("all-at-once") without the reset-setting arrow appearing next to it.
CURA-7827
The user doesn't know what a global stack is. This is a message that more clearly specifies what is really happening as far as the user can see.
The global stack may be None if this code is executed while there is no active printer. Normally the only time there is no active printer is:
- during first launch, while in the welcome screen
- during start-up until the profiles have been loaded
- if there was a profile corruption of some kind with the active printer.
So this function should not get called during those times. It probably isn't called except for the last case (in which case it's acceptable I guess).
This change is made after a request from a translator what the hell this means.
Contributes to issue CURA-7783.
The addMachineExtruders function assumes that this is a new printer (first time the printer is activated since a restart of Cura) and it needs to add the extruder stacks to it. However most of the time when we're switching, it's not to a new printer. If it's not a new printer, this function would get called anyway and we'd be adding the extruders multiple times. This then does a lot of unnecessary work and eventually fails a couple of calls deep.
This change prevents it from adding the extruders if there are already extruders associated with the printer, thus preventing this unnecessary work (switch is faster) and preventing the error from happening.
Discovered during work on CURA-7501.
When importing a profile that doesn't much the current nozzle combination (e.g. importing a 'high'
quality when we have AA0.8 and AA0.4 nozzles), the profile was being accepted and a success message
was shown to the user, but the quality did not show up in the profile list.
This commit fixes that by accepting the quality profile and informing the user that the profile is
not visible due to the current configuration.
CURA-7691
