Re: [lmi] Looking for your input concerning possible XRC improvement

[Greg Chicares]

On 1/8/23 14:52, Vadim Zeitlin wrote:
[...]
>       https://groups.google.com/g/wx-dev/c/RnJL-fk651k
> 
> In short, I'd like to be able to optionally associate a "feature" (I'd have
> called it "variant", but this is already used for something else in the wx
> API) to XRC nodes and specify, when loading the XRC file, which features
> should be enabled (meaning that the nodes specifying one of these features
> would be kept) and not (so that any nodes specifying only the features not
> in the set of the enabled ones would be discarded). And as there have been
> no replies to the original posts on wx-dev, I plan to go ahead with the
> original plan as described in that post.

We already use the somewhat similar "platform" in 'menus.xrc':

    <object class="wxMenuItem" name="window_next">
        <label platform="unix|mac">_Next</label>
        <label platform="win">_Next\tCtrl-Tab</label>

That file also contains several 'object_ref' elements. Some, like
'file_menu_{with,without}_.*', are alternatives, of which one is
selected according to the context provided by that XRC file. OTOH,
'test_menu' is conditionally {en,dis}abled in 'skeleton.cpp'
depending on a "password".

>  While I'd like to do it to simplify things for another project I'm
> involved with, I think this might be potentially useful to lmi too, e.g. I
> have a suspicion that multiple skin files might actually be replaced by a
> single (or at least a reduced number of) file(s) using this mechanism. I'm
> not completely sure if this is really the case and even whether you'd be
> interested in doing it if it were, but I thought I'd at least ask about it,
> so that I could consider any lmi-specific requirements when implementing
> support for this.

Thanks for asking. I don't think this would be very useful for lmi.

For 'test_menu', we might do something like
  if(condition)
    wxXmlResource::SetEnabledFeatures("ash_nazg");
and then we wouldn't have to call FindMenu("Test") or Remove() in
Skeleton::AdjustMenus(), because the "test" feature would be
{en,dis}abled in XRC. That would be a little cleaner--as a comment
in 'skeleton.cpp' says,
  /// Whatever can be done in wxxrc generally should be done there.
This wouldn't be a dramatic simplification. Maybe it would let
us expunge Skeleton::AdjustMenus(), because ash_nazg-ness is an
immutable property set on program initialization, and it looks like
Skeleton::CreateChildFrame() would then no longer need to call
Skeleton::AdjustMenus().

As for the multiple skin files...no, I don't think we'd want to use
"features" to consolidate them. That might have made sense when
those skins were originally developed, in order to prevent haphazard
divergence. But, that divergence having already occurred, attempting
now to unscramble that set of eggs to impose conformity across skins
would be perceived by end users as gratuitous and unwelcome change.

IIRC, these two:
  skin_group_carveout.xrc
  skin_group_carveout3.xrc
differ only slightly, one being pretty much a subset of the other.
But the choice between them is made not at run time but at the time
a distribution is assembled. And I think the one that's a subset
might no longer be used.