On Tue, Aug 26, 2008 at 04:23:59PM -0400, Gwern Branwen wrote:

Before we do a release, I have a question: are we actually up to date on patches?

When I look at DarcsWatch http://darcswatch.nomeata.de/repo_http:__code.haskell.org_XMonadContrib.html, I see a number of patches, and some of them look good. For example, one patch adds some more search engines to Action.Search http://www.haskell.org/pipermail/xmonad/2008-May/005663.html. Now, it doesn't apply cleanly, but that's probably because it's been sitting around since May, and I don't see any replies to it saying yea or nay.

Re-record and send it if you think it is worthwhile.

Or how about this UpdatePointer patch http://www.haskell.org/pipermail/xmonad/2008-June/005845.html? No comments, applies cleanly, and doesn't look fatally flawed to me.

It has the words 'UpdatePointer' in it, which at one time had several patches and workarounds that tended to subtly break other things. This patch is probably okay, I can take a look at it after the release.

Another example: runOrCopy: http://www.haskell.org/pipermail/xmonad/2008-June/005799.html. I did criticize the duplication, but what I meant by that was to fix it or add a comment (TODO/FIXME) about the issue - I didn't intend for it to not be applied at all.

When a patch gets criticism from the module's author, how else should we react? If you'd like this patch to be pushed with some additional changes you can apply it locally and send the patch along with your modifications.

....

Well, I think you get the idea. Perhaps before patches get even more stale and forgotten than they already are, we could go through DarcsWatch and clear out patches (and ask Nomeata to remove some of the irrelevant ones like the Xfce one.)

-- gwern Iraq Hercules Bosnia Summercon Compsec 20 Albright EuroFed RDI encryption

I don't think it is wise to apply all these patches before the release. Cheers, Spencer Janssen

OK, since we aren't applying any patches until after 0.8, I thought I would make a list for when we do. This is a long list, so I hope people read it through (it certainly took long enough to compile). XMONAD http://darcswatch.nomeata.de/repo_http:__code.haskell.org_xmonad.html 9 patches outstanding. Let's go through the interesting ones: * "add warpGeometry field to XConf" http://www.haskell.org/pipermail/xmonad/2008-May/005651.html Applicable. No comments on it. Useful? I don't know Mirror so I can't say. * "XDG_CONFIG_HOME support" http://www.haskell.org/pipermail/xmonad/2008-May/005762.html. Applicable. Commented upon. The discussion never came to any conclusion I can see. The 5 non-patch emails discussing it: ** sjanssen, opposed (or at least skeptical): http://www.haskell.org/pipermail/xmonad/2008-May/005765.html ** dons, noncommittal: http://www.haskell.org/pipermail/xmonad/2008-May/005770.html ** Brandon Allbery, in favor of (?): http://www.haskell.org/pipermail/xmonad/2008-May/005771.html ** Devin Mullins, opposed: http://www.haskell.org/pipermail/xmonad/2008-May/005772.html ** Isaac Jones, in favor of: http://www.haskell.org/pipermail/xmonad/2008-May/005774.html. ** the patch author, in favor of (obviously) So: 1 neutral, 2 opposed, 3 in favor of. I don't know much about this, but the code change looks fairly clear to me, and the one real disadvantage adduced ('This has one disadvantage I can think of: for DEs that set $XDG automatically, users will have to know about it in order to know where to put their .xmonad.hs -- otherwise the file won't be detected. Perhaps that's not worth worrying about.') doesn't sound terribly serious? * "darcs patch: pass mouse clicks on to focused windows (experimental)" http://www.haskell.org/pipermail/xmonad/2008-June/005807.html Applicable. No comments on it. Marked experimental; perhaps Lukas Mai can comment on whether this is still good? * "Use threadWaitRead to avoid blocking in nextEvent in the main loop" http://www.haskell.org/pipermail/xmonad/2008-June/005895.html Allbery commented with advice http://www.haskell.org/pipermail/xmonad/2008-June/005897.html, and Adam Sampson took it and apparently wrote a new & improved patch http://www.haskell.org/pipermail/xmonad/2008-June/005899.html. This second patch is applicable, but I see no feedback on it. A good idea? Not being able to usefully run threads because of blocking strikes me as a problem. * "keyActions moved to XState" http://www.haskell.org/pipermail/xmonad/2008-July/006063.html Applicable. No comments. Confusingly, the second patch does not seem to exist on the mailing list, although Darcswatch has it at http://darcswatch.nomeata.de/20080715143436-7641b-979a1f6ea132b4dceba775c8d9.... A good idea? Looks like it; it enables a interesting looking patch to XMC http://www.haskell.org/pipermail/xmonad/2008-July/006041.html: "* XMonad.Actions.DynamicKeys: utilities to update key bindings at runtime" Summary: 5 outstanding patches of the 9 total are worth considering; 2 or 3 look worthwhile to me. XMONADCONTRIB http://darcswatch.nomeata.de/repo_http:__code.haskell.org_XMonadContrib.html 13 patches outstanding. Let's go through the interesting ones: * "Actions.Search: added {deb,debbts,debpts,images,isohunt} search engines" http://www.haskell.org/pipermail/xmonad/2008-May/005663.html Not applicable. No comments. I've emailed intrigeri asking him to re-record and send, since it is definitely a worthwhile patch to Action.Search. If he doesn't I probably will (assuming I don't forget). * "Fix window region checking in UpdatePointer", "Fix window region checking in UpdatePointer (and 1 more)" http://www.haskell.org/pipermail/xmonad/2008-June/005843.html, http://www.haskell.org/pipermail/xmonad/2008-June/005845.html Applicable. No comments. Joachim reported no bugs. ** "Only move pointers over managed windows" http://darcswatch.nomeata.de/20080610195916-23c07-acb9d3a32366a2d83284a837fd... See previous. * "XMonad.Actions.CopyWindow runOrCopy" http://www.haskell.org/pipermail/xmonad/2008-June/005799.html, patch http://darcswatch.nomeata.de/20080602205742-20747-65c3b7fcab114e84def368c540... Applicable. I commented and criticized it a little; I think it should be applied - I don't mind grappling with the code duplication later. * "Make prompt controlMask keybindings work when other modifiers are active" ???; patch http://darcswatch.nomeata.de/20080608222350-18f27-aa3de81015e9eb69d4bdd91a21... Not applicable. I don't know anything about this one. I include it because I don't actually know for certain that the current Prompt code does have working 'controlMask keybindings' when other modifiers are active. * "hide the implementation type in "EwmhDesktopsLayout"" Not applicable (due to a Darcs bug?). Was a response to this thread http://www.haskell.org/pipermail/xmonad/2008-June/thread.html#5837, but while the other patches got applied, this one got ignored - no comments on it. * "ManageDocks: keep struts on top" An attachment on Google Code (?); I can't find the right bug report. Patch: http://darcswatch.nomeata.de/20080626200455-18f27-727aac59e80057468e07299cea... Applicable. No discussion that I know of. * "darcs patch: Improvements in documentation (and 3 more)" ** "XMonad.Actions.Plane: removed unneeded hiding" ** "XMonad.Config.Gnome: using XMonad.Actions.Plane" ** "XMonad.Actions.Plane.planeKeys: function to make easier to configure" http://www.haskell.org/pipermail/xmonad/2008-July/006064.html Applicable. No discussion. (Poor Marco! Counting his Xmonad patch, that makes 5 or so patches that just got ignored.) * "XMonad.Actions.DynamicKeys: utilities to update key bindings at runtime" http://www.haskell.org/pipermail/xmonad/2008-July/006041.html Applicable. No comments. Requires the patch to XMonad core discussed previously. Summary: 10 or 11 patches worth considering; and 3 or 4 especially so. MISC http://darcswatch.nomeata.de/unmatched.html * "Fixes for Ssh Module" ???; patch: http://darcswatch.nomeata.de/20080810121734-d4c7e-893bfc8762644b1f97a488b318... May be applicable, but a darcs bug is triggered. I don't know where this one came from. It looks like some substantial Ssh changes though and is worth looking at? -- gwern Kvashnin OC-12 World BROMURE nitrate Marxist ASIC intelligence NAIA Defcon

Em Qui, 2008-08-28 às 15:09 -0600, Justin Bogner escreveu:

Gwern Branwen writes:

...

* "darcs patch: Improvements in documentation (and 3 more)" ** "XMonad.Actions.Plane: removed unneeded hiding" ** "XMonad.Config.Gnome: using XMonad.Actions.Plane" ** "XMonad.Actions.Plane.planeKeys: function to make easier to configure" http://www.haskell.org/pipermail/xmonad/2008-July/006064.html Applicable. No discussion. (Poor Marco! Counting his Xmonad patch, that makes 5 or so patches that just got ignored.)

I think the problem here was probably that there are four patches in that set, and one of them seems dubious (Plane seems like a user preference, not something to default for all Gnome users). The other three patches in that set look okay to me.

Isn't it possible to apply just the 3 others? If not, maybe I should resend then. About the other one, I don't think using gnome-terminal, and M-p to gnomeRun and M-Q to gnome-session-save --kill is a default to all Gnome users. I think they're a possible configuration to have a good interface with GNOME. The default way Metacity handles workspaces is very similar to Plane, so I thought that users coming from Metacity would enjoy having similar key bindings for workspace navigation. Greetings. -- marcot Página: http://marcotmarcot.googlepages.com/ Blog: http://marcotmarcot.blogspot.com/ Correio: marcot@riseup.net XMPP: marcot@jabber.org IRC: marcot@irc.freenode.net Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil

On Thu, Aug 28, 2008 at 03:09:05PM -0600, Justin Bogner wrote:

...

* "ManageDocks: keep struts on top" An attachment on Google Code (?); I can't find the right bug report. Patch: http://darcswatch.nomeata.de/20080626200455-18f27-727aac59e80057468e07299cea... Applicable. No discussion that I know of.

Several people seemed interested in this on IRC, but nobody commented on it on the mailing list. It works for my use cases, but I was hoping others would comment on whether it could be better in any way.

I remember having comments for this patch, but I must have forgotten to send an email. This patch addresses an important problem, but I think it goes about it in the wrong way. There are two sorts of struts programs that we typically use: * override-redirect bars like dzen and xmobar. ICCCM says that we shouldn't manage these windows at all, so lowering them is technically a violation of the ICCCM. Instead, these windows should lower themselves on startup. * desktop bars such as kicker and gnome-panel. We are allowed to manage these, and they even set atoms on their window we can use to stack them. In manageDocks, when a window is detected as a DOCK or DESKTOP window, we should send all DESKTOP windows to the bottom of the stacking order and all DOCK windows to one layer above that.

...

* "darcs patch: Improvements in documentation (and 3 more)" ** "XMonad.Actions.Plane: removed unneeded hiding" ** "XMonad.Config.Gnome: using XMonad.Actions.Plane" ** "XMonad.Actions.Plane.planeKeys: function to make easier to configure" http://www.haskell.org/pipermail/xmonad/2008-July/006064.html Applicable. No discussion. (Poor Marco! Counting his Xmonad patch, that makes 5 or so patches that just got ignored.)

I think the problem here was probably that there are four patches in that set, and one of them seems dubious (Plane seems like a user preference, not something to default for all Gnome users). The other three patches in that set look okay to me.

Yes, this is why I passed over that patch bundle the first time. Cheers, Spencer Janssen

On 2008 Aug 30, at 2:55, Justin Bogner wrote:

Spencer Janssen writes:

...

* desktop bars such as kicker and gnome-panel. We are allowed to manage these, and they even set atoms on their window we can use to stack them. In manageDocks, when a window is detected as a DOCK or DESKTOP window, we should send all DESKTOP windows to the bottom of the stacking order and all DOCK windows to one layer above that.

That said, the behaviour I expect is that docks should be at the very top or not visible at all, and never anything in between.

This is often a configurable preference (see for example Windows' task bar). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 2008 Aug 30, at 23:43, Justin Bogner wrote:

"Brandon S. Allbery KF8NH" writes:

...

On 2008 Aug 30, at 2:55, Justin Bogner wrote:

...

That said, the behaviour I expect is that docks should be at the very top or not visible at all, and never anything in between.

This is often a configurable preference (see for example Windows' task bar).

Sorry, poor choice of terminology on my part. To be clear, I meant top of the stacking order, not the screen. Now that I think of it though, I think I've used a taskbar that had an option like "allow other windows to cover the taskbar" at some point.

The Windows preference is "allow other windows to cover taskbar" or something like that. The Gnome panel used to have a similar option' I haven't checked recently. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

Em Qui, 2008-08-28 às 16:45 -0400, Gwern Branwen escreveu:

* "keyActions moved to XState" http://www.haskell.org/pipermail/xmonad/2008-July/006063.html Applicable. No comments. Confusingly, the second patch does not seem to exist on the mailing list, although Darcswatch has it at http://darcswatch.nomeata.de/20080715143436-7641b-979a1f6ea132b4dceba775c8d9....

It's here: http://www.haskell.org/pipermail/xmonad/2008-July/006062.html

(Poor Marco! Counting his Xmonad patch, that makes 5 or so patches that just got ignored.)

=) -- marcot Página: http://marcotmarcot.googlepages.com/ Blog: http://marcotmarcot.blogspot.com/ Correio: marcot@riseup.net XMPP: marcot@jabber.org IRC: marcot@irc.freenode.net Telefone: 25151920 Celular: 98116720 Endereço: Rua Turfa, 639/701 Prado 30410-370 Belo Horizonte/MG Brasil

On 2008 Aug 28, at 23:30, Robert Prije wrote:

Gwern Branwen wrote:

...

* "Fixes for Ssh Module" ???; patch: <http://darcswatch.nomeata.de/20080810121734-d4c7e-893bfc8762644b1f97a488b318...

...

May be applicable, but a darcs bug is triggered. I don't know where this one came from. It looks like some substantial Ssh changes though and is worth looking at?

I wasn't aware it was triggering a darcs bug. I'll try to look into it this weekend.

I recall that one going by on the list (in fact it's still in my inbox); the primary intent is to support prompting for a user. I've had in mind a similar notion, but more intelligent: tab-complete before an @ as user, after @ as host. Not that I'm likely to get to it any time soon. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 2008 Aug 29, at 8:41, Marco Túlio Gontijo e Silva wrote:

Em Qui, 2008-08-28 às 23:41 -0400, Brandon S. Allbery KF8NH escreveu:

...

I've had in mind a similar notion, but more intelligent: tab- complete before an @ as user, after @ as host.

The problem I see here is that I don't usually need to set the username, so I'd prefer to have host completion always.

You would need to type an @ to activate the username part. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 2008 Aug 29, at 17:04, Spencer Janssen wrote:

On Thu, Aug 28, 2008 at 04:45:50PM -0400, Gwern Branwen wrote:

...

* "XDG_CONFIG_HOME support" http://www.haskell.org/pipermail/xmonad/2008-May/005762.html. Applicable. Commented upon. The discussion never came to any conclusion I can see. The 5 non-patch emails discussing it: ** sjanssen, opposed (or at least skeptical): <http://www.haskell.org/pipermail/xmonad/2008-May/005765.html

...

** dons, noncommittal: <http://www.haskell.org/pipermail/xmonad/2008-May/005770.html

...

** Brandon Allbery, in favor of (?): <http://www.haskell.org/pipermail/xmonad/2008-May/005771.html

...

** Devin Mullins, opposed: <http://www.haskell.org/pipermail/xmonad/2008-May/005772.html

...

** Isaac Jones, in favor of: <http://www.haskell.org/pipermail/xmonad/2008-May/005774.html

...

.

Isaac Dupree.

Definitely in favor, since my home directory lives on a network filesystem but state like this needs to be per-host. I currently have some *very* ugly workarounds that mostly work (need to be careful with ~, and with programs like ssh which trust /etc/passwd instead of $HOME), but proper XDG_CONFIG_HOME support would make most of it unnecessary. And if xmonad doesn't come with this support I will have to install it locally: *all* undergrad accounts live in AFS, not local disk, so xmonad won't work when the user is logged into multiple machines (which they will be; ECE undergrad coursework involves large distributed Matlab and Cadence runs). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 2008 Aug 29, at 21:30, Devin Mullins wrote:
> On Fri, Aug 29, 2008 at 09:02:05PM -0400, Brandon S. Allbery KF8NH  
> wrote:
>> Definitely in favor, since my home directory lives on a network
>> filesystem but state like this needs to be per-host.
> State? I can think of
> * the 'history' file from Prompt
> * the xmonad binary, which is labelled with the platform (presumably a
>   result of a request from you :)
> What about that needs to be per-host, or what am I missing?

The history file is the one that worries me; cross-network locking  
doesn't work so well, and I find myself collecting private shell  
history files (i.e. shell puts history in .bash_history.pid because it  
thinks .bash_history is locked) that don't make it into the real one.

>> $HOME), but proper XDG_CONFIG_HOME support would make most of it
>> unnecessary.
> Would an acceptable alternative be to pass the config directory as a
> cmdline arg?

What exactly is the problem with following a documented standard?

-- 
brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com
system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu
electrical and computer engineering, carnegie mellon university    KF8NH

On 2008 Aug 31, at 7:47, Devin Mullins wrote:

On Sun, Aug 31, 2008 at 12:09:31AM -0400, Brandon S. Allbery KF8NH wrote:

...

...

Would an acceptable alternative be to pass the config directory as a cmdline arg? What exactly is the problem with following a documented standard? My reasons are Spencer's reasons, plus it's not really a standard standard. You didn't answer the question.

I answered the question with another question: if the history file isn't properly locked, it must be non-shared which means at minimum a separate one per host. And if we're picking and choosing which standards we consider to be "true" standards, we risk getting locked out of distributions that disagree with us. (I would not be greatly surprised if Debian were to decide to demand it where it is relevant.) -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 2008 Aug 31, at 15:06, Devin Mullins wrote:

On Sun, Aug 31, 2008 at 10:00:48AM -0400, Brandon S. Allbery KF8NH wrote:

...

I answered the question with another question: if the history file isn't properly locked, it must be non-shared which means at minimum a separate one per host. I'm not sure I follow. I was asking if: xmonad --configdir ~/.xmonad-`hostname` # or similar would meet your needs, and if it would do so in a manner not-too-distastefully to you.

Let me rephrase this: KDE already does the right thing. GNOME seems to finally be getting there. Why do I need custom configuration for xmonad? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On Sep 4, 2008, at 12:55 , Devin Mullins wrote:

In case you're curious why I am okay with this option: This way, it's an explicit choice by the user, and not something thrust upon him by his particular platform that we then have to discover during an IRC support session.

Whereas I am looking for a way to configure as many things as possible with as few special variables as possible. This comes of having to manage several hundred local packages on top of vendor packages for 7 platforms. In any case, having already pushed xmonad out of the current round of upgrades (I'm running out of time and can't wait for bikesheds) it doesn't really matter any more. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH

On 08/31/2008 12:27 PM, Brandon S. Allbery KF8NH wrote:

Let me rephrase this: KDE already does the right thing. GNOME seems to finally be getting there. Why do I need custom configuration for xmonad?

For what it's worth, I'd like to register my support for this issue too. freedesktop.org's purpose is to improve interoperability and provide the "one standard way" of doing things across different X desktops. It seems that Gnome, KDE, and Xfce are all working closely with them already [1], and I am surprised that there would be so much resistance here. I think that for a standard like freedesktop.org that big players like Gnome and KDE are following, the default policy for xmonad should be to follow the standard that the big players are following unless there are very good reasons not to. On the support issue that Spencer and Devin mentioned, does anybody have actual examples of desktop environments or distributions that explicitly set XDG_CONFIG_HOME to some value other than $HOME/.config? Gnome doesn't set it at all. KDE doesn't set it at all (based on my interpretation of their online docs). If it's the case that it's hardly ever set *except* when a user needs to set it to something else and explicitly sets it, then xmonad would always use the default value of $HOME/.config, and it seems it would have little impact on support. That's my $.02. -calvin 1. http://en.wikipedia.org/wiki/Freedesktop.org

This discussion has seemingly diverged in two different directions, and I'd like to clarify exactly what the concerns are. The discussion was initially about moving xmonad.hs to XDG_CONFIG_HOME. This is essentially a bike shed issue: some prefer $HOME/.xmonad/xmonad.hs and others prefer $HOME/.config/xmonad/xmonad.hs. I prefer the former, and I haven't seen any convincing arguments for the latter, so we're going to stick with $HOME/.xmonad/xmonad.hs. Brandon Allbery presented another concern about data files that xmonad writes, such as the cached executable and prompt's history. It is possible that there are race conditions with concurrent readers/writers that may cause corruption. One potential workaround for this is to append the hostname to XDG_DATA_HOME (or perhaps XDG_CACHE_HOME). It is important to note that this is orthogonal to XDG_CONFIG_HOME and only involves internal xmonad files that the user typically doesn't interact with. I don't think this solution is the right direction. There are still potential problems with multiple instances of xmonad on the same hostname, and it seems to be non-standard (or at least not expected) use of the XDG Base Directory Specification. If the potential of writing corrupted files is still a concern, I recommend that someone create a bug on the bug tracker and/or a new thread on the mailing list. I also suggest that we avoid mentioning XDG_CONFIG_HOME at all in that discussion, because it is orthogonal and tends to result in bike-shed arguments. Cheers, Spencer Janssen

Hi, Am Dienstag, den 26.08.2008, 16:23 -0400 schrieb Gwern Branwen:

Or how about this UpdatePointer patch http://www.haskell.org/pipermail/xmonad/2008-June/005845.html? No comments, applies cleanly, and doesn't look fatally flawed to me.

I know that _something_ behaved differently when I packaged and installed the release candidate, although I wasn’t sure until you notified me of this. I must have had it applied locally before. I’m considering to apply it in the 0.8 Debian package when I package it, so that I can use it myself unmodified. Of course, I’d prefer it to be in the release, but I see that it’s a bit late for that. Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de

Hi, Am Donnerstag, den 28.08.2008, 15:06 -0400 schrieb Gwern Branwen:

On 2008.08.26 23:32:19 +0200, Joachim Breitner scribbled 1.6K characters:

...

Hi,

Am Dienstag, den 26.08.2008, 16:23 -0400 schrieb Gwern Branwen:

...

Or how about this UpdatePointer patch http://www.haskell.org/pipermail/xmonad/2008-June/005845.html? No comments, applies cleanly, and doesn't look fatally flawed to me.

I know that _something_ behaved differently when I packaged and installed the release candidate, although I wasn’t sure until you notified me of this. I must have had it applied locally before.

That's interesting. So you didn't see any problems with this patch? Did it get more widely used? If it's been de facto tested extensively already, application would be a good idea.

I’ve been using it since it was posted, and it’s fine. Without it, I sometimes have mouse jumps away from popped up menus, just because Xmonad felt it had to run loghook for some reason. From my POV, this is tested and can be considered a bug fix, not a new feature, and therefore could, with some goodwill, be applied in a release freeze :-) I don’t know of anyone else using it, so if anyone on this list uses UpdatePointer without these patches, please speak up.

...

I’m considering to apply it in the 0.8 Debian package when I package it, so that I can use it myself unmodified. Of course, I’d prefer it to be in the release, but I see that it’s a bit late for that.

Greetings, Joachim

Well, I think it'd be a good thing for the official release to not be different from the packaged releases; whether the resolution should be you applying it and convincing dons & sjanssen to apply it, or whether they should convince you to not apply it I have no opinion on. I just think it was bad enough when all the Debian users had problems unique to them that I don't want even a mild repeat.

I understand, but OTOH it’s a equally good thing to actually for the maintainer use the package as was released, to be able to properly respond to user’s questions. Anyways, this is a very minor and local change, and of course I’ll be responsible for any problems the Debian users might have with UpdatePointer. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

Hi, Am Freitag, den 29.08.2008, 06:40 -0400 schrieb Aaron Culich:

I was not aware of this patch because I haven't followed the patches much in a while, but I would consider this patch to be a bug fix that I would be very thankful for. Most of the time the bug is just annoying, but occasionally it can make things frustratingly unusable-- not often, but just enough. I've learned to live with the problem like hiking with a pebble in one's shoe.

I don't know how many people actually use UpdatePointer, but I suspect that for those who do use it and experience this bug, most would probably be very happy to have this fix.

Just to make sure: Have you actually applied and tested it now, and can you confirm it works for you? Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata

On Fri, Aug 29, 2008 at 03:24:46PM -0500, Spencer Janssen wrote:

Regarding Debian specific patches, I'd really rather not have that. If there is an issue that is important for Debian users, it is probably important to all xmonad users. As such, it seems best to lobby for inclusion upstream rather than help only a minority of the xmonad community.

Yeah, I think his argument is that, given failure to lobby for such inclusion, it's within the distro's right to do what's best for its users and introduce a major vulnerability into OpenSSL. ;)