dash-to-dock
dash-to-dock copied to clipboard
micheleg
Show window previews on mouse hover
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 (https://github.com/jderose9/dash-to-panel/issues/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.
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.
@0matgal0 Thanks for the suggestion. I think it makes sense, as the overview shows all previews already.
@micheleg What do you think?
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.
@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!
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.
- 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:
- Would you like to add some configuration options? Specifically for size and timeouts.
- @jderose9 if you don't mind me tagging you, any suggestions for us over here? This is based on your work after all :)
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.
@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.
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!
@runningnak3d I guess this would the win windows peak like behaviour which can be found in dash-to-panel?
@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
@micheleg Here is a new rebase. There is only one new commit: [b76e8409f96d721f2d74f2ef95498515ca8f470a], 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 [50fb364cca22c017ba576dfb9286946853859866] (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!
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.
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.
Just curious if Dash to Dock crashes on login with this patch applied for anyone else.
I am running Gnome 3.30, but without systemd -- so before digging to hard, I wanted to see if it worked on 3.30 at all.
I would rally like to see this get merged, Specifically hoping the feature #639 " do not reorder windows" I did look into the changes proposed but did not see that change explicitly is it included @franglais125 ?
Hey, just checking in on this as I was about to file an issue and ran across this in a closed one. Dash to Panel has been getting some press lately, made me remember I was looking for this type of feature.
Once again, hoping that this feature gets merged! This feature would be amazing to see finally implemented.
This feature makes and already awesome extension even more awesome - great job! I'm really hoping it gets merged soon!
Is work ongoing to get this feature merged? I think this is probably the feature many are looking forward to.
I don't think it would be an overstatement to say that there is a lot of community support for this feature to finally get merged.
Is there any movement on this issue? Is there anything the community needs to do to help do this?