Small UI issues

Just a couple of small things:

  1. This is sort of a follow-on to your more complete implementation of the inches/mm preference setting (and thanks again for that!). The units in the comments section of the g-code output are always in mm, regardless of choice of G20/G21. Whether or not the units in the comments change along with G20/G21, there should be a header comment to say what the units are.

  2. I’ve tried enabling “Token spacer” for my machine, but the setting of the checkbox doesn’t stick, and has no effect.

  • If you put a line with G20 in your gcode header (machine definition) then the gcode output will be converted to inches

  • I can’t replicate the token spacer problem. In my machine def, if I check or uncheck it and reload the page, the change persists :confused:

The G-code values change correctly with G20/G21. The G-code comments do not. I.e.:
; camFastFeed = 508

; camFastFeedZ = 203.2

G0Z0.1700F8.0000
G0X-0.2563Y-0.7398F20

As for the token spacer, I went back into my machine config just now to try it again.
I checked “Token spacer”, hit save, and the checkbox was cleared just as it saved. To make sure I could change anything at all, I checked “strip comments”, and that worked as expected. After doing that, the “token spacer” checkbox started working correctly. :neutral_face: Go figure. :slight_smile:

aha. sorry, i had insufficient caffeine at the time i read and replied. will fix the comment units.

will review the token spacer issue again.

what do you think about having this detected from the gcode header like units instead of yet another checkbox?

You say “yet another checkbox”, yet the token spacer checkbox already exists. But assuming that’s what you’re talking about: The header is for adding machine specific g-code. This checkbox affects how kiri formats g-code. I’m not sure how that would be expressed in the header.

I meant eliminating the checkboxes for spacer and comment strip and inferring them from the header instead. If the header uses spaces “G0 X0 Y0 Z0” or not “G0X0Y0Z0” the behavior of the rest of the gcode will follow that convention. In general, I prefer a UI uncluttered by things that could just as easily be inferred or discovered.

I’m having trouble picturing what would go into the header that you could use to infer comment strip or preserve.

And for token spacer, it requires putting a command with parameters into the header.

In either case, I think the features would be undiscoverable – there would be no obvious way for the user to know they could get spacing, or comments, and if they happened to trigger one of them, they wouldn’t know what caused the change.

Fair points. I think of it like this. All devices have gcode headers. Those gcode headers must conform to the gcode style acceptable to the device. If the generated gcode just follows the header conventions, then it’s entirely “safe”. If the user is savvy enough to understand whether spacing or comments are acceptable for a device, then they already understand gcode headers. If they aren’t, then they first must be educated about gcode formats.