[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gEDA: Big changes to RC file system



On Thu, Jan 27, 2005 at 07:19:30AM -0500, Stuart Brorson wrote:

> 6.  read /foo/bar/gafrc while sitting in the directory /foo/bar.  This
>     takes care of all the guile search path problems, like when people put
>     things like (component-library "../common/symlib") or some such into
>     their RC files.
> 7.  After that, read the file itself.

What happens if my local RCs do more than just modify the search path?
Suppose then that I have one schematic open, and I open another one in a
different directory.  Now, an apparently innocuous action -- opening a
schematic -- has non-local consequences, as my first schematic starts
behaving oddly.

> 8.  Leave the directory to this directory.  This is good because the
>     user expects that the next time he tries to open a schematic, the
>     program will start in the last directory visited.  (I hate the Windoze
>     behavior -- common for may MS apps -- where the filebrowser always
>     starts at "My Documents", even if you had to browse ten levels deep
>     into a networked server the last time you needed to open a doc.)

Can't we resolve all of these problems by simply chdir(2)ing into the
directory whenever we open a schematic?  This way, relative paths will
continue to work, and, say, an RC with key bindings will not affect
already-open windows.

Actually, we'd probably want to chdir whenever we switch schematics.

> The reason I use absolute paths everywhere is so that the program's
> operation becomes independent of which particular directory you are
> sitting in at any time. 

Right, so we associate a current working directory with a schematic, not
with where the program was started with.

Absolute paths are evil.

> Now, use the file browser to open ../B/b.sch.  The schematic b.sch
> will be missing the symbol b_sym.sym.  This is because as currently
> run, gschem never opens and reads ../B/gafrc, so it doesn't know about
> ../B/sym/b_sym.sym.

Like I said, chdir should solve this.

> I have seen several different people complain about gEDA/gaf being
> misconfigured [1], and I suspect that this is the problem. 
> Most newbies think they can use the file browser to browse to a new
> schematic and open it up.  When they try it, however, the schematics
> they view appear broken if they have locally defined components.

As opposed to newbies (or even experienced users!) who open a schematic,
open another one, go back to the first one, and are unable to add
components because their library path got mangled?

I'd put my fist through the monitor if this happened.

Like I've said before, add this if people want it, but please make it
possible to turn it off via an RC setting.

Alternately, and this is more complex to implement, keep a set of
settings associated with each schematic, and swap them in whenever we
switch schematics.  This means that if proj_a/gafrc sets the background
colour to black, and proj_b/gafrc sets it to white, I'll get a black
background whenever I'm looking at proj_a, and a white one when I'm
looking at proj_b.

-- 
Luke Stras <stras@utias.toronto.edu>
"The meek can have the Earth; the rest of us have other plans" 
  --Henry Spencer