-
Notifications
You must be signed in to change notification settings - Fork 198
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
Make gui/workorder-details
and gui/workshop-job
work again
#799
base: master
Are you sure you want to change the base?
Conversation
issues:
|
This can likely be solved by changing the
The preferred solution here is to modify
The UI definitely needs some updating and testing. It uses code from |
docs/gui/workorder-details.rst
Outdated
@@ -9,8 +9,7 @@ This tool allows you to adjust item types, materials, and/or traits for items | |||
used in manager workorders. The jobs created from those workorders will inherit | |||
the details. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the introductory text could use a few more examples of things you can do with this tool that you wouldn't be able to do in vanilla. what do you think are the most useful situations where this tool helps?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
probably use dyed or dyeable (=undyed I think) cloth, or encrust unimproved items...
I'm not quite sure.
970f738
to
9eca80b
Compare
gui/workorder-details.lua
work againgui/workorder-details
and gui/workshop-job
work again
|
That's still fine to use. At some point, I'll swap out the implementation to use a ZScreenModal, but that should be transparent to the callers. |
Sphinx is complaining because of What's the approach with removed scripts here, should I keep the referenced docs as is, or maybe make its only content a reference to the new script? |
Tool removal is a tad janky since it crosses repos. You have to add an entry to https://github.com/DFHack/dfhack/blob/develop/docs/about/Removed.rst, but CI for both repos will fail until everything is consistent. |
this PR should be completed simultaneously with DFHack/scripts#799 or abandoned in case DFHack#3729 is solved
gui/job-details.lua
Outdated
@@ -92,14 +86,13 @@ function JobDetails:init(args) | |||
frame = { l = 0, b = 0 }, | |||
text = { | |||
{ key = 'LEAVESCREEN', text = ': Back', | |||
on_activate = self:callback('dismiss') | |||
-- on_activate = self:callback('dismiss') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yeah, not needed. the base ZScreen superclass takes care of window lifecycles
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
gui/job-details.lua
Outdated
|
||
DetailsHotkeyOverlay_BuildingTask = defclass(DetailsHotkeyOverlay_BuildingTask, DetailsHotkeyOverlay) | ||
DetailsHotkeyOverlay_BuildingTask.ATTRS{ | ||
default_pos={x=-120, y=6}, -- {x=-120, y=6} is right above the job title on all but smallest widths |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd move this to the right by 5 so it still looks good at the smallest width
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I "reserved" the whole line using frame={w=1000, h= 1}
, so that now with dfhack.screen.getWindowSize()
I can move the hotkey around and it always fits.
It would've been nice to be able to move the widget itself. IIRC that wasn't possible last time I checked (half a year ago? because of label placement in the workorder-recheck.lua).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I improved upon this. The logic is as follows now.
- Fix the distance from the right edge; make the widget slightly wider than necessary to allow moving the text around
- determine the calculated x1 coordinate of the frame, which is the
screen width
minus thedistance from the right
minus thewidget width
- if the x1 < 0, set it to 0 --- making it the real position of the widget (I think this works better than built-in methods for some reason, although it's a few experiments back)
- is the real left edge position of the widget too far to the left (
x1 < 6
), move the text to the right (offset = 6 - x1
).
This works well enough until you try to narrow the game window to the minimum and then widen it again. Then the self.frame.r
is changed from 102
to 77
and stays that way. That's why the 4th step is needed
- restore original
self.frame.r
Even with this after widening the window it doesn't immediately get the right position, but another small resizing in any direction sets it right.
something changed somewhere and now we have for some reason a set bit without a name: (even though and this is how the list is filled from a bitfield: local function list_flags(list, bitfield)
for name,val in pairs(bitfield) do
if val then
table.insert(list, name)
end
end
end Might this be a bug? Or maybe it should've been To avoid confusion, I'll change the method above to exclude those. |
That might require a structure update. I'll look into it |
I identified the flags and pushed the updated build to the Steam |
cache references to global statics
Also, refactor the way header text is built
changed it to work based on window size instead of reading the screen
did that
defaults is hard - I'd have to know them for every job type in advance. I added a
change item type is now disabled if armok tools aren't present. Traits have same problem as defaults: I'd need to know in advance what the defaults are, to prevent the user from removing the non-default ones.
changed that. Now I'm not sure anything but
removed that
changed that. Btw, there are two modes: work order and active job, with slightly different texts It's possible we can only ever see |
for _, obj in pairs(self.list.choices) do | ||
local stored_obj = self.stored[obj.index] | ||
|
||
local item_type = stored_obj.item_type |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Attempting to reset changes for me results in this error:
gui/job-details.lua:419: attempt to index a nil value (local 'stored_obj')
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looking through the code, it looks like storeInitialProperties is checking job.items
instead of job.job_items
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the job.job_items
vs job.items
is the bane of my existence 😣
because there are two structures involved, manager order and job, and one of them has both but uses the one that's distinct.
I think I fixed it now.
This PR merges the
gui/workorder-details.lua
intogui/workshop-job.lua
and updates the result to work with DF50.