On Wed, Jun 16, 2021 at 12:08:22PM +0200, z...@sirc.hu wrote:
> workararound. Unfortunately this v9.26 brought back the same little
> annoying bug: black borders around until I not moved the window on the
> screen. More details and screenshots at
Hi, I can't seem to reproduce this, i.e. I don't get a black border
anywhere with your winoptions and commandline.
I ran icewm 1.4.3.0~pre-20181030-2 from debian buster, and current urxvt
and your commandline:
> `rxvt -bl -tr -geometry +100+50 -e top`
I didn't get any border, only the window with top inside.
I do get a border when specifying e.g. "-w 5 -bl", which would be correct
behaviour, but the default of an (unpatched) rxvt-unicode would be 0.
You could try to infer who this window belongs to by using something like
"xwininfo -tree -frame" and seeing if icewm reparents the window, and if the
coordinates are correct.
For example, I get this with your example:
xwininfo: Window id: 0x600009 "top"
Root window id: 0x3a9 (the root window) (has no name)
Parent window id: 0x3a9 (the root window) (has no name)
1 child:
0x60000e (has no name): () 880x456+2+2 +102+52
Which indicates there is just the urxvt window itself, and this when icewm
gives it a border:
xwininfo: Window id: 0x2000de "Frame"
Root window id: 0x3a9 (the root window) (has no name)
Parent window id: 0x3a9 (the root window) (has no name)
11 children:
0x2000df "Container": () 884x460+5+5 +105+55
1 child:
0x600009 "top": ("rxvt" "URxvt") 884x460+0+0 +105+55
1 child:
0x60000e (has no name): () 880x456+2+2 +107+57
0x2000e0 "topSide": () 862x5+16+0 +116+50
0x2000e9 (has no name): () 5x16+889+0 +989+50
0x2000e8 (has no name): () 5x16+0+0 +100+50
0x2000e7 (has no name): () 16x16+878+454 +978+504
0x2000e6 (has no name): () 16x16+0+454 +100+504
0x2000e5 (has no name): () 16x16+878+0 +978+50
0x2000e4 (has no name): () 16x16+0+0 +100+50
0x2000e3 (has no name): () 862x5+16+465 +116+515
0x2000e2 (has no name): () 5x438+889+16 +989+66
0x2000e1 (has no name): () 5x438+0+16 +100+66
Maybe you can find out who the black area belongs to. xprop vs. xprop
-frame could also be useful.
> https://github.com/bbidulock/icewm/issues/492
Wow, what an arrogant ass, he admits he doesn't even know if its a bug in
urxvt, but:
It isn't their first bug (see above), so yes, it would be useful for
the future if they become more aware of their slippages.
Thats damning given that icewm has about 20 times more open bugs than
urxvt right now.
I am tempted to say, since urxvt only sets the option for the window
manager when a position is specified, its likely a wm bug (or potentially
a driver bug). Especially as its the wm job to draw the border.
However, if we can work out a way to reproduce it I will look at it and
see what the origin could be. It could be a urxvt bug, or it could simply
be an incompatiiblity. Or an icewm bug.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schm...@schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
_______________________________________________
rxvt-unicode mailing list
rxvt-unicode@lists.schmorp.de
http://lists.schmorp.de/mailman/listinfo/rxvt-unicode
