Alright, here's the deal. By default, this is what happens:
There's two common ways of tweaking this behavior. One way is to change case (6) to keep the mapping as is, but change input focus to the screen that is showing the workspace you selected. See view. The other way is to change (1) and (3) in tandem: create (10 * number of screens) workspaces, and arrange for the mod+1,2,...,0 keybindings to choose which workspace to jump to based on both which key you pressed and which screen is currently focused. The result of this modification is to create the illusion that each screen has an independent set of workspaces that never interfere with each other -- rendering case (6), the confusing case, impossible. See IndependentScreens.
The JVM has a hardcoded whitelist of window managers that it expects. This can be spoofed by setting it to "LG3D" using something like http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-SetWMName.html
I can think of at least two options for you:
Write some keybinds to detect the current workspace and move in a way that simulates moving on a 2D grid. Like, if you have 9 workspaces and are on #3, and you hit your "down" keybind, it would move to #6 instead of #4.
If you want a visual representation, look at GridSelect in the contrib extensions. That'll let you pop them up in a 2D grid for navigation.
haven't tried this, but been considering it as i've been planning on picking up a larger monitor soon:
Basically it splits your 1 monitor into 2 virtual monitors/screens, so xmonad would work as if you were running a dual monitor setup. for me at least that's a big deal, since keeping 1 workspace viewable while i switch between others is a common workflow for me.
there may be some fancy pure-xmonad solution to provide something similar, but i'm not aware of one. curious if there is though since that'd be much simpler to set up.
Do something like the following in your ~/.xmonad/xmonad.hs:
import XMonad.Hooks.SetWMName defaults = gnomeConfig { startupHook = startupHook gnomeConfig >> setWMName "LG3D" }
More info/other options. Hope that helps!
I can't say much about Awesome because I don't remember what it was that made me stop trying it out. That was many years ago.
I've been using Xmonad since around 2008. Xmonad's defaults are excellent so you can live with them while learning how to configure it (Haskell). It follows some window manager standards rather strictly, which can lead to problems with focus with some software which violates those standards. Both Awesome and Xmonad are non re-parenting window managers, so you might run into problems with the odd Java or Mono window, but it's rare and there are some easy work-arounds. ( Xmonad and AwesomeWM )
I don't have a config solution to incorporate directly, but I think I know how you can achieve what it is that you're looking to do.
You'll need to define a custom XPC config that modifies historyFilter
.
myXPC :: XPConfig myXPC = defaultXPConfig {historyFilter = nub , position = Top }
Note, however, that HISTCONTROL=ignoreboth
keeps a history without duplicates and without leading spaces. If you want that behaviour, you'll need to compose nub
with something that filters out strings with leading spaces.
This is a bit trickier. You'll basically need to implement a custom instance of XPrompt
to do this. In that, you can specify a particular behavior to modeAction
that can do the required history search that you'd want. For examples of how to do this, look at Launcher.
You can then either use this new mode to be the replacement for current shell thing, or add it as an extra mode to the shell, by using mkXPromptWithModes
instead of mkXPrompt
that shellPrompt
uses.
It sounds like you are looking for XMonad.Layout.IndependentScreens which gives you separate workspaces on each monitor.
You want to potentially use use MarshallPP to prevent your workspace list from showing 1_1, 2_1, 1_2, 2_2, etc. as it does list the workspaces on both monitors.
If you want to swap the workspace on both monitors at the same time there's probably something for that too, but I haven't used that myself.
You can use XMonad.Hooks.ServerMode. I would recommend using the latest development version, which has been greatly improved (in particular you can define messages with a parameter, using serverModeEventHookF
). The documentation of the module gives as an example a small Haskell program to send messages to XMonad, which can be compiled and used as a remote control for XMonad (or you can use any language with appropriate X bindings).
N.B. If you do not want to install the complete development version of XMonad, you can just put this specific module in your personal modules in ~/.xmonad/lib .
My advice: first get yourself up and running with a basic, minimal config that also incorporates xmobar (or dzen2).
Then go check out xmonad-contrib, and read through all of them, and just try out each one that sounds even remotely interesting to you. It may sound like a lot, but here are the advantages:
You'll gain a lot of experience reading and implementing Haskell. Make sure to read the source of those modules/functions you don't quite understand, and pay close attention to types.
You'll get the full sense of what modules are out there for you to absorb into your own config. There will be things you'd never have thought of yourself, but once you try them out, you'll wonder how you could live without it. (I'm looking at you, Scratchpad and Prompt.Man.)
This is what I did when I first moved from Awesome to xmonad. Now I'm super comfortable tweaking my config on the fly, coming up with new stuff myself, absorbing new ideas as I come across them. I attribute all this to becoming very familiar with reading the xmonad-docs. (By the way, don't neglect to read docs for the core xmonad libraries, too.)
tl;dr The xmonad-docs, especially for xmonad-contrib, are your best friend. Get comfy and cozy with them, and you can do damn near anything in xmonad.
I'm not familiar with xmonad (don't ask how I got here), but there are several options.
a) use .xsession: It should work as usual; don't forget to make it executeable
b) Start things via the window manager configuration, which xmonad apparently doesn't support
c) services.xserver.displayManager.sessionCommands
: This setting is global for all sessions
d) Create your own session via services.xserver.displayManager.session
to have Xmonad started in XFCE you can do something like this:
http://www.haskell.org/haskellwiki/Xmonad/Using_xmonad_in_XFCE#Ensure_XMonad_gets_started
it's not very clear there. basically you add xmonad to the startup applications and kill xfwm4 under session, then save the session
I just fixed this last night on my own machine.
Does the current app still respond? If so then this is almost certainly your problem: XMonad FAQ
dynamicLog is writing to a pipe but is never being cleared; you can cat the buffer under the /proc/[process id of XMonad] (see the FAQ) and unfreeze XMonad. (I Ctrl-Alt-F2'd into a separate terminal to do so).
A more permanent fix will probably involve adding some reference to StdinReader to your .xmobarrc.
I remember trying to achieve the same and finding a mailing list thread where people were discussing the problem. The conclusion was that it would require a 'major rewrite' of some part of xmonad. And it seemed that at that point, no one was really willing to do that.
But maybe someone else knows better? I too would like to know if decorating floating windows only is possible.
EDIT: I guess thats the mail I remember reading: http://www.haskell.org/pipermail/xmonad/2009-October/008737.html
You can use the XMonad.Hooks.EwmhDesktops module like this, or just use the XFCE module itself.
If you're having the problem of only seeing xfce4-panel on one workspace, get the class name of xfce4-panel and put doIgnore in the manage hooks. > className =? "Xfce4-panel" --> doIgnore
(I'm not sure if the class name is capitalised or not, so use xprop to double check it).
Perhaps this haskell docs show what you want?
In particular:
{-# OPTIONS_GHC -fno-warn-name-shadowing #-} module X where
And put -threaded after OPTIONS_GHC instead.
Am on a windows box right now, so I can't check my self.
Edit: And some more flags. Also out the check config archive on the xmonad wiki, am sure someone uses flags in their configs.
To take a relatively low-level approach, there are two steps here: invoking a terminal emulator, and positioning the window that the terminal emulator creates. A window manager can't really link those two directly, but you could pass along some information through X window properties. Your terminal emulator probably has an option to set the "application name" of a window, e.g.
urxvt -name urxvtq terminator --classname terminatorq
(Check that this works by running xprop | grep WM_CLASS
and clicking on a window launched that way.)
So create a keybinding for that:
((modm, xK_q), spawn "urxvt -name urxvtq")
And then add a manageHook rule to position the window when it opens using something from XMonad.ManageHelpers:
import XMonad.Hooks.ManageHelpers import qualified XMonad.StackSet as W
appName =? "urxvtq" --> doRectFloat (W.RationalRect 0 0.5 1 0.5)
This example positions the window in the bottom half of my screen.
You can do it if you do it outside of the avoidStruts/desktopLayoutModifiers function. something like:
import XMonad import XMonad.Config.Desktop import XMonad.Hooks.EwmhDesktops import XMonad.Layout.MultiToggle import XMonad.Layout.MultiToggle.Instances import XMonad.Util.EZConfig
myLayout = layoutHook desktopConfig
main = xmonad $ desktopConfig
{ layoutHook = mkToggle (single NBFULL) $ myLayout
, handleEventHook = fullscreenEventHook
}
additionalKeysP
[ ("M-f", sendMessage $ Toggle NBFULL) ]
see also: Modifying layouts: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Config-Desktop.html
I used this to get the fullscreen toggle keybind: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-MultiToggle.html
and I use this to get the it working with fullscreen events: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-EwmhDesktops.html
Are you sure your config compiles?
From the documentation it looks like statusBar is meant to be used with xmobarPP, not xmobar.
What happens if you change your last line to:
main = xmonad =<< xmobar myConfig
Have a look at how it's defined:
azertyConfig = defaultConfig { keys = azertyKeys <+> keys defaultConfig }
Something like
main = xfceConfig { keys = azertyKeys <+> keys defaultConfig }
Also, you can of course do your own bindings, or use the default ones. The default ones are based on vim, so if you're used to using hjkl on azerty under vim you'll be quite at home. Here's what I do for dvorak/kde/dual head:
import XMonad import XMonad.Config.Kde import XMonad.Actions.CycleWS ( nextScreen, swapNextScreen, shiftNextScreen ) import XMonad.Util.EZConfig ( additionalKeys )
myModMask = mod4Mask
myConfig = kde4Config
{ modMask = myModMask
} additionalKeys
[ ((myModMask, xK_o )
, nextScreen)
, ((myModMask, xK_e )
, swapNextScreen)
, ((myModMask .|. shiftMask, xK_e )
, shiftNextScreen)
]
main = xmonad myConfig
plus
xmodmap -e "clear lock" xmodmap -e "keycode 66 = Hyper_L" xmodmap -e "clear Mod4" xmodmap -e "add Mod4 = Hyper_L"
to give caps lock a purpose as well as
xmodmap -e "keycode 94 = Escape NoSymbol Escape NoSymbol Escape"
To put another escape on the key right to the left shift that international keyboards have more than US ones.
Your bar's dock gap is not being managed or hidden during the fullscreen layout. It just hangs out as the window has been self-defined to do.
You could use ManageDocks. It just detects if a window is a docking type and provides a visibility toggle and a docking gap. Apply the functionality to your manageHook and layoutHook: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-ManageDocks.html
You should look at UrgencyHooks: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-UrgencyHook.html
And it was covered here: http://braincrater.wordpress.com/2009/03/14/pimp-your-xmonad-4-urgency-hooks/
I found that discussion, but it appears to be several years old, and it may be doable now. I saw references to the possibility of doing it with some new feature, by applying a decoration to a layout, kinda like:
myLayouts = simpleDecoration (simpleFloat shrinkText defaultTheme)
But I couldn't get it to behave as I expected.
EDIT: Yep, that's the one.
> Fri Oct 2 21:30:30 EDT 2009
Still the case now?
From http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-SimpleFloat.html :
> A simple floating layout where every window is placed according to the window's initial attributes. > > This version is decorated with the SimpleDecoration style.
From http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-SimpleDecoration.html :
> layout modifier for adding simple decorations to the windows of a given layout. The decorations are in the form of ion-like tabs for window titles.
Hence my confusion.
Per default, Xmonad uses a mode called greedy view, which is... not all that practical. Have a look here for this: http://www.haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#Replacing_greedyView_with_view
I had a nearly identical motivation! Taking notes from a screencast, and needing to pause, rewind a bit, etc.... when I realised I could write an emacs minor mode: https://github.com/markhepburn/mplayer-mode
(I've only used it once so far, and it probably didn't save me any time and all once time to write it is included, but it was fun I guess)
Did some playing around with doing this the "standard" way and launching xmonad within Gnome. There's a PPA that basically provides everything I want but it hasn't been updated for Wiley.
https://launchpad.net/~gekkio/+archive/ubuntu/xmonad
I'll try you suggestion next, /u/manpacket.
What kind of XMonad config are you using? If you want a simple Gnome session with Metacity replaced with XMonad, see my PPA:
https://launchpad.net/~gekkio/+archive/ubuntu/xmonad
It has XMonad backports and XMonad+Gnome session packages that should give you a working setup on all supported Ubuntu versions. Just make sure you are using gnomeConfig in your xmonad.hs.
If you want something more customized, like gnome-panel replaced with xmobar, you can still check out the session files for some hints.
The X server itself doesn't support hardware accelerated rendering of the desktop, so without a compositor, it's really rendering the entire desktop in software. This is not a good thing for performance (of course on high-end PCs you might not notice it, but on e.g. a Raspberry Pi the X desktop is very noticeably slow). Support for compositors was then added as an afterthought to the X architecture. A compositor does the rendering of the screen image using hardware accelerated graphics (typically OpenGL) on behalf of the X server, which reduces CPU load since there's no software rendering going on, and is generally just a good idea since every computer (excluding servers with e.g. Xeons) today has at least a built-in GPU that is capable enough for compositing, and that will only sit there unused if you use software rendering for drawing the desktop. It also reduces things like flickering, flashing and tearing on the desktop. And there are systems on which it does make a difference right away: on a Raspberry Pi, the WIP Wayland-based Maynard desktop is noticeably much smoother and faster than the default LXDE desktop.
Note that desktop effects such as the ones in KWin and Compiz are not compositing, they're just one of the nice extra things that become possible when the desktop compositing is done in hardware on a GPU. Running a compositor such as compton or xcompmgr gives an advantage even if you aren't using any effects such as drop shadows or transparency.
Wayland solves problems in the X architecture, protocol and server. Here are two good articles about what's good and bad about X, and how Wayland is different:
You could use X.A.MessageFeedback, I believe. I use this to have key bindings that do similar (but distinct) actions on sublayouts vs normal windows.
http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-MessageFeedback.html
U can use a scratchpad for that.
I have that for weechat for example.
setup your scratchpads:
scratchpads = [ NS "weechat" "urxvtc -title 'WeeChat 1.4' -e weechat" (title =? "WeeChat 1.4") (customFloating (W.RationalRect 0.1 0.1 0.8 0.8)) ]
add a keybind for the scratchpad. for example:
((modMask, xK_c), namedScratchpadAction scratchpads "weechat")
more info:
I only know of the <code>insertPosition</code> way to do things, where insertPosition Above Newer
is the XMonad default.
Hopefully, this helps do what you want.
statusBar
is a function in XMonad.Hooks.DynamicLog. I pass it pBar
(my bar program with the right command line arguments), pp'
as the pretty print options, toggleStrutsKey
for it's visibility toggle, and my custom bar config. It handles everything else from there, and works particularly well with xmobar.
ghc -Wall
does give me some output for general warnings (like a lot of "no type signature"). I will sift through them and see if any seem relevant (or fix them just because it's good). Thanks.
Right, the default XMonad behavior is to keep the sets of screens and workspaces independent and let you show any workspace on any screen.
You might find view instead of greedyView or even XMonad.Layout.IndependentScreens to your liking.
Take a look at XMonad.Actions.FloatKeys Specifically the keysMoveWindow function.
If you need more example you can check out my xmonad.hs. I don't have the mouse command removed, but removing it would be relatively simple. :)
As others mention, you want a Full layout to achieve that; however you may also be interested in tabs, or you might be interested in looking at all of the layouts and maybe choose something like AutoMaster.
http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-DynamicLog.html#v:statusBar
The statusbar
command handles leaving space for the bar. Something like this should work
import XMonad.Hooks.DynamicLog
myBar = "xmonad" --the command used to launch the statusbar -- Key binding to toggle the gap for the bar. toggleStrutsKey XConfig {XMonad.modMask = modMask} = (modMask, xK_b) main = xmonad << statusbar myBar defaultPP toggleStrutsKey myConf myConf = defaultConfig{ ....
edit It's another fail, read at the end of this comment.
Okay, so I managed to do it, using XMonad.Actions.PerWorkspaceKeys.
Related configuration:
import XMonad.Actions.PerWorkspaceKeys
workspaceModkeys = [ (mod1Mask, map show ([1..4] ++ [6..9])) -- use Alt as modkey on all workspaces , (mod4Mask, ["5"]) -- save 5th (use Win there) ]
modifiedKeysList conf = [ ((0, xK_Return), spawn $ XMonad.terminal conf) -- launch a terminal , ((shiftMask, xK_c ), kill) -- close focused window ]
unmodifiedKeys conf = [ ((0, xF86XK_AudioPlay ), spawn "mpc toggle") , ((0, xF86XK_AudioStop ), spawn "mpc stop") ]
keysList conf = concat (map modifyKey (modifiedKeysList conf)) ++ (unmodifiedKeys conf)
modifyKey :: ((KeyMask, KeySym), X()) -> [((KeyMask, KeySym), X())] modifyKey k = map (f k) workspaceModkeys where f ((mask, key), action) (mod, workspaces) = ((mask .|. mod, key), bindOn (map (\w -> (w, action)) workspaces))
myKeys conf = M.fromList $ keysList conf
main = xmonad $ defaultConfig { keys = myKeys }
Still might look into window-specific keys later, but I'm done for now.
But it's a fail again. XMonad acts as expected, but software does not receive pressed keys. I mean, Chrome switches to second tab when I press Alt+2 (and when my modKey is winkey). But with this configuration Chrome on 5th workspace does nothing, it just doesn't see I pressed the key.
Thanks!
I foresee monadic abyss, but this could work. I'll say something as soon as I'm done or fail.
edit I failed. Well, currently watching into XMonad.Actions.KeyRemap, as seems to be close to the thing I want to accomplish.
The better option for what the OP wants is XMonad.Layout.IndependantScreens. Follow the directions there and you'll achieve exactly what you're looking for.
well, if you really need this you might have to use xmonad as you propose. i'm pretty sure it's possible but you would have to ask one of the haskell hackers probably in #xmonad on freenode... they're always very helpful
edit: ok, first google search gives this: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Util-Paste.html
That's just a prompt; if you are using Firefox so much, use the runOrRaise functions directly - http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-WindowGo.html
(You're welcome, by the way.)
I tried to do this once, and the best I could do was to use a XMonad.Layout.Combo layout to combine a tabbed layout with another. Let me know if you find a better solution!
I prefer hammerspoon over Amethyst. Hammerspoon gives you the simpler level of control like Xmonad.
I wish I could use Haskell in Hammerspoon, I find Lua lacking in comparison.
Glyphs can be added in two ways. Firstly via their unique unicodes, which would be added into your template flags in the commands section, e.g “\xf17c”. Another way is to paste the actual glyph into the template section of the xmobarrc. Check out https://fontawesome.com/v6.0/icons to search for glyphs and unicodes.
Finally, in my experience I had issues with glyphs appearing when added directly into the template section. This is because I hadn’t got a UTF8 locale set. To remedy this ensure a locale is set that supports unicodes e.g for British English it would be “en_GB.UTF-8” rather than just “en_GB”.
I hope this helps.
I probably mistaken but it is not crushing, if you change version of the compiler, you should recompile xmonad with the current compiler, as you state.
A possible solution, instead of using an alias that will be raised every time you make an update is to write a hook for pacman. Arch Wiki
Sadly cVim hasn't had any updates for 9 months or so.
Mouseless seems to be the most maintained fork, but there isn't a Chrome web store version.
No need to say sorry. I mean something like the xmonad-log-applet. Actually just getting the xmonad-log-applet to work with the Unity panel would be amazing. It seems there are other people interested in this too, https://github.com/alexkay/xmonad-log-applet/issues/2.
P.S. You should add a flatter thingy to your site ;)
I solved the issue by disabling all the Gnome stuff and just running pure xmonad. To the best of my knowledge I followed the instructions here just as they were written: http://www.haskell.org/haskellwiki/Xmonad/Using_xmonad_in_Gnome#Ubuntu_Natty
I sometimes get the same error if I run a command that wants to open a file browser, such as the 'open download folder' command in skype.
That did the trick, thanks!
For other people coming here for the solution, there are a few classes you have to import. More details here.