Re: [lmi] Using picker controls for paths

[Greg Chicares]

On 2016-06-04 15:40, Vadim Zeitlin wrote:
> On Wed, 1 Jun 2016 17:54:43 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> but I'm not sure exactly how, say, GetPath() and GetFileName() differ.)
> 
>  They only differ by the type of their return value, the first one returns
> a string while the second one returns a wxFileName (~~ boost::path) object.
> 
>  Actually the first version of my patch uses SetFileName() with the
> following comment:
> 
>         if(td == from_string_to_control)
>             {
>             // Use SetFileName() here instead of SetPath() directly in order 
> to
>             // format the path correctly, e.g. use more usual backslashes 
> under
>             // MSW even if the path is stored using slashes in the
>             // configuration file.
>             control.SetFileName(wxFileName(data));
>             }
>         else
>             {
>             // Use just GetPath() here because we want to store the path
>             // exactly as the user entered it.
>             data = control.GetPath().ToStdString();
>             }
> 
> I.e. the idea was that the default path "C:/etc/opt/lmi/default.ill" would
> be shown to the user as more usual "C:\etc\opt\lmi\default.ill". And this
> worked without any problem until I started using the directory picker for
> the print directory as well. At which point I started getting warnings
> about "Contents of more than one control changed" whenever the preferences
> dialog was opened because both the file and directory pickets were changed
> due to the normalization performed by SetFileName()/SetDirName()
> respectively.
> 
>  I didn't see any simple way to avoid this warning, so, finally, I've just
> abandoned the idea of normalizing the paths when showing them and the final
> version simply shows them as they're, which works. Maybe you don't consider
> normalizing the paths be a good idea anyhow, of course, but if you do, I
> could try looking more into making this work without disabling/removing the
> check for the number of changes controls in MvcController::UponUpdateUI().
> Should I do this?

[I retained an unusually large chunk of context above so that we don't have
to look up old emails.] I originally interpreted this as suggesting that
only forward slashes would be used, everywhere. What I observe is slightly
different. I start with this forward-slash path in 'configurable_settings.xml'
(which is now read from /opt/lmi/data/ because that's the location specified
by '--data_path', thanks):

/opt/lmi/bin[1]$grep print_dir ../data/configurable_settings.xml
  <print_directory>C:/opt/lmi/bin</print_directory>

Now I run lmi in the background, changing the path...
 - by typing nonexistent directory 'C:/opt/lmi/bdata'
 - by using the dirpicker GUI to select opt|lmi|data
and grep the xml for the directory as above...

/opt/lmi/bin[0]$./lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data &
[1] 1320
/opt/lmi/bin[0]$grep print_dir ../data/configurable_settings.xml
  <print_directory>C:\opt\lmi\bdata</print_directory>
/opt/lmi/bin[0]$grep print_dir ../data/configurable_settings.xml
  <print_directory>C:\opt\lmi\data</print_directory>

...and my forward slashes are changed to backward.

I don't know for sure whether that change might lead to a grave problem
like inability to read a file, but I really would like to keep forward
slashes everywhere and always. It looks really strange in the GUI when
I change only one of these controls:
      Input defaults [C:/etc/opt/lmi/default.ill]  <-- FORWARD
  Printout directory [C:\opt\lmi\data]             <-- BACKWARD

Curiously, if I exit and reload lmi, I see only forward slashes in
both GUI fields, though the xml file contains backslashes.

Can we just have forward slashes, everywhere and always?

>  In addition to this, there are two minor cosmetic issues with the dialog
[...snip the first...]
>  The second point is worse, although it only appears when themes are
> enabled, meaning that you won't see it by default. However most (all?)
> users will and if you enable themes, you can see that the background
> between the pickers text and button is grey and not the same white as the
> notebook background around them. I'm not sure why does this happen yet, but
> I'm almost certain it's a bug in wxMSW. And this means that it can only be
> fixed in wxMSW itself. However a possible workaround in lmi could would be
> to explicitly set the pickers background to white, and, to ensure that this
> looks correctly in all themes and not just the default one, also set the
> white background for the panel itself. This is not ideal because it still
> will override the theme chosen by the user and will look strange when
> themes are disabled, so I'd prefer to fix this in wxMSW itself -- but even
> if I manage to do it, this would require updating the version of wxWidgets
> used by lmi once again.

Again I preserve full context in case it's useful, but...neither Kim nor I
can see this. I was going to try setting a theme here, but I'm currently
using "Windows Classic (modified)" and am afraid of losing my forgotten
but careful modifications, and this msw-xp VM is not at all like what end
users have anyway. In theory, I might try it on my corporate laptop, but
it's locked down so I can't run lmi (or even browse this mailing list).
Anyway, you've described what you see in enough detail, but it just doesn't
seem to happen in our end users' world.

> GC> Could I also ask you to opine on the "TODO ??" markers in transferor.cpp',
> 
>  I'll do this next but I wanted to post this quickly to let you know about
> the new PR.

I think I'll just go ahead and resolve all of them except the one
concerning wxControlWithItems and wxItemContainerImmutable.