Window error
Status: Beta
Brought to you by:
anomie
Menu
▾
▴
#1 Window error
On my system, wmsystemtray fails to produce a usable window. I am using Linux-x86 with X11R6 and WindowMaker. What happens is that a placeholder for the window appears on the bottom of the screen, and the window is presumably somewhere on the screen, invisible. It does not draw on the window at all, nor does it take over the system tray windows. When the --non-wmaker switch is passed it does the same thing, except the window is visible (due to the title bar), and the window has an icon in the window list (without the switch, it has none). Am I doing something wrong? This is how it came out of the box.
What does the placeholder icon look like? If it's just an empty square with two arrows and numbers (e.g. "1/1", or maybe "0/0") at the bottom, that's the actual dockapp. If not, I'm curious as to what you are seeing; the program (without --non-wmaker) shouldn't be creating any icons except for the dockapp icons.
Can you run the program with the options "-v -v" (yes, 2 -v's) and paste the debugging information here?
Also, as a sanity check, which system tray icons are you expecting to show up? If you're not sure, gtrayicon is a fairly simple app that can be used as a test.
I can't run it with the verbosity up right now, since I'm not home, but no window appears when I run the application. It exists, but nothing is drawn, so it is invisible. The dockapp does not appear in the dock, only a window appears in the list. It has no icon without the --non-wmaker switch; it is a completely empty square (in the window list). With the switch it has the default icon for windows in wmaker. The icons I was expecting were for Pidgin and Ario. I haven't tested Ario in another WM, but the icon for Pidgin shows up in GNOME.
Okay, I have run it with verbosity on. It produced the following result:
--------------------------------------------------------------
wmsystemtray: Creating windows
wmsystemtray: My pid is 1612
wmsystemtray: Opening display ':0.0'
wmsystemtray: Interning atoms
wmsystemtray: Loading XPM
wmsystemtray: Allocating window hints
wmsystemtray: Parsing geometry string ''
wmsystemtray: 0 0 64 64
wmsystemtray: Allocating space for 1 windows
wmsystemtray: Creating selection window
wmsystemtray: Creating GCs
wmsystemtray: Dock window #0 is 1200009
wmsystemtray: Freeing X hints
wmsystemtray: Updating display: page 1 of 1
wmsystemtray: Drawing window 0 (1200009)
wmsystemtray: Initializing protocols
wmsystemtray: fdtray: Loading atoms
wmsystemtray: fdtray: Grabbing system tray selection
wmsystemtray: X time is 681411
wmsystemtray: fdtray: Notifying clients that we are now the system tray
wmsystemtray: Setting signal handlers
wmsystemtray: Entering main loop
wmsystemtray: Got X event 28
wmsystemtray: Got X event 28
wmsystemtray: Got X event 28
wmsystemtray: Got X event 28
wmsystemtray: Got X event 28
wmsystemtray: Got X event 14
wmsystemtray: Got X event 14
wmsystemtray: Got X event 22
wmsystemtray: Got X event 19
wmsystemtray: Got X event 28
wmsystemtray: Need update? No
wmsystemtray: Got X event 33
wmsystemtray: fdtray: Dock request for window 1000b59
wmsystemtray: Adding tray icon 1000b59 of type 0
wmsystemtray: Mapping tray icon 1000b59
wmsystemtray: Need update? Yes
wmsystemtray: Updating display: page 1 of 1
wmsystemtray: Drawing window 0 (1200009)
wmsystemtray: [0] Tray icon 1000b59 at 0 8,4
wmsystemtray: Reparenting 1000b59 to 1200009
wmsystemtray: Got X event 14
wmsystemtray: Got X event 14
wmsystemtray: Got X event 21
wmsystemtray: X time is 681462
wmsystemtray: Got X event 22
wmsystemtray: Got X event 19
wmsystemtray: Got X event 28
wmsystemtray: Got X event 22
wmsystemtray: Got X event 22
wmsystemtray: Need update? No
wmsystemtray: Got X event 33
wmsystemtray: fdtray: Dock request for window 1400004
wmsystemtray: Adding tray icon 1400004 of type 0
wmsystemtray: Need update? Yes
wmsystemtray: Updating display: page 1 of 1
wmsystemtray: Drawing window 0 (1200009)
wmsystemtray: [0] Tray icon 1000b59 at 0 8,4
wmsystemtray: Tray icon 1400004 is not visible
wmsystemtray: Reparenting 1400004 to 1200009
wmsystemtray: Got X event 14
wmsystemtray: Got X event 14
wmsystemtray: Got X event 21
wmsystemtray: X time is 688700
wmsystemtray: Need update? No
wmsystemtray: Got X event 28
wmsystemtray: Got X event 28
wmsystemtray: Mapping tray icon 1400004
wmsystemtray: Need update? Yes
wmsystemtray: Updating display: page 1 of 1
wmsystemtray: Drawing window 0 (1200009)
wmsystemtray: [0] Tray icon 1000b59 at 0 8,4
wmsystemtray: [1] Tray icon 1400004 at 0 32,4
wmsystemtray: Got X event 14
wmsystemtray: Got X event 14
wmsystemtray: Got X event 22
wmsystemtray: Got X event 22
wmsystemtray: Got X event 22
wmsystemtray: Got X event 19
wmsystemtray: Need update? No
wmsystemtray: Got X event 28
wmsystemtray: Need update? No
wmsystemtray: Got X event 18
wmsystemtray: A poorly-behaved application tried to unmap window 1400004!
wmsystemtray: Got X event 17
wmsystemtray: Tray icon 1400004 was destroyed, removing
wmsystemtray: Removing tray icon 1400004 of type 0
wmsystemtray: fdtray: Reparenting 1400004 to the root window
wmsystemtray: Ignoring BadWindow error
wmsystemtray: Ignoring BadWindow error
wmsystemtray: Ignoring BadWindow error
wmsystemtray: Need update? Yes
wmsystemtray: Updating display: page 1 of 1
wmsystemtray: Drawing window 0 (1200009)
wmsystemtray: [0] Tray icon 1000b59 at 0 8,4
wmsystemtray: Got X event 14
wmsystemtray: Got X event 14
wmsystemtray: Need update? No
wmsystemtray: Main loop ended
wmsystemtray: Cleaning up for exit
wmsystemtray: fdtray: Releasing system tray selection
wmsystemtray: Removing all icons
wmsystemtray: Removing tray icon 1000b59 of type 0
wmsystemtray: fdtray: Reparenting 1000b59 to the root window
wmsystemtray: Deinitializing protocols
wmsystemtray: Closing display
wmsystemtray: Exiting app
Everything in that output seems completely normal, it *seems* to be working fine.
> wmsystemtray: Dock window #0 is 1200009
One thing that might help, if you use this number with xwininfo (like "xwininfo -id 0x1200009") it should output some useful information, including the position of the window on the screen and the "Map State" which should be IsViewable.
> wmsystemtray: fdtray: Dock request for window 1000b59
> wmsystemtray: Adding tray icon 1000b59 of type 0
> wmsystemtray: Mapping tray icon 1000b59
> wmsystemtray: Need update? Yes
> wmsystemtray: Updating display: page 1 of 1
> wmsystemtray: Drawing window 0 (1200009)
> wmsystemtray: [0] Tray icon 1000b59 at 0 8,4
> wmsystemtray: Reparenting 1000b59 to 1200009
This indicates that it found an icon for some application (I guess either pidgin or ario), and successfully placed it in the upper-left position inside the dockapp window.
> wmsystemtray: fdtray: Dock request for window 1400004
[...]
> wmsystemtray: [1] Tray icon 1400004 at 0 32,4
Much the same for a second icon, although this time the icon was initially hidden and then showed itself after it was placed into wmsystemtray.
> wmsystemtray: Tray icon 1400004 was destroyed, removing
> wmsystemtray: Removing tray icon 1400004 of type 0
> wmsystemtray: fdtray: Reparenting 1400004 to the root window
> wmsystemtray: Ignoring BadWindow error
> wmsystemtray: Ignoring BadWindow error
> wmsystemtray: Ignoring BadWindow error
And then that second application went away. "Ignoring BadWindow error" is not unexpected, BTW.
> It has no icon without the --non-wmaker switch; it is a completely empty
> square (in the window list).
A completely empty square is certainly something unusual, it should at least have two small buttons with arrows and the numbers "1/1" at the bottom; see the screenshots at http://www.dockapps.org/file.php/id/355 for example.
Will you provide the output of the following commands?
xdpyinfo | grep SHAPE
xdpyinfo | grep XFIXES
wmaker --version
The SHAPE and XFIXES extensions are both present, according to xdpyinfo, and I am using Window Maker version 0.92.0. xwininfo -id 0x1000009 produces the following:
--------------------------------------------------
xwininfo: Window id: 0x1000009 "wmsystemtray"
Absolute upper-left X: -1
Absolute upper-left Y: -1
Relative upper-left X: 0
Relative upper-left Y: 0
Width: 64
Height: 64
Depth: 16
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x20 (installed)
Bit Gravity State: ForgetGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsUnviewable
Override Redirect State: no
Corners: +-1+-1 -1297+-1 -1297-705 +-1-705
-geometry 64x64+-1+-1
This bug appears to have to do with Window Maker. I started wmsystemtray in Blackbox and it worked perfectly.
That's the same version of WindowMaker I use. Although perhaps the distribution patches might make a difference, I use Debian's version. If you can point me to the sources for whichever version specifically you use, I'll try compiling and running it here.
> -geometry 64x64+-1+-1
That's odd, it seems like it's not being picked up as a dockapp. I assume other dockapps work fine for you? What does "xwininfo -id 0xwhatever -children" show? Also "xprop -id 0xwhatever", and possibly the same for the number minus 1.
I am currently using Slackware's version of WindowMaker, though I may attempt to compile vanilla WindowMaker and replace my version with it. I can run wmbluecpu, though it does not appear in the dock; it appears with the icons to applications, which I don't believe it should. xwinfo -children produces the following:
------------------------------------------------------------------
Root window id: 0xdd (the root window) (has no name)
Parent window id: 0x1400008 "wmsystemtray"
1 child:
0xc0108a "Pidgin": ("pidgin" "Pidgin") 24x24+8+4 +7+3
------------------------------------------------------------------
and xprop for the child window produces the following:
------------------------------------------------------------------
GDK_TIMESTAMP_PROP(GDK_TIMESTAMP_PROP) = 0x61
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 12587148
_XEMBED_INFO(_XEMBED_INFO) = 0x1, 0x1
_NET_WM_USER_TIME(CARDINAL) = 580220
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0xc0108b
WM_CLIENT_LEADER(WINDOW): window id # 0xc00001
_NET_WM_PID(CARDINAL) = 1588
WM_LOCALE_NAME(STRING) = "en_US"
WM_CLIENT_MACHINE(STRING) = "DEIMOS-Slackware"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
program specified minimum size: 22 by 22
window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "pidgin", "Pidgin"
WM_ICON_NAME(STRING) = "Pidgin"
_NET_WM_ICON_NAME(UTF8_STRING) = 0x50, 0x69, 0x64, 0x67, 0x69, 0x6e
WM_NAME(STRING) = "Pidgin"
_NET_WM_NAME(UTF8_STRING) = 0x50, 0x69, 0x64, 0x67, 0x69, 0x6e
------------------------------------------------------------------
And so that you can see what I see, I am attaching a dump of the dock window, from xwd.
Scratch the dump of the window, xwd refused to dump it. Output was:
------------------------------------------------------------------
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 73 (X_GetImage)
Serial number of failed request: 233
Current serial number in output stream: 233
> I can run wmbluecpu, though it does not appear in the dock; it appears with
> the icons to applications, which I don't believe it should.
A dockapp will appear with the app icons, until you put it in the dock. After
all, a dockapp is just a program that puts its UI in the appicon rather than
opening a normal window.
> Parent window id: 0x1400008 "wmsystemtray"
> 1 child:
> 0xc0108a "Pidgin": ("pidgin" "Pidgin") 24x24+8+4 +7+3
That tells us that Pidgin's icon certainly is being placed into the
wmsystemtray window. But for some reason your version of Windowmaker is not
actually picking up the icon window to use for the appicon, so you can't see
it.
> and xprop for the child window produces the following:
What about xprop for the wmsystemtray window? Both the 0x1400009 and 0x140008
(or the equivalents) might be helpful.
Also, just out of curiousity, would it be possible for you to create a
completely new user on your system (i.e. with all the default configurations)
and open wmsystemtray and pidgin to see if it happens to work there?
I have found the problem: one of the fixes to deal with wmaker was breaking it. Commenting out the if statement at line 544 in wmsystray.c solves the problem. A new problem arises, however: the window (which is now drawn properly) cannot be moved, and when clicked or right-clicked no menu appears. The icons held in the systray do work, though, and can be clicked, right-clicked, etc. like they should be able to be.
The problem with moving the window seems to be due to the sizes being hard-coded into the application. I have my desktop set to use 64x64 windows, and the window is drawn as being 64x64, so I cannot get any border to drag. Anyway, I'm closing this bug since the problems have been resolved. Thank you for your help, anomie.
The first bug was due to hacks put in place for old versions of wmaker. The second bug was due to hardcoded values in the application. The problems have been found, therefore I am closing the bug.
If commenting out line 542 makes it work, the "first" bug is that something is odd about the behavior of using XSetWindowBackgroundPixmap with ParentRelative on your system. The second "bug" is because commenting out the whole if block in question means that the window never gets set to the intended non-rectangular shape.
I wonder if commenting out the "XClearArea(display, icon->w, 0, 0, 0, 0, True);" at line 337 instead fixes your problem (although it will cause odd graphics if you close the first icon's program so the following icons get shifted, since the icon won't get repainted for its new background). I also wonder if docker works for you with its -wmaker option, since it also uses a ParentRelative background.
Yes, I uncommented the most of that block and it now works. I added a patch that contains the version of wmsystemtray I was using.
Yes, I saw that patch. But rather than just putting an ugly background behind the icons, I'd rather find out why XSetWindowBackgroundPixmap with ParentRelative is failing to work correctly.