mainsail-crew / mainsail

Mainsail is the popular web interface for managing and controlling 3D printers with Klipper.
https://docs.mainsail.xyz
GNU General Public License v3.0
1.67k stars 346 forks source link

Action messages in console are not greyed out #1950

Closed nmaggioni closed 2 weeks ago

nmaggioni commented 1 month ago

Mainsail Version:

v2.12.0

Browser:

Chrome

Device:

Desktop PC

Operating System:

Linux

What happened?

Using action_respond_info() in macros or directly running RESPOND commands prints text in the console with the default primary color.

What did you expect to happen instead?

Text should be printed in greyed out (disabled) color.

How to reproduce this bug?

Call action_respond_info("Test") from a macro or just run RESPOND TYPE="command" MSG="Test": the text printed in the console will be of the standard primary color.

Calling RESPOND TYPE="command" MSG="action: Test", instead, prints it in the disabled (greyed out) color.

image

Additional information:

While updating some macros I noticed that my debug output wasn't being printed in grey anymore and was getting confused with the standard logging messages printed to the console.

I remember not having to prefix the statements with anything in particular to get them to print as low-priority, disabled messages; did something change with the introduction of prompt dialogs or am I just misremembering things? Since manually prefixing the messages with action: makes detection work successfully once again, I have the hunch that this is a small regression or new edge case in event parsing logic.

meteyou commented 1 month ago

Thank you for your bug report. This behavior is intentional, because outputs like // action: xxx are from/for Octoprint and therefore they are displayed in grey. This behavior has been the same since the beginning of the console in Mainsail.

You can find more informations about this here: https://www.klipper3d.org/G-Codes.html#respond_1

nmaggioni commented 1 month ago

Thank you, I must be misremembering an old behavior then. Sorry for the noise.

On the other hand: would a PR with additional parsing logic centered on a custom prefix (much like what's done for // echo: right now) be interesting for the project? Something like a configurable debug prefix that has the same graphical effect as action messages but actually gets stripped from the message's contents.

zellneralex commented 1 month ago

We discussing that internally, personally I am not a fan of separating User and Klipper output by color. But I use it as a regular print output and also use filters to tailor the klipper related output to what i want to see at print start. E.g. image Disclaimer: That is a combined output of my own macros + tailored klipper outputs of QuadGantryLevel and BedMeshCalibrate apative=1

For your second Question: A user defined prefix is much to risky you would be surprised how creative people gets by using special chars or even spaces. And than you deal with in some cases unexpected behavior of klipper plus the issue that you need to special tailor the regex to also find that case. That said a pre defined prefix like // debug: xxx might be a solution. The only issue is that people need to read the docs to find that.

meteyou commented 1 month ago

@nmaggioni are you interested in making a PR for the // debug: prefix? would you use the same color as the action outputs?