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
from

Conversation

@franglais125
Copy link
Contributor

commented Aug 21, 2017

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 (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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 5, 2017

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

@micheleg What do you think?

@jacopo1395

This comment has been minimized.

Copy link

commented Nov 28, 2017

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

This comment has been minimized.

Copy link
Contributor Author

commented Nov 30, 2017

@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!

@jacopo1395

This comment has been minimized.

Copy link

commented Dec 28, 2017

I reinstalled the extension and now it works fine.

@franglais125 franglais125 force-pushed the franglais125:hover_preview branch from 862a1a0 to 70fb794 Jan 6, 2018
@franglais125

This comment has been minimized.

Copy link
Contributor Author

commented Jan 6, 2018

Rebased following the code reorganization!

@micheleg

This comment has been minimized.

Copy link
Owner

commented Jan 18, 2018

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

This comment has been minimized.

Copy link
Contributor Author

commented Jan 18, 2018

  • 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

This comment has been minimized.

Copy link

commented Jan 18, 2018

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

commented Mar 5, 2018

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

This comment has been minimized.

Copy link
Owner

commented Mar 31, 2018

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

@runningnak3d

This comment has been minimized.

Copy link

commented Apr 1, 2018

@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 franglais125 force-pushed the franglais125:hover_preview branch from 70fb794 to b76e840 Apr 2, 2018
@franglais125

This comment has been minimized.

Copy link
Contributor Author

commented Apr 2, 2018

@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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link

commented Jun 10, 2018

Any news here?

@franglais125

This comment has been minimized.

Copy link
Contributor Author

commented Jun 10, 2018

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

This comment has been minimized.

Copy link

commented Jun 20, 2018

+1 Hope to see this soon :)

franglais125 added 10 commits Jul 13, 2017
Most of the functions are imported from dash-to-panel, and are adapted
where appropriate.
This is so that this is not triggered when hovering.
We add a timeout to ungrab the actor, and we manually trigger
'enter-event' for appIcons.

When moving from the (open) menu to the dock, the grabHandler is still
active, and hover notifications are not properly propagated.

Idea imported from dash-to-panel and adapted.
We need to adapt the MenuManager behavior with respect to
'open-state-changed' handling. The behavior depends on whether the menu
was opened on click or on hover.
@franglais125 franglais125 force-pushed the franglais125:hover_preview branch from b76e840 to 3420343 Aug 3, 2018
@micheleg micheleg added this to In progress in dash-to-dock Aug 26, 2018
@xgdgsc

This comment has been minimized.

Copy link

commented Sep 21, 2018

Hoping this get merged !

@runningnak3d

This comment has been minimized.

Copy link

commented Oct 8, 2018

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.

@thenewnano

This comment has been minimized.

Copy link

commented Oct 22, 2018

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 ?

@uocxp

This comment has been minimized.

Copy link

commented Jan 29, 2019

any news ?

@Fmstrat

This comment has been minimized.

Copy link

commented May 7, 2019

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.

@viggy96

This comment has been minimized.

Copy link

commented Jul 1, 2019

It would be awesome to get this merged!

@viggy96

This comment has been minimized.

Copy link

commented Jul 10, 2019

Once again, hoping that this feature gets merged! This feature would be amazing to see finally implemented.

@Horus125

This comment has been minimized.

Copy link

commented Jul 11, 2019

This feature makes and already awesome extension even more awesome - great job! I'm really hoping it gets merged soon!

@viggy96

This comment has been minimized.

Copy link

commented Jul 23, 2019

Is work ongoing to get this feature merged? I think this is probably the feature many are looking forward to.

@viggy96

This comment has been minimized.

Copy link

commented Jul 24, 2019

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.

@elpraga

This comment has been minimized.

Copy link

commented Aug 7, 2019

Any updates on this one? Is there a chance it gets merged?

@viggy96

This comment has been minimized.

Copy link

commented Aug 9, 2019

Is there any movement on this issue? Is there anything the community needs to do to help do this?

@viggy96

This comment has been minimized.

Copy link

commented Aug 10, 2019

Is there anyone with the proper permissions on this repository who can help resolve conflicts and merge this in?

@viggy96

This comment has been minimized.

Copy link

commented Aug 12, 2019

Is this repo even active anymore? Is there no one with the proper repository permissions to help merge this in?

@viggy96

This comment has been minimized.

Copy link

commented Sep 8, 2019

Is there anyone in this repository who can work to try to merge this? Is a fork necessary to revive this project? The work has been put in by a community member, and yet this long-awaited feature still hasn't been merged in.

@franglais125

This comment has been minimized.

Copy link
Contributor Author

commented Sep 8, 2019

Just dropping by: I won't be able to work on this for the foreseeable future. Two young toddlers are taking most of my time (and understandably so). Anyone else feel free to take over in the mean time.

I haven't touched this branch in a long time, and it will for sure need some rework given the changes to the extension and general "API".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
dash-to-dock
  
In progress
You can’t perform that action at this time.