- xmonad - Haskell.org

Issue 150 in xmonad: Invisible cursor with XFT font in Prompt
by codesite-noreply＠google.com 11 Mar '08

11 Mar '08

Issue 150: Invisible cursor with XFT font in Prompt http://code.google.com/p/xmonad/issues/detail?id=150 Comment #3 by byorgey: No problem! I'll close this ticket then. Issue attribute updates: Status: Fixed -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 150 in xmonad: Invisible cursor with XFT font in Prompt
by codesite-noreply＠google.com 11 Mar '08

11 Mar '08

Issue 150: Invisible cursor with XFT font in Prompt http://code.google.com/p/xmonad/issues/detail?id=150 Comment #2 by uhh.ag.econ: It works. Sorry for the bogus issue; I forgot to touch my xmonad.hs after pulling and recompiling xmonad (and I just got back from vacation, so I was a little behind). -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 151 in xmonad: XMonad needs to spot resize events in non-floating windows -- dons
by codesite-noreply＠google.com 11 Mar '08

11 Mar '08

Issue 151: XMonad needs to spot resize events in non-floating windows -- dons http://code.google.com/p/xmonad/issues/detail?id=151 New issue report by mj.fialka: What steps will reproduce the problem? 1. In tiled layout open XTerm window and run for example Midnight Commander in it in order to have some good visual reference. 2. Then change the font size of the running XTerm on-the-fly (i.e. from menu, alt-right-mouse on running XTerm's window). 3. Do the same with floating XTerm and check the difference. See? 4. In tiled layout you can also try to "mod-shift-space" (reset) the layouts to defaults to see it also have no expected effect on the XTerm (and the application running inside it). What is the expected output? What do you see instead? We can see correct behaviour in the floating XTerm because XMonad seems (or rather: it seems to me) to handle this part of windowing differently when "managing" floating windows and when managing tiled windows. In tiled layout the geometry changes requested by the application such as XTerm itself seems not be noticed by XMonad at all. I would expect XMonad should notice the geometry change and reflect it "somehow". I think the action taken when XMonad notices the event of window geometry change request should be the same as it is when new one window is added to the layout or when a window is removed from the layout because in these cases XTerm windows "resize" correctly and so do programs running inside of the XTerms (such as the mentioned example Midnight Commander). Finally here is the #xmonad IRC talk snippet with dons where you can see what he thinks about it: ---snip--- 19:31 : dons: ok. create a ticket for this. basically, we need to spot resize events in non-floating windows 19:31 : dons: i think this should be easy 19:31 : dons: and may be a subset of some other bugs ---snip--- Thank you very much for solving this issue. (I realized I simply can not live without changing XTerm fonts on-the-fly, although not only XTerm can behave this way:) What version of the product are you using? On what operating system? DARCS version of XMonad running on Debian/Etch GNU/Linux OS. Please provide any additional information below. If this error is due to a module from XMonadContrib, please tag this issue with 'Component-Contrib' below. Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 150 in xmonad: Invisible cursor with XFT font in Prompt
by codesite-noreply＠google.com 11 Mar '08

11 Mar '08

Issue 150: Invisible cursor with XFT font in Prompt http://code.google.com/p/xmonad/issues/detail?id=150 Comment #1 by byorgey: I recently pushed some patches from arossato to fix this issue. Does the issue still exist with the latest darcs, or can this ticket be closed? Issue attribute updates: Status: Accepted -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 150 in xmonad: Invisible cursor with XFT font in Prompt
by codesite-noreply＠google.com 11 Mar '08

11 Mar '08

Issue 150: Invisible cursor with XFT font in Prompt http://code.google.com/p/xmonad/issues/detail?id=150 New issue report by uhh.ag.econ: What steps will reproduce the problem? 1. Enable XFT support in XMonadContrib. 2. Set the XPromptConfig font to a TrueType font. 3. Activate the prompt. What is the expected output? What do you see instead? The cursor in the prompt should be visible. Instead, the cursor is invisible. What version of the product are you using? On what operating system? xmonad from darcs on Ubuntu Gutsy. Please provide any additional information below. It seems to be printing the character under the cursor with bgColor as both the forground and background (I was able to see the the edge of an "f" under the cursor overwriting the edge of a preceeding "d", so I know that it is being drawn). Also, the visual length of the string changes as the cursor moves. While scrolling through the string, the portion after the cursor wiggles left and right by a few pixels. When the cursor reaches the beginning of the line, the length shortens much more. If this error is due to a module from XMonadContrib, please tag this issue with 'Component-Contrib' below. XMonadContrib Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 145 in xmonad: Misplaced menus in openoffice with gtk widgets
by codesite-noreply＠google.com 09 Mar '08

09 Mar '08

Issue 145: Misplaced menus in openoffice with gtk widgets http://code.google.com/p/xmonad/issues/detail?id=145 Comment #2 by itsjdh: With and without. I'll file a bug report against openoffice. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

my proposal for a Xinerama safe PerWorkspace
by Andrea Rossato 09 Mar '08

09 Mar '08

Hi, this is my proposal for a Xinerama safe PerWorkspace. It includes a new LayoutClass method: runLayout :: Workspace WorkspaceId (layout a) a -> Rectangle -> X ([(a, Rectangle)], Maybe (layout a)) This is just some code moved around: Fri Feb 22 18:58:15 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * runLayout is now a LayoutClass method and takes the Workspace and the screen Rectangle M ./XMonad/Core.hs -7 +7 M ./XMonad/Operations.hs -5 +5 This is the patch to PerWorkspace: Fri Feb 22 18:59:54 CET 2008 Andrea Rossato <andrea.rossato(a)unibz.it> * PerWorkspace: reimplemented using runLayout This way we have a Xinerama safe PerWorkspace and the emptyLayout method for free. M ./XMonad/Layout/PerWorkspace.hs -73 +27 Some lines were left there just because I'm lazy....;) Cheers, Andrea ps: I must confess that if the runLayout method could be accepted in the core my request of changing the 'description' type would be gone. While my sense of symmetry would require it for implementing a LayoutCombinator class as I have it mind, still I'm coming to thing that, from the practical point of view, the restrictions imposed by that signature are irrelevant for our purposes. And, probably, the fact of restricting the class to what I call pure combinators only, would be just fine. This is quite a common pattern of mine when it comes to type classes: I cannot see where I'll end up when I start implementing them. There must be some hidden weirdness I cannot grasp entirely. ;)

5 7

Issue 149 in xmonad: Xinerama support not working
by codesite-noreply＠google.com 09 Mar '08

09 Mar '08

Issue 149: Xinerama support not working http://code.google.com/p/xmonad/issues/detail?id=149 Comment #1 by dons00: So only a single large screen is detected, it seems. Can you rebuild X11 and xmonad from darcs, and see if its still the case? Do you have any unusual settings in your xorg.conf? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 149 in xmonad: Xinerama support not working
by codesite-noreply＠google.com 08 Mar '08

08 Mar '08

Issue 149: Xinerama support not working http://code.google.com/p/xmonad/issues/detail?id=149 New issue report by dukedave: What steps will reproduce the problem? 1. Install xmonad 2. Started using xmonad by placing it in .xsession 3. Opened a terminal What is the expected output? What do you see instead? The terminal is stretched across both screens rather than occupying just one. Opening a second terminal puts them side by side but pressing mod+w and mod+e does nothing, confirming xmonad believes they are both on the same screen. What version of the product are you using? On what operating system? xmonad 0.6 from Hackage tarball (Jan 08) with X11 1.4.1 Ubuntu Gutsy Linux Please provide any additional information below. During X11 build I see: checking X11/extensions/Xinerama.h usability... yes checking X11/extensions/Xinerama.h presence... yes checking for X11/extensions/Xinerama.h... yes Ran following in ghci: compiledWithXinerama True openDisplay "" >>= getScreenInfo [Rectangle {rect_x = 0, rect_y = 0, rect_width = 1280, rect_height = 1024},Rectangle {rect_x = 1280, rect_y = 0, rect_width = 1280, rect_height = 1024}] On a desktop with a single window, floating it and then tiling it with mod+t has no affect (it still spans both screens). Using Gnome/Metacity the xinerama set up is correctly detected and windows behave as expected, maximising to occupy one screen. Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

xmonad is one year old today
by Don Stewart 08 Mar '08

08 Mar '08

Happy first birthday xmonad! On this day in 2007, Spencer comitted the first prototype code into our xmonad darcs repository, starting off a year long adventure that has been xmonad development. Tue Mar 6 17:35:27 PST 2007 Spencer Janssen * Initial import. We'd long been frustrated with the limits of dwm and wmii, and were looking to make a nicer, more extensible window manager. A year later, we seem to have pretty much accomplished those original goals! Some other nice commits from the early days. Tue Mar 6 22:42:23 PST 2007 Spencer Janssen * Plan for statusbar Tue Mar 6 22:45:39 PST 2007 Don Stewart * focus left and right (mod-j/mod-k) Wed Mar 7 03:12:47 PST 2007 Don Stewart * Add support for multiple workspaces Yes, that's right, for a day there xmonad only suppored one workspace :) Wed Mar 7 17:04:24 PST 2007 Don Stewart * Add Alt-Shift-[1..5], to move the current client to a new workspace 2 days after the first commit, our now extensive QuickCheck testsuite was in place, Thu Mar 8 04:05:21 PST 2007 Don Stewart * forgot to add Properties.hs Leading to 1000s of window manager tests now run on every commit! And building a culture of testing and reasoning -- we're perhaps the first window manager ever to use static analysis, type theory (the zipper structure!) and theorem proving to improve code quality! Since there there's been 7 releases, and thousands of commits. A total of more than 50 developers have contributed code. Thank you all! Looking back on the year, it feels amazing -- it doesn't feel like 12 months have past. With nearly 300 people on the mailing list here, 100 in the #xmonad irc channel, and binary packages for almost every distro. The extension library, which is now 8 times larger than xmonad itself, came as a big surprise, and turned out to be critical in keeping the project flexible and robust. Spencer and I are looking forward to another exciting year, with more great innovations in the extension suite, and improved flexibility in the core system. Let's keep tiling window manager innovation fresh and exciting! And thanks to all the developers who've made this possible: The current and former commiters, Spencer Janssen Don Stewart Devin Mullins Jason Creighton Andrea Rossato David Roundy Brent Yorgey Eric Mertens Braden Shepherdson Lukas Mai Roman Cheplyaka And all those who've contributed patches! Aaron Denney Adam Vogt Alec Berryman Alex Tarkovsky Alexandre Buisse Austin Seipp Brandon Allbery Chris Mears Christian Thiemann Clemens Fruhwirth Daniel Neri Daniel Wagner Dave Harrison David Glasser David Lazar Devin Mullins Dmitry Kurochkin Dougal Stanton Stefan O'Rear Ferenc Wagner Gwern Branwen Hans Philipp Annen Ivan Tarasov Jamie Webb Jeremy Apthorp Joachim Breitner Joachim Fasting Joe Thornber Joel Suovaniemi Juraj Hercek Kai Grossjohann Karsten Schoelzel Klaus Weidner Valery V. Vorot Mats Jansborg Matsuyama Tomohiro Michael Fellinger Michael Sloan Miikka Koskinen Neil Mitchell Nelson Elhage Nick Burlett Nicolas Pouillard Peter De Wachter Robert Marlow Roman Cheplyaka Sam Hughes Shachaf Ben-Kiki Shae Erisson Simon Peyton Jones And all the users for helpful feedback, but reports, screenshots, ideas, discussion and patience!

5 4