Godley Table Resizing Awry
System dynamics program with additional features for economics
Brought to you by:
hpcoder,
profstevekeen
This video illustrates the problem. I think the damaged Godley Tables were ones I resized in the original model. There's one that is fine, the Workers one, which was small enough not to need resizing.
An immediate fix I can see here is adding a "Reset to Original Size" option on the right-click menu. But overall this demonstrates real problems with resizing that may be the product of the capacity to resize variables and parameters.
I have installed 2.19?? beta and am working through the tutorial in the
help files. I added a constant but the value protruded outside the
boundary. Attempting to resize the icon also made the value bigger and
still protruding. I am writing a separate note to you about the GUI.
1 / 17 Glyndon Road, Camberwell VIC 3124, Australia
hedley.finger@gmail.com
Tel. +61 3 9836 4635
Cell +61 412 461 558
Typed laboriously on Samsung Galaxy Note 3
On Sat, 27 Jun 2020 14:41 Steve Keen profstevekeen@users.sourceforge.net
wrote:
Related
Bugs:
#1202Luckily this was relatively easy to fix in the present resize item implementation (silent demo attached), which I see Russell has improved significantly over what I had initilaly committed.
I spent several days trying to do this back when I was working on improving feature 94. I tried to set zoomFactors individually for items, and, as you suggested then, essentially to their original sizes when a model is first opened. I thought I had stashed the previous zoomFactor before a resize so that one could return to it. But it proved even harder (for me) than resizing all items individually. Yet another failure, sorry :(
I'm going to commit the current fix now. I think Russell will quickly spot how to improve it if it is not entirely satisfactory (which I suspect may be the case).
That looks good Wynand, thanks.
I've posted a separate ticket about a need to refactor resizing in general;
this is a good fix for now with this scaling problem, but I still want to
see a less intrusive and more conventional approach to resizing before we
put Bentham to bed.
Best, Steve
Professor Steve Keen
Head, School of Economics, Politics & History,
Kingston University London
www.debtdeflation.com/blogs
www.ideaeconomics.org
@ProfSteveKeen
Ph (W) +44 (0)20 8417-2306
On Sat, Jun 27, 2020 at 6:06 PM Wynand wdednam@users.sourceforge.net
wrote:
Related
Bugs:
#1202I'm glad you like it, thank you :)
I think it is reasonable, but am also pretty sure Russell will make changes to render the final code look seamless. Currently, there is still a slight junp in crossing over from the zoomFactor of the entire model and that of individual items on the canvas.
This was incidentally the starting point for my attempt to set zoom factors of individual items in the way you suggested, but then the code became incredibly unstable. It may have been a good idea and doable, but the feature was dragging out too long.
Wynand correctly added in a missing v->zoomFactor() in the positioning, which is because Item::width() and Item::height() are not multiplied by zoomFactor, when arguably they should. I'll raise a separate ticket to refactor these calls. The addition "globalZoomFactor" tries to take into account the scaling problem as you zoom out on the above example (with iconScale() < 1). The trouble is it isn't correct when iconScale=1. In fact the whole thing is quite a mess, with layers of "fixes" patched over the top of each other, resulting in impossible to understand code - leading to more fixes when more uses cases are found to be rendered incorrectly. We have Item::iWidth/iHeight, GodleyIcon::iconWidth/iconHeight and Godley::Icon::iconScale, all of which interact with each other, and attempt to essentially solve the same problem. We need to refactor the code, getting rid of all but the basic Item::iWidth/iHeight. I'll add a ticket for that now.