Add quick-actions on thumbnails

[lwouis]

Add quick actions on thumbnails, similar to what WindowSwitcher is doing:

I think only these are actually useful:

• Resize half-screen left/right/up/down
• Resize full-screen
• Quit

In a first phase, keyboard only, then maybe some visual buttons can be added.

More details in this video, especially the minimize behaviour which shows limitation of the Mac API (can't get thumbnail of a minimized window)

[gingerr]

Should the support for some native shortcuts (cmd-m/q/w) be realized here or in a another issue?
Also that drag files into tabs feature sounds good.

https://news.ycombinator.com/item?id=21253850

[lwouis]

First implem of this could be anything to be honest. From there we can have new tickets to fill the gaps.

For drag and drop of files onto the thumbnails, this is definitely another ticket lol

Feel free to open it. I would suggest exploring more what that would look like and describe in the ticket. For instance do we want to send the file to the app like the app switcher does, or do we want to show the window after like 2d hovering with the file on the thumbnail, or both maybe

[rbnis]

I'd love to to implement closing windows (cmd-q/w). I have seen that you started in #81 with an implementation for split windows.

Would you prefer if I open a new PR based on master (maybe including your split window implementation) or should I base my PR on #81?

[lwouis]

Hi @Robinhuett! I'm really glad you want to contribute! I'm currently working on a massive PR that will bring v2.0.0. I thought about it and i see 2 ways: either you wait a few days/weeks and work on that of v2, or you can work on top of master now, and I'll rebase and fix conflicts in my PR.

In any case cmd-q/w should be pretty simple. The reason my PR has been stuck for a while is that resizing is way more complex because it involves multi-display.

I think I will probably discard my quick-actions PR later and make on fresh implem on top of v2 anyway, so if you start working right away, please do it on master, taking inspiration from my PR if it helps you.

Let me know what you plan on doing :)

[rbnis]

I have already tested a few things on master and got it semi working, but im not happy with the state of it. After looking at the changes from your last PR I'll probably wait till it is merged since it fixes a few things I also had in mind.
I'll keep an eye on your PR and will start in there to get quick-actions upstream asap after your merge :)

Thanks for this cool project

[lwouis]

@Robinhuett I finished the work today actually. Feel free to try v2 out, and make a PR on top of current master!

[ghost]

I would like to see this implemented similar to the way the native Command-Tab works. (I will assume the shortcut here is Option-Tab)

1. Option is held down, and Tab is pressed at least once, triggering the window switcher.
2. While a window is selected, and Option is still being held down, w will close the selected window, m will minimize it, etc.

I do not think application-level shortcuts (such as quit) should be available. Alt-tab is about managing single windows at once, so shortcuts that apply to many separate windows would lead to unexpected and accidental actions.

[lwouis]

@ezity your desire of not being able to press q to quit, makes me think that, after we add the new "Close window", "Minimize window", and "Quit app" shortcuts, we should change the shortcuts behavior, including the existing ones

So that you can empty them to disable them. That way users can disable shortcut they don't want. I think that solves every issue.

Now should the "Quit app" shortcut be on or off by default, that I'm not sure.

[ghost]

@lwouis My personal opinion is that by default window shortcuts are on and app shortcuts off.

On a different note, I'd like to add that the UI for the shortcuts is really great - it clearly communicates how to use the app.

So that you can empty them to disable them.

Maybe a little x in the box displaying the shortcut. Kind of like this (but obviously in the middle not the top):

[lwouis]

On a different note, I'd like to add that the UI for the shortcuts is really great - it clearly communicates how to use the app.

Thank you! I thought a lot about it :)

Maybe a little x in the box displaying the shortcut. Kind of like this (but obviously in the middle not the top):

It's available in the latest release

When emptied, it looks like this:

Ideally I would like to have the controls resize in width, depending on their content, so that there is never any ellipsis. However that's very hard to do without Interface Builder, so I think the current behavior is good enough, and I would rather focus on other tickets

[lwouis]

After release of v3.11.0, here is where we stand regarding quick-actions:

Remaining candidates

• Fullscreen/De-fullscreen window [1]
• Tile window as seen on the picture in the OP (e.g. left half, right half, maximize, etc)

[1] what about tiling left/right?

Out of scope, as I think this level of detail would be better served by a WM like yabai:

• Move window by x pixels
• Resize window by x pixels

Additional things to work on / think about

• For tiling, how many shortcuts should be defined? That can escalate quickly with left half, right half, left third, right third, maximized, etc
• The preferences are starting to be numerous. How to handle both: complexity for users, and physical size of the preferences window?
• Mouse UI, like the picture in the OP. For the icons, we can continue to use vectors from SF Symbols, but I don't know which design to do, how big to have the buttons, how many buttons? If we put all icons, it may look like a Christmas tree

Personal anecdote

While testing the shortcut to hide apps from AltTab, I was blown away but how fast the window show/hide. It is an amazing way to manage what's on screen! I never thought about such a workflow until I experienced it. I suggest you give it a try! Also it's fun to realize that you can minimize > hide > deminimize. At this point the window is visible, but the app is still hidden technically. Oh macOS, you silly goose 🙉

Please feel free to share your feedback! 👍

[ghost]

For tiling, how many shortcuts should be defined? That can escalate quickly with left half, right half, left third, right third, maximized, etc

I think it is reasonable to stick to OS-level shortcuts. So full-screen, tile-left/right - yes; move window x pixels, right/left third - no.

Mouse UI, like the picture in the OP. For the icons, we can continue to use vectors from SF Symbols, but I don't know which design to do, how big to have the buttons, how many buttons? If we put all icons, it may look like a Christmas tree

I think actions (as opposed to information) should be available only on mouse-over. This strikes a good balance - all functionality is available with the mouse, but the interface isn't cluttered with buttons that aren't necessary for keyboard use. Specifically, I think we could replace the window title with icons for actions when the user mouses over the window.

The preferences are starting to be numerous. How to handle both: complexity for users, and physical size of the preferences window?

I prefer minimizing preferences. For instance, with the current appearance preferences, I am hesitant to mess with them - there are simply too many options. I think most of that section could be replaced by a simple size option (large, medium, or small). In addition, we could offer an accessibility option that allows super-large UI elements (and maybe slightly more customizability). I find the fish shell design document inspirational in this matter.

Great work on the latest release, the quick-actions are a huge improvement to my workflow.

[lwouis]

I think it is reasonable to stick to OS-level shortcuts. So full-screen, tile-left/right - yes; move window x pixels, right/left third - no.

When I said "tiling", I was referring to resizing the window the way the app in the OP does. It's not using the fullscreen mode where you can have side-by-side fullscreen'ed apps. It's just resizing the apps the way you would using the mouse and resizing with the handle. I used to use Spectacle.app for instance to do it. This is in my opinion way better than fullscreening apps because it's instant. Fullscreen on macOS is an absolute mess. Long animations, and at the technical level a fullscreen app is an app on another space.

On the OP picture, you see how WindowSwitcher is giving buttons to instantly resize the window by many ratios. I was wondering how many of these do we do. These are essential to me. I use Phoenix.app today, and was considering switching to yabai, but it's a bit too involved for my needs, especially for the work laptop where I can't disable SIP for instance.

I think actions (as opposed to information) should be available only on mouse-over. This strikes a good balance - all functionality is available with the mouse, but the interface isn't cluttered with buttons that aren't necessary for keyboard use. Specifically, I think we could replace the window title with icons for actions when the user mouses over the window.

Yes mouse hover for sure. Now for how the controls are, there are so many options: on top of the existing UI elements, replacing as you suggest, or merging the way the "hidden" or "minimized" font-icons currently push the right side of the titles. A lot of designs are possible here. It think making the thumbnail look a window the way it's done in the OP is the most intuitive, but there are many details to iron out here.

I prefer minimizing preferences. For instance, with the current appearance preferences, I am hesitant to mess with them - there are simply too many options. I think most of that section could be replaced by a simple size option (large, medium, or small). In addition, we could offer an accessibility option that allows super-large UI elements (and maybe slightly more customizability). I find the fish shell design document inspirational in this matter.

There is a lot I disagree with in the fish document you linked. Configuration is a nightmare to maintain, yes I agree 100%. However it brings functionality, so it's a cost that brings value. Now the question how much you expose is basically how many users you want to fully empower.

You said you think we could make kind of macro preferences "large, medium, or small" the same way we have the "theme" preference which is already changing multiple aspects of the UI. Here is my issue with having 3 sizes: which values would each carry for their set of settings? Can you find 3 sets of value for large, medium, or small, and still enable these user flows:

• Someone wants to only have 1 row of windows because they are OCD and never have more than 5 windows open, so they want them nice and big on 1 row
• Someone wants to hide the titles (currently they can set the text height to 0 to remove them)
• Someone wants to hide the app icons (currently they can set the icon size to 0 to remove them)
• Someone always has 30-50 windows open (I have a friend with 200 chrome tabs always open for instance), so they want tiny thumbnails to see everything in a glance
• Someone wants AltTab to take 100% screen space when showing, because they get bigger pictures that way, and what's the point of not taking the whole space when you invoke AltTab anyway? You wanna be looking at it right, not the background? (their thinking)

What would be your 3 sizes?

	max size on screen	min windows per row	max windows per row	...
S	?	?	?	?
M	?	?	?	?
L	?	?	?	?

In case you're not sure what the different layout preferences do (it's not trivial), I just explained it nicely here.

I thought a lot about preferences over the course of this project. I think the best is to have "modes". Some apps do it. You go in the prefs the first time you see friendly simple limited choices. But there is a "power user" button. If you click it you unlock a million choices to really have the flow that maximizes the way your wanna use the software.

Now here is the challenge: how do you decide the simplified preferences if you don't have data over the userbase? If we knew that 80% of users have these values, then we could optimize for how people use the app and provide t-shirt sizes, the same way t-shirt manufacturers actually provide t-shirt sizes: by looking at their bell curve sells graphs. However from the get go I decided that this project would be in the libre-software culture, and not do telemetry. It's insane how much telemetry there is today. Install LittleSnitch and you will be amazed at something like 200 HTTP call per hours coming from your apps, to sell your info to advertisers. I want this project to be a child poster as to what good software is. Nothing without user consent, everything works offline, performance is a feature, credit is given to third-party libraries, etc.

All this being said, if you have a great vision on how to simplify the preferences, please feel free to share a mockup. We can surely discuss how to improve the design. Right now I just exposed a lot of levers so people can do what they want. Later I was thinking of better organizing for sure. Also other improvements like #85 and #127

[lwouis]

I implemented the 3 window controls (close, minimize, fullscreen). I'll keep this ticket open as a reminder of more polish that can be added in a next step:

• Mouse hovering the 3 icons should show visual feedback that they are interactive buttons. For example, the color could get more intense, or opacity could be low/high on mouseenter/mouseexit.

• Same as above, but for mouseDown/mouseUp

• When the thumbnail is narrow, the placement of the 3 buttons should be modified to be centered above the thumbnails

• Finally, I'm not sure if they should still be in scope, but if they are: add the resize buttons as seen in the OP screenshot

[kushagr-m]

Could you please add an option to disable these hover controls? I use another window manager rxhanson/Rectangle to manage window sizing and I don't really want this app switcher trying to do that too.

Also, it just looks kinda weird and out of place -- if you need to mouse hover the alt-tab preview to see them why would you choose to do that rather than just move your mouse to the top corner of the window itself? That is hold ⌥Tab, then move your mouse/trackpad to hover the window, vs. just move your cursor in the first place.
With keyboard shortcuts, we already have ⌘W, ⌘H and ^⌘F respectively, so Alt-Tab probably doesn't need to manage these.

I don't mind leaving the feature in the app if people find it useful but please add an option to disable it.

[lwouis]

Also, it just looks kinda weird and out of place

Are you referring to their UI/look? If so, could you please elaborate on what's wrong, and how you think it should be improved

With keyboard shortcuts, we already have ⌘W, ⌘H and ^⌘F respectively, so Alt-Tab probably doesn't need to manage these

The existence of keyboard shortcuts doesn't mean there shouldn't be a visual ,mouse-operated, alternative to the same functionality. That's why windows have these 3 buttons and you can use shortcuts to manipulate them. Shortcuts are fast and repeatable but lack the discoverability and friendliness of visual elements.

please add an option to disable it

I thought about doing that originally, then thought that it's really not that intrusive as you have to mouse hover to activate it. Even then, you can simply not click on them if you don't want to engage with them. I thought it's fine to have it on without a preference. I guess it's visually distracting you? We can add a preference I guess. I'm not enthusiastic about adding a preference for every single small aspect of the app, as they keep pilling up and getting out of control, but at the same time I don't know how to satisfy everyone.

[kushagr-m]

Are you referring to their UI/look? If so, could you please elaborate on what's wrong, and how you think it should be improved

Yes, they look a bit strange. There's no indicator that they're interactable on hover (but I understand this will be changed).

Also they're a bit too big and could be shrunk. There's also too much padding around the icons in the circle. The full screen button should be two triangles rather than a plus for consistency (see the following screenshot).

Even then, you can simply not click on them if you don't want to engage with them.

They're also distracting if I'm using my mouse to select a window. If I try to click on the top left corner of a window with my mouse I could inadvertently close/minimise/fullscreen it. This could cause problems.

If we're still sticking with the Windows 10 style, a cross "close window" button appears in the top right corner when hovering -- this might be a less intrusive way to do this.

For a more Mac-like way to do this, notice how hovering a space in Mission Control shows a cross in a white circle in the top left (note how this takes a fraction of a second to show up so a user doesn't accidentally close a window). I was unable to take a screenshot of this but I'm sure you can see what I mean.

The existence of keyboard shortcuts doesn't mean there shouldn't be a visual, mouse-operated, alternative to the same functionality. That's why windows have these 3 buttons and you can use shortcuts to manipulate them. Shortcuts are fast and repeatable but lack the discoverability and friendliness of visual elements.

I completely agree -- that's why windows have these buttons in the top-left. As an app named for a keyboard shortcut, I would think that the primary focus would be on keyboard shortcuts? A visual way to manipulate windows already exists in the form of Mission Control.

Additionally, a keyboard shortcut (namely ⌥Tab) is already required to show the Alt-Tab interface to even have a target to hover. If a user already needs to use a keyboard shortcut to invoke the application, it's counterintuitive to me to make them then use their mouse.

With regards to discoverability, the 3 buttons are hidden until a hover so they're inherently going to be a little bit hard to discover anyway.

I'm not enthusiastic about adding a preference for every single small aspect of the app, as they keep pilling up and getting out of control, but at the same time I don't know how to satisfy everyone.

Honestly this does make sense to me, but I think that you should be a little bit more opinionated then with what features you add. By necessity, adding more features is going to mean more options -- if you want less options then I think you should avoid what is (in my eyes at least) feature bloat.

Another idea if you don't want to clutter the options menu is to use "hidden options" accessed by command line, similar to Rectangle -- see the Readme for details. These preferences are set by the defaults write terminal command, so you could make them a little bit more complicated, for advanced users only.

[lwouis]

There's also too much padding around the icons in the circle. The full screen button should be two triangles rather than a plus for consistency

I'm using the SF Symbols font from Apple for these indicator. These are great because the license allow me to use them. They are also vector graphics, so scale with resolution. That font doesn't have a fullscreen icon with the 2 triangles currently, unfortunately, thus why I picked the + icon.

If we're still sticking with the Windows 10 style, a cross "close window" button appears in the top right corner when hovering -- this might be a less intrusive way to do this.

I don't understand how it is less intrusive. It's the same thing except square instead of circle, and right instead of left. Also they provide less functionality by having only the close button.

For a more Mac-like way to do this, notice how hovering a space in Mission Control shows a cross in a white circle in the top left (note how this takes a fraction of a second to show up so a user doesn't accidentally close a window). I was unable to take a screenshot of this but I'm sure you can see what I mean.

I compared with WindowSwitcher and HyperSwitch when developing the feature. HyperSwitch has a delay before displaying the button, as you mention. So I considered that. Then I decided AltTab was about snappiness, and I would rather have functionality available instantly without latency.

Interesting to note that for Mission Control, while they do have a delay to show the close buttons, that delay is a one-off, unlike HyperSwitch. Once they show, you can mouse in and out and they show up instantly. It's a global flag basically.

Overall, I'm unconvinced it's clearly better. It would prevent some accidental clicks, but would also introduce new accidental clicks. If the buttons appear right when you click, and your mouse is over the cross button, then you will be surprised and it will close the window. Having everything appear instantly actually shows all info upfront and avoid that issue. It does however have the issue where you move to a window to focus it and click quickly and interact with the buttons by mistake. So pros-cons on both designs.

I would also note that both MC and HS have only the close buttons, which make their UI smaller, at the cost of functionality.

As an app named for a keyboard shortcut, I would think that the primary focus would be on keyboard shortcuts?

The name of the app is not driving design. If there is a way to improve the UX that involves more mouse usage, it will be added of course.

A visual way to manipulate windows already exists in the form of Mission Control

Mission Control doesn't have many of the properties of AltTab. Windows are not in chronological order, and many more. Also a lot of users say they want one app to handle all their window management, and not multiple apps. That's a really common feedback I read from users.

If a user already needs to use a keyboard shortcut to invoke the application, it's counterintuitive to me to make them then use their mouse

I think this line of thinking is flawed. All alternative apps, including all OS built-in ones have mouse hover and mouse click to interact with the windows.

Honestly this does make sense to me, but I think that you should be a little bit more opinionated then with what features you add. By necessity, adding more features is going to mean more options -- if you want less options then I think you should avoid what is (in my eyes at least) feature bloat.

I think it is a bit ironic that you suggest for a more opinionated app, when the opinion I had to show these buttons does not suit you, and you are asking now to modify it. I could remove them entirely, and now other users would be sad to lose that feature. Being opinionated means picking a side. Preferences allow to keep both sides empowered. I thought here I could avoid the preference because it is not a very intrusive feature. For example, having the app start at login is very intrusive, so of course it should be a preference, not an opinion on my side. But then there are low impact things like the color of the shadow around text. I try to avoid preferences for non-intrusive features, unless users start complaining because their preference is on the other side of the fence. Then after we discuss usually I would add the preference because I would rather have too many preferences than not empower all users. That philosophy is in itself an opinionated stance from me, ironically. That opinion can be criticized by citing famous apps with ungodly preference UIs because the authors allow extreme customization. There is no perfect approach

Another idea if you don't want to clutter the options menu is to use "hidden options" accessed by command line, similar to Rectangle -- see the Readme for details. These preferences are set by the defaults write terminal command, so you could make them a little bit more complicated, for advanced users only.

I dislike this very much, as I want users to be able to discover all the app has to offer organically, not by going online on some wiki. I have plans to rework the preferences at some point. The current winning strategy when discussing with other users (#351) is to have Simple/Advanced modes. When switching to advanced, the user unlocks a pletora of fine-tuned preferences to really go deep in customizing their experience. Of course, which settings are Simple and which are Advanced will require opinionated selection. Because AltTab has no telemetry (on purpose), usage can't decide either. It has to be a contributor, probably me

I wanted to share my thoughts, and I realize this response is getting big. As a bottom line: I will implement a preference to hide these new buttons.

[kushagr-m]

Thanks for your detailed response. I understand why you chose to add this feature and I also understand now the care you took in finding the best functionality here. To be fair to you, I may have misunderstood the goals of this app. As you say, there is no perfect approach to app design and you can't make everyone happy.

With that said, thank you for hearing me out and getting into this discussion

[lwouis]

I'm closing this ticket. I decided that the resizing/moving of windows is best handled by other tools. I have seen pretty much no request for this, and it would clutter the UI a lot.

I'll probably open more tickets to add for example mouser hover effects on the colored circles, and polish like this, but this big ticket should now be closed, as its scope is mainly implemented by now.