JetBrains IDEs dont work well in Penrose.

[doums]

Describe the bug

Hi, First thank for your work and providing us this promising library! I just built a simple wm with it and quickly noticed that JetBrains IDE had some issues in Penrose. I don't know if these are issues on their side but what I can tell is that I have no problem with them in dwm. For example when I add a new file from the file browser within the IDE a new window opens with an input inside to write the file name. This window is cropped to half its height and I can resize it (only I can do is to toggle fullscreen). Some other windows dialog open with an enormous size with UI parts outside the screen, again I have to toggle fullscreen to be able to be able to see the content. Additional bugs I noticed:

• when I start to write in the editor, when the window of autocompletion stuff spawns sometimes I lose the focus on the editor window, so the key pressed stop to be received by the editor.
• when I interact with the IDE, the border of its window are colored with the unfocused border color

Versions & OS Details

• OS: Linux
• Distribution: Arch Linux 5.10.9-arch1-1
• Penrose Version 0.2

Additional context

(I will add log soon)

xprop output

_NET_ACTIVE_WINDOW(WINDOW): window id # 0x14001b6
_NET_WM_DESKTOP(CARDINAL) = 1
_NET_WM_USER_TIME(CARDINAL) = 6118232
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0xb6, 0x1, 0x40, 0x1, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0
XdndAware(ATOM) = BITMAP
_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
		window id # of group leader: 0x140004c
WM_TRANSIENT_FOR(WINDOW): window id # 0x140004c
_NET_WM_PID(CARDINAL) = 4762
WM_CLIENT_MACHINE(STRING) = "mitx"
WM_PROTOCOLS(ATOM): protocols
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x0, 0x0, 0x0, 0x0
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified location: 1561, 677
		program specified size: 454 by 82
		window gravity: NorthWest
WM_CLASS(STRING) = "jetbrains-clion", "jetbrains-clion"
WM_CLIENT_LEADER(WINDOW): window id # 0x1400008
_NET_WM_NAME(UTF8_STRING) = "win6"
WM_NAME(STRING) = "win6"

_NET_ACTIVE_WINDOW(WINDOW): window id # 0x14002dc
_NET_WM_DESKTOP(CARDINAL) = 1
_NET_WM_USER_TIME(CARDINAL) = 6409846
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG
_MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x3, 0x26, 0x1e, 0x0, 0x0
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0xdc, 0x2, 0x40, 0x1, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0
XdndAware(ATOM) = BITMAP
_NET_WM_ICON(CARDINAL) = 	Icon (80 x 80):
	(not shown)

_NET_WM_STATE(ATOM) = _NET_WM_STATE_SKIP_TASKBAR
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
		window id # of group leader: 0x140004c
WM_TRANSIENT_FOR(WINDOW): window id # 0x140004c
_NET_WM_PID(CARDINAL) = 4762
WM_CLIENT_MACHINE(STRING) = "mitx"
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS
WM_CLASS(STRING) = "jetbrains-clion", "jetbrains-clion"
WM_CLIENT_LEADER(WINDOW): window id # 0x1400008
_NET_WM_ICON_NAME(UTF8_STRING) = "Register New File Type Association"
WM_ICON_NAME(STRING) = "Register New File Type Association"
_NET_WM_NAME(UTF8_STRING) = "Register New File Type Association"
WM_NAME(STRING) = "Register New File Type Association"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		user specified location: 6, 6
		program specified location: 6, 6
		program specified size: 2560 by 1440
		program specified minimum size: 642 by 314
		window gravity: NorthWest

screenshot

logs of a short session where I start the IDE, and I go through bug cases https://paste.ofcode.org/HvuFMGRHjaVytzXc6fPuXm

[sminez]

Hey! Thanks for taking an interest in penrose.

Floating window support is patchy at the moment I'm afraid. They should be getting mapped at the position that they request unless it overlaps the status bar, in which case it should get bumped down but not resized. If you can provide the logs like you are mentioning and possibly some screenshots that would really help!

Running xprop on the windows in question and providing the output would also help if that's alright?

[doums]

Of course, I added some samples in the PR desc. In the man of dwm there is a note about Java, maybe this can help ?

ISSUES Java applications which use the XToolkit/XAWT backend may draw grey windows only. The XToolkit/XAWT backend breaks ICCCM-compliance in recent JDK 1.5 and early JDK 1.6 versions, because it assumes a reparenting window manager. Possible workarounds are using JDK 1.4 (which doesn't contain the XToolkit/XAWT backend) or setting the environment variable AWT_TOOLKIT=MToolkit (to use the older Mo‐ tif backend instead) or running xprop -root -f _NET_WM_NAME 32a -set _NET_WM_NAME LG3D or wmname LG3D (to pretend that a non-reparenting window manager is running that the XToolkit/XAWT backend can recognize) or when using OpenJDK setting the environment variable _JAVA_AWT_WM_NONREPARENTING=1.

[psychon]

Edit: Oh and: Nothing below explains why some windows are cropped to half their heights. I have no idea on that one.

penrose currently doesn't implement the following part of ICCCM (both windows in your xprop are unfocusable according to their WM_HINTS and one supports the WM_TAKE_FOCUS protocol while the other one does not):

WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS

See https://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7 for some details. The code as-is seems to assume the passive input model (it uses SetInputFocus and does not send WM_TAKE_FOCUS).

Welcome to the joy of X11 programming. If you thought that the WM decides which window gets the input focus, then you are wrong. The locally active input and globally active input model mean that the application has the final say in which of its windows gets the input focus. (There are lots of other fun pieces in ICCCM. Good luck finding a nice abstraction over WM_SIZE_HINTS, but that's not important as long as penrose cannot resize windows.)

In other news: WM_HINTS is basically its own little binary format. You need something like this to parse that property: https://github.com/meh/rust-xcb-util/blob/a15e660e8ffad5a7deff8511cf719568800c02e2/src/icccm.rs#L425 (and no, I do not know the specific API one has to call to get this, but I recently-ish had to write my own parser for this binary format for x11rb)

[scynthero]

When i try to open clion it displays a grey screen and doesn't respond to a kill_client key combination

[psychon]

Ah, the (in)famous Java grey screen bug. AFAIR Java expects a reparenting WM and does not do anything until it receives a ReparentNotify. Either that or it waits for some ConfigureNotify or so. Once upon a time, I actually digged into some Java source code to figure this out and ohh, the horrors. Java does not follow ICCCM. At all. It just makes up its own random rules and expects everyone to follow. And everyone uses reparenting wm.

Random relevant Google result: https://superuser.com/questions/400766/netbeans-java-shows-empty-window-in-tiling-window-manager-awesome-wm

(But I actually thought there was some WM variable one can set to make Java behave a little less bad...)

(And yes, Java actually tries to detect the kind of WM that is running and for some of them it behaves a little less standards incompatible.)

[auscyber]

Use this var, it works on xmonad _JAVA_AWT_WM_NONREPARENTING=1

[doums]

Sadly, It does not with Penrose.

[lomartins]

Use this var, it works on xmonad _JAVA_AWT_WM_NONREPARENTING=1

This variable worked for me. I put it in .zshenv

Thank you @AusCyberman!

[sminez]

Closing due to lack of activity and the fact that (as pointed out above) this is an infamous Java bug with non reparenting window managers.