[xmonad] darcs patch: Add a way to update the modifier in X.L.LayoutModifier

[Gwern Branwen]

On Thu, Apr 29, 2010 at 2:46 PM, Gwern Branwen <gwern0 at gmail.com> wrote:
> On Mon, Mar 29, 2010 at 7:41 PM, Brent Yorgey <byorgey at seas.upenn.edu> wrote:
>> On Mon, Mar 29, 2010 at 11:17:08AM -0400, Gwern Branwen wrote:
>>> On Fri, Mar 26, 2010 at 12:00 PM, Adam Vogt <vogt.adam at gmail.com> wrote:
>>> > * On Friday, March 26 2010, Gwern Branwen wrote:
>>> >
>>> >>On Sat, Aug 22, 2009 at 5:55 PM, Daniel Schoepe
>>> >><daniel.schoepe at googlemail.com> wrote:
>>> >>> Sat Aug 22 23:39:58 CEST 2009  Daniel Schoepe <daniel.schoepe at gmail.com>
>>> >>>  * Add a way to update the modifier in X.L.LayoutModifier
>>> >>>
>>> >>>  This patch adds the possibility to update the state of a layout modifier when
>>> >>>  modifying the underlying layout before it is run(i.e. using modifyLayout).
>>> >>>  The modified state is also passed to the subsequent call of redoLayout, whose
>>> >>>  return takes precedence if both functions return modified states of the layout
>>> >>>  modifier.
>>> >>
>>> >>Anyone have feedback on this? Another patch that's been hanging around
>>> >>for far too long.
>>> >>
>>> >>--
>>> >>gwern
>>> >
>>> > At the time it didn't seem sensible to extend the already sizable class
>>> > without having any code that actually needed the new method.
>>>
>>> Would there be any specific downside to this, though? If X.L.Drawer
>>> could use this, and there's no downside, there would seem to be a
>>> benefit to applying.
>>
>> I vote for applying it, given that something could make use of it.
>> The LayoutModifier class is so complicated already that one more
>> method won't hurt anything.
>>
>> Maybe we should advertise for a student to do a GSoC project cleaning
>> up LayoutModifier and everything that uses it. ;)
>>
>> -Brent
>
> Alright. If no one objects, I will apply this in 7 days.

I've pushed it. Thanks for the patch, Daniel.

-- 
gwern