P2D and P3D renderers don't set `WM_CLASS` for Linux

processing-bot commented 1 year ago

Created by: @ColdMacaroni

Description

When running a sketch that uses the P2D or P3D renderer. The WM_CLASS window variable is not set. This makes it difficult (impossible?) to set window rules for the resulting window. (For example, making it so a tiling window manager makes the window float by default, instead of resizing it.)

Expected Behavior

WM_CLASS should be set to "Processing", "processing-sketch" or similar. For reference, the main processing app has a WM_CLASS of "Processing", "Processing" and a sketch with the default renderer has a WM_CLASS of "processing-core-PApplet", "processing-core-PApplet".

Current Behavior

The WM_CLASS variable is not set. (I don't mean empty, it just doesn't exist)

Steps to Reproduce

Run a sketch that uses P2D or P3D as a renderer. Example code:

size(128, 128, P2D);

Inspect the window class with xprop (or another similar tool). To use xprop, simply run it on a terminal and click on the window. You can also pipe it into grep to filter out the other variables: xprop | grep WM_CLASS

Your Environment

Processing version: 4.3 (1293)
Operating System and OS version: Arch Linux (kernel 6.4.12-arch1-1)
Other information:
- Xorg server version: 21.1.8
- Tested with the following window managers:
  - AwesomeWM
  - XMonad
  - Hyprland (through XWayland)

processing-bot commented 11 months ago

Replied by @icq4ever on Dec 13, 2023, 18:00

I tested with xprop command on linux as follow

xprop -name "sketch_231214a" -f WM_CLASS 8s -set WM_CLASS "Processing"

and confirmed that WM_CLASS added on canvas(running window). now I'm researching how can I add this on source code.

processing-bot commented 11 months ago

Replied by @icq4ever on Dec 13, 2023, 18:04

https://stackoverflow.com/a/29218320 this thread show where can start point. and similar codes already added here . hmm..

https://github.com/kfeuz/processing/commit/3f79ddddb316a9c1abc20f2e8a3514a344611a49?diff=unified&w=0#diff-6428616152344f7571cc03d4749adf9c77757cd02f9e4c1ccffc0f843d392388

this is the main sketch window maybe ?

plopez01 commented 2 days ago

I stumbled upon this myself and could reproduce the issue checking with xprop. I'm gonna try to fix it.

hx2A commented 2 days ago

@plopez01 I'd love to see this fixed. Even if you don't find a solution, please post what you learn so someone else can build on what you figure out.

plopez01 commented 1 day ago

Okay, I've done some digging and this is what I got until now.

The window creation process

The first thing I did was track down the window creation when using the P2D or P3D renderer.

When one of this renderers is used a specific implementation of a PSurface interface is used: PSurfaceJOGL. This implementation instead of using AWT to handle window creation, it uses NEWT, a windowing toolkit which is provided by JOGL (the library used to provide OpenGL bindings for Java).

So when initFrame(...) is called in the PSurfaceJOGL, window creation is handled by a sub-call to initWindow(),

which calls to NewtFactory.createWindow(...) ,
which in turn will call create() on a specific window implementation, in this case it's very probably jogamp.newt.driver.x11,
which calls to CreateWindow with a bunch of window paremeters, this is where I would like to note this x11 WindowDriver class actually has a WINDOW_CLASS_NAME field with a default value of "NewtWindow", but AFAIK it's not used anywhere, and especially not passed down the window creation pipeline.
which in turn calls to a native method implemented in C than can be found here.

Pheew, that was a lot of calls, but we finally get to the bottom and we can see the window creation process and especially a call to createJavaWindowProperty(...) which calls to XChangeProperty. There are a bunch of calls to this function that set X parameters like the window icon, or set the WM_NAME, which we can see is actually being set to the sketch name right now.

In Conclusion

I think the problem is being caused because NEWT doesn't set the WM_CLASS property (maybe they intended at some point because of the unused WINDOW_CLASS_NAME but never actually got to doing it). This differs from the behaviour with the default renderer which uses the PSurfaceAWT, in this case X properties I'm guessing are handled by AWT itself and WM_CLASS is set.

Possible solutions

A possible solution would be to raise an issue in the JOGL repo and maybe a PR to implement handling of the WM_CLASS property, maybe with it's own setter just as setTitle. I could try to create this PR but I don't know if it would be accepted, or how long it would take as it's not just a bug, it expands the public API and would require some thinking on how it should be organized.
Another option that would not requiere to intervene in external libraries would be to figure out a way to set the X window property ourselves, I think this might be more plausible. I will do some reaserch and keep this updated.

Please do let me know what you think about this. If missed anything or anyone has any suggestions or comments I will greatly appreciate them!

Funny story

This happened to me the first time I tried to post this comment. Github decieded to play it funny and failed the request to post this comment, when I switched to the "Write" panel to copy what I wrote and try again, it deleted everything, (picture my face thinking I had to write it all again). Then I had a revelation, went to about:processes, looked at the tab PID, went to the Task Manager and dumped the process memory, then I was able to recover all the message from there! (This is actually the second time a memory dump has saved me from losing data). Edit: Later I saw It actually did post my first message... facepalm

processing / processing4