- xmonad - Haskell.org

Popup origin
by Donald Allen 10 Sep '09

10 Sep '09

I'm new to xmonad, but not to tiling window managers, having used dwm for a time (I got tired of the sometimes unruly-junior-high-school-boy character of discussion on their mailing list, though this does not apply to Anselm himself, who is unfailingly polite). So I'm giving xmonad a try, and so far, so good. I do have one issue, however. I have a pair of systems that share (via a dvm) a Lenovo display with a 16/9 aspect ratio. On that display, popup dialogs, such as the file-chooser that appears during file-download operations in Firefox, are positioned too low on the screen, resulting the in the bottom of the dialog being cut off (this is not an issue on my older Thinkpad G41 with a 1400x1050 display). Is there a way to specify the origin of popup windows via the configuration system? I should mention that I'm running OpenBSD 4.5 Release on all these systems and xmonad 0.7, which is the version Release 4.5 provides as a package. So I'm aware that there is a newer version of xmonad. (I've had no success trying to build the newer version with the ghc compiler and libraries Release 4.5 provides.) So, it's possible this issue has been addressed in the newer version. Thanks in advance for any help -- /Don Allen

2 2

Issue 314 in xmonad: Investigate merging SmartBorders to core
by codesite-noreply＠google.com 10 Sep '09

10 Sep '09

Status: Accepted Owner: SpencerJanssen Labels: Milestone-Release0.9 Type-Enhancement New issue 314 by SpencerJanssen: Investigate merging SmartBorders to core http://code.google.com/p/xmonad/issues/detail?id=314 Enabling the SmartBorders extension is the first step we suggest users take to make proper borderless fullscreen floating windows work. However, SmartBorders has a few problems: * It depends on LayoutModifier, which is a rather ugly bit of code. It would need some help to be up to core's standard of elegance, I think. * SmartBorder's behavior on non-floating windows may be controversial. An alternative is to remove the fullscreen floating logic from SmartBorders and implement it directly in core. This has the annoyance of being less general, but will probably be simpler. Comments solicited. -- 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 313 in xmonad: Merge contrib's isFullscreen and doFullFloat to core
by codesite-noreply＠google.com 10 Sep '09

10 Sep '09

Updates: Labels: Type-Enhancement Comment #1 on issue 313 by SpencerJanssen: Merge contrib's isFullscreen and doFullFloat to core http://code.google.com/p/xmonad/issues/detail?id=313 (No comment was entered for this change.) -- 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 313 in xmonad: Merge contrib's isFullscreen and doFullFloat to core
by codesite-noreply＠google.com 10 Sep '09

10 Sep '09

Status: Accepted Owner: SpencerJanssen Labels: Milestone-Release0.9 New issue 313 by SpencerJanssen: Merge contrib's isFullscreen and doFullFloat to core http://code.google.com/p/xmonad/issues/detail?id=313 We ought to add the manageHook > isFullscreen --> doFullFloat to the default configuration, it seems to fix issues with full screen windows (especially Flash). -- 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 312 in xmonad: [improvement] MosaicAlt: change tall/wide
by codesite-noreply＠google.com 09 Sep '09

09 Sep '09

Status: New Owner: ---- New issue 312 by OrbisVicis: [improvement] MosaicAlt: change tall/wide http://code.google.com/p/xmonad/issues/detail?id=312 What steps will reproduce the problem? 1. Use MosaicAlt 2. Apply tallWindowAlt/wideWindowAlt 3. First several applications have no affect What is the expected output? What do you see instead? MosaicAlt probably increments the tallness or width of an application window by a fixed amount. Often first increments dont produce enough change to effect a layout modification. What should happen: application of tallness/width immediately jumps to the next possible layout What version of the product are you using? On what operating system? xmonad 0.8.1 xmonad-contrib 0.8.1 archlinux -- 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 not playing well with floating windows
by Massimo Gengarelli 09 Sep '09

09 Sep '09

Hi everyone, I'm quite new to XMonad and haskell itself, so I really don't know if it's a problem of my configuration file or it's the default behaviour of XMonad. Everytime I make a window floating, the tiled windows in background swap between themselves, without any reason or fixed rule. If I replace them in the order I want, they re-swap as soon as I move/resize the floated window. I'm using Linux Gentoo and XMonad 0.8.1. Thanks in advance. -- Massimo Gengarelli <massimo.gengarelli(a)gmail.com> Computer Science student @ http://www.unibo.it . http://massitm.sohead.org <-- my personal, outdated, website. Do you guys know what you're doing, or are you just hacking?

6 7

better alternative for stalonetry?
by Chengqi Song 09 Sep '09

09 Sep '09

hi all, im using stalonetry as my tray program but it performs not well. there often are icons missing. i have to frequently restart stalonetry to get the missing icons displayed. do you have the same problem? is there any better choice? what i need is just a tray program :) thanks lars

2 2

Issue 4 in xmonad: Separate focus for tiled and floating layers
by Chengqi Song 08 Sep '09

08 Sep '09

any hero can come up and do this for us haskell newbies? :D lars ----- Forwarded message from codesite-noreply(a)google.com ----- Date: Tue, 08 Sep 2009 10:02:34 +0000 From: codesite-noreply(a)google.com To: xmonad(a)haskell.org Subject: [xmonad] Issue 4 in xmonad: Separate focus for tiled and floating layers Comment #14 on issue 4 by songcq: Separate focus for tiled and floating layers http://code.google.com/p/xmonad/issues/detail?id=4 I want this feature very much. The current behavior of floating window is too annoying. -- 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 _______________________________________________ xmonad mailing list xmonad(a)haskell.org http://www.haskell.org/mailman/listinfo/xmonad ----- End forwarded message -----

1 0

Issue 4 in xmonad: Separate focus for tiled and floating layers
by codesite-noreply＠google.com 08 Sep '09

08 Sep '09

Comment #14 on issue 4 by songcq: Separate focus for tiled and floating layers http://code.google.com/p/xmonad/issues/detail?id=4 I want this feature very much. The current behavior of floating window is too annoying. -- 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

Bluetile
by gwern0＠gmail.com 06 Sep '09

06 Sep '09

Resources: - Original thread/ANN: http://thread.gmane.org/gmane.comp.lang.haskell.xmonad/7458/ - Jan Vorberger's OP: http://article.gmane.org/gmane.comp.lang.haskell.xmonad/7458 > "I'm planning to decide on a somewhat fixed configuration of XMonad, probably in combination with Gnome as a DE, and then trying to make this functionality available via mouse commands that - hopefully - will be easy to pick up.<br> > I also want to completely rework the whole floating layer thing, as it seems to me to be a fairly foreing [sic] concept for a newcomer and it's awkward to use. My current idea is to instead use a floating layout algorithm, that could work similiar [sic] to a conventional window manager. It could even be set as the default layout algorithm. That way, the WM could almost be a 'drop-in' replacement for - let's say Metacity - greeting the user with the familiar concept of manipulating windows and then leading him to the tiling paradigm once he switches the layout." Jan later [wrote](http://article.gmane.org/gmane.comp.lang.haskell.xmonad/7495) that > "@Don: I will definitely try to contribute back changes and improvements, if I can. Once I start implementing I will also make my repository available for others to try out. Thx for offering assistance, I might come back to that later." But given that Bluetile has been done a while, I guess we'll just have to content ourselves with the repos. - A PDF presentation of some sort is available at http://parsys.informatik.uni-oldenburg.de/theses/docs/bluetile_zwischenvort… - Google Translate link, may or may not work: http://translate.google.com/translate?hl=en&sl=de&u=http://parsys.informati… The actual code seems to be broken up into 4 packages; everything is BSD3 so no concerns about reuse: - bluetilutils: http://hackage.haskell.org/package/bluetileutils (Darcs repo: http://tuvok.home.dyndns.org/bluetile-repos/bluetileutils down?) A package of 3 Gtk2hs executables: i. bluetiledock ii. bluetilemockwin iii. bluetilegreet - xmonad-bluetilebranch: http://hackage.haskell.org/package/xmonad-bluetilebranch (I have no local repo for this, although it was presumably at http://tuvok.home.dyndns.org/bluetile-repos/xmonad-bluetilebranch ) - xmonad-contrib-bluetilebranch: http://hackage.haskell.org/package/xmonad-contrib-bluetilebranch (same comment for repo) - bluetile: http://hackage.haskell.org/package/bluetile (repo: http://tuvok.home.dyndns.org/bluetile-repos/bluetile ) Now, looking at the code (bearing in mind I am only reading and haven't compiled/run anything yet): # bluetileutils ## bluetiledock This creates a minimalistic strut app. It supports 14 buttons/commands: - switch to workspaces 0-9 - 4 commands to switch to floating/tiled1/tiled2/fullscreen (presumably tiled1 and tiled2 = 2 windows each on 1/2 screen split horizontal & vertical) Interesting is how bluetiledock achieves this functionality, how it makes xmonad actually do something - it seems to be using a X-based method of IPC, in which a integer is stored in an X atom and xmonad then grabs it and does something with it: ~~~~{.haskell} sendCommandX :: Int -> IO () sendCommandX com = do d <- X.openDisplay "" rw <- X.rootWindow d $ X.defaultScreen d a <- X.internAtom d "XMONAD_COMMAND" False X.allocaXEvent $ \e -> do XE.setEventType e X.clientMessage XE.setClientMessageEvent e rw a 32 (fromIntegral com) XE.currentTime X.sendEvent d rw False X.structureNotifyMask e X.sync d False ~~~~ ## bluetilegreet A splashscreen/help; checks for empty file ~/.bluetilegreet and if it exists, makes it and runs. It then basically displays the XML contents of bluetilegreet.glade, which run something like: ~~~~{.xml} <property name="label" translatable="yes">Quickstart: Open a few windows and notice that you are currently in the traditional layout mode, known from most other window managers. To start tiling, switch to another layout in one of these ways:</property> <property name="wrap">True</property> </widget> </child> <child> <widget class="GtkLabel" id="label3"> <property name="visible">True</property> <property name="label" translatable="yes">* Using the dock on the left (buttons A, S, D or F), * pressing the middle mouse button while holding down the Windows key or * using the keyboard shortcuts Win+A, Win+S, Win+D or Win+F .</property> </widget> <packing> <property name="top_attach">1</property> <property name="bottom_attach">2</property> </packing> </child> <child> <widget class="GtkLabel" id="label4"> <property name="visible">True</property> <property name="label" translatable="yes">You should be fine exploring the tiling paradigm with your mouse alone, but to get the most out of it you might want to look at the keyboard shortcuts at some point. They are documented on Bluetile's website.</property> <property name="wrap">True</property> ~~~~ It might be a good idea to have something similar for XMonad; it's not like it really matters if we dump an empty hidden file in ~/.xmonad ## bluetilemockwin No idea. It creates some sort of widget with the RGB color specified as 3 ints. Grep doesn't seem to show up any use in the main bluetile repo. ~~~~{.haskell} main :: IO () main = do args <- getArgs progName <- getProgName if length args /= 3 then putStrLn $ "Usage: " ++ progName ++ " 0 0 65535" else let r = read $ args !! 0 g = read $ args !! 1 b = read $ args !! 2 in showMockWin (Color r g b) showMockWin :: Color -> IO () showMockWin c = do initGUI window <- windowNew onDestroy window mainQuit widgetModifyBg window StateNormal c widgetShowAll window mainGUI ~~~~ # xmonad-contrib-bluetilebranch Without a repo, it's hard to know exactly what's changed. But by my count, this XMC fork adds the following modules: - XMonad.Actions.BluetileCommands defines `[(String, X ())]`, which seem to support the 14 commands used by the dock, and 4 others (quit, quit-and-start-metacity, increase master, decrease master) - XMonad.Actions.WindowMenu much as it sounds, supporting the following commands: ~~~~{.haskell} actions = [ ("Cancel menu", return ()) , ("Close" , kill) , ("Maximize" , sendMessage $ maximizeRestore w) , ("Minimize" , sendMessage $ MinimizeWin w) ] ++ [ ("Move to workspace " ++ tag, windows $ W.shift tag) | tag <- tags ] ~~~~ - XMonad.Hooks.BluetileDock - XMonad.Hooks.CustomRestart adequately summarized by a snippet ~~~~{.haskell} a <- io $ internAtom d "XMONAD_CUSTOM_RESTART" False when (mt == a) $ do restart prog True ~~~~ - XMonad.Hooks.EventHook Old code? Seems to've been removed in darcs XMC - XMonad.Hooks.RestoreMinimized - XMonad.Hooks.WorkspaceByPos No idea. What I did notice is that it looks like it could use the Maybe monad! ~~~{.haskell} needsMoving :: Window -> X (Maybe WorkspaceId) needsMoving w = withDisplay $ \d -> do -- only relocate windows with non-zero position wa <- io $ getWindowAttributes d w if ((wa_x wa) == 0) && ((wa_y wa) == 0) then return Nothing else do ws <- gets windowset sc <- fromMaybe (W.current ws) <$> pointScreen (fi $ wa_x wa) (fi $ wa_y wa) maybeWkspc <- screenWorkspace (W.screen sc) case maybeWkspc of Nothing -> return Nothing Just wkspc -> do let currentWksp = W.currentTag ws if currentWksp == wkspc then return Nothing else return (Just wkspc) ~~~~ - XMonad.Layout.BorderResize - XMonad.Layout.DecorationUtils Support for the BorderResize? - XMonad.Layout.DraggingVisualizer - XMonad.Layout.MouseResizableTile - XMonad.Layout.NoFrillsDecoration - XMonad.Layout.PositionStoreFloat - XMonad.Layout.ThreeColumnsMiddle just an alias for ThreeColumns - XMonad.Layout.WindowSwitcherDecoration looks like a module to use a mouse to 'drag' a window onto another and swap their positions # bluetile About what you would expect - importing most of the above, running the dock and the greeter. So to conclude this whirlwind tour: I see a lot of valuable stuff. The greeter is something that could definitely be in core (although I think the gtk2hs dep is untenable, so I expect a better idea would be to run an xmessage prompt with a list of keybindings). The dock is a nice alternative to the ridiculously baroque setups for xmobar and dzen - those may be really nice and customizable, but they are absolutely unsuitable for beginners, and even setting up a Gnome panel is a bit much for non-intermediate or advanced XMonaders. And the string atom stuff has already been done by Stumpwm/Ratpoison, and I asked for this in the past - XMonad should be scriptable from the outside. -- gwern

14 20