Bug 305044

No bug, removed intentionally (present windows was never really a tabbox mode and the invocation rather a kludge)

Notice that you still can access present windows through a shortcut (personally abusing the dropdown key next to the right meta/super key) and navigate using the arrow keys or activate it through an active corner what is both also more effective than the serial alt+tab switching and/or starting it with alt+tab and then use it with the mouse,

The qml grid layout does not and does not aim to replace actual present windows.

Ok, thanks for the explanation. Now my problem is that: in kde 4.8 if I press alt+tab fast, I switch to the window selected before, If I hold alt+tab, the present window effect start and I can select a window with mouse click or stay on current window if I release the keys. It's my work configuration and I can't live without it :). Now in kde 4.9 I can't have this behavior. There is a way to have the same behavior as kde 4.8 with kde 4.9?
dbus? hotkeys? pls give me a workaround for my problem.

Thx for your awesome work and sorry for my english.
Bye

give a try to the Grid layout - it is most close to the present windows 
effect and in fact inspired by Present Windows and written to replace 
the TabBox mode of Present Windows.

sorry but I'm not agree with you. The grid layout is good but not as good as present window. Present window is more clear and distraction-free (fullscreen effect and when mouse cursor hover a window there is a nice zoom effect), more useful (I can close window with right click button) and more quick (when click a window the effect terminate and window clicked is selected, instead of release alt+tab key). I use the corner for activate present window but isn't quick as keyboard shurtcut (on a 22" the space is so much). For me this is a heavy regression. I beg you to reconsider the benefits of present window effect and re-add to selection list.

Bye

>  I use the corner for activate present window but isn't quick as keyboard shurtcut
as mentioned before - you still can activate the effect by a shortcut (default is ctrl+f9 or so, but i'd really adver the otherwise rather pointless context menu key)

And yes: "present windows" aka "exposé" is a generation ahead of tabboxes and taskbars - that is why it doesn't fit the generally serial tabbox approach.

I'm surprised that present windows is removed from the task switcher. It was by far by favorite switcher. I had an overview and for me nothing compares to that. Could you find a way to reintroduce this feature?

(In reply to comment #6)
> I'm surprised that present windows is removed from the task switcher. It was
> by far by favorite switcher. I had an overview and for me nothing compares
> to that. Could you find a way to reintroduce this feature?
no, that was a clear decision

This is a usability regression.

Present windows effect is good for fast window navigation with minimal user actions (how it was in 4.8):
- Press Alt-Tab to activate window selection
- Move mouse over desired window. zoom+highlight effect on mouse over gives good visual feed back for user. Thumbnails are proportional to real window sizes which helps to locate a window (natural layout).
- Release Alt to swich to highlighted window.
- To summarize: activate window selection by holding a key, mouse over focuses to window, release key to complete window selection. Extremely good visual feed back.

I have assigned my Alt-Tab to Present windows effect but it now requires an extra mouse click to activate the window. Releasing the Alt doesn't dispose the effect. And surprisingly cycling through windows is not possible using tab key in this setup. This is a clear usability regression. Yet, it is still slightly better than any of the current alternatives.

In 4.9 the grid effect is slightly similar but it has its own problems:
- Moving mouse over window thumbnail doesn't highlight nor activate element.
- Clicking on thumbnail moves the focus to thumbnail but doesn't switch to selected window (this step should not be required)
- Visual feedback is modest/messy, some effort needed to locate desired window (poor highlighting, all windows, except really small ones, are shrank into equally sized thumbnails making it harder to reason about real window size). Thumbnail focus change brings a relevant window to front in background but this creates visual noise due window translucency.
- To summarize: activate window selection by holding a key, focus to thumbnail by clicking it, release key to complete window selection. Visual feed back is subtle/messy making window navigation slightly awkward.

The author who made theses changes between 4.8 and 4.9 probably had good intentions and a solid reasoning behind his decisions. Perhaps there was some technical reason why old behaviour had to be removed. Or was the change part of some long term plan? Or was the purpose to make it more "mainstream" and remove some features which might accidentally confuse some users? Or perhaps the author just wanted to try something new. What ever the reason was it resulted a usability regression. 

Please consider reopening.

The reasoning is provided in the review request which went prior to the change: https://git.reviewboard.kde.org/r/104357/

The change will not be reverted!

Title of this bug is "no present window effect in KCM task switcher menu". This bug exists because some users feel that user experience degraded between 4.8 and 4.9.

Grid effect might have it's own merits and I think that it is a fine *addition*. The technical reasoning behind grid effect seems to be relatively solid but unfortunately it has usability problems for some users when comparing it as a *replacement* for present windows effect.

Do you have any ideas how we could get present windows effect back? Cover switch and flip switch already utilize desktop effects. And not to mention it worked fine in 4.8. Adding support for present windows effect (or something very similar) should not be that hard?

(In reply to comment #10)
> Do you have any ideas how we could get present windows effect back?
Support to Present Windows will not be added again. It was a hack, I'm sorry that I added that hack (I was young and didn't know what I was doing) and I removed the hack again. I will not allow such hacks to go in again.

I'm sorry that we cannot satisfy your needs and that you consider it as a regression. Unfortunately we cannot satisfy all users. Sometimes it is required to do changes for improving the code quality. This was one of such cases.

Btw. I actually planned to drop the Present Windows effect in 4.10. I won't get to it probably, but it is still something I want to do. It will be replaced by a QML replacement which would allow to use Present Windows without compositing. But it would completely make it impossible to use it for something like Alt+Tab. I in general think such decisions through and have a longer planning for it :-)

Ok, but I am still slightly baffled why flip and switch work and something similar to present windows cannot.

Loosing a Present Windows desktop effect doesn't bother me (I have set effect animation speed to instant) but loosing a smooth *workflow* makes me grumpy.

Anyway, I guess we then just have to hope that such smooth workflow as 4.8 allowed will return in one form or in another in near future.

(In reply to comment #12)
> Ok, but I am still slightly baffled why flip and switch work and something
> similar to present windows cannot.
flip and cover switch have been written as an Alt+Tab effect. That's their only task, they have been designed especially for this.

Present Windows on the other hand was an existing effect which got somehow hacked to work as an Alt+Tab effect.

*** Bug 308374 has been marked as a duplicate of this bug. ***

I came to the bug tracker to file this report myself, and came upon this report.

This is extremely frustrating.  I am very disappointed in this decision.  As others have stated, this is a major usability regression.  The new QML switcher is nice, but I very, very strongly prefer Present Windows.  As others have said, it 1) makes full use of screen space; 2) hides unnecessary chrome, whereas the new switcher has distracting chrome from Plasma; 3) has better animation.

Fundamentally, the technical rationale for removing useful, working functionality is irrelevant.  What matters is the end user experience, i.e. the product aspect.  From the user's perspective, a feature he used, and had used for years, is suddenly gone, without explanation or recourse.  This is the kind of behavior I expect from GNOME, not from KDE.

IMO, a developer who takes responsibility for producing software which is used by many people bears a certain responsibility to those users.  The fact that it's FOSS and volunteer-made is beside the point.  If one is unwilling to be a caretaker, so to speak, of the software, of the useful functionality in it, he should not take on the task of maintaining it.

It is certainly within his prerogative to make whatever changes he wishes, especially to the underlying technical infrastructure.  However, to rip out features that users use, and to then dismiss their pleas with technical excuses--which to a user are meaningless--is not a good way to treat people.  This is not "nice", nor is it kind, nor does it follow the Golden Rule.  In a way it is selfish--certainly from the user's perspective, it is.

"Hack, schmack."  Who cares.  The point is, it worked, and it worked well, and it was useful, and it was the preference of many users--real, living, breathing people.  It worked before, and it can work again.  It's not that it's not possible, it's that the developer doesn't want to.  And in a way that's fine--he is a volunteer, after all--but in a way it's not fine, because he ripped it out against users' wishes.  Being a good caretaker of software like this includes not ripping out features, even for the purposes of rearchitecting the software, until the features have been reimplemented.  Doing otherwise seems irresponsible.  Instead the users are, in effect if not in so many words, told to "deal with it."  That is simply not the way to run a community project.

At the very, very least, the Present Windows effect should have the option added to work as the Alt+Tab switcher.  As it is now, when I assign Alt+Tab to it, when I hold down Alt and press Tab twice, it simply goes back to the current window, rather than cycling through them.  How hard would it be to make it cycle through them until Alt is released?  Probably a few lines of code here and there!

Mr. Gräßlin, I ask that you reconsider, and that you at least implement the suggested changes to the Present Window effect so it may be function as before.

And, lest I fail to mention this: you mentioned your desire to remove Present Windows altogether in the future.  I can't help but be reminded of this GNOME bug report, in which a useful feature was ripped out for no reason, only because the developer didn't use it personally: https://bugzilla.gnome.org/show_bug.cgi?id=676842  This is arrogant, rude, selfish, andjust plain wrong.  Developers with such a mindset should not have commit privileges on codebases used by others.  I implore you not to go down this road.  This is not what KDE is supposed to be like.

(In reply to comment #15)
>  This is the kind of behavior I expect from GNOME, not from KDE.
with this sentence you unfortunately destroyed your complete argumentation. I do not tolerate such comments. Please read the http://www.kde.org/code-of-conduct/ especially the part about being respectful. Yes that also applies being respectful to the developers of our sister community GNOME.

> Mr. Gräßlin, I ask that you reconsider, and that you at least implement the
> suggested changes to the Present Window effect so it may be function as
> before.
I'm again very sorry that I added the changes to Present Windows in the first place and I will not add them again as it cannot be implemented in a way that it would pass a review request. I'm very sorry about that and I think it is the wrong solution.

If the new grid layout is not sufficient, it should be improved but so far nobody has come with any suggestions on how to improve it or provided additional layouts.

I do not accept the ranting and insulting which is happening in this report. This behavior is unacceptable. This will not change my decision which is final in that regard.

Ok guys, do not worry. Martin is right, this behavior is unacceptable. Here we shoud try to convince the developers to reimplement this effect as tabbox effect, so try to add useful consideration in a moderate behavior.

> If the new grid layout is not sufficient, it should be improved but so far nobody has > come with any suggestions on how to improve it or provided additional layouts.
In comment 4 I've reported my reason:
present window PRO
1) Present window is more clear and distraction-free (fullscreen effect and when mouse cursor hover a window there is a nice light and zoom effect)
2) more useful (I can close window with right click button) 
3) more quick (when click a window the effect terminate and window clicked is selected, instead of release alt+tab key). I use the corner for activate present window but isn't quick as keyboard shurtcut (on a 22" the space is so much)

grid layout PRO
1) no compositing is required.

So, fo me, grid layout can have a chance to substitute silently present window if this work will be done:
1) make rectangular background size big as entire display size and use a dark transparent color (so there isn't distraction and window can be identified better)
2) add highlight of the window on mouse cover
3) add close button in the top-right corner of the window for close window or add right clickoption for do this
4) click with mouse on a window terminate the effect.

This is my suggestions.

Bye guys, thx for yours work and sorry for my poor english

(In reply to comment #17)
> So, fo me, grid layout can have a chance to substitute silently present
> window if this work will be done:
> 1) make rectangular background size big as entire display size and use a
> dark transparent color (so there isn't distraction and window can be
> identified better)
> 2) add highlight of the window on mouse over
> 3) add close button in the top-right corner of the window for close window
> or add right clickoption for do this
> 4) click with mouse on a window terminate the effect.

+1 from me to all of the points. I would add "...on mouse over or currently selected" to 2) to make it more clear.

I just want to point out that it is possible to write once own layout as described in http://techbase.kde.org/Development/Tutorials/KWin/WindowSwitcher (unfortunately not yet updated for 4.9). Also it is possible to share the layouts through GHNS (see http://kde-look.org/index.php?xcontentmode=92&PHPSESSID=ebb26c2dd9a7da094edf401485751a3e) and GHNS integration in the KCM will be integrated in 4.10.

I do not see any reason why we as the developers need to copy the dialog. If there is the wish by the community, the community can take care of developing and distributing such a layout. I do not intend to write such a layout or include one into KWin as it would not integrate with the other layouts and is basically a duplication of the Grid layout. Just for a few minor tweakings there is no reason to include another layout.

PLEASE BRING BACK PRESENT WINDOWS ALT+TAB SWITCHER!! I miss it sooooooooooooooo much!!!!

Grid visualization is so infeior. 

Aspects of the present windows effect that I find valuable and suprior to any other task switching option:
  * full screen
  * windows fly from their stacked position into the task switcher, making it easier to see what's going on

I understand that I can still access present windows as an effect, but having it available as a task switcher was far better because I could walk through the windows with the same keyboard shortcut as I used to invoke the switcher, and the windows were ordered by the ones most recently used. 

Very sad that this is gone now.

yes, it *is* superior.

So i frankly start to "wonder" why ppl. seem so eager to omit those superior aspects (habits and because humans are irrational, i guess)

Notice:
a) I did *not* decide to remove it and actually warned to do so.
Not because i questioned the step, but because i foresaw this bug report.
Just wanted to point out: i'm not trying to defend myself =)

b) Also please be aware that i'm just expressing my personal opinion.
I do not try to convice ppl. to behave the one or other way, nor is this an "official KWin" statement or so.

--

Exposé (aka "present windows") is superior to tabboxes and taskbars (and window popup lists, which are still better than stupid tasbkbars =) in two aspects:
1. it's direct (tabboxes and taskbars are "avatars", you've to link them to the window in your brain)
2. it's *not* serial (the matrix alignment turns O(n²) into O(2n) for the distance to the desired window)

Obviously the invocation by alt+tab detroys aspect N°2.
In other terms: that would only make sense for few (<4) windows (where only only the windows in your access interest matter, ie. if you only swap between the upper two windows, you got two windows and a messy desktop)

Otherwise using the arrows or even the mouse is more efficient.
(Hint: there's a more or less pointless key between your right meta and control key. Use that as trigger by thumb, brings your fingers on the cross)

It remains the <4 windows case and the therefore the question, whether the animation and scling (time and reorientation) overhead is worth that, or you'd be better of just outlining/highlighting the selected window (which is even more direct, but serial - so only fits few windows)

My personal suggestion would be to avoid indirection altogether, ie. never use any tabbox (and no taskbar either, but that's a different matter) and use present windows by the mouse (in general) and the keyboard only when there are many windows. Otherwise (keyboard, few swapping windows) just step through by the highlighter - that's faster than *anything* else for that scenario.

"Abusing" present windows as tabbox frankly makes no sense to me and never has. *shrug*

I just uploaded a Window Switcher layout which more closely mimics the old Present Windows effect to kde-look.org. You can download it from: http://kde-look.org/content/show.php?content=154858

Features:
* Selecting Windows by mouse over
* Close Windows Button
* Makes use of full screen
* Shows Background

Not yet possible is highlight/saturation and zooming.

I intend to add support for highlight/saturation for 4.10 but I do not intend to add zooming support. If someone wants to work on it: the source is available.

The downloaded package can be installed with:
plasmapkg -t windowswitcher -i <fileName.kwinswitcher>

Most likely it will be possible to download directly from the configuration module starting with the next minor release. It is working already, I downloaded it on my second system (in fact I only implemented this switcher to test the download ;-)

I too feel that Present Windows is a much better task switcher as it allows mouse and keyboard navigation. Plus there is no scroll all windows are just there and it feels somewhat more "natural".

I installed "Pesent Windows Clone (opaque)" style in KDE 4.10 opposite to its name it offers transparent background when switching and I think its a fair compromise.

I have to agree that this should be reopened. This is a regression in several aspects:

1. All existing switchers, *including* "Present Windows Clone", impose ordering on windows based on 'age'. Present Windows tries to preserve relative positions.

2. Similarly, Present Windows keeps windows on the same screen. The layout-based switchers only use the current screen.

3. Present Windows removes clutter by shrinking/moving all windows until they do not overlap (and you can see your pretty wallpaper :-) ). (The 'opaque' flavor is a little better here, but even with 'show selected' and 'outline selected' options turned off, it still shows through window clutter.)

4. Present Windows uses a non-uniform "best fit" layout that also considers relative window sizes. (Okay, it's an option, but it's missing from layout-based switchers, including the "clone".)

I'm also disturbed by the suggestion that even Present Windows as an effect is going to go away. If the new QML thing *really* imposes no loss of functionality while gaining the ability to work without compositing, then well and good... however the gist of the comments here do not inspire confidence that that will truly be the case.

If implementing alt-tab cannot be done in Present Windows cleanly in its current state, then maybe this is an indication that the API needs to be improved?

Even if Martin Gräßlin is not going to fix it, having it open is an indication that the KDE community accepts that this is a regression that should be fixed. At the very least, I am not convinced that it is fundamentally impossible to provide a 'present windows' effect as a switcher. That implies that the kwin API is such to preclude the possibility *and* cannot be changed. This feels more like it should have been a "WONTFIX".

This bug will not be reopened and any further discussion won't help. In fact I'm currently working on removing the present windows effect altogether and replace it by a QML variant. So any approaches about "let's put Alt+Tab in Present Windows" won't happen as that code will not be touched again.

... except for fixing present bugs, of course ;-)

> Even if Martin Gräßlin is not going to fix it, having it open is an indication that the KDE community accepts that this is a regression that should be fixed. At the very least, I am not convinced that it is fundamentally impossible to provide a 'present windows' effect as a switcher. That implies that the kwin API is such to preclude the possibility *and* cannot be changed. This feels more like it should have been a "WONTFIX".

Matthew is absolutely right.  This bug is not "INVALID."  This bug is a legitimate complaint about a real regression in usefulness.  If the developer is unwilling to fix the regression, fine, but don't close the bug as "INVALID"; mark it honestly and let it stand for others to find when they, too, get frustrated by the regression.  (At the very least it would help prevent more duplicate reports.)

Could somebody please do me a favor and explain *why* one would actually want to omit half the advantages "present windows" provides over stupid tabboxes in order to use it like one? (see comment #27)

If there's no sane explanation, this is not a regression and thus that claim and alongside it the bug actually would be "invalid".

Regarding the "API needs to be improved" stuff:
present windows wasn't written as tabbox in the first place (because it's not), somebody (*cough* not me *cough* ;-) kludged it in there later on but that lead to several conflicts because the entire effect is rather written towards direct interaction, not alt+tabbing around (following a focus chain not being visually represented by the effect...) - thus the removal.

Bottomline:
if this is *only* about the ability to connect a certain shortcut (alt+tab) to the efffect rather than a tabbox and use the tab key inside the effect (as cumbersome serial navigation in addition to the arrow keys) that'd not require much of a change.

If this is about present windows to become a tabbox, half the arguments in  comment #24 (all regarding positioning at least) are pretty much void, because PW would rather loose that ability or not be a tabbox at all.

(In reply to comment #28)
> tabboxes in order to use it like one? (see comment #27)
comment #24 ...
 
> If this is about present windows to become a tabbox, half the arguments in 
> comment #24
comment #27 ...

sorry.

to make people happy

*** Bug 320233 has been marked as a duplicate of this bug. ***