Re: [lmi] [PATCH] Accept command line arguments in lmi_wx

[Vadim Zeitlin]

On Sun, 08 Mar 2015 00:30:53 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2015-02-15 18:46, Vadim Zeitlin wrote:
GC> > 
GC> >  While testing the performance of different operations with a big census, 
I
GC> > got annoyed by the fact that I had to open the one and same census file
GC> > each time over and over again from the GUI (even if it's as simple as
GC> > pressing Alt+F,1 -- arguably, I get annoyed too easily)
GC> 
GC> That's what I do.

 I did too, and it's definitely fine for a few times, but if you do this 10
or 20 times in a row (and I ran the benchmarks when optimizing the census
view many times more than that), it becomes annoying, especially because
it's unnecessary manual action that can be automated.

GC> I'm not averse to adding this sort of facility to lmi. I have two
GC> minor, interrelated objections to this particular way of doing it:
GC> 
GC> (1) The original "Unrecognized parameters" diagnostic seems useful,
GC> and I hesitate to lose it.

 This is actually a bug in my patch, thanks for noticing it. Giving a
parameter that can't be opened as a normal input file should result in an
error message and it even does, actually, but I instinctively used
wxLogError() for it and so the end user never saw it as the error was only
displayed on stderr. This reminds me that I never made the patch that I
promised to do "soon" 3 months ago (see
http://lists.nongnu.org/archive/html/lmi/2014-12/msg00011.html) which would
have avoided this problem, so I'm going to try to do it "really soon now".
But in the meanwhile the updated version of the patch uses warning()
instead of wxLogError() and so does result in an error message without any
further changes.

GC> (2) It's inconsistent with the way file names are handled by the
GC> command-line 'lmi_cli*' binary. The difference is perhaps arbitrary
GC> between
GC>   lmi_wx file0 file1
GC> in this patch versus
GC>   lmi_cli -f file0 --file=file1
GC> in 'lmi_cli*' today; but we want consistency, and I tend to prefer
GC> the latter for lmi.

 Yes, consistency is definitely important. If lmi_cli behaviour could be
changed, I think it would be the best from the consistency point of view as
not only would it make the behaviour of CLI and GUI programs consistent
with each other, but it would also make them both consistent with the other
programs (unfortunate exceptions such as dd(1) aside...). But if, as I
suspect, it can't, the attached patch should be the next best solution.

GC> Or of course you could just maintain a private patch.

 In principle, I could do it, of course, but I still believe that running a
document-oriented application with an input file is so standard that it's
just strange to not have this functionality in the official version (even
though using "--file" option for it instead of positional parameter makes
it less standard and so less useful from this point of view). And, of
course, not having yet another local patch to apply/merge does make things
a bit simpler for me as well.

 So if you don't see any problems with the attached patch, I'd be grateful
if you could still apply it, please.

 Thanks in advance,
VZ

0001-Add-file-command-line-option-to-the-GUI-program-too.patch
Description: Text document