delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2016/07/31/11:10:50

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: <nj1fn4$tk0$1@ger.gmane.org>
Message-ID: <alpine.DEB.2.00.1607311702430.7286@igor2priv>
References: <alpine DOT DEB DOT 2 DOT 00 DOT 1606041445000 DOT 28818 AT igor2priv> <575325A6 DOT 5020802 AT iee DOT org> <nj0afa$sel$1 AT ger DOT gmane DOT org> <5753CE50 DOT 1020405 AT iee DOT org> <nj1fn4$tk0$1 AT ger DOT gmane DOT org>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
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


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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019