Re: [lmi] wx update; pending specification changes

[Vadim Zeitlin]

On Sat, 06 Dec 2014 11:38:51 +0000 Greg Chicares <address@hidden> wrote:

GC> > Me> [...] whether you apply the above patch or not
GC> 
GC> I'm deliberately deferring it in order to focus on 'wx_test' for now.

 The trouble is that I risk having merge conflicts with this patch when I
do the other changes to the test (e.g. cleanup ones). I will, of course, be
able to resolve it -- using Git gives me confidence to perform merges I
would never dream of doing with svn, and this is by far not the worst of
them -- but it would be even better to not have to do it at all.

 I also wonder about the other test-related patches I am working on (or
planned to start soon), notably the "test cleanup" patch which adds
removing of the temporary files and the preservation of configurable
settings file and recently open files history and also the one adding
"--gui_test_path" command line option. Without speaking about moving the
"Test" menu contents into the automated tests, which I didn't start yet,
but was planning to do next. I can work on several things at once, but I'm
afraid I start having a bit too many balls in the air to handle all of them
efficiently...


GC> I'll also mention a difference I noticed when running 'wx_test' with this
GC> wx update. There's some test that opens the preferences dialog and changes
GC> its fields. It seems "busier" now: my impression is that it cycles through
GC> every combobox item now, whereas previously it just changed the selection
GC> once in each combobox. Of course, it could be that what's happening in the
GC> comboboxes hasn't changed, but the way wx updates the screen has.

 Yes, I didn't want to mention this to cut down on not strictly necessary
email, but what happens is that wxYield(), used now, actually updates the
combobox after each key press, whereas before, with the emulated events,
this didn't happen. FWIW this is an example of something that could
conceivably behave differently in the old test and the real application as
any event handlers reacting to the selection change wouldn't have been
called in the former unlike in the latter (and even though in practice
there are no such handlers now, it would be an annoying problem to debug if
any were added later).

 In short, the new behaviour is expected and, in some sense, more correct.

GC> Kim and I have already reviewed several of the automated GUI tests, and
GC> I'm writing specifications that explain what we really want them to do.
GC> Soon I'll commit a modified 'wx_test_about_version.cpp' with a comment
GC> block indicating the desired behavior. It won't actually describe the code
GC> it precedes, yet; please take is as our request to change the code so that
GC> it does what the comment says.

 Working on it.

GC> If that process suits you, I'll commit similar changes to the thirteen
GC> other 'wx_test*.cpp' files. Or, if you prefer, I could copy the comment
GC> block of each file here as we modify it, to start a discussion thread.

 This would be even better for me, as I will almost certainly have
questions about less trivial tests. And while on the surface it might seem
that it would be more work for you, I'm not even sure about this, as I
could just include the comment in my patch implementing the requested
behaviour, so AFAICS it just replaces writing the comment with writing an
email for you, which shouldn't be materially different. So, if possible,
I'd prefer to start with emails.

 TIA,
VZ