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: Message-ID: 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: References: Message-ID: 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 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: References: Message-ID: 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 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 > 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: 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: References: Message-ID: 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-", 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 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 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 >> 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-", spawn "exec emacs") , ("M-S-", 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 #include #include #include #include #include #include #include #include #include #include #include #include #include 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: On Sat, May 3, 2014 at 11:35 AM, Ivan Ivanov 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: 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 #include #include #include #include #include #include #include #include #include #include #include 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: 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: promptsshsupportuserprefix.dpatch Type: application/octet-stream Size: 15651 bytes Desc: not available URL: 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: References: <1213701399131301@web6g.yandex.ru> 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" : > On Sat, May 3, 2014 at 11:35 AM, Ivan Ivanov 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: 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* *>* There are 10 types of people, those who know binary and those who don't. -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: Message-ID: On Sun, May 4, 2014 at 2:49 PM, Eyal Erez 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: 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: Message-ID: 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: References: Message-ID: 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 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: References: Message-ID: 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 wrote: > On Sun, May 4, 2014 at 2:49 PM, Eyal Erez 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* *>* There are 10 types of people, those who know binary and those who don't. -------------- next part -------------- An HTML attachment was scrubbed... URL: 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: References: Message-ID: 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 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 wrote: > >> On Sun, May 4, 2014 at 2:49 PM, Eyal Erez 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* *>* > > There are 10 types of people, those who know binary and those who don't. > > -- *Eyal Erez <**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: 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 are output to StdinReader via xmobar, where one is expected. Only the devel workspace (2) is affected by this problem. The expected output: What I see: 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 , 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: 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 : > 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: References: <5364B888.8050101@texttheater.net> Message-ID: 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 : > 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: 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: 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 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: 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: 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: References: 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: References: Message-ID: 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 : > * 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: Message-ID: 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: References: 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 : >> * 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