Replies: 1 comment
-
I have something that may be of interest. After a decade of i3 I'm using Sway for the first time in another iteration of my config but that's incidental. My config helps me use a computer despite my having Parkinson's Disease, and in it are some of my wacky ideas as code to see whether they sink or swim in day to day use. https://github.com/EllaTheCat/dopamine-2024 When I visit a workspace I run a script defined in the table. It knows what app dominates that workspace, and how many instances minimum are supposed to be there, so when I visit a workspace it's ready with apps sitting there. With 100 workspaces I can have options according to workspace number. it's what you want but conceptually inside-out. Workspaces are the concept the user works with, apps are the means to an end. it's not where to put the app to do the job, it's which workspace does the job. I won't ramble on. There's code and plenty comments, take what you need. Feedback welocme. |
Beta Was this translation helpful? Give feedback.
-
Hi,
Context/Use Case:
I am trying to optimize my workflow and still struggle quite a bit with VS Code. I have usually multiple VS Code instances open with different code workspaces and also want to place them upon starting onto different i3 workspaces, so that e.g. I have my VS Code for the backend development on my main monitor, the VS Code instance for the Web UI on the left monitor and so on.
Current Solutions tested
So a simple solution like
assign [class="code"] $ws2
is not sufficient for meSo far I haven't been able to figure out how to achieve this in a convenient way (I should probably open a separate Q&A for that), since I haven't figured out how to differentiate between different VS Code instances (trying to find differences with
xprop
or getting ides from e.g. i3 Window Manager Tips and Tricks were not successful, I am currently thinking to tinker with something likexdotool search --name "Title of App" set_window --class "New WM Class"
but his is also probably not a feasible solution.The solution I use currently which works quite well most of the time is that I use
i3-msg
, e.g.bindsym b exec --no-startup-id i3-msg workspace $ws2; exec /usr/bin/code -n ~/data/code/backend/
bindsym f exec --no-startup-id i3-msg workspace $ws3; exec /usr/bin/code -n ~/data/code/frontend/
The only downside with this solution is that if I am to quick using the bindings or I chain it even in one binding, more than often it does not work out in case of e.g. a focus change or the application taking longer to start than the next
i3-msg
call which switches the workspace. This is not really a dealbreaker, but often very annoying and because it is not deterministic. So more often I find myself using the simple solution again and manually moving the instances to other workspaces.Idea
So finally my idea is that if it would be possible to do something like this
bindsym b exec --workspace=$ws2 /usr/bin/code -n ~/data/code/backend/
bindsym f exec ---workspace=$ws3 /usr/bin/code -n ~/data/code/frontend/
and it would be ensured that the application is opened in the correct workspace (even if parallel exec calls are made) this would allow for quite some easy and flexible solutions where assigning or moving is not possible easily.
It could also be made in a way that this way of executing overrides any normal assign/move rules, so an end user can have exceptions to any rules very easily.
Similar Ideas/ discussions
I read also #4556 which seems very similar and it was mentioned it is technically not possible, but I think my idea is slightly different, or maybe it sparks an idea in the reader how this kind of problem could be solved, even though there is a technical limitation.
BR,
Alex
Beta Was this translation helpful? Give feedback.
All reactions