Hi Dick, and all the others involved in the modular design.
I noticed something regarding the modular kicad apps :
When you have some modal window opened in one of the app, eg the module
properties window in pcbnew, all the kicad modules are frozen until you
close that window.
It's not a big deal, but rather boring, when you need to check something
in eeschema when editing module properties, you can't launch eeschema
with the button in the kicad main window as it is not responding. And if
eeschema was alredy opened you can't even scroll the schematic.
I don't know if it is technically possible to change this behaviour, but
I think it could be a great improvement.
Just my two cents.
regards,
yann
Le 04/08/2014 18:05, Dick Hollenbeck a écrit :
On 07/29/2014 02:02 PM, Wayne Stambaugh wrote:
On 7/27/2014 1:33 PM, Dick Hollenbeck wrote:
Gentlemen:
In the course of trying to load the schematic editor directly under kicad.exe,
by-passing
eeschema top frame itself, I was exposed to a range of issues in the design of
eeschema.
Firstly, I discovered the most excellent work by Wayne Stambaugh regarding the
schematic
library containers.
Thanks Dick. I wasn't really expecting any credit. I was just one of
those things that needed fixed so I fixed it. I knew that that only way
to move Eeschema forward was to fix the underlying library containers.
I wish I had the time to finish the SCHEMATIC object and come up with a
better way to handle sheet hierarchies. With those two pieces of the
puzzle in place, we could start moving towards the new file format and
other enhancement that we have discussed over the years.
There are a long chain of dependencies here. LIB_EDIT_FRAME, to come up first,
needs the
libraries. That is obvious in words. But SCH_EDIT_FRAME typically loads the
libraries
before popping up LIB_EDIT_FRAME. You have a similar discussion about
LIB_VIEW_FRAME.
(I believe I solved all these similar problems for PCBNEW.) So now I went to
solve them
for EESCHEMA and produced an 11,000 line patch in 2.5 days. Remember that
about only
1/7th of a patch line count are actual changed lines.
The eeschema libraries were global, even if hidden behind a static class
function, they
were global. This would not dovetail into the notion of multiple open
projects, each
having its own set of libraries. So in the course of moving libraries into a
project
specific container, lots of changes were needed. First among those was to park
the
libraries container in the PROJECT. It was a necessary but insufficient
solution for
multiple open projects. One remaining issue is the fact that with multiple
open projects
you'd still have the same library open twice. Its hard to have the same
problem in
PCBNEW, (would have to duplicate project specific libraries) and even if you
did, most of
the plugins react to a change on disk and will re-cache if one of the copies is
edited.
We now have the libraries container in the PROJECT at least, and it is loaded
on demand,
by any _eeschema.kiface KIWAY_PLAYER that needs it.
For 5 years or more no one questioned the terminology I introduced in the SWEET
distributed library design regarding the definition of PART and a COMPONENT.
The time to
object was 5 years ago. So I went with those original terms per that prior
design.
LIB_COMPONENT is now LIB_PART. SCH_COMPONENT remains.
Works for me. I've always thought that LIB_COMPONENT and SCH_COMPONENT
naming was confusing.
SCH_COMPONENT uses a link to a LIB_PART. That link was previously done by a
library
search on every Draw() call. This was easy since the library container was
global, and
the SCH_COMPONENT had access to the global container. Not so now.
I seem to remember some other global variables used by the Draw()
functions. The color table and possibly some visibility settings come
to mind. I don't know if these have any context per project but it may
be one of those things you want to look out for just in case.
This also introduced an avoidable performance hit, which is avoided if a link
to the
LIB_PART is retained across SCH_COMPONENT redraws.
You can pretty much now tell where this took me. Squarely into
boost::shared_ptr and it
companion class boost::weak_ptr.
I will get it working in another half day and push it to its own branch, and
would like
folks to use EESCHEMA for a couple of days in that branch.
My son and I are doing a very complex board
together.
And you can load the part editor and footprint editors directly from kicad.exe,
for a
single project now.
Awesome work Dick! I'll try to do some testing as soon as I see the
branch on launchpad.
Wayne
I pushed an early branch of this work to milestoneB.
See the commit log for some of the details.
The shared_ptr turned out to be a can of worms. No, several cans of worms, all
stacked
like a 2 miles of dominos.
So I used a single one per LIB_PART according to this link here, and saved us
all a lot of
gray hairs. This is a very elegant solution which cherry picks not one IOTA
more than
what we needed:
http://www.boost.org/doc/libs/1_55_0/libs/smart_ptr/sp_techniques.html#weak_without_shared
I pushed this to branch milestoneB and would appreciate some testing help.
There are some TODO items in my section of TODO.txt for this block of work.
Most notable
is moving the Color loading into the eeschema KIFACE::OnKifaceStart().
Also, the libraries are loaded more often than they should be, I think
SCH_EDIT_FRAME
needs to quit deliberately loading them and simply use the data on demand
technique. You
can see schematic editor loading libraries even if you load the lib editor
first. This is
trivial to fix.
I will fix those TODO items along with any bug reports and get 'em done soon.
I also saw a segfault somewhere as I was leaving the room. Need to track
perhaps a couple
of these down.
All in all, kicad is more modular, and there's lot to like here I think.
Dick
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
