On Thu, Jan 31, 2008 at 1:07 PM, Andrea Rossato < mailing_list@istitutocolli.org> wrote:
But it's not just about messages; we'd also need doLayoutInWorkspace and emptyLayoutInWorkspace. In particular xinerama support would not work without those. Since PerWorkspace is the only layout that could
On Thu, Jan 31, 2008 at 12:29:55PM -0500, Brent Yorgey wrote: possibly
use this information, adding three new methods to the LayoutClass just for this is almost certainly not the way to go.
Ok, so, if I get it right, you are proposing to go back to existential and everything just because you think it is wrong to extend a class, which, I was told, is just something you can extend without breaking what is built upon it.
I do not think it is wrong to extend a class *in general*. What I do think is not very elegant is to add *three new methods* to the LayoutClass (also requiring changes to the xmonad core so that it calls these new methods instead of the old ones), just to support a *single* layout. And no, these methods would not make the LayoutClass more general; this is the only layout I can conceivably think of that would need to know the tag of the workspace in which it is being called. Note I am also not proposing to go back to existential wrappers everywhere, I'm pretty sure I put a sad face next to that in my e-mail. =)
All this because you suppose PerWorspace is the only one that *may* be using a non pure combinator.
It has nothing to do with purity/non-purity. I assume you are referring to the thing with the 'description' method not having a result in the X monad? This is an orthogonal issue; I don't have a strong feeling about it one way or another. It is true that the only layout I have seen that could possibly need this, again, is PerWorkspace. But in any case the *main* point is to get PerWorkspace working with xinerama, which has nothing to do with the type of 'description', but about the need for somehow getting this extra information about what workspace a layout resides in. Regards, -Brent