Show window previews on mouse hover

[franglais125]

A few things to say about this:

• Credit goes to @jderose9; most of this code was taken and adapted from dash-to-panel.
• Comments and suggestions are obviously welcome. I'm sure there a different approaches for a few things here.
• In particular, I'd love to get some feedback from people running on Gnome 3.24+. There is an open issue for dash-to-panel (gnome-shell crashes when an app window is closed home-sweet-gnome/dash-to-panel#170), that could very well be related to this feature. I tried a few times to help over there but could never really pinpoint the source of the problem. Apparently this affects only people running on 3.24+ (and more so on Wayland), hence the request for testing.
• I tried to keep the commits organized, to show why each change was introduced.

Cheers! Hope you like this.

[0matgal0]

Maybe on Activites overview it shouldn't trigger (and revert to click to show preview behaviour)? It's quite easy to trigger the hover by accident when going to activites, which then makes it hard to select a window in overview.

[franglais125]

@0matgal0 Thanks for the suggestion. I think it makes sense, as the overview shows all previews already.

@micheleg What do you think?

[jacopocarlini]

I'm testing this version and it's great. I found a bug (I do not know if it is known): when setting "dynamic" or "adaptive" transparency with the dock in bottom position, the rounded corners are wrong.

The corner to top left is NOT rounded, instead the corner to BOTTOM right is rounded.

[franglais125]

@jacopo1395 Thanks for the feedback on window previews.

I'm testing this version and it's great. I found a bug (I do not know if it is known): when setting "dynamic" or "adaptive" transparency with the dock in bottom position, the rounded corners are wrong.

The corner to top left is NOT rounded, instead the corner to BOTTOM right is rounded.

I cannot reproduce this, but if you can do so consistently, please open a new issue!

[jacopocarlini]

I reinstalled the extension and now it works fine.

[franglais125]

Rebased following the code reorganization!

[micheleg]

Thanks for rebasing the branch. I'm running this for test so I'll add few comments:

• the previews are huge! (I see that they scaled based on the screen size to 1/5 of the screen which is smart, but that seems too much for me).
• For test I set a long HOVER_ENTER_TIMEOUT (~750ms) because I don't want the previews to appear immediately (personal preference). I notice that this situation occurs: I open the right click menu but also the windows previews get shown soon after.

[franglais125]

• the previews are huge! (I see that they scaled based on the screen size to 1/5 of the screen which is smart, but that seems too much for me).

I personally found it was more comfortable to have them a bit larger, but this might be due to my (very) crappy screen. It was simply hard to distinguish what was inside the previews.

Besides the default size we use (1/5, which we can change obviously), would you keep the "based on screen size" approach?

• For test I set a long HOVER_ENTER_TIMEOUT (~750ms) because I don't want the previews to appear immediately (personal preference). I notice that this situation occurs: I open the right click menu but also the windows previews get shown soon after.

You are rather right here... I set it to 100ms by default, which seems a bit low. I don't really know what the best value would be. I expect users would want the previews to show up rather quickly if they are going to use them for window navigation. A compromise can surely be found in an intermediate value.

---

Now, regarding both issues:

1. Would you like to add some configuration options? Specifically for size and timeouts.
2. @jderose9 if you don't mind me tagging you, any suggestions for us over here? This is based on your work after all :)

[jderose9]

In dash-to-panel, timeout is already an option, but not size. But, even with a long timeout, I don't see the preview pop up if the secondary menu is open (in dash-to-panel). I could be wrong, but I can't find specific code to handle this. Perhaps either the leave event is firing when the secondary is opened, cancelling the timeout or the grab helper is blocking some events, or something along those lines.

The preview size is fixed at 350x200 but could be set with _thumbnailWidth/_thumbnailHeight properties in thumbnailPreview class. The thumbnail is recreated each time it is displayed so just setting the new value should be enough. There's an outstanding issue in the tracker asking for this, but it hasn't been completed yet.

PS.. In the interest of not taking undue credit - while I've made some changes/fixes, this code came originally from ZorinOS.

[emilioea]

@franglais125 I've been testing your version and so far it all seems to work very well. I'm very happy with the default 100ms delay, I wouldn't want to wait any longer.

Would it be possible to keep the order of the previews in the same order the windows were open? To me it is a bit distracting that the order changes to the most recent used first.

[runningnak3d]

Is it possible to dim (or hide) all the other windows except the one that you are hovering over? This would allow you to take a peek at what is going on without have to activate the window.

Probably outside the scope of this PR if it is even possible at all...

Thanks so much for adding this very useful feature!

[micheleg]

@runningnak3d I guess this would the win windows peak like behaviour which can be found in dash-to-panel?

[runningnak3d]

@micheleg I have not used dash-to-panel, but it would be like the old Windows 7 "aero peek". I hate MIcrosoft, but that was a very useful feature. If dash-to-panel has something equivalent, then I would love to see it ported.

-- Brian

[franglais125]

@micheleg Here is a new rebase. There is only one new commit: [b76e840], it addresses the last issue you mentioned with overlapping menus and previews.

As listed before, here are two more things that I leave up to your preference/discretion:

• windows preview size is currently set to a max of 20% of screen size [50fb364] (e.g. this commit could simply be dropped)
• hover timeout, which is set to 100ms, while you would rather have a bigger value (you suggested ~750ms)

---

@emilioea It is certainly possible to keep the order constant (i.e. use a time-based ordering). You can have a look here: https://github.com/jderose9/dash-to-panel/blob/master/windowPreview.js#L1122. We simply need to change that in our windowPreview.js function. I didn't change this as this is the way we were already doing it for the previews we had. @micheleg any preference for this? I personally like better the time-based approach.

---

@runningnak3d it would certainly be very nice to have the window-peek feature here as well. At the moment I can't commit to making a (quality) port of the code, sorry!

[rugk]

As for the size and timing values, I think they should be configurable by the user just as the timing for showing the whole dock.

[rugk]

Any news here?

[franglais125]

I haven't had time to work on this lately, sorry to say. This branch "works", but I think it could also see some improvements still.

[jamesst20]

+1 Hope to see this soon :)

[naanlizard]

As of recently they've added it, and it's a good upgrade! I'll giving it a whirl. Thank you for the suggestion

[FSpark]

As of recently they've added it, and it's a good upgrade! I'll giving it a whirl. Thank you for the suggestion

Really? don't know where to see it yet...

[viggy96]

Seeing as this will take a long time, would it be much easier in the meantime to just add an option to have the "all windows" submenu open by default, if the user has window previews enabled? That would honestly be good enough to satisfy the vast majority of users asking for this feature. Of course, it might not be the ideal, but its much easier, considering all the work is already there. There just has to be an option to have the menu open by default, rather than closed, and requiring an extra click.

[viggy96]

I actually just noticed that there is a "show window previews" option under "click actions". Right now I have it bound to middle click, but that UI looks perfect for showing when hovering over an icon in the dock. Is there a way for dash to dock to capture the "hover" event and show the same dialog that it shows when you use the "show window preview" click action?

For others who read this, using middle click or right click to show the window preview is a great workaround until the hovering thing is merged in.

[mj0ln1r]

I actually just noticed that there is a "show window previews" option under "click actions". Right now I have it bound to middle click, but that UI looks perfect for showing when hovering over an icon in the dock. Is there a way for dash to dock to capture the "hover" event and show the same dialog that it shows when you use the "show window preview" click action?

For others who read this, using middle click or right click to show the window preview is a great workaround until the hovering thing is merged in.

Oh, it works. Thank you.

[yashkumar1803]

Hi, is there any update on this feature? Thank you.

[dev-bre]

is there any update on this feature?

[hohfchns]

I actually just noticed that there is a "show window previews" option under "click actions". Right now I have it bound to middle click, but that UI looks perfect for showing when hovering over an icon in the dock. Is there a way for dash to dock to capture the "hover" event and show the same dialog that it shows when you use the "show window preview" click action?
For others who read this, using middle click or right click to show the window preview is a great workaround until the hovering thing is merged in.

This works but it would be much more intuitive to just hover, especially since hover currently does nothing other than show the application's name

[lucas-marx]

still nothing?

[Nirzak]

More than 4 years have been passed! Isn't there anyone to merge this into the main code? Looks like it will never be merged :(

[rodrigoGA]

if there is priority by waiting time, the priority of this merge request should be critical

[wgorski]

It's actually a shame that @franglais125 did all the work, implemented an awesome and much needed feature and no-one had the time to merge it.
To the maintainers: Is there a specific problem with this feature?

[ghost]

Hey! Someone merge it?

[alexeymuranov]

Hey! Someone merge it?

Someone fork it? :)

[CodeWithShreyans]

@3v1n0 @micheleg Why not merging???

[reginaldoboeke]

Is there any update on this feature?

[warent]

Shocked to see no response. Even a rejection would be better than silence at this point :(

[tomikaka22]

bump.

[mkalitka]

That would be a nice feature to have, please merge that

[Revadike]

Bro, why not merging? Wtf?

[dechimp]

I'm not sure how to view the merge conflicts this has with the master branch, but maybe fixing those would help. Still no guarantee that the maintainer will give it attention.
@micheleg 's account has been inactive over a year. @3v1n0, can we get a status update?

[rugk]

I'm not sure how to view the merge conflicts this has with the master branch

Might only be possible as the author but you can do it online on GitHub. Otherwise, if the OP cannot do this or has abandoned this PR; you can likely also fork this PR (or rather this branch), create a new PR and do the same. Something like this…
Or use GitHub Codespaces to have a quick VM, where you can change stuff…

Aka:

[jwaxy]

still no progress?

[chrischriscris]

2024 bump

[quiellll]

omg still nothing... it's been years 😞

[Nirzak]

Yeah definitely a much needed feature still waiting for a long time.

[palexdev]

@micheleg any reason for this still not being a thing?