(I'm assuming your window manager is metacity, if that's not the case, please tell us)

I'm not in a good enough state to know if this is a libwnck or a metacity bug. Moving to libwnck for now.

Ok,.. thanks again (as with the notification area bug).
btw: If there are fixes for these bugs,.. will they go into the 2.20 branch or will I have to wait the long time until 2.22?

Another issue: I'm heavily use multiple screens and as far as I know most GNOME developers only have access to single screen setups...
In my long "experience" with multiple screens, I've probably collected lots of ideas how to improve GNOME's multiscreen support.
I've already filed a big bug some years ago but nothing happened.

Are you much involved in the related parts of GNOME? So I could write you some of my ideas and you can share them with the responsible people.

Regards,
Chris.

(In reply to comment #2)
> Ok,.. thanks again (as with the notification area bug).
> btw: If there are fixes for these bugs,.. will they go into the 2.20 branch or
> will I have to wait the long time until 2.22?

They'll go in 2.20 if they don't imply major code changes.

> Another issue: I'm heavily use multiple screens and as far as I know most GNOME
> developers only have access to single screen setups...
> In my long "experience" with multiple screens, I've probably collected lots of
> ideas how to improve GNOME's multiscreen support.
> I've already filed a big bug some years ago but nothing happened.
> 
> Are you much involved in the related parts of GNOME? So I could write you some
> of my ideas and you can share them with the responsible people.

The most important part is filing the bugs, and if you've done this, then that's already great :-)

It might be useful to have a list of all those bugs somewhere, so they're easy to reach. Feel free to share ideas with me if you want. Or maybe you can start a wiki page on live.gnome.org and link all the bugs from there and add your ideas there? Then it'll be a good place to start fixing multiscreen bugs.

Any progress here in the meantime?
This bug is extremely annoying and I cannot imagine that it's so difficult to fix as it used to work in 2.18...

Best wishes,
Chris.

I can confirm that this bug continues to exist in GNOME 2.20.

I can confirm continued existence of this bug in Workspace Switcher 2.20.2, as shipped in Fedora 8.

An added datapoint tho, the bug appears to be slightly elusive and only appear in some configurations, even if perfectly reproducible (for me at least):

If I add a workspace switcher as a single row to the top panel of each screen it will work as expected (switching each screens appropriate workspaces).

If I add a 2-column workspace switcher in a side panel on screen #1 and a single-row switcher on the top panel of screen #2 it will still work as expected.

However, if I add a switcher to an extra side panel on screen #2 it will assume the same configuration as the switcher on screen #1, and act as if it were a switcher on screen #1 (switching the first screens workspaces, etc).

Wow! You're right,... the top panel (meaning a panel that is located on the top of the screen) works,..
But on the bottom it doesn't.

David: interesting. At least, this suggests that this is an applet/libwnck bug and not a wm bug.

Could probably be a race where something is setting the internal pointer to the screen to the default screen because the widget hasn't been added to a widget hierarchy. Hrm. Most probably happening, looking at the code.

I think the fix is:
 + in wnck_pager_set_layout_hint(), if pager->priv->screen is NULL, be more clever and don't blindly set the screen. Only set it if the widget has been added to a container (or look at gtk_widget_get_screen_unchecked())
 + maybe the same in wnck_pager_size_request(), although I fail to see why someone would request the size of the widget before having added to a container

If somebody can test this... :-)

(In reply to comment #4)
> Any progress here in the meantime?
> This bug is extremely annoying and I cannot imagine that it's so difficult to
> fix as it used to work in 2.18...

It's actually quite hard to fix if you don't know why this is happening, and since no developer has a setup with multiple X screens, it doesn't help.

Ok, bear in mind that I'm completely unfamiliar with the code, but I had some time and, following your suggestion, got it working by using the following change: 

in wnck_pager_set_layout_hint()

 /* if we're not realized, we don't know about our screen yet */
  if (pager->priv->screen == NULL)
    if (gtk_widget_has_screen (GTK_WIDGET (pager))) {
       _wnck_pager_set_screen (pager);
    } else {
        return FALSE;
    }
  g_assert (pager->priv->screen != NULL);

I've committed a fix. I'd love if one of you could try libwnck trunk and check that it works as expected.

Thanks!

Yay, yes, your fix worked nicely on my machine at work at least.

Thankyou very much :)

In comment #10, is the fix included in libwnck-2.20.3?
I have a similar (but not the same) problem with workspace switcher on a dual screen (not Xinerama) setup, but it has not been fixed by upgrading to
libwnck-2.20.3.

Since it is probably not the same bug, I have filled a separate bug #512521.

Jan: no, it's not in libwnck 2.20.3.

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

Yes,.. it works in GNOME 2.22... at first I thought my system was hacked (when the workspace switcher worked again)... but then it turned out that this bug was actually just fixed ;)


If now someone could fix #346162 an perhaps improve multiscreen support in general (@Vincent: do you remember my email with some proposals?) that would be like Christmas and Easter together ;)

Thanks for fixing,
Chris.

Christoph: I still have your mail in my inbox :-)