From: "=?UTF-8?Q?Alfredo_Fern=c3=a1ndez_D=c3=adaz?=" <lswitcher-dev@2rosenthals.com>
Subject: Re: [lswitcher-dev] lSwitcher 2.92 RC 9
To: lSwitcher Developers Mailing List <lswitcher-dev@2rosenthals.com>
References: <list-1130479@2rosenthals.com> <list-1131904@2rosenthals.com>
 <list-1132073@2rosenthals.com> <list-1132254@2rosenthals.com>
 <list-1132305@2rosenthals.com> <list-1133572@2rosenthals.com>
 <list-1134376@2rosenthals.com>
Message-ID: <5F6A61CB.6050809@yahoo.es>
Date: Tue, 22 Sep 2020 22:42:51 +0200
User-Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:38.0) Gecko/20100101 Firefox/38.0
 SeaMonkey/2.35
MIME-Version: 1.0
In-Reply-To: <list-1134376@2rosenthals.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Length: 3641

Hi,

not lagging behind by much this time around...

On 20/09/22 20:28, Gregg Young wrote:
> On Tue, 22 Sep 2020 00:11:57 -0400 Lewis wrote:
>>
>> Hi...
<snip>
>> Perhaps a better approach would be to not change
>> the menus until after a program (or XCenter) restart. Managing this
>> would be a longer term RFE. The Miscellaneous page Language area could
>> include a static line under the dropdown stating something to that
>> effect, so the user isn't left wondering why the menus do not change
>> immediately.
>
> For now I will add a message under the drop down that a restart is needed
> to assure all the menus appear properly.

Good. Frankly, I can't think of a use case where this wouldn't be enough.

[...]
>>>> I can confirm that Shift-F10 works for the popup window (when sticky;

Same here.

>>>> of course, as I don't normally use a sticky popup window, it took me
>>>> a couple minutes to figure out how the key combination is 'sposed to
>>>> work).
>>> This works without sticky set. However it is difficult to do a
>>> shift+F10 while holding down the alt or ctl key. The left shift works I
>>> haven't tried the right.

It does. As a keyboard person, right shift+F10 is more of a natural 
combination for me while I press left Ctrl/Alt+Tab.

>> I don't know many people who are accustomed to performing two separate
>> 2-key operations at the same time. Yes, I see that this does work, but
>> as a pianist, I can tell you that's quite a cacophony of key presses.
>> :-)
>
> Yes IBM picked the shift+F10 for this. Probably wouldn't have been my first choice.

But this is settable, system-wide (and actually one of the first things I 
change on every working system): see "Mappings" tab of the Keyboard object in 
System Configuration.

If the base code allows, instead of listening for specific mouse or keyboard 
events like MB2 or S+F10, lSwitcher should be checking for a PM message that a 
pop-up menu is being invoked. IIRC the name of the message is CN_CONTEXTMENU. 
With Styler, even the Win menu key could be used for this.

[...]

 > 5. Some minor documentation updates (including Lewis')

I see the help reverts to 'may fail' instead of 'will fail' for reducing the 
Desktop work area when it is also ON for XCenter. Wording is irrelevant if the 
UI forbids the option to be checked. As I mentioned before, this worked (for 
me anyway) in lSwitcher 2.71, and it still works with lSw 2.71 on AOS 5.0.6, 
so why disallow it? Assuming everything else is fine, this will still prevent 
me from upgrading on my main system.

I see a number of other things are (mostly?) unchanged, so I'll summarize, as 
my previous screenshots are still valid:

-Key descriptions get clipped at the sides of the PM popup at 800x600.

-Tile and Cascade still seem to be problematic and do funny (maybe slightly 
different?) stuff with certain windows compared to what the system does:

Regarding the Desktop, it has no 'tile' or 'cascade' entries on its popup menu 
on the system Window list. lSwitcher mimics this on its own popup menu now 
(good), and the mnemonics are not shown. However they are still active, and 
you can press them to 'Tile' and 'Cascade' the Desktop window, which is not 
reversible, as I also mentioned. Nobody will do this intentionally, but it's 
not nice if it happens to happen by accident.

Regarding non-resizable windows (notably DHCP Monitor, omnipresent in my test 
systems, so an easy target), system 'tile' and 'cascade' from the Window list 
move the window around but without resizing, whereas lSw's 'tile' and 
'cascade' do resize it, which it seems to dislike.

That's all for now.

Thanks,
A.