From darcswatch at nomeata.de  Thu May  1 00:45:48 2014
From: darcswatch at nomeata.de (darcswatch at nomeata.de)
Date: Thu, 01 May 2014 01:45:48 +0100
Subject: [xmonad] Applied: New XMonad layout based on bspwm
References: <CAEE_=c0zd-Jbep8_74mbkzcev_-tx+bfEyDyqYF=XM35uSAapA@mail.gmail.com>
Message-ID: <E1Wff8G-0007Gu-6m@urchin.earth.li>

This 1-patch bundle was just applied to http://code.haskell.org/XMonadContrib:

20140430205848  benweitzman at gmail.com
 * Add BinarySpacePartition layout 


-- 
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__code.haskell.org_XMonadContrib.html#bundle-c072bc84e8510079df25aa9013fe391463d9a2e8

From vogt.adam at gmail.com  Thu May  1 01:54:03 2014
From: vogt.adam at gmail.com (adam vogt)
Date: Wed, 30 Apr 2014 21:54:03 -0400
Subject: [xmonad] New XMonad layout based on bspwm
In-Reply-To: <CAEE_=c0zd-Jbep8_74mbkzcev_-tx+bfEyDyqYF=XM35uSAapA@mail.gmail.com>
References: <CAEE_=c0zd-Jbep8_74mbkzcev_-tx+bfEyDyqYF=XM35uSAapA@mail.gmail.com>
Message-ID: <CAHfjoWmJku+DeocFMr3Hvv0qsts2xsGcadmeX7shjqEh1rY5-Q@mail.gmail.com>

Hello Ben,

I've applied it. I've changed Bound to XMonad.Util.Types.Direction2D.
Swap conflicts with the Swap in XMonad.Layout.WindowNavigation, but I
dunno if it's worth giving it an odd name (Exchange or SwapBSP) to
help a few people avoid qualified imports.

Ideally the ExpandTowards R message should do something when the
window is already the right-most window on the screen. Probably that
action should be what ShrinkTowards L does. Or maybe it should be what
ExpandTowards L does. One way to get around that configuration mess is
have the message include a function.

There are other layouts (Mosaic and MosaicAlt) in contrib that also
recursively split areas in half. It might be nice to switch between a
more automatically balanced tree (Mosaic) and one in which the layout
is more "under your control".

Regards,
Adam

On Wed, Apr 30, 2014 at 5:17 PM, Ben Weitzman <benweitzman at gmail.com> wrote:
> Hi,
>
> I've written a binary space partition layout based of bspwm. Each time a
> window is inserted, it splits the current window into two. You can resize,
> rotate, and swap the leafs of the BSP tree around.
>
> Attached is the darcs patch.
>
> Cheers,
> Ben
>
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>

From benweitzman at gmail.com  Thu May  1 02:21:54 2014
From: benweitzman at gmail.com (Ben Weitzman)
Date: Wed, 30 Apr 2014 22:21:54 -0400
Subject: [xmonad] New XMonad layout based on bspwm
In-Reply-To: <CAHfjoWmJku+DeocFMr3Hvv0qsts2xsGcadmeX7shjqEh1rY5-Q@mail.gmail.com>
References: <CAEE_=c0zd-Jbep8_74mbkzcev_-tx+bfEyDyqYF=XM35uSAapA@mail.gmail.com>
 <CAHfjoWmJku+DeocFMr3Hvv0qsts2xsGcadmeX7shjqEh1rY5-Q@mail.gmail.com>
Message-ID: <CAEE_=c3QakTpNfsLXmBNZY73-9URMRgDW9oTe3VcEWTDVtFDmw@mail.gmail.com>

Thanks Adam,

First of all, thanks for the name conflict info. Even after a year with
XMonad there are still lots of things I don't know :)

Could you clarify why you think ExpandTowards R should do something if the
window is up against the right edge? It seems like it might be
counterintuitive for a window to grow towards the left if it can't grow
towards the right. Perhaps a more general Expand or Expand
Vertical/Horizontal message would be helpful?

Ben


On Wed, Apr 30, 2014 at 9:54 PM, adam vogt <vogt.adam at gmail.com> wrote:

> Hello Ben,
>
> I've applied it. I've changed Bound to XMonad.Util.Types.Direction2D.
> Swap conflicts with the Swap in XMonad.Layout.WindowNavigation, but I
> dunno if it's worth giving it an odd name (Exchange or SwapBSP) to
> help a few people avoid qualified imports.
>
> Ideally the ExpandTowards R message should do something when the
> window is already the right-most window on the screen. Probably that
> action should be what ShrinkTowards L does. Or maybe it should be what
> ExpandTowards L does. One way to get around that configuration mess is
> have the message include a function.
>
> There are other layouts (Mosaic and MosaicAlt) in contrib that also
> recursively split areas in half. It might be nice to switch between a
> more automatically balanced tree (Mosaic) and one in which the layout
> is more "under your control".
>
> Regards,
> Adam
>
> On Wed, Apr 30, 2014 at 5:17 PM, Ben Weitzman <benweitzman at gmail.com>
> wrote:
> > Hi,
> >
> > I've written a binary space partition layout based of bspwm. Each time a
> > window is inserted, it splits the current window into two. You can
> resize,
> > rotate, and swap the leafs of the BSP tree around.
> >
> > Attached is the darcs patch.
> >
> > Cheers,
> > Ben
> >
> > _______________________________________________
> > xmonad mailing list
> > xmonad at haskell.org
> > http://www.haskell.org/mailman/listinfo/xmonad
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140430/7f0a808f/attachment.html>

From vogt.adam at gmail.com  Thu May  1 17:32:01 2014
From: vogt.adam at gmail.com (adam vogt)
Date: Thu, 1 May 2014 13:32:01 -0400
Subject: [xmonad] New XMonad layout based on bspwm
In-Reply-To: <CAEE_=c3QakTpNfsLXmBNZY73-9URMRgDW9oTe3VcEWTDVtFDmw@mail.gmail.com>
References: <CAEE_=c0zd-Jbep8_74mbkzcev_-tx+bfEyDyqYF=XM35uSAapA@mail.gmail.com>
 <CAHfjoWmJku+DeocFMr3Hvv0qsts2xsGcadmeX7shjqEh1rY5-Q@mail.gmail.com>
 <CAEE_=c3QakTpNfsLXmBNZY73-9URMRgDW9oTe3VcEWTDVtFDmw@mail.gmail.com>
Message-ID: <CAHfjoWnGFWvtBgdGyCQoB1Xu6wsnVwKv-BSCK5SSEEazknvoWw@mail.gmail.com>

Hi Ben,

ExpandTowards R could mean something like "grow the current window,
preferably shrinking the one(s) to the right". Yes it might be
counterintuitive, but my opinion is that a layout should do something
somewhat sensible instead of nothing. I don't mind if that's a
separate message. To expand on my suggestion earlier, you might add a
message:

 data ModifyTree = ModifyTree (Zipper Split -> Maybe (Zipper Split))

>From which it would be straightforward to make up a "counterintuitive"
keybindings with something like:

moveABorderToTheLeft :: X ()
moveABorderToTheLeft = sendMessage $
   ModifyTree $ msum [
                           expandTreeTowards L,
                           shrinkTreeTowards R]

Possibly make an instance Monoid ModifyTree that does what the
MonadPlus instance used above does, and then it could be a pretty as:

  ("M-<Left>", sendMessage (expandTreeTowards' L <> shrinkTreeTowards' R)),

where expandTreeTowards' :: Direction2D -> ModifyTree is exported by
the BSP module.

Regards,
Adam

On Wed, Apr 30, 2014 at 10:21 PM, Ben Weitzman <benweitzman at gmail.com> wrote:
> Thanks Adam,
>
> First of all, thanks for the name conflict info. Even after a year with
> XMonad there are still lots of things I don't know :)
>
> Could you clarify why you think ExpandTowards R should do something if the
> window is up against the right edge? It seems like it might be
> counterintuitive for a window to grow towards the left if it can't grow
> towards the right. Perhaps a more general Expand or Expand
> Vertical/Horizontal message would be helpful?
>
> Ben
>
>
> On Wed, Apr 30, 2014 at 9:54 PM, adam vogt <vogt.adam at gmail.com> wrote:
>>
>> Hello Ben,
>>
>> I've applied it. I've changed Bound to XMonad.Util.Types.Direction2D.
>> Swap conflicts with the Swap in XMonad.Layout.WindowNavigation, but I
>> dunno if it's worth giving it an odd name (Exchange or SwapBSP) to
>> help a few people avoid qualified imports.
>>
>> Ideally the ExpandTowards R message should do something when the
>> window is already the right-most window on the screen. Probably that
>> action should be what ShrinkTowards L does. Or maybe it should be what
>> ExpandTowards L does. One way to get around that configuration mess is
>> have the message include a function.
>>
>> There are other layouts (Mosaic and MosaicAlt) in contrib that also
>> recursively split areas in half. It might be nice to switch between a
>> more automatically balanced tree (Mosaic) and one in which the layout
>> is more "under your control".
>>
>> Regards,
>> Adam
>>
>> On Wed, Apr 30, 2014 at 5:17 PM, Ben Weitzman <benweitzman at gmail.com>
>> wrote:
>> > Hi,
>> >
>> > I've written a binary space partition layout based of bspwm. Each time a
>> > window is inserted, it splits the current window into two. You can
>> > resize,
>> > rotate, and swap the leafs of the BSP tree around.
>> >
>> > Attached is the darcs patch.
>> >
>> > Cheers,
>> > Ben
>> >
>> > _______________________________________________
>> > xmonad mailing list
>> > xmonad at haskell.org
>> > http://www.haskell.org/mailman/listinfo/xmonad
>> >
>
>

From codesite-noreply at google.com  Thu May  1 20:10:01 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 01 May 2014 20:10:01 +0000
Subject: [xmonad] Issue 563 in xmonad: xmonad-contrib build fails on
	MultiToggle.hs
In-Reply-To: <4-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>
References: <4-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>
Message-ID: <5-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>


Comment #5 on issue 563 by sim... at cryp.to: xmonad-contrib build fails on  
MultiToggle.hs
http://code.google.com/p/xmonad/issues/detail?id=563

This error still exists when building the current release version of  
xmonad/xmonad-contrib with GHC 7.8.2. Is there any chance that a fix for  
this issue could be made available on Hackage?

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Thu May  1 20:37:32 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 01 May 2014 20:37:32 +0000
Subject: [xmonad] Issue 563 in xmonad: xmonad-contrib build fails on
	MultiToggle.hs
In-Reply-To: <5-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>
References: <5-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>
Message-ID: <6-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>


Comment #6 on issue 563 by Ian... at gmail.com: xmonad-contrib build fails on  
MultiToggle.hs
http://code.google.com/p/xmonad/issues/detail?id=563

@ sim... at cryp.to. I originally filed the bug, and the suggested fix of  
compiling from darcs worked for me (it took a while to get around to it and  
I forgot to comment on the bug). Does it work for you?

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Thu May  1 21:21:34 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 01 May 2014 21:21:34 +0000
Subject: [xmonad] Issue 563 in xmonad: xmonad-contrib build fails on
	MultiToggle.hs
In-Reply-To: <6-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>
References: <6-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>
Message-ID: <7-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>


Comment #7 on issue 563 by sim... at cryp.to: xmonad-contrib build fails on  
MultiToggle.hs
http://code.google.com/p/xmonad/issues/detail?id=563

Well, I can verify that adding the "ambiguous types" extension to the Cabal  
file remedies the issue.

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Fri May  2 01:42:18 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 02 May 2014 01:42:18 +0000
Subject: [xmonad] Issue 563 in xmonad: xmonad-contrib build fails on
	MultiToggle.hs
In-Reply-To: <7-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>
References: <7-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>
Message-ID: <8-3425899027203913298-4763048127870894210-codesite-noreply=google.com@googlecode.com>


Comment #8 on issue 563 by vogt.a... at gmail.com: xmonad-contrib build fails  
on MultiToggle.hs
http://code.google.com/p/xmonad/issues/detail?id=563

I uploaded 0.11.3 which has the fix we put in darcs.

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sat May  3 05:11:34 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sat, 03 May 2014 05:11:34 +0000
Subject: [xmonad] Issue 566 in xmonad: xmonad gives bogus configure events
Message-ID: <0-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 566 by StevensE... at gmail.com: xmonad gives bogus configure events
http://code.google.com/p/xmonad/issues/detail?id=566

What steps will reproduce the problem?
1. Compile the program below.
2. Run it.
3. Move the mouse pointer between windows.

What is the expected output? What do you see instead?

I don't expect to see configure events being generated and I certainly  
don't expect bogus broken ones to be generated.

What version of the product are you using? On what operating system?
xmonad 0.10, Linux

Are you using an xmonad.hs?  Please attach it and the output of "xmonad
--recompile".

import XMonad

import qualified XMonad.StackSet as W

import XMonad.Layout.MouseResizableTile
import XMonad.Layout.WindowNavigation
import XMonad.Layout.LayoutHints
import XMonad.Layout.Fullscreen

import XMonad.Hooks.Minimize
import XMonad.Layout.Minimize
import XMonad.Hooks.ManageHelpers
import XMonad.Hooks.ManageDocks
import XMonad.Hooks.FadeInactive

import XMonad.Util.EZConfig
import XMonad.Util.Run

import XMonad.Prompt
import XMonad.Prompt.RunOrRaise
import XMonad.Prompt.Shell

import XMonad.Config.Kde


main = do
   spawn "xmodmap -e 'keycode 135 = Super_R'"
   xmonad myConfig

baseConfig = kde4Config

myConfig = baseConfig
  { modMask = mod4Mask
  , borderWidth = 0
  , workspaces = fmap show [1 .. 4]
  , handleEventHook = myEventHook (handleEventHook baseConfig)
  , layoutHook = myLayout
  , manageHook = myManageHook (manageHook baseConfig)
  , logHook = myLogHook (logHook baseConfig)
  } `additionalKeysP`
  [ ("M-a", windows W.focusUp)
  , ("M-e", windows W.focusDown)

  , ("M-C-a", windows W.swapUp)
  , ("M-C-e", windows W.swapDown)

  , ("M-k", sendMessage ShrinkSlave)
  , ("M-j", sendMessage ExpandSlave)

  , ("M-p", shellPrompt $ defaultXPConfig {
            position = Top,
            height = 20
        })

  , ("M-<Return>", spawn "exec emacs")
  , ("M-S-<Return>", spawn "exec abrowser")
  ]

myEventHook baseHook =
   minimizeEventHook
   <+> hintsEventHook
   <+> baseHook
   <+> fullscreenEventHook

myManageHook baseHook = composeAll [
   baseHook
   , className =? "Do" --> doFloat
   , className =? "plasma-desktop" --> doFloat
   , className =? "Plasma-desktop" --> doFloat
   , className =? "klipper" --> doFloat
   , className =? "Klipper" --> doFloat
   , fullscreenManageHook]

myLayout =
   ( fullscreenFull
   . windowNavigation
   . avoidStrutsOn []
   . layoutHintsToCenter
   . minimize
   ) myBasicLayout

myBasicLayout = tileLayout ||| tileLayout { isMirrored = True } ||| Full  
where
   tileLayout = mouseResizableTile {
     draggerType = FixedDragger {
                 gapWidth = 5
                 , draggerWidth = 6
        }
     }

myLogHook baseLogHook = do
   baseLogHook
   fadeInactiveLogHook 0xee000000


Please provide any additional information below.

The C program:

#include <assert.h>
#include <errno.h>
#include <poll.h>
#include <math.h>
#include <stdbool.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <GL/glx.h>
#include <xcb/xcb.h>
#include <X11/Xlib.h>
#include <X11/Xlib-xcb.h>
#include <unistd.h>

static int errnum_from_connection(xcb_connection_t * connection)
{
     switch (xcb_connection_has_error(connection)) {
     case 0:
         return 0;

     case XCB_CONN_ERROR:
         return EPROTO;

     case XCB_CONN_CLOSED_EXT_NOTSUPPORTED:
         return ENOSYS;

     case XCB_CONN_CLOSED_MEM_INSUFFICIENT:
         return ENOMEM;

     case XCB_CONN_CLOSED_REQ_LEN_EXCEED:
         return EINVAL;

     case XCB_CONN_CLOSED_PARSE_ERR:
         return EINVAL;

     default:
         assert(false);
     }
}

int main(int argc, char *argv[])
{
     int error_status = 0;

     Display * display = XOpenDisplay(NULL);
     if (NULL == display) {
         perror("XOpenDisplay");
     }

     xcb_connection_t * connection = XGetXCBConnection(display);
     unsigned screen_number = XDefaultScreen(display);

     xcb_screen_t * screen = NULL;
     {
         xcb_screen_iterator_t iter =  
xcb_setup_roots_iterator(xcb_get_setup(connection));
         for (size_t ii = 0; ii < screen_number; ++ii) {
             if (0 == iter.rem) {
                 break;
             }

             xcb_screen_next (&iter);
         }

         if (0 == iter.rem) {
             error_status = EINVAL;
             goto disconnect;
         }

         screen = iter.data;
     }

     /* Query framebuffer configurations */
     GLXFBConfig fb_config;
     {
         static int const attrib_list[] = {
             GLX_BUFFER_SIZE, 0,       /* color index buffer size */
             GLX_LEVEL, 0    ,         /* buffer-level */
             GLX_DOUBLEBUFFER, True,   /* double buffer */

             GLX_STEREO, False,
             GLX_AUX_BUFFERS, 0,

             GLX_RED_SIZE, GLX_DONT_CARE,
             GLX_GREEN_SIZE, GLX_DONT_CARE,
             GLX_BLUE_SIZE, GLX_DONT_CARE,
             GLX_ALPHA_SIZE, GLX_DONT_CARE,

             GLX_DEPTH_SIZE, 16,

             GLX_STENCIL_SIZE, 0,
             GLX_ACCUM_RED_SIZE, 0,
             GLX_ACCUM_GREEN_SIZE, 0,
             GLX_ACCUM_BLUE_SIZE, 0,
             GLX_ACCUM_ALPHA_SIZE, 0,
             GLX_RENDER_TYPE, GLX_RGBA_BIT,

             GLX_DRAWABLE_TYPE, GLX_WINDOW_BIT,

             GLX_X_RENDERABLE, True,

             GLX_X_VISUAL_TYPE, GLX_DONT_CARE,

             GLX_CONFIG_CAVEAT, GLX_DONT_CARE,

             GLX_TRANSPARENT_TYPE, GLX_NONE,

             GLX_TRANSPARENT_INDEX_VALUE, GLX_DONT_CARE,
             GLX_TRANSPARENT_RED_VALUE, GLX_DONT_CARE,
             GLX_TRANSPARENT_GREEN_VALUE, GLX_DONT_CARE,
             GLX_TRANSPARENT_BLUE_VALUE, GLX_DONT_CARE,
             GLX_TRANSPARENT_ALPHA_VALUE, GLX_DONT_CARE,
             None
         };

         int configs_count;
         GLXFBConfig *configs = glXChooseFBConfig(display, screen_number,
                                                  attrib_list,
                                                  &configs_count);
         if (NULL == configs) {
             error_status = ENOSYS;
             goto disconnect;
         }
         fb_config = configs[0];
         XFree(configs);
     }

     int visual_id;
     switch (glXGetFBConfigAttrib(display, fb_config, GLX_VISUAL_ID,  
&visual_id)) {
     case GLX_NO_EXTENSION:
     case GLX_BAD_ATTRIBUTE:
         error_status = ENOSYS;
         goto disconnect;

     default:
         break;
     }

     GLXContext glx_context = glXCreateNewContext(display, fb_config,  
GLX_RGBA_TYPE, 0, true);
     if (NULL == glx_context) {
         error_status = ENOSYS;
         goto disconnect;
     }

     xcb_colormap_t colormap = xcb_generate_id(connection);
     if ((error_status = errnum_from_connection(connection)) != 0) {
         goto destroy_glx_context;
     }

     xcb_create_colormap(connection, XCB_COLORMAP_ALLOC_NONE,
                         colormap,
                         screen->root,
                         visual_id);
     if ((error_status = errnum_from_connection(connection)) != 0) {
         goto destroy_glx_context;
     }

     xcb_window_t window = xcb_generate_id(connection);
     if ((error_status = errnum_from_connection(connection)) != 0) {
         goto destroy_glx_context;
     }

     {
         uint32_t values[] = {XCB_EVENT_MASK_STRUCTURE_NOTIFY, colormap, 0};
         xcb_create_window(connection,
                           XCB_COPY_FROM_PARENT,
                           window,
                           screen->root,
                           0, 0,
                           540, 480,
                           0,
                           XCB_WINDOW_CLASS_INPUT_OUTPUT,
                           visual_id,
                           XCB_CW_EVENT_MASK | XCB_CW_COLORMAP, values);
     }
     if ((error_status = errnum_from_connection(connection)) != 0) {
         goto disconnect;
     }

     xcb_map_window(connection, window);
     if ((error_status = errnum_from_connection(connection)) != 0) {
         goto destroy_window;
     }

     xcb_flush(connection);
     if ((error_status = errnum_from_connection(connection)) != 0) {
         goto destroy_window;
     }

     GLXWindow glxwindow = glXCreateWindow(display,
                                           fb_config,
                                           window,
                                           0);
     if (!window) {
         error_status = ENOSYS;
         goto destroy_window;
     }

     xcb_atom_t wm_delete_window;
     {
         xcb_intern_atom_cookie_t cookie = xcb_intern_atom(connection, 1, 12,
                                                           "WM_PROTOCOLS");
         if ((error_status = errnum_from_connection(connection)) != 0) {
             goto destroy_glx_window;
         }

         xcb_generic_error_t *error = NULL;
         xcb_intern_atom_reply_t* reply = xcb_intern_atom_reply(connection,  
cookie, &error);
         if ((error_status = errnum_from_connection(connection)) != 0) {
             goto destroy_glx_window;
         }
         if (error != NULL) {
             free(error);
             error_status = ENOSYS;
             goto destroy_glx_window;
         }

         xcb_atom_t wm_protocols = reply->atom;
         free(reply);

         xcb_intern_atom_cookie_t cookie2 = xcb_intern_atom(connection, 0,  
16,
                                                            "WM_DELETE_WINDOW");
         if ((error_status = errnum_from_connection(connection)) != 0) {
             goto destroy_glx_window;
         }

         xcb_intern_atom_reply_t* reply2 = xcb_intern_atom_reply(connection,  
cookie2, &error);
         if ((error_status = errnum_from_connection(connection)) != 0) {
             goto destroy_glx_window;
         }
         if (error != NULL) {
             free(error);
             error_status = ENOSYS;
             goto destroy_glx_window;
         }

         wm_delete_window = reply2->atom;
         free(reply2);

         xcb_change_property(connection, XCB_PROP_MODE_REPLACE, window,  
wm_protocols, 4, 32, 1,
                             &wm_delete_window);
         if ((error_status = errnum_from_connection(connection)) != 0) {
             goto destroy_glx_window;
         }
     }

     if (!glXMakeContextCurrent(display,
                                glxwindow,
                                glxwindow,
                                glx_context)) {
         error_status = ENOSYS;
         goto destroy_glx_window;
     }

     for (;;) {
         /* Handle GUI events first before rendering */
         /* We have to use the Xlib event queue because of broken Mesa
          * libraries which abuse it.
          */
         XEvent event;
         XNextEvent(display, &event);
         switch (event.type) {
             {
             case ConfigureNotify:;
                 XConfigureEvent* configure_event = (void*)&event;

                 fprintf(stderr,
                         "Configure:\n"
                         "serial: %lu\n"
                         "send_event: %u\n"
                         "display: %p\n"
                         "x: %i y: %i\n"
                         "width: %i height: %i!\n"
                         "border_width: %u\n",
                         configure_event->serial,
                         configure_event->send_event,
                         configure_event->display,
                         configure_event->x, configure_event->y,
                         configure_event->width, configure_event->height,
                         configure_event->border_width);

                 glViewport(0, 0, configure_event->width,  
configure_event->height);
                 glClear(GL_COLOR_BUFFER_BIT);
                 glXSwapBuffers(display, glxwindow);
                 break;
             }

         case ClientMessage:;
             goto cleanup_gl;

         default:
             /* Unknown event type, ignore it */
             break;
         }
     }

  cleanup_gl:

  destroy_glx_window:
     glXDestroyWindow(display, glxwindow);

  destroy_window:
     xcb_destroy_window(connection, window);
     {
         int errnum = errnum_from_connection(connection);
         if (0 == error_status) {
             error_status = errnum;
         }
     }

  destroy_glx_context:
     glXMakeContextCurrent(display, None, None, NULL);
     glXDestroyContext(display, glx_context);

  disconnect:
     xcb_flush(connection);
     {
         int errnum = errnum_from_connection(connection);
         if (0 == error_status) {
             error_status = errnum;
         }
     }

     XCloseDisplay(display);

  shutdown:

     return error_status;
}


-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From maschinenraum at texttheater.net  Sat May  3 09:36:08 2014
From: maschinenraum at texttheater.net (Kilian Evang)
Date: Sat, 03 May 2014 11:36:08 +0200
Subject: [xmonad] smartBorders and fullscreen Firefox
Message-ID: <5364B888.8050101@texttheater.net>

Hi all,

I'm using Ubuntu 12.04's "Gnome with Xmonad" session, currently with the
following config:

https://github.com/texttheater/.xmonad/blob/3e73e43cbfc57d418281c60dc700e494f7812183/xmonad.hs

As you can see, I have it set up so that fullscreen windows cover the
whole screen, including the Gnome panels

For Firefox, this required some extra work because apparently
isFullscreen doesn't trigger when Firefox goes fullscreen. Luckily,
there is XMonad.Layout.Fullscreen.fullscreenEventHook and
XMonad.Layout.Fullscreen.fullscreenFull to handle this.

What still doesn't work is for XMonad.Layout.NoBorders to notice when
Firefox goes fullscreen. Although I'm using smartBorders, a border
around the fullscreen Firefox window is still drawn as long as there is
another window on the same workspace.

Can I tweak my config so that this border goes away?

Also, should the NoBorders module be improved to handle this situation?

Cheers,
Kilian

From likan26.09 at yandex.ru  Sat May  3 15:35:01 2014
From: likan26.09 at yandex.ru (Ivan Ivanov)
Date: Sat, 03 May 2014 19:35:01 +0400
Subject: [xmonad] sendMessage Expand
Message-ID: <1213701399131301@web6g.yandex.ru>

Hello everybody. I'm newby in xmonad. I use this config ( http://pastebin.com/Dq1M4pWd) I trying to underestand Expand mechanism (masterkey + h in this config ), because it doesn't work on this (http://itmages.ru/image/view/1646784/12abfc9d) layout. How can I expand size of the left window? Sorry for my English ;-)

From allbery.b at gmail.com  Sat May  3 16:41:22 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sat, 3 May 2014 12:41:22 -0400
Subject: [xmonad] sendMessage Expand
In-Reply-To: <1213701399131301@web6g.yandex.ru>
References: <1213701399131301@web6g.yandex.ru>
Message-ID: <CAKFCL4VukR7+r6FCt4YdepaqVd8+BsxLsSeft1iPjg0td7twtg@mail.gmail.com>

On Sat, May 3, 2014 at 11:35 AM, Ivan Ivanov <likan26.09 at yandex.ru> wrote:

> Hello everybody. I'm newby in xmonad. I use this config (
> http://pastebin.com/Dq1M4pWd) I trying to underestand Expand mechanism
> (masterkey + h in this config ), because it doesn't work on this (
> http://itmages.ru/image/view/1646784/12abfc9d) layout. How can I expand
> size of the left window? Sorry for my English ;-)
>

You want the Expand message to be handled by LayoutBuilder's LayoutN; but
that layout passes it to the currently focused sub-layout (which, showing
only a single window at a time, ignores it). I think you'd need a custom
variant of LayoutBuilder to get it to support Expand / Shrink messages.

-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140503/a132c96d/attachment.html>

From codesite-noreply at google.com  Sat May  3 19:43:29 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sat, 03 May 2014 19:43:29 +0000
Subject: [xmonad] Issue 566 in xmonad: xmonad gives bogus configure
	events
In-Reply-To: <0-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
References: <0-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
Message-ID: <1-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>


Comment #1 on issue 566 by StevensE... at gmail.com: xmonad gives bogus  
configure events
http://code.google.com/p/xmonad/issues/detail?id=566

I should mention that the windows need to be console windows (the kind that  
have to be multiples of the console character size) to trigger the  
configure events.

Also, here is a much simpler version of the code.

#include <assert.h>
#include <errno.h>
#include <poll.h>
#include <math.h>
#include <stdbool.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <GL/glx.h>
#include <X11/Xlib.h>
#include <unistd.h>

int main(int argc, char *argv[])
{
     int error_status = 0;

     Display * display = XOpenDisplay(NULL);
     if (NULL == display) {
         perror("XOpenDisplay");
     }

     unsigned screen_number = XDefaultScreen(display);

     /* Query framebuffer configurations */
     XVisualInfo visual_info;
     {
         static int const attrib_list[] = {
             GLX_RGBA, True,

             GLX_RED_SIZE, 5,
             GLX_GREEN_SIZE, 5,
             GLX_BLUE_SIZE, 3,

             GLX_DOUBLEBUFFER, True,
             GLX_DEPTH_SIZE, 16,
             None
         };

         XVisualInfo *ptr = glXChooseVisual(display, screen_number,
                                            (int*)attrib_list);
         if (NULL == ptr) {
             error_status = ENOSYS;
             goto disconnect;
         }
         visual_info = *ptr;
         XFree(ptr);
     }

     Colormap cmap = XCreateColormap(display, DefaultRootWindow(display),
                                     visual_info.visual, AllocNone);

     XSetWindowAttributes attributes;
     memset(&attributes, 0, sizeof attributes);

     attributes.colormap = cmap;
     attributes.event_mask = StructureNotifyMask;

     Window window = XCreateWindow(display,
                                   RootWindow(display, visual_info.screen),
                                   0, 0,
                                   600, 600,
                                   0,
                                   visual_info.depth,
                                   InputOutput, visual_info.visual,
                                   CWColormap | CWEventMask, &attributes);

     XMapWindow(display, window);

     GLXContext glx_context = glXCreateContext(display, &visual_info, NULL,  
GL_TRUE);
     if (NULL == glx_context) {
         error_status = ENOSYS;
         goto destroy_window;
     }

     if (!glXMakeContextCurrent(display,
                                window,
                                window,
                                glx_context)) {
         error_status = ENOSYS;
         goto destroy_window;
     }

     for (;;) {
         /* Handle GUI events first before rendering */
         /* We have to use the Xlib event queue because of broken Mesa
          * libraries which abuse it.
          */
         XEvent event;
         XNextEvent(display, &event);
         switch (event.type) {
             {
             case ConfigureNotify:;
                 XConfigureEvent* configure_event = &event.xconfigure;

                 fprintf(stderr,
                         "Configure:\n"
                         "serial: %lu\n"
                         "send_event: %u\n"
                         "display: %p\n"
                         "x: %i y: %i\n"
                         "width: %i height: %i!\n"
                         "border_width: %u\n",
                         configure_event->serial,
                         configure_event->send_event,
                         configure_event->display,
                         configure_event->x, configure_event->y,
                         configure_event->width, configure_event->height,
                         configure_event->border_width);

                 glViewport(0, 0, configure_event->width,  
configure_event->height);
                 glClear(GL_COLOR_BUFFER_BIT);
                 glXSwapBuffers(display, window);
                 break;
             }

         case ClientMessage:;
             goto destroy_glx_context;

         default:
             /* Unknown event type, ignore it */
             break;
         }
     }

  destroy_glx_context:
     glXMakeContextCurrent(display, None, None, NULL);
     glXDestroyContext(display, glx_context);

  destroy_window:
     XDestroyWindow(display, window);

  disconnect:
     XCloseDisplay(display);

  shutdown:

     return error_status;
}


-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From linxray at gmail.com  Sun May  4 09:20:56 2014
From: linxray at gmail.com (Lei Chen)
Date: Sun, 4 May 2014 17:20:56 +0800
Subject: [xmonad] Newbie first patch to make the **Ssh** extension work with
	user.
Message-ID: <CAByXYiuMHxaZdv62XnMnYqC0=Et6DqONo=nud6DaNeXH5Evh8g@mail.gmail.com>

Hi,

The patch add *user* support to the *Ssh* extension, .e.g ssh admin at host.
By the way, it is the first time i write haskell code snippet for a great
project. If there is anything wrong with the code, code style, comment,
 please let me know.
The *XMonad* is awesome, i love it.

-- 
No pain ,No gain!
>From Ray!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140504/779f3d42/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: promptsshsupportuserprefix.dpatch
Type: application/octet-stream
Size: 15651 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140504/779f3d42/attachment-0001.obj>

From likan26.09 at yandex.ru  Sun May  4 17:23:19 2014
From: likan26.09 at yandex.ru (Ivan Ivanov)
Date: Sun, 04 May 2014 21:23:19 +0400
Subject: [xmonad] sendMessage Expand
In-Reply-To: <CAKFCL4VukR7+r6FCt4YdepaqVd8+BsxLsSeft1iPjg0td7twtg@mail.gmail.com>
References: <1213701399131301@web6g.yandex.ru>
 <CAKFCL4VukR7+r6FCt4YdepaqVd8+BsxLsSeft1iPjg0td7twtg@mail.gmail.com>
Message-ID: <2355001399224199@web26g.yandex.ru>

Is there other ways to resize windows in this layout, without using Expand/Shrink messages?

03.05.2014, 20:41, "Brandon Allbery" <allbery.b at gmail.com>:
> On Sat, May 3, 2014 at 11:35 AM, Ivan Ivanov <likan26.09 at yandex.ru> wrote:
>> Hello everybody. I'm newby in xmonad. I use this config ( http://pastebin.com/Dq1M4pWd) I trying to underestand Expand mechanism (masterkey + h in this config ), because it doesn't work on this (http://itmages.ru/image/view/1646784/12abfc9d) layout. How can I expand size of the left window? Sorry for my English ;-)
>
> You want the Expand message to be handled by LayoutBuilder's LayoutN; but that layout passes it to the currently focused sub-layout (which, showing only a single window at a time, ignores it). I think you'd need a custom variant of LayoutBuilder to get it to support Expand / Shrink messages.
>
> --
> brandon s allbery kf8nh ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? sine nomine associates
> allbery.b at gmail.com ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad ? ? ? ?http://sinenomine.net

From oneself at gmail.com  Sun May  4 18:49:13 2014
From: oneself at gmail.com (Eyal Erez)
Date: Sun, 4 May 2014 14:49:13 -0400
Subject: [xmonad] Trouble Rebinding ToggleStruts
Message-ID: <CAJiJgM0SPd6zeRJ+Je8hvXv8DK0Znz5tR=1yqdAChSdDSB2-6w@mail.gmail.com>

Hi,

I've been having a lot of trouble with xmobar after a recent upgrade.  I'm
using xmobar v0.20.1 and xmonad v0.11.  At first, xmonad stopped respecting
show struts and was continuously covering xmobar.  I then changed my
xmonad.hs from this:

main = do
  xmproc <- spawnPipe "xmobar"
  xmonad $ defaultConfig
             { logHook = takeTopFocus >> dynamicLogWithPP (xmobarPP
                         { ppOutput = hPutStrLn xmproc
                         , ppTitle = xmobarColor "#A8FC46" "" . shorten 50
                         , ppOrder = \(ws:_:t:_) -> [ws, t]
                         })
             -- Other definitions.
             }
To this:
main = xmonad =<< xmobar defaultConfig
        {  -- no logHook defined
        -- Other definitions.
        }

This works fine, but now for some reason, Alt-B is bound to ToggleStruts.
 I would like this to be Ctrl-Shift-B, and I have a key binding which adds
the second one, but I can't seem to get rid of the first.

How can I unbind Alt-B, and where is it coming from?

-- 
*Eyal Erez <**oneself at gmail.com* <oneself at gmail.com>*>*

There are 10 types of people, those who know binary and those who don't.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140504/a9d9b3ac/attachment.html>

From allbery.b at gmail.com  Sun May  4 20:58:27 2014
From: allbery.b at gmail.com (Brandon Allbery)
Date: Sun, 4 May 2014 16:58:27 -0400
Subject: [xmonad] Trouble Rebinding ToggleStruts
In-Reply-To: <CAJiJgM0SPd6zeRJ+Je8hvXv8DK0Znz5tR=1yqdAChSdDSB2-6w@mail.gmail.com>
References: <CAJiJgM0SPd6zeRJ+Je8hvXv8DK0Znz5tR=1yqdAChSdDSB2-6w@mail.gmail.com>
Message-ID: <CAKFCL4V+1=hQHOq5AA9wFrjJKavG9KmU_+jtByQ9DTCvH4Zq=g@mail.gmail.com>

On Sun, May 4, 2014 at 2:49 PM, Eyal Erez <oneself at gmail.com> wrote:

> To this:
> main = xmonad =<< xmobar defaultConfig
>         {  -- no logHook defined
>          -- Other definitions.
>         }
>
> This works fine, but now for some reason, Alt-B is bound to ToggleStruts.
>  I would like this to be Ctrl-Shift-B, and I have a key binding which adds
> the second one, but I can't seem to get rid of the first.
>
> How can I unbind Alt-B, and where is it coming from?
>

It's coming from the xmobar combinator applied to defaultConfig:

    xmobar conf = statusBar "xmobar" xmobarPP toggleStrutsKey conf


(see
http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-DynamicLog.html#v:xmobar
)

If you want to replace toggleStrutsKey then you will need to use your own
invocation of statusBar.

    -- |    -- Helper function which provides ToggleStruts keybinding
  --    toggleStrutsKey :: XConfig t -> (KeyMask, KeySym)
toggleStrutsKey XConfig{modMask = modm} = (modm, xK_b )


-- 
brandon s allbery kf8nh                               sine nomine associates
allbery.b at gmail.com                                  ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140504/8bb4a169/attachment.html>

From codesite-noreply at google.com  Sun May  4 21:57:39 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 04 May 2014 21:57:39 +0000
Subject: [xmonad] Issue 566 in xmonad: xmonad gives bogus configure
	events
In-Reply-To: <1-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
Message-ID: <2-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>


Comment #2 on issue 566 by daniel.w... at gmail.com: xmonad gives bogus  
configure events
http://code.google.com/p/xmonad/issues/detail?id=566

Does this happen with the default configuration? If not, could you spend a  
little bit of time to try to minimize your config for us?

For others reading: compiling the given C program requires -lX11 -lGL in  
the compile line.

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sun May  4 21:58:39 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 04 May 2014 21:58:39 +0000
Subject: [xmonad] Issue 566 in xmonad: xmonad gives bogus configure
	events
In-Reply-To: <2-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
References: <2-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
Message-ID: <3-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>


Comment #3 on issue 566 by daniel.w... at gmail.com: xmonad gives bogus  
configure events
http://code.google.com/p/xmonad/issues/detail?id=566

(I do not see configure events happening in my config, even when testing  
with a terminal and a gvim open, which both specify resize increments in  
their window manager hints.)

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sun May  4 22:02:20 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 04 May 2014 22:02:20 +0000
Subject: [xmonad] Issue 566 in xmonad: xmonad gives bogus configure
	events
In-Reply-To: <3-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
References: <3-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
Message-ID: <4-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>


Comment #4 on issue 566 by allber... at gmail.com: xmonad gives bogus  
configure events
http://code.google.com/p/xmonad/issues/detail?id=566

I'm not having a good weekend so have not been looking closely at this, but  
the first comment points to (and my initial suspicion was) the layout hints  
module, and probably hintsEventHook in particular. (Also my personal  
observation is that that module seems to cause more problems than it  
fixes....)

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From darcswatch at nomeata.de  Mon May  5 00:25:26 2014
From: darcswatch at nomeata.de (darcswatch at nomeata.de)
Date: Mon, 05 May 2014 01:25:26 +0100
Subject: [xmonad] Applied: Newbie first patch to make the **Ssh** extension
	work with	user.
References: <CAByXYiuMHxaZdv62XnMnYqC0=Et6DqONo=nud6DaNeXH5Evh8g@mail.gmail.com>
Message-ID: <E1Wh6ik-0006C5-8i@urchin.earth.li>

This 1-patch bundle was just applied to http://code.haskell.org/XMonadContrib:

20140504091120  linxray at gmail.com
 * This patch makes the Ssh extension works with **user** arguments in ssh, .e.g ssh admin at localhost.


-- 
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__code.haskell.org_XMonadContrib.html#bundle-8688e4e11cbdcb8113be236bd6bf8ae5523bed21

From vogt.adam at gmail.com  Mon May  5 00:27:47 2014
From: vogt.adam at gmail.com (adam vogt)
Date: Sun, 4 May 2014 20:27:47 -0400
Subject: [xmonad] Newbie first patch to make the **Ssh** extension work
 with user.
In-Reply-To: <CAByXYiuMHxaZdv62XnMnYqC0=Et6DqONo=nud6DaNeXH5Evh8g@mail.gmail.com>
References: <CAByXYiuMHxaZdv62XnMnYqC0=Et6DqONo=nud6DaNeXH5Evh8g@mail.gmail.com>
Message-ID: <CAHfjoWkf-JG78g7KuyUK6JXcLemhSQQtf2LbOcvAF3EWoUKxgA@mail.gmail.com>

Thanks Lei, I've applied it.

Next time try to avoid introducing warnings:

 (\(u,h) -> h)

is better written as:

 (\(_u, h) -> h)

or

 snd

Of course it doesn't really make any difference with tiny functions
like that one, but with bigger functions that warning helps us avoid
bugs and makes things easier to understand.

Regards,
Adam

On Sun, May 4, 2014 at 5:20 AM, Lei Chen <linxray at gmail.com> wrote:
> Hi,
>
> The patch add *user* support to the *Ssh* extension, .e.g ssh admin at host.
> By the way, it is the first time i write haskell code snippet for a great
> project. If there is anything wrong with the code, code style, comment,
> please let me know.
> The *XMonad* is awesome, i love it.
>
> --
> No pain ,No gain!
> From Ray!
>
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>

From oneself at gmail.com  Mon May  5 03:59:42 2014
From: oneself at gmail.com (Eyal Erez)
Date: Sun, 4 May 2014 23:59:42 -0400
Subject: [xmonad] Trouble Rebinding ToggleStruts
In-Reply-To: <CAKFCL4V+1=hQHOq5AA9wFrjJKavG9KmU_+jtByQ9DTCvH4Zq=g@mail.gmail.com>
References: <CAJiJgM0SPd6zeRJ+Je8hvXv8DK0Znz5tR=1yqdAChSdDSB2-6w@mail.gmail.com>
 <CAKFCL4V+1=hQHOq5AA9wFrjJKavG9KmU_+jtByQ9DTCvH4Zq=g@mail.gmail.com>
Message-ID: <CAJiJgM39ho5RkqCFPFZHmCfKqstmdAMcm90FvQJo0R1YaXvN9A@mail.gmail.com>

Hi,

Thank you very much for your help.

Would you mind posting an example of how I might use statusBar?  I'm kind
of a Haskell newb.


On Sun, May 4, 2014 at 4:58 PM, Brandon Allbery <allbery.b at gmail.com> wrote:

> On Sun, May 4, 2014 at 2:49 PM, Eyal Erez <oneself at gmail.com> wrote:
>
>> To this:
>> main = xmonad =<< xmobar defaultConfig
>>         {  -- no logHook defined
>>          -- Other definitions.
>>         }
>>
>> This works fine, but now for some reason, Alt-B is bound to ToggleStruts.
>>  I would like this to be Ctrl-Shift-B, and I have a key binding which adds
>> the second one, but I can't seem to get rid of the first.
>>
>> How can I unbind Alt-B, and where is it coming from?
>>
>
> It's coming from the xmobar combinator applied to defaultConfig:
>
>     xmobar conf = statusBar "xmobar" xmobarPP toggleStrutsKey conf
>
>
> (see
> http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-DynamicLog.html#v:xmobar
> )
>
> If you want to replace toggleStrutsKey then you will need to use your own
> invocation of statusBar.
>
>     -- |    -- Helper function which provides ToggleStruts keybinding    --    toggleStrutsKey :: XConfig t -> (KeyMask, KeySym)    toggleStrutsKey XConfig{modMask = modm} = (modm, xK_b )
>
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>



-- 
*Eyal Erez <**oneself at gmail.com* <oneself at gmail.com>*>*

There are 10 types of people, those who know binary and those who don't.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140504/1b829313/attachment.html>

From oneself at gmail.com  Mon May  5 04:03:37 2014
From: oneself at gmail.com (Eyal Erez)
Date: Mon, 5 May 2014 00:03:37 -0400
Subject: [xmonad] Trouble Rebinding ToggleStruts
In-Reply-To: <CAJiJgM39ho5RkqCFPFZHmCfKqstmdAMcm90FvQJo0R1YaXvN9A@mail.gmail.com>
References: <CAJiJgM0SPd6zeRJ+Je8hvXv8DK0Znz5tR=1yqdAChSdDSB2-6w@mail.gmail.com>
 <CAKFCL4V+1=hQHOq5AA9wFrjJKavG9KmU_+jtByQ9DTCvH4Zq=g@mail.gmail.com>
 <CAJiJgM39ho5RkqCFPFZHmCfKqstmdAMcm90FvQJo0R1YaXvN9A@mail.gmail.com>
Message-ID: <CAJiJgM1yMaQU0iOo16aw8qbeuYcbzPoE8NObHn2bZXn2rjt4kw@mail.gmail.com>

I think I found a good example here:
https://wiki.archlinux.org/index.php/xmonad

Thank you kindly for your help.

-- Imports.
import XMonad
import XMonad.Hooks.DynamicLog

-- The main function.
main = xmonad =<< statusBar myBar myPP toggleStrutsKey myConfig

-- Command to launch the bar.
myBar = "xmobar"

-- Custom PP, configure it as you like. It determines what is being
written to the bar.
myPP = xmobarPP { ppCurrent = xmobarColor "#429942" "" . wrap "<" ">" }

-- Key binding to toggle the gap for the bar.
toggleStrutsKey XConfig {XMonad.modMask = modMask} = (modMask, xK_b)

-- Main configuration, override the defaults to your liking.
myConfig = defaultConfig { modMask = mod4Mask }



On Sun, May 4, 2014 at 11:59 PM, Eyal Erez <oneself at gmail.com> wrote:

> Hi,
>
> Thank you very much for your help.
>
> Would you mind posting an example of how I might use statusBar?  I'm kind
> of a Haskell newb.
>
>
> On Sun, May 4, 2014 at 4:58 PM, Brandon Allbery <allbery.b at gmail.com>wrote:
>
>> On Sun, May 4, 2014 at 2:49 PM, Eyal Erez <oneself at gmail.com> wrote:
>>
>>> To this:
>>> main = xmonad =<< xmobar defaultConfig
>>>         {  -- no logHook defined
>>>          -- Other definitions.
>>>         }
>>>
>>> This works fine, but now for some reason, Alt-B is bound to
>>> ToggleStruts.  I would like this to be Ctrl-Shift-B, and I have a key
>>> binding which adds the second one, but I can't seem to get rid of the first.
>>>
>>> How can I unbind Alt-B, and where is it coming from?
>>>
>>
>> It's coming from the xmobar combinator applied to defaultConfig:
>>
>>     xmobar conf = statusBar "xmobar" xmobarPP toggleStrutsKey conf
>>
>>
>> (see
>> http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-DynamicLog.html#v:xmobar
>> )
>>
>> If you want to replace toggleStrutsKey then you will need to use your own
>> invocation of statusBar.
>>
>>     -- |    -- Helper function which provides ToggleStruts keybinding    --    toggleStrutsKey :: XConfig t -> (KeyMask, KeySym)    toggleStrutsKey XConfig{modMask = modm} = (modm, xK_b )
>>
>>
>> --
>> brandon s allbery kf8nh                               sine nomine
>> associates
>> allbery.b at gmail.com
>> ballbery at sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>> http://sinenomine.net
>>
>
>
>
> --
> *Eyal Erez <**oneself at gmail.com* <oneself at gmail.com>*>*
>
> There are 10 types of people, those who know binary and those who don't.
>
>


-- 
*Eyal Erez <**oneself at gmail.com* <oneself at gmail.com>*>*

There are 10 types of people, those who know binary and those who don't.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140505/fa66b8a9/attachment.html>

From codesite-noreply at google.com  Mon May  5 07:46:22 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Mon, 05 May 2014 07:46:22 +0000
Subject: [xmonad] Issue 567 in xmonad: Cloned workspace output via
	StdinReader
Message-ID: <0-3425899027203913298-16077179880034521228-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 567 by k... at ccsfcc.net: Cloned workspace output via StdinReader
http://code.google.com/p/xmonad/issues/detail?id=567

I'm not really sure what's causing this problem. If I focus on my second  
workspace (devel), two instances of <devel> are output to StdinReader via  
xmobar, where one is expected. Only the devel workspace (2) is affected by  
this problem.

The expected output:
<devel>

What I see:
<devel> <devel>

xmonad 0.11-8 and xmonad-contrib 0.11.2-3 on Arch Linux x86_64, kernel  
3.14.2.

xmonad.hs is attached. `xmonad --recompile` does not output errors.
.xmobarrc is also attached as well as a picture of the bar's issue.

This only happens when I focus on the second workspace (devel). All others  
work fine. This started happening out of the blue.


Attachments:
	xmobar.png  3.8 KB
	xmonad.hs  2.1 KB
	.xmobarrc  535 bytes

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Mon May  5 07:48:47 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Mon, 05 May 2014 07:48:47 +0000
Subject: [xmonad] Issue 567 in xmonad: Cloned workspace output via
	StdinReader
In-Reply-To: <0-3425899027203913298-16077179880034521228-codesite-noreply=google.com@googlecode.com>
References: <0-3425899027203913298-16077179880034521228-codesite-noreply=google.com@googlecode.com>
Message-ID: <1-3425899027203913298-16077179880034521228-codesite-noreply=google.com@googlecode.com>


Comment #1 on issue 567 by k... at ccsfcc.net: Cloned workspace output via  
StdinReader
http://code.google.com/p/xmonad/issues/detail?id=567

Sorry, here's an updated screenshot attached.

Attachments:
	xmobar.png  5.3 KB

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Tue May  6 07:49:13 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Tue, 06 May 2014 07:49:13 +0000
Subject: [xmonad] Issue 567 in xmonad: Cloned workspace output via
	StdinReader
In-Reply-To: <1-3425899027203913298-16077179880034521228-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-16077179880034521228-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-16077179880034521228-codesite-noreply=google.com@googlecode.com>
Message-ID: <2-3425899027203913298-16077179880034521228-codesite-noreply=google.com@googlecode.com>


Comment #2 on issue 567 by k... at ccsfcc.net: Cloned workspace output via  
StdinReader
http://code.google.com/p/xmonad/issues/detail?id=567

Update: When I first focus on <devel>, it takes two focus actions to  
actually bring up the screen. Only for this workstation.

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From audunskaugen at gmail.com  Tue May  6 09:36:11 2014
From: audunskaugen at gmail.com (Audun Skaugen)
Date: Tue, 06 May 2014 11:36:11 +0200
Subject: [xmonad] smartBorders and fullscreen Firefox
In-Reply-To: <5364B888.8050101@texttheater.net>
References: <5364B888.8050101@texttheater.net>
Message-ID: <op.xffmalxq8tltis@behemoth>

Hi,
I remember having the same issue when using xmonad. The reason is that  
smartBorders only activate when a floating window covers the entire  
screen, not when a tiled window covers the screen. I guess it could be  
modified to be effective on both cases.

My (very lacking) workaround was to turn off borders completely and use  
XMonad.Hooks.FadeInactive to distinguish focus instead.

P? Sat, 03 May 2014 11:36:08 +0200, skrev Kilian Evang  
<maschinenraum at texttheater.net>:

> Hi all,
>
> I'm using Ubuntu 12.04's "Gnome with Xmonad" session, currently with the
> following config:
>
> https://github.com/texttheater/.xmonad/blob/3e73e43cbfc57d418281c60dc700e494f7812183/xmonad.hs
>
> As you can see, I have it set up so that fullscreen windows cover the
> whole screen, including the Gnome panels
>
> For Firefox, this required some extra work because apparently
> isFullscreen doesn't trigger when Firefox goes fullscreen. Luckily,
> there is XMonad.Layout.Fullscreen.fullscreenEventHook and
> XMonad.Layout.Fullscreen.fullscreenFull to handle this.
>
> What still doesn't work is for XMonad.Layout.NoBorders to notice when
> Firefox goes fullscreen. Although I'm using smartBorders, a border
> around the fullscreen Firefox window is still drawn as long as there is
> another window on the same workspace.
>
> Can I tweak my config so that this border goes away?
>
> Also, should the NoBorders module be improved to handle this situation?
>
> Cheers,
> Kilian
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad


-- 
Audun Skaugen

From codesite-noreply at google.com  Wed May  7 00:31:20 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Wed, 07 May 2014 00:31:20 +0000
Subject: [xmonad] Issue 568 in xmonad: Actions.DynamicWorkspaceGroups
 viewWSGroup changes which workspace has focus incorrectly
Message-ID: <0-3425899027203913298-5223533229951273802-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 568 by nwfila... at gmail.com: Actions.DynamicWorkspaceGroups  
viewWSGroup changes which workspace has focus incorrectly
http://code.google.com/p/xmonad/issues/detail?id=568

When running viewWSGroup, the focus is set to whichever display is last in  
the windowset's visible set.  It would be better, IMHO, if focus were  
considered part of the WSGroup.  Simply reversing the list of workspaces  
should mean that the last greedyView serves to restore focus to the  
workspace (and screen) focused-at-group-creation-time.

--- old-XMonadContrib/XMonad/Actions/DynamicWorkspaceGroups.hs	2014-05-06  
20:26:25.919864085 -0400
+++ new-XMonadContrib/XMonad/Actions/DynamicWorkspaceGroups.hs	2014-05-06  
20:26:26.163865644 -0400
@@ -93,7 +93,7 @@
  -- | Give a name to the current workspace group.
  addCurrentWSGroup :: WSGroupId -> X ()
  addCurrentWSGroup name = withWindowSet $ \w ->
-  addWSGroup name $ map (W.tag . W.workspace) (W.current w : W.visible w)
+  addWSGroup name $ map (W.tag . W.workspace) (reverse $ W.current w :  
W.visible w)

  -- | Delete the named workspace group from the list of workspace
  --   groups.  Note that this has no effect on the workspaces involved;

A different, equally-defensible behavior, would be to consider the focus to  
not be part of the WSGroup and to hold the current focus across the  
viewWSGroup operation.  A wrapper like this may be useful:

holdScreenFocus a = do
   s <- gets (S.screen . S.current . windowset)
   r <- a
   screenWorkspace s >>= maybe (return ()) (windows . S.view)
   return r

Thanks!
--nwf;

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From linxray at gmail.com  Wed May  7 03:39:25 2014
From: linxray at gmail.com (Lei Chen)
Date: Wed, 7 May 2014 11:39:25 +0800
Subject: [xmonad] smartBorders and fullscreen Firefox
In-Reply-To: <op.xffmalxq8tltis@behemoth>
References: <5364B888.8050101@texttheater.net>
	<op.xffmalxq8tltis@behemoth>
Message-ID: <CAByXYis_5t75nNpyfo+0+NamHmLc2FY2GBV_bZGZTfqn5vCN2A@mail.gmail.com>

Hi,

I have the same problem before. I solve it by floating the window and apply
smartboards to it.
After that, the window i want fullscreen works well.
please  check my xmonad.hs @ http://oopschen.github.io/file/xmonad.hs


2014-05-06 17:36 GMT+08:00 Audun Skaugen <audunskaugen at gmail.com>:

> Hi,
> I remember having the same issue when using xmonad. The reason is that
> smartBorders only activate when a floating window covers the entire screen,
> not when a tiled window covers the screen. I guess it could be modified to
> be effective on both cases.
>
> My (very lacking) workaround was to turn off borders completely and use
> XMonad.Hooks.FadeInactive to distinguish focus instead.
>
> P? Sat, 03 May 2014 11:36:08 +0200, skrev Kilian Evang <
> maschinenraum at texttheater.net>:
>
>  Hi all,
>>
>> I'm using Ubuntu 12.04's "Gnome with Xmonad" session, currently with the
>> following config:
>>
>> https://github.com/texttheater/.xmonad/blob/
>> 3e73e43cbfc57d418281c60dc700e494f7812183/xmonad.hs
>>
>> As you can see, I have it set up so that fullscreen windows cover the
>> whole screen, including the Gnome panels
>>
>> For Firefox, this required some extra work because apparently
>> isFullscreen doesn't trigger when Firefox goes fullscreen. Luckily,
>> there is XMonad.Layout.Fullscreen.fullscreenEventHook and
>> XMonad.Layout.Fullscreen.fullscreenFull to handle this.
>>
>> What still doesn't work is for XMonad.Layout.NoBorders to notice when
>> Firefox goes fullscreen. Although I'm using smartBorders, a border
>> around the fullscreen Firefox window is still drawn as long as there is
>> another window on the same workspace.
>>
>> Can I tweak my config so that this border goes away?
>>
>> Also, should the NoBorders module be improved to handle this situation?
>>
>> Cheers,
>> Kilian
>> _______________________________________________
>> xmonad mailing list
>> xmonad at haskell.org
>> http://www.haskell.org/mailman/listinfo/xmonad
>>
>
>
> --
> Audun Skaugen
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
>



-- 
No pain ,No gain!
>From Ray!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140507/aec28df2/attachment.html>

From alexis.mailinglist at de-bruyn.fr  Wed May  7 16:47:54 2014
From: alexis.mailinglist at de-bruyn.fr (Alexis de BRUYN)
Date: Wed, 07 May 2014 18:47:54 +0200
Subject: [xmonad] DynamicWorkspaceGroups persistent after reboot?
In-Reply-To: <20140428143854.GA1544@seas.upenn.edu>
References: <5336CC5F.8080500@de-bruyn.fr>
 <20140407170057.GA11100@seas.upenn.edu> <53440C2C.2080308@de-bruyn.fr>
 <20140409190918.GA5689@seas.upenn.edu> <5346D66D.9070108@de-bruyn.fr>
 <20140428143854.GA1544@seas.upenn.edu>
Message-ID: <536A63BA.5000202@de-bruyn.fr>

Thanks a lot Brent, all is working fine for me!

Regards,

On 28.04.2014 16:38, Brent Yorgey wrote:
> On Thu, Apr 10, 2014 at 07:35:41PM +0200, Alexis de BRUYN wrote:
>> On 09.04.2014 21:09, Brent Yorgey wrote:
>>>
>>> The following function should achieve what you want:
>>>
>>>   import qualified Data.Map                    as M
>>>   import qualified XMonad.Util.ExtensibleState as XS
>>>
>>>   addWSGroup' :: WSGroupId -> [(ScreenId, WorkspaceId)] -> X ()
>>>   addWSGroup' name = XS.modify . withWSG . M.insert name
>>
>> I have got the following error:
>> xmonad.hs:27:32: Not in scope: `withWSG'
> 
> Sorry for that, withWSG was not exported.  I have just pushed a patch
> adding a new function
> 
>   addRawWSGroup
> 
> which is defined in the same way as the addWSGroup' I suggested
> above.  I have tested it and it seems to work.  So now you can call it
> from your startup hook like so:
> 
>   myStartupHook = do
>     addRawWSGroup "g1" [(S 0, "1"), (S 1, "2"), (S 2, "3")]
>     ... etc.
> 
> To use it you will have to obtain the latest darcs version of
> xmonad-contrib, like so:
> 
>   darcs get http://code.haskell.org/XMonadContrib
>   cd XMonadContrib
>   cabal install
> 
> The darcs version is quite stable so you should have no problems
> upgrading to it.
> 
> -Brent

-- 
Alexis de BRUYN

From codesite-noreply at google.com  Thu May  8 21:30:47 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Thu, 08 May 2014 21:30:47 +0000
Subject: [xmonad] Issue 566 in xmonad: xmonad gives bogus configure
	events
In-Reply-To: <4-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
References: <4-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>
Message-ID: <5-3425899027203913298-17707427951963256191-codesite-noreply=google.com@googlecode.com>


Comment #5 on issue 566 by StevensE... at gmail.com: xmonad gives bogus  
configure events
http://code.google.com/p/xmonad/issues/detail?id=566

Yep layoutHints seems to be causing the problem. Thank you, very much.

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sat May 10 08:01:59 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sat, 10 May 2014 08:01:59 +0000
Subject: [xmonad] Issue 558 in xmonad: add xmir support
In-Reply-To: <10-3425899027203913298-1942339895481446142-codesite-noreply=google.com@googlecode.com>
References: <10-3425899027203913298-1942339895481446142-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-1942339895481446142-codesite-noreply=google.com@googlecode.com>
Message-ID: <11-3425899027203913298-1942339895481446142-codesite-noreply=google.com@googlecode.com>


Comment #11 on issue 558 by mikelie... at gmail.com: add xmir support
http://code.google.com/p/xmonad/issues/detail?id=558

Yeah, this topic is rearing its ugly head again, so it might be a good idea  
to make a clear definitive analysis available.

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sun May 11 05:10:09 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 11 May 2014 05:10:09 +0000
Subject: [xmonad] Issue 569 in xmonad: GenerateManpage regex issue
Message-ID: <0-3425899027203913298-4420657738280497580-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 569 by pashev.i... at gmail.com: GenerateManpage regex issue
http://code.google.com/p/xmonad/issues/detail?id=569

util/GenerateManpage.hs uses "xK_(\\w+)" which cannot work on some  
platforms, e. g. illumos (opensolaris). It even does not work if  
Text.Regex.Posix is built with bundled regex sources (like on windows).

I suggest to use "xK_([[:alnum:]]+)" instead.

See http://osdyson.org/issues/169 and http://osdyson.org/news/64 ;-)

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sun May 11 15:49:02 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 11 May 2014 15:49:02 +0000
Subject: [xmonad] Issue 569 in xmonad: GenerateManpage regex issue
In-Reply-To: <0-3425899027203913298-4420657738280497580-codesite-noreply=google.com@googlecode.com>
References: <0-3425899027203913298-4420657738280497580-codesite-noreply=google.com@googlecode.com>
Message-ID: <1-3425899027203913298-4420657738280497580-codesite-noreply=google.com@googlecode.com>


Comment #1 on issue 569 by daniel.w... at gmail.com: GenerateManpage regex  
issue
http://code.google.com/p/xmonad/issues/detail?id=569

Patch attached (but untested); it changes \w to [_[:alnum:]] rather than  
[[:alnum:]] as the man page for grep suggests that this is what \w is  
really a shortcut for.

Attachments:
	regex.dpatch  5.8 KB

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sun May 11 17:20:42 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 11 May 2014 17:20:42 +0000
Subject: [xmonad] Issue 569 in xmonad: GenerateManpage regex issue
In-Reply-To: <1-3425899027203913298-4420657738280497580-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-4420657738280497580-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-4420657738280497580-codesite-noreply=google.com@googlecode.com>
Message-ID: <2-3425899027203913298-4420657738280497580-codesite-noreply=google.com@googlecode.com>

Updates:
	Status: Fixed

Comment #2 on issue 569 by vogt.a... at gmail.com: GenerateManpage regex issue
http://code.google.com/p/xmonad/issues/detail?id=569

Thanks Igor and Daniel. I've pushed the patch and it seems to work.

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Mon May 12 14:06:39 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Mon, 12 May 2014 14:06:39 +0000
Subject: [xmonad] Issue 570 in xmonad: add systemd support
Message-ID: <0-3425899027203913298-15333021697025024755-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 570 by olyasi... at gmail.com: add systemd support
http://code.google.com/p/xmonad/issues/detail?id=570

There are few user-made .service files for xmonad.
It would be great to see such file available as part of xmonad or  
xmonadcontrib so users could easily start xmonad with "systemd --user"

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Tue May 13 01:33:59 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Tue, 13 May 2014 01:33:59 +0000
Subject: [xmonad] Issue 568 in xmonad: Actions.DynamicWorkspaceGroups
 viewWSGroup changes which workspace has focus incorrectly
In-Reply-To: <0-3425899027203913298-5223533229951273802-codesite-noreply=google.com@googlecode.com>
References: <0-3425899027203913298-5223533229951273802-codesite-noreply=google.com@googlecode.com>
Message-ID: <1-3425899027203913298-5223533229951273802-codesite-noreply=google.com@googlecode.com>

Updates:
	Status: Accepted

Comment #1 on issue 568 by byor... at gmail.com:  
Actions.DynamicWorkspaceGroups viewWSGroup changes which workspace has  
focus incorrectly
http://code.google.com/p/xmonad/issues/detail?id=568

Both these seem reasonable to me.  Does anyone else who uses  
DynamicWorkspaceGroups have a preference?

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Wed May 14 16:44:30 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Wed, 14 May 2014 16:44:30 +0000
Subject: [xmonad] Issue 433 in xmonad: Alternative Implementation of
	WorkspaceDir
In-Reply-To: <1-3425899027203913298-4261345723270558712-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-4261345723270558712-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-4261345723270558712-codesite-noreply=google.com@googlecode.com>
Message-ID: <2-3425899027203913298-4261345723270558712-codesite-noreply=google.com@googlecode.com>


Comment #2 on issue 433 by liskni... at gmail.com: Alternative Implementation  
of WorkspaceDir
http://code.google.com/p/xmonad/issues/detail?id=433

Hey, is there any progress with this? I think it might solve a problem of  
mine:

In addition to a global xmobar with workspaces, battery info, time, date  
and so on I have one xmobar on each screen with a workspace name and a list  
of windows (just like a hardstatus line in GNU screen). I'd love these  
per-screen xmobars to show me the workspace directory as well.

I solved this by adding modifierDescription that prints the directory to  
instance LayoutModifier WorkspaceDir, but that lacks any configurability  
whatsoever, and adding a function field to data WorkspaceDir is prohibited  
by the Read/Show instances. Therefore, this is definitely not something I  
could possibly submit as a patch.

Now I found this and it seems it may be a cleaner solution. :-)

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From joe9mail at gmail.com  Sat May 17 03:28:55 2014
From: joe9mail at gmail.com (Joe M)
Date: Fri, 16 May 2014 22:28:55 -0500
Subject: [xmonad] Issue 433 in xmonad: Alternative Implementation of
 WorkspaceDir
In-Reply-To: <2-3425899027203913298-4261345723270558712-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-4261345723270558712-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-4261345723270558712-codesite-noreply=google.com@googlecode.com>
 <2-3425899027203913298-4261345723270558712-codesite-noreply=google.com@googlecode.com>
Message-ID: <20140517032855.GA1864@master>

https://github.com/joe9/xmonad-task/blob/master/XMonad/Actions/Task.hs

-- This module allows to organize your workspaces on a precise task
-- basis. So instead of having a workspace called `work' you can
-- setup one workspace per task. Here we call these workspaces,
-- tasks. The great thing with tasks is that one can attach a
-- directory, starting layout and ScreenId that makes sense to each
-- particular task. One can also attach an action which will be
-- triggered when switching to a topic that does not have any windows
-- in it. So you can attach your mail client to the mail task, some
-- terminals in the right directory to the xmonad task... This package
-- also provides a nice way to display your tasks in an historical
-- way using a custom `pprWindowSet' function. You can also easily
-- switch to recent tasks using this history of last focused tasks.


codesite-noreply at google.com wrote:
> 
> Comment #2 on issue 433 by liskni... at gmail.com: Alternative Implementation  
> of WorkspaceDir
> http://code.google.com/p/xmonad/issues/detail?id=433
> 
> Hey, is there any progress with this? I think it might solve a problem of  
> mine:
> 
> In addition to a global xmobar with workspaces, battery info, time, date  
> and so on I have one xmobar on each screen with a workspace name and a list  
> of windows (just like a hardstatus line in GNU screen). I'd love these  
> per-screen xmobars to show me the workspace directory as well.
> 
> I solved this by adding modifierDescription that prints the directory to  
> instance LayoutModifier WorkspaceDir, but that lacks any configurability  
> whatsoever, and adding a function field to data WorkspaceDir is prohibited  
> by the Read/Show instances. Therefore, this is definitely not something I  
> could possibly submit as a patch.
> 
> Now I found this and it seems it may be a cleaner solution. :-)
> 
> -- 
> You received this message because this project is configured to send all  
> issue notifications to this address.
> You may adjust your notification preferences at:
> https://code.google.com/hosting/settings
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140516/d782f9ef/attachment.sig>

From codesite-noreply at google.com  Sun May 18 20:44:10 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 18 May 2014 20:44:10 +0000
Subject: [xmonad] Issue 571 in xmonad: Other workspaces windows viewable on
	empty workspaces
Message-ID: <0-3425899027203913298-4329276186710892177-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 571 by sl... at azavea.com: Other workspaces windows viewable on  
empty workspaces
http://code.google.com/p/xmonad/issues/detail?id=571

What steps will reproduce the problem?
1. Visit empty workspace, open a program, like a web browser.
2. Visit another empty workspace (mod+<1/2/3/etc.>)

What is the expected output? What do you see instead?
I expect to see an empty workspace, with my background image. Instead, I  
see the program I opened on the other workspace. I can't do anything to it,  
it just appears to be there. This is a bit disorienting.

If I open a window on every workspace, this bug is not a problem.  
Workspaces and window management work as expected.

What version of the product are you using? On what operating system?

Debian GNU/Linux, unstable branch. Installed through apt. I recently did a  
large amount of package upgrades, and this bug was introduced. Oddly, I did  
the same updates on another machine, running an almost identical stack with  
xmonad, and the bug does not exist.

Here's the xmonad package info (on both machines):

-------------------------------------------
steve at euwe:~$ apt-cache show xmonad
Package: xmonad
Source: xmonad (0.11-7)
Version: 0.11-7+b1
Installed-Size: 2666
Maintainer: Debian Haskell Group  
<pkg-haskell-maintainers at lists.alioth.debian.org>
Architecture: amd64
Replaces: xmonad-rebuild
Provides: x-window-manager
Depends: libc6 (>= 2.14), libffi6 (>= 3.0.4), libgmp10, libx11-6, libxext6,  
libxinerama1, libxrandr2 (>= 2:1.2.99.3), x11-utils
Recommends: libghc-xmonad-dev, libghc-xmonad-doc, xfonts-base
Suggests: dmenu
Conflicts: xmonad-rebuild
Description-en: Lightweight X11 window manager written in Haskell
  Xmonad is a minimalist tiling window manager for X, written in
  Haskell.  Windows are managed using automatic layout algorithms,
  which can be dynamically reconfigured. At any time windows are
  arranged so as to maximise the use of screen real estate. All
  features of the window manager are accessible purely from the
  keyboard: a mouse is entirely optional.  Xmonad is configured in
  Haskell, and custom layout algorithms may be implemented by the user
  in config files. A principle of Xmonad is predictability: the user
  should know in advance precisely the window arrangement that will
  result from any action.
  .
  This package comes pre-configured with the default configuration. If
  you want to build your custom-configured version, make sure that
  libghc-xmonad-dev is installed and put your configuration in
  ~/.xmonad/xmonad.hs
Description-md5: a827bdbc621fa78a6624eb347265b935
Homepage: http://xmonad.org/
Tag: implemented-in::haskell, interface::x11, role::program,  
uitoolkit::xlib,
  x11::window-manager
Section: x11
Priority: optional
Filename: pool/main/x/xmonad/xmonad_0.11-7+b1_amd64.deb
Size: 430140
MD5sum: 46df4852f126117d3980856504ce5278
SHA1: 10203968a65d0a51ad989cda49c5225c4d5ef224
SHA256: 39073c319cc4eb1b8995dbabfe14b2ce2c268edab07275bb8f472c7faaffd314

-------------------------------------------

Are you using an xmonad.hs?  Please attach it and the output of "xmonad
--recompile".

I am, but this bug exists when I don't use it. "xmonad --recompile"  
produces no output.

My xmonad.hs can be seen here:
https://github.com/steventlamb/xmonad-config/blob/53340a37a6daf5f814f0fe79db0e4d1b8ed8272d/xmonad.hs


Please provide any additional information below.

I'm mostly looking for some direction for how to go forward. Has anyone  
seen this? Is there a term used to describe this bug/behavior? Something  
like "Sticky windows".

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sun May 18 21:12:22 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 18 May 2014 21:12:22 +0000
Subject: [xmonad] Issue 571 in xmonad: Other workspaces windows viewable
	on empty workspaces
In-Reply-To: <0-3425899027203913298-4329276186710892177-codesite-noreply=google.com@googlecode.com>
References: <0-3425899027203913298-4329276186710892177-codesite-noreply=google.com@googlecode.com>
Message-ID: <1-3425899027203913298-4329276186710892177-codesite-noreply=google.com@googlecode.com>


Comment #1 on issue 571 by allber... at gmail.com: Other workspaces windows  
viewable on empty workspaces
http://code.google.com/p/xmonad/issues/detail?id=571

This is typically a bug in the xorg video driver; xmonad handles window  
placement policy, this is redraws not happening which is between the X  
server and whatever client is not redrawing (or the server itself if there  
is no backdrop window).

While things like this often happen with NVidia driver regressions and the  
only known workarounds involve running a compositing manager, apparently a  
recent Intel video driver update introduced this in the case where the root  
window is left at the default black; `xsetroot -grey` is a workaround in  
this case.

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sun May 18 21:34:14 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sun, 18 May 2014 21:34:14 +0000
Subject: [xmonad] Issue 571 in xmonad: Other workspaces windows viewable
	on empty workspaces
In-Reply-To: <1-3425899027203913298-4329276186710892177-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-4329276186710892177-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-4329276186710892177-codesite-noreply=google.com@googlecode.com>
Message-ID: <2-3425899027203913298-4329276186710892177-codesite-noreply=google.com@googlecode.com>


Comment #2 on issue 571 by sl... at azavea.com: Other workspaces windows  
viewable on empty workspaces
http://code.google.com/p/xmonad/issues/detail?id=571

Thanks so much! The workaround works great. In my case, I added:

`spawn "xsetroot -cursor_name left_ptr -solid black"`

to the main do block in my xmonad.hs file.

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From filmil at gmail.com  Wed May 21 20:39:49 2014
From: filmil at gmail.com (=?UTF-8?B?RmlsaXAgTWlsZXRpYyAo0KTQuNC70LjQvyDQnNC40LvQtdGC0LjRmyk=?=)
Date: Wed, 21 May 2014 13:39:49 -0700
Subject: [xmonad] bluetile: Configuring number of virtual desktops;
	2-monitor behavior
Message-ID: <CAKaOXih0a+vZOaJq3WizN34Oxrt_D33uM7O9sB-_EgpT95hf7g@mail.gmail.com>

Hello!

I'm just now dabbling in tiling window managers, so sorry if this question
is less technical than befits the mailing list.  I didn't find user-level
docs on http://www.bluetile.org/.

So here go the questions, basic as they may be:

   1. How do I configure the number of workspaces to use in bluetile?
   2. Is there a way to sanitize the 2-monitor behavior in bluetile.
    Though I didn't quite figure out the logic behind workspace switches, and
   maybe they are working as intended; it's just that the workspace switches
   on a 2-monitor display confuse me.  Is there config magic that will
   unconfuse me?

F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140521/d3dacb1f/attachment.html>

From daniel at wagner-home.com  Sun May 25 02:30:34 2014
From: daniel at wagner-home.com (Daniel Wagner)
Date: Sat, 24 May 2014 22:30:34 -0400
Subject: [xmonad] bluetile: Configuring number of virtual desktops;
 2-monitor behavior
In-Reply-To: <CAKaOXih0a+vZOaJq3WizN34Oxrt_D33uM7O9sB-_EgpT95hf7g@mail.gmail.com>
References: <CAKaOXih0a+vZOaJq3WizN34Oxrt_D33uM7O9sB-_EgpT95hf7g@mail.gmail.com>
Message-ID: <6aed19ffaa49fa1b7f0c1d45dfb08407@seas.upenn.edu>

On 2014-05-21 16:39, Filip Miletic wrote:
> 	* How do I configure the number of workspaces to use in bluetile?

Looking at the config, it uses ten. This is pretty standard, since most 
people bind workspaces to keys 0-9. Changing it is easy, though. For 
example, if you only want three, make an xmonad.hs that looks like this:

import XMonad
import XMonad.Config.Bluetile

main = xmonad bluetileConfig
     { workspaces = ["1", "2", "3"]
     }

Of course you don't have to use the same unimaginative names I did.

> 	* Is there a way to sanitize the 2-monitor behavior in bluetile.
> ?Though I didn't quite figure out the logic behind workspace
> switches, and maybe they are working as intended; it's just that the
> workspace switches on a 2-monitor display confuse me. ?Is there
> config magic that will unconfuse me?

Dunno about bluetile for sure, but for xmonad, see this SO question:
http://stackoverflow.com/q/23271662/791604

~d

From md143rbh7f at gmail.com  Thu May 29 23:05:22 2014
From: md143rbh7f at gmail.com (md143rbh7f)
Date: Thu, 29 May 2014 16:05:22 -0700
Subject: [xmonad] Patch to fix dbus-send in XMonad.Config.Gnome
In-Reply-To: <CAHoiLu_RxbmsuZ4g-sTjn_LT8wk=-tZ6esxPuBKosD3w_wJr5Q@mail.gmail.com>
References: <CAHoiLu_RxbmsuZ4g-sTjn_LT8wk=-tZ6esxPuBKosD3w_wJr5Q@mail.gmail.com>
Message-ID: <CAHoiLu_XaUk3A3_5ArUkcEfXGu=fY4s57hTO7-U=BRs27RyRww@mail.gmail.com>

Hi, can someone look at this and commit it? It fixes a command-line
flag that XMonad.Config.Gnome sends to dbus-send. I'm tired of having
to manually repatch XMonad-Contrib every time (because otherwise
XMonad / GNOME integration breaks).

2014-01-28 19:45 GMT-08:00 md143rbh7f <md143rbh7f at gmail.com>:
> * Fix dbus-send call in XMonad.Config.Gnome
> dbus-send --print-reply=string is invalid, but it was silently ignored until
> recently:
> http://cgit.freedesktop.org/dbus/dbus/commit/tools/dbus-send.c?id=c690ee4351f99ed5e629ffcf5f4a2edcd418d103
> I've changed XMonad.Config.Gnome to run --print-reply=literal, since that's
> what the old behavior was.

From darcswatch at nomeata.de  Fri May 30 19:05:23 2014
From: darcswatch at nomeata.de (darcswatch at nomeata.de)
Date: Fri, 30 May 2014 20:05:23 +0100
Subject: [xmonad] Applied: Patch to fix dbus-send in XMonad.Config.Gnome
References: <CAHoiLu_RxbmsuZ4g-sTjn_LT8wk=-tZ6esxPuBKosD3w_wJr5Q@mail.gmail.com>
Message-ID: <E1WqS7H-0003KY-Rv@urchin.earth.li>

This 1-patch bundle was just applied to http://code.haskell.org/XMonadContrib:

20140129032114  md143rbh7f at gmail.com
 * Fix dbus-send call in XMonad.Config.Gnome
 dbus-send --print-reply=string is invalid, but it was silently ignored until recently:
 http://cgit.freedesktop.org/dbus/dbus/commit/tools/dbus-send.c?id=c690ee4351f99ed5e629ffcf5f4a2edcd418d103
 I've changed XMonad.Config.Gnome to run --print-reply=literal, since that's what the old behavior was.


-- 
This message was brought to you by DarcsWatch
http://darcswatch.nomeata.de/repo_http:__code.haskell.org_XMonadContrib.html#bundle-2d739c67067f24db784f1a1db9d121f839e21067

From daniel at wagner-home.com  Fri May 30 19:05:27 2014
From: daniel at wagner-home.com (Daniel Wagner)
Date: Fri, 30 May 2014 15:05:27 -0400
Subject: [xmonad] Patch to fix dbus-send in XMonad.Config.Gnome
In-Reply-To: <CAHoiLu_XaUk3A3_5ArUkcEfXGu=fY4s57hTO7-U=BRs27RyRww@mail.gmail.com>
References: <CAHoiLu_RxbmsuZ4g-sTjn_LT8wk=-tZ6esxPuBKosD3w_wJr5Q@mail.gmail.com>
 <CAHoiLu_XaUk3A3_5ArUkcEfXGu=fY4s57hTO7-U=BRs27RyRww@mail.gmail.com>
Message-ID: <3b3d2e99dc278ce8ef40055a9a0e7f4e@seas.upenn.edu>

Applied, thanks!
~d

On 2014-05-29 19:05, md143rbh7f wrote:
> Hi, can someone look at this and commit it? It fixes a command-line
> flag that XMonad.Config.Gnome sends to dbus-send. I'm tired of having
> to manually repatch XMonad-Contrib every time (because otherwise
> XMonad / GNOME integration breaks).
> 
> 2014-01-28 19:45 GMT-08:00 md143rbh7f <md143rbh7f at gmail.com>:
>> * Fix dbus-send call in XMonad.Config.Gnome
>> dbus-send --print-reply=string is invalid, but it was silently ignored 
>> until
>> recently:
>> http://cgit.freedesktop.org/dbus/dbus/commit/tools/dbus-send.c?id=c690ee4351f99ed5e629ffcf5f4a2edcd418d103
>> I've changed XMonad.Config.Gnome to run --print-reply=literal, since 
>> that's
>> what the old behavior was.
> _______________________________________________
> xmonad mailing list
> xmonad at haskell.org
> http://www.haskell.org/mailman/listinfo/xmonad

From codesite-noreply at google.com  Fri May 30 22:10:24 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 30 May 2014 22:10:24 +0000
Subject: [xmonad] Issue 572 in xmonad: bug @ XMonad.Operations floatLocation
Message-ID: <0-3425899027203913298-12573130475418278554-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----

New issue 572 by rui.da... at gmail.com: bug @ XMonad.Operations floatLocation
http://code.google.com/p/xmonad/issues/detail?id=572

What steps will reproduce the problem?
1. trying to use XMonad.Operations floatLocation and dependents like:  
float...

What is the expected output?
float location should query the window and not the XConfig for the border  
width.

What do you see instead?
floatLocation uses border width from the XConfig instead of the window.
this conflicts with NoBorders when borders are toggled.

What version of the product are you using?
the one that come with my distro.

On what operating system?
debian wheezy.

Are you using an xmonad.hs?
yap.

Please attach it and the output of "xmonad --recompile".
compiles fine, works bad.

Please provide any additional information below.
--
-- such as the bug correction...
--
-- | Given a window, find the screen it is located on, and compute
-- the geometry of that window wrt. that screen.
floatLocation :: Window -> X (ScreenId, W.RationalRect)
floatLocation w = withDisplay $ \d -> do
     ws <- gets windowset
     wa <- io $ getWindowAttributes d w
     -- bw <- fi <$> asks (borderWidth . config) -- abc
     sc <- fromMaybe (W.current ws) <$> pointScreen (fi $ wa_x wa) (fi $  
wa_y wa)

     let sr = screenRect . W.screenDetail $ sc
         rr = W.RationalRect ((fi (wa_x wa) - fi (rect_x sr)) % fi  
(rect_width sr))
                             ((fi (wa_y wa) - fi (rect_y sr)) % fi  
(rect_height sr))
                             (fi (wa_width  wa + bw*2) % fi (rect_width sr))
                             (fi (wa_height wa + bw*2) % fi (rect_height sr))
         bw = wa_border_width wa -- abc

     return (W.screen sc, rr)
   where fi x = fromIntegral x


-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Fri May 30 22:13:15 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Fri, 30 May 2014 22:13:15 +0000
Subject: [xmonad] Issue 572 in xmonad: bug @ XMonad.Operations
	floatLocation
In-Reply-To: <0-3425899027203913298-12573130475418278554-codesite-noreply=google.com@googlecode.com>
References: <0-3425899027203913298-12573130475418278554-codesite-noreply=google.com@googlecode.com>
Message-ID: <1-3425899027203913298-12573130475418278554-codesite-noreply=google.com@googlecode.com>


Comment #1 on issue 572 by rui.da... at gmail.com: bug @ XMonad.Operations  
floatLocation
http://code.google.com/p/xmonad/issues/detail?id=572

flea location...

    
http://xmonad.org/xmonad-docs/xmonad/src/XMonad-Operations.html#floatLocation

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sat May 31 01:32:03 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sat, 31 May 2014 01:32:03 +0000
Subject: [xmonad] Issue 572 in xmonad: bug @ XMonad.Operations
	floatLocation
In-Reply-To: <1-3425899027203913298-12573130475418278554-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-12573130475418278554-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-12573130475418278554-codesite-noreply=google.com@googlecode.com>
Message-ID: <2-3425899027203913298-12573130475418278554-codesite-noreply=google.com@googlecode.com>


Comment #2 on issue 572 by rui.da... at gmail.com: bug @ XMonad.Operations  
floatLocation
http://code.google.com/p/xmonad/issues/detail?id=572

... notice that is possible that other functions have the same problem...

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sat May 31 21:21:56 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sat, 31 May 2014 21:21:56 +0000
Subject: [xmonad] Issue 573 in xmonad: getSelection leaks a handle to the X
	server
Message-ID: <0-3425899027203913298-14349414989738637870-codesite-noreply=google.com@googlecode.com>

Status: New
Owner: ----
Labels: Component-Contrib

New issue 573 by allber... at gmail.com: getSelection leaks a handle to the X  
server
http://code.google.com/p/xmonad/issues/detail?id=573

getSelection opens its own connection to the X server to retrieve and  
convert the current selection without impacting the main connection or run  
loop. It doesn't close the connection afterward, so repeated use will  
eventually cause the server to stop accepting connections or xmonad to run  
out of file descriptors, depending on system load etc.

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sat May 31 21:22:56 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sat, 31 May 2014 21:22:56 +0000
Subject: [xmonad] Issue 573 in xmonad:
 XMonad.Util.XSelection.getSelection leaks a handle to the X server
In-Reply-To: <0-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>
References: <0-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>
Message-ID: <1-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>

Updates:
	Summary: XMonad.Util.XSelection.getSelection leaks a handle to the X server

Comment #1 on issue 573 by allber... at gmail.com:  
XMonad.Util.XSelection.getSelection leaks a handle to the X server
http://code.google.com/p/xmonad/issues/detail?id=573

(No comment was entered for this change.)

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sat May 31 21:28:37 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sat, 31 May 2014 21:28:37 +0000
Subject: [xmonad] Issue 573 in xmonad:
 XMonad.Util.XSelection.getSelection leaks a handle to the X server
In-Reply-To: <1-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>
References: <1-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>
Message-ID: <2-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>


Comment #2 on issue 573 by gwe... at gmail.com:  
XMonad.Util.XSelection.getSelection leaks a handle to the X server
http://code.google.com/p/xmonad/issues/detail?id=573

I see. That would explain why every few weeks my X.org refuses to open up  
any more applications and I have to restart it. Would it be sufficient to  
simply add a 'closeDisplay' at the end of 'getSelection' to match  
the 'openDisplay' at the start?

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sat May 31 21:32:58 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sat, 31 May 2014 21:32:58 +0000
Subject: [xmonad] Issue 573 in xmonad:
 XMonad.Util.XSelection.getSelection leaks a handle to the X server
In-Reply-To: <2-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>
References: <2-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>
Message-ID: <3-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>


Comment #3 on issue 573 by allber... at gmail.com:  
XMonad.Util.XSelection.getSelection leaks a handle to the X server
http://code.google.com/p/xmonad/issues/detail?id=573

`closeDisplay dpy`, yes, although you need to handle both legs of the `if`  
at the end. I don't think it needs anything else, although I can think of  
timing issues which could potentially lead to it never receiving that  
SelectionNotify event it busywaits on.

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

From codesite-noreply at google.com  Sat May 31 23:53:05 2014
From: codesite-noreply at google.com (codesite-noreply at google.com)
Date: Sat, 31 May 2014 23:53:05 +0000
Subject: [xmonad] Issue 573 in xmonad:
 XMonad.Util.XSelection.getSelection leaks a handle to the X server
In-Reply-To: <3-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>
References: <3-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>
 <0-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>
Message-ID: <4-3425899027203913298-17690187920386402337-codesite-noreply=google.com@googlecode.com>


Comment #4 on issue 573 by gwe... at gmail.com:  
XMonad.Util.XSelection.getSelection leaks a handle to the X server
http://code.google.com/p/xmonad/issues/detail?id=573

So could we do that as:

     hunk ./XMonad/Util/XSelection.hs 66
     -    if ev_event_type ev == selectionNotify
     -       then do res <- getWindowProperty8 dpy clp win
     -               return $ decode . map fromIntegral . fromMaybe [] $ res
     -       else destroyWindow dpy win >> return ""
     +    result <- if ev_event_type ev == selectionNotify
     +                 then do res <- getWindowProperty8 dpy clp win
     +                         return $ decode . map fromIntegral .  
fromMaybe [] $ res
     +                 else destroyWindow dpy win >> return ""
     +    closeDisplay dpy
     +    return result

? Compiles, anyway.

-- 
You received this message because this project is configured to send all  
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings