On Jun 14, 2017, at 9:21 AM, Devin Asay via use-livecode
mailto:use-livecode@lists.runrev.com>> wrote:
As one who teaches newbies LiveCode, I am a proponent of property labels that
are both succinct and descriptive, while not straying too far from the actual
property name. There are obvious ex
Great discussion!
> On Jun 14, 2017, at 1:20 AM, Mark Waddingham via use-livecode
> wrote:
>
> On 2017-06-14 02:18, Monte Goulding via use-livecode wrote:
>> I think this is one of those cases where the default behaviour was a
>> bad idea. Or perhaps was implemented before groups were used for
On 2017-06-14 02:18, Monte Goulding via use-livecode wrote:
I think this is one of those cases where the default behaviour was a
bad idea. Or perhaps was implemented before groups were used for much
other than backgrounds. Other objects we need to set to the formatted
width/height so why are grou
> On 14 Jun 2017, at 3:21 pm, J. Landman Gay via use-livecode
> wrote:
>
> I wonder why we have both lockUpdates and boundingRect. They seem very
> similar.
Lock updates is intended to avoid recalculation of group properties when child
object properties are changed. The general idea is:
set
I wonder why we have both lockUpdates and boundingRect. They seem very
similar.
On 6/13/17 7:54 PM, Scott Rossi via use-livecode wrote:
Keep in mind, there’s also the lockUpdates property of groups, which while
differing mechanically “under the hood”, essentially causes the same perceived
res
What about "keepGroupRect"?
Like set the keepGroupRect of grp "xyz" to true
That way it explicitly limits it to groups. Or it could be
"KeepRect" but that might imply a more general meaning.
Bill P
William Prothero
http://es.earthednet.org
> On Jun 13, 2017, at 5:44 PM, Richard Gaskin via use-
Keep in mind, there’s also the lockUpdates property of groups, which while
differing mechanically “under the hood”, essentially causes the same perceived
result — while enabled, a group’s rect is not changed when its child objects
are resized/repositioned.
I don’t know how all these are verbose
james at thehales.id.au wrote:
> Jacque wrote:
>> I agree with the concept in general, but the word "crop" implies
>> permanent removal. When you crop an image, it permanently erases the
>> parts outside the rectangle. Unfortunately I can't think of a better
>> term. Maybe something like "prevent
Jacque wrote:
> I agree with the concept in general, but the word "crop" implies
> permanent removal. When you crop an image, it permanently erases the
> parts outside the rectangle. Unfortunately I can't think of a better
> term. Maybe something like "prevent auto-resizing"?
Actually it doesn'
> On 14 Jun 2017, at 8:19 am, Devin Asay via use-livecode
> wrote:
>
> Yes, in essence. If you have a group and set the clipsToRect property to true
> (there’s no way to set it in the PI yet—that’s what I’m going to add), you
> can then change the rect of the group, and the group will *not* a
> Brahmanathaswami. wrote:
> I am pretty sure that
>
> Crops to rect
>
> would suffice.
+1
Even I could follow that argument without reading it twice. ;-)
James
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this ur
On 06/13/2017 03:19 PM, Devin Asay via use-livecode wrote:
ClipsToRect is the property name. So what “plain language” label do you think
would be best for the PI?
I always have my preference set to display the LC property rather than
the 'description', so I don't really care, but...
how ab
AnchorRect?
Bob S
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
+1 but too late.
Bob S
> On Jun 13, 2017, at 10:15 , Scott Rossi via use-livecode
> wrote:
>
>
>
> The most important rule to follow when establishing any new property should
> be: Don't use "dont".
>
> The application of a "negative property" should never have been established
> (dontW
> On Jun 13, 2017, at 4:19 PM, Devin Asay via use-livecode
> wrote:
>
> Yes, in essence. If you have a group and set the clipsToRect property to true
> (there’s no way to set it in the PI yet—that’s what I’m going to add), you
> can then change the rect of the group, and the group will *not*
Yes, in essence. If you have a group and set the clipsToRect property to true
(there’s no way to set it in the PI yet—that’s what I’m going to add), you can
then change the rect of the group, and the group will *not* automatically reset
its rect to the size of the child controls + margin. It is
(The ? was meant to soften my suggestion, not to indicate that I'm not
following - that's that's always a possibility)
Phil
On 6/13/17 3:11 PM, Phil Davis wrote:
So it's about manually updating the rect vs. having it in an
auto-update mode?
Phil Davis
On 6/13/17 3:01 PM, Devin Asay via us
So it's about manually updating the rect vs. having it in an auto-update
mode?
Phil Davis
On 6/13/17 3:01 PM, Devin Asay via use-livecode wrote:
So far I’m kind of partial to Scott R’s “Persistent rect”. Conversely, it could
be something like “Auto-update rect”, but then the checkbox would b
So far I’m kind of partial to Scott R’s “Persistent rect”. Conversely, it could
be something like “Auto-update rect”, but then the checkbox would be opposite
the property setting. That’s almost as bad as something like dontUpdateRect.
(Sorry, Scott, plug your ears.)
Devin
On Jun 13, 2017, at
On 6/13/17 4:17 PM, Jim Lambert via use-livecode wrote:
or
‘Clip Group to rect’
There are a few others like that, where the explanation is just the
original term (or close) with spaces added. I always felt that didn't
explain much. But the suggestion does have company in the PI.
--
Jacquel
or
‘Clip Group to rect’
Jim Lambert
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Group crops to rect
> Jacque wrote:
> I agree with the concept in general, but the word "crop" implies permanent
> removal. When you crop an image, it permanently erases the parts outside the
> rectangle. Unfortunately I can't think of a better term. Maybe something like
> "prevent auto-resizin
Tks Devin for moving this over here.
@ Jacque: OK rignt-- agreed "crop" is wrong.. because, yes, it implies
"irrevocably chopping off image data"
But "lock" also has the problem of assuming the loc is locked, which it is not.
How about a word that really is what it does
Constrain rect
Logic
Jacque,
I moved this tangent to a new thread. See thread "clipsToRect property (was Re:
Instantiaing Grouped Controls - Templates - Responsive)”.
FWIW I had the same reaction to “crop”.
Devin
On Jun 13, 2017, at 1:31 PM, J. Landman Gay via use-livecode
mailto:use-livecode@lists.runre
On 6/13/17 12:36 PM, Sannyasin Brahmanathaswami via use-livecode wrote:
there is also strong logic for
Group crops to rect
This also correlates well with the word "clips" in the property name itself.
i.e. zero ambiquity
I agree with the concept in general, but the word "crop" implies
perma
My understanding is, “before” and “after” are really only intended to work with
mouse events.
Regards,
Scott Rossi
Creative Director
Tactile Media, UX/UI Design
> On Jun 13, 2017, at 12:24 PM, Sannyasin Brahmanathaswami via use-livecode
> wrote:
>
> OK so *why* is
>
> before mouseup
Oh boy, this custom control thing is awesome + external behaviors as text only
scripts… What a break through! At 60+ should not get too excited about
anything, but this has my brain on fire. I even took all the code out of the
control, moved it to a behavior… and then, even for buttons the *onl
Good suggestions, Scott and BR.
My list now:
- Persistent rect
- Crop to rect
- Lock rect (analogous to lockLoc’s “Lock size and position”)
Anyone else want to chime in?
Yes, I admit I threw up a little bit in my mouth when I typed “Don’t…”, but in
my defense it was pretty far down the l
re: label for adding clipsToRect to the PI
from a graphic design point of view…where people are frequently doing this very
same thing inside some frame|window|div etc. in fact, may be switching back
and forth between their image design environment and Livecode…
there is also strong logic for
The most important rule to follow when establishing any new property should be:
Don't use "dont".
The application of a "negative property" should never have been established
(dontWrap, I'm talking to you). Properties should always be non-negative and
simply enabled or disabled depending on t
On Jun 12, 2017, at 11:45 PM, Mark Waddingham via use-livecode
mailto:use-livecode@lists.runrev.com>> wrote:
On 2017-06-12 22:22, Richard Gaskin via use-livecode wrote:
For group controls you will find that it is. Try it. It's quite handy.
Another useful thing which I'm not sure is particularl
Mark Waddingham wrote:
> On 2017-06-13 17:37, Richard Gaskin via use-livecode wrote:
>> FWIW the clipsToRect property does not appear among the keys of
>> "the properties" of a group either.
>>
>> Should I add a note to that report, or file a separate report for
>> that?
>
> If you could file a s
On 2017-06-13 17:37, Richard Gaskin via use-livecode wrote:
Mark Waddingham wrote:
I think this might be missing from the PI control definitions:
http://quality.livecode.com/show_bug.cgi?id=18945
FWIW this property does not appear among the keys of "the properties"
of a group either.
Sh
Mark Waddingham wrote:
> I think this might be missing from the PI control definitions:
>
> http://quality.livecode.com/show_bug.cgi?id=18945
FWIW this property does not appear among the keys of "the properties" of
a group either.
Should I add a note to that report, or file a separate rep
Sannyasin Brahmanathaswami wrote:
> On 6/12/17, 7:45 PM, "use-livecode on behalf of Mark Waddingham wrote:
>
> Another useful thing which I'm not sure is particularly visible
> (but is in the dictionary!) is the group 'clipsToRect' property.
...
> Mark …Ha! "OOooh Myy Gawd"
>
> had I know
Mark Waddingham wrote:
> On 2017-06-12 22:22, Richard Gaskin via use-livecode wrote:
>> For group controls you will find that it is. Try it. It's quite
>> handy.
>
> Another useful thing which I'm not sure is particularly visible (but
> is in the dictionary!) is the group 'clipsToRect' property.
Mark Waddingham wrote:
This might have been mentioned somewhere else in this thread, but its
probably worth repeating if so as a group with clipsToRect true, and a
resizeControl handler makes a good base for a custom control.
BR: indeed confirmed
just by setting that one property f
On 2017-06-13 08:53, Sannyasin Brahmanathaswami via use-livecode wrote:
Mark …Ha! "OOooh Myy Gawd"
had I known this from the beginning it would all have "worked out of
the box" because the resetting rects and locs of child objects of the
group was causing the rect of the group to "jump around" h
Mark …Ha! "OOooh Myy Gawd"
had I known this from the beginning it would all have "worked out of the box"
because the resetting rects and locs of child objects of the group was causing
the rect of the group to "jump around" hence there no fixed coord system to
work from.
This is great… right we
On 2017-06-12 22:22, Richard Gaskin via use-livecode wrote:
For group controls you will find that it is. Try it. It's quite handy.
Another useful thing which I'm not sure is particularly visible (but is
in the dictionary!) is the group 'clipsToRect' property.
When 'the clipsToRect' is set t
J. Landman Gay wrote:
> On 6/12/17 1:19 PM, Richard Gaskin via use-livecode wrote:
>> > a) if a stack is 414 X 736, and opens on a device that is 414 X
>> > 736 with full screen mode set to showAll… is the resizeStack
>> > handler fired?
>>
>> Supporting your interest in avoiding theory, I'm com
Sannyasin Brahmanathaswami wrote:
> Yes, I did try. and certainly any manual resizing fires the resize
> msgs as expect.
Excellent. You now have one trigger point for the sequence of resizing
actions when a stack is opened or the orientation is changed.
If you have multiple cards and you nee
On 6/12/17 1:19 PM, Richard Gaskin via use-livecode wrote:
> 2) I like everything you are describing but I don't get this:
> "resizeControl" is never triggered if the resizeStack is "dormant"
> that was my last "problem" … so, how are we "trigger" the resizeStack
> to "fire" when any stack
On 12/06/2017 18:30, Sannyasin Brahmanathaswami via use-livecode wrote:
2) I like everything you are describing but I don't get this: "resizeControl" is never triggered if the resizeStack is
"dormant" that was my last "problem" … so, how are we "trigger" the resizeStack to
"fire" when any st
Yes, I did try. and certainly any manual resizing fires the resize msgs as
expect.
But the interest was, initially, to get the resizeControl to fire from script.
As resizeable it off of all stacks -- deliberately so team does not
inadvertently break their rect with the slip of a drag/save.
I w
Sannyasin Brahmanathaswami wrote:
> @ Richard
>
> 1) Again, all very nice theory
>
> Viz-a-viz my lament… "where are all the examples, sample code" We all
> don't live it the stratosphere of visionary LiveCode architecture like
> you doi. -☺
I'm relatively late to mobile development, actually.
@ Richard
1) Again, all very nice theory
Viz-a-viz my lament… "where are all the examples, sample code" We all don't
live it the stratosphere of visionary LiveCode architecture like you doi. -☺
Can you post sample stacks with your resize handlers?
2) I like everything you are describing but I
Sannyasin Brahmanathaswami wrote:
> first: the resizeControl thing did not work out at all because it
> depends on the user resizing the stack.
The resizeStack message should be sent in response to anything that
causes the stack to resize.
This should not be limited to the user action of resi
OK well, continued working on this
first: the resizeControl thing did not work out at all because it depends on
the user resizing the stack.
using that same handler but with "send" breaks everything because if you set
the rect of the main enclosing object then the rect of the group "me" start t
Alex Tweedly wrote:
> On 09/06/2017 00:40, Richard Gaskin via use-livecode wrote:
>> I don't understand. A script-only stack contain no objects, so
>> even if you later copy them, they still need to be dynamically
>> instantiated at some point, no?
>>
>> Like a Zen koan: how can there be a binar
On 09/06/2017 00:40, Richard Gaskin via use-livecode wrote:
I don't understand. A script-only stack contain no objects, so even
if you later copy them, they still need to be dynamically instantiated
at some point, no?
Like a Zen koan: how can there be a binary object where there is no
bi
Alex Tweedly wrote:
> On 08/06/2017 22:37, Richard Gaskin via use-livecode wrote:
>> Alex Tweedly wrote:
>>
>> > On 08/06/2017 20:20, Richard Gaskin wrote:
>> >> If you're committed to a script-only stack there's no decision to
>> >> make: every control must be instantiated dynamically, because a
On 08/06/2017 22:37, Richard Gaskin via use-livecode wrote:
Alex Tweedly wrote:
> On 08/06/2017 20:20, Richard Gaskin via use-livecode wrote:
>> If you're committed to a script-only stack there's no decision to
>> make: every control must be instantiated dynamically, because a
>> script-only s
Alex Tweedly wrote:
> On 08/06/2017 20:20, Richard Gaskin via use-livecode wrote:
>> If you're committed to a script-only stack there's no decision to
>> make: every control must be instantiated dynamically, because a
>> script-only stack contains the stack script only, no objects.
>>
> Well, not
On 08/06/2017 20:20, Richard Gaskin via use-livecode wrote:
In general I try to "go to TOWN": Touch Only What's Needed.
If I don't need to create an object I probably won't, adjusting an
existing object instead. It only saves one step, but its a savings
just the same.
If you're committed
Sannyasin Brahmanathaswami wrote:
> 1) does it make sense to build this dynamically as needed from script
> using "create" and then you put this "create control" script into a
> library? It has the advantage of no binary object, so you can keep it
> in your text only "stacks" .livecodescript, but
I've done it both ways but usually only create controls on the fly when
there are only a few objects (two or three usually.) Anything more complex,
I use a template group and copy that instead. It's nearly instantaneous. I
did a mobile app that copied a group dozens of times in a preOpenCard
ha
Hi BR - for me it depends on how many instances of the control I’m likely to
need on the screen. If I only ever display one at a time then I usually include
it as a shared group and place it on any card that might require it and
show/hide, populate and layer it dynamically as required. If I need
58 matches
Mail list logo