Written by smenjas the 29 Feb 08 at 01:34.

If an application needs my attention, it's task bar button should simply pulse so I can turn my attention to it when I'm ready. Pidgin does this; why not everything else?

If an application needs my attention, it's task bar button should simply pulse so I can turn my attention to it when I'm ready. Pidgin does this; why not everything else?

Written by smenjas the 5 Feb 09 at 09:59.

On Mac OS X, Growl provides a system-wide way to notify the user that something has happened without getting in the way. I'd very much like to see Ubuntu adopt something like that.

On Mac OS X, Growl provides a system-wide way to notify the user that something has happened without getting in the way. I'd very much like to see Ubuntu adopt something like that.

Written by runesvend the 29 Mar 09 at 17:40.

I'm imagining that pressing and holding a button (Control, Alt, or some other key of choice) while clicking on a program launcher icon in the panel, would make the window of the newly launched program appear _behind_ the currently active window. That way, I can quickly and easily press Alt+Tab to get to the newly opened application window when I wish to.

I'm imagining that pressing and holding a button (Control, Alt, or some other key of choice) while clicking on a program launcher icon in the panel, would make the window of the newly launched program appear _behind_ the currently active window. That way, I can quickly and easily press Alt+Tab to get to the newly opened application window when I wish to.

Written by MathUHenry the 9 Jul 09 at 18:09.

When a program is launched, it is granted the "active window" status. I would like programs to not be able to grant themselves the "active window" status. When another program is selected, the loading program is moved to the background and should be forced to stay there (until the user selects it). When I press ctrl alt d, I want it to minimize until I select it.

In short, don't let programs bring themselves to the front (even update manager). If a program MUST notify me of something, then I think the new notification system is the coolest/most-convenient-ever way to do it.

When a program is launched, it is granted the "active window" status. I would like programs to not be able to grant themselves the "active window" status. When another program is selected, the loading program is moved to the background and should be forced to stay there (until the user selects it). When I press ctrl alt d, I want it to minimize until I select it. In short, don't let programs bring themselves to the front (even update manager). If a program MUST notify me of something, then I think the new notification system is the coolest/most-convenient-ever way to do it.

Written by pererik87 the 6 Jan 10 at 09:44.

The "preload window" should set the order position and workspace, then the program should not be able to steal focus or change workspace any more after started. If a program does not have a preload screen and uses long time to start it should be given a container or something.

In other words: programs should be locked to the order and workspace they get when someone start them unless user changer the order.

Gimp is an example of a program that takes long time to start and then steals your focus, even if you change workspace and select unlimited of other windows.

The "preload window" should set the order position and workspace, then the program should not be able to steal focus or change workspace any more after started. If a program does not have a preload screen and uses long time to start it should be given a container or something. In other words: programs should be locked to the order and workspace they get when someone start them unless user changer the order. Gimp is an example of a program that takes long time to start and then steals your focus, even if you change workspace and select unlimited of other windows.

Written by orblivion the 16 Sep 09 at 22:22.

1) More things should pop under. This could of course be annoying if you're trying to run a program and have to switch windows every time.

2) Warning periods. If things pop over, I need to have a warning. Maybe in Compiz, windows could fade in for a certain period of time (.5 to 1 seconds, user configured) without yet having focus. In Metacity, they could disable input controls for the same period. This interrupts what I'm doing, but at least I notice before I inadvertently do anything.

For notifications or dialogs, I think #1 would be just fine. I'll get to the window when I have a chance. #2 would be good for programs I deliberately open, or dialogs that really need my attention.

1) More things should pop under. This could of course be annoying if you're trying to run a program and have to switch windows every time. 2) Warning periods. If things pop over, I need to have a warning. Maybe in Compiz, windows could fade in for a certain period of time (.5 to 1 seconds, user configured) without yet having focus. In Metacity, they could disable input controls for the same period. This interrupts what I'm doing, but at least I notice before I inadvertently do anything. For notifications or dialogs, I think #1 would be just fine. I'll get to the window when I have a chance. #2 would be good for programs I deliberately open, or dialogs that really need my attention.

Written by owenduffy the 3 Oct 09 at 14:44.

Why not prevent windows from stealing focus, but have their icons on the Gnome panel (or awn, or whatever) blink or otherwise make themselves conspicuous? That way the user is aware that another window requires attention, but doesn't have to deal with it immediately, either to respond to it or close/minimise it.

Why not prevent windows from stealing focus, but have their icons on the Gnome panel (or awn, or whatever) blink or otherwise make themselves conspicuous? That way the user is aware that another window requires attention, but doesn't have to deal with it immediately, either to respond to it or close/minimise it.

Written by xubaj the 10 Nov 09 at 12:38.

while typing, no window should be allowed to steal focus until the keyboard is unused for about 2 secs. instead they should pop-under.

while typing, no window should be allowed to steal focus until the keyboard is unused for about 2 secs. instead they should pop-under.

Written by xubaj the 10 Nov 09 at 12:44.

if windows want to pop-up and steal focus, they should be displayed highlighted in background (or very glassy in foreground), so you know that a window wants to get focus. but the windows stay in background until you stop typing. when you stop typing they all appear in there original order.

if windows want to pop-up and steal focus, they should be displayed highlighted in background (or very glassy in foreground), so you know that a window wants to get focus. but the windows stay in background until you stop typing. when you stop typing they all appear in there original order.

Written by lapgoat the 13 Oct 10 at 12:09.

The window manager should watch mouse movement and keyboard usage. If there has been a keystroke in the last second or the mouse pointer has moved more than a few pixels in the last half second, assume that the user may continue typing or click. Place the new popup at the lowest Z-level to minimize risk of accidentally clicking and retain keyboard focus on the current window.

If an application is in need of input but has been denied it, flash the task switcher or add an icon to the notification area to get the user's attention. If the application urgently needs attention, send a notification to via the selected preferred method (libnotify or such).

If there hasn't been any input in the above timeframes, the new window can be granted the ability to pop up at the top Z-level, but it should be denied keyboard focus until the user interacts with it.

If the user has requested an application window to open, the expected behavior is that the new window will come to the top and be given focus. Some heuristics should be developed to maximize the probability that this expected behavior occurs, otherwise the window manager becomes difficult to use.

The window manager should watch mouse movement and keyboard usage. If there has been a keystroke in the last second or the mouse pointer has moved more than a few pixels in the last half second, assume that the user may continue typing or click. Place the new popup at the lowest Z-level to minimize risk of accidentally clicking and retain keyboard focus on the current window. If an application is in need of input but has been denied it, flash the task switcher or add an icon to the notification area to get the user's attention. If the application urgently needs attention, send a notification to via the selected preferred method (libnotify or such). If there hasn't been any input in the above timeframes, the new window can be granted the ability to pop up at the top Z-level, but it should be denied keyboard focus until the user interacts with it. If the user has requested an application window to open, the expected behavior is that the new window will come to the top and be given focus. Some heuristics should be developed to maximize the probability that this expected behavior occurs, otherwise the window manager becomes difficult to use.

Written by der_hede the 15 Oct 10 at 12:14.

There are many reasons why focus stealing is annoying. One is you have to find your old window if you do not want to use the new window directly.

The other is the group of simple popup windows asking you short questions or inform you about something.

While the first one is no problem, you still can switch to your desired window, the second one is very bad if you are writing a letter or something else.

Imagine the popup "Are you shure you want to do something [no][yes]" pops up while you are writing something and the default value you are accepting with [space] (an often pressed key in writings) is not the one you intentionally wanted to press...

For the later one there's a KISS solution: No one can react to any new windows in a certain time period. Lets say 1-2 Seconds. So there's simply no chance there is any usable input to such windows inside a 1-2 Seconds time frame from the creation of the window.

So one solution would be to simply ignore all new input to new windows for 1-2 Seconds.

This could be as simple as a default option for "Popup" Style Windows in GTK/Qt/etc.

There are many reasons why focus stealing is annoying. One is you have to find your old window if you do not want to use the new window directly. The other is the group of simple popup windows asking you short questions or inform you about something. While the first one is no problem, you still can switch to your desired window, the second one is very bad if you are writing a letter or something else. Imagine the popup "Are you shure you want to do something [no][yes]" pops up while you are writing something and the default value you are accepting with [space] (an often pressed key in writings) is not the one you intentionally wanted to press... For the later one there's a KISS solution: No one can react to any new windows in a certain time period. Lets say 1-2 Seconds. So there's simply no chance there is any usable input to such windows inside a 1-2 Seconds time frame from the creation of the window. So one solution would be to simply ignore all new input to new windows for 1-2 Seconds. This could be as simple as a default option for "Popup" Style Windows in GTK/Qt/etc.

Written by Lachu the 16 Oct 10 at 13:54.

Instead of allowing to steal focus, only suggest user to switch onto new window or window asking for focus. Solution is already implemented in KDE SC - the task item will higlights, but we needs some think more visible.

I suggest to show transparent preview of window asking for focus in top-right corner of screen. Desktop environment will display this preview only, when keyboard/mouse are inactive for long period of time. Also, it will be displayed for few second after asking for focus.

Instead of allowing to steal focus, only suggest user to switch onto new window or window asking for focus. Solution is already implemented in KDE SC - the task item will higlights, but we needs some think more visible. I suggest to show transparent preview of window asking for focus in top-right corner of screen. Desktop environment will display this preview only, when keyboard/mouse are inactive for long period of time. Also, it will be displayed for few second after asking for focus.

Written by Aielyn the 19 Oct 10 at 06:46.

It seems the problem is that you want to not lose the *focus* on the current window, but you also want to be able to quickly see and react to new windows that pop up.

Why not essentially push new windows to the top of the stack as far as display is concern, but keep the focus on the original window? Then, perhaps a time-based element could allow the system to automatically switch to the new window if no input is occurring within the set time. Another alternative would be to have it pushed to the top of the display stack, but after a set number of seconds, it would minimise (showing the minimise effect) and put a highlight on the tab for the new window.

This would be an option, of course, and the time-based element would be an option as well.

It seems the problem is that you want to not lose the *focus* on the current window, but you also want to be able to quickly see and react to new windows that pop up. Why not essentially push new windows to the top of the stack as far as display is concern, but keep the focus on the original window? Then, perhaps a time-based element could allow the system to automatically switch to the new window if no input is occurring within the set time. Another alternative would be to have it pushed to the top of the display stack, but after a set number of seconds, it would minimise (showing the minimise effect) and put a highlight on the tab for the new window. This would be an option, of course, and the time-based element would be an option as well.

Written by shadowentity the 28 Sep 11 at 09:31.

a plug-in interface to use a module that makes decisions about the z-level, focus and maybe even the workspace and/or window-size and/or orientation of the window that is about coming up.

a configurable default module should exist and be used by default to apply simple rulesets such as "never", "always", "only raise'", etc. and offer an option to eval a script function or something.

it would keep simple things simple and make complex things possible.

a plug-in interface to use a module that makes decisions about the z-level, focus and maybe even the workspace and/or window-size and/or orientation of the window that is about coming up. a configurable default module should exist and be used by default to apply simple rulesets such as "never", "always", "only raise'", etc. and offer an option to eval a script function or something. it would keep simple things simple and make complex things possible.

Written by gaxi the 21 Oct 11 at 07:27.

CompizConfig Settings Manager > General > General Options > Focus & Raise Behaviour
Focus Prevention Level = "Very High"

For me this works perfectly, new windows do not steal my focus any more when typing.
I'm using 11.04

CompizConfig Settings Manager > General > General Options > Focus & Raise Behaviour Focus Prevention Level = "Very High" For me this works perfectly, new windows do not steal my focus any more when typing. I'm using 11.04