gui/probe candidate

[MagistrumT-T]

I tempted some vengeful deity by mentioning work downtime and got swamped this week. This creates a tool that will run probe on the position of the mouse and show it in a window in the right corner of the screen. Left click locks on a tile.

I chose the same window that gui/design uses, it feels comfortable there. I'm not sure about pausing the game, maybe someone could be trying to check something changing in realtime?

I should probably let the map movement keys go through, someone might be trying to check something on multiple z-levels.

Probe spits out a lot of lines, which is fine because the widgets have auto scrollbar feature for big elements. Sadly, updating the frame resets the scrolling position. So every time I move the mouse to check another tile it will snap back to the top and I have to scroll down again to see the light tags and such.

Outside of ASCII mode it is actually kind of difficult to discern where a tile ends and another begins sometimes, definitely add a transparent or blinking cursor to help pinpoint which tile is being probed, specially if locked on a tile.

It works fine as is, but I'll keep committing to this while the PR is open.

[myk002]

don't forget documentation in docs/gui/probe.rst and a line in the "New Tools" section in the changelog

[myk002]

since you're allowing the window to be resized, a widgets.WrappedLabel might be more appropriate here.

[MagistrumT-T]

Now that I have done it I find it a bit harder to understand this way. The wrapping is perfect for the tiletypes section, but on the materials section it becomes difficult to parse and to someone who is not already used to probe it is impossible to discern what it is describing because there are a lot of colons on the material names/description.

Wondering if having text clearly going off screen wouldn't be better to hint to the player that he should extend the screen if he needs that bit of info, but I don't know if it is even common knowledge that you can move and resize DFHack screens, considering vanilla screens don't let you I don't think anyone even tries.

[myk002]

if the text needs better formatting, you have a few options:

1. change the formatting of probe itself
2. have probe return the raw data in a structure via a Lua API call and you can format it yourself

[MagistrumT-T]

Thinking a bit about it, I believe it would be very clear where and how wrapping is happening if we just color the words before the first colon on each line(if present). I don't suppose we have any markup or anything like that for the current label text pen situation? If not I think we are going with 2.

[myk002]

Outside of ASCII mode it is actually kind of difficult to discern where a tile ends and another begins sometimes, definitely add a transparent or blinking cursor to help pinpoint which tile is being probed, specially if locked on a tile.

See gui/quickfort for a blue marker that indicates the hovered tile. Alternately, you could choose a boundary-with-center-dot cursor like gui/pathable

[MagistrumT-T]

gui/quickfort and gui/pathable do it via C++, right? I was trying to avoid it, so I used the map overlay thing gui/design uses.

[myk002]

gui/quickfort and gui/pathable do it via C++, right? I was trying to avoid it, so I used the map overlay thing gui/design uses.

gui/pathable does it with C++, but gui/blueprint and gui/quickfort do it in pure Lua. I was just mentioning gui/pathable for its choice of tile highlight cursor, which you can just as easily use from Lua.

[MagistrumT-T]

gui/quickfort indeed does the exact blink behavior I wished for in lua, I have no idea how I missed it. I think I looked a gui/pathable and stopped searching? Anyways, It looks great!