darcs patch: Layout.Spacing: Outer window edges now get as much spa...
Hello XMonad contributors!
I've attached here my first patch to XMonadContrib; specifically to the
Layout.Spacing component. This change makes it so that all edges of all
windows have the same amount of space around them, regardless of whether
they're up against the edge of the screen.
This matches my personal preference, but I don't know whether the original
behaviour was by design or if this style of spacing was already considered
and rejected. I'd welcome any discussion on the pros and cons of doing things
this way, as well as finding out whether anyone objects to this change. At
the end of the day it's up to you whether this patch should be included.
Thank you to geekosaur and fizzie in #xmonad for their help with the tricky
question of determining whether a Workspace has just one window on it, for
the smartSpacing part.
All the best,
Felix
1 patch for repository http://code.haskell.org/XMonadContrib:
Thu Dec 18 20:47:34 EST 2014 Felix Crux
On Thu, Dec 18, 2014 at 9:16 PM,
This matches my personal preference, but I don't know whether the original behaviour was by design or if this style of spacing was already considered and rejected.
There's at least three variations of this module that have been requested; and, oddly, everyone proposing a variant thinks that it is intuitively obvious that it's the only sensible one and wonders why nobody else ever considered it or if there's some technical reason why it's not already "the" implementation. In other words, you should be providing an *alternative* instead of replacing the existing implementation, because your "obviously correct" is not obvious to everyone else. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
On Fri, Dec 19 09:35, Brandon Allbery wrote:
There's at least three variations of this module that have been requested; and, oddly, everyone proposing a variant thinks that it is intuitively obvious that it's the only sensible one and wonders why nobody else ever considered it or if there's some technical reason why it's not already "the" implementation.
Hm; I must not have expressed myself clearly. My intention in labelling the change as "personal preference", asking whether there were existing reasons for having it the current way, and putting it up for discussion, was precisely to indicate that I *don't* think this is the only sensible way, and that I suspect someone *has* considered different ways.
In other words, you should be providing an *alternative* instead of replacing the existing implementation, because your "obviously correct" is not obvious to everyone else.
Again, when I said "personal preference", I did not expect it to be taken as implying I believe it to be "obviously correct". I have attached a modified patch that adds this behaviour as a separate option that does not replace the existing behaviour. Cheers, -- Felix
Hi Felix, I've pushed your patch. But here's an idea: In my config I have a: data ExpandEdges a = ExpandEdges Int deriving (Read,Show) instance LayoutModifier ExpandEdges Window where modifyLayout (ExpandEdges n) ws (Rectangle x y w h) = let bigRect = Rectangle (x - fromIntegral n) (y - fromIntegral n) (w + 2*fromIntegral n) (h + 2*fromIntegral n) in runLayout ws bigRect -- | push edges off-screen, or towards the center of the screen for negative numbers. expandEdges :: Int -> l a -> ModifiedLayout ExpandEdges l a expandEdges n layout = ModifiedLayout (ExpandEdges n) layout So we could define: spacingWithEdge n = expandEdges (-n) . spacing n This implementation is worse because the description is probably too long. But it does suggest that we're missing the combination that leaves no gaps at the screen edge: spacingOnlyBetweenWindows n = expandEdges n . spacing n Then again there's not too much point in defining extra things in contrib that nobody actually uses. Regards, Adam
On Sun, Dec 21, 2014, at 21:52, adam vogt wrote:
I've pushed your patch.
Thank you! Much appreciated.
But here's an idea: ...<snip>...
I really like the approach of having a more use-case-agnostic approach like the one you suggest. I have to admit I can barely read Haskell though, and I don't know anything about XMonad internals, so I can't comment on the actual implementation. I think it looks like a good idea, but someone other than me would be needed to pursue it. Maybe it could even be generalized further in relation to XMonad.Layout.Gaps.
Then again there's not too much point in defining extra things in contrib that nobody actually uses.
Well, if it's of comparable complexity to the current implementation, the cost wouldn't seem to be too high, and it might save someone some time in the future. Cheers, -- Felix
participants (4)
-
adam vogt -
Brandon Allbery -
Felix Crux -
felixc＠felixcrux.com