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=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type;
	bh=EN/EFDgHuP/2+ZifWwYMZYx16dVAmtlFOZN+xugg3B8=;
	b=m09tyqcGvas/WAmc1a/3l36TyE/n+t6EVAbdqTdMcjQHMnBxUdEHgx/5gzAZresp8W
	ZQ8Gva/T5mzwttvYC59gcWxkCSC8DTPqaBbJkBjaGIbu5lyBaDSfds7jMs+TKSIRmmPY
	mCfE5PCaIQPsVyJGMJUKAYTI3/UDNgPcFDQDTs2N/2E7VqqpGyY4n8vmVPAKKYvys7OD
	2b7UJRQtpE7Irx0HPgQAQ77NBkuNYzUL/lkZbNGkYZV0Q7BnVABJCP8VuSBDaXV1SLJX
	19AN1WRmsnKkbct3mEZyNOlI2n1cJlkMKnl0lu+kebHNs68SYbK39KRTkmO6LTWAjsvA
	uadw==
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:content-type;
	bh=EN/EFDgHuP/2+ZifWwYMZYx16dVAmtlFOZN+xugg3B8=;
	b=VbJwqkvc0/JH1F6OOqAZCRwBDAnOLdbbdGmMhE4iFtE9tlVuiAy0QkLdiVncT6YRaF
	we7XTD/tYLR19xcJ7Hl2Nutrbjgzexwj7eLvI5s79U0jKUCJ6Xfv84EGc37JoXhR96/p
	n+QfwXqpB+IH4bXWim4HvEw+cgRKOSMqbdmJZHoiAkz5A4q5DlOqPOL72Jyz+0jFhQ/A
	+p/zD65cryrH7aST3uEGkxKeCa+UQTD4X+nBsNP8a/i0WCdWaUCv8jPCd8QHTroDJBs0
	BJAQhtjnYjXYJO59mpJfSdThQd+9oPTlJZ7xSrKRAmgpTKn3S5TzhQF314NupMRZYfoz
	xNlA==
X-Gm-Message-State:	AG10YOS2C5ljf3llGwotXpOTkXVdva7biokrpx/FeD76OVK7HThcxk60FZ0Z2sewwRnJh79fyVD53RJAesHqbw==
MIME-Version:	1.0
X-Received:	by 10.194.115.196 with SMTP id jq4mr8533287wjb.101.1456430406032;
	Thu, 25 Feb 2016 12:00:06 -0800 (PST)
In-Reply-To:	<CAC4O8c_VGVSJ293PtQOj-YNan0TYnYadJHAQ8iAXN8ccg4pK9A@mail.gmail.com>
References:	<CAC4O8c_VGVSJ293PtQOj-YNan0TYnYadJHAQ8iAXN8ccg4pK9A AT mail DOT gmail DOT com>
Date:	Thu, 25 Feb 2016 11:00:05 -0900
Message-ID:	<CAC4O8c-RZ13jYXTiAaLskpXKqppqt_Hsst6Ms5DQcOA_xFMzpQ@mail.gmail.com>
Subject:	[geda-user] Re: exactly how is moving between sides/layers supposed to work, and
	more generally...
From:	"Britton Kerin (britton DOT kerin AT gmail DOT com) [via geda-user AT delorie DOT com]" <geda-user AT delorie DOT com>
To:	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

On Wed, Feb 24, 2016 at 6:10 PM, Britton Kerin <britton DOT kerin AT gmail DOT com> wrote:
> I've always just muddled through on the basic knowledge that:
>
>   Select->Move selected elements to other side, followed by a click
>        would put parts on other side
>
> and
>
>   Select->Move selected to current layer
>        would move already selected traces to the current layer
>
> In going through documenting everything I found the more useful B hotkey which
> sends the hovered element straight through the board without requiring a
> pre-select or additional click.
>
> These are all useful operations but the interface is painfully inconsistent
> about them:
>
> 1. Select->Move selected elements to other side (Shift-B)
>        Can handle sets of selected elements, but requires them to first be
>        selected and then the selection clicked after the menu item is activated
>        to send them to the other side.  The hotkey sends selected items to the
>        other side immediately, but doesn't do anything if nothing is selected.
>        Alternately, iff nothing is selected before the menu item is activated,
>        a single subsequently clicked element is sent to the other side
>
> 2. Select->Move selected to current layer (Shift-M)
>        Ignores elements (its name should change to reflect this).  When either
>        the menu item or the hot key is activated, the selected
>        lines/arcs/polys/maybe_other_things are moved to the current layer.
>        If nothing is selected nothing is done.

Reconsidering this in light of Stephan's explanation of the general hotkey
pattern, it seems that most of the inconsistency is between 1. and 2. above.  I
like the 2 behavior better.  The extra click following menu item activation
could be removed for 1. (it doesn't have any meaning if anything is selected,
and is much less useful than the B behavior if things aren't) and we would
have consistent behavior.  Both 1 and 2 could get a pop-up warning if nothing
selected.  The only people who would experience a discontinuity are ones who
are doing it the awful way I've done it for years using the 1. menu item
without a selection, and you'd be doing them a favor disrupting that habit for
them.

There are some related issues around cut and copy.  These are fundamental
operations and even more worth fixing.  Right now so far as I can tell:

     Without a selection:

           * hot keys (Ctrl-X Ctrl-V) do nothing
           * 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

     With a selection both menu and hotkey behavior are slightly weird (spooky
     action at a distance on the selection rather than the clicked or hovered
     point) but highly useful since they let you position the grab point.

Options:

     Require a selection, give a pop-up if there isn't one.  A selection is
     currently required anyway for decent behavior so far as I can tell.

     Slightly more complicatedly could do as I propose originally for these and
     cut/copy clicked (menu item) or hovered (hotkey) element if no selection.
     I believe there is no other existing hotkey system involving these.  It's
     what naieve users are going to expect.  It would be convenient.  The big
     down side is you get really weirdly inconsistent (but useful ) behavior
     depending on whether there is a selection or not.

Britton

- Raw text -