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

Feature Proposal: Remove titles from thumbnails, add dynamic horizontal sizing #611

Open
alex285 opened this issue Mar 26, 2019 · 43 comments

Comments

Projects
None yet
8 participants
@alex285
Copy link

commented Mar 26, 2019

this is really a proposal rather a request, b/c even if that feature was available, im not sure i would be using it; i have to see it in actual use :)

consider the next case that we have a two windows of the same or of a different app, that one consumes more space horizontally, and the other more space vertically (eg a tiled window)

Screenshot from 2019-03-26 12-50-11

Dash to Panel will currently use the same horizontal space for both previews. that makes some sense b/c less width won't fit the title (or trim it too much to read)

to my use i notice that i rarely pick windows on the titles, but mostly pay attention on the thumbnail

so the proposal is to be a single option that removes the titles bellow the thumbnails, and also adjust the padding depending window size. in this case the second Tilix preview should had less left/right padding

im a bit lazy to boot on W10 to see how they handle that, but im pretty sure they use dynamic horizontal sizing depending window proportions

@charlesg99

This comment has been minimized.

Copy link
Member

commented Mar 27, 2019

Hey alex285, thank you for the suggestion! Yeah right now we are scaling the thumbnail based on the set preview dimensions, but it might be worth a try to see it scaled the other way around (based on the actual window dimensions). Is Windows doing it much differently (can't remember)? Seems related to #576. Thanks!

@jderose9

This comment has been minimized.

Copy link
Member

commented Mar 28, 2019

Windows will reduce the height as much as it can to fit a preview of all the windows at their original aspect ratio. ie. if there's a single window in the preview and it is more wide than narrow, it will reduce the preview popup height so that there is a thin border all the way around. With multiple windows containing mixed aspect ratio, you would get a larger gap above/below the windows with a wider aspect ratio.

@charlesg99

This comment has been minimized.

Copy link
Member

commented May 17, 2019

Hey guys, I started playing with the previews to remove the extra padding (although we can preserve the option to have fixed sizes) and I'm looking for some feedback on the animations I have so far:

Peek 2019-05-17 01-17

I had to ditch the use of the popup menus for the previews, so there is no input grab with this (which is personally the reason I'm working on this). Sorry about the gif, no cursor for god knows what and it is a bit choppy. What do you think? Thanks!

@alex285

This comment has been minimized.

Copy link
Author

commented May 17, 2019

is there somewhere the code we can try it? the only feedback i can tell by watching the gif is "WOW!!!" :)

@digiberk

This comment has been minimized.

Copy link

commented May 18, 2019

I love it. That's the way it should be!

@charlesg99

This comment has been minimized.

Copy link
Member

commented May 18, 2019

Great, I'll keep at it and push to a branch when it is "usable". It's a long weekend here in Canada, so hopefully I'll have some time to work on it, eh?

@alex285

This comment has been minimized.

Copy link
Author

commented May 21, 2019

i'll spam this a bit, but to give some additional feedback ..not even my videos get 100 likes :)))

Screenshot from 2019-05-21 04-27-33

..apart those i demo Dash to Panel :)

@charlesg99

This comment has been minimized.

Copy link
Member

commented May 21, 2019

@alex285 Hey awesome! Thanks for sharing and cool video! I'm pretty much done with the new previews, only need to tidy up/connect the settings and I'll be ready to push. Stay tuned :)

@charlesg99

This comment has been minimized.

Copy link
Member

commented May 24, 2019

The first version of the new previews is available on branch "custom-window-preview". Here be dragons!

To install:

git clone https://github.com/home-sweet-gnome/dash-to-panel.git
cd dash-to-panel
git checkout custom-window-preview
make install

Then Alt-F2 -> 'r' to restart gnome-shell or log out/in if on Wayland.

Feedback and testing will be appreciated, Thanks!

@HelpMeRuth

This comment has been minimized.

Copy link

commented May 24, 2019

just to leave my first impressions:

  1. the borders inherit the global opacity, making it look kinda weird over white backgrounds.
    So i suggest having optional separate styling(opacity / color) for it.
  2. Seems like it forces a fixed height even when the previews itself are smaller.
    So i suggest making the height dynamic just like how its awesomely done with the width

thats it! thanks for this amazing work :)

@n1lt0n

This comment has been minimized.

Copy link

commented May 24, 2019

I love it !!!! thx!!!!!

@xela92

This comment has been minimized.

Copy link

commented May 24, 2019

The first version of the new previews is available on branch "custom-window-preview". Here be dragons!

To install:

git clone https://github.com/home-sweet-gnome/dash-to-panel.git
cd dash-to-panel
git checkout custom-window-preview
make install

Then Alt-F2 -> 'r' to restart gnome-shell or log out/in if on Wayland.

Feedback and testing will be appreciated, Thanks!

Testing it right now, this is the best looking window preview EVER. I reaaaally love it. Very fluid animations, behaviour is perfect. Maybe the only thing I'd change is the close window button background, think a little brighter would be cute.

anyway, it rocks!!! :-D

@charlesg99

This comment has been minimized.

Copy link
Member

commented May 25, 2019

Thank you for the feedback! Glad it's working good on your end!

So i suggest making the height dynamic just like how its awesomely done with the width

I played with that quite a bit and concluded that a single size would be easier to understand as a user setting. Under the hood, the window is scaled up as much as possible within a 16:9 ratio. I had to limit that somehow, otherwise a very large window (having, say, a 10:1 ratio) could've potentially filled your screen sideways. Over the weekend I'll try to see if I could reduce/animate the height of the previews container to fit the height of its taller window.

So i suggest having optional separate styling(opacity / color) for it.

Yeah I wasn't quite sure about what to do with the colors :) I kinda wanted it to work based on the panel color/opacity and so I'm using that as a base for the preview color variations. Looks cool in front of an empty desktop with a nice background, but I agree that it isn't really what people see most of their day. Maybe we could define a minimum opacity for the previews (like 20% or something), even if the panel is set to be almost transparent?

Maybe the only thing I'd change is the close window button background, think a little brighter would be cute

I tried to make the close button's background a little brighter instead of darker! I pushed the change to the branch, let me know if you like it better!

Thanks!

@ddnexus

This comment has been minimized.

Copy link

commented May 25, 2019

Great improvements overall! Thank you!

The animation of the switch-to-window are super smooth now even when they are on different desktop! That's great!

A few comment/issues:

  • The lighter background color for the close booton on the preview may look quite ulgy and it is a noticeable exception to the overall theme used for the OS.

    1. The icon used seems to be the wrong one for the different usage. Instead of picking the regular close icon used in all the window title-bars (as it should be, since now the icon is on a title bar and not on the window itself), it picks the icon used to close the window previews displayed in the overview. That is a big icon in most themes (since it is overlapping to usually big preview windows), while in the little frame of DtP looks really huge.
    2. DtP should not add any different background color just for that icon, since while it might look nice in your specific theme may look really ugly and out of style in most others. Please, "If ain't broken don't fix it!" ;)
  • If you preview-focus a file window (e.g. nautilus) and start to type... it will type in the actual window, causing the window to search.. and getting an fatal error in the file app. The user interaction with the preview should not be passed to the actual window.

  • Sometimes for some reason that looks random, if you have multiple windows for an app (tried in Nautilus), it refuses to select-focus one of them. That is seldom happening but I will keep an eye on it, trying to find a way to reproduce the behavior.

  • The contextual menu for the miniature windows is gone. Is that a need, a choice or just a glitch?

@ddnexus

This comment has been minimized.

Copy link

commented May 25, 2019

Another glitch of this branch is that if you use autohide, it will hide the bar even if you are hovering on one of its menu, leaving the menu visible and hiding the bar.

@HelpMeRuth

This comment has been minimized.

Copy link

commented May 25, 2019

(white on black for max contrast)
maximized program:
image
smaller program:
image
wide program:
image

what about just keeping the 16:9 scaling but at the end you just omit the empty space? i really don like the inconsistent borders :)

about theming, i think limiting the opacity is a good idea(or maybe just make it user configurable). It also might be cool to make it follow the dominant icon color (if enabled), more color is more happy :P

@ddnexus

This comment has been minimized.

Copy link

commented May 25, 2019

@HelpMeRuth

more color is more happy

unless you have migraines triggered by color brightness and contrast, in which case less color and less contrast is more happy (e.g. Equilux Theme)

@charlesg99

This comment has been minimized.

Copy link
Member

commented May 27, 2019

Hello, some visual tweaks to the opacity and an option to dynamically reduce the size of the preview containers were added to the branch if you'd like to try. Thanks!

@ddnexus

This comment has been minimized.

Copy link

commented May 27, 2019

Thanks for improving the background for the preview bar and removing the exception for the close box!.

Is the " option to dynamically reduce the size of the preview containers " the "Use a fixed size for the window preview"? I don't see any difference: it always adjust the size of the container to the window shape, and I would rather disable that because the scale of the previews windows is variable for each window and it is confusing. (e.g. when you search for a small window, you cannot find it because it has been scaled up to the available size).

I understand that scaling the window may be better for viewing more details, but I rather prefer to have the container fixed (to a screen-size shape) and the window displayed in the original proportion and positioned as it is on the screen. A lot easier to find in my case. I can identify the position and size better than the content, that is very small and often very similar.

@HelpMeRuth

This comment has been minimized.

Copy link

commented May 27, 2019

I'm not seeing any difference between enabled / disabled with "Use a fixed size for the window preview" as well

@charlesg99

This comment has been minimized.

Copy link
Member

commented May 27, 2019

Hum weird, this is how it looks like over here (same windows, tried on g-s 3.22, 3.28 and 3.32):

Disabled, so it dynamically resizes:

Peek 2019-05-27 08-12

Enabled, so it uses a fixed size:

Peek 2019-05-27 08-14

The behavior should be something like this: it scales down the window while respecting a maximum aspect ratio of 16:9, so i.e., if a window has a 18:6 ratio and the option is set to "fixed size", the preview will be centered in the preview's frame, but the height of the frame will remain the same. If the "fixed size" option isn't set, the height of the frame is reduced to fit the preview. Also, when "not fixed", if there are more than one preview in the frame, the taller one defines the height of the frame and the other ones are centered. Hope that makes sense.

@ddnexus

This comment has been minimized.

Copy link

commented May 27, 2019

I like the fixed behavior!

Why a hard-coded aspect ratio? For me is fine, but it would be weird for screens with a different aspect ratio. The ideal way should be getting the aspect ratio from the screen automatically, not sure if that is possible or easy tough.

@HelpMeRuth

This comment has been minimized.

Copy link

commented May 27, 2019

ahh! my bad didnt notice it because i didnt have long ratio'd windows haha.
the only issue standing for me:
chrome maximized:
image
discord normal sized
image
telegram normal sized:
image
g tweaks normal sized:
image
tilix normal sized:
image
tilix maximized:
image

from my small test it seems like non gtk apps work fine(kinda they still have a 1px padding around them when not maximized even tho the padding is set to 0px) but gtk apps have some thick padding around themselfs when not maximized

(note: i tweaked the MIN_MENU_ALPHA to 0.8 within the code which is i think my preferred level)

@ddnexus

This comment has been minimized.

Copy link

commented May 27, 2019

@charlesg99 it still does not work here.

What should happen with a very tall window and a very wide window of the same application with fixed size? I would expect to see two equally sized containers; one with a tall window with a lot of space on its sides and another with a wide window with a lot of space above and below.

@HelpMeRuth

This comment has been minimized.

Copy link

commented May 27, 2019

@ddnexus
with "Use a fixed size for the window preview" ENABLED it makes the height always the same (defaults to 240) just like how it was in the beginning(so dynamic width only iirc).
When you DISABLE it makes the height dynamic just like the width so there's supposedly minimal empty space in the preview container but still is limited by the set max height
you can see it in the gif's above and my screenshot from discord

@HelpMeRuth

This comment has been minimized.

Copy link

commented May 27, 2019

Disabled:
image
Enabled:
image

@ddnexus

This comment has been minimized.

Copy link

commented May 27, 2019

@HelpMeRuth thanks, but what about the example in my previous post? Could you post a screenshot? Than you

@HelpMeRuth

This comment has been minimized.

Copy link

commented May 27, 2019

using kid3, qt doesnt seem to have resize limits (stupid :p)
height test->
DISABLED:
image
ENABLED:
image

hmm haha it seems like the toggle only counts for height not width, so it doesnt seem to be how you'd like it yet.

width test ->
DISABLED:
image

ENABLED:
image

conclusion: "fixed" only counts for height, width is still dynamic (according to this issue's original request)
note: the telegram desktop is a folder name not a bug

@ddnexus

This comment has been minimized.

Copy link

commented May 27, 2019

Thank you @HelpMeRuth. Now I understand why I don't see any difference!

@charlesg99 what is the point of "fixed" if the width is never fixed? As I said in a previous comment, you want to use "fixed" in order to have the window miniature in the context of the (full-screen-like container), easy to pick/identify because it does not force you to understand the content, but just remember the size/position of the window. If you change the relative window scale and the container shape then it defeats its purpose! "Fixed" should be... "fixed" IMO. :)

Personally, I don't see any advantage on saving horizontal real-estate on horizontal screens, unless you have a zillion windows opened for the same app (and in that case good look spotting it anyway), but with the fixed option working properly, it will not be a problem.

@HelpMeRuth

This comment has been minimized.

Copy link

commented May 27, 2019

but with the fixed option working properly, it will not be a problem.

+1 fixed size should actually mean fixed size,
what about 2 toggles for dynamic width and height? this should resolve all conflicts in interest

@charlesg99

This comment has been minimized.

Copy link
Member

commented May 29, 2019

Sorry guys, I'm still thinking about how to present all the options to the users... The thing about the current "size" value is that it works and is easy to understand if the panel is horizontal (height of the preview) OR vertical (width of the preview). Currently the previews "should" work if/when the option to set the panel vertically is added in the future.

I'm leaning towards offering the following options, which I think would allow all configurations while removing the hard coded aspect ratio (currently defined by the dimensions of the primary monitor):

  • Size (numeric value, default 240)
  • Aspect ratio X (numeric value, default 16)
  • Aspect ratio Y (numeric value, default 9)

Both aspect ratio values could be set to "Fixed" with a switch, So as examples, on a horizontal panel:

The current "Fixed" behavior would be obtained by setting:
Aspect ratio X not fixed
Aspect ratio Y fixed

The current "Not Fixed" behavior would be obtained by setting:
Aspect ratio X not fixed
Aspect ratio Y not fixed

The desired (and undesired as per this original issue ;) "All fixed" behavior would be obtained by setting:
Aspect ratio X fixed
Aspect ratio Y fixed

Does it make sense? Any thoughts? My main concern is presenting this to the users in an easy to understand way, while allowing as much customization as possible.

Thanks!

@ddnexus

This comment has been minimized.

Copy link

commented May 29, 2019

With just a couple of field + switch you offer all the possible configurations. That's really the widest customization possible with the minimum input required. Great for the user! I don't know how tricky for you though. :)

@ddnexus

This comment has been minimized.

Copy link

commented May 29, 2019

I report this here, because it looks like only this branch is affected.
Commit a3c8da8 broke the persistency of the intellihide when hovering on the system menus of the panel.

@charlesg99

This comment has been minimized.

Copy link
Member

commented May 29, 2019

Ha sorry about that @ddnexus, you are right! I didn't correctly understand the intellihide issue you were reporting. This should now be fixed. Thanks!

@ddnexus

This comment has been minimized.

Copy link

commented May 29, 2019

Glad to have found a better way to explain the problem. It works! Thank you!

@ddnexus

This comment has been minimized.

Copy link

commented May 29, 2019

Just to remember a minor cosmetic glitch/improvement.

The close icon of the preview window is the same icon the window gets in the overview. That was kind of ok with the old preview because it was displayed over the window thumbnail, but now that it is displayed in a bar, it should be switched for the close title bar icon. The overview's icon is bigger in most themes and it looks quite out of proportion (and style) when it appears in a bar.

@charlesg99

This comment has been minimized.

Copy link
Member

commented May 30, 2019

The new sizing options were added, but I wonder if it is easy enough to understand. Could you please try playing with those and see if they make sense?

@ddnexus

This comment has been minimized.

Copy link

commented May 30, 2019

It looks nice and logical, however it may not behave as one would expect - depending of what one would actually expect of course :).

The fixed width is working as expected and on a horizontal frame the effect is evident, however the fixed height on an horizontal frame is not actually so spectacular, since it's easy obliterated by any other window of the same app with a different proportion.

Another thing about the fixed-fixed option: the scale and position of the windows inside the frame (that is supposed to represent the screen) is modified anyway. I was expecting to see the actual window/screen proportion not altered, but I am not sure whether that would make sense anymore.

In conclusion, all that settings for one small difference might be a burden for maintenance and we may have asked you too much. I'm fine with anything makes sense to you at this point. We have already more than what we may ask for.

DtP is really amazing! Thank you!!!

@HelpMeRuth

This comment has been minimized.

Copy link

commented Jun 7, 2019

have you looked into this bug?
where gtk apps have a bigger padding around them than non gtk apps, when i set padding to 1px the following happens:
maximized windows:
image
non gtk normal window:
image
gtk normal window:
image

apart from this I have no other problems, been using it ever since the code dropped :)
maybe a slight annoyance is that windows get unfocused when using the window previews.

@charlesg99

This comment has been minimized.

Copy link
Member

commented Jun 8, 2019

Hey HelpMeRuth, thanks for the feedback!

maybe a slight annoyance is that windows get unfocused when using the window previews.

Yeah, I removed that... you can pull/install again. The idea came from @ddnexus, but it was annoying me as well. Plus, I don't see why hovering over a preview should prevent normal keyboard input... Hovering over the panel doesn't.

gtk apps have a bigger padding around them than non gtk apps

It seems this is how mutter renders GTK windows. Not sure why, I haven't dug very deep on that, maybe I'll open an issue. The following red outline is what is considered a window (and is the source of the previews), which explains the added padding. Note this is on a black background...

GTK:
image

Non GTK:
image

@charlesg99

This comment has been minimized.

Copy link
Member

commented Jun 10, 2019

@HelpMeRuth Since your comment, that extra padding was all I could see :)

I dug a little and it turns out that it was GTK's client side decorations that needed to be removed to have consistent paddings. Should be fixed, please pull/install again to see if that works for you. Thanks!

@HelpMeRuth

This comment has been minimized.

Copy link

commented Jun 10, 2019

:) its working! here's one more thing to see:
image
image

non gtk + non maximized windows have slightly bigger padding 🤣

@charlesg99

This comment has been minimized.

Copy link
Member

commented Jun 10, 2019

Hey thanks! Yes you are right, Qt windows also have some empty space but they aren't declaring themselves as client decorated (Mutter wise). Should be fixed now!

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