Re: Unexpected behavior on ctwm menus, with workaround

On Sun, 17 Sep 2017 15:42:11 -0500
"Matthew D. Fuller" <[email protected]> wrote:

> On Thu, Sep 07, 2017 at 01:29:08AM -0400 I heard the voice of
> Steve Litt, and lo! it spake thus:
> > 
> > I'll give it some more thought after I've recovered from Hurricane
> > Irma, which depending on exact course could either give me some
> > great kite flying weather or rip down my house.  
> 
> Hope it wound up with more the latter than the former for you.  I've
> got family in the path, and they got plenty wet and blown around, but
> luckily avoided any major damage.

Thanks! Like your family, my problems were limited to some lost siding,
a few broken branches, and a few thin trees that will need to be cut
down before the next storm. I was in credibly lucky.

> 
> 
> > I can't actually fix the root cause: I tried, but couldn't
> > understand the code enough.  
> 
> OK, I had some time today, so I went through HandleKeyPress() and gave
> it the comment/minor-cleanup treatment some other parts of the
> codebase have had, so it should be a little more readable (in current
> trunk)[2].

Thanks! And thanks for the detailed explanation of both what the "side
effect" is, and the rationale for the way it's coded. I couldn't
exactly understand the side effect when in the workspace thingy, but I
perfectly understood the menu default value feature and its
requirements.

[snip]
 
> Now, is there a better way we should handle that clash?  That's
> another discussion we can have...

What I should have done is, in the 1980's when twm was made, I should
have gone to its developers and made the point that having a menu
choice that could be both a command and a submenu costs more in
confusion than it could ever be worth in convenience. But in the 1980's
I was a little punk DOS programmer with Turbo Pascal and RBASE, totally
oblivious to the bigger picture.

So now we're in 2017, the concept of default behaviors for menu items
is established settled law, and removing it would break a lot of
peoples' menus and habits. The best we can do is remove unexpected
behavior, and I think it will be pretty easy because you already have
all the information captured...

If somebody pushes rightarrow or Return on a command type
item, run the command. I believe it works this way now. If somebody
pushes rightarrow on any menu item, show the submenu. It works this
way now. If somebody presses Return on a menu item with a default,
run the default. It works this way now. If somebody pushes Return on a
menu item with no default, show the submenu. It does not work this way
now.

In other words, if someone presses Return on a submenu item with no
default, the submenu should be displayed. If you imagine a mythical
function called HasDefault(MenuItem *item), which I'd assume but don't
know would simply read item->action, then I think the following
modification of the code would implement the change I describe in
English in the preceding paragraph:


	case F_MENU :
		if((!strcmp(keynam, "Return")) && (HasDefault(item))) {

Wouldn't the preceding do everything that's done now except display a
submenu if someone hits Return on a submenu choice with no default?

If my idea causes a side effect with workspaces, perhaps do this
instead:


	case F_MENU :
		if(!strcmp(keynam, "Return")) {
			if(ActiveMenu == Scr->Workspaces) {
				/* Do workspace menu stuff */
				return
			}
			else if HasDefault(item) {
				/* Execute the default */
				return;
			}
			/* Explicitly remove return statement from here
			*/
		}

What do you think?

Thanks for your great explanation!

SteveT

Steve Litt
September 2017 featured book: Manager's Guide to Technical
Troubleshooting Brand new, second edition
http://www.troubleshooters.com/mgr