Paul Fertser | 30 Aug 17:22 2014
Picon

Re: darcs patch: Add Stoppable layout for power saving

Hi,

On Fri, Aug 29, 2014 at 06:41:14PM -0700, Anton Vorontsov wrote:
> +signalLocalWindow :: Signal -> Window -> X ()
> +signalLocalWindow s w  = do
> +    host <- io $ getEnvDefault "HOSTNAME" ""
> +    hasProperty (Machine host) w >>= flip when (signalWindow s w)

HOSTNAME is a bash-specific variable and it's not exported by default,
so neither XMonad nor ghci sees it (even though I actually use bash on
this machine):

Prelude System.Posix.Env> getEnv "HOSTNAME" 
Nothing

As the result, this version doesn't work as expected.

I've noticed another unpleasant side-effect of this: urxvtd is a
single process that can have many windows (each spawned with
urxvtc). So if the stoppable workspace has a urxvtd window, all the
other terminal windows get frozen too. Should an optional filtering
facility be added?

On an unrelated note, where do you get opportunities to apply your
Haskell skills?

--

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@...
(Continue reading)

Anton Vorontsov | 30 Aug 03:41 2014

darcs patch: Add Stoppable layout for power saving

Changes:

- Per Brandon Allbery's suggestion the module now checks
  WM_CLIENT_MACHINE, and thus no longer tries to stop remote clients.

- Per Paul Fertser's suggestion improved documentation, and also
  implemented a delay to make X11 clipboard limitations less noticeable.

1 patch for repository http://code.haskell.org/XMonadContrib:

Fri Aug 29 18:03:14 PDT 2014  Anton Vorontsov <anton <at> enomsg.org>
  * Add Stoppable layout for power saving

  This module implements a special kind of layout modifier, which when
  applied to a layout, causes xmonad to stop all non-visible processes. In a
  way, this is a sledge-hammer for applications that drain power. For
  example, given a web browser on a stoppable workspace, once the workspace
  is hidden the web browser will be stopped.

  Note that the stopped application won't be able to communicate with X11
  clipboard. For this, the module actually stops applications after a
  certain delay, giving a chance for a user to complete copy-paste sequence.
  By default, the delay equals to 15 seconds, it is configurable via
  'Stoppable' constructor.

  The stoppable modifier prepends a mark (by default equals to
  \"Stoppable\") to the layout description (alternatively, you can choose
  your own mark and use it with 'Stoppable' constructor). The stoppable
  layout (identified by a mark) spans to multiple workspaces, letting you to
  create groups of stoppable workspaces that only stop processes when none
(Continue reading)

Paul Fertser | 29 Aug 19:10 2014
Picon

Re: darcs patch: Add Stoppable layout for power saving

On Thu, Aug 28, 2014 at 01:12:31PM -0700, Anton Vorontsov wrote:
> On Thu, Aug 28, 2014 at 11:00:28PM +0400, Paul Fertser wrote:
> > Handy for the shit-sites that make firefox spin violently even when
> > it's not visible!
> 
> Exactly. :) Extends laptop on-battery time drastically.

This has an unpleasant side-effect though, I'm usually having firefox
(duh, should be using emacs-w3m more but it sucks in its own ways)
fullscreen and when I copy a link from it or just select some text,
and switch to a different workspace, the pasting from X selection
doesn't happen until I switch back to unfreeze the
shit-browser. That's less annoying than wasting cpu cycles but as a
known limitation should better be documented.

--

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@...
Paul Fertser | 28 Aug 21:00 2014
Picon

Re: darcs patch: Add Stoppable layout for power saving

Great idea, Anton!

Handy for the shit-sites that make firefox spin violently even when
it's not visible!

On Thu, Aug 28, 2014 at 06:07:24PM +0000, Anton Vorontsov wrote:
> +-- > main = xmonad def
> +-- >    { layoutHook = layoutHook def ||| stoppable (layoutHook def) }
> +--
> +-- For more detailed instructions on editing the logHook see:
> +--
> +-- "XMonad.Doc.Extending#The_log_hook_and_external_status_bars"

Why is that you're talking about modifying the logHook when tweaking
layoutHook, is this a typo?

--

-- 
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercerpav@...
Brandon Allbery | 28 Aug 20:14 2014
Picon

Re: darcs patch: Add Stoppable layout for power saving

On Thu, Aug 28, 2014 at 2:07 PM, Anton Vorontsov <anton-9xeibp6oKSgdnm+yROfE0A@public.gmane.org> wrote:
To stop the process we use signals, which works for most cases.

Please check WM_CLIENT_MACHINE so you don't try to kill a process not running on the same machine xmonad is (ssh forwarding, TCP X server connections, etc.)

--
brandon s allbery kf8nh                               sine nomine associates
unix, openafs, kerberos, infrastructure, xmonad        http://sinenomine.net
<div><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote">On Thu, Aug 28, 2014 at 2:07 PM, Anton Vorontsov <span dir="ltr">&lt;<a href="mailto:anton@..." target="_blank">anton@...</a>&gt;</span> wrote:<br><blockquote class="gmail_quote">To stop the process we use signals, which works for most cases.</blockquote>
</div>
<br>Please check WM_CLIENT_MACHINE so you don't try to kill a process not running on the same machine xmonad is (ssh forwarding, TCP X server connections, etc.)<br clear="all"><div><br></div>-- <br><div dir="ltr">
<div>brandon s allbery kf8nh &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; sine nomine associates</div>
<div>
<a href="mailto:allbery.b@..." target="_blank">allbery.b@...</a> &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;<a href="mailto:ballbery@..." target="_blank">ballbery@...</a>
</div>
<div>unix, openafs, kerberos, infrastructure, xmonad &nbsp; &nbsp; &nbsp; &nbsp;<a href="http://sinenomine.net" target="_blank">http://sinenomine.net</a>
</div>
</div>
</div></div></div>
Anton Vorontsov | 28 Aug 20:07 2014

darcs patch: Add Stoppable layout for power saving

It seems that my last email got silently eaten by spam filters. It's been
a whole day, so let's try it again with a different smtp...

1 patch for repository http://code.haskell.org/XMonadContrib:

Wed Aug 27 15:02:19 PDT 2014  Anton Vorontsov <anton <at> enomsg.org>
  * Add Stoppable layout for power saving

  This module implements a special kind of layout modifier, which when
  applied to a layout, causes xmonad to stop all non-visible processes. In a
  way, this is a sledge-hammer for applications that drain power. For
  example, given a web browser on a stoppable workspace, as soon as the
  workspace is hidden the web browser will be stopped.

  The stoppable modifier prepends a mark (by default equals to "Stoppable")
  to the layout description (alternatively, you can choose your own mark and
  use it with 'Stoppable' constructor). The stoppable layout (identified by
  a mark) spans to multiple workspaces, letting you to create groups of
  stoppable workspaces that only stop processes when none of the workspaces
  are visible, and conversely, unfreezing all processes even if one of the
  stoppable workspaces are visible.

  To stop the process we use signals, which works for most cases. For
  processes that tinker with signal handling (debuggers), another
  (Linux-centric) approach may be used. See
  https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt

Attachment (patch-preview.txt): text/x-darcs-patch, 5526 bytes
It seems that my last email got silently eaten by spam filters. It's been
a whole day, so let's try it again with a different smtp...

1 patch for repository http://code.haskell.org/XMonadContrib:

Wed Aug 27 15:02:19 PDT 2014  Anton Vorontsov <anton <at> enomsg.org>
  * Add Stoppable layout for power saving

  This module implements a special kind of layout modifier, which when
  applied to a layout, causes xmonad to stop all non-visible processes. In a
  way, this is a sledge-hammer for applications that drain power. For
  example, given a web browser on a stoppable workspace, as soon as the
  workspace is hidden the web browser will be stopped.

  The stoppable modifier prepends a mark (by default equals to "Stoppable")
  to the layout description (alternatively, you can choose your own mark and
  use it with 'Stoppable' constructor). The stoppable layout (identified by
  a mark) spans to multiple workspaces, letting you to create groups of
  stoppable workspaces that only stop processes when none of the workspaces
  are visible, and conversely, unfreezing all processes even if one of the
  stoppable workspaces are visible.

  To stop the process we use signals, which works for most cases. For
  processes that tinker with signal handling (debuggers), another
  (Linux-centric) approach may be used. See
  https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt

Chris Bell | 25 Aug 19:11 2014

Per-workspace Application Instances

Hi all,

I started using xmonad last week, and encountered very few problems
during configuration and use. It's nearly perfect for how I work. But
I've run into a bothersome issue.

There are times when I need to have dozens of PDFs readily available.
Since I started using xmonad, I switched to qpdfview for its tabbed
interface. Whenever I open a PDF from a file manager (xfe), qpdfview
is called with the --unique option, so that all new windows open as
tabs in the main window. The problem is that, if I want to then open a
PDF on a different workspace, I either need to create a new instance
of qpdfview, or use a different PDF viewer. A minor inconvenience, to
be sure. But then I realized that qpdfview has a --instance <name>
option, which I imagine could be used with xmonad's workspace
identifiers. So, any instance started in workspace 3 would be named
'd3', and qpdfview would be called with '--unique --instance d3'.

The problem is, I don't know where to start with this. My idea was to
use environment variables to identify the current workspace, but I'm
not sure how to. Any suggestions/ideas are greatly appreciated!

Regards,

Chris
Ruslan Kiianchuk | 17 Aug 02:06 2014
Picon

Dim unfocused windows

Hello.

So there is XMonad.Hooks.FadeWindows module that allows to make unfocused windows slightly transparent.

But is it possible to just dim unfocused windows without changing their opacity (the way fadeing option does this for URXVT?).

Thanks.

--
Sincerely, Ruslan Kiianchuk.
<div><div dir="ltr">
<div>
<div>Hello.<br><br>So there is <a href="http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-FadeWindows.html">XMonad.Hooks.FadeWindows</a> module that allows to make unfocused windows slightly transparent.<br><br>
</div>But is it possible to just dim unfocused windows without changing their opacity (the way <span>fadeing</span> option does this for URXVT?).<br><br>
</div>Thanks.<br clear="all"><div><div><div>
<br>-- <br><div>Sincerely, Ruslan Kiianchuk.</div>
</div></div></div>
</div></div>
Klaas van Schelven | 12 Aug 09:24 2014

Bug? garbage screen when switching virtual workspaces.

I suppose I should start with a rant on how XMonad sucks to get everyone's attention. However, truth is I've been enjoying xmonad for some c. 5 years now, without any problems whatsoever. However: 

I've recently upgraded my Ubuntu from 10.04 to 14.04.

Xmonad appeared to work after changing the syntax of dmenu_run and recompiling.
However, sometimes when switching workspaces, I end up with with some garbage window with the following properties:

* slightly offset to the bottom & right from the normal location (slightly means: a couple of pixels)
* the area usually contains the contents of the window that was displaying right before making the switch (but as I set, slightly offset to the right & bottom)
* usually the window is killable using my standard kill-key-combo.
* It appears (though I'm not sure) that google-chrome if often involved in this. One observed behavior: after killing the "ghost window" everything seemed to work fine again, except that chrome was gone. Tentative conclusion: the ghost window was in fact chrome.
* My "unfloat" modifier (Mod-T) doesn't change anything

When observing the above, I just run windows full screen and use various workspaces for the various windows.

* A behavior that appears related: in a few cases I did not manage to get rid of the ghost window. In those cases I got some kind of mosaic inside the full-screen chrome window, comprised of ca. 5 times 5 smaller, mirrored rectangles which contained part of chrome. I'll try to make a screenshot next time this happens.

I'm sorry if the problem description is somewhat vague, and/or if I'm not using the correct terminology.
As I said, I've set up XMonad years ago, and haven't changed a thing since so I'm somewhat lost for the right words at times (the correct terminology is in my fingers)
Any pointers to debugging this problem or requests for specifc configs/logs are welcome.


regards,
Klaas
<div><div dir="ltr">
<div>I suppose I should start with a rant on how XMonad sucks to get everyone's attention. However, truth is I've been enjoying xmonad for some c. 5 years now, without any problems whatsoever. However:&nbsp;</div>

<div><br></div>
<div>I've recently upgraded my Ubuntu from 10.04 to 14.04.</div>
<div><br></div>
<div>Xmonad appeared to work after changing the syntax of dmenu_run and recompiling.</div>
<div>However, sometimes when switching workspaces, I end up with with some garbage window with the following properties:</div>

<div><br></div>
<div>* slightly offset to the bottom &amp; right from the normal location (slightly means: a couple of pixels)</div>
<div>* the area usually contains the contents of the window that was displaying right before making the switch (but as I set, slightly offset to the right &amp; bottom)</div>

<div>* usually the window is killable using my standard kill-key-combo.</div>
<div>* It appears (though I'm not sure) that google-chrome if often involved in this. One observed behavior: after killing the "ghost window" everything seemed to work fine again, except that chrome was gone. Tentative conclusion: the ghost window was in fact chrome.</div>

<div>* My "unfloat" modifier (Mod-T) doesn't change anything</div>
<div><br></div>
<div>When observing the above, I just run windows full screen and use various workspaces for the various windows.</div>
<div><br></div>
<div>* A behavior that appears related: in a few cases I did not manage to get rid of the ghost window. In those cases I got some kind of mosaic inside the full-screen chrome window, comprised of ca. 5 times 5 smaller, mirrored rectangles which contained part of chrome. I'll try to make a screenshot next time this happens.</div>

<div><br></div>
<div>I'm sorry if the problem description is somewhat vague, and/or if I'm not using the correct terminology.</div>
<div>As I said, I've set up XMonad years ago, and haven't changed a thing since so I'm somewhat lost for the right words at times (the correct terminology is in my fingers)</div>

<div>Any pointers to debugging this problem or requests for specifc configs/logs are welcome.</div>
<div><br></div>
<br><div>regards,</div>
<div>Klaas</div>
</div></div>
codesite | 8 Aug 10:41 2014
Picon

Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes

Status: New
Owner: ----

New issue 576 by martin.s...@...: On FreeBSD Xmonad loses first  
hotkey sometimes
http://code.google.com/p/xmonad/issues/detail?id=576

What steps will reproduce the problem?

1. Install FreeBSD (amd64).
2. Write a minimal xmonad.hs with xterm binding.
3. Start xmonad in Xorg.
4. Try (multiple times) Mod+Shift+Return.

What is the expected output? What do you see instead?

It's expected that xterm opens with the first time Mod+Shift+Return is  
pressed. Sometimes Xmonad loses the key-combo and you need to press it  
twice in fast succession. If you wait too long between the first and the  
second time in sequence, the hotkey will be lost again and again.

I repeat once again: it happens SOMETIMES, but on average every 4th time.  
Try to open terminal and exit it again (Mod+Shift+Return -> Ctrl-D ->  
Mod+Shift+Return -> Ctrl-D -> ...).

What version of the product are you using? On what operating system?

hs-xmonad-0.11_7

FreeBSD 10.0 RELEASE (amd64).

Are you using an xmonad.hs?  Please attach it and the output of "xmonad
--recompile".

You don't need mine. Use a minimal one:

import XMonad

main = xmonad defaultConfig
         { modMask = mod1Mask
         , terminal = "xterm"
         }

Additional info:
Cannot be reproduced on Linux. Everything works as expected there.

--

-- 
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
codesite | 7 Aug 22:31 2014
Picon

Re: Issue 168 in xmonad: gnome-panel with autohide enabled appears behind main windows


Comment #10 on issue 168 by jhy...@...: gnome-panel with
autohide  
enabled appears behind main windows
http://code.google.com/p/xmonad/issues/detail?id=168

Any update on this?  I am thinking of switching to a tiling window manager.

--

-- 
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

Gmane