[Gretl-devel] 'include' w/o 'open' -- new behavior

Sven Schreiber svetosch at gmx.net
Sat Dec 22 11:10:43 EST 2007


Am 22.12.2007 16:00, Allin Cottrell schrieb:
> On Sat, 22 Dec 2007, Riccardo (Jack) Lucchetti wrote:
> 
>> IMO both Allin and Sven make valid points. I agree with Sven 
>> that the concept of the userdir is not useful if you prefer, as 
>> I do, to organise your files into nicely separate subtrees. But 
>> I've never had a problem with "./" in my scripts (I don't know 
>> what happens with Windows, though).
> 
> I think that CWD and "./" work just fine if you're launching gretl 
> from, e.g., the bash prompt in an xterm (as I do).  You know what 
> the initial CWD is, and can pre-set it easily by cd'ing to your 
> project directory.  On the other hand, I accept that it's of 
> questionable usefulness on Windows, where most users won't know 
> what the CWD is when they launch gretl (and won't even have any 
> means of finding out, short of typing "set" in the gretl console).

Exactly. For example, for my current setup it seems to be 
"e:\iwonttellyouthepath" but I don't have any idea where that comes from 
or how to change the corresponding windows setting. (It's _not_ in the 
gretl preferences, and it's _not_ the current setting for "My 
Documents"; however, it could be that some months ago it _used to_ to 
the setting for "My Documents" -- so maybe some stale registry or ini 
setting?)


> I'd really rather not get into that if possible.  But here's an 
> idea (based on what you've suggested):
> 
> 1. Let's think of what we presently call "userdir" as gretl's 
> "private" data directory.  On Windows, we needn't offer a choice 
> of this directory on installation; we can just automatically use 
> USERAPPDATADIR/gretl (the current default).  On other platforms we 
> can continue to default to ~/gretl (perhaps ~/.gretl would be more 
> appropriate but that has compatibility issues).

Yes, I guess that's more or less what I had in mind with %AppData% in 
the email I just sent before I noticed yours.

> 
> 2. We add the concept of a user's "working directory" based on the 
> present value of "currdir".  We can save this between sessions 
> (which we currently don't).  We won't write any "internal" files 
> to this directory, but we'll make it the default for explicit 
> file open/save, for shell commands, and so on.

Sounds great!

> 
> 3. That leaves the question of what the "working directory" should 
> default to on first-time installation, i.e. before "currdir" has 
> been set.  Here are some options:
> 
> On Windows: the Desktop, MYDOCUMENTS, MYDOCUMENTS/gretl, ??

I don't care much because I would change it right away anyway, but <the 
localized/generalized version of> MYDOCUMENTS immediately comes to (my) 
mind.

> On Linux: the CWD, HOME, HOME/gretl, ??

HOME for the same reason.

> 
> We could prompt for this on a first-time Windows install, but I 
> think that's likely to be confusing since the user probably won't 
> really know what's being asked at that point.

And as I said, a global setting for all users doesn't make much sense 
IMHO. And it's not necessary, since the first open/save operation will 
take care of it.

> 
> 4. One more loose end: should the working dir be explicitly 
> settable, or should it always just be set implicitly by data or 
> script file open operations?  Maybe we should offer something like
> 
> [] Always start in directory: _____________
> 
> That is, a check box plus a directory slot that is enabled if the 
> box is checked.  (Rationale: a user might sometimes want to open a 
> data file or script from some neutral location such as the 
> Desktop, without thereby switching the working directory to that 
> location.)

For backwards-compatibility I guess the current concept of userdir 
should be preserved if possible. (So maybe even should retain that name, 
and what you suggested as the new use of userdir should be called 
something else.) So yes, it should be settable IMHO.

Thanks again very much for the open-mindedness to new ideas and criticisms!

cheers,
sven


More information about the Gretl-devel mailing list