proposal: add extra screen parameter to runLayout

newer
Issue 163 in xmonad: Add hoogle...

Brent Yorgey

26 Mar 2008 26 Mar '08

10:37 a.m.

So, this morning I began hacking up gaps as a LayoutModifier in contrib. I didn't get too far before I realized that in order to retain the same behavior as the current built-in gaps (*per screen* gap configuration), a layout needs to be able to know on which *screen* it is called! This is the point at which I had a profound sense of deja vu, since of course we had the same issue with PerWorkspace, only with *screen* replaced by *workspace*. gah! I think, however, this could be useful information for other potential layouts as well -- I don't have any particular examples in mind, but having layouts that can behave differently depending on which screen they're on sounds like it could be useful for more than just per-screen gaps. So, I propose to add an extra screen parameter to runLayout and friends (which of course requires a bunch of trivial updates in contrib, unfortunately). I'm happy to do all the work, but I wanted to throw this idea out there first and see what people think, whether anyone has any better ideas, and so on. -Brent

Attachments:

attachment.html (text/html — 1.1 KB)

Show replies by date

David Roundy

26 Mar 26 Mar

10:51 a.m.

On Wed, Mar 26, 2008 at 10:37:48AM -0400, Brent Yorgey wrote:

...

So, this morning I began hacking up gaps as a LayoutModifier in contrib. I didn't get too far before I realized that in order to retain the same behavior as the current built-in gaps (*per screen* gap configuration), a layout needs to be able to know on which *screen* it is called! This is the point at which I had a profound sense of deja vu, since of course we had the same issue with PerWorkspace, only with *screen* replaced by *workspace*. gah!

I think, however, this could be useful information for other potential layouts as well -- I don't have any particular examples in mind, but having layouts that can behave differently depending on which screen they're on sounds like it could be useful for more than just per-screen gaps. So, I propose to add an extra screen parameter to runLayout and friends (which of course requires a bunch of trivial updates in contrib, unfortunately). I'm happy to do all the work, but I wanted to throw this idea out there first and see what people think, whether anyone has any better ideas, and so on.

Why not just check the rectangle against the screen rectangle? That sounds simpler and safer to me. -- David Roundy Department of Physics Oregon State University

Brent Yorgey

11:25 a.m.

On Wed, Mar 26, 2008 at 10:51 AM, David Roundy wrote:

...

Why not just check the rectangle against the screen rectangle? That sounds simpler and safer to me.

I'm not sure that I follow. Are different screens guaranteed to have different rectangles? -Brent

David Roundy

11:32 a.m.

On Wed, Mar 26, 2008 at 11:25:32AM -0400, Brent Yorgey wrote:

...

On Wed, Mar 26, 2008 at 10:51 AM, David Roundy wrote:

...
Why not just check the rectangle against the screen rectangle? That sounds simpler and safer to me.

I'm not sure that I follow. Are different screens guaranteed to have different rectangles?

If they don't have different rectangles, then they are displaying the same contents. A window isn't located on a "screen", it's located at a coordinate in an abstract space. If a point is in a screen rectangle then it's visible on that screen. If it's in multiple screen rectangles, then multiple screens are displaying it (which would be the case if you're mirroring content... I imagine xinerama can do this). So if two screens *do* have the same rectangle, then they ought to have the same gap (and really should hold the same workspace). -- David Roundy Department of Physics Oregon State University

Brent Yorgey

12:02 p.m.

On Wed, Mar 26, 2008 at 11:32 AM, David Roundy wrote:

...

On Wed, Mar 26, 2008 at 11:25:32AM -0400, Brent Yorgey wrote:

...
On Wed, Mar 26, 2008 at 10:51 AM, David Roundy wrote:

...
Why not just check the rectangle against the screen rectangle? That sounds simpler and safer to me.

I'm not sure that I follow. Are different screens guaranteed to have different rectangles?

If they don't have different rectangles, then they are displaying the same contents. A window isn't located on a "screen", it's located at a coordinate in an abstract space. If a point is in a screen rectangle then it's visible on that screen. If it's in multiple screen rectangles, then multiple screens are displaying it (which would be the case if you're mirroring content... I imagine xinerama can do this). So if two screens *do* have the same rectangle, then they ought to have the same gap (and really should hold the same workspace).

Aha! Thanks, David! I did not understand before that the coordinates of window and screen rectangles are relative to an absolute coordinate system *that extends over all screens*. I.e. I thought that each screen had its own separate coordinate system. Great, I'm really glad I sent a message to the list about this first! David's suggested approach of matching screen rectangles will work great, no need to go making modifications to the LayoutClass again. Gaps in contrib, coming soon! =) Perhaps I will even write a PerScreen extension module that will allow you to easily apply various layouts or modifiers on a per-screen basis, so Lee can easily have Reflected layouts on the left screen, and so on. But I probably won't get that done before 0.7. -Brent

David Roundy

1:30 p.m.

On Wed, Mar 26, 2008 at 12:02:46PM -0400, Brent Yorgey wrote:

...

Perhaps I will even write a PerScreen extension module that will allow you to easily apply various layouts or modifiers on a per-screen basis, so Lee can easily have Reflected layouts on the left screen, and so on. But I probably won't get that done before 0.7.

Note that even this feature could be done without PerScreen (provided the xinerma config correctly matches the physical layout) by reflecting the layout if the screen rectangle is to the left of the average of all screen rectangles (or to the left of a specified coordinate?). Which would mean also mean that the idea could be readily applied to combined layouts in a meaningful manner even in the absence of xinerama. (e.g. reflectLeftSide (tall *|* tall) would be identical to (reflect tall *|* tall) -- David Roundy Department of Physics Oregon State University

Spencer Janssen

2:12 p.m.

On Wed, Mar 26, 2008 at 11:32:38AM -0400, David Roundy wrote:

...

On Wed, Mar 26, 2008 at 11:25:32AM -0400, Brent Yorgey wrote:

...
On Wed, Mar 26, 2008 at 10:51 AM, David Roundy wrote:

...
Why not just check the rectangle against the screen rectangle? That sounds simpler and safer to me.

I'm not sure that I follow. Are different screens guaranteed to have different rectangles?

If they don't have different rectangles, then they are displaying the same contents. A window isn't located on a "screen", it's located at a coordinate in an abstract space. If a point is in a screen rectangle then it's visible on that screen. If it's in multiple screen rectangles, then multiple screens are displaying it (which would be the case if you're mirroring content... I imagine xinerama can do this). So if two screens *do* have the same rectangle, then they ought to have the same gap (and really should hold the same workspace). -- David Roundy Department of Physics Oregon State University

I note that we currently remove duplicated screen rectangles, so it is true that each screen is uniquely identified by rectangle. I'm not sure that I'd rely on this property too heavily, though. Cheers, Spencer Janssen

Mathias Stearn

11:12 a.m.

I could see this being useful if you have two monitors with one rotated to tall mode (looks like a sideways T). It would make sense for a given workspace to use a different layout if on the tall monitor. Mayhaps a mirrorIfOnScreen n l layout modifyer. On 3/26/08, Brent Yorgey wrote:

...

So, this morning I began hacking up gaps as a LayoutModifier in contrib. I didn't get too far before I realized that in order to retain the same behavior as the current built-in gaps (*per screen* gap configuration), a layout needs to be able to know on which *screen* it is called! This is the point at which I had a profound sense of deja vu, since of course we had the same issue with PerWorkspace, only with *screen* replaced by *workspace*. gah!

I think, however, this could be useful information for other potential layouts as well -- I don't have any particular examples in mind, but having layouts that can behave differently depending on which screen they're on sounds like it could be useful for more than just per-screen gaps. So, I propose to add an extra screen parameter to runLayout and friends (which of course requires a bunch of trivial updates in contrib, unfortunately). I'm happy to do all the work, but I wanted to throw this idea out there first and see what people think, whether anyone has any better ideas, and so on.

-Brent

_______________________________________________ xmonad mailing list xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad

David Roundy

11:15 a.m.

On Wed, Mar 26, 2008 at 11:12:24AM -0400, Mathias Stearn wrote:

...

I could see this being useful if you have two monitors with one rotated to tall mode (looks like a sideways T). It would make sense for a given workspace to use a different layout if on the tall monitor. Mayhaps a mirrorIfOnScreen n l layout modifyer.

Note that this could also be achieved by simply checking the rectangle provided, and laying things out based on its aspect ratio. This would have the same effect, and would also work well when used with layout combinators. -- David Roundy Department of Physics Oregon State University

Lee Aylward

11:55 a.m.

On Wed, Mar 26, 2008 at 11:12:24AM -0400, Mathias Stearn wrote:

...

I could see this being useful if you have two monitors with one rotated to tall mode (looks like a sideways T). It would make sense for a given workspace to use a different layout if on the tall monitor. Mayhaps a mirrorIfOnScreen n l layout modifyer.

I think this would also be useful when used in conjunction with Reflect. A while back I thought that it would be nice to reflect all layouts on my left screen. That way I could always keep the master window nearer to the center of my desktop. Is this possible now with the current set of Layouts? Thanks, -- Lee Aylward

Don Stewart

28 Mar 28 Mar

7:39 p.m.

lee:

...

On Wed, Mar 26, 2008 at 11:12:24AM -0400, Mathias Stearn wrote:

...
I could see this being useful if you have two monitors with one rotated to tall mode (looks like a sideways T). It would make sense for a given workspace to use a different layout if on the tall monitor. Mayhaps a mirrorIfOnScreen n l layout modifyer.

I think this would also be useful when used in conjunction with Reflect. A while back I thought that it would be nice to reflect all layouts on my left screen. That way I could always keep the master window nearer to the center of my desktop.

Is this possible now with the current set of Layouts?

That's a great use case I've thought would be nice, too.

Spencer Janssen

26 Mar 26 Mar

2:14 p.m.

On Wed, Mar 26, 2008 at 10:37:48AM -0400, Brent Yorgey wrote:

...

So, this morning I began hacking up gaps as a LayoutModifier in contrib. I didn't get too far before I realized that in order to retain the same behavior as the current built-in gaps (*per screen* gap configuration), a layout needs to be able to know on which *screen* it is called! This is the point at which I had a profound sense of deja vu, since of course we had the same issue with PerWorkspace, only with *screen* replaced by *workspace*. gah!

I think, however, this could be useful information for other potential layouts as well -- I don't have any particular examples in mind, but having layouts that can behave differently depending on which screen they're on sounds like it could be useful for more than just per-screen gaps. So, I propose to add an extra screen parameter to runLayout and friends (which of course requires a bunch of trivial updates in contrib, unfortunately). I'm happy to do all the work, but I wanted to throw this idea out there first and see what people think, whether anyone has any better ideas, and so on.

-Brent

Why bother with implementing the manual gap semantics as a layout? I'm planning on replacing gaps with avoidStruts -- can you demonstrate any advantages of manual gaps over avoidStruts? Cheers, Spencer Janssen

Brent Yorgey

6:25 p.m.

On Wed, Mar 26, 2008 at 2:14 PM, Spencer Janssen wrote:

...

...
So, this morning I began hacking up gaps as a LayoutModifier in contrib. I didn't get too far before I realized that in order to retain the same behavior as the current built-in gaps (*per screen* gap configuration), a layout needs to be able to know on which *screen* it is called! This is

...
point at which I had a profound sense of deja vu, since of course we had

On Wed, Mar 26, 2008 at 10:37:48AM -0400, Brent Yorgey wrote: the the

...
same issue with PerWorkspace, only with *screen* replaced by *workspace*. gah!

I think, however, this could be useful information for other potential layouts as well -- I don't have any particular examples in mind, but having layouts that can behave differently depending on which screen they're on sounds like it could be useful for more than just per-screen gaps. So, I propose to add an extra screen parameter to runLayout and friends (which of course requires a bunch of trivial updates in contrib, unfortunately). I'm happy to do all the work, but I wanted to throw this idea out there first and see what people think, whether anyone has any better ideas, and so on.

-Brent

Why bother with implementing the manual gap semantics as a layout? I'm planning on replacing gaps with avoidStruts -- can you demonstrate any advantages of manual gaps over avoidStruts?

Well, if all you are using gaps for is to avoid certain status bar/dock-type windows, then no; obviously a dedicated "manual gaps" module would be useful if you wanted gaps for any other reason. I can't think of any, though. As discussed on the IRC channel, I'll now focus my efforts on adding some features to ManageDocks (in particular, the ability to toggle gaps for different docks independently is important to me), which I'll push after the 0.7 release. I'll still keep my half-done gaps code around, though, just in case someone ends up wanting it. =) -Brent

6263

Age (days ago)

6265

Last active (days ago)

List overview

Download

12 comments

6 participants

participants (6)

Brent Yorgey
David Roundy
Don Stewart
Lee Aylward
Mathias Stearn
Spencer Janssen