A modest proposal for a new property

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

A modest proposal for a new property

Tom Glod via use-livecode
In the past few List digests, there's been some discussion of practical issues regarding when a click does or doesn't count as clicking *on* a particular item. So, here's a proposed addition to LiveCode…

=============

Name: clickableRegion

Recognized abbreviation: clickReg

"clickableRegion" is a proposed property of anything in a stack that might a user might reasonably be expected to click on—controls, that is. We're talking buttons, fields, graphics, images, yada yada yada.

The clickableRegion of a control is a return-delimited list of points that define a region of the screen. Since clickableRegion is a property of a control, the engine's internal representation of these points should probably use the location of the control as the origin (the 0,0 point) for the clickableRegion's points.

Any click whose clickLoc is within the area defined by a control's clickableRegion, will be treated by the engine as if it were a click on that control.

The default value of a control's clickableRegion should be determined by that control's visible-on-screen pixels—for fields, this should be the field's rectangle; for graphics, this should be the points of the graphic; and so on and so forth.

The clickableRegion property should be both get-able and set-able. If you clear the clickableRegion (such as by setting it to ""), it should revert back to its default value.

Since clickableRegion can be set to arbitrary values, it may well happen that 2 or more controls have overlapping clickableRegions. This may not be a problem if the engine can simply make use of whatever magic it does when it handles clickLocs which fall within the rects of 2+ overlapping buttons. If the engine's existing 'click-disambiguation' machinery does not suffice to determine which control an ambiguous click is meant for, go with the control that has the highest-value layer property.

=============

Thoughts/comments/complaints?


   
"Bewitched" + "Charlie's Angels" - Charlie = "At Arm's Length"
   
Read the webcomic at [ http://www.atarmslength.net ]!
   
If you like "At Arm's Length", support it at [ http://www.patreon.com/DarkwingDude ].

_______________________________________________
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: A modest proposal for a new property

Tom Glod via use-livecode
How would you determine that a clickLoc is within such a
"region" or not?
(Say, for simplicity, the region is inside the control's
rectangle)

_______________________________________________
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: A modest proposal for a new property

Tom Glod via use-livecode
In reply to this post by Tom Glod via use-livecode
That won't work. Everything else is screen based, so a conversion of coordinates would have to be performed if relating to anything like object location.

Bob S


> On Sep 25, 2017, at 23:24 , Quentin Long via use-livecode <[hidden email]> wrote:
>
> The clickableRegion of a control is a return-delimited list of points that define a region of the screen. Since clickableRegion is a property of a control, the engine's internal representation of these points should probably use the location of the control as the origin (the 0,0 point) for the clickableRegion's points.


_______________________________________________
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: A modest proposal for a new property

Tom Glod via use-livecode
In reply to this post by Tom Glod via use-livecode
For many images with alpha layers the returned values would be a complex
set of points, and for some discontiguous.

If the purpose for obtaining that collection of points is to determine
whether a click at a specific location would be inside or outside the
control's region(s), that would require a lot of calculations, taking
non-trivial development time to write and a fair bit of CPU time to
execute in script.

It may be simpler and more efficient to let the engine do that
calculation using existing functions built into the engine.

See the Dictionary entries for:

- "within" function - describes how the clickable region is calculated
    and will serve the majority of use-cases well.

- "intersect" function - which goes further to allow the scripter to
    optionally define an alpha channel threshold.

--
  Richard Gaskin
  Fourth World Systems


Quentin Long wrote:

> In the past few List digests, there's been some discussion of practical issues regarding when a click does or doesn't count as clicking *on* a particular item. So, here's a proposed addition to LiveCode…
>
> =============
>
> Name: clickableRegion
>
> Recognized abbreviation: clickReg
>
> "clickableRegion" is a proposed property of anything in a stack that might a user might reasonably be expected to click on—controls, that is. We're talking buttons, fields, graphics, images, yada yada yada.
>
> The clickableRegion of a control is a return-delimited list of points that define a region of the screen. Since clickableRegion is a property of a control, the engine's internal representation of these points should probably use the location of the control as the origin (the 0,0 point) for the clickableRegion's points.
>
> Any click whose clickLoc is within the area defined by a control's clickableRegion, will be treated by the engine as if it were a click on that control.
>
> The default value of a control's clickableRegion should be determined by that control's visible-on-screen pixels—for fields, this should be the field's rectangle; for graphics, this should be the points of the graphic; and so on and so forth.
>
> The clickableRegion property should be both get-able and set-able. If you clear the clickableRegion (such as by setting it to ""), it should revert back to its default value.
>
> Since clickableRegion can be set to arbitrary values, it may well happen that 2 or more controls have overlapping clickableRegions. This may not be a problem if the engine can simply make use of whatever magic it does when it handles clickLocs which fall within the rects of 2+ overlapping buttons. If the engine's existing 'click-disambiguation' machinery does not suffice to determine which control an ambiguous click is meant for, go with the control that has the highest-value layer property.
>
> =============
>
> Thoughts/comments/complaints?


_______________________________________________
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: A modest proposal for a new property

Tom Glod via use-livecode
In reply to this post by Tom Glod via use-livecode
I asked because I thought QL's proposal might be based on a new algorithm?

There are already (partial) solutions to that:

In LCS getting "transparency" clicks of cross-layered objects is hard but
possible for a big class of regions (see stack #47 = "pointInShape" of
the Raspi stacks collection, July 2015).

For LCB I already implemented "transparency clicks" for rotated rectangular
shapes in my last two (already shared) widgets. Just now also for a bit more
complicated shapes (-> LC Global, Nov).

Both methods are based on the subdivison algorithm by MShimrat (Aug 1962).
This algorithm is in LCB/LC 9.0.0-dp9 *very* fast, by the way, usable in a
mouseDown handler for checking regions defined by several hundred points.

For more general regions (closed polygons), as Quentin L. suggests, this
algorithm is also applicable, *without change* as long as the region-polygons
are not self-intersecting.


_______________________________________________
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: A modest proposal for a new property

Tom Glod via use-livecode
Certainly doable in a script, but consider the simplicity of this with a
polygon as complex and even self-intersecting as you'd like:

on mouseMove
    put within(grc 1, the mouseLoc )
end mouseMove

--
  Richard Gaskin
  Fourth World Systems


hh wrote:

> I asked because I thought QL's proposal might be based on a new algorithm?
>
> There are already (partial) solutions to that:
>
> In LCS getting "transparency" clicks of cross-layered objects is hard but
> possible for a big class of regions (see stack #47 = "pointInShape" of
> the Raspi stacks collection, July 2015).
>
> For LCB I already implemented "transparency clicks" for rotated rectangular
> shapes in my last two (already shared) widgets. Just now also for a bit more
> complicated shapes (-> LC Global, Nov).
>
> Both methods are based on the subdivison algorithm by MShimrat (Aug 1962).
> This algorithm is in LCB/LC 9.0.0-dp9 *very* fast, by the way, usable in a
> mouseDown handler for checking regions defined by several hundred points.
>
> For more general regions (closed polygons), as Quentin L. suggests, this
> algorithm is also applicable, *without change* as long as the region-polygons
> are not self-intersecting.

_______________________________________________
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: A modest proposal for a new property

Tom Glod via use-livecode
In reply to this post by Tom Glod via use-livecode
The way that this problem is handled in sort other tools is to have a definable hit area for each control (usually those would be buttons). You can set the idle, over, and pressed versions of the button’s image, and also you can set the hit area image.

LiveCode already has a way to do most of that, couldn’t the hit area be another entry I the inspector’s icons section?
_______________________________________________
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: A modest proposal for a new property

Tom Glod via use-livecode
Colin Holgate write:

 > The way that this problem is handled in sort other tools is to have a
 > definable hit area for each control (usually those would be buttons).
 > You can set the idle, over, and pressed versions of the button’s
 > image, and also you can set the hit area image.
 >
 > LiveCode already has a way to do most of that, couldn’t the hit area
 > be another entry I the inspector’s icons section?

Where would one obtain the list of polygon points?

Currently the hit region is definable using the alpha channel.

--
  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: A modest proposal for a new property

Tom Glod via use-livecode
How do you currently set the alpha channel? The hit area icon I was suggesting could be an image with the alpha channel that the button uses. That way you could have any shape hit area, it wouldn’t have to be based on the button’s icon.

> On Sep 26, 2017, at 1:14 PM, Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> Colin Holgate write:
>
> > The way that this problem is handled in sort other tools is to have a
> > definable hit area for each control (usually those would be buttons).
> > You can set the idle, over, and pressed versions of the button’s
> > image, and also you can set the hit area image.
> >
> > LiveCode already has a way to do most of that, couldn’t the hit area
> > be another entry I the inspector’s icons section?
>
> Where would one obtain the list of polygon points?
>
> Currently the hit region is definable using the alpha channel.


_______________________________________________
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: A modest proposal for a new property

Tom Glod via use-livecode
How would you use the alpha channel to do this? I just had an image and the transparent part of the image did not send a mouseup message. I put a button behind the image to solve it. Was there a way I could have used the alpha channel to get the mouseup message anywhere in the image and still retain the transparency?

Ralph DiMola
IT Director
Evergreen Information Services
[hidden email]


-----Original Message-----
From: use-livecode [mailto:[hidden email]] On Behalf Of Colin Holgate via use-livecode
Sent: Tuesday, September 26, 2017 1:18 PM
To: How to use LiveCode
Cc: Colin Holgate
Subject: Re: A modest proposal for a new property

How do you currently set the alpha channel? The hit area icon I was suggesting could be an image with the alpha channel that the button uses. That way you could have any shape hit area, it wouldn’t have to be based on the button’s icon.

> On Sep 26, 2017, at 1:14 PM, Richard Gaskin via use-livecode <[hidden email]> wrote:
>
> Colin Holgate write:
>
> > The way that this problem is handled in sort other tools is to have
> > a definable hit area for each control (usually those would be buttons).
> > You can set the idle, over, and pressed versions of the button’s
> > image, and also you can set the hit area image.
> >
> > LiveCode already has a way to do most of that, couldn’t the hit area
> > be another entry I the inspector’s icons section?
>
> Where would one obtain the list of polygon points?
>
> Currently the hit region is definable using the alpha channel.


_______________________________________________
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: A modest proposal for a new property

Tom Glod via use-livecode
Ralph DiMola wrote:

 > How would you use the alpha channel to do this? I just had an image
 > and the transparent part of the image did not send a mouseup message.
 > I put a button behind the image to solve it. Was there a way I could
 > have used the alpha channel to get the mouseup message anywhere in
 > the image and still retain the transparency?

An image which appears to the user to have empty regions will have those
regions treated as empty by LC's default hit testing.  If doing your own
hit testing you can adjust the threshold passed to the intersect
function, but that's a lot of work compared to just using the best
object for the job at hand:

If you need a rectangular clickable area with an image inside it, what
you have is a button - you can set the icon of a button to the image you
want displayed in it.

It's still two objects, but lets you store the image object in a
separate stack where you can keep all of your image assets together,
rather than adding an extra object to the UI stack.

Extra bonus points: FWIW when I last tested this (though it's been quite
some time ago) buttons rendered much faster than images.

--
  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: A modest proposal for a new property

Tom Glod via use-livecode
Though this is not a universal solution… but related..

FWIW we have an enhancement request in for widgets to allow us to set their margins.
The entire area of a widget  is its "hit box" (term from Unity)

So all we need it to be able to set margins. Typical use case might be to have a 24 X 24 widget in a box that is 414w x 40 high… set the left margin to 20 and the widget effectively aligns left and the entire area across the screen becomes a hit box.



On 9/26/17, 9:21 AM, "use-livecode on behalf of Richard Gaskin via use-livecode" <[hidden email] on behalf of [hidden email]> wrote:

    If you need a rectangular clickable area with an image inside it, what
    you have is a button - you can set the icon of a button to the image you
    want displayed in it.
   
    It's still two objects, but lets you store the image object in a
    separate stack where you can keep all of your image assets together,
    rather than adding an extra object to the UI stack.
   
    Extra bonus points: FWIW when I last tested this (though it's been quite
    some time ago) buttons rendered much faster than images.

_______________________________________________
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: A modest proposal for a new property

Tom Glod via use-livecode
In reply to this post by Tom Glod via use-livecode
@Richard G.

Everybody engaged in this thread knows about "within" and "intersect".
They are good and very effective where they are applicable.

Now solve this simple example:

Make a circular arc showing 70% of a pie and then tell us when clicking
into the oval which part is hit, the 70% or the transparent 30%.

A one-liner?

The OP's proposal, for example, would define a series of points along the outline path of the uncomplete pie as hit-region. Good idea.
_______________________________________________
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: A modest proposal for a new property

Tom Glod via use-livecode
hh wrote:

 > Now solve this simple example:
 >
 > Make a circular arc showing 70% of a pie and then tell us when
 > clicking into the oval which part is hit, the 70% or the transparent
 > 30%.
 >
 > A one-liner?
 >
 > The OP's proposal, for example, would define a series of points along
 > the outline path of the uncomplete pie as hit-region. Good idea.

I don't have a one-liner for that.

Given a set of coordinates describing the hit region as suggested, what
would be the one-liner to solve it?

--
  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: A modest proposal for a new property

Tom Glod via use-livecode
In reply to this post by Tom Glod via use-livecode
Colin Holgate wrote:

 > The way that this problem is handled in sort other tools is to have a
 > definable hit area for each control (usually those would be buttons).
 > You can set the idle, over, and pressed versions of the button’s
 > image, and also you can set the hit area image.
 >
 > LiveCode already has a way to do most of that, couldn’t the hit area
 > be another entry I the inspector’s icons section?

This seems like a viable option, easy to use for a wide range of
use-cases and presumably within reasonable cost for the engine team to
implement, since it would be a variant of the existing code used to
calculate hit regions from the alpha channel.

--
  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: A modest proposal for a new property

Tom Glod via use-livecode
In reply to this post by Tom Glod via use-livecode
On 09/26/2017 01:46 PM, hh via use-livecode wrote:

> Now solve this simple example:
>
> Make a circular arc showing 70% of a pie and then tell us when clicking
> into the oval which part is hit, the 70% or the transparent 30%.

That's the point where I stopped trying to do pie charts in LiveCode.
Worse: try to set a tooltip showing the percentage under the cursor.

--
  Mark Wieder
  [hidden email]

_______________________________________________
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: A modest proposal for a new property

Tom Glod via use-livecode
Mark Wieder wrote:
> On 09/26/2017 01:46 PM, hh via use-livecode wrote:
>
>> Now solve this simple example:
>>
>> Make a circular arc showing 70% of a pie and then tell us when clicking
>> into the oval which part is hit, the 70% or the transparent 30%.
>
> That's the point where I stopped trying to do pie charts in LiveCode.
> Worse: try to set a tooltip showing the percentage under the cursor.

Multiple graphic 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: A modest proposal for a new property

Tom Glod via use-livecode
On 09/26/2017 06:02 PM, Richard Gaskin via use-livecode wrote:

 >> Worse: try to set a tooltip showing the percentage under the cursor.
 >
 > Multiple graphic objects?
 >

Been there.
When they're stacked on top of each other the transparent part of the
rect is still the object under the cursor, and so obscures what's
underneath.

--
  Mark Wieder
  [hidden email]

_______________________________________________
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: A modest proposal for a new property

Tom Glod via use-livecode
Mark Wieder wrote:

 > On 09/26/2017 06:02 PM, Richard Gaskin via use-livecode wrote:
 >
 >> Worse: try to set a tooltip showing the percentage under the
 >> cursor.
 > >
 > > Multiple graphic objects?
 > >
 >
 > Been there.
 > When they're stacked on top of each other the transparent part of the
 > rect is still the object under the cursor, and so obscures what's
 > underneath.

I would consider that a bug.  Polygons work quite nicely in tracking
only mouse actions over filled area; I can't imagine any reason we
wouldn't expect the same for all graphics.

Is there a bug report/enhancement request for this?

--
  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: A modest proposal for a new property

Tom Glod via use-livecode
In reply to this post by Tom Glod via use-livecode
The original issue that influenced this one was how to provide a larger hit
zone on an SVG widget. How would this property work for that?

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com



On September 26, 2017 6:56:56 PM Richard Gaskin via use-livecode
<[hidden email]> wrote:

> Colin Holgate wrote:
>
>  > The way that this problem is handled in sort other tools is to have a
>  > definable hit area for each control (usually those would be buttons).
>  > You can set the idle, over, and pressed versions of the button’s
>  > image, and also you can set the hit area image.
>  >
>  > LiveCode already has a way to do most of that, couldn’t the hit area
>  > be another entry I the inspector’s icons section?
>
> This seems like a viable option, easy to use for a wide range of
> use-cases and presumably within reasonable cost for the engine team to
> implement, since it would be a variant of the existing code used to
> calculate hit regions from the alpha channel.
>
> --
>   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



_______________________________________________
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
12