kicad-developers team mailing list archive
Mailing list archive
Re: Fixing libcommon
Maciej Suminski <maciej.suminski@xxxxxxx>
Sun, 19 Mar 2017 22:04:15 +0100
spf=pass (sender IP is 220.127.116.11) smtp.mailfrom=cern.ch; lists.launchpad.net; dkim=none (message not signed) header.d=none;lists.launchpad.net; dmarc=bestguesspass action=none header.from=cern.ch;
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
On 03/19/2017 09:34 PM, Reece R. Pollack wrote:
> On 03/19/17 16:23, Maciej Suminski wrote:
>> On 03/19/2017 01:03 AM, Reece R. Pollack wrote:
>>> I want to accomplish two goals:
>>> 1. Allow the user to set the origin from which the location of all
>>> objects is measured. Right now this is the upper left corner of
>>> whatever Paper size and orientation is selected in the Page
>>> Settings. The user should be able to set the origin to a more
>>> convenient location, such as a reference point on a PCB.
>>> 2. Allow the user to set the positive X and Y directions from that
>>> reference point. This would allow a user to display Y-axis
>>> coordinates increasing from bottom to top, or decreasing as it is
>>> I want to accomplish these goals in a consistent manner across all
>>> editors (Schematic, Footprint, and Layout) without causing major
>>> revision to the internal representations.
>>> Could this be integrated into the work your doing to handle internal
>>> unit conversions?
>> Hi Reece,
>> What I am planning is not really related to the features you mention.
>> Currently we have a few files that contain multiple #ifdef
>> PCBNEW/EESCHEMA/etc. and is compiled many times with different
>> definitions, which is not the right way to go.
>> The final goal is to make all files compile only once. To do so, I am
>> moving the code parts wrapped with ifdefs to corresponding applications.
>> It is a refactor, without adding any new features.
>> We had a plan for another refactor that could be more related to your
>> wishes. I can give you some details, if you are interested.
> I'm very interested in anything that would help me avoid duplicating
> effort or complicating planned development.
The details have to be settled with Wayne first, but the idea has been
already proposed and got preliminary approval .
There are two variants of classes to handle graphic items and texts:
- DRAWSEGMENT and TEXTE_PCB for boards
- EDGE_MODULE and TEXTE_MODULE for footprints
The main difference is the board variants store only the absolute
position, whereas the footprint related classes keep also the
coordinates relative to the parent footprint.
We could simplify the class tree and remove one class in each group.
Relative coordinates are necessary, but the link to parent MODULE could
be replaced with a link to parent BOARD_ITEM_CONTAINER. This is a common
interface for both BOARD and MODULE classes. If we pursue the idea even
further, we could keep relative coordinates for all items, no matter if
their parent is a footprint or a board.
BOARD objects also store their position (as every BOARD_ITEM do), but
right now it is always (0, 0). Perhaps the board position could be
treated as the reference point. Depending on the rotation angle, you can
also have different X & Y axes directions.
It is an idea that should be discussed first. I would like to plan the
implementation and get Wayne's approval before we move forward.