This is upping the importance of the resize feature of the program. The current implementation--particularly in the latest beta, where resizing is possible on all objects--is making the program unworkable from a user's point of view.
The capacity to resize from any corner of an object is a one-step operation that can be emulated by a two-step operation where resizing can only be done from the bottom right hand corner: first resize, then move. The original idea to have resize arrows on every corner of a resizable object worked well when those object were restricted to Plots and Godley Tables, which are large objects in themselves: what would be a two-step operation with a standard resizing handle becomes a one-step operation.
But now that every object can be resized, the resize arrows themselves have become a nuisance. Firstly, the arrows spring up all the time when you're trying to edit a model: it's annoying. Secondly, because the arrows intrude into the interior of objects, you can tripper a resize when what you wanted to do was a move. The advantage of being able to reduce two steps (resize then move) to one (resize) is more than outweighed by how intrusive (and elusive! see video) the resize arrows are,
I would prefer to implement a different, and more conventional strategy: every object has a resize handle in the bottom left hand corner. If expanding an object puts it somewhere you don't want its right hand side to be after the resize, then you move it.
I've just seen Wynand's comment here and I'll check his demo video now. If this has addressed some of the annoyance issues here, great. But overall I do think this refactoring is necessary.
Just check the video: great, the specific hassle with Godley Tables is no more. Please pop a beta ASAP, since I want to record a video for a conference in London next week.
Anonymous
When we pivot to bug seek and destroy on July 1, I will tackle on this one.
I have made the resize handle smaller on variables, operations (including the int op) and the switch icon (see attached silent demo). It now appears only on bottom right hand corner of these objects. It's a bit tricky to find on the int op, but consistently appears below the bottom of the attached variable at the right end of the combined bounding box.
I really have to thank Russell here again for generalising the bounding box for these items. This was the part that eluded me when I was working on feature 94 and has also made it possible to quickly make these fixes now. (The resize code is also much simpler now).
I have made further improvements based on Russell's suggestions and also fixed the problem with the arrows not appearing on the bottom-right corner of the coupled int op (attached silent demo, in which I also quickly show what the parameter and variable tabs look like now).
I changed the title, as this is a change of functionality, not a refactor which by definition doesn't change externally visible behaviour (apart from incidentlally fixing bugs).
Just a comment - I'm used to having resize handles on all four corners in my window manager, however IIUC, you are requesting here a single resize handle on the bottom right corner. Is there a standard representation of the resize handle? Are you happy to continue with the current arrow style, or is there something else that might be more recognisable.
Yes mate; the standard resize is the same as we use to resize the Godley
Table window. It's much less intrusive than the arrows we're using at
present.
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 Sun, Jul 5, 2020 at 8:00 AM High Performance Coder hpcoder@users.sourceforge.net wrote:
Related
Bugs:
#1203I've made the improvements that Russell suggested on the pull request at Github. I've commited the code and it is now ready to be merged.
Steve - what you are referring to is the window decorations added by your window manager, which varies by window manager. In your case, the window manger is Windows 10, and the decorations have evolved over time since Windows 1.0. MacOSX has a complete different set of decorotations. In my window manager (FVWM - the author is coy about what the 'F' stands for), there is a resize handle on each corner, but its not particulary obvious that they are resize handles if you're not used to the conventions of the WM.
In this case, we need to settle on what we want for resize handles. Arrows was an attempt to make it obvious. We're settled on only having it in one corner (which corner), which makes sense, because you can always drag the widget to place it correctly. But need to decide on how it should appear.
Last edit: High Performance Coder 2020-07-12
I've come in a bit late here. I am playing with Minsky 2.19?? on Ubuntu
18.04.4 and the resize arrows are driving me a little bit more nuts. I try
to resize a Var and the value inside it enlarges. I then manage to enlarge
the envelope of the Var and the value over-enlarges even more in
proportion, and there is no way to get the damn value back inside the
envelope.
I think the whole question of selection and resizing is bound up together;
more below.
First, in most vector drawing programs, when a graphic object is clicked it
is selected and handles appear at the corners and along the sides:
[image: image.png] LibreOffice Draw [image: image.png]Draw [image:
image.png]Inkscape
In LibreOffice Draw, the handles do not indicate any action until the
selection pointer hovers over one, and then the pointer turns into a corner
or side resize pointer as shown. (Note: This is what Ubuntu does when you
are in the Desktop resizing windows.) In Inkscape, small double-headed
arrows appear outside the object near the corners and sides; they indicate
their resizing function. The sides also turn into ant trails. Another click
on the item, and the arrows rotate 90° and indicate that the item can be
rotated about its centre:
[image: image.png]Inkscape
Note that a handle is highlighted in Inkscape when the pointer hovers over
it. Most vector drawing programs allow you to resize an object from its
centre (not from the opposite corner) when a control key -- Alt, Ctrl,
Shft -- is held down simultaneously. Both Inscape and Draw are invariant
across platforms, so clearly the programs are bypassing the FWVM and
supplying their own pointers. At some point stage Minsky is going to be
used in education so it would be good for the bubby economists to see the
same thing across various platforms.
--
1/17 Glyndon Road, Camberwell VIC 3124, Australia
hedley.finger@gmail.com
Telephone 03 9836 4635
Mobile 0412 461 558
LinuxCounter.net registered computer 576484 (course there are more Linux
users than that!)
I've come in a bit late here. I am playing with Minsky 2.19?? on Ubuntu 18.04.4 and the resize arrows are driving me a little bit more nuts. I try to resize a Var and the value inside it enlarges. I then manage to enlarge the envelope of the Var and the value over-enlarges even more in proportion, and there is no way to get the damn value back inside the envelope.
I think the whole question of selection and resizing is bound up together; more below.
First, in most vector drawing programs, when a graphic object is clicked it is selected and handles appear at the corners and along the sides:
image.png LibreOffice Draw image.pngDraw image.pngInkscape
In LibreOffice Draw, the handles do not indicate any action until the selection pointer hovers over one, and then the pointer turns into a corner or side resize pointer as shown. (Note: This is what Ubuntu does when you are in the Desktop resizing windows.)
In Inkscape, small double-headed arrows appear outside the object near the corners and sides; they indicate their resizing function. The sides also turn into ant trails. Another click on the item, and the arrows rotate 90° and indicate that the item can be rotated about its centre:
image.png Inkscape
Note that a handle is highlighted in Inkscape when the pointer hovers over it. Most vector drawing programs allow you to resize an object from its centre (not from the opposite corner) when a control key -- Alt, Ctrl, Shft -- is held down simultaneously.
In both Draw and Inkscape the arrows are quite large and easily selected, along the amazing now-you-see-them stick arrows in Minsky.
Both Inscape and Draw are invariant across platforms, so clearly the programs are bypassing the FWVM and supplying their own pointers. At some point stage Minsky is going to be used in education so it would be good for the bubby economists to see the same thing across various platforms.
I am against a single resize handle because it means fuffing about to move the item to the position you want. Why not a resize from centre? It accomplishes the same thing at the price of holding down a control key.
Last edit: Hedley Finger 2020-07-13
All the canvas items for which the four arrows could lead to clutter inside the corresponding icon now have a single, smaller resize handle on the bottom right-hand corner.
What is the experience of this functionality like in the latest beta? Should we extend it to all items on the canvas?
I've just seen this Wynand--it's nice. I think it meets my objections and
Hedley's. So I'd say lock it in. As usual, looking forward to the next
version!
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 Fri, Jul 17, 2020 at 3:53 PM Wynand wdednam@users.sourceforge.net
wrote:
Related
Bugs:
#1203Hi Steve,
Glad you think it is better now. :)
There are little fixes (such as flips and rotations of the ops and vars) we still need to take care of, but I see Russell has raised that issue in a separate ticket:
https://sourceforge.net/p/minsky/tickets/1201/