Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

spawnOnce does not run after re-login #155

Closed
favonia opened this issue Mar 8, 2017 · 1 comment
Closed

spawnOnce does not run after re-login #155

favonia opened this issue Mar 8, 2017 · 1 comment

Comments

@favonia
Copy link

favonia commented Mar 8, 2017

Problem Description

spawnOnce will not run the command after logout and login. It seems the records inserted by spawnOnce stay in xmonad.state forever. I am using xmonad-contrib version 0.13.

Configuration File

module Main where

import XMonad
import XMonad.Util.SpawnOnce

main :: IO ()
main = xmonad def { startupHook = spawnOnce "firefox" }
@pjones
Copy link
Contributor

pjones commented Mar 14, 2017

This is a bug caused by xmonad/xmonad#86

Thank you for reporting. I'm going to close this as a duplicate.

@pjones pjones closed this as completed Mar 14, 2017
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Jan 2, 2020
@depressed-pho
Update to xmonad-0.14
eafde22 
0.14 (July 30, 2018)
Bug Fixes
* The state file that xmonad uses while restarting itself is now
  removed after it is processed. This fixes a bug that manifested in
  several different ways:
  * Names of old workspaces would be resurrected after a restart
  * Screen sizes would be wrong after changing monitor configuration
    (#90)
  * spawnOnce stopped working (xmonad/xmonad-contrib#155)
  * Focus did not follow when moving between workspaces (#87)
  * etc.
* Recover old behavior (in 0.12) when focusFollowsMouse == True: the
  focus follows when the mouse enters another workspace but not moving
  into any window.
* Compiles with GHC 8.4.1
* Restored compatability with GHC version prior to 8.0.1 by removing
  the dependency on directory version 1.2.3.

0.13 (February 10, 2017)
Breaking Changes
* When restarting xmonad, resume state is no longer passed to the next
  process via the command line. Instead, a temporary state file is
  created and xmonad's state is serialized to that file.
* When upgrading to 0.13 from a previous version, the --resume command
  line option will automatically migrate to a state file.
* This fixes issue #12.

Enhancements
* You can now control which directory xmonad uses for finding your
  configuration file and which one is used for storing the compiled
  version of your configuration. In order of preference:
  * New environment variables. If you want to use these ensure you set
    the correct environment variable and also create the directory it
    references:
    * XMONAD_CONFIG_DIR
    * XMONAD_CACHE_DIR
    * XMONAD_DATA_DIR
  * The ~/.xmonad directory.
  * XDG Base Directory Specification directories, if they exist:
    * XDG_CONFIG_HOME/xmonad
    * XDG_CACHE_HOME/xmonad
    * XDG_DATA_HOME/xmonad
* If none of these directories exist then one will be created using
  the following logic: If the relevant environment variable mentioned
  in step (1) above is set, the referent directory will be created and
  used. Otherwise ~/.xmonad will be created and used.
* This fixes a few issues, notably #7 and #56.
* A custom build script can be used when xmonad is given the
  --recompile command line option. If an executable named build exists
  in the xmonad configuration directory it will be called instead of
  ghc. It takes one argument, the name of the executable binary it
  must produce.
* This fixes #8. (One of two possible custom build solutions. See the
  next entry for another solution.)
* For users who build their xmonad configuration using tools such as
  cabal or stack, there is another option for executing xmonad.
* Instead of running the xmonad executable directly, arrange to have
  your login manager run your configuration binary instead. Then, in
  your binary, use the new launch command instead of xmonad.
* This will keep xmonad from using its configuration file
  checking/compiling code and directly start the window manager
  without execing any other binary.
* See the documentation for the launch function in XMonad.Main for
  more details.
* Fixes #8. (Second way to have a custom build environment for
  XMonad. See previous entry for another solution.)
netbsd-srcmastr pushed a commit to NetBSD/pkgsrc that referenced this issue Jan 14, 2020
@depressed-pho
Update to xmonad-0.14
736eb80 
0.14 (July 30, 2018)
Bug Fixes
* The state file that xmonad uses while restarting itself is now
  removed after it is processed. This fixes a bug that manifested in
  several different ways:
  * Names of old workspaces would be resurrected after a restart
  * Screen sizes would be wrong after changing monitor configuration
    (#90)
  * spawnOnce stopped working (xmonad/xmonad-contrib#155)
  * Focus did not follow when moving between workspaces (#87)
  * etc.
* Recover old behavior (in 0.12) when focusFollowsMouse == True: the
  focus follows when the mouse enters another workspace but not moving
  into any window.
* Compiles with GHC 8.4.1
* Restored compatability with GHC version prior to 8.0.1 by removing
  the dependency on directory version 1.2.3.

0.13 (February 10, 2017)
Breaking Changes
* When restarting xmonad, resume state is no longer passed to the next
  process via the command line. Instead, a temporary state file is
  created and xmonad's state is serialized to that file.
* When upgrading to 0.13 from a previous version, the --resume command
  line option will automatically migrate to a state file.
* This fixes issue #12.

Enhancements
* You can now control which directory xmonad uses for finding your
  configuration file and which one is used for storing the compiled
  version of your configuration. In order of preference:
  * New environment variables. If you want to use these ensure you set
    the correct environment variable and also create the directory it
    references:
    * XMONAD_CONFIG_DIR
    * XMONAD_CACHE_DIR
    * XMONAD_DATA_DIR
  * The ~/.xmonad directory.
  * XDG Base Directory Specification directories, if they exist:
    * XDG_CONFIG_HOME/xmonad
    * XDG_CACHE_HOME/xmonad
    * XDG_DATA_HOME/xmonad
* If none of these directories exist then one will be created using
  the following logic: If the relevant environment variable mentioned
  in step (1) above is set, the referent directory will be created and
  used. Otherwise ~/.xmonad will be created and used.
* This fixes a few issues, notably #7 and #56.
* A custom build script can be used when xmonad is given the
  --recompile command line option. If an executable named build exists
  in the xmonad configuration directory it will be called instead of
  ghc. It takes one argument, the name of the executable binary it
  must produce.
* This fixes #8. (One of two possible custom build solutions. See the
  next entry for another solution.)
* For users who build their xmonad configuration using tools such as
  cabal or stack, there is another option for executing xmonad.
* Instead of running the xmonad executable directly, arrange to have
  your login manager run your configuration binary instead. Then, in
  your binary, use the new launch command instead of xmonad.
* This will keep xmonad from using its configuration file
  checking/compiling code and directly start the window manager
  without execing any other binary.
* See the documentation for the launch function in XMonad.Main for
  more details.
* Fixes #8. (Second way to have a custom build environment for
  XMonad. See previous entry for another solution.)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@pjones @favonia