If a single window is already open and in focus - minimize it instead

[ghost]

I would like to see such feature, I can't come up with the reason why it's not the default behavior.. maybe it's hard to implement? thx.

[e3rd]

(IMHO, I don't think it should be default behaviour. I couldn't use the computer without display.)

[ghost]

lol what do you mean?

[e3rd]

• That I don't find it useful to change the current default behaviour.
  When I jumapp to an application, I want to be sure that it's active without looking to the screen. If it is minimized instead, it would be confusing to me.
• And what if there are several instances of an app – should it cycle or minimize all of them?
• If you want to implement such a feature, you may want to use get_active_windowid() script function, then check if it's your window and eventually run wmctrl -b toggle,shaded or so.

[ghost]

Now I understood, quite unusual workflow you have without a screen :)
Can you explain in more detail how to implement it? I'm zero in coding, certainly not able to do it myself.

[e3rd]

Maybe the minimize mechanism I did is not perfect. I used wmctrl.
It may be nicer with xdotool but I don't want to add further dependency.
You can test my pull request if the -m flag works for your needs.

[mkropat]

Thanks a bunch @e3rd for putting together a PR. Do you mind testing it out @darutse and see if it does what you're looking for?

There are examples of this behavior on other platforms. On Windows, the Windows-key+number combination performs jumpapp like behavior, and if the app is already focused it will minimize it. I can only speak personally, but I find this behavior a little confusing.

One of the design goals of jumpapp is to reduce the amount of thinking a user has to do about "modes" when navigating the desktop. The modes in this case are: is the program already running or not? Is the window minimized? Hidden behind another window? On another desktop? The advantage of jumpapp for me is that I don't have to think about all that. I press one key and the program I want is focused.

(For more context on eliminating "modes", check out this talk by Bret Victor where he talks about Larry Tesler.)

I see altering jumpapp to have two different behaviors — focus an app, or minimize it if it's already focused — to be a small step backwards.

All of that is a really long way of saying that I don't think it should be the default behavior, but I'm totally cool with making it an option.

[e3rd]

(I totally agree with this opinion, thanks for writing it so clearly.)

[ghost]

I get it now, is just my workflow usually looks like this:

1. working with 1st window
2. bringing 2nd window in front (doing something in it)
3. minimizing 2nd window and I left with 1st window in front of me.
   I'm not thinking about some kind of 'modes' at that point, it happens naturally for me at least.
   Nevermind, after some research I found that wmctrl doesn't support minimizing only shade, and even with xdotool it really tricky to do, possible solution might be to directly send minimize shortcut to the window, but such shortcut can be different for any particular DE or non present at all.
   Not worth to bother really. Also the solution by e3rd not that great either, it shades too fast to the point that you cannot control the state of the window, probably shouldn't be added to the main in this state.

[e3rd]

3. minimizing 2nd window and I left with 1st window in front of me.

Why do you minimize 2nd window when even without minimizing, the 1st window will take focus (jumpapp cycle amongst windows)?

xdotool

With xdotool it seems easy to me. You may use xbindkeys to assign "Win+Down" keys to command xdotool windowminimize $(xdotool getactivewindow).

it shades too fast

Me too I think that the feature is not crucial. I wanted just to please you.
But what do you mean by "you cannot control the state"? What do you want to control?

[ghost]

Why do you minimize 2nd window when even without minimizing, the 1st window will take focus

If there is more than one window of 1st type it will cycle, I can't be sure what exactly will be focused. It seems logical just to minimize 2nd window. If cycling based on access time will be implemented I probably will adjust my workflow.

But what do you mean by "you cannot control the state"? What do you want to control?

When I press the button (not holding) the window shades and un-shades like 50 times in a row, and usually end up being unshaded

[e3rd]

un-shades like 50 times

Wow, you are right.
Let's not debug it and trash out this feature.

[mkropat]

This got implemented in #41 and is included in the latest release.