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.

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

Motif normal border style hints are ignored #3678

Open
shachaf opened this Issue Apr 5, 2019 · 11 comments

Comments

Projects
None yet
4 participants
@shachaf
Copy link

commented Apr 5, 2019

I'm submitting a…

[x] Bug
[ ] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Current Behavior

When a window requests (using _MOTIF_WM_HINTS) to be drawn without borders, or with pixel borders, and then requests to be drawn with normal borders, the second request is ignored.

Expected Behavior

If the first request is respected, the second request should also be as well.

This issue was introduced in #2386 in response to #2385: A window had a "draw borders normally" motif hint, and it overrode the i3 configuration requesting a pixel border.

If the decision is that i3 configuration should take precedence in the case of BS_NORMAL hints, then BS_NORMAL should be taken to mean "what the border style would have been with no hints", not "what the border style currently is"

Alternatively there could be an option for border settings that take precedence over window hints. Or hints could be ignored entirely. But ignoring only hints requesting a normal border isn't a good solution.

Reproduction Instructions

#include <SDL2/SDL.h>
int main() {
  SDL_Init(SDL_INIT_VIDEO);
  SDL_Window *window = SDL_CreateWindow("test", 0, 0, 200, 200, 0);
  SDL_Event e;
  while (SDL_WaitEvent(&e) && e.type != SDL_QUIT) {
    if (e.type == SDL_KEYDOWN) {
      if (e.key.keysym.sym == 'a') SDL_SetWindowBordered(window, 0);
      if (e.key.keysym.sym == 'b') SDL_SetWindowBordered(window, 1);
    }
  }
}

Press 'a' and then 'b'; the window remains borderless. In Metacity (whose implementation window_update_motif_hints is designed to mimic), this is handled correctly.

Environment

I'm using i3 4.14.1, but this issue still exists in master: https://github.com/i3/i3/blob/next/src/handlers.c#L1187

@i3bot

This comment has been minimized.

Copy link

commented Apr 5, 2019

I don’t see a link to logs.i3wm.org. Did you follow https://i3wm.org/docs/debugging.html? (In case you actually provided a link to a logfile, please ignore me.)

@shachaf

This comment was marked as resolved.

Copy link
Author

commented Apr 5, 2019

This bug is still present in master -- I linked to the file and line. How do I reopen this issue?

@Airblader Airblader added 4.16 and removed unsupported-version labels Apr 5, 2019

@Airblader Airblader reopened this Apr 5, 2019

@Airblader

This comment was marked as resolved.

Copy link
Member

commented Apr 5, 2019

I reopened it. Sorry for that. :-)

@i3 i3 deleted a comment from i3bot Apr 5, 2019

@Airblader Airblader added the discussion label Apr 5, 2019

@yshui

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2019

Does i3 not monitor window property changes?

@shachaf

This comment has been minimized.

Copy link
Author

commented Apr 5, 2019

It does, in handle_motif_hints_change, which calls window_update_motif_hints and correctly identifies the new border style as BS_NORMAL, and then ignores it. See https://github.com/i3/i3/blob/next/src/handlers.c#L1187.

@yshui

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2019

Ah ok. Then it should be trivial to change that then, if we found that desirable.

@shachaf

This comment has been minimized.

Copy link
Author

commented Apr 6, 2019

Yes, it doesn't seem difficult to fix. Do people have an opinion on what the right behavior is?

@Airblader

This comment has been minimized.

Copy link
Member

commented Apr 7, 2019

Maybe we could see how window managers like awesome and Openbox handle this. If they give preference to the Motif hints, we should perhaps do the same.

@shachaf

This comment has been minimized.

Copy link
Author

commented Apr 8, 2019

awesome leaves interpreting motif hints to the user: https://awesomewm.org/apidoc/classes/client.html#client.motif_wm_hints.

Openbox tries to apply Motif hints "subtractively": https://github.com/danakj/openbox/blob/master/openbox/client.c#L1857-L1873. That is, if the hint specifies no decorations, it'll remove decorations, but it won't add decorations if the hint asks for normal decorations. This seems like a pretty reasonable behavior?

(It also respects KDE_NET_WM_WINDOW_TYPE_OVERRIDE (and NET_WM_WINDOW_TYPE_SPLASH, etc.): https://github.com/danakj/openbox/blob/master/openbox/client.c#L1596)

@Airblader

This comment has been minimized.

Copy link
Member

commented Apr 10, 2019

Yeah, the Openbox behavior sounds reasonable to me.

@shachaf

This comment has been minimized.

Copy link
Author

commented Apr 10, 2019

Right now Cons just have a single border_style value, which isn't enough information to figure out whether it was set due to user or window requests. Should this be separated into user_border_style and window_border_style or something like that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.