[Original comment by TonyC]

In the first case, I don't think it is obvious that the window manager should be handling these hints, but maybe a case could be made for it. Even the spec says that _NEW_WM_TYPE_NOTIFICATION is typically used with the override-redirect hint.

For example, the xfce4-notifyd sets this hint on its notifications. Those windows request no decorations and do not accept input focus. So why are they being managed? The lack of the override-redirect hint may reasonably be thought of as a mistake.

_NET_WM_STATE_MODAL seems like it should be floated because they are a kind of dialog box. But I think _NET_WM_STATE_SKIP_PAGE also needs some kind of argument for why those windows should be floated.

[Original comment by kerncece@…]

Now, what do applications set these E_WM_H hints for if not for the window manager?

Indeed, the spec says typically. But not necessarily (as otherwise override-redirect would be inferred and e.g. not have to be set with GDK function after the window has been realized ← additional complexity). What if xfce4-notifyd ever needs user focus (providing e.g. an optional set of buttons, or a text entry on the notification)? Does that necessarily requalify it as a DIALOG even if it still looks like a notification (albeit with feedback)? Why force it on programmers (i.e. override-redirect hint) and not just go with common sense on our part? IMHO, the spec is pretty clear on what window types can be considered floating.

i3 does already check the type hint when deciding whether the window want_floating, but it only considers DIALOG, UTILITY, TOOLBAR, and SPLASH. So why only those?

I'm not certain about _NET_WM_STATE_SKIP_TASKBAR/PAGER, but the only windows I know set this are transient DIALOGs (and NOTIFICATIONs, SPLASH screens, the DESKTOP, DOCKs, ...) and windows I set this manually for with devilspie. The latter I have sticky (in xfwm4) and "always on top".

Ordinarily, yes, windows that set _NET_WM_STATE_SKIP_TASKBAR/PAGER also set an appropriate type hint, but this may escape the mind of an unpedantic programmer who just uses their gtk_window_new().

This brings me to conclusion: Programmers make errors. Will we stumble over every one of them (and firmly insist that the onus is solely on the authors to correct them), or will we be fuzzy enough to handle the small flaws gracefully?

xfce4-whiskermenu-plugin creates a menu in a MODAL NORMAL window. Hopefully, this will change soon. Instructions for how to float xfce4-notifyd are years old. These are two examples of likely many. Lets fix this now? :-)

The associated code is attempted in patch #421.

The rationale for floating windows with equal min and max size hints is here:

• https://faq.i3wm.org/question/582/do-i3wm-autofloat/?answer=585#post-id-585
• http://standards.freedesktop.org/wm-spec/latest/ar01s09.html#NORESIZE

Replying to comment 2 by kerncece@…:

What if xfce4-notifyd ever needs user focus (providing e.g. an optional set of buttons, or a text entry on the notification)? Does that necessarily requalify it as a DIALOG even if it still looks like a notification (albeit with feedback)?
override_redirect windows can take user input (take clicks on workspaces in i3bar as an example), the question is whether they should be a managed window. For desktop notifications, I’d argue they should not be.

Why force it on programmers (i.e. override-redirect hint) and not just go with common sense on our part? IMHO, the spec is pretty clear on what window types can be considered floating.
I think we disagree on common sense and on the clarity expressed in that spec :).

i3 does already check the type hint when deciding whether the window want_floating, but it only considers DIALOG, UTILITY, TOOLBAR, and SPLASH. So why only those?
Because for those it’s actually clear, for many of the rest, not so much.

I'm not certain about _NET_WM_STATE_SKIP_TASKBAR/PAGER, but the only windows I know set this are transient DIALOGs (and NOTIFICATIONs, SPLASH screens, the DESKTOP, DOCKs, ...) and windows I set this manually for with devilspie. The latter I have sticky (in xfwm4) and "always on top".
Anecdotal evidence does not convince me here, sorry.

Ordinarily, yes, windows that set _NET_WM_STATE_SKIP_TASKBAR/PAGER also set an appropriate type hint, but this may escape the mind of an unpedantic programmer who just uses their gtk_window_new().
I don’t care. The case you describe is clearly an upstream bug that should be fixed upstream and not in every window manager out there.

This brings me to conclusion: Programmers make errors. Will we stumble over every one of them (and firmly insist that the onus is solely on the authors to correct them), or will we be fuzzy enough to handle the small flaws gracefully?
We will adhere to the spec and fix problems where they should be fixed. i3 will not become a collection of workarounds for the mistakes of app authors.

I also commented on the patch you submitted. Feel free to follow up with a patch for the clear cases (i.e. windows with equal min and max size and modal windows).

[Original comment by kerncece@…]

How can you be so blunt about app authors' mistakes. :(
The author sets

gtk_window_set_type_hint() to NOTIFICATION
gtk_window_set_position() to somewhere particular
gtk_window_set_decorated(false)

How is it not clear what the user wants? Not all libraries are made perfectly convenient to use. So neither should we be?

And sorry, but you got it backwards: It's just one window manager and all other apps. Discounting other tiling WMs, only i3 has this kind of a problem. :-)

And on what anecdotal evidence do you base your firm resolution that fixed-size windows should be afloat?

[Original comment by TonyC]

Replying to comment 4 by kerncece@…:

And on what anecdotal evidence do you base your firm resolution that fixed-size windows should be afloat?

That is not a difficult argument to make if you think it through.

According to the spec,

Windows can indicate that they are non-resizable by setting minheight = maxheight and minwidth = maxwidth in the ICCCM WM_NORMAL_HINTS property. The Window Manager MAY decorate such windows differently.

Here, "non-resizable" means "cannot be resized". Tiling a window generally resizes it. Therefore if the non-resizable aspect of the window is to be honored, it cannot be a tiling window. A window that is not a tiling window is a floating window. #

We don't require a formal mathematical proof for all feature requests, but sometimes we ask that you make a convincing argument for your use case. :)

In the case of notifications, my present thinking is both that they should not be managed and that if one accidentally asks to be, it should be set to floating. But I am not enough of an expert on software project management to understand the general implications of the assumptions implicit within that statement.

I have, however, had the experience of a project blowing up on me because of a lot of hacky code.

[Original comment by kerncece@…]

I understand. Thanks.

I propose, in addition to the agreed upon, that we also float NOTIFICATION and MENU. Here is why:

Most FOSS GUI software is written in (usually) one of the popular toolkits: GTK+, Qt, Tk, wxWidgets, ...
I'm an expert on exactly none of them, but I can see GTK+ is fairly popular. The weird thing is, GTK+ provides some widgets, like GtkComboBox, GtkMenu, GtkTooltip, and various functions for drag and drop, ... all of which set their respective window type hint AS WELL AS mark the realized GdkWindow as override-redirect. By default and all by themselves without programmer's notice.

The problem?

GTK+ doesn't seem to wrap notifications in any way. There is not a GtkNotification. And not everyone uses libnotify, it seems. Windows that are purported to be notification windows — set the appropriate type hint, renounce decorations, and position themselves absolutely, among other features, do not behave like notification windows only because the stupid programmer wasn't aware at the time, that in order to satisfy some exotic tiling WM they never heard of, they should be setting the override-redirect flag, on a GdkWindow after their widget is realized, preferably in a callback.

Similarly, GDK_WINDOW_TYPE_HINT_MENU is used in the wild (most results are dupes, though). While GTK internally uses DROPDOWN_MENU and POPUP_MENU on associated (override-redirect) widgets, MENU is left hanging. While the specification is clear: it doesn't say anything about floating, but it describes what a MENU is: "pinnable menu windows, respectively (i.e. toolbars and menus "torn off" from the main application)". Now if these are better tiled to a third of my screen than floated, I apologize for not seeing it. On additional note, MENU is given the same paragraph as TOOLBAR.

The thing is, as I see it, and I'm fairly new to this, we have a tiling WM here. Obviously normal rules about sizing and positioning windows don't apply. While there is abundant specification covering all the former aspects, there is nothing in EWMH about floating vs. tiling. The issue is strangely not explicitly covered or foresighted by the specification. This is why I say we have to rely on "common sense" (not what the spec expressively demands, but also how it interprets) and look at things as used in practice and how they make sense.

Please also answer my pending question in the CR, particularly the one about TODO. :) Thank you.

[Original comment by kerncece@…]

I uploaded a new patch, #427. It incorporates your feedback from the previous one and floats windows according to agreed upon conditions. Since all our current thinking seem to be in accord, I took the liberty to add notifications in as well. If that line is disputable and is the only one as such, you are welcome to merge without it. Thanks. :)

[Original comment by Kernc]

This ticket was fixed in commit http://c.i3wm.org/8ed95ae5:

Improved detection of windows that want floating

Windows that match the following criteria are floated by default:
- dialog, utility, toolbar, or splash windows,
- modal windows, or
- windows that have specified equal minimum and maximum size.

closes #1182