| Summary: | present windows zoom | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Marcus <marcus.moeller> |
| Component: | effects-window-management | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | CC: | bugs, hanswchen |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Marcus
2012-01-27 20:44:23 UTC
please argue why this needs a config option. Is there any usability problem in having the zoom? Anything not working as expected? (In reply to comment #0) >I have also configured active window glow, so it's clear which one it > is. Hummm? The oxygen decoration glow? That's not related to present windows highlightning at all (it marks the active window, not the hovered one.) Ah, you are right, active window glow is not for the present window. But I still think highlighting is enough. Zooming just takes longer and is visually disturbing from the flat view. (In reply to comment #3) > Zooming just takes longer Wrong, the zoom level precisely follows the highlight level. It's the same variable, just not translated into the brightness, but also the scale. There were btw. several bug reports about the PW highlightning being to weak - interesting to now hear the exact opposite ;-) Even one more argument to make it configurable. And if it also affects brightness this would possibly solve 292594, too ;) (In reply to comment #5) > Even one more argument to make it configurable. And if it also affects > brightness this would possibly solve 292594, too ;) Actually "no" and "no". Second no, because "deactivating" zoom would also deactivate any brightness change. First no, because there's only a very limited range of reasonable alteration. Picking "some" value out of that should be good enough. Having a "highlight intensity" feature is really just adding complexity for "i'd like 2 more percent brightness and 2 less percent scaling" - what Martin called "featuritis" Point about the window highlightning in present windows is to a) make the hovered window easy to be grasped b) not be annoying (eg. some ppl. get "seasick" from a pulsating scaling) c) not be too resource intense (petting the intel chips ;-) If you claim and can reason why the current behavior fails on one of those, that needs to be fixed. If it's just about personal taste: you will not have a monitor big enough to carry all options required to fit everyones taste. If it's just about: I don't like changes - just give it a week or two ;-) I don't like the new zoom effect either and would welcome an option to disable it (but I can see why you, the developers, don't want yet another option :). I'll try to explain what I don't like about it: 1. Too "excessive". This one is a bit hard to describe. Personally I felt that the old way was "clean" and fine to find the window you wanted. As an analogy, imagine if icons in Dolphin would zoom on hover - it would feel like "too much". That's sort of how I feel about the current Present Windows. 2. Windows are zoomed in even though you don't hover over them. I can understand why it's implemented this way - zoom shows that a window is selected - but it feels weird to me. I think it's because I'm used to zoom on hover, so when I move away the mouse, I expect the window to shrink (e.g. when the cursor is over the desktop). Right now it reminds me of buggy applications that fail to detect that I've moved my mouse. 3. It's distracting. With the old implementation, Present Windows was static, so it was very predictable. With Zoom things "move" (grow/shrink) which adds distraction with little benefits. I like the regular grid layout (see e.g. http://hanswchen.files.wordpress.com/2009/02/overview1.png). The zoom also breaks the "regularity" of the grid, especially since windows grow/shrink as you move around the mouse. To summarize, I think the zoom effect is excessive and distracting while it doesn't help much to identify the windows. I agree, the effect is annoying and there should be an option to turn it off. It's particularly annoying with small Windows, like Firefox's download window. When you hover over it when the Present Windows plugin is activated, it zooms to easily twice it's size—this is very jarring! The zoom has been implemented to solve a often reported wish that the highlighting in Present Windows is not strong enough. Having now a request to turn it off again is quite disheartening. The request does not name any reason why it should be disabled or why a config option should be implemented. Given that I don't see any valid reason to turn it off or make it configurable (Present Windows already has quite a lot of config options, so I doubt anyone would find the option). FTR: Hans /is/ correct in his point 2 I've just tested (because of the desktop grid behavior ;-) and clicking an empty area act as cancel. This should be reflected in that no window is highlighted (zoom or not) when the cursor is above an empty area (alt+tab is unaffected) to prevent confusion -> RR this evening =) @Thomas: I believe it's "half-right": the window is still selected in the sense that if you press Enter, you'll switch to it. Therefore it would be confusing if there was no selection at all. One solution could be to decouple the "zoom" selection and "brightness" selection, i.e., a selected window appears bright and zoomed in, but if the user moves the mouse cursor outside the window, it'll shrink back to normal size (but still appear brighter). @Martin: I think you've mentioned that it may be possible to port the Present Windows effect to QML. I think that would be the best solution, allowing users to easily make a "fork" with no zoom and submit it to GHNS. (Of course, if there are annoying issues with the current effect, such as too much zoom for small windows, they should be fixed.) (In reply to comment #11) > @Thomas: > I believe it's "half-right": the window is still selected in the sense that > if you press Enter, you'll switch to it. This is actually connected to the highlighted state, so if the window is not highlighted, pressing enter will cancel the effect (acts as clicking) > such as too much zoom for small windows This is no bug, but intended to allow ppl. to see the window content, the only question would be what to do with _actually_ tiny windows (ie. that are small not because of many windows in present windows and limited space) (In reply to comment #11) > @Martin: > I think you've mentioned that it may be possible to port the Present Windows > effect to QML. I think that would be the best solution, allowing users to > easily make a "fork" with no zoom and submit it to GHNS. (Of course, if > there are annoying issues with the current effect, such as too much zoom for > small windows, they should be fixed.) that bug #295775 (In reply to comment #12) > This is actually connected to the highlighted state, so if the window is not > highlighted, pressing enter will cancel the effect (acts as clicking) OK, that makes it much simpler. This doesn't seem to be the case currently in 4.8.x though, is that something that'll be changed or did I miss something? > > such as too much zoom for small windows > This is no bug, but intended to allow ppl. to see the window content, the > only question would be what to do with _actually_ tiny windows (ie. that are > small not because of many windows in present windows and limited space) A sensible solution, in my opinion, would be to limit it to the window size. In other words - don't scale a thumbnail larger than the size of its window. (In reply to comment #13) > that bug #295775 Thanks! (In reply to comment #14) > OK, that makes it much simpler. This doesn't seem to be the case currently > in 4.8.x though how did you get no window highlighted? ;-P (you actually can through the filter - filtering away all windows and pressing enter will still cause a cancel) (In reply to comment #15) > how did you get no window highlighted? ;-P > (you actually can through the filter - filtering away all windows and > pressing enter will still cause a cancel) Ah, now I understand. So what the fix will do is to unhighlight windows if the mouse cursor moves away? I trust you KWin developers on this, I just wanted to make sure that Present Windows will still work the same way with both mouse and keyboard. :) Git commit 196964ddcacfee370ff7a636d36dfcdfd99f9e4c by Thomas Lübking. Committed on 13/03/2012 at 08:46. Pushed by luebking into branch 'master'. Don't highlight windows w/o mouse REVIEW: 104264 M +13 -17 kwin/effects/presentwindows/presentwindows.cpp http://commits.kde.org/kde-workspace/196964ddcacfee370ff7a636d36dfcdfd99f9e4c |
