Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Tricky minimize/maximize/restore things in rootless #1015

Open
dimbor-ru opened this issue Apr 30, 2021 · 20 comments · Fixed by #1016
Open

Tricky minimize/maximize/restore things in rootless #1015

dimbor-ru opened this issue Apr 30, 2021 · 20 comments · Fixed by #1016

Comments

@dimbor-ru
Copy link

Some programs are now ashamed to use wm and its buttons to perform these operations. They at least continue to use the ICCCM and Extended WM hints specifications. Namely WM_CHANGE_STATE and _NET_WM_STATE client messages sent to root window. Attached are two green buttons to illustrate this "outrageous" behavior. It not worked in rootless on linux nx-client (naturally on nxwin too).

I started exploring ways to solve the problem. Can be forcibly replaced root window in these client messages and deliver them to real wm. The only thing that stops me is that a similar question has already been discussed here: #830
I don't want to break something globally with my future patches and I want to hear your opinions.
@uli42
Copy link
Member

uli42 commented Apr 30, 2021

I have compiled your test program. It is working fine locally, it is also working fine in a desktop NX session. In a rootless session that has been started from inside the desktop session the buttons of the testprogram seem to have no effect. However, the window manager controls for minimizing and maximizing are still working. Just to be sure: is this the problem you are describing or is this another problem?

I have not checked the source yet.

@dimbor-ru
Copy link
Author

Exactly. It is this problem that is being described. Native wm controls are left for contrast only.

@dimbor-ru
Copy link
Author

Here's another way to reproduce the problem: In the x terminal rootless session try to operate youreself window by xclimsg.

@uli42
Copy link
Member

uli42 commented Apr 30, 2021

Can we simulate your suggested fix with xclimsg?

@dimbor-ru
Copy link
Author

dimbor-ru commented Apr 30, 2021 •
edited
Loading

Firstly, the fix is still only my fantasy ;)

For example, the maximization case. Simulation done if command xclimsg -m -w <realx_winid> _NET_WM_STATE 1 _NET_WM_STATE_MAXIMIZED_VERT _NET_WM_STATE_MAXIMIZED_HORZ starting on client of real x-server. On nx-session with <nx_winid> of same window command do nothing. These client messages are filtered by nxagent if xev not lying.

Did I answer the question or did not understand it?

@uli42
Copy link
Member

uli42 commented Apr 30, 2021 via email

@dimbor-ru
Copy link
Author

I am completely confused. !M uses the following terminology and we have the chain: local x server - local proxy (~nxcomp) - remote proxy (~nxagent) - x-client (our program). Code on local side named nx client, on remote side - nx server. I will now assume that "proxy side"==nx server side. Command xclimsg -t <local_root_wid> -w <any_wid> ... cause error now. Error of failed request: BadWindow (invalid Window parameter) local_root_wid not known to remote.

@uli42
Copy link
Member

uli42 commented May 1, 2021 via email

@uli42
Copy link
Member

uli42 commented May 1, 2021

Ok, after reading your description again I think you have done the right thing from the beginning. I can replicate your result:

$ nxagent -R :55 -nxrealwindowprop -reportwids -reportprivatewids
...
NXAGENT_WINDOW_ID: PRIVATE_WINDOW,WID:[0xc40004e],INT:[0x200001]  <---
NXAGENT_WINDOW_ID: PRIVATE_WINDOW,WID:[0xc400050],INT:[0x200003]
NXAGENT_WINDOW_ID: PRIVATE_WINDOW,WID:[0xc400051],INT:[0x200004]
...

(:55 is the nxagent's display number, 0x200001 is the internal window id,0xc40004e is the external id)

$ DISPLAY=:55 xclimsg -m -w 0x200001  _NET_WM_STATE 1 _NET_WM_STATE_MAXIMIZED_VERT _NET_WM_STATE_MAXIMIZED_HORZ

-> nothing happens

$ DISPLAY=:0 xclimsg -m -w 0xc40004e  _NET_WM_STATE 1 _NET_WM_STATE_MAXIMIZED_VERT _NET_WM_STATE_MAXIMIZED_HORZ

-> window is maximized

@uli42
Copy link
Member

uli42 commented May 1, 2021

While playing around with this I came across this: Your source code calls XInternAtom(..., True). In a fresh rootless session this cannot work as the atoms will be missing if there's no window manager. So you should call XInternAtom() with False.

@dimbor-ru
Copy link
Author

Ok, after reading your description again I think you have done the right thing from the beginning. I can replicate your result:
...

Very good!

  1. Our terminology is synchronized now. (Like local and remote atoms ;)
  2. I learned a lot of interesting about command line options. I would search there lastly, It's true.
  3. The idea of fix has the right to life. Presumable exposure point - nxagentHandleClientMessageEvent().

Your source code calls XInternAtom(..., True). In a fresh rootless session this cannot work as the atoms will be missing if there's no window manager. So you should call XInternAtom() with False.

You're right. I tried to imitate the behavior of proprietary software only. And I can't be sure that there is not written in the same way.

Thanks for all items. I will take a timeout for writing a patch.

@dimbor-ru
Copy link
Author

Presumable exposure point - nxagentHandleClientMessageEvent().

Ups! Because of excessive optimism, I confused the direction of the messages. This is normal for me.
The necessary client messages are safely caught in NXEvents.c, ProcSendEvent()
In this regard, I have another question. Will the community beat me if I try to change wids in the request directly? Or do I need to dance there like nxagentSendNotify()?

@uli42
Copy link
Member

uli42 commented May 2, 2021

Yes and no. You can use nxagentLocalToRemoteAtom() to map the atoms and for the window mapping stuff there are lots of nxagentWindow* macros.

I have tried to implement this (in ProcSendEvent() yesterday but I failed. It send the message but the WM did not react on it. Hope the best for your approach.

uli42 added a commit to uli42/nx-libs that referenced this issue May 2, 2021
@uli42
Forward ClientMessages to nxproxy side
6268bb2 
This should help with clients requesting window manager actions like
maximizing or minimizing. This is a first version as it only handles
messages of type WM_STATE_CHANGE and _NET_WM_STATE. But ICCCM and EWMH
know some more.

The other direction, setting of properties by the WM, is already
implemented in Rootless.c.

Fixes ArcticaProject#1015
@uli42
Copy link
Member

uli42 commented May 2, 2021

I have done some tests and now have a patch ready, please have a look.

@dimbor-ru
Copy link
Author

Nuts! Everything is working. You have saved a lot of my time. Now I can add handling these messages to nxwin and its pseudo-wm. But in reality, to steal from dad-xwin creatively.

@dimbor-ru
Copy link
Author

I have added client messages handling to nxwin multiwindow mode. There, the code is no longer "academic", but is still used in OpenNX for Windows and in NXClientCE. No problems have been noticed yet.

@uli42
Copy link
Member

uli42 commented May 7, 2021 via email

@dimbor-ru
Copy link
Author

It feels good. I do not know what to find fault with. Thanks again.

uli42 added a commit to uli42/nx-libs that referenced this issue May 16, 2021
@uli42
Forward ClientMessages to nxproxy side
5d1c220 
This should help with clients requesting window manager actions like
maximizing or minimizing. This is a first version as it only handles
messages of type WM_STATE_CHANGE and _NET_WM_STATE. But ICCCM and EWMH
know some more.

The other direction, setting of properties by the WM, is already
implemented in Rootless.c.

Fixes ArcticaProject#1015
@uli42 uli42 mentioned this issue May 16, 2021
Merged
sunweaver pushed a commit to uli42/nx-libs that referenced this issue Jun 8, 2021
@uli42 @sunweaver
Forward ClientMessages to nxproxy side
9e10ed3 
This should help with clients requesting window manager actions like
maximizing or minimizing. This is a first version as it only handles
messages of type WM_STATE_CHANGE and _NET_WM_STATE. But ICCCM and EWMH
know some more.

The other direction, setting of properties by the WM, is already
implemented in Rootless.c.

Fixes ArcticaProject#1015
dimbor-ru pushed a commit to dimbor-ru/nx-libs that referenced this issue Aug 16, 2022
@uli42 @dimbor-ru
Forward ClientMessages to nxproxy side
fbc6b28 
This should help with clients requesting window manager actions like
maximizing or minimizing. This is a first version as it only handles
messages of type WM_STATE_CHANGE and _NET_WM_STATE. But ICCCM and EWMH
know some more.

The other direction, setting of properties by the WM, is already
implemented in Rootless.c.

Fixes ArcticaProject#1015
@uli42
Copy link
Member

uli42 commented Apr 8, 2024

I have come across a problem with this patch: I was trying to run xxdiff 50b1 (https://github.com/blais/xxdiff resp. https://furius.ca/xxdiff/) and ended up with a crashing nxagent I looks like pWin is unset in Events.c:4511.

@uli42 uli42 reopened this Apr 8, 2024
@uli42
Copy link
Member

uli42 commented Apr 8, 2024 

#0  ForwardClientMessage (client=0x2d47b20, stuff=0x2fb6708) at Events.c:4511
#1  0x0000000000423af7 in ProcSendEvent (client=0x2d47b20) at NXevents.c:430
#2  0x0000000000431ce3 in Dispatch () at NXdispatch.c:488
#3  0x000000000040f10a in main (argc=20, argv=0x7ffe1a48e478, envp=<optimized out>) at main.c:350

This happens because pWin is 0x0 in ForwardClientMessage. I can trigger this by running xxdiff 50b1 from https://github.com/blais/xxdiff on Rocky8.9.

@uli42 uli42 reopened this Apr 8, 2024
@uli42 uli42 mentioned this issue Apr 8, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Forward ClientMessages to nxproxy side uli42/nx-libs
2 participants
@uli42 @dimbor-ru