X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f X-Recipient: geda-user AT delorie DOT com Date: Sun, 31 Jul 2016 17:19:03 +0200 (CEST) X-X-Sender: igor2 AT igor2priv To: geda-user AT delorie DOT com X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu" From: gedau AT igor2 DOT repo DOT hu Subject: Re: [geda-user] pcb: ARC bug In-Reply-To: Message-ID: References: <575325A6 DOT 5020802 AT iee DOT org> <5753CE50 DOT 1020405 AT iee DOT org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Precedence: bulk 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.