kicad-developers team mailing list archive
Mailing list archive
Re: 5.0.1 release
Seth and JP,
On 09/23/2018 03:41 AM, jp charras wrote:
Le 22/09/2018 à 20:09, Seth Hillbrand a écrit :
Am Sa., 22. Sep. 2018 um 10:22 Uhr schrieb Wayne Stambaugh
You may want to coordinate with JP on this. I believe he is working on
a fix as well. I also have a few ideas that I would like to discuss
about the current design going forward. I'm going to be busy the rest
of the day but tomorrow I will have some time to go over some of my
thoughts about the current situation.
Just seeing this. 1778564 turned out to be a clang-specific problem.
Long-term, a lot of this probably goes away if we incorporate kicad2step
internally but I'll be curious to hear other thoughts/options.
I recently made a few tests on Linux, and find there are many issues
with filenames (and strings) using non ascii7 chars.
These issues are encountered when kicad2step is a console application
using a wxAppConsole application.
When a similar (nearly the same) code run using wxApp, these problems
For instance, on my Linux 14.04 French, inside a wxAppConsole:
"wxLogMessage( "12à" );" segfaults.
And wxPrint, wxFile, wxFileName have serious issues.
(wxLogMessage and wxPrint print nothing if a string contains unicode chars)
Inside a wxApp, it works as expected.
Currently, I have a modified source (only for tests) where I removed
all wxLogMessage calls and replaced by a Report(wxStrin& msg) call to
avoid issues in wxLogMessage .
And I am waiting for Wayne's ideas.
Of course incorporate kicad2step internally will fix these non ascii7
But there is a difficulty: Opencascade prints messages on a console when
How to collect them if we want to print them inside a window in Kicad.
An alternate option (I tested it) is modifying kicad2step to use wxApp,
and run it like now as external application.
I don't think it can be done for 5.01 release.
I would prefer we spend the minimal amount of time required to fix the
current kicad2step issues as best we can. I never been a big fan of
calling an external app to create the mcad files. I suspect there are
some users who will want to continue to use the stand alone app but I
really do not want to continue to support it over the long run. The
current design was always meant to be a stop gap measure to provide
support for step and iges output.
I would like to see us fix this in three phases.
Phase 1, remove external process call:
Copy the pcb/ and sexpr/ from the kicad2 step folder into the common/
Create a new KICAD2MCAD object that only handles the export options in
the dialog and accepts an optional REPORTER object to dump to the dialog
Replace all instances of wxLogMessage in the step export code to us the
optional REPORTER object.
Since OCE has a known issue with non-ascii characters, check if the
output file name contains non-ascii characters and write to a temporary
file and then copy the temporary file to the proper file name using the
correct file name (thanks to JP for that suggestion).
Phase 2: remove dependency of external s-expr parser.
Pass a BOARD object to the KICAD2MCAD object and use the actual board
objects to create generate the oce call information rather than the
Remove the s-expr code as it willl no longer be required.
Phase 3: command line access to the exporter
Add command line support for the step exporter to pcbnew.
Remove the stand alone kicad2step code.
I don't think phase 1 will be all that difficult but it will be some
busy to replace wxLogMessage with REPORTER. Phase two will require a
lot more effort to go through all of the oce output code and replace the
current parser with the BOARD objects. Phase 3 may be tricky if we
cannot figure out a way to run the export code without displaying the
frame window but I haven't looked at this yet so I could be wrong.
As far as timing, I would like to see Phase 1 be done as part of 5.1.
Phases 2 and 3 can be done as part of v6 or later.