Clone graphic does not respect dimensions

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Clone graphic does not respect dimensions

MichaelL-2
When I clone a graphic (an 8 by 8 pixel oval) in LiveCode 8.1.1 the copy comes out at the default size for a new oval, 120 by 120. That would not be a clone, in my opinion. Is it correct behaviour?

Michael

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

ScottR
It's wrong but it's always been like this.  LC doesn't like graphics smaller than 9 pixels.

Regards,

Scott Rossi
Creative Director
Tactile Media UX/UI Design

> On Nov 30, 2016, at 4:48 PM, Michael Julian Lew <[hidden email]> wrote:
>
> When I clone a graphic (an 8 by 8 pixel oval) in LiveCode 8.1.1 the copy comes out at the default size for a new oval, 120 by 120. That would not be a clone, in my opinion. Is it correct behaviour?
>
> Michael
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

Richmond Mathewson-2
In reply to this post by MichaelL-2
Was the graphic locked?

Richmond.

On 12/1/16 2:48 am, Michael Julian Lew wrote:
> When I clone a graphic (an 8 by 8 pixel oval) in LiveCode 8.1.1 the copy comes out at the default size for a new oval, 120 by 120. That would not be a clone, in my opinion. Is it correct behaviour?
>
> Michael
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

BNig
In reply to this post by ScottR
Scott Rossi wrote
It's wrong but it's always been like this.  LC doesn't like graphics smaller than 9 pixels.

Regards,

Scott Rossi
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

if you set those values to "<8" then it lets you clone a 8 by 8 graphic.

Kind regards
Bernd
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

Richard Gaskin
BNig wrote:
 > Scott Rossi wrote
 >> It's wrong but it's always been like this.  LC doesn't like graphics
 >> smaller than 9 pixels.
 >>
 >> Regards,
 >>
 >> Scott Rossi
 >
 > 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
 >
 > if you set those values to "<8" then it lets you clone a 8 by 8
 > graphic.

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?

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

Jeanne A. E. DeVoto
At 7:39 AM -0800 12/1/2016, Richard Gaskin wrote:

>BNig wrote:
>>  Scott Rossi wrote
>>>  It's wrong but it's always been like this.  LC doesn't like graphics
>  >> smaller than 9 pixels.
>  >
>>  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".

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

Richard Gaskin
Jeanne A. E. DeVoto wrote:

 > At 7:39 AM -0800 12/1/2016, Richard Gaskin wrote:
 >>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.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

MichaelL-2
In reply to this post by MichaelL-2
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.

--
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

Richard Gaskin
Michael Julian Lew wrote:

 > Richard Gaskin wrote:
 >> 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?
 >>
 >> 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.
 >
 > 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.

In principle I agree.  The challenge is that we don't have a separate
message for clone as distinct from other ways to create a new graphic.

If it were up to me, I'd say let the user do whatever they want.  If
they want to make a control too small to be used, who am I to stop them?

But as Jeanne suggested, it may be that the IDE is trying to be helpful
in cases of accidental resizing too small.

Personally, I'd favor simplifying the extra work the IDE is doing and
just leave the user alone.

If there must be a threshold, at least make it smaller than it is now.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

BNig
Richard Gaskin wrote
Michael Julian Lew wrote:

 > Richard Gaskin wrote:
 >> 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?
 >>
 >> 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.
 >
 > 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.

In principle I agree.  The challenge is that we don't have a separate
message for clone as distinct from other ways to create a new graphic.

If it were up to me, I'd say let the user do whatever they want.  If
they want to make a control too small to be used, who am I to stop them?

But as Jeanne suggested, it may be that the IDE is trying to be helpful
in cases of accidental resizing too small.

Personally, I'd favor simplifying the extra work the IDE is doing and
just leave the user alone.

If there must be a threshold, at least make it smaller than it is now.

--
  Richard Gaskin
It seems the consensus is to lower the threshold when graphics are changed to default sizes. I will do an enhancement request next week and propose that the currrent threshold of 8 by 8 and lower will be reduced to 5 by 5 and lower. That should cover most clone requests and still prevents most accidental clicks. The double-click delta default is 4 in case someone double-clicks right away.

If Edinburgh agrees I will do a pull-request.

Kind regards
Bernd
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

Jeanne A. E. DeVoto
At 3:02 AM -0800 12/2/2016, BNig wrote:
>It seems the consensus is to lower the threshold when graphics are changed
>to default sizes. I will do an enhancement request next week and propose
>that the currrent threshold of 8 by 8 and lower will be reduced to 5 by 5
>and lower.


Is there any reason not to check the tool, instead of playing with
the size threshold?

If the tool is not any of the graphic tools, then the user was not
manually creating the object: it must have been created via script
and there's no issue of accidental clicks, so the IDE should not
override the size. If the tool is a graphic tool, then the user
manually created the object and so it's reasonable to apply a size
floor.

Am I missing something?

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
hh
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

hh
In reply to this post by MichaelL-2
Yet another option is a 0.618 x 0.618 pixels threshold. I definitely need that
when using a HiRes display ;-)

"A common mistake that people make when trying to design something completely
foolproof is to underestimate the ingenuity of complete fools." (Douglas Adams)


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

Richard Gaskin
In reply to this post by Jeanne A. E. DeVoto
Jeanne A. E. DeVoto wrote:

 > At 3:02 AM -0800 12/2/2016, BNig wrote:
 >> It seems the consensus is to lower the threshold when graphics are
 >> changed to default sizes. I will do an enhancement request next week
 >> and propose that the currrent threshold of 8 by 8 and lower will be
 >> reduced to 5 by 5 and lower.
 >
 > Is there any reason not to check the tool, instead of playing with
 > the size threshold?
 >
 > If the tool is not any of the graphic tools, then the user was not
 > manually creating the object: it must have been created via script
 > and there's no issue of accidental clicks, so the IDE should not
 > override the size. If the tool is a graphic tool, then the user
 > manually created the object and so it's reasonable to apply a size
 > floor.

I believe the original post here was about cloning, presumably done via
Option+drag (on macOS, or Cntrl+drag on Win and Linux).

But another case might be scripted creation of objects that use drag
rather than the create command.

So many possibilities that I wouldn't be opposed to completely removing
arbitrary IDE-imposed limits on what people can do with their objects.

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

mwieder
In any event, if there's going to be a size trap, I don't believe it belongs in the backscript newGraphic handler. If the intention of the minimum size restriction is to prevent accidental double-clicks, there are better ways to deal with that situation.
--
 Mark Wieder
 ahsoftware@gmail.com
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

Jeanne A. E. DeVoto
In reply to this post by Richard Gaskin
At 12:23 PM -0800 12/2/2016, Richard Gaskin wrote:
>I believe the original post here was about cloning, presumably done
>via Option+drag (on macOS, or Cntrl+drag on Win and Linux).

Hmm, I was under the impression that it was scripted using the
"clone" command. I'd forgotten about option-drag...

...but that's also done with the pointer tool, not the graphic tool.
So checking the tool would also exempt that case from auto-resizing
small graphics.

>So many possibilities that I wouldn't be opposed to completely
>removing arbitrary IDE-imposed limits on what people can do with
>their objects.

A good point, but there's also the utility of having the interface
act to "heal" common mistakes and enable common patterns (like
single-clicking with an object tool to create that object). I think
this may simply be a philosophical difference-some people prefer an
IDE that stays out of the way, and others prefer one that does
certain things for them. The trick is always to figure out what
things most users will take as helpful, and what they'll take as
getting in the way. ;-)

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

Richard Gaskin
Jeanne A. E. DeVoto wrote:

 > At 12:23 PM -0800 12/2/2016, Richard Gaskin wrote:
 >>I believe the original post here was about cloning, presumably done
 >>via Option+drag (on macOS, or Cntrl+drag on Win and Linux).
 >
 > Hmm, I was under the impression that it was scripted using the
 > "clone" command. I'd forgotten about option-drag...
 >
 > ...but that's also done with the pointer tool, not the graphic tool.
 > So checking the tool would also exempt that case from auto-resizing
 > small graphics.

IMO it would be even worse to have an IDE convenience prevent people
from scripting their apps.


 >>So many possibilities that I wouldn't be opposed to completely
 >>removing arbitrary IDE-imposed limits on what people can do with
 >>their objects.
 >
 > A good point, but there's also the utility of having the interface
 > act to "heal" common mistakes and enable common patterns (like
 > single-clicking with an object tool to create that object).

How often does that accident that happen?

And how often does one need to use a smaller graphic in their app and
find themselves mystified by being unable to do so?

Either path has trade-offs, but since this is a developer tool, rather
than a consumer drawing tool, I'd favor design decisions that leave the
developer in control.

If someone's smart enough to develop software, they're probably smart
enough to figure out how to grab a resize handle and make a graphic
larger. :)

--
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

BNig
In reply to this post by Jeanne A. E. DeVoto
Jeanne A. E. DeVoto wrote
Hmm, I was under the impression that it was scripted using the
"clone" command. I'd forgotten about option-drag...

...but that's also done with the pointer tool, not the graphic tool.
So checking the tool would also exempt that case from auto-resizing
small graphics.
I like the idea of checking the tool to allow cloning at sizes below 9 by 9 if it were not for the use case that copying/pasting a graphic smaller than 9 by 9 is possible while the graphic tool is active.
This is where checking for the tool would fail and the graphic would be pasted at default dimensions.

This leaves changing the "newGraphic" handler wholesale (without considering the tool) to values smaller than 9 by 9 e.g. smaller 6 by 6 to cover most common use cases and still let the IDE prevent user mishaps by converting a new graphic to default 120 by 120 if the newly created graphic is smaller than 6 by 6.

Kind regards
Bernd
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

Mark Waddingham-2
In reply to this post by Richard Gaskin
On 2016-12-03 01:47, Richard Gaskin wrote:
> If someone's smart enough to develop software, they're probably smart
> enough to figure out how to grab a resize handle and make a graphic
> larger. :)

I think that was the problem - and why the check was present. (Of
course, the check should only ever have been done whilst the user was
*editing* in the IDE, and not in the normal course of things - but
that's an entirely different matter).

Prior to 8.0, if your control was smaller than 8x8 it was virtually
impossible to use the edit handles as they were 'interior' to the
object. I suspect that was why the minimum size restriction was put in
place.

Since 8.0, however, edit handlers are on the corners of the controls
meaning that you can still easily resize a control which is 1x1. This
probably means that check can actually be removed without any adverse
effects.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Clone graphic does not respect dimensions

BNig
Mark Waddingham-2 wrote
On 2016-12-03 01:47, Richard Gaskin wrote:
> If someone's smart enough to develop software, they're probably smart
> enough to figure out how to grab a resize handle and make a graphic
> larger. :)

I think that was the problem - and why the check was present. (Of
course, the check should only ever have been done whilst the user was
*editing* in the IDE, and not in the normal course of things - but
that's an entirely different matter).

Prior to 8.0, if your control was smaller than 8x8 it was virtually
impossible to use the edit handles as they were 'interior' to the
object. I suspect that was why the minimum size restriction was put in
place.

Since 8.0, however, edit handlers are on the corners of the controls
meaning that you can still easily resize a control which is 1x1. This
probably means that check can actually be removed without any adverse
effects.

Warmest Regards,

Mark.
Enhancement request:
http://quality.livecode.com/show_bug.cgi?id=18966

Kind regards
Bernd