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

Handle WM_CHANGE_STATE client requests #1279

Closed
i3bot opened this issue Jun 18, 2014 · 6 comments
Closed

Handle WM_CHANGE_STATE client requests #1279

i3bot opened this issue Jun 18, 2014 · 6 comments
Assignees
@i3bot
Labels
4.8

Comments

@i3bot
Copy link

i3bot commented Jun 18, 2014

[Originally reported by i3-new-ticket]
(Hi,

Using the latest next branch I have noticed with two applications;

HandBrake 0.9.9
KeePassX 0.4.3

When I start them this message;

[i3bar/src/xcb.c:527] ERROR: Error getting _XEMBED_INFO property: error_code 3

[i3bar/src/xcb.c:542] ERROR: Window 0280004b violates the XEMBED protocol,
_XEMBED_INFO not set

I have not noticed any problems with keepassx, but with HandBrake the system tray
icon is suppose to minimize the application to the system tray so it is not
visible on the workspace, and then if you click it again, opens HandBrake back to
the workspace.

  1. HandBrake is open and visible on the workspace, now click the system tray icon
    and HandBrake is no longer visible on workspace and sent to the system tray.
  2. Click the system tray icon again and this time HandBrake is opened back up and
    appearing on the workspace.

I've been told this is an upstream bug from GTK, and nothing the HandBrake
developers can do

But I do not see this problem on any other DE/WM, so then it makes me wonder, can
the system tray icon be made to work properly from changes made to i3? Because it appears that something i3 is doing that no other DE/WM is doing is causing this bug.

What is i3 doing different here that this is the only Window Manager with a system
tray I see this problem in?

I understand i3 might be a tiling window manager, but the end-user also has a
statusbar and system tray in i3 to use, and it would be nice to get this working.

I hope it might be possible that the i3 team can change something here to make
this work.

Thank you very much for your time and consideration over this, and looking into
it...
@i3bot
Copy link
Author

i3bot commented Jun 18, 2014

[Original comment by TonyC]

I looked into this in #1262.

As for handbrake, clicking on the tray icon gives us a _NET_WM_STATE_HIDDEN request, which means "toggle the hidden state of the window" which is very difficult to handle in i3, because we don't know what to do (indeed, the spec even says a window manager should probably ignore these requests).

http://standards.freedesktop.org/wm-spec/wm-spec-latest.html

_NET_WM_STATE_HIDDEN should be set by the Window Manager to indicate that a window would not be visible on the screen if its desktop/viewport were active and its coordinates were within the screen bounds. The canonical example is that minimized windows should be in the _NET_WM_STATE_HIDDEN state. Pagers and similar applications should use _NET_WM_STATE_HIDDEN instead of WM_STATE to decide whether to display a window in miniature representations of the windows on a desktop.

So they are essentially telling us to "minimize" the window, but we have no concept of this in i3, nor do we claim support of it.

@i3bot
Copy link
Author

i3bot commented Jun 18, 2014

[Original comment by anonymous]

These applications I'll list I've used and they all minimize to the tray in i3;

cmst
Hexchat
KeePassX
transmission

I'm sure if I dig around I can find more apps that will minimize to the tray.

There seems to be some type of support going on for these apps, so I'm not sure why this can't work in HandBrake as well...

When you say there is no concept of this in i3, it's working for other apps... Hmm

@i3bot
Copy link
Author

i3bot commented Jun 18, 2014

[Original comment by anonymous]

I forgot to mention, I'm a bit confused that i3 has a system tray, yet i3 developers are going to tell the end-users you really don't have support for it?

Then I don't get why it's there if it's not going to be supported?

Personally I really appreciate having the system tray and I thank all of you invloved for making this to PLEASE keep it alive!

I'm not a coder, but the way I'm seeing this is just a lack of support for HandBrake, and possibly some other apps is all, not to say there isn't system tray support in i3 because there is, use Transmission and see the support. :)

THANKS

@i3bot
Copy link
Author

i3bot commented Jun 18, 2014

[Original comment by TonyC]

Ok, I looked at it again and _NET_WM_STATE_HIDDEN is not the request we should be looking at. Instead it is the WM_CHANGE_STATE request, which I think we can handle.

More info:

http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.4

@i3bot
Copy link
Author

i3bot commented Jun 19, 2014

[Original comment by anonymous]

Look forward to seeing the changes and testing out.

Thanks TonyC you ROCK! :)

@i3bot
Copy link
Author

i3bot commented Jun 24, 2014

[Original comment by Tony Crisci]

This ticket was fixed in commit http://c.i3wm.org/136b3e34:

Handle WM_CHANGE_STATE requests for iconic state

http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.4

 > IconicState - The client's top-level window is iconic (whatever that
 > means for this window manager). The client can assume that its
 > top-level window is not viewable, its icon_window (if any) will be
 > viewable and, failing that, its icon_pixmap (if any) or its
 > WM_ICON_NAME will be displayed.

For these requests, we just close the window.

fixes #1279

@i3bot i3bot self-assigned this Jun 24, 2014
stapelberg pushed a commit that referenced this issue Feb 4, 2015
@acrisci @stapelberg
Handle WM_CHANGE_STATE requests for iconic state
136b3e3 
http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.4

 > IconicState - The client's top-level window is iconic (whatever that
 > means for this window manager). The client can assume that its
 > top-level window is not viewable, its icon_window (if any) will be
 > viewable and, failing that, its icon_pixmap (if any) or its
 > WM_ICON_NAME will be displayed.

For these requests, we just close the window.

fixes #1279
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@i3bot i3bot

Labels
4.8
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@i3bot