2011/6/7 Ted Zlatanov :

On Tue, 7 Jun 2011 13:07:21 -0400 Brandon Allbery wrote: BA> 2011/6/7 Ted Zlatanov :

...

...

and pinned to a window edge.  So far so good.  But XMonad doesn't give it the keyboard focus; I can only use the mouse in that frame.  That's a problem since Emacs is mostly keyboard-driven, so it's hard to do much in that frame.

BA> Most of the dock management stuff does a doIgnore on windows, which BA> means they'll never receive keyboard focus.  You'll find more flexible BA> code in XMonad.Hooks.ManageHelpers for things like this; just leave BA> off the doIgnore part.

OK, so it's not a bug?  It seems unreasonable to block docks from getting the keyboard focus.  Why does XMonad do it and others don't?

I suspect it's mostly a matter of cargo cult coding: people blindly copying code without really understanding what it does. The author of ManageHelpers understood well enough to include other possibilities.

Looking at the docs for XMonad.Hooks.ManageHelpers didn't help me much (I don't know the XMonad internals and configuration well at all).

Hrm. Have had too many things going on of late and apparently misremembered; I had been working on extended freedesktop.org support and thought I'd discovered that I was reinventing parts of ManageHelpers. This is from my own package, which is on hold at the moment:

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

This replaces the "manageDocks" in manageHook, but you still need the rest of the ManageDocks machinery to handle the struts.

2011/6/7 Ted Zlatanov :

On Tue, 7 Jun 2011 14:14:34 -0400 Brandon Allbery wrote: BA> 2011/6/7 Ted Zlatanov :

...

...

OK, so it's not a bug?  It seems unreasonable to block docks from getting the keyboard focus.  Why does XMonad do it and others don't?

BA> I suspect it's mostly a matter of cargo cult coding:  people blindly BA> copying code without really understanding what it does.  The author of BA> ManageHelpers understood well enough to include other possibilities.

OK, but I'm talking about the default settings.  Is it reasonable to block docks from getting the keyboard focus by default?  What is gained by that?  Or is there no default and my configuration is the problem?

Most docks don't expect keyboard input directly and either open a new window or explicitly request input focus (e.g. gnome mini-commander applet), so users get confused when input focus goes to a dock especially in click-to-focus mode. I think one of the early minimalist docks did the wrong thing with input focus, too. In any case, it's somewhat unusual for a dock to want the input focus, and strange things can happen if you grant it. (Even in newer ones; I had some odd behavior from KDE4's Plasma while working on my freedesktop.org extensions due to unexpected input focus.)

BA> This replaces the "manageDocks" in manageHook, but you still need the BA> rest of the ManageDocks machinery to handle the struts.

OK.  Do you want me to open a bug or a wishlist item for this to remind you to put that functionality in the core?

Iyt wouldn't go into core, it would go into contrib with ManagDocks and ManageHelpers. I don't need a bug for it though (well, there already is one) as it's in my own to-dos and I'm using xmonad regularly enough that just use is enough of a reminder that it's incomplete. :)

On Tue, Jun 7, 2011 at 16:04, John Yates wrote:

been entirely successful.  Are you suggesting  that mine is a vain quest?  Or can you suggest how I might actually get it to work under Xmonad?

Dig back a few messages and you'll find the source code for a function manageUtility. Copy it into your xmonad.hs and invoke it instead of manageDocks in your manageHook.

2011/6/8 Ted Zlatanov :

On Tue, 7 Jun 2011 18:18:34 -0400 Brandon Allbery wrote: BA> Dig back a few messages and you'll find the source code for a function BA> manageUtility.  Copy it into your xmonad.hs and invoke it instead of BA> manageDocks in your manageHook.

Can it be applied only to Emacs frames at the manageHook level?

Yes, although you'll have to work out what to use to select it yourself. (This may be tricky as I've found emacs can set or change titles in odd ways.

title =? "my emacs frame" --> manageUtility

just like any other managehook.

On Tue, 7 Jun 2011 15:32:48 -0400 Brandon Allbery wrote: BA> 2011/6/7 Ted Zlatanov :

...

OK, but I'm talking about the default settings.  Is it reasonable to block docks from getting the keyboard focus by default?  What is gained by that?  Or is there no default and my configuration is the problem?

BA> Most docks don't expect keyboard input directly and either open a new BA> window or explicitly request input focus (e.g. gnome mini-commander BA> applet), so users get confused when input focus goes to a dock BA> especially in click-to-focus mode. I think one of the early BA> minimalist docks did the wrong thing with input focus, too. OK. There should be a way for an Emacs frame marked as a dock (or any dock, really) to tell XMonad that it can handle keyboard input, then, without any special configuration. Can you think of a way to do that? Maybe with some WM hints? BA> In any case, it's somewhat unusual for a dock to want the input BA> focus, and strange things can happen if you grant it. (Even in BA> newer ones; I had some odd behavior from KDE4's Plasma while working BA> on my freedesktop.org extensions due to unexpected input focus.) I only want an Emacs frame to get the keyboard focus, not docks in general. I think Emacs can handle it, and will ask the Emacs developers to fix whatever bugs we find. Like I said, if the window requests the focus, then you know it can handle it :) BA> Iyt wouldn't go into core, it would go into contrib with ManagDocks BA> and ManageHelpers. I don't need a bug for it though (well, there BA> already is one) as it's in my own to-dos and I'm using xmonad BA> regularly enough that just use is enough of a reminder that it's BA> incomplete. :) OK. I'll warn XMonad users about this, since it doesn't seem it can be fixed easily. On Tue, 7 Jun 2011 16:04:38 -0400 John Yates wrote: JY> I regularly have attempted to create a single emacs mini-buffer docked at JY> the bottom of my screen for all of my frames. (My goal is to approximate JY> the experience of the Apollo Computer DM's command window.) I have never JY> been entirely successful. Are you suggesting that mine is a vain quest? JY> Or can you suggest how I might actually get it to work under Xmonad? I want to do something similar but more like a gnome-panel replacement with many "tiles" of interactive, dynamic, and static content. At least one "tile" will be a command window like you describe, basically a minibuffer. Ted