giseldo/neodataset huggingface dataset:
pan while moving mouse after cancelling selection box (lp:#1776648)

[Original report](https://bugs.launchpad.net/bugs/1776648) created by **eelik (eelik)**
```
1. Check "pan while moving object" in preferences.
2. Start drawing a selection box with left mouse button down.
3. While still drawing (button down), press Esc to cancel.
4. Release the mouse button, move mouse outside the view area.

It pans even though nothing is moved or even selected.

A remedy is to make a new selection box.

Application: kicad
Version: (5.0.0-rc2-129-g72b49accc), release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1
librtmp/2.3
Platform: Windows 7 (build 7601, Service Pack 1), 64-bit edition, 64 bit,
Little endian, wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.54.1
    Compiler: GCC 7.1.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```
Original tags: gal pcbnew

Story points: 18.0
Technical layer draw order on Modern toolset (lp:#1776369)

[Original report](https://bugs.launchpad.net/bugs/1776369) created by **Fabián Inostroza (fabianinostroza)**
```
With the Legacy toolset the technical layers were drawn on top of copper
layers (or some kind of xor), with the modern toolset the order is not well
defined.

As an example, the F.CrtYd layer is drawn over F.Cu only after selecting
the F.CrtYd layer, selecting other layer keeps the F.CrtYd layer on top of
F.Cu.
The B.CrtYd layer is always drawn on top of the B.Cu layer, no need to
select B.CrtYd first.

F.SilkS, B.SilkS, Dwgs.User (used to define specify keepout areas in
footprints) are drawn behind copper layer unless they are selected.

I don't know if it is a good idea to always draw the silkscreen layers on
top of copper layers but I think that the CrtYd and Dwgs.User layers
should, as they help positioning the components on the board and to define
the real keepout areas.

Application: kicad
Version: (5.0.0-rc2-119-g896ad3774), debug build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.60.0 GnuTLS/3.5.18 zlib/1.2.11 libidn2/2.0.4 libpsl/0.20.2
(+libidn2/2.0.4) libssh2/1.8.0 nghttp2/1.32.0 librtmp/2.3
Platform: Linux 4.16.0-2-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.62.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.60.0
    Compiler: GCC 7.3.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=OFF
```
Original tags: pcbnew

Story points: 32.0
Resistor calculator (lp:#1776275)

[Original report](https://bugs.launchpad.net/bugs/1776275) created by **Jakub Kozdon (fldrivers)**
```
Can you add into calculator series and mainly parallel resistors (possibly
capacitor/inductor) calculator/selector like here:
http://www.qsl.net/in3otd/parallr.html

--

Application: kicad
Version: (5.0.0-rc2-dev-603-g5a05135), release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.38.0 OpenSSL/1.0.1t zlib/1.2.8 libidn/1.29 libssh2/1.4.3
librtmp/2.3
Platform: Linux 3.16.0-6-amd64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.55.0
    Curl: 7.38.0
    Compiler: GCC 4.9.2 with C++ ABI 1002

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=OFF
    KICAD_SPICE=ON
```
Original tags: pcb-calculator

Story points: 16.0
Trim trailing zeros in dialogs (lp:#1776083)

[Original report](https://bugs.launchpad.net/bugs/1776083) created by **Nicholas Savenlid (nicholas-z)**
```
can we skip the trailing zeros ?

example 0,300

want to change this value you need to delete all the trailing zeros first
(2 of them)

its this way in all possible menus and situation, and if you work a lot
with the tool it eventually becomes a burden.
```

Story points: 10.0
Move to higher python-wxgtk version (lp:#1776031)

[Original report](https://bugs.launchpad.net/bugs/1776031) created by **Szőgyényi Gábor (szg0000)**
```
"apt-get install python-wxgtk2.8" is not working under Debian untesting.
This package have "oldlibs" property. Can we move to "python-wxgtk3.0" |
"python-wxgtk4.0" ?
```

Story points: 10.0
gerbview lacks grid changing in main menu or toolbar (lp:#1775979)

[Original report](https://bugs.launchpad.net/bugs/1775979) created by **eelik (eelik)**
```
In Gerbview (5.0rc) it's possible to change grid from the context menu, but
not the main menu or the toolbar. Some people, including me, have had
problems finding out that changing grid is possible at all.
```

Story points: 6.0
The QFN footprint wizard generates invalid footprints (lp:#1775961)

[Original report](https://bugs.launchpad.net/bugs/1775961) created by **Rene Poeschl (poeschlr)**
```
The current qfn footprint wizard always centers the pads at the body
dimension. This means that either the heel fillet is way too small or the
toe fillet is way too large.
I would suggest to add at least a parameter to control the pad center
position.
Or upgrade the generator to use ipc calculations.
As an inspiration have a look at the ipc dfn_qfn generator script i created
for generating footprints for the official lib.
https://github.com/pointhi/kicad-footprint-generator/pull/125
```

Story points: 12.0
Pcbnew- cancel Properties dialog, graphic item deselected. (lp:#1775946)

[Original report](https://bugs.launchpad.net/bugs/1775946) created by **ToniGraham (tonigau)**
```
PCBNEW Version: (V5.0.0-rc2-dev-659-g1f5b575ea), winXPP sp3

Graphic item not selected after edit.
I don't think this is really a bug but... ?

When I select a graphic item eg Line, Arc, Text...   & then E to edit (or
double click)
Clicking ok, cancel or <esc> the item is no longer selected.
(The item is visually deselected upon entering edit mode)
Unlike copper items like tracks, vias etc.. which stay selected.

Maybe it is supposed to behave this way but it is in-consistent with copper
layers.


Additional Usage:
If I am operating on zoom of say 5.0 & have thin graphic lines(0.05mm),
selection is with the mouse cursor, not grid snapping cross-hair cursor. As
such multiple clicks are often needed & sometimes double click object is
engaged & edit popup, but exit edit cancels selection.  try again...

cheers
```

Story points: 6.0
WYSIWYG editing for pads (lp:#1775545)

[Original report](https://bugs.launchpad.net/bugs/1775545) created by **eelik (eelik)**
```
I would like to have WYSIWYG size editing for pads, at least for the
footprint editor.

For example, I want to resize a pad so that the right size is more to the
right but left size is kept where it was. Now I have to open the properties
dialog and set both new x-size and new location, either after doing some
calculation or by entering a formula which I have to remember. Even before
that I have to think about the coordinates or size and remember it while I
edit the properties.

On the contrary, zones don't have such properties but are edited with
WYSIWYG principle. With a square zone I can just select the zone, grab the
white ball (resize handle) and drag. Maybe something similar could be done
with pads?

I don't think identical to zones would be the best option. If the resize
handles appear every time a pad is selected it would look messy and would
lead to accidental resizings and difficulties in moving pads (which is
probably more common situation than editing their size). Maybe it would be
better to have a context menu item "Resize" which would select the pad,
show the handles and allow resizing.

The behavior should of course be a bit different from zones - it would
allow dragging only along the axis of the pad (like Control+drag with
zones). Dragging from a corner wouldn't be necessary in my opinion, two
consecutive drags in two directions would do that if needed.

This possibility would make KiCad feature set more consistent with itself:
1. Zones can be edited in this way, pads not, even though pads are also
geometrically polygons.
2. Pads can be moved WYSIWYG, so X/Y coordinates can be edited WYSIWYG but
X/Y size can't.
```
Original tags: pcbnew

Story points: 6.0
New components after reading netlist are seen as two (lp:#1775265)

[Original report](https://bugs.launchpad.net/bugs/1775265) created by **eelik (eelik)**
```
It's quite annoying that after reading a netlist first time in pcbnew the
new components are seen as two, one set in the place where pcbnew
originally puts them and the other when I move the mouse.

Application: kicad
Version: (5.0.0-rc2-66-g0a91f0bc9)--5, release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.55.1 OpenSSL/1.0.2g zlib/1.2.11 libidn2/2.0.2 libpsl/0.18.0
(+libidn2/2.0.2) librtmp/2.3
Platform: Linux 4.13.0-43-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.62.0
    Curl: 7.55.1
    Compiler: GCC 7.2.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=OFF
    KICAD_USE_OCC=OFF
    KICAD_SPICE=OFF
```
Original tags: pcbnew

Story points: 6.0
Add Items listbox to Export to SVG for references, values, worksheet, etc. (lp:#1775206)

[Original report](https://bugs.launchpad.net/bugs/1775206) created by **Piotr Gałka (piotrgalka)**
```
I think Export (SVG and others) should (now they don't - I've checked for
SVG with 2 days old version) use Values & References visibility flags as
there are no such flags in Export dialog box.

I know that "no new functions added now" but as Export uses right panel
colors using these flags (for things which can't be decided in Export
dialog box) seems for me being just the same function and I suppose it
needs hopefully adding only two if() for each of export formats and in
places where probability of makeing this way new bugs is very low.

Why I think it is usefull. I found the only way to get directly form KiCad
2 pictures with black elements on gray copper - one with references and one
with values by designing my footprints with the same picture at F.Silks and
F.CrtYd and Reference at one of them and Value at second. If for Export
(SVG) I could switch on/off Reference/Value I'd need to use only one layer
for it.
```

Story points: 10.0
Symbol reference swap does not change copper zone net (lp:#1774967)

[Original report](https://bugs.launchpad.net/bugs/1774967) created by **Patrik Bachan (xorly)**
```
Hi,
here is simple way to reproduce this bug:
- let's have Schematic with symbols J1 and J2, both already in PCB
- attach copper zone to any pad, eg. Net-(J1-Pad1)
- Swap J1 and J2 references in schematic and update PCB (match by
_timestamp_)

Current behavior:
Copper zone remains attached to Net-(J1-Pad1) and breaks connection from
pad, because pads' net changed from Net-(J1-Pad1) to Net-(J2-Pad1)

Expected behavior:
Copper zone should be attached to Net-(J2-Pad1), because only references
changed, FPs stayed in place. (Same behavior as traces have)


This happens only when you swap references, if you change reference to
something unique, copper zones net is changed and everything is OK.

If you use netlabel to name net you attach copper zone to, there is no
reference in net name and thus everything is OK.


Application: kicad
Version: (5.0.0-rc2-dev-683-gc8f4e1051), release build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.60.0 OpenSSL/1.1.0h zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2
(+libidn2/2.0.4) nghttp2/1.31.1
Platform: Linux 4.16.13-1-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.66.0
    Curl: 7.59.0
    Compiler: GCC 7.3.1 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON
```
Original tags: pcbnew

Story points: 6.0
Thermal relief missing for custom pad shapes (lp:#1774762)

[Original report](https://bugs.launchpad.net/bugs/1774762) created by **Gaurav Juvekar (gauravjuvekar)**
```
Application: kicad
Version: 5.0.0-rc2-unknown-bfa8903~65~ubuntu16.04.1, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-128-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.58.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.47.0
    Compiler: GCC 5.4.0 with C++ ABI 1009

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```

Story points: 8.0
Custom pad shape by merging shapes doesn't respect anchor pad orientation (lp:#1774759)

[Original report](https://bugs.launchpad.net/bugs/1774759) created by **Gaurav Juvekar (gauravjuvekar)**
```
Application: kicad
Version: 5.0.0-rc2-unknown-bfa8903~65~ubuntu16.04.1, release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.47.0 OpenSSL/1.0.2g zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.4.0-128-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.58.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.47.0
    Compiler: GCC 5.4.0 with C++ ABI 1009

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=OFF
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```
Original tags: pcbnew

Story points: 10.0
Dashed lines in Pcbnew (lp:#1774241)

[Original report](https://bugs.launchpad.net/bugs/1774241) created by **Hildo Guillardi Júnior (hildogjr)**
```
In issues #594059 and #1405026 was implemented the dashed line on Eeschema.
I think, this same feature is missing on Pcbnew.
```
Original tags: feature.request

Story points: 18.0
Highlight cross-probe before click-handling (lp:#1774179)

[Original report](https://bugs.launchpad.net/bugs/1774179) created by **Janis Skujenieks (janis-skujenieks)**
```
When I select component in Eeschema it takes a noticeable time before the
according footprint gets selected/highlighted in Pcbnew. It feels about 0.5
seconds or more for me. My PCB is quite simple. I wouldn't report this, but
I remember it previously was practically instant. Previously I was using
8c78bd5fd87e3db84c0ff01291c7b43dc976bb5c commit with some personal changes.

Current version:
Application: kicad
Version: (5.0.0-rc2-35-gda6600525), debug build
Libraries:
    wxWidgets 3.0.4
    libcurl/7.59.0 OpenSSL/1.1.0h zlib/1.2.11 libidn2/2.0.4 libpsl/0.20.1
(+libidn2/2.0.4) nghttp2/1.31.1
Platform: Linux 4.16.2-2-ARCH x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.66.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.59.0
    Compiler: GCC 7.3.1 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```

Story points: 12.0
Component selector search should highlight the best match (lp:#1774110)

[Original report](https://bugs.launchpad.net/bugs/1774110) created by **Oliver (schrodingersgat)**
```
This is a follow on from a bug previously reported at
https://bugs.launchpad.net/kicad/+bug/1738696

The component filtering does not return the "most appropriate" results
based on the search string the user inputs.

Please refer to the attached screen captures.

Refer to the screen-captures here - https://imgur.com/a/JpzbPXI

It seems that the selection algorithm filters the components correctly
(only showing ones which match the string in some way). But the weighting
algorithm which determines the "best" match out of the returned results
does not always work as expected.

Application: kicad
Version: (5.0.0-rc2-dev-789-g6f249e5eb), release build
Libraries:
    wxWidgets 3.0.3
    libcurl/7.54.1 OpenSSL/1.0.2l zlib/1.2.11 libssh2/1.8.0 nghttp2/1.23.1
librtmp/2.3
Platform: Windows 8 (build 9200), 64-bit edition, 64 bit, Little endian,
wxMSW
Build Info:
    wxWidgets: 3.0.3 (wchar_t,wx containers,compatible with 2.8)
    Boost: 1.60.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.54.1
    Compiler: GCC 7.1.0 with C++ ABI 1011

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=ON
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```
Original tags: eeschema windows

Story points: 6.0
Status field in files mixes internal flags and attributes (lp:#1774009)

[Original report](https://bugs.launchpad.net/bugs/1774009) created by **Seth Hillbrand (sethh)**
```
The kicad_plugin outputs a "status" field for each segment and track.  This
is drawn from the STATUS_FLAGS defines (base_struct.h)

This is problematic because the STATUS_FLAGS are used internally to mark
temporary processing states, memory management and drawing states as well
as attributes of the track such as LOCKED and DP_COUPLED.

Only the attributes need to be stored.  Storing the others creates needless
diffs and mixing the states and attributes introduces the opportunity for
bugs.

We should separate flags that need to be stored/retrieved from the
transient flags.
```
Original tags: pcbnew

Story points: 6.0
Net Classes Editor "move up" button (lp:#1773841)

[Original report](https://bugs.launchpad.net/bugs/1773841) created by **Reece Pollack (reece-pollack)**
```
To rearrange the Net Classes table one clicks on a row to select it then
clicks on the "Move Up" button. This moves the selected row up one row, but
the moved row is no longer selected. If the intent is to move a row up
several rows, it is necessary to select it again before clicking "Move Up"
again. Clicking "Move Up" repeatedly without selecting a new row causes the
two rows to repeatedly swap positions. The moved row should still be
selected after it is moved to its new position.

Then, after saving the Net Classes table, reopening the dialog shows the
table sorted in lexicographic order. So what is the point of having a "Move
Up" button?

Built from sources derived from this Git commit:
    2cb65f9 Make the Simulator error strings translatable

Application: kicad
Version: (5.0.0-rc2-39-g4cac861), debug build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.11 libidn/1.32 librtmp/2.3
Platform: Linux 4.13.0-41-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.58.0
    OpenCASCADE Community Edition: 6.8.0
    Curl: 7.47.0
    Compiler: GCC 5.4.0 with C++ ABI 1009

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_USE_OCC=OFF
    KICAD_SPICE=ON
```

Story points: 6.0
The origins of 6.0 (pun intended) (lp:#1773638)

[Original report](https://bugs.launchpad.net/bugs/1773638) created by **Jeff Young (jeyjey)**
```
There have been some discussions in bug reports and on forums regarding the
various origins.

We currently have a file origin, which is fixed.  It's absolute value is
somewhat immaterial as most board houses will use the edge cuts to position
the footprints.  Essentially all it does is tell us where to draw the page
boundaries and page frame.

We also have a drill origin, which is user settable.  I suspect this is
mostly legacy, as most manufacturers are happy enough without one.  But
conceptually one could make an argument that it should set the origin for
/all/ file values, not just drill file values.  This is probably a low
value change.

We also have a grid origin, which is user settable.  Conceptually we think
of this as just a grid origin, but many of our users think of it as the
editing/display origin (which, to be honest, makes more sense).

When locations are edited through the UI, they are presented relative to
file origin.  There's no particular value in this, while there would be
/considerable/ value in presenting them relative to the grid origin.

One bug report suggests adding textboxes for grid-relative positions to the
existing textboxes for file-relative positions.  I believe this would be a
mistake as it just complicates the UI and the file-relative positions have
little value to the user.

For 6.0, I would recommend we change the GUI positions to grid-origin-
relative.

I can also see an argument for changing the file positions to drill-origin-
relative, but I'm ambivalent about that.
```

Story points: 70.0
touchpad panning schematics extremely slow on macOS (lp:#1773562)

[Original report](https://bugs.launchpad.net/bugs/1773562) created by **CeDeROM (cederom)**
```
Hey there, working on macOS with no 3button mouse requires Touchpad Panning
to be mandatory..
Panning the PCB editor works fine and smoothly just as the zooming.
Panning the SCH editor is terrybly slow and reminds playing Doom on my
Atari..
How can I fix/improve performance of SCH display?
```

Story points: 6.0
open footprint from library with list and preview like in symbol editor (lp:#1773558)

[Original report](https://bugs.launchpad.net/bugs/1773558) created by **CeDeROM (cederom)**
```
Hello, it would be nice to have a nice list of components with a preview
from an active library being edited in PCB footprint editor, just like it
is done in schematic symbol editor - you can see a list of components with
preview, not only a small wintow that forces you to search components by
hand..
```

Story points: 6.0