XMonadContrib: Tabbed layout bugs
Hi, I have been noticing a few bugs with the contributed Tabbed layout (1) Sometimes the tabs will be drawn on top of floating windows. I think this only happens when a floating window is opened in a location that overlaps with a tab, but I haven't found a systematic way of testing this. (2) The text in tabs does not properly handle Unicode. I am assuming my applications, for example Firefox, are using UTF8 in their title strings. In such cases the tab is simply blank. This occurs regardless of whether TabbedLayout is configured with a font that contains the offending glyph or not. The expected behavior when the font does not have the glyph would be to use a blank or box like many other applications do. (3) This is more of an enhancement, but it would be very useful to be able to specify XFT fonts in addition to "classical" X11 fonts for tabs.
On Thu, Jul 05, 2007 at 02:52:56PM -0400, Geoffrey Alan Washburn wrote:
Hi, I have been noticing a few bugs with the contributed Tabbed layout
Since David is getting married I'll try to have a look.
(1) Sometimes the tabs will be drawn on top of floating windows. I think this only happens when a floating window is opened in a location that overlaps with a tab, but I haven't found a systematic way of testing this.
I need a way to verify. I'll try to make some tests.
(2) The text in tabs does not properly handle Unicode. I am assuming my applications, for example Firefox, are using UTF8 in their title strings. In such cases the tab is simply blank. This occurs regardless of whether TabbedLayout is configured with a font that contains the offending glyph or not. The expected behavior when the font does not have the glyph would be to use a blank or box like many other applications do.
Haskell and C, plus Unicode is a big mess for me (especially the C side), but I'm interested in the problem and I will have a look and try to find a solution.
(3) This is more of an enhancement, but it would be very useful to be able to specify XFT fonts in addition to "classical" X11 fonts for tabs.
sorry but this is very far from being something I have an idea about. I have a feeling, though, and it says "No way!" All the best, Andrea
Andrea Rossato on 2007-07-05 22:22:08 +0200:
On Thu, Jul 05, 2007 at 02:52:56PM -0400, Geoffrey Alan Washburn wrote:
(1) Sometimes the tabs will be drawn on top of floating windows. I think this only happens when a floating window is opened in a location that overlaps with a tab, but I haven't found a systematic way of testing this.
I need a way to verify. I'll try to make some tests.
I just ran across something like this for the first time today and can reproduce it. I tried to run eog (a GNOME image viewer) from the command line with a URL and learned that I couldn't. eog popped up an error message with file not found, but for some reason, instead of being centered on the screen, it was up in the top left corner. Initially, the image was drawn underneath the tabs (but over my dzen status bar and the xterm that spawned it); when I meta-clicked to move it, the error window was again drawn correctly, and I could not make the window move back underneath the tabs. If the error window had been drawn in the center of the screen there wouldn't have been a problem. I don't know if that's eog's fault or xmonad's.
On Thu, Jul 05, 2007 at 04:13:48PM -0500, Alec Berryman wrote:
I just ran across something like this for the first time today and can reproduce it. I tried to run eog (a GNOME image viewer) from the command line with a URL and learned that I couldn't. eog popped up an error message with file not found, but for some reason, instead of being centered on the screen, it was up in the top left corner. Initially, the image was drawn underneath the tabs (but over my dzen status bar and the xterm that spawned it); when I meta-clicked to move it, the error window was again drawn correctly, and I could not make the window move back underneath the tabs.
If the error window had been drawn in the center of the screen there wouldn't have been a problem. I don't know if that's eog's fault or xmonad's.
Unfortunately I don't run any gnome package and I do not thing I'm going to install 2 millions packages to verify the bug with eog...;-) As far as I understand when a window should be placed above the tabs (that is to say, when that window should hide the tabs), and you do something (change focus or stuff like that) tabs show up and now cover the previous window. Am I getting it correctly? Andrea
Andrea Rossato on 2007-07-06 09:34:00 +0200:
On Thu, Jul 05, 2007 at 04:13:48PM -0500, Alec Berryman wrote:
I just ran across something like this for the first time today and can reproduce it. I tried to run eog (a GNOME image viewer) from the command line with a URL and learned that I couldn't. eog popped up an error message with file not found, but for some reason, instead of being centered on the screen, it was up in the top left corner. Initially, the image was drawn underneath the tabs (but over my dzen status bar and the xterm that spawned it); when I meta-clicked to move it, the error window was again drawn correctly, and I could not make the window move back underneath the tabs.
If the error window had been drawn in the center of the screen there wouldn't have been a problem. I don't know if that's eog's fault or xmonad's.
Unfortunately I don't run any gnome package and I do not thing I'm going to install 2 millions packages to verify the bug with eog...;-)
I also saw it happen with the GIMP last night; it could be that it's a GTK+ thing with error boxes. As I mentioned, it's easily reproducable; if you sent me a patch for xmonad to isoloate the information you're looking for, I'd be happy to run it for you. Alternatively, I've attached a small test case that uses GTK+ dialog boxes. You can compile it with: gcc `pkg-config --cflags gtk+-2.0` `pkg-config --libs gtk+-2.0` gtk-error-window-under-tabs.c You should just need GTK+ libs for that, not the full-blown GNOME stack.
As far as I understand when a window should be placed above the tabs (that is to say, when that window should hide the tabs), and you do something (change focus or stuff like that) tabs show up and now cover the previous window. Am I getting it correctly?
Mostly. Tabs should never be drawn on top of a newly-created window. Changing focus won't snap xmonad into the correct behavior, but attempting to move or resize the offending window will. I've attached a screenshot in case you can't compile the sample program.
On Fri, Jul 06, 2007 at 10:19:41AM -0500, Alec Berryman wrote:
You should just need GTK+ libs for that, not the full-blown GNOME stack.
as I said before I can reproduce it and I know where the problem lies, even though I seem not to be able to find a working solution (yet!). Still there's something I do not grasp yet: when I try to move those windows XMonad seems to start an infinite recursion... funny though...;-) I'll post a solution if and as soon as I find it. Andrea
On Fri, Jul 06, 2007 at 10:19:41AM -0500, Alec Berryman wrote:
GtkWidget *dlg = gtk_message_dialog_new(NULL, GTK_DIALOG_MODAL, GTK_MESSAGE_ERROR, GTK_BUTTONS_OK, "foo");
I'm puzzled... Attached you'll a patch. Actually two: the first, already sent here and awaiting review from XMonad developers, is unrelated but adds some configuration option (and I'm working on that version of tabbed. The second one is want I'd like you to try (you must apply them both). This is the only way I can operate from a plugin. I can move the window somewhere. Now, the code you created does not comply with gaps too. I did not check, but it should. So there are issues within XMonad too (a ticket should be open, I'd say), and issues related to the exported API: an external module should be able to do what tabbed.hs is doing, and floating window should comply, I think. Anyway, this is something that must be discussed with core XMonad developers. Ciao Andrea
Andrea Rossato on 2007-07-06 20:06:12 +0200:
On Fri, Jul 06, 2007 at 10:19:41AM -0500, Alec Berryman wrote:
GtkWidget *dlg = gtk_message_dialog_new(NULL, GTK_DIALOG_MODAL, GTK_MESSAGE_ERROR, GTK_BUTTONS_OK, "foo");
I'm puzzled...
Attached you'll a patch. Actually two: the first, already sent here and awaiting review from XMonad developers, is unrelated but adds some configuration option (and I'm working on that version of tabbed.
The second one is want I'd like you to try (you must apply them both). This is the only way I can operate from a plugin. I can move the window somewhere.
Now, the code you created does not comply with gaps too. I did not check, but it should. So there are issues within XMonad too (a ticket should be open, I'd say), and issues related to the exported API: an external module should be able to do what tabbed.hs is doing, and floating window should comply, I think.
Your patch doesn't completely fix the issue. When I run the sample program, the window is still created in the top-left corner, disregarding the gap and the tabs; the window is drawn under the tabs. When the mouse enters the window, the window is repositioned to be in the top-left corner of the screen, but below the gap. The window is still drawn under the tabs. This behavior doesn't have anything to do with focus as far as I can tell - the window pops up with a red border indicating focus and if I hit enter the box goes away. Again, if I start to move or resize the window, it is drawn correctly. If I try it with the "full" layout, I see a similar behavior - window drawn in the top-left without regard for the gap, but it doesn't seem as out of place since there are no tabs drawn over it. The window should be drawn in the center; I think you're right in that this isn't a tabbed issue but a XMonad floating layout one.
On Thu, Jul 05, 2007 at 04:13:48PM -0500, Alec Berryman wrote:
I just ran across something like this for the first time today and can reproduce it. I tried to run eog (a GNOME image viewer) from the command line with a URL and learned that I couldn't. eog popped up an error message with file not found, but for some reason, instead of being centered on the screen, it was up in the top left corner. Initially, the image was drawn underneath the tabs (but over my dzen status bar and the xterm that spawned it); when I meta-clicked to move it, the error window was again drawn correctly, and I could not make the window move back underneath the tabs.
I think I can now reproduce it: select a tiled layout and open at least 3 windows. Focus a small one on the upper corner, float it. Switch to the tabbed layout, and there you go: tabs are over the floating window. Is this the problem you were reporting? Now I must find a solution ... Andrea
On Thu, Jul 05, 2007 at 02:52:56PM -0400, Geoffrey Alan Washburn wrote:
(2) The text in tabs does not properly handle Unicode. I am assuming my applications, for example Firefox, are using UTF8 in their title strings. In such cases the tab is simply blank. This occurs regardless of whether TabbedLayout is configured with a font that contains the offending glyph or not. The expected behavior when the font does not have the glyph would be to use a blank or box like many other applications do.
This problem is not really XMonad specific, but relays in the interaction between Haskell and Xlib. X11-extras export fetchName, a wrapper for XFetchName. Unfortunately this function handles only iso-8859-1 text data, so it is not possible to retrieve the window's name if it contains multi byte characters. Have a look here for a clearer explanation: http://www.debian.org/doc/manuals/intro-i18n/ch-examples.en.html#s13.1.8 Solving it means digging into the XTextProperty with XGetWMName(), and so writing all the library support for it. I'm sorry but this is out of the reach of my knowledge. Maybe Spencer can have a look... Ciao Andrea
Andrea Rossato wrote:
This problem is not really XMonad specific, but relays in the interaction between Haskell and Xlib.
X11-extras export fetchName, a wrapper for XFetchName. Unfortunately this function handles only iso-8859-1 text data, so it is not possible to retrieve the window's name if it contains multi byte characters.
Have a look here for a clearer explanation: http://www.debian.org/doc/manuals/intro-i18n/ch-examples.en.html#s13.1.8
Solving it means digging into the XTextProperty with XGetWMName(), and so writing all the library support for it. I'm sorry but this is out of the reach of my knowledge.
Maybe Spencer can have a look...
Okay, I suspected it might be more of an issue with the X11 bindings than xmonad itself. I may look into this myself, after finishing my dissertation, if someone else hasn't resolved the problem in the meantime.
participants (3)
-
Alec Berryman -
Andrea Rossato -
Geoffrey Alan Washburn