From carstenmattner at gmail.com Tue Jul 1 14:08:40 2014 From: carstenmattner at gmail.com (Carsten Mattner) Date: Tue, 1 Jul 2014 16:08:40 +0200 Subject: [xmonad] Chromium floating required Message-ID: I tried current Chromium and Chrome to test some websites and found out that the new version requires for Chromium to be floating or else there's glitches and corrupted drawing. Anyone else seen this? From allbery.b at gmail.com Tue Jul 1 14:44:13 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Tue, 1 Jul 2014 10:44:13 -0400 Subject: [xmonad] Chromium floating required In-Reply-To: References: Message-ID: On Tue, Jul 1, 2014 at 10:08 AM, Carsten Mattner wrote: > I tried current Chromium and Chrome to test some websites and found out > that > the new version requires for Chromium to be floating or else there's > glitches and corrupted drawing. > > Anyone else seen this? > I'm not seeing this in the most recent Chrome on Fedora 19, but it's running in a VM. Are you using an NVidia driver in xorg, by any chance? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From zev at bewilderbeest.net Tue Jul 1 19:38:45 2014 From: zev at bewilderbeest.net (Zev Weiss) Date: Tue, 1 Jul 2014 14:38:45 -0500 Subject: [xmonad] Chromium floating required In-Reply-To: References: Message-ID: <74060E8C-9567-470A-A61D-8B84FC095F9D@bewilderbeest.net> On Jul 1, 2014, at 9:44 AM, Brandon Allbery wrote: > On Tue, Jul 1, 2014 at 10:08 AM, Carsten Mattner wrote: > I tried current Chromium and Chrome to test some websites and found out that > the new version requires for Chromium to be floating or else there's > glitches and corrupted drawing. > > Anyone else seen this? > > I'm not seeing this in the most recent Chrome on Fedora 19, but it's running in a VM. Are you using an NVidia driver in xorg, by any chance? > I saw similar misbehavior from Chromium on Debian Jessie on some recent releases -- I didn't think to associate it with xmonad though, and haven't tried floating its windows to see if it goes away. Frankly I just figured it was Chromium breakage and got so fed up with it (and various other bits of Chromium stupidity) that I've started mostly just using Firefox instead. (And no, no NVidia stuff on my system, just Haswell integrated graphics via i915.ko.) But of course now I can't reproduce it, so it may be that some minor Chromium update in the interim (now on 35.0.1916.153-2) has fixed it, or at least made it less egregious. Zev Weiss From carstenmattner at gmail.com Wed Jul 2 20:03:10 2014 From: carstenmattner at gmail.com (Carsten Mattner) Date: Wed, 2 Jul 2014 22:03:10 +0200 Subject: [xmonad] Chromium floating required In-Reply-To: <74060E8C-9567-470A-A61D-8B84FC095F9D@bewilderbeest.net> References: <74060E8C-9567-470A-A61D-8B84FC095F9D@bewilderbeest.net> Message-ID: On Tue, Jul 1, 2014 at 9:38 PM, Zev Weiss wrote: > > On Jul 1, 2014, at 9:44 AM, Brandon Allbery wrote: > >> On Tue, Jul 1, 2014 at 10:08 AM, Carsten Mattner wrote: >> I tried current Chromium and Chrome to test some websites and found out that >> the new version requires for Chromium to be floating or else there's >> glitches and corrupted drawing. >> >> Anyone else seen this? >> >> I'm not seeing this in the most recent Chrome on Fedora 19, but >> it's running in a VM. Are you using an NVidia driver in xorg, by >> any chance? >> > > I saw similar misbehavior from Chromium on Debian Jessie on some > recent releases -- I didn't think to associate it with xmonad > though, and haven't tried floating its windows to see if it goes > away. Frankly I just figured it was Chromium breakage and got so fed > up with it (and various other bits of Chromium stupidity) that I've > started mostly just using Firefox instead. (And no, no NVidia stuff > on my system, just Haswell integrated graphics via i915.ko.) > > But of course now I can't reproduce it, so it may be that some minor > Chromium update in the interim (now on 35.0.1916.153-2) has fixed > it, or at least made it less egregious. Only i915 here too and Chromium 38.0.2080.0 without floating rule doesn't glitch but redraws of window contents (html body) are very slow if I don't enable floating. This must be be all caused by the new Aura backend. Tried with floating reenabled and same window size as non-floating and there's no such visible redrawing you can watch happen. Good thing Chromium is not my main browser but in floating mode Aura doesn't fail as miserably. Someone with more Xlib experience may find out something interesting I guess. From mail at joachim-breitner.de Thu Jul 3 05:44:25 2014 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 03 Jul 2014 07:44:25 +0200 Subject: [xmonad] darcs patch: needs update for mplayer2 Message-ID: 1 patch for repository http://code.haskell.org/xmonad: Thu Jul 3 07:43:59 CEST 2014 Joey Hess * needs update for mplayer2 xmonad floats mplayer by default. However, Debian has switched to mplayer2, and so on upgrade, it will stop floating. This can be easily fixed in the user's config file, but here is a patch that avoids bothering the user with breakage on upgrade. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-preview.txt Type: text/x-darcs-patch Size: 719 bytes Desc: Patch preview URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: needs-update-for-mplayer2.dpatch Type: application/x-darcs-patch Size: 7229 bytes Desc: A darcs patch for your repository! URL: From carstenmattner at gmail.com Thu Jul 3 16:31:12 2014 From: carstenmattner at gmail.com (Carsten Mattner) Date: Thu, 3 Jul 2014 18:31:12 +0200 Subject: [xmonad] darcs patch: needs update for mplayer2 In-Reply-To: References: Message-ID: On Thu, Jul 3, 2014 at 7:44 AM, Joachim Breitner wrote: > 1 patch for repository http://code.haskell.org/xmonad: > > Thu Jul 3 07:43:59 CEST 2014 Joey Hess > * needs update for mplayer2 > > xmonad floats mplayer by default. However, Debian has switched to > mplayer2, and so on upgrade, it will stop floating. This can be easily > fixed in the user's config file, but here is a patch that avoids > bothering the user with breakage on upgrade. > > > [needs update for mplayer2 > Joey Hess **20140703054359 > Ignore-this: 9a17f371a79b5d656473dedfc4b85c85 > > xmonad floats mplayer by default. However, Debian has switched to > mplayer2, and so on upgrade, it will stop floating. This can be easily > fixed in the user's config file, but here is a patch that avoids > bothering the user with breakage on upgrade. > ] hunk ./src/XMonad/Config.hs 95 > manageHook :: ManageHook > manageHook = composeAll > [ className =? "MPlayer" --> doFloat > + , className =? "mplayer2" --> doFloat > , className =? "Gimp" --> doFloat ] I guess "mpv" should also be in there. From allbery.b at gmail.com Thu Jul 3 16:33:14 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 3 Jul 2014 12:33:14 -0400 Subject: [xmonad] darcs patch: needs update for mplayer2 In-Reply-To: References:

Message-ID: On Thu, Jul 3, 2014 at 12:31 PM, Carsten Mattner wrote: > On Thu, Jul 3, 2014 at 7:44 AM, Joachim Breitner > wrote: > > 1 patch for repository http://code.haskell.org/xmonad: > > > > Thu Jul 3 07:43:59 CEST 2014 Joey Hess > > * needs update for mplayer2 > > > > xmonad floats mplayer by default. However, Debian has switched to > > mplayer2, and so on upgrade, it will stop floating. This can be easily > > fixed in the user's config file, but here is a patch that avoids > > bothering the user with breakage on upgrade. > > I guess "mpv" should also be in there. > As long as we're cleaning that up, gimp should probably *not* be in there any more. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Fri Jul 4 22:58:39 2014 From: vogt.adam at gmail.com (adam vogt) Date: Fri, 4 Jul 2014 18:58:39 -0400 Subject: [xmonad] darcs patch: needs update for mplayer2 In-Reply-To: References:

Message-ID: Brandon, Joachim: The mplayer2 and gimp changes have been applied. Carsten: Mpv doesn't seem to be terribly popular according to popcon (), so I'm hesitant to add something that very few users will use. Regards, Adam On Thu, Jul 3, 2014 at 12:33 PM, Brandon Allbery wrote: > On Thu, Jul 3, 2014 at 12:31 PM, Carsten Mattner > wrote: >> >> On Thu, Jul 3, 2014 at 7:44 AM, Joachim Breitner >> wrote: >> > 1 patch for repository http://code.haskell.org/xmonad: >> > >> > Thu Jul 3 07:43:59 CEST 2014 Joey Hess >> > * needs update for mplayer2 >> > >> > xmonad floats mplayer by default. However, Debian has switched to >> > mplayer2, and so on upgrade, it will stop floating. This can be easily >> > fixed in the user's config file, but here is a patch that avoids >> > bothering the user with breakage on upgrade. >> >> I guess "mpv" should also be in there. > > > As long as we're cleaning that up, gimp should probably *not* be in there > any more. > > -- > brandon s allbery kf8nh sine nomine associates > allbery.b at gmail.com ballbery at sinenomine.net > unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://www.haskell.org/mailman/listinfo/xmonad > From allbery.b at gmail.com Mon Jul 7 02:52:43 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 6 Jul 2014 22:52:43 -0400 Subject: [xmonad] [Haskell-cafe] How to have a managed window unfocusable? In-Reply-To: References: Message-ID: On Sun, Jul 6, 2014 at 10:23 PM, Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > I'd like to have a transparent clock floating on my desktop. > > If I made it ignored (unmanaged), it would not be above and would be > blocked by other windows. > > If I made it managed and float, when I floated up and down, it would be > focused and I needed to press hotkey again to move focus to correct window. > > Anyway I could manage it, but not focusing on it? > This is difficult, because X11 expects that the way you do this is to unmanage it *and* that a window that is unmanaged knows how to manage itself. In particular, the X server may well send focus to a managed window *itself* via its window focus inheritance policy. The best xmonad could do would be to use a handleEventHook to detect the window being given focus (this might be rather difficult because focusIn and focusOut events are not currently delivered by the Haskell X11 bindings, sigh) and send focus elsewhere --- but in that case the window would still briefly receive focus. You probably need to find a clock program that knows how to operate as an unmanaged window. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Jul 7 03:17:24 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sun, 6 Jul 2014 23:17:24 -0400 Subject: [xmonad] [Haskell-cafe] How to have a managed window unfocusable? In-Reply-To: References:

Message-ID: On Sun, Jul 6, 2014 at 10:57 PM, Magicloud Magiclouds < magicloud.magiclouds at gmail.com> wrote: > Thank you for the explanation. I always thought "focus" was managed by WM. > Explicit focus is managed by the WM. But you don't explicitly choose a window to receive focus when the focused window goes away. The window manager is not invoked then, instead the server checks the focus inheritance policy *of the window that just closed*. And the default is to give focus to (the X server's idea of) the "previous window". It doesn't ask the window manager which that is, or ask the window manager to change the focused window; it determines that and assigns focus itself, and the window manager finds out about it from the subsequent FocusIn event. > Is "above" also controlled by X instead of WM? I tried to patch the code > of the clock to manage itself (keep itself topmost), but did not seem to > work. > Older programs do it themselves; modern programs tend to expect the window manager to do it based on EWMH hints, but xmonad does not implement the window layers part of the spec --- and it's not clear *how* to implement it in xmonad's model, as it runs into the same problems as Bug 4 (all the horrible problems with floating windows in xmonad's model). More or less, the way you'd have to do it is to call XRaiseWindow() regularly, possibly in response to any X11 event other than Expose (sending it on that event risks an infinite loop since the server will generate an Expose event if any part of your window was covered). (This kind of thing is why EWMH moved it into the window manager. Now if only we could do it right given how the StackSet works....) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From codesite-noreply at google.com Mon Jul 14 10:00:01 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Mon, 14 Jul 2014 10:00:01 +0000 Subject: [xmonad] Issue 531 in xmonad: Multiple workspaces with the same name confuses XMonad In-Reply-To: <2-3425899027203913298-3549037574840950913-codesite-noreply=google.com@googlecode.com> References: <2-3425899027203913298-3549037574840950913-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-3549037574840950913-codesite-noreply=google.com@googlecode.com> Message-ID: <3-3425899027203913298-3549037574840950913-codesite-noreply=google.com@googlecode.com> Comment #3 on issue 531 by killian.... at megasoft.be: Multiple workspaces with the same name confuses XMonad http://code.google.com/p/xmonad/issues/detail?id=531 Maybe related, not sure: But using renameWorkspace I named 2 workspaces the name. When the workspace was selected xmobar was showing "WorkSName WorkSName". I was unable to navigate to the second WorkSName. So I renamed this one using renameWorkspace to something else, that worked. However when I went back to WorkSName xmonad crashed: xmonad-x86_64-l[5507]: segfault at 40 ip 00007f140991aa23 sp 00007fff4d5f4908 error 4 in libX11.so.6.3.0[7f14098b7000+13c000] -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From codesite-noreply at google.com Mon Jul 14 14:33:07 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Mon, 14 Jul 2014 14:33:07 +0000 Subject: [xmonad] Issue 531 in xmonad: Multiple workspaces with the same name confuses XMonad In-Reply-To: <3-3425899027203913298-3549037574840950913-codesite-noreply=google.com@googlecode.com> References: <3-3425899027203913298-3549037574840950913-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-3549037574840950913-codesite-noreply=google.com@googlecode.com> Message-ID: <4-3425899027203913298-3549037574840950913-codesite-noreply=google.com@googlecode.com> Comment #4 on issue 531 by allber... at gmail.com: Multiple workspaces with the same name confuses XMonad http://code.google.com/p/xmonad/issues/detail?id=531 killian.de.volder at megasoft.be, any chance you can get a backtrace from that crash? (usually this indicates problems with the haskell X11 bindings) -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings From daniel at schoepe.org Sun Jul 20 13:42:53 2014 From: daniel at schoepe.org (Daniel Schoepe) Date: Sun, 20 Jul 2014 15:42:53 +0200 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <877g4cbrkp.fsf@gmail.com> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> Message-ID: <874myci1sy.fsf@schoepe.localhost> Hi, I think this is a nice idea, but maybe you should get the list of passwords from the directory specified by the environment variable $PASSWORD_STORE_DIR like pass does (falling back to ~/.password-store if it's empty). Another idea would be to run `pass ls' and try to remove the pretty-printing it adds; this would avoid duplicating what pass does for finding the password directory, but would require assuming that it will always pretty-print passwords in the same way. Sadly pass doesn't seem to provide a way to just list the names of the passwords without any additional formatting. Best regards, Daniel On Thu, 19.06.2014 21:57 +0200, ardumont wrote: > Hello, > > Here are the latest updates about this new XMonad.Prompt.Pass: > - More explicit prompt labels for each `password` prompt > - Improved documentation (more concise + add improved links rendering) > > Please, let me know if anything is wrong. > > > ardumont writes: > >> Hello, >> >> Here is an amended patch featuring: >> - typo fixes in header description (`helloWorld` instead of the right function `passPrompt`, >> missing XPConfig instance on the binding example -- thanks OODavo on #irc) >> - another prompt `passGeneratePrompt` to generate a password for a given >> entry (update already existing entry) >> - another prompt `passRemovePrompt` to remove a password for a given entry >> >> I forgot to explicit that all those prompts auto-complete on existing >> entries. >> >> Thanks for considering adding this. >> Any suggestions on improvments is more than welcome. >> >> Cheers, >> >> ardumont writes: >> >>> Hello, >>> >>> You will find enclosed a patch to propose a new XMonad.Prompt.Pass. >>> >>> From the header description documentation: >>> >>> -- Provides a shell prompt to lookup passwords in a password-storage (located on user's home @$HOME\/.password-store@). >>> -- The password storage used is . >>> -- >>> -- When one validates its input, the corresponding password is loaded >>> -- in the clipboard for a limited period of 45 seconds. >>> -- >>> -- Greatly inspired from >>> >>> I'm open to any suggestions on how to improve on this. >>> >>> Cheers, >>> -- >>> @ardumont >> >> >> -- >> @ardumont > > > -- > @ardumont > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://www.haskell.org/mailman/listinfo/xmonad From eniotna.t at gmail.com Tue Jul 22 15:36:52 2014 From: eniotna.t at gmail.com (ardumont) Date: Tue, 22 Jul 2014 17:36:52 +0200 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <874myci1sy.fsf@schoepe.localhost> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> Message-ID: <8738dtflrf.fsf@gmail.com> Hello, Daniel Schoepe writes: > Hi, > > I think this is a nice idea, Great! > but maybe you should get the list of > passwords from the directory specified by the environment variable > $PASSWORD_STORE_DIR like pass does (falling back to ~/.password-store if > it's empty). > Good idea, this way people can specify another storage folder if they want to. > Another idea would be to run `pass ls' and try to remove the > pretty-printing it adds; this would avoid duplicating what pass does for > finding the password directory, but would require assuming Yes, another idea which abstracts away again from where it is stored and avoid code duplication. > that it will always pretty-print passwords in the same way. At the moment, `man pass` specify `tree` program as the implementation. This one needs a little extra work because of the parsing output though. > Sadly pass > doesn't seem to provide a way to just list the names of the passwords > without any additional formatting. Indeed. I propose to improve the existing code with the first implementation suggestion as a first step. And then, if it is approved and merged, see what users say about it. What do you think? Best regards, > > Best regards, > Daniel > > On Thu, 19.06.2014 21:57 +0200, ardumont wrote: >> Hello, >> >> Here are the latest updates about this new XMonad.Prompt.Pass: >> - More explicit prompt labels for each `password` prompt >> - Improved documentation (more concise + add improved links rendering) >> >> Please, let me know if anything is wrong. >> >> >> ardumont writes: >> >>> Hello, >>> >>> Here is an amended patch featuring: >>> - typo fixes in header description (`helloWorld` instead of the right function `passPrompt`, >>> missing XPConfig instance on the binding example -- thanks OODavo on #irc) >>> - another prompt `passGeneratePrompt` to generate a password for a given >>> entry (update already existing entry) >>> - another prompt `passRemovePrompt` to remove a password for a given entry >>> >>> I forgot to explicit that all those prompts auto-complete on existing >>> entries. >>> >>> Thanks for considering adding this. >>> Any suggestions on improvments is more than welcome. >>> >>> Cheers, >>> >>> ardumont writes: >>> >>>> Hello, >>>> >>>> You will find enclosed a patch to propose a new XMonad.Prompt.Pass. >>>> >>>> From the header description documentation: >>>> >>>> -- Provides a shell prompt to lookup passwords in a password-storage (located on user's home @$HOME\/.password-store@). >>>> -- The password storage used is . >>>> -- >>>> -- When one validates its input, the corresponding password is loaded >>>> -- in the clipboard for a limited period of 45 seconds. >>>> -- >>>> -- Greatly inspired from >>>> >>>> I'm open to any suggestions on how to improve on this. >>>> >>>> Cheers, >>>> -- >>>> @ardumont >>> >>> >>> -- >>> @ardumont >> >> >> -- >> @ardumont >> _______________________________________________ >> xmonad mailing list >> xmonad at haskell.org >> http://www.haskell.org/mailman/listinfo/xmonad -- @ardumont From daniel at schoepe.org Tue Jul 22 22:25:31 2014 From: daniel at schoepe.org (Daniel Schoepe) Date: Wed, 23 Jul 2014 00:25:31 +0200 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <8738dtflrf.fsf@gmail.com> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> Message-ID: <87r41dghes.fsf@schoepe.localhost> Hi, On Tue, 22.07.2014 17:36 +0200, ardumont wrote: > I propose to improve the existing code with the first implementation suggestion as > a first step. > > And then, if it is approved and merged, see what users say about it. > What do you think? sounds good to me. Best regards, Daniel From eniotna.t at gmail.com Wed Jul 23 09:58:46 2014 From: eniotna.t at gmail.com (ardumont) Date: Wed, 23 Jul 2014 11:58:46 +0200 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <87r41dghes.fsf@schoepe.localhost> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> Message-ID: <871ttcflbd.fsf@gmail.com> Hello, So I updated the code according to our last exchange. Enclosed in this email, you will find the amended patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: xmonad-prompt-pass-3.dpatch Type: test/x-patch Size: 21910 bytes Desc: not available URL: -------------- next part -------------- The documentation has been updated as well: #+begin_src doc This module provides 3 XMonad.Prompt to ease passwords manipulation (generate, read, remove): one to lookup passwords in the password-storage. one to generate a password for a given password label that the user inputs. one to delete a stored password for a given password label that the user inputs. All those prompts benefit from the completion system provided by the module XMonad.Prompt. The password store is setuped through an environment variable PASSWORD_STORE_DIR. If this is set, use the content of the variable. Otherwise, the password store is located on user's home $HOME/.password-store. Source: The password storage implementation is the password-store cli. Inspired from http://babushk.in/posts/combining-xmonad-and-pass.html Synopsis #+end_src An insight about I tested this, I modified my xmonad.hs and reloaded xmonad: - without the environment variable. Pass does look into the `~/.password-store`. I have completion proposed on the prompt (my password store is stored there) - with the environment variable (in xmonad's main function, I added an ugly `System.Posix.setEnv "PASSWORD_STORE_DIR" "/home/tony" True`. I have no completion on the prompt because there is nothing there. Cheers, Daniel Schoepe writes: > Hi, > > On Tue, 22.07.2014 17:36 +0200, ardumont wrote: >> I propose to improve the existing code with the first implementation suggestion as >> a first step. >> >> And then, if it is approved and merged, see what users say about it. >> What do you think? > > sounds good to me. > > Best regards, > Daniel -- @ardumont