September 2008 - xmonad

Issue 205 in xmonad: I would like wiggling mouse to select window its over.
by codesite-noreply＠google.com 07 Sep '08

07 Sep '08

Issue 205: I would like wiggling mouse to select window its over. http://code.google.com/p/xmonad/issues/detail?id=205 Comment #5 by nomeata: Nor for me, which I find sometimes annoying :-) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 205 in xmonad: I would like wiggling mouse to select window its over.
by codesite-noreply＠google.com 07 Sep '08

07 Sep '08

Issue 205: I would like wiggling mouse to select window its over. http://code.google.com/p/xmonad/issues/detail?id=205 Comment #4 by fophillips1990: > clicking in a window transfers the click to the window Never has for me. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 205 in xmonad: I would like wiggling mouse to select window its over.
by codesite-noreply＠google.com 07 Sep '08

07 Sep '08

Issue 205: I would like wiggling mouse to select window its over. http://code.google.com/p/xmonad/issues/detail?id=205 Comment #3 by brian.brunswick: Yes. The habit and expectation that has built up with focus-follows-mouse is that as soon as the mouse is visible, that's the focused window. I pay more attention to the mouse pointer than I do to the coloured border. Its actually disconcerting that this is no longer true immediately after a workspace switch, for however long it is before the mouse crosses a window boundary. I'm suggesting changing the /cross-a-window-boundary/ test with some movement threshold, which is actually /more/ predictable as user interface behaviour than finding a window boundary, a variable distance away. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 205 in xmonad: I would like wiggling mouse to select window its over.
by codesite-noreply＠google.com 07 Sep '08

07 Sep '08

Issue 205: I would like wiggling mouse to select window its over. http://code.google.com/p/xmonad/issues/detail?id=205 Comment #2 by otto.seherol: yes, but clicking in a window transfers the click to the window, so you need to find a neutral zone in the window, which is not as comfortable as just wiggling the mouse. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Patch for xmobar: who to mail?
by Dominik Bruhn 06 Sep '08

06 Sep '08

Hy, I got a (i hope) great patch for the Mail-Plugin of xmobar and I want to share it. Who should is willing to have a look at the code and the documentation, as my haskell-knowledge is not very good and the documentation might contain some errors. I think it might be usuable for others so perhaps (I dont know the policy for this) the darcs patch could be applied to the rep. So: Who can have a look and who can apply? Thanks -- Dominik Bruhn mailto: dominik(a)dbruhn.de

2 1

Issue 205 in xmonad: I would like wiggling mouse to select window its over.
by codesite-noreply＠google.com 06 Sep '08

06 Sep '08

Issue 205: I would like wiggling mouse to select window its over. http://code.google.com/p/xmonad/issues/detail?id=205 Comment #1 by daniel.wagner: You could click on the window. This transfers focus, and if your preferred solution would already have your hand on the mouse, then this is a pretty straightforward solution. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

xmonad 0.8 release candidate
by Spencer Janssen 05 Sep '08

05 Sep '08

The xmonad team has finally been `seq`ed into making a new release, and there are a few things you can do to help: - test these release candidate tarballs http://xmonad.org/xmonad-0.7.20080820.tar.gz http://xmonad.org/xmonad-contrib-0.7.20080820.tar.gz - let us know about any critical issues that should be fixed before the release - check the documentation of your favorite modules, and submit bugs or patches for any missing docs - contributors please only push bugfixes and documentation updates until 0.8 is released - help us update the wiki documentation (the KDE and GNOME guides should be updated to use XMonad.Config.*, for example) - check the brief change list below, and tell me what I've missed. These changes will be mentioned in the release announcement, so we're looking for new functionality, important bug fixes, and compatibility notices See you on the other side of 0.8, The xmonad team core: gaps removed floats always use current screen setlocale/make title locale aware performance hack, reduced window redraws made (|||) associative contrib: Perworkspace: selectively apply layout modifiers to workspaces ManageDocks: ability to toggle gaps on each side of the screen separately HintedGride layout XMonad.Layout.Gaps: a layout modifier for manual gaps locale awareness for window titles, UTF-8 support ManageHelpers: some support for _NET_WM_STATE_FULLSCREEN XMonad.Config.{Desktop, Gnome, Kde, Xfce} XMonad.Hooks.DynamicLog: xmobar function for starting xmobar WindowNavigation improvements PlainConfig? remove ScratchWorkspace (no longer maintained) XMonad.Hooks.FadeInactive: works with xcompmgr to fade inactive windows new Scratchpad

15 45

Issue 214 in xmonad: mouse shift with java
by codesite-noreply＠google.com 05 Sep '08

05 Sep '08

Issue 214: mouse shift with java http://code.google.com/p/xmonad/issues/detail?id=214 Comment #1 by Braden.Shepherdson: This sounds to me like a badly-coded Java app that is using absolute coordinates and just leaving space for where it assumes a title bar to be. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 214 in xmonad: mouse shift with java
by codesite-noreply＠google.com 04 Sep '08

04 Sep '08

Issue 214: mouse shift with java http://code.google.com/p/xmonad/issues/detail?id=214 New issue report by girodt: > What steps will reproduce the problem? 1. launch greenfoot (http://www.greenfoot.org/download/) 2. try out the drop-down and the contextual menus for the dropdown menus, the mouse influence is heavily shifted from the actual mouse position. for the contextual menus, the whole menu is shifted away from where it should appear, in concordance with mouse influence. I tried to run the program in fluxbox to give it a try, and everything seems to be in place. It looks like this vertical shift is linked to the height of the (non-existing) status-bar of the window. I'm really outside of my area here, but I'm wondering if Java/SWING is making a call to the WM to gather informations that will allow it to calculate the mouse coordinates relative to the window's space. > What version of the product are you using? On what operating system? xmonad-0.7 + xmonad-contrib-0.7 on archlinux Issue attributes: Status: New Owner: ---- Labels: Type-Defect Priority-Medium -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Re: [xmonad] many dzen instances
by Jesús Guerrero 04 Sep '08

04 Sep '08

On Thu, 04 Sep 2008 21:01:09 +0200 Robert Manea <rob.manea(a)googlemail.com> wrote: > I suppose you are using 'avoidStruts' to let xmonad know about the > correct values for the dzen instances. Yup. > > If so, then your issue are actually 2 issues: > > 1. Dzen sets some properties that tell xmonad to set apart some > screenspace for it. > Xmonad seems to be fine with the dzen on top, the one at the very > bottom should > work just as well, without any further config, though. > > 2. The second issue is the way how dzen decides to set those properties. > It does this > by inspecting wether it touches either the top or bottom edge of the > screen, and only sets > strut information if this is actually the case. > > This means a dzen that does not touch one of the screen borders will > never be recognized > by xmonad and get extra space. > > I'm not sure if the latest xmonad release still contains code to > manually set a gap, but this for sure > would be the easiest way to solve your issue in a simple way. I understand. I also thought of that solution, and I think the code is still there, but I haven't even tried, since that would be only a temporal workaround if the code is going to be deprecated soon. However, there were some other concerns. I thikn that conky was leaking memory or something. That and a few other annoyances made me switch. I now use a couple of gkrellms on the right side of one of my monitors to monitor a couple of boxes, and all is fine. I keep one dzen on the top for my windows, layouts and workspaces. So, after all I found a suitable solution for me. Thanks for the response. -- Jesús Guerrero <i92guboj(a)terra.es>

1 0