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