On Mon, Jun 11, 2007 at 02:07:32PM +1000, Donald Bruce Stewart wrote:

droundy:

...

This is a sort of hypothetical change. I like this design more than the recursive import approach. I'm not sure how often people will want to dynamically adjust the width of their borders, but I also don't see any reason to forbid it.

Hmm, interesting. Not massively compelling yet, but something to keep in mind.

Part of the motivation is simply that I'd like to avoid recursive imports--largely because I see them as a crude hack to avoid good design, by hiding parameters. Global constants aren't much better than global variables. Of course, we've already got global variables, but they're explicit in our state, and that's good. The other issue is that I really think that the border width should be layout-dependent. This patch doesn't do that, and I'm not quite sure how to do it properly, but there's really no benefit to a border around a full-screen (or tabbed) window. -- David Roundy http://www.darcs.net

On Mon, Jun 11, 2007 at 09:43:11AM -0500, Spencer Janssen wrote:

On Mon, 11 Jun 2007 06:54:29 -0700 David Roundy wrote:

...

On Mon, Jun 11, 2007 at 02:07:32PM +1000, Donald Bruce Stewart wrote:

...

droundy:

...

This is a sort of hypothetical change. I like this design more than the recursive import approach. I'm not sure how often people will want to dynamically adjust the width of their borders, but I also don't see any reason to forbid it.

Hmm, interesting. Not massively compelling yet, but something to keep in mind.

Part of the motivation is simply that I'd like to avoid recursive imports--largely because I see them as a crude hack to avoid good design, by hiding parameters. Global constants aren't much better than global variables. Of course, we've already got global variables, but they're explicit in our state, and that's good.

The other issue is that I really think that the border width should be layout-dependent. This patch doesn't do that, and I'm not quite sure how to do it properly, but there's really no benefit to a border around a full-screen (or tabbed) window.

Excepting, of course, multi-head setups.

Indeed, that's a good point. But also a reasonable argument for making the borderWidth configurable by layout. -- David Roundy http://www.darcs.net

On Mon, Jun 11, 2007 at 06:54:29AM -0700, David Roundy wrote:

On Mon, Jun 11, 2007 at 02:07:32PM +1000, Donald Bruce Stewart wrote:

...

droundy:

...

This is a sort of hypothetical change. I like this design more than the recursive import approach. I'm not sure how often people will want to dynamically adjust the width of their borders, but I also don't see any reason to forbid it.

Hmm, interesting. Not massively compelling yet, but something to keep in mind.

Part of the motivation is simply that I'd like to avoid recursive imports--largely because I see them as a crude hack to avoid good design, by hiding parameters. Global constants aren't much better than global variables. Of course, we've already got global variables, but they're explicit in our state, and that's good.

The other issue is that I really think that the border width should be layout-dependent. This patch doesn't do that, and I'm not quite sure how to do it properly, but there's really no benefit to a border around a full-screen (or tabbed) window.

One idea, which I've been toying with (but haven't implemented yet!) is to force the global borderWidth to 0, and give layouts the responsibility for constructing borders. This would require exposing the floating layer to layouts, but that seems needed anyway to do a reasonable job with compositing. Stefan