Mail Archives: geda-user/2015/09/16/19:58:11
--f46d0444eba382a128051fe611c8
Content-Type: text/plain; charset=UTF-8
On Wed, Sep 16, 2015 at 12:24 AM, Sabin Iacob (iacobs AT m0n5t3r DOT info) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> On 09/16/2015 10:33 AM, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
> geda-user AT delorie DOT com] wrote:
> >
> > I made a fix to make gtk pan correctly to violation and put crosshair
> > on it.
> >
> > I could add in pointer warping but maybe people dont want it?
> >
> > Now the work flow is:
> >
> > click_on_violation -> point_at_crosshair -> zoom
>
>
> this is much better than the current situation; however, doesn't the
> crosshair follow the mouse? won't attempting to point at the crosshair
> move it?
>
Yep. Funny what you don't notice when testing. So you can potentially get
lost on your way to the main window, with only a little tiny purple part to
show where you want to go. Presumably this is why pointer warping was done
in the first place.
Given this I think warp is the way to go. For gnome it works ok even
without focus-follows-mouse on in the window manager, since scroll events
still go to the hovered window.
mind you, this may not be too big of an issue (you still have the
> supposed violation centered and highlighted)
>
I dunno, it's still weird to have to depend on centering, that takes user
training just like warp or worse because it's more subtle. The warp may
juke you the first few times but has a payout after that.
> >
> > It could be just:
> >
> > click_on_violation -> zoom
>
>
> I'm not sure about others, but I find having the mouse pointer jump to
> arbitrary places ... disconcerting
>
> also, remember that at least Linux window managers are pretty adamant
> about focus stealing prevention[1] , so when you click the violation the
> mouse would jump somewhere, but the DRC window will stay on top, and it
> may cover the place it's trying to point at anyway, so moving the mouse
> is meaningless.
>
Ug you're right. I always put it beside. The main window could perhaps be
reliably raised, but maybe its not worth all this.
--f46d0444eba382a128051fe611c8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Wed, Sep 16, 2015 at 12:24 AM, Sabin Iacob (<a href=3D"mailto:iacobs AT m0n=
5t3r.info">iacobs AT m0n5t3r DOT info</a>) [via <a href=3D"mailto:geda-user AT delori=
e.com">geda-user AT delorie DOT com</a>] <span dir=3D"ltr"><<a href=3D"mailto:g=
eda-user AT delorie DOT com" target=3D"_blank">geda-user AT delorie DOT com</a>></span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">On 09/16/2015 10:33 AM, Britton =
Kerin (<a href=3D"mailto:britton DOT kerin AT gmail DOT com">britton DOT kerin AT gmail DOT com</=
a>) [via<br>
<span class=3D""><a href=3D"mailto:geda-user AT delorie DOT com">geda-user AT delorie=
.com</a>] wrote:<br>
><br>
> I made a fix to make gtk pan correctly to violation and put crosshair<=
br>
> on it.<br>
><br>
> I could add in pointer warping but maybe people dont want it?<br>
><br>
> Now the work flow is:<br>
><br>
>=C2=A0 =C2=A0 click_on_violation -> point_at_crosshair -> zoom<br=
>
<br>
<br>
</span>this is much better than the current situation; however, doesn't=
the<br>
crosshair follow the mouse? won't attempting to point at the crosshair<=
br>
move it?<br></blockquote><div><br></div><div style=3D"">Yep.=C2=A0 Funny wh=
at you don't notice when testing.=C2=A0 So you can potentially get lost=
on your way to the main window, with only a little tiny purple part to sho=
w where you want to go.=C2=A0 Presumably this is why pointer warping was do=
ne in the first place.</div><div style=3D""><br></div><div style=3D"">Given=
this I think warp is the way to go.=C2=A0 For gnome it works ok even witho=
ut focus-follows-mouse on in the window manager, since scroll events still =
go to the hovered window.</div><div><br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
">
mind you, this may not be too big of an issue (you still have the<br>
supposed violation centered and highlighted)<br></blockquote><div><br></div=
><div style=3D"">I dunno, it's still weird to have to depend on centeri=
ng, that takes user training just like warp or worse because it's more =
subtle.=C2=A0 The warp may juke you the first few times but has a payout af=
ter that.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=
=3D"">
><br>
> It could be just:<br>
><br>
>=C2=A0 =C2=A0 click_on_violation -> zoom<br>
<br>
<br>
</span>I'm not sure about others, but I find having the mouse pointer j=
ump to<br>
arbitrary places ... disconcerting<br>
<br>
also, remember that at least Linux window managers are pretty adamant<br>
about focus stealing prevention[1] , so when you click the violation the<br=
>
mouse would jump somewhere, but the DRC window will stay on top, and it<br>
may cover the place it's trying to point at anyway, so moving the mouse=
<br>
is meaningless.<br></blockquote><div><br></div><div style=3D"">Ug you'r=
e right.=C2=A0 I always put it beside.=C2=A0 The main window could perhaps =
be</div><div style=3D"">reliably raised, but maybe its not worth all this.<=
/div><div>=C2=A0</div></div></div></div>
--f46d0444eba382a128051fe611c8--
- Raw text -