Vision on multi-monitor display/selection

[felixfung]

I think for quite a while multi-monitor has been a weakness for skippy-xd. I have not worked on it too much. Most code/feature was long existing.

Needless to say, multi-monitor window management/workflow is very important for anyone who has more than one monitor.

I happen to have access to only one monitor.

I do have a TV, which I can occasionally connect to, to work on multi-monitor code.

So, help in testing is definitely needed. If anyone can help with code, even better.

I think the vision for window selection is pretty straightforward.

1. It should work with minimal configuration. When there is ambiguity/multiple possibilities, there should be options on config file, or command line parameter
2. Two options:

• All windows stay in their monitor of origin
• All windows lump into the current monitor (existing behaviour to determine current monitor with mouse position)

3. Switch/expose/paging may have distinct behaviours on the previous "two options", particularly for paging

On point one: Xinerama and XRandR are both libraries to access multi-monitor information. The useful information, from skippy-xd perspective, is simply the monitor/screen geometries. @nPHYN1T3 if I recall correctly the shortcoming of Xinerama was that it could not distinguish between screen and monitor, leading to windows displaying in between monitors, and GPU utilization being suboptimal or something?

Probably, we want to introduce optional XRandR library to skippy-xd (#183), and introduce a config option whether to use XRandR or Xinerama.

On point two: current only option is to lump all windows to current monitor. The other option (#36) will require quite some coding, since there are so many possibilities to take into account:

• monitor display/single monitor display
• XScreens
• pseudo transparency/real transparency
• virtual desktop position
• panel off sets

Ideal multi-monitor config: (?)

[multimonitor]
# Library to access multimonitor information
# Options are xrandr or xinerama
multimonLib = xrandr

# Display only windows on the current XScreen
showOnlyCurrentScreen = true

# Whether to squish all windows on current monitor
# Or windows stay in their original monitor
showWindowsOnCurrentMonitor = false

# Whether to show pages on current monitor
# Each page showing multiple monitor displays
# Or each monitor displays their respective pages
showPagesOnCurrentMonitor = false

Please discuss. AND I will need testers/coders for this.

[ghost]

"if I recall correctly the shortcoming of Xinerama was that it could not distinguish between screen and monitor"

This touches on that "how it's configured" bit. Now I could be misremembering but xinerama was originally implemented to "lump" several monitors into a single screen space. Hence things drawing between screen bezels because it thinks there is just one screen, which makes things rather ugly and broken in some cases.

However this goes back to what I used to know vs what I've forgot heh. xrandr because it's dealing with the actual screen configurations should be where you query positions and dimensions and get the correct feedback.

To the config section I'd toss in...
# Display only windows on the current XScreen
showOnlyCurrentScreen = false

# Show all windows on triggering monitor vs show windows on their parent monitor
showWindowsOnParentScreen = true

# Always expose on a set screen
# 0 denotes following triggering screen if showWindowsOnParentScreen = false
# This would mean screens are not zero indexed but the question of how to number
# them is up in the air. Especially with some layouts being horizontal and others vertical
# and to further complicate if you are running asymetrical XScreen setups one might where one
# XScreen you want forceExposeScreen = 2 and on another forceExposeScreen = 4.
forceExposeScreen = Int

[felixfung]

1. I would use the term "Monitor" rather than "Screen" to distinguish it from XScreen clearly. In xorg.conf XScreen is simply "Screen" https://wiki.archlinux.org/title/Multihead#Example:_dualhead_configuration_using_relative_coordinates_with_custom_resolutions, correct me if I'm wrong?
2. forceExposeScreen = Int is not a bad idea, but this way of configuring has two slightly messy points:
   a. forceExposeScreen is only used when showWindowsOnParentScreen = false
   b. Like you notice, how to index the monitors is up in the air
   c. That's why I had showWindowsOnCurrentMonitor and showPagesOnCurrentMonitor in my first post, so by default skippy-xd would default on current monitor, which can be set via user script similar to https://github.com/felixfung/skippy-xd/wiki/Advanced-Uses-and-Special-Set-Ups#xscreen. (two options because for paging users might want different setting compared to switch and expose)

Nevertheless I feel our ideas on multi-monitor config options are similar, and so far I am not missing entire important points .

[ghost]

1. In xorg.conf XScreen is simply "Screen"

Yeah but the context there is different. Also "Screen" is again capitalized and numbered outside the declaration i.e. `Screen "Screen0"

The force bit reminds me of something I was going to say in another bit but forgot (it's chaos here). I was spitballing about skippy updating window lists/snapshots on an interval. I'm not sure if that's how it's working and why new windows can slip through the cracks but outside the possible performance hit if that IS roughly how things are being done why not drop the intervals and just update when skippy is called/triggered so everything is current and let the user lament the extra 2 milliseconds it took heh.

[felixfung]

I was spitballing about skippy updating window lists/snapshots on an interval. I'm not sure if that's how it's working and why new windows can slip through the cracks but outside the possible performance hit if that IS roughly how things are being done why not drop the intervals and just update when skippy is called/triggered so everything is current and let the user lament the extra 2 milliseconds it took heh.

What do you mean by this? The logic is update completely triggered by events. There is no polling.

There used to be polling, but that was eliminated somewhat recently with #314.

[ghost]

What do you mean by this? The logic is update completely triggered by events. There is no polling.

Spitball, guess, conjecture.

There used to be polling, but that was eliminated somewhat recently with #314.

Hence why I was wondering if it was a polling/update interval issue. ;)

[felixfung]

If you experience any issue with windows update or related please report with new issue. Thanks.

[felixfung]

Why

 showOnlyCurrentScreen = false

I thought you want XScreen filtering?
#180 (comment)

[ghost]

?? if showOnlyCurrentScreen means XScreen then ignore that. I thought that was for which screen/monitor you are on. i.e. if I'm on monitor 2 I want to only see applications on that screen "exposed." This makes it a hell of a lot easier to find things. This is also why having skippy also be able to show all applications on their parent screens is important. It means you don't have 3+ screens worth of windows crammed into a single screen space making them too small to pick out. As noted on my other post even the icons don't help because they are truncated due to the small window sizes.

[felixfung]

Are there any practical case for not filtering XScreen?

[ghost]

OK I've rewriten this a few times trying to remember and think about this but I don't think there is a need for the option (it should just always be "on") as skippy now uses sockets to know which XScreen its on either way. Being able to turn this off just means if you moved your config to a machine with more than one XScreen skippy would appear to be broken.

At the very least I think the option name should be changed as it's a tad misleading. It should be "showOnlyCurrentXScreen" otherwise it gives the impression of "show only what is on the monitor/screen you call from on a multi monitor setup."

I might be over more help over the winter as writing my window switcher yesterday kinda egged on the idea I should brush up on the two main xlibs and look info doing something in C instead...however motivation might see that devolve into big talk no action. My burnout is all consuming the last few years.

[felixfung]

Please see https://chatgpt.com/c/68f1f232-b07c-8329-8ffd-69c212f558fe, is this the correct way to do multi monitor?

• Remove screens logic in code
• Replace xinerama query of monitor data with xrandr query
• User (not code) work with screens by invoking one app per screen

[felixfung]

My experience with LLM is slightly better than yours, otherwise agree with you.

Now in this case, I happen to agree on the diagnosis and action items from chatgpt, but of course I am not certain.

And I would like to gain confirmation. Because you know what? I would like to get multi monitor done. But if no one actually provides help I'm gonna shelf the entire thing.

[ghost]

Heh well I can help testing but the deeper stuff will take a while. Like I said I hope to dig in over winter but who knows how that will go. I've been trying to get reacquainted with a few things but it's all chaos all the time and focus is hard to come by when I have to stop and go deal with BS every ten minutes. Le sigh...

Speaking of I just figured I should check to see what skippy is written in...phew C.

While I know not all users will see it; have you thought about doing a poll? I know you have the discussion post about how people are using skippy but are lots multi screen users hindered by the lack of these things? It's kinda hard to imagine anyone not having at least 2 screens these days but hence the poll. See who needs what on the missing features list.

I just don't want to put you in therapy and I've not seen anyone else saying they need this stuff.

[felixfung]

I have tried polls previously and unfortunately too few users participate. (Did you? ;) )

For me skippy-xd is a showcase of how window selection/management should be done. The biggest room for improvement for skippy-xd right now is multi monitor (the second being expose layout incremental improvements).

For this reason, I want to do #183 and #36. #36 is high cost, since there are so many combinatorial possibilities in window offsets. If we want to do #183, we would not want to first do #36, then do #183, then redo #36 becaues the offsets change. Hence, we want to do #36, then do #183.

[felixfung]

I guess to refresh your knowledge/memory regarding screens/monitors and skippy-xd, read #183 and #180?

[ghost]

Yeah the insane depth to which display stuff goes is...insane. Hence why I said don't put yourself in therapy over this especially if it was largely for my setup. Which is because I don't see many else in the multi monitor discussions so it kinda seems like I'm it. That said I can't imagine I'm the only one. I might be an extremely rare multiGPU user but multi monitor? - Can't be. Even my pleb ass roommates run dual the triple screens.

The most recent skippy build kinda drove home I have 2 main needs. List all windows on all monitors or list everything on the monitor my pointing device is on. Right now I use rofi for "all" but it can't do just the monitor my pointer is on which is why I wrote something this week to fill that gap. Seeing skippy truncate my icons really showcased my icons are more important that seeing the windows. Again lots of terms or multiple browsers and text editors are visually useless for seeing who is what. It's all just dark gray rect's with illegible text when scaled down.

I had planned on reacquainting myself with C...it's been a hot minute (since the 90's) and I had a few things I was going to try to do. One of those things was write the little switcher I just did but in C and have it do all apps from all monitors on their parent monitor and only what is on the triggering monitor. This is why I said I may be of more help as Winter progresses but I can't say for sure if anything will come of anything. It's a steep ramp to get back up to speed with this stuff.

My icon set is also a big factor in these tools and how I navigate my systems. I have icons for terms in various grid configurations, browser icons with tells for is this the Chromium in the top center screen or the Chromium on the left bottom screen? Is that Firefox the one on the right? Is this Palemoon instance used for this or that? All my terminals are launched with icons to indicate where they are (what screen and which position) and color coded to let me know if it's an SSH session and the color tells me which machine. I'm funny like that. ;)

[felixfung]

Yeah the insane depth to which display stuff goes is...insane. Hence why I said don't put yourself in therapy over this especially if it was largely for my setup. Which is because I don't see many else in the multi monitor discussions so it kinda seems like I'm it. That said I can't imagine I'm the only one. I might be an extremely rare multiGPU user but multi monitor? - Can't be. Even my pleb ass roommates run dual the triple screens.

If we want to further expand on multi-monitor features, e.g. #36, in addition to fixing recently discovered bugs #354, #356, #374, we would want to clarify and/or fix the screen vs monitor problems, and/or xinerama vs xrandr problem. The recent multi-monitor/screen bugs highlight how messy different setups/configurations can require different offsets (to be confirmed with verified debugging).

There will be no point in implementing e.g. #36, deal with all the offsets, then implement #183, then deal with all the offsets again.

[felixfung]

Which is why I keep saying showOnlyCurrentScreen NEEDS to be showOnlyCurrentXScreen otherwise it's misleading. Hell even I forgot he.

Based on my current understanding XScreens should always be filtered to current?

Current understanding:

• Remove screens logic in code
• Replace xinerama query of monitor data with xrandr query
• User (not code) work with screens by invoking one app per screen

Though I could joke depending on the fifo permissions it might be a security issue on a multi seat machine heh. If everyones skippy instances are all writing to /tmp with only an XScreen/UID number separating instances...well... ;)

Each skippy-xd daemon would r/w to a separate pipe, each pipe with its unique XScreen+UID combo.

[ghost]

Based on my current understanding XScreens should always be filtered to current?

Well I noted on one of the other posts I tested on my dual XScreen laptop yesterday and while I think it should default to 'only show current' keeping the setting user definable makes sense. Skippy was able to actually switch to and set input to things selected on other XScreens making it useful in some cases.

The caveat to that is over crowding. This is where the crux of multimonitor issues are for me at least. Right now Skippy can do "only this screen" but it can't do all screens/monitors/displays ON their screen/monitor/display. Meaning all the windows from X screens/monitors/displays are all crammed into ONE making it a mess and really hard to pick out which window you are looking for. This is why being able to show all windows on their parent screen is important when triggering.

I'd also note there needs to be a layout other than xd and cosmos where the windows are predictable. Right now cosmos and xd will change window placements making it harder to find things fast.

I would also say showOnlyCurrentMonitor needs to be an arg not a setting. You should be able to call skippy in either mode without having to change your config, kill the daemon and relaunch. Right now I have win+w skippy "only current mon" but ctrl+tab is rofi all Windows from all screens. i.e. I should be able to have skippy-xd --expose -cm and skippy-xd --expose -am set on different keybinds so I can call the mode I need.

[felixfung]

Skippy was able to actually switch to and set input to things selected on other XScreens making it useful in some cases.

I thought XScreens are supposed to be pretty much independent?

Right now based on my very limited understanding there is no use case for not filtering XScreens.

I'd also note there needs to be a layout other than xd and cosmos where the windows are predictable. Right now cosmos and xd will change window placements making it harder to find things fast.

xd was not written by me. cosmos is. Please open new discussion on how cosmos is suboptimal.

You should be able to call skippy in either mode without having to change your config, kill the daemon and relaunch.

You can do skippy-xd --config-reload or skippy-xd --config config_path.

I don't see many users looking to alternate between single/multi monitor filtering, so

Of course in the longer term, when there is proper multi monitor support, and config option for displaying on current vs original monitor, the need/use for alternating would be even less.

[ghost]

I thought XScreens are supposed to be pretty much independent?

Yes they are largely separated. However since skippy seems to be switching to applications on other XScreens just fine it could be useful to jump around while keeping the window list mess on a particular XScreen or screen. Again user choice is typically good and it might be nice to have this for workflow.

I'm sorry if this seems to be "waffling" like but it's been a while since I used skippy and I had forgot some of these various behaviors/issues/limitations.

You can do skippy-xd --config-reload or skippy-xd --config config_path.

Still not a good way to go about it when switching modes. You still have to open your config and edit which again is a pita.

I don't see many users looking to alternate between single/multi monitor filtering, so

I do. There are windows/applications that are always on Screen X i.e. I call the "just this screen" to dig through the stack. However for things that move around like filemanagers, notepads, filemanager opened terminals, video players etc then I call "show me everything." (because I don't know where the F___ that thing is...

I will however say if Skippy gets the ability to finally show all windows on their parent monitor that will drastically change things. Without this though skippy is very hard to use unless it's set to only show from "this monitor."

[felixfung]

Again user choice is typically good and it might be nice to have this for workflow.

User choices are typically good if all option combinations are well defined and bug free and usable.

Hopefully this discussion will clarify whether XScreen filtering fits into this category.

You still have to open your config and edit which again is a pita.

You can (and some users do) have multiple pre-configured config files, and use skippy-xd --config to switch between them.

I will however say if Skippy gets the ability to finally show all windows on their parent monitor that will drastically change things. Without this though skippy is very hard to use unless it's set to only show from "this monitor."

Hopefully this discussion converges to actionable item and we perfect multi-monitor window selection.

[felixfung]

Newest idea:

[multimonitor]

# Library to access multimonitor information
# Options are xrandr or xinerama
multimonLib = xrandr

# Filter windows by monitor
showOnlyCurrentMonitor = false

# Display only windows on the current XScreen
showOnlyCurrentXScreen = true

# Whether windows stay within their original monitor
# Or squish all windows into the current monitor
switchOnCurrentMonitor = false
exposeOnCurrentMonitor = false
PagingOnCurrentMonitor = false

[musqz]

Newest idea:

[multimonitor]

# Library to access multimonitor information
# Options are xrandr or xinerama
multimonLib = xrandr

# Filter windows by monitor
showOnlyCurrentMonitor = false

# Display only windows on the current XScreen
showOnlyCurrentXScreen = true

# Whether windows stay within their original monitor
# Or squish all windows into the current monitor
switchOnCurrentMonitor = false
exposeOnCurrentMonitor = false
PagingOnCurrentMonitor = false

Looks good to me — this would make Skippy-XD a bit more flexible for multi-monitor setups.
The proposed [multimonitor] idea seems like a solid improvement for handling different screens independently.

[felixfung]

Thought about it a little bit more.

For switchOnCurrentMonitor, there is a bit of dilemma.

By default switch uses xd, where ordering is based on z-order. Let's say we have 2 monitors A and B, each z-order like this:

===A===      ===B===
1  3  5      2  4  6

With switchOnCurrentMonitor = true, and B being current monitor, it is simple:

===A===        ===B===
             1 2 3 4 5 6

With switchOnCurrentMonitor = false, the layout naturally should remain to be:

===A===      ===B===
1  3  5      2  4  6

HOWEVER, when the user does next (e.g. Tab in Alt-Tab), the next window is based on z-order. Hence the highlighted window moves in zigzag between the two monitors.

In general, users remember the last window, but do NOT remember the nth window. Hence, the users MIGHT want switching to the last window even if it means switching monitors, but for the nth window, it would appear to be an arbitrary jump between monitors, impossible to keep track.

This dilemma does not exist for cosmos layout, because window ordering on cosmos is based on window layout position.

Possible solutions:

1. XD next window logic to first sort through monitor. In the example above, it would be 1, 3, 5, 2, 4, 6. The drawback would be plenty of users would want switch between monitors for windows 1 and 2.
2. XD honours z-order and performs 1, 2, 3, 4, 5, 6. But after the first next the highlighted window would seem to jump arbitrarily.
3. The first next can go between monitors. The latter nexts would stay within monitor. I think it can be fairly easily achieved in the code. This rule is on the one hand probably the most intuitive, but sometimes the user would still feel puzzled because there is a piecewise if logic hidden.
4. Introduce config option to choose between these solutions. I think it would over-complicate things.

So far I think option 3 is perhaps the most appropriate.

Probably for switch the default should be switchOnCurrentMonitor = true. In this config setting the dilemma does not exist, and probably is relatively optimal for the purpose of switch anyway.

# Whether windows stay within their original monitor
# Or squish all windows into the current monitor
switchOnCurrentMonitor = TRUE
exposeOnCurrentMonitor = false
PagingOnCurrentMonitor = false

[gitdexgit]

Introduction about me a user who uses skippy-xd

@felixfung @musqz Here is how I use skippy-xd now... My setup improved so much.. .( I hate that pannel not refreshing fast enough) but overall I'm 100% complete. It's hard for me or any features that look shiny to out compete what I do for now.

This is 100% personal setup I dedicated a lot of time to make it. And it's a reflection to how I used to use windows 10 with ahk which started all this linux computer automation personal setup optimization hobby thing.

Do you need more than this?

This is what I use skippy-xd for

(sry if there is any lag, recording things isn't my strongest point I don't know how to record using GPU and I don't know what good softwares are for recording 2 monitors at the same time lol)

https://youtu.be/JqDDrQPNBvE

skippy-xd multi-monitoir is alreayd too good. Here is how I use skippy-xd with multi monitor

here is the xdotool config used https://bpa.st/raw/XNRQ

here is skippy-xd.rc --> https://bpa.st/raw/RXWQ
here is skippy-xd2.rc --> https://bpa.st/raw/YDBA
here is skippy-xd3.rc --> https://bpa.st/raw/3WYQ

(my keyd config is ugly you don't want to see that it has dvorak for F** sake hehehee... but the skippy-xd interactions are same thing with xdotool just capslock + alt, capslock+meta caplsokc+enter , capslock +, and cpaslock +. and capslock+/ it's just easier for me to hit capslock and remember things.)

(btw that double alt tap I use it all the time instead of alt+tab I do use alt+Tab by habbit but I love tapping alt 2 times and it returns me to the preview window I was in. It's it's own config because alt+Tab is on current monitor windows... with no animation while double alt+tap is return me to the preview window on all monitor but with no animation... )

(mod4+tab is the basically you guys hold alt and hit tab right but for me I hold meta and hit tab... as you see in the video it shows me all windows on monitor. I also have one for all windows on only current monitor... you saw the vid you see how everythign fits very well. (I've used it for 2 months everything for me fits and I will never change it any time soon.)

that's all I use. Thanks for the work on the cli changes it reduced from 7 or 3.

Here is how I switch to windows with titles or great imprtance:

this is without skippy-xd how I switch windows without skippy-xd with 2 monitors
https://youtu.be/dGmZFoVMx0o

there is also a mini thing I made with wmctl that can switch to windows with the same class with alt+grave but I don't use it with terminals (it's messy) I do use it with other applications like browser or you know those that have few about 4 windows.

I do also use dropdown terminal... this helps resolves the issue of terminals having too many. also use a thing on the pannel to run some aliases it's not perfect but it does the job

I have grouping on main pannel monitor

But I don't really care that much... only use it as an indicator that oh yeah for terminal on this destkop I need 100% to use skippy-xd preview here to deal with these 6.

again I usually have 1 program per each destkop only monitors issue you know...

I have the ghossty too many monitor preview issue but on computer lol hhh can't be helped. it is what it is.

And that's it really I showed you rofi... when skippy-xd fails and when I fail to find something... and fail to cycle my destkops really fast with that thing that was in here

that pannel that was in here the xfce4 for desktops preview with me all the time... I gave up and rofi it... and also sometimes when I don't feel like hitting a hotkey I know where I'm going for I'm going to firefox it's on who care where it is.. .boom.. go there.

my pannels are all hideable they are always on the bottom so I can like make window so big (not full window F11 thing)

so yeah I don't think I need multi-monitor features. I can navigate my computer pretty fast and have so many I can never max out on windows I max out on ram before I max out on windows.

what I have to say regarding multi-monitor

introduction about what I have to say regarding multip-monitor

Here is a scuffed thing I wrote really fast on this topic. I rewrote this like 3 times I'm so bad at writing comments lol hhh.

@felixfung I will only say this on this topic and never anything else.

@felixfung idk I don't think any change is necessary maybe better fix on more important problems.

Is there a need for multi-monitor extra features and support? The people who have 3 monitors What are they exactly saying?

I only have 2 monitors and I think the human brain can only deal with 2 monitors... and that's it.

skippy-xd already has great support with multi-monitor. All you need is "Show all windows on monitors", and "Show windows on current monitor" and that's it.

body

Please tell users what they want? as you see me I don't need what's bellow:

if user wants to see windows on his 3rd monitor just move mouse, automate the moving of the mouse run skippy-xd and return mouse to it's original position (we all did that automating mouse movement, what I call the dump solutions in xdotool)

The idea of... I want to only see windows on 3rd monitor...
--> well just make a script that moves mouse to 3rd montir and that's it.

I want to see only windows on 2nd monitor and 3rd monitor but not the main monitor.
--> well you move your mouse to 2nd monitor open preview then move your mouse to 3rd monitor and that's it. what else you want? You want to like "Show windows on all monitor" but then have control in the config to hide windows that belong to first monitor. "So show all monitrs" but then we hide windows that belong to certain ones and we have control to which windows that belong to each monitor to hide.

SOUNDS LIKE WE NEED TO FOCUS ON BETTER THINGS.

My config https://bpa.st/raw/XNRQ already good with 2 monitors if it's good with 2 monitors it's good with 3 and 4 and 5. No matter how I think about it If I use a 3rd monitor I wouldn't change anything about my config and I wouldn't want anything in regards to how skippy-xd that I want to change. Maybe the Paging where instead of having everything in 1 big screen maybe we can take advantage of multiple screens for bigger preview... idk... I would love a way to zoom in the preview... like graphics, better text visuals, search, not wasting time moving my mouse in the previewer. idk

idk to me I know what windows are on each destkop all the time. so what's the point of a previewer?

Do you know alt+tab terminator... this program on windows. this one

alt tab terminator https://duckduckgo.com/?t=ffab&q=alt+tab+terminator&ia=images&iax=images I used to use it 2y ago when I was on windows.

it has preview and search on the alt tab... ofc it sucks with typical alt+Tab but it's like rofi window switcher with a preview (IN realime) well that's hard to do in X11 but the preview is so big.

Maybe we need a 3rd mode of skippy-xd where you can only see 1 window but you can search and the window is big so you see a preview of it.

We recommend the users to run skippy-xd at startup with the right window thing Qtreeury ... we make sure that skippy-xd never crashes and if it crashes it has cache so it remembers where it was last time... idk something like this.

and that's it. we make skippy-xd a window switcher killer, a alt+Tab switcher killer... and (paging needs more development) a destkop switcher killer.

for now it's only a alt+tab switcher killer. It still hasn't killed my window switcher rofi I still use that. still hasn't killed my workflow pannel still use that (It's hard to beat in my opinion because it's personal I'm already used to it and it's well integrated with keyd and you know just too good for me.)

umm maybe you can like add mouse drag where you can like in paging you can drag windows aroudn to send them to a destkop that would be cool.

Conclusion

I don't think we need to care about people who have 3 4 or 5 monitors the problem is already solvable with xdotool. Only fix bugs that they might have where windows not rednering correctly or glitching.

We should focus on other needs.

Do we really need to focus on multi-monitor, when it's already good? I have 2 monitors and you know me I'm a maniac for optimizations I say it. I have no issues issuing skippy-xd with 2 monitors.

If I can do it with 2 I can do it with 3 or 4 or 5. it's just 3 monitors to me introduces too much distractions.

Last words for inspiration for further development

I hope this helps you gain inspiration for further skippy-xd design if you need to move the software further and ran out of ideas you can check out alt+tab terminator, differnet WM managers that have built int alt+tab see how they handle windows and destkops. see how X11 works how wayland works with displaying or rendering the window like thumbnail and such... to maybe cook something with thumbnail or zoom... rofi switcher builds of other people where they have rofi as an alt+tab with thumbnail preview and search (basically made it alt+tab terminator on linux), search, window serach fuzzy find. idk see how other users use skippy-xd and such.

Other than that I think skippy-xd is complete. maybe a extensions? or moving on to skippy-xd2 with all the crazy ideas ? everything in a gui go all crazy with search and everything idk.

regardless I have nothing to say or contribure more... I still need to learn my lua and c and c++ it wil ltake a long time and I'll probably be busy :D.

have a good one guys. if you don't hear from me I'm doing an LFS or something.

[felixfung]

You have mentioned a few times a want for magnifier and on the fly filtering. I would say skippy-xd can already achieve these if we can script windows to appear on top of the skippy-xd full screen window.

I would encourage you to explore this. I would like very much to do it also.

[felixfung]

Copying comment from above for easier reference: #365 (reply in thread)

Thought about it a little bit more.

For switchOnCurrentMonitor, there is a bit of dilemma.

By default switch uses xd, where ordering is based on z-order. Let's say we have 2 monitors A and B, each z-order like this:

===A===      ===B===
1  3  5      2  4  6

With switchOnCurrentMonitor = true, and B being current monitor, it is simple:

===A===        ===B===
             1 2 3 4 5 6

With switchOnCurrentMonitor = false, the layout naturally should remain to be:

===A===      ===B===
1  3  5      2  4  6

HOWEVER, when the user does next (e.g. Tab in Alt-Tab), the next window is based on z-order. Hence the highlighted window moves in zigzag between the two monitors.

In general, users remember the last window, but do NOT remember the nth window. Hence, the users MIGHT want switching to the last window even if it means switching monitors, but for the nth window, it would appear to be an arbitrary jump between monitors, impossible to keep track.

This dilemma does not exist for cosmos layout, because window ordering on cosmos is based on window layout position.

Possible solutions:

1. XD next window logic to first sort through monitor. In the example above, it would be 1, 3, 5, 2, 4, 6. The drawback would be plenty of users would want switch between monitors for windows 1 and 2.
2. XD honours z-order and performs 1, 2, 3, 4, 5, 6. But after the first next the highlighted window would seem to jump arbitrarily.
3. The first next can go between monitors. The latter nexts would stay within monitor. I think it can be fairly easily achieved in the code. This rule is on the one hand probably the most intuitive, but sometimes the user would still feel puzzled because there is a piecewise if logic hidden.
4. Introduce config option to choose between these solutions. I think it would over-complicate things.

So far I think option 3 is perhaps the most appropriate.

Probably for switch the default should be switchOnCurrentMonitor = true. In this config setting the dilemma does not exist, and probably is relatively optimal for the purpose of switch anyway.

# Whether windows stay within their original monitor
# Or squish all windows into the current monitor
switchOnCurrentMonitor = TRUE
exposeOnCurrentMonitor = false
PagingOnCurrentMonitor = false

[felixfung]

For paging, there are also interesting considerations.

Paging offers an overview of all virtual desktop, and by extension all your windows. Whether the user wants to see it in the current monitor, for a concise overview, or have them separate on each monitor, is up to the user, controlled by config option.

Now the presentation between PagingOnCurrentMonitor = false and PagingOnCurrentMonitor = true are significantly different.

PagingOnCurrentMonitor = true: current behaviour. Each "page" shows a virtual desktop, with all monitors lumped onto a page.

PagingOnCurrentMonitor = false: each monitor shows n pages, the page being a virtual desktop for that monitor.

But, no dilemma.

[felixfung]

Latest idea, leaning towards removing showOnlyCurrentXScreen:

[multimonitor]

# Library to access multimonitor information
# Options are xrandr or xinerama
multimonLib = xrandr

# Filter windows by monitor
showOnlyCurrentMonitor = false

# Whether windows stay within their original monitor
# Or squish all windows into the current monitor
switchOnCurrentMonitor = true
exposeOnCurrentMonitor = false
PagingOnCurrentMonitor = false

This raises a new question: showOnlyCurrentMonitor may be redundant and should be removed?

For expose and paging, showOnlyCurrentMonitor is probably redundant. But for switch, as elaborated by the dilemma above, users MAY want to limit options to current monitor only...

Introducing command line parameter is probably overkill...

Perhaps showOnlyCurrentMonitor can be moved to switchOnlyCurrentMonitor?

[multimonitor]

# Library to access multimonitor information
# Options are xrandr or xinerama
multimonLib = xrandr

# Whether windows stay within their original monitor
# Or squish all windows into the current monitor
switchOnCurrentMonitor = true
switchOnlyCurrentMonitor = false
exposeOnCurrentMonitor = false
PagingOnCurrentMonitor = false

[felixfung]

Thinking a bit more, too many choices and options is not necessarily a good thing...

According to this design:

The first next can go between monitors. The latter nexts would stay within monitor. I think it can be fairly easily achieved in the code. This rule is on the one hand probably the most intuitive, but sometimes the user would still feel puzzled because there is a piecewise if logic hidden.

Once the user has landed on the appropriate monitor, limiting selection to current monitor is pretty easy.

So if we have the simplest config:

[multimonitor]

# Library to access multimonitor information
# Options are xrandr or xinerama
multimonLib = xrandr

# Whether windows stay within their original monitor
# Or squish all windows into the current monitor
switchOnCurrentMonitor = true
exposeOnCurrentMonitor = false
PagingOnCurrentMonitor = false

# When already on last window on current monitor,
# Go to the first window on the next monitor
# As opposed to loop back to first window on current monitor
switchCycleMonitors = true
exposeCycleMonitors = true
pagingCycleMonitors = true

When switchLayout = xd and switchOnCurrentMonitor = true, all windows display on current monitor based on z-order.

When switchLayout = xd and switchOnCurrentMonitor = false, each monitor show its windows based on z-order., scoped within its own monitor only. The first switch next may switch to non-current monitor. Subsequent next stays within current monitor. Of course up/down/left/right can go across monitors.

In addition, similar to layout section, introduce switchCycleMonitors/exposeCycleMonitors/pagingCycleMonitors, default true.

[felixfung]

Changed my mind regarding *CycleMonitors, I think they are over-complicated. Removed and behaviour always switch to next monitor after last window.

[multimonitor]

# Library to access multimonitor information
# Options are xrandr or xinerama
multimonLib = xrandr

# Whether windows stay within their original monitor
# Or squish all windows into the current monitor
switchOnCurrentMonitor = true
exposeOnCurrentMonitor = false
PagingOnCurrentMonitor = false