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

[Vadim Zeitlin]

On Mon, 9 Jan 2023 22:06:39 +0000 Greg Chicares <gchicares@sbcglobal.net> wrote:

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

 Yes, and the new "feature" attribute will be very similar to the existing
"platform" one.

GC> Thanks for asking. I don't think this would be very useful for lmi.
GC> 
GC> For 'test_menu', we might do something like
GC>   if(condition)
GC>     wxXmlResource::SetEnabledFeatures("ash_nazg");
GC> and then we wouldn't have to call FindMenu("Test") or Remove() in
GC> Skeleton::AdjustMenus(), because the "test" feature would be
GC> {en,dis}abled in XRC. That would be a little cleaner

 Sorry, I'm a bit confused as the two paragraphs above seem to be saying
somewhat opposite things, so I'd like to ask to confirm: would it be useful
to switch to using SetEnabledFeatures("ash_nazg") in lmi or not?

 I realize that it won't be "very useful", but I'm not sure if you meant
that it would be still worth doing even though it isn't very useful, or
that it's so far from being very useful as to not be worth doing at all?

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

 In fact, I still have a "harmonize spacing and margins across different
pages and tasks" somewhere in my TODO list and I was thinking about it when
writing the previous message. Unscrambling the skins would make doing that
much less onerous, and I hoped that making things more consistent could be
actually welcomed by the end users, but you're, of course, a better judge
of this.

 Thanks again,
VZ

pgpSKAvjMNcaM.pgp
Description: PGP signature