Michael Norrish | 1 Jun 04:03 2012
Picon

xmobar disappears

When I restart xmonad with a M-q command my xmobar disappears.  There's an 
xmobar process running and it's not obviously blocked.  (strace shows it doing 
things, including recvfrom and writev both with non-zero positive return codes).

Xmonad also appears to think it's there in at least some sense because there's a 
strut on the top of the screen.  But instead of there being anything visible, I 
can just see the wallpaper window...

This is all under LightDM/Ubuntu12.04.  If I attempt to alter the "root window" 
(with something like display -window root some.jpg) the wallpaper doesn't 
change, suggesting that there is a wallpaper window lying on top of the "real 
root window".  Also, the wallpaper responds to right-clicks and brings up a 
gnome-config type menu.

So, perhaps my xmobar restarts underneath the wallpaper and is thus obscured.

If so, how might I bring it to the fore?

I'm running a cabal xmonad and xmobar on top of Ubuntu12.04, with an 
/usr/share/xsessions/xmonad.desktop that looks like:

   [Desktop Entry]
   Encoding=UTF-8
   Name=XMonad
   Comment=Lightweight tiling window manager
   Exec=gnome-session --session=xmonad
   Icon=xmonad.png
   Type=XSession

and a /usr/share/gnome-session/sessions/xmonad.session that looks like:
(Continue reading)

Brandon Allbery | 1 Jun 04:25 2012
Picon

Re: xmobar disappears

On Thu, May 31, 2012 at 10:03 PM, Michael Norrish <michael.norrish-3w/jM7ZMsnj0CCvOHzKKcA@public.gmane.org> wrote:
When I restart xmonad with a M-q command my xmobar disappears.  There's an xmobar process running and it's not obviously blocked.  (strace shows it doing things, including recvfrom and writev both with non-zero positive return codes).

Given that you're using the Ubuntu Gnome/Xmonad session, it's trapped under the nautilus desktop window.  You probably want to set "lowerOnStart = False" in ~/.xmobarrc.  If this isn't sufficient and you need to actively raise it, something like this in the ManageHook might work:

    appName =? "xmobar" --> liftX . withDisplay . (io .) . flip raiseWindow =<< ask

--
brandon s allbery                                      allbery.b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

<div><div dir="ltr">On Thu, May 31, 2012 at 10:03 PM, Michael Norrish <span dir="ltr">&lt;<a href="mailto:michael.norrish@..." target="_blank">michael.norrish@...</a>&gt;</span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote">When I restart xmonad with a M-q command my xmobar disappears. &nbsp;There's an xmobar process running and it's not obviously blocked. &nbsp;(strace shows it doing things, including recvfrom and writev both with non-zero positive return codes).<br>
</blockquote>
<div><br></div>
<div>Given that you're using the Ubuntu Gnome/Xmonad session, it's trapped under the nautilus desktop window. &nbsp;You probably want to set "lowerOnStart = False" in ~/.xmobarrc. &nbsp;If this isn't sufficient and you need to actively raise it, something like this in the ManageHook might work:</div>
<div><br></div>
<div>&nbsp; &nbsp; appName =? "xmobar" --&gt; liftX . withDisplay . (io .) . flip raiseWindow =&lt;&lt; ask</div>
<div><br></div>
</div>-- <br>brandon s allbery &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a href="mailto:allbery.b@..." target="_blank">allbery.b@...</a><br>
wandering unix systems administrator (available) &nbsp; &nbsp; (412) 475-9364 vm/sms<br><br>
</div></div>
Michael Norrish | 1 Jun 04:35 2012
Picon

Re: xmobar disappears

On 01/06/12 12:25, Brandon Allbery wrote:
> On Thu, May 31, 2012 at 10:03 PM, Michael Norrish <michael.norrish@...
> <mailto:michael.norrish@...>> wrote:
>
>     When I restart xmonad with a M-q command my xmobar disappears.  There's an
>     xmobar process running and it's not obviously blocked.  (strace shows it
>     doing things, including recvfrom and writev both with non-zero positive
>     return codes).
>
>
> Given that you're using the Ubuntu Gnome/Xmonad session, it's trapped under the
> nautilus desktop window.  You probably want to set "lowerOnStart = False" in
> ~/.xmobarrc.

This seems to do the trick; thanks!

> If this isn't sufficient and you need to actively raise it,
> something like this in the ManageHook might work:
>
>      appName =? "xmobar" --> liftX . withDisplay . (io .) . flip raiseWindow =<< ask

This fails with

xmonad.hs:122:76:
     Couldn't match expected type `Endo WindowSet' with actual type `()'
     Expected type: Display -> Window -> IO (Endo WindowSet)
       Actual type: Display -> Window -> IO ()
     In the first argument of `flip', namely `raiseWindow'
     In the second argument of `(.)', namely `flip raiseWindow'

But I'll try to get back to the list with a version that works (for future 
reference).

Michael

Brandon Allbery | 1 Jun 04:55 2012
Picon

Re: xmobar disappears

On Thu, May 31, 2012 at 10:35 PM, Michael Norrish <michael.norrish-3w/jM7ZMsnj0CCvOHzKKcA@public.gmane.org> wrote:

    appName =? "xmobar" --> liftX . withDisplay . (io .) . flip raiseWindow =<< ask

xmonad.hs:122:76:
   Couldn't match expected type `Endo WindowSet' with actual type `()'
   Expected type: Display -> Window -> IO (Endo WindowSet)
     Actual type: Display -> Window -> IO ()
   In the first argument of `flip', namely `raiseWindow'
   In the second argument of `(.)', namely `flip raiseWindow'

But I'll try to get back to the list with a version that works (for future reference).

*sigh* I always forget mangling it back to the type ManageHook expects...

    appName =? "xmobar" --> (liftX . withDisplay . (io .) . flip raiseWindow =<< ask) <+> idHook

and may require extra parentheses depending on how you mix it into an existing ManageHook.

--
brandon s allbery                                      allbery.b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

<div><div dir="ltr">On Thu, May 31, 2012 at 10:35 PM, Michael Norrish <span dir="ltr">&lt;<a href="mailto:michael.norrish@..." target="_blank">michael.norrish@...</a>&gt;</span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote">
<div class="im">
<blockquote class="gmail_quote">
<br>
&nbsp; &nbsp; appName =? "xmobar" --&gt; liftX . withDisplay . (io .) . flip raiseWindow =&lt;&lt; ask<br>
</blockquote>
<br>
</div>xmonad.hs:122:76:<br>
 &nbsp; &nbsp;Couldn't match expected type `Endo WindowSet' with actual type `()'<br>
 &nbsp; &nbsp;Expected type: Display -&gt; Window -&gt; IO (Endo WindowSet)<br>
 &nbsp; &nbsp; &nbsp;Actual type: Display -&gt; Window -&gt; IO ()<br>
 &nbsp; &nbsp;In the first argument of `flip', namely `raiseWindow'<br>
 &nbsp; &nbsp;In the second argument of `(.)', namely `flip raiseWindow'<br><br>
But I'll try to get back to the list with a version that works (for future reference).</blockquote>
<div><br></div>
<div>*sigh* I always forget mangling it back to the type ManageHook expects...</div>
<div><br></div>
<div>
&nbsp; &nbsp; appName =? "xmobar" --&gt; (liftX . withDisplay . (io .) . flip raiseWindow =&lt;&lt; ask) &lt;+&gt; idHook</div>
<div><br></div>
<div>and may require extra parentheses depending on how you mix it into an existing ManageHook.</div>
<div><br></div>
</div>-- <br>brandon s allbery &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a href="mailto:allbery.b@..." target="_blank">allbery.b@...</a><br>wandering unix systems administrator (available) &nbsp; &nbsp; (412) 475-9364 vm/sms<br><br>
</div></div>
Michael Norrish | 1 Jun 06:33 2012
Picon

Re: xmobar disappears

On 01/06/12 12:55, Brandon Allbery wrote:
>
> *sigh* I always forget mangling it back to the type ManageHook expects...
>
>      appName =? "xmobar" --> (liftX . withDisplay . (io .) . flip raiseWindow
> =<< ask) <+> idHook
>
> and may require extra parentheses depending on how you mix it into an existing
> ManageHook.

I'm afraid that gives exactly the same error.  An earlier post of yours to this 
mailing list (http://www.haskell.org/pipermail/xmonad/2011-June/011495.html) has

> manageUtility :: ManageHook
> manageUtility =  ask >>=
>                  \win -> liftX (withDisplay $ \dpy -> io $ raiseWindow dpy win) >>
>                  doFloat

The doFloat on the end is necessary to get the type-error to go away. 
Presumably idHook would be better there, making the entry

   appName =? "xmobar" -->
     (ask >>=
      \win -> liftX (withDisplay $ \dpy -> io $ raiseWindow dpy win) >>
      idHook)

If the .xmobarrc has lowerOnStart set to True, the above doesn't help.  (Nor 
does the version with doFloat.)

So, in my situation it looks as if it has to be lowerOnStart = False in the 
.xmobarrc.

Michael

Brandon Allbery | 1 Jun 06:38 2012
Picon

Re: xmobar disappears

On Fri, Jun 1, 2012 at 12:33 AM, Michael Norrish <michael.norrish-3w/jM7ZMsnj0CCvOHzKKcA@public.gmane.org> wrote:
 appName =? "xmobar" -->
   (ask >>=
    \win -> liftX (withDisplay $ \dpy -> io $ raiseWindow dpy win) >>
    idHook)

If the .xmobarrc has lowerOnStart set to True, the above doesn't help.  (Nor does the version with doFloat.)

It wouldn't; the lowerOnStart happens concurrently, and probably (but not certainly) after the above.  I am a bit confused about how something that typechecked in ghci here didn't work, but I'm still bringing this machine back toward something resembling sanity and in particular its ghc and/or xmonad may be slightly deranged (I'm waiting on the HP update that was supposed to happen today).
 
--
brandon s allbery                                      allbery.b-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org
wandering unix systems administrator (available)     (412) 475-9364 vm/sms

<div><div dir="ltr">On Fri, Jun 1, 2012 at 12:33 AM, Michael Norrish <span dir="ltr">&lt;<a href="mailto:michael.norrish@..." target="_blank">michael.norrish@...</a>&gt;</span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote">
<div class="im">&nbsp;appName =? "xmobar" --&gt;</div>
 &nbsp; &nbsp;(ask &gt;&gt;=<br>
 &nbsp; &nbsp; \win -&gt; liftX (withDisplay $ \dpy -&gt; io $ raiseWindow dpy win) &gt;&gt;<br>
 &nbsp; &nbsp; idHook)<br><br>
If the .xmobarrc has lowerOnStart set to True, the above doesn't help. &nbsp;(Nor does the version with doFloat.)<br>
</blockquote>
<div><br></div>
<div>It wouldn't; the lowerOnStart happens concurrently, and probably (but not certainly) after the above. &nbsp;I am a bit confused about how something that typechecked in ghci here didn't work, but I'm still bringing this machine back toward something resembling sanity and in particular its ghc and/or xmonad may be slightly deranged (I'm waiting on the HP update that was supposed to happen today).</div>
<div>&nbsp;</div>
</div>-- <br>brandon s allbery &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a href="mailto:allbery.b@..." target="_blank">allbery.b@...</a><br>wandering unix systems administrator (available) &nbsp; &nbsp; (412) 475-9364 vm/sms<br><br>
</div></div>
codesite | 2 Jun 18:44 2012
Picon

Re: Issue 177 in xmonad: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol


Comment #86 on issue 177 by losinsk...@...: xmonad does not
follow  
ICCCM and ignores WM_TAKE_FOCUS protocol
http://code.google.com/p/xmonad/issues/detail?id=177

With Java 7 I get no focus at all it was lost one time. There are a few  
ressources for that bit no solution:
http://bugs.sun.com/view_bug.do?bug_id=6798064
http://grokbase.com/t/openjdk/awt-dev/106y6r0vgm/swing-dev-jdk17-on-x11-keyboard-focus-consistently-broken-on-some-window-managers
https://github.com/scode/bug-swingfocus

Joachim Breitner | 2 Jun 19:37 2012
Picon

Re: [patch] EwmhDesktops: make setActiveWindow set _NET_WM_STATE for gtk-3.4

Hi,

Am Mittwoch, den 21.03.2012, 20:11 -0400 schrieb Brandon Allbery:
> On Wed, Mar 21, 2012 at 19:49, Gwern Branwen <gwern0@...> wrote:
>         Does anyone have any thoughts on this?
> 
> 
> Technically we should also be setting _NET_WM_STATE_FOCUSED for
> focused windows and removing that atom when the windowe loses focus
> (this is a recent revision to EWMH; it didn't exist when EWMHDesktops
> was originally written).  It would be interesting to see if doing so
> fixes any of the other occasional odd behaviors that get reported.

I tested this here, and just ensuring that _NET_WM_STATE exists did not
seem to make a difference. The proper solution, as I gather from reading
the mutter source, seems to be
 * Include _NET_WM_STATE_FOCUSED in _NET_SUPPORTED
 * For the active window, edit the list _NET_WM_STATE and include
_NET_WM_STATE_FOCUSED (just appending will keep enlarging the list)
 * For other windows, remove it from the list.

Greetings,
Joachim

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata@... | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@... | http://people.debian.org/~nomeata
Hi,

Am Mittwoch, den 21.03.2012, 20:11 -0400 schrieb Brandon Allbery:
> On Wed, Mar 21, 2012 at 19:49, Gwern Branwen <gwern0@...> wrote:
>         Does anyone have any thoughts on this?
> 
> 
> Technically we should also be setting _NET_WM_STATE_FOCUSED for
> focused windows and removing that atom when the windowe loses focus
> (this is a recent revision to EWMH; it didn't exist when EWMHDesktops
> was originally written).  It would be interesting to see if doing so
> fixes any of the other occasional odd behaviors that get reported.

I tested this here, and just ensuring that _NET_WM_STATE exists did not
seem to make a difference. The proper solution, as I gather from reading
the mutter source, seems to be
 * Include _NET_WM_STATE_FOCUSED in _NET_SUPPORTED
 * For the active window, edit the list _NET_WM_STATE and include
_NET_WM_STATE_FOCUSED (just appending will keep enlarging the list)
 * For other windows, remove it from the list.

Greetings,
Joachim

--

-- 
Joachim "nomeata" Breitner
Debian Developer
  nomeata@... | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata@... | http://people.debian.org/~nomeata
Picon

Prompt completion: Longest common string

Well, I don't know if I can be clear enough; I'm looking to be able to
"complete" when I press tab instead of cycle through every option.

For example:

   Run: gno
   a lot of output that starts with gnome-

I would expect that pressing <Tab> turns gno to gnome-

I've been looking trough the Xmonad.Prompt and Xmonad.Prompt.Shell in
the contrib docs, but I can't find the correct function to do it.

I guess it have to do with 'mkComplFunFromList' or 'nextCompletion',
but I don't how (or where) to start :(

Any help/guidance would be greatly appreciated.

Regards,
--

-- 
Pablo Olmos de Aguilera Corradini -  <at> PaBLoX
http://www.glatelier.org/
http://about.me/pablox/
http://www.linkedin.com/in/pablooda/
Linux User: #456971 - http://counter.li.org/

codesite | 3 Jun 17:02 2012
Picon

Issue 507 in xmonad: Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14

Status: New
Owner: ----

New issue 507 by smp...@...: Pattern match failure in do
expression  
at XMonad/Prompt.hs:601:3-14
http://code.google.com/p/xmonad/issues/detail?id=507

**What steps will reproduce the problem?**
I'm not sure that I can exactly describe how I get it. Generally speaking,  
it's
`shellPrompt' call and fast `t' pressing.

Than I get xmonad totally freezed and message in terminal where I call  
`xinit',
which run xmonad:

     Pattern match failure in do expression at XMonad/Prompt.hs:601:3-14

At 601 line of Prompt.hs there is unsafe pattern matching:

   Just bgcolor <- io $ initColor d (bgColor c)
   Just border  <- io $ initColor d (borderColor c)

**What is the expected output? What do you see instead?**
What I want is some `fromJust' there or hadling this situation with `case'.

It's xmonad-contrib-0.10-r1 build from gentoo-haskell overlay.  
(https://github.com/gentoo-haskell/gentoo-haskell/tree/master/x11-wm/xmonad-contrib)


Gmane