pothi.love/0021-compute_layout

112 lines
3.0 KiB
Plaintext
Raw Permalink Normal View History

snapshot: a whole new approach to panning Basic idea: If the goal is for the cursor to be on the viewport, focus the code on ensuring that constraint by construction. Motivation: The downstream driver.love fork still has persistent bugs. And I'm seeing some inconclusive signs that edit.lua might be failing to change screen_top some of the time when it needs to. But this only happens in driver.love, never in lines.love. So the null hypothesis is that there's some subtle assumption in lines.love that we're violating when rendering it on a surface. What do you do with such subtleties? It might actually be counterproductive to fix them at source. You end up with complexity upstream that won't actually matter there if it breaks. Which is a recipe for it to break silently and far away from the downstream fork that might actually care about it. Or it might confuse people in future who don't care about the downstream forks, just lines.love. Maybe it makes sense to modify edit.lua here and take the hit on all possible future merge conflicts. But considering the cost of tracking this down, it seems simplest to: a) come up with the constraint I care about, and b) modify outside edit.lua, either what it sees or its results, to preserve the new constraint. Long ago I used to have this assertion in pensieve.love that the cursor must be within the viewport, but I ended up taking it out because it kept breaking for me when I was trying to do real work. It seems clear that there are possible assertions that are useful and yet counterproductive. If you can't keep it out of the product in the course of testing, then it annoys users where ignoring it would be a more graceful experience. Even when the user is just yourself! So it turns out this is not a problem only for large teams of extrinsically motivated people who don't eat their own dog food. No, for some things you have to fix the problem by construction, not just verify it with an assertion. This plan isn't fully working yet in this commit. I've only fixed cases for down-arrow. I need to address up arrow, and there might also be changes for left/right arrows. Hmm, I'm going to try to follow the implementation of bring_cursor_of_cursor_node_in_view() in pensieve.love. In the process of doing this I also noticed a bug with page-up/down. It already existed, but this approach has made it more obvious.
2023-10-27 22:48:45 +00:00
compute_layout = function(node, x,y, nodes_to_render)
--[[ --debug prints when modifying the DOM
if node.type == 'rows' or node.type == 'cols' then
print(node.type, node.button, #node.data)
else
print(node.type, node.button)
end
--]]
-- append to nodes_to_render flattened instructions to render a hierarchy of nodes
-- return x,y rendered until (surface coordinates)
if node.type == 'text' then
-- leaf node containing raw text
node.x = x
node.y = y
-- render background if necessary
2023-06-21 04:53:27 +00:00
local pending_nodes = {}
if node.bg then
2023-06-21 05:20:23 +00:00
local n = {type='rectangle', drawmode='fill', r=node.bg.r, g=node.bg.g, b=node.bg.b, x=node.x-5, y=node.y-5, rx=node.rx, ry=node.ry}
2023-06-21 04:53:27 +00:00
table.insert(pending_nodes, n)
table.insert(nodes_to_render, n)
end
2023-06-21 04:53:27 +00:00
-- render border if necessary
if node.border then
2023-06-21 05:20:23 +00:00
local n = {type='rectangle', drawmode='line', r=node.border.r, g=node.border.g, b=node.border.b, x=node.x-5, y=node.y-5, rx=node.rx, ry=node.ry}
2023-06-21 04:53:27 +00:00
table.insert(pending_nodes, n)
table.insert(nodes_to_render, n)
end
-- render contents
if node.width then
node.w = node.width
else
node.w = 0
for i,line in ipairs(node.data) do
local width = love.graphics.getFont():getWidth(line.data)/Viewport.zoom
if node.w < width then node.w = width end
end
end
if node.editor == nil then
initialize_editor(node)
else
snapshot: a whole new approach to panning Basic idea: If the goal is for the cursor to be on the viewport, focus the code on ensuring that constraint by construction. Motivation: The downstream driver.love fork still has persistent bugs. And I'm seeing some inconclusive signs that edit.lua might be failing to change screen_top some of the time when it needs to. But this only happens in driver.love, never in lines.love. So the null hypothesis is that there's some subtle assumption in lines.love that we're violating when rendering it on a surface. What do you do with such subtleties? It might actually be counterproductive to fix them at source. You end up with complexity upstream that won't actually matter there if it breaks. Which is a recipe for it to break silently and far away from the downstream fork that might actually care about it. Or it might confuse people in future who don't care about the downstream forks, just lines.love. Maybe it makes sense to modify edit.lua here and take the hit on all possible future merge conflicts. But considering the cost of tracking this down, it seems simplest to: a) come up with the constraint I care about, and b) modify outside edit.lua, either what it sees or its results, to preserve the new constraint. Long ago I used to have this assertion in pensieve.love that the cursor must be within the viewport, but I ended up taking it out because it kept breaking for me when I was trying to do real work. It seems clear that there are possible assertions that are useful and yet counterproductive. If you can't keep it out of the product in the course of testing, then it annoys users where ignoring it would be a more graceful experience. Even when the user is just yourself! So it turns out this is not a problem only for large teams of extrinsically motivated people who don't eat their own dog food. No, for some things you have to fix the problem by construction, not just verify it with an assertion. This plan isn't fully working yet in this commit. I've only fixed cases for down-arrow. I need to address up arrow, and there might also be changes for left/right arrows. Hmm, I'm going to try to follow the implementation of bring_cursor_of_cursor_node_in_view() in pensieve.love. In the process of doing this I also noticed a bug with page-up/down. It already existed, but this approach has made it more obvious.
2023-10-27 22:48:45 +00:00
update_editor_box(node)
end
2023-06-22 05:12:46 +00:00
node.h = box_height(node)
table.insert(nodes_to_render, node)
2023-06-21 04:53:27 +00:00
for _,n in ipairs(pending_nodes) do
2023-06-21 05:20:23 +00:00
n.w = node.w+10
n.h = node.h+10
end
elseif node.type == 'rows' then
node.x = x
node.y = y
local node_to_render
if node.bg then
node_to_render = {type='rectangle', r=node.bg.r, g=node.bg.g, b=node.bg.b, x=node.x, y=node.y}
table.insert(nodes_to_render, node_to_render)
end
-- lay out children top to bottom
local subx,suby = x,y
local w,h = 0,0
local subnodes
for _,child in ipairs(node.data) do
if child.margin then
suby = suby+child.margin
h = h+child.margin
end
if not child.width then
child.width = node.width -- HACK: should we set child.w or child.width? Neither is quite satisfactory.
end
snapshot: a whole new approach to panning Basic idea: If the goal is for the cursor to be on the viewport, focus the code on ensuring that constraint by construction. Motivation: The downstream driver.love fork still has persistent bugs. And I'm seeing some inconclusive signs that edit.lua might be failing to change screen_top some of the time when it needs to. But this only happens in driver.love, never in lines.love. So the null hypothesis is that there's some subtle assumption in lines.love that we're violating when rendering it on a surface. What do you do with such subtleties? It might actually be counterproductive to fix them at source. You end up with complexity upstream that won't actually matter there if it breaks. Which is a recipe for it to break silently and far away from the downstream fork that might actually care about it. Or it might confuse people in future who don't care about the downstream forks, just lines.love. Maybe it makes sense to modify edit.lua here and take the hit on all possible future merge conflicts. But considering the cost of tracking this down, it seems simplest to: a) come up with the constraint I care about, and b) modify outside edit.lua, either what it sees or its results, to preserve the new constraint. Long ago I used to have this assertion in pensieve.love that the cursor must be within the viewport, but I ended up taking it out because it kept breaking for me when I was trying to do real work. It seems clear that there are possible assertions that are useful and yet counterproductive. If you can't keep it out of the product in the course of testing, then it annoys users where ignoring it would be a more graceful experience. Even when the user is just yourself! So it turns out this is not a problem only for large teams of extrinsically motivated people who don't eat their own dog food. No, for some things you have to fix the problem by construction, not just verify it with an assertion. This plan isn't fully working yet in this commit. I've only fixed cases for down-arrow. I need to address up arrow, and there might also be changes for left/right arrows. Hmm, I'm going to try to follow the implementation of bring_cursor_of_cursor_node_in_view() in pensieve.love. In the process of doing this I also noticed a bug with page-up/down. It already existed, but this approach has made it more obvious.
2023-10-27 22:48:45 +00:00
subx,suby = compute_layout(child, x,suby, nodes_to_render)
if w < child.w then
w = child.w
end
h = h+child.h
end
node.w = w
node.h = h
if node_to_render then
node_to_render.w = w
node_to_render.h = h
end
elseif node.type == 'cols' then
node.x = x
node.y = y
-- lay out children left to right
local node_to_render
if node.bg then
node_to_render = {type='rectangle', r=node.bg.r, g=node.bg.g, b=node.bg.b, x=node.x, y=node.y}
table.insert(nodes_to_render, node_to_render)
end
local subx,suby = x,y
local w,h = 0,0
for _,child in ipairs(node.data) do
if child.margin then
subx = subx+child.margin
w = w+child.margin
end
snapshot: a whole new approach to panning Basic idea: If the goal is for the cursor to be on the viewport, focus the code on ensuring that constraint by construction. Motivation: The downstream driver.love fork still has persistent bugs. And I'm seeing some inconclusive signs that edit.lua might be failing to change screen_top some of the time when it needs to. But this only happens in driver.love, never in lines.love. So the null hypothesis is that there's some subtle assumption in lines.love that we're violating when rendering it on a surface. What do you do with such subtleties? It might actually be counterproductive to fix them at source. You end up with complexity upstream that won't actually matter there if it breaks. Which is a recipe for it to break silently and far away from the downstream fork that might actually care about it. Or it might confuse people in future who don't care about the downstream forks, just lines.love. Maybe it makes sense to modify edit.lua here and take the hit on all possible future merge conflicts. But considering the cost of tracking this down, it seems simplest to: a) come up with the constraint I care about, and b) modify outside edit.lua, either what it sees or its results, to preserve the new constraint. Long ago I used to have this assertion in pensieve.love that the cursor must be within the viewport, but I ended up taking it out because it kept breaking for me when I was trying to do real work. It seems clear that there are possible assertions that are useful and yet counterproductive. If you can't keep it out of the product in the course of testing, then it annoys users where ignoring it would be a more graceful experience. Even when the user is just yourself! So it turns out this is not a problem only for large teams of extrinsically motivated people who don't eat their own dog food. No, for some things you have to fix the problem by construction, not just verify it with an assertion. This plan isn't fully working yet in this commit. I've only fixed cases for down-arrow. I need to address up arrow, and there might also be changes for left/right arrows. Hmm, I'm going to try to follow the implementation of bring_cursor_of_cursor_node_in_view() in pensieve.love. In the process of doing this I also noticed a bug with page-up/down. It already existed, but this approach has made it more obvious.
2023-10-27 22:48:45 +00:00
subx,suby = compute_layout(child, subx,y, nodes_to_render)
w = w + child.w
if h < child.h then
h = child.h
end
end
node.w = w
node.h = h
if node_to_render then
node_to_render.w = w
node_to_render.h = h
end
end
return x+node.w,y+node.h
end