Re: A modest proposal for a new property

[hh via use-livecode]

@Quentin L.

Hopefully the following citation can help all of us to understand
better what's going on. Especially point (1) relates to our current
discussion:

Posted by Mark Waddingham in a long thread (2015) in the LC Builder
forum, not hard to find. It still describes at about the current state.

"Okay so there are two things here... How things work at the moment (1)
and how I propose things should evolve (2).

The code you write in LCB (let's call it the 'widget implementation') 
sits at the same level as the C++ code in the engine which controls 
the 'legacy' controls. There's a C++ wrapper control in the engine 
(MCWidget) which provides a host environment for the LCB code. It 
manipulates and marshals various parts of the event stream and other 
aspects of the engine to give a reasonably 'clean' set of events 
which the widget implementation sees. From the high-level perspective 
you have a widget object on which you can set a script (let's call 
this the 'script object'). You can think of it as the script object 
being the realization of a widget implementation in the LiveCode 
environment.

(1) At the moment widget implementations are entirely responsible for 
dispatching all messages to their script object. This means that if a 
widget implementation does not react to, or post the mouse event 
messages, the script object will not see them. This mirrors how the 
legacy controls are written in the engine - they, for the most part, 
individually control what event messages are sent to the script 
objects and when.

(2) My proposal is to change this slightly to ensure there is a 
reasonable level of 'default behavior' in widgets, generalizing and 
improving the current (although not entirely consistent) default 
behavior amongst the existing legacy controls. Using a mouse click as 
an example, here is my current suggestion of how it would work:

The engine receives a mouseDown event on a widget.
A mouseDown message is sent to the script object of the widget.
If the mouseDown message is handled (and not passed) then the script 
object will have been considered to have 'grabbed' the mouse click 
gesture and will then receive the mouseUp / mouseRelease message at 
some later date - the widget implementation will not see the 
OnMouseDown event or the subsequent OnMouseUp.
If, on the other hand, the mouseDown message is not handled then the 
widget will receive the OnMouseDown event and subsequently the 
OnMouseUp event. In this case script would still receive the 
mouseUp / mouseRelease message *after* the widget has processed the 
OnMouseUp event - this is to ensure that (just like widgets) the 
script object always gets matched pairs of mouseDown / mouseUp.

With this logic, the script of a widget can choose to 'block' the 
widget implementation from processing the mouse click gesture but if 
it chooses not to then the widget will handle it.

For the other mouse events, such as mouseEnter / mouseLeave / 
mouseMove then they are just notifications so script and the widget 
will get the events to process.

This logic should mean that any widget which does not handle mouse 
click events will still allow the script object to handle them 
(without any additional work); and widgets that do handle mouse click 
events still generate the script messages which you might expect.

Let's take an example of a push button widget. I'm imagining here 
that the push button widget will dispatch a 'clicked' message to 
script when a mouseUp event is received within its bounds. The order 
of events would be as follows:

In the case the script object passes (or does not handle) the 
mouseDown event:
mouseDown to script object
OnMouseDown to widget
...
OnMouseUp to widget
clicked to script object
mouseUp to script object

In the case the script object handles (and does not pass) the 
mouseDown event:
mouseDown to script object
...
mouseUp to script object

This hopefully gives the best of both worlds - script can control 
whether widgets handle the mouse gestures, and still get notification 
about significant points in the gesture; whilst widgets are 
guaranteed to get a mouse gesture to process in entirety (if script 
decides it should be so) and thus an opportunity to reinterpret the 
gesture as a higher-level event (such as clicked, or 'barClicked' in 
the example of a graphing widget as suggested by Trevor)."

___
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

Re: A modest proposal for a new property

[Quentin Long via use-livecode]

sez hh :
> > > JLG wrote:
> > > 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?
> 
> > Quentin L. wrote:
> > I?m thinking that a single line of code would suffice:
> >
> > set the clickableRegion of widget ?Fred? to ListOfPoints
> >
> > As i?ve noted previously, the engine *already* handles clickable
> > regions for *every* control ... 
> 
> No. Sadly (or luckily, depending on one's point of view) a widget is
> not an ordinary control. This has to be implemented in the widget.
Hold it. I don't--can't--believe that the engine *does not* take care of 
deciding when a given mouse-click does or doesn't land on a widget. Unless 
you're saying that the mouse-click might trigger *either* the widget itself, 
*or* the widget's script, depending on exactly what location the mouse-click is 
at?

> To see this write one that handles only the mouse events, not to
> speak of a clickable region.
> Even this is hard to control: who gets first which mouseEvent, the
> widget's script or the widget.
I don't see what difference it makes whether a mouse-click causes mouse events 
to be sent to the *widget proper*, or, instead, to the *widget's script*. 
Either way, *something* has to determine whether the dingus is triggered by a 
mouse-click at an arbitrary screen location, right? And if it's not the engine 
which does that… what *is* doing that?

   
"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
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

Re: A modest proposal for a new property

[J. Landman Gay via use-livecode]

On 9/28/17 11:53 AM, hh via use-livecode wrote:

JLG wrote:
The original issue that influenced this one was
how to provide a larger hit zone on an SVG widget...


Yet another option.
You can use my iconGrid widget for that. Use a 1x1 grid
with your SVG icon as property.

It informs you whether the used SVG icon itself or the
enlarged transparent region was clicked (look at its script).
Also the placement of the SVG icon within the enlarged
widget can be set.


Thanks, I hadn't thought of that. It sounds like something we can use 
until LC implements margins.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: A modest proposal for a new property

[hh via use-livecode]

> JLG wrote:
> The original issue that influenced this one was
> how to provide a larger hit zone on an SVG widget...

Yet another option.
You can use my iconGrid widget for that. Use a 1x1 grid
with your SVG icon as property.

It informs you whether the used SVG icon itself or the
enlarged transparent region was clicked (look at its script).
Also the placement of the SVG icon within the enlarged
widget can be set.


___
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

Re: A modest proposal for a new property

[Jim Lambert via use-livecode]

> Herman wrote:
> 
> 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?


Here’s a kludge. But it’s no one liner.

It takes a few milliseconds depending on size of the graphic.

on mouseUp pButtonNumber
   put inMe(the target, the clickloc)
end mouseUp

function inMe targ, where
   lock screen
   import snapshot from targ
   set the loc of the last image to the loc of targ
   put within(the last image, where) into returnValue
   delete the last image
   return returnValue
end inMe

Put the mouseUp handler in the graphic script.
The function can go in the graphic, group, card or stack script.

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

Re: A modest proposal for a new property

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:
> On 2017-09-27 03:20, Mark Wieder via use-livecode wrote:
>> 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.
>
> Methinks that could be considered a bug :)
>
> The graphic object does do hit-testing based on the content of the
> graphic - but it is not complete/100% accurate for all graphic types.
...
> For ovals: incorrect! It checks the point is within the oval defined
> by the rect *but* it does not take into account startangle or angle.

Thanks  - submitted:

Oval graphics use incorrect hit-testing
http://quality.livecode.com/show_bug.cgi?id=20479

--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: A modest proposal for a new property

[Mike Bonner via use-livecode]

As far as the pie charts go.. A workaround is to create the required ovals
one at a time and import an image from each, then stack THOSE up.

Or alternatively use the ovals, stack them, group them, and have a list of
background colors used in each, and then in the group mouseup handler use
the mousecolor to determine what/where was clicked.  To be able to hit an
area that has no oval color would require one more hoop to be jumped
through.  Place a full oval matching background color behind the pie
segments that can catch a click in the "empty" location (still using the
mousecolor)

Which makes me think, how about a new object.  An oval with definable color
arcs.  0 to 85 blue, 85 to 270 red, 270 onward green.   (or an innocuous
grey meaning no data defined for that chunk)  Then one could still check
the mousecolor to determine a clicks result.  The negative of this method
is that one couldn't explode the pie chart.

On Wed, Sep 27, 2017 at 10:48 AM, Sannyasin Brahmanathaswami via
use-livecode  wrote:

> marvelous, very important thread…in mobile, it's all about the touch msg…
>
> yes "all of the above" the enhancement request to allow margins for
> widgets stands as still useful but plays directly into the other scenarios
> described here.  And though separate "desires," they do over lap
>
> e.g. As it is now, the entire rect of an SVG widget is it's hit box.
> Hence the request for margins… which is "it's own solution"
>
> But then, this:
>
> "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."
>
> Having SVG on top of a graphic or vice-versa is, will be, a common use
> case, which is yet another scenario.
>
> you may *not* want the mouse event  to pass through the "transparent"
> area. to objects below, objects below being "eye-candy" (gradient
> backgrounds etc.)
>
> How Mark will provide a solution for "all of the above" will be
> interesting to see.
>
>
> Richard wrote:
>
> And where an SVG widget needs a clickable region larger than its
> bounds,
> the SVG widget would need to be enhanced to provide that.
>
> All of these are practical desires, but each has its own solution.
>
> ___
> 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
___
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

Re: A modest proposal for a new property

[Sannyasin Brahmanathaswami via use-livecode]

marvelous, very important thread…in mobile, it's all about the touch msg…

yes "all of the above" the enhancement request to allow margins for widgets 
stands as still useful but plays directly into the other scenarios described 
here.  And though separate "desires," they do over lap

e.g. As it is now, the entire rect of an SVG widget is it's hit box. 
Hence the request for margins… which is "it's own solution" 

But then, this:

"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."  

Having SVG on top of a graphic or vice-versa is, will be, a common use case, 
which is yet another scenario.

you may *not* want the mouse event  to pass through the "transparent" area. to 
objects below, objects below being "eye-candy" (gradient backgrounds etc.)

How Mark will provide a solution for "all of the above" will be interesting to 
see.


Richard wrote:

And where an SVG widget needs a clickable region larger than its bounds, 
the SVG widget would need to be enhanced to provide that.

All of these are practical desires, but each has its own solution.

___
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

Re: A modest proposal for a new property

[Mark Waddingham via use-livecode]

On 2017-09-27 03:20, Mark Wieder via use-livecode wrote:

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.


Methinks that could be considered a bug :)

The graphic object does do hit-testing based on the content of the 
graphic - but it is not complete/100% accurate for all graphic types.


For opaque rectangles: correct - it checks the point is within the rect.

For non-opaque rectangles: correct - it checks the point is within the 
outline.


For rounded rectangles: incorrect - it uses the same code as rectangle 
(so roundness of corners is not taken into account).


For regular polygons, polygons and curves: correct - it checks if the 
point is within the outline and (if opaque) it checks the point is 
within the polygon.


For lines: correct - it checks whether the point is on the line.

For ovals: incorrect! It checks the point is within the oval defined by 
the rect *but* it does not take into account startangle or angle.


As a pie chart would be a stacked collection of oval graphics with 
different angles/startangles - this is why it doesn't work.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: A modest proposal for a new property

[Richard Gaskin via use-livecode]

hh wrote:

>> Richard Gaskin wrote:
>
>> > Mark Wieder wrote:
>> > 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?
>
> Sadly no. This simply doubles the problem.
> The pie chart was the cause I made the mentioned "pointInShape"-stack.
> There it is done by computing a math relation for the arc, but would
> be easier to see by a points-path, that describeds the outline of the
> pie.

I think it depends on what one wants to do.

For a great many cases your chart widget would be a perfect fit, and I 
appreciate your sharing it.


But in Microsoft Excel, LibreOffice Calc, and others, the various arcs 
that comprise a pie chart are handled as separate vector objects, giving 
us the opportunity to pull one out to draw attention to it, or adjust 
its graphic properties separate from the others.


If the bug Mark Wieder described were addressed, all that plus accurate 
hit testing would be easily accomplished with existing objects.


If one were to replicate that part of LC's graphics-manipulation 
subsystem inside of a widget (allowing the pointer tool to handle 
elements of a pie chart separately, allowing all of the graphics 
properties we have to be applied to specific interior objects, etc.) it 
would seem an ambitious task.


For the most common use cases your widget seems a good option.

For other cases it seems also worth pursuing the hit-testing bug with 
graphics.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: A modest proposal for a new property

[Richard Gaskin via use-livecode]

Exactly.  This discussion has raised so many very different use-cases 
that I don't believe any single solution will satisfy them all.


In those cases where an irregular shape needs to work like a rectangular 
button, it would seem simplest to use a button displaying the image as 
an icon.


Where an image needs to treat clicks in a way that reflect its visual 
outline, the default behavior may already suffice in some cases, and in 
others there may be ways to adjust the alpha threshold for the desired 
effect.


Where Mark Wieder expects arcs to be clickable only within the visible 
shape, I agree and would call that one a bug, so the behavior is made 
consistent with polygons and images.


And where an SVG widget needs a clickable region larger than its bounds, 
the SVG widget would need to be enhanced to provide that.


All of these are practical desires, but each has its own solution.

--
 Richard Gaskin
 Fourth World Systems


J. Landman Gay wrote:

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 | jacque at hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On September 26, 2017 6:56:56 PM Richard Gaskin via use-livecode 
 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
  
  Ambassador at FourthWorld.comhttp://www.FourthWorld.com



___
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

Re: A modest proposal for a new property

[Quentin Long via use-livecode]

sez  hh :
To: use-livecode@lists.runrev.com
> 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)
Given that the engine *already does* have *some* sort of mechanism for 
determining which control gets triggered by a click at an arbitrary location, 
I'm pretty sure that this is a solved problem on some level. As matters stand, 
the clickable region for a control is entirely determined by the engine; my 
proposal makes that clickable region a thing which developers can adjust.

   
"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
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

Re: A modest proposal for a new property

[hh via use-livecode]

> Richard Gaskin wrote:

> > Mark Wieder wrote:
> > 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?

Sadly no. This simply doubles the problem.
The pie chart was the cause I made the mentioned "pointInShape"-stack.
There it is done by computing a math relation for the arc, but would be
easier to see by a points-path, that describeds the outline of the pie.

> Jacqueline LG wrote:
> 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?

[1] Active from widget:
Enlarge the size of the widget by transparent parts to the wanted hitZone
and react on a hitMessage from the widget which sends to its parent, for
example, "clickedInHitzone clickLoc, otherProps".
Here hitZone is a settable polygonial property, given as path or points,
as QL suggested. (For example you could set the hitzone of a svg icon to
the path of a different svg icon, or build it from the points of a LCS
graphic object or any points list).

OR

[2] Passive from widget:
Make in LCS clickable transparent regions, layer them as you want and
identify (possibly disabled) widgets with it. Then send a hitMessage to
these (possibly disabled) objects. And do the hard job of mixing native
and non-native layers by yourself.

*** Currently, in both cases the hitMessage has to be implemented by
the author of the widget, as sender or as receiver. ***

I have it already *partially* done for case [1] with my (shared) widgets
SVG_Text and OrientedText. There you can react or not on a click on
*transparent* parts of the widget. This would be doable with the same
technique for a big class of polygonial regions -- just as Quentin proposed.

Easy future for part [2]: The public handlers of a widget become really
"public" -- I hope someone of the LC-team comes in to at least that point.
Currently they can (easily) be made public only by the author of the widget.

What you can't currently have is something in LCS that can act on widgets
with a method that is not implememented in the widget. That would be doable
but, TMHO, would be against the 'nature' of LCB-widgets. I would immediately
stop making widgets then.

This is my clear opinion, may sound hard:
If someone wants LCB to imitate features of certain (formatting-)languages
like CSS, then he/she should better do that in that (formatting-)language,
it is easy enough. And not try to make LCB slower by requesting to organize
his/her (possibly chaotic) layout.

OR

[3] The simplest way:
Write your own (upgraded) widget. Then you can have your own hitZones,
may even be of size zero or covering the display of all possibly connected
devices. And you can even hide the widget's rectangular "overflow" by using
"clip to  on ".

___
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

Re: A modest proposal for a new property

[J. Landman Gay 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 | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On September 26, 2017 6:56:56 PM Richard Gaskin via use-livecode 
 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
  
  ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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




___
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

Re: A modest proposal for a new property

[Richard Gaskin 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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: A modest proposal for a new property

[Mark Wieder 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
 ahsoftw...@gmail.com

___
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

Re: A modest proposal for a new property

[Richard Gaskin 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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: A modest proposal for a new property

[Mark Wieder 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
 ahsoftw...@gmail.com

___
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

Re: A modest proposal for a new property

[Richard Gaskin 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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: A modest proposal for a new property

[Richard Gaskin 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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: A modest proposal for a new property

[hh 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
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

Re: A modest proposal for a new property

[Sannyasin Brahmanathaswami 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"  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
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

Re: A modest proposal for a new property

[Richard Gaskin 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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

RE: A modest proposal for a new property

[Ralph DiMola 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
rdim...@evergreeninfo.net


-Original Message-
From: use-livecode [mailto:use-livecode-boun...@lists.runrev.com] 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 
> <use-livecode@lists.runrev.com> 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
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


___
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

Re: A modest proposal for a new property

[Colin Holgate 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 
>  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
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

Re: A modest proposal for a new property

[Richard Gaskin 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
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
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

Re: A modest proposal for a new property

[Colin Holgate 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
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

Re: A modest proposal for a new property

[Richard Gaskin 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
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

Re: A modest proposal for a new property

[hh 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
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

Re: A modest proposal for a new property

[Richard Gaskin 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
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

Re: A modest proposal for a new property

[Bob Sneidar 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 
>  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
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

Re: A modest proposal for a new property

[hh 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
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