Created attachment 916 
cycle raise patch

Comment 2 Olivier Fourdan 2007-01-01 21:41:46 CET

Thanks a lot, I'll keep that for review after 4.4.0

Comment 3 Peter de Ridder 2011-12-15 16:11:27 CET

Created attachment 4025 
Temporarily raise window on cycle

I picked this up from the Design SIG and noticed this bug exists later on.

This patch has a slightly different approach as the original patch.
It only temporarily raises the window. So cycling doesn't change the order of the other windows.
This brings a problem with the current implementation. If something would trigger a clientApplyStackList during cycling the raised window would be placed back.
(This wouldn't be hard to solve, only there are more ways to go)

Future thinking: With compositing this feature could become obsolete if there would be a preview window in the tabwin. But might be irrelevant to the report.

Comment 4 Olivier Fourdan 2011-12-16 09:44:44 CET

I am not sure this is suitable, that makes cycling much more slower, that's not really within the goals of xfce tbh.

Comment 5 Olivier Fourdan 2011-12-16 09:46:03 CET

Note that since the original report was opened, a new cycling between windows of the same app has been implemented, which is quite convenient for cycling between terminals (and just terminals) for example.

Comment 6 Peter de Ridder 2011-12-16 11:33:51 CET

(In reply to comment #4)
> I am not sure this is suitable, that makes cycling much more slower, that's not
> really within the goals of xfce tbh.

It is an option to use it, not required. And for the systems from a couple of years ago this should be to much of a problem.
To make switching faster the window could be raised after X time of waiting, but I don't think that is an usage improvement.

I'd like to second the inclusion of this patch.  I've been using it for several
months now and in my opinion it's usefulness for people who like to control
their window manager with the keyboard simply cannot be overstated: switching to
hidden windows becomes intuitive, there's no need to associate windows with
their icons and names as with the built-in switcher.

Running xfce on a three-year-old subnotebook, I cannot observe any slowness due
to this patch.  Furthermore, as the feature added by the patch is optional and
switched-off by default, I cannot see any reason for not including it.

Olivier, please reconsider applying this patch.

Comment 8 Simon Steinbeiss 2014-08-05 17:27:04 CEST

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

Can we bring this back to life? I find it very frustrating that the windows are displayed as obfuscated blue blobs.  I see where the windows are, but cannot see content.  Why don't you make it possible?  WindowMaker and Enlightenment allowed this in the old days.  Every old window manager did.

Created attachment 7327 
cycle raise patch

Raising revival. This patch is against latest xfwm4 git master.

Created attachment 7328 
cycle raise patch

I wonder - what should I do to avoid another 10 years period? :-) Perhaps some pull request?

Comment 13 Git Bot 2017-12-20 10:37:01 CET

David Siroky referenced this bugreport in commit 58dcef04b4737ec9871a312567923334d36b50fb

Raise window while cycling

https://git.xfce.org/xfce/xfwm4/commit?id=58dcef04b4737ec9871a312567923334d36b50fb

Comment 14 Olivier Fourdan 2017-12-20 10:39:49 CET

Long overdue, indeed. Kind of superfluous with window preview in cycling, though.

Thanks for the patch.