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
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 h
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
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.
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...
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
ahsoftw...@gmail.
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
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)
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 n
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
> >>
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
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 scr
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
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
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 <
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 tar
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
_
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
> wrote:
>
> When I clone a graphic (an 8 by 8 pixel oval) in LiveCode 8.1.1 the cop
18 matches
Mail list logo
