Mail Archives: geda-user/2016/07/31/11:10:50
On Sun, 5 Jun 2016, Kai-Martin Knaak wrote:
> M. J. Everitt wrote:
>
>> What I mean by the 'working area' is the canvas area described in
>> PCB as the "Board size" in the preferences, not by any outline
>> drawn on the screen.
>
> We are using "working area" in the exact same sense. I fail to see the
> reasons why there is a distinction between the "working area" and the
> vast rest of the technically available coordinate space. Why is it
> necessary to prevent the user from accessing objects outside the
> working area?
So I took a closer look in the code. Figured how exactly this happens, and
unfortunately it's not as easy to fix or even work it around as it seemed.
(Boring details at the bottom.)
It seems alternativs are staying with the current behaviour or going with
your idea about (at least optionally) not limiting the working area.
I am wondering... How does "not limiting" differ from setting the board
size to real huge? What I can think of, so far:
- mathematically it's like we can use only 1/4 of the plane because
bumping into the limit that no coordinate shall be negative with the
current code; in user experience this means a hardwired limit by two
edges. This might be solved by just starting drawing in the middle, but
this leads to....
- large coordinates, which may make the save files less human-readable,
potentially harder to script-process in some cases, and maybe less
VCS-friendly too, in some cases
- zooming to extent; the current code zooms to page extents; if we say
page is "inifinite" new code is needed that zooms to the bounding box of
union of all objects (not a big deal, tho)
- exporters? I am not sure about this one, but some exporters use board
extents (probably wouldn't be hard to replace that with the above bounding
box code)
Regards,
Igor2
P.S. Fine print about the problem: there's a bounding box of where
crosshair can go while dragging something. It's calculated in the moment
the user starts to drag. It'd be easy to fix it for arc so arc can be
moved beyond the edge by 1/4 or 1/2 of the page. What is hard is that the
very same code should work for buffers. Imagine there's a large arc and a
small line or via in the corner of the arc; if you select and move them
together, the big arc buys some extra margin, which allows you to move the
buffer out of the design area so much that the small object gets
inaccessible or even disappers from screen. Once the selection is
cancelled, the object can not be accessed anymore. If it went out in the
positive direction, increasing page size gets it back. If it went out in
the negative direction, who-knows-what-happens.
- Raw text -