Awn

Program Icon on Taskbar should migrate with window when moved to another desktop (3d desktop)

Bug #145722 reported by nulled
18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Awn
Fix Released
High
haytjes

Bug Description

I am running Ubuntu Feisty Fawn with Beryl and Avant Navigator.

This may or may not be a bug.

If I Spawn a program naturally I will see the Programs ICON on Avant's Task bar as it should.

But, if I move that same spawned program to another desktop ( say from Desktop #1 to Desktop #2)
Avant (in my view) should move the taskbar Icon with it to desktop #2.

I know that the program was spawned from Desktop #1 however, it would be cool if Avant would also
readjust or move program Icons so they follow their Window if that window is moved to another desktop/viewport.

:)

Keep in mind I have "Show windows from all Viewports UNCHECKED"

Revision history for this message
Andrew Starr-Bochicchio (andrewsomething) wrote :

Running Compiz Fusion on Gutsy, I can reproduce this if the window is moved through the window's left click context menu. If I physically drag it to another workspace, the icon updates as expected.

Changed in awn:
status: New → Confirmed
Neil J. Patel (njpatel)
Changed in awn:
milestone: none → 0.2.8
Revision history for this message
haytjes (h4writer) wrote :

Also affects awn-rewrite. Bug in awn-rewrite is even worse. This should be fixed before release of awn-rewrite.

Changed in awn:
importance: Undecided → High
milestone: 0.6.0 → 0.4.0
haytjes (h4writer)
Changed in awn:
milestone: 0.4.0 → 0.3.2
haytjes (h4writer)
Changed in awn:
assignee: nobody → h4writer
Revision history for this message
haytjes (h4writer) wrote :

This patch should solve it.
Problem was that Compiz uses viewports instead of workspaces.
Also Wnck doesn't deal well with viewports. Atleast there is no easy way to know if a window is moved from one viewport to another. This patch listens to the moves of the window and determinates if the window is moved off the viewport and then asks awn-task-manager to check every task if it should be visible.

I'm still doubting to add a key (like in shiny-switcher) to determinate first if the workspace is working with viewports and then only run the code when there are viewports?

Revision history for this message
moonbeam (rcryderman) wrote :

haytjes,

The relevant code for detecting viewports in shinyswitcher is

=================
  shinyswitcher->got_viewport = wnck_workspace_is_virtual(wnck_screen_get_active_workspace(shinyswitcher->wnck_screen));

  if (wnck_screen_get_window_manager_name(shinyswitcher->wnck_screen))
    if (strcmp(wnck_screen_get_window_manager_name(shinyswitcher->wnck_screen), "compiz") == 0)
    {
      printf("ShinySwitcher Message: compiz detected\n");
      shinyswitcher->got_viewport = TRUE;
    }
=================

We don't have to use a config key at all... and the signals can be hooked up conditionally based on the result.

haytjes (h4writer)
Changed in awn:
status: Confirmed → In Progress
Revision history for this message
Michal Hruby (mhr3) wrote :

Attached is edited h4writer's patch with moonbeam's suggestion.

@moonbeam: Please review.

Revision history for this message
moonbeam (rcryderman) wrote :

I'll review fully tomorrow.... but the use of wnck_screen_force_update() probably needs to be removed.

I will definitely make time tomorrow (taking it somewhat easy).

Revision history for this message
Michal Hruby (mhr3) wrote :

Note that without the use of wnck_screen_force_update(), I was unable to get valid workspace wnck_screen_get_active_workspace() and also wnck_window_get_workspace() returned always NULL.

Revision history for this message
moonbeam (rcryderman) wrote :

if wnck_screen_force_update() is only called on startup of awn then that is ok.

Revision history for this message
Michal Hruby (mhr3) wrote :

Fix pushed to trunk r533.

Changed in awn:
status: In Progress → Fix Committed
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.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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