- xmonad - Haskell.org

Patch: X.H.FadeInactive and X.A.GridSelect
by Jesper Reenberg 07 May '12

07 May '12

X.H.FadeInactive: Attached is my previous patch, which seems to have been stranded. Anyways there don't seem to have been any objections. X.A.GridSelect: * Fixed X.A.GridSelect to be consistent in the way it (now) sorts the shown elements when modifying the searchString. The implemented ordering sorts based on how "deep the needle is in the haystack", meaning that searching for "st" in the elements "Install" and "Study" will order them as "Study" and "Install". Previously there was no ordering and when using GridSelect to select workspaces, the ordering was not consistent, as the list of workspaces (if not modified manually) is ordered by last used. In this case either "Study" or "Install" would come first depending on which workspace was last visited. By not having it consistent, it really fucks with muscle memory. I'm open for other ways of sorting the elements when the searchString is not null, however sorting them in the order of "the depth of the match" seems to be very intuitive, as I (and others I have talked to) tend to write the first letters of the word that is searched for. -- Reenberg

3 2

FloatKeys and window decorations
by Sergey Khorev 07 May '12

07 May '12

Hi, It looks like contrib's FloatKeys do not play nicely with decorated windows. For instance, if I activate simpleFloat and try to use keysMoveWindow, the decoration simply disappears. Moreover, if I remove the call to `float' from keysMoveWindow, I end up with two separate pieces: the window moved and its decoration. Any idea how it can be fixed? Or are those fundamentally incompatible?

2 1

Changes to XPrompt
by Carlos López Camey 06 May '12

06 May '12

Hello xmonaders, I started to code something upon XPrompt, but I noticed that what I would like the code to do, needs some changes in XPrompt, which I'm not sure should go into XPrompt, or into a new type of Prompt (not related to XPrompt). This question sometimes makes me doubt when changing XPrompt.hs, so I thought I would ask and decide where to do it. The changes would be: * Autocomplete based on several modes (there is always a mode set) The autocomplete items are generally path to files, mode 1 could use for example `locate %s`, mode 2 `recollq` [0] (searches for tokens inside files) and mode 3 `locate --regexp %s` to autocomplete. * one-column-only list of autocompletions For the purpose, they are always paths, so they are quite large to keep it in different columns. But this be a setting on the configuration. * Navigating through completion items and changing autocompletion list on "real time" There is always an item highlighted (if items > 0) The highlighted item not necesarilly is equal to the prompt buffer text. I may write "xmonad.hs" but the autocomplete item shows a full path highlighted. This implies adding an additional field to XPState, complIndex :: Int, that knows which item to highlight next (not based on the buffer's text) * Action is not necesarilly a String -> X a. I'd like to count on a Map Extension (String -> String) in some config, where type Extension = String. This map would describe what to do with each file depending on its extension. e.g. an element of the map could be (".org",\path -> "emacs "++path). So I'm not sure how the new signature would be: String -> X a? but this String would be the command sent to spawn, computed using a function that uses the map described above. I know this is a long list of features, but I hope it to be materialized eventually. My questions would be then, is it right to do a new XPrompt? it's hard not to think on changes braking current xmonad.hs configurations. In case a new Prompt is needed, name it LauncherPrompt, does it belong to xmonad-contrib? Creating a new Prompt would imply having different config types (XPConfig and LauncherPromptConfig), and very similar actions on both each prompt module.. for example killBefore :: XP() and killBefore :: LauncherP (). That's not acceptable IMHO. I appreciate your comments, [0] http://www.lesbonscomptes.com/recoll/

2 1

* Converted UrgencyHooks to simple Window -> X () functions [patch]
by David McLean 04 May '12

04 May '12

1 patch for repository http://code.haskell.org/XMonadContrib: Fri May 4 10:38:29 EST 2012 gopsychonauts(a)gmail.com * Converted UrgencyHooks to simple Window -> X () functions Previously, UrgencyHooks were members of the typeclass UrgencyHook, and had to implement Read and Show instances. This was for historical reasons, as originally the UrgencyHook was stored as a layout modifier. Changes in the module's implementation---it now uses handleEventHook and logHook instead---mean that those constraints are no longer needed. Thus, changing the UrgencyHook to a simpler single type is possible. This makes writing new UrgencyHooks simpler, as now they're just functions and don't require a whole new typeclass instance. It also allows for useful behaviour such as UrgencyHook being a Monoid: this increases cohesion in an XConfig definition since multiple UrgencyHooks may now be combined with <+>, just as manageHook and logHook may be. Regrettably, this does break compatibility with any previously-defined custom urgency hooks, since the UrgencyHook typeclass no longer exists.

3 4

Workspace Layout for Dia
by Eyal Erez 03 May '12

03 May '12

Hi, I'm trying to configure one of my workspaces for using Dia ( http://live.gnome.org/Dia) When I used Dia I have three application windows open: 1. The main drawing window (Role: "diagram_window") 2. Toolbox window (Role: "toolbox_window") 3. Layer window (Role: "layer_window") I would like to have them setup in the following way (sorry for the bad ascii art). The 2 and 3 windows can be on the left or the right, I don't really care, and 2 or 3 can be on top, doesn't matter: ----------- |2| | |-| 1 | |3| | ----------- The closest I've been able to model this is using the existing Gimp example: dia = withIM (0.15) (Role "toolbox_window") $ reflectHoriz $ withIM (0.2) (Role "layer_window") Full However, this produces the following layout, which is good for Gimp, but less for Dia: ----------- | | | | |2| 1 |3| | | | | ----------- How can I configure the first case? It looks like it's a Tall layout with the right ratio, but how do I get the right windows in right place:? Thank you, -- ** There are 10 types of people, those who know binary and those who don't.

3 4

Focus problem with Java applications?
by Robert Sawko 03 May '12

03 May '12

Dear All, I am a relative newcomer to xmonad. I have been using it for the last couple of months and I enjoy it immensely but there's an issue which started to bug me recently. I can't seem to edit some textboxes in Java applications. I already have wmname LG3D in my xinitrc. I have found and read this thread http://code.google.com/p/xmonad/issues/detail?id=177 and tried the ICCCMFocus trick but no avail. Is this a known bug? Is there any fix to it? The java application I use is geogebra and matlab. geogebra for instance does not allow me to modify slider settings that are presented in a dialogue window. Please let me know if there's any possibility of getting this fixed. Robert

2 1

[patch] getXMonadDir in XMonad.Hooks.Script
by Julia Jomantaite 01 May '12

01 May '12

Hi, I think it would be better to reuse the existing getXMonadDir function in XMonad.Hooks.Script rather than get the home directory and concatenate it with "/.xmonad". -- Julia

1 0

Issue 499 in xmonad: X.L.LayoutHints tries to handle windows without a sizehint
by codesite-noreply＠google.com 30 Apr '12

30 Apr '12

Status: New Owner: ---- New issue 499 by MathStuf(a)gmail.com: X.L.LayoutHints tries to handle windows without a sizehint http://code.google.com/p/xmonad/issues/detail?id=499 What steps will reproduce the problem? 1. Use a program which doesn't set size hints (sxiv and feh image viewers are two I've found). 2. Move focus around with layoutHints applied 3. Watch window change between 1x1, 1xn, mx1, proper size, and (rarely) fullscreen. What is the expected output? What do you see instead? layoutHints should ignore windows without size hints. What version of the product are you using? On what operating system? Fedora Rawhide with darcs as of 2012-02-29. Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". It's large, but I've narrowed it down to layoutHints. X11 bindings bug filed at: https://github.com/haskell-pkg-janitors/X11/issues/3

1 1

[patch] recompile correctly identifying source files in ~/.xmonad/lib
by David McLean 30 Apr '12

30 Apr '12

2 1

How set new floating window gets on top ?
by David Unric 28 Apr '12

28 Apr '12

Hi, even with manageHook set to manageHook of defaultConfig, all new floating windows created on workspace with simplestFloat or simpleFloat layouts recieve focus but are placed _bellow_ current windows which I find very frustrating. For example on empty simplestFloat workspace I launch xterm, then launch gvim. Gvim gets focus but appears behind xterm (bellow in window stack sense). Maybe I'm not smart enough but I can't find how to change this behaviour of floating layout. I'd simply need all new floating windows are placed on top of the stack. Any idea ? Thanks in an advance. David

2 1