kicad-developers team mailing list archive

[Sergey Borshch <sb-sf@xxxxxxxxxxxxxxxxxxxxx>]

On 03.03.2016 16:26, Wayne Stambaugh wrote:
> On 3/1/2016 8:56 PM, Sergey Borshch wrote:
> > On 01.03.2016 15:23, Wayne Stambaugh wrote:
> > > I was under the impression
> > > that the user was trying to delete a trace and a nearby footprint was
> > > deleted rather than the trace.  That shouldn't happen without a
> > > disambiguation menu.
> > So you'll get annoying menu every time you want to delete wire under
> > footprint in wire placement mode. I propose to add some intelligence:
> > let's current selected tool take precedence in selection. For example,
> > in wire placement mode if user press del key while pointing mouse cursor
> > to the wire under footprint, wire can be deleted without menu. If there
> > is only footprint under cursor - it can be deleted without menu. If
> > there more than one wire or more than one non-wire items (footprints or
> > footprint and drawing line or line and filled zone) under cursor - menu
> > appears. If there is more than one wire and another non-wire item(s)
> > under cursor - menu appears, but only wires shown.
>
> This seems like a plausible solution but it still does not fix the
> posters original issue.  If there is only a single object under the
> cursor then it will be deleted not matter which tool or when no tool is
> selected.
Sounds good, but what about object which is under cursor but have all 
visible parts outside the current visible area (unfilled copper pour or 
just footprint on some zoom levels)? User press Del key, nothing changes 
at the screen and only after some time user suddenly discover that his 
footprint or copper pour lost. That was a real situation which forced me 
to fill bug report #1538805 - *locked* footprints was *silently* deleted 
when all visible parts of it was outside the visible area.

>  I do like the idea of using the currently selected tool as a
> way to resolve some disambiguation situations.  Obviously this wont work
> in every situation but it would be an improvement over the current solution.


--
Regards,
   Sergey A. Borshch            mailto: sb-sf@xxxxxxxxxxxxxxxxxxxxx
     SB ELDI ltd. Riga, Latvia