Add [Alt]+[Tab] keyboard shortcut (Now: Run only a single instance)

[ikem-krueger]

I like to use [Alt]+[Tab] to cycle thru the window previews.

And I like to use [Alt]+[Shift]+[Tab] to do this in reverse.

[richardgv]

Huh, I may implement it after I finish my exam. Well, if it doesn't actually conflict with your WM... I hope keyboard grabbing works.

[ikem-krueger]

I would reassign the keyboard shortcuts.

So the first [Alt]+[Tab] would start skippy-xd, the second [Alt]+[Tab] cycle thru the windows.

(Same for [Alt]+[Shift]+[Tab].)

[richardgv]

Heh, okay. Let me deal with the exam firstly, okay?

[atenrok]

I second on that! Glad to see somebody has similar habits already. First thing, I assigned "Alt+Tab" to run "skippy-xd --activate-window-picker". I was hoping I can change the config file to assign the "Tab" key to switch selection, and a "Space" key to focus, but i don't even know the syntax of keys in skippy-xd.rc, some examples would be handy.

The major issue I have with this right now, is that skippy does allow to run a second instance of itself and I don't know if there is a way to prevent it. I still tend to press Alt+Tab more than once, and this often creates multiple "expose" windows.

Good luck with your exam richardgv, unless it already happened :)

[ikem-krueger]

The daemon is a bit tricky/unstable. That's why I run skippy-xd on demand.

For that I made a custom shortcut in the mate-keybinding-properties:

Name: skippy-xd
Command: skippy-xd
Shortcut: [Ctrl]+[Tab]

[richardgv]

Ctrl+(Shift+)Tab is introduced in b6de2f0 to cycle through mini windows. Not in a sensible order, though. I would need to change something in layout.c to get this right, and I don't yet understand that file. :-D

If you are willing to use Alt instead of Ctrl, modify the definitions of KEY_PREV and KEY_NEXT in src/clientwin.c. Key bindings will be made customizable when I have some time to work on #31, which is like, infinitely remote. :-D

The daemon is a bit tricky/unstable. That's why I run skippy-xd on demand.

Indeed, unfortunately I don't have the time to fix it.

[ikem-krueger]

Thank you for your work. :>

[atenrok]

Great job richardgv! I have modified clientwin.c to have the key cycle between the mini-windows, as in my case I skippy-xd is activated by + and unfortunately skippy-xd still does not prevent multiple instances of itself from running.

Looking forward to more fixes.

[richardgv]

unfortunately skippy-xd still does not prevent multiple instances of itself from running.

You could write a simple wrapper script to avoid the situation, Like, ps -C skippy-xd >& /dev/null || skippy-xd. I don't see why it has to be a built-in feature.

[atenrok]

I don't see why it has to be a built-in feature.

simply because it is extremely inconvenient when you accidentally run into a situation with several layers of mini-windows on top of each other, and you don't realize what is going on since nothing indicates multiple running instances of skippy and only pressing enough times brings you back to your desktop (been there myself several times). On the other hand, I can't think about a possible situation when someone would need several instances of skippy running simultaneously.

But yes, you are right, I can write a wrapper script.

[atenrok]

Just realized that github markdown drops everything enclosed between the < and > symbols, unless I prepend those symbols by backslash. So my in my previous posts some lines lost their original sense:

I have modified clientwin.c to have the key cycle between the mini-windows, as in my case I skippy-xd is activated by + …

…and you don't realize what is going on since nothing indicates multiple running instances of skippy and only pressing enough times brings you back to your desktop…

[richardgv]

@atenrok:

I see. Indeed, it would be annoying if you have lazyTrans enabled and window stack gets messed up. But it isn't easy to get a lock perfectly working: The user may have multiple X displays, there could be multiple screens in each X display, and probably the screen list will be changed dynamically (?). We have to do a per-screen lock and handle possible changes correctly, and handle the case when skippy-xd crashes / is killed. And we have to deal with racing conditions. Considering it's rare, it's easy to prevent on client side (you don't have to make sure it works on a computer system in a nuclear plant with 10 X displays and 20 screens in each :-D ), and it's tricky, I will put it on the bottom of my TODO list, which most likely I will never reach. :-D