kicad-developers team mailing list archive
Mailing list archive
Re: Redundunt Lib path info
Before I start, nice work on the OrCad conversion. I looked at it a
couple of weeks ago.
Your questions fall into two categories: code related, and philosophy
Regarding code: "use the source Luke".
Philosophy: this is better for Jean-Pierre to answer since I was not
involved back when the project manager was written or file formats chosen.
Regarding the log window: The normal child launch mechanism of Kicad
launching PCBNEW, does redirect stdout of PCBNEW back through a pipe to
Kicad. This is done in wxWidgets, at least on the Linux version and
possibly on Windows too. When compiled with DEBUG=1, pcbnew uses
printf()s to stdout, and std::cout<< as well. These bytes get routed to
the parent, Kicad. But it is not reading this stream and eventually
pcbnew will lock up as the pipe gets full.
See my comment at line 238 of pcbnew/files. If you wanted to pursue
this path, you could teach Kicad to read from this pipe, and get any
output from either of eeschema and pcbnew.
You should start with the place where wxWidgets is used to launch the
child processes. The pipe handles can be grabbed from there. We are
utilizing less than the full features of the platform independent
launching mechanism provided within Kicad.
I almost always run pcbnew from the command prompt, as I toggle moment
to moment from user to developer. Same for eeschema. I basically don't
ever use the project manager. There may be other users in the same boat.
But yes, I think it would be fairly easy to send text through a pipe
back to the parent process. The child just writes to stdout. For me,
I guess that would show up on the console, since there would be no
parent most of the time. It's hard to beat printf()s for convenience
of reporting. The hard work is in the kicad project manager, finding a
way to read from the pipe in the background and put whats read into a
tele-type style scrolling text area. For communicate between eeschema
and pcbnew we use a loopback socket. But there is a simpler solution
for the parent child relationship especially if the text is flowing in
one direction only, from child to parent, as described. wxWidgets
supports event listening hooks, and you may be able to provide a hook to
read from the pipes associated with the children and do all this from
the same main thread. It might be easy, depends on how well you read
and program :)
Hope this helps,
Here is an area for enhancement I could work on with
some background info before I jump into the code.
At first glance it seems the library Path information
is required to be in the schematic file(.sch) and in the
project file(.pro). I wonder why this is the case.
If I'm importing a schematic with it's libraries as
is the case with an OrCad EDIF file, I can include
the Library Refs in the schematics file with a path='.',
the schematic and library files in some temp directory
unknown to KiCad and I would expect EEschema to be able to
run standalone without the KiCad project mgr. This doesn't seem
to be the case so I create a new project using KiCad and
it sets up the default libraries/ install PATH.
Why should KiCad need to know either the EEschema or pcbnew
libraries/Path? Putting the info in two places doesn't
seem optimal or necessary.
Also is the Library PATH a single PATH or can it be
a ':' separated multipath also dictating the search path
for symbols or footprints? Could be one search path for
both since symbols are (.sym) and footprints are (.mod).
A search path would also help with multiple symbols for
resistors and caps coming out of OrCad (or other sources)
also with different scaling/orientation. The user would only
need to make sure symbols for the current schematic was first
in the list.
Also I see there is a log window in KiCad project mgr.
What would it take to echo unresolved symbols when a schematic
is loaded or even the path of a resolved (found) symbol?
Great work todate.
Yahoo! Groups Links
*** If he runs, I will be supporting Tom Tancredo for President in 2008. ***