Re: [lmi] Using picker controls for paths

[Greg Chicares]

On 2016-06-07 20:35, Vadim Zeitlin wrote:
> On Tue, 7 Jun 2016 20:18:13 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2016-06-04 15:40, Vadim Zeitlin wrote:
[...]
> GC> Now I run lmi in the background, changing the path...
> GC>  - by typing nonexistent directory 'C:/opt/lmi/bdata'
> GC>  - by using the dirpicker GUI to select opt|lmi|data
> GC> and grep the xml for the directory as above...
> GC> 
> GC> /opt/lmi/bin[0]$./lmi_wx_shared --ash_nazg --data_path=/opt/lmi/data &
> GC> [1] 1320
> GC> /opt/lmi/bin[0]$grep print_dir ../data/configurable_settings.xml
> GC>   <print_directory>C:\opt\lmi\bdata</print_directory>
> GC> /opt/lmi/bin[0]$grep print_dir ../data/configurable_settings.xml
> GC>   <print_directory>C:\opt\lmi\data</print_directory>
> GC> 
> GC> ...and my forward slashes are changed to backward.
> 
>  Yes, this is the (currently) expected behaviour.

Oh.

> GC> I don't know for sure whether that change might lead to a grave problem
> GC> like inability to read a file,
> 
>  I really don't think so. If anything, using forward slashes might as
> they're "foreign" under MSW and, annoyingly, a few native functions do no
> support them -- while most of the rest of them do. Backslash is the native
> path separator, so I don't see how could using it result in any problems.

OTOH, I strive always to use forward slashes, and I might write a shell
script that extracts a path from an xml file and then tries to cd to
that path. I'd probably be mindful enough to drop the "c:", but the
backslashes could cause me grief, so I'd rather avoid them in xml at
least.

> GC> but I really would like to keep forward slashes everywhere and always.
> GC> It looks really strange in the GUI when
> GC> I change only one of these controls:
> GC>       Input defaults [C:/etc/opt/lmi/default.ill]  <-- FORWARD
> GC>   Printout directory [C:\opt\lmi\data]             <-- BACKWARD
> 
>  Yes, I agree with this. I still think the best solution is to consistently
> use backslashes rather than [forward] slashes under MSW, but it's better to
> consistently use either one of them rather than mixing both.

Discussed below.

> GC> Curiously, if I exit and reload lmi, I see only forward slashes in
> GC> both GUI fields, though the xml file contains backslashes.
> 
>  This is a side effect of using fs::system_complete() in
> configurable_settings ctor. FWIW I wouldn't be surprised if newer version
> of Boost.Filesystem didn't behave in this way, it looks wrong to me to
> change the path separators, especially for an already absolute path.

Agreed.

> GC> Can we just have forward slashes, everywhere and always?
> 
>  I could try to do it, but personally I still think that it would be more
> correct to use backslashes in the UI. We could, however, use slashes in the
> XML file. Maybe this would be a good enough compromise?

Good: backslashes everywhere in the GUI, forward in the xml.
Could you prepare something I could 'git am' please?

> GC> >  In addition to this, there are two minor cosmetic issues with the 
> dialog
> GC> [...snip the first...]
> GC> >  The second point is worse, although it only appears when themes are
> GC> > enabled, meaning that you won't see it by default. However most (all?)
> GC> > users will and if you enable themes, you can see that the background
> GC> > between the pickers text and button is grey and not the same white as 
> the
> GC> > notebook background around them. I'm not sure why does this happen yet, 
> but
> GC> > I'm almost certain it's a bug in wxMSW. And this means that it can only 
> be
> GC> > fixed in wxMSW itself. However a possible workaround in lmi could would 
> be
> GC> > to explicitly set the pickers background to white, and, to ensure that 
> this
> GC> > looks correctly in all themes and not just the default one, also set the
> GC> > white background for the panel itself. This is not ideal because it 
> still
> GC> > will override the theme chosen by the user and will look strange when
> GC> > themes are disabled, so I'd prefer to fix this in wxMSW itself -- but 
> even
> GC> > if I manage to do it, this would require updating the version of 
> wxWidgets
> GC> > used by lmi once again.
> GC> 
> GC> Again I preserve full context in case it's useful, but...neither Kim nor I
> GC> can see this.
> 
>  This is very strange because it's 100% reproducible under Windows 7 with
> the default theme and I'm pretty sure it should be reproducible under
> Windows XP as well. I didn't test this under Windows 10 yet, but I'm
> relatively confident that this should happen there as well.
> 
> GC> I was going to try setting a theme here, but I'm currently
> GC> using "Windows Classic (modified)" and am afraid of losing my forgotten
> GC> but careful modifications

Since you are quite sure there's something anomalous, I made a throwaway
clone of my VM and am trying to change the theme there. Perhaps I've
failed, because I'm looking for this:

| GC> > if you enable themes, you can see that the background
| GC> > between the pickers text and button is grey and not the same white as 
the
| GC> > notebook background around them.

and I can't see it. It looks just like the screenshots I emailed you
privately earlier today.

Here's what I did:
  Start | Settings | Control Panel | Display
On the "Themes" tab, I had "Windows Classic (modified)", and the only other
options are
  My Current Theme
  Windows Classic
I don't know why "My Current Theme" would differ from my current theme, but
I switched to it, got "Please Wait" for a second or two, and then--everything
still looked the same.

I tried "Browse..." but that found nothing.

I tried "More themes online..." but...

  http://www.microsoft.com/windows/plus/screensavers.asp
| Your current User-Agent string appears to be from an automated process,
| if this is incorrect, please click this link:United States English
| Microsoft Homepage

For the record, my UA string is:

  Mozilla/5.0 (Windows NT 5.1; rv:46.0) Gecko/20100101 Firefox/46.0

I guess these guys really don't like firefox.

Well, I'm abandoning this attempt.

> GC> > GC> Could I also ask you to opine on the "TODO ??" markers in 
> transferor.cpp',
> GC> > 
> GC> >  I'll do this next but I wanted to post this quickly to let you know 
> about
> GC> > the new PR.
> GC> 
> GC> I think I'll just go ahead and resolve all of them except the one
> GC> concerning wxControlWithItems and wxItemContainerImmutable.
> 
>  I've started looking at those, but am not ready to post the patch yet, so
> if you'd like to do it immediately, please go ahead, but if it's not very
> urgent, I could still do it, after finishing with the "..." buttons
> business.

See my separate email on that topic. Perhaps you know the secret
incantation to make this all just work.