I recently started using xmonad and I am really enjoying it. Previously, I had used awesome, but xmonad just seems cleaner. Granted, its dependencies are much heavier. I spent a long time bouncing between xmonad and awesome and decided to get some work done and just pick one. Spend few days with each, but realize that if you keep switching, neither one will feel like home.
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 X f*ckin' Monad window manager is written in Haskell. I use it, and it's both easy to configure, and blazing fast. I also hear it didn't require much source code either.
Back then, GUI was the canonically hyped killer app for OO. But now, we have good reasons to believe FP doesn't suck at it.
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.
> One of the great benefits of a dynamic language is that it can be hot-reloaded, that is, reloaded at runtime.
If I recall correctly, Yi does something equivalent. So does the Xmonad window manager, now that I think of it. Haskell is quite statically typed.
Whatever "dynamic" means here, this is not about the type system.
I recently switched from Awesome to XMonad and am loving it. Took me about a day to set up everything how I wanted it, including reading through the documentation, learning some more Haskell, checking out all the contrib modules for extending XMonad, and adding and configuring XMobar.
With Awesome, the sane defaults (and the status bar that comes with it) are almost too sane, in the sense that I never bothered to really customize it (because I never had to). XMonad, on the other hand, starts you off with nothing, forcing you to really build something personal and enjoyable.
Also, even though Lua is probably easier to pick up than Haskell, I could never quite wrap my head around Vicious, etc. (I couldn't even get my battery widget working...), whereas the XMonad contrib modules are very understandable to me.
I've been very happy with xmonad on my netbook, by the way, for what it's worth. I'm fine with GNOME 3 on my laptop because I can afford the loss of space, but xmonad makes the netbook use case so much nicer, and it works nicely when you plug in an external monitor.
It takes a bit of a learning curve, but it's pretty fun. (There's also /r/xmonad if you want to drop by and ask questions.)
Until its screen broke, my netbook was the Ubuntu non-desktop install ("server" / what you get from the alternate installer without checking any boxes), plus xmonad. You may want a handful of other things if you want e.g. a GUI for wireless networks, but it was still well under 4 GB because I avoided installing most of a modern big desktop environment.
I think xmonad (my tiling wm of choice) has a couple good tutorials: tour of xmonad and tombuntu
ed: accidentally a word
The stuff you can do with Haskell's types is interesting and it's worth learning (real life use-cases are basically going to be data science and some ML. Then there's stuff like xmonad.), but with Clojure and SBCL most of everything has been "Christ that makes so much sense" and "oh my God there's a macro for this thank you."
> What I would really like to see is an actual practical problem solved with them, not a toy problem like adding 5 to a number.
Does an X window manager that people actually use qualify?
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.
The music client shown is ncmpcpp. The battery percentage is green whenever it's plugged in (and white otherwise). The bar next to the artist name shows progress in the current song.
I'm using xmonad's fadeInactive to make all ncmpcpp windows and unfocused windows slightly transparent.
The wallpaper is JMW Turner's "Rain, Steam and Speed - The Great Western Railway". I used to have weather wallpapers that updated according to METAR data, but I much prefer this painting.
I'm happy to share any part of my setup if you're interested.
ncmpcpp conf The window shown was created with "ncmpcpp -S visualizer"
xmobarrc If you want the moon icons I used or that script, I can send that too.
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.
Try XMonad. It's a window manager written using the king of retardedly high-level abstract languages and it's quite zippy on netbook-class hardware. (I use it on my pre-Atom Eee PC 900 -- one core, 900 MHz).
Python and Ruby code will generally run slowly. That's not because they're high-level languages; it's because people use terrible Python and Ruby interpreters. A high-level language with a modern optimizing compiler (e.g. Haskell, Ocaml, SML, Lisp, Go) will regularly perform within a few percent of C, at a tiny fraction of the developer time.
I'm sick of C machismo based on 20-year-old performance assumptions.
How about Xmonad? You can avoid the 'learning-curve' part by simply using somebody's configuration; the default configuration is pretty usable too! The nice thing is that you can hack on it in the future if you want to.
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.
To figure out which package you want, see: xmonad.org/download.
To install/manage software, since I personally find the GUI tools more obfuscating than helpful, I recommend you look at: help.ubuntu.com/community/AptGet/Howto.
Chances are you'll also be wanting to look at this: wiki.lxde.org/en/LXSession_Edit.
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
Well I use something like that for my setup... It's on a github repo but I don't use the transparent windows.
I've done my best to make it readable to anyone (usually future-me), it uses explicit imports so I don't have mysterious unknown functions, it's kind of commented.
Some keybindings:
This module seems to do exactly that (transparent inactive windows). I actually got it working before I started using version control but here is the commit when I removed it so it should be easy to add back. Also you must run a composite manager (like xcompmgr) for this to work
Maybe that was a little too long I use it for the readme of that repo. Hope it helps.
EDIT: I misread the first requirement. That's probably just some options for xmobar that's called with the spawn command (I use dzen so no idea)
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
> And in xmonad I have <M-BS> mapped to a function that brings me to my last-used workspace.
Thank you for this idea. This will make things so much easier.
For those that are interested, CycleWS
provides a toggleWS
function which can be used to implement this. See http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-CycleWS.html#v:toggleWS.
Between tabbed and gridselect I think you should find what you are looking for, if I understand correctly. (Example)
The only time I've ever legitimately used that is for network debugging when I had multiple tcpdumps, tail -f logs, firewall debugs, and programs up all right next to each other to watch in real time. Otherwise I just distribute among my workspaces.
I am pretty sure the i3 website used to link to an youtube video of a talk performed by the main i3 developer. Maybe it was at Google, I don't remember.
However, the thing I loved most is http://xmonad.org/tour
It's simple, clear and short.
Use that and practice while reading it, even if you settle for another tiling WM later. It'll take you maybe 30 minutes but it's the best investment of time if you aim to learn the basics and lay a solid foundation for your further learning.
Follow up:
Bolstered with false courage about my newly acquired FunctionalFu(r) skills, I loaded xmonad.
Just... wow.
I really love data processing. It may have a sordid past, but it's definitely getting better.
You can do this with GridSelect. From the documentation:
, ((modm, xK_s), spawnSelected defaultGSConfig ["xterm","gmplayer","gvim"])
That pulls up a menu with three options: xterm, gmplayer, and gvim.
Config lets you tweak the color, cell width, etc. So you can spawn a mouse-based menu that fills your whole screen with options grouped by color with (relative) ease.
You could also roll it yourself with dzen. A bit harder, since you have to manage pipechains of input and everything.
Yes. :)
But you can, and I do!
There are a number of no-nonsense tiling window managers available that will do this job exactly; I personally use xmonad.
The problem is that it becomes hard to decide where the "division of labour" between tmux and the window manager should lie. Should you use the tiling window manager to control all of your panes (to use the tmux terminology), or should you use it only to control the arrangement of non-terminals, while leaving tmux to manage panes inside a single terminal session.
I tend towards the latter, mostly because that way I can keep my tmux session running even if I kill X. And I can access it remotely, etc.
I'm not familiar with the usability of herbstluftwm, but you can certainly achieve those layouts in xmonad by using SubLayout. It might not be as simple to configure as what you're used to though.
Some, especially the devs, would consider Haskell a pro, not a con. As the website says:
> xmonad is stable. > haskell + smart programming practices guarantee a crash-free experience.
Haskell is a pure functional language with strong static typing. That means if your config compiles without error (no type mismatches), then you'll have no runtime errors, which means no freezing, crashing, etc. of X11 due to the WM.
With WMs written/configured in other languages, you could crash during usage because of syntax errors, since these can't really be caught. (Awesome does have a sort of syntactic well-formedness test that you can run on your config, but it's not nearly as robust as Haskell's type checking.)
Depending on your school, the POSIX compliant nature of Mac OS might make a MBP worth it. It gets you the perks of running something like linux, but you can also watch Netflix or run Photoshop without having to hack together an elaborate workaround. So even if you're not in love with Apple (and these days, who is?) it's still mighty convenient to be using a Mac.
This might vary from school to school; "software engineering" might involve more MS technology than "computer science" does at my school. Here, the department infrastucture is Linux from top to bottom, so Macs fit right in. If your school isn't like this, everyone else is spot on in suggesting a Lenovo. Macs are solid, but my experience is Lenovo laptops actually stand up better to abuse in practice. Drop a MBP, and the screen will crack. A Thinkpad, probably not.
Personally, I have a 13" MBP as well as a little EeePC running Ubuntu with xmonad.
I had a netbook with similar specs, and ended up using the Ubuntu versions with lighter window managers. Xubuntu in particular was a good mix of features and streamlining.
Nowadays I run bare-bones Debian with only the packages I've selected. I use the XMonad window manager, which is great for keyboard-only use.
Of course, all of this goes on inside a virtual machine since I upgraded to a proper laptop, so my entertainment needs are taken care of by Win7.
Except that it doesn't have an embedded lisp interpreter. (ratpoison.el
just uses call-process
to run ratpoison commands.)
Flawed analogy aside, it's not like there aren't others - sawfish, stumpwm, and if you want to go really far back, GWM (popular back when having windows bounce off of each other with tunable elasticity was a thing :-) There's also xwem, though unlike the others I've never actually seen it used. (The "heinously programmable" windowmanager of choice these days seems to be xmonad which uses Haskell...)
It's just a light weight window manager. So I have lots of keyboard commands to shift my windows around how I want them. It automatically tiles everything, so I never have any unused space on my screen.
I was asking because it's really customizable, but I haven't done too much with my set up yet, so I wanted to see what sorts of things other people had done.
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.
>more layouts
I don't think so; awesome seems to have twelve layouts or so, while with xmonad-contrib, xmonad has about seventy layouts (not all of them are useful, but still).
On my local box I've stopped using screen since xmonad became my window manager (http://xmonad.org/).
Mate Desktop. The reason is easy. It works fine compare to gnome 3 in seamless mode from Virtualbox (if you must use Windows ; its nice that you only see your linux applikations not the complete stuff). I like the filemanager more then on gnome3, because you can use "yyyy-mm-dd hh:ss" as date format.
Compare to KDE it has low hardware requirements, so i can use my familiar DE on RaspberryPI, Server or Workstation.
What i also like is Xmonad (from time to time also xmonad + mate at same time), but not everone like tiling windows. And on my Laptop i Use awesomewm because it's awesome :-)
Note: I make every effort to programatically figure out if links originally posted to Reddit are still good, but it's difficult.
If the original URL doesn't work, or has been replaced with something else, please help out by searching the Wayback Machine for the URL and posting a contemporary link if you find one. There's also a Chrome Extension which makes this process easy.
Speaking of window managers, there are many different window managers to choose from on Linux and BSD operating systems. Some of them are tiling window managers like i3, others look and behave more or less like the Microsoft Windows or the macOS desktop and then there are some window managers that are different from that again.
A couple of other tiling window managers include xmonad and awesome.
xmonad was the first one I tried and awesome was the second. Nowadays I just run Mate, which is not a tiling window manager. I catch some flak from my peers for not using a tiling window manager but quite frankly I have found that even thought tiling window managers are powerful they don't suit my particular workflow well enough, so that's why I run Mate even though that's not ideal either. I don't know if the ideal window manager really exists, or if one even could exist, given that different tasks have some different nuances to them in terms of how you work with one or multiple windows and applications.
There exist a couple of programs on Windows and macOS that give you a bit of what a real tiling window manager gives you but the difference is that on Windows and macOS all of the ones I am aware of run on top of the native desktop, so they don't have complete control over everything. Meanwhile on Linux and BSD operating systems the window manager can be truly responsible for the whole desktop environment due to the modular nature of these systems.
> Xmonad
I found http://xmonad.org/, and it looks like it's just a window manager. I use a window manager, too (slate). It will not absolutely remove the need to interact with something with a cursor.
Maybe if there was a thing like vimium but for the whole OS...
Using tmux, with tmuxinator here, to quickly start sessions with custom layouts and different things running on different windows/panes. This usually includes a window for vim open in the project folder, and then other windows which will start VMs and ssh into them, if needed, windows on remote servers, panes rebuilding assets or re-running rests on change, etc...
All of this from Xmonad, a tilling window manager with a configuration file in Haskell. Having a configuration file in a full featured programming language, allows you to customise things to a level that's just crazy.
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
Hmm.
It's a little murky in reddit whether you should take someone's post in the context of the whole discussion, or just in the context of the message they are responding to.
But, ok.
By the way. You could make the point that code and configuration are not that different. For example: http://xmonad.org/ In this window manager, you configure it by creating a Haskell file that sets rough configurations and behavior of the window manager, then compile the program. In this instance "Configuration" is compiled in as part of design. Pretty flexible strategy.
Ultimately, "Code" and "Configuration" Are pretty nebulously defined.
Manual tiling just for my fellow aestheticians in /r/unixporn. I don’t know if it was introduced in a recent version (I’m on 3.20), but windows snap to the borders of others when dragging by default. Though I think you could achieve something similar automatically with a tiling WM like xmonad or i3.
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:
Did you have to do any configuration to get rofi to do the window switching? I'm using it with xmonad but no desktop environment, and it doesn't seem to recognize any windows straight out of the box. I don't think I saw anything about that in your dotfiles, but maybe it comes free from having xfce.
EDIT: never mind, figured it out: <code>XMonad.Hooks.EwmhDesktops</code> provides that capability.
I'm getting the exact same problem as you. Found this post while Googling around for a solution.
Did you ever find a resolution or relevant bug post about it? I'm also tempted to ask on /r/xmonad to see if they know what the root of the cause could be.
EDIT: Nevermind! I found the message you posted in with the problem, and found the workaround someone mentioned by including a handleEventHook. Seems to work great for me now. Thanks!
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.
Disclaimer: tinkered with "nooby" gnu/linuxes for a few years before trying both arch and xmonad.
A simple text editor is almost always included (vi or vim). There is a holy war between vim and emacs. Pick a side. Web browser you will have to install yourself. Some browsers work in X mode, eg firefox. Some browsers even work in command line mode, eg lynx or emacs. For me , xmonad took a few days to understand and set up according to my wants, but it’s better than any other window manager I’ve tried. The xmonad home page contains good documentation.
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. :)
The music client shown is ncmpcpp. The battery percentage is green whenever it's plugged in (and white otherwise). The bar next to the artist name shows progress in the current song.
I'm using xmonad's (fadeInactive)[http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-FadeInactive.html] to make all ncmpcpp windows and unfocused windows slightly transparent.
The wallpaper is JMW Turner's "Rain, Steam and Speed - The Great Western Railway". I used to have weather wallpapers that updated according to METAR data, but I much prefer this painting.
I'm happy to share any part of my setup if you're interested.
As a language itself, I would say that for me it's quicker to write than other languages (even quicker than Python for me), because:
The feedback loop is shorter. You can compile it piece by piece (aka hole driven development) and have a type checker guide you. Most mistakes you make will be immediately detected and explained thanks to the powerful type system.
The language provides more language features and abstractions than other high level languages I know (like Python, C#, Java, Bash, JS).
It's more concise.
Refactoring code or adding feature is easier.
That being said, it's might not be as fast as e.g. Python if you compare whole ecosystems, because Python has a lot of libraries and it can act as a simple glue between them, a glue for pre-made solutions. However, from my experience, some of those libraries tend to be inflexible due to language limitations. So if you have to go outside of boundaries of what they were designed for, it will be much harder. In Haskell it's usually easy to add concurrency and parallelism, for example. Furthermore, I find that the lack of type signatures makes some of those libraries harder to learn. The classic example would be two old libraries like xlib Python vs XMonad Haskell:
http://python-xlib.sourceforge.net/doc/html/python-xlib_21.html#SEC20
http://xmonad.org/xmonad-docs/X11/Graphics-X11-Xlib-Window.html
In Xmonad I can glance at type signatures and immediately have an idea of what they do, what they expect and what they return. But that's more of an argument dynamic vs static languages. And, from my experience, static languages save time and, perhaps more importantly, nerve cells ( I don't need to worry that if I pass it some value that something will explode or that it will return something fancy).
You're gonna have to choose what keys you can remap
I never use F keys or the home end pg up/down keys so I remap those a lot.
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.
> If I only want to watch videos and browse the web, I'll use my android tablet. PCs are meant for getting work done.
I said 'out of the box'.
Also, what programs are you using that are not available, and with no decent alternatives on Linux, other than those related to editing and creating media? Just curious.
Linux is really perfect for me because programming, web browsing, IRC and media consumption are the only things I use my computer for and I get a huge productivity boost my completely customizing my environment, and with programs like xmonad.
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{ ....
Showing the windows in expose is usually achieved via compositing, so you would probably have to use compiz or kwin or something like this.
There are also some other options, for example you can use application menus from xfce or lxde and bind them to keybindings.
Xmonad has a nice replacement for expose in http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-GridSelect.html . Have a look at the screenshots at the bottom.
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.
It's XMonad.Prompt.Shell, so you can have it if you switch from bspwm to XMonad :)
If you like hacking prompts, it's part of a killer prompts library that blows dmenu out of the water though. So it might be worth it.
I used to use bspwm. I moved back to XMonad when I realized I really wanted to be able to actually program my WM, not just use and configure it.
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
Since an xmonad configuration file appears to simply be a text file, then Ada can certainly be used to read and write them. Although you wouldn't have the Haskell syntax/semantic checking unless you built a Haskell parser into your configuration tool.
Or are you asking whether an application can define a configuration format using Ada syntax? That's certainly doable, if a bit heavyweight for a config file. E.g. GNAT's project configuration (gpr) files use an Ada-like syntax.
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.)
If you plan on using xmonad, you can use this but you'll have to edit the config. I'm sure you can find config examples for it via google.
I used xmonad for a half year, and while I love the idea of a tiling WM and its good for ~80% of what I want to do, for the other 20% its horrible. Does StumpWM let you quickly switch between tiling and non-tiling?
Try a tiling window manager. I would recommend StumpWM, but hivemind would probably prefer XMonad.
Hehe, no problem again, and just noticed I've again forget (I'm a bit tired after a day of hard work :) ) an interesting link:
Which contains informations to set it up to work as the window manager of your favorite desktop environment - a nice way to start hacking around it, too. So if you've got XFCE, Gnome or KDE installed, you can already give it a try while still using your favorite DE's tools.
Yeah, to be honest, Awesome was a bad example on my part. Awesome technically does both, making it is a dynamic window manager; but it primarily does tiling. Actual tiling window managers (Like... Xmonad, there we go.) just tile. The concept behind tiling window managers is that they are more efficient because you don't have to arrange your windows. Some people love it, others hate it. I don't mind it really, but it takes getting used to coming off of a stacking window manager.
Honestly? I've never used Awesome, so I really don't know. But compared to other tiling WMs, it is everything I claim it to be.
Xmonad is thoroughly documented, and writing a new layout seems like it would be straightforward. But with all of the layouts available, I don't know if you'd need to. :)
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!
Divvy looks interesting, but really it's just a dumbed down tiling window manager with a pretty (and mildly confusing) UI...
The beauty of real tiling window managers like xmonad et al. is that you no longer need to even think about managing windows. Everything is taken care of for you: windows are always tiled in such a way as to use all of the available space and the main window (at least with the default configuration) uses the most space. In addition, all window operations (switch focus, swap main window) is done using the keyboard, so in most cases you don't even need a mouse to use your computer anymore.
Yes, it's called wmctrl.
This functionality is provided by the XMonad.Hooks.EwmhDesktops module.
Though for the sort of functionality described in the article you'd probably be better off just adding it in your xmonad configuration.