Awn

Avant Window Navigator uses one desktop only with Metacity compositing

Bug #231347 reported by Brice Terzaghi
8
Affects Status Importance Assigned to Milestone
Awn
Fix Released
High
Unassigned

Bug Description

Hello,
I'm using Ubuntu 8.04 (Hardy Heron), which includes Gnome 2.22 and it's new feature of screen compositing with Metacity. I've activated it through Gconf and AWN works, except that the dock appears on one virtual desktop only (if run at startup, it will show up on the first desktop, if run later, it will launch on the current desktop).
To have it appear on my 4 desktops, I have to run 4 instances of AWN.

I'm not sure if it comes from Metacity or AWN, although it seems that other dock softwares work as expected.

Using AWN 0.2.1 from Ubuntu Hardy repository.

Revision history for this message
Brice Terzaghi (terzag) wrote :

Just tried v. 0.3.1 (Reacocard's repository) and same problem.

Revision history for this message
moonbeam (rcryderman) wrote :

terzag,

I am unable to duplicate his issue using a bzr build of awn in combination with metacity 2.23.8. Also many users have the combination that you are using and the issue does not seem to be common so I'm not going to be surprised if there's some difficulties tracking down the cause.

The first thing I'm going to suggest is resetting your awn settings. Please not that this will RESET ALL OF YOUR AWN CONFIGURATION and you will need to reconfigure. http://wiki.awn-project.org/FAQ#How_do_I_reset_AWN.27s_preferences.3F This might resolve the issue if it's a result of a specific set of configuration choices in awn.

Also, have you changed the configuration of Metacity beyond activating the compositing feature?

Thank for contributing to awn,

Changed in awn:
status: New → Incomplete
Revision history for this message
Brice Terzaghi (terzag) wrote :

Ok. I've just tried to reset preferences according to the link you gave, with no change. I also removed ~/.config/awn just in case.

I don't think I changed the configuration of Metacity, although I don't know how I would have done it if it's the case.

Revision history for this message
Brice Terzaghi (terzag) wrote :

Well, I can confirm that the problem doesn't happen with a new user, so it has to come from my personal settings. :/

I'll try to find out what is causing that behaviour. Sorry for the bug report.

Revision history for this message
moonbeam (rcryderman) wrote :

terzag,

If you determine the cause could you please post it here. It does look like some other users have experienced the same issue on Hardy.

Thanks,

Revision history for this message
Brice Terzaghi (terzag) wrote :

I may have a clue but I'm not sure of what to do.

With the new user, when I set preferences of the Gnome workspaces applet, I have two option : set rows and set columns. With my regular account, I have completely different options. I think it might come from the Compiz configurator (compizconfig-settings-manager package).
As far as I remember, Compiz doesn't manage workspaces like Metacity : instead of setting 4 workspaces, it sets 4 desktops with 1 workspace each, which would explain why AWN doesn't spread to the others (they don't exist).
In CCSM, there is only 1 workspace set indeed (and the number can't be changed as the option is greyed out).
I think CCSM (or something else related to Compiz) has trashed GConf options and made Gnome use its way of handling multiple workspaces even when using another window manager.
But I don't know where to check in Gconf for these options. In Apps -> Metacity -> General, num_workspaces is set to 4 as expected.

Revision history for this message
moonbeam (rcryderman) wrote :

awn deals with both workspace/viewports and desktops so even if Metacity was using a workspace/viewport configuration it should still work. Well, in most cases at least... Also, Metacity handles desktops in the same way as xfwm4, and most other WM (default conf), AFAIK. That being said it is possible that your theory is correct...

My suggestion is the following:

Assuming you are using a bzr version of awn and awn-extras.

1) Remove the gnome panel switcher if present.
2) Start the shinyswitcher applet. It will attempt to configure the desktop to 4x1 configuration (this can be modified using gconf-editor).

If shinyswitcher starts ok then try switching desktops and see if you observe the same behavior.

Revision history for this message
Brice Terzaghi (terzag) wrote :

"1) Remove the gnome panel switcher if present."
I'm not sure to understand what you mean : an awn applet or the native workspace selector from Gnome ?

"2) Start the shinyswitcher applet. It will attempt to configure the desktop to 4x1 configuration (this can be modified using gconf-editor)."
Shinyswitcher starts well but it doesn't make appear AWN on the others workspaces. If I manually run the dock on each workspace, I can browse through them with Shinyswitcher. If the workspace selector applet on my Gnome toolbar is active, the workspaces switch as expected (choosing the third in Shinyswitcher moves to the third in the Gnome applet).

Revision history for this message
moonbeam (rcryderman) wrote :

terzag,

Thanks for testing that. I have one other confirmation of the same behaviour you are seeing. Also on Hardy.

I'll continue to see if we can track down the cause. If there are any other thoughts/ideas on your part pleas post here.

Revision history for this message
Arne Fahrenwalde (macgeneral) wrote :

I experience the same problem on Fedora 9!

I made a workaround using Devilspie and forcing AWN on all workspaces with it... But it seems that it doesn't work if I log in the first time but works when I restart AWN.

Weirdly it also seems that it worked once or twice without Devilspie but not alway.

I use GNOME 2.22.1 with Metacity 2.22.0-3 with AWN 0.2.6 and the Open Source nVidia Driver (nv). I enabled the Composite Setting using Gconf as well and I transfered my old settings from AWN & Compiz etc. when switching from Debian Lenny (testing) to Fedora 9.
As I can't use Compiz right now because the new X-Server in Fedora is still a beta and nVidia doesn't release any drivers for Beta packages -.-

I will try to purge all my settings (incl. the Compiz ones maybe) and then repost if it changed anything

Revision history for this message
Arne Fahrenwalde (macgeneral) wrote :

Just purged all my settings and still no change!

Revision history for this message
Brice Terzaghi (terzag) wrote :

I tried to remove all my settings the could be related (deleted .gconf and all compiz settings I could find) and no change. Next step will be to remove all my user settings and see what happens.

Anyway, there's a behaviour I didn't see before (might be because I removed Compiz settings or just because I didn't try it):
- if I start Gnome with Metacity and launch AWN, it appears on one desktop only, as reported at first
- if I start Gnome with Compiz (or switch to Compiz before toying with AWN) and launch AWN, it shows up in all desktops as expected; if I then reverts to Metacity, it stays apparent on all desktops.

Revision history for this message
moonbeam (rcryderman) wrote :

This appears to a variation on https://bugs.launchpad.net/ubuntu/+source/xfwm4/+bug/152822

So my guess is that metacity on Fedora 9 is not treating docks as sticky by default... though that seems to be the behavior in other distributions. Maybe there is a configuration option somewhere for this.

A few comments.

1) I'm guessing xfwm4 decided to patch this even though they felt, at least according to the linked bug, that the initial behavior was correct. Anyone know what the exact fix was that was applied to xfwm4?

2) I'm not sure if a WM should treat a DOCK as sticky by default or not... I haven't read the spec closely. I believe a xfwm4 dev indicated that it wasn't a requirement at least. If it is in the spec somewhere that Docks should be treated as sticky my inclination is to leave things the way they are... otherwise we do need to start setting the sticky.

3) njpatel regarding your comment about gtk_window_stick () in the linked bug. It is being used. It's not working. I also tried changing its position earlier and later within the code and could not get the state set.

4) Metacity on Hardy, and on my own system have treated awn as sticky. I have used several versions since the initial release of the new compositor and have never seen it vary from this behavior. This is not meant to imply that it is doing the "right" thing by default.

Revision history for this message
Tony (to-tophill) wrote :

I'm another user with same problem.
Ubuntu Hardy, Metacity (not compiz) , nv driver.

moonbeam (rcryderman)
Changed in awn:
importance: Undecided → High
status: Incomplete → Confirmed
Revision history for this message
Danilo Marques (pcdanpos) wrote :

Hi folks! I've had this same problem with awn and I got success to workaround it with devilspie application. Relevant informations:

- Ubuntu Hardy Heron i386 installed on Nec Versa notebook completely up-to-date (hardy security / updates / proposed);
- metacity 2.22.0-0ubuntu4;
- avant-window-navigator-trunk 0.3.~bzr244-hardy1-1;
- devilspie 0.21-1;

I created the .devilspie directory and inside it the file awn.ds with following content:

(if (is (application_name) "avant-window-navigator") (pin))

Saved the file and so I created an entry at sessions to devilspie (System -> Preferences -> Sessions):

Name: Devilspie
Command: /usr/bin/devilspie
Comment: Find windows and perform actions on them

Saved it and restarted the system. After the next boot and logged into X session, I got awn properly pinned to all workspaces.

FYI.

Danpos.

Revision history for this message
moonbeam (rcryderman) wrote :

Danilo, Thank you for the temporary fix.

We're definitely looking into getting this properly resolved. I"ve looked into the issue and we are do the proper calls to set awn as sticky... but it's not sticking for some reason. This bug definitely does have a high priority though.

To further complicate matters I am absolutely unable to duplicate the bug on metacity 2.23.8.

According to my understanding the following procedure should trigger it:

1) close awn.
2) start metacity.
3) start awn.

But things still work for me. Can someone confirm this sequence triggers the bug.

Revision history for this message
Brice Terzaghi (terzag) wrote :

I can confirm the following behaviours on my system :
- start Metacity, start AWN : appears only on one desktop
- start Compiz, start AWN, switch to Metacity : AWN appears on all desktops
- start Compiz, start AWN (appears on all desktops), close AWN, switch to Metacity, start AWN : appears only on one desktop

It seems related to starting AWN from Metacity.

But as I said above, this doesn't happen with a new user with default settings : starting AWN from Metacity makes it appear on all desktops. I think it's a bug from Compiz Fusion messing with the user settings rather than AWN itself.

Revision history for this message
moonbeam (rcryderman) wrote :

ok.. to sum up at this point. I think the most relevant points are.

1) Happening on metacity on Fedora 9 and Ubuntu Hardy. Disregard my implication at one point that his was a Fedora 9 issue... I was dealing with a Fedora only (seemingly) but at the same time :-) So seemingly an issue with the new metacity with the new compositor. However, I am unable to reproduce on Gentoo with metacity 2.23.8

2) For some people it might be related to having previously run compiz. A new user account does not exhibit the issue if compiz has not been used. We seem to have a least one case of the bug appearing without this though.

3) If awn is started under a different WM (such as compiz) then the bar is stick as expected and switching to metacity without closing awn leaves awn on all desktops. However if awn is started after metacity then the issue appears.

4) Even though the awn code is calling gtk_window_stick() that state is not showing in 'xprop -name avant-window-navigator' This is definitely the problem.

Revision history for this message
moonbeam (rcryderman) wrote :

Possible fix committed with revision 262. Can someone test?

Changed in awn:
status: Confirmed → In Progress
Revision history for this message
Danilo Marques (pcdanpos) wrote :

@moonbeam

This revision is for avant-window-navigator-trunk or is for another branch? Please confirm that information.

Danpos.

Revision history for this message
moonbeam (rcryderman) wrote :

This is for trunk. https://code.edge.launchpad.net/~awn-core/awn/trunk

However, if you're using the ppa then it has not been refreshed with to this new revision yes. The only way to currently test would be using source. I'll leave a note here when the awn-testing ppa has been refreshed with this revision. https://launchpad.net/~awn-testing/+archive

Revision history for this message
Danilo Marques (pcdanpos) wrote :

@moonbeam

Thanks for information. I'll wait that revision be available for ppa (trunk) branch (it's that I use right now).

Danpos.

Revision history for this message
moonbeam (rcryderman) wrote :

The ppa has been updated to rev 262

Revision history for this message
moonbeam (rcryderman) wrote :

rev 262 was a partial fix. The bar (background) was not being made sticky. That is remedied in rev 264

Changed in awn:
status: In Progress → Fix Committed
Revision history for this message
Danilo Marques (pcdanpos) wrote :

@moonbeam

Today at afternoon (local time) I got notification from update-manager (security and others including awn packages from ppa - trunk - branch). I got the rev 264 and after installed them and reboot the machine, where I took care of disable devilspie workaround, I can to say you the avant-window-navigator (ppa/trunk rev 264) is working PROPERLY here with Metacity (i.e., it's sticked on all workspaces).

Thank you for yours efforts in order to fix awn for us.

Regards,

Danpos.

Revision history for this message
Brice Terzaghi (terzag) wrote :

Seems to work for me too.

moonbeam (rcryderman)
Changed in awn:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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