Bug 149396 - auto raise windows when mouse remains over title bar
Summary: auto raise windows when mouse remains over title bar
Status: RESOLVED INTENTIONAL
Alias: None
Product: kwin
Classification: Plasma
Component: core (other bugs)
Version First Reported In: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-30 21:32 UTC by Elmar Stellnberger (AT/K)
Modified: 2022-04-22 19:37 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Elmar Stellnberger (AT/K) 2007-08-30 21:32:16 UTC
Version:           Unbekannt (using KDE 3.5.7 "release 69.1" , openSUSE )
Compiler:          Target: i586-suse-linux
OS:                Linux (i686) release 2.6.16.27-0.9-default

It is already possible to auto unshade a window by leaving the mouse pointer on its title bar for a certain time: 
 window behaviour -> extended -> auto unshade (i.e. Fensterverhalten -> Erweitert -> automatischer Fensterheber)

 Instead of unshading after a certain time over the title bar the window could also simply be lifted into the foreground. Activating both - unshade and activate - would also make up a useful combination.
Comment 1 Elmar Stellnberger (AT/K) 2008-01-31 21:01:26 UTC
  The suggestion has been to activate and bring a window to the top only if the mouse pointer remains over the window title, not just over any part of the window. All currently supported activation options can not distinguish between the title bar and the rest of the window:
win.beh.->activation->activation-rule : by click / on mouse contact / (exactly) beneath mouse pointer
  While there does not seem to be any difference between the latter three options, there is no option like 'on contact with title bar' or 'if hovered/shaded only' (the primary 'activation' pulldown menu is definitely the better location compared to the initially mentioned 'extended' pane for these options). 
  An indiscriminate on-touch bring-to-top mechanism like the one already implemented is simply too obtrusive for most use cases.
Comment 2 Nate Graham 2022-04-22 19:37:51 UTC
With no duplicate reports, patches, or developer interest in 15 years, I think it's safe to say this won't end up happening, sorry. :)