* On Friday, March 26 2010, Gwern Branwen wrote:

On Sat, Aug 22, 2009 at 5:55 PM, Daniel Schoepe wrote:

...

Sat Aug 22 23:39:58 CEST 2009  Daniel Schoepe  * 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. -- Adam

On Fri, Mar 26, 2010 at 12:00 PM, Adam Vogt wrote:

* On Friday, March 26 2010, Gwern Branwen wrote:

...

On Sat, Aug 22, 2009 at 5:55 PM, Daniel Schoepe wrote:

...

Sat Aug 22 23:39:58 CEST 2009  Daniel Schoepe  * 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. -- gwern

On Mon, Mar 29, 2010 at 11:17:08AM -0400, Gwern Branwen wrote:

On Fri, Mar 26, 2010 at 12:00 PM, Adam Vogt wrote:

...

* On Friday, March 26 2010, Gwern Branwen wrote:

...

On Sat, Aug 22, 2009 at 5:55 PM, Daniel Schoepe wrote:

...

Sat Aug 22 23:39:58 CEST 2009  Daniel Schoepe  * 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

On Thu, Apr 29, 2010 at 2:46 PM, Gwern Branwen wrote:

On Mon, Mar 29, 2010 at 7:41 PM, Brent Yorgey 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 wrote:

...

* On Friday, March 26 2010, Gwern Branwen wrote:

...

On Sat, Aug 22, 2009 at 5:55 PM, Daniel Schoepe wrote:

...

Sat Aug 22 23:39:58 CEST 2009  Daniel Schoepe  * 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