From omari at smileystation.com  Mon Feb  1 13:41:41 2010
From: omari at smileystation.com (Omari Norman)
Date: Mon Feb  1 13:14:03 2010
Subject: [xmonad] make DynamicLog prefix workspace names with number
In-Reply-To: <470538.82872.qm@web111807.mail.gq1.yahoo.com>
References: <ccd8be491001291823k2be7258crd28faeba1e866139@mail.gmail.com>
	<470538.82872.qm@web111807.mail.gq1.yahoo.com>
Message-ID: <20100201184141.GA12263@barry.normanonet.net>

Hi Lara,

> Following up on this question, is it possible to have the log
> automatically set the name of the workspace to the programs running in
> it? 

Can't help you there :( I'm rudimentary with xmonad and haskell...

2010/1/30 Omari Norman <omari@smileystation.com>:

> Is there any easy way to get DynamicLog to prefix the names of
> workspaces with numbers?

I cobbled together something rudimentary in zsh. Surely this could be
done in Haskell using the ppOutput function in dynamicLog, and maybe
when I have a few minutes to mess around with Haskell I'll do that. This
is very primitive--workspace names can't have spaces--but it does
(currently) work, in case someone else finds it handy.

-------------- next part --------------
#!/bin/zsh

# xmobar_with_ws_numbers - takes output from xmonad intended for
# xmobar. Changes the workspaces portion, adding workspace numbers.
# Then, pipes the output to xmobar.
#
# Assumes there are only alphanumeric characters [a-zA-Z0-9] in
# workspace names, and it will likely choke on anything that's not
# ASCII. Thus you can't have spaces or symbols in workspace names.

# Given a workspace number on $1 and the entire workspace text on
# $2, echoes the workspace text with a workspace number added.
# Takes into account the format of xmobar input, which has xml-like
# tags to indicate colors.
addNumber() {
    if echo $2 | grep -q '<'; then
        echo -n $2 | sed -r 's/>([a-zA-Z0-9]*)</>'$1':\1</'
    else
        echo -n "$1:$2"
    fi
}

while read line; do
    workspaces_str=$(echo $line | cut -d: -f 1)
    workspaces_arr=(${(s: :)workspaces_str})
    for num in $(seq 1 ${#workspaces_arr}); do
        addNumber $num ${workspaces_arr[$num]}
        echo -n ' '
    done
    echo -n ':'
    echo $line | cut -d: -f 2-
done | xmobar
From hgabreu at gmail.com  Mon Feb  1 14:51:22 2010
From: hgabreu at gmail.com (Henrique G. Abreu)
Date: Mon Feb  1 14:23:10 2010
Subject: [xmonad] (sub)layout set up
In-Reply-To: <70d6e6e41002010547w4bb4a187v23836f9944298da7@mail.gmail.com>
References: <ee86ab31001261905y7a5af23bi6bb3b0dad2c7ae39@mail.gmail.com> 
	<70d6e6e41002010547w4bb4a187v23836f9944298da7@mail.gmail.com>
Message-ID: <ee86ab31002011151xe0af42bi7717676a3521be84@mail.gmail.com>

Thanks Quentin, I've got sublayout working with Adam's help at #xmonad.
I've noticed this "limitation" you said about tabbed being the outer
layout, but it's no big deal.
The feature I really missed was a way to auto-group some windows,
by matching them in the manageHook or something like X.L.ComboP does.

Henrique G. Abreu



On Mon, Feb 1, 2010 at 11:47, Quentin Moser <moserq@gmail.com> wrote:
> Hi,
>
> SubLayouts is probably closest to what you want. You can use a layout such as
>
>> subLayout [] row $ tall ||| Mirror tall ||| Full
>> ? where row = Mirror $ Tall 0 0 0
>> ? ? ? ? tall = Tall 1 (3/100) 0.5
>
> Basically, this will manage your windows according to the second
> layout (tall ||| ...), but allow you to put several windows together
> into a single "group", inside of which they will be placed according
> to the first layout (row).
>
> Something you can not do, however, is have a tabbed layout as your
> "main" layout, as in your example. The way XMonad.Layout.Decoration
> handles tabbing simply doesn't work when all your windows aren't
> stacked exactly on top of each other.
>
> Tabbing the windows inside a sub-group works, though, and SubLayout
> defines a "subTabbed" modifier precisely for that.
>
>
> On Wed, Jan 27, 2010 at 4:05 AM, Henrique G. Abreu <hgabreu@gmail.com> wrote:
>> Hi all,
>>
>> I want to set up a layout that treats two matched windows as one, like
>> always side-by-side.
>> I also want to be able to switch the "master" layout, like: Tall ..
>> ||| Mirror Tall .. ||| simpleTabbed
>> and keep this pair of windows always together side-by-side in this layouts.
>> Of course I will have other windows involved in this layouts and
>> that's the point.
>>
>> I've tried sublayout but I found it to hard to set.
>> Also tried ComboP combineTwoP, which comes close to what I want but
>> has sad limitations
>> like "reserving" the area to the 2nd layout and not being able to
>> switch the ruling layout.
>> Does it make sense or I'm wanting something too odd?
>>
>> Thanks,
>> Henrique G. Abreu
>> _______________________________________________
>> xmonad mailing list
>> xmonad@haskell.org
>> http://www.haskell.org/mailman/listinfo/xmonad
>>
>
From ff0000.it at gmail.com  Mon Feb  1 17:13:59 2010
From: ff0000.it at gmail.com (Alessandro Massignan)
Date: Mon Feb  1 16:45:56 2010
Subject: [xmonad] focus handling
Message-ID: <162fabca1002011413r1e0968a0g18b8f73382b43395@mail.gmail.com>

Hi all,

i've a workspace for pidgin/skype and i wonder if their roster window should
avoid focus switching (focusUp and focusDown) letting me to focus only the
other windows (chats, options, ...).
Is there a way to prevent a window being focused (eg. by classname, role,
...)?

thanks to all,
ff0000
From laramichaels1978 at yahoo.com  Mon Feb  1 17:41:29 2010
From: laramichaels1978 at yahoo.com (Lara Michaels)
Date: Mon Feb  1 17:13:03 2010
Subject: [xmonad] make DynamicLog prefix workspace names with number
In-Reply-To: <20100201184141.GA12263@barry.normanonet.net>
Message-ID: <900136.22870.qm@web111807.mail.gq1.yahoo.com>

Hi Omari,

Many thanks, I will try it out!

Ivan, that is a good question. One could concatenate the progam names or something... : )

cheers

l

--- On Mon, 2/1/10, Omari Norman <omari@smileystation.com> wrote:

> From: Omari Norman <omari@smileystation.com>
> Subject: Re: [xmonad] make DynamicLog prefix workspace names with number
> To: xmonad@haskell.org
> Date: Monday, February 1, 2010, 6:41 PM
> Hi Lara,
> 
> > Following up on this question, is it possible to have
> the log
> > automatically set the name of the workspace to the
> programs running in
> > it? 
> 
> Can't help you there :( I'm rudimentary with xmonad and
> haskell...
> 
> 2010/1/30 Omari Norman <omari@smileystation.com>:
> 
> > Is there any easy way to get DynamicLog to prefix the
> names of
> > workspaces with numbers?
> 
> I cobbled together something rudimentary in zsh. Surely
> this could be
> done in Haskell using the ppOutput function in dynamicLog,
> and maybe
> when I have a few minutes to mess around with Haskell I'll
> do that. This
> is very primitive--workspace names can't have spaces--but
> it does
> (currently) work, in case someone else finds it handy.
> 
> 
> -----Inline Attachment Follows-----
> 
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
> 


      
From hgabreu at gmail.com  Mon Feb  1 21:48:04 2010
From: hgabreu at gmail.com (Henrique G. Abreu)
Date: Mon Feb  1 21:19:52 2010
Subject: [xmonad] focus handling
In-Reply-To: <162fabca1002011413r1e0968a0g18b8f73382b43395@mail.gmail.com>
References: <162fabca1002011413r1e0968a0g18b8f73382b43395@mail.gmail.com>
Message-ID: <ee86ab31002011848i442344f9kde87f55659119ec4@mail.gmail.com>

I think you're looking for XMonad.Layout.BoringWindows

Henrique G. Abreu



On Mon, Feb 1, 2010 at 20:13, Alessandro Massignan <ff0000.it@gmail.com> wrote:
> Hi all,
>
> i've a workspace for pidgin/skype and i wonder if their roster window should
> avoid focus switching (focusUp and focusDown) letting me to focus only the
> other windows (chats, options, ...).
> Is there a way to prevent a window being focused (eg. by classname, role,
> ...)?
>
> thanks to all,
> ff0000
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
From vogt.adam at gmail.com  Tue Feb  2 00:36:29 2010
From: vogt.adam at gmail.com (Adam Vogt)
Date: Tue Feb  2 00:08:20 2010
Subject: [xmonad] focus handling
In-Reply-To: <162fabca1002011413r1e0968a0g18b8f73382b43395@mail.gmail.com>
References: <162fabca1002011413r1e0968a0g18b8f73382b43395@mail.gmail.com>
Message-ID: <20100202053629.GA9223@smuckers.phub.net.cable.rogers.com>

* On Monday, February 01 2010, Alessandro Massignan wrote:

>Hi all,
>
>i've a workspace for pidgin/skype and i wonder if their roster window should
>avoid focus switching (focusUp and focusDown) letting me to focus only the
>other windows (chats, options, ...).
>Is there a way to prevent a window being focused (eg. by classname, role,
>...)?
>
>thanks to all,
>ff0000

This can be accomplished with XMonad.Layout.BoringWindows [1]. While the
module doesn't export functionality to directly set target windows as
boring, you can work around that in your config with something like:

] import XMonad
] import qualified XMonad.StackSet as W
] import XMonad.Layout.BoringWindows
] 
] -- | Variant of 'markBoring', if 'XMonad.Layout.BoringWindows.IsBoring'
] --   was exported we could write much shorter:
] -- > markBoring' = sendMessage . IsBoring
] markBoring' :: Window -> X ()
] markBoring' w = do
]     st@XState { windowset = ws } <- get
]     env <- ask
]     (_,st') <- io $ runX env
]                          st{ windowset = W.insertUp w ws }
]                          markBoring
] 
]     -- this should encourage consideration of some alternative to the built-in
]     -- records: all this does is set the current layout in st to the one gotten
]     -- from st'
]     put $ st{ windowset =
]             ws{ W.current =
]               (W.current ws){ W.workspace =
]                (W.workspace $ W.current ws){ W.layout =
]                         W.layout $ W.workspace
]                         $ W.current $ windowset st'
]               }}}}
] 
] doBoring :: ManageHook
] doBoring = do
]     w <- ask
]     liftX $ markBoring' w
]     idHook

Then use doBoring as other ManageHooks. This also requires that you
modify your layout and add some keybindings as described in the
BoringWindows documentation.

However, if you reset your layout (mod-shift-space), then you would have
to run that manageHook over all the windows present in your workspace to
get your correct behavior back. Ex. you could use the following rerunMH
function to run a managehook (the one you defined using doBoring) on all
the windows in your current workspace:

] rerunMH :: ManageHook -> X ()
] rerunMH mhook = withWindowSet $ mapM_ (runQuery mhook) .  W.index

This might make sense to run after resetting layouts (mod-shift-space)
as this fragment that fits in some keybindings does (for a specific
managehook):

]   ,((modm .|. shiftMask,xK_space),
]           do { setLayout . Layout . layoutHook =<< ask
]              ; rerunMH (className =? "foo" --> doBoring)
]              }
]       )

Hope this helps,
--
Adam

[1] http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-BoringWindows.html
From ff0000.it at gmail.com  Tue Feb  2 04:30:37 2010
From: ff0000.it at gmail.com (Alessandro Massignan)
Date: Tue Feb  2 04:02:30 2010
Subject: [xmonad] focus handling
In-Reply-To: <20100202053629.GA9223@smuckers.phub.net.cable.rogers.com>
References: <162fabca1002011413r1e0968a0g18b8f73382b43395@mail.gmail.com> 
	<20100202053629.GA9223@smuckers.phub.net.cable.rogers.com>
Message-ID: <162fabca1002020130w578cae45s1e64aba339bc6e86@mail.gmail.com>

Thanks Henrique and Adam,

helps deep in Hask-Hell :-)
Ok, i'm still a total newbie and the code snippet looks a bit weird to
my eyes, but this encourage me to go on! :-)
I'll give a try to BoringWindows and i think i'll succeed, because
XMonad is a divine gift and, finally, i come to the definitive WM ;-)

Thanks again!
ff0000
From damian.only at gmail.com  Tue Feb  2 06:04:36 2010
From: damian.only at gmail.com (Damian)
Date: Tue Feb  2 05:36:28 2010
Subject: [xmonad] Gaps between windows
Message-ID: <47a330c51002020304uec4b0dbidddd6ec5f142cace@mail.gmail.com>

(or in winter I need some color...)

Hello,

I want to configure xmonad so that it leaves some amount of space
between windows. Here is a mockup:
    http://yfrog.com/1glayoutiwantp

The closest layout I could find is XMonad.Layout.Gaps, but it does not
leave space between windows, it introduces a gap with regard to the
screen.

Any ideas about how to get this behaviour?

Thanks in advance,
Damian.
From hgabreu at gmail.com  Tue Feb  2 06:47:25 2010
From: hgabreu at gmail.com (Henrique G. Abreu)
Date: Tue Feb  2 06:19:13 2010
Subject: [xmonad] Gaps between windows
In-Reply-To: <47a330c51002020304uec4b0dbidddd6ec5f142cace@mail.gmail.com>
References: <47a330c51002020304uec4b0dbidddd6ec5f142cace@mail.gmail.com>
Message-ID: <ee86ab31002020347h6f895f72l6cf66db326df87ff@mail.gmail.com>

I think your looking for import XMonad.Layout.Spacing
http://www.xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-Spacing.html

Henrique G. Abreu



On Tue, Feb 2, 2010 at 09:04, Damian <damian.only@gmail.com> wrote:
> (or in winter I need some color...)
>
> Hello,
>
> I want to configure xmonad so that it leaves some amount of space
> between windows. Here is a mockup:
> ? ?http://yfrog.com/1glayoutiwantp
>
> The closest layout I could find is XMonad.Layout.Gaps, but it does not
> leave space between windows, it introduces a gap with regard to the
> screen.
>
> Any ideas about how to get this behaviour?
>
> Thanks in advance,
> Damian.
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
From codesite-noreply at google.com  Tue Feb  2 07:06:44 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Tue Feb  2 06:38:16 2010
Subject: [xmonad] Issue 369 in xmonad: Html5 video fullscreen window doesn't
	stay in fullscreen mode
Message-ID: <0-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 369 by mceier: Html5 video fullscreen window doesn't stay in  
fullscreen mode
http://code.google.com/p/xmonad/issues/detail?id=369

What steps will reproduce the problem?
1. open http://diveintohtml5.org/video.html#movie in firefox 3.6 ( browser
that supports html5 <video> tag )
2. Do right mouse click on the movie and select fullscreen mode
3.

What is the expected output? What do you see instead?
Fullscreen window should stay in fullscreen mode and play video, but
instead it is automatically closed after it is opened

What version of the product are you using? On what operating system?
xmonad 0.9.1 on gentoo

Are you using an xmonad.hs?  Please attach it and the output of "xmonad
--recompile".
yes
"xmonad --recompile" outputs nothing.

Please provide any additional information below.
When myManageHook ( from default xmonad.hs ) is defined as follows:
myManageHook = doFullFloat
video works as expected ( it does not close automatically ), but every
window is "full float"
when myManageHook is:
myManageHook = isFullscreen --> doFullFloat
this fullscreen window closes automatically
also tried :
myManageHook = composeAll [ className =? "Toplevel" --> doFullFloat,
isFullscreen --> doFullFloat ]
it also didn't help.
Attached xprop output ( run in awesome ).
Flash fullscreen windows work as expected.


Attachments:
	fs_prop.txt  9.8 KB

--
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
From damian.only at gmail.com  Tue Feb  2 09:57:37 2010
From: damian.only at gmail.com (Damian)
Date: Tue Feb  2 09:29:29 2010
Subject: [xmonad] Gaps between windows
In-Reply-To: <ee86ab31002020347h6f895f72l6cf66db326df87ff@mail.gmail.com>
References: <47a330c51002020304uec4b0dbidddd6ec5f142cace@mail.gmail.com> 
	<ee86ab31002020347h6f895f72l6cf66db326df87ff@mail.gmail.com>
Message-ID: <47a330c51002020657r1f096bc3l1b0f480fd8b5cd9c@mail.gmail.com>

On Tue, Feb 2, 2010 at 12:47 PM, Henrique G. Abreu <hgabreu@gmail.com> wrote:
> I think your looking for import XMonad.Layout.Spacing
> http://www.xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-Spacing.html
Perfect! I totally missed it from
http://www.xmonad.org/xmonad-docs/xmonad-contrib/. Thanks a lot.

My desktop looks happier now.
From codesite-noreply at google.com  Tue Feb  2 21:49:55 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Tue Feb  2 21:21:26 2010
Subject: [xmonad] Re: Issue 69 in xmonad: Key binding improvements
In-Reply-To: <8-3425899027203913298-14001011751146869357-codesite-noreply=google.com@googlecode.com>
References: <8-3425899027203913298-14001011751146869357-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-14001011751146869357-codesite-noreply=google.com@googlecode.com>
Message-ID: <9-3425899027203913298-14001011751146869357-codesite-noreply=google.com@googlecode.com>


Comment #9 on issue 69 by mark.stosberg: Key binding improvements
http://code.google.com/p/xmonad/issues/detail?id=69

I'm struggling to try Xmonad because I don't have a windows key and  
the "loving
caress" of xmodmap (as the original poster puts it) is not so gentle. As  
someone new
to Xmonad and Haskell, the "sufficient" workaround is not simple at all:

  - delete all of the default keybindings
  - add a single keybinding for your desired prefix key that activates a  
submap
  - add all the desired keybindings to your submap

I wouldn't know how to start with implementing that.

I even tried the "extra user-friendly" BlueTile alternative. It also  
assumed I had a
Windows key...

--
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
From codesite-noreply at google.com  Tue Feb  2 22:30:31 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Tue Feb  2 22:02:01 2010
Subject: [xmonad] Issue 370 in xmonad: Xinerama, CycleWS & Empt workspaces
Message-ID: <0-3425899027203913298-10628488929604801762-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 370 by seansorrell: Xinerama, CycleWS & Empt workspaces
http://code.google.com/p/xmonad/issues/detail?id=370

What steps will reproduce the problem?
1. On a Xinerama setup, pull up one workspace with a window, and one without
2. From the workspace with the window, use a keybinding to call
XMonad.Actions.CycleWS nextScreen (or prevScreen)


What is the expected output? What do you see instead?
The cursor _should_ jump reliably to the screen without the window, but it
only works about 3 times out of 10.


Suggestion: move the cursor over a few extra pixels to ensure that it
really is on the correct screen


What version of the product are you using? On what operating system?
xmonad 0.9 on Archlinux 64-bit
nVidia 9800GT

Attachments:
	xmonad.hs  5.7 KB
	xorg.conf  1.3 KB

--
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
From v.dijk.bas at gmail.com  Wed Feb  3 05:57:31 2010
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Wed Feb  3 05:29:22 2010
Subject: [xmonad] Respecting the Window Manager Input Hint
Message-ID: <f73f66151002030257i6f97501fm6961ecc8d0b47de2@mail.gmail.com>

Hello,

I'm developing a scientific instrument which runs Gentoo Linux and
uses Haskell for running the measurements. The device also uses XMonad
for window management. Because the device has a touchscreen instead of
a physical keyboard, I would like to use the the on-screen-keyboard:
onboard [1].

The way onboard is supposed to work is that you move the focus to the
window that needs input and then click on one of the onboard keys.
Onboard will then generate an X11 event that will be send to the
window that has focus.

For correct operation, it's crucial that onboard does not get focus
itself because then the key events will be send to itself! To prevent
getting focus, onboard gives a hint to the window manager to not
accept focus.

$ xprop     # (click on the onboard window)
...
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: False
...

Unfortunately xmonad does not respect this hint by focusing the
onboard window anyway when my pointer enters it.

How can I prevent this?

Possible solutions:

* Use a manage hook that removes onboard from xmonad management so
that it won't get focus anymore:
className =? "Onboard" --> doIgnore
While this solves my problem this has the disadvantage that the
onboard window is not managed anymore.

* Use XMonad.Layout.BoringWindows and the code in the recent thread on
"focus handling". Unfortunately I didn't get this to work. (Maybe I
have to put some more time into this)

* Patch xmonad to respect the Window Manager Input Hint by not giving
focus to windows that don't want't to get focus.
How difficult would this be?

regards,

Bas

[1] https://wiki.ubuntu.com/Accessibility/Projects/onBoard
From codesite-noreply at google.com  Wed Feb  3 10:14:57 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Wed Feb  3 09:46:26 2010
Subject: [xmonad] Re: Issue 69 in xmonad: Key binding improvements
In-Reply-To: <9-3425899027203913298-14001011751146869357-codesite-noreply=google.com@googlecode.com>
References: <9-3425899027203913298-14001011751146869357-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-14001011751146869357-codesite-noreply=google.com@googlecode.com>
Message-ID: <10-3425899027203913298-14001011751146869357-codesite-noreply=google.com@googlecode.com>


Comment #10 on issue 69 by korp...@korpios.com: Key binding improvements
http://code.google.com/p/xmonad/issues/detail?id=69

On my system, at least, my left and right modifier keys of the same type  
(e.g.,
"alt", "shift") are seen by X as different keys; this leaves open the  
possibility of
using one of the two for Xmonad, and the other for its original purpose.   
You can
check by running "xev" and seeing what key code you get when you press  
those keys; if
they are indeed different, and if you are amenable to the idea (e.g., if  
you notice
you always use only the left or right version of that key), you should be  
able to
write a much simpler xmodmap than "delete and re-add everything" which gets  
you what
you want.

--
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
From v.dijk.bas at gmail.com  Wed Feb  3 11:05:50 2010
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Wed Feb  3 10:37:39 2010
Subject: [xmonad] Re: Respecting the Window Manager Input Hint
In-Reply-To: <f73f66151002030257i6f97501fm6961ecc8d0b47de2@mail.gmail.com>
References: <f73f66151002030257i6f97501fm6961ecc8d0b47de2@mail.gmail.com>
Message-ID: <f73f66151002030805w6526993ft639746a9b7d8bcee@mail.gmail.com>

The attached patch does what I want. It only sets the input focus when
the window needs it:

hunk ./XMonad/Operations.hs 330

     -- If we ungrab buttons on the root window, we lose our mouse bindings.
     whenX (not <$> isRoot w) $ setButtonGrab False w
-    io $ do setInputFocus dpy w revertToPointerRoot 0
+    io $ do needsInput <- liftM wmh_input $ getWMHints dpy w
+            when needsInput $ setInputFocus dpy w revertToPointerRoot 0
             -- raiseWindow dpy w

Can anybody review this?

Also see: http://tronche.com/gui/x/xlib/ICC/client-to-window-manager/wm-hints.html

regards,

Bas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: only_setInputFocus_when_needed.patch
Type: application/octet-stream
Size: 3620 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/xmonad/attachments/20100203/ed40838c/only_setInputFocus_when_needed.obj
From wirtwolff at gmail.com  Wed Feb  3 12:10:12 2010
From: wirtwolff at gmail.com (Wirt Wolff)
Date: Wed Feb  3 11:41:46 2010
Subject: [xmonad] Respecting the Window Manager Input Hint
In-Reply-To: <f73f66151002030257i6f97501fm6961ecc8d0b47de2@mail.gmail.com>
References: <f73f66151002030257i6f97501fm6961ecc8d0b47de2@mail.gmail.com>
Message-ID: <1265215843-sup-5183@chigamba>

Excerpts from Bas van Dijk's message of Wed Feb 03 03:57:31 -0700 2010:
>
> ..  <snip>
> 
> For correct operation, it's crucial that onboard does not get focus
> itself because then the key events will be send to itself! To prevent
> getting focus, onboard gives a hint to the window manager to not
> accept focus.
> 
> $ xprop     # (click on the onboard window)
> ...
> WM_HINTS(WM_HINTS):
>         Client accepts input or input focus: False
> ...
> 
> Unfortunately xmonad does not respect this hint by focusing the
> onboard window anyway when my pointer enters it.
> 
> How can I prevent this?
>
> Possible solutions:
> 
> * Use a manage hook that removes onboard from xmonad management so
> that it won't get focus anymore:
> className =? "Onboard" --> doIgnore
> While this solves my problem this has the disadvantage that the
> onboard window is not managed anymore.
> 
> * Use XMonad.Layout.BoringWindows and the code in the recent thread on
> "focus handling". Unfortunately I didn't get this to work. (Maybe I
> have to put some more time into this)

In my experience these are painful if any windows are floating,
as it's difficult to track which windows cover which as z-order
gets shuffled. (Not familiar with recent thread, though, just
"standard" boring BoringWindows.)

> 
> * Patch xmonad to respect the Window Manager Input Hint by not giving
> focus to windows that don't want't to get focus.
> How difficult would this be?

Warning, these are quick responses, not thought through very deeply;
hopfully they are helpful. ;-)

Might be worth trying out the patches posted on issue 177 on the
tracker [177]; there are ones applicable to recent darcs or to
a darcs get of tag 0.9 xmonad core. While issue 177 doesn't
mention onboard app specifically, nor the WM_HINTS focus alerting
method you describe, those patches enabled proper operation of
similar apps, like scim input and Cellwriter input panel.
Hopefully they work for you even without modification, but worth
a look. 

For an example of reading state from wm hints in handleEventHook,
see fullscreenEventHook in contrib, in darcs version of
XMonad.Hooks.EwmhDesktops. This might be helpful coupled with
boring approach if you did decide to go that route.

[177] http://code.google.com/p/xmonad/issues/detail?id=177
-- 
wmw
From codesite-noreply at google.com  Wed Feb  3 14:30:21 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Wed Feb  3 14:01:50 2010
Subject: [xmonad] Re: Issue 369 in xmonad: Html5 video fullscreen window
	doesn't stay in fullscreen mode
In-Reply-To: <0-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
References: <0-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
Message-ID: <1-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>


Comment #1 on issue 369 by audunskaugen: Html5 video fullscreen window  
doesn't stay in fullscreen mode
http://code.google.com/p/xmonad/issues/detail?id=369

I tested it a bit. For me too it doesn't work with just the doFullFloat  
manage hook,
but it does work with the recently merged fullScreenEventHook (see #339).

That eventHook hasn't made it into a release yet, but you can add it to  
your config,
like in the one attached.



Attachments:
	totemFullscreen.hs  1.1 KB

--
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
From codesite-noreply at google.com  Wed Feb  3 15:41:07 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Wed Feb  3 15:12:34 2010
Subject: [xmonad] Re: Issue 369 in xmonad: Html5 video fullscreen window
	doesn't stay in fullscreen mode
In-Reply-To: <1-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
Message-ID: <2-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>


Comment #2 on issue 369 by mceier: Html5 video fullscreen window doesn't  
stay in fullscreen mode
http://code.google.com/p/xmonad/issues/detail?id=369

I tried using totemFullscreen.hs, but it didn't solve the problem. I am
attaching my xmonad.hs, with eventHook from totemFullscreen.hs.

Did you try to play the video from the url I have given, in fullscreen  
mode ?


Attachments:
	xmonad.hs  14.2 KB

--
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
From codesite-noreply at google.com  Wed Feb  3 15:45:15 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Wed Feb  3 15:16:43 2010
Subject: [xmonad] Re: Issue 369 in xmonad: Html5 video fullscreen window
	doesn't stay in fullscreen mode
In-Reply-To: <2-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
References: <2-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
Message-ID: <3-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>


Comment #3 on issue 369 by mceier: Html5 video fullscreen window doesn't  
stay in fullscreen mode
http://code.google.com/p/xmonad/issues/detail?id=369

one more thing, for me it did work with doFullFloat, but without  
isFullscreen before
it, e.g. myManageHook = doFullFloat, but that makes every window FullFloat,  
not just
the fullscreen video window.


--
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
From v.dijk.bas at gmail.com  Wed Feb  3 16:53:40 2010
From: v.dijk.bas at gmail.com (Bas van Dijk)
Date: Wed Feb  3 16:25:29 2010
Subject: [xmonad] Respecting the Window Manager Input Hint
In-Reply-To: <1265215843-sup-5183@chigamba>
References: <f73f66151002030257i6f97501fm6961ecc8d0b47de2@mail.gmail.com> 
	<1265215843-sup-5183@chigamba>
Message-ID: <f73f66151002031353o75e02acfx6f55f5b8c4074714@mail.gmail.com>

On Wed, Feb 3, 2010 at 6:10 PM, Wirt Wolff <wirtwolff@gmail.com> wrote:
> Might be worth trying out the patches posted on issue 177 on the tracker

It was definitely worth trying out the latest patch in issue 177 from
vogt.adam because it completely solves my bug!

(Note that both vogt's and my patch only call setInputFocus when the
input hint is set.)

I will add a comment to issue 177 indicating that the latest patch
also makes onboard work correctly.

Thanks very much,

Bas
From codesite-noreply at google.com  Wed Feb  3 16:57:15 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Wed Feb  3 16:28:42 2010
Subject: [xmonad] Re: Issue 177 in xmonad: xmonad does not follow ICCCM and
	ignores WM_TAKE_FOCUS protocol
In-Reply-To: <28-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
References: <28-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
Message-ID: <29-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>


Comment #29 on issue 177 by v.dijk.bas: xmonad does not follow ICCCM and  
ignores WM_TAKE_FOCUS protocol
http://code.google.com/p/xmonad/issues/detail?id=177

The latest patch from vogt.adam also makes the onboard[1] application work  
correctly.
Also see the discussion in [2].

[1] https://wiki.ubuntu.com/Accessibility/Projects/onBoard
[2] http://www.haskell.org/pipermail/xmonad/2010-February/009703.html

--
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
From codesite-noreply at google.com  Thu Feb  4 07:06:01 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Thu Feb  4 06:37:27 2010
Subject: [xmonad] Re: Issue 369 in xmonad: Html5 video fullscreen window
	doesn't stay in fullscreen mode
In-Reply-To: <3-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
References: <3-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
Message-ID: <4-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>


Comment #4 on issue 369 by audunskaugen: Html5 video fullscreen window  
doesn't stay in fullscreen mode
http://code.google.com/p/xmonad/issues/detail?id=369

That's strange. I tried to play the video in the url exactly as you said,  
and
fullscreened it using rightclick -> fullscreen.

I tested it now using just the minimal totemFullscreen.hs on another  
computer. It
worked there too. I didn't test with your config file, since it seems to  
include
lots of stuff outside of -contrib.

Are you running xmonad-0.9.1?

--
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
From codesite-noreply at google.com  Thu Feb  4 08:10:07 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Thu Feb  4 07:41:34 2010
Subject: [xmonad] Re: Issue 369 in xmonad: Html5 video fullscreen window
	doesn't stay in fullscreen mode
In-Reply-To: <4-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
References: <4-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
Message-ID: <5-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>


Comment #5 on issue 369 by mceier: Html5 video fullscreen window doesn't  
stay in fullscreen mode
http://code.google.com/p/xmonad/issues/detail?id=369

xmonad --version, shows:
xmonad 0.9.1

also portage shows:
x11-wm/xmonad-0.9.1 and x11-wm/xmonad-contrib-0.9.1 ( it is from haskell  
overlay )

so I'm pretty sure that I'm running xmonad-0.9.1

maybe my config is somehow broken ?



--
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
From codesite-noreply at google.com  Thu Feb  4 12:37:31 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Thu Feb  4 12:08:56 2010
Subject: [xmonad] Re: Issue 369 in xmonad: Html5 video fullscreen window
	doesn't stay in fullscreen mode
In-Reply-To: <5-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
References: <5-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
Message-ID: <6-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>


Comment #6 on issue 369 by mceier: Html5 video fullscreen window doesn't  
stay in fullscreen mode
http://code.google.com/p/xmonad/issues/detail?id=369

I created minimal xmonad.hs that uses totemFullscreen.hs, defaultConfig,  
minimal
keybindings and minimal set of layouts, and does not depend on gnome.
Results are that, in Full layout fullscreen video window closes  
automatically, in
tiled and Mirror tiled, it works as expected.


Attachments:
	xmonad.hs  2.3 KB

--
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
From jao at gnu.org  Fri Feb  5 17:20:00 2010
From: jao at gnu.org (Jose A. Ortega Ruiz)
Date: Fri Feb  5 17:40:20 2010
Subject: [xmonad] Re: xmobar add-ons
References: <87wrz2guac.fsf@newton.homeunix.net>
Message-ID: <87tytvfhpr.fsf@newton.homeunix.net>

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

> The code is available in this darcs repo:
>
>   <http://darcs.hacks-galore.org/jao/xmobar>
>
> which you can also browse on-line at
>
>   <http://darcs.hacks-galore.org/darcsweb/jao?r=xmobar;a=summary>

I've just added a couple more monitors: MBox, a mail monitor for mbox
files (need hinotify), and DiskU, a disk usage monitor. The latter uses
and FFI binding, and there was some trickery involved in making it work
on 64bit systems: if you try it on such a system, i'd be glad to hear of
that.

Thanks!
jao
-- 
Computers are useless.  They can only give you answers.
 - Pablo Picasso

From codesite-noreply at google.com  Sat Feb  6 07:24:54 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Sat Feb  6 06:56:13 2010
Subject: [xmonad] Re: Issue 369 in xmonad: Html5 video fullscreen window
	doesn't stay in fullscreen mode
In-Reply-To: <6-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
References: <6-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
Message-ID: <7-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>


Comment #7 on issue 369 by audunskaugen: Html5 video fullscreen window  
doesn't stay in fullscreen mode
http://code.google.com/p/xmonad/issues/detail?id=369

Ah, I hadn't tested it with full layout before. That's the behaviour I get  
as well. I
have no idea why a fullscreen layout would cause the window to close.

I believe that the fullscreen window automatically closes when another  
window gets
focused, so maybe the full layout fails to focus the new window properly?

--
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
From codesite-noreply at google.com  Sat Feb  6 09:13:12 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Sat Feb  6 08:44:32 2010
Subject: [xmonad] Re: Issue 369 in xmonad: Html5 video fullscreen window
	doesn't stay in fullscreen mode
In-Reply-To: <7-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
References: <7-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>
Message-ID: <8-3425899027203913298-13040023232612925621-codesite-noreply=google.com@googlecode.com>


Comment #8 on issue 369 by mceier: Html5 video fullscreen window doesn't  
stay in fullscreen mode
http://code.google.com/p/xmonad/issues/detail?id=369

I wrote Full-like layout, which instead of hiding non-focused windows, it  
sets their
Rectangle to 0 0 0 0. This seems to 'work', but there are some side-effects  
in at
least one application ( xterm - which looses its contents after resize ).
I think there should be better fix.


Attachments:
	xmonad.hs  2.7 KB

--
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
From darcswatch at nomeata.de  Sun Feb  7 00:05:25 2010
From: darcswatch at nomeata.de (darcswatch@nomeata.de)
Date: Sat Feb  6 23:36:44 2010
Subject: [xmonad] Applied: xmonad under ghc 6.12.1 -- progress
References: <20100112222839.GA2902@seas.upenn.edu>
Message-ID: <E1NdzKn-0003Qy-OF@quimby.ehbuehl.net>

This 1-patch bundle was just applied to http://code.haskell.org/XMonadContrib:

20100112172507  Brent Yorgey <byorgey@cis.upenn.edu>
 * suppress some warnings under ghc 6.12.1 and clean up redundant imports to get rid of some others.


-- 
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__code.haskell.org_XMonadContrib.html#bundle-c28694f0cb64dfdfdfa5e36d35b7225eeb4d3814
From darcswatch at nomeata.de  Sun Feb  7 00:05:28 2010
From: darcswatch at nomeata.de (darcswatch@nomeata.de)
Date: Sat Feb  6 23:36:46 2010
Subject: Applied: Re: [xmonad] xmonad under ghc 6.12.1 -- progress
References: <20100125045620.GA906@smuckers.phub.net.cable.rogers.com>
Message-ID: <E1NdzKq-0003R1-83@quimby.ehbuehl.net>

This 2-patches bundle was just applied to http://code.haskell.org/XMonadContrib:

20100112172507  Brent Yorgey <byorgey@cis.upenn.edu>
 * suppress some warnings under ghc 6.12.1 and clean up redundant imports to get rid of some others.

20100124203324  Adam Vogt <vogt.adam@gmail.com>
 * Use extensible-exceptions to allow base-3 or base-4


-- 
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__code.haskell.org_XMonadContrib.html#bundle-a9993ed19ad21869b00b03ad5cbd069f2b0c3f46
From spencerjanssen at gmail.com  Sun Feb  7 17:19:26 2010
From: spencerjanssen at gmail.com (Spencer Janssen)
Date: Sun Feb  7 16:50:43 2010
Subject: [xmonad] xmobar add-ons
In-Reply-To: <87wrz2guac.fsf@newton.homeunix.net>
References: <87wrz2guac.fsf@newton.homeunix.net>
Message-ID: <20100207221925.GA12141@celeborn>

On Thu, Jan 28, 2010 at 03:48:11PM +0100, Jose A. Ortega Ruiz wrote:
> 
> Hi,
> 
> I hope i'm not off-topic. I'm posting here because i haven't been able
> to contact Andrea, xmobar's maintainer, and i thought some of you might
> be interested in a couple of add-ons to xmobar that i've been hacking
> on:
> 
>  - two new monitors, MultiCpu and Disk, providing cpu usage for
>    multicores and disk I/O speeds, respectively.
>  - new options to all monitors to set maximum/minimum field widths and
>    padding characters.
> 
> The code is available in this darcs repo:
> 
>   <http://darcs.hacks-galore.org/jao/xmobar>
> 
> which you can also browse on-line at
> 
>   <http://darcs.hacks-galore.org/darcsweb/jao?r=xmobar;a=summary>
> 
> The additions are documented in the README file. Since this is my first
> Haskell hacking beyond tutorial snippets, i'm sure the code can be
> improved, so feel free to criticise it as deserved, or to ask for
> other improvements.
> 
> Thanks!
> jao

I have commit access to xmobar, feel free to 'darcs send' me any patches you
might have.

If you plan to do lots of xmobar hacking let me know and I can grant you
access as well.


Cheers,
Spencer Janssen
From darcswatch at nomeata.de  Sun Feb  7 17:25:29 2010
From: darcswatch at nomeata.de (darcswatch@nomeata.de)
Date: Sun Feb  7 16:56:45 2010
Subject: [xmonad] Applied: Re: darcs patch: Correct warnings with ghc-6.12
	(and 1	more)
References: <20100118182605.GA20000@smuckers.uwaterloo.ca>
Message-ID: <E1NeFZJ-0001oM-HK@quimby.ehbuehl.net>

This 1-patch bundle was just applied to http://code.haskell.org/xmonad:

20100118181532  Adam Vogt <vogt.adam@gmail.com>
 * Correct warnings with ghc-6.12
 Changes include:
   - compatibility with base-4 or 3 (base-2 untested) by using
     extensible-exceptions. This adds an additional dependency for users of
     ghc<6.10)
   - list all dependencies again when -ftesting (change in Cabal-1.8.0.2)
   - remove unnecessary imports
   - suppress -fwarn-unused-do-bind, with appropriate Cabal-1.8 workaround,
     described here:
     http://www.haskell.org/pipermail/xmonad/2010-January/009554.html


-- 
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__code.haskell.org_xmonad.html#bundle-91149097df05a2922a662109b68eb0b10be619c3
From codesite-noreply at google.com  Sun Feb  7 17:31:53 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Sun Feb  7 17:03:08 2010
Subject: [xmonad] Re: Issue 310 in xmonad: XMonad.Main.handle eats WM_NAME
	property changes
In-Reply-To: <2-3425899027203913298-8738805126544157789-codesite-noreply=google.com@googlecode.com>
References: <2-3425899027203913298-8738805126544157789-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-8738805126544157789-codesite-noreply=google.com@googlecode.com>
Message-ID: <3-3425899027203913298-8738805126544157789-codesite-noreply=google.com@googlecode.com>

Updates:
	Status: Fixed

Comment #3 on issue 310 by SpencerJanssen: XMonad.Main.handle eats WM_NAME  
property changes
http://code.google.com/p/xmonad/issues/detail?id=310

Applied.

--
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
From codesite-noreply at google.com  Mon Feb  8 06:56:44 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb  8 06:27:57 2010
Subject: [xmonad] Re: Issue 325 in xmonad: Layout.Spacing breaks
	Layout.WindowNavigation
In-Reply-To: <6-3425899027203913298-15849859458202010030-codesite-noreply=google.com@googlecode.com>
References: <6-3425899027203913298-15849859458202010030-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-15849859458202010030-codesite-noreply=google.com@googlecode.com>
Message-ID: <7-3425899027203913298-15849859458202010030-codesite-noreply=google.com@googlecode.com>


Comment #7 on issue 325 by damian.only: Layout.Spacing breaks  
Layout.WindowNavigation
http://code.google.com/p/xmonad/issues/detail?id=325

For me it doesn't matter if spacing is applied after, the WindowNavigation  
doesn't
behave properly.

For instance I have the following configuration:
   longMaster = windowNavigation (Tall 1 (3/100) (3/5))
   consoleLayout = spacing 10 longMaster ||| spacing 10 ( Mirror longMaster )

And the window navigation works fine for the first layout, but it fails in  
the
mirrored mode.

--
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
From codesite-noreply at google.com  Mon Feb  8 09:36:27 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb  8 09:07:40 2010
Subject: [xmonad] Issue 371 in xmonad: Program using popup menus can freeze
	the desktop
Message-ID: <0-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 371 by facundominguez: Program using popup menus can freeze the  
desktop
http://code.google.com/p/xmonad/issues/detail?id=371

> What steps will reproduce the problem?
1. Compile and run the attached Java program.
javac Grab.java
java Grab

> What is the expected output? What do you see instead?

The expected output is that I should be able to use the other desktop
applications while this application is running. What I see instead, is that
none of the windows reacts to mouse clicks or keyboard events until the
running java program is killed.

> What version of the product are you using? On what operating system?

I'm using xmonad 0.9.1 and java 1.6.0.12
Debian Lenny
Linux 2.6.26-2-686 #1 SMP Sat Dec 26 09:01:51 UTC 2009 i686 GNU/Linux

> Are you using an xmonad.hs?  Please attach it and the output of "xmonad
--recompile".

The output of "xmonad --recompile" is empty.
Find attached xmonad.hs

> Please provide any additional information below.

This bug is very annoying when developing java applications that for any
accidental bug freeze without closing all its open popup menus.


Attachments:
	Grab.java  1.1 KB
	xmonad.hs  13.8 KB

--
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
From codesite-noreply at google.com  Mon Feb  8 10:59:08 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb  8 10:30:22 2010
Subject: [xmonad] Re: Issue 371 in xmonad: Program using popup menus can
	freeze the desktop
In-Reply-To: <0-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
References: <0-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
Message-ID: <1-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>


Comment #1 on issue 371 by daniel.wagner: Program using popup menus can  
freeze the desktop
http://code.google.com/p/xmonad/issues/detail?id=371

Have you tried this under other WMs (with the same toolkit, environment  
variables,
etc.)? This sounds an awful lot like your app is doing an active grab and  
not
releasing it, which can't really be blamed on xmonad.

--
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
From codesite-noreply at google.com  Mon Feb  8 11:04:26 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb  8 10:35:38 2010
Subject: [xmonad] Re: Issue 371 in xmonad: Program using popup menus can
	freeze the desktop
In-Reply-To: <1-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
Message-ID: <2-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>


Comment #2 on issue 371 by hgabreu: Program using popup menus can freeze  
the desktop
http://code.google.com/p/xmonad/issues/detail?id=371

I can reproduce this problem.

--
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
From ott at mirix.org  Mon Feb  8 11:24:02 2010
From: ott at mirix.org (Matthias-Christian Ott)
Date: Mon Feb  8 10:55:17 2010
Subject: [xmonad] EWMH Panel in Haskell
Message-ID: <20100208162401.GA24334@qp>

Hi,

recently switched from dwm to xmonad. I'm quite happy with this
decision, but I'm used to have a good status bar on top of the screen.

I tried xmobar, which had problems with background colors, and dzen2
(with dmplex and multiple instances). None of these status bars supports
mouse interaction, so they aren't a choice for me.

Since xmonad also implements the emwh specification, I tried out several
ewmh compliant panels. ouri?o was most similar to dwm's status bar, but
doesn't seem very customisable and extensible to me.

Although I'm not an experienced Haskell programmer and I find Haskell
very ugly and a bit limiting, I think it would be a good idea to write
a ewmh panel in Haskell.

Is there an existing code? What are the drawbacks of ewmh (I read about
conceptual problems with xrandr)?

Regards,
Matthias-Christian
From codesite-noreply at google.com  Mon Feb  8 11:43:02 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb  8 11:14:16 2010
Subject: [xmonad] Re: Issue 371 in xmonad: Program using popup menus can
	freeze the desktop
In-Reply-To: <2-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
References: <2-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
Message-ID: <3-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>


Comment #3 on issue 371 by facundominguez: Program using popup menus can  
freeze the desktop
http://code.google.com/p/xmonad/issues/detail?id=371

> Have you tried this under other WMs (with the same toolkit, environment  
> variables,
etc.)? This sounds an awful lot like your app is doing an active grab and  
not
releasing it, which can't really be blamed on xmonad.

I have tested the application with metacity, and the same happens. But I do  
not
understand if that frees xmonad from all possible responsibility.

Is it mandatory to give focus to user applications when they request it,  
despite of
the fact that the user may not want that?

--
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
From ingeniware at gmail.com  Mon Feb  8 12:43:26 2010
From: ingeniware at gmail.com (Sergey Manucharian)
Date: Mon Feb  8 12:14:42 2010
Subject: [xmonad] EWMH Panel in Haskell
In-Reply-To: <20100208162401.GA24334@qp>
References: <20100208162401.GA24334@qp>
Message-ID: <20100208104326.02c10da1@laser-sm.laser>

Hi Matthias-Christian,

Excerpts from Matthias-Christian Ott's message of Mon, 08 Feb 2010
17:24 +0100:

> I tried xmobar, which had problems with background colors, and dzen2
> (with dmplex and multiple instances). None of these status bars
> supports mouse interaction, so they aren't a choice for me.

That's not exactly correct. Dzen2 DOES support mouse interaction, at
least the svn version. I don't use mouse interaction with xmonad's
status bar (though it can be implemented), but I have several gadgets
based on dzen2 and using mouse clicks.

Cheers,
Sergey
From ott at mirix.org  Mon Feb  8 12:59:03 2010
From: ott at mirix.org (Matthias-Christian Ott)
Date: Mon Feb  8 12:30:20 2010
Subject: [xmonad] EWMH Panel in Haskell
In-Reply-To: <20100208104326.02c10da1@laser-sm.laser>
References: <20100208162401.GA24334@qp>
	<20100208104326.02c10da1@laser-sm.laser>
Message-ID: <20100208175903.GB25025@qp>

On Mon, Feb 08, 2010 at 10:43:26AM -0700, Sergey Manucharian wrote:
> Hi Matthias-Christian,

Hi Sergey,

> Excerpts from Matthias-Christian Ott's message of Mon, 08 Feb 2010
> 17:24 +0100:
> 
> > I tried xmobar, which had problems with background colors, and dzen2
> > (with dmplex and multiple instances). None of these status bars
> > supports mouse interaction, so they aren't a choice for me.
> 
> That's not exactly correct. Dzen2 DOES support mouse interaction, at
> least the svn version. I don't use mouse interaction with xmonad's
> status bar (though it can be implemented), but I have several gadgets
> based on dzen2 and using mouse clicks.

Yes, you are right. You could write a hook to read input from dzen2
or use wmctrl for this [1]. But dzen2 also does single-pass rendering,
which isn't acceptable for me.

It's not that what I want to have is impossible with existing software
and some tricks, but I prefer a solution with a good rendering engine
(cairo and pango?) and support for higher order functions.

Of course a solution that is not "quick and dirty" takes more time to
develop and design, but I think it could be useful to the community.

The problem is just, that I'm not a particullary good haskel programmer
and probably won't write good code at the first try. So if any Haskell
wizard would be willing to write the initial code or there is good
existing code, that would be much better.

> Cheers,
> Sergey

Regards,
Matthias-Christian

[1] http://www.doitian.com/2009/09/clickable-dzen2-panel-for-xmonad/
From codesite-noreply at google.com  Mon Feb  8 15:13:22 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb  8 14:44:35 2010
Subject: [xmonad] Re: Issue 371 in xmonad: Program using popup menus can
	freeze the desktop
In-Reply-To: <3-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
References: <3-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
Message-ID: <4-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>


Comment #4 on issue 371 by daniel.wagner: Program using popup menus can  
freeze the desktop
http://code.google.com/p/xmonad/issues/detail?id=371

The way I understand it, it's not just mandatory -- there is literally no  
choice. The
request goes straight to the X server, with no WM intervention at all.

...but IANA X expert

--
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
From gwern0 at gmail.com  Mon Feb  8 16:51:20 2010
From: gwern0 at gmail.com (Gwern Branwen)
Date: Mon Feb  8 16:22:33 2010
Subject: [xmonad] XMC.Prompt: changing greenXPConfig to have no border
Message-ID: <cbf55b101002081351n275cfe94w66c8b3804d7b6266@mail.gmail.com>

I've been mulling for a while what border color would go best with the
terminal-style greenXPConfig prompt (green text on black background),
since the default white was clearly unsatisfactory. I tried yellow for
a while, but that didn't seem much better. Then I realized the problem
was there being a border at all, and that I ought to do just:

hunk ./XMonad/Prompt.hs 226
-greenXPConfig = defaultXPConfig { fgColor = "green", bgColor = "black" }
+greenXPConfig = defaultXPConfig { fgColor = "green", bgColor =
"black", promptBorderWidth = 0 }

Simple enough. It pleases me.

As far as the config archive knows, the only 2 users of greenXPConfig
are myself and Adam Vogt:

20.hs:import XMonad.Prompt (greenXPConfig)
20.hs:            ((m .|. shiftMask,xK_p), shellPrompt greenXPConfig)
20.hs:          , ((m,              xK_b), safePrompt "firefox" greenXPConfig)
20.hs:          , ((m .|. shiftMask,xK_c), prompt (term ++ " -e") greenXPConfig)
20.hs:          , ((m .|. shiftMask,xK_e), prompt "emacsclient -c -a
emacs" greenXPConfig)
20.hs:          , ((m,              xK_g), promptSearch greenXPConfig google)
20.hs:          , ((m,              xK_t), promptSearch greenXPConfig wikipedia)
20.hs:          , ((m,              xK_u), promptSearch greenXPConfig isohunt)
20.hs:          , ((m,              xK_y), promptSearch greenXPConfig wayback)
7.hs:import XMonad.Prompt(XPConfig(font), XPrompt(showXPrompt),
greenXPConfig, mkXPrompt)
7.hs:myXPConfig = greenXPConfig { font =
"xft:Profont:pixelsize=15:autohint=true" }

If he nor anyone else objects, in a few days I'll just push this small change.

-- 
gwern
From vogt.adam at gmail.com  Mon Feb  8 17:08:57 2010
From: vogt.adam at gmail.com (Adam Vogt)
Date: Mon Feb  8 16:40:35 2010
Subject: [xmonad] Re: XMC.Prompt: changing greenXPConfig to have no border
In-Reply-To: <cbf55b101002081351n275cfe94w66c8b3804d7b6266@mail.gmail.com>
References: <cbf55b101002081351n275cfe94w66c8b3804d7b6266@mail.gmail.com>
Message-ID: <20100208220857.GA10538@smuckers.uwaterloo.ca>

* On Monday, February 08 2010, Gwern Branwen wrote:

...
>As far as the config archive knows, the only 2 users of greenXPConfig
>are myself and Adam Vogt:
...
>
>If he nor anyone else objects, in a few days I'll just push this small change.
>
>-- 
>gwern


Go for it.

--
Adam
From codesite-noreply at google.com  Mon Feb  8 19:35:25 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb  8 19:06:37 2010
Subject: [xmonad] Re: Issue 325 in xmonad: Layout.Spacing breaks
	Layout.WindowNavigation
In-Reply-To: <7-3425899027203913298-15849859458202010030-codesite-noreply=google.com@googlecode.com>
References: <7-3425899027203913298-15849859458202010030-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-15849859458202010030-codesite-noreply=google.com@googlecode.com>
Message-ID: <8-3425899027203913298-15849859458202010030-codesite-noreply=google.com@googlecode.com>


Comment #8 on issue 325 by vogt.adam: Layout.Spacing breaks  
Layout.WindowNavigation
http://code.google.com/p/xmonad/issues/detail?id=325

Well try this instead for your second layout:

> secondLayout = spacing 10 $ Mirror $ windowNavigation $ Tall 1 (3/100)  
> (3/5)

Note that `Mirror' and `spacing n' are very similar in that they  
significantly adjust
the rectangles given to windows, so you need to apply those ones after  
windowNavigation.

But while the problem with spacing could probably be worked around in  
changes to
windowNavigation, maybe a better way is to apply layout modifiers in such a  
way that
avoids those conflicts:

> import Data.Ord
> import Data.List
> import XMonad
> import XMonad.Layout.Spacing as S
> import XMonad.Layout.WindowNavigation

> type Precedence = Int
> type LM a = (Layout a -> Layout a, Precedence)

> applyModifiers :: (LayoutClass l a, Read (l a)) => [LM a] -> (l a ->  
> Layout a)
> applyModifiers lms l = foldr ($) (Layout l) $ map fst $ sortBy (comparing  
> snd) lms

> xmonad' :: XConfig Layout -> IO ()
> xmonad' x@XConfig{layoutHook = Layout l} = xmonad x{layoutHook = l}

> mirror = (\(Layout a) -> Layout (Mirror a),1)
> spacing' n = (\(Layout a) -> Layout (spacing n a),1)
> nav = (\(Layout a) -> Layout (windowNavigation a),0)

Example:

> main = xmonad' { layoutHook = applyModifiers [nav,spacing' 5,mirror] Full  
> }

But perhaps the sort could be done at the type-level, and possibly using  
hlists...


--
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
From codesite-noreply at google.com  Mon Feb  8 23:29:55 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb  8 23:01:05 2010
Subject: [xmonad] Re: Issue 371 in xmonad: Program using popup menus can
	freeze the desktop
In-Reply-To: <4-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
References: <4-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>
Message-ID: <5-3425899027203913298-14647087745126866190-codesite-noreply=google.com@googlecode.com>

Updates:
	Status: Invalid

Comment #5 on issue 371 by SpencerJanssen: Program using popup menus can  
freeze the desktop
http://code.google.com/p/xmonad/issues/detail?id=371

As others have indicated, this is a fundamental issue in the X11 protocol.   
There is
nothing a WM can or should do to work around it.

--
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
From cjns1989 at gmail.com  Tue Feb  9 00:40:01 2010
From: cjns1989 at gmail.com (Chris Jones)
Date: Tue Feb  9 00:11:13 2010
Subject: [xmonad] Customizing xmonad on debian lenny
Message-ID: <20100209054001.GB1511@turki.gavron.org>

I have been trying to customize a couple of things in xmonad 0.7
following the online tutorials to the letter and after a week of
frustration, I'm beginning to think that these tutorials only cover the
current release, which would explain why whatever I tried always seemed
to result in bizarre undocumented errors.

The product works fine out of the box as long as you just use the
defaults, but there are just a couple of things I need to change, such
as some of the key bindings (which happen to clash with bindings I have
defined in applications I run frequently), as well as the default
terminal and the corresponding $TERM environment variable, for instance.

Besides, I would like to set up a system status bar at the bottom of
the screen, and apparently this is not available by default. 

This is a debian stable aka "lenny" system, and the version of xmonad is
as expected pretty ancient.

I wouldn't mind installing the current stable version of xmonad, but
since the version from the debian stable repository pulled something
like 400 Meg of Haskell dependencies, I have a feeling this is probably
not going to be straightforward.

Or should I wait till the current debian testing, aka squeeze becomes
stable, and hopefully things will work as advertised?

Please advise.

CJ
From ivan.miljenovic at gmail.com  Tue Feb  9 01:59:10 2010
From: ivan.miljenovic at gmail.com (Ivan Miljenovic)
Date: Tue Feb  9 01:30:22 2010
Subject: [xmonad] XMC.Prompt: changing greenXPConfig to have no border
In-Reply-To: <cbf55b101002081351n275cfe94w66c8b3804d7b6266@mail.gmail.com>
References: <cbf55b101002081351n275cfe94w66c8b3804d7b6266@mail.gmail.com>
Message-ID: <ccd8be491002082259y40ce18b3o39ad63c8edc3e753@mail.gmail.com>

On 9 February 2010 08:51, Gwern Branwen <gwern0@gmail.com> wrote:
> As far as the config archive knows, the only 2 users of greenXPConfig
> are myself and Adam Vogt:

Yes, but there is quite likely to be many other people that don't have
configs submitted to the archive that use this config (I don't, but
there might be some that do).  As such, this is a change that they
won't be expecting, etcetera, etcetera.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
IvanMiljenovic.wordpress.com
Joan Crawford  - "I, Joan Crawford, I believe in the dollar.
Everything I earn, I spend." -
http://www.brainyquote.com/quotes/authors/j/joan_crawford.html
From ivan.miljenovic at gmail.com  Tue Feb  9 02:00:43 2010
From: ivan.miljenovic at gmail.com (Ivan Miljenovic)
Date: Tue Feb  9 01:31:55 2010
Subject: [xmonad] Customizing xmonad on debian lenny
In-Reply-To: <20100209054001.GB1511@turki.gavron.org>
References: <20100209054001.GB1511@turki.gavron.org>
Message-ID: <ccd8be491002082300l1e972602g1c46933f8aa6df54@mail.gmail.com>

On 9 February 2010 16:40, Chris Jones <cjns1989@gmail.com> wrote:
> I wouldn't mind installing the current stable version of xmonad, but
> since the version from the debian stable repository pulled something
> like 400 Meg of Haskell dependencies, I have a feeling this is probably
> not going to be straightforward.

I expect that that 400 MB of Haskell dependencies is mainly composed
of GHC, which you will need if you want to customise XMonad anyway.
By itself, XMonad is more of a tiling WM library with a very boring
sample WM included as a demo.

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
IvanMiljenovic.wordpress.com
Samuel Goldwyn  - "I don't think anyone should write their
autobiography until after they're dead." -
http://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html
From wagnerdm at seas.upenn.edu  Tue Feb  9 05:43:58 2010
From: wagnerdm at seas.upenn.edu (wagnerdm@seas.upenn.edu)
Date: Tue Feb  9 05:15:14 2010
Subject: [xmonad] Customizing xmonad on debian lenny
In-Reply-To: <20100209054001.GB1511@turki.gavron.org>
References: <20100209054001.GB1511@turki.gavron.org>
Message-ID: <20100209054358.10555eymy78y5bpw@webmail.seas.upenn.edu>

Come join us in #xmonad on Freenode. We will make fun of you for a few  
minutes for using such an ancient xmonad, then do our best to help you  
out.

As for 400MB of Haskell dependencies, I'm rather surprised that you're  
able to customize 0.7 without having those same dependencies. If  
you've got GHC installed, you might want to consider grabbing X11,  
xmonad, and xmonad-contrib from the darcs repositories (even the  
bleeding edge is quite stable -- I've never had it crash) and trying  
to build those.

Good luck!
~d

Quoting Chris Jones <cjns1989@gmail.com>:

> I have been trying to customize a couple of things in xmonad 0.7
> following the online tutorials to the letter and after a week of
> frustration, I'm beginning to think that these tutorials only cover the
> current release, which would explain why whatever I tried always seemed
> to result in bizarre undocumented errors.
>
> The product works fine out of the box as long as you just use the
> defaults, but there are just a couple of things I need to change, such
> as some of the key bindings (which happen to clash with bindings I have
> defined in applications I run frequently), as well as the default
> terminal and the corresponding $TERM environment variable, for instance.
>
> Besides, I would like to set up a system status bar at the bottom of
> the screen, and apparently this is not available by default.
>
> This is a debian stable aka "lenny" system, and the version of xmonad is
> as expected pretty ancient.
>
> I wouldn't mind installing the current stable version of xmonad, but
> since the version from the debian stable repository pulled something
> like 400 Meg of Haskell dependencies, I have a feeling this is probably
> not going to be straightforward.
>
> Or should I wait till the current debian testing, aka squeeze becomes
> stable, and hopefully things will work as advertised?
>
> Please advise.
>
> CJ
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
>


From john at yates-sheets.org  Tue Feb  9 11:24:00 2010
From: john at yates-sheets.org (John Yates)
Date: Tue Feb  9 10:55:10 2010
Subject: [xmonad] EWMH Panel in Haskell
In-Reply-To: <20100208175903.GB25025@qp>
References: <20100208162401.GA24334@qp>
	<20100208104326.02c10da1@laser-sm.laser> <20100208175903.GB25025@qp>
Message-ID: <3f14737c1002090824t65aadefax57e3e16297452f4f@mail.gmail.com>

You do not say of what the rest of your environment consists.  If you
are using Gnome you can get a very nice clickable single panel, much
like dwm, dzen2 or xmobar.  I run Ubuntu Karmic and have done just
that.  I posted earlier version (xmonad 0.8) to
http://haskell.org/haskellwiki/Xmonad/Config_archive (look for John
Yates).

/john

PS: I will try to update my entry on the Config_archive page in the near future.
From ott at mirix.org  Tue Feb  9 11:31:19 2010
From: ott at mirix.org (Matthias-Christian Ott)
Date: Tue Feb  9 11:02:31 2010
Subject: [xmonad] EWMH Panel in Haskell
In-Reply-To: <3f14737c1002090824t65aadefax57e3e16297452f4f@mail.gmail.com>
References: <20100208162401.GA24334@qp>
	<20100208104326.02c10da1@laser-sm.laser>
	<20100208175903.GB25025@qp>
	<3f14737c1002090824t65aadefax57e3e16297452f4f@mail.gmail.com>
Message-ID: <20100209163119.GA28227@qp>

On Tue, Feb 09, 2010 at 11:24:00AM -0500, John Yates wrote:
> You do not say of what the rest of your environment consists.  If you
> are using Gnome you can get a very nice clickable single panel, much
> like dwm, dzen2 or xmobar.  I run Ubuntu Karmic and have done just
> that.  I posted earlier version (xmonad 0.8) to
> http://haskell.org/haskellwiki/Xmonad/Config_archive (look for John
> Yates).

The rest of my environment consits of several urxvts/uxterms and
firefox.

Regards,
Matthias-Christian
From john at yates-sheets.org  Tue Feb  9 20:29:38 2010
From: john at yates-sheets.org (John Yates)
Date: Tue Feb  9 20:00:51 2010
Subject: [xmonad] EWMH Panel in Haskell
In-Reply-To: <20100209163119.GA28227@qp>
References: <20100208162401.GA24334@qp>
	<20100208104326.02c10da1@laser-sm.laser> <20100208175903.GB25025@qp>
	<3f14737c1002090824t65aadefax57e3e16297452f4f@mail.gmail.com>
	<20100209163119.GA28227@qp>
Message-ID: <3f14737c1002091729q6d5a8e0eq56da555dfc05c71f@mail.gmail.com>

On Tue, Feb 9, 2010 at 11:31 AM, Matthias-Christian Ott <ott@mirix.org> wrote:
> The rest of my environment consits of several urxvts/uxterms and
> firefox.

(Please forgive me if the following attempt to extrapolate from your
brief response is off target.)

It sounds like you are a "dyed in the wool" command-line user.
Further, it sounds like you are saying that not only do you _not_ run
a mainstream window manager but also that you choose _not_ to run any
of the components associated with a mainstream GUI desktop
environment.

I too am a command-line devotee though I run most of my shells within
emacs.  That said I am happy to run bits of the gnome GUI in a single
bar across the top of my screen (gnome panel and a handful of
applets).  Within that panel I use dzen2 to displays what would
otherwise appear on a title bar if I chose to have my windows so
decorated.  Again in that panel I have Mod4-p bound run dmenu for
launching programs.  And much as I love tiling window managers in
general and xmonad in particular I still appreciate the Gnome
Workspace Switcher's visual presentation of my 9 workspaces.  (A
picture can truly be worth many key strokes and much searching.)

Bottom-line: even after replacing my window manager I find that a
desktop environment still offers many reusable components that I would
never think of reinventing.  I encourage you to read the wiki pages on
xmonad integration with Gnome and/or KDE.  (I use Gnome because it is
Ubuntu's default environment and therefore best supported under that
distribution.)

/john
From e.imhotep at gmail.com  Tue Feb  9 20:53:11 2010
From: e.imhotep at gmail.com (Francesco Mazzoli)
Date: Tue Feb  9 20:24:19 2010
Subject: [xmonad] dzen bar not visible with the Minimize module
Message-ID: <13e62bc1002091753r35e05d42g82087d852a5485ac@mail.gmail.com>

Hi,
I have got a problem with the Minimize module and I can't find a solution.

When I try to use it using the example code provided in the module
page, one of my two dzen bars disappear.
This is my desktop without the Minimize module:
http://i50.tinypic.com/2d6w9d3.png

and that's what happen when I activate it:
http://i46.tinypic.com/34e9vth.png

Here is my configuration file:
http://hpaste.org/fastcgi/hpaste.fcgi/view?id=17112#a17112

The only line of code that I change is this:
layoutHook = smartBorders $ avoidStruts (Full ||| tiled  ||| Mirror tiled)
to that:
layoutHook = smartBorders $ avoidStruts $ minimize (Full ||| tiled
||| Mirror tiled)

As you can see I have already hasked in the archlinux forum and in the
xmonad irc channel, but no one seems to have a solution.

I absolutely adore xmonad and this module would make it even better!
From wagnerdm at seas.upenn.edu  Tue Feb  9 21:59:34 2010
From: wagnerdm at seas.upenn.edu (wagnerdm@seas.upenn.edu)
Date: Tue Feb  9 21:30:47 2010
Subject: [xmonad] dzen bar not visible with the Minimize module
In-Reply-To: <13e62bc1002091753r35e05d42g82087d852a5485ac@mail.gmail.com>
References: <13e62bc1002091753r35e05d42g82087d852a5485ac@mail.gmail.com>
Message-ID: <20100209215934.16471a40isryzb5w@webmail.seas.upenn.edu>

Your pretty-printer is almost certainly throwing an exception in the  
case statement.  Be sure to add a case for your minimized layout!
~d

Quoting Francesco Mazzoli <e.imhotep@gmail.com>:

> Hi,
> I have got a problem with the Minimize module and I can't find a solution.
>
> When I try to use it using the example code provided in the module
> page, one of my two dzen bars disappear.
> This is my desktop without the Minimize module:
> http://i50.tinypic.com/2d6w9d3.png
>
> and that's what happen when I activate it:
> http://i46.tinypic.com/34e9vth.png
>
> Here is my configuration file:
> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=17112#a17112
>
> The only line of code that I change is this:
> layoutHook = smartBorders $ avoidStruts (Full ||| tiled  ||| Mirror tiled)
> to that:
> layoutHook = smartBorders $ avoidStruts $ minimize (Full ||| tiled
> ||| Mirror tiled)
>
> As you can see I have already hasked in the archlinux forum and in the
> xmonad irc channel, but no one seems to have a solution.
>
> I absolutely adore xmonad and this module would make it even better!
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
>


From e.imhotep at gmail.com  Wed Feb 10 06:01:29 2010
From: e.imhotep at gmail.com (Francesco Mazzoli)
Date: Wed Feb 10 05:32:38 2010
Subject: [xmonad] dzen bar not visible with the Minimize module
In-Reply-To: <20100209215934.16471a40isryzb5w@webmail.seas.upenn.edu>
References: <13e62bc1002091753r35e05d42g82087d852a5485ac@mail.gmail.com>
	<20100209215934.16471a40isryzb5w@webmail.seas.upenn.edu>
Message-ID: <13e62bc1002100301n7ae71228v924016dd9a736c4a@mail.gmail.com>

Thanks for the answer!

I don't think I really understand how this work. Does minimize its own
layout, or is it a modification of the others?

I tried both way adding a "Minimize" and "minimize" case, and
modifying the existing layouts adding minimize to them, but it didn't
work.

What am I doing wrong?

Francesco
On 10 February 2010 02:59,  <wagnerdm@seas.upenn.edu> wrote:
> Your pretty-printer is almost certainly throwing an exception in the case
> statement. ?Be sure to add a case for your minimized layout!
> ~d
>
> Quoting Francesco Mazzoli <e.imhotep@gmail.com>:
>
>> Hi,
>> I have got a problem with the Minimize module and I can't find a solution.
>>
>> When I try to use it using the example code provided in the module
>> page, one of my two dzen bars disappear.
>> This is my desktop without the Minimize module:
>> http://i50.tinypic.com/2d6w9d3.png
>>
>> and that's what happen when I activate it:
>> http://i46.tinypic.com/34e9vth.png
>>
>> Here is my configuration file:
>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=17112#a17112
>>
>> The only line of code that I change is this:
>> layoutHook = smartBorders $ avoidStruts (Full ||| tiled ?||| Mirror tiled)
>> to that:
>> layoutHook = smartBorders $ avoidStruts $ minimize (Full ||| tiled
>> ||| Mirror tiled)
>>
>> As you can see I have already hasked in the archlinux forum and in the
>> xmonad irc channel, but no one seems to have a solution.
>>
>> I absolutely adore xmonad and this module would make it even better!
>> _______________________________________________
>> xmonad mailing list
>> xmonad@haskell.org
>> http://www.haskell.org/mailman/listinfo/xmonad
>>
>>
>
>
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
From cjns1989 at gmail.com  Wed Feb 10 11:33:16 2010
From: cjns1989 at gmail.com (Chris Jones)
Date: Wed Feb 10 11:04:24 2010
Subject: [xmonad] Customizing xmonad on debian lenny
In-Reply-To: <20100209054358.10555eymy78y5bpw@webmail.seas.upenn.edu>
	<ccd8be491002082300l1e972602g1c46933f8aa6df54@mail.gmail.com>
References: <20100209054001.GB1511@turki.gavron.org>
	<20100209054358.10555eymy78y5bpw@webmail.seas.upenn.edu>
	<20100209054001.GB1511@turki.gavron.org>
	<ccd8be491002082300l1e972602g1c46933f8aa6df54@mail.gmail.com>
Message-ID: <20100210163316.GB3063@turki.gavron.org>

On Tue, Feb 09, 2010 at 02:00:43AM EST, Ivan Miljenovic wrote:
> On 9 February 2010 16:40, Chris Jones <cjns1989@gmail.com> wrote:

> > I wouldn't mind installing the current stable version of xmonad, but
> > since the version from the debian stable repository pulled something
> > like 400 Meg of Haskell dependencies, I have a feeling this is
> > probably not going to be straightforward.
> 
> I expect that that 400 MB of Haskell dependencies is mainly composed
> of GHC, which you will need if you want to customise XMonad anyway.
> By itself, XMonad is more of a tiling WM library with a very boring
> sample WM included as a demo.

hehe.. uninteresting was the word that came to my mind.

In the world of software, I can think of lots of uninteresting stuff but
problably nothing more boring than window managers. That's why I'm
looking for one that just gets out of the way and lets me get on with my
life. What does interest me, though is the tiling interface per se, how
it can make things more effective than the traditional destktop with its
menus, icons, and all that point & click stuff. What I have done so far
is toned down one of the better thought-out ones -- i.e.  Window Maker,
eventually removing practically everything, save for a few keyboard
bindings that fire up frequently used applications and let me switch
workspaces. Not a good approach to the problem: makes more sense to
start with the bare metal and add in the stuff you need.

As to the dependencies, you are likely quite correct. It's just the way
the packaging system works, it delivers everything Haskell, including
mountains of doc that can be browsed online, rather than try to be more
selective and end up missing something useful.

On Tue, Feb 09, 2010 at 05:43:58AM EST, wagnerdm@seas.upenn.edu wrote:

> Come join us in #xmonad on Freenode. We will make fun of you for a few  
> minutes for using such an ancient xmonad, then do our best to help you  
> out.

That won't be necessary. I eventually got a chance to boot into debian
testing and with 0.8 everything appears to behave as advertised.

> As for 400MB of Haskell dependencies, I'm rather surprised that you're  
> able to customize 0.7 without having those same dependencies. 

When you apt-get xmonad, regardless of the version, debian ends up
installing what looks like close to a hundred packages. Meaning that I
was concerned that trying to install manually might have landed me in
dependency hell. I don't think this would have been the case, though:
despite the large number of packages, and size thereof.. the actual
dependency is quite trivial: you just need a working Haskell environment
in order to configure xmonad. Doesn't look like a case of fifteen layers
of libraries, with half of them dummy packages to resolve compatiblity
issues.

> If you've got GHC installed, you might want to consider grabbing X11,
> xmonad, and xmonad-contrib from the darcs repositories (even the
> bleeding edge is quite stable -- I've never had it crash) and trying
> to build those.

As stated above, the debian squeeze version appears to be fairly easy to
set up. Where I did waste a lot of time was with xmobar. Peculiar syntax
and rather approximate documenation. I probably would have been better
off taking the dzen route.

One quick question, I see a bunch of screenshots on the xmonad wiki and
some look pretty much like what I'm trying to end up with, but the
configuration files or scripts appear not to have been made available.

Sorry for trying to steal from other folks, but I don't have much time
to devote to this right now, and I thought that it might be an effective
approach to clone someone's configuration and use that as a starting
point.

Thank you for your comments.

CJ
From wagnerdm at seas.upenn.edu  Wed Feb 10 12:45:32 2010
From: wagnerdm at seas.upenn.edu (wagnerdm@seas.upenn.edu)
Date: Wed Feb 10 12:16:45 2010
Subject: [xmonad] Customizing xmonad on debian lenny
In-Reply-To: <20100210163316.GB3063@turki.gavron.org>
References: <20100209054001.GB1511@turki.gavron.org>
	<20100209054358.10555eymy78y5bpw@webmail.seas.upenn.edu>
	<20100209054001.GB1511@turki.gavron.org>
	<ccd8be491002082300l1e972602g1c46933f8aa6df54@mail.gmail.com>
	<20100210163316.GB3063@turki.gavron.org>
Message-ID: <20100210124532.16267jtfj91rgv40@webmail.seas.upenn.edu>

Quoting Chris Jones <cjns1989@gmail.com>:

> Where I did waste a lot of time was with xmobar. Peculiar syntax
> and rather approximate documenation.

I have similar complaints.

> One quick question, I see a bunch of screenshots on the xmonad wiki and
> some look pretty much like what I'm trying to end up with, but the
> configuration files or scripts appear not to have been made available.

It might help if you say which ones you liked. Their authors would  
probably be pleased as punch. ;-)

~d
From wagnerdm at seas.upenn.edu  Wed Feb 10 12:48:42 2010
From: wagnerdm at seas.upenn.edu (wagnerdm@seas.upenn.edu)
Date: Wed Feb 10 12:19:56 2010
Subject: [xmonad] dzen bar not visible with the Minimize module
In-Reply-To: <13e62bc1002100301n7ae71228v924016dd9a736c4a@mail.gmail.com>
References: <13e62bc1002091753r35e05d42g82087d852a5485ac@mail.gmail.com>
	<20100209215934.16471a40isryzb5w@webmail.seas.upenn.edu>
	<13e62bc1002100301n7ae71228v924016dd9a736c4a@mail.gmail.com>
Message-ID: <20100210124842.70016glx4xzs8twc@webmail.seas.upenn.edu>

Each layout (and layout modifier) can specify its own string. Maybe  
the easiest way to find out what the right string to add is to add a  
catch-all case; this will also help you in the future when you forget  
about this problem. =)

It would look something like

(\x -> case {- can't remember what went here -} of
         "Tabbed" -> ...
         ...      -> ...
         s        -> "Unexpected layout <" ++ s ++ ">"
)

Good luck!
~d

Quoting Francesco Mazzoli <e.imhotep@gmail.com>:

> Thanks for the answer!
>
> I don't think I really understand how this work. Does minimize its own
> layout, or is it a modification of the others?
>
> I tried both way adding a "Minimize" and "minimize" case, and
> modifying the existing layouts adding minimize to them, but it didn't
> work.
>
> What am I doing wrong?
>
> Francesco
> On 10 February 2010 02:59,  <wagnerdm@seas.upenn.edu> wrote:
>> Your pretty-printer is almost certainly throwing an exception in the case
>> statement. ?Be sure to add a case for your minimized layout!
>> ~d
>>
>> Quoting Francesco Mazzoli <e.imhotep@gmail.com>:
>>
>>> Hi,
>>> I have got a problem with the Minimize module and I can't find a solution.
>>>
>>> When I try to use it using the example code provided in the module
>>> page, one of my two dzen bars disappear.
>>> This is my desktop without the Minimize module:
>>> http://i50.tinypic.com/2d6w9d3.png
>>>
>>> and that's what happen when I activate it:
>>> http://i46.tinypic.com/34e9vth.png
>>>
>>> Here is my configuration file:
>>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=17112#a17112
>>>
>>> The only line of code that I change is this:
>>> layoutHook = smartBorders $ avoidStruts (Full ||| tiled ?||| Mirror tiled)
>>> to that:
>>> layoutHook = smartBorders $ avoidStruts $ minimize (Full ||| tiled
>>> ||| Mirror tiled)
>>>
>>> As you can see I have already hasked in the archlinux forum and in the
>>> xmonad irc channel, but no one seems to have a solution.
>>>
>>> I absolutely adore xmonad and this module would make it even better!
>>> _______________________________________________
>>> xmonad mailing list
>>> xmonad@haskell.org
>>> http://www.haskell.org/mailman/listinfo/xmonad
>>>
>>>
>>
>>
>> _______________________________________________
>> xmonad mailing list
>> xmonad@haskell.org
>> http://www.haskell.org/mailman/listinfo/xmonad
>>
>
>

From Julien.Steinhauser at orange.fr  Wed Feb 10 12:53:08 2010
From: Julien.Steinhauser at orange.fr (julien steinhauser)
Date: Wed Feb 10 12:23:37 2010
Subject: [xmonad] Customizing xmonad on debian lenny
In-Reply-To: <20100210163316.GB3063@turki.gavron.org>
References: <20100209054001.GB1511@turki.gavron.org>
	<20100209054358.10555eymy78y5bpw@webmail.seas.upenn.edu>
	<20100209054001.GB1511@turki.gavron.org>
	<ccd8be491002082300l1e972602g1c46933f8aa6df54@mail.gmail.com>
	<20100210163316.GB3063@turki.gavron.org>
Message-ID: <20100210175308.GA27865@eol.dynalias.org>

Hello,

On Wed, Feb 10, 2010 at 11:33:16AM -0500, Chris Jones wrote:
> 
> 
> When you apt-get xmonad, regardless of the version, debian ends up
> installing what looks like close to a hundred packages. Meaning that I
> was concerned that trying to install manually might have landed me in
> dependency hell. I don't think this would have been the case, though:
> despite the large number of packages, and size thereof.. the actual
> dependency is quite trivial: you just need a working Haskell environment
> in order to configure xmonad. Doesn't look like a case of fifteen layers
> of libraries, with half of them dummy packages to resolve compatiblity
> issues.
> 
Your debian seems not like mine, if I remember well I just needed
those packages to get a XMonad with full extensions :

$ apt-get source xmonad xmonad-contrib

# aptitude install ghc6 libghc6-mtl-dev libghc6-utf-8-string-dev
libghc6-x11-dev libghc6-x11-xft-dev


> One quick question, I see a bunch of screenshots on the xmonad wiki and
> some look pretty much like what I'm trying to end up with, but the
> configuration files or scripts appear not to have been made available.

This is surely what you look for :

http://www.haskell.org/haskellwiki/Xmonad/Config_archive


From codesite-noreply at google.com  Wed Feb 10 13:10:46 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Wed Feb 10 12:41:53 2010
Subject: [xmonad] Issue 372 in xmonad: Changes made to defaultConfig do not
	take on recompile and restart.
Message-ID: <0-3425899027203913298-11588448711754788183-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 372 by aditya.siram: Changes made to defaultConfig do not take on  
recompile and restart.
http://code.google.com/p/xmonad/issues/detail?id=372

What steps will reproduce the problem?
1. change any defaultConfig setting, in my case change terminal =
"gnome-termimal" to terminal = "xterm", recompile (xmonad --recompile) and
restart(xmonad --restart)

What is the expected output? What do you see instead?
mod-shift-return should now pull up an xterm. Instead it still opens a
gnome-terminal.

What version of the product are you using? On what operating system?
0.9.1, Ubuntu Karmic

Are you using an xmonad.hs?  Please attach it and the output of "xmonad
--recompile".
config file is attached. Recompile step has no output.

Attachments:
	xmonad.hs  2.0 KB

--
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
From e.imhotep at gmail.com  Wed Feb 10 13:34:17 2010
From: e.imhotep at gmail.com (Francesco Mazzoli)
Date: Wed Feb 10 13:05:25 2010
Subject: [xmonad] dzen bar not visible with the Minimize module
In-Reply-To: <20100210124842.70016glx4xzs8twc@webmail.seas.upenn.edu>
References: <13e62bc1002091753r35e05d42g82087d852a5485ac@mail.gmail.com>
	<20100209215934.16471a40isryzb5w@webmail.seas.upenn.edu>
	<13e62bc1002100301n7ae71228v924016dd9a736c4a@mail.gmail.com>
	<20100210124842.70016glx4xzs8twc@webmail.seas.upenn.edu>
Message-ID: <13e62bc1002101034k3135337eub2fc84aad7ada99b@mail.gmail.com>

Ohh right, I always think about xmonad.hs as "static" configuration
files and I don't even think about these things.

Anyway, thanks a lot I've got it now.

On 10 February 2010 17:48,  <wagnerdm@seas.upenn.edu> wrote:
> Each layout (and layout modifier) can specify its own string. Maybe the
> easiest way to find out what the right string to add is to add a catch-all
> case; this will also help you in the future when you forget about this
> problem. =)
>
> It would look something like
>
> (\x -> case {- can't remember what went here -} of
> ? ? ? ?"Tabbed" -> ...
> ? ? ? ?... ? ? ?-> ...
> ? ? ? ?s ? ? ? ?-> "Unexpected layout <" ++ s ++ ">"
> )
>
> Good luck!
> ~d
>
> Quoting Francesco Mazzoli <e.imhotep@gmail.com>:
>
>> Thanks for the answer!
>>
>> I don't think I really understand how this work. Does minimize its own
>> layout, or is it a modification of the others?
>>
>> I tried both way adding a "Minimize" and "minimize" case, and
>> modifying the existing layouts adding minimize to them, but it didn't
>> work.
>>
>> What am I doing wrong?
>>
>> Francesco
>> On 10 February 2010 02:59, ?<wagnerdm@seas.upenn.edu> wrote:
>>>
>>> Your pretty-printer is almost certainly throwing an exception in the case
>>> statement. ?Be sure to add a case for your minimized layout!
>>> ~d
>>>
>>> Quoting Francesco Mazzoli <e.imhotep@gmail.com>:
>>>
>>>> Hi,
>>>> I have got a problem with the Minimize module and I can't find a
>>>> solution.
>>>>
>>>> When I try to use it using the example code provided in the module
>>>> page, one of my two dzen bars disappear.
>>>> This is my desktop without the Minimize module:
>>>> http://i50.tinypic.com/2d6w9d3.png
>>>>
>>>> and that's what happen when I activate it:
>>>> http://i46.tinypic.com/34e9vth.png
>>>>
>>>> Here is my configuration file:
>>>> http://hpaste.org/fastcgi/hpaste.fcgi/view?id=17112#a17112
>>>>
>>>> The only line of code that I change is this:
>>>> layoutHook = smartBorders $ avoidStruts (Full ||| tiled ?||| Mirror
>>>> tiled)
>>>> to that:
>>>> layoutHook = smartBorders $ avoidStruts $ minimize (Full ||| tiled
>>>> ||| Mirror tiled)
>>>>
>>>> As you can see I have already hasked in the archlinux forum and in the
>>>> xmonad irc channel, but no one seems to have a solution.
>>>>
>>>> I absolutely adore xmonad and this module would make it even better!
>>>> _______________________________________________
>>>> xmonad mailing list
>>>> xmonad@haskell.org
>>>> http://www.haskell.org/mailman/listinfo/xmonad
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> xmonad mailing list
>>> xmonad@haskell.org
>>> http://www.haskell.org/mailman/listinfo/xmonad
>>>
>>
>>
>
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
From cjns1989 at gmail.com  Wed Feb 10 13:37:25 2010
From: cjns1989 at gmail.com (Chris Jones)
Date: Wed Feb 10 13:08:42 2010
Subject: [xmonad] Customizing xmonad on debian lenny
In-Reply-To: <20100210124532.16267jtfj91rgv40@webmail.seas.upenn.edu>
References: <20100209054001.GB1511@turki.gavron.org>
	<20100209054358.10555eymy78y5bpw@webmail.seas.upenn.edu>
	<20100209054001.GB1511@turki.gavron.org>
	<ccd8be491002082300l1e972602g1c46933f8aa6df54@mail.gmail.com>
	<20100210163316.GB3063@turki.gavron.org>
	<20100210124532.16267jtfj91rgv40@webmail.seas.upenn.edu>
Message-ID: <20100210183725.GE3063@turki.gavron.org>

On Wed, Feb 10, 2010 at 12:45:32PM EST, wagnerdm@seas.upenn.edu wrote:
> Quoting Chris Jones <cjns1989@gmail.com>:

[..]

> It might help if you say which ones you liked. Their authors would  
> probably be pleased as punch. ;-)

Hm.. Sorry about that, I was generically thinking that the config files
& scripts were there and that I was just too dumb to figure out where
they were.. :-)

Actually, the ones that use dzen are all pretty good. The two xinerama
mostly pale green screenshots are aesthetically very pleasing, not what
I would use such colors myself.. would depress me in not time, but where
the good stuff really is the dzen gotmor site, particularly the last
screenshot, with just a status bar and a few widgets:

http://dzen.geekmode.org/dwiki/lib/exe/fetch.php?cache=cache&media=dzen:dzen_dbar_styles.png

What puzzles me is that it looks like contrary to xmobar, dzen does need
to be infoked from xmonad.hs, but then how does xmonad know that it's
there and needs to leave a gap for it at the top/bottom of the screen.

Thanks,

CJ
From cjns1989 at gmail.com  Wed Feb 10 14:09:57 2010
From: cjns1989 at gmail.com (Chris Jones)
Date: Wed Feb 10 13:41:05 2010
Subject: [xmonad] Customizing xmonad on debian lenny
In-Reply-To: <20100210175308.GA27865@eol.dynalias.org>
References: <20100209054001.GB1511@turki.gavron.org>
	<20100209054358.10555eymy78y5bpw@webmail.seas.upenn.edu>
	<20100209054001.GB1511@turki.gavron.org>
	<ccd8be491002082300l1e972602g1c46933f8aa6df54@mail.gmail.com>
	<20100210163316.GB3063@turki.gavron.org>
	<20100210175308.GA27865@eol.dynalias.org>
Message-ID: <20100210190957.GF3063@turki.gavron.org>

On Wed, Feb 10, 2010 at 12:53:08PM EST, julien steinhauser wrote:
> Hello,
> 
> On Wed, Feb 10, 2010 at 11:33:16AM -0500, Chris Jones wrote:

> > When you apt-get xmonad, regardless of the version, debian ends up
> > installing what looks like close to a hundred packages. Meaning that
> > I was concerned that trying to install manually might have landed me
> > in dependency hell. I don't think this would have been the case,
> > though: despite the large number of packages, and size thereof.. the
> > actual dependency is quite trivial: you just need a working Haskell
> > environment in order to configure xmonad. Doesn't look like a case
> > of fifteen layers of libraries, with half of them dummy packages to
> > resolve compatiblity issues.
> > 
> Your debian seems not like mine, if I remember well I just needed
> those packages to get a XMonad with full extensions :

They're all different :-)

I assume that the difference is that I have a very minimal system that
was installed one package at a time, not via the gnome-desktop, or
KDE-desktop, or whatever they call these things in the installer, and
that a lot of other stuff that was already installed on your system --
and that I had managed so far not to install on mine -- eventually got
pulled in.. oh, well..

> $ apt-get source xmonad xmonad-contrib
> 
> # aptitude install ghc6 libghc6-mtl-dev libghc6-utf-8-string-dev
> libghc6-x11-dev libghc6-x11-xft-dev

Makes sense to me. Unfortunately, I was doing something else at the time
the install was running and I didn't really bother making even a mental
note of what these extra packages were. I'm sure there's a way I could
find out, this is debian after all, probably some log or other in
/var/cache/apt .. but since all went well and since it's not working on
the lenny system anyway, I think I'll just do an apt-get remove --purge
followed by an autoremove and focus on the squeeze system for now.

> > One quick question, I see a bunch of screenshots on the xmonad wiki
> > and some look pretty much like what I'm trying to end up with, but
> > the configuration files or scripts appear not to have been made
> > available.

> This is surely what you look for :
> 
> http://www.haskell.org/haskellwiki/Xmonad/Config_archive

Precisely what I was looking for.. not sure how I missed it.

Thank you for your comments.

CJ


From wagnerdm at seas.upenn.edu  Wed Feb 10 14:16:17 2010
From: wagnerdm at seas.upenn.edu (wagnerdm@seas.upenn.edu)
Date: Wed Feb 10 13:47:29 2010
Subject: [xmonad] Customizing xmonad on debian lenny
In-Reply-To: <20100210183725.GE3063@turki.gavron.org>
References: <20100209054001.GB1511@turki.gavron.org>
	<20100209054358.10555eymy78y5bpw@webmail.seas.upenn.edu>
	<20100209054001.GB1511@turki.gavron.org>
	<ccd8be491002082300l1e972602g1c46933f8aa6df54@mail.gmail.com>
	<20100210163316.GB3063@turki.gavron.org>
	<20100210124532.16267jtfj91rgv40@webmail.seas.upenn.edu>
	<20100210183725.GE3063@turki.gavron.org>
Message-ID: <20100210141617.11021ikl01emfxno@webmail.seas.upenn.edu>

Quoting Chris Jones <cjns1989@gmail.com>:

> What puzzles me is that it looks like contrary to xmobar, dzen does need
> to be infoked from xmonad.hs, but then how does xmonad know that it's
> there and needs to leave a gap for it at the top/bottom of the screen.

Actually, it's probably easiest to invoke your bar from within xmonad,  
whether it's xmobar or dzen. xmonad knows how much gap to leave  
becaues xmobar and dzen set strut hints, and the  
manageDocks/avoidStruts manage hook and layout modifier, respectively,  
know what to do with those.

Cheers,
~d
From ott at mirix.org  Wed Feb 10 16:45:18 2010
From: ott at mirix.org (Matthias-Christian Ott)
Date: Wed Feb 10 16:16:36 2010
Subject: [xmonad] EWMH Panel in Haskell
In-Reply-To: <3f14737c1002091729q6d5a8e0eq56da555dfc05c71f@mail.gmail.com>
References: <20100208162401.GA24334@qp>
	<20100208104326.02c10da1@laser-sm.laser>
	<20100208175903.GB25025@qp>
	<3f14737c1002090824t65aadefax57e3e16297452f4f@mail.gmail.com>
	<20100209163119.GA28227@qp>
	<3f14737c1002091729q6d5a8e0eq56da555dfc05c71f@mail.gmail.com>
Message-ID: <20100210214518.GA30043@qp>

On Tue, Feb 09, 2010 at 08:29:38PM -0500, John Yates wrote:
> On Tue, Feb 9, 2010 at 11:31 AM, Matthias-Christian Ott <ott@mirix.org> wrote:
> > The rest of my environment consits of several urxvts/uxterms and
> > firefox.
> 
> (Please forgive me if the following attempt to extrapolate from your
> brief response is off target.)
> 
> It sounds like you are a "dyed in the wool" command-line user.
> Further, it sounds like you are saying that not only do you _not_ run
> a mainstream window manager but also that you choose _not_ to run any
> of the components associated with a mainstream GUI desktop
> environment.

None of the mainstream desktop environments meets my needs (I tried
them for several years), though I really appreciate visualisation. It
may sound a bit odd, but software that uses technology and concepts
from an era when people used dot matrix printers and terminals simply
works for me better. It's not that I'm happy with it, but I simply
couldn't find something better.

> I too am a command-line devotee though I run most of my shells within
> emacs.  That said I am happy to run bits of the gnome GUI in a single
> bar across the top of my screen (gnome panel and a handful of
> applets).  Within that panel I use dzen2 to displays what would
> otherwise appear on a title bar if I chose to have my windows so
> decorated.  Again in that panel I have Mod4-p bound run dmenu for
> launching programs.  And much as I love tiling window managers in
> general and xmonad in particular I still appreciate the Gnome
> Workspace Switcher's visual presentation of my 9 workspaces.  (A
> picture can truly be worth many key strokes and much searching.)
> 
> Bottom-line: even after replacing my window manager I find that a
> desktop environment still offers many reusable components that I would
> never think of reinventing.  I encourage you to read the wiki pages on
> xmonad integration with Gnome and/or KDE.  (I use Gnome because it is
> Ubuntu's default environment and therefore best supported under that
> distribution.)

It was not long ago that you could live very well without GNOME and
KDE. But since then people tried to unify hardware configuration and
the result of this is hal, NetworkManager and GNOME Power Manager. This
has the unpleasant result that nearly all major GNU/Linux distributions
just work with them out of the box.

You have a herd of daemons idling on your system (which aren't even
decoupled from the user interface), not to mention the unnecessary
abstraction and redundant security layers. If you choose to live
without them, you have a hard life, because now you have to imitate
their functionality with the previous generation software, just
because developers want to give users graphical user interfaces.

I really regret this development and developed a certain antipathy
against GNOME and KDE. They don't fulfil my needs and make my life
harder that it could be.

Generally speaking, this is an outcome of the UNIX history, an
operating system that is the evolution of Space Travel. The worse is
better approach and general UNIX philosophy are just a bad joke.
 
> /john

Regards,
Matthias-Christian
From mail at justinbogner.com  Thu Feb 11 01:52:59 2010
From: mail at justinbogner.com (Justin Bogner)
Date: Thu Feb 11 01:24:08 2010
Subject: [xmonad] Re: Issue 343 in xmonad: XMonad.Prompt.RunOrRaise doesnt
	always detect an already running program
In-Reply-To: <f891ced41002102032w5f14045cxc8567e576ada7f2d@mail.gmail.com>
References: <0-3425899027203913298-15208981400943881031-codesite-noreply=google.com@googlecode.com>
	<3-3425899027203913298-15208981400943881031-codesite-noreply=google.com@googlecode.com>
	<4-3425899027203913298-15208981400943881031-codesite-noreply=google.com@googlecode.com>
	<cbf55b100911231010o6695b889te7a7abeec372ae4a@mail.gmail.com>
	<f891ced41002102032w5f14045cxc8567e576ada7f2d@mail.gmail.com>
Message-ID: <f891ced41002102252t99437dbg14d269a71b8c3a7e@mail.gmail.com>

[Note: I sent an incorrect patch earlier, but I think the mail bounced.
If you see another mail like this one, this is the correct one.]

Took me a while to get around to it, but this should fix issue
343. Spencer's idea of passing in the workarounds is more correct, but
given that the workarounds only seem to be necessary for pre-3.0 mozilla
apps, I don't think it's necessary (yet).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: issue343.dpatch
Type: application/octet-stream
Size: 28842 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/xmonad/attachments/20100211/2b658b0a/issue343-0001.obj
From vogt.adam at gmail.com  Thu Feb 11 02:15:34 2010
From: vogt.adam at gmail.com (Adam Vogt)
Date: Thu Feb 11 01:46:42 2010
Subject: [xmonad] darcs patch: Fix compile error when using base-3 (thanks
	bogner).
Message-ID: <4b73ae96.9753f10a.4ea3.65de@mx.google.com>

Thu Feb 11 01:39:38 EST 2010  Adam Vogt <vogt.adam@gmail.com>
  * Fix compile error when using base-3 (thanks bogner).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 4474 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/xmonad/attachments/20100211/c298b450/attachment.bin
From gwern0 at gmail.com  Thu Feb 11 11:43:41 2010
From: gwern0 at gmail.com (Gwern Branwen)
Date: Thu Feb 11 11:14:45 2010
Subject: [xmonad] XMC.Prompt: changing greenXPConfig to have no border
In-Reply-To: <ccd8be491002082259y40ce18b3o39ad63c8edc3e753@mail.gmail.com>
References: <cbf55b101002081351n275cfe94w66c8b3804d7b6266@mail.gmail.com>
	<ccd8be491002082259y40ce18b3o39ad63c8edc3e753@mail.gmail.com>
Message-ID: <cbf55b101002110843g2f2c55e9kabd550db53488c78@mail.gmail.com>

On Tue, Feb 9, 2010 at 1:59 AM, Ivan Miljenovic
<ivan.miljenovic@gmail.com> wrote:
> On 9 February 2010 08:51, Gwern Branwen <gwern0@gmail.com> wrote:
>> As far as the config archive knows, the only 2 users of greenXPConfig
>> are myself and Adam Vogt:
>
> Yes, but there is quite likely to be many other people that don't have
> configs submitted to the archive that use this config (I don't, but
> there might be some that do). ?As such, this is a change that they
> won't be expecting, etcetera, etcetera.

It removes, rather than adds, and so is that much less likely to bother anyone.

Also, if they really cared, they should've uploaded their config. We
can't let ourselves be held hostage by hypotheticals.

Since Adam has assented, I'm making the change now.

-- 
gwern
From darcswatch at nomeata.de  Thu Feb 11 12:05:25 2010
From: darcswatch at nomeata.de (darcswatch@nomeata.de)
Date: Thu Feb 11 11:36:29 2010
Subject: [xmonad] Applied: darcs patch: Fix compile error when using base-3
	(thanks	bogner).
References: <4b73ae96.9753f10a.4ea3.65de@mx.google.com>
Message-ID: <E1NfcTl-0001Mc-TK@quimby.ehbuehl.net>

This 1-patch bundle was just applied to http://code.haskell.org/xmonad:

20100211063938  Adam Vogt <vogt.adam@gmail.com>
 * Fix compile error when using base-3 (thanks bogner).


-- 
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__code.haskell.org_xmonad.html#bundle-0acc4941cd032672277758e993e5b34e7b478a00
From gwern0 at gmail.com  Thu Feb 11 12:39:03 2010
From: gwern0 at gmail.com (Gwern Branwen)
Date: Thu Feb 11 12:10:21 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib;
	WAS Small announce about the completion of the bluetile merge
Message-ID: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>

On Mon, Dec 7, 2009 at 7:27 PM, Gwern Branwen <gwern0@gmail.com> wrote:
> On Mon, Dec 7, 2009 at 4:34 PM, Wirt Wolff <wirtwolff@gmail.com> wrote:
>> A bluetileConfig could also play a role similar to the template
>> config in providing a reference for people picking and choosing parts
>> of the bluetile configuration, or wanting to activate them all plus
>> a few customizations.
>>
>> Thanks for bearing with the long-winded saying of:
>> * Yes I agree they should continue as synced separate projects.
>> * Some of the bluetile server commands should be available from contrib.
>> * There should be a bluetileConfig providing all but the dock and greeter
>> bits from bluetile. As much as possible normal Config.Foo customization
>> methods should work, and any deviations be well documented and include
>> integration helper functions if needed.
>>
>> regards,
>> --
>> wmw
>
> Here's something I've been thinking. What if we came up with an
> xmonad.hs that included all the stuff everybody asks for and the
> obvious newbie aids like a first-run xmesage prompt? (Let's call this
> a standardConfig, as opposed to barebonesConfig or pimpedOutConfig.)
>
> Then we could take the current xmonad package, rename it
> 'xmonad-core'*; the new 'xmonad' would be basically a cabal file
> depending on xmonad-core and xmonad-contrib, and an executable reading
> 'Main.hs...importXMonad...import XMonadContrib.StandardConfig...main =
> xmonad standardConfig'. (xmonad-core's executable would be left alone
> of course.)
>
> If we get ambitious, the new xmonad main could do more. Perhaps we
> could check for XineRama in main and then modify our standardConfig to
> use SmartBorders or not?
>
> This, I think, could make everyone happy:
>
> - The people concerned about keeping the core minimal and pure can
> tell anyone suggesting 'hey, let's make SmartBorders the default
> layout' to change the standardConfig and leave the core alone. The
> tension between a default that is on par with TWM or raw X and a
> bloated failing awesome-like core goes away.
> - People who really want the stripped down xmonad have a name which
> makes it very clear which one of 'xmonad', 'xmonad-core', and
> 'xmonad-contrib' they want.
> - Distro & package maintainers bear very small costs since the package
> is really small and simple. Quite possibly it may not need updating
> for years or indefinitely once we get dynamic linking. (Since, if I
> understand the idea right, the compiled program would not hardwire the
> xmonad libraries but point to libxmonad.so or something, and would get
> new versions of 'xmonad' and 'standardConfig' everytime the respective
> libraries were changed.)
> - The majority of our users' lives will be easier: by installing
> 'xmonad', they get the core and -contrib as dependencies, and they
> don't have to struggle to get a comfortable setup. Sane defaults. I
> think we could make a standardConfig which is competitive with fluxbox
> or ratpoison. Even if a user doesn't want the spartan -core, but
> dislikes the standardConfig, they could still be better off, since
> it's unlikely they dislike the entire thing or even most of it. It
> seems to me that most people tend to dislike 1 or 2 things; if a
> person dislikes only 1 thing, they ideally will only have to change
> one thing.
> - People with existing configs are entirely unaffected. Because module
> names are split from package names, their xmonad.hs will never know
> the difference. (Presumably the new xmonad executable will see the
> xmonad.hs and recompile/run it rather than continue with
> standardConfig.)
> - This idea is better than some separate 'bluetile' executable
> package. dons and others have spent years publicizing xmonad. People
> who want xmonad install 'xmonad'. The people who would benefit from it
> are almost by definition the people who would not know about it until
> too late.
> ? ? Nor can we add an executable section to XMonadContrib for exactly
> the same reason. Someone just trying out XMonad may well never install
> -contrib or even know about it until they begin complaining. If you
> knew little about Xmonad and saw ?the Debian description at
> <http://packages.debian.org/sid/xmonad> would you be able to instantly
> infer 100% of the time that "Xmonad is configured in Haskell, and
> custom layout algorithms may be implemented by the user in config
> files" implies that there is an enormous collection of extensions &
> customizations called xmonad-contrib? I mean, -contrib isn't even a
> recommended or suggests!
>
> The major downsides I can think of:
>
> - hardcore minimalists might complain that they have to relearn to
> 'install xmonad-core' rather than 'install xmonad', lest they pull in
> -contrib as well. But then, these tend to be the people best able to
> bear the costs; I cannot weep for them.
> - the documentation might become misleading in places. Perhaps not
> majorly; many problems will be averted by the fact that the old
> 'xmonad' executable could always be reached as 'xmonad-core', and to
> do anything programming-wise would require using module names, and
> since the new xmonad depends on xmonad-core, there'd be no breakage.
> To be consistent, we might want to rename the darcs repo to
> .../xmonad-core; but then, the new 'xmonad' is so small we could just
> tuck it away in its own directory, or make the repo have 2 top-level
> folders, xmonad-core & xmonad.
> - this requires effort and approval from many people.
> ? ? (How many distro maintainers do we have? 3 or 4? Toss in another
> 3 for the -core devs, and then maybe a few more for people in favor of
> the general idea of a default userfriendly config but really couldn't
> we just make it another XMC module or something. Hard to have a
> consensus or get anything done with 10 people complaining, and this
> doesn't work if the official xmonad package doesn't change. It can't
> be done as a fork, as I covered above.)
>
> * this is what everybody in #xmonad seems to say to distinguish the
> core package from contrib, anyway

Has anyone thought about it since? It's not at all uncommon in #xmonad
to see people having issues with adding common config options that I
think this proposal would address.

-- 
gwern
From hofmann2004 at arcor.de  Thu Feb 11 13:34:27 2010
From: hofmann2004 at arcor.de (Ralph Hofmann)
Date: Thu Feb 11 13:05:37 2010
Subject: [xmonad] Autohiding of the Gnome-Panel
Message-ID: <1265913268.2432.6.camel@desktop>

I use xmonad and Gnome and I would like to use a gnome-panel with
autohiding. But with autohiding the gnome-panel stays always behind the
windows and can't be accessed. A google search only showed me a rather
old bug report. I've tried avoidStruts from XMonad-Hooks-ManageDocks,
but it didn't help.

Is there a solution?

Greetings

Ralph

From Julien.Steinhauser at orange.fr  Thu Feb 11 13:52:35 2010
From: Julien.Steinhauser at orange.fr (julien steinhauser)
Date: Thu Feb 11 13:23:00 2010
Subject: [xmonad] Autohiding of the Gnome-Panel
In-Reply-To: <1265913268.2432.6.camel@desktop>
References: <1265913268.2432.6.camel@desktop>
Message-ID: <20100211185235.GA9392@eol.dynalias.org>

On Thu, Feb 11, 2010 at 07:34:27PM +0100, Ralph Hofmann wrote:
> 
> I use xmonad and Gnome and I would like to use a gnome-panel with
> autohiding. But with autohiding the gnome-panel stays always behind the
> windows and can't be accessed. A google search only showed me a rather
> old bug report. I've tried avoidStruts from XMonad-Hooks-ManageDocks,
> but it didn't help.
> 
> Is there a solution?
> 

Yes, while searching something similar to setup an environnement
for my girlfriend I had found the following in the mailing list archive
but I didn't wrote down the original author name, sorry...

In ManageDocks.hs go to line 128 and substitute :

? ? struts <- (filter careAbout . concat) `fmap` mapM getStrut wins

? ? -- we grab the window attributes of the root window rather than checking
? ? -- the width of the screen because xlib caches this info and it tends to
? ? -- be incorrect after RAndR
? ? wa <- io $ getWindowAttributes dpy rootw
? ? let screen = r2c $ Rectangle (fi $ wa_x wa) (fi $ wa_y wa) (fi $ wa_width wa) (fi $ wa_height wa)
? ? return $ \r -> c2r $ foldr (reduce screen) (r2c r) struts
? where careAbout (s,_,_,_) = s `S.member` ss

with :

? ? (strutWins,struts) <- do
? ? ? stss <- mapM getStrut wins
? ? ? let (ws, s) = unzip [ (w,st) | (w,sts) <- zip wins stss, st <- sts, careAbout st ]
? ? ? return (unique ws, unique s)

? ? -- move all the struts to the top of X's stacking order.
? ? sequence_ $ map (\w -> io $ raiseWindow dpy w) strutWins

? ? -- we grab the window attributes of the root window rather than checking
? ? -- the width of the screen because xlib caches this info and it tends to
? ? -- be incorrect after RAndR
? ? wa <- io $ getWindowAttributes dpy rootw
? ? let screen = r2c $ Rectangle (fi $ wa_x wa) (fi $ wa_y wa) (fi $ wa_width wa) (fi $ wa_height wa)
? ? return $ \r -> c2r $ foldr (reduce screen) (r2c r) struts
? where careAbout (s,_,_,_) = s `S.member` ss

? ? ? ? unique []? ? ?= []
? ? ? ? unique (x:xs) = x : unique (filter (/=x) xs)

and then rebuild your librairies.

It was advised it could break something else in the config
but i don't remember what.

I hope it will help anyway.


From wagnerdm at seas.upenn.edu  Thu Feb 11 16:19:25 2010
From: wagnerdm at seas.upenn.edu (wagnerdm@seas.upenn.edu)
Date: Thu Feb 11 16:20:11 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS
	Small announce about the completion of the bluetile merge
In-Reply-To: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
Message-ID: <20100211161925.11365r1y99qn21s0@webmail.seas.upenn.edu>

I for one am strongly in favor of sane defaults, and I don't think  
current xmonad can really claim that seriously. Breaking up the  
packages this way could enable that.
~d

Quoting Gwern Branwen <gwern0@gmail.com>:

> On Mon, Dec 7, 2009 at 7:27 PM, Gwern Branwen <gwern0@gmail.com> wrote:
>> On Mon, Dec 7, 2009 at 4:34 PM, Wirt Wolff <wirtwolff@gmail.com> wrote:
>>> A bluetileConfig could also play a role similar to the template
>>> config in providing a reference for people picking and choosing parts
>>> of the bluetile configuration, or wanting to activate them all plus
>>> a few customizations.
>>>
>>> Thanks for bearing with the long-winded saying of:
>>> * Yes I agree they should continue as synced separate projects.
>>> * Some of the bluetile server commands should be available from contrib.
>>> * There should be a bluetileConfig providing all but the dock and greeter
>>> bits from bluetile. As much as possible normal Config.Foo customization
>>> methods should work, and any deviations be well documented and include
>>> integration helper functions if needed.
>>>
>>> regards,
>>> --
>>> wmw
>>
>> Here's something I've been thinking. What if we came up with an
>> xmonad.hs that included all the stuff everybody asks for and the
>> obvious newbie aids like a first-run xmesage prompt? (Let's call this
>> a standardConfig, as opposed to barebonesConfig or pimpedOutConfig.)
>>
>> Then we could take the current xmonad package, rename it
>> 'xmonad-core'*; the new 'xmonad' would be basically a cabal file
>> depending on xmonad-core and xmonad-contrib, and an executable reading
>> 'Main.hs...importXMonad...import XMonadContrib.StandardConfig...main =
>> xmonad standardConfig'. (xmonad-core's executable would be left alone
>> of course.)
>>
>> If we get ambitious, the new xmonad main could do more. Perhaps we
>> could check for XineRama in main and then modify our standardConfig to
>> use SmartBorders or not?
>>
>> This, I think, could make everyone happy:
>>
>> - The people concerned about keeping the core minimal and pure can
>> tell anyone suggesting 'hey, let's make SmartBorders the default
>> layout' to change the standardConfig and leave the core alone. The
>> tension between a default that is on par with TWM or raw X and a
>> bloated failing awesome-like core goes away.
>> - People who really want the stripped down xmonad have a name which
>> makes it very clear which one of 'xmonad', 'xmonad-core', and
>> 'xmonad-contrib' they want.
>> - Distro & package maintainers bear very small costs since the package
>> is really small and simple. Quite possibly it may not need updating
>> for years or indefinitely once we get dynamic linking. (Since, if I
>> understand the idea right, the compiled program would not hardwire the
>> xmonad libraries but point to libxmonad.so or something, and would get
>> new versions of 'xmonad' and 'standardConfig' everytime the respective
>> libraries were changed.)
>> - The majority of our users' lives will be easier: by installing
>> 'xmonad', they get the core and -contrib as dependencies, and they
>> don't have to struggle to get a comfortable setup. Sane defaults. I
>> think we could make a standardConfig which is competitive with fluxbox
>> or ratpoison. Even if a user doesn't want the spartan -core, but
>> dislikes the standardConfig, they could still be better off, since
>> it's unlikely they dislike the entire thing or even most of it. It
>> seems to me that most people tend to dislike 1 or 2 things; if a
>> person dislikes only 1 thing, they ideally will only have to change
>> one thing.
>> - People with existing configs are entirely unaffected. Because module
>> names are split from package names, their xmonad.hs will never know
>> the difference. (Presumably the new xmonad executable will see the
>> xmonad.hs and recompile/run it rather than continue with
>> standardConfig.)
>> - This idea is better than some separate 'bluetile' executable
>> package. dons and others have spent years publicizing xmonad. People
>> who want xmonad install 'xmonad'. The people who would benefit from it
>> are almost by definition the people who would not know about it until
>> too late.
>> ? ? Nor can we add an executable section to XMonadContrib for exactly
>> the same reason. Someone just trying out XMonad may well never install
>> -contrib or even know about it until they begin complaining. If you
>> knew little about Xmonad and saw ?the Debian description at
>> <http://packages.debian.org/sid/xmonad> would you be able to instantly
>> infer 100% of the time that "Xmonad is configured in Haskell, and
>> custom layout algorithms may be implemented by the user in config
>> files" implies that there is an enormous collection of extensions &
>> customizations called xmonad-contrib? I mean, -contrib isn't even a
>> recommended or suggests!
>>
>> The major downsides I can think of:
>>
>> - hardcore minimalists might complain that they have to relearn to
>> 'install xmonad-core' rather than 'install xmonad', lest they pull in
>> -contrib as well. But then, these tend to be the people best able to
>> bear the costs; I cannot weep for them.
>> - the documentation might become misleading in places. Perhaps not
>> majorly; many problems will be averted by the fact that the old
>> 'xmonad' executable could always be reached as 'xmonad-core', and to
>> do anything programming-wise would require using module names, and
>> since the new xmonad depends on xmonad-core, there'd be no breakage.
>> To be consistent, we might want to rename the darcs repo to
>> .../xmonad-core; but then, the new 'xmonad' is so small we could just
>> tuck it away in its own directory, or make the repo have 2 top-level
>> folders, xmonad-core & xmonad.
>> - this requires effort and approval from many people.
>> ? ? (How many distro maintainers do we have? 3 or 4? Toss in another
>> 3 for the -core devs, and then maybe a few more for people in favor of
>> the general idea of a default userfriendly config but really couldn't
>> we just make it another XMC module or something. Hard to have a
>> consensus or get anything done with 10 people complaining, and this
>> doesn't work if the official xmonad package doesn't change. It can't
>> be done as a fork, as I covered above.)
>>
>> * this is what everybody in #xmonad seems to say to distinguish the
>> core package from contrib, anyway
>
> Has anyone thought about it since? It's not at all uncommon in #xmonad
> to see people having issues with adding common config options that I
> think this proposal would address.
>
> --
> gwern
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
>

From spencerjanssen at gmail.com  Fri Feb 12 00:06:05 2010
From: spencerjanssen at gmail.com (Spencer Janssen)
Date: Thu Feb 11 23:36:56 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS
	Small announce about the completion of the bluetile merge
In-Reply-To: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
Message-ID: <20100212050605.GA9080@celeborn>

I don't see the point of adding another package, what problem does it really
solve?  Some of the arguments for adding a third package border on
intellectual dishonesty: we can't claim that xmonad is the same minimal window
manager if we quadruple the lines of code used in the default configuration.

I'd like to see concrete suggestions of what ought to be added if we made this
xmonad/core/contrib split.

Regarding "sane defaults", I think there are just a few things that need to
be added to xmonad proper:
 - Full screen windows
 - ICCCM focus protocol/make Java work
 - Handling of a few window types: dock, desktop, etc.
 - Status bar without editing xmonad.hs (current plan is to do this via EWMH)

Each of these could be added to the xmonad we know now without changing
packaging policy.


Cheers,
Spencer Janssen
From wagnerdm at seas.upenn.edu  Fri Feb 12 00:36:38 2010
From: wagnerdm at seas.upenn.edu (wagnerdm@seas.upenn.edu)
Date: Fri Feb 12 00:07:46 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS
	Small announce about the completion of the bluetile merge
In-Reply-To: <20100212050605.GA9080@celeborn>
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
	<20100212050605.GA9080@celeborn>
Message-ID: <20100212003638.5212952sqrubmbxk@webmail.seas.upenn.edu>

Quoting Spencer Janssen <spencerjanssen@gmail.com>:

>  (1) Full screen windows
>  (2) ICCCM focus protocol/make Java work
>  (3) Handling of a few window types: dock, desktop, etc.
>  (4) Status bar without editing xmonad.hs (current plan is to do  
> this via EWMH)

These are a good start. I assume (1) means (isFullscreen ->  
doFullFloat), and (3) means sticking avoidStruts/manageDocks in the  
core. To those, I would add smartBorders, modMask = mod4Mask,  
something to address  
http://www.reddit.com/r/xmonad/comments/aaexm/gnome_do_in_xmonad/c0glyav (not  
sure if there's even anything in contrib right now for this), and  
perhaps switching the default layouts to one of the hinted ones (can't  
count how many people complain about urxvt's, emacs' and vim's  
misbehavior in #xmonad). I think gwern's suggestion to have some kind  
of welcome-message for first-time users should also be considered part  
of the proposal.

2 cents, etc. etc.
~d
From ivan.miljenovic at gmail.com  Fri Feb 12 04:54:56 2010
From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic)
Date: Fri Feb 12 04:26:02 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib;
	WAS Small announce about the completion of the bluetile merge
In-Reply-To: <20100212050605.GA9080@celeborn> (Spencer Janssen's message of
	"Thu, 11 Feb 2010 23:06:05 -0600")
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
	<20100212050605.GA9080@celeborn>
Message-ID: <87sk96srrj.fsf@gmail.com>

Spencer Janssen <spencerjanssen@gmail.com> writes:

> I don't see the point of adding another package, what problem does it really
> solve?  Some of the arguments for adding a third package border on
> intellectual dishonesty: we can't claim that xmonad is the same minimal window
> manager if we quadruple the lines of code used in the default configuration.
>

Agreed; if anything, I would think that merging xmonad and
xmonad-contrib makes more sense than another split (seeing how many new
users don't realise that xmonad by itself is rather boring).

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
IvanMiljenovic.wordpress.com
From hofmann2004 at arcor.de  Fri Feb 12 06:56:51 2010
From: hofmann2004 at arcor.de (Ralph Hofmann)
Date: Fri Feb 12 06:27:57 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS
	Small announce about the completion of the bluetile merge
In-Reply-To: <20100212050605.GA9080@celeborn>
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
	<20100212050605.GA9080@celeborn>
Message-ID: <1265975811.2545.37.camel@desktop>

As a still new user, who is trying to find his way, i think it is very
good to start with a very simple default configuration. 

But there is some kind of a gap between the defaults and the highly
individualized configs, that can be found by searching the internet. As
a new user, you are a little bit lost in this gap.

It could be filled by config examples, which each of them would cover a
certain topic. For instance the topic "layout" could be covered by a
xmonad.hs, that contains a series of layouts, which can be tested by
commenting them in and out. Another topic could be "dock handling".
Another one "key and mouse configuration" and so on. The examples should
cover only the topic and nothing else. I think this would be very
helpful to get new users started.

Regards

Ralph


Am Donnerstag, den 11.02.2010, 23:06 -0600 schrieb Spencer Janssen:
> I don't see the point of adding another package, what problem does it really
> solve?  Some of the arguments for adding a third package border on
> intellectual dishonesty: we can't claim that xmonad is the same minimal window
> manager if we quadruple the lines of code used in the default configuration.
> 
> I'd like to see concrete suggestions of what ought to be added if we made this
> xmonad/core/contrib split.
> 
> Regarding "sane defaults", I think there are just a few things that need to
> be added to xmonad proper:
>  - Full screen windows
>  - ICCCM focus protocol/make Java work
>  - Handling of a few window types: dock, desktop, etc.
>  - Status bar without editing xmonad.hs (current plan is to do this via EWMH)
> 
> Each of these could be added to the xmonad we know now without changing
> packaging policy.
> 
> 
> Cheers,
> Spencer Janssen
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad


From hofmann2004 at arcor.de  Fri Feb 12 10:19:37 2010
From: hofmann2004 at arcor.de (Ralph Hofmann)
Date: Fri Feb 12 09:50:41 2010
Subject: [xmonad] Autohiding of the Gnome-Panel
In-Reply-To: <20100211185235.GA9392@eol.dynalias.org>
References: <1265913268.2432.6.camel@desktop>
	<20100211185235.GA9392@eol.dynalias.org>
Message-ID: <1265987977.2924.1.camel@desktop>

Am Donnerstag, den 11.02.2010, 19:52 +0100 schrieb julien steinhauser:
>
> and then rebuild your librairies.
> 
> It was advised it could break something else in the config
> but i don't remember what.
> 
> I hope it will help anyway.
> 

It helps.

Thank you very much.

Cheers

Ralph


From codesite-noreply at google.com  Fri Feb 12 15:01:26 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Fri Feb 12 14:32:27 2010
Subject: [xmonad] Re: Issue 135 in xmonad: toggleBorders
	(XMonad.Action.NoBorders) Causes floating windows to grow in size
In-Reply-To: <1-3425899027203913298-3718672213899791083-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-3718672213899791083-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-3718672213899791083-codesite-noreply=google.com@googlecode.com>
Message-ID: <2-3425899027203913298-3718672213899791083-codesite-noreply=google.com@googlecode.com>


Comment #2 on issue 135 by neoraider: toggleBorders  
(XMonad.Action.NoBorders) Causes floating windows to grow in size
http://code.google.com/p/xmonad/issues/detail?id=135

This bug occurred when I tried to disable the border of a Gnome-Do window
automatically (it doesn't look nice with one), causing the Gnome-Do window  
to grow
indefinitely, filling the whole screen after a few seconds.

The attached patch solves the problem for me, making  
XMonad.Operations.floatLocation
use the actual window border width instead of the globally configured one.

Attachments:
	xmonad.patch  588 bytes

--
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
From gwern0 at gmail.com  Fri Feb 12 15:55:08 2010
From: gwern0 at gmail.com (Gwern Branwen)
Date: Fri Feb 12 15:26:09 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS 
	Small announce about the completion of the bluetile merge
In-Reply-To: <20100212050605.GA9080@celeborn>
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
	<20100212050605.GA9080@celeborn>
Message-ID: <cbf55b101002121255v3c8e190dsa6a0d90562af69dc@mail.gmail.com>

On Fri, Feb 12, 2010 at 12:06 AM, Spencer Janssen
<spencerjanssen@gmail.com> wrote:
> I don't see the point of adding another package, what problem does it really
> solve? ?Some of the arguments for adding a third package border on
> intellectual dishonesty: we can't claim that xmonad is the same minimal window
> manager if we quadruple the lines of code used in the default configuration.

If we're going to throw around phrases like 'intellectual dishonesty',
then I submit that presenting the current xmonad-core as anything more
than a demo is dishonest. Does anyone use xmonad-core without any
customizations? Or without anything from xmonad-contrib?

For that matter, I see people in #haskell who still think xmonad-core
is ~500 lines. Is it dishonest that
http://www.cse.unsw.edu.au/~dons/code/xmonad-web/ still says ~500?

Even adding in all the suggestions, the new xmonad will still be
minimalistic compared to most every WM, if not xmonad-core. Any claim
about 'the same minimal window manager' will be just as true with a
simple s/xmonad/xmonad-core/.

> I'd like to see concrete suggestions of what ought to be added if we made this
> xmonad/core/contrib split.
>
> Regarding "sane defaults", I think there are just a few things that need to
> be added to xmonad proper:
> ?- Full screen windows
> ?- ICCCM focus protocol/make Java work
> ?- Handling of a few window types: dock, desktop, etc.
> ?- Status bar without editing xmonad.hs (current plan is to do this via EWMH)
>
> Each of these could be added to the xmonad we know now without changing
> packaging policy.
>
>
> Cheers,
> Spencer Janssen

If they really could be added so easily, then why haven't they? Some
of those may be unpolished, but others are old. In the same email, you
complain about the dishonesty of quadrupling the codebase and then
suggest adding those specific ones in; aren't those non-minimalistic
too?

-- 
gwern
From codesite-noreply at google.com  Fri Feb 12 19:40:03 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Fri Feb 12 19:11:05 2010
Subject: [xmonad] Re: Issue 99 in xmonad: Move XMonad.Util.Replace to core
In-Reply-To: <7-3425899027203913298-12435773892097374809-codesite-noreply=google.com@googlecode.com>
References: <7-3425899027203913298-12435773892097374809-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-12435773892097374809-codesite-noreply=google.com@googlecode.com>
Message-ID: <8-3425899027203913298-12435773892097374809-codesite-noreply=google.com@googlecode.com>

Updates:
	Status: Fixed

Comment #8 on issue 99 by SpencerJanssen: Move XMonad.Util.Replace to core
http://code.google.com/p/xmonad/issues/detail?id=99

(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
From darcswatch at nomeata.de  Fri Feb 12 19:45:22 2010
From: darcswatch at nomeata.de (darcswatch@nomeata.de)
Date: Fri Feb 12 19:16:22 2010
Subject: [xmonad] Applied: darcs patch: Add --replace flag with
	documentation (issue	99).
References: <4b2e6eca.47c1f10a.2509.4102@mx.google.com>
Message-ID: <E1Ng68Q-0004Gp-5R@quimby.ehbuehl.net>

This 1-patch bundle was just applied to http://code.haskell.org/xmonad:

20091220183529  Adam Vogt <vogt.adam@gmail.com>
 * Add --replace flag with documentation (issue 99).


-- 
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__code.haskell.org_xmonad.html#bundle-c2538ca292606fefe0916d4ca213f29bb5ffdc04
From cjns1989 at gmail.com  Fri Feb 12 20:41:12 2010
From: cjns1989 at gmail.com (Chris Jones)
Date: Fri Feb 12 20:12:12 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS
	Small announce about the completion of the bluetile merge
In-Reply-To: <cbf55b101002121255v3c8e190dsa6a0d90562af69dc@mail.gmail.com>
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
	<20100212050605.GA9080@celeborn>
	<cbf55b101002121255v3c8e190dsa6a0d90562af69dc@mail.gmail.com>
Message-ID: <20100213014112.GC2986@turki.gavron.org>

On Fri, Feb 12, 2010 at 03:55:08PM EST, Gwern Branwen wrote:
> On Fri, Feb 12, 2010 at 12:06 AM, Spencer Janssen
> <spencerjanssen@gmail.com> wrote:

> > I don't see the point of adding another package, what problem does
> > it really solve? ?Some of the arguments for adding a third package
> > border on intellectual dishonesty: we can't claim that xmonad is the
> > same minimal window manager if we quadruple the lines of code used
> > in the default configuration.

> If we're going to throw around phrases like 'intellectual dishonesty',
> then I submit that presenting the current xmonad-core as anything more
> than a demo is dishonest. Does anyone use xmonad-core without any
> customizations? Or without anything from xmonad-contrib?

I'm a newcomer to xmonad, with no knowledge of Haskell. 

xmonad 0.8 as shipped by debian squeeze let me do everything I needed
without additional customization.

It took my fingers about an hour to learn the well-thought out default
keyboard actions and in terms of window and workspace mangement, there
was absolutely nothing I wasn't able to do more efficiently than on any
desktop or WM I have tried so far.

Minimal customization:

1. I changed the terminal to 'xterm -u8 -tn xterm-256color'
2. I added a minimal xmobar: date, CPU%, THRM, weather, %mem, %swap 

But I could have lived without these.

I can't think of anything that needs to be added to the minimal xmonad
configuration.

Just the impressions & opinions of s/o new to xmonad.

CJ
From codesite-noreply at google.com  Sat Feb 13 04:35:54 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Sat Feb 13 04:06:57 2010
Subject: [xmonad] Re: Issue 177 in xmonad: xmonad does not follow ICCCM and
	ignores WM_TAKE_FOCUS protocol
In-Reply-To: <29-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
References: <29-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
Message-ID: <30-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>


Comment #30 on issue 177 by k.ljungkvist: xmonad does not follow ICCCM and  
ignores WM_TAKE_FOCUS protocol
http://code.google.com/p/xmonad/issues/detail?id=177

The latest patch solves the problems with focus in Matlab for me. Good work!

--
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
From gwern0 at gmail.com  Sat Feb 13 18:37:22 2010
From: gwern0 at gmail.com (gwern0@gmail.com)
Date: Sat Feb 13 18:08:20 2010
Subject: [xmonad] darcs patch: loc.hs: hlintify (and 1 more)
Message-ID: <4b7737b2.a815f10a.20ac.ffffed44@mx.google.com>

Sat Feb 13 18:15:37 EST 2010  gwern0@gmail.com
  * loc.hs: hlintify

Sat Feb 13 18:28:27 EST 2010  gwern0@gmail.com
  * Main.hs: hlintify - shorter & more readable
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 6467 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/xmonad/attachments/20100213/b6fdc74f/attachment.bin
From codesite-noreply at google.com  Sat Feb 13 18:45:45 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Sat Feb 13 18:16:42 2010
Subject: [xmonad] Issue 373 in xmonad: Hlintify XMonad & XMonadContrib
Message-ID: <0-3425899027203913298-11989166490824167323-codesite-noreply=google.com@googlecode.com>

Status: Accepted
Owner: gwern0
Labels: Type-Enhancement Priority-Low Component-Contrib Maintainability  
Component-Core

New issue 373 by gwern0: Hlintify XMonad & XMonadContrib
http://code.google.com/p/xmonad/issues/detail?id=373

Hlint (http://community.haskell.org/~ndm/hlint/) is a code-style tool that
flags verbose, useless, or otherwise bad bits of code. It would be good if
XMC had clean code. (Hlint strives for 'correctness'; none of the changes
ought to affect the semantics of the code.)

XMonad-core generates roughly 31 suggestions and XMC roughly 468. Even
excluding debatable suggestions like eta-reduction, this is a lot of small
bad things. Fortunately, they are all generally very easy to fix and
understand why the code was flagged, making this a good beginner project.

Attached are the 2 HTML reports hlint generates (obviously 31+468 messages
is a bit much to paste in).

Attachments:
	core.html  38.5 KB
	xmc.html  528 KB

--
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
From juhe_xmonad at hck.sk  Sat Feb 13 18:56:41 2010
From: juhe_xmonad at hck.sk (Juraj Hercek)
Date: Sat Feb 13 18:20:36 2010
Subject: [xmonad] Shutdown hook
Message-ID: <4B773C39.2060204@hck.sk>

Hello,

There is a startupHook in XConfig. I'm missing shutdownHook however. Is 
there any proper way to execute custom code when xmonad is about to exit?

Thanks,
Juraj
From codesite-noreply at google.com  Sat Feb 13 18:49:47 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Sat Feb 13 18:20:43 2010
Subject: [xmonad] Re: Issue 373 in xmonad: Hlintify XMonad & XMonadContrib
In-Reply-To: <0-3425899027203913298-11989166490824167323-codesite-noreply=google.com@googlecode.com>
References: <0-3425899027203913298-11989166490824167323-codesite-noreply=google.com@googlecode.com>
Message-ID: <1-3425899027203913298-11989166490824167323-codesite-noreply=google.com@googlecode.com>


Comment #1 on issue 373 by gwern0: Hlintify XMonad & XMonadContrib
http://code.google.com/p/xmonad/issues/detail?id=373

I like to think of hlint as -Wall on steroids, if that metaphor helps  
anyone.

--
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
From dons at galois.com  Sat Feb 13 18:55:39 2010
From: dons at galois.com (Don Stewart)
Date: Sat Feb 13 18:26:39 2010
Subject: [xmonad] Shutdown hook
In-Reply-To: <4B773C39.2060204@hck.sk>
References: <4B773C39.2060204@hck.sk>
Message-ID: <20100213235539.GC26377@whirlpool.galois.com>

juhe_xmonad:
> Hello,
>
> There is a startupHook in XConfig. I'm missing shutdownHook however. Is  
> there any proper way to execute custom code when xmonad is about to exit?
>

xmonad exits by throwing an asynchronous exception from the inner loop
out to main. The runtime catches this an exits gracefully.

You can write your own shutdown hook by catching this exception in your 
config main, and running your hook, before rethrowing.

I bet someone's already done this, and wrapped it up nicely, otherwise,
look at Control.Exception in the Haskell base library for how to use the
catch/handle functions.

Pseudocode:

    import Control.Exception
    import XMonad

    main = handle xmonad shutdown
       where
        shutdown e = do
            ... my action ...
            throw e
From mail at justinbogner.com  Sat Feb 13 19:28:35 2010
From: mail at justinbogner.com (Justin Bogner)
Date: Sat Feb 13 18:59:35 2010
Subject: [xmonad] [Patch] Remove an obsolete comment
Message-ID: <f891ced41002131628q139f65eanb6643b4dcd1c1b3@mail.gmail.com>

Attached.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: obsolete-comment.patch
Type: application/octet-stream
Size: 5241 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/xmonad/attachments/20100213/8a400d6e/obsolete-comment-0001.obj
From juhe_xmonad at hck.sk  Sat Feb 13 19:56:01 2010
From: juhe_xmonad at hck.sk (Juraj Hercek)
Date: Sat Feb 13 19:19:55 2010
Subject: [xmonad] Shutdown hook
In-Reply-To: <20100213235539.GC26377@whirlpool.galois.com>
References: <4B773C39.2060204@hck.sk>
	<20100213235539.GC26377@whirlpool.galois.com>
Message-ID: <4B774A21.2020101@hck.sk>

On 02/14/2010 12:55 AM, Don Stewart wrote:
> juhe_xmonad:
>    
>> Hello,
>>
>> There is a startupHook in XConfig. I'm missing shutdownHook however. Is
>> there any proper way to execute custom code when xmonad is about to exit?
>>
>>      
> xmonad exits by throwing an asynchronous exception from the inner loop
> out to main. The runtime catches this an exits gracefully.
>
> You can write your own shutdown hook by catching this exception in your
> config main, and running your hook, before rethrowing.
>
> I bet someone's already done this, and wrapped it up nicely, otherwise,
> look at Control.Exception in the Haskell base library for how to use the
> catch/handle functions.
>
> Pseudocode:
>
>      import Control.Exception
>      import XMonad
>
>      main = handle xmonad shutdown
>         where
>          shutdown e = do
>              ... my action ...
>              throw e
>    

Thanks for quick response!

-- Juraj
From ivan.miljenovic at gmail.com  Sat Feb 13 23:17:51 2010
From: ivan.miljenovic at gmail.com (Ivan Miljenovic)
Date: Sat Feb 13 22:48:48 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS 
	Small announce about the completion of the bluetile merge
In-Reply-To: <cbf55b101002121255v3c8e190dsa6a0d90562af69dc@mail.gmail.com>
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
	<20100212050605.GA9080@celeborn>
	<cbf55b101002121255v3c8e190dsa6a0d90562af69dc@mail.gmail.com>
Message-ID: <ccd8be491002132017x55360bd4j85c9e9e74d2a968d@mail.gmail.com>

On 13 February 2010 07:55, Gwern Branwen <gwern0@gmail.com> wrote:
> If we're going to throw around phrases like 'intellectual dishonesty',
> then I submit that presenting the current xmonad-core as anything more
> than a demo is dishonest. Does anyone use xmonad-core without any
> customizations? Or without anything from xmonad-contrib?

I've helped some people on #xmonad get XMonad working on its own
without -contrib...

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
IvanMiljenovic.wordpress.com
Samuel Goldwyn  - "I'm willing to admit that I may not always be
right, but I am never wrong." -
http://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html
From dons at galois.com  Sat Feb 13 23:24:21 2010
From: dons at galois.com (Don Stewart)
Date: Sat Feb 13 22:55:21 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS
	Small announce about the completion of the bluetile merge
In-Reply-To: <20100212050605.GA9080@celeborn>
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
	<20100212050605.GA9080@celeborn>
Message-ID: <20100214042421.GA27360@whirlpool.galois.com>

spencerjanssen:
> I don't see the point of adding another package, what problem does it really
> solve?  Some of the arguments for adding a third package border on
> intellectual dishonesty: we can't claim that xmonad is the same minimal window
> manager if we quadruple the lines of code used in the default configuration.
> 
> I'd like to see concrete suggestions of what ought to be added if we made this
> xmonad/core/contrib split.
> 
> Regarding "sane defaults", I think there are just a few things that need to
> be added to xmonad proper:
>  - Full screen windows
>  - ICCCM focus protocol/make Java work
>  - Handling of a few window types: dock, desktop, etc.
>  - Status bar without editing xmonad.hs (current plan is to do this via EWMH)
> 
> Each of these could be added to the xmonad we know now without changing
> packaging policy.

I also agree: adding these to the core is the sensible thing.

Originally the idea was that xmonad-the-core was what Spencer and I ran
without any configuration. If that's not the case anymore, we should add
some things to the core. These look like a sensible list of things.

-- Don
From daniel at wagner-home.com  Sun Feb 14 19:09:25 2010
From: daniel at wagner-home.com (daniel@wagner-home.com)
Date: Sun Feb 14 18:40:26 2010
Subject: [xmonad] darcs patch: minor style changes (and 2 more)
Message-ID: <20100215000925.CA8D110CD35@sorghum.localdomain>

Mon Dec 28 12:30:16 EST 2009  Daniel Wagner <daniel@wagner-home.com>
  * minor style changes

Mon Jan  4 00:42:51 EST 2010  Daniel Wagner <daniel@wagner-home.com>
  * DynamicLog support for IndependentScreens

Sun Feb 14 19:07:31 EST 2010  daniel@wagner-home.com
  * documentation for marshallPP
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/x-darcs-patch
Size: 35745 bytes
Desc: A darcs patch for your repository!
Url : http://www.haskell.org/pipermail/xmonad/attachments/20100214/8a2bcfd4/attachment-0001.bin
From dons at galois.com  Sun Feb 14 19:25:47 2010
From: dons at galois.com (Don Stewart)
Date: Sun Feb 14 18:56:43 2010
Subject: [xmonad] [Patch] Remove an obsolete comment
In-Reply-To: <f891ced41002131628q139f65eanb6643b4dcd1c1b3@mail.gmail.com>
References: <f891ced41002131628q139f65eanb6643b4dcd1c1b3@mail.gmail.com>
Message-ID: <20100215002547.GD32019@whirlpool.galois.com>


[Removed an obsolete comment
Justin Bogner <mail@justinbogner.com>**20100213233901
 Ignore-this: 8557f01a889eb533b670d458083b624a
 ] hunk ./XMonad/StackSet.hs 229
  
     where equating f = \x y -> f x == f y
      
      -    -- 'Catch'ing this might be hard. Relies on monotonically
           increasing
           -    -- workspace tags defined in 'new'
           -    --
           -    -- and now tags are not monotonic, what happens here?
           -
            -- |
             -- Set focus to the given workspace.  If that workspace
             does not exist
              -- in the stackset, the original workspace is returned.
              If that workspace is

I'd argue that we keep the comment about Catch -- if only for historical
reasons. There's a design consideration there for someone to look at in
the future.

-- Don
-------------- next part --------------
A non-text attachment was scrubbed...
Name: obsolete-comment.patch
Type: application/octet-stream
Size: 5242 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/xmonad/attachments/20100214/de2b1b82/obsolete-comment.obj
From darcswatch at nomeata.de  Sun Feb 14 19:45:35 2010
From: darcswatch at nomeata.de (darcswatch@nomeata.de)
Date: Sun Feb 14 19:16:29 2010
Subject: [xmonad] Applied: darcs patch: minor style changes (and 2 more)
References: <20100215000925.CA8D110CD35@sorghum.localdomain>
Message-ID: <E1Ngp5j-0007If-Ko@quimby.ehbuehl.net>

This 3-patches bundle was just applied to http://code.haskell.org/XMonadContrib:

20091228173016  Daniel Wagner <daniel@wagner-home.com>
 * minor style changes

20100104054251  Daniel Wagner <daniel@wagner-home.com>
 * DynamicLog support for IndependentScreens

20100215000731  daniel@wagner-home.com
 * documentation for marshallPP


-- 
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__code.haskell.org_XMonadContrib.html#bundle-1a15b6cc3ecaacce603de6042bc6e06e181bbb39
From codesite-noreply at google.com  Mon Feb 15 07:44:52 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb 15 07:15:43 2010
Subject: [xmonad] Re: Issue 177 in xmonad: xmonad does not follow ICCCM and
	ignores WM_TAKE_FOCUS protocol
In-Reply-To: <30-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
References: <30-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
Message-ID: <31-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>


Comment #31 on issue 177 by malte.sommerkorn: xmonad does not follow ICCCM  
and ignores WM_TAKE_FOCUS protocol
http://code.google.com/p/xmonad/issues/detail?id=177

Just wanted to add that usage of Maple (another commercial Java app)  
benefits from
the latest patch, too. (It doesn't apply right away to the current  
repository, but
the conflict resolution is obvious.)

--
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
From cjns1989 at gmail.com  Mon Feb 15 12:11:44 2010
From: cjns1989 at gmail.com (Chris Jones)
Date: Mon Feb 15 11:42:37 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS
	Small announce about the completion of the bluetile merge
In-Reply-To: <87sk96srrj.fsf@gmail.com>
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
	<20100212050605.GA9080@celeborn> <87sk96srrj.fsf@gmail.com>
Message-ID: <20100215171144.GA3343@turki.gavron.org>

On Fri, Feb 12, 2010 at 04:54:56AM EST, Ivan Lazar Miljenovic wrote:
> Spencer Janssen <spencerjanssen@gmail.com> writes:

[..]

> (seeing how many new users don't realise that xmonad by itself is
> rather boring).

.. which for a _user_ is exactly what a good window manager should be: I
don't it to be 'interesting' like compiz and such.. so I'm not
distracted and can focus on whatever I have to do.

Obviously not for me to have a say in this, but I'd much prefer folks
who have mastered this stuff wrote a detailed manual on xmonad
configuration.

CJ
From cjns1989 at gmail.com  Mon Feb 15 12:28:31 2010
From: cjns1989 at gmail.com (Chris Jones)
Date: Mon Feb 15 11:59:31 2010
Subject: [xmonad] Copy/paste via keyboard
Message-ID: <20100215172831.GB3343@turki.gavron.org>

GNU/screen has a powerful keyboard-controlled mechanism that lets you
copy rectangular blocks, append to its paste buffer, direct the output
to a file, etc.

I like tiny fonts, and I find that using the keyboard is quicker and a
lot more accurate. When I use the mouse, I always end up either missing
some stuff, or copy-pasting extra stuff to be on the safe side. 

I _think_ I saw references online to a similar copy/paste feature in
xmonad, but nothing conclusive. 

Is it something that's available out of the box with 0.8 (debian
squeeze) or is it something that you need to script/configure?

Or is this just a case of wishful thinking on my part?

Thanks,

CJ

From vogt.adam at gmail.com  Mon Feb 15 13:38:16 2010
From: vogt.adam at gmail.com (Adam Vogt)
Date: Mon Feb 15 13:09:33 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS
	Small announce about the completion of the bluetile merge
In-Reply-To: <20100215171144.GA3343@turki.gavron.org>
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
	<20100212050605.GA9080@celeborn> <87sk96srrj.fsf@gmail.com>
	<20100215171144.GA3343@turki.gavron.org>
Message-ID: <20100215183816.GA14081@smuckers>

* On Monday, February 15 2010, Chris Jones wrote:

>[..]
>
>Obviously not for me to have a say in this, but I'd much prefer folks
>who have mastered this stuff wrote a detailed manual on xmonad
>configuration.
>
>CJ

Hello Chris,

What is missing from the present documentation that you would like to
see in this detailed manual?

--
Adam
From mr.progo at gmail.com  Mon Feb 15 13:53:16 2010
From: mr.progo at gmail.com (Mikael Puhakka)
Date: Mon Feb 15 13:24:09 2010
Subject: [xmonad] Layout.Gaps and PerScreen; is it going to happen?
Message-ID: <d663d1bd1002151053q7e547416jeae7843d8b52c12f@mail.gmail.com>

Dear Xmonad community,

I've recently switched to Xmonad from a 3-year relationship with
Fluxbox and just after 4-5 days of daily using I am beginning to love
this thing very passionately.

However, the old habits die hard and I don't even want to let go of
every of them. Some vices of mine include a small Conky instance in a
corner, a pseudo-transparent xterm tail -f :ing /var/log/messages with
semi-hourly fortunes, and a Rainlendar the flashy calendar
application.

The "tail -f" monitor behind stuff in tiled environments such as this
doesn't make much sense but I rather wouldn't part from the other two.
Basically the subject says it all; I wonder if there is a working Gap
modifier that would work on one screen only (I have currently a
tri-head xinerama setup). I googled through the mailing lists and
since 2008 there has been no fuzz about it.

Am I left with a hack like a gapped layout to be used with one screen
only, or is there a better solution for this? These applications don't
do well with Layout.Monitor or alike. As a lazy workaround I've been
using "Circle" layout for that particular screen and workspace (it's
surprisingly handy and not just an eye toy).

TIA,
Mikael
From wagnerdm at seas.upenn.edu  Mon Feb 15 13:58:59 2010
From: wagnerdm at seas.upenn.edu (wagnerdm@seas.upenn.edu)
Date: Mon Feb 15 13:29:57 2010
Subject: [xmonad] Layout.Gaps and PerScreen; is it going to happen?
In-Reply-To: <d663d1bd1002151053q7e547416jeae7843d8b52c12f@mail.gmail.com>
References: <d663d1bd1002151053q7e547416jeae7843d8b52c12f@mail.gmail.com>
Message-ID: <20100215135859.66357h3taeqnb7g0@webmail.seas.upenn.edu>

If conky and rainlendar set their struts properly, you should be able  
to get by with manageDocks/avoidStruts. Documentation:
http://www.xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-ManageDocks.html

~d

Quoting Mikael Puhakka <mr.progo@gmail.com>:

> Dear Xmonad community,
>
> I've recently switched to Xmonad from a 3-year relationship with
> Fluxbox and just after 4-5 days of daily using I am beginning to love
> this thing very passionately.
>
> However, the old habits die hard and I don't even want to let go of
> every of them. Some vices of mine include a small Conky instance in a
> corner, a pseudo-transparent xterm tail -f :ing /var/log/messages with
> semi-hourly fortunes, and a Rainlendar the flashy calendar
> application.
>
> The "tail -f" monitor behind stuff in tiled environments such as this
> doesn't make much sense but I rather wouldn't part from the other two.
> Basically the subject says it all; I wonder if there is a working Gap
> modifier that would work on one screen only (I have currently a
> tri-head xinerama setup). I googled through the mailing lists and
> since 2008 there has been no fuzz about it.
>
> Am I left with a hack like a gapped layout to be used with one screen
> only, or is there a better solution for this? These applications don't
> do well with Layout.Monitor or alike. As a lazy workaround I've been
> using "Circle" layout for that particular screen and workspace (it's
> surprisingly handy and not just an eye toy).
>
> TIA,
> Mikael
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
>


From codesite-noreply at google.com  Mon Feb 15 15:35:58 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb 15 15:06:50 2010
Subject: [xmonad] Issue 374 in xmonad: WM keys don't work after exiting a
	GLUT game mode app
Message-ID: <0-3425899027203913298-4382401776772017079-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 374 by penma23: WM keys don't work after exiting a GLUT game mode  
app
http://code.google.com/p/xmonad/issues/detail?id=374

When exiting an application that uses the game mode of the GLUT library, no
WM keys work, until the mouse pointer is used to focus *some window* on the
screen, at which point all WM keys will work again.

This behaviour can not be observed in many other window managers (so far
tested: awesome, dwm, twm), so I believe this is a bug in xmonad.

Attached is a test program that enters game mode and exits upon keypress.
After exiting, WM keys will not work anymore.

Observed in at least 0.9.1, on Linux, using Xorg.


Attachments:
	glut-grab.c  960 bytes

--
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
From cjns1989 at gmail.com  Tue Feb 16 03:12:40 2010
From: cjns1989 at gmail.com (Chris Jones)
Date: Tue Feb 16 02:43:31 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS
	Small announce about the completion of the bluetile merge
In-Reply-To: <20100215183816.GA14081@smuckers>
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
	<20100212050605.GA9080@celeborn> <87sk96srrj.fsf@gmail.com>
	<20100215171144.GA3343@turki.gavron.org>
	<20100215183816.GA14081@smuckers>
Message-ID: <20100216081240.GG3343@turki.gavron.org>

On Mon, Feb 15, 2010 at 01:38:16PM EST, Adam Vogt wrote:
> * On Monday, February 15 2010, Chris Jones wrote:
> 
> >[..]
> >
> >Obviously not for me to have a say in this, but I'd much prefer folks
> >who have mastered this stuff wrote a detailed manual on xmonad
> >configuration.
> >
> >CJ
> 
> Hello Chris,

Hello Adam,

> What is missing from the present documentation that you would like to
> see in this detailed manual?

I think that if I was able to provide a useful answer to your question,
I should already be on my way to writing the manual. :-)

Seriously.. here's the context: 

Over the years, I have toned down my current window manager of choice's
functionalities to a barebones environment that does what I need and
nothing else.. namely:

1. provide multiple workspaces 

2. let me bind a few keyboard actions to launching frequently used
   applications, mainly 256-color xterms and differently configured
   instances of GNU screen

3. binding keys to navigating workspaces

Naturally, I wanted to do the same thing in xmonad, which once I had
tried it out of the box basically amounted to changing default workspace
navigation keybindings and adjusting the terminal definition.

One additional requirement, something I do not have in my current window
manager setup was to have xmonad display stuff I like to keep an eye on
at all times, such as CPU temperature, CPU%, mem%, swap%, network RX/TX,
as well as the current date and time and outside temperature as recorded
by my local weather station.

I was not planning on anything fancy, just numbers, pretty much what I
have implemented via short home-grown scripts in my current GNU/screen
environment, but with one important difference: 

With my current setup, each instance of GNU/screen runs separate
instances of my monitoring scripts, which is not optimal.

So my needs were very modest indeed, and after a bit of digging, some
copy-pasting and the usual trial and error cycles, I was able to pretty
much set up the above environment in xmonad without bothering anybody
here or on the IRC channel with questions you folks must have already
answered hundreds of times.

All the same, I have the following observations:

1. It would have been much better if I had been able to work with a
   document that walked me through the above configuration instead of
   having to dig for it in various places.

2. At this point, I have a file called xmonad.hs, that appears to do
   what I want, but since it was created by copy-pasting other users'
   configuration files, I have only a very vague idea how it does it. 

For instance, I have the following:

------------------------------------------------------------------------
import XMonad
import XMonad.Hooks.DynamicLog
import XMonad.Hooks.ManageDocks
import XMonad.Util.Run(spawnPipe)
import XMonad.Util.EZConfig(additionalKeys)
import System.IO
------------------------------------------------------------------------

What does this do? Why do I need it? Do I really need this? all of it?

And further down:

------------------------------------------------------------------------
main = do
    xmproc <- spawnPipe "/usr/bin/xmobar /home/me/.xmobarrc"
    xmonad $ defaultConfig
        { manageHook  = manageDocks <+> myManageHook 
                        <+> manageHook defaultConfig
...
------------------------------------------------------------------------

Same questions, basically.. And also what's a '$'.. what's a '<+>'..

Don't take me wrong, I am not being critical, I got xmonad to basically
do what I need with possibly less frustration than if I was configure
supposedly user-friendly desktops such as gnome, kde, etc. 

I was mainly wondering if it might be possible to have a document that
takes a user who has little or no programming experience, and no prior
knowledge of Haskell, just some fluency with an editor and the keyboard,
and make configuring xmonad a meaningful experience, giving said user at
least a general idea of what he is doing and why he needs to do it,
rather than giving him a feeling that he's taken a dive into a dark pit,
should count his blessings he's still alive but has come out none the
wiser. 

No question that there are probably other new users out there who might
want to set up something a bit more fun, with additional functionality,
and maybe some eye candy and bells and  whistles I have no use for. And
it's true that the FAQ in particular does at least partially answer
quite a few questions regarding individual practical aspects of the
configuration, but they are all pretty much in terms of "copy-paste" the
following two lines to xmonad.hs and hit mod+q.

I know too little to be in a position to answer the question: is it
possible to write such a document, and what would form it could take..
maybe it would turn out to be a short Haskell tutorial focusing on what
parts of the language are necessary to configure xmonad?

As stated before, I don't think a new user like me can speculate about
this but what I do see is that in this same thread, using somewhat
different terms, Ralph Hofmann, one other recent newcomer pretty much
felt the same about the current documentation, it's basically OK, "aber
etwas fehlt" (something is missing).

I do wish I could be a little more specific, but as hinted above, if I
could clearly identify what's missing, I probably have all the answers
already: I'm pretty much in the position of the caveman who vaguely
suspects that there ought to be a quicker better way to pay a visit to
his cousins in the neighboring valley than trudging barefoot through
mounds of snow, but unfortunately for him, it's another 30,000 years
before someone more knowledgeable decides it's time to invent the
snowmobile.

Thanks,

CJ



From gwern0 at gmail.com  Tue Feb 16 09:25:37 2010
From: gwern0 at gmail.com (Gwern Branwen)
Date: Tue Feb 16 08:56:28 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS 
	Small announce about the completion of the bluetile merge
In-Reply-To: <20100216081240.GG3343@turki.gavron.org>
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
	<20100212050605.GA9080@celeborn> <87sk96srrj.fsf@gmail.com>
	<20100215171144.GA3343@turki.gavron.org>
	<20100215183816.GA14081@smuckers>
	<20100216081240.GG3343@turki.gavron.org>
Message-ID: <cbf55b101002160625t54e7e361pab944c89acaea2c8@mail.gmail.com>

On Tue, Feb 16, 2010 at 3:12 AM, Chris Jones <cjns1989@gmail.com> wrote:
> On Mon, Feb 15, 2010 at 01:38:16PM EST, Adam Vogt wrote:
>> * On Monday, February 15 2010, Chris Jones wrote:
>>
>> >[..]
>> >
>> >Obviously not for me to have a say in this, but I'd much prefer folks
>> >who have mastered this stuff wrote a detailed manual on xmonad
>> >configuration.
>> >
>> >CJ
>>
>> Hello Chris,
>
> Hello Adam,
>
>> What is missing from the present documentation that you would like to
>> see in this detailed manual?
>
> I think that if I was able to provide a useful answer to your question,
> I should already be on my way to writing the manual. :-)
>
> Seriously.. here's the context:
>
> Over the years, I have toned down my current window manager of choice's
> functionalities to a barebones environment that does what I need and
> nothing else.. namely:
>
> 1. provide multiple workspaces
>
> 2. let me bind a few keyboard actions to launching frequently used
> ? applications, mainly 256-color xterms and differently configured
> ? instances of GNU screen
>
> 3. binding keys to navigating workspaces
>
> Naturally, I wanted to do the same thing in xmonad, which once I had
> tried it out of the box basically amounted to changing default workspace
> navigation keybindings and adjusting the terminal definition.
>
> One additional requirement, something I do not have in my current window
> manager setup was to have xmonad display stuff I like to keep an eye on
> at all times, such as CPU temperature, CPU%, mem%, swap%, network RX/TX,
> as well as the current date and time and outside temperature as recorded
> by my local weather station.
>
> I was not planning on anything fancy, just numbers, pretty much what I
> have implemented via short home-grown scripts in my current GNU/screen
> environment, but with one important difference:
>
> With my current setup, each instance of GNU/screen runs separate
> instances of my monitoring scripts, which is not optimal.
>
> So my needs were very modest indeed, and after a bit of digging, some
> copy-pasting and the usual trial and error cycles, I was able to pretty
> much set up the above environment in xmonad without bothering anybody
> here or on the IRC channel with questions you folks must have already
> answered hundreds of times.
>
> All the same, I have the following observations:
>
> 1. It would have been much better if I had been able to work with a
> ? document that walked me through the above configuration instead of
> ? having to dig for it in various places.
>
> 2. At this point, I have a file called xmonad.hs, that appears to do
> ? what I want, but since it was created by copy-pasting other users'
> ? configuration files, I have only a very vague idea how it does it.
>
> For instance, I have the following:
>
> ------------------------------------------------------------------------
> import XMonad
> import XMonad.Hooks.DynamicLog
> import XMonad.Hooks.ManageDocks
> import XMonad.Util.Run(spawnPipe)
> import XMonad.Util.EZConfig(additionalKeys)
> import System.IO
> ------------------------------------------------------------------------
>
> What does this do? Why do I need it? Do I really need this? all of it?
>
> And further down:
>
> ------------------------------------------------------------------------
> main = do
> ? ?xmproc <- spawnPipe "/usr/bin/xmobar /home/me/.xmobarrc"
> ? ?xmonad $ defaultConfig
> ? ? ? ?{ manageHook ?= manageDocks <+> myManageHook
> ? ? ? ? ? ? ? ? ? ? ? ?<+> manageHook defaultConfig
> ...
> ------------------------------------------------------------------------


Hold on. Didn't you earlier write that

> xmonad 0.8 as shipped by debian squeeze let me do everything I needed
without additional customization.

That seems like both customization & usage of -contrib modules (at
least 4 of them). What then did you mean earlier?

-- 
gwern
From sean at seanneilan.com  Tue Feb 16 15:55:11 2010
From: sean at seanneilan.com (Sean Neilan)
Date: Tue Feb 16 15:26:20 2010
Subject: [xmonad] xmonad stops responding even after removing loghook
	reference
Message-ID: <689a257a1002161255p1f90a347x6e7745f7faea80e0@mail.gmail.com>

Hey All,

My xmonad installation on Ubuntu 9.10 i386 stops responding after a while.
It's just like the faq entry here:
http://www.haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#XMonad_stops_but_the_current_window_still_responds_to_keys

I've commented out references to logHook in my xmonad config file
http://pastebin.com/f8622e8a

Still, the same error is happening.

Does anyone know if I'm doing something wrong?

Thank you for your time.

Sean Neilan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/xmonad/attachments/20100216/5aabe330/attachment.html
From cjns1989 at gmail.com  Tue Feb 16 17:31:31 2010
From: cjns1989 at gmail.com (Chris Jones)
Date: Tue Feb 16 17:02:25 2010
Subject: [xmonad] Splitting into xmonad-core/xmonad/xmonad-contrib; WAS
	Small announce about the completion of the bluetile merge
In-Reply-To: <cbf55b101002160625t54e7e361pab944c89acaea2c8@mail.gmail.com>
References: <cbf55b101002110939h2284194ar9939d1504db3592e@mail.gmail.com>
	<20100212050605.GA9080@celeborn> <87sk96srrj.fsf@gmail.com>
	<20100215171144.GA3343@turki.gavron.org>
	<20100215183816.GA14081@smuckers>
	<20100216081240.GG3343@turki.gavron.org>
	<cbf55b101002160625t54e7e361pab944c89acaea2c8@mail.gmail.com>
Message-ID: <20100216223131.GI3343@turki.gavron.org>

On Tue, Feb 16, 2010 at 09:25:37AM EST, Gwern Branwen wrote:
> On Tue, Feb 16, 2010 at 3:12 AM, Chris Jones <cjns1989@gmail.com> wrote:

[..]

> Hold on. Didn't you earlier write that
> 
> > xmonad 0.8 as shipped by debian squeeze let me do everything I needed
> without additional customization.

> That seems like both customization & usage of -contrib modules (at
> least 4 of them). What then did you mean earlier?

Yes, that was earlier. 

But then, I figured that creating an xmonad.hs file specifying a
terminal definition of 'xterm -tn xterm-256color' was cleaner than
adding setting/exporting the TERM environment variable in my
.bash_profile.

Likewise, as described in my previous message, I have written a few
short scripts that use GNU/screen's hard status line to display system
monitoring information, the current date/time & outside temperature. 

This works regardless of the window manager, but having xmobar display
the same data would be a better solution.

I did not have to do any of that to have a perfectly workable
environment. Just a couple of minor tweaks to improve on my current
setup was all I changed from the default configuration.

In other words, I reiterate that where I'm concerned:

"xmonad 0.8 as shipped by debian squeeze let me do everything I needed
 without additional customization."

Regarding "usage of -contrib modules.." I assume you mean the import
statements? 

As stated in my previous message, I have absolutely no clue what these
are for, what they do, whether I need them, and if so, why.. etc.

I believe I copy-pasted them from John Goertzen's excellent step by step
tutorial on how to integrate xmobar to xmonad. Since I have to boot to a
different partition/system to configure xmobar, and since everything was
working the way I wanted, I didn't look into these aspects further.

I am pretty sure I could remove most of the stuff in the configuration
file, but I have not been able to locate a detailed manual -- step by
step is another good way to put it -- that describes what exactly I am
supposed to do to configure xmonad.

Which was precisely the object of my previous message.

CJ
From vogt.adam at gmail.com  Tue Feb 16 21:32:44 2010
From: vogt.adam at gmail.com (Adam Vogt)
Date: Tue Feb 16 21:03:58 2010
Subject: [xmonad] xmonad stops responding even after removing loghook
	reference
In-Reply-To: <689a257a1002161255p1f90a347x6e7745f7faea80e0@mail.gmail.com>
References: <689a257a1002161255p1f90a347x6e7745f7faea80e0@mail.gmail.com>
Message-ID: <20100217023244.GA23390@smuckers.uwaterloo.ca>

Hi Sean,

This line which you didn't comment will cause xmonad to try to spawn a
dzen and write to that pipe (in addition to your usage of spawnPipe):

283.  Log.dzen $ \ defaultConfig -> xmonad $

Your problem might go away if you get rid of that too, or work out why
dzen isn't consuming it's stdin (because of missing fonts or whatever
that prevent it from running).

--
Adam

* On Tuesday, February 16 2010, Sean Neilan wrote:

>Hey All,
>
>My xmonad installation on Ubuntu 9.10 i386 stops responding after a while.
>It's just like the faq entry here:
>http://www.haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#XMonad_stops_but_the_current_window_still_responds_to_keys
>
>I've commented out references to logHook in my xmonad config file
>http://pastebin.com/f8622e8a
>
>Still, the same error is happening.
>
>Does anyone know if I'm doing something wrong?
>
>Thank you for your time.
>
>Sean Neilan

>_______________________________________________
>xmonad mailing list
>xmonad@haskell.org
>http://www.haskell.org/mailman/listinfo/xmonad

From sean at seanneilan.com  Tue Feb 16 22:49:15 2010
From: sean at seanneilan.com (Sean Neilan)
Date: Tue Feb 16 22:20:22 2010
Subject: [xmonad] xmonad stops responding even after removing loghook 
	reference
In-Reply-To: <20100217023244.GA23390@smuckers.uwaterloo.ca>
References: <689a257a1002161255p1f90a347x6e7745f7faea80e0@mail.gmail.com> 
	<20100217023244.GA23390@smuckers.uwaterloo.ca>
Message-ID: <689a257a1002161949g3515a7a4j939a710d9e9aa529@mail.gmail.com>

Got it. That fixed it! Thank you very much!

I had to comment the lines
main = do
  dzen2 <- spawnPipe ( "killall rundzen; rundzen --" ++ (join $ map (wrap
"-" "-") myWorkspaces))
  Log.dzen $ \ defaultConfig -> xmonad $
  defaultConfig -> xmonad $

and replace it with
main = xmonad defaults

and make
default = defaultConfig {
......
}
And of course left indent defaultConfig

I'm very new to haskell & xmonad. I inferred it from the default template
file. I appreciate your help a lot!

I will definitely be using xmonad & hope to make some extensions! Thanks
again!

-Sean

On Tue, Feb 16, 2010 at 8:32 PM, Adam Vogt <vogt.adam@gmail.com> wrote:

> Hi Sean,
>
> This line which you didn't comment will cause xmonad to try to spawn a
> dzen and write to that pipe (in addition to your usage of spawnPipe):
>
> 283.  Log.dzen $ \ defaultConfig -> xmonad $
>
> Your problem might go away if you get rid of that too, or work out why
> dzen isn't consuming it's stdin (because of missing fonts or whatever
> that prevent it from running).
>
> --
> Adam
>
> * On Tuesday, February 16 2010, Sean Neilan wrote:
>
> >Hey All,
> >
> >My xmonad installation on Ubuntu 9.10 i386 stops responding after a while.
> >It's just like the faq entry here:
> >
> http://www.haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#XMonad_stops_but_the_current_window_still_responds_to_keys
> >
> >I've commented out references to logHook in my xmonad config file
> >http://pastebin.com/f8622e8a
> >
> >Still, the same error is happening.
> >
> >Does anyone know if I'm doing something wrong?
> >
> >Thank you for your time.
> >
> >Sean Neilan
>
> >_______________________________________________
> >xmonad mailing list
> >xmonad@haskell.org
> >http://www.haskell.org/mailman/listinfo/xmonad
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/xmonad/attachments/20100216/c8433193/attachment-0001.html
From mr.progo at gmail.com  Wed Feb 17 10:59:48 2010
From: mr.progo at gmail.com (Mikael Puhakka)
Date: Wed Feb 17 10:30:36 2010
Subject: [xmonad] Layout.Gaps and PerScreen; is it going to happen?
In-Reply-To: <20100215135859.66357h3taeqnb7g0@webmail.seas.upenn.edu>
References: <d663d1bd1002151053q7e547416jeae7843d8b52c12f@mail.gmail.com>
	<20100215135859.66357h3taeqnb7g0@webmail.seas.upenn.edu>
Message-ID: <d663d1bd1002170759v6c0b7f75te5c9f9583cc99ed7@mail.gmail.com>

Hello,

I did manage to get Conky set its struts properly against the Google
consensus (I was going to reply yesterday to say that Conky can't
strut but they were all wrong;)

However, apparently Conky sets a wrong kind of attributes to its strut:

_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 201, 0, 0, 0, 0, 0, 0, 4032, 4239
_NET_WM_STRUT(CARDINAL) = 0, 0, 0, 201

Graphically presented, this picture represents a "Full" layout with a
black terminal, red conky and white is unused background:

http://havu.viuhka.fi/kuvat/xmonad_layout_struts.png

I would very much like to have the unused strut space on the right
side all the way to the top. This way Rainlendar could sneak in
without strutting also.

I just wonder if the issue here is caused by conky (the above WM_STRUT
records indicate so, if I am reading it correctly) or avoidStruts. I
did try the more specific avoidStrutsOn [R] but it didn't do anything
besides the basic operations a plain "avoidStruts" does.

Enlighten me, o mighty one.
--Mikael

On Mon, Feb 15, 2010 at 20:58,  <wagnerdm@seas.upenn.edu> wrote:
> If conky and rainlendar set their struts properly, you should be able to get
> by with manageDocks/avoidStruts. Documentation:
> http://www.xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-ManageDocks.html
>
> ~d
>
> Quoting Mikael Puhakka <mr.progo@gmail.com>:
>
>> Dear Xmonad community,
>>
>> I've recently switched to Xmonad from a 3-year relationship with
>> Fluxbox and just after 4-5 days of daily using I am beginning to love
>> this thing very passionately.
>>
>> However, the old habits die hard and I don't even want to let go of
>> every of them. Some vices of mine include a small Conky instance in a
>> corner, a pseudo-transparent xterm tail -f :ing /var/log/messages with
>> semi-hourly fortunes, and a Rainlendar the flashy calendar
>> application.
>>
>> The "tail -f" monitor behind stuff in tiled environments such as this
>> doesn't make much sense but I rather wouldn't part from the other two.
>> Basically the subject says it all; I wonder if there is a working Gap
>> modifier that would work on one screen only (I have currently a
>> tri-head xinerama setup). I googled through the mailing lists and
>> since 2008 there has been no fuzz about it.
>>
>> Am I left with a hack like a gapped layout to be used with one screen
>> only, or is there a better solution for this? These applications don't
>> do well with Layout.Monitor or alike. As a lazy workaround I've been
>> using "Circle" layout for that particular screen and workspace (it's
>> surprisingly handy and not just an eye toy).
>>
>> TIA,
>> Mikael
>> _______________________________________________
>> xmonad mailing list
>> xmonad@haskell.org
>> http://www.haskell.org/mailman/listinfo/xmonad
>>
>>
>
>
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
From kweidner at pobox.com  Wed Feb 17 13:51:33 2010
From: kweidner at pobox.com (Klaus Weidner)
Date: Wed Feb 17 13:22:20 2010
Subject: [xmonad] Several new modules (patch flood)
In-Reply-To: <70d6e6e41001190945g635e678ayfa145a1160bfcc8a@mail.gmail.com>
References: <70d6e6e41001161810oeae40fy596be3ba51ed9711@mail.gmail.com>
	<20100117022056.GA2295@whirlpool.galois.com>
	<70d6e6e41001190945g635e678ayfa145a1160bfcc8a@mail.gmail.com>
Message-ID: <3b67b7d31002171051k344a0cecmf07a3ae1a018b1ae@mail.gmail.com>

I had been trying something similar, here's the config I've been using
for a while that combines tiled and tabbed layouts. I haven't split
this out into a separate file, so it's unfortunately mixed up with my
other customizations :-/

More details (and crude ASCII graphics) are in the file.

-Klaus

On Tue, Jan 19, 2010 at 9:45 AM, Quentin Moser <moserq@gmail.com> wrote:
> I just discovered Adam Vogt's XMonad.Layout.SubLayouts module, which
> seems to do pretty much exactly the same thing as my
> XMonad.Layout.Groups module. I _did_ spend several dozen minutes
> looking through the xmonad-comtrib modules to see if no-one had
> implemented this before, but I missed it (of course, there's no way a
> mere hour could be enough to find a module in xmonad-contrib >>). Big
> "doh" moment.
>
> Anyway, I'm planning on taking a serious look at SubLayouts, seeing in
> what ways it differs from my own module, and posting an update once
> I've figured things out; these two modules are definitely too similar
> for one not to absorb the other.
>
> If Adam has comments to make about this, I'm also all ears.
>
> For now, my patches can definitely be merged, but X.L.Groups should be
> considered an unstable interface. The rest won't change even if I move
> to X.L.SubLayouts (well, except that X.L.Groups.Examples might get a
> name change).
>
> Q. Moser
>
> On Sun, Jan 17, 2010 at 3:20 AM, Don Stewart <dons@galois.com> wrote:
>> Well done!!
>>
>> moserq:
>>> Hello XMonad,
>>>
>>>
>>> I apologize for the bulk delivery, these are all things I wrote over
>>> the last week and I didn't really want
>>> to stop coding to send updates (or eat, or sleep, for that matter --).
>>
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmonad.hs
Type: text/x-haskell
Size: 10431 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/xmonad/attachments/20100217/8a4c7419/xmonad.bin
From cjns1989 at gmail.com  Thu Feb 18 20:28:44 2010
From: cjns1989 at gmail.com (Chris Jones)
Date: Thu Feb 18 19:59:33 2010
Subject: [xmonad] Copy/paste via keyboard
In-Reply-To: <20100215172831.GB3343@turki.gavron.org>
References: <20100215172831.GB3343@turki.gavron.org>
Message-ID: <20100219012844.GD9995@turki.gavron.org>

Any thoughts?

Thanks,

CJ
From sean at seanneilan.com  Thu Feb 18 20:38:15 2010
From: sean at seanneilan.com (Sean Neilan)
Date: Thu Feb 18 20:09:03 2010
Subject: [xmonad] Copy/paste via keyboard
In-Reply-To: <20100219012844.GD9995@turki.gavron.org>
References: <20100215172831.GB3343@turki.gavron.org>
	<20100219012844.GD9995@turki.gavron.org>
Message-ID: <2988625015619074192@unknownmsgid>

Control c, control v. Vim is +gP for paste and something else for copy.

Unless your trying to also select using the mouse too.

-Sean
sean@seanneilan.com

On Feb 18, 2010, at 7:28 PM, Chris Jones <cjns1989@gmail.com> wrote:

> Any thoughts?
>
> Thanks,
>
> CJ
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
From cjns1989 at gmail.com  Thu Feb 18 21:36:32 2010
From: cjns1989 at gmail.com (Chris Jones)
Date: Thu Feb 18 21:07:14 2010
Subject: [xmonad] Copy/paste via keyboard
In-Reply-To: <2988625015619074192@unknownmsgid>
References: <20100215172831.GB3343@turki.gavron.org>
	<20100219012844.GD9995@turki.gavron.org>
	<2988625015619074192@unknownmsgid>
Message-ID: <20100219023632.GE9995@turki.gavron.org>

On Thu, Feb 18, 2010 at 08:38:15PM EST, Sean Neilan wrote:
> Control c, control v. Vim is +gP for paste and something else for copy.

I should use  Control+C to copy and Control_V to paste.. ??

How do I select what I'm copying?

> Unless your trying to also select using the mouse too.

As the "Subject:" of this post specified, I'm talking about "Copy/paste
via keyboard".

I'm not sure what you mean by "using the mouse too"..???

Thank you for your comments.

CJ
From ivan.miljenovic at gmail.com  Thu Feb 18 21:46:05 2010
From: ivan.miljenovic at gmail.com (Ivan Miljenovic)
Date: Thu Feb 18 21:16:46 2010
Subject: [xmonad] Copy/paste via keyboard
In-Reply-To: <20100219023632.GE9995@turki.gavron.org>
References: <20100215172831.GB3343@turki.gavron.org>
	<20100219012844.GD9995@turki.gavron.org>
	<2988625015619074192@unknownmsgid>
	<20100219023632.GE9995@turki.gavron.org>
Message-ID: <ccd8be491002181846q647cfefcud4ae03fdb7337ba8@mail.gmail.com>

In which applications are you actually wanting to copy/paste?

If you mean in the terminal, that depends on which terminal you're
referring to.  However, shift-insert seems to normally paste and you can
use applications like xsel to copy output.

Realistically, this kind of stuff is program-specific and nothing to do
with xmonad.

As a guess, GNU screen allows you to copy/paste because it has tighter
control of the terminals involved.

On 19 February 2010 13:36, Chris Jones <cjns1989@gmail.com> wrote:
> On Thu, Feb 18, 2010 at 08:38:15PM EST, Sean Neilan wrote:
>> Control c, control v. Vim is +gP for paste and something else for copy.
>
> I should use ?Control+C to copy and Control_V to paste.. ??
>
> How do I select what I'm copying?
>
>> Unless your trying to also select using the mouse too.
>
> As the "Subject:" of this post specified, I'm talking about "Copy/paste
> via keyboard".
>
> I'm not sure what you mean by "using the mouse too"..???
>
> Thank you for your comments.
>
> CJ
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>



-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
IvanMiljenovic.wordpress.com
Samuel Goldwyn  - "I'm willing to admit that I may not always be
right, but I am never wrong." -
http://www.brainyquote.com/quotes/authors/s/samuel_goldwyn.html
From wagnerdm at seas.upenn.edu  Thu Feb 18 22:10:56 2010
From: wagnerdm at seas.upenn.edu (wagnerdm@seas.upenn.edu)
Date: Thu Feb 18 21:41:44 2010
Subject: [xmonad] Copy/paste via keyboard
In-Reply-To: <ccd8be491002181846q647cfefcud4ae03fdb7337ba8@mail.gmail.com>
References: <20100215172831.GB3343@turki.gavron.org>
	<20100219012844.GD9995@turki.gavron.org>
	<2988625015619074192@unknownmsgid>
	<20100219023632.GE9995@turki.gavron.org>
	<ccd8be491002181846q647cfefcud4ae03fdb7337ba8@mail.gmail.com>
Message-ID: <20100218221056.14274c9fbuhcfwao@webmail.seas.upenn.edu>

Quoting Ivan Miljenovic <ivan.miljenovic@gmail.com>:

> Realistically, this kind of stuff is program-specific and nothing to do
> with xmonad.

I tend to agree. Firefox has caret browsing [1], OpenOffice (and other  
word processors) have shift+movements, vim/emacs have selection modes,  
there's xsel/xclip for copying files or command output in a terminal,  
etc.

Nevertheless, there are kludges for moving the mouse pointer with the  
keyboard. You may be interested in one of [2] or [3], for example. I  
know there is a program out there as well for moving the mouse by  
cutting the screen into 4 (9?) pieces, then cutting one of those  
pieces into 4, and so on until you've got to a single pixel (or a  
small enough region that anywhere in there will do). You may find it  
with Google, or perhaps somebody else on this list uses it and can  
point you to its name.

Cheers,
~d

[1] http://brajeshwar.com/2006/turning-on-caret-browsing-in-firefox/
[2] http://www.tuxfiles.org/linuxhelp/movecursor.html
[3] http://hg.suckless.org/swarp/
From cjns1989 at gmail.com  Thu Feb 18 22:59:05 2010
From: cjns1989 at gmail.com (Chris Jones)
Date: Thu Feb 18 22:29:46 2010
Subject: [xmonad] Copy/paste via keyboard
In-Reply-To: <ccd8be491002181846q647cfefcud4ae03fdb7337ba8@mail.gmail.com>
References: <20100215172831.GB3343@turki.gavron.org>
	<20100219012844.GD9995@turki.gavron.org>
	<2988625015619074192@unknownmsgid>
	<20100219023632.GE9995@turki.gavron.org>
	<ccd8be491002181846q647cfefcud4ae03fdb7337ba8@mail.gmail.com>
Message-ID: <20100219035905.GF9995@turki.gavron.org>

On Thu, Feb 18, 2010 at 09:46:05PM EST, Ivan Miljenovic wrote:
> In which applications are you actually wanting to copy/paste?

All/Any.

> If you mean in the terminal, 

Which "terminal"?

> that depends on which terminal you're referring to.  However,
> shift-insert seems to normally paste and you can use applications like
> xsel to copy output.

Still does not tell me how I should _SELECT_ whatever I need to copy &
paste.

> Realistically, this kind of stuff is program-specific and nothing to do
> with xmonad.

So what do I do when I want to copy-paste between between application A
and application B..? 

Do I use application A's specs or application B's..?

See my point?

> As a guess, GNU screen allows you to copy/paste because it has tighter
> control of the terminals involved.

That I know.

Basically, you're confirming that xmonad does not provide a generic
keyboard-driven copy-paste mechanism.

But since no window manager that I know of provides this feature, maybe
the flaw is in X's design and xmonad is not to blame.

Hehe.. Not sure if I'm the duchess or the dormouse any more.

Thank you for your comments.

CJ
From ivan.miljenovic at gmail.com  Thu Feb 18 23:12:31 2010
From: ivan.miljenovic at gmail.com (Ivan Miljenovic)
Date: Thu Feb 18 22:43:13 2010
Subject: [xmonad] Copy/paste via keyboard
In-Reply-To: <20100219035905.GF9995@turki.gavron.org>
References: <20100215172831.GB3343@turki.gavron.org>
	<20100219012844.GD9995@turki.gavron.org>
	<2988625015619074192@unknownmsgid>
	<20100219023632.GE9995@turki.gavron.org>
	<ccd8be491002181846q647cfefcud4ae03fdb7337ba8@mail.gmail.com>
	<20100219035905.GF9995@turki.gavron.org>
Message-ID: <ccd8be491002182012m224c778ekc6691ccafd4cd16@mail.gmail.com>

On 19 February 2010 14:59, Chris Jones <cjns1989@gmail.com> wrote:
> On Thu, Feb 18, 2010 at 09:46:05PM EST, Ivan Miljenovic wrote:
>> In which applications are you actually wanting to copy/paste?
>
> All/Any.

Right, there's no real generic way of doing things that I know of.

>> If you mean in the terminal,
>
> Which "terminal"?

xterm, konsole, urxvt, etc.  Whichever one you use.

>> that depends on which terminal you're referring to. ?However,
>> shift-insert seems to normally paste and you can use applications like
>> xsel to copy output.
>
> Still does not tell me how I should _SELECT_ whatever I need to copy &
> paste.

With a mouse or one of the programs mentioned earlier in this thread
that allows for keyboard control of the pointer.

>> Realistically, this kind of stuff is program-specific and nothing to do
>> with xmonad.
>
> So what do I do when I want to copy-paste between between application A
> and application B..?

Copy using program A and paste into program B.

> Basically, you're confirming that xmonad does not provide a generic
> keyboard-driven copy-paste mechanism.

Exactly.

> But since no window manager that I know of provides this feature, maybe
> the flaw is in X's design and xmonad is not to blame.

I would argue that it isn't part of the WM's job to do it (after all,
the M is for Manage).  Does any other WM (or even a DE) have this
sense of universal copy/paste?

> Hehe.. Not sure if I'm the duchess or the dormouse any more.

Not sure if I get your reference...

> Thank you for your comments.

Comments are (currently) free; helpful advice is extra :p

-- 
Ivan Lazar Miljenovic
Ivan.Miljenovic@gmail.com
IvanMiljenovic.wordpress.com
Marie von Ebner-Eschenbach  - "Even a stopped clock is right twice a
day." - http://www.brainyquote.com/quotes/authors/m/marie_von_ebnereschenbac.html
From Julien.Steinhauser at orange.fr  Fri Feb 19 05:28:00 2010
From: Julien.Steinhauser at orange.fr (julien steinhauser)
Date: Fri Feb 19 04:57:53 2010
Subject: [xmonad] Copy/paste via keyboard
In-Reply-To: <20100219035905.GF9995@turki.gavron.org>
References: <20100215172831.GB3343@turki.gavron.org>
	<20100219012844.GD9995@turki.gavron.org>
	<2988625015619074192@unknownmsgid>
	<20100219023632.GE9995@turki.gavron.org>
	<ccd8be491002181846q647cfefcud4ae03fdb7337ba8@mail.gmail.com>
	<20100219035905.GF9995@turki.gavron.org>
Message-ID: <20100219102800.GB4862@eol.dynalias.org>

On Thu, Feb 18, 2010 at 10:59:05PM -0500, Chris Jones wrote:
> 
> On Thu, Feb 18, 2010 at 09:46:05PM EST, Ivan Miljenovic wrote:
> > In which applications are you actually wanting to copy/paste?
> 
> All/Any.
> 
> > If you mean in the terminal, 
> 
> Which "terminal"?
> 
> > that depends on which terminal you're referring to.  However,
> > shift-insert seems to normally paste and you can use applications like
> > xsel to copy output.
> 
> Still does not tell me how I should _SELECT_ whatever I need to copy &
> paste.
> 
> > Realistically, this kind of stuff is program-specific and nothing to do
> > with xmonad.
> 
As others said, it depends on the program.
With gtk apps like web browsers, you can use shift-ctrl-arrows
to select with keyboard, but actually, selecting on gtk apps
is one of the only things i find easier and quicker to do with a mouse.

I guess the keyboard selecting feature is already implemented
 in your text editor. :)

You could also use view instead of less as a viewer.


From thomas at xteddy.org  Fri Feb 19 06:23:09 2010
From: thomas at xteddy.org (Thomas Adam)
Date: Fri Feb 19 05:54:10 2010
Subject: [xmonad] Copy/paste via keyboard
In-Reply-To: <20100219035905.GF9995@turki.gavron.org>
References: <20100215172831.GB3343@turki.gavron.org>
	<20100219012844.GD9995@turki.gavron.org> 
	<2988625015619074192@unknownmsgid>
	<20100219023632.GE9995@turki.gavron.org> 
	<ccd8be491002181846q647cfefcud4ae03fdb7337ba8@mail.gmail.com> 
	<20100219035905.GF9995@turki.gavron.org>
Message-ID: <18071eea1002190323r41367727u848031d441c25beb@mail.gmail.com>

On 19 February 2010 03:59, Chris Jones <cjns1989@gmail.com> wrote:
> Do I use application A's specs or application B's..?
>
> See my point?

I think you should look at a program called "parcellite".

-- Thomas Adam
From byorgey at seas.upenn.edu  Sat Feb 20 11:34:46 2010
From: byorgey at seas.upenn.edu (Brent Yorgey)
Date: Sat Feb 20 11:05:22 2010
Subject: [xmonad] Copy/paste via keyboard
In-Reply-To: <20100218221056.14274c9fbuhcfwao@webmail.seas.upenn.edu>
References: <20100215172831.GB3343@turki.gavron.org>
	<20100219012844.GD9995@turki.gavron.org>
	<2988625015619074192@unknownmsgid>
	<20100219023632.GE9995@turki.gavron.org>
	<ccd8be491002181846q647cfefcud4ae03fdb7337ba8@mail.gmail.com>
	<20100218221056.14274c9fbuhcfwao@webmail.seas.upenn.edu>
Message-ID: <20100220163445.GA30450@seas.upenn.edu>

On Thu, Feb 18, 2010 at 10:10:56PM -0500, wagnerdm@seas.upenn.edu wrote:
> I know 
> there is a program out there as well for moving the mouse by cutting the 
> screen into 4 (9?) pieces, then cutting one of those pieces into 4, and so 
> on until you've got to a single pixel (or a small enough region that 
> anywhere in there will do). You may find it with Google, or perhaps 
> somebody else on this list uses it and can point you to its name.

That would be keynav.

-Brent
From mr.progo at gmail.com  Sat Feb 20 11:46:51 2010
From: mr.progo at gmail.com (Mikael Puhakka)
Date: Sat Feb 20 11:17:29 2010
Subject: [xmonad] Layout.Gaps and PerScreen; is it going to happen?
In-Reply-To: <d663d1bd1002170759v6c0b7f75te5c9f9583cc99ed7@mail.gmail.com>
References: <d663d1bd1002151053q7e547416jeae7843d8b52c12f@mail.gmail.com>
	<20100215135859.66357h3taeqnb7g0@webmail.seas.upenn.edu>
	<d663d1bd1002170759v6c0b7f75te5c9f9583cc99ed7@mail.gmail.com>
Message-ID: <d663d1bd1002200846l3aee7114o2ded495309731037@mail.gmail.com>

Hello,
I wanted to chime in and state that the issue isn't with xmonad at
all. Now that I had time, I checked out the xprop outputs and how
conky calculates it. With an older version of 1.80 it looks like a
design decision to define struts to "bottom" when user chooses to
place conky to "bottom right" corner.

Enough of offtopic, I wanted also to say that Xmonad really tickles my
needs. I honestly thought I couldn't move on from Fluxbox as I was
very customed to the traditional layered windowing with mildly useful
tabs along with it. Like in dwm, hardcoded settings  are something
magical and surprisingly handy.

-- Mikael

On Wed, Feb 17, 2010 at 17:59, Mikael Puhakka <mr.progo@gmail.com> wrote:
> Hello,
>
> I did manage to get Conky set its struts properly against the Google
> consensus (I was going to reply yesterday to say that Conky can't
> strut but they were all wrong;)
>
> However, apparently Conky sets a wrong kind of attributes to its strut:
>
> _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 201, 0, 0, 0, 0, 0, 0, 4032, 4239
> _NET_WM_STRUT(CARDINAL) = 0, 0, 0, 201
>
> Graphically presented, this picture represents a "Full" layout with a
> black terminal, red conky and white is unused background:
>
> http://havu.viuhka.fi/kuvat/xmonad_layout_struts.png
>
> I would very much like to have the unused strut space on the right
> side all the way to the top. This way Rainlendar could sneak in
> without strutting also.
>
> I just wonder if the issue here is caused by conky (the above WM_STRUT
> records indicate so, if I am reading it correctly) or avoidStruts. I
> did try the more specific avoidStrutsOn [R] but it didn't do anything
> besides the basic operations a plain "avoidStruts" does.
>
> Enlighten me, o mighty one.
> --Mikael
>
> On Mon, Feb 15, 2010 at 20:58, ?<wagnerdm@seas.upenn.edu> wrote:
>> If conky and rainlendar set their struts properly, you should be able to get
>> by with manageDocks/avoidStruts. Documentation:
>> http://www.xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-ManageDocks.html
>>
>> ~d
>>
>> Quoting Mikael Puhakka <mr.progo@gmail.com>:
>>
>>> Dear Xmonad community,
>>>
>>> I've recently switched to Xmonad from a 3-year relationship with
>>> Fluxbox and just after 4-5 days of daily using I am beginning to love
>>> this thing very passionately.
>>>
>>> However, the old habits die hard and I don't even want to let go of
>>> every of them. Some vices of mine include a small Conky instance in a
>>> corner, a pseudo-transparent xterm tail -f :ing /var/log/messages with
>>> semi-hourly fortunes, and a Rainlendar the flashy calendar
>>> application.
>>>
>>> The "tail -f" monitor behind stuff in tiled environments such as this
>>> doesn't make much sense but I rather wouldn't part from the other two.
>>> Basically the subject says it all; I wonder if there is a working Gap
>>> modifier that would work on one screen only (I have currently a
>>> tri-head xinerama setup). I googled through the mailing lists and
>>> since 2008 there has been no fuzz about it.
>>>
>>> Am I left with a hack like a gapped layout to be used with one screen
>>> only, or is there a better solution for this? These applications don't
>>> do well with Layout.Monitor or alike. As a lazy workaround I've been
>>> using "Circle" layout for that particular screen and workspace (it's
>>> surprisingly handy and not just an eye toy).
>>>
>>> TIA,
>>> Mikael
>>> _______________________________________________
>>> xmonad mailing list
>>> xmonad@haskell.org
>>> http://www.haskell.org/mailman/listinfo/xmonad
>>>
>>>
>>
>>
>> _______________________________________________
>> xmonad mailing list
>> xmonad@haskell.org
>> http://www.haskell.org/mailman/listinfo/xmonad
>>
>
From codesite-noreply at google.com  Sat Feb 20 15:07:29 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Sat Feb 20 14:38:06 2010
Subject: [xmonad] Issue 375 in xmonad: keysResizeWindow doesn't always work
Message-ID: <0-3425899027203913298-14907461048215614562-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 375 by wei.hoo: keysResizeWindow doesn't always work
http://code.google.com/p/xmonad/issues/detail?id=375

It seems that scaling a window down always work, but scaling up often
fails. Here's my relevant keybinding:
        , ("M-<KP_Left>", withFocused (keysResizeWindow (-10, 0) (1%2,
1%2)))
        , ("M-<KP_Right>", withFocused (keysResizeWindow (10, 0) (1%2,
1%2)))
        , ("M-<KP_Up>", withFocused (keysResizeWindow (0, 10) (1%2,
1%2)))
        , ("M-<KP_Down>", withFocused (keysResizeWindow (0, -10) (1%2,
1%2)))

I tested the operations on Google Chrome, Emacs, and urxvt:
All four work on Chrome.
M-U and M-R fail on urxvt; M-L and M-D work.
M-U fail on Emacs; others work.

What version of the product are you using? On what operating system?
Darcs. Arch.

Are you using an xmonad.hs?  Please attach it and the output of
"xmonad
--recompile".

Please provide any additional information below.


Attachments:
	xmonad.hs  9.1 KB

--
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
From sean at seanneilan.com  Sat Feb 20 22:04:25 2010
From: sean at seanneilan.com (Sean Neilan)
Date: Sat Feb 20 21:35:23 2010
Subject: [xmonad] increase size of font on terminal
Message-ID: <689a257a1002201904k33998cf8y8d4d4a4446538a88@mail.gmail.com>

Hey All,

Does anyone know how to increase the font size on the terminal that comes
with xmonad? You know, the one for when you press Alt-Shift-Enter.

Thank you very much for your time.

-Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/xmonad/attachments/20100220/ce6a2b58/attachment-0001.html
From korpios at korpios.com  Sat Feb 20 22:34:54 2010
From: korpios at korpios.com (Tom Tobin)
Date: Sat Feb 20 22:05:29 2010
Subject: [xmonad] increase size of font on terminal
In-Reply-To: <689a257a1002201904k33998cf8y8d4d4a4446538a88@mail.gmail.com>
References: <689a257a1002201904k33998cf8y8d4d4a4446538a88@mail.gmail.com>
Message-ID: <bf0b20a91002201934x5fbc731av56e97cca019321a8@mail.gmail.com>

On Sat, Feb 20, 2010 at 9:04 PM, Sean Neilan <sean@seanneilan.com> wrote:
> Hey All,
> Does anyone know how to increase the font size on the terminal that comes
> with xmonad? You know, the one for when you press Alt-Shift-Enter.

That terminal doesn't come with xmonad; it's xterm [1].

A lot depends on your particular system, but you can try adding the
following to your ~/.Xresources file:

xterm*faceSize: 14

The next xterm you open will hopefully be at a larger size.  Xterm
configuration is unfortunately a somewhat involved topic, though, and
probably beyond the scope of this group.

[1] http://en.wikipedia.org/wiki/Xterm
From sean at seanneilan.com  Sat Feb 20 23:00:09 2010
From: sean at seanneilan.com (Sean Neilan)
Date: Sat Feb 20 22:31:04 2010
Subject: [xmonad] increase size of font on terminal
In-Reply-To: <bf0b20a91002201934x5fbc731av56e97cca019321a8@mail.gmail.com>
References: <689a257a1002201904k33998cf8y8d4d4a4446538a88@mail.gmail.com> 
	<bf0b20a91002201934x5fbc731av56e97cca019321a8@mail.gmail.com>
Message-ID: <689a257a1002202000q654cbff9obfc83a17818ea809@mail.gmail.com>

Got it. I didn't know xmonad used xterm. That makes this much easier.

Thank you very much!

On Sat, Feb 20, 2010 at 9:34 PM, Tom Tobin <korpios@korpios.com> wrote:

> On Sat, Feb 20, 2010 at 9:04 PM, Sean Neilan <sean@seanneilan.com> wrote:
> > Hey All,
> > Does anyone know how to increase the font size on the terminal that comes
> > with xmonad? You know, the one for when you press Alt-Shift-Enter.
>
> That terminal doesn't come with xmonad; it's xterm [1].
>
> A lot depends on your particular system, but you can try adding the
> following to your ~/.Xresources file:
>
> xterm*faceSize: 14
>
> The next xterm you open will hopefully be at a larger size.  Xterm
> configuration is unfortunately a somewhat involved topic, though, and
> probably beyond the scope of this group.
>
> [1] http://en.wikipedia.org/wiki/Xterm
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/xmonad/attachments/20100220/916de2ea/attachment.html
From zao at acc.umu.se  Sat Feb 20 23:17:02 2010
From: zao at acc.umu.se (Lars Viklund)
Date: Sat Feb 20 22:47:39 2010
Subject: [xmonad] increase size of font on terminal
In-Reply-To: <689a257a1002202000q654cbff9obfc83a17818ea809@mail.gmail.com>
References: <689a257a1002201904k33998cf8y8d4d4a4446538a88@mail.gmail.com>
	<bf0b20a91002201934x5fbc731av56e97cca019321a8@mail.gmail.com>
	<689a257a1002202000q654cbff9obfc83a17818ea809@mail.gmail.com>
Message-ID: <20100221041658.GA27640@hatchepsut.acc.umu.se>

On Sat, Feb 20, 2010 at 10:00:09PM -0600, Sean Neilan wrote:
> Got it. I didn't know xmonad used xterm. That makes this much easier.

It uses whatever you specify in your ~/xmonad/xmonad.hs.

If you haven't created one and overridden it, the default is xterm, as
can be seen in Config.hs in the xmonad source.

If you had changed it to say gnome-terminal, Terminal or konsole, you
could use their specific keys to adjust their fonts and whatnot.

-- 
Lars Viklund | zao@acc.umu.se
From damian.only at gmail.com  Sun Feb 21 09:40:31 2010
From: damian.only at gmail.com (Damian)
Date: Sun Feb 21 09:11:25 2010
Subject: [xmonad] Xmonad, beagle-search, and mime types
Message-ID: <47a330c51002210640y156853daw92358e73ffe9807d@mail.gmail.com>

Hello,

I don't consider myself a smart person. Even my mom used to say that I
wasn't so bright. But still, should this be so damn difficult?

'beagle-search' is a front end for the beagle desktop search engine.
When you issue a query, the application shows you icons (which
represent files) with the result of the query. If you click on the
icon, the file will be opened with the default application. The
problem is that I cannot set the default application by any means. For
instance I would like to open jpeg image files using geeqie.

I've failed miserably in trying to associate filetypes to
applications, using beagle search. The application beagle-search uses
xdg-open to open applications. If a filetype has no application
associated, then the default handler is firefox (don't ask me why).

So I tried to see how xdg-open works, but the man page didn't give me
any useful information. The related command, xdg-mime, doesn't work as
I expected.

I've created a file called geeqie.desktop in the directory
/home/damian/.local/share/applications with the following contents:
  [Desktop Entry]
  Encoding=UTF-8
  Name=Geeqie
  Exec=geeqie
  MimeType=image/jpeg
  Icon=exec
  NoDisplay=true

Then I've tried to associate geeqie with jpeg files by running:
    xdg-mime default geeqie.desktop image/jpeg

The command terminates successfully, and after running
    xdg-mime query default image/jpeg
I get as output "geeqie.desktop".

But xdg-open (and therefore beagle-search) still refuses to open jpeg
images with geeqie.

Any ideas?

Thanks in advance.
From wagnerdm at seas.upenn.edu  Sun Feb 21 12:33:33 2010
From: wagnerdm at seas.upenn.edu (wagnerdm@seas.upenn.edu)
Date: Sun Feb 21 12:04:12 2010
Subject: [xmonad] Xmonad, beagle-search, and mime types
In-Reply-To: <47a330c51002210640y156853daw92358e73ffe9807d@mail.gmail.com>
References: <47a330c51002210640y156853daw92358e73ffe9807d@mail.gmail.com>
Message-ID: <20100221123333.6068456987u21oys@webmail.seas.upenn.edu>

I've been fighting with xdg-open myself, having just switched to  
chromium. It turns out it's a pretty readable shell script (open it up  
in your favorite editor and have a look!). Here's approximately what  
it does:

* is there a KDE session running? use kde-open, fall back to kfmclient
* is there a Gnome session running? use gvfs-open, fall back to gnome-open
* is there an XFCE session running? use exo-open
* try, in order: mimeopen, run-mailcap, $BROWSER, firefox, mozilla, netscape

So, probably what's happening to you is that you aren't running KDE,  
Gnome, or XFCE, you don't have mimeopen or run-mailcap installed, and  
you haven't set $BROWSER.

I export BROWSER=gnome-open and love it, but old versions do have a  
bug where gnome-open totally ignores  
.local/share/applications/defaults.list, so make sure to update  
gnome-open!

Good luck,
~d

Quoting Damian <damian.only@gmail.com>:

> Hello,
>
> I don't consider myself a smart person. Even my mom used to say that I
> wasn't so bright. But still, should this be so damn difficult?
>
> 'beagle-search' is a front end for the beagle desktop search engine.
> When you issue a query, the application shows you icons (which
> represent files) with the result of the query. If you click on the
> icon, the file will be opened with the default application. The
> problem is that I cannot set the default application by any means. For
> instance I would like to open jpeg image files using geeqie.
>
> I've failed miserably in trying to associate filetypes to
> applications, using beagle search. The application beagle-search uses
> xdg-open to open applications. If a filetype has no application
> associated, then the default handler is firefox (don't ask me why).
>
> So I tried to see how xdg-open works, but the man page didn't give me
> any useful information. The related command, xdg-mime, doesn't work as
> I expected.
>
> I've created a file called geeqie.desktop in the directory
> /home/damian/.local/share/applications with the following contents:
>   [Desktop Entry]
>   Encoding=UTF-8
>   Name=Geeqie
>   Exec=geeqie
>   MimeType=image/jpeg
>   Icon=exec
>   NoDisplay=true
>
> Then I've tried to associate geeqie with jpeg files by running:
>     xdg-mime default geeqie.desktop image/jpeg
>
> The command terminates successfully, and after running
>     xdg-mime query default image/jpeg
> I get as output "geeqie.desktop".
>
> But xdg-open (and therefore beagle-search) still refuses to open jpeg
> images with geeqie.
>
> Any ideas?
>
> Thanks in advance.
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
>


From damian.only at gmail.com  Sun Feb 21 14:14:47 2010
From: damian.only at gmail.com (Damian)
Date: Sun Feb 21 13:45:46 2010
Subject: [xmonad] Xmonad, beagle-search, and mime types
In-Reply-To: <20100221123333.6068456987u21oys@webmail.seas.upenn.edu>
References: <47a330c51002210640y156853daw92358e73ffe9807d@mail.gmail.com> 
	<20100221123333.6068456987u21oys@webmail.seas.upenn.edu>
Message-ID: <47a330c51002211114l49beb4b5q401777941094722c@mail.gmail.com>

On Sun, Feb 21, 2010 at 6:33 PM,  <wagnerdm@seas.upenn.edu> wrote:
> I've been fighting with xdg-open myself, having just switched to chromium.
> It turns out it's a pretty readable shell script (open it up in your
> favorite editor and have a look!). Here's approximately what it does:
>
> * is there a KDE session running? use kde-open, fall back to kfmclient
> * is there a Gnome session running? use gvfs-open, fall back to gnome-open
> * is there an XFCE session running? use exo-open
> * try, in order: mimeopen, run-mailcap, $BROWSER, firefox, mozilla, netscape
>
> So, probably what's happening to you is that you aren't running KDE, Gnome,
> or XFCE, you don't have mimeopen or run-mailcap installed, and you haven't
> set $BROWSER.
>
> I export BROWSER=gnome-open and love it, but old versions do have a bug
> where gnome-open totally ignores .local/share/applications/defaults.list, so
> make sure to update gnome-open!
>
> Good luck,
> ~d
Thanks a lot for the answer. I see if I can fix it that way.

>
> Quoting Damian <damian.only@gmail.com>:
>
>> Hello,
>>
>> I don't consider myself a smart person. Even my mom used to say that I
>> wasn't so bright. But still, should this be so damn difficult?
>>
>> 'beagle-search' is a front end for the beagle desktop search engine.
>> When you issue a query, the application shows you icons (which
>> represent files) with the result of the query. If you click on the
>> icon, the file will be opened with the default application. The
>> problem is that I cannot set the default application by any means. For
>> instance I would like to open jpeg image files using geeqie.
>>
>> I've failed miserably in trying to associate filetypes to
>> applications, using beagle search. The application beagle-search uses
>> xdg-open to open applications. If a filetype has no application
>> associated, then the default handler is firefox (don't ask me why).
>>
>> So I tried to see how xdg-open works, but the man page didn't give me
>> any useful information. The related command, xdg-mime, doesn't work as
>> I expected.
>>
>> I've created a file called geeqie.desktop in the directory
>> /home/damian/.local/share/applications with the following contents:
>> ?[Desktop Entry]
>> ?Encoding=UTF-8
>> ?Name=Geeqie
>> ?Exec=geeqie
>> ?MimeType=image/jpeg
>> ?Icon=exec
>> ?NoDisplay=true
>>
>> Then I've tried to associate geeqie with jpeg files by running:
>> ? ?xdg-mime default geeqie.desktop image/jpeg
>>
>> The command terminates successfully, and after running
>> ? ?xdg-mime query default image/jpeg
>> I get as output "geeqie.desktop".
>>
>> But xdg-open (and therefore beagle-search) still refuses to open jpeg
>> images with geeqie.
>>
>> Any ideas?
>>
>> Thanks in advance.
>> _______________________________________________
>> xmonad mailing list
>> xmonad@haskell.org
>> http://www.haskell.org/mailman/listinfo/xmonad
>>
>>
>
>
> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>
From damian.only at gmail.com  Sun Feb 21 14:18:46 2010
From: damian.only at gmail.com (Damian)
Date: Sun Feb 21 13:49:45 2010
Subject: [xmonad] Xmonad, beagle-search, and mime types
In-Reply-To: <47a330c51002211114l49beb4b5q401777941094722c@mail.gmail.com>
References: <47a330c51002210640y156853daw92358e73ffe9807d@mail.gmail.com> 
	<20100221123333.6068456987u21oys@webmail.seas.upenn.edu>
	<47a330c51002211114l49beb4b5q401777941094722c@mail.gmail.com>
Message-ID: <47a330c51002211118u5a4a486bo1cc001a6189ec167@mail.gmail.com>

On Sun, Feb 21, 2010 at 8:14 PM, Damian <damian.only@gmail.com> wrote:
> On Sun, Feb 21, 2010 at 6:33 PM, ?<wagnerdm@seas.upenn.edu> wrote:
>> I've been fighting with xdg-open myself, having just switched to chromium.
>> It turns out it's a pretty readable shell script (open it up in your
>> favorite editor and have a look!). Here's approximately what it does:
>>
>> * is there a KDE session running? use kde-open, fall back to kfmclient
>> * is there a Gnome session running? use gvfs-open, fall back to gnome-open
>> * is there an XFCE session running? use exo-open
>> * try, in order: mimeopen, run-mailcap, $BROWSER, firefox, mozilla, netscape
>>
>> So, probably what's happening to you is that you aren't running KDE, Gnome,
>> or XFCE, you don't have mimeopen or run-mailcap installed, and you haven't
>> set $BROWSER.
>>
>> I export BROWSER=gnome-open and love it, but old versions do have a bug
>> where gnome-open totally ignores .local/share/applications/defaults.list, so
>> make sure to update gnome-open!
>>
>> Good luck,
>> ~d
> Thanks a lot for the answer. I see if I can fix it that way.
Indeed, I just exported BROWSER=gnome-open and it worked fine (I
should have hacked xdg-open). Thanks again.

>
>>
>> Quoting Damian <damian.only@gmail.com>:
>>
>>> Hello,
>>>
>>> I don't consider myself a smart person. Even my mom used to say that I
>>> wasn't so bright. But still, should this be so damn difficult?
>>>
>>> 'beagle-search' is a front end for the beagle desktop search engine.
>>> When you issue a query, the application shows you icons (which
>>> represent files) with the result of the query. If you click on the
>>> icon, the file will be opened with the default application. The
>>> problem is that I cannot set the default application by any means. For
>>> instance I would like to open jpeg image files using geeqie.
>>>
>>> I've failed miserably in trying to associate filetypes to
>>> applications, using beagle search. The application beagle-search uses
>>> xdg-open to open applications. If a filetype has no application
>>> associated, then the default handler is firefox (don't ask me why).
>>>
>>> So I tried to see how xdg-open works, but the man page didn't give me
>>> any useful information. The related command, xdg-mime, doesn't work as
>>> I expected.
>>>
>>> I've created a file called geeqie.desktop in the directory
>>> /home/damian/.local/share/applications with the following contents:
>>> ?[Desktop Entry]
>>> ?Encoding=UTF-8
>>> ?Name=Geeqie
>>> ?Exec=geeqie
>>> ?MimeType=image/jpeg
>>> ?Icon=exec
>>> ?NoDisplay=true
>>>
>>> Then I've tried to associate geeqie with jpeg files by running:
>>> ? ?xdg-mime default geeqie.desktop image/jpeg
>>>
>>> The command terminates successfully, and after running
>>> ? ?xdg-mime query default image/jpeg
>>> I get as output "geeqie.desktop".
>>>
>>> But xdg-open (and therefore beagle-search) still refuses to open jpeg
>>> images with geeqie.
>>>
>>> Any ideas?
>>>
>>> Thanks in advance.
>>> _______________________________________________
>>> xmonad mailing list
>>> xmonad@haskell.org
>>> http://www.haskell.org/mailman/listinfo/xmonad
>>>
>>>
>>
>>
>> _______________________________________________
>> xmonad mailing list
>> xmonad@haskell.org
>> http://www.haskell.org/mailman/listinfo/xmonad
>>
>
From ml at n-sch.de  Sun Feb 21 18:06:52 2010
From: ml at n-sch.de (Nils)
Date: Sun Feb 21 17:37:35 2010
Subject: [xmonad] [patch] New extension: X.H.ScreenCorners
Message-ID: <20100221230652.GA31312@xps>

Hi,

I wrote a new extension today which will add KDE like screen corners to
XMonad. See the documentation of the new module for more informations.

http://www.n-sch.de/hdocs/xmonad-contrib/XMonad-Hooks-ScreenCorners.html

Patch is attached.


Nils Schweinsberg
-------------- next part --------------
Mon Feb 22 00:02:59 CET 2010  Nils Schweinsberg <mail@n-sch.de>
  * New extension: XMonad.Hooks.ScreenCorners

New patches:

[New extension: XMonad.Hooks.ScreenCorners
Nils Schweinsberg <mail@n-sch.de>**20100221230259
 Ignore-this: c3a715e2590ed094ed5908bd225b185e
] {
addfile ./XMonad/Hooks/ScreenCorners.hs
hunk ./XMonad/Hooks/ScreenCorners.hs 1
+-----------------------------------------------------------------------------
+-- |
+-- Module      :  XMonad.Hooks.ScreenCorners
+-- Copyright   :  (c) 2009 Nils Schweinsberg
+-- License     :  BSD3-style (see LICENSE)
+--
+-- Maintainer  :  Nils Schweinsberg <mail@n-sch.de>
+-- Stability   :  unstable
+-- Portability :  unportable
+--
+-- Run @X ()@ actions by touching the edge of your screen the your mouse.
+--
+-----------------------------------------------------------------------------
+
+module XMonad.Hooks.ScreenCorners
+    (
+    -- * Usage
+    -- $usage
+    -- * Event hook
+      screenCornerEventHook
+    , ScreenCorner (..)
+
+    -- * X11 input methods
+    , defaultEventInput
+    , adjustEventInput
+    ) where
+
+import Data.Monoid
+import Foreign.C.Types
+
+import XMonad
+import XMonad.Actions.UpdateFocus (adjustEventInput)
+
+data ScreenCorner = SCUpperLeft
+                  | SCUpperRight
+                  | SCLowerLeft
+                  | SCLowerRight
+
+inCorner :: ScreenCorner -> X () -> Display -> CInt -> CInt -> X ()
+inCorner corner xF dpy ix iy = do
+
+    let
+        screen = defaultScreen dpy
+        xMax   = displayWidth  dpy screen - 1
+        yMax   = displayHeight dpy screen - 1
+        pos    = case (ix,iy, corner) of
+                      (0,0, SCUpperLeft)                           -> Just ()
+                      (x,0, SCUpperRight) | x == xMax              -> Just ()
+                      (0,y, SCLowerLeft)  | y == yMax              -> Just ()
+                      (x,y, SCLowerRight) | x == xMax && y == yMax -> Just ()
+                      _                                            -> Nothing
+
+    case pos of
+         Just _ -> do
+             -- Ignore any MotionEvents
+             defaultEventInput
+             -- Run our X ()
+             xF
+             -- Handle MotionEvents again
+             adjustEventInput
+
+         _ -> return ()
+
+-- | The event hook manager for @ScreenCorners@.
+screenCornerEventHook :: Event -> [(ScreenCorner, X ())] -> X All
+screenCornerEventHook MotionEvent { ev_event_display = dpy, ev_x = ix, ev_y = iy } lis = do
+
+    mapM_ (\(c,x) -> inCorner c x dpy ix iy) lis
+    return $ All True
+
+screenCornerEventHook _ _ = return $ All True
+
+
+-- | Use the default input methods
+defaultEventInput :: X ()
+defaultEventInput = withDisplay $ \dpy -> do
+    rootw <- asks theRoot
+    io $ selectInput dpy rootw $  substructureRedirectMask .|. substructureNotifyMask
+                              .|. enterWindowMask .|. leaveWindowMask .|. structureNotifyMask
+                              .|. buttonPressMask
+
+
+-- $usage
+--
+-- This extension adds KDE-like screen corners to XMonad. By moving your cursor
+-- into one of your screen corners you can trigger an @X ()@ action, for
+-- example "XMonad.Actions.GridSelect".gotoSelected or
+-- "XMonad.Actions.CycleWS".nextWS etc.
+--
+-- To use it, import it on top of your @xmonad.hs@:
+--
+-- > import XMonad.Hooks.ScreenCorners
+--
+-- Then add @adjustEventInput@ to your startup hook:
+--
+-- > myStartupHook = do
+-- >     ...
+-- >     adjustEventInput
+--
+-- And put your custom ScreenCorners to your event hook:
+--
+-- > myEventHook e = do
+-- >     ...
+-- >     screenCornerEventHook e [ (SCUpperRight, goToSelected defaultGSConfig { gs_cellwidth = 200 })
+-- >                             , (SCLowerRight, nextWS)
+-- >                             , (SCLowerLeft,  prevWS)
+-- >                             ]
hunk ./xmonad-contrib.cabal 149
                         XMonad.Hooks.Place
                         XMonad.Hooks.PositionStoreHooks
                         XMonad.Hooks.RestoreMinimized
+                        XMonad.Hooks.ScreenCorners
                         XMonad.Hooks.Script
                         XMonad.Hooks.ServerMode
                         XMonad.Hooks.SetWMName
}

Context:

[documentation for marshallPP
daniel@wagner-home.com**20100215000731
 Ignore-this: efa38829b40dc1586f5f18c4bab21f7d
] 
[DynamicLog support for IndependentScreens
Daniel Wagner <daniel@wagner-home.com>**20100104054251
 Ignore-this: 16fe32f1d66abf4a79f8670131663a60
] 
[minor style changes
Daniel Wagner <daniel@wagner-home.com>**20091228173016
 Ignore-this: 605de753d6a5007751de9d7b9f8ab9ca
] 
[XMonad.Prompt: remove white border from greenXPConfig
gwern0@gmail.com**20100211163641
 Ignore-this: 1cd9a6de02419b7747eab98eb4e84c35
] 
[Fixed reversed history searching direction in X.P.history(Up|Down)Matching
Daniel Schoepe <daniel.schoepe@gmail.com>**20100208162901
 Ignore-this: 61b9907318d18ef2fb5bc633048d3afc
] 
[Compatibility for rename of XMonad.numlockMask
Adam Vogt <vogt.adam@gmail.com>**20100124201955
 Ignore-this: 765c58a8b77ca0b54f05fd69a9bba714
] 
[Use extensible-exceptions to allow base-3 or base-4
Adam Vogt <vogt.adam@gmail.com>**20100124203324
 Ignore-this: 136f35fcc0f3a824b96eea0f4e04f276
] 
[suppress some warnings under ghc 6.12.1 and clean up redundant imports to get rid of some others.
Brent Yorgey <byorgey@cis.upenn.edu>**20100112172507
 Ignore-this: bf3487b27036b02797d9f528a078d006
] 
[Corrected documentation in X.Prompt
Daniel Schoepe <daniel.schoepe@gmail.com>**20100201204522
 Ignore-this: 98f9889a4844bc765cbb9e43bd83bc05
] 
[Use Stack instead of list in X.Prompt.history*Matching
Daniel Schoepe <daniel.schoepe@gmail.com>**20100201202839
 Ignore-this: 45d03c7096949bd250dd1c5c2d3646d4
] 
[BluetileConfig: Fullscreen tweaks and border color change
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20100131233347
 Ignore-this: 2a10959bed0f3fb9985e3dd1010f123b
] 
[A.CycleWindows replace partial rotUp and rotDown with safer versions
Wirt Wolff <wirtwolff@gmail.com>**20100123231912
 Ignore-this: 6b4e40c15b66fc53096910e85e736c23
 Rather than throw exceptions, handle null and singleton lists, i.e.
 f [] gives [] and f [x] gives [x].
] 
[Use <+> instead of explicit M.union to merge keybindings in X.C.*
Adam Vogt <vogt.adam@gmail.com>**20100124202136
 Ignore-this: e7bfd99eb4d3e6735153d1d5ec00a885
] 
[Fix incorrect import suggestion in L.Tabbed (issue 362)
Adam Vogt <vogt.adam@gmail.com>**20100121182501
 Ignore-this: 5e46f140a7e8c2abf0ac75b3262a7da4
] 
[Swap window ordering in L.Accordion (closes Issue 358). Thanks rsaarelm.
Adam Vogt <vogt.adam@gmail.com>**20100121154344
 Ignore-this: cd06b0f4fc85f857307aaae8f6e40af7
 
 This change keeps windows in the same ordering when focus is changed.
] 
[use restart to restart xmonad (no longer bluetile)
Jens Petersen <petersen@haskell.org>**20100116105935
 Ignore-this: e6e27c65e25201fc84bfaf092dad48ac
] 
[X.L.Decoration: avoid flicker by not showing decowins without rectangles
Tomas Janousek <tomi@nomi.cz>**20100116112054
 Ignore-this: 6f38634706c3f35272670b969fc6cc96
 
 These would be hidden by updateDecos immediately after being shown. This
 caused flicker with simpleTabbed and only one window on a workspace.
] 
[Add a way to cycle only through matching history entries in X.Prompt
Daniel Schoepe <daniel.schoepe@gmail.com>**20100113233036
 Ignore-this: d67aedb25f2cc6f329a78d5d3eebdd2b
 
 This patch adds a way go up through X.Prompt's history using
 only those entries that start with the current input, similar
 to zsh's `history-search-backward'.
] 
[Style changes in L.Minimize
Adam Vogt <vogt.adam@gmail.com>**20100104144448
 Ignore-this: 5f64c0717e24ed6cbe2c9fad50bf78a3
] 
[minimize_floating
konstantin.sobolev@gmail.com**20091230070105
 Ignore-this: 2c0e1b94f123a869fb4e72a802e59c2
 Adds floating windows support to X.L.Minimize
] 
[Use more imported cursor constants.
Adam Vogt <vogt.adam@gmail.com>**20091230220927
 Ignore-this: 91e55c63a1d020fafb6b53e6abf9766c
] 
[import new contrib module, X.A.DynamicWorkspaceOrder
Brent Yorgey <byorgey@cis.upenn.edu>**20091230192350
 Ignore-this: bba2c0c30d5554612cc6e8bd59fee205
] 
[X.A.CycleWS: export generalized 'doTo' function for performing an action on a workspace relative to the current one
Brent Yorgey <byorgey@cis.upenn.edu>**20091230191953
 Ignore-this: 7cf8efe7c45b501cbcea0943f667b77e
] 
[new contrib module, X.A.DynamicWorkspaceGroups, for managing groups of workspaces on multi-head setups
Brent Yorgey <byorgey@cis.upenn.edu>**20091229165702
 Ignore-this: fc3e6932a95f57b36b4d8d4cc7f3e2d7
] 
[new contrib module from Tomas Janousek, X.A.WorkspaceNames
Brent Yorgey <byorgey@cis.upenn.edu>**20091229163915
 Ignore-this: 5bc7caaf38647de51949a24498001474
] 
[X.P.Shell, filter empty string from PATH
Tim Horton <tmhorton@gmail.com>**20091224033217
 Ignore-this: 1aec55452f917d0be2bff7fcf5937766
 
 doesDirectoryExist returns True if given an empty string using ghc <= 6.10.4.
 This causes getDirectoryContents to raise an exception and X.P.Shell does not
 render. This is only an issue if you have an empty string in your PATH.
 
 Using ghc == 6.12.1, doesDirectoryExist returns False given an empty string, so
 this should not be an issue in the future.
 
] 
[small tweak to battery logger
Brent Yorgey <byorgey@cis.upenn.edu>**20091227085641
 Ignore-this: 350dfed0cedd250cd9d4bd3391cbe034
] 
[Use imported xC_bottom_right_corner in A.MouseResize
Adam Vogt <vogt.adam@gmail.com>**20091227233705
 Ignore-this: 52794f788255159b91e68f2762c5f6a1
] 
[X.A.MouseResize: assign an appropriate cursor for the resizing inpuwin
Tomas Janousek <tomi@nomi.cz>**20091227212140
 Ignore-this: d9ce96c2cd0312b6b5be4acee30a1da3
] 
[Fix the createSession bug in spawnPipe
Spencer Janssen <spencerjanssen@gmail.com>**20091227003501
 Ignore-this: 2d7f8746eb657036d39f3b9aac22b3c9
 Both the new XMonad.Core.xfork function and spawnPipe call createSession, calling
 this function twice results in an error.
] 
[Let the core know about MouseResizableTile's draggers, so they are stacked correctly
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091223145428
 Ignore-this: 7c096aba6b540ccf9b49c4ee86c6091a
] 
[Update all uses of forkProcess to xfork
Spencer Janssen <spencerjanssen@gmail.com>**20091223064558
 Ignore-this: 963a4ddf1d2f4096bbb8969b173cd0c1
] 
[Make X.L.Minimize explicitly mark minimized windows as boring
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091222214529
 Ignore-this: b1e8adf26ac87dede6c1b7a7d687411c
] 
[Actions/Search: added openstreetmap
intrigeri@boum.org**20091222114545
 Ignore-this: fafc4680c8b59b7a044d995c1dacec9a
] 
[Add a search predicate option to XMonad.Prompt
Mike Lundy <mike@fluffypenguin.org>**20091221025408
 Ignore-this: 8e8804eeb9650d38bc225e15887310da
] 
[In D.Extending note how <+> can be used with keybindings.
Adam Vogt <vogt.adam@gmail.com>**20091220190739
 Ignore-this: ebea8ef8a835ed368fa06621add6519f
] 
[Fix MultiToggle crashes with decorated layouts
Tomas Janousek <tomi@nomi.cz>**20091220004733
 Ignore-this: 9208f5da9f0de95464ea62cb45e8f291
 
 The problem was that certain layouts keep their "world" state in their value,
 which was thrown away and forgotten after ReleaseResources during toggle.
 
 In particular, decorated layouts store some X11 handles in them and
 allocate/deallocate it as appropriate. If any modification to their state is
 ignored, they may try to deallocate already deallocated memory, which results
 in a crash somewhere inside Xlib.
 
 This patch makes Transformers reversible so that nothing is ever ignored. As a
 side effect, layout transformers now do receive messages and messages for the
 base layout do not need the undo/reapply cycle -- we just pass messages to the
 current transformed layout and unapply the transformer when needed.
 (This, however, doesn't mean that the base layout is not asked to release
 resources on a transformer change -- we still need the transformer to release
 its resources and there's no way to do this without asking the base layout as
 well.)
] 
[Golf / style change in U.ExtensibleState
Adam Vogt <vogt.adam@gmail.com>**20091208010506
 Ignore-this: c35bd85baae4700e14417ac7e07de959
] 
[Style changes in EwmhDesktops
Adam Vogt <vogt.adam@gmail.com>**20091219003824
 Ignore-this: 905eff9ed951955c8f62617b2d82302e
] 
[Add support for fullscreen through the _NET_WM_STATE protocol
audunskaugen@gmail.com**20091214135119
 Ignore-this: 430ca3c6779e36383f8ce8e477ee9622
 
 This patch adds support for applications using the
 gtk_window_fullscreen function, and other applications using
 _NET_WM_STATE for the same purpose.
] 
[TAG 0.9.1
Spencer Janssen <spencerjanssen@gmail.com>**20091216233651
 Ignore-this: 713d9dd89d775e30346f57a61038d308
] 
[Bump version to 0.9.1
Spencer Janssen <spencerjanssen@gmail.com>**20091216232634
 Ignore-this: bcd799c3341ee6c69a259e1dca747cac
] 
[Match X11 dependencies with xmonad's
Spencer Janssen <spencerjanssen@gmail.com>**20091216012630
 Ignore-this: bcbd6e3e5e2675cdac6f1d1b1bc09853
] 
[Safer X11 version dependency
Spencer Janssen <spencerjanssen@gmail.com>**20091216005916
 Ignore-this: 6dc805a8a0c7a3d3369bc1d6d97d4f56
] 
[Update Prompt for numlockMask changes
Spencer Janssen <spencerjanssen@gmail.com>**20091103222621
 Ignore-this: 4980e2fdf4c296a266590cc4acf76e1e
] 
[X.L.MouseResizableTile: change description for mirrored variant
Tomas Janousek <tomi@nomi.cz>**20091211124218
 Ignore-this: dbc02fb777e35cdc15fb11979c1e983e
 
 The description for mirrored MouseResizableTile is now "Mirror
 MouseResizableTile", to follow the standard of other layouts that can be
 mirrored using the Mirror modifier.
] 
[X.A.GridSelect: documentation typo fix
Tomas Janousek <tomi@nomi.cz>**20091211182515
 Ignore-this: 521bef2a73a9e969d7a96defb555177b
 
 spotted by Justin on IRC
] 
[A.GridSelect shouldn't grab keys if there are no choices.
Adam Vogt <vogt.adam@gmail.com>**20091210183038
 Ignore-this: 48509f780120014a10b32e7289369f32
 
 Thanks thermal2008 in #xmonad for bringing up the corner case when gridselect
 is run with an empty list of choices.
] 
[Added Bluetile's config
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091209150309
 Ignore-this: 641ae527ca6f615e81822b6f38f827e7
] 
[BluetileCommands - a list of commands that Bluetile uses to communicate with its dock
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091208234431
 Ignore-this: 1a5a5e69c7c37d3ffe8d8e09496568de
] 
[onScreen' variation for X () functions
Nils Schweinsberg <mail@n-sch.de>**20091209003717
 Ignore-this: 6a9644c729c2b60f94398260f3640e4d
] 
[Use lookup instead of find in A.PerWorkspaceKeys
Adam Vogt <vogt.adam@gmail.com>**20091129032650
 Ignore-this: 7ecb043df4317365ff3d25b17303eed8
] 
[Change of X.A.OnScreen, more simple and predictable behaviour of onScreen, new functions: toggle(Greedy)OnScreen
Nils Schweinsberg <mail@n-sch.de>**20091207155050
 Ignore-this: c375250778758e401217bcad83567d3b
] 
[Module to ensure that a dragged window always stays in front of all other windows
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091129004506
 Ignore-this: a8a389198ccc28a66686561d4d17e91b
] 
[Decoration that allows to switch the position of windows by dragging them onto each other.
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091129003431
 Ignore-this: 38aff0f3beb1a1eb304219c4f3e85593
] 
[A decoration with small buttons and a supporting module
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091129002416
 Ignore-this: 2d65133bc5b9ad29bad7d06780bdaa4
] 
[XMonad.Actions.Search: finally fixed the internet archive search plugin
gwern0@gmail.com**20091205033435
 Ignore-this: c78ecebced9bc8e39e6077ffa9f9f182
] 
[XMonad.Actions.Search: in retrospect, a bit silly to make everyone go through SSL
gwern0@gmail.com**20091205033318
 Ignore-this: 452b4e6efb83935fc1063ab695ae074d
] 
[Prompt.hs: Corrected quit keybindings
Tim Horton <tmhorton@gmail.com>**20091203050041
 Ignore-this: e8cd2cd1d41f6807f68157ef37c631ea
] 
[Extended decoration module with more hooks and consolidated some existing ones
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091128234310
 Ignore-this: 5a23af3009ecca2feb9a84f8c6f8ac33
] 
[Extended decoration theme to contain extra static text that always appears in the title bar
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091024213928
 Ignore-this: 95f46d6b9ff716a2d8002a426c1012c8
] 
[Extended paintAndWrite to allow for multiple strings to be written into the rectangle
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091024205111
 Ignore-this: eb7d32284b7f98145038dcaa14f8075e
] 
[Added the alignment option 'AlignRightOffset'
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091024204513
 Ignore-this: 58cc00e1be669877e38a97e36b924969
] 
[Prevent windows from being decorated that are too small to contain decoration.
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20090627094316
 Ignore-this: 39b806462bbd424f1206b635e9d506e1
] 
[X.L.MouseResizableTile: keep draggers on the bottom of the window stack.
Tomas Janousek <tomi@nomi.cz>**20091126173413
 Ignore-this: 8089cf8ce53580090b045f4aebb1b899
] 
[Implemented smarter system of managing borders for BorderResize
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091122233651
 Ignore-this: 4775c082249e598a84c79b2e819f28b0
] 
[X.H.DynamicLog: fix xmonadPropLog double-encoding of UTF-8
Tomas Janousek <tomi@nomi.cz>**20091121004829
 Ignore-this: bde612bbd1a19951f9718a03e737c4ac
 
 dynamicLogString utf-8 encodes its output, xmonadPropLog shouldn't do that
 again.
] 
[X.H.DynamicLog: make documentation for 'dzen' and 'xmobar' slightly more clear
Brent Yorgey <byorgey@cis.upenn.edu>**20091121170739
 Ignore-this: c9a241677fda21ef93305fc3882f102e
] 
[X.H.ManageDocks: ignore struts that cover an entire screen on that screen
Tomas Janousek <tomi@nomi.cz>**20091119145043
 Ignore-this: ad7bbf10c49c9f3e938cdc3d8588e202
 
 Imagine a screen layout like this:
 
   11111111
   11111111
   11111111
    222222    <--- xmobar here
    222222
    222222
 
 When placing xmobar as indicated, the partial strut property indicates that an
 entire height of screen 1 is covered by the strut, as well as a few lines at
 the top of screen 2. The original code would create a screen rectangle of
 negative height and wreak havoc. This patch causes such strut to be ignored on
 the screen it covers entirely, resulting in the desired behaviour of a small
 strut at the top of screen 2.
 
 Please note that this semantics of _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL is
 different to what is in wm-spec. The "correct" thing to do would be to discard
 the covered portion of screen 1 leaving two narrow areas at the sides, but
 this new behaviour is probably more desirable in many cases, at least for
 xmonad/xmobar users.
 
 The correct solution of having separate _NET_WM_STRUT_PARTIAL for each
 Xinerama screen was mentioned in wm-spec maillist in 2007, but has never
 really been proposed, discussed and included in wm-spec. Hence this "hack".
] 
[Use imported 'fi' in PositionStoreHooks
Adam Vogt <vogt.adam@gmail.com>**20091119103112
 Ignore-this: 6563a3093083667c79aa491a6f59b805
] 
[Changed interface of X.U.ExtensibleState
Daniel Schoepe <daniel.schoepe@gmail.com>**20091116171013
 Ignore-this: 9a830f9341e461628974890bab0bd65b
 
 Changed the interface of X.U.ExtensibleState to resemble that of
 Control.Monad.State and modified the modules that use it accordingly.
] 
[PositionStoreFloat - a floating layout with support hooks
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091115184833
 Ignore-this: 8b1d0fcef1465356d72cb5f1f32413b6
] 
[PositionStore utility to store information about position and size of a window
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091108195735
 Ignore-this: 2f6e68a490deb75cba5d007b30c93fb2
] 
[X.H.Urgencyhook fix minor doc bug
Anders Engstrom <ankaan@gmail.com>**20091115131121
 Ignore-this: 18b63bccedceb66c77b345a9300f1ac3
] 
[X.H.DynamicLog fix minor indentation oddness
Anders Engstrom <ankaan@gmail.com>**20091115130707
 Ignore-this: 7f2c49eae5527874ca4499767f4167c4
] 
[X.A.CycleWS cycle by tag group
Anders Engstrom <ankaan@gmail.com>**20091115130217
 Ignore-this: 909da8c00b47a31d04f59bd3751c60bc
 Allow grouping of workspaces, so that a user can cycle through those in the same group. Grouping is done by using a special character in the tag.
] 
[Use less short names in X.Prompt
Adam Vogt <vogt.adam@gmail.com>**20091115025647
 Ignore-this: 1d27b8efc4d829a5642717c6f6426336
] 
[Use io instead of liftIO in Prompt
Adam Vogt <vogt.adam@gmail.com>**20091115025301
 Ignore-this: cd4031b74cd5bb874cd2c3cc2cb087f2
] 
['io' and 'fi' are defined outside of Prompt
Adam Vogt <vogt.adam@gmail.com>**20091115024001
 Ignore-this: 3426056362db9cbfde7d2f4edbfe6f36
] 
[Use zipWithM_ instead of recursion in Prompt.printComplList
Adam Vogt <vogt.adam@gmail.com>**20091115023451
 Ignore-this: 2457500ed871ef120653a3d4ada13441
] 
[Minor style changes in DynamicWorkspaces
Adam Vogt <vogt.adam@gmail.com>**20091115022751
 Ignore-this: 1a6018ab134e4420a949354575a8a110
] 
[X.A.DynamicWorkspaces fix doc and add behaviour
Anders Engstrom <ankaan@gmail.com>**20091113233903
 Ignore-this: ab7c20a9c1b43ebc6a7f4700d988fb73
 Before this patch the documentation claims that it won't do anything on non-empty workspaces when it actually does. This patch fixes the documentation to reflect the actual behaviour, but also adds the behaviour promised by the documentation in other functions. It does not break configs. In addition it also provides functions to help removing empty workspaces when leaving them.
] 
[rework XMonad.Util.Dzen
daniel@wagner-home.com**20091114051509
 Ignore-this: 16d93f91c54f7d195b1a418e6c0351c5
] 
[generalize IO actions to MonadIO m => m actions
daniel@wagner-home.com**20091114023616
 Ignore-this: 2c801a27b0ffee34a2f0daca3778613a
 
 This should not cause any working configs to stop working, because IO is an instance of MonadIO, and because complete configs will pin down the type of the call to IO.  Note that XMonad.Config.Arossato is not a complete config, and so it needed some tweaks; with a main function, this should not be a problem.
] 
[fix documentation to match implementation
daniel@wagner-home.com**20091114021328
 Ignore-this: 6dbbb118b139f443c40a573445a48d07
] 
[Bypass more of stringToKeysym in U.Paste
Adam Vogt <vogt.adam@gmail.com>**20091114223726
 Ignore-this: 617c922647e9f49f5ecefa0eb1c65d3c
] 
[Don't erase floating information with H.InsertPosition (Issue 334)
Adam Vogt <vogt.adam@gmail.com>**20091113161402
 Ignore-this: de1c03eb860ea25b390ee5c756b02997
] 
[Rename gridselectViewWorkspace to gridselectWorkspace, add another example.
Adam Vogt <vogt.adam@gmail.com>**20091112211435
 Ignore-this: 462cf1c7f66ab97a1ce642977591a910
 
 The name should be more general to suggest uses other than just viewing other
 workspaces.
] 
[X.A.DynamicWorkspaces: fix addWorkspace and friends so they never add another copy of an existing workspace
Brent Yorgey <byorgey@cis.upenn.edu>**20091112201351
 Ignore-this: 5bfe8129707b038ed04383b7566b2323
] 
[Trim whitespace in H.FloatNext
Adam Vogt <vogt.adam@gmail.com>**20091111022702
 Ignore-this: 1ad52678246fa1ac951169c2356ce10b
] 
[Use ExtensibleState in H.FloatNext
Adam Vogt <vogt.adam@gmail.com>**20091111022513
 Ignore-this: 760d95a685af080466cb4164d1096423
] 
[Make a haddock link direct in C.Desktop.
Adam Vogt <vogt.adam@gmail.com>**20091111013810
 Ignore-this: da724a7974c3de60f49996c1fe92d3fb
] 
[Change A.TopicSpace haddocks to use block quotes.
Adam Vogt <vogt.adam@gmail.com>**20091111013241
 Ignore-this: 6f7f43d2715cfde62b9c05c7d9a0da2
] 
[Add defaultTopicConfig, to allow adding more fields to TopicSpace later.
Adam Vogt <vogt.adam@gmail.com>**20091111012915
 Ignore-this: 6dad95769651a9a1ef8d771f81c91f8e
] 
[X.A.WindowGo: fix haddock markup
Spencer Janssen <spencerjanssen@gmail.com>**20091111003256
 Ignore-this: c6a06de900ca8b67498abf5152e3d9ea
] 
[Minor style corrections in X.U.SpawnOnce
Daniel Schoepe <daniel.schoepe@gmail.com>**20091109201543
 Ignore-this: 1264852c23b4f84b2580bf4567529c68
] 
[Add gridselectViewWorkspace in X.A.GridSelect
Daniel Schoepe <daniel.schoepe@gmail.com>**20091109155815
 Ignore-this: 5543211e9e3fd325cb798b004635a525
] 
[minor-doc-fix-in-ManageHelpers
`Henrique Abreu <hgabreu@gmail.com>'**20091104172727
 Ignore-this: 231ad417541bc3c17a1cb2dff139d55d
] 
[Set buffering to LineBuffering in scripts/xmonadpropread.hs
Daniel Schoepe <daniel.schoepe@gmail.com>**20091108204106
 Ignore-this: 4e593fc1461fbbfb5b147c7c7702584e
 
 (Required for the script to work properly with tools like dzen)
] 
[X.U.ExtensibleState: style
Spencer Janssen <spencerjanssen@gmail.com>**20091108182858
 Ignore-this: f189da75ad2c57ae9cca48eaf69a6bad
] 
[X.A.DynamicWorkspaces: new 'addWorkspacePrompt' method
Brent Yorgey <byorgey@cis.upenn.edu>**20091108170503
 Ignore-this: a3992b1b7938be80d8fd2a5a503a4042
] 
[Remove defaulting when using NoMonomorphismRestriction in H.EwmhDesktops
Adam Vogt <vogt.adam@gmail.com>**20091107195255
 Ignore-this: ca3939842639c94ca4fd1ff6624319c1
] 
[Update A.TopicSpace to use extensible state. No config changes required.
Adam Vogt <vogt.adam@gmail.com>**20091107194502
 Ignore-this: 7a82aad512bb727b3447de0faa4a210f
] 
[Inline tupadd function in A.GridSelect
Adam Vogt <vogt.adam@gmail.com>**20091101190312
 Ignore-this: 458968154303ab865c304f387d6ac83b
] 
[Alphabetize exposed-modules
Spencer Janssen <spencerjanssen@gmail.com>**20091107174946
 Ignore-this: 919684aea7747a756b303f9b34a2870b
] 
[Use X.U.SpawnOnce in my config
Spencer Janssen <spencerjanssen@gmail.com>**20091107174615
 Ignore-this: fe8f5f75136128280942771ec429f09a
] 
[Add XMonad.Util.SpawnOnce
Spencer Janssen <spencerjanssen@gmail.com>**20091107173820
 Ignore-this: 8d4657bbaa8dbeb1d0f9d22293bfef19
] 
[Store deserialized data after reading in X.U.ExtensibleState
Daniel Schoepe <daniel.schoepe@gmail.com>**20091107103832
 Ignore-this: 192beca56e9437292bd3f16451ae9e66
] 
[Fixed conflict between X.U.ExtensibleState and X.C.Sjanssen
Daniel Schoepe <daniel.schoepe@gmail.com>**20091107103619
 Ignore-this: 80f4bb218574d7c528af17473c6e4f66
] 
[Use X.U.ExtensibleState instead of IORefs
Daniel Schoepe <daniel.schoepe@gmail.com>**20091106115601
 Ignore-this: e0e80e31e51dfe76f2b2ed597892cbba
   
 This patch changes SpawnOn, DynamicHooks and UrgencyHooks to
 use X.U.ExtensibleState instead of IORefs. This simplifies the
 usage of those modules thus also breaking current configs.
] 
[Add X.U.ExtensibleState
Daniel Schoepe <daniel.schoepe@gmail.com>**20091106115336
 Ignore-this: d80d9d0c10a53fb71a375e432bd29344
] 
[My config uses xmonadPropLog now
Spencer Janssen <spencerjanssen@gmail.com>**20091107005230
 Ignore-this: 8f16b8bea86dfcd3739f1566f5897578
] 
[Add xmonadpropread script
Spencer Janssen <spencerjanssen@gmail.com>**20091107004858
 Ignore-this: 8cc7ed36ec1126d0139638148f9642e8
] 
[Add experimental xmonadPropLog function
Spencer Janssen <spencerjanssen@gmail.com>**20091107004624
 Ignore-this: f09b2c11b16a3af993b63d1b39566120
] 
[XMonad.Actions.Search: imdb search URL tweak for bug #33
gwern0@gmail.com**20091103222330
 Ignore-this: bae5e6d3ec6c4b6591016ece9dffb202
] 
[Clean imports for L.BoringWindows
Adam Vogt <vogt.adam@gmail.com>**20091103140649
 Ignore-this: 56946a652329390dbdd63746ca23ee8e
] 
[I maintain L.BoringWindows
Adam Vogt <vogt.adam@gmail.com>**20091103140509
 Ignore-this: de853972b4c1c4cefa2dc29e68828d5d
] 
[fix window rectangle calculation in X.A.UpdatePointer
Tomas Janousek <tomi@nomi.cz>**20091026154918
 Ignore-this: ad0c3a020b802854919c7827faa001ad
] 
[Implement hasProperty in terms of runQuery in U.WindowProperties
Adam Vogt <vogt.adam@gmail.com>**20091031154945
 Ignore-this: 1c351bc436e0e323dc25d8f5ff734dcb
 
 This addresses issue 302 for unicode titles by actually using the complicated
 XMonad.ManageHook.title code, instead of reimplementing it with stringProperty
 (which doesn't appear to handle unicode).
] 
[Add functions to access the current input in X.Prompt
Daniel Schoepe <daniel.schoepe@gmail.com>**20091030235033
 Ignore-this: 3f568c1266d85dcaa5722b19bbbd61dd
] 
[Remove putSelection, fixes #317
Spencer Janssen <spencerjanssen@gmail.com>**20091030224354
 Ignore-this: 6cfd6d92e1d133bc9e3cbb7c8339f735
] 
[Fix typo in H.FadeInactive documentation
Adam Vogt <vogt.adam@gmail.com>**20091029165736
 Ignore-this: b2af487cd382416160d5540b7f210464
] 
[X.L.MultiCol constructor 0 NWin bugfig
Anders Engstrom <ankaan@gmail.com>**20091029105633
 Ignore-this: e6a24f581593424461a8675984d14d25
 Fix bug where the constructor did not accept catch-all columns. Also some minor cleaning.
] 
[X.H.ManageHelpers: added currentWs that returns the current workspace
Ismael Carnales <icarnales@gmail.com>**20091028193519
 Ignore-this: dcd3dac6bd741d26747807691f125637
] 
[X.L.MultiColumns bugfix and formating
Anders Engstrom <ankaan@gmail.com>**20091027131741
 Ignore-this: 6978f485d18adb8bf81cf6c8e0d0332
 Fix bug where a column list of insufficient length could be used to find the column of the window. Also fix formating to conform better with standards.
] 
[X.L.MultiColumns NWin shrinkning fix
Anders Engstrom <ankaan@gmail.com>**20091027005932
 Ignore-this: 9ba40ee14ec12c3885173817eac2b564
 Fixed a bug where the list containing the number of windows in each column was allowed the shrink if a column was unused.
] 
[New Layout X.L.MultiColumns
Anders Engstrom <ankaan@gmail.com>**20091024175155
 Ignore-this: a2d3d2eee52c28eab7d125f6b621cada
 New layout inspired the realization that I was switching between Mirror Tall and Mirror ThreeCol depending on how many windows there were on the workspace. This layout will make those changes automatically.
] 
[Changing behaviour of ppUrgent with X.H.DynamicLog
mail@n-sch.de**20090910010411
 Ignore-this: 3882f36d5c49e53628485c1570bf136a
 
 Currently, the ppUrgent method is an addition to the ppHidden method.
 This doesn't make any sense since it is in fact possible to get urgent
 windows on the current and visible screens. So I've raised the ppUrgent
 printer to be above ppCurrent/ppVisible and dropped its dependency on
 ppHidden.
 
 In addition to that this makes it a lot more easier to define a more
 custom ppUrgent printer, since you don't have to "undo" the ppHidden
 printer anymore. This also basicly removes the need for dzenStrip,
 although I just changed the description.
 
 -- McManiaC / Nils
 
] 
[fix X.U.Run.spawnPipe fd leak
Tomas Janousek <tomi@nomi.cz>**20091025210246
 Ignore-this: 24375912d505963fafc917a63d0e79a0
] 
[TAG 0.9
Spencer Janssen <spencerjanssen@gmail.com>**20091026013449
 Ignore-this: 542b6105d6deed65e12d1f91c666b0b2
] 
Patch bundle hash:
1589fb0c3eb36273dadf2d1dfadace0cbf20456f
From ml at n-sch.de  Sun Feb 21 18:26:10 2010
From: ml at n-sch.de (Nils)
Date: Sun Feb 21 17:56:51 2010
Subject: [xmonad] [patch] New extension: X.H.ScreenCorners
In-Reply-To: <20100221230652.GA31312@xps>
References: <20100221230652.GA31312@xps>
Message-ID: <20100221232610.GA407@xps>

On Mon, Feb 22, 2010 at 12:06:52AM +0100, Nils wrote:
> Hi,
> 
> I wrote a new extension today which will add KDE like screen corners to
> XMonad. See the documentation of the new module for more informations.

Sorry, I should have done some more testing since I threw something out
during development which I think is kinda important: Move the mouse
cursor away from the current corner to avoid unwanted loops? Patch is
attached.
-------------- next part --------------
Mon Feb 22 00:15:50 CET 2010  Nils Schweinsberg <mail@n-sch.de>
  * [patch] X.H.ScreenCorners: move the mouse cursor to avoid loops

New patches:

[[patch] X.H.ScreenCorners: move the mouse cursor to avoid loops
Nils Schweinsberg <mail@n-sch.de>**20100221231550
 Ignore-this: c8d2ece0f6e75aba1b091d5f9de371dc
] {
hunk ./XMonad/Hooks/ScreenCorners.hs 47
         xMax   = displayWidth  dpy screen - 1
         yMax   = displayHeight dpy screen - 1
         pos    = case (ix,iy, corner) of
-                      (0,0, SCUpperLeft)                           -> Just ()
-                      (x,0, SCUpperRight) | x == xMax              -> Just ()
-                      (0,y, SCLowerLeft)  | y == yMax              -> Just ()
-                      (x,y, SCLowerRight) | x == xMax && y == yMax -> Just ()
+                      (0,0, SCUpperLeft)                           -> Just (50, 50)
+                      (x,0, SCUpperRight) | x == xMax              -> Just (x - 50, 50)
+                      (0,y, SCLowerLeft)  | y == yMax              -> Just (50, y - 50)
+                      (x,y, SCLowerRight) | x == xMax && y == yMax -> Just (x - 50, y - 50)
                       _                                            -> Nothing
 
     case pos of
hunk ./XMonad/Hooks/ScreenCorners.hs 54
-         Just _ -> do
+         Just (x,y) -> do
              -- Ignore any MotionEvents
              defaultEventInput
hunk ./XMonad/Hooks/ScreenCorners.hs 57
+             -- move the mouse cursor so we avoid an unwanted loop
+             rootw <- asks theRoot
+             io $ warpPointer dpy none rootw 0 0 0 0 (fromIntegral x) (fromIntegral y)
              -- Run our X ()
              xF
              -- Handle MotionEvents again
}

Context:

[New extension: XMonad.Hooks.ScreenCorners
Nils Schweinsberg <mail@n-sch.de>**20100221230259
 Ignore-this: c3a715e2590ed094ed5908bd225b185e
] 
[documentation for marshallPP
daniel@wagner-home.com**20100215000731
 Ignore-this: efa38829b40dc1586f5f18c4bab21f7d
] 
[DynamicLog support for IndependentScreens
Daniel Wagner <daniel@wagner-home.com>**20100104054251
 Ignore-this: 16fe32f1d66abf4a79f8670131663a60
] 
[minor style changes
Daniel Wagner <daniel@wagner-home.com>**20091228173016
 Ignore-this: 605de753d6a5007751de9d7b9f8ab9ca
] 
[XMonad.Prompt: remove white border from greenXPConfig
gwern0@gmail.com**20100211163641
 Ignore-this: 1cd9a6de02419b7747eab98eb4e84c35
] 
[Fixed reversed history searching direction in X.P.history(Up|Down)Matching
Daniel Schoepe <daniel.schoepe@gmail.com>**20100208162901
 Ignore-this: 61b9907318d18ef2fb5bc633048d3afc
] 
[Compatibility for rename of XMonad.numlockMask
Adam Vogt <vogt.adam@gmail.com>**20100124201955
 Ignore-this: 765c58a8b77ca0b54f05fd69a9bba714
] 
[Use extensible-exceptions to allow base-3 or base-4
Adam Vogt <vogt.adam@gmail.com>**20100124203324
 Ignore-this: 136f35fcc0f3a824b96eea0f4e04f276
] 
[suppress some warnings under ghc 6.12.1 and clean up redundant imports to get rid of some others.
Brent Yorgey <byorgey@cis.upenn.edu>**20100112172507
 Ignore-this: bf3487b27036b02797d9f528a078d006
] 
[Corrected documentation in X.Prompt
Daniel Schoepe <daniel.schoepe@gmail.com>**20100201204522
 Ignore-this: 98f9889a4844bc765cbb9e43bd83bc05
] 
[Use Stack instead of list in X.Prompt.history*Matching
Daniel Schoepe <daniel.schoepe@gmail.com>**20100201202839
 Ignore-this: 45d03c7096949bd250dd1c5c2d3646d4
] 
[BluetileConfig: Fullscreen tweaks and border color change
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20100131233347
 Ignore-this: 2a10959bed0f3fb9985e3dd1010f123b
] 
[A.CycleWindows replace partial rotUp and rotDown with safer versions
Wirt Wolff <wirtwolff@gmail.com>**20100123231912
 Ignore-this: 6b4e40c15b66fc53096910e85e736c23
 Rather than throw exceptions, handle null and singleton lists, i.e.
 f [] gives [] and f [x] gives [x].
] 
[Use <+> instead of explicit M.union to merge keybindings in X.C.*
Adam Vogt <vogt.adam@gmail.com>**20100124202136
 Ignore-this: e7bfd99eb4d3e6735153d1d5ec00a885
] 
[Fix incorrect import suggestion in L.Tabbed (issue 362)
Adam Vogt <vogt.adam@gmail.com>**20100121182501
 Ignore-this: 5e46f140a7e8c2abf0ac75b3262a7da4
] 
[Swap window ordering in L.Accordion (closes Issue 358). Thanks rsaarelm.
Adam Vogt <vogt.adam@gmail.com>**20100121154344
 Ignore-this: cd06b0f4fc85f857307aaae8f6e40af7
 
 This change keeps windows in the same ordering when focus is changed.
] 
[use restart to restart xmonad (no longer bluetile)
Jens Petersen <petersen@haskell.org>**20100116105935
 Ignore-this: e6e27c65e25201fc84bfaf092dad48ac
] 
[X.L.Decoration: avoid flicker by not showing decowins without rectangles
Tomas Janousek <tomi@nomi.cz>**20100116112054
 Ignore-this: 6f38634706c3f35272670b969fc6cc96
 
 These would be hidden by updateDecos immediately after being shown. This
 caused flicker with simpleTabbed and only one window on a workspace.
] 
[Add a way to cycle only through matching history entries in X.Prompt
Daniel Schoepe <daniel.schoepe@gmail.com>**20100113233036
 Ignore-this: d67aedb25f2cc6f329a78d5d3eebdd2b
 
 This patch adds a way go up through X.Prompt's history using
 only those entries that start with the current input, similar
 to zsh's `history-search-backward'.
] 
[Style changes in L.Minimize
Adam Vogt <vogt.adam@gmail.com>**20100104144448
 Ignore-this: 5f64c0717e24ed6cbe2c9fad50bf78a3
] 
[minimize_floating
konstantin.sobolev@gmail.com**20091230070105
 Ignore-this: 2c0e1b94f123a869fb4e72a802e59c2
 Adds floating windows support to X.L.Minimize
] 
[Use more imported cursor constants.
Adam Vogt <vogt.adam@gmail.com>**20091230220927
 Ignore-this: 91e55c63a1d020fafb6b53e6abf9766c
] 
[import new contrib module, X.A.DynamicWorkspaceOrder
Brent Yorgey <byorgey@cis.upenn.edu>**20091230192350
 Ignore-this: bba2c0c30d5554612cc6e8bd59fee205
] 
[X.A.CycleWS: export generalized 'doTo' function for performing an action on a workspace relative to the current one
Brent Yorgey <byorgey@cis.upenn.edu>**20091230191953
 Ignore-this: 7cf8efe7c45b501cbcea0943f667b77e
] 
[new contrib module, X.A.DynamicWorkspaceGroups, for managing groups of workspaces on multi-head setups
Brent Yorgey <byorgey@cis.upenn.edu>**20091229165702
 Ignore-this: fc3e6932a95f57b36b4d8d4cc7f3e2d7
] 
[new contrib module from Tomas Janousek, X.A.WorkspaceNames
Brent Yorgey <byorgey@cis.upenn.edu>**20091229163915
 Ignore-this: 5bc7caaf38647de51949a24498001474
] 
[X.P.Shell, filter empty string from PATH
Tim Horton <tmhorton@gmail.com>**20091224033217
 Ignore-this: 1aec55452f917d0be2bff7fcf5937766
 
 doesDirectoryExist returns True if given an empty string using ghc <= 6.10.4.
 This causes getDirectoryContents to raise an exception and X.P.Shell does not
 render. This is only an issue if you have an empty string in your PATH.
 
 Using ghc == 6.12.1, doesDirectoryExist returns False given an empty string, so
 this should not be an issue in the future.
 
] 
[small tweak to battery logger
Brent Yorgey <byorgey@cis.upenn.edu>**20091227085641
 Ignore-this: 350dfed0cedd250cd9d4bd3391cbe034
] 
[Use imported xC_bottom_right_corner in A.MouseResize
Adam Vogt <vogt.adam@gmail.com>**20091227233705
 Ignore-this: 52794f788255159b91e68f2762c5f6a1
] 
[X.A.MouseResize: assign an appropriate cursor for the resizing inpuwin
Tomas Janousek <tomi@nomi.cz>**20091227212140
 Ignore-this: d9ce96c2cd0312b6b5be4acee30a1da3
] 
[Fix the createSession bug in spawnPipe
Spencer Janssen <spencerjanssen@gmail.com>**20091227003501
 Ignore-this: 2d7f8746eb657036d39f3b9aac22b3c9
 Both the new XMonad.Core.xfork function and spawnPipe call createSession, calling
 this function twice results in an error.
] 
[Let the core know about MouseResizableTile's draggers, so they are stacked correctly
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091223145428
 Ignore-this: 7c096aba6b540ccf9b49c4ee86c6091a
] 
[Update all uses of forkProcess to xfork
Spencer Janssen <spencerjanssen@gmail.com>**20091223064558
 Ignore-this: 963a4ddf1d2f4096bbb8969b173cd0c1
] 
[Make X.L.Minimize explicitly mark minimized windows as boring
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091222214529
 Ignore-this: b1e8adf26ac87dede6c1b7a7d687411c
] 
[Actions/Search: added openstreetmap
intrigeri@boum.org**20091222114545
 Ignore-this: fafc4680c8b59b7a044d995c1dacec9a
] 
[Add a search predicate option to XMonad.Prompt
Mike Lundy <mike@fluffypenguin.org>**20091221025408
 Ignore-this: 8e8804eeb9650d38bc225e15887310da
] 
[In D.Extending note how <+> can be used with keybindings.
Adam Vogt <vogt.adam@gmail.com>**20091220190739
 Ignore-this: ebea8ef8a835ed368fa06621add6519f
] 
[Fix MultiToggle crashes with decorated layouts
Tomas Janousek <tomi@nomi.cz>**20091220004733
 Ignore-this: 9208f5da9f0de95464ea62cb45e8f291
 
 The problem was that certain layouts keep their "world" state in their value,
 which was thrown away and forgotten after ReleaseResources during toggle.
 
 In particular, decorated layouts store some X11 handles in them and
 allocate/deallocate it as appropriate. If any modification to their state is
 ignored, they may try to deallocate already deallocated memory, which results
 in a crash somewhere inside Xlib.
 
 This patch makes Transformers reversible so that nothing is ever ignored. As a
 side effect, layout transformers now do receive messages and messages for the
 base layout do not need the undo/reapply cycle -- we just pass messages to the
 current transformed layout and unapply the transformer when needed.
 (This, however, doesn't mean that the base layout is not asked to release
 resources on a transformer change -- we still need the transformer to release
 its resources and there's no way to do this without asking the base layout as
 well.)
] 
[Golf / style change in U.ExtensibleState
Adam Vogt <vogt.adam@gmail.com>**20091208010506
 Ignore-this: c35bd85baae4700e14417ac7e07de959
] 
[Style changes in EwmhDesktops
Adam Vogt <vogt.adam@gmail.com>**20091219003824
 Ignore-this: 905eff9ed951955c8f62617b2d82302e
] 
[Add support for fullscreen through the _NET_WM_STATE protocol
audunskaugen@gmail.com**20091214135119
 Ignore-this: 430ca3c6779e36383f8ce8e477ee9622
 
 This patch adds support for applications using the
 gtk_window_fullscreen function, and other applications using
 _NET_WM_STATE for the same purpose.
] 
[TAG 0.9.1
Spencer Janssen <spencerjanssen@gmail.com>**20091216233651
 Ignore-this: 713d9dd89d775e30346f57a61038d308
] 
[Bump version to 0.9.1
Spencer Janssen <spencerjanssen@gmail.com>**20091216232634
 Ignore-this: bcd799c3341ee6c69a259e1dca747cac
] 
[Match X11 dependencies with xmonad's
Spencer Janssen <spencerjanssen@gmail.com>**20091216012630
 Ignore-this: bcbd6e3e5e2675cdac6f1d1b1bc09853
] 
[Safer X11 version dependency
Spencer Janssen <spencerjanssen@gmail.com>**20091216005916
 Ignore-this: 6dc805a8a0c7a3d3369bc1d6d97d4f56
] 
[Update Prompt for numlockMask changes
Spencer Janssen <spencerjanssen@gmail.com>**20091103222621
 Ignore-this: 4980e2fdf4c296a266590cc4acf76e1e
] 
[X.L.MouseResizableTile: change description for mirrored variant
Tomas Janousek <tomi@nomi.cz>**20091211124218
 Ignore-this: dbc02fb777e35cdc15fb11979c1e983e
 
 The description for mirrored MouseResizableTile is now "Mirror
 MouseResizableTile", to follow the standard of other layouts that can be
 mirrored using the Mirror modifier.
] 
[X.A.GridSelect: documentation typo fix
Tomas Janousek <tomi@nomi.cz>**20091211182515
 Ignore-this: 521bef2a73a9e969d7a96defb555177b
 
 spotted by Justin on IRC
] 
[A.GridSelect shouldn't grab keys if there are no choices.
Adam Vogt <vogt.adam@gmail.com>**20091210183038
 Ignore-this: 48509f780120014a10b32e7289369f32
 
 Thanks thermal2008 in #xmonad for bringing up the corner case when gridselect
 is run with an empty list of choices.
] 
[Added Bluetile's config
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091209150309
 Ignore-this: 641ae527ca6f615e81822b6f38f827e7
] 
[BluetileCommands - a list of commands that Bluetile uses to communicate with its dock
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091208234431
 Ignore-this: 1a5a5e69c7c37d3ffe8d8e09496568de
] 
[onScreen' variation for X () functions
Nils Schweinsberg <mail@n-sch.de>**20091209003717
 Ignore-this: 6a9644c729c2b60f94398260f3640e4d
] 
[Use lookup instead of find in A.PerWorkspaceKeys
Adam Vogt <vogt.adam@gmail.com>**20091129032650
 Ignore-this: 7ecb043df4317365ff3d25b17303eed8
] 
[Change of X.A.OnScreen, more simple and predictable behaviour of onScreen, new functions: toggle(Greedy)OnScreen
Nils Schweinsberg <mail@n-sch.de>**20091207155050
 Ignore-this: c375250778758e401217bcad83567d3b
] 
[Module to ensure that a dragged window always stays in front of all other windows
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091129004506
 Ignore-this: a8a389198ccc28a66686561d4d17e91b
] 
[Decoration that allows to switch the position of windows by dragging them onto each other.
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091129003431
 Ignore-this: 38aff0f3beb1a1eb304219c4f3e85593
] 
[A decoration with small buttons and a supporting module
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091129002416
 Ignore-this: 2d65133bc5b9ad29bad7d06780bdaa4
] 
[XMonad.Actions.Search: finally fixed the internet archive search plugin
gwern0@gmail.com**20091205033435
 Ignore-this: c78ecebced9bc8e39e6077ffa9f9f182
] 
[XMonad.Actions.Search: in retrospect, a bit silly to make everyone go through SSL
gwern0@gmail.com**20091205033318
 Ignore-this: 452b4e6efb83935fc1063ab695ae074d
] 
[Prompt.hs: Corrected quit keybindings
Tim Horton <tmhorton@gmail.com>**20091203050041
 Ignore-this: e8cd2cd1d41f6807f68157ef37c631ea
] 
[Extended decoration module with more hooks and consolidated some existing ones
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091128234310
 Ignore-this: 5a23af3009ecca2feb9a84f8c6f8ac33
] 
[Extended decoration theme to contain extra static text that always appears in the title bar
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091024213928
 Ignore-this: 95f46d6b9ff716a2d8002a426c1012c8
] 
[Extended paintAndWrite to allow for multiple strings to be written into the rectangle
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091024205111
 Ignore-this: eb7d32284b7f98145038dcaa14f8075e
] 
[Added the alignment option 'AlignRightOffset'
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091024204513
 Ignore-this: 58cc00e1be669877e38a97e36b924969
] 
[Prevent windows from being decorated that are too small to contain decoration.
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20090627094316
 Ignore-this: 39b806462bbd424f1206b635e9d506e1
] 
[X.L.MouseResizableTile: keep draggers on the bottom of the window stack.
Tomas Janousek <tomi@nomi.cz>**20091126173413
 Ignore-this: 8089cf8ce53580090b045f4aebb1b899
] 
[Implemented smarter system of managing borders for BorderResize
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091122233651
 Ignore-this: 4775c082249e598a84c79b2e819f28b0
] 
[X.H.DynamicLog: fix xmonadPropLog double-encoding of UTF-8
Tomas Janousek <tomi@nomi.cz>**20091121004829
 Ignore-this: bde612bbd1a19951f9718a03e737c4ac
 
 dynamicLogString utf-8 encodes its output, xmonadPropLog shouldn't do that
 again.
] 
[X.H.DynamicLog: make documentation for 'dzen' and 'xmobar' slightly more clear
Brent Yorgey <byorgey@cis.upenn.edu>**20091121170739
 Ignore-this: c9a241677fda21ef93305fc3882f102e
] 
[X.H.ManageDocks: ignore struts that cover an entire screen on that screen
Tomas Janousek <tomi@nomi.cz>**20091119145043
 Ignore-this: ad7bbf10c49c9f3e938cdc3d8588e202
 
 Imagine a screen layout like this:
 
   11111111
   11111111
   11111111
    222222    <--- xmobar here
    222222
    222222
 
 When placing xmobar as indicated, the partial strut property indicates that an
 entire height of screen 1 is covered by the strut, as well as a few lines at
 the top of screen 2. The original code would create a screen rectangle of
 negative height and wreak havoc. This patch causes such strut to be ignored on
 the screen it covers entirely, resulting in the desired behaviour of a small
 strut at the top of screen 2.
 
 Please note that this semantics of _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL is
 different to what is in wm-spec. The "correct" thing to do would be to discard
 the covered portion of screen 1 leaving two narrow areas at the sides, but
 this new behaviour is probably more desirable in many cases, at least for
 xmonad/xmobar users.
 
 The correct solution of having separate _NET_WM_STRUT_PARTIAL for each
 Xinerama screen was mentioned in wm-spec maillist in 2007, but has never
 really been proposed, discussed and included in wm-spec. Hence this "hack".
] 
[Use imported 'fi' in PositionStoreHooks
Adam Vogt <vogt.adam@gmail.com>**20091119103112
 Ignore-this: 6563a3093083667c79aa491a6f59b805
] 
[Changed interface of X.U.ExtensibleState
Daniel Schoepe <daniel.schoepe@gmail.com>**20091116171013
 Ignore-this: 9a830f9341e461628974890bab0bd65b
 
 Changed the interface of X.U.ExtensibleState to resemble that of
 Control.Monad.State and modified the modules that use it accordingly.
] 
[PositionStoreFloat - a floating layout with support hooks
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091115184833
 Ignore-this: 8b1d0fcef1465356d72cb5f1f32413b6
] 
[PositionStore utility to store information about position and size of a window
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091108195735
 Ignore-this: 2f6e68a490deb75cba5d007b30c93fb2
] 
[X.H.Urgencyhook fix minor doc bug
Anders Engstrom <ankaan@gmail.com>**20091115131121
 Ignore-this: 18b63bccedceb66c77b345a9300f1ac3
] 
[X.H.DynamicLog fix minor indentation oddness
Anders Engstrom <ankaan@gmail.com>**20091115130707
 Ignore-this: 7f2c49eae5527874ca4499767f4167c4
] 
[X.A.CycleWS cycle by tag group
Anders Engstrom <ankaan@gmail.com>**20091115130217
 Ignore-this: 909da8c00b47a31d04f59bd3751c60bc
 Allow grouping of workspaces, so that a user can cycle through those in the same group. Grouping is done by using a special character in the tag.
] 
[Use less short names in X.Prompt
Adam Vogt <vogt.adam@gmail.com>**20091115025647
 Ignore-this: 1d27b8efc4d829a5642717c6f6426336
] 
[Use io instead of liftIO in Prompt
Adam Vogt <vogt.adam@gmail.com>**20091115025301
 Ignore-this: cd4031b74cd5bb874cd2c3cc2cb087f2
] 
['io' and 'fi' are defined outside of Prompt
Adam Vogt <vogt.adam@gmail.com>**20091115024001
 Ignore-this: 3426056362db9cbfde7d2f4edbfe6f36
] 
[Use zipWithM_ instead of recursion in Prompt.printComplList
Adam Vogt <vogt.adam@gmail.com>**20091115023451
 Ignore-this: 2457500ed871ef120653a3d4ada13441
] 
[Minor style changes in DynamicWorkspaces
Adam Vogt <vogt.adam@gmail.com>**20091115022751
 Ignore-this: 1a6018ab134e4420a949354575a8a110
] 
[X.A.DynamicWorkspaces fix doc and add behaviour
Anders Engstrom <ankaan@gmail.com>**20091113233903
 Ignore-this: ab7c20a9c1b43ebc6a7f4700d988fb73
 Before this patch the documentation claims that it won't do anything on non-empty workspaces when it actually does. This patch fixes the documentation to reflect the actual behaviour, but also adds the behaviour promised by the documentation in other functions. It does not break configs. In addition it also provides functions to help removing empty workspaces when leaving them.
] 
[rework XMonad.Util.Dzen
daniel@wagner-home.com**20091114051509
 Ignore-this: 16d93f91c54f7d195b1a418e6c0351c5
] 
[generalize IO actions to MonadIO m => m actions
daniel@wagner-home.com**20091114023616
 Ignore-this: 2c801a27b0ffee34a2f0daca3778613a
 
 This should not cause any working configs to stop working, because IO is an instance of MonadIO, and because complete configs will pin down the type of the call to IO.  Note that XMonad.Config.Arossato is not a complete config, and so it needed some tweaks; with a main function, this should not be a problem.
] 
[fix documentation to match implementation
daniel@wagner-home.com**20091114021328
 Ignore-this: 6dbbb118b139f443c40a573445a48d07
] 
[Bypass more of stringToKeysym in U.Paste
Adam Vogt <vogt.adam@gmail.com>**20091114223726
 Ignore-this: 617c922647e9f49f5ecefa0eb1c65d3c
] 
[Don't erase floating information with H.InsertPosition (Issue 334)
Adam Vogt <vogt.adam@gmail.com>**20091113161402
 Ignore-this: de1c03eb860ea25b390ee5c756b02997
] 
[Rename gridselectViewWorkspace to gridselectWorkspace, add another example.
Adam Vogt <vogt.adam@gmail.com>**20091112211435
 Ignore-this: 462cf1c7f66ab97a1ce642977591a910
 
 The name should be more general to suggest uses other than just viewing other
 workspaces.
] 
[X.A.DynamicWorkspaces: fix addWorkspace and friends so they never add another copy of an existing workspace
Brent Yorgey <byorgey@cis.upenn.edu>**20091112201351
 Ignore-this: 5bfe8129707b038ed04383b7566b2323
] 
[Trim whitespace in H.FloatNext
Adam Vogt <vogt.adam@gmail.com>**20091111022702
 Ignore-this: 1ad52678246fa1ac951169c2356ce10b
] 
[Use ExtensibleState in H.FloatNext
Adam Vogt <vogt.adam@gmail.com>**20091111022513
 Ignore-this: 760d95a685af080466cb4164d1096423
] 
[Make a haddock link direct in C.Desktop.
Adam Vogt <vogt.adam@gmail.com>**20091111013810
 Ignore-this: da724a7974c3de60f49996c1fe92d3fb
] 
[Change A.TopicSpace haddocks to use block quotes.
Adam Vogt <vogt.adam@gmail.com>**20091111013241
 Ignore-this: 6f7f43d2715cfde62b9c05c7d9a0da2
] 
[Add defaultTopicConfig, to allow adding more fields to TopicSpace later.
Adam Vogt <vogt.adam@gmail.com>**20091111012915
 Ignore-this: 6dad95769651a9a1ef8d771f81c91f8e
] 
[X.A.WindowGo: fix haddock markup
Spencer Janssen <spencerjanssen@gmail.com>**20091111003256
 Ignore-this: c6a06de900ca8b67498abf5152e3d9ea
] 
[Minor style corrections in X.U.SpawnOnce
Daniel Schoepe <daniel.schoepe@gmail.com>**20091109201543
 Ignore-this: 1264852c23b4f84b2580bf4567529c68
] 
[Add gridselectViewWorkspace in X.A.GridSelect
Daniel Schoepe <daniel.schoepe@gmail.com>**20091109155815
 Ignore-this: 5543211e9e3fd325cb798b004635a525
] 
[minor-doc-fix-in-ManageHelpers
`Henrique Abreu <hgabreu@gmail.com>'**20091104172727
 Ignore-this: 231ad417541bc3c17a1cb2dff139d55d
] 
[Set buffering to LineBuffering in scripts/xmonadpropread.hs
Daniel Schoepe <daniel.schoepe@gmail.com>**20091108204106
 Ignore-this: 4e593fc1461fbbfb5b147c7c7702584e
 
 (Required for the script to work properly with tools like dzen)
] 
[X.U.ExtensibleState: style
Spencer Janssen <spencerjanssen@gmail.com>**20091108182858
 Ignore-this: f189da75ad2c57ae9cca48eaf69a6bad
] 
[X.A.DynamicWorkspaces: new 'addWorkspacePrompt' method
Brent Yorgey <byorgey@cis.upenn.edu>**20091108170503
 Ignore-this: a3992b1b7938be80d8fd2a5a503a4042
] 
[Remove defaulting when using NoMonomorphismRestriction in H.EwmhDesktops
Adam Vogt <vogt.adam@gmail.com>**20091107195255
 Ignore-this: ca3939842639c94ca4fd1ff6624319c1
] 
[Update A.TopicSpace to use extensible state. No config changes required.
Adam Vogt <vogt.adam@gmail.com>**20091107194502
 Ignore-this: 7a82aad512bb727b3447de0faa4a210f
] 
[Inline tupadd function in A.GridSelect
Adam Vogt <vogt.adam@gmail.com>**20091101190312
 Ignore-this: 458968154303ab865c304f387d6ac83b
] 
[Alphabetize exposed-modules
Spencer Janssen <spencerjanssen@gmail.com>**20091107174946
 Ignore-this: 919684aea7747a756b303f9b34a2870b
] 
[Use X.U.SpawnOnce in my config
Spencer Janssen <spencerjanssen@gmail.com>**20091107174615
 Ignore-this: fe8f5f75136128280942771ec429f09a
] 
[Add XMonad.Util.SpawnOnce
Spencer Janssen <spencerjanssen@gmail.com>**20091107173820
 Ignore-this: 8d4657bbaa8dbeb1d0f9d22293bfef19
] 
[Store deserialized data after reading in X.U.ExtensibleState
Daniel Schoepe <daniel.schoepe@gmail.com>**20091107103832
 Ignore-this: 192beca56e9437292bd3f16451ae9e66
] 
[Fixed conflict between X.U.ExtensibleState and X.C.Sjanssen
Daniel Schoepe <daniel.schoepe@gmail.com>**20091107103619
 Ignore-this: 80f4bb218574d7c528af17473c6e4f66
] 
[Use X.U.ExtensibleState instead of IORefs
Daniel Schoepe <daniel.schoepe@gmail.com>**20091106115601
 Ignore-this: e0e80e31e51dfe76f2b2ed597892cbba
   
 This patch changes SpawnOn, DynamicHooks and UrgencyHooks to
 use X.U.ExtensibleState instead of IORefs. This simplifies the
 usage of those modules thus also breaking current configs.
] 
[Add X.U.ExtensibleState
Daniel Schoepe <daniel.schoepe@gmail.com>**20091106115336
 Ignore-this: d80d9d0c10a53fb71a375e432bd29344
] 
[My config uses xmonadPropLog now
Spencer Janssen <spencerjanssen@gmail.com>**20091107005230
 Ignore-this: 8f16b8bea86dfcd3739f1566f5897578
] 
[Add xmonadpropread script
Spencer Janssen <spencerjanssen@gmail.com>**20091107004858
 Ignore-this: 8cc7ed36ec1126d0139638148f9642e8
] 
[Add experimental xmonadPropLog function
Spencer Janssen <spencerjanssen@gmail.com>**20091107004624
 Ignore-this: f09b2c11b16a3af993b63d1b39566120
] 
[XMonad.Actions.Search: imdb search URL tweak for bug #33
gwern0@gmail.com**20091103222330
 Ignore-this: bae5e6d3ec6c4b6591016ece9dffb202
] 
[Clean imports for L.BoringWindows
Adam Vogt <vogt.adam@gmail.com>**20091103140649
 Ignore-this: 56946a652329390dbdd63746ca23ee8e
] 
[I maintain L.BoringWindows
Adam Vogt <vogt.adam@gmail.com>**20091103140509
 Ignore-this: de853972b4c1c4cefa2dc29e68828d5d
] 
[fix window rectangle calculation in X.A.UpdatePointer
Tomas Janousek <tomi@nomi.cz>**20091026154918
 Ignore-this: ad0c3a020b802854919c7827faa001ad
] 
[Implement hasProperty in terms of runQuery in U.WindowProperties
Adam Vogt <vogt.adam@gmail.com>**20091031154945
 Ignore-this: 1c351bc436e0e323dc25d8f5ff734dcb
 
 This addresses issue 302 for unicode titles by actually using the complicated
 XMonad.ManageHook.title code, instead of reimplementing it with stringProperty
 (which doesn't appear to handle unicode).
] 
[Add functions to access the current input in X.Prompt
Daniel Schoepe <daniel.schoepe@gmail.com>**20091030235033
 Ignore-this: 3f568c1266d85dcaa5722b19bbbd61dd
] 
[Remove putSelection, fixes #317
Spencer Janssen <spencerjanssen@gmail.com>**20091030224354
 Ignore-this: 6cfd6d92e1d133bc9e3cbb7c8339f735
] 
[Fix typo in H.FadeInactive documentation
Adam Vogt <vogt.adam@gmail.com>**20091029165736
 Ignore-this: b2af487cd382416160d5540b7f210464
] 
[X.L.MultiCol constructor 0 NWin bugfig
Anders Engstrom <ankaan@gmail.com>**20091029105633
 Ignore-this: e6a24f581593424461a8675984d14d25
 Fix bug where the constructor did not accept catch-all columns. Also some minor cleaning.
] 
[X.H.ManageHelpers: added currentWs that returns the current workspace
Ismael Carnales <icarnales@gmail.com>**20091028193519
 Ignore-this: dcd3dac6bd741d26747807691f125637
] 
[X.L.MultiColumns bugfix and formating
Anders Engstrom <ankaan@gmail.com>**20091027131741
 Ignore-this: 6978f485d18adb8bf81cf6c8e0d0332
 Fix bug where a column list of insufficient length could be used to find the column of the window. Also fix formating to conform better with standards.
] 
[X.L.MultiColumns NWin shrinkning fix
Anders Engstrom <ankaan@gmail.com>**20091027005932
 Ignore-this: 9ba40ee14ec12c3885173817eac2b564
 Fixed a bug where the list containing the number of windows in each column was allowed the shrink if a column was unused.
] 
[New Layout X.L.MultiColumns
Anders Engstrom <ankaan@gmail.com>**20091024175155
 Ignore-this: a2d3d2eee52c28eab7d125f6b621cada
 New layout inspired the realization that I was switching between Mirror Tall and Mirror ThreeCol depending on how many windows there were on the workspace. This layout will make those changes automatically.
] 
[Changing behaviour of ppUrgent with X.H.DynamicLog
mail@n-sch.de**20090910010411
 Ignore-this: 3882f36d5c49e53628485c1570bf136a
 
 Currently, the ppUrgent method is an addition to the ppHidden method.
 This doesn't make any sense since it is in fact possible to get urgent
 windows on the current and visible screens. So I've raised the ppUrgent
 printer to be above ppCurrent/ppVisible and dropped its dependency on
 ppHidden.
 
 In addition to that this makes it a lot more easier to define a more
 custom ppUrgent printer, since you don't have to "undo" the ppHidden
 printer anymore. This also basicly removes the need for dzenStrip,
 although I just changed the description.
 
 -- McManiaC / Nils
 
] 
[fix X.U.Run.spawnPipe fd leak
Tomas Janousek <tomi@nomi.cz>**20091025210246
 Ignore-this: 24375912d505963fafc917a63d0e79a0
] 
[TAG 0.9
Spencer Janssen <spencerjanssen@gmail.com>**20091026013449
 Ignore-this: 542b6105d6deed65e12d1f91c666b0b2
] 
Patch bundle hash:
d4f77bd4d26bd2d440dda309aa00d9afc5d4055c
From spencerjanssen at gmail.com  Sun Feb 21 18:44:24 2010
From: spencerjanssen at gmail.com (Spencer Janssen)
Date: Sun Feb 21 18:14:26 2010
Subject: [xmonad] [patch] New extension: X.H.ScreenCorners
In-Reply-To: <20100221230652.GA31312@xps>
References: <20100221230652.GA31312@xps>
Message-ID: <20100221234424.GA27484@celeborn>

On Mon, Feb 22, 2010 at 12:06:52AM +0100, Nils wrote:
> Hi,
> 
> I wrote a new extension today which will add KDE like screen corners to
> XMonad. See the documentation of the new module for more informations.
> 
> http://www.n-sch.de/hdocs/xmonad-contrib/XMonad-Hooks-ScreenCorners.html
> 
> Patch is attached.
> 
> 
> Nils Schweinsberg

I think it would be better to create InputOnly windows in the screen corners,
then listen for mouse entry events.  Using mouse motion on the root window
seems fragile.


Cheers,
Spencer Janssen
From Julien.Steinhauser at orange.fr  Sun Feb 21 21:34:54 2010
From: Julien.Steinhauser at orange.fr (julien steinhauser)
Date: Sun Feb 21 21:05:56 2010
Subject: [xmonad] recompile, dzen and togglestruts
Message-ID: <20100222023454.GA18392@eol.dynalias.org>

Hello,

On a fresh XMonad setup, I meet an issue and I'd like wise advices,
wether I'm doing things correctly or not.

I use two dzen, one for views, layout and title on the left
and one for other things on right.

The one on left is launched from within xmonad.hs via spawnpipe
the one on right is lauched from my .xinitrc.

If i make a change in xmonad.hs and want to recompile it,
it compiles silently (no output with xmonad --recompile).

All clients which were already here before the recompile
 won't cover the left dzen anymore after the recompile even
with the mod-b shortcut (dzen stays on top)
but they still cover the dzen on the right. 

All clients launched after the recompile behave the normal way,
until I recompile ...

My xmonad version :
~$ xmonad --version
xmonad 0.9.1
(Source package xmonad and xmonad-contrib from Debian Sid)

I attach my xmonad.hs

I hope this message wasn't too confused.

Julien 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmonad.hs.gz
Type: application/octet-stream
Size: 1557 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/xmonad/attachments/20100221/1a203677/xmonad.hs.obj
From codesite-noreply at google.com  Mon Feb 22 04:03:29 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb 22 03:33:59 2010
Subject: [xmonad] Issue 376 in xmonad: TwinView issues
Message-ID: <0-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 376 by dripstone.blendercn: TwinView issues
http://code.google.com/p/xmonad/issues/detail?id=376

What steps will reproduce the problem?

1. Enable Nvidia TwinView
2. Put some windows on main screen, and some on another screen
3. Switch between different workspaces using mod 1, mod 2 ...

What is the expected output? What do you see instead?
It is easy to get windows messed up. A window which should show on main
screen can jump to another screen.

What version of the product are you using? On what operating system?
0.9


--
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
From Julien.Steinhauser at orange.fr  Mon Feb 22 05:12:26 2010
From: Julien.Steinhauser at orange.fr (julien steinhauser)
Date: Mon Feb 22 04:42:07 2010
Subject: [xmonad] recompile, dzen and togglestruts
In-Reply-To: <20100222023454.GA18392@eol.dynalias.org>
References: <20100222023454.GA18392@eol.dynalias.org>
Message-ID: <20100222101226.GA2798@eol.dynalias.org>

On Mon, Feb 22, 2010 at 03:34:54AM +0100, julien steinhauser wrote:
> Hello,
> 
> On a fresh XMonad setup, I meet an issue and I'd like wise advices,
> wether I'm doing things correctly or not.
> 
> I use two dzen, one for views, layout and title on the left
> and one for other things on right.
> 
> The one on left is launched from within xmonad.hs via spawnpipe
> the one on right is lauched from my .xinitrc.
> 
> If i make a change in xmonad.hs and want to recompile it,
> it compiles silently (no output with xmonad --recompile).
> 
> All clients which were already here before the recompile
>  won't cover the left dzen anymore after the recompile even
> with the mod-b shortcut (dzen stays on top)
> but they still cover the dzen on the right. 
> 
> All clients launched after the recompile behave the normal way,
> until I recompile ...
> 
> My xmonad version :
> ~$ xmonad --version
> xmonad 0.9.1
> (Source package xmonad and xmonad-contrib from Debian Sid)
> 
> I attach my xmonad.hs
> 
> I hope this message wasn't too confused.
> 
> Julien 


> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad

Actually, my xmonad.hs is quite small, I reattached it not gunzipped
for convenience.
Sorry for double posting.

Julien
-------------- next part --------------
A non-text attachment was scrubbed...
Name: xmonad.hs
Type: text/x-haskell
Size: 4666 bytes
Desc: not available
Url : http://www.haskell.org/pipermail/xmonad/attachments/20100222/b21c39e7/xmonad.bin
From ml at n-sch.de  Mon Feb 22 06:32:04 2010
From: ml at n-sch.de (Nils)
Date: Mon Feb 22 06:02:47 2010
Subject: [xmonad] [patch] X.H.ScreenCorners with InputOnly windows
In-Reply-To: <20100221234424.GA27484@celeborn>
References: <20100221230652.GA31312@xps>
 <20100221234424.GA27484@celeborn>
Message-ID: <20100222113204.GA8538@xps>

On Sun, Feb 21, 2010 at 05:44:24PM -0600, Spencer Janssen wrote:
> I think it would be better to create InputOnly windows in the screen corners,
> then listen for mouse entry events.  Using mouse motion on the root window
> seems fragile.

Ok, I've rewritten everything to use InputOnly windows. Patch is
attached. This kinda breaks the old interface of this extension, but I
hope this doesnt matter in this early stage of development. :)
-------------- next part --------------
Mon Feb 22 00:15:50 CET 2010  Nils Schweinsberg <mail@n-sch.de>
  * [patch] X.H.ScreenCorners: move the mouse cursor to avoid loops

Mon Feb 22 12:24:59 CET 2010  Nils Schweinsberg <mail@n-sch.de>
  * X.H.ScreenCorners rewritten to use InputOnly windows instead of waiting for MotionEvents on the root window

New patches:

[[patch] X.H.ScreenCorners: move the mouse cursor to avoid loops
Nils Schweinsberg <mail@n-sch.de>**20100221231550
 Ignore-this: c8d2ece0f6e75aba1b091d5f9de371dc
] {
hunk ./XMonad/Hooks/ScreenCorners.hs 47
         xMax   = displayWidth  dpy screen - 1
         yMax   = displayHeight dpy screen - 1
         pos    = case (ix,iy, corner) of
-                      (0,0, SCUpperLeft)                           -> Just ()
-                      (x,0, SCUpperRight) | x == xMax              -> Just ()
-                      (0,y, SCLowerLeft)  | y == yMax              -> Just ()
-                      (x,y, SCLowerRight) | x == xMax && y == yMax -> Just ()
+                      (0,0, SCUpperLeft)                           -> Just (50, 50)
+                      (x,0, SCUpperRight) | x == xMax              -> Just (x - 50, 50)
+                      (0,y, SCLowerLeft)  | y == yMax              -> Just (50, y - 50)
+                      (x,y, SCLowerRight) | x == xMax && y == yMax -> Just (x - 50, y - 50)
                       _                                            -> Nothing
 
     case pos of
hunk ./XMonad/Hooks/ScreenCorners.hs 54
-         Just _ -> do
+         Just (x,y) -> do
              -- Ignore any MotionEvents
              defaultEventInput
hunk ./XMonad/Hooks/ScreenCorners.hs 57
+             -- move the mouse cursor so we avoid an unwanted loop
+             rootw <- asks theRoot
+             io $ warpPointer dpy none rootw 0 0 0 0 (fromIntegral x) (fromIntegral y)
              -- Run our X ()
              xF
              -- Handle MotionEvents again
}
[X.H.ScreenCorners rewritten to use InputOnly windows instead of waiting for MotionEvents on the root window
Nils Schweinsberg <mail@n-sch.de>**20100222112459
 Ignore-this: f9866d3e3f1ea09ff9e9bb593146f0b3
] {
hunk ./XMonad/Hooks/ScreenCorners.hs 1
+{-# LANGUAGE DeriveDataTypeable #-}
 -----------------------------------------------------------------------------
 -- |
 -- Module      :  XMonad.Hooks.ScreenCorners
hunk ./XMonad/Hooks/ScreenCorners.hs 20
     (
     -- * Usage
     -- $usage
-    -- * Event hook
-      screenCornerEventHook
-    , ScreenCorner (..)
 
hunk ./XMonad/Hooks/ScreenCorners.hs 21
-    -- * X11 input methods
-    , defaultEventInput
-    , adjustEventInput
+    -- * Adding screen corners
+      ScreenCorner (..)
+    , addScreenCorner
+    , addScreenCorners
+
+    -- * Event hook
+    , screenCornerEventHook
     ) where
 
 import Data.Monoid
hunk ./XMonad/Hooks/ScreenCorners.hs 31
-import Foreign.C.Types
-
+import Data.List (find)
 import XMonad
hunk ./XMonad/Hooks/ScreenCorners.hs 33
-import XMonad.Actions.UpdateFocus (adjustEventInput)
+
+import qualified Data.Map as M
+import qualified XMonad.Util.ExtensibleState as XS
 
 data ScreenCorner = SCUpperLeft
                   | SCUpperRight
hunk ./XMonad/Hooks/ScreenCorners.hs 41
                   | SCLowerLeft
                   | SCLowerRight
+                  deriving (Eq, Ord, Show)
+
+
+
+--------------------------------------------------------------------------------
+-- ExtensibleState modifications
+--------------------------------------------------------------------------------
+
+newtype ScreenCornerState = ScreenCornerState (M.Map Window (ScreenCorner, X ()))
+    deriving Typeable
+
+instance ExtensionClass ScreenCornerState where
+    initialValue = ScreenCornerState M.empty
+
+-- | Add one single @X ()@ action to a screen corner
+addScreenCorner :: ScreenCorner -> X () -> X ()
+addScreenCorner corner xF = do
+
+    ScreenCornerState m <- XS.get
+    (win,xFunc) <- case find (\(_,(sc,_)) -> sc == corner) (M.toList m) of
+
+                        Just (w, (_,xF')) -> return (w, xF' >> xF) -- chain X actions
+                        Nothing           -> flip (,) xF `fmap` createWindowAt corner
 
hunk ./XMonad/Hooks/ScreenCorners.hs 65
-inCorner :: ScreenCorner -> X () -> Display -> CInt -> CInt -> X ()
-inCorner corner xF dpy ix iy = do
+    XS.modify $ \(ScreenCornerState m') -> ScreenCornerState $ M.insert win (corner,xFunc) m'
+
+-- | Add a list of @(ScreenCorner, X ())@ tuples
+addScreenCorners :: [ (ScreenCorner, X ()) ] -> X ()
+addScreenCorners = mapM_ (\(corner, xF) -> addScreenCorner corner xF)
+
+
+--------------------------------------------------------------------------------
+-- Xlib functions
+--------------------------------------------------------------------------------
+
+fi :: (Integral a, Num b) => a -> b
+fi = fromIntegral
+
+-- "Translate" a ScreenCorner to real (x,y) Positions
+createWindowAt :: ScreenCorner -> X Window
+createWindowAt SCUpperLeft = createWindowAt' 0 0
+createWindowAt SCUpperRight = withDisplay $ \dpy ->
+    let w = displayWidth  dpy (defaultScreen dpy) - 1
+    in createWindowAt' (fi w) 0
+
+createWindowAt SCLowerLeft = withDisplay $ \dpy ->
+    let h = displayHeight dpy (defaultScreen dpy) - 1
+    in createWindowAt' 0 (fi h)
+
+createWindowAt SCLowerRight = withDisplay $ \dpy ->
+    let w = displayWidth  dpy (defaultScreen dpy) - 1
+        h = displayHeight dpy (defaultScreen dpy) - 1
+    in createWindowAt' (fi w) (fi h)
+
+-- Create a new X window at a (x,y) Position
+createWindowAt' :: Position -> Position -> X Window
+createWindowAt' x y = withDisplay $ \dpy -> io $ do
+
+    rootw <- rootWindow dpy (defaultScreen dpy)
 
     let
hunk ./XMonad/Hooks/ScreenCorners.hs 102
-        screen = defaultScreen dpy
-        xMax   = displayWidth  dpy screen - 1
-        yMax   = displayHeight dpy screen - 1
-        pos    = case (ix,iy, corner) of
-                      (0,0, SCUpperLeft)                           -> Just (50, 50)
-                      (x,0, SCUpperRight) | x == xMax              -> Just (x - 50, 50)
-                      (0,y, SCLowerLeft)  | y == yMax              -> Just (50, y - 50)
-                      (x,y, SCLowerRight) | x == xMax && y == yMax -> Just (x - 50, y - 50)
-                      _                                            -> Nothing
+        visual   = defaultVisualOfScreen $ defaultScreenOfDisplay dpy
+        attrmask = cWOverrideRedirect
+
+    w <- allocaSetWindowAttributes $ \attributes -> do
+
+        set_override_redirect attributes True
+        createWindow dpy        -- display
+                     rootw      -- parent window
+                     x          -- x
+                     y          -- y
+                     1          -- width
+                     1          -- height
+                     0          -- border width
+                     0          -- depth
+                     inputOnly  -- class
+                     visual     -- visual
+                     attrmask   -- valuemask
+                     attributes -- attributes
+
+    -- we only need mouse entry events
+    selectInput dpy w enterWindowMask
+    mapWindow dpy w
+    sync dpy False
+    return w
 
hunk ./XMonad/Hooks/ScreenCorners.hs 127
-    case pos of
-         Just (x,y) -> do
-             -- Ignore any MotionEvents
-             defaultEventInput
-             -- move the mouse cursor so we avoid an unwanted loop
-             rootw <- asks theRoot
-             io $ warpPointer dpy none rootw 0 0 0 0 (fromIntegral x) (fromIntegral y)
-             -- Run our X ()
-             xF
-             -- Handle MotionEvents again
-             adjustEventInput
 
hunk ./XMonad/Hooks/ScreenCorners.hs 128
-         _ -> return ()
+--------------------------------------------------------------------------------
+-- Event hook
+--------------------------------------------------------------------------------
 
hunk ./XMonad/Hooks/ScreenCorners.hs 132
--- | The event hook manager for @ScreenCorners@.
-screenCornerEventHook :: Event -> [(ScreenCorner, X ())] -> X All
-screenCornerEventHook MotionEvent { ev_event_display = dpy, ev_x = ix, ev_y = iy } lis = do
+-- | Handle screen corner events
+screenCornerEventHook :: Event -> X All
+screenCornerEventHook CrossingEvent { ev_window = win } = do
 
hunk ./XMonad/Hooks/ScreenCorners.hs 136
-    mapM_ (\(c,x) -> inCorner c x dpy ix iy) lis
-    return $ All True
+    ScreenCornerState m <- XS.get
 
hunk ./XMonad/Hooks/ScreenCorners.hs 138
-screenCornerEventHook _ _ = return $ All True
+    case M.lookup win m of
+         Just (_, xF) -> xF
+         Nothing      -> return ()
 
hunk ./XMonad/Hooks/ScreenCorners.hs 142
+    return (All True)
 
hunk ./XMonad/Hooks/ScreenCorners.hs 144
--- | Use the default input methods
-defaultEventInput :: X ()
-defaultEventInput = withDisplay $ \dpy -> do
-    rootw <- asks theRoot
-    io $ selectInput dpy rootw $  substructureRedirectMask .|. substructureNotifyMask
-                              .|. enterWindowMask .|. leaveWindowMask .|. structureNotifyMask
-                              .|. buttonPressMask
+screenCornerEventHook _ = return (All True)
 
 
hunk ./XMonad/Hooks/ScreenCorners.hs 147
+--------------------------------------------------------------------------------
 -- $usage
 --
 -- This extension adds KDE-like screen corners to XMonad. By moving your cursor
hunk ./XMonad/Hooks/ScreenCorners.hs 159
 --
 -- > import XMonad.Hooks.ScreenCorners
 --
--- Then add @adjustEventInput@ to your startup hook:
+-- Then add your screen corners in our startup hook:
 --
 -- > myStartupHook = do
 -- >     ...
hunk ./XMonad/Hooks/ScreenCorners.hs 163
--- >     adjustEventInput
+-- >     addScreenCorner SCUpperRight (goToSelected defaultGSConfig { gs_cellwidth = 200})
+-- >     addScreenCorners [ (SCLowerRight, nextWS)
+-- >                      , (SCLowerLeft,  prevWS)
+-- >                      ]
 --
hunk ./XMonad/Hooks/ScreenCorners.hs 168
--- And put your custom ScreenCorners to your event hook:
+-- Then wait for screen corner events in your event hook:
 --
 -- > myEventHook e = do
 -- >     ...
hunk ./XMonad/Hooks/ScreenCorners.hs 172
--- >     screenCornerEventHook e [ (SCUpperRight, goToSelected defaultGSConfig { gs_cellwidth = 200 })
--- >                             , (SCLowerRight, nextWS)
--- >                             , (SCLowerLeft,  prevWS)
--- >                             ]
+-- >     screenCornerEventHook e
}

Context:

[New extension: XMonad.Hooks.ScreenCorners
Nils Schweinsberg <mail@n-sch.de>**20100221230259
 Ignore-this: c3a715e2590ed094ed5908bd225b185e
] 
[documentation for marshallPP
daniel@wagner-home.com**20100215000731
 Ignore-this: efa38829b40dc1586f5f18c4bab21f7d
] 
[DynamicLog support for IndependentScreens
Daniel Wagner <daniel@wagner-home.com>**20100104054251
 Ignore-this: 16fe32f1d66abf4a79f8670131663a60
] 
[minor style changes
Daniel Wagner <daniel@wagner-home.com>**20091228173016
 Ignore-this: 605de753d6a5007751de9d7b9f8ab9ca
] 
[XMonad.Prompt: remove white border from greenXPConfig
gwern0@gmail.com**20100211163641
 Ignore-this: 1cd9a6de02419b7747eab98eb4e84c35
] 
[Fixed reversed history searching direction in X.P.history(Up|Down)Matching
Daniel Schoepe <daniel.schoepe@gmail.com>**20100208162901
 Ignore-this: 61b9907318d18ef2fb5bc633048d3afc
] 
[Compatibility for rename of XMonad.numlockMask
Adam Vogt <vogt.adam@gmail.com>**20100124201955
 Ignore-this: 765c58a8b77ca0b54f05fd69a9bba714
] 
[Use extensible-exceptions to allow base-3 or base-4
Adam Vogt <vogt.adam@gmail.com>**20100124203324
 Ignore-this: 136f35fcc0f3a824b96eea0f4e04f276
] 
[suppress some warnings under ghc 6.12.1 and clean up redundant imports to get rid of some others.
Brent Yorgey <byorgey@cis.upenn.edu>**20100112172507
 Ignore-this: bf3487b27036b02797d9f528a078d006
] 
[Corrected documentation in X.Prompt
Daniel Schoepe <daniel.schoepe@gmail.com>**20100201204522
 Ignore-this: 98f9889a4844bc765cbb9e43bd83bc05
] 
[Use Stack instead of list in X.Prompt.history*Matching
Daniel Schoepe <daniel.schoepe@gmail.com>**20100201202839
 Ignore-this: 45d03c7096949bd250dd1c5c2d3646d4
] 
[BluetileConfig: Fullscreen tweaks and border color change
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20100131233347
 Ignore-this: 2a10959bed0f3fb9985e3dd1010f123b
] 
[A.CycleWindows replace partial rotUp and rotDown with safer versions
Wirt Wolff <wirtwolff@gmail.com>**20100123231912
 Ignore-this: 6b4e40c15b66fc53096910e85e736c23
 Rather than throw exceptions, handle null and singleton lists, i.e.
 f [] gives [] and f [x] gives [x].
] 
[Use <+> instead of explicit M.union to merge keybindings in X.C.*
Adam Vogt <vogt.adam@gmail.com>**20100124202136
 Ignore-this: e7bfd99eb4d3e6735153d1d5ec00a885
] 
[Fix incorrect import suggestion in L.Tabbed (issue 362)
Adam Vogt <vogt.adam@gmail.com>**20100121182501
 Ignore-this: 5e46f140a7e8c2abf0ac75b3262a7da4
] 
[Swap window ordering in L.Accordion (closes Issue 358). Thanks rsaarelm.
Adam Vogt <vogt.adam@gmail.com>**20100121154344
 Ignore-this: cd06b0f4fc85f857307aaae8f6e40af7
 
 This change keeps windows in the same ordering when focus is changed.
] 
[use restart to restart xmonad (no longer bluetile)
Jens Petersen <petersen@haskell.org>**20100116105935
 Ignore-this: e6e27c65e25201fc84bfaf092dad48ac
] 
[X.L.Decoration: avoid flicker by not showing decowins without rectangles
Tomas Janousek <tomi@nomi.cz>**20100116112054
 Ignore-this: 6f38634706c3f35272670b969fc6cc96
 
 These would be hidden by updateDecos immediately after being shown. This
 caused flicker with simpleTabbed and only one window on a workspace.
] 
[Add a way to cycle only through matching history entries in X.Prompt
Daniel Schoepe <daniel.schoepe@gmail.com>**20100113233036
 Ignore-this: d67aedb25f2cc6f329a78d5d3eebdd2b
 
 This patch adds a way go up through X.Prompt's history using
 only those entries that start with the current input, similar
 to zsh's `history-search-backward'.
] 
[Style changes in L.Minimize
Adam Vogt <vogt.adam@gmail.com>**20100104144448
 Ignore-this: 5f64c0717e24ed6cbe2c9fad50bf78a3
] 
[minimize_floating
konstantin.sobolev@gmail.com**20091230070105
 Ignore-this: 2c0e1b94f123a869fb4e72a802e59c2
 Adds floating windows support to X.L.Minimize
] 
[Use more imported cursor constants.
Adam Vogt <vogt.adam@gmail.com>**20091230220927
 Ignore-this: 91e55c63a1d020fafb6b53e6abf9766c
] 
[import new contrib module, X.A.DynamicWorkspaceOrder
Brent Yorgey <byorgey@cis.upenn.edu>**20091230192350
 Ignore-this: bba2c0c30d5554612cc6e8bd59fee205
] 
[X.A.CycleWS: export generalized 'doTo' function for performing an action on a workspace relative to the current one
Brent Yorgey <byorgey@cis.upenn.edu>**20091230191953
 Ignore-this: 7cf8efe7c45b501cbcea0943f667b77e
] 
[new contrib module, X.A.DynamicWorkspaceGroups, for managing groups of workspaces on multi-head setups
Brent Yorgey <byorgey@cis.upenn.edu>**20091229165702
 Ignore-this: fc3e6932a95f57b36b4d8d4cc7f3e2d7
] 
[new contrib module from Tomas Janousek, X.A.WorkspaceNames
Brent Yorgey <byorgey@cis.upenn.edu>**20091229163915
 Ignore-this: 5bc7caaf38647de51949a24498001474
] 
[X.P.Shell, filter empty string from PATH
Tim Horton <tmhorton@gmail.com>**20091224033217
 Ignore-this: 1aec55452f917d0be2bff7fcf5937766
 
 doesDirectoryExist returns True if given an empty string using ghc <= 6.10.4.
 This causes getDirectoryContents to raise an exception and X.P.Shell does not
 render. This is only an issue if you have an empty string in your PATH.
 
 Using ghc == 6.12.1, doesDirectoryExist returns False given an empty string, so
 this should not be an issue in the future.
 
] 
[small tweak to battery logger
Brent Yorgey <byorgey@cis.upenn.edu>**20091227085641
 Ignore-this: 350dfed0cedd250cd9d4bd3391cbe034
] 
[Use imported xC_bottom_right_corner in A.MouseResize
Adam Vogt <vogt.adam@gmail.com>**20091227233705
 Ignore-this: 52794f788255159b91e68f2762c5f6a1
] 
[X.A.MouseResize: assign an appropriate cursor for the resizing inpuwin
Tomas Janousek <tomi@nomi.cz>**20091227212140
 Ignore-this: d9ce96c2cd0312b6b5be4acee30a1da3
] 
[Fix the createSession bug in spawnPipe
Spencer Janssen <spencerjanssen@gmail.com>**20091227003501
 Ignore-this: 2d7f8746eb657036d39f3b9aac22b3c9
 Both the new XMonad.Core.xfork function and spawnPipe call createSession, calling
 this function twice results in an error.
] 
[Let the core know about MouseResizableTile's draggers, so they are stacked correctly
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091223145428
 Ignore-this: 7c096aba6b540ccf9b49c4ee86c6091a
] 
[Update all uses of forkProcess to xfork
Spencer Janssen <spencerjanssen@gmail.com>**20091223064558
 Ignore-this: 963a4ddf1d2f4096bbb8969b173cd0c1
] 
[Make X.L.Minimize explicitly mark minimized windows as boring
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091222214529
 Ignore-this: b1e8adf26ac87dede6c1b7a7d687411c
] 
[Actions/Search: added openstreetmap
intrigeri@boum.org**20091222114545
 Ignore-this: fafc4680c8b59b7a044d995c1dacec9a
] 
[Add a search predicate option to XMonad.Prompt
Mike Lundy <mike@fluffypenguin.org>**20091221025408
 Ignore-this: 8e8804eeb9650d38bc225e15887310da
] 
[In D.Extending note how <+> can be used with keybindings.
Adam Vogt <vogt.adam@gmail.com>**20091220190739
 Ignore-this: ebea8ef8a835ed368fa06621add6519f
] 
[Fix MultiToggle crashes with decorated layouts
Tomas Janousek <tomi@nomi.cz>**20091220004733
 Ignore-this: 9208f5da9f0de95464ea62cb45e8f291
 
 The problem was that certain layouts keep their "world" state in their value,
 which was thrown away and forgotten after ReleaseResources during toggle.
 
 In particular, decorated layouts store some X11 handles in them and
 allocate/deallocate it as appropriate. If any modification to their state is
 ignored, they may try to deallocate already deallocated memory, which results
 in a crash somewhere inside Xlib.
 
 This patch makes Transformers reversible so that nothing is ever ignored. As a
 side effect, layout transformers now do receive messages and messages for the
 base layout do not need the undo/reapply cycle -- we just pass messages to the
 current transformed layout and unapply the transformer when needed.
 (This, however, doesn't mean that the base layout is not asked to release
 resources on a transformer change -- we still need the transformer to release
 its resources and there's no way to do this without asking the base layout as
 well.)
] 
[Golf / style change in U.ExtensibleState
Adam Vogt <vogt.adam@gmail.com>**20091208010506
 Ignore-this: c35bd85baae4700e14417ac7e07de959
] 
[Style changes in EwmhDesktops
Adam Vogt <vogt.adam@gmail.com>**20091219003824
 Ignore-this: 905eff9ed951955c8f62617b2d82302e
] 
[Add support for fullscreen through the _NET_WM_STATE protocol
audunskaugen@gmail.com**20091214135119
 Ignore-this: 430ca3c6779e36383f8ce8e477ee9622
 
 This patch adds support for applications using the
 gtk_window_fullscreen function, and other applications using
 _NET_WM_STATE for the same purpose.
] 
[TAG 0.9.1
Spencer Janssen <spencerjanssen@gmail.com>**20091216233651
 Ignore-this: 713d9dd89d775e30346f57a61038d308
] 
[Bump version to 0.9.1
Spencer Janssen <spencerjanssen@gmail.com>**20091216232634
 Ignore-this: bcd799c3341ee6c69a259e1dca747cac
] 
[Match X11 dependencies with xmonad's
Spencer Janssen <spencerjanssen@gmail.com>**20091216012630
 Ignore-this: bcbd6e3e5e2675cdac6f1d1b1bc09853
] 
[Safer X11 version dependency
Spencer Janssen <spencerjanssen@gmail.com>**20091216005916
 Ignore-this: 6dc805a8a0c7a3d3369bc1d6d97d4f56
] 
[Update Prompt for numlockMask changes
Spencer Janssen <spencerjanssen@gmail.com>**20091103222621
 Ignore-this: 4980e2fdf4c296a266590cc4acf76e1e
] 
[X.L.MouseResizableTile: change description for mirrored variant
Tomas Janousek <tomi@nomi.cz>**20091211124218
 Ignore-this: dbc02fb777e35cdc15fb11979c1e983e
 
 The description for mirrored MouseResizableTile is now "Mirror
 MouseResizableTile", to follow the standard of other layouts that can be
 mirrored using the Mirror modifier.
] 
[X.A.GridSelect: documentation typo fix
Tomas Janousek <tomi@nomi.cz>**20091211182515
 Ignore-this: 521bef2a73a9e969d7a96defb555177b
 
 spotted by Justin on IRC
] 
[A.GridSelect shouldn't grab keys if there are no choices.
Adam Vogt <vogt.adam@gmail.com>**20091210183038
 Ignore-this: 48509f780120014a10b32e7289369f32
 
 Thanks thermal2008 in #xmonad for bringing up the corner case when gridselect
 is run with an empty list of choices.
] 
[Added Bluetile's config
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091209150309
 Ignore-this: 641ae527ca6f615e81822b6f38f827e7
] 
[BluetileCommands - a list of commands that Bluetile uses to communicate with its dock
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091208234431
 Ignore-this: 1a5a5e69c7c37d3ffe8d8e09496568de
] 
[onScreen' variation for X () functions
Nils Schweinsberg <mail@n-sch.de>**20091209003717
 Ignore-this: 6a9644c729c2b60f94398260f3640e4d
] 
[Use lookup instead of find in A.PerWorkspaceKeys
Adam Vogt <vogt.adam@gmail.com>**20091129032650
 Ignore-this: 7ecb043df4317365ff3d25b17303eed8
] 
[Change of X.A.OnScreen, more simple and predictable behaviour of onScreen, new functions: toggle(Greedy)OnScreen
Nils Schweinsberg <mail@n-sch.de>**20091207155050
 Ignore-this: c375250778758e401217bcad83567d3b
] 
[Module to ensure that a dragged window always stays in front of all other windows
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091129004506
 Ignore-this: a8a389198ccc28a66686561d4d17e91b
] 
[Decoration that allows to switch the position of windows by dragging them onto each other.
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091129003431
 Ignore-this: 38aff0f3beb1a1eb304219c4f3e85593
] 
[A decoration with small buttons and a supporting module
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091129002416
 Ignore-this: 2d65133bc5b9ad29bad7d06780bdaa4
] 
[XMonad.Actions.Search: finally fixed the internet archive search plugin
gwern0@gmail.com**20091205033435
 Ignore-this: c78ecebced9bc8e39e6077ffa9f9f182
] 
[XMonad.Actions.Search: in retrospect, a bit silly to make everyone go through SSL
gwern0@gmail.com**20091205033318
 Ignore-this: 452b4e6efb83935fc1063ab695ae074d
] 
[Prompt.hs: Corrected quit keybindings
Tim Horton <tmhorton@gmail.com>**20091203050041
 Ignore-this: e8cd2cd1d41f6807f68157ef37c631ea
] 
[Extended decoration module with more hooks and consolidated some existing ones
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091128234310
 Ignore-this: 5a23af3009ecca2feb9a84f8c6f8ac33
] 
[Extended decoration theme to contain extra static text that always appears in the title bar
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091024213928
 Ignore-this: 95f46d6b9ff716a2d8002a426c1012c8
] 
[Extended paintAndWrite to allow for multiple strings to be written into the rectangle
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091024205111
 Ignore-this: eb7d32284b7f98145038dcaa14f8075e
] 
[Added the alignment option 'AlignRightOffset'
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091024204513
 Ignore-this: 58cc00e1be669877e38a97e36b924969
] 
[Prevent windows from being decorated that are too small to contain decoration.
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20090627094316
 Ignore-this: 39b806462bbd424f1206b635e9d506e1
] 
[X.L.MouseResizableTile: keep draggers on the bottom of the window stack.
Tomas Janousek <tomi@nomi.cz>**20091126173413
 Ignore-this: 8089cf8ce53580090b045f4aebb1b899
] 
[Implemented smarter system of managing borders for BorderResize
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091122233651
 Ignore-this: 4775c082249e598a84c79b2e819f28b0
] 
[X.H.DynamicLog: fix xmonadPropLog double-encoding of UTF-8
Tomas Janousek <tomi@nomi.cz>**20091121004829
 Ignore-this: bde612bbd1a19951f9718a03e737c4ac
 
 dynamicLogString utf-8 encodes its output, xmonadPropLog shouldn't do that
 again.
] 
[X.H.DynamicLog: make documentation for 'dzen' and 'xmobar' slightly more clear
Brent Yorgey <byorgey@cis.upenn.edu>**20091121170739
 Ignore-this: c9a241677fda21ef93305fc3882f102e
] 
[X.H.ManageDocks: ignore struts that cover an entire screen on that screen
Tomas Janousek <tomi@nomi.cz>**20091119145043
 Ignore-this: ad7bbf10c49c9f3e938cdc3d8588e202
 
 Imagine a screen layout like this:
 
   11111111
   11111111
   11111111
    222222    <--- xmobar here
    222222
    222222
 
 When placing xmobar as indicated, the partial strut property indicates that an
 entire height of screen 1 is covered by the strut, as well as a few lines at
 the top of screen 2. The original code would create a screen rectangle of
 negative height and wreak havoc. This patch causes such strut to be ignored on
 the screen it covers entirely, resulting in the desired behaviour of a small
 strut at the top of screen 2.
 
 Please note that this semantics of _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL is
 different to what is in wm-spec. The "correct" thing to do would be to discard
 the covered portion of screen 1 leaving two narrow areas at the sides, but
 this new behaviour is probably more desirable in many cases, at least for
 xmonad/xmobar users.
 
 The correct solution of having separate _NET_WM_STRUT_PARTIAL for each
 Xinerama screen was mentioned in wm-spec maillist in 2007, but has never
 really been proposed, discussed and included in wm-spec. Hence this "hack".
] 
[Use imported 'fi' in PositionStoreHooks
Adam Vogt <vogt.adam@gmail.com>**20091119103112
 Ignore-this: 6563a3093083667c79aa491a6f59b805
] 
[Changed interface of X.U.ExtensibleState
Daniel Schoepe <daniel.schoepe@gmail.com>**20091116171013
 Ignore-this: 9a830f9341e461628974890bab0bd65b
 
 Changed the interface of X.U.ExtensibleState to resemble that of
 Control.Monad.State and modified the modules that use it accordingly.
] 
[PositionStoreFloat - a floating layout with support hooks
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091115184833
 Ignore-this: 8b1d0fcef1465356d72cb5f1f32413b6
] 
[PositionStore utility to store information about position and size of a window
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091108195735
 Ignore-this: 2f6e68a490deb75cba5d007b30c93fb2
] 
[X.H.Urgencyhook fix minor doc bug
Anders Engstrom <ankaan@gmail.com>**20091115131121
 Ignore-this: 18b63bccedceb66c77b345a9300f1ac3
] 
[X.H.DynamicLog fix minor indentation oddness
Anders Engstrom <ankaan@gmail.com>**20091115130707
 Ignore-this: 7f2c49eae5527874ca4499767f4167c4
] 
[X.A.CycleWS cycle by tag group
Anders Engstrom <ankaan@gmail.com>**20091115130217
 Ignore-this: 909da8c00b47a31d04f59bd3751c60bc
 Allow grouping of workspaces, so that a user can cycle through those in the same group. Grouping is done by using a special character in the tag.
] 
[Use less short names in X.Prompt
Adam Vogt <vogt.adam@gmail.com>**20091115025647
 Ignore-this: 1d27b8efc4d829a5642717c6f6426336
] 
[Use io instead of liftIO in Prompt
Adam Vogt <vogt.adam@gmail.com>**20091115025301
 Ignore-this: cd4031b74cd5bb874cd2c3cc2cb087f2
] 
['io' and 'fi' are defined outside of Prompt
Adam Vogt <vogt.adam@gmail.com>**20091115024001
 Ignore-this: 3426056362db9cbfde7d2f4edbfe6f36
] 
[Use zipWithM_ instead of recursion in Prompt.printComplList
Adam Vogt <vogt.adam@gmail.com>**20091115023451
 Ignore-this: 2457500ed871ef120653a3d4ada13441
] 
[Minor style changes in DynamicWorkspaces
Adam Vogt <vogt.adam@gmail.com>**20091115022751
 Ignore-this: 1a6018ab134e4420a949354575a8a110
] 
[X.A.DynamicWorkspaces fix doc and add behaviour
Anders Engstrom <ankaan@gmail.com>**20091113233903
 Ignore-this: ab7c20a9c1b43ebc6a7f4700d988fb73
 Before this patch the documentation claims that it won't do anything on non-empty workspaces when it actually does. This patch fixes the documentation to reflect the actual behaviour, but also adds the behaviour promised by the documentation in other functions. It does not break configs. In addition it also provides functions to help removing empty workspaces when leaving them.
] 
[rework XMonad.Util.Dzen
daniel@wagner-home.com**20091114051509
 Ignore-this: 16d93f91c54f7d195b1a418e6c0351c5
] 
[generalize IO actions to MonadIO m => m actions
daniel@wagner-home.com**20091114023616
 Ignore-this: 2c801a27b0ffee34a2f0daca3778613a
 
 This should not cause any working configs to stop working, because IO is an instance of MonadIO, and because complete configs will pin down the type of the call to IO.  Note that XMonad.Config.Arossato is not a complete config, and so it needed some tweaks; with a main function, this should not be a problem.
] 
[fix documentation to match implementation
daniel@wagner-home.com**20091114021328
 Ignore-this: 6dbbb118b139f443c40a573445a48d07
] 
[Bypass more of stringToKeysym in U.Paste
Adam Vogt <vogt.adam@gmail.com>**20091114223726
 Ignore-this: 617c922647e9f49f5ecefa0eb1c65d3c
] 
[Don't erase floating information with H.InsertPosition (Issue 334)
Adam Vogt <vogt.adam@gmail.com>**20091113161402
 Ignore-this: de1c03eb860ea25b390ee5c756b02997
] 
[Rename gridselectViewWorkspace to gridselectWorkspace, add another example.
Adam Vogt <vogt.adam@gmail.com>**20091112211435
 Ignore-this: 462cf1c7f66ab97a1ce642977591a910
 
 The name should be more general to suggest uses other than just viewing other
 workspaces.
] 
[X.A.DynamicWorkspaces: fix addWorkspace and friends so they never add another copy of an existing workspace
Brent Yorgey <byorgey@cis.upenn.edu>**20091112201351
 Ignore-this: 5bfe8129707b038ed04383b7566b2323
] 
[Trim whitespace in H.FloatNext
Adam Vogt <vogt.adam@gmail.com>**20091111022702
 Ignore-this: 1ad52678246fa1ac951169c2356ce10b
] 
[Use ExtensibleState in H.FloatNext
Adam Vogt <vogt.adam@gmail.com>**20091111022513
 Ignore-this: 760d95a685af080466cb4164d1096423
] 
[Make a haddock link direct in C.Desktop.
Adam Vogt <vogt.adam@gmail.com>**20091111013810
 Ignore-this: da724a7974c3de60f49996c1fe92d3fb
] 
[Change A.TopicSpace haddocks to use block quotes.
Adam Vogt <vogt.adam@gmail.com>**20091111013241
 Ignore-this: 6f7f43d2715cfde62b9c05c7d9a0da2
] 
[Add defaultTopicConfig, to allow adding more fields to TopicSpace later.
Adam Vogt <vogt.adam@gmail.com>**20091111012915
 Ignore-this: 6dad95769651a9a1ef8d771f81c91f8e
] 
[X.A.WindowGo: fix haddock markup
Spencer Janssen <spencerjanssen@gmail.com>**20091111003256
 Ignore-this: c6a06de900ca8b67498abf5152e3d9ea
] 
[Minor style corrections in X.U.SpawnOnce
Daniel Schoepe <daniel.schoepe@gmail.com>**20091109201543
 Ignore-this: 1264852c23b4f84b2580bf4567529c68
] 
[Add gridselectViewWorkspace in X.A.GridSelect
Daniel Schoepe <daniel.schoepe@gmail.com>**20091109155815
 Ignore-this: 5543211e9e3fd325cb798b004635a525
] 
[minor-doc-fix-in-ManageHelpers
`Henrique Abreu <hgabreu@gmail.com>'**20091104172727
 Ignore-this: 231ad417541bc3c17a1cb2dff139d55d
] 
[Set buffering to LineBuffering in scripts/xmonadpropread.hs
Daniel Schoepe <daniel.schoepe@gmail.com>**20091108204106
 Ignore-this: 4e593fc1461fbbfb5b147c7c7702584e
 
 (Required for the script to work properly with tools like dzen)
] 
[X.U.ExtensibleState: style
Spencer Janssen <spencerjanssen@gmail.com>**20091108182858
 Ignore-this: f189da75ad2c57ae9cca48eaf69a6bad
] 
[X.A.DynamicWorkspaces: new 'addWorkspacePrompt' method
Brent Yorgey <byorgey@cis.upenn.edu>**20091108170503
 Ignore-this: a3992b1b7938be80d8fd2a5a503a4042
] 
[Remove defaulting when using NoMonomorphismRestriction in H.EwmhDesktops
Adam Vogt <vogt.adam@gmail.com>**20091107195255
 Ignore-this: ca3939842639c94ca4fd1ff6624319c1
] 
[Update A.TopicSpace to use extensible state. No config changes required.
Adam Vogt <vogt.adam@gmail.com>**20091107194502
 Ignore-this: 7a82aad512bb727b3447de0faa4a210f
] 
[Inline tupadd function in A.GridSelect
Adam Vogt <vogt.adam@gmail.com>**20091101190312
 Ignore-this: 458968154303ab865c304f387d6ac83b
] 
[Alphabetize exposed-modules
Spencer Janssen <spencerjanssen@gmail.com>**20091107174946
 Ignore-this: 919684aea7747a756b303f9b34a2870b
] 
[Use X.U.SpawnOnce in my config
Spencer Janssen <spencerjanssen@gmail.com>**20091107174615
 Ignore-this: fe8f5f75136128280942771ec429f09a
] 
[Add XMonad.Util.SpawnOnce
Spencer Janssen <spencerjanssen@gmail.com>**20091107173820
 Ignore-this: 8d4657bbaa8dbeb1d0f9d22293bfef19
] 
[Store deserialized data after reading in X.U.ExtensibleState
Daniel Schoepe <daniel.schoepe@gmail.com>**20091107103832
 Ignore-this: 192beca56e9437292bd3f16451ae9e66
] 
[Fixed conflict between X.U.ExtensibleState and X.C.Sjanssen
Daniel Schoepe <daniel.schoepe@gmail.com>**20091107103619
 Ignore-this: 80f4bb218574d7c528af17473c6e4f66
] 
[Use X.U.ExtensibleState instead of IORefs
Daniel Schoepe <daniel.schoepe@gmail.com>**20091106115601
 Ignore-this: e0e80e31e51dfe76f2b2ed597892cbba
   
 This patch changes SpawnOn, DynamicHooks and UrgencyHooks to
 use X.U.ExtensibleState instead of IORefs. This simplifies the
 usage of those modules thus also breaking current configs.
] 
[Add X.U.ExtensibleState
Daniel Schoepe <daniel.schoepe@gmail.com>**20091106115336
 Ignore-this: d80d9d0c10a53fb71a375e432bd29344
] 
[My config uses xmonadPropLog now
Spencer Janssen <spencerjanssen@gmail.com>**20091107005230
 Ignore-this: 8f16b8bea86dfcd3739f1566f5897578
] 
[Add xmonadpropread script
Spencer Janssen <spencerjanssen@gmail.com>**20091107004858
 Ignore-this: 8cc7ed36ec1126d0139638148f9642e8
] 
[Add experimental xmonadPropLog function
Spencer Janssen <spencerjanssen@gmail.com>**20091107004624
 Ignore-this: f09b2c11b16a3af993b63d1b39566120
] 
[XMonad.Actions.Search: imdb search URL tweak for bug #33
gwern0@gmail.com**20091103222330
 Ignore-this: bae5e6d3ec6c4b6591016ece9dffb202
] 
[Clean imports for L.BoringWindows
Adam Vogt <vogt.adam@gmail.com>**20091103140649
 Ignore-this: 56946a652329390dbdd63746ca23ee8e
] 
[I maintain L.BoringWindows
Adam Vogt <vogt.adam@gmail.com>**20091103140509
 Ignore-this: de853972b4c1c4cefa2dc29e68828d5d
] 
[fix window rectangle calculation in X.A.UpdatePointer
Tomas Janousek <tomi@nomi.cz>**20091026154918
 Ignore-this: ad0c3a020b802854919c7827faa001ad
] 
[Implement hasProperty in terms of runQuery in U.WindowProperties
Adam Vogt <vogt.adam@gmail.com>**20091031154945
 Ignore-this: 1c351bc436e0e323dc25d8f5ff734dcb
 
 This addresses issue 302 for unicode titles by actually using the complicated
 XMonad.ManageHook.title code, instead of reimplementing it with stringProperty
 (which doesn't appear to handle unicode).
] 
[Add functions to access the current input in X.Prompt
Daniel Schoepe <daniel.schoepe@gmail.com>**20091030235033
 Ignore-this: 3f568c1266d85dcaa5722b19bbbd61dd
] 
[Remove putSelection, fixes #317
Spencer Janssen <spencerjanssen@gmail.com>**20091030224354
 Ignore-this: 6cfd6d92e1d133bc9e3cbb7c8339f735
] 
[Fix typo in H.FadeInactive documentation
Adam Vogt <vogt.adam@gmail.com>**20091029165736
 Ignore-this: b2af487cd382416160d5540b7f210464
] 
[X.L.MultiCol constructor 0 NWin bugfig
Anders Engstrom <ankaan@gmail.com>**20091029105633
 Ignore-this: e6a24f581593424461a8675984d14d25
 Fix bug where the constructor did not accept catch-all columns. Also some minor cleaning.
] 
[X.H.ManageHelpers: added currentWs that returns the current workspace
Ismael Carnales <icarnales@gmail.com>**20091028193519
 Ignore-this: dcd3dac6bd741d26747807691f125637
] 
[X.L.MultiColumns bugfix and formating
Anders Engstrom <ankaan@gmail.com>**20091027131741
 Ignore-this: 6978f485d18adb8bf81cf6c8e0d0332
 Fix bug where a column list of insufficient length could be used to find the column of the window. Also fix formating to conform better with standards.
] 
[X.L.MultiColumns NWin shrinkning fix
Anders Engstrom <ankaan@gmail.com>**20091027005932
 Ignore-this: 9ba40ee14ec12c3885173817eac2b564
 Fixed a bug where the list containing the number of windows in each column was allowed the shrink if a column was unused.
] 
[New Layout X.L.MultiColumns
Anders Engstrom <ankaan@gmail.com>**20091024175155
 Ignore-this: a2d3d2eee52c28eab7d125f6b621cada
 New layout inspired the realization that I was switching between Mirror Tall and Mirror ThreeCol depending on how many windows there were on the workspace. This layout will make those changes automatically.
] 
[Changing behaviour of ppUrgent with X.H.DynamicLog
mail@n-sch.de**20090910010411
 Ignore-this: 3882f36d5c49e53628485c1570bf136a
 
 Currently, the ppUrgent method is an addition to the ppHidden method.
 This doesn't make any sense since it is in fact possible to get urgent
 windows on the current and visible screens. So I've raised the ppUrgent
 printer to be above ppCurrent/ppVisible and dropped its dependency on
 ppHidden.
 
 In addition to that this makes it a lot more easier to define a more
 custom ppUrgent printer, since you don't have to "undo" the ppHidden
 printer anymore. This also basicly removes the need for dzenStrip,
 although I just changed the description.
 
 -- McManiaC / Nils
 
] 
[fix X.U.Run.spawnPipe fd leak
Tomas Janousek <tomi@nomi.cz>**20091025210246
 Ignore-this: 24375912d505963fafc917a63d0e79a0
] 
[TAG 0.9
Spencer Janssen <spencerjanssen@gmail.com>**20091026013449
 Ignore-this: 542b6105d6deed65e12d1f91c666b0b2
] 
Patch bundle hash:
5000fa410e80b5cea1d309a32ddf60ee2efbfbff
From ml at n-sch.de  Mon Feb 22 06:53:58 2010
From: ml at n-sch.de (Nils)
Date: Mon Feb 22 06:24:39 2010
Subject: [xmonad] [patch] Fixed typos
In-Reply-To: <20100222113204.GA8538@xps>
References: <20100221230652.GA31312@xps> <20100221234424.GA27484@celeborn>
	<20100222113204.GA8538@xps>
Message-ID: <20100222115358.GA11285@xps>

Sorry? Got another patch which will fix some typos. I really should have
taken a closer look *before* sending these patches. :)
-------------- next part --------------
Mon Feb 22 12:51:42 CET 2010  Nils Schweinsberg <mail@n-sch.de>
  * X.H.ScreenCorners typos

New patches:

[X.H.ScreenCorners typos
Nils Schweinsberg <mail@n-sch.de>**20100222115142
 Ignore-this: 805ba06f6215bb83a68631f750743830
] {
hunk ./XMonad/Hooks/ScreenCorners.hs 12
 -- Stability   :  unstable
 -- Portability :  unportable
 --
--- Run @X ()@ actions by touching the edge of your screen the your mouse.
+-- Run @X ()@ actions by touching the edge of your screen with your mouse.
 --
 -----------------------------------------------------------------------------
 
hunk ./XMonad/Hooks/ScreenCorners.hs 152
 --
 -- This extension adds KDE-like screen corners to XMonad. By moving your cursor
 -- into one of your screen corners you can trigger an @X ()@ action, for
--- example "XMonad.Actions.GridSelect".gotoSelected or
--- "XMonad.Actions.CycleWS".nextWS etc.
+-- example @"XMonad.Actions.GridSelect".goToSelected@ or
+-- @"XMonad.Actions.CycleWS".nextWS@ etc.
 --
 -- To use it, import it on top of your @xmonad.hs@:
 --
hunk ./XMonad/Hooks/ScreenCorners.hs 168
 -- >                      , (SCLowerLeft,  prevWS)
 -- >                      ]
 --
--- Then wait for screen corner events in your event hook:
+-- And finally wait for screen corner events in your event hook:
 --
 -- > myEventHook e = do
 -- >     ...
}

Context:

[Prevent possible pattern match failure in X.A.UpdateFocus
Daniel Schoepe <daniel.schoepe@gmail.com>**20100221234735
 Ignore-this: fe132d248db01076a1038e9e8acbdf42
] 
[X.H.ScreenCorners rewritten to use InputOnly windows instead of waiting for MotionEvents on the root window
Nils Schweinsberg <mail@n-sch.de>**20100222112459
 Ignore-this: f9866d3e3f1ea09ff9e9bb593146f0b3
] 
[[patch] X.H.ScreenCorners: move the mouse cursor to avoid loops
Nils Schweinsberg <mail@n-sch.de>**20100221231550
 Ignore-this: c8d2ece0f6e75aba1b091d5f9de371dc
] 
[New extension: XMonad.Hooks.ScreenCorners
Nils Schweinsberg <mail@n-sch.de>**20100221230259
 Ignore-this: c3a715e2590ed094ed5908bd225b185e
] 
[documentation for marshallPP
daniel@wagner-home.com**20100215000731
 Ignore-this: efa38829b40dc1586f5f18c4bab21f7d
] 
[DynamicLog support for IndependentScreens
Daniel Wagner <daniel@wagner-home.com>**20100104054251
 Ignore-this: 16fe32f1d66abf4a79f8670131663a60
] 
[minor style changes
Daniel Wagner <daniel@wagner-home.com>**20091228173016
 Ignore-this: 605de753d6a5007751de9d7b9f8ab9ca
] 
[XMonad.Prompt: remove white border from greenXPConfig
gwern0@gmail.com**20100211163641
 Ignore-this: 1cd9a6de02419b7747eab98eb4e84c35
] 
[Fixed reversed history searching direction in X.P.history(Up|Down)Matching
Daniel Schoepe <daniel.schoepe@gmail.com>**20100208162901
 Ignore-this: 61b9907318d18ef2fb5bc633048d3afc
] 
[Compatibility for rename of XMonad.numlockMask
Adam Vogt <vogt.adam@gmail.com>**20100124201955
 Ignore-this: 765c58a8b77ca0b54f05fd69a9bba714
] 
[Use extensible-exceptions to allow base-3 or base-4
Adam Vogt <vogt.adam@gmail.com>**20100124203324
 Ignore-this: 136f35fcc0f3a824b96eea0f4e04f276
] 
[suppress some warnings under ghc 6.12.1 and clean up redundant imports to get rid of some others.
Brent Yorgey <byorgey@cis.upenn.edu>**20100112172507
 Ignore-this: bf3487b27036b02797d9f528a078d006
] 
[Corrected documentation in X.Prompt
Daniel Schoepe <daniel.schoepe@gmail.com>**20100201204522
 Ignore-this: 98f9889a4844bc765cbb9e43bd83bc05
] 
[Use Stack instead of list in X.Prompt.history*Matching
Daniel Schoepe <daniel.schoepe@gmail.com>**20100201202839
 Ignore-this: 45d03c7096949bd250dd1c5c2d3646d4
] 
[BluetileConfig: Fullscreen tweaks and border color change
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20100131233347
 Ignore-this: 2a10959bed0f3fb9985e3dd1010f123b
] 
[A.CycleWindows replace partial rotUp and rotDown with safer versions
Wirt Wolff <wirtwolff@gmail.com>**20100123231912
 Ignore-this: 6b4e40c15b66fc53096910e85e736c23
 Rather than throw exceptions, handle null and singleton lists, i.e.
 f [] gives [] and f [x] gives [x].
] 
[Use <+> instead of explicit M.union to merge keybindings in X.C.*
Adam Vogt <vogt.adam@gmail.com>**20100124202136
 Ignore-this: e7bfd99eb4d3e6735153d1d5ec00a885
] 
[Fix incorrect import suggestion in L.Tabbed (issue 362)
Adam Vogt <vogt.adam@gmail.com>**20100121182501
 Ignore-this: 5e46f140a7e8c2abf0ac75b3262a7da4
] 
[Swap window ordering in L.Accordion (closes Issue 358). Thanks rsaarelm.
Adam Vogt <vogt.adam@gmail.com>**20100121154344
 Ignore-this: cd06b0f4fc85f857307aaae8f6e40af7
 
 This change keeps windows in the same ordering when focus is changed.
] 
[use restart to restart xmonad (no longer bluetile)
Jens Petersen <petersen@haskell.org>**20100116105935
 Ignore-this: e6e27c65e25201fc84bfaf092dad48ac
] 
[X.L.Decoration: avoid flicker by not showing decowins without rectangles
Tomas Janousek <tomi@nomi.cz>**20100116112054
 Ignore-this: 6f38634706c3f35272670b969fc6cc96
 
 These would be hidden by updateDecos immediately after being shown. This
 caused flicker with simpleTabbed and only one window on a workspace.
] 
[Add a way to cycle only through matching history entries in X.Prompt
Daniel Schoepe <daniel.schoepe@gmail.com>**20100113233036
 Ignore-this: d67aedb25f2cc6f329a78d5d3eebdd2b
 
 This patch adds a way go up through X.Prompt's history using
 only those entries that start with the current input, similar
 to zsh's `history-search-backward'.
] 
[Style changes in L.Minimize
Adam Vogt <vogt.adam@gmail.com>**20100104144448
 Ignore-this: 5f64c0717e24ed6cbe2c9fad50bf78a3
] 
[minimize_floating
konstantin.sobolev@gmail.com**20091230070105
 Ignore-this: 2c0e1b94f123a869fb4e72a802e59c2
 Adds floating windows support to X.L.Minimize
] 
[Use more imported cursor constants.
Adam Vogt <vogt.adam@gmail.com>**20091230220927
 Ignore-this: 91e55c63a1d020fafb6b53e6abf9766c
] 
[import new contrib module, X.A.DynamicWorkspaceOrder
Brent Yorgey <byorgey@cis.upenn.edu>**20091230192350
 Ignore-this: bba2c0c30d5554612cc6e8bd59fee205
] 
[X.A.CycleWS: export generalized 'doTo' function for performing an action on a workspace relative to the current one
Brent Yorgey <byorgey@cis.upenn.edu>**20091230191953
 Ignore-this: 7cf8efe7c45b501cbcea0943f667b77e
] 
[new contrib module, X.A.DynamicWorkspaceGroups, for managing groups of workspaces on multi-head setups
Brent Yorgey <byorgey@cis.upenn.edu>**20091229165702
 Ignore-this: fc3e6932a95f57b36b4d8d4cc7f3e2d7
] 
[new contrib module from Tomas Janousek, X.A.WorkspaceNames
Brent Yorgey <byorgey@cis.upenn.edu>**20091229163915
 Ignore-this: 5bc7caaf38647de51949a24498001474
] 
[X.P.Shell, filter empty string from PATH
Tim Horton <tmhorton@gmail.com>**20091224033217
 Ignore-this: 1aec55452f917d0be2bff7fcf5937766
 
 doesDirectoryExist returns True if given an empty string using ghc <= 6.10.4.
 This causes getDirectoryContents to raise an exception and X.P.Shell does not
 render. This is only an issue if you have an empty string in your PATH.
 
 Using ghc == 6.12.1, doesDirectoryExist returns False given an empty string, so
 this should not be an issue in the future.
 
] 
[small tweak to battery logger
Brent Yorgey <byorgey@cis.upenn.edu>**20091227085641
 Ignore-this: 350dfed0cedd250cd9d4bd3391cbe034
] 
[Use imported xC_bottom_right_corner in A.MouseResize
Adam Vogt <vogt.adam@gmail.com>**20091227233705
 Ignore-this: 52794f788255159b91e68f2762c5f6a1
] 
[X.A.MouseResize: assign an appropriate cursor for the resizing inpuwin
Tomas Janousek <tomi@nomi.cz>**20091227212140
 Ignore-this: d9ce96c2cd0312b6b5be4acee30a1da3
] 
[Fix the createSession bug in spawnPipe
Spencer Janssen <spencerjanssen@gmail.com>**20091227003501
 Ignore-this: 2d7f8746eb657036d39f3b9aac22b3c9
 Both the new XMonad.Core.xfork function and spawnPipe call createSession, calling
 this function twice results in an error.
] 
[Let the core know about MouseResizableTile's draggers, so they are stacked correctly
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091223145428
 Ignore-this: 7c096aba6b540ccf9b49c4ee86c6091a
] 
[Update all uses of forkProcess to xfork
Spencer Janssen <spencerjanssen@gmail.com>**20091223064558
 Ignore-this: 963a4ddf1d2f4096bbb8969b173cd0c1
] 
[Make X.L.Minimize explicitly mark minimized windows as boring
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091222214529
 Ignore-this: b1e8adf26ac87dede6c1b7a7d687411c
] 
[Actions/Search: added openstreetmap
intrigeri@boum.org**20091222114545
 Ignore-this: fafc4680c8b59b7a044d995c1dacec9a
] 
[Add a search predicate option to XMonad.Prompt
Mike Lundy <mike@fluffypenguin.org>**20091221025408
 Ignore-this: 8e8804eeb9650d38bc225e15887310da
] 
[In D.Extending note how <+> can be used with keybindings.
Adam Vogt <vogt.adam@gmail.com>**20091220190739
 Ignore-this: ebea8ef8a835ed368fa06621add6519f
] 
[Fix MultiToggle crashes with decorated layouts
Tomas Janousek <tomi@nomi.cz>**20091220004733
 Ignore-this: 9208f5da9f0de95464ea62cb45e8f291
 
 The problem was that certain layouts keep their "world" state in their value,
 which was thrown away and forgotten after ReleaseResources during toggle.
 
 In particular, decorated layouts store some X11 handles in them and
 allocate/deallocate it as appropriate. If any modification to their state is
 ignored, they may try to deallocate already deallocated memory, which results
 in a crash somewhere inside Xlib.
 
 This patch makes Transformers reversible so that nothing is ever ignored. As a
 side effect, layout transformers now do receive messages and messages for the
 base layout do not need the undo/reapply cycle -- we just pass messages to the
 current transformed layout and unapply the transformer when needed.
 (This, however, doesn't mean that the base layout is not asked to release
 resources on a transformer change -- we still need the transformer to release
 its resources and there's no way to do this without asking the base layout as
 well.)
] 
[Golf / style change in U.ExtensibleState
Adam Vogt <vogt.adam@gmail.com>**20091208010506
 Ignore-this: c35bd85baae4700e14417ac7e07de959
] 
[Style changes in EwmhDesktops
Adam Vogt <vogt.adam@gmail.com>**20091219003824
 Ignore-this: 905eff9ed951955c8f62617b2d82302e
] 
[Add support for fullscreen through the _NET_WM_STATE protocol
audunskaugen@gmail.com**20091214135119
 Ignore-this: 430ca3c6779e36383f8ce8e477ee9622
 
 This patch adds support for applications using the
 gtk_window_fullscreen function, and other applications using
 _NET_WM_STATE for the same purpose.
] 
[TAG 0.9.1
Spencer Janssen <spencerjanssen@gmail.com>**20091216233651
 Ignore-this: 713d9dd89d775e30346f57a61038d308
] 
[Bump version to 0.9.1
Spencer Janssen <spencerjanssen@gmail.com>**20091216232634
 Ignore-this: bcd799c3341ee6c69a259e1dca747cac
] 
[Match X11 dependencies with xmonad's
Spencer Janssen <spencerjanssen@gmail.com>**20091216012630
 Ignore-this: bcbd6e3e5e2675cdac6f1d1b1bc09853
] 
[Safer X11 version dependency
Spencer Janssen <spencerjanssen@gmail.com>**20091216005916
 Ignore-this: 6dc805a8a0c7a3d3369bc1d6d97d4f56
] 
[Update Prompt for numlockMask changes
Spencer Janssen <spencerjanssen@gmail.com>**20091103222621
 Ignore-this: 4980e2fdf4c296a266590cc4acf76e1e
] 
[X.L.MouseResizableTile: change description for mirrored variant
Tomas Janousek <tomi@nomi.cz>**20091211124218
 Ignore-this: dbc02fb777e35cdc15fb11979c1e983e
 
 The description for mirrored MouseResizableTile is now "Mirror
 MouseResizableTile", to follow the standard of other layouts that can be
 mirrored using the Mirror modifier.
] 
[X.A.GridSelect: documentation typo fix
Tomas Janousek <tomi@nomi.cz>**20091211182515
 Ignore-this: 521bef2a73a9e969d7a96defb555177b
 
 spotted by Justin on IRC
] 
[A.GridSelect shouldn't grab keys if there are no choices.
Adam Vogt <vogt.adam@gmail.com>**20091210183038
 Ignore-this: 48509f780120014a10b32e7289369f32
 
 Thanks thermal2008 in #xmonad for bringing up the corner case when gridselect
 is run with an empty list of choices.
] 
[Added Bluetile's config
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091209150309
 Ignore-this: 641ae527ca6f615e81822b6f38f827e7
] 
[BluetileCommands - a list of commands that Bluetile uses to communicate with its dock
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091208234431
 Ignore-this: 1a5a5e69c7c37d3ffe8d8e09496568de
] 
[onScreen' variation for X () functions
Nils Schweinsberg <mail@n-sch.de>**20091209003717
 Ignore-this: 6a9644c729c2b60f94398260f3640e4d
] 
[Use lookup instead of find in A.PerWorkspaceKeys
Adam Vogt <vogt.adam@gmail.com>**20091129032650
 Ignore-this: 7ecb043df4317365ff3d25b17303eed8
] 
[Change of X.A.OnScreen, more simple and predictable behaviour of onScreen, new functions: toggle(Greedy)OnScreen
Nils Schweinsberg <mail@n-sch.de>**20091207155050
 Ignore-this: c375250778758e401217bcad83567d3b
] 
[Module to ensure that a dragged window always stays in front of all other windows
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091129004506
 Ignore-this: a8a389198ccc28a66686561d4d17e91b
] 
[Decoration that allows to switch the position of windows by dragging them onto each other.
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091129003431
 Ignore-this: 38aff0f3beb1a1eb304219c4f3e85593
] 
[A decoration with small buttons and a supporting module
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091129002416
 Ignore-this: 2d65133bc5b9ad29bad7d06780bdaa4
] 
[XMonad.Actions.Search: finally fixed the internet archive search plugin
gwern0@gmail.com**20091205033435
 Ignore-this: c78ecebced9bc8e39e6077ffa9f9f182
] 
[XMonad.Actions.Search: in retrospect, a bit silly to make everyone go through SSL
gwern0@gmail.com**20091205033318
 Ignore-this: 452b4e6efb83935fc1063ab695ae074d
] 
[Prompt.hs: Corrected quit keybindings
Tim Horton <tmhorton@gmail.com>**20091203050041
 Ignore-this: e8cd2cd1d41f6807f68157ef37c631ea
] 
[Extended decoration module with more hooks and consolidated some existing ones
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091128234310
 Ignore-this: 5a23af3009ecca2feb9a84f8c6f8ac33
] 
[Extended decoration theme to contain extra static text that always appears in the title bar
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091024213928
 Ignore-this: 95f46d6b9ff716a2d8002a426c1012c8
] 
[Extended paintAndWrite to allow for multiple strings to be written into the rectangle
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091024205111
 Ignore-this: eb7d32284b7f98145038dcaa14f8075e
] 
[Added the alignment option 'AlignRightOffset'
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091024204513
 Ignore-this: 58cc00e1be669877e38a97e36b924969
] 
[Prevent windows from being decorated that are too small to contain decoration.
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20090627094316
 Ignore-this: 39b806462bbd424f1206b635e9d506e1
] 
[X.L.MouseResizableTile: keep draggers on the bottom of the window stack.
Tomas Janousek <tomi@nomi.cz>**20091126173413
 Ignore-this: 8089cf8ce53580090b045f4aebb1b899
] 
[Implemented smarter system of managing borders for BorderResize
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091122233651
 Ignore-this: 4775c082249e598a84c79b2e819f28b0
] 
[X.H.DynamicLog: fix xmonadPropLog double-encoding of UTF-8
Tomas Janousek <tomi@nomi.cz>**20091121004829
 Ignore-this: bde612bbd1a19951f9718a03e737c4ac
 
 dynamicLogString utf-8 encodes its output, xmonadPropLog shouldn't do that
 again.
] 
[X.H.DynamicLog: make documentation for 'dzen' and 'xmobar' slightly more clear
Brent Yorgey <byorgey@cis.upenn.edu>**20091121170739
 Ignore-this: c9a241677fda21ef93305fc3882f102e
] 
[X.H.ManageDocks: ignore struts that cover an entire screen on that screen
Tomas Janousek <tomi@nomi.cz>**20091119145043
 Ignore-this: ad7bbf10c49c9f3e938cdc3d8588e202
 
 Imagine a screen layout like this:
 
   11111111
   11111111
   11111111
    222222    <--- xmobar here
    222222
    222222
 
 When placing xmobar as indicated, the partial strut property indicates that an
 entire height of screen 1 is covered by the strut, as well as a few lines at
 the top of screen 2. The original code would create a screen rectangle of
 negative height and wreak havoc. This patch causes such strut to be ignored on
 the screen it covers entirely, resulting in the desired behaviour of a small
 strut at the top of screen 2.
 
 Please note that this semantics of _NET_WM_STRUT and _NET_WM_STRUT_PARTIAL is
 different to what is in wm-spec. The "correct" thing to do would be to discard
 the covered portion of screen 1 leaving two narrow areas at the sides, but
 this new behaviour is probably more desirable in many cases, at least for
 xmonad/xmobar users.
 
 The correct solution of having separate _NET_WM_STRUT_PARTIAL for each
 Xinerama screen was mentioned in wm-spec maillist in 2007, but has never
 really been proposed, discussed and included in wm-spec. Hence this "hack".
] 
[Use imported 'fi' in PositionStoreHooks
Adam Vogt <vogt.adam@gmail.com>**20091119103112
 Ignore-this: 6563a3093083667c79aa491a6f59b805
] 
[Changed interface of X.U.ExtensibleState
Daniel Schoepe <daniel.schoepe@gmail.com>**20091116171013
 Ignore-this: 9a830f9341e461628974890bab0bd65b
 
 Changed the interface of X.U.ExtensibleState to resemble that of
 Control.Monad.State and modified the modules that use it accordingly.
] 
[PositionStoreFloat - a floating layout with support hooks
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091115184833
 Ignore-this: 8b1d0fcef1465356d72cb5f1f32413b6
] 
[PositionStore utility to store information about position and size of a window
Jan Vornberger <jan.vornberger@informatik.uni-oldenburg.de>**20091108195735
 Ignore-this: 2f6e68a490deb75cba5d007b30c93fb2
] 
[X.H.Urgencyhook fix minor doc bug
Anders Engstrom <ankaan@gmail.com>**20091115131121
 Ignore-this: 18b63bccedceb66c77b345a9300f1ac3
] 
[X.H.DynamicLog fix minor indentation oddness
Anders Engstrom <ankaan@gmail.com>**20091115130707
 Ignore-this: 7f2c49eae5527874ca4499767f4167c4
] 
[X.A.CycleWS cycle by tag group
Anders Engstrom <ankaan@gmail.com>**20091115130217
 Ignore-this: 909da8c00b47a31d04f59bd3751c60bc
 Allow grouping of workspaces, so that a user can cycle through those in the same group. Grouping is done by using a special character in the tag.
] 
[Use less short names in X.Prompt
Adam Vogt <vogt.adam@gmail.com>**20091115025647
 Ignore-this: 1d27b8efc4d829a5642717c6f6426336
] 
[Use io instead of liftIO in Prompt
Adam Vogt <vogt.adam@gmail.com>**20091115025301
 Ignore-this: cd4031b74cd5bb874cd2c3cc2cb087f2
] 
['io' and 'fi' are defined outside of Prompt
Adam Vogt <vogt.adam@gmail.com>**20091115024001
 Ignore-this: 3426056362db9cbfde7d2f4edbfe6f36
] 
[Use zipWithM_ instead of recursion in Prompt.printComplList
Adam Vogt <vogt.adam@gmail.com>**20091115023451
 Ignore-this: 2457500ed871ef120653a3d4ada13441
] 
[Minor style changes in DynamicWorkspaces
Adam Vogt <vogt.adam@gmail.com>**20091115022751
 Ignore-this: 1a6018ab134e4420a949354575a8a110
] 
[X.A.DynamicWorkspaces fix doc and add behaviour
Anders Engstrom <ankaan@gmail.com>**20091113233903
 Ignore-this: ab7c20a9c1b43ebc6a7f4700d988fb73
 Before this patch the documentation claims that it won't do anything on non-empty workspaces when it actually does. This patch fixes the documentation to reflect the actual behaviour, but also adds the behaviour promised by the documentation in other functions. It does not break configs. In addition it also provides functions to help removing empty workspaces when leaving them.
] 
[rework XMonad.Util.Dzen
daniel@wagner-home.com**20091114051509
 Ignore-this: 16d93f91c54f7d195b1a418e6c0351c5
] 
[generalize IO actions to MonadIO m => m actions
daniel@wagner-home.com**20091114023616
 Ignore-this: 2c801a27b0ffee34a2f0daca3778613a
 
 This should not cause any working configs to stop working, because IO is an instance of MonadIO, and because complete configs will pin down the type of the call to IO.  Note that XMonad.Config.Arossato is not a complete config, and so it needed some tweaks; with a main function, this should not be a problem.
] 
[fix documentation to match implementation
daniel@wagner-home.com**20091114021328
 Ignore-this: 6dbbb118b139f443c40a573445a48d07
] 
[Bypass more of stringToKeysym in U.Paste
Adam Vogt <vogt.adam@gmail.com>**20091114223726
 Ignore-this: 617c922647e9f49f5ecefa0eb1c65d3c
] 
[Don't erase floating information with H.InsertPosition (Issue 334)
Adam Vogt <vogt.adam@gmail.com>**20091113161402
 Ignore-this: de1c03eb860ea25b390ee5c756b02997
] 
[Rename gridselectViewWorkspace to gridselectWorkspace, add another example.
Adam Vogt <vogt.adam@gmail.com>**20091112211435
 Ignore-this: 462cf1c7f66ab97a1ce642977591a910
 
 The name should be more general to suggest uses other than just viewing other
 workspaces.
] 
[X.A.DynamicWorkspaces: fix addWorkspace and friends so they never add another copy of an existing workspace
Brent Yorgey <byorgey@cis.upenn.edu>**20091112201351
 Ignore-this: 5bfe8129707b038ed04383b7566b2323
] 
[Trim whitespace in H.FloatNext
Adam Vogt <vogt.adam@gmail.com>**20091111022702
 Ignore-this: 1ad52678246fa1ac951169c2356ce10b
] 
[Use ExtensibleState in H.FloatNext
Adam Vogt <vogt.adam@gmail.com>**20091111022513
 Ignore-this: 760d95a685af080466cb4164d1096423
] 
[Make a haddock link direct in C.Desktop.
Adam Vogt <vogt.adam@gmail.com>**20091111013810
 Ignore-this: da724a7974c3de60f49996c1fe92d3fb
] 
[Change A.TopicSpace haddocks to use block quotes.
Adam Vogt <vogt.adam@gmail.com>**20091111013241
 Ignore-this: 6f7f43d2715cfde62b9c05c7d9a0da2
] 
[Add defaultTopicConfig, to allow adding more fields to TopicSpace later.
Adam Vogt <vogt.adam@gmail.com>**20091111012915
 Ignore-this: 6dad95769651a9a1ef8d771f81c91f8e
] 
[X.A.WindowGo: fix haddock markup
Spencer Janssen <spencerjanssen@gmail.com>**20091111003256
 Ignore-this: c6a06de900ca8b67498abf5152e3d9ea
] 
[Minor style corrections in X.U.SpawnOnce
Daniel Schoepe <daniel.schoepe@gmail.com>**20091109201543
 Ignore-this: 1264852c23b4f84b2580bf4567529c68
] 
[Add gridselectViewWorkspace in X.A.GridSelect
Daniel Schoepe <daniel.schoepe@gmail.com>**20091109155815
 Ignore-this: 5543211e9e3fd325cb798b004635a525
] 
[minor-doc-fix-in-ManageHelpers
`Henrique Abreu <hgabreu@gmail.com>'**20091104172727
 Ignore-this: 231ad417541bc3c17a1cb2dff139d55d
] 
[Set buffering to LineBuffering in scripts/xmonadpropread.hs
Daniel Schoepe <daniel.schoepe@gmail.com>**20091108204106
 Ignore-this: 4e593fc1461fbbfb5b147c7c7702584e
 
 (Required for the script to work properly with tools like dzen)
] 
[X.U.ExtensibleState: style
Spencer Janssen <spencerjanssen@gmail.com>**20091108182858
 Ignore-this: f189da75ad2c57ae9cca48eaf69a6bad
] 
[X.A.DynamicWorkspaces: new 'addWorkspacePrompt' method
Brent Yorgey <byorgey@cis.upenn.edu>**20091108170503
 Ignore-this: a3992b1b7938be80d8fd2a5a503a4042
] 
[Remove defaulting when using NoMonomorphismRestriction in H.EwmhDesktops
Adam Vogt <vogt.adam@gmail.com>**20091107195255
 Ignore-this: ca3939842639c94ca4fd1ff6624319c1
] 
[Update A.TopicSpace to use extensible state. No config changes required.
Adam Vogt <vogt.adam@gmail.com>**20091107194502
 Ignore-this: 7a82aad512bb727b3447de0faa4a210f
] 
[Inline tupadd function in A.GridSelect
Adam Vogt <vogt.adam@gmail.com>**20091101190312
 Ignore-this: 458968154303ab865c304f387d6ac83b
] 
[Alphabetize exposed-modules
Spencer Janssen <spencerjanssen@gmail.com>**20091107174946
 Ignore-this: 919684aea7747a756b303f9b34a2870b
] 
[Use X.U.SpawnOnce in my config
Spencer Janssen <spencerjanssen@gmail.com>**20091107174615
 Ignore-this: fe8f5f75136128280942771ec429f09a
] 
[Add XMonad.Util.SpawnOnce
Spencer Janssen <spencerjanssen@gmail.com>**20091107173820
 Ignore-this: 8d4657bbaa8dbeb1d0f9d22293bfef19
] 
[Store deserialized data after reading in X.U.ExtensibleState
Daniel Schoepe <daniel.schoepe@gmail.com>**20091107103832
 Ignore-this: 192beca56e9437292bd3f16451ae9e66
] 
[Fixed conflict between X.U.ExtensibleState and X.C.Sjanssen
Daniel Schoepe <daniel.schoepe@gmail.com>**20091107103619
 Ignore-this: 80f4bb218574d7c528af17473c6e4f66
] 
[Use X.U.ExtensibleState instead of IORefs
Daniel Schoepe <daniel.schoepe@gmail.com>**20091106115601
 Ignore-this: e0e80e31e51dfe76f2b2ed597892cbba
   
 This patch changes SpawnOn, DynamicHooks and UrgencyHooks to
 use X.U.ExtensibleState instead of IORefs. This simplifies the
 usage of those modules thus also breaking current configs.
] 
[Add X.U.ExtensibleState
Daniel Schoepe <daniel.schoepe@gmail.com>**20091106115336
 Ignore-this: d80d9d0c10a53fb71a375e432bd29344
] 
[My config uses xmonadPropLog now
Spencer Janssen <spencerjanssen@gmail.com>**20091107005230
 Ignore-this: 8f16b8bea86dfcd3739f1566f5897578
] 
[Add xmonadpropread script
Spencer Janssen <spencerjanssen@gmail.com>**20091107004858
 Ignore-this: 8cc7ed36ec1126d0139638148f9642e8
] 
[Add experimental xmonadPropLog function
Spencer Janssen <spencerjanssen@gmail.com>**20091107004624
 Ignore-this: f09b2c11b16a3af993b63d1b39566120
] 
[XMonad.Actions.Search: imdb search URL tweak for bug #33
gwern0@gmail.com**20091103222330
 Ignore-this: bae5e6d3ec6c4b6591016ece9dffb202
] 
[Clean imports for L.BoringWindows
Adam Vogt <vogt.adam@gmail.com>**20091103140649
 Ignore-this: 56946a652329390dbdd63746ca23ee8e
] 
[I maintain L.BoringWindows
Adam Vogt <vogt.adam@gmail.com>**20091103140509
 Ignore-this: de853972b4c1c4cefa2dc29e68828d5d
] 
[fix window rectangle calculation in X.A.UpdatePointer
Tomas Janousek <tomi@nomi.cz>**20091026154918
 Ignore-this: ad0c3a020b802854919c7827faa001ad
] 
[Implement hasProperty in terms of runQuery in U.WindowProperties
Adam Vogt <vogt.adam@gmail.com>**20091031154945
 Ignore-this: 1c351bc436e0e323dc25d8f5ff734dcb
 
 This addresses issue 302 for unicode titles by actually using the complicated
 XMonad.ManageHook.title code, instead of reimplementing it with stringProperty
 (which doesn't appear to handle unicode).
] 
[Add functions to access the current input in X.Prompt
Daniel Schoepe <daniel.schoepe@gmail.com>**20091030235033
 Ignore-this: 3f568c1266d85dcaa5722b19bbbd61dd
] 
[Remove putSelection, fixes #317
Spencer Janssen <spencerjanssen@gmail.com>**20091030224354
 Ignore-this: 6cfd6d92e1d133bc9e3cbb7c8339f735
] 
[Fix typo in H.FadeInactive documentation
Adam Vogt <vogt.adam@gmail.com>**20091029165736
 Ignore-this: b2af487cd382416160d5540b7f210464
] 
[X.L.MultiCol constructor 0 NWin bugfig
Anders Engstrom <ankaan@gmail.com>**20091029105633
 Ignore-this: e6a24f581593424461a8675984d14d25
 Fix bug where the constructor did not accept catch-all columns. Also some minor cleaning.
] 
[X.H.ManageHelpers: added currentWs that returns the current workspace
Ismael Carnales <icarnales@gmail.com>**20091028193519
 Ignore-this: dcd3dac6bd741d26747807691f125637
] 
[X.L.MultiColumns bugfix and formating
Anders Engstrom <ankaan@gmail.com>**20091027131741
 Ignore-this: 6978f485d18adb8bf81cf6c8e0d0332
 Fix bug where a column list of insufficient length could be used to find the column of the window. Also fix formating to conform better with standards.
] 
[X.L.MultiColumns NWin shrinkning fix
Anders Engstrom <ankaan@gmail.com>**20091027005932
 Ignore-this: 9ba40ee14ec12c3885173817eac2b564
 Fixed a bug where the list containing the number of windows in each column was allowed the shrink if a column was unused.
] 
[New Layout X.L.MultiColumns
Anders Engstrom <ankaan@gmail.com>**20091024175155
 Ignore-this: a2d3d2eee52c28eab7d125f6b621cada
 New layout inspired the realization that I was switching between Mirror Tall and Mirror ThreeCol depending on how many windows there were on the workspace. This layout will make those changes automatically.
] 
[Changing behaviour of ppUrgent with X.H.DynamicLog
mail@n-sch.de**20090910010411
 Ignore-this: 3882f36d5c49e53628485c1570bf136a
 
 Currently, the ppUrgent method is an addition to the ppHidden method.
 This doesn't make any sense since it is in fact possible to get urgent
 windows on the current and visible screens. So I've raised the ppUrgent
 printer to be above ppCurrent/ppVisible and dropped its dependency on
 ppHidden.
 
 In addition to that this makes it a lot more easier to define a more
 custom ppUrgent printer, since you don't have to "undo" the ppHidden
 printer anymore. This also basicly removes the need for dzenStrip,
 although I just changed the description.
 
 -- McManiaC / Nils
 
] 
[fix X.U.Run.spawnPipe fd leak
Tomas Janousek <tomi@nomi.cz>**20091025210246
 Ignore-this: 24375912d505963fafc917a63d0e79a0
] 
[TAG 0.9
Spencer Janssen <spencerjanssen@gmail.com>**20091026013449
 Ignore-this: 542b6105d6deed65e12d1f91c666b0b2
] 
Patch bundle hash:
9d2ced4994ffeb3fde2e6e11003681a4e40ab168
From codesite-noreply at google.com  Mon Feb 22 08:53:10 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb 22 08:23:42 2010
Subject: [xmonad] Re: Issue 375 in xmonad: keysResizeWindow doesn't always
	work
In-Reply-To: <0-3425899027203913298-14907461048215614562-codesite-noreply=google.com@googlecode.com>
References: <0-3425899027203913298-14907461048215614562-codesite-noreply=google.com@googlecode.com>
Message-ID: <1-3425899027203913298-14907461048215614562-codesite-noreply=google.com@googlecode.com>


Comment #1 on issue 375 by ankaan: keysResizeWindow doesn't always work
http://code.google.com/p/xmonad/issues/detail?id=375

I recognize this as something I have run into before. I am quite sure that  
it has to
do with the window size hints that the resize function tries to respect.  
You are
requesting a change in window size that is so small that after applying the  
window
hints the window get the same size and therefore does not seem to work. A  
workaround
is increasing the delta and/or using another point to resize around (second  
tuple).

But it should be changed so that the window is always resized and never  
rounded back
to what it was before the change. That is the sane behaviour.

--
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
From codesite-noreply at google.com  Mon Feb 22 09:29:37 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb 22 09:00:07 2010
Subject: [xmonad] Re: Issue 177 in xmonad: xmonad does not follow ICCCM and
	ignores WM_TAKE_FOCUS protocol
In-Reply-To: <31-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
References: <31-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
Message-ID: <32-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>


Comment #32 on issue 177 by hgabreu: xmonad does not follow ICCCM and  
ignores WM_TAKE_FOCUS protocol
http://code.google.com/p/xmonad/issues/detail?id=177

patch cannot be applied in latest darcs
Sorry, but why this patch have not been applied to the repo yet?

--
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
From codesite-noreply at google.com  Mon Feb 22 09:55:15 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb 22 09:25:47 2010
Subject: [xmonad] Re: Issue 177 in xmonad: xmonad does not follow ICCCM and
	ignores WM_TAKE_FOCUS protocol
In-Reply-To: <32-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
References: <32-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
Message-ID: <33-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>


Comment #33 on issue 177 by vogt.adam: xmonad does not follow ICCCM and  
ignores WM_TAKE_FOCUS protocol
http://code.google.com/p/xmonad/issues/detail?id=177

Here you go:

Attachments:
	track-currently-processing-event.dpatch  14.4 KB

--
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
From codesite-noreply at google.com  Mon Feb 22 10:12:08 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb 22 09:42:39 2010
Subject: [xmonad] Re: Issue 376 in xmonad: TwinView issues
In-Reply-To: <0-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
References: <0-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
Message-ID: <1-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>

Updates:
	Status: Invalid

Comment #1 on issue 376 by vogt.adam: TwinView issues
http://code.google.com/p/xmonad/issues/detail?id=376

You are supposed to be able to have workspaces swap screens. This ensures  
that focus
stays on the current screen.

If you'd rather have the focus jump to the other screen when you try to  
view the
other visible workspace, see here:
http://haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#Replacing_greedyView_with_view

--
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
From Julien.Steinhauser at orange.fr  Mon Feb 22 10:21:13 2010
From: Julien.Steinhauser at orange.fr (julien steinhauser)
Date: Mon Feb 22 09:51:06 2010
Subject: [xmonad] recompile, dzen and togglestruts
In-Reply-To: <20100222101226.GA2798@eol.dynalias.org>
References: <20100222023454.GA18392@eol.dynalias.org>
	<20100222101226.GA2798@eol.dynalias.org>
Message-ID: <20100222152113.GA10365@eol.dynalias.org>

On Mon, Feb 22, 2010 at 11:12:26AM +0100, julien steinhauser wrote:
> On Mon, Feb 22, 2010 at 03:34:54AM +0100, julien steinhauser wrote:
> > Hello,
> > 
> > On a fresh XMonad setup, I meet an issue and I'd like wise advices,
> > wether I'm doing things correctly or not.
> > 
> > I use two dzen, one for views, layout and title on the left
> > and one for other things on right.
> > 
> > The one on left is launched from within xmonad.hs via spawnpipe
> > the one on right is lauched from my .xinitrc.
> > 
> > If i make a change in xmonad.hs and want to recompile it,
> > it compiles silently (no output with xmonad --recompile).
> > 
> > All clients which were already here before the recompile
> >  won't cover the left dzen anymore after the recompile even
> > with the mod-b shortcut (dzen stays on top)
> > but they still cover the dzen on the right. 
> > 
> > All clients launched after the recompile behave the normal way,
> > until I recompile ...
> > 
> > My xmonad version :
> > ~$ xmonad --version
> > xmonad 0.9.1
> > (Source package xmonad and xmonad-contrib from Debian Sid)
> > 
> > I attach my xmonad.hs
> > 
> > I hope this message wasn't too confused.
> > 
> > Julien 
> 
> 
> > _______________________________________________
> > xmonad mailing list
> > xmonad@haskell.org
> > http://www.haskell.org/mailman/listinfo/xmonad
> 
> Actually, my xmonad.hs is quite small, I reattached it not gunzipped
> for convenience.
> Sorry for double posting.
> 
> Julien

> import XMonad
> import Data.Monoid
> import System.Exit
> 
> import XMonad.Actions.DwmPromote
> import XMonad.Actions.CycleWS
> import XMonad.Actions.RotSlaves
> 
> import XMonad.Hooks.ManageDocks
> import XMonad.Hooks.DynamicLog
> 
> import XMonad.Layout.NoBorders
> import XMonad.Layout.TwoPane
> 
> import qualified XMonad.StackSet as W
> import qualified Data.Map        as M
> 
> import XMonad.Util.Run
> 
> myTerminal      = "urxvtc"
> ?
> myFocusFollowsMouse :: Bool
> myFocusFollowsMouse = True
> ?
> myBorderWidth   = 1
> ?
> myModMask       = mod4Mask
> ?
> myWorkspaces    = ["1","2","3","4"]
> ?
> myNormalBorderColor  = "#000000"
> myFocusedBorderColor = "#00ff00"
> 
> myKeys conf@(XConfig {XMonad.modMask = modm}) = M.fromList $
> ?
>     [ ((modm .|. shiftMask, xK_Return), spawn $ XMonad.terminal conf)
>     , ((modm,               xK_p     ), spawn "exe=`dmenu_path | xft_dmenu` && eval \"exec $exe\"")
>     , ((modm,               xK_s     ), spawn "spawnsurf")
>     , ((modm,               xK_x     ), spawn "actions")
>     , ((modm,               xK_r     ), spawn "racine")
>     , ((modm,               xK_a     ), spawn "setxkbmap fr")
>     , ((modm,               xK_q     ), spawn "setxkbmap us")
>     , ((modm,               xK_l     ), spawn "cd `cat /tmp/lastdir` && exec scd")
>     , ((modm,               xK_exclam), spawn "scd")
>     , ((modm,               xK_Insert), spawn "urxvtc -e vi ~/.xmonad/xmonad.hs")
>     , ((modm,               xK_m     ), spawn "urxvtc -e mutt")
>     , ((modm,               xK_F1    ), spawn "dmenu_man")
>     , ((modm .|. shiftMask, xK_p     ), spawn "sdmenu_run")
>     , ((modm,               xK_w     ), kill)
> ?
>     , ((modm,               xK_space ), sendMessage NextLayout)
>     , ((modm .|. shiftMask, xK_space ), setLayout $ XMonad.layoutHook conf)
>     , ((modm,               xK_n     ), refresh)
>     , ((modm,               xK_Tab   ), windows W.focusDown)
>     , ((modm .|. shiftMask, xK_Tab   ), rotSlavesUp)?
>     , ((modm,               0x13bd   ), windows W.focusUp  )
> ?
>     , ((modm,               xK_Return), dwmpromote )
>     , ((modm .|. shiftMask, xK_j     ), windows W.swapDown  )
>     , ((modm .|. shiftMask, xK_k     ), windows W.swapUp    )
>     , ((modm,               xK_Left  ), sendMessage Shrink)
>     , ((modm,               xK_Right ), sendMessage Expand)
>     , ((modm .|. shiftMask, xK_t     ), withFocused $ windows . W.sink)
>     , ((modm              , xK_comma ), sendMessage (IncMasterN 1))
>     , ((modm              , xK_semicolon ), sendMessage (IncMasterN (-1)))
>     , ((modm,               xK_Down),  nextWS)
>     , ((modm,               xK_Up),    prevWS)
>     , ((modm .|. shiftMask, xK_Down),  shiftToNext)
>     , ((modm .|. shiftMask, xK_Up),    shiftToPrev)?
>     , ((modm .|. controlMask, xK_Down), shiftToNext >> nextWS)
>     , ((modm .|. controlMask, xK_Up),   shiftToPrev >> prevWS)
>     , ((modm              , xK_b     ), sendMessage ToggleStruts)
>     , ((modm .|. shiftMask, xK_q     ), io (exitWith ExitSuccess))
>     , ((modm .|. controlMask, xK_q     ), spawn "xmonad --recompile; xmonad --restart")
>     ]
>     ++
> ?
>     [((m .|. modm, k), windows $ f i)
>         | (i, k) <- zip (XMonad.workspaces conf) [0x26,0xe9,0x22,0x27]
>         , (f, m) <- [(W.greedyView, 0), (W.shift, shiftMask)
>         , (\i -> W.greedyView i . W.shift i, controlMask)]]
>     ++
> ?
>     [((m .|. modm, key), screenWorkspace sc >>= flip whenJust (windows . f))
>         | (key, sc) <- zip [xK_z, xK_e] [0..]
>         , (f, m) <- [(W.view, 0), (W.shift, shiftMask)
>         , (\i -> W.view i . W.shift i, controlMask)]]
> ?
> 
> myLayout =  smartBorders $ avoidStruts (tiled ||| Mirror tiled ||| TwoPane (3/100) (31/50) ||| Full)
>   where
>     tiled   = Tall nmaster delta ratio
>     nmaster = 1
>     ratio   = 31/50
>     delta   = 3/100
> 
> myManageHook = composeAll
>     [ className =? "MPlayer"        --> doFloat
>     , className =? "Gimp"           --> doFloat
>     , resource  =? "desktop_window" --> doIgnore
>     ]?
> 
> myEventHook = mempty
> ?
> myStartupHook = return ()
> 
> main = do
>     h <- spawnPipe "dzen2 -w 1240 -ta l"
>     xmonad $ defaultConfig {
>         terminal           = myTerminal,
>         focusFollowsMouse  = myFocusFollowsMouse,
>         borderWidth        = myBorderWidth,
>         modMask            = myModMask,
>         workspaces         = myWorkspaces,
>         normalBorderColor  = myNormalBorderColor,
>         focusedBorderColor = myFocusedBorderColor,
>         keys               = myKeys,
>         layoutHook         = myLayout,
>         manageHook         = myManageHook <+> manageDocks,
>         logHook            = dynamicLogWithPP $ dzenPP { ppOutput = hPutStrLn h },
>         handleEventHook    = myEventHook,
>         startupHook        = myStartupHook
>     }

> _______________________________________________
> xmonad mailing list
> xmonad@haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad

I solved it, I had to start the dzen which shows my workspaces,
 layout and title from my .xinitrc as well, like my other dzen.


From codesite-noreply at google.com  Mon Feb 22 15:48:46 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb 22 15:19:17 2010
Subject: [xmonad] Re: Issue 376 in xmonad: TwinView issues
In-Reply-To: <1-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
Message-ID: <2-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>


Comment #2 on issue 376 by daniel.wagner: TwinView issues
http://code.google.com/p/xmonad/issues/detail?id=376

You may also like XMonad.Layout.IndependentScreens, which gives each screen  
its own
set of workspaces.
http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-IndependentScreens.html

--
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
From codesite-noreply at google.com  Mon Feb 22 16:48:33 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb 22 16:19:04 2010
Subject: [xmonad] Re: Issue 376 in xmonad: TwinView issues
In-Reply-To: <2-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
References: <2-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
Message-ID: <3-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>


Comment #3 on issue 376 by dripstone.blendercn: TwinView issues
http://code.google.com/p/xmonad/issues/detail?id=376

Hi, I don't know what greedyView is, so I tried daniel.wagner's way.

The code I used in xmonad.hs is:
import XMonad.Layout.IndependentScreens
...
...
          ++ [       ("M" ++ m ++ ('-':k:[]) , windows $ onCurrentScreen f i)
                     | (i, k) <- zip myWorkspaces ['1'..'0']
                     , (f, m) <- [(W.view, ""), (W.shift, "-S"),  
(copy, "-C-S")]
It's not working.

Suppose the focus is always on main screen. If I press mod 1, I have window  
A on main
screen, and B,C on the other screen. Now if I press mod 2, I will have B,C  
on main
screen, and D on the other screen.

However, sometimes it works. For example, after I try mod n(random) for a  
couple of
times, I press mod 1, A is on main screen, B,C on the other. When I press  
mod 2, A
will be replaced by D. B,C remain on the other screen.

--
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
From codesite-noreply at google.com  Mon Feb 22 17:45:05 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb 22 17:15:36 2010
Subject: [xmonad] Re: Issue 376 in xmonad: TwinView issues
In-Reply-To: <3-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
References: <3-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
Message-ID: <4-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>


Comment #4 on issue 376 by daniel.wagner: TwinView issues
http://code.google.com/p/xmonad/issues/detail?id=376

You may need to log out and log back in to eliminate xmonad's stored state,  
which may
be inconsistent with X.L.IndependentScreens' assumptions.

--
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
From codesite-noreply at google.com  Mon Feb 22 18:07:42 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb 22 17:38:13 2010
Subject: [xmonad] Re: Issue 376 in xmonad: TwinView issues
In-Reply-To: <4-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
References: <4-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
Message-ID: <5-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>


Comment #5 on issue 376 by dripstone.blendercn: TwinView issues
http://code.google.com/p/xmonad/issues/detail?id=376

Thanks, but restarting linux didn't solve the problem.

--
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
From codesite-noreply at google.com  Mon Feb 22 19:00:33 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb 22 18:31:03 2010
Subject: [xmonad] Re: Issue 376 in xmonad: TwinView issues
In-Reply-To: <5-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
References: <5-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
Message-ID: <6-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>


Comment #6 on issue 376 by wirtwo...@gmail.com: TwinView issues
http://code.google.com/p/xmonad/issues/detail?id=376

To the OP: ['1'..'0'] is the same as [] or ""
so the bindings in comment three will not add or
change any key bindings; try instead:

   | (i, k) <- zip myWorkspaces "1234567890"

or

   | (i, k) <- zip myWorkspaces (['1'..'9'] ++ "0")


--
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
From codesite-noreply at google.com  Tue Feb 23 00:02:47 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Mon Feb 22 23:33:16 2010
Subject: [xmonad] Re: Issue 375 in xmonad: keysResizeWindow doesn't always
	work
In-Reply-To: <1-3425899027203913298-14907461048215614562-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-14907461048215614562-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-14907461048215614562-codesite-noreply=google.com@googlecode.com>
Message-ID: <2-3425899027203913298-14907461048215614562-codesite-noreply=google.com@googlecode.com>


Comment #2 on issue 375 by wei.hoo: keysResizeWindow doesn't always work
http://code.google.com/p/xmonad/issues/detail?id=375

ankaan, you're absolutely right. I hacked the FloatKeys module to ignore  
the size
hint and everything is fine now. For those who're interested, my code is at
http://github.com/wh5a/arch/commit/3ea2702785a6197c6fc5d5fba4207c13c87
f0fa5

--
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
From codesite-noreply at google.com  Tue Feb 23 04:07:14 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Tue Feb 23 03:37:42 2010
Subject: [xmonad] Re: Issue 376 in xmonad: TwinView issues
In-Reply-To: <6-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
References: <6-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>
Message-ID: <7-3425899027203913298-3926886484248194716-codesite-noreply=google.com@googlecode.com>


Comment #7 on issue 376 by dripstone.blendercn: TwinView issues
http://code.google.com/p/xmonad/issues/detail?id=376

Both methods didn't work.
I am confused :) I have 9 workspaces:
     myWorkspaces = map (:[]) ['1' .. '9']
How can I map 10 shortcuts for them:
     | (i, k) <- zip myWorkspaces "1234567890"


--
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
From codesite-noreply at google.com  Wed Feb 24 16:27:07 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Wed Feb 24 15:57:32 2010
Subject: [xmonad] Re: Issue 370 in xmonad: Xinerama,
	CycleWS & Empt workspaces
In-Reply-To: <0-3425899027203913298-10628488929604801762-codesite-noreply=google.com@googlecode.com>
References: <0-3425899027203913298-10628488929604801762-codesite-noreply=google.com@googlecode.com>
Message-ID: <1-3425899027203913298-10628488929604801762-codesite-noreply=google.com@googlecode.com>


Comment #1 on issue 370 by seansorrell: Xinerama, CycleWS & Empt workspaces
http://code.google.com/p/xmonad/issues/detail?id=370

Close this one please, it was nothing more than user error.

For completeness, I'm attaching a (very small) patch for my supplied config.

Attachments:
	cursor-focus.patch  116 bytes

--
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
From codesite-noreply at google.com  Wed Feb 24 16:49:43 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Wed Feb 24 16:20:07 2010
Subject: [xmonad] Re: Issue 370 in xmonad: Xinerama,
	CycleWS & Empt workspaces
In-Reply-To: <1-3425899027203913298-10628488929604801762-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-10628488929604801762-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-10628488929604801762-codesite-noreply=google.com@googlecode.com>
Message-ID: <2-3425899027203913298-10628488929604801762-codesite-noreply=google.com@googlecode.com>

Updates:
	Status: Invalid

Comment #2 on issue 370 by byorgey: Xinerama, CycleWS & Empt workspaces
http://code.google.com/p/xmonad/issues/detail?id=370

OK, closing.

--
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
From codesite-noreply at google.com  Sun Feb 28 18:05:41 2010
From: codesite-noreply at google.com (codesite-noreply@google.com)
Date: Sun Feb 28 17:35:53 2010
Subject: [xmonad] Re: Issue 177 in xmonad: xmonad does not follow ICCCM and
	ignores WM_TAKE_FOCUS protocol
In-Reply-To: <33-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
References: <33-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
	<0-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>
Message-ID: <34-3425899027203913298-17817162588143971274-codesite-noreply=google.com@googlecode.com>


Comment #34 on issue 177 by malte.sommerkorn: xmonad does not follow ICCCM  
and ignores WM_TAKE_FOCUS protocol
http://code.google.com/p/xmonad/issues/detail?id=177

Am I right to notice, though, that fullscreen firefox flash video is badly  
affected?

--
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