Clone graphic does not respect dimensions
Michael Julian Lew
michaell at unimelb.edu.au
Thu Dec 1 19:27:09 EST 2016
Seems to me that if the current restriction on the result of “clone” is intended to prevent possible problems when tools palette is being used then a very bad design decision was made. A solution should not affect what happens when the user clones an abject that is already in the stack.
The script function “clone” should clone the object _exactly_ when used by itself, but could be used in conjunction with size-dectecting code for the palette.
Michael
BNig wrote:
that is determined somewhat arbitrarily by the
revBackScriptLibrary in handler
on newGraphic
if the width of the target < 9 and the height of the target < 9 then
.... use default values
Would that be a user experience bug?
What would be a good reason to prevent the user from doing a
reasonable action like this?
If the size is explicitly set, why not let it remain so?
I expect this was done to prevent the case where someone:
1. chooses a graphic tool from the Tools palette
2. clicks to start dragging out the graphic
3. accidentally double-clicks instead and ends the graphic, resulting
in an unintentionally-tiny graphic
It also lets you click once with a graphic tool to create a
default-size graphic at that spot.
Perhaps newGraphic could test what tool is chosen, and change the
size only if the tool is "graphic".
I can see the benefit of minimizing occurrences of objects that are
*prohibitively* small to work with, but am less enthused about
constraining options for the user at the much lower threshold of mere
possible inconvenience.
I'd opt for a 4px threshold.
--
More information about the use-livecode
mailing list