Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

gui/probe candidate #967

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

MagistrumT-T
Copy link
Contributor

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.

Creates a tool that will run probe on the position of the mouse and show it in a screen in the right corner of the screen.
Copy link
Member

@myk002 myk002 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

gui/probe.lua Outdated Show resolved Hide resolved
gui/probe.lua Outdated Show resolved Hide resolved
gui/probe.lua Outdated
label='Lock on tile:',
initial_option=false,
},
widgets.Label{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Switches from ZScreenModal to ZScreen to stop being greedy with the inputs.
Doesn't keep updating the keyboard cursor position anymore.
@myk002
Copy link
Member

myk002 commented Feb 9, 2024

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

"Hovering" kind of makes it seem like holding the mouse over any tile without doing anything will trigger it, but I think one would quickly discover that isn't the case and try to run it anyway.
@MagistrumT-T
Copy link
Contributor Author

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
Copy link
Member

myk002 commented Feb 13, 2024

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.

When in graphics mode it just renders over the current tile transparently, so I think it doesn't need to blink there.
@MagistrumT-T
Copy link
Contributor Author

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!

Forgot the lock and screen over behavior on the last commit.
Also noticed that I had set the lock key to 'f' instead of 'ctrl-f'.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants