Implement useless gap support about awesome HOT 11 CLOSED

i don't think what visual separation is useless

from awesome.

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

from awesome.

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.

from awesome.

Neat. I'd like this.

from awesome.

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

Thanks

from awesome.

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

from awesome.

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.

from awesome.

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.

from awesome.

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

from awesome.

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?

from awesome.

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?

from awesome.