On Fri, 11 Nov 2011, Øyvind Aabling wrote:
On Thu, 10 Nov 2011, Wayne Stambaugh wrote:
On 11/10/2011 1:15 PM, Øyvind Aabling wrote:
There seems to be a problem with the eeschema
library editor in recent BZR versions of kicad:
Changes to edited parts aren't saved to disk, and the only
way to exit the library editor is to discard all changes :-(
I've now checked the BZR versions that I've been running lately,
and it works in BZR 3001 and 3153, and is broken in 3212,
3221 and 3226 (so it broke somewhere between 3153 and 3212).
I've updated my Debian recently, so I pulled BZR 3001
again (had deleted it :-) and the latest (BZR 3226), and
compiled both, to see if the problem was (in some obscure way)
related to library files on my system that have been upgraded
since compiling the various versions of kicad (No, it isn't ...).
To recreate:
Start eeschema,
start the Library Editor,
"Select working library",
(any library that you have write access to, e.g. in your project dir)
"Load component to edit from the current lib",
(any component will do)
"Create a new component from the current one",
(or change the component in some way, or create a new
component, or ... - anything that's considered a change)
"Update current component in current library",
(this step can be skipped - the next step will
then ask for inclusion of the changes, which
doesn't make any difference on the behaviour)
"Save current library to disk"
Include last component changes? Yes
Modify library file "<name>.lib"? Yes
Now, the <name>.lib and/or <name>.dcm file(s) should have been
updated, but no, they're not, and the "Save current library to disk"
icon (far left) doesn't inactivate (gray out) either.
I do not have this problem on 64 bit Debian Testing using KiCad version BZR
3226 and wxWidgets 2.8.12 even with all of the fancy new Gnome 3 stuff. The
library file changes are saved properly and the save current library tool
bar icon and file menu entry are disabled as expected.
Well, I kinda suspected that, as such a major
problem probably couldn't go unnoticed for long :-)
I'm also using 64-bit Debian Testing, but with wxWidgets 2.8.10.1-3.1.
With wxWidgets upgraded to 2.8.12.1-2, I've now recompiled a
clean BZR 3226 tree with $MAKE unset (normally set to "make -j5").
The problem isn't in wxWidgets or the parallel
make, as the problem still persists :-(
Since you don't see this problem on a similar system, it sounds like
my system contains a buggy version of some (other) library - one that
contains a feature not used in kicad until somewhere between 3153 and 3212.
Even though I upgraded only a few weeks ago, apt-get now wants
to update almost 1k packages (out of 3k), so I think I'll do a
full (dist-)upgrade tomorrow, and see if that makes a difference.
I've now done an apt-get dist-upgrade (1k packages updated,
2k unchanged), and have recompiled various kicad versions.
The problem still persists after the upgrade, so I've also done
a binary search between BZR revisions 3153 and 3212 (and also
did 3227), to determine the exact revision containing the break:
bzr update -r revno:XXXX ; rsync ./ ../kicad-test ;
cd ../kicad-test ; make build ; cd build ; cmake ;
make ; make install ; kicad (start eeschema, test it ...)
The result is:
BZR 3153: Works
BZR 3180: Works
BZR 3195: Works
BZR 3203: Works
BZR 3204: Broken
BZR 3205: Broken
BZR 3208: Broken
BZR 3212: Broken
BZR 3227: Broken
So, it's something in BZR 3204 that hits me.
I've looked at a "diff -ur" between the 3203 and 3204 source trees,
and have determined that it's the changes to common/basicframe.cpp
that breaks the Library editor Save function for me:
--- === ---
diff -ur kicad-3203/common/basicframe.cpp kicad-3204/common/basicframe.cpp
--- kicad-3203/common/basicframe.cpp 2011-11-11 12:20:58.000000000 +0100
+++ kicad-3204/common/basicframe.cpp 2011-11-11 12:21:40.000000000 +0100
@@ -543,25 +543,21 @@
{
wxString msg;
- wxCHECK_MSG( aFileName.IsOk(), false, wxT( "Invalid file name object. Bad
programmer!" ) );
+ wxCHECK_MSG( aFileName.IsOk(), false,
+ wxT( "File name object is invalid. Bad programmer!" ) );
+ wxCHECK_MSG( !aFileName.GetPath().IsEmpty(), false,
+ wxT( "File name object path <" ) + aFileName.GetFullPath() +
+ wxT( "> is not set. Bad programmer!" ) );
if( aFileName.IsDir() && !aFileName.IsDirWritable() )
{
msg.Printf( _( "You do not have write permissions to folder <%s>." ),
GetChars( aFileName.GetPath() ) );
}
- else if( !aFileName.FileExists() )
+ else if( !aFileName.FileExists() && !aFileName.IsDirWritable() )
{
- // Extract filename path, and if void, uses the CWD
- // because IsDirWritable does not like void path
- wxString filedir = aFileName.GetPath();
- if( filedir.IsEmpty() )
- filedir = wxGetCwd();
- if( !aFileName.IsDirWritable(filedir) )
- {
- msg.Printf( _( "You do not have write permissions to save file
<%s> to folder <%s>." ),
- GetChars( aFileName.GetFullName() ), GetChars( filedir
) );
- }
+ msg.Printf( _( "You do not have write permissions to save file <%s> to
folder <%s>." ),
+ GetChars( aFileName.GetFullName() ), GetChars(
aFileName.GetPath() ) );
}
else if( aFileName.FileExists() && !aFileName.IsFileWritable() )
{
--- === ---
AFAICS, all other changes between 3203
and 3204 are irrelevant for this problem.
The wxCHECK_MSG's are probably harmless (unless they
have sideeffects ?), and why these changes hits me and
not you (_any_ of you ?), I can't imagine, but ...:
