[Kicad-developers] [PATCH] Large board speed

[Seth Hillbrand]

​Hi All-

Here's an updated patch for working with large, complex boards in v5.

Tom, I took your advice and put a light layer over an RTree for the
connectivity search.  Since this gets us bounding box collisions, we can do
commutative hits by using both items in the collision, eliminating the need
to iterate over the full list.

I also did a test merge with your dev tree and had only a couple minor
conflicts, so I think our approaches will compliment well.

It's not a full SHAPE collision, so it doesn't yet address
https://bugs.launchpad.net/kicad/+bug/1718831 but it speeds up the
connectivity and ratsnest to useable speeds for complex boards.

Please have a look and test-drive if possible.  Let me know if you see any
issues.  If you need a relatively complex board to test with with, you can
use https://github.com/ciaa/Hardware/tree/master/PCB/ACC/CIAA_ACC

-Seth


0001-Adjust-connectivity-to-use-RTree.patch
Description: Binary data
___
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

Re: [Kicad-developers] Footprint Library Wizard removal

[jp charras]

Le 24/05/2018 à 10:19, Maciej Sumiński a écrit :
> Attached a revised patch set, as the previous one looked ugly on Windows
> (and fine on Linux).

Thanks Orson.

The look of this dialog is much better now.

Just two remarks about the dialog itself: the dialog is not re-sizable, and 
should be derived from
our DIALOG_SHIM base class.


> 
> Cheers,
> Orson
> 
> On 05/23/2018 12:17 PM, Maciej Sumiński wrote:
>> As it has been reported [1], the Footprint Library Wizard is restricted
>> to the old Github repositories (one repo per library vs current single
>> repo for all libraries). I propose to replace it with a common file
>> browser, similar to the one in the Symbol Library Table dialog. In the
>> future we may develop a separate dialog to update the local libraries,
>> using a genuine git client letting us any repository (not only Github),
>> perhaps traverse through commits and display logs.
>>
>> I could not use the standard file dialog, as wxWidgets does not provide
>> one to select both files *and* directories, but it is necessary to
>> handle both .pretty libraries (directories) and foreign formats (e.g.
>> Eagle .lbr files) with a single dialog.
>>
>> Github plugin is still available, but has to be selected manually in the
>> Footprint Library Table dialog. I think it is reasonable not to expose
>> it, as it brings troubles to inexperienced users.
>>
>> AFAICT, the attached patch introduces one new string ("Show Hidden" in
>> the selector dialog), breaking the string freeze rule. The string is not
>> crucial, so it might be removed for the time being.
>>
>> Cheers,
>> Orson


-- 
Jean-Pierre CHARRAS

___
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

Re: [Kicad-developers] More default fields in schematic

[Jeff Young]

OK, I double-checked.  The schematic doesn’t get the mandatory names at all 
(just 1, 2, 3, 4).  The netlist exporters (at least generic and kicad) write 
the untranslated version in all lower-case.  The BOM exporters use the generic 
netlist exporter.

The 4 known fields are hard-coded, so there’s no existing mechanism we could 
lean on to do the translations for “standard" default fields.  It’d probably be 
best to store them in English and translate going out to the UI….

Cheers,
Jeff


> On 23 May 2018, at 13:00, Wayne Stambaugh  wrote:
> 
> You may want to test this just to be sure.  We had a similar issue with
> translating board layer names in the old board file format which created
> a big headache when we implemented the current board file format.
> 
> On 5/23/2018 4:43 AM, Jeff Young wrote:
>> Reference/Value/Footprint/Datasheet are translated only in the UI: the
>> file always uses the English versions.  (Presumably external tools will
>> look at the files, BOMs, netlists, etc.)
>> 
>>> On 23 May 2018, at 00:41, Wayne Stambaugh >> 
>>> >> wrote:
>>> 
>>> Wouldn't translating them defeat the purpose?  I thought the goal was
>>> consistency.  If you translate them, they will be different for each
>>> language and render code like kicost somewhat useless.
>>> 
>>> On 05/22/2018 05:52 PM, Kristoffer Ödmark wrote:
 Yes, the only way to make them translateable is to hard-code these and
 other values into kicad, same as the existing hard-coded fields.
 
 That would be a good solution for me, having similar to layers a large
 set of predefined fields, being able to name them and enable them at
 will. But storing them in the files as the hard-codes values.
 
 This means a large change to the code though, at least if we must have
 the enable/disable feature for this, along with creating new custom
 fields. Not even the PCB editor has this yet. 
 
 Also, I don't think any of the bom exporter plug-ins are localized, and
 at least one of them completely ignores custom fields and adds it own
 instead, regardless of what is in the file.
 
 Meanwhile my patch does not affect existing installations, does not
 change any BOM, and does not enforce anything and comes in at a whooping
 3-4 lines of patch in a single file. It will however add 3 lines to two
 dialogs (field editor and symbol editor) for new installations, which
 can be removed, with 6 clicks of the mouse in eeschema. 
 
 - Kristoffer 
 
 On Tue, May 22, 2018, 20:01 Jeff Young 
 >
 >> wrote:
 
I can confirm that default fields only get added when the symbol is
edited AND the default field’s value is non-empty.  So it doesn’t
seem to me that the proposed patch would pollute existing BOMs.  Or
am I missing something?
 
Seth’s comment regarding localisation is an issue, though, as we
don’t currently translate default fields.
 
> On 22 May 2018, at 17:53, Wayne Stambaugh  
> >
> wrote:
> 
> On 5/22/2018 12:43 PM, Jeff Young wrote:
>>> It should output all fields defined in schematic symbols
regardless if
>>> each optional field is defined in every symbol.  If they are
outputting
>>> anything other than that, I would consider this a bug.
>> 
>> I had trouble parsing this.  Are you saying that the list of
output fields should be the union of all fields which have a value
somewhere (but excluding default fields which are uniformly blank)?
> 
> Yes.  It should be the equivalent of a logical OR.  If a field
exists in
> a single symbol, it should get added to the BOM.
> 
>> 
>> As it stands in 5.0, default fields don’t get pushed to symbols
unless the symbol is edited.  At that point I’m not sure if they’re
all pushed, or only those with values.
>> 
> 
> It used to be that fields only get saved when they are added to the
> symbol using the edit symbol properties dialog.  That code has
changed a
> lot since it was originally written so I cannot confirm this.
 
 
 
 ___
 Mailing list: https://launchpad.net/~kicad-developers 
 
 Post to : kicad-developers@lists.launchpad.net 
 
 >
 

Re: [Kicad-developers] Footprint Library Wizard removal

[Seth Hillbrand]

​Orson-

The new one looks good here.

I'd vote for skipping the extra string field for now and ignore hidden
files.

-S​



Am Do., 24. Mai 2018 um 01:20 Uhr schrieb Maciej Sumiński <
maciej.sumin...@cern.ch>:

> Attached a revised patch set, as the previous one looked ugly on Windows
> (and fine on Linux).
>
> Cheers,
> Orson
>
> On 05/23/2018 12:17 PM, Maciej Sumiński wrote:
> > As it has been reported [1], the Footprint Library Wizard is restricted
> > to the old Github repositories (one repo per library vs current single
> > repo for all libraries). I propose to replace it with a common file
> > browser, similar to the one in the Symbol Library Table dialog. In the
> > future we may develop a separate dialog to update the local libraries,
> > using a genuine git client letting us any repository (not only Github),
> > perhaps traverse through commits and display logs.
> >
> > I could not use the standard file dialog, as wxWidgets does not provide
> > one to select both files *and* directories, but it is necessary to
> > handle both .pretty libraries (directories) and foreign formats (e.g.
> > Eagle .lbr files) with a single dialog.
> >
> > Github plugin is still available, but has to be selected manually in the
> > Footprint Library Table dialog. I think it is reasonable not to expose
> > it, as it brings troubles to inexperienced users.
> >
> > AFAICT, the attached patch introduces one new string ("Show Hidden" in
> > the selector dialog), breaking the string freeze rule. The string is not
> > crucial, so it might be removed for the time being.
> >
> > Cheers,
> > Orson
> >
> > 1. https://bugs.launchpad.net/kicad/+bug/1772209
> >
> >
> >
> > ___
> > 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
>
___
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

Re: [Kicad-developers] Symbol field editor dialog improvements

[Jeff Young]

Hi Ben,

Here’s a thought: when you did a git format-patch did you specify —attach 
origin/master?


> On 24 May 2018, at 16:02, Ben Gamari  wrote:
> 
> Jeff Young  writes:
> 
>>> Hmm, I had used git format-patch. Is there something wrong with the
>>> patch to suggest that I hadn’t?
>> 
>> On my machine git format-patch creates a multi-part mime message. I’m
>> enough of a git noob not to know whether or not that’s a problem but
>> when I try to apply your patch (which isn’t multi-part mime) using
>> “git am” I get:
>> 
> Are you sure you mean `git format-patch` and not `git send-email`? My
> understanding is that git format-patch just produces a standard patch
> file with a git-specific header containing authorship metadata.
> 
>> Applying: field editor: Find components when reference field is clicked
>> error: corrupt patch at line 21
>> 
> Hmm, odd. I would expect git format-patch to produce . I'll investigate.
> 
>> Can anyone point me in the right direction?
>> 
>> I agree that the algorithm in your second patch is superior. Do you
>> want to re-implement it on the current code, or do you want me to
>> change the existing algorithm?
>> 
> I can take care of it. Thanks!
> 
> Cheers,
> 
> - Ben


___
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

Re: [Kicad-developers] Symbol field editor dialog improvements

[Ben Gamari]

Jeff Young  writes:

>> Hmm, I had used git format-patch. Is there something wrong with the
>> patch to suggest that I hadn’t?
>
> On my machine git format-patch creates a multi-part mime message. I’m
> enough of a git noob not to know whether or not that’s a problem but
> when I try to apply your patch (which isn’t multi-part mime) using
> “git am” I get:
>
Are you sure you mean `git format-patch` and not `git send-email`? My
understanding is that git format-patch just produces a standard patch
file with a git-specific header containing authorship metadata.

> Applying: field editor: Find components when reference field is clicked
> error: corrupt patch at line 21
>
Hmm, odd. I would expect git format-patch to produce . I'll investigate.

> Can anyone point me in the right direction?
>
> I agree that the algorithm in your second patch is superior. Do you
> want to re-implement it on the current code, or do you want me to
> change the existing algorithm?
>
I can take care of it. Thanks!

Cheers,

- Ben


signature.asc
Description: PGP signature
___
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

Re: [Kicad-developers] Symbol field editor dialog improvements

[Jeff Young]

> Hmm, I had used git format-patch. Is there something wrong with the
> patch to suggest that I hadn’t?

On my machine git format-patch creates a multi-part mime message.  I’m enough 
of a git noob not to know whether or not that’s a problem but when I try to 
apply your patch (which isn’t multi-part mime) using “git am” I get:

Applying: field editor: Find components when reference field is clicked
error: corrupt patch at line 21

Can anyone point me in the right direction?

I agree that the algorithm in your second patch is superior.  Do you want to 
re-implement it on the current code, or do you want me to change the existing 
algorithm?

Cheers,
Jeff.


> On 24 May 2018, at 14:55, Ben Gamari  wrote:
> 
> Jeff Young  writes:
> 
>> Hi Ben,
>> 
>> You probably saw my comments in the bug that 0002 has already been
>> addressed.
>> 
> I see that. That being said, I somewhat favor the approach taken in my
> patch. The reason is that the committed solution behaves slightly
> unfortunately when faced with projects containing different sets of
> fields.
> 
> For instance, imagine I have a two projects
> 
> * Proj1 has fields A, B, C
> * Proj2 has fields A, B, D
> 
> When I switch from one project to the other the state of fields C and D
> will be forgotten. With my approach, however, they are retained. IMHO
> this is a more consistent (and certainly, in my case, useful) behavior.
> 
> Not to mention, my patch is considerably simpler, avoiding the need to
> serialise.
> 
>> Could you change the opening and closing braces to be on their own
>> line in 0001? (The rest matches our coding standard so I assume you
>> found it, but if not:
>> http://kicad.readthedocs.io/en/stable/Documentation/development/coding-style-policy/
>> ).
>> 
> Done. Revised patch attached.
> 
>> Also, if you could use git format-patch to produce the patch that would be 
>> great.
>> 
> Hmm, I had used git format-patch. Is there something wrong with the
> patch to suggest that I hadn't?
> 
> Cheers,
> 
> - Ben
> 
> From b8807c2888f3995eec7709aae91c44b880b954a5 Mon Sep 17 00:00:00 2001
> From: Ben Gamari 
> Date: Sat, 19 May 2018 11:25:28 -0400
> Subject: [PATCH] field editor: Find components when reference field is clicked
> 
> This makes it significantly easier to find a particular component when
> using the field editor, as I often do for part selection.
> ---
> eeschema/dialogs/dialog_fields_editor_global.cpp | 12 
> 1 file changed, 12 insertions(+)
> 
> diff --git a/eeschema/dialogs/dialog_fields_editor_global.cpp 
> b/eeschema/dialogs/dialog_fields_editor_global.cpp
> index f9e179452..308b68b8d 100644
> --- a/eeschema/dialogs/dialog_fields_editor_global.cpp
> +++ b/eeschema/dialogs/dialog_fields_editor_global.cpp
> @@ -174,6 +174,10 @@ public:
> return GetValue( m_rows[ aRow ], aCol );
> }
> 
> +std::vector GetRowReferences( int aRow )
> +{
> +return m_rows[ aRow ].m_Refs;
> +}
> 
> wxString GetValue( DATA_MODEL_ROW& group, int aCol )
> {
> @@ -823,7 +827,15 @@ void DIALOG_FIELDS_EDITOR_GLOBAL::OnRegroupComponents( 
> wxCommandEvent& event )
> void DIALOG_FIELDS_EDITOR_GLOBAL::OnTableCellClick( wxGridEvent& event )
> {
> if( event.GetCol() == REFERENCE )
> +{
> m_dataModel->ExpandCollapseRow( event.GetRow());
> +std::vector refs = m_dataModel->GetRowReferences( 
> event.GetRow() );
> +if (refs.size() == 1)
> +{
> +m_parent->FindComponentAndItem( refs[0].GetRef() + 
> refs[0].GetRefNumber(),
> +true, FIND_COMPONENT_ONLY, 
> wxEmptyString, false );
> +}
> +}
> else
> event.Skip();
> }
> -- 
> 2.16.2
> 


___
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

Re: [Kicad-developers] FreeRouting

[matthew venn]

I also use it a lot. I've been doing RGB keyboards recently and so have a
matrix of 4 pin leds and 2 pin switches. I use the autorouter for doing the
matrices.

Matt

On 24 May 2018 at 09:52, Luca Mini  wrote:

> Hi Brian and all,
> I admit to use autorouter to produce many fully functional and
> professional circuits (with Kicad obviously) . Sometimes I use manual
> routing for controlled impedance/noise/... tracks but generally I use it,
> for feasibilty and placement evaluation too.
> Why demonize autorouter? I believe it is really useful :D
>
> Thanks to support "autorouting" tool, with or without the specific dialog
> box.
>
> Cheers,
> Luca
>
>
>
> *Luca Mini*
> Via Brione, 11/C
> 10040 Givoletto (TO)
> EMAIL: luca.mini.freela...@gmail.com
> Cell: +39 334 2459673
>
> 2018-05-23 17:44 GMT+02:00 jp charras :
>
>> Le 23/05/2018 à 17:18, Brian Piccioni a écrit :
>> > For what it is worth, and despite knowing it is politically incorrect
>> to admit to using an autorouter, I have used Freeroute in the past and
>> would like to continue using it in the future. As much fun as manual
>> routing is (I treat it like a video game) sometimes you just want a board
>> quickly. You can always clean up dumb routes.
>> >
>> > Moreover, like Geographic reannotation, autorouting is a normal feature
>> for a professional PCB CAD tool and its absence is the sort of thing which
>> is noticed.
>> >
>>
>> I agree with Brian.
>>
>> And this is the exact reason I added a (poor) autorouter in Pcbnew.
>>
>>
>> > -Original Message-
>> > From: Kicad-developers > documenteddesigns@lists.launchpad.net> On Behalf Of Wayne Stambaugh
>> > Sent: May 23, 2018 9:17 AM
>> > To: Luca Mini 
>> > Cc: kicad-developers@lists.launchpad.net
>> > Subject: Re: [Kicad-developers] FreeRouting
>> >
>> > Hi Luca,
>> >
>> > Thanks for link.  It appears that we may have been a bit premature on
>> the removal of the FreeRouting dialog.  I just downloaded the latest source
>> code from the website below and the latest source file modification date is
>> 10/27/17 so it appears that our assumption that FreeRouting is no longer
>> being maintained is false.  There are even instructions on how to use KiCad
>> with FreeRouting[1] which shows the removed dialog.  Of course, we could
>> ping the FreeRouting folks to update their website to use the KiCad export
>> and import features.  Would someone please check on the user forum and see
>> if we are going to get a lot of backlash for removing this?
>> >
>> > Thanks,
>> >
>> > Wayne
>> >
>> > [1]: https://freerouting.org/freerouting/using-with-kicad
>> >
>> > On 5/23/2018 8:51 AM, Luca Mini wrote:
>> >> Hi Wayne,
>> >> I use freerouting and this link seems to be active on the "Freerouting"
>> >> argument.
>> >>
>> >> https://freerouting.org
>> >>
>> >> Cheers,
>> >> Luca
>> >>
>> >>
>> >> *Luca Mini*
>> >> Via Brione, 11/C
>> >> 10040 Givoletto (TO)
>> >> EMAIL: luca.mini.freela...@gmail.com
>> >> 
>> >> Cell: +39 334 2459673
>> >>
>> >> 2018-05-21 18:54 GMT+02:00 Wayne Stambaugh > >> >:
>> >>
>> >> Hey JP,
>> >>
>> >> On 5/21/2018 12:27 PM, jp charras wrote:
>> >> > Le 21/05/2018 à 18:09, Seth Hillbrand a écrit :
>> >> >> ​Hi Wayne-
>> >> >>
>> >> >> In https://bugs.launchpad.net/bugs/1567790
>> >>  you mentioned that we
>> >> won't be supporting FreeRouting for
>> >> >> v5.  Should we remove this menu item/icon from the menus?
>> >> >>
>> >> >> -S​
>> >> >>
>> >> >
>> >> > Hi Seth,
>> >> >
>> >> > Are you talking about .dsn and .ses files export import, or the
>> >> menu to call FreeRoute from Pcbnew?
>> >> >
>> >> > This is really not the same thing.
>> >> > Many EDA tools support .dsn and .ses files export import (and
>> this
>> >> import/export feature does not
>> >> > create issues).
>> >> >
>> >>
>> >> I'm OK with removing the FreeRouting dialog and menu entry.  I
>> don't see
>> >> any compelling reason to keep it since we already have support for
>> >> Specctra dsn export and Specctra session import for users who wish
>> to
>> >> continue using it.  Is FreeRouting even supported any more?  I
>> thought
>> >> it hasn't been maintained for quite some time.
>> >>
>> >> Cheers,
>> >>
>> >> Wayne
>>
>> --
>> Jean-Pierre CHARRAS
>>
>> ___
>> 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 : 

Re: [Kicad-developers] FreeRouting

[Luca Mini]

Hi Brian and all,
I admit to use autorouter to produce many fully functional and professional
circuits (with Kicad obviously) . Sometimes I use manual routing for
controlled impedance/noise/... tracks but generally I use it, for
feasibilty and placement evaluation too.
Why demonize autorouter? I believe it is really useful :D

Thanks to support "autorouting" tool, with or without the specific dialog
box.

Cheers,
Luca



*Luca Mini*
Via Brione, 11/C
10040 Givoletto (TO)
EMAIL: luca.mini.freela...@gmail.com
Cell: +39 334 2459673

2018-05-23 17:44 GMT+02:00 jp charras :

> Le 23/05/2018 à 17:18, Brian Piccioni a écrit :
> > For what it is worth, and despite knowing it is politically incorrect to
> admit to using an autorouter, I have used Freeroute in the past and would
> like to continue using it in the future. As much fun as manual routing is
> (I treat it like a video game) sometimes you just want a board quickly. You
> can always clean up dumb routes.
> >
> > Moreover, like Geographic reannotation, autorouting is a normal feature
> for a professional PCB CAD tool and its absence is the sort of thing which
> is noticed.
> >
>
> I agree with Brian.
>
> And this is the exact reason I added a (poor) autorouter in Pcbnew.
>
>
> > -Original Message-
> > From: Kicad-developers  documenteddesigns@lists.launchpad.net> On Behalf Of Wayne Stambaugh
> > Sent: May 23, 2018 9:17 AM
> > To: Luca Mini 
> > Cc: kicad-developers@lists.launchpad.net
> > Subject: Re: [Kicad-developers] FreeRouting
> >
> > Hi Luca,
> >
> > Thanks for link.  It appears that we may have been a bit premature on
> the removal of the FreeRouting dialog.  I just downloaded the latest source
> code from the website below and the latest source file modification date is
> 10/27/17 so it appears that our assumption that FreeRouting is no longer
> being maintained is false.  There are even instructions on how to use KiCad
> with FreeRouting[1] which shows the removed dialog.  Of course, we could
> ping the FreeRouting folks to update their website to use the KiCad export
> and import features.  Would someone please check on the user forum and see
> if we are going to get a lot of backlash for removing this?
> >
> > Thanks,
> >
> > Wayne
> >
> > [1]: https://freerouting.org/freerouting/using-with-kicad
> >
> > On 5/23/2018 8:51 AM, Luca Mini wrote:
> >> Hi Wayne,
> >> I use freerouting and this link seems to be active on the "Freerouting"
> >> argument.
> >>
> >> https://freerouting.org
> >>
> >> Cheers,
> >> Luca
> >>
> >>
> >> *Luca Mini*
> >> Via Brione, 11/C
> >> 10040 Givoletto (TO)
> >> EMAIL: luca.mini.freela...@gmail.com
> >> 
> >> Cell: +39 334 2459673
> >>
> >> 2018-05-21 18:54 GMT+02:00 Wayne Stambaugh  >> >:
> >>
> >> Hey JP,
> >>
> >> On 5/21/2018 12:27 PM, jp charras wrote:
> >> > Le 21/05/2018 à 18:09, Seth Hillbrand a écrit :
> >> >> ​Hi Wayne-
> >> >>
> >> >> In https://bugs.launchpad.net/bugs/1567790
> >>  you mentioned that we
> >> won't be supporting FreeRouting for
> >> >> v5.  Should we remove this menu item/icon from the menus?
> >> >>
> >> >> -S​
> >> >>
> >> >
> >> > Hi Seth,
> >> >
> >> > Are you talking about .dsn and .ses files export import, or the
> >> menu to call FreeRoute from Pcbnew?
> >> >
> >> > This is really not the same thing.
> >> > Many EDA tools support .dsn and .ses files export import (and this
> >> import/export feature does not
> >> > create issues).
> >> >
> >>
> >> I'm OK with removing the FreeRouting dialog and menu entry.  I
> don't see
> >> any compelling reason to keep it since we already have support for
> >> Specctra dsn export and Specctra session import for users who wish
> to
> >> continue using it.  Is FreeRouting even supported any more?  I
> thought
> >> it hasn't been maintained for quite some time.
> >>
> >> Cheers,
> >>
> >> Wayne
>
> --
> Jean-Pierre CHARRAS
>
> ___
> 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