Thanks everyone for your input. I'll revert patch and move to creating the IO_ERROR exceptions for unimportable items.
As an aside, is there a particular reason why polygons are not editable in the footprint editor? Even if they were restricted to non-copper? Regards Russell On Tue, Sep 26, 2017 at 12:34 AM Wayne Stambaugh <stambau...@gmail.com> wrote: > On 9/25/2017 9:13 AM, jp charras wrote: > > Le 25/09/2017 à 10:22, Maciej Sumiński a écrit : > >> Hi Russell, > >> > >> Would you provide a board example that would be affected by the change? > >> It would be very helpful to test the patch. > >> > >> I am not really sure whether EDGE_MODULEs drawn on copper layers will be > >> exported to Gerbers and I am certain that they will not be taken into > >> account during DRC or zone fill calculations. If my suspicions are > >> correct, then IMHO presence of such footprints should lead to a warning > >> message and nothing more. Perhaps they could be converted to custom > >> shape pads, but I am not sure it is always applicable or trivial. > >> > >> Regards, > >> Orson > > > > I am also not especially thrilled by allowing EDGE_MODULEs items on > copper layers for 2 reasons: > > - DRC does not take in account these items. > > - EDGE_MODULEs polygonal shapes are not editable in the footprint editor. > > Therefore you cannot remove or change them. > > > > They are allowed in a very specific case: automatically generated > microwave footprints. > > (and I recently modified a microwave footprint type to use a custom pad). > > > > A warning message is currently the only one reliable way to manage this > kind of item. > > Allowing EDGE_MODULEs items on copper layers during Eagle to Pcbnew > import process is the best way > > to create serious issues and mistakes. > > In short: on a copper layer, you cannot easily put graphic items. > > > > Remark: EDGE_MODULEs items on copper layers are handled in zone filling > and plot functions. > > However, because they are not belonging a net (because in Pcbnew they > are not currently linked to a > > pad), they cannot be perfectly handled. > > Thank you for the input JP. > > Russel, you will have to change your patch accordingly. I see two > possible options, neither will be easy. Convert to a custom pad or > convert to another layer and warn the user about the issues so they can > manually fix them. The custom pad conversion complexity is obvious. > The user warning is not as easy as it would seem. No UI code is allowed > in plugins. This means that you must queue up messages, raise an > IO_ERROR exception, and catch that in the UI code. > > > > >> > > <<<snipped>>> > > _______________________________________________ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
