It would be good to allow expressions in fields that affect the placement or sizes of components.
Examples for pcbnew
If we want to have a pad that is always ratio 1:2, we can define width=2*$height for instance. $height is a reference to some other property in the same component (the entry fields should show the variable names they provide, or mouse-over or something. Possibly field completion).
It should be possible to refer to fields of other components (e.g. $R22.x$"designator with space".x ... better syntax probably), so that it is possible to have relative placement of components.
if I want to place LEDs in a circle around a encoder with designator ENC1, we now can only specify the angle in degrees for each of these LEDs and have the coordinates determined by something like x=10mm * cos($angle) + $enc1.x, y=10mm * sin($angle) + $enc1.y.
We also could have a special global bag of variables that people can use to have a single place to define variables $global.led_ring_radius for instance. Then we can use that in all the places.
(x=$global.led_ring_radius * cos($angle) * $enc1.x)
Possibly named user-defined variable in components ? These could be configured in the schematic and pcbnew. This would allow to for instance number the LEDs in the schematic and then use expressions such as $pinnumber * 15 to calculate the angle.
Footprint design ?
This might actually also be useful for just definition of packages, because it is possible to directly read things from a datasheet and enter it as expressions. e.g. pins with spacing of 0.5mm start 3mm from the edge of the package ? Let's have some variable $package.edge = 3mm so we can define the position of a pin as $package.edge + $pin * 0.5mm. Made up example of course, but it allows much faster modification on changes.
This should be pretty simple expressions (should be easy to write a parser for it and constraint solver), but it will be very powerful as a CAD tool, as it allows things that are otherwise too tedious.
It need to be thought through and carefully documented first (possibly with some demo implementation) before settling too early so that we are not locked into a hard-to-extend situation.
Now things are pretty neat as if the encoder is moved, all the LEDs around it are also moved (as they are tied to the $enc1.x, $enc1.y coordinates.
Problems arise if the user wants to move constraint things with a mouse (e.g. one of the LEDs). Three options:
not moving (like a 'locked module')
Moving but adding relative coordinates to the expression; say we moved x by 12.3mm, it would change the expression to x=$global.led_ring_radius * cos($angle) * $enc1.x + 12.3mm
totally replace the expression with the new coordinates, overwriting whatever expression was in there before (but maybe remember the expression so that later on this can be recovered with a drop-down ?)
Lots of questions to think more refined about but really powerful.
It would be good to allow expressions in fields that affect the placement or sizes of components.
Examples for pcbnew
width=2*$heightfor instance.$heightis a reference to some other property in the same component (the entry fields should show the variable names they provide, or mouse-over or something. Possibly field completion).$R22.x$"designator with space".x... better syntax probably), so that it is possible to have relative placement of components.ENC1, we now can only specify theanglein degrees for each of these LEDs and have the coordinates determined by something likex=10mm * cos($angle) + $enc1.x,y=10mm * sin($angle) + $enc1.y.$global.led_ring_radiusfor instance. Then we can use that in all the places. (x=$global.led_ring_radius * cos($angle) * $enc1.x)$pinnumber * 15to calculate the angle.Footprint design ?
$package.edge = 3mmso we can define the position of a pin as$package.edge + $pin * 0.5mm. Made up example of course, but it allows much faster modification on changes.This should be pretty simple expressions (should be easy to write a parser for it and constraint solver), but it will be very powerful as a CAD tool, as it allows things that are otherwise too tedious.
It need to be thought through and carefully documented first (possibly with some demo implementation) before settling too early so that we are not locked into a hard-to-extend situation.
Now things are pretty neat as if the encoder is moved, all the LEDs around it are also moved (as they are tied to the
$enc1.x,$enc1.ycoordinates. Problems arise if the user wants to move constraint things with a mouse (e.g. one of the LEDs). Three options:x=$global.led_ring_radius * cos($angle) * $enc1.x + 12.3mmLots of questions to think more refined about but really powerful.