Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show window previews on mouse hover #574

Open
wants to merge 11 commits into
base: master
Choose a base branch
from

Conversation

franglais125
Copy link
Contributor

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
Copy link

0matgal0 commented Nov 5, 2017

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
Copy link
Contributor Author

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

@micheleg What do you think?

@jacopocarlini
Copy link

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
Copy link
Contributor Author

@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
Copy link

I reinstalled the extension and now it works fine.

@franglais125
Copy link
Contributor Author

Rebased following the code reorganization!

@micheleg
Copy link
Owner

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
Copy link
Contributor Author

  • 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
Copy link

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
Copy link

emilioea commented Feb 14, 2018

@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
Copy link

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
Copy link
Owner

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

@runningnak3d
Copy link

@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
Copy link
Contributor Author

@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
Copy link

rugk commented Apr 2, 2018

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
Copy link

rugk commented Jun 10, 2018

Any news here?

@franglais125
Copy link
Contributor Author

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
Copy link

+1 Hope to see this soon :)

@FSpark
Copy link

FSpark commented Feb 19, 2020

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
Copy link

viggy96 commented Jun 17, 2020

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
Copy link

viggy96 commented Jul 13, 2020

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
Copy link

mj0ln1r commented Oct 3, 2020

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.

@somepaulo somepaulo mentioned this pull request Oct 10, 2020
@yashkumar1803
Copy link

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

@dev-bre
Copy link

dev-bre commented Jun 3, 2021

is there any update on this feature?

@hohfchns
Copy link

hohfchns commented Jul 9, 2021

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
Copy link

still nothing?

@Tuxman2 Tuxman2 mentioned this pull request Sep 22, 2021
21 tasks
@Nirzak
Copy link

Nirzak commented Nov 9, 2021

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
Copy link

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

@wgorski
Copy link

wgorski commented Nov 10, 2021

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
Copy link

ghost commented Nov 25, 2021

Hey! Someone merge it?

@alexeymuranov
Copy link

Hey! Someone merge it?

Someone fork it? :)

@CodeWithShreyans
Copy link

@3v1n0 @micheleg Why not merging???

@reginaldoboeke
Copy link

Is there any update on this feature?

@warent
Copy link

warent commented Aug 2, 2022

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

@tomikaka22
Copy link

bump.

@mkalitka
Copy link

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

@Revadike
Copy link

Bro, why not merging? Wtf?

@dechimp
Copy link

dechimp commented Aug 10, 2023

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
Copy link

rugk commented Aug 15, 2023

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:
Open in GitHub Codespaces

@jwaxy
Copy link

jwaxy commented Nov 10, 2023

still no progress?

@chrischriscris
Copy link

2024 bump

@quiellll
Copy link

quiellll commented May 4, 2024

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

@Nirzak
Copy link

Nirzak commented May 5, 2024

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

@palexdev
Copy link

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

@julioapv
Copy link

2024 bump, I wish it gets merged soon :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.