Mouse Interaction behaviour

[Renaud AUBIN]

Hello,

I'm currently trying to figure out where and how a target is
identified with respect to mouse events.
The main issue is that the current interaction model (from w3c
recommandations) is not really adapted to our needs.

The big picture: we have 2D P&ID diagrams with a lot of pipes to
interact with. This kind of diagram is very useful to prepare
operations on real process with a good functionnal view of what we are
going to do... but that's only true at a certain zoom level! As a
consequence, we need to be able to interact (focusIn, focusOut, click)
with polylines of limited stroke width at a "global" zoom level.
Actually, we can interact with a pipe's polyline only when the mouse
pointer is *exactly* over the polyline. Now, our users' need drive us
to the point that we really need to modify this behaviour. So we need
to modify batik to provide magnetism-like interaction or a targetable
polyline with a (maybe) configurable distance (i.e. we don't need to
be over the line but at a configurable distance in screen space for
example with zoom-dependant thresholds).

Any suggestions on where to begin to save us some time ?

Best regards,

Renaud

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@...
For additional commands, e-mail: batik-dev-help@...

[jonathan wood-3]

Hi Renaud,

  This is a shot in the dark based on you description.

The basic problem I distilled:  You need fuzzy control over mouse selection..

I've solved this in the past by obtaining the selection or current point x,y (using a glasspane etc) and then checking your configurable fuzzy bounds by creating a rect centered on the point and use getIntersectionList or getEnclosureList to determine what is within rect/2 distance of the cursor.

Hope this helps...good luck!

On Fri, Nov 6, 2009 at 3:01 PM, Renaud AUBIN <renaud.aubin@...> wrote:

Hello,

I'm currently trying to figure out where and how a target is
identified with respect to mouse events.
The main issue is that the current interaction model (from w3c
recommandations) is not really adapted to our needs.

The big picture: we have 2D P&ID diagrams with a lot of pipes to
interact with. This kind of diagram is very useful to prepare
operations on real process with a good functionnal view of what we are
going to do... but that's only true at a certain zoom level! As a
consequence, we need to be able to interact (focusIn, focusOut, click)
with polylines of limited stroke width at a "global" zoom level.
Actually, we can interact with a pipe's polyline only when the mouse
pointer is *exactly* over the polyline. Now, our users' need drive us
to the point that we really need to modify this behaviour. So we need
to modify batik to provide magnetism-like interaction or a targetable
polyline with a (maybe) configurable distance (i.e. we don't need to
be over the line but at a configurable distance in screen space for
example with zoom-dependant thresholds).

Any suggestions on where to begin to save us some time ?

Best regards,

Renaud

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@...
For additional commands, e-mail: batik-dev-help@...

[Renaud AUBIN]

Hi,

Thank you Jonathan.
Is there a way to do that at a lower level to optimize the processing?
If not, any clues about where the geometrical processing is really
done are welcomed!

Renaud

2009/11/6 jonathan wood <jonathanshawwood@...>:

>
> Hi Renaud,
>
>   This is a shot in the dark based on you description.
>
> The basic problem I distilled:  You need fuzzy control over mouse
> selection..
>
> I've solved this in the past by obtaining the selection or current point x,y
> (using a glasspane etc) and then checking your configurable fuzzy bounds by
> creating a rect centered on the point and use getIntersectionList or
> getEnclosureList to determine what is within rect/2 distance of the cursor.
>
> Hope this helps...good luck!
>
> On Fri, Nov 6, 2009 at 3:01 PM, Renaud AUBIN <renaud.aubin@...> wrote:
>>
>> Hello,
>>
>> I'm currently trying to figure out where and how a target is
>> identified with respect to mouse events.
>> The main issue is that the current interaction model (from w3c
>> recommandations) is not really adapted to our needs.
>>
>> The big picture: we have 2D P&ID diagrams with a lot of pipes to
>> interact with. This kind of diagram is very useful to prepare
>> operations on real process with a good functionnal view of what we are
>> going to do... but that's only true at a certain zoom level! As a
>> consequence, we need to be able to interact (focusIn, focusOut, click)
>> with polylines of limited stroke width at a "global" zoom level.
>> Actually, we can interact with a pipe's polyline only when the mouse
>> pointer is *exactly* over the polyline. Now, our users' need drive us
>> to the point that we really need to modify this behaviour. So we need
>> to modify batik to provide magnetism-like interaction or a targetable
>> polyline with a (maybe) configurable distance (i.e. we don't need to
>> be over the line but at a configurable distance in screen space for
>> example with zoom-dependant thresholds).
>>
>> Any suggestions on where to begin to save us some time ?
>>
>> Best regards,
>>
>> Renaud
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-dev-unsubscribe@...
>> For additional commands, e-mail: batik-dev-help@...
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@...
For additional commands, e-mail: batik-dev-help@...

[Helder Magalhães]

Hi Renaud,


> Is there a way to do that at a lower level to optimize the processing?

Probably: you may try implementing the concept at the GVT [1] (lower
level), but it may become challenging. ;-)


Good luck,
 Helder


[1] http://xmlgraphics.apache.org/batik/using/architecture.html

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@...
For additional commands, e-mail: batik-dev-help@...

[thomas.deweese]

Hi Renaud,

   BTW this discussion should really take place on batik-users since it doesn't involve
development of Batik.

Renaud AUBIN <renaud.aubin@...> wrote on 11/19/2009 02:58:28 PM:

> Is there a way to do that at a lower level to optimize the processing?

    Feel free to inspect the code that currently does the intersection
testing at:
        batik.bridge.SVGSVGElementBridge

    I don't think you will find significant optimizations in that
code.

> If not, any clues about where the geometrical processing is really
> done are welcomed!

    What you might consider doing (at the cost of memory) would be
to 'duplicate' your lines with a wider stroke (probably using a 'use'
element).  You can make the duplicate invisible (fill="none" stroke="none")
but still sensitive to mouse events (pointer-events="all").


> 2009/11/6 jonathan wood <jonathanshawwood@...>:
> >
> > Hi Renaud,
> >
> >   This is a shot in the dark based on you description.
> >
> > The basic problem I distilled:  You need fuzzy control over mouse
> > selection..
> >
> > I've solved this in the past by obtaining the selection or currentpoint x,y
> > (using a glasspane etc) and then checking your configurable fuzzy bounds by
> > creating a rect centered on the point and use getIntersectionList or
> > getEnclosureList to determine what is within rect/2 distance of the cursor.
> >
> > Hope this helps...good luck!
> >
> > On Fri, Nov 6, 2009 at 3:01 PM, Renaud AUBIN <renaud.aubin@...> wrote:
> >>
> >> Hello,
> >>
> >> I'm currently trying to figure out where and how a target is
> >> identified with respect to mouse events.
> >> The main issue is that the current interaction model (from w3c
> >> recommandations) is not really adapted to our needs.
> >>
> >> The big picture: we have 2D P&ID diagrams with a lot of pipes to
> >> interact with. This kind of diagram is very useful to prepare
> >> operations on real process with a good functionnal view of what we are
> >> going to do... but that's only true at a certain zoom level! As a
> >> consequence, we need to be able to interact (focusIn, focusOut, click)
> >> with polylines of limited stroke width at a "global" zoom level.
> >> Actually, we can interact with a pipe's polyline only when the mouse
> >> pointer is *exactly* over the polyline. Now, our users' need drive us
> >> to the point that we really need to modify this behaviour. So we need
> >> to modify batik to provide magnetism-like interaction or a targetable
> >> polyline with a (maybe) configurable distance (i.e. we don't need to
> >> be over the line but at a configurable distance in screen space for
> >> example with zoom-dependant thresholds).
> >>
> >> Any suggestions on where to begin to save us some time ?
> >>
> >> Best regards,
> >>
> >> Renaud
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: batik-dev-unsubscribe@...
> >> For additional commands, e-mail: batik-dev-help@...
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@...
> For additional commands, e-mail: batik-dev-help@...
>

[Renaud AUBIN]

Hi Thomas,

I have in fact submitted this topic on the dev side because I don't
want to 'duplicate' my primitives but hack batik internals to fit my
needs.
It's not really related to batik-dev since what I would get is out of
specs wrt to W3C SVG recom, but it's no more or less related to
batik-user…

Renaud

2009/11/20  <thomas.deweese@...>:

> Hi Renaud,
>
>    BTW this discussion should really take place on batik-users since it
> doesn't involve
> development of Batik.
>
> Renaud AUBIN <renaud.aubin@...> wrote on 11/19/2009 02:58:28 PM:
>
>> Is there a way to do that at a lower level to optimize the processing?
>
>     Feel free to inspect the code that currently does the intersection
> testing at:
>         batik.bridge.SVGSVGElementBridge
>
>     I don't think you will find significant optimizations in that
> code.
>
>> If not, any clues about where the geometrical processing is really
>> done are welcomed!
>
>     What you might consider doing (at the cost of memory) would be
> to 'duplicate' your lines with a wider stroke (probably using a 'use'
> element).  You can make the duplicate invisible (fill="none" stroke="none")
> but still sensitive to mouse events (pointer-events="all").
>
>
>> 2009/11/6 jonathan wood <jonathanshawwood@...>:
>> >
>> > Hi Renaud,
>> >
>> >   This is a shot in the dark based on you description.
>> >
>> > The basic problem I distilled:  You need fuzzy control over mouse
>> > selection..
>> >
>> > I've solved this in the past by obtaining the selection or currentpoint
>> > x,y
>> > (using a glasspane etc) and then checking your configurable fuzzy bounds
>> > by
>> > creating a rect centered on the point and use getIntersectionList or
>> > getEnclosureList to determine what is within rect/2 distance of the
>> > cursor.
>> >
>> > Hope this helps...good luck!
>> >
>> > On Fri, Nov 6, 2009 at 3:01 PM, Renaud AUBIN <renaud.aubin@...>
>> > wrote:
>> >>
>> >> Hello,
>> >>
>> >> I'm currently trying to figure out where and how a target is
>> >> identified with respect to mouse events.
>> >> The main issue is that the current interaction model (from w3c
>> >> recommandations) is not really adapted to our needs.
>> >>
>> >> The big picture: we have 2D P&ID diagrams with a lot of pipes to
>> >> interact with. This kind of diagram is very useful to prepare
>> >> operations on real process with a good functionnal view of what we are
>> >> going to do... but that's only true at a certain zoom level! As a
>> >> consequence, we need to be able to interact (focusIn, focusOut, click)
>> >> with polylines of limited stroke width at a "global" zoom level.
>> >> Actually, we can interact with a pipe's polyline only when the mouse
>> >> pointer is *exactly* over the polyline. Now, our users' need drive us
>> >> to the point that we really need to modify this behaviour. So we need
>> >> to modify batik to provide magnetism-like interaction or a targetable
>> >> polyline with a (maybe) configurable distance (i.e. we don't need to
>> >> be over the line but at a configurable distance in screen space for
>> >> example with zoom-dependant thresholds).
>> >>
>> >> Any suggestions on where to begin to save us some time ?
>> >>
>> >> Best regards,
>> >>
>> >> Renaud
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: batik-dev-unsubscribe@...
>> >> For additional commands, e-mail: batik-dev-help@...
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-dev-unsubscribe@...
>> For additional commands, e-mail: batik-dev-help@...
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@...
For additional commands, e-mail: batik-dev-help@...

[Renaud AUBIN]

>     Feel free to inspect the code that currently does the intersection
> testing at:
>         batik.bridge.SVGSVGElementBridge
>
>     I don't think you will find significant optimizations in that
> code.

Ok, at first sight, SVGSVGElement and/or gvt modifications should do well…
Mea culpa, I don't mean to do optimizations in a strict geometrical or
batikish POV but rather as our end users' POV.

>     What you might consider doing (at the cost of memory) would be
> to 'duplicate' your lines with a wider stroke (probably using a 'use'
> element).  You can make the duplicate invisible (fill="none" stroke="none")
> but still sensitive to mouse events (pointer-events="all").

We have CAD Schemas and for some of them we have quite a lot of
primitives. We have thought about that already some times ago but it
seems to us that the performance and the memory usage will really
suffer.

Renaud

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@...
For additional commands, e-mail: batik-dev-help@...

[Renaud AUBIN]

I have finally a beginning of response. Since I would modify the
interactivity mostly with polylines, I have made some preliminary
tests using differents implementations of
gvt/StrokeShapePainter.getPaintedArea (I instantiate a new BasicStroke
on which I can hack ad return just in palce of the original) with a
pointer-event equals to stroke.

Renaud

2009/11/20  <thomas.deweese@...>:

> Hi Renaud,
>
>    BTW this discussion should really take place on batik-users since it
> doesn't involve
> development of Batik.
>
> Renaud AUBIN <renaud.aubin@...> wrote on 11/19/2009 02:58:28 PM:
>
>> Is there a way to do that at a lower level to optimize the processing?
>
>     Feel free to inspect the code that currently does the intersection
> testing at:
>         batik.bridge.SVGSVGElementBridge
>
>     I don't think you will find significant optimizations in that
> code.
>
>> If not, any clues about where the geometrical processing is really
>> done are welcomed!
>
>     What you might consider doing (at the cost of memory) would be
> to 'duplicate' your lines with a wider stroke (probably using a 'use'
> element).  You can make the duplicate invisible (fill="none" stroke="none")
> but still sensitive to mouse events (pointer-events="all").
>
>
>> 2009/11/6 jonathan wood <jonathanshawwood@...>:
>> >
>> > Hi Renaud,
>> >
>> >   This is a shot in the dark based on you description.
>> >
>> > The basic problem I distilled:  You need fuzzy control over mouse
>> > selection..
>> >
>> > I've solved this in the past by obtaining the selection or currentpoint
>> > x,y
>> > (using a glasspane etc) and then checking your configurable fuzzy bounds
>> > by
>> > creating a rect centered on the point and use getIntersectionList or
>> > getEnclosureList to determine what is within rect/2 distance of the
>> > cursor.
>> >
>> > Hope this helps...good luck!
>> >
>> > On Fri, Nov 6, 2009 at 3:01 PM, Renaud AUBIN <renaud.aubin@...>
>> > wrote:
>> >>
>> >> Hello,
>> >>
>> >> I'm currently trying to figure out where and how a target is
>> >> identified with respect to mouse events.
>> >> The main issue is that the current interaction model (from w3c
>> >> recommandations) is not really adapted to our needs.
>> >>
>> >> The big picture: we have 2D P&ID diagrams with a lot of pipes to
>> >> interact with. This kind of diagram is very useful to prepare
>> >> operations on real process with a good functionnal view of what we are
>> >> going to do... but that's only true at a certain zoom level! As a
>> >> consequence, we need to be able to interact (focusIn, focusOut, click)
>> >> with polylines of limited stroke width at a "global" zoom level.
>> >> Actually, we can interact with a pipe's polyline only when the mouse
>> >> pointer is *exactly* over the polyline. Now, our users' need drive us
>> >> to the point that we really need to modify this behaviour. So we need
>> >> to modify batik to provide magnetism-like interaction or a targetable
>> >> polyline with a (maybe) configurable distance (i.e. we don't need to
>> >> be over the line but at a configurable distance in screen space for
>> >> example with zoom-dependant thresholds).
>> >>
>> >> Any suggestions on where to begin to save us some time ?
>> >>
>> >> Best regards,
>> >>
>> >> Renaud
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: batik-dev-unsubscribe@...
>> >> For additional commands, e-mail: batik-dev-help@...
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: batik-dev-unsubscribe@...
>> For additional commands, e-mail: batik-dev-help@...
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@...
For additional commands, e-mail: batik-dev-help@...