Re: [lmi] Allow switching skin while lmi is running

[Greg Chicares]

On 2016-06-01 22:29, Vadim Zeitlin wrote:
> On Wed, 1 Jun 2016 22:17:21 +0000 Greg Chicares <address@hidden> wrote:
[...editing default_input_filename_ in a wxFilePickerCtrl...]
> GC> > 
> GC> > [...] I'm pretty sure we want wxFLP_FILE_MUST_EXIST
> GC> 
> GC> Now I'm not so sure.
> 
>  I still think this flag should be used, but perhaps it should be possible
> to leave the field empty if you just have no appropriate candidate file at
> all.

Then what should be the behavior of a system built from the public
repository only--say, by someone unknown to us who might want to use
lmi? The builtin default is "/etc/opt/lmi/default.ill", which in that
case will not exist. I'd like something appropriate to happen, with no
annoying warning.

> GC> At first, it seemed silly to name a file that
> GC> doesn't exist. OTOH, I usually run lmi with no default input file.
> GC> Today, I simply leave 'default_input_file' pointing by default to
> GC> a file that doesn't exist on my machine, and default_cell() does
> GC> the right thing for me:
> GC> 
> GC>   static Input const builtin_default;
> GC>   if(0 != access(default_input_file.c_str(), F_OK))
> GC>       {
> GC>       user_default = builtin_default;
> GC>       }
> 
>  Would it be conceivable to modify this code to skip calling access() if
> default_input_file is empty?

- if(0 != access(default_input_file.c_str(), F_OK))
+ if(default_input_file.empty() || 0 != access(default_input_file.c_str(), 
F_OK))

Sure, but may I ask why? POSIX says access() returns -1 and sets errno
to ENOENT in that case. Are you concerned about non-POSIX behavior on
some OS like msw? Or is this intended as a speed optimization (which I
would expect to save few if any cycles)?

> GC> And that file would have to be a valid '.ill' file, or the catch clause
> GC> in default_cell() would remove it:
> GC> 
> GC>   catch(...)
> GC>       {
> GC>       if(0 == std::remove(default_input_file.c_str()))
> ...
> GC> Maybe deletion is a mistake.
> 
>  It certainly seems so to me. IMO deleting files should never be done
> without an explicit user confirmation and while I can accept that lmi does
> it for its own _output_ files, it still seems very wrong to do it for the
> input ones.

I keep wondering why I would ever have done this. My hypothesis:
historically (and even unto today in production) the only way to
change this file name has been to edit the xml by hand; so, when
I was testing it, I probably edited the '.ill' by hand, and found
that hand editing can produce an invalid file, which causes a
warning every time the system is started. Deletion prevented that
warning from occurring. In retrospect, it's not a good reason.