Fedora 9: clicking on an active application located on another workspace has no effect

Bug #234032 reported by Arne Fahrenwalde on 2008-05-22
6
Affects Status Importance Assigned to Milestone
Awn
High
Unassigned
Metacity
New
Undecided
Unassigned

Bug Description

* Distribution: Fedora 9 (Sulphur) i386
   * Kernel: Linux 2.6.25.3-18.fc9.i686
   * GNOME: 2.22.1 (gnome-desktop-2.22.1-5.fc9)
   * MetaCity: metacity-2.22.0-3.fc9 with composite enabled through Gconf
   * Xorg: xorg-x11-server-Xorg-1.4.99.901-29.20080415.fc9
   * libwnck: libwnck-2.22.1-1.fc9 and gnome-python2-libwnck-2.22.0-2.fc9
   * AWN: avant-window-navigator-0.2.6-8.fc9 installed with PackageKit / Yum (official Fedora repo)
   * Graphics Card: nVidia GeForce FX Go5700 64 MB with the open source "nv" driver

As written on https://answers.launchpad.net/awn/+question/33925

Problem:
* When selecting an applications in the AWN Dock, which is located on a workspace other then the current one, the AWN icon bounces but nothing happens!

Expected behaviour:
* Switch workspace or bring the window on the current workspace

Repoducable:
* Always (for me) - even on a fresh User account with only tweaked setting is that Composite Manager is enabled in MetaCity with Gconf

Steps to reproduce:
* Open an application (either launcher or just a normal task)
* Switch to another workspace
* Click on the application icon in the AWN Dock

Note: the AWN icon stops bouncing as soon as you manually switch to that workspace and select the application

MetaCity:
* handles it correct (Window List and Window Selector Applets switch to the workspace the application is located on when selecting it in the list)

Attachment:
* Screenshot of the bouncing icon after a click on the application which shows that the current workspace is still the first one instead of the second one (the workspace the target application is located on) - the workspace applet in the top menu bar gives an "overview"

Related branches

Arne Fahrenwalde (macgeneral) wrote :
moonbeam (rcryderman) wrote :

Unable to reproduce with:
   gentoo
   metacity 2.23.8
    X.Org X Server 1.5.99.1
   libwnck 2.22.1

However, the behavior has been confirmed on a second Fedora 9 system. This appears to be rather fedora specific. Is anyone able to reproduce this issue on a non-F9 system?

It also may be specific to version 0.2.6 of awn though I can't think of any changes to core since the 0.2.6 release that would relate to this issue.... but it will need to be checked.

moonbeam (rcryderman) wrote :

Confirmed on a second Fedora 9 installation

Changed in awn:
status: New → Confirmed
moonbeam (rcryderman) wrote :

It has been suggested that this is the result of some changes made in metacity due to undesirable behaviour being exhibited with Firefox.

moonbeam (rcryderman) wrote :

Still unable to reproduce

Unable to reproduce with:
   gentoo
   metacity 2.23.21
   libwnck 2.22.1

The behaviour I see is that the window in question is brought to the current workspace. Not my preferred behaviour, but reasonable nonetheless (xfwm4 allows for this to be configured)

Krešo Kunjas (deresh) wrote :

i have the same issues on new ubuntu hardy install. AWN is from trunk packages in PPA (https://edge.launchpad.net/~awn-testing/+archive)

only thing i changed is turning metacity compositor on with gconf

moonbeam (rcryderman) wrote :

For reference please see: http://bugzilla.gnome.org/show_bug.cgi?id=482354

It is related to a patch applied by downstream (Fedora/Ubuntu). It is not present in upstream. If anyone is aware of a repository where unpatched versions are available please feel free to note it in this bug.

Thomas Thurman (marnanel) wrote :

Hello, upstream person here.

I have been asked to PPA unpatched versions. I will attempt to do this in the next couple of days.

moonbeam (rcryderman) wrote :

Thomas,

Thanks for that. I'm sure it will have many users and not just due to this issue.

I'll also take this opportunity to mention that a metacity package for hardy is available at https://launchpad.net/~gilir/+archive/+index . According to my understanding this is the stock Hardy metacity build minus the one patch in question. Thanks to gilir for this one.

To sum up if you're conservative in nature then gilir's ppa is probably the best choice. If you're more adventurous and enjoy testing things that bleed then Thomas Thurman's ppa build (when it arrives) might be more to your liking.

I believe this should provide adequate options for Ubuntu users. If anyone knows of similar packages available for Fedora please take the time to note them here.

Thomas, ping?
(confirming this problem with awn from the ppa, and metacity composite 2.24.0 backported myself from intrepid ibex to hardy heron)

Thomas Thurman (marnanel) wrote :

Thanks for the reminder (life got in the way a little). Working on the PPA now, and got most of it done (just have to try to get my head around the intricacies of debian/rules).

If I'm not mistaken, Thomas did package it up in there: https://launchpad.net/~marnanel/+archive

Could anyone test?

Julien Lavergne (gilir) wrote :

Since I use metacity on Debian, I have the same problem, with 2.22 and 2.24, composite enable or not.
The strange thing is that the behavior is correct if I use the classic gnome panel applet (window list) : if I click on a window not in the current workspace, it bring me to its workspace. If I use Awn, when I click on the icon, the application move to the current workspace.

Patch on Debian for metacity : http://patch-tracking.debian.net/package/metacity/1:2.22.0-2

moonbeam (rcryderman) wrote :

Julien,

I have a strong suspicion that gnome panel isn't using the stock libwnck (or gtk+) method of activating the window that we are using. This is just a guess but I'm guessing that gnome panel explicitly changes the workspace for you then activates the window. I really feel this type of behaviour should be controlled by the WM. In our case their are basically two desirable behaviours when a window is selected.

1) Move to window's workspace and activate the window
or
2) Move the window to the current workspace and activate it (ick).

Both approaches have a fair number of people who favour them. Then there are certain applications where using the standard window activation methods which just want it to request attention when activated.

We could provide an option to specify which behaviour is desired in awn and have it explicitly switch workspace or bring the the window to the current workspace. But I strongly feel it is _wrong_ to need to configure this on a per application basis... unfortunately I suspect we're going to be forced to implement this bit of ugliness.

moonbeam (rcryderman) wrote :

After some discussion on #awn we are proposing/intending the following.

Three options:
0 = just call activate,
1 = move to workspace and
2= move window

The default will be 0 ( <commentary> the sane option if the WM behaviour is sane </commentary> ).

We will try to advertise to package maintainers that the config option exists and how to modify the default if their WM requires it.

Comments welcome.

Julien Lavergne (gilir) wrote :

I'm agree that this should be something controled by the WM. According to the bugzilla entry, there are still discussion on this.
But of course, an option for AWN will be a + :) And your proposal seems ok.

moonbeam (rcryderman) on 2009-01-31
Changed in awn:
importance: Undecided → High
milestone: none → 0.4.0
Michal Hruby (mhr3) wrote :

The options which moonbeam mentioned were already added to AWN's trunk.

Changed in awn:
milestone: 0.4.0 → 0.3.2
status: Confirmed → Fix Committed
moonbeam (rcryderman) on 2009-02-09
Changed in awn:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.