Mail Archives: geda-user/2016/03/03/06:09:42
| X-Authentication-Warning: | delorie.com: mail set sender to geda-user-bounces using -f
|
| X-Recipient: | geda-user AT delorie DOT com
|
| X-Original-DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed;
|
| d=googlemail.com; s=20120113;
|
| h=mime-version:in-reply-to:references:date:message-id:subject:from:to;
|
| bh=cIVgLQ955JBBqLpqr6K0fqts5RIAocZx584aElAwOX4=;
|
| b=Bq2EiTx9g2h1COxV5xsWUqRSO9D7sd7ADKyj9ZsNqJiEcBNbhvQ+f11dwWeYp4PhUj
|
| GmP22PXKDzUnFMWqteYNykWqWpra19CptXKpJXPPpewydkp/90Y/HCC0xkKpFINBmBSw
|
| u5i48RtCxFhWtJU6zmv6TQnlTiYq4vyget+dIxRx7G3lAw9w99wKKUx3DyGTP54qfDgx
|
| CoMRkI41ROV9YPX2mJN7m73CpFVLTUARTjrCEqG/JRTO+BOD+S328aoEDn4yKVJWFXKK
|
| MPHQq6f5kL7LdWqsMqarz9pgM7eRlw3UcH5HaSFR5y/299fgwJXqnKdvup38ycki7oYy
|
| B8+Q==
|
| X-Google-DKIM-Signature: | v=1; a=rsa-sha256; c=relaxed/relaxed;
|
| d=1e100.net; s=20130820;
|
| h=x-gm-message-state:mime-version:in-reply-to:references:date
|
| :message-id:subject:from:to;
|
| bh=cIVgLQ955JBBqLpqr6K0fqts5RIAocZx584aElAwOX4=;
|
| b=mYyq7u8Lqu9UJLK4lj/HktbYkcJXb14pL6yjmsOoDeYarZgFLCl62mU5GA4jPwta/u
|
| VFymRX2He9TZpIdM/W0ZO3mcSMdF4+6jVWIHbkQ0M7mJfqGgxUdwqQgnQGfHxiqVUuTJ
|
| lYpllZTHnyF/SMFMszLAchhoxAeIm2pWHvgd4RmkT9zElI0/twvnH/4Oepeb8eEQqhix
|
| e3QLevJevHlYlCRs8NJbYVfGDkBfzPEY5STmcWr7VoPbh5m7sIq9qG7sAispS/tG6tsj
|
| SGvRIgQt1Uz05Iu9PxHqS4gd9A7N4FxH66L1Ga+Zv5PWHGVJ5RqdN+rR5XcFm56toYRG
|
| hyJg==
|
| X-Gm-Message-State: | AD7BkJLL0vLoaQ468Zjh1xVSPn+m6XXJtHwXELWNlw1TMQeip7S24LHXkzFudA/hpDesaD+YRQuz/vd7HgMd3g==
|
| MIME-Version: | 1.0
|
| X-Received: | by 10.202.195.209 with SMTP id t200mr1275456oif.26.1457003310483;
|
| Thu, 03 Mar 2016 03:08:30 -0800 (PST)
|
| In-Reply-To: | <CAC4O8c8KAPerjsx-izyb2ow6jmu_nSkPPL5g-CoXGz=QBnWoNw@mail.gmail.com>
|
| References: | <CAC4O8c8Syp2o8AZ45OW+1G=L550v_rXpymxy3gdSa+PXBGGBvw AT mail DOT gmail DOT com>
|
| <nav19e$oks$1 AT ger DOT gmane DOT org>
|
| <CAC4O8c8KAPerjsx-izyb2ow6jmu_nSkPPL5g-CoXGz=QBnWoNw AT mail DOT gmail DOT com>
|
| Date: | Thu, 3 Mar 2016 11:08:30 +0000
|
| Message-ID: | <CAJXU7q-vcJFHPNPskSU4HMt6MLFWWPqiUjBGyeO14fQp==QcQQ@mail.gmail.com>
|
| Subject: | Re: [geda-user] how to fix cut and copy behavior when no selection
|
| From: | "Peter Clifton (petercjclifton AT googlemail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
|
| To: | gEDA User Mailing List <geda-user AT delorie DOT com>
|
| Reply-To: | geda-user AT delorie DOT com
|
| Errors-To: | nobody AT delorie DOT com
|
| X-Mailing-List: | geda-user AT delorie DOT com
|
| X-Unsubscribes-To: | listserv AT delorie DOT com
|
--001a11352994c21279052d2304ae
Content-Type: text/plain; charset=UTF-8
From recollection, the expect-click mode should not prevent GUI updates.
Normal GDK / GTK event processing will be taking place, so drawing updates,
event timers etc.. "should" just work unless we deliberately lock them out.
The main thing to watch out for when nesting GTK main loops like this, is
to avoid the possibility of deep recursion. I think I've seen and fixed
crashes due to this, but don't remember if it was in PCB or gschem.
Peter
On 28 February 2016 at 21:48, Britton Kerin (britton DOT kerin AT gmail DOT com) [via
geda-user AT delorie DOT com] <geda-user AT delorie DOT com> wrote:
> On Sun, Feb 28, 2016 at 5:47 AM, Kai-Martin Knaak <kmk AT familieknaak DOT de>
> wrote:
> > Britton Kerin wrote:
> >
> >> Without a selection:
> >> * hot keys (Ctrl-X Ctrl-V) dump you in paste mode with
> >> nothing to paste and the crosshair locked in a strange
> >> way
> >> * menu items put in expect-click mode, but when they get
> >> a click they don't actually cut or copy anything, but
> >> instead lock the crosshair in a strange way and dump you
> >> in paste mode, only with nothing to paste
> >
> > I agree, this is an issue which irritated about every student I
> > introduced to geda.
> >
> >
> >> Options:
> >>
> >> 1. Require a selection, give an erro pop-up if there isn't one.
> >> * Pros: simplest to implement, minimal surprise, surprise explained
> >> * Cons: requires a selection
> >>
> >> 2. If no selection, overload hovered/clicked point to select
> >> object in addition
> >> to establishing snap point.
> >> * Pros: single-element cut/copy behave as probably expected,
> >> more convenient for experienced users also
> >> * Cons: slightly harder to implement, potentially surprising
> >> behavior
> >>
> >> Opinions or other approaches?
> >
> > I like the second option. It is compatible with the general notion:
> > "use selection if it exists, else use the object under the mouse
> > pointer". IMHO, the ability to act on objects without explicit
> > selection is one of the strengths of the current pcb GUI.
>
> There are a couple things with 2. It makes things work the obvious way
> when
> no selection, but with selection that intuitive behavior is suddenly gone.
> Convenient but surprising. Also, its possible to select things that can't
> be cut/copied independently (element pins/pads). Things like B apparently
> handle this by acting on the containing element but it's again a bit less
> intuitive. It's somewhat disturbing that cut/copy silently ignore portions
> of the selection they can't act on, but there's a good chance experienced
> users habitually take advantage of that behavior.
>
> >
> > There is one item on my wish list, that would make this paradigm much
> > more transparent --> Somehow highlight the object under the mouse so
> > you can see in advance what is going to be affected by an action. The
> > challenge is to find a non-obtrusive way that "works" even in crowded
> > circumstances.
>
> This is on my list too sine Peter Clifton mentioned it as a possibility.
> The uncertainty about what's being selected or acted on is one of the
> big things that make pcb feel rickety for new users and it keeps on being
> somewhat annoying even for quite experienced users. Unfortunately I think
> expect-click mode is going to be a big obstacle to this. It looks like it
> mostly locks up the GUI and runs its own loop. I don't fully understand it
> but I guess updates to the drawing area are not going to happen or need
> wild
> contortions to achieve.
>
> Britton
>
--001a11352994c21279052d2304ae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">From recollection, the expect-click mode should not preven=
t GUI updates. Normal GDK / GTK event processing will be taking place, so d=
rawing updates, event timers etc.. "should" just work unless we d=
eliberately lock them out.<div><br></div><div>The main thing to watch out f=
or when nesting GTK main loops like this, is to avoid the possibility of de=
ep recursion. I think I've seen and fixed crashes due to this, but don&=
#39;t remember if it was in PCB or gschem.</div><div><br>Peter</div></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 28 February 201=
6 at 21:48, Britton Kerin (<a href=3D"mailto:britton DOT kerin AT gmail DOT com">britt=
on DOT kerin AT gmail DOT com</a>) [via <a href=3D"mailto:geda-user AT delorie DOT com">geda-=
user AT delorie DOT com</a>] <span dir=3D"ltr"><<a href=3D"mailto:geda-user AT del=
orie.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;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On S=
un, Feb 28, 2016 at 5:47 AM, Kai-Martin Knaak <<a href=3D"mailto:kmk AT fam=
ilieknaak.de">kmk AT familieknaak DOT de</a>> wrote:<br>
> Britton Kerin wrote:<br>
><br>
>> Without a selection:<br>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* hot keys (Ctrl-X Ctrl-V)=
dump you in paste mode with<br>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nothing to paste an=
d the crosshair locked in a strange<br>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0way<br>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* menu items put in expect=
-click mode, but when they get<br>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0a click they don=
9;t actually cut or copy anything, but<br>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0instead lock the cr=
osshair in a strange way and dump you<br>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0in paste mode, only=
with nothing to paste<br>
><br>
> I agree, this is an issue which irritated about every student I<br>
> introduced to geda.<br>
><br>
><br>
>> Options:<br>
>><br>
>> 1. Require a selection, give an erro pop-up if there isn't one=
.<br>
>> * Pros: simplest to implement, minimal surprise, surprise explaine=
d<br>
>> * Cons: requires a selection<br>
>><br>
>> 2. If no selection, overload hovered/clicked point to select<br>
>> object in addition<br>
>> to establishing snap point.<br>
>> * Pros: single-element cut/copy behave as probably expected,<br>
>> more convenient for experienced users also<br>
>> * Cons: slightly harder to implement, potentially surprising<br>
>> behavior<br>
>><br>
>> Opinions or other approaches?<br>
><br>
> I like the second option. It is compatible with the general notion:<br=
>
> "use selection if it exists, else use the object under the mouse<=
br>
> pointer". IMHO, the ability to act on objects without explicit<br=
>
> selection is one of the strengths of the current pcb GUI.<br>
<br>
</div></div>There are a couple things with 2.=C2=A0 It makes things work th=
e obvious way when<br>
no selection, but with selection that intuitive behavior is suddenly gone.<=
br>
Convenient but surprising.=C2=A0 Also, its possible to select things that c=
an't<br>
be cut/copied independently (element pins/pads).=C2=A0 Things like B appare=
ntly<br>
handle this by acting on the containing element but it's again a bit le=
ss<br>
intuitive.=C2=A0 It's somewhat disturbing that cut/copy silently ignore=
portions<br>
of the selection they can't act on, but there's a good chance exper=
ienced<br>
users habitually take advantage of that behavior.<br>
<span class=3D""><br>
><br>
> There is one item on my wish list, that would make this paradigm much<=
br>
> more transparent --> Somehow highlight the object under the mouse s=
o<br>
> you can see in advance what is going to be affected by an action. The<=
br>
> challenge is to find a non-obtrusive way that "works" even i=
n crowded<br>
> circumstances.<br>
<br>
</span>This is on my list too sine Peter Clifton mentioned it as a possibil=
ity.<br>
The uncertainty about what's being selected or acted on is one of the<b=
r>
big things that make pcb feel rickety for new users and it keeps on being<b=
r>
somewhat annoying even for quite experienced users.=C2=A0 Unfortunately I t=
hink<br>
expect-click mode is going to be a big obstacle to this.=C2=A0 It looks lik=
e it<br>
mostly locks up the GUI and runs its own loop.=C2=A0 I don't fully unde=
rstand it<br>
but I guess updates to the drawing area are not going to happen or need wil=
d<br>
contortions to achieve.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Britton<br>
</font></span></blockquote></div><br></div>
--001a11352994c21279052d2304ae--
- Raw text -