Bug 178913 - Should show panels in Present Windows switching
Summary: Should show panels in Present Windows switching
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: effects-present-windows (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: VLO wishlist with 1 vote (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 212265 376752 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-12-27 19:37 UTC by Roman Odaisky
Modified: 2021-04-20 15:57 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.22


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Roman Odaisky 2008-12-27 19:37:10 UTC
Version:            (using Devel)
OS:                Linux
Installed from:    Compiled sources

I suggest that the Present Windows switching feature (the Exposé-like one) show all the Plasma panels. Currently only the windows are shown and all the panels are hidden.

The reason behind this request is the following. Screen corners are the easiest points to navigate to, but there are only four of them. If I use for Exposé the corner where the K menu is located, it somewhat impairs my ability to use the menu. The nice feature of requiring the mouse to be pushed slightly beyond the corner to activate the corner helps, but not completely. So what if moving the mouse to the corner would trigger the Exposé thing, but the K menu button would remain there, so I can click it if that was my intent? Looking at screenshots of the ‘real’ Mac OS’ Exposé, I can see they preserve the dock and the menu bar, and I think KWin should also do that.

This can be expanded further. What if there were Plasma panels (or even widgets) that would be shown *only* in Present Windows mode? The borders of the screen are pretty much unused in that mode, a lot of useful things could be placed there.

For example, my current KDE 3 desktop has several panels, of which only one is visible at all times. It contains the K button, a clock, then the taskbar and the notification area. The corner behind the K button causes another panel to appear that has buttons for quick launching of applications (screenshot: http://files.rsdn.ru/48787/kde3-panels.png). This way the same corner has two functions and none hinders the other. It has proven extremely useful for me. I think being able to use panels while in Present Windows mode would be useful, saving precious screen corners, and there should be no drawbacks.
Comment 1 lucas 2008-12-28 02:53:44 UTC
This is currently CANTFIX as present windows eats all mouse clicks preventing the panel from being used. When X gains input redirection though it could become possible by redirecting all dock windows (A problem would be the menu as KWin can't detect its type) while keeping the rest how they are.
Comment 2 Martin Flöser 2009-01-13 11:22:19 UTC
SVN commit 910398 by graesslin:

Add an option to show/not hide panels. Panels are of course not included into filtering and cannot be selected. Like all other windows you can't interact with panels. Option is default off.
CCBUG: 178913


 M  +18 -1     presentwindows.cpp  
 M  +1 -0      presentwindows.h  
 M  +6 -0      presentwindows_config.cpp  
 M  +9 -2      presentwindows_config.ui  


WebSVN link: http://websvn.kde.org/?view=rev&revision=910398
Comment 3 Roman Odaisky 2009-01-13 12:54:08 UTC
Thanks.

Does the change allow the behavior described above? I. e., I want to open the K menu, but push the mouse too far into the corner and Present Windows is triggered. If I then, without moving the mouse, click it, what happens?
Comment 4 Martin Flöser 2009-01-13 13:09:28 UTC
(In reply to comment #3)
> Thanks.
> 
> Does the change allow the behavior described above? I. e., I want to open the K
> menu, but push the mouse too far into the corner and Present Windows is
> triggered. If I then, without moving the mouse, click it, what happens?
> 
No your desired behaviour is not implemented as it is as said in comment #1 a cantfix. The new option just allows to see the panel without any possible interaction.
Comment 5 Roman Odaisky 2009-01-13 13:13:36 UTC
Okay. So what happens if I click on a panel in Present Windows mode? If that would quit the mode and a subsequent click (already in normal mode) would be passed to the panel, I think that would be quite fine.
Comment 6 Martin Flöser 2009-01-13 13:22:59 UTC
(In reply to comment #5)
> Okay. So what happens if I click on a panel in Present Windows mode? If that
> would quit the mode and a subsequent click (already in normal mode) would be
> passed to the panel, I think that would be quite fine.
> 
Yes that works. I just tested, clicking twice on the k-menu button in present window will end present window and open kickoff. So I think it's ok to you if I mark the bug as worksforme.

Just as a hint: this is added for 4.3, not for the upcoming 4.2.
Comment 7 jos poortvliet 2009-01-31 00:13:43 UTC
Roman: I think your idea makes sense (and it is unfortunate it can't be done yet), but

@Martin I doubt this really fixes it. After all, if you go bottom-left and click once, sometimes nothing happens (present-windows comes and goes), sometimes you get the menu.

It does however add an option to the config dialog for something incredibly obscure (it doesn't add any functionality, why would anyone want it?).

I would vote for keeping the panel visible by default (doesn't hurt, I suppose, but not showing it would be equally good for me). Do not show any option in the gui (you might make this configurable from the config file for that 1 in 100000 users that likes it). And once this is truly fixed (thanks to improvements in X.org) we won't need an option either (should just be on).

@both I don't think this is a bad idea but it currently doesn't work anyway, wouldn't need a config when it did and thus really shouldn't clutter the config dialogs right now.

Just my 2 cents (spread over a few paragraphs.
Comment 8 lucas 2009-01-31 04:03:36 UTC
I agree with Jos but would rather the change be completely reverted instead of being made enabled by default.
Comment 9 Roman Odaisky 2009-01-31 12:55:37 UTC
I must not have been completely clear.

What I suggested is a possibility of using the same corner for both a button and Present Windows and being able to use either. If I want to switch to a window, I move the mouse to the corner and click the window. If I want to use the button, I move the mouse to the corner as well, if Present Windows is triggered I disregard it, and I click (maybe twice) to activate whatever I have on the panel.

Does anyone think such behaviour would cause problems for users?
Comment 10 jos poortvliet 2009-02-02 13:19:58 UTC
@Roman: I think we understood you correctly. The problem is that currently it is not possible to have this work reliably. There is a half-way-there solution, but having it doesn't bring any real benefit, thus I said adding an option for that wouldn't be a good idea.
Comment 11 lucas 2009-10-29 09:47:40 UTC
*** Bug 212265 has been marked as a duplicate of this bug. ***
Comment 12 lucas 2009-10-29 09:49:14 UTC
Reopening as the commit is controversial.
Comment 13 lucas 2009-10-29 09:58:13 UTC
After thinking about this for a little while I think I've come up with a solution: Have a non-modal fullscreen effect mode.

This mode will be pretty much identical to the existing fullscreen mode (Intercept all mouse clicks) but instead will have the panels untransformed and have their window shape cut out from the effect mouse input window. This will allow the user to interact with the panel while the effect is activated.

Since KWin also intercepts all mouse clicks for window focus policies we can use these to detect if the user has interacted with a panel while an effect is activated and pass that signal back to the effect. Present windows in this case would have the signal trigger the effect deactivation.
Comment 14 Will Stephenson 2009-10-29 11:46:07 UTC
Sounds great, as long as the panel clicks don't simply cause an immediate 
effect deactivation - that would create the same impression that the panel 
click was not properly handled.  Example - user tries to click the taskbar to 
activate a window in prevent windows mode and the clicked taskbar item is not 
focused.
Comment 15 Martin Flöser 2017-02-21 16:02:46 UTC
*** Bug 376752 has been marked as a duplicate of this bug. ***
Comment 16 Nate Graham 2021-04-20 15:57:31 UTC
Done by Felipe Kinoshita with https://invent.kde.org/plasma/kwin/-/commit/ff3cb59967b440eefe47d9c6b194964b8af2af0d in Plasma 5.22!