kicad-developers team mailing list archive

[Jon Evans <jon@xxxxxxxxxxxxx>]

Hi Clemens, thanks for the suggestions!  I will take some time to think
about them.

Hi Kristoffer, I understand there will be people like you who want the
current system, and I am trying to figure out the best way to propose
something that would be accepted by all.  The current system has some
problems -- both actual bugs like the one I referred to (basically having
the popup menu breaks double-clicking), and also limits the possibility of
implementing certain features.

The core of the issue is how KiCad thinks about selection of objects
compared to most other software that deals with graphical objects that the
user interacts with.

Most applications have the concept of a "selection set" that contains 0 or
more objects.  You can select one or more objects, and then separately from
the action of selecting, you can do things to the objects.  KiCad uses a
more "immediate" concept of selection -- you select an object at the same
time as doing something to it.  For certain use cases, KiCad's style is
actually faster -- fewer user inputs needed to do things.  For other use
cases, KiCad is slower or cannot do things.  For example, because KiCad has
no real concept of a selection set right now (blocks don't really work the
same way, at least the way blocks are implemented now), you can't pick
arbitrary objects and move them together, or align them to each other,
etc.  You can only drag-select to pick a block of all objects inside your
drag rectangle, which often isn't want you want.

I am going to keep working on my proof of concept, and since it will
basically change the selection model of KiCad to be more like other
applications, I will hide this behind a setting in the preferences, so that
people who look at my branch can switch between the old and new behavior
and see which they prefer.

I imagine that if this feature gets accepted into KiCad, it will likely be
a user-selectable option, since it makes big changes to the behavior that
old KiCad users expect.  But, I'm going to advocate for it anyway, because
I think that moving to a user interface that is more similar to most
applications is the right thing to do to increase KiCad user base and
reduce the barrier to people switching from other tools.

Best,
Jon

On Sun, Feb 12, 2017 at 8:13 AM, Kristoffer Ödmark <
kristofferodmark90@xxxxxxxxx> wrote:

> Hmm, I am a fan of the selection menu that pops up actually, I would like
> to keep it.
>
> I think that the list can be used simultaneous with the hotkeys and
> autoselection. Just hide it whenever another action is invoked on the item
> that is curently selected in the list.
>
> - Kristoffer
>
> On 2017-02-12 00:16, Jon Evans wrote:
>
>> I was going to add a context menu entry for "next selection", is that
>> obvious enough to you or do you think there should be extra hints?
>>
>> On Feb 11, 2017 18:14, "Chris Pavlina" <pavlina.chris@xxxxxxxxx
>> <mailto:pavlina.chris@xxxxxxxxx>> wrote:
>>
>>     Very nice. I only think it needs to be a bit more obvious how to do
>> it.
>>
>>     On Sat, Feb 11, 2017 at 05:49:05PM -0500, Jon Evans wrote:
>>     > Proof of concept: https://www.youtube.com/watch?v=JfnXPosOHcY
>>     <https://www.youtube.com/watch?v=JfnXPosOHcY>
>>     > (when you see the selection changing, I'm hitting the new hotkey I
>>     made for
>>     > cycling through items)
>>     >
>>     > On Sat, Feb 11, 2017 at 2:24 PM, Chris Pavlina
>>     <pavlina.chris@xxxxxxxxx <mailto:pavlina.chris@xxxxxxxxx>>
>>
>>     > wrote:
>>     >
>>     > > I wish I had thoughts more verbose than "yes" right now... Yeah,
>>     this is
>>     > > how most tools work, and it's quite intuitive. I would be 100%
>>     in favor
>>     > > of implementing it this way.
>>     > >
>>     > > On Sat, Feb 11, 2017 at 02:21:08PM -0500, Jon Evans wrote:
>>     > > > Hi all,
>>     > > >
>>     > > > I had been thinking about proposing this already as a UX
>>     enhancement, and
>>     > > > then while looking through the starter bugs realized that
>>     lp:1154020 [1]
>>     > > is
>>     > > > actually quite difficult to solve in a nice way due to the
>>     popup menu
>>     > > used
>>     > > > for clarification today, so I decided to send it out now.
>>     > > >
>>     > > > I propose that we change the selection code to "guess" at the
>>     item the
>>     > > user
>>     > > > wanted to select, and let the user cycle through the set of
>>     items that
>>     > > are
>>     > > > near the last point they clicked with a hotkey (and possible a
>>     context
>>     > > menu
>>     > > > option "Next").  This is similar to how the commercial tools
>>     I've used
>>     > > work.
>>     > > >
>>     > > > A few more ideas about this:
>>     > > >
>>     > > > - The currently selected item needs to be indicated somehow.
>>     Currently
>>     > > we
>>     > > > don't highlight all items when selected (for example, fields)
>>     and so
>>     > > either
>>     > > > highlighting which item you are selecting or showing it in the
>>     message
>>     > > > panel would be required for this to be friendly.
>>     > > >
>>     > > > - This would tie in nicely to selection filtering stuff that
>>     other devs
>>     > > are
>>     > > > working on.  Turning on a selection filter mode ("components
>>     only", "text
>>     > > > objects only", etc) would restrict the set of items that can
>>     be picked,
>>     > > and
>>     > > > greatly increase the chance that the right item will be
>>     selected on the
>>     > > > first click.
>>     > > >
>>     > > > - Some commercial tools have "focus" modes, which are kind of
>> like
>>     > > filters,
>>     > > > but they don't restrict what you can select, but rather
>>     influence what
>>     > > will
>>     > > > be selected first.  So if you are in "component focus mode"
>>     and you
>>     > > select
>>     > > > a component with a label on top, the component will always be
>>     selected
>>     > > > first.
>>     > > >
>>     > > > - We could map two hotkeys next to each other (for example ","
>>     and "." on
>>     > > > QWERTY keyboards) and let people step forward and backward
>>     through the
>>     > > > clarification list
>>     > > >
>>     > > > I think this change would make item selection faster, allow
>>     fixing some
>>     > > > long-standing bugs, and work nicely with enhancements to
>> selection
>>     > > > filtering that are coming.  The one downside is that you would
>>     no longer
>>     > > > get a list of all items that are underneath the cursor, but I
>>     can't see
>>     > > the
>>     > > > value in that information.
>>     > > >
>>     > > > Any thoughts on this?
>>     > > >
>>     > > > Best,
>>     > > > Jon
>>     > > >
>>     > > > [1] https://bugs.launchpad.net/kicad/+bug/1154020
>>     <https://bugs.launchpad.net/kicad/+bug/1154020>
>>     > >
>>     > >
>>
>>
>>
>> _______________________________________________
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>