Implement useless gap support

[Elv13]

Here we are again,

For the zillion-th time, someone asked for it, so I got bored of the same feature request and hacked it. Here is the code:
Elv13@bb987e4

I need some feedback before porting this to master and doing a proper PR.

It seem to work fine. Is it useful: no. Does it look nice: maybe. Will I recommend anyone using that: no

[actionless]

i don't think what visual separation is useless

[Elv13]

Oh, I forgot to talk about the code:

Done:

• Implement for all layouts
• Add methods in awful.tag like other properties

What's left:

• Find a way to hook that with beautiful (I don't want to require() it in awful.tag
• Remove the 10px default and use 0px
• Somehow add comments in theme or rc.lua to guide users
• Port to master
• Do more advanced testing

[BenoitZugmeyer]

For what it's worth, I would love to see this in Awesome. For now, I use lain, which is great but has one annoying issue.

[liquiddandruff]

Neat. I'd like this.

[Elv13]

@BenoitZugmeyer @liquiddandruff: Can you test the branch and give some feedback?

Thanks

[BenoitZugmeyer]

Testing it right now. No issue spotted. I'll keep using it for a few days.

If anyone is interested, here is an ArchLinux PKGBUILD

[BenoitZugmeyer]

I've spotted an issue:

• With the layout awful.layout.suit.tile
• Open two clients
• Increase the number of columns (awful.tag.incncol(1), default binding Mod+Ctrl+h)

The space between the clients is increasing.

[silverhammermba]

I would definitely like this to be added. Window borders are so ugly, but useless gaps provide the same separation while looking nice! I'll see if I can play around with the code a bit.

[silverhammermba]

I took a different approach which I find much simpler: silverhammermba/awesome@986e9bf

My idea was to let the layout arrange the clients as usual, then perform a second pass to slightly shrink each client to create the gaps. The advantage of this method is that it involves very little code and is layout-agnostic.

However, there are two issues with this approach:

1. Since each layout directly modifies the client geometry, this approach resizes each client twice when arranging the screen (once for the layout, once for the gaps). This causes an unpleasant flickering effect.
2. A naive implementation completely breaks the floating layout. That's because the floating layout doesn't actually mark the clients as floating (they are still returned by awful.client.tiled) it just doesn't modify any client geometry. But this results in every client shrinking down to nothing because the second pass assumes that the client geometry has been set to some fixed size before shrinking it. My workaround is to store the client geometries before the layout does its stuff, so that we can check if the geometry was unchanged and not shrink it.

I think that both of these problems could be solved by DRYing off the layout code so that each layout simply partitions the screen according to the number of clients, returns the resulting geometries, and the geometries are actually applied in awful.layout.arrange after optional post-processing (for borders, useless gaps, etc.). I implemented these as #101

[blueyed]

Now that #101 is merged, useless gaps can/should be implemented based on it (silverhammermba@986e9bf).

@silverhammermba
Can you please create a new PR for this?

[silverhammermba]

Sure thing, but I'm stuck in the same place @Elv13 was: making the gaps not hard-coded. I feel like they should be configured similarly to border widths, but there's a surprising amount of code for handling the border width property. Any advice on how I should approach this?