Importing of symbols
D Sievers
I was curious, where you're importing symbols in the newSchematic()
method, why you've commented out several gEDA directories, rather than
importing the whole set they provide. Is it just to make a shorter
list, or because those symbols cause trouble in some way?
I've been working through the PyQt book, and have some PSchem features
in progress. Hopefully I can post up a branch soon (a week or so) with
something for you to look at.
Regards,
Doug
Andrzej
>
> I was curious, where you're importing symbols in the newSchematic()
> method, why you've commented out several gEDA directories, rather than
> importing the whole set they provide. Is it just to make a shorter
> list, or because those symbols cause trouble in some way?
They are commented out for the sole purpose of making the import time
shorter. I'm using it for debugging only so I don't want to wait too
long for the PSchem to import all the available libraries.
At some point we are going to have our own storage back-end. In this
case the load process will be automatic and lazy (i.e. it will only
load these cellviews that are accessed by the user). Then this
restriction will go away.
When importing symbol libraries be careful about the cell name
resolution. Look at the "spnet" library for example - it uses its own
symbols (spnet.sym) which partially overshadow symbols from the "sym"
library. This is because there is a notion of "scope" in the library
hierarchy.
Also, there are still many features not yet implemented. This includes
attributes (which I started working on), connectivity, pins etc. They
may be visible on the schematics but there is no any semantics
attached to them yet.
> I've been working through the PyQt book, and have some PSchem features
> in progress. Hopefully I can post up a branch soon (a week or so) with
> something for you to look at.
Good. Hope you have fun with it.
BTW, last time I told you to use TortoiseGit (which I still think is
very good), but now I found that plain "git gui" has one "killer
feature" that I highly recommend you to use: http://vimeo.com/2111264
At least for me it is now far more easy to split larger changes into
several smaller independent commits. Sorry if I'm stating something
obvious - it wasn't obvious for me.
Cheers,
Andrzej
D Sievers
Slow progress lately, I think I might trash what I've been working on,
based on what you had mentioned regarding the lazy loading.
I was working on implementing a light-weight version of the
"Preferences" dialog that's used in Eric4, since I figured one thing
to start on would be a dialog where a user can set their symbol import
paths, and have the application load them on start-up.
Well, the Eric preferences dialog is great, but it's rather
complicated. Although I've streamlined it quite a bit, at the moment
it's still designed to use the Qt Designer for a base to the dialogs,
which then generates PyQt code output (not PySide). I suppose for
PySide, one could use the PySide toolchain to generate the ui code
from the file, but since currently you've implemented a choice for
users in the Globals file, any code that's autogenerated would still
need to be changed to reflect the choices from the global file. So,
it's all a little complicated.
If you're unfamiliar the Eric preferences will load a page as a
module, so it's relatively easy to add configuration pages, which
makes it nice to work with as the application/preferences grows.
However, it was also a little overcomplicated, and I've done a rather
large amount of refactoring and am not quite pleased with it yet. I
was hoping to avoid "re-inventing the wheel" but it may have been much
faster to do so.
If you like the idea of a preferences dialog, I'll continue to work on
it. If not, I might continue on it at lower priority, and release it
as a side project. I was thinking it's something that almost every app
needs, and if I made it as a modular dialog it would be easy to plug
in to PSchem or any app.
Regards,
Doug
On Apr 24, 5:46 am, Andrzej <ndrwr...@googlemail.com> wrote:
Andrzej
A configuration mechanism is a great idea, very valuable contribution.
It may indeed be tricky to implement so take your time. I haven't
thought about it much so far (except for storing/restoring some
settings using Qt settings backend - this has been temporarily
disabled because I hit an incompatibility between PyQt and PySide in
handling QVariant/QByteArray), so I'm going to rely on your good
sense. If you're using implementation of eric as an example the result
should be OK.
I'm not sure if we want to store the import settings in the
preferences dialog. Sure, things like recently used paths should be
stored in the configuration backend but actual GUI controls should
rather go into an import dialog box (once we have one). For the time
being I'm OK with putting them into general preferences, though, if
only for making the development easier.
What exactly compatibility problem did you hit? Ideally we could work
it around so that the final solution works with both toolkits. If the
auto-generated code needs some manual tweaks - I'm OK with that.
Hopefully someday it will be fixed.
Thanks,
Andrzej