Custom Gcode UI Redesign

lordofhyphens commented 7 years ago

Version

1.3.0-dev

Rationale

The current mechanism(s) for inserting custom GCode into a print produces a lot of large text boxes and multiple configuration options exposed in libslic3r. I think it is possible to fold all of the current custom GCode (and the common use case of before/after layer X) into a single UI element that the user can expand/collapse as they wish.

Technical

Custom GCode has two logical parameters: What to be inserted and When to insert it.

What is simple enough; a single string containing the gcode to be inserted.
When is the reason we have 6+ separate configuration options for custom GCode.
- To be useful at a minimum, a gcode snippet should be assignable to a layer (either before or after), or one of the known fixed occasions (already supported by Slic3r).
  - Pre-print gcode
  - Post-print gcode
  - Toolchange (pre)
  - Toolchange (post)
  - All layer (pre)
  - All layer (post)
  - Between objects
  - Users should be able to assign multiple snippets to the same general When and specify an ordering to those (with a default order generated).

UI

The Custom Gcode textbox element would become be replaced by an option to add more Custom GCode textboxes that also have configurable fields for the When parameters. Probably a dropdown for "Before/After X" and a free-floating field that would accept a comma-separated list of numbers to apply the same field to multiple layer numbers. I also propose an "before/after Z" parameter (also taking a list of Z heights) that rounds down to the nearest layer.

For reasons of UI consistency, multiple GCode parameters should also be able to be re-ordered within their own configuration entry.

Filament and Print copies of this UI should have an additional Override option to replace all snippets from the corresponding hook (if present). The default behavior will still be append and follow the existing logic for encapsulation: Printer->Filament->Print for before custom GCode blocks and Print->Filament->Printer for after GCode blocks. Override would follow the priority of Print->Filament->Printer, where a marked Override snippet replaces that on a lower priority (eg. a Print Override will replace both Filament and Printer custom gcode for the same hook, and Filament only overrides Print).

Generalizing the UI in this manner permits applying most of the custom GCode options on a per-filament and per-print basis, either as an override (replace) or addendum (append).

SW Impact

This change would necessarily touch the following file areas:

lib/Slic3r/GUI/OptionsGroup*
- Define a new UI control element. This is where the interfacing with wxWidgets happens.
xs/src/libslic3r/PrintConfig.cpp
xs/src/libslic3r/Config.hpp
- Define the configuration type.

Caveats

Backwards compatibility for existing parameters would need to remain.
Need a good CLI interface for specifying the expanded parameters (perhaps enforcing some order to custom gcode parameters so that the When parameters precede the What parameter they affect).

This feature request would implement #3092 and re-implement #4177. Some of this functionality is duplicated in Conditional GCode, but in a more discover-able method.

goofdad commented 7 years ago

@lordofhyphens ... thanks for the rabbithole! Some thoughts:

Users should be able to assign multiple snippets to the same general When and specify an ordering to those (with a default order generated).

This feels overcomplicated. I'm not seeing a use-case for multiple "before-layer" snippets, or "tool-change" snippets and then adding an order parameter. How is that different than just using them in the same snippet?

a gcode snippet should be assignable to a layer

Yes, but as I said in my PR (#4177) I philosophically like the separation between the printer owning the gcode to insert and the print owning the list of layers. I'm just contemplating about a way to have different tags trigger different gcode (perhaps using the conditional syntax)

Backwards compatibility for existing parameters would need to remain.

Is there a mechanism for versioning of parameters / config files? Is such a thing anathema for some reason that I'm missing? It seems to me it would also help re: #3574

I just want to make sure I'm going down the correct rabbit hole and not out shaving yaks :)

lordofhyphens commented 7 years ago

Once users see something in the UI, they will try to use it like that. It has happened before, it will happen again. There wouldn't necessarily be something to stop you from assigning 3 snippets to the same place and layer, so we handle it as best we can. From the perspective of the system it would not be any different, but it does let us capture the case of two before gcode that do things and hitting the same layer on both (you want to do X on layers 2, 9, 17 and Y on 19, 50 and x and y on 17 layer).
We try very hard to not break existing configuration files. Usually it involves converting them on first load and using the new stuff from then on. The way the config system is, it is at least crash resistant in terms of forward compatibility.

goofdad commented 7 years ago

Rather than a button that can add items ad-nauseam, what if I implemented it as a dropdown with the G-Code options available, including the following:

All current gcode labels (Start G-Code, End, etc)
Tagged Filament Start G-Code
Tagged Filament End G-Code
Tagged Layer G-Code (perhaps "Before Layer" and "After Layer")?

Then provided "tags" in the Filament for Filament G-Code and in Print for Layer G-Code.

Upon start I could default extant filament gcode to tags named after the filament, and then encode them in an "if [tag]" in the Filament G-Code.

I'll have to figure out:

How to dynamically change the gcode box
How to create tag placeholders on the fly from the tags
How to upgrade existing filament gcode (how big a priority is this as 1.2.9 didn't support it yet)

lordofhyphens commented 7 years ago

Personally I think the button to add snippets is better UI and easier for people to mash things together.

goofdad commented 7 years ago

With the UI learning curve about the same for both, I think I'll mock them both up, submit them both, and we can play and see what rises to the top :)

goofdad commented 7 years ago

LOL ... this is fun. I'm learning WxWidgets as I go. Fun Fun Fun. If you could point me to a way to hide / show items in an $optgroup that would be great. If not, I'll figure it out ...

lordofhyphens commented 7 years ago

The wxwidgets Web documents should be fine for the most part.

I believe that there is a Show and Hide methods on all of them.

On Nov 2, 2017 4:55 PM, "goofdad" notifications@github.com wrote:

LOL ... this is fun. I'm learning WxWidgets as I got. Fun Fun Fun. If you could point me to a way to hide / show items in an $optgroup that would be great. If not, I'll figure it out ...

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/alexrj/Slic3r/issues/4178#issuecomment-341570064, or mute the thread https://github.com/notifications/unsubscribe-auth/AAB8CsZWd7zkod_vG6ZyvPcQxvS07Yn0ks5syjpXgaJpZM4QNutA .

foreachthing commented 7 years ago

Whatever you do, just make that textbox bigger and hide that mouse-over-tooltip; maybe put it in an (?) next to the textbox. Depending on where you enter the textbox (with your mouse) you can't read the gcode anymore.

rob-miller commented 6 years ago

The ability to 'include' gcode files would be nice for this, e.g. my PETG filament settings vary per spool due to preferred melt temperature, but all have the same retract and pressure advance settings for my printer's firmware. So if I could [include "petg_settings.gcode"] or similar that would be useful?

slic3r / Slic3r