[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Greg Chicares
Subject: Re: [lmi] Looking for your input concerning possible XRC improvement
Date: Tue, 10 Jan 2023 02:59:33 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.0

On 1/10/23 01:07, Vadim Zeitlin wrote:
> 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> 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?

That's a definite "maybe".

>  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?

| "I won't say, I won't say."

> 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.

Few if any end users every use more than a single skin.
At this point, I think any change would be as unwelcome
as GUI changes in any other application.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]