[xmonad] The future of PerWorkspace

Brent Yorgey byorgey at gmail.com
Fri Feb 1 07:59:54 EST 2008


On Fri, Feb 1, 2008 at 1:48 AM, Andrea Rossato <
mailing_list at istitutocolli.org> wrote:

> On Fri, Feb 01, 2008 at 12:22:32AM -0600, Spencer Janssen wrote:
> > As far as I know, there has only been one other proposal that solves the
> > Xinerama issues with PerWorkspace -- adding a WorkspaceId argument to
> doLayout.
> > I think we've all agreed that isn't so nice.  My message proposal is
> actually
> > very similar -- except that only layouts that care about workspace
> location
> > need to handle these messages, whereas an extra argument to doLayout
> must be
> > mentioned in every single layout instance.
> >
> > Have you proposed another implementation that solves the Xinerama issue,
> and I
> > missed it?
>
> Yes you did. You actually did miss quite a lot of the stuff I've been
> sending recently. You are not the only one, though.
>

Hey, there's no need for that.  You have been sending rather a lot of stuff
lately, you know, you can't blame people for not quite being able to keep
up. =)


>
> As I say I did not propose to change doLayout, but just to change, in
> runLayout, doLayout with a doLayoutInWorkspace which takes the
> workspace and calls "doLayout (layout w)". The same for
> (emptyLayoutInWorkspace w = emptyLayout (layout w) and handleMessage.
>
> Did you read this message and the attached patch?
> http://www.haskell.org/pipermail/xmonad/2008-January/004493.html
>
> If a layout may be knowing the workspace it is running on, we could
> implement a general purpose combinator (my LayoutCombinator class and
> a general purpose CombinedLayout, implemented on top of the layout
> class.
>

Andrea, I would like to point out that having methods like
doLayoutInWorkspace and so on have nothing to do with the viability of your
LayoutCombinator class.  These methods have only to do with implementing
PerWorkspace in particular. In fact, I rather liked your LayoutCombinator
class and would like a chance to try implementing PerWorkspace using it
together with sjanssen's approach of special messages sent by a startup
hook.  I would like to ask if you can just re-push your LayoutCombinator
class and CombinedLayout combinator, without making any changes to
PerWorkspace?  That way it will not break anything and we can play around
with implementing things in terms of it.


>
> As I mention here:
> http://code.google.com/p/xmonad/issues/detail?id=129
> (I answered to your challenge, but you did not to mine!), with my
> proposal, PerWorkspace implementation would be:
>
> instance LayoutCombinator PerWorkspace a where
>    chooser (PerWorkspace wsIds) = do
>        t <- getCurrentTag
>        return $ if t `elem` wsIds then DoFirst else DoSecond
>

Again, you seem to be confusing the issue of the type of 'description' with
the problem of getting PerWorkspace to work with xinerama.  The above code
still would not work with xinerama, which is my main goal.  It also still
does not work with messages that may be sent to a non-focused workspace.

That implementation IS ACTUALLY working and has been in xmc repository
> for a couple of days. Than I had to remove it since I asked for core
> support and I was told I would not get it.
>

No, it wasn't; there is still the issue of messages sent to non-focused
workspaces, which probably wouldn't cause any problems most of the time (so
it appeared to work) but could cause subtle bugs.  I sent an explanation of
this to the list earlier.

Cheers,
-Brent
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/xmonad/attachments/20080201/3187de54/attachment.htm


More information about the xmonad mailing list