feat(ui): Add FORCE_MOVE support to tool controls

[kerbilg]

Closes: #494

Hi,
I am here with another PR 😁 I hope I have not misunderstood the request.

I have made a video again to demonstrate the function:

force_move-demo.mov

I have not included a warning, anyone who manually activates force_move should actually know the dangers. Personally, I would find it annoying. If it is still desired, I can work on it.

This PR is not complete and needs some css work. I've been working on it for days but failed, maybe someone else can help. There is a comment under Toolhead.vue.

You can see the css disaster by marking the background:

If anyone has any questions about the code, please contact me on Discord: BastelKlug#5605

Signed-off-by: Kerim Bilgic [email protected]

[kerbilg]

Hi, I have fixed the style errors. In theory it is now adoptable.

So here is the current status:

[pedrolamas]

Thanks for this @BastelKlug, I've just taken it for a quick test and it works very well! 😁

Having said that, I personally am not a fan of the override positioning...

I do wonder if it would look better as a button here:

If you look at the temperature charts, we have a button there that has "Chart Off/On", and I think the same approach can be taken here...

@matmen what do you think?

[matmen]

I agree, having it in the card header would be much better placement-wise. I also think that some kind of warning definitely is necessary here, optimally every time FORCE_MOVE is enabled, but I'm also fine with having a setting under General that shows/hides the checkbox in the tool card (which then displays a warning when it's toggled on). Maybe the latter is even a better option so we don't clutter "normal" users UIs?

[kerbilg]

Hi, I will work on the changes and upload them when they are ready.

[kerbilg]

Hi, I am back and have implemented the suggestions.

So here you can see the changes in action:
https://youtu.be/OSIAlxry9mk (sorry github only allows files less than 10mb)

[pedrolamas]

This is really great, thank you for your work here @BastelKlug! 🙂

I've now approved the PR, but made a couple of changes before we merge this down, specifically:

• dropped the visibility toggle for FORCE_MOVE button (if it is enabled in printer.cfg, then always show)
• some minor styling tweaks for consistency
• added public to any Prop for proper lint alignment
• refactored logic on toolhead buttons color and disabled states

[pedrolamas]

I do wonder if we should change the movement buttons from the existing up/down/left/right arrows to minus/plus when FORCE_MOVE is enabled... any thoughts on that @BastelKlug @matmen ?

[kerbilg]

I think the old design with the arrows looks better 🤔

[pedrolamas]

...but I'm also fine with having a setting under General that shows/hides the checkbox in the tool card (which then displays a warning when it's toggled on).

@matmen I notice now that you actually mentioned having a toggle button to show/hide the FORCE_MOVE button on the interface - the one I just removed (oops!)

I wonder if we actually need this toggle, given the button will only show if enabled in the printer.cfg (same as the QGL, bed screws, z_tilt, etc.)

[matmen]

My thoughts were that users that sometimes use FORCE_MOVE could disable the toggle for a less cluttered UI, but seeing the changes I don't really mind having it there anymore. I'll review this later :)

[matmen]

Ah! I remember why I wanted it 😉

[kerbilg]

Ah! I remember why I wanted it 😉

Oh I don't know if it's realistic, but if there are too many buttons, it should actually change to the mobile layout (with the dropdown menu) I had already noticed it when I was developing

[pedrolamas]

I think in those cases, everything should just go to the overflow menu... guess we need to make a few changes here... but that is for a different matter to this topic! 🙂

[matmen]

Functionality wise it works fine, though I'm wondering it it maybe should be disabled when the printer is homed? Maybe I'm missing something here, but what's the use case of using FORCE_MOVE when the printer is already homed and can be moved - is it just for moving it out of range (that's what I use FORCE_MOVE for mostly)?

[pedrolamas]

...maybe should be disabled when the printer is homed?

True, but if Klipper allows it, why should we limit the feature ourselves? It's not like we disable the homing buttons when the printer is homed either! 🙂

I know some users have overridden the default homing procedure and use FORCE_MOVE instead (I believe there's even an "advanced homing macro" somewhere, though I can't remember where I saw it now...)

[matmen]

...maybe should be disabled when the printer is homed?

True, but if Klipper allows it, why should we limit the feature ourselves? It's not like we disable the homing buttons when the printer is homed either! 🙂

True, fair enough 😂