Strange window that isn't a window
Brought to you by:
torrey
Menu
▾
▴
#189 Strange window that isn't a window
I am using Gnome and Sawfish right now, but observed
very similar behavior with OroborOSX 0.8p3, so I
believe this is an XDarwin issue.
What happens is this. I launch an xterm, and from that
xterm I type 'mm', which launches the MeetingMaker
application. MeetingMaker immediately creates a
docked icon called 'mmxp' that does not seem to
correspond to any real window. This weird icon gets
randomly mapped to other windows, such as xterms,
and the whole layering thing gets confused, causing
windows to look focused but not accept keystrokes.
This happens every time with Meeting Maker, very
reproducible. There is no window in existence with the
name 'mmxp', but the window manager seems to get
confused and map it to other windows. Then, they get all
flustered, and for example, bringing a window to front
makes it not really come to front any more but just hang
back, while another window will get the keyboard focus
even though I didn't click on it.
Logged In: YES
user_id=346175
One note" my symptoms after the creation of this strange
dock item are similar to those reported in the thread, "xterm
don't always become active" in this forum.
Logged In: YES
user_id=313617
I wonder if it might actually be related to 497219
(XQueryTree)...?
Since this 'mystery window' does get withdrawn (by OroborOSX,
at least, when it goes to the dock - what happens with gnome/
sawfish?) it's vaguely possible that some obscure, rare bug
in XQueryTree would cause this behaviour.
Adrian
BTW, Richard, it is a real window, which does exist - take a
look at the verbose log you sent me a few days ago...
OroborOSX X11 event: map request (window,lastfocus:
0xa00007,0x80000e)
TRACE1: create_new_client 0xa00007 (0x80000e)
OroborOSX info: XGetWindowAttributes returned status 1
==== NEW WINDOW: 0xa00007 hints...
title: mmxp
res_name: mmxp
res_class: Mmxp
ret,argc: 1 1
argv: /usr/local/mmxp6.0.8/mmxp
flags: 0x3
input: 1
XID : 0x3
state: 0x3
Used initial state hints
---- MWM HINTS...
flags : 0x2
functions : 0xffffffff
decorations: 0
inputMode : 0xffffffff
status : 0x424ff0
DECOR_BORDER, DECOR_TITLE: 0x2 , 0x8
Got bounds (min/max): 3/1148 , 1/823
Placing in center: 576,424
OroborOSX info: into configure_client
(client,mask,frame_only,lastfocus: 0x584b60,31,0,0x80000e) 64
Sending configurenotify event to window: 0xa00007
OroborOSX info: sending inhibitnone and updateall
Sending hack_id = 1149 to XDarwin...
2002-05-31 16:14:53.878 XDarwin[9292] ======== set new window
HackID to 1149
2002-05-31 16:14:53.879 XDarwin[9292] HackID 1149 : Set top-
left of window 576,425
2002-05-31 16:14:53.879 XDarwin[9292] myFrame: 576 , 424 1
x 1
2002-05-31 16:14:53.879 XDarwin[9292] set myFrame: 576 ,
424 1 x 1
2002-05-31 16:14:53.880 XDarwin[9292] HackID 1149 : Set top-
left of window 576,425
2002-05-31 16:14:53.880 XDarwin[9292] myFrame: 576 , 424 1
x 1
2002-05-31 16:14:53.880 XDarwin[9292] set myFrame: 576 ,
424 1 x 1
2002-05-31 16:14:53.881 XDarwin[9292] HackID 1149 : Set top-
left of window 576,425
2002-05-31 16:14:53.881 XDarwin[9292] myFrame: 576 , 424 1
x 1
2002-05-31 16:14:53.881 XDarwin[9292] set myFrame: 576 ,
424 1 x 1
sending window to dock... 0xa00007 [0x584b60]
OroborOSX info: into set_focus_client (client,last:
0x57f540,0x57f540)
OroborOSX info: into configure_client
(client,mask,frame_only,lastfocus: 0x57f540,64,0,0x80000e) 64
2002-05-31 16:14:54.199 XDarwin[9292] HACKID 1149 : No
miniaturizing from wrong thread...
2002-05-31 16:14:54.203 XDarwin[9292] >>>>>>>>>>> Got
xwinToDock at: 0x1d4c770
2002-05-31 16:14:54.204 XDarwin[9292] HACKID 1149 :
Miniaturizing from right thread...?
2002-05-31 16:14:54.204 XDarwin[9292] HACKID 1149 : ***** Got
will miniaturize notification...
Entered SendHackCommand for docked client: -23404 0
Notice that the window is of size 1x1 and that it is
immediately docked - this is your mystery window!
Looking at the rest of this particular log (not included
here), I can see that the window is then moved offscreen (but
it still exists, and hence seems to 'vanish' when you select
it from the Window menu). Also, when you select this window
(so focussing it) then it appears (quite rightly!) that no
window has the focus...
In fact, after scrutinising your log, it seems like OroborOSX
has done exactly as I expect it to! (Even though the fact
that all windows appear to have 'backgrounded' is somewhat
misleading - it's just that the window which actually has the
focus [the 'mmxp' window you chose from the menu] is
offscreen...)
I don't know if there is some flag I've overlooked which
should tell OroborOSX not to focus this window...? But then
what should it do when this window is chosen...?
Anyway, I'm really interested to know the behaviour under
gnome/sawfish (in particular, what happens when this mmxp
window first appears - do you get an icon for it or
something?) Do you ever have the problem with xterm keyboard
focus under gnome/sawfish?
Bye!
Adrian
Logged In: YES
user_id=346175
Adrian:
Man, is there a forum you DON'T monitor? :-) How do you do
your searches? You don't miss a thing related to
OroborOSX, kudos!
Anyhow, the behavior described above IS for Sawfish/
Gnome. It's interesting that the mmxp window is a real, off-
screen window. Wouldn't it be proper to not create icons of
off-screen windows?
I don't know why, but with the creation of this window in both
OOSX and Sawfish (and probably every other wm), the
window ordering mechanism soon gets confused. In sawfish,
the exact behaviors I've noticed are that the window that is in
front is not selectable and cannot accept keyboard focus,
unless I select it in the Gnome panel at the bottom of my
monitor. Then all seems well for a while.
The damnable part is, I cannot ever put my finger on exactly
when things go weird on me. Just suddenly, I can't type into
the frontmost window. That's a symptom that appears across
the board.
Logged In: YES
user_id=313617
> Man, is there a forum you DON'T monitor?
Every month or so I try to remember to take a look through the list of
XDarwin bugs. Since yours is so recent, and has the same subject as
your xdarwin.org post, it caught my attention...
> behavior described above IS for Sawfish/Gnome.
Ah! Interesting...
> the mmxp window is a real, off-screen window
Look again at the console log...
Placing in center: 576,424
...
...HackID 1149 : Set top-left of window 576,425
...myFrame: 576 , 424 1 x 1
it does not start off-screen.
It is only moved off-screen later on, when you choose it from the menu
and the window is remapped.
It's really quite a bizarre thing to do, and I'm not sure what the reasoning
is behind it.
Out of interest, how does twm cope with it...?
Have you been able to try running MeetingMaker under a second
XDarwin (i.e. separating it from your X display with OroborOSX)?
Adrian
Logged In: YES
user_id=346175
You sed:
>it does not start off-screen.
>It is only moved off-screen later on, when you choose it from
the menu
>and the window is remapped.
>It's really quite a bizarre thing to do, and I'm not sure what
the reasoning is behind it.
Only thing I can think of is maybe to keep a toehold on an X
connection while the other windows show up? I'm not even
sure what I mean by this, but just note that the window shows
up immediately and persists. Smells like a hack.
>Out of interest, how does twm cope with it...?
Not sure yet.
> Have you been able to try running MeetingMaker under a
second XDarwin (i.e. separating it from your X display with
OroborOSX)?
I've been mainly using Gnome/Sawfish since I noticed the
speed difference with OOSX. Just now I tried to change
XDarwin's prefs and find I'm not able to type into any text
boxes in XDarwin's prefs window, what's up with that? Didn't
you mention that as a bug way back when, somewhere or
other?
I am SO TIRED of having to quit XDarwin and thus reopen all
my terminal windows, sigh... wait! Even if I do, I still can't type
into the prefs window. Wasup?