5 ms·

My biggest issue with i3 and awesome is as soon as I plug in a second monitor the whole things just falls apart and it becomes too much to manage. Anyone try t

My biggest issue with i3 and awesome is as soon as I plug in a second monitor the whole things just falls apart and it becomes too much to manage. Anyone try this with multiple monitors?

nobleach 6y ago
I've worked very hard to get my multi-monitor experience not to suck. In the end I landed on using this: https://github.com/lpicanco/i3-autodisplay https://github.com/lpicanco/i3-autodisplay This and a couple of scripts that run to change my audio output to HDMI when a plug event happens. I have to admit that I hate the "cobbled together" experience.
riquito 6y ago
What's the exact issue? If you assign a bunch of workspaces (say 6,7,8,9) to the secondary monitor when it appears your flow shouldn't really change
michaelmrose 6y ago
The way multiple monitors work out of the box is that a workspace is created when you first switch to it on the monitor that is focused. This means that even if you always use foo on monitor bar you must switch to monitor bar before hitting the hotkey to switch to foo. If all you know is focus directional hotkeys you could trivially have to hit focus left 7 times to get to the left monitor for example before hitting super+3 to switch to 3. This is of course horrible. Your life would be simplified if you had a hotkey to focus output right and focus output left. This makes it not TOO laborious however your life would be simplified MUCH MUCH more if you used the assign directive to assign particular workspaces to particular monitors for example 1-5 on left monitor and 6-0 on right. You would accomplish this for example by using workspace 1 output name workspace 2 output name ... Then if you watch to switch to 3 on left monitor you don't have to worry about where you are presently you can simply hit super+3 wherever you are.
Galanwe 6y ago
Been using i3 daily with 3 monitors and no problem (2 external screens + laptop) for 10 years now. What is your problem exactly? I usually reserve [0] for the laptop, [1], [2], [3] and [4] for my left monitor, and [5] on my right monitor.
Elv13 6y ago
(one of AwesomeWM maintainer here) This is a rather common issue for all OS, but even more annoying for tilling WMs since it messes up with the layouts. The good news is that a lot have been made to fix this in AwesomeWM git-master and more is coming. What's there: * If you set the `-- awesome_mode: api-level=5:screen=off` modeline at the top of `rc.lua`, all screens will be virtual rather than tied to a physical screen. In practice this means you can block and act upon physical screen removal. Previously, once the screen was gone, it was gone. Now you can either have full control or have the default handler * Screen swap: You can swap your primary screen back yo your laptop screen when disconnecting. So at least you don't lose everything. * Screen splitting: If you have a extra wide or double width monitor, you can split it in multiple virtual screens. This helps since it allows you to have the "main" virtual screen the same aspect ratio as the laptop screen. It means nothing moves when you switch back to the laptop mode. * Full signals and handlers for everything: By default it's still not perfect, but at least there is sane ways to plug your own logic everywhere in the screen removal and addition process. * Better mixed DPI: It is now easier to ignore the DPI X11 think it has and override it before the screen gets created. This way, you can ensure your laptop and main screen use something sane when in mirror/presentation mode. * Tags (workspaces) have a `request::screen` to "save" them when a screen is gone. So you can send them to a screen that still exists without losing the layout. What's coming: * There will be rules to apply can screen changes (https://elv13.github.io/declarative_rules/ruled.screen.html https://elv13.github.io/declarative_rules/ruled.screen.html). This will allow a declarative syntax to define the behavior on screen change. * The ability to have "sets of workspaces" you can share across screens (XMonad style). This is an interesting solution to the problem. Since the same "state" can be shared by more than 1 screen, then adding and removing a screen doesn't destroy the state. However this is really complex to bolt on the current design and I have been trying for like 2 years to make it perfect and backward compatible.

My biggest issue with i3 and awesome is as soon as I plug in a second monitor the whole things just falls apart and it becomes too much to manage. Anyone try this with multiple monitors?

nobleach 6y ago

I've worked very hard to get my multi-monitor experience not to suck. In the end I landed on using this: https://github.com/lpicanco/i3-autodisplay https://github.com/lpicanco/i3-autodisplay This and a couple of scripts that run to change my audio output to HDMI when a plug event happens. I have to admit that I hate the "cobbled together" experience.

riquito 6y ago

What's the exact issue? If you assign a bunch of workspaces (say 6,7,8,9) to the secondary monitor when it appears your flow shouldn't really change

michaelmrose 6y ago

The way multiple monitors work out of the box is that a workspace is created when you first switch to it on the monitor that is focused. This means that even if you always use foo on monitor bar you must switch to monitor bar before hitting the hotkey to switch to foo. If all you know is focus directional hotkeys you could trivially have to hit focus left 7 times to get to the left monitor for example before hitting super+3 to switch to 3. This is of course horrible. Your life would be simplified if you had a hotkey to focus output right and focus output left. This makes it not TOO laborious however your life would be simplified MUCH MUCH more if you used the assign directive to assign particular workspaces to particular monitors for example 1-5 on left monitor and 6-0 on right. You would accomplish this for example by using workspace 1 output name workspace 2 output name ... Then if you watch to switch to 3 on left monitor you don't have to worry about where you are presently you can simply hit super+3 wherever you are.

Galanwe 6y ago

Been using i3 daily with 3 monitors and no problem (2 external screens + laptop) for 10 years now. What is your problem exactly? I usually reserve [0] for the laptop, [1], [2], [3] and [4] for my left monitor, and [5] on my right monitor.

Elv13 6y ago

(one of AwesomeWM maintainer here) This is a rather common issue for all OS, but even more annoying for tilling WMs since it messes up with the layouts. The good news is that a lot have been made to fix this in AwesomeWM git-master and more is coming. What's there: * If you set the `-- awesome_mode: api-level=5:screen=off` modeline at the top of `rc.lua`, all screens will be virtual rather than tied to a physical screen. In practice this means you can block and act upon physical screen removal. Previously, once the screen was gone, it was gone. Now you can either have full control or have the default handler * Screen swap: You can swap your primary screen back yo your laptop screen when disconnecting. So at least you don't lose everything. * Screen splitting: If you have a extra wide or double width monitor, you can split it in multiple virtual screens. This helps since it allows you to have the "main" virtual screen the same aspect ratio as the laptop screen. It means nothing moves when you switch back to the laptop mode. * Full signals and handlers for everything: By default it's still not perfect, but at least there is sane ways to plug your own logic everywhere in the screen removal and addition process. * Better mixed DPI: It is now easier to ignore the DPI X11 think it has and override it before the screen gets created. This way, you can ensure your laptop and main screen use something sane when in mirror/presentation mode. * Tags (workspaces) have a `request::screen` to "save" them when a screen is gone. So you can send them to a screen that still exists without losing the layout. What's coming: * There will be rules to apply can screen changes (https://elv13.github.io/declarative_rules/ruled.screen.html https://elv13.github.io/declarative_rules/ruled.screen.html). This will allow a declarative syntax to define the behavior on screen change. * The ability to have "sets of workspaces" you can share across screens (XMonad style). This is an interesting solution to the problem. Since the same "state" can be shared by more than 1 screen, then adding and removing a screen doesn't destroy the state. However this is really complex to bolt on the current design and I have been trying for like 2 years to make it perfect and backward compatible.