Hi, Am Mittwoch, den 19.03.2008, 11:05 -0700 schrieb Don Stewart:

mail:

...

Hi,

these are updates to the EWHM module, making it react to pager and window list interaction. It depends on Andrea’s patches, most notably EventHook.

I could not merge my old EWHM interaction patches (darcs problems), so I re-recorded them. Don’t try to merge them if you have the old ones floating around (which most likely is not the case).

They basically work, but not fully reliable, although all messages arrive. Maybe some race conditions with other xmonad code, this needs to be checked by more experienced coders (check function "handler"). But as it does not introduce a regression, it should be save to apply to the main line.

Ok. So you're view is that this won't affect the core, or other plugins, and is generally useful for pushing forward on the event system?

Hmm, I did not completely review the EventHook code, but I could successfully use it, therefore it is useful :-). I also think that the small glitches left are not related to the EventHook code, i observed them with my own hook system from back then as well. It works without changes to the core. Personally I must say that I’d prefer a hook inserted in the core (just like logHook etc.) for simplicity, but I’m fine with whatever works. Greetings, Joachim -- Joachim Breitner e-Mail: mail@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata@joachim-breitner.de

dons:

mail:

...

Hi,

these are updates to the EWHM module, making it react to pager and window list interaction. It depends on Andrea’s patches, most notably EventHook.

I could not merge my old EWHM interaction patches (darcs problems), so I re-recorded them. Don’t try to merge them if you have the old ones floating around (which most likely is not the case).

They basically work, but not fully reliable, although all messages arrive. Maybe some race conditions with other xmonad code, this needs to be checked by more experienced coders (check function "handler"). But as it does not introduce a regression, it should be save to apply to the main line.

Can you redo these patches against XMonadContrib head, they can't be applied currently, due to:

$ darcs apply /tmp/add-eventhook_-a-layout-modifier-to-handle-x-events.dpatch darcs: Cannot apply this patch bundle, since we're missing

Sun Oct 28 04:25:52 PDT 2007 mail@joachim-breitner.de tagged UPSTREAM_xmonadcontrib_0.4

Applied!

Hi, Am Samstag, den 22.03.2008, 11:55 -0400 schrieb David Roundy:

Of course, you could lobby for fixes in core, but that's a slow and tedious process.

A thought that occured to me: I know these kind of statements from heart as a Debian Developer, because Debian is 11 years old and has over one thousand developers. But that it should also apply to xmonad, which is 1 year old and has maybe 60 contributors makes one think. Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail@joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata@joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata@debian.org

On Sat, Mar 22, 2008 at 10:34:35AM -0700, Don Stewart wrote:

Patches to the core are expected to reach a higher standard of assurance than patches to the contrib modules. This is to ensure we retain the stability for the core feature set.

I would hope people agree that this policy has helped contribute to robustness and reliability of the core system over several releases now.

That's a good policy, unfortunately inconsistently enforced, which is what causes the trouble. see e.g. a patch which apparently went into core without review Thu Dec 27 00:03:56 PST 2007 Spencer Janssen * Broadcast button events to all layouts, fix for issue #111 which fixed no bugs (so far as anyone can tell) and introduced new bugs, but was never rolled back, because sjanssen felt that it was *morally* right, in spite of its causing regressions. David

On Sat, Mar 22, 2008 at 12:12:06PM -0700, Don Stewart wrote:

...

On Sat, Mar 22, 2008 at 10:34:35AM -0700, Don Stewart wrote:

...

Patches to the core are expected to reach a higher standard of assurance than patches to the contrib modules. This is to ensure we retain the stability for the core feature set.

I would hope people agree that this policy has helped contribute to robustness and reliability of the core system over several releases now.

That's a good policy, unfortunately inconsistently enforced, which is what causes the trouble. see e.g. a patch which apparently went into core without review

Thu Dec 27 00:03:56 PST 2007 Spencer Janssen * Broadcast button events to all layouts, fix for issue #111

which fixed no bugs (so far as anyone can tell) and introduced new bugs, but was never rolled back, because sjanssen felt that it was *morally* right, in spite of its causing regressions.

I'm more than happy to consider any patches that fix regressions, close bugs, or enable new features. Particularly if they come with risk/benefit summaries, tests, and are written to inspire confidence in the code.

If David and/or Joachim would like to collaborate to come up with a solution that satisifies all parties to #111, I'm happy to look at it!

See Andreas' patch from February 23 http://www.haskell.org/pipermail/xmonad/2008-February/004860.html the problem is already solved, it's just that noone looked at it. -- David Roundy Department of Physics Oregon State University