Re: Is it possible to foce Java applications to conform to the layout?
The parent is a window that is painted and immediately made invisible on the screen, it's hard to notice it. From what I could see it didn't look like it fit into the layout either. Is there anything that can be done without changing the source code of KeePassX? Best regards, Kent On Tue, May 24, 2011 at 21:56, Uli Schlachter psyc...@znc.in wrote: On 22.05.2011 13:08, Kent Larsson wrote: I use some Java programs, like KeePassX and my Bank ID, and I've noticed that their windows are created on top of the other windows and are not fitting into the layout I am using at the moment. Is there something I can do to force them to conform to the layout I am using? In the case of KeePassX the first window, asking me for a password and optionally a keyfile is displaying the problem described above. However, the next window that opens indeed fits into the layout. I don't know if that information is of any help, but I wrote it just in case. :-) Right now, Kent Larsson wrote: [...] I'll show you some KeePassX data. xprop for the first Window of KeePassX asking me for password and/or key: [...] _NET_WM_STATE(ATOM) = _NET_WM_STATE_MODAL WM_TRANSIENT_FOR(WINDOW): window id # 0x197 [...] _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_NORMAL [...] When closing that Window KeePassX opens the normal usage Window. It behaves as it should and fits into the layout. The xprop for it reads: [...] _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL The password-asking window is a dialog in state modal. That means that it's parent (0x197, dunno which window that is) is unusable as long as this window is open. As a result, awesome will make the client floating and place it above its parent. So what is the parent client here? The second window has type modal and no _NET_WM_STATE, so it acts like a normal window. :-) So, what is the parent and why does this not have the right behavior? Cheers, Uli -- - He made himself, me nothing, you nothing out of the dust - Er machte sich mir nichts, dir nichts aus dem Staub -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Is it possible to foce Java applications to conform to the layout?
On 29.05.2011 17:10, Kent Larsson wrote: The parent is a window that is painted and immediately made invisible on the screen, it's hard to notice it. From what I could see it didn't look like it fit into the layout either. Is there anything that can be done without changing the source code of KeePassX? Make a rule that calls awful.client.floating.set(c, false) on the client. I think that should make it be tiled. Cheers, Uli -- Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Is it possible to foce Java applications to conform to the layout?
On 22.05.2011 13:08, Kent Larsson wrote: I use some Java programs, like KeePassX and my Bank ID, and I've noticed that their windows are created on top of the other windows and are not fitting into the layout I am using at the moment. Is there something I can do to force them to conform to the layout I am using? In the case of KeePassX the first window, asking me for a password and optionally a keyfile is displaying the problem described above. However, the next window that opens indeed fits into the layout. I don't know if that information is of any help, but I wrote it just in case. :-) Right now, Kent Larsson wrote: [...] I'll show you some KeePassX data. xprop for the first Window of KeePassX asking me for password and/or key: [...] _NET_WM_STATE(ATOM) = _NET_WM_STATE_MODAL WM_TRANSIENT_FOR(WINDOW): window id # 0x197 [...] _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DIALOG, _NET_WM_WINDOW_TYPE_NORMAL [...] When closing that Window KeePassX opens the normal usage Window. It behaves as it should and fits into the layout. The xprop for it reads: [...] _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL The password-asking window is a dialog in state modal. That means that it's parent (0x197, dunno which window that is) is unusable as long as this window is open. As a result, awesome will make the client floating and place it above its parent. So what is the parent client here? The second window has type modal and no _NET_WM_STATE, so it acts like a normal window. :-) So, what is the parent and why does this not have the right behavior? Cheers, Uli -- - He made himself, me nothing, you nothing out of the dust - Er machte sich mir nichts, dir nichts aus dem Staub -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Is it possible to foce Java applications to conform to the layout?
Hi! I use some Java programs, like KeePassX and my Bank ID, and I've noticed that their windows are created on top of the other windows and are not fitting into the layout I am using at the moment. Is there something I can do to force them to conform to the layout I am using? In the case of KeePassX the first window, asking me for a password and optionally a keyfile is displaying the problem described above. However, the next window that opens indeed fits into the layout. I don't know if that information is of any help, but I wrote it just in case. :-) Best regards, Kent -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
Re: Is it possible to foce Java applications to conform to the layout?
On 22.05.2011 13:08, Kent Larsson wrote: In the case of KeePassX the first window, asking me for a password and optionally a keyfile is displaying the problem described above. However, the next window that opens indeed fits into the layout. I don't know if that information is of any help, but I wrote it just in case. :-) Open a terminal, run xprop, click on one of the evil windows and tell us what xprop tells you. I bet java is (once again) being stupid. Uli -- Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? -- To unsubscribe, send mail to awesome-unsubscr...@naquadah.org.
