Miroirs/guile-swayer
1
0
Fork 0
mirror of https://github.com/ebeem/guile-swayer.git synced 2024-12-26 21:59:03 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions

add more information about workspace groups module in readme

Browse source
This commit is contained in:
Almarhoon Ibraheem 2024-06-19 17:24:01 +03:00
parent f8c156e734
commit 88b8acd1f1
2 changed files with 36 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

40
README.org
View file

@ -59,8 +59,8 @@ You can assign keybindings that execute Guile code! Obviously, running shell com
;; it also allows you to execute guile expressions on trigger.
;; requires configuring commander-path, refer to the FIXME note in keybindings.scm for more details.
;; refer to modules/general.scm for more about how this is done.
;; define leader keymap
;; define leader keymap
(define (exec command)
"execute given shell command"
(format #t "running: ~a\n" command)
@ -110,7 +110,7 @@ Certain scenarios necessitate subscribing to events. One example from my =workfl
(add-hook! sway-workspace-hook workspace-changed)
#+end_src
Note: To receive any events, you must subscribe to them. You can subscribe to individual events that interest you or to all avilable events. Without subscribing and running the event listener in your =init.scm=, your hooks will not receive any events.
Note: To receive any events, you must subscribe to them. You can subscribe to individual events that interest you or to all available events. Without subscribing and running the event listener in your =init.scm=, your hooks will not receive any events.
The event listener thread is a Unix socket that waits for sway events. This must be executed, preferably as the last expression in your =init.scm= file, because =thread-join= will block execution. This blocking is necessary to keep the listener active and prevent the script from exiting.
@ -131,6 +131,7 @@ Clone this repository to your =~/.config/sway=
*** Project Structure
|------------------------------+-----------------------------------------------------------------------------------------------------------|
| File | Description |
|------------------------------+-----------------------------------------------------------------------------------------------------------|
| init.scm | Main entry point for configuring Sway using Guile. |
@ -154,13 +155,17 @@ Clone this repository to your =~/.config/sway=
| swayipc/events | Provides =Gulie Hooks= for all available =Sway= events. |
| swayipc/info | Provides =Guile functions= for querying Sway's current state and information. |
| swayipc/records | Provides =Guile records= representing Sway's data structures. |
|------------------------------+-----------------------------------------------------------------------------------------------------------|
1- You can start your =swayipc= configurations from the =REPL=, =terminal=, or a configuration file.
Remember: for debugging or displaying output, it's best to run Guile from the REPL or terminal. You can also pipe the output to a file if you desire.
1- You can start your =swayipc= configurations from the =REPL=, =terminal=, or a =configuration file=.
Remember: for debugging or displaying output, it's best to run Guile from the =REPL= or =terminal=. You can also pipe the output to a file if you desire.
#+begin_src conf
# from sway config file
exec_always "~/.config/sway/init.scm"
# good idea to kill all current guile swayipc instances first
exec_always "pkill -f '.*guile.*sway/init.scm'"
# then run a fresh instance, sleeping ensures a more reilable execution
exec_always "sleep 0.5 && ~/.config/sway/init.scm"
#+end_src
2- I plan to publish a module for =swayipc=, it's currently not hosted anywhere. You'll need to add the module to your =load path=. Additionally, =swayipc= includes another patched Guile library called =guile-json=, which is embedded for now. In the future, this will be included as a separate dependency rather than embedded.
@ -211,4 +216,27 @@ My workspaces function as groups or tasks that span across all three monitors in
Similarly, this setup extends to projects I work on. If I focus on my dotfiles, I want all monitors to switch to the workspace dedicated to that task. The same principle applies to game development or any other specific task or project workspace I engage with.
Normal workspaces
#+begin_src
| ws#1 | ws#2 | ws#3 | ws#4 | ws#5 | ws#6 |
#+end_src
Grouped workspaces (3 monitors)
#+begin_src
| ws#1 | ws#2 |
|-----------------------------------------------------|
| ws#1-1 & ws#1-2 & ws#1-3 | ws#2-1 & ws#2-2 & ws#2-3 |
#+end_src
Example of navigation into a workspace (same behavior regardless of the method used to switch workspaces):
#+begin_src
ws#1> go to ws#2-1
ws#2> go to ws#2-2 (same group, no switching)
ws#2> go to ws#1-3
ws#1> ..
#+end_src
You can partially configure workspace groups to span or sync only some workspaces. This allows you to have workspaces that do not span and others that do, with the ability to pin specific workspaces to their monitors when focused.
Note: this behavior is achieved via =modules/workspace-groups.scm=