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

[Greg Chicares]

On 2016-05-30 17:24, Vadim Zeitlin wrote:
> On Mon, 30 May 2016 14:04:03 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Now we have
> GC>   ce_product_name.?pp
> GC>   ce_skin_name.?pp
> GC> and the first determines its enumerators in
> GC>   product_names.?pp
> GC> while the second does that in an unnamed namespace in the 'ce_' source.
> GC> 
> GC> I'd like to determine the enumerators in a parallel location for both:
> GC> that makes code review and future maintenance easier. Do you strongly
> GC> prefer that I not create new
> GC>   skin_names.?pp
> GC> files?
> 
>  No, not really strongly, but I think I prefer to keep them private in that
> file just because I don't see any reason to "export" them. Why not merge
> product_names.cpp with ce_product_name.cpp instead?

Okay, I'll do that soon.

I plan to make a few more small changes. First of all, I'm thinking that the
fetch_*_names() code can be simpler and more similar in both 'ce_*.cpp' files.
Showing basenames instead of full filenames in the GUI seems friendlier. I
don't think we really need to distinguish between regexes
  /skin\.xrc/ and /skin_.*\.xrc/
because the single regex /skin.*\.xrc/ is good enough.

And I wonder why I ever transformed '.product' filenames to lowercase, when
we never distribute them with any uppercase letters; the reason is lost in
the mists of time, but presumably had something to do with DOS compatibility.
I think it's time to get rid of this.

Is there any particular reason for the following implementation?
  std::string const& default_skin_name()
  {
      static std::string const default_name("default");
      return default_name;
  }
Is it precisely because this default is an impossible value, which therefore
triggers a useful diagnostic in some particular scenario?