Why thread limitations on mouse reads?

[Charles Goodwin]

If I have a thread that passes a value to a property who in turn makes
use of a call to box.mouseinside, box.mouse.x, or box.mouse.y, the
follwing error is given:

Scheduler: a JavaScript thread spawned with ibex.thread()
threw an exception:
at
file:src/org/ibex/theme/win2k/scrollbar.t:36
at trap on property "action"
at file:src/ibex/lib/repeatable.t:30
JSExn: you cannot read from the box.mouse property
in background thread context
at org.ibex.Box.get(Box.java:523)
at
org.ibex.js.Interpreter.run(Interpreter.java:313)
at
org.ibex.js.Interpreter.resume(Interpreter.java:39)
at org.ibex.js.JSFunction.perform(JSFunction.java:31)
at
org.ibex.Scheduler.defaultRun(Scheduler.java:77)
at org.ibex.Scheduler.run(Scheduler.java:54)
at org.ibex.Scheduler.init(Scheduler.java:17)
at org.ibex.Main.main(Main.java:101)

This seems like a very unecessary limitation and rules about basically
any time-based interaction with the mouse.

[Charles Goodwin]

*bump* as this is an important issue. You're cutting out a lot of
opportunity with this unecessary restriction.

Also, what about trap restrictions that were going to go such as on
width/height/shrink/hshrink/vshrink?

Post by Charles Goodwin
If I have a thread that passes a value to a property who in turn makes
use of a call to box.mouseinside, box.mouse.x, or box.mouse.y, the
Scheduler: a JavaScript thread spawned with ibex.thread()
at
file:src/org/ibex/theme/win2k/scrollbar.t:36
at trap on property "action"
at file:src/ibex/lib/repeatable.t:30
JSExn: you cannot read from the box.mouse property
in background thread context
at org.ibex.Box.get(Box.java:523)
at
org.ibex.js.Interpreter.run(Interpreter.java:313)
at
org.ibex.js.Interpreter.resume(Interpreter.java:39)
at org.ibex.js.JSFunction.perform(JSFunction.java:31)
at
org.ibex.Scheduler.defaultRun(Scheduler.java:77)
at org.ibex.Scheduler.run(Scheduler.java:54)
at org.ibex.Scheduler.init(Scheduler.java:17)
at org.ibex.Main.main(Main.java:101)
This seems like a very unecessary limitation and rules about basically
any time-based interaction with the mouse.
--
- Charlie
_______________________________________________
core mailing list
http://lists.xwt.org/listinfo/core

[Charles Goodwin]

Post by Charles Goodwin
*bump* as this is an important issue. You're cutting out a lot of
opportunity with this unecessary restriction.

Thanks to David for higlhighting ways of getting around this with
perceptive use of Move/Enter/Leave.

Post by Charles Goodwin
Also, what about trap restrictions that were going to go such as on
width/height/shrink/hshrink/vshrink?

Any news on this?

[Adam Megacz]

Post by Charles Goodwin

Post by Charles Goodwin
*bump* as this is an important issue. You're cutting out a lot of
opportunity with this unecessary restriction.

Thanks to David for higlhighting ways of getting around this with
perceptive use of Move/Enter/Leave.

This is the long term solution. In general you shouldn't usually need
to know the position of the mouse except when it's being clicked or
moved over your (box's) surface.

- a

[Adam Megacz]

The limitations are there so that some boxes can fake mouse actions
from the perspective of other boxes. If a box can look at the mouse
at any random time, it's going to be really hard to fake it.

The real solution (which I haven't gotten around to implementing yet)
is to have Press1, Release1, Move, etc put an (x,y) mouse position
instead of 'true'.

- a

Post by Charles Goodwin
If I have a thread that passes a value to a property who in turn makes
use of a call to box.mouseinside, box.mouse.x, or box.mouse.y, the
Scheduler: a JavaScript thread spawned with ibex.thread()
at
file:src/org/ibex/theme/win2k/scrollbar.t:36
at trap on property "action"
at file:src/ibex/lib/repeatable.t:30
JSExn: you cannot read from the box.mouse property
in background thread context
at org.ibex.Box.get(Box.java:523)
at
org.ibex.js.Interpreter.run(Interpreter.java:313)
at
org.ibex.js.Interpreter.resume(Interpreter.java:39)
at org.ibex.js.JSFunction.perform(JSFunction.java:31)
at
org.ibex.Scheduler.defaultRun(Scheduler.java:77)
at org.ibex.Scheduler.run(Scheduler.java:54)
at org.ibex.Scheduler.init(Scheduler.java:17)
at org.ibex.Main.main(Main.java:101)
This seems like a very unecessary limitation and rules about basically
any time-based interaction with the mouse.
--
- Charlie
_______________________________________________
core mailing list
http://lists.xwt.org/listinfo/core

[Brian Alliet]

Post by Adam Megacz
The real solution (which I haven't gotten around to implementing yet)
is to have Press1, Release1, Move, etc put an (x,y) mouse position
instead of 'true'.

If we do that we can also avoid constantly flooding the queue with
mousemove events. We could only have the platform class send mousemove
events when a Move trap is set somewhere on the surface.

-Brian

[Adam Megacz]

Very good call.

- a

Post by Brian Alliet

Post by Adam Megacz
The real solution (which I haven't gotten around to implementing yet)
is to have Press1, Release1, Move, etc put an (x,y) mouse position
instead of 'true'.

If we do that we can also avoid constantly flooding the queue with
mousemove events. We could only have the platform class send mousemove
events when a Move trap is set somewhere on the surface.
-Brian
_______________________________________________
core mailing list
http://lists.xwt.org/listinfo/core