File operations, bugs and change requests

[Dr M]

There are several issues in the dialogues and actions under the file menu.

1) The dialogue to load layout or net file should open in the same directory as the already open pcb file. I spend a lot of time repeatedly navigating back to my work directory from this dialogue.

2) The gsch2pcb or load layout item, I figure which, where it should have simply changed one foot print, instead reinitialized the pcb file, trashing my layout and causing a loss of about one hour of work.

[Chad Parker (parker-charles)]

Regarding #1:

It looks like pcb should be keeping track of three different directories: a layout dir, an element dir, and a netlist dir. So, the first time you load any of these three things, the path should be your working directory, probably home if you are launching through a gui. The second time you load a layout, it should open pointing at the same directory your current layout is in. The second time you load a netlist, it should open pointing to the same directory your current netlist is in. And ditto for elements.

Can you confirm this behavior?

If you were to launch pcb from a terminal in which the current directory were the directory of your layout, then that directory would be the working directory, and the dialogs should open pointing there.

One way to perhaps make this a little kinder would be to use the "layout dir" as a fallback for the netlist dir or element dir if they aren't set yet. However, I can conceive of instances in which this would be undesirable. For example, if a user keeps their footprint library in $HOME/lib/pcb/footprints , then it would be more convenient to have the opening directory be your home directory.

So, perhaps opening netlists should use the layout directory but loading elements should not?

[Dr M (drmcn)]

I am about to start a board and will try confirm the behavior shortly.

Aside, another area that seems could a bit more fleshed, is the parts
management.   Its not clear what the conventions are for this, its not
obvious which  attributes if any, were intended to store the vendor and
partnumber.  My work around for the moment, is to use the description
attribute, c.f. /description=Digikey <partnumber>, /or Mouse, or Arrow,
etc.

To connect this all together, I wrote a python script to read the
schematics and create a bom in csv format.  For those who are
interested, I attached a copy of the current version of the python
script.  Its work in progress, but seems to do the job.   I upload it
the output to Digikey and click "checkout", and so far it seems to work.

On 05/27/2018 01:03 PM, Chad Parker wrote:
> Regarding #1:
>
> It looks like pcb should be keeping track of three different
> directories: a layout dir, an element dir, and a netlist dir. So, the
> first time you load any of these three things, the path should be your
> working directory, probably home if you are launching through a gui. The
> second time you load a layout, it should open pointing at the same
> directory your current layout is in. The second time you load a netlist,
> it should open pointing to the same directory your current netlist is
> in. And ditto for elements.
>
> Can you confirm this behavior?
>
> If you were to launch pcb from a terminal in which the current directory
> were the directory of your layout, then that directory would be the
> working directory, and the dialogs should open pointing there.
>
> One way to perhaps make this a little kinder would be to use the "layout
> dir" as a fallback for the netlist dir or element dir if they aren't set
> yet. However, I can conceive of instances in which this would be
> undesirable. For example, if a user keeps their footprint library in
> $HOME/lib/pcb/footprints , then it would be more convenient to have the
> opening directory be your home directory.
>
> So, perhaps opening netlists should use the layout directory but loading
> elements should not?
>

[Dr M (drmcn)]

man!   i'm creating yet another smt footprint, and once again looking up
how to do it.  this is by far the most tedious part of working with any
layout program.  there used to be a very nice set of instructions on how
to do this, i wish i could remember where i found them. uggghhh!

On 05/27/2018 01:03 PM, Chad Parker wrote:
> Regarding #1:
>
> It looks like pcb should be keeping track of three different
> directories: a layout dir, an element dir, and a netlist dir. So, the
> first time you load any of these three things, the path should be your
> working directory, probably home if you are launching through a gui. The
> second time you load a layout, it should open pointing at the same
> directory your current layout is in. The second time you load a netlist,
> it should open pointing to the same directory your current netlist is
> in. And ditto for elements.
>
> Can you confirm this behavior?
>
> If you were to launch pcb from a terminal in which the current directory
> were the directory of your layout, then that directory would be the
> working directory, and the dialogs should open pointing there.
>
> One way to perhaps make this a little kinder would be to use the "layout
> dir" as a fallback for the netlist dir or element dir if they aren't set
> yet. However, I can conceive of instances in which this would be
> undesirable. For example, if a user keeps their footprint library in
> $HOME/lib/pcb/footprints , then it would be more convenient to have the
> opening directory be your home directory.
>
> So, perhaps opening netlists should use the layout directory but loading
> elements should not?
>

[Dr M (drmcn)]

success, this time i did it by using emacs and the file format
information in the pcb document.

the error messages in the log window still leave a lot to be desired.
as a conjecture, i wonder if scheme is really the best choice of
scripting language for this.  python could make life a lot easier.  it
can conveniently give you exactly the point where it failed.

On 05/27/2018 02:31 PM, Dr M C Nelson wrote:
> man! i'm creating yet another smt footprint, and once again looking up
> how to do it.  this is by far the most tedious part of working with
> any layout program.  there used to be a very nice set of instructions
> on how to do this, i wish i could remember where i found them. uggghhh!
>
>
> On 05/27/2018 01:03 PM, Chad Parker wrote:
>> Regarding #1:
>>
>> It looks like pcb should be keeping track of three different
>> directories: a layout dir, an element dir, and a netlist dir. So, the
>> first time you load any of these three things, the path should be your
>> working directory, probably home if you are launching through a gui. The
>> second time you load a layout, it should open pointing at the same
>> directory your current layout is in. The second time you load a netlist,
>> it should open pointing to the same directory your current netlist is
>> in. And ditto for elements.
>>
>> Can you confirm this behavior?
>>
>> If you were to launch pcb from a terminal in which the current directory
>> were the directory of your layout, then that directory would be the
>> working directory, and the dialogs should open pointing there.
>>
>> One way to perhaps make this a little kinder would be to use the "layout
>> dir" as a fallback for the netlist dir or element dir if they aren't set
>> yet. However, I can conceive of instances in which this would be
>> undesirable. For example, if a user keeps their footprint library in
>> $HOME/lib/pcb/footprints , then it would be more convenient to have the
>> opening directory be your home directory.
>>
>> So, perhaps opening netlists should use the layout directory but loading
>> elements should not?
>>
>

[Chad Parker (parker-charles)]

pcb doesn't use scheme. I would love to get python into pcb, but this is not an easy task.

[Dr M (drmcn)]

I can confirm that it had no default when it opens the netlist file.
The default should be the same directory as the pcb file.

On 05/27/2018 01:03 PM, Chad Parker wrote:
> Regarding #1:
>
> It looks like pcb should be keeping track of three different
> directories: a layout dir, an element dir, and a netlist dir. So, the
> first time you load any of these three things, the path should be your
> working directory, probably home if you are launching through a gui. The
> second time you load a layout, it should open pointing at the same
> directory your current layout is in. The second time you load a netlist,
> it should open pointing to the same directory your current netlist is
> in. And ditto for elements.
>
> Can you confirm this behavior?
>
> If you were to launch pcb from a terminal in which the current directory
> were the directory of your layout, then that directory would be the
> working directory, and the dialogs should open pointing there.
>
> One way to perhaps make this a little kinder would be to use the "layout
> dir" as a fallback for the netlist dir or element dir if they aren't set
> yet. However, I can conceive of instances in which this would be
> undesirable. For example, if a user keeps their footprint library in
> $HOME/lib/pcb/footprints , then it would be more convenient to have the
> opening directory be your home directory.
>
> So, perhaps opening netlists should use the layout directory but loading
> elements should not?
>

[Dr M (drmcn)]

Same thing for layout.  It should be opening the dialogue in the same
directory as the pcb, and instead it seems to open the user's home
directory.

On 05/27/2018 01:03 PM, Chad Parker wrote:
> Regarding #1:
>
> It looks like pcb should be keeping track of three different
> directories: a layout dir, an element dir, and a netlist dir. So, the
> first time you load any of these three things, the path should be your
> working directory, probably home if you are launching through a gui. The
> second time you load a layout, it should open pointing at the same
> directory your current layout is in. The second time you load a netlist,
> it should open pointing to the same directory your current netlist is
> in. And ditto for elements.
>
> Can you confirm this behavior?
>
> If you were to launch pcb from a terminal in which the current directory
> were the directory of your layout, then that directory would be the
> working directory, and the dialogs should open pointing there.
>
> One way to perhaps make this a little kinder would be to use the "layout
> dir" as a fallback for the netlist dir or element dir if they aren't set
> yet. However, I can conceive of instances in which this would be
> undesirable. For example, if a user keeps their footprint library in
> $HOME/lib/pcb/footprints , then it would be more convenient to have the
> opening directory be your home directory.
>
> So, perhaps opening netlists should use the layout directory but loading
> elements should not?
>

[Chad Parker (parker-charles)]

How are you executing pcb? Are you clicking on a .pcb file and your window manager is opening the file in pcb, are you running pcb from some kind of applications menu, and then browsing to your .pcb file, or are you launching pcb from the command line?

[Dr M (drmcn)]

Generally, I run the program from a context menu,  or double click on
the file.  Sometime ealier, I did that and after browsing to the private
build, set it as the default.

On 06/01/2018 02:29 PM, Chad Parker wrote:
> How are you executing pcb? Are you clicking on a .pcb file and your
> window manager is opening the file in pcb, are you running pcb from some
> kind of applications menu, and then browsing to your .pcb file, or are
> you launching pcb from the command line?
>

[Dr M (drmcn)]

P/S, I recall the same behavior in the "stock version" that came from
the Fedora repository

On 06/01/2018 02:29 PM, Chad Parker wrote:
> How are you executing pcb? Are you clicking on a .pcb file and your
> window manager is opening the file in pcb, are you running pcb from some
> kind of applications menu, and then browsing to your .pcb file, or are
> you launching pcb from the command line?
>

[Chad Parker (parker-charles)]

Why don't you give branch LP1773409 a try.

[Dr M (drmcn)]

Okay, will look for it.

On 06/01/2018 03:10 PM, Chad Parker wrote:
> Why don't you give branch LP1773409 a try.
>

[Dr M (drmcn)]

Can you send me a url to it?  Thanks

On 06/01/2018 03:10 PM, Chad Parker wrote:
> Why don't you give branch LP1773409 a try.
>

[Chad Parker (parker-charles)]

There isn't really a url. It's a branch in the git repository. You'd have to check it out.

cd <pcb_source_tree>
git checkout LP1773409
make
./src/pcbtest.sh

[Dr M (drmcn)]

oh right. of course,  i recall getting the first tree as a zip from the
web site.

On 06/01/2018 04:45 PM, Chad Parker wrote:
> There isn't really a url. It's a branch in the git repository. You'd
> have to check it out.
>
> cd <pcb_source_tree>
> git checkout LP1773409
> make
> ./src/pcbtest.sh
>

[Dr M (drmcn)]

Hi

That didn't work, I forget what the error text was exactly, but it was
along the lines of not recognizing the branch.   Then I tried a pull,
and that worked but it did not compile, the errors are as listed below.
It seems like it has some conflict about which version of automake it
wants to use.  All of the required programs are installed and up to
date.   After that I tried the pull again, and it seemed to work, it
printed a message that it was now working in that branch, but produces
the same compilation errors.

  cd .. && /bin/sh /home/nelson/Utilities/pcb/missing automake-1.15
--foreign tests/Makefile
configure.ac:6: error: version mismatch.  This is Automake 1.15.1,
configure.ac:6: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:6: comes from Automake 1.15.  You should recreate
configure.ac:6: aclocal.m4 with aclocal and run automake again.
WARNING: 'automake-1.15' is probably too old.
          You should only need it if you modified 'Makefile.am' or
          'configure.ac' or m4 files included by 'configure.ac'.
          The 'automake' program is part of the GNU Automake package:
          <http://www.gnu.org/software/automake>
          It also requires GNU Autoconf, GNU m4 and Perl in order to run:
          <http://www.gnu.org/software/autoconf>
          <http://www.gnu.org/software/m4/>
          <http://www.perl.org/>
make[2]: *** [Makefile:743: Makefile.in] Error 63
make[2]: Leaving directory '/home/nelson/Utilities/pcb/tests'
make[1]: *** [Makefile:535: all-recursive] Error 1
make[1]: Leaving directory '/home/nelson/Utilities/pcb'
make: *** [Makefile:474: all] Error 2

On 06/01/2018 04:45 PM, Chad Parker wrote:
> There isn't really a url. It's a branch in the git repository. You'd
> have to check it out.
>
> cd <pcb_source_tree>
> git checkout LP1773409
> make
> ./src/pcbtest.sh
>

[Dr M (drmcn)]

re-ran the entire sequence, autogen, configure, and make,  and it
compiled okay. then ran pcbtest.sh, it seemed okay, and so i repeated
from configure --prefix=<mygeda>, through make install.   it runs, opens
the pcb file, and then opens the file dialog for the netlist in the same
directory.   will let you know if i see anything that needs to be
reported.  thank you

On 06/03/2018 07:16 PM, Dr M C Nelson wrote:
> Hi
>
> That didn't work, I forget what the error text was exactly, but it was
> along the lines of not recognizing the branch.   Then I tried a pull,
> and that worked but it did not compile, the errors are as listed
> below.  It seems like it has some conflict about which version of
> automake it wants to use.  All of the required programs are installed
> and up to date.   After that I tried the pull again, and it seemed to
> work, it printed a message that it was now working in that branch, but
> produces the same compilation errors.
>
>  cd .. && /bin/sh /home/nelson/Utilities/pcb/missing automake-1.15
> --foreign tests/Makefile
> configure.ac:6: error: version mismatch.  This is Automake 1.15.1,
> configure.ac:6: but the definition used by this AM_INIT_AUTOMAKE
> configure.ac:6: comes from Automake 1.15.  You should recreate
> configure.ac:6: aclocal.m4 with aclocal and run automake again.
> WARNING: 'automake-1.15' is probably too old.
>          You should only need it if you modified 'Makefile.am' or
>          'configure.ac' or m4 files included by 'configure.ac'.
>          The 'automake' program is part of the GNU Automake package:
>          <http://www.gnu.org/software/automake>
>          It also requires GNU Autoconf, GNU m4 and Perl in order to run:
>          <http://www.gnu.org/software/autoconf>
>          <http://www.gnu.org/software/m4/>
>          <http://www.perl.org/>
> make[2]: *** [Makefile:743: Makefile.in] Error 63
> make[2]: Leaving directory '/home/nelson/Utilities/pcb/tests'
> make[1]: *** [Makefile:535: all-recursive] Error 1
> make[1]: Leaving directory '/home/nelson/Utilities/pcb'
> make: *** [Makefile:474: all] Error 2
>
>
> On 06/01/2018 04:45 PM, Chad Parker wrote:
>> There isn't really a url. It's a branch in the git repository. You'd
>> have to check it out.
>>
>> cd <pcb_source_tree>
>> git checkout LP1773409
>> make
>> ./src/pcbtest.sh
>>
>

[Chad Parker (parker-charles)]

Let's jump back to this thread for discussion on gsch2pcb.

Okay, so, the sequence of events as I understand it goes as follows:

1. create a schematic
2. run gsch2pcb
3. open layout and start editing
4. make changes to the schematic
5. run gsch2pcb
6. you get a message in pcb saying the file on disk has changed, and you reload it to get your schematic updates.
7. your layout edits are wiped out because they only existed in memory

It seems like one way to address this would be to add a warning message when changes are detected if the current layout is modified. Maybe a confirmation dialog. This is something we really should have anyway. Do you think that would have prevented your situation?

On Sun, Jun 10, 2018 at 3:35 PM, Dr M <email address hidden> wrote:
on the file management thing, with gsch2pcb overwriting my design, i
think that occurred when i had unsaved changes in the pcb editing
session, and so it was really my fault. pcb and emacs know when a file
has been changed while they have it open, and i still both together for
some more complicated situations, so a lock file that gsch2pcb would see
when the file is open by pcb might be a solution, but it would be
inconvenient to also lock-out the editor that i sometimes keep open in
parallel,

[Dr M (drmcn)]

That sounds like a good idea. The message dialogue needs to be very clear.
Seems the user should then save their work and rerun gsch2pcb.

On Sun, Jun 10, 2018, 4:10 PM Chad Parker <email address hidden> wrote:

> Let's jump back to this thread for discussion on gsch2pcb.
>
> Okay, so, the sequence of events as I understand it goes as follows:
>
> 1. create a schematic
> 2. run gsch2pcb
> 3. open layout and start editing
> 4. make changes to the schematic
> 5. run gsch2pcb
> 6. you get a message in pcb saying the file on disk has changed, and you
> reload it to get your schematic updates.
> 7. your layout edits are wiped out because they only existed in memory
>
> It seems like one way to address this would be to add a warning message
> when changes are detected if the current layout is modified. Maybe a
> confirmation dialog. This is something we really should have anyway. Do
> you think that would have prevented your situation?
>
>
> On Sun, Jun 10, 2018 at 3:35 PM, Dr M <email address hidden> wrote:
> on the file management thing, with gsch2pcb overwriting my design, i
> think that occurred when i had unsaved changes in the pcb editing
> session, and so it was really my fault. pcb and emacs know when a file
> has been changed while they have it open, and i still both together for
> some more complicated situations, so a lock file that gsch2pcb would see
> when the file is open by pcb might be a solution, but it would be
> inconvenient to also lock-out the editor that i sometimes keep open in
> parallel,
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1773409
>
> Title:
> File operations, bugs and change requests
>
> Status in pcb:
> In Progress
>
> Bug description:
> There are several issues in the dialogues and actions under the file
> menu.
>
> 1) The dialogue to load layout or net file should open in the same
> directory as the already open pcb file. I spend a lot of time
> repeatedly navigating back to my work directory from this dialogue.
>
> 2) The gsch2pcb or load layout item, I figure which, where it should
> have simply changed one foot print, instead reinitialized the pcb
> file, trashing my layout and causing a loss of about one hour of work.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/pcb/+bug/1773409/+subscriptions
>

[Dr M (drmcn)]

Fantastic, can't wait to try it.

On 07/31/2018 08:21 PM, Chad Parker wrote:
> ** Changed in: pcb
> Status: In Progress => Fix Committed
>