twm takes no control

twm takes no control

[Dai Itasaka]

Quoted is what I posted as "no key input" last month.

Today I did the update and now twm doesn't take any key input
anymore. I can't move the keyboard focus from one window to another
by pressing the f.downiconmgr or the likes. In fact, no key command
(f.iconify, f.raiselower, f.zoom....) works now.

My preference is to use Ctrl key plus Shift key plus a letter key.
For example, f.downiconmgr is Ctrl+Shift+j. In .twmrc, it is like

    "j" = c|s : all : f.downiconmgr

It looks as if this Shift key is not detected as pressed. So instead
of taking it as Ctrl-Shift-x, it takes as Ctrl-x, and it is passed
through twm to whatever application that has the focus at the time
because it is no longer interpreted as a valid twm command key.

This was working before. What wasn't working is xterm, not twm.
But now, twm isn't.

Dai


) My startxwin.sh gives me the root window and an xterm window in it.
) I login to a remote host from this xterm after doing xhost for it.
) From there, I invoke xterm specifying the local PC as the display.
) Now I have two xterm windows here: one invoked locally, the other
) invoked from the remote host.
) 
) TWM is my window manager. My preference is to show the IconManager
) at the upper right hand corner of the root, in which I can move
) from one icon to the next by pressing the keyboard combo specified
) in the ~/.twmrc as "f.downiconmgr" or "f.upiconmgr". If I press
) the key combo, no matter where the mouse cursor is at, it jumps
) to the IconManager area and points to the window that has the keyboard
) focus at the time. As I press the "up" or the "down" key, the mouse
) cursor jumps to one icon up or down, and the keyboard focus moves
) to the corresponding window at once. This is the equivalent of
) MS Windows' Alt-Tab for me in X(no autoraise by default though).
) This is how I move the keyboard focus from one window to another.
) I can't live without this as I have been doing this for over 10
) years now. I'm so accustomed to it that I sometimes do it in MS
) Windows.
) 
) Now, with the latest Cygwin install, I still can move the keyboard
) focus by pressing the "up" or "down" key, thus I can toggle the
) keyboard focus between the two xterm windows I mentioned above.
) But, the xterm that is locally executed(cygwin xterm) doesnt take
) any key input unless I move the mouse cursor over the xterm
) window area, while the one that is remotely executed can take key
) inputs as usual without moving a mouse(the mouse cursor stays in
) the IconManager area).
) 
) Until the one before the latest(XFree86-xserv-4.3.0-18?), this was
) not the case. I was able to move around AND TYPE. Something that
) was added since then broke this capability.
) 
) 

Re: twm takes no control

[Harold L Hunt II]

Dai,

twm is yours.  I don't use it, I don't know how it works, most of my
users don't use it, I have no reason to fix it, I don't understand its
source code... I place the wounded twm at your feet and let you decide
what to do with it.  twm is all yours.  Fix the bugs that are important
to you, or point me to the correct fix if something needs to be fixed
with Xt/Xaw/etc.

I'm not saying this to be mean.  I am simply saying that I don't use twm
and I have no need for it to work correctly.  It will be much better in
your hands.

Harold

Dai Itasaka wrote:
> Quoted is what I posted as "no key input" last month.
> 
> Today I did the update and now twm doesn't take any key input
> anymore. I can't move the keyboard focus from one window to another
> by pressing the f.downiconmgr or the likes. In fact, no key command
> (f.iconify, f.raiselower, f.zoom....) works now.
> 
> My preference is to use Ctrl key plus Shift key plus a letter key.
> For example, f.downiconmgr is Ctrl+Shift+j. In .twmrc, it is like
> 
>     "j" = c|s : all : f.downiconmgr
> 
> It looks as if this Shift key is not detected as pressed. So instead
> of taking it as Ctrl-Shift-x, it takes as Ctrl-x, and it is passed
> through twm to whatever application that has the focus at the time
> because it is no longer interpreted as a valid twm command key.
> 
> This was working before. What wasn't working is xterm, not twm.
> But now, twm isn't.
> 
> Dai
> 
> 
> ) My startxwin.sh gives me the root window and an xterm window in it.
> ) I login to a remote host from this xterm after doing xhost for it.
> ) From there, I invoke xterm specifying the local PC as the display.
> ) Now I have two xterm windows here: one invoked locally, the other
> ) invoked from the remote host.
> ) 
> ) TWM is my window manager. My preference is to show the IconManager
> ) at the upper right hand corner of the root, in which I can move
> ) from one icon to the next by pressing the keyboard combo specified
> ) in the ~/.twmrc as "f.downiconmgr" or "f.upiconmgr". If I press
> ) the key combo, no matter where the mouse cursor is at, it jumps
> ) to the IconManager area and points to the window that has the keyboard
> ) focus at the time. As I press the "up" or the "down" key, the mouse
> ) cursor jumps to one icon up or down, and the keyboard focus moves
> ) to the corresponding window at once. This is the equivalent of
> ) MS Windows' Alt-Tab for me in X(no autoraise by default though).
> ) This is how I move the keyboard focus from one window to another.
> ) I can't live without this as I have been doing this for over 10
> ) years now. I'm so accustomed to it that I sometimes do it in MS
> ) Windows.
> ) 
> ) Now, with the latest Cygwin install, I still can move the keyboard
> ) focus by pressing the "up" or "down" key, thus I can toggle the
> ) keyboard focus between the two xterm windows I mentioned above.
> ) But, the xterm that is locally executed(cygwin xterm) doesnt take
> ) any key input unless I move the mouse cursor over the xterm
> ) window area, while the one that is remotely executed can take key
> ) inputs as usual without moving a mouse(the mouse cursor stays in
> ) the IconManager area).
> ) 
> ) Until the one before the latest(XFree86-xserv-4.3.0-18?), this was
> ) not the case. I was able to move around AND TYPE. Something that
> ) was added since then broke this capability.
> ) 
> ) 
> 

Re: twm takes no control

[Dai Itasaka]

) > > It is obvious that it is not twm that is broken.
) >
) > So it is another little issue related to the shared Xt and Xaw
) > libraries.  I did a search in the twm sources for "Vendor", "Shell",
) > "VendorShell", etc. but didn't find anything.  I am sure that you can
) > probably find info on how the OS/2 guys handled this bug, but searching
) > for "OS2" turned up nothing in the twm sources either.
) >
) I don't think so, Harold.  If this happens with twm run from other OSs,
) that eliminates twm itself and all its dlls, doesn't it?  It must be
) internal to the Cygwin X server, or its dlls, right?
) 
) Dai,  could you test the inverse?  Cygwin's twm controlling a RedHat or
) SuSE X server?  I think that would definately rule out twm and its dlls.

Cygwin's twm worked fine on a RedHat X Server.
I think Brian is right. It must be the Cygwin X server.

Re: twm takes no control

[Harold L Hunt II]

Brian,

Brian Ford wrote:

> On Thu, 20 Nov 2003, Harold L Hunt II wrote:
> 
> 
>>Dai,
>>
>>Dai Itasaka wrote:
>>
>>
>>>It is not just Cygwin version of twm. Exactly the same symptom is
>>>observed when using a twm on a RedHat or SuSE box managing a cygwin
>>>display.
>>>
>>>It is obvious that it is not twm that is broken.
>>
>>So it is another little issue related to the shared Xt and Xaw
>>libraries.  I did a search in the twm sources for "Vendor", "Shell",
>>"VendorShell", etc. but didn't find anything.  I am sure that you can
>>probably find info on how the OS/2 guys handled this bug, but searching
>>for "OS2" turned up nothing in the twm sources either.
>>
> 
> I don't think so, Harold.  If this happens with twm run from other OSs,
> that eliminates twm itself and all its dlls, doesn't it?  It must be
> internal to the Cygwin X server, or its dlls, right?

Hmmm... sounds reasonable.

Harold

Re: twm takes no control

[Brian Ford]

On Thu, 20 Nov 2003, Harold L Hunt II wrote:

> Dai,
>
> Dai Itasaka wrote:
>
> > It is not just Cygwin version of twm. Exactly the same symptom is
> > observed when using a twm on a RedHat or SuSE box managing a cygwin
> > display.
> >
> > It is obvious that it is not twm that is broken.
>
> So it is another little issue related to the shared Xt and Xaw
> libraries.  I did a search in the twm sources for "Vendor", "Shell",
> "VendorShell", etc. but didn't find anything.  I am sure that you can
> probably find info on how the OS/2 guys handled this bug, but searching
> for "OS2" turned up nothing in the twm sources either.
>
I don't think so, Harold.  If this happens with twm run from other OSs,
that eliminates twm itself and all its dlls, doesn't it?  It must be
internal to the Cygwin X server, or its dlls, right?

Dai,  could you test the inverse?  Cygwin's twm controlling a RedHat or
SuSE X server?  I think that would definately rule out twm and its dlls.

> I am at a loss.  As I said, this is yours to debug further.  If twm is
> the only app that is broken by the shared libs, then I am still not
> particularly concerned.  If it turns out that every other app is broken,
> or a significant number of other apps are broken, then I will certainly
> become concerned.
>
I don't have any examples, but to me, the description implies the latter
ought to be the case.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

Re: twm takes no control

[Harold L Hunt II]

Dai,

Dai Itasaka wrote:

> It is not just Cygwin version of twm. Exactly the same symptom is
> observed when using a twm on a RedHat or SuSE box managing a cygwin
> display.
> 
> It is obvious that it is not twm that is broken.

So it is another little issue related to the shared Xt and Xaw
libraries.  I did a search in the twm sources for "Vendor", "Shell",
"VendorShell", etc. but didn't find anything.  I am sure that you can
probably find info on how the OS/2 guys handled this bug, but searching
for "OS2" turned up nothing in the twm sources either.

I am at a loss.  As I said, this is yours to debug further.  If twm is
the only app that is broken by the shared libs, then I am still not
particularly concerned.  If it turns out that every other app is broken,
or a significant number of other apps are broken, then I will certainly
become concerned.

Harold

Re: twm takes no control

[Dai Itasaka]

It is not just Cygwin version of twm. Exactly the same symptom is
observed when using a twm on a RedHat or SuSE box managing a cygwin
display.

It is obvious that it is not twm that is broken.

Dai

 
) twm is yours.  I don't use it, I don't know how it works, most of my
) users don't use it, I have no reason to fix it, I don't understand its
) source code... I place the wounded twm at your feet and let you decide
) what to do with it.  twm is all yours.  Fix the bugs that are important
) to you, or point me to the correct fix if something needs to be fixed
) with Xt/Xaw/etc.
) 
) I'm not saying this to be mean.  I am simply saying that I don't use twm
) and I have no need for it to work correctly.  It will be much better in
) your hands.
) 
) 

Re: twm takes no control

[Dai Itasaka]

I noticed that the mouse cursor jumps to the IconMgr area
if no window has the keyboard focus. This is a normal twm
behavior. In that sense, it looks as if it is working. But
once somebody claims the focus, twm can't take over. This
is not normal.

Dai