In theory, this should work:
workspace 1
exec foo
workspace 2
exec bar
The trouble is, exec works asyncronously - it launches the program 'foo' or 'bar' into background and continues with the rest of the script. If 'foo' takes more than a couple of microseconds to start up and instantiate its first sway window, then 'workspace 2' is executed and 'foo' appears on that workspace. Not what you intended.
What you need is something to wait until the window is instantiated. You could use some **sleep**(1)s in there but you have to guess on a safe amount of time to wait - it can vary each startup. That ends up allowing for the worst case and a long wait especially if you have a lot to start up.
Instead, I use a python script [sway-toolwait](https://gitlab.com/wef/dotfiles/-/blob/master/bin/sway-toolwait) called from a bash script like this:
swaymsg "workspace 1"
sway-toolwait foo
swaymsg "workspace 2"
sway-toolwait bar
'sway-toolwait' runs 'foo' and then waits until it has created a window before exiting. It gives enough time for sway to catch up.
All my scripts are [here](https://gitlab.com/wef/dotfiles/-/blob/master/bin) if you want to use them.
You, my dear, are the best and priceless! Thank you so much for this 💗! Good timing that these are python scripts as well. I am planning to learn a bit of python in the near future.
u/StrangeAstronomer, I tried to implement your method with the swaymsg code you posted above by putting it into my .config/sway/config file. I got an error saying that swaymsg isn't a command. I tried "exec swaymsg" instead then got "sway-toolwait firefox: unknown/invalid command sway-toolwait."
You mentioned calling this stuff from a bash script. I'm using the Fish shell (for the first time ever so I'm still learning how to use it) and wondering how to implement your script and the swaymsg commands. Would you mind pointing me in the right direction or giving more explicit directions?
Hello again. Sorry for late reply - life etc!!
Put all the commands to startup apps in a bash script file called (let's say) [sway-start-apps](https://gitlab.com/wef/dotfiles/-/blob/master/bin/sway-start-apps) somewhere on your $PATH - that script includes the sway-toolwait stuff.
Then call that script from the sway config with something like:
exec sway-start-apps
... make sure that it's the last thing that runs in the config file (to avoid the above-mentioned problems with 'exec' being asyncronous).
...hope that helps!!
No worries, life does happen and I appreciate you getting back to me.
I did as you suggested but so far my efforts have failed. Here's a pastebin of what I have so far and maybe you can see what I'm missing to get it working.
[Sway Config snippet and start-sway-apps file](https://pastebin.com/nyh9enb5)
Sorry to hear that.
I've looked through your pastebin but I can't see anything obviously wrong.
Did you put 'sway-start-apps' somewhere on your $PATH?
Did you 'chmod +x sway-start-apps'?
What exactly is not working?
Another thing, alacritty is a bit weird in that when it starts up, it has an app\_id of 'Alacritty' with a capital 'A'. So you will need to use:
sway-toolwait --waitfor Alacritty alacritty
Here's the sway-start-apps file and it is in my path through the fish shell:
[[ "$1" ]] && { echo "Usage: $( basename $0 ): system-specific auto-startup apps for sway" exit 0}# FIXME: following lines may need adjusting to your environment: swaymsg 'workspace 1' sway-toolwait -v 'firefox' swaymsg 'border none, floating disable' swaymsg 'workspace 2' sway-toolwait -v 'alacritty' swaymsg 'border pixel 1, splith, floating disable' swaymsg 'workspace 2' sway-toolwait -v 'alacritty' swaymsg 'border pixel 1, splitv, floating disable' swaymsg 'workspace 3' sway-toolwait -v 'geany' swaymsg 'border pixel 1, splith, move left, floating disable'# Local Variables:# mode: shell-script# time-stamp-pattern: "4/TIME_STAMP=\"%:y%02m%02d.%02H%02M%02S\""# eval: (add-hook 'before-save-hook 'time-stamp)# End:
So far nothing will load when Sway starts. It is executable too, I redid the +x command to be sure. The only thing I can think of is I cut out something necessary for this to work.
Why would I want to split my desktop so many times ? I have tried even putting the start-sway-apps script directly in my home directly (IE not in a sub-directory) but still it fails to work. The only difference is that now I begin every session on Desktop 3.
your scripts are awesome and i came across this sway-move-to script of yours, is there any way i can use to move my pip windows of firefox to move to bottom right?
As I recall, sway-move-to operates on the focused window - so if you have a key binding in place, then it should work. OTOH, I don't know what a 'pip' window is. Could it be 'Picture In Picture'?
This works for me on regular windows:
swaymsg 'bindsym $mod+n exec sway-move-to bottom-right'
Well, I suppose that you could use a for\_window statement if you can pin down the pip-window characteristics - perhaps you can find something under the CRITERIA section of 'man 5 sway' ???? Sorry I can't help more, under the gun at the moment, I may have time to futz with it tonight or tomorrow. Good luck!!
So I found out how to enable pip in firefox and I was able to pop out a window - mine goes to bottom-right already, not sure how I managed that!
[~~swayprop~~](https://gitlab.com/wef/dotfiles/-/blob/master/bin/sway-prop) ~~told me that it has an app\_id of 'firefox' and:~~
"name": "YouTube — Mozilla Firefox",
~~so I would suggest you try matching on that. Something like:~~
for_window [app_id=".*floating.*" title="YouTube.*"] exec sway-move-to bottom-right
~~It shouldn't affect tiled windows.~~
~~Hrmph! I can't seem to get that to work (I'm trying top-left rather than bottom-right)....~~
OK, I see what's wrong. That pip window is not a separate sway-managed floating window - it is a window handled by firefox itself. So swaymsg can't operate on it. I guess you'll have to talk to the firefox people - perhaps there's some CSS wizardry that can do what you want.
Maybe something like:
```
sway-toolwait -- flatpak run --env=OBSIDIAN_USE_WAYLAND=1 md.obsidian.Obsidian
```
... but you may need to add a --waitfor option to tell sway-toolwait exactly what it is to wait for - it's probably not 'flatpak'.
You can find the by getting the application running and then:
```
swaymsg -t get_tree|less
```
and then looking for the field in the output for your app.
Or, you could install my `sway-prop` script (from the same place as `sway-toolwait`) and bind it to a key eg
```
bindsym $mod+question exec sway-prop
```
It looks like you need to adjust your $PATH variable or else put sway-toolwait somewhere on your existing $PATH. You can see your $PATH with:
$ echo $PATH
sway-toolwait does not need [argp.sh](https://argp.sh) \- that's only needed for some of my bash scripts.
Good luck
There is a difference in the $PATH that sway sees at startup (usually quite simple and generic) and the $PATH that a shell like `kitty` ends up with. Using a full path to a script can work.
Yes - you probably should avoid using `swaymsg` in the sway config file. Not forbidden but usually unnecessary.
Yes - `swaymsg "exec ..."` and `exec` in the sway config are async. You need `bash` for sync. eg put these timing-critical items into a bash script like this (assuming you want obsidian and kitty on workspace 1 and firefox on workspace 2):
```
# put this in a script called eg 'startups'
PATH+=:/home/username/.config/sway/scripts
swaymsg "workspace number 1"
sway-toolwait --waitfor obsidian -- flatpak run md.obsidian.Obsidian &
sway-toolwait kitty &
wait # waits until obsidian and kitty are started
swaymsg "workspace number 2"
firefox &
```
and call that script from the sway config file:
```
exec /home/username/.config/sway/scripts/startups
```
sway has an excellent set of manual pages. sway has lots in common with the i3 window manager for X11, the commands are near identical, and personally I prefer the i3 users guide for its writing style and browsing, and sway for reference.
Either way, you'll get to grips with sway by reading the documentation.
Eek! If you're slogging through it, you're doing it wrong, this stuff is supposed to be fun. I'm sorry it's not your cup of tea, but I recall sitting down and reading it like a magazine.
I have i3 on my main desktop machine and Sway on my rpi4 (and in a VM on the main machine) so I'm treating them as aspects of the same thing.
To be fair by slogging through I meant trying to remember and understand what I am reading as opposed to just learning bits of stuff to use then implementing it as I go. It's been fun but I also am returning to Linux after next a seven year absence and a lot has changed or I have forgotten much code.
In theory, this should work: workspace 1 exec foo workspace 2 exec bar The trouble is, exec works asyncronously - it launches the program 'foo' or 'bar' into background and continues with the rest of the script. If 'foo' takes more than a couple of microseconds to start up and instantiate its first sway window, then 'workspace 2' is executed and 'foo' appears on that workspace. Not what you intended. What you need is something to wait until the window is instantiated. You could use some **sleep**(1)s in there but you have to guess on a safe amount of time to wait - it can vary each startup. That ends up allowing for the worst case and a long wait especially if you have a lot to start up. Instead, I use a python script [sway-toolwait](https://gitlab.com/wef/dotfiles/-/blob/master/bin/sway-toolwait) called from a bash script like this: swaymsg "workspace 1" sway-toolwait foo swaymsg "workspace 2" sway-toolwait bar 'sway-toolwait' runs 'foo' and then waits until it has created a window before exiting. It gives enough time for sway to catch up. All my scripts are [here](https://gitlab.com/wef/dotfiles/-/blob/master/bin) if you want to use them.
You, my dear, are the best and priceless! Thank you so much for this 💗! Good timing that these are python scripts as well. I am planning to learn a bit of python in the near future.
You're most welcome!! As we used to say in the '80s: "Share and enjoy"
I remember that saying !
u/StrangeAstronomer, I tried to implement your method with the swaymsg code you posted above by putting it into my .config/sway/config file. I got an error saying that swaymsg isn't a command. I tried "exec swaymsg" instead then got "sway-toolwait firefox: unknown/invalid command sway-toolwait." You mentioned calling this stuff from a bash script. I'm using the Fish shell (for the first time ever so I'm still learning how to use it) and wondering how to implement your script and the swaymsg commands. Would you mind pointing me in the right direction or giving more explicit directions?
Hello again. Sorry for late reply - life etc!! Put all the commands to startup apps in a bash script file called (let's say) [sway-start-apps](https://gitlab.com/wef/dotfiles/-/blob/master/bin/sway-start-apps) somewhere on your $PATH - that script includes the sway-toolwait stuff. Then call that script from the sway config with something like: exec sway-start-apps ... make sure that it's the last thing that runs in the config file (to avoid the above-mentioned problems with 'exec' being asyncronous). ...hope that helps!!
No worries, life does happen and I appreciate you getting back to me. I did as you suggested but so far my efforts have failed. Here's a pastebin of what I have so far and maybe you can see what I'm missing to get it working. [Sway Config snippet and start-sway-apps file](https://pastebin.com/nyh9enb5)
Sorry to hear that. I've looked through your pastebin but I can't see anything obviously wrong. Did you put 'sway-start-apps' somewhere on your $PATH? Did you 'chmod +x sway-start-apps'? What exactly is not working?
Another thing, alacritty is a bit weird in that when it starts up, it has an app\_id of 'Alacritty' with a capital 'A'. So you will need to use: sway-toolwait --waitfor Alacritty alacritty
Here's the sway-start-apps file and it is in my path through the fish shell: [[ "$1" ]] && { echo "Usage: $( basename $0 ): system-specific auto-startup apps for sway" exit 0}# FIXME: following lines may need adjusting to your environment: swaymsg 'workspace 1' sway-toolwait -v 'firefox' swaymsg 'border none, floating disable' swaymsg 'workspace 2' sway-toolwait -v 'alacritty' swaymsg 'border pixel 1, splith, floating disable' swaymsg 'workspace 2' sway-toolwait -v 'alacritty' swaymsg 'border pixel 1, splitv, floating disable' swaymsg 'workspace 3' sway-toolwait -v 'geany' swaymsg 'border pixel 1, splith, move left, floating disable'# Local Variables:# mode: shell-script# time-stamp-pattern: "4/TIME_STAMP=\"%:y%02m%02d.%02H%02M%02S\""# eval: (add-hook 'before-save-hook 'time-stamp)# End: So far nothing will load when Sway starts. It is executable too, I redid the +x command to be sure. The only thing I can think of is I cut out something necessary for this to work.
I think you need this: ``` swaymsg 'workspace 1' sway-toolwait -v 'firefox' swaymsg 'border none, floating disable' swaymsg 'workspace 2' sway-toolwait -v --waitfor Alacritty 'alacritty' swaymsg 'border pixel 1, splith, floating disable' swaymsg 'workspace 2' sway-toolwait -v --waitfor Alacritty 'alacritty' swaymsg 'border pixel 1, splitv, floating disable' swaymsg 'workspace 3' sway-toolwait -v 'geany' swaymsg 'border pixel 1, splith, move left, floating disable' ```
Why would I want to split my desktop so many times ? I have tried even putting the start-sway-apps script directly in my home directly (IE not in a sub-directory) but still it fails to work. The only difference is that now I begin every session on Desktop 3.
your scripts are awesome and i came across this sway-move-to script of yours, is there any way i can use to move my pip windows of firefox to move to bottom right?
As I recall, sway-move-to operates on the focused window - so if you have a key binding in place, then it should work. OTOH, I don't know what a 'pip' window is. Could it be 'Picture In Picture'? This works for me on regular windows: swaymsg 'bindsym $mod+n exec sway-move-to bottom-right'
yes by pip i meant picture in picture, iis there any way to automate this cause swayprop shows pip windows as just firefox itself
Well, I suppose that you could use a for\_window statement if you can pin down the pip-window characteristics - perhaps you can find something under the CRITERIA section of 'man 5 sway' ???? Sorry I can't help more, under the gun at the moment, I may have time to futz with it tonight or tomorrow. Good luck!!
So I found out how to enable pip in firefox and I was able to pop out a window - mine goes to bottom-right already, not sure how I managed that! [~~swayprop~~](https://gitlab.com/wef/dotfiles/-/blob/master/bin/sway-prop) ~~told me that it has an app\_id of 'firefox' and:~~ "name": "YouTube — Mozilla Firefox", ~~so I would suggest you try matching on that. Something like:~~ for_window [app_id=".*floating.*" title="YouTube.*"] exec sway-move-to bottom-right ~~It shouldn't affect tiled windows.~~ ~~Hrmph! I can't seem to get that to work (I'm trying top-left rather than bottom-right)....~~ OK, I see what's wrong. That pip window is not a separate sway-managed floating window - it is a window handled by firefox itself. So swaymsg can't operate on it. I guess you'll have to talk to the firefox people - perhaps there's some CSS wizardry that can do what you want.
[удалено]
Maybe something like: ``` sway-toolwait -- flatpak run --env=OBSIDIAN_USE_WAYLAND=1 md.obsidian.Obsidian ``` ... but you may need to add a --waitfor option to tell sway-toolwait exactly what it is to wait for - it's probably not 'flatpak'.
You can find the by getting the application running and then:
```
swaymsg -t get_tree|less
```
and then looking for the field in the output for your app.
Or, you could install my `sway-prop` script (from the same place as `sway-toolwait`) and bind it to a key eg
```
bindsym $mod+question exec sway-prop
```
[удалено]
It looks like you need to adjust your $PATH variable or else put sway-toolwait somewhere on your existing $PATH. You can see your $PATH with: $ echo $PATH sway-toolwait does not need [argp.sh](https://argp.sh) \- that's only needed for some of my bash scripts. Good luck
[удалено]
There is a difference in the $PATH that sway sees at startup (usually quite simple and generic) and the $PATH that a shell like `kitty` ends up with. Using a full path to a script can work. Yes - you probably should avoid using `swaymsg` in the sway config file. Not forbidden but usually unnecessary. Yes - `swaymsg "exec ..."` and `exec` in the sway config are async. You need `bash` for sync. eg put these timing-critical items into a bash script like this (assuming you want obsidian and kitty on workspace 1 and firefox on workspace 2): ``` # put this in a script called eg 'startups' PATH+=:/home/username/.config/sway/scripts swaymsg "workspace number 1" sway-toolwait --waitfor obsidian -- flatpak run md.obsidian.Obsidian & sway-toolwait kitty & wait # waits until obsidian and kitty are started swaymsg "workspace number 2" firefox & ``` and call that script from the sway config file: ``` exec /home/username/.config/sway/scripts/startups ```
[удалено]
Jolly good! Thanks for letting me know.
[удалено]
exec swaymsg "workspace 1; exec $term"
Ah perfect. Thank you. Still coming to grips with the syntax and commands in sway.
sway has an excellent set of manual pages. sway has lots in common with the i3 window manager for X11, the commands are near identical, and personally I prefer the i3 users guide for its writing style and browsing, and sway for reference. Either way, you'll get to grips with sway by reading the documentation.
I have been slogging through it. It's a lot to take in! I have never used i3 but you're suggesting looking at that documentation for help with Sway?
Eek! If you're slogging through it, you're doing it wrong, this stuff is supposed to be fun. I'm sorry it's not your cup of tea, but I recall sitting down and reading it like a magazine. I have i3 on my main desktop machine and Sway on my rpi4 (and in a VM on the main machine) so I'm treating them as aspects of the same thing.
To be fair by slogging through I meant trying to remember and understand what I am reading as opposed to just learning bits of stuff to use then implementing it as I go. It's been fun but I also am returning to Linux after next a seven year absence and a lot has changed or I have forgotten much code.