After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 317528 - Window Tabbing highlight broken
Window Tabbing highlight broken
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
2.8.x
Other Linux
: High normal
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on:
Blocks:
 
 
Reported: 2005-09-29 14:38 UTC by Daniel Holbach
Modified: 2005-10-03 17:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12


Attachments
The relevant gtk+ patch for bug 316180 (2.00 KB, patch)
2005-09-30 15:12 UTC, Elijah Newren
reviewed Details | Review
Continue the insanity; do even more stuff behind gtk+'s back and break even more invariants (608 bytes, patch)
2005-09-30 15:42 UTC, Elijah Newren
none Details | Review
Alternate version of the patch, incorporating Havoc's comments (806 bytes, patch)
2005-10-03 17:09 UTC, Elijah Newren
committed Details | Review

Description Daniel Holbach 2005-09-29 14:38:09 UTC
Distribution/Version: Ubuntu Breezy

Forwarded from http://bugzilla.ubuntu.com/show_bug.cgi?id=16589

In previous versions of metacity when Tabbing through windows, it would draw
round the border of the window no matter how deep in the stack it was.  The
resulting effect of this is that I could tab through my windows and rather than
look at the icon and titles, just wait until I saw the border in the place I
remember the window being.

This gave a great subconcious "give me the window that was *THERE*" effect.  In
fact, it was so great and subconcious, I had to have it pointed out to me that
I'd been using and relying on it for ages.

Sadly this appears to be broken in the latest version, and it's like losing a limb.

Instead of drawing the border and keeping it there, it ever-so-briefly flashes
it.  In fact, it's so quick that it's almost impossible to make out.  If this is
a deliberate decision, it was a very bad idea and could it be reverted?  If not,
could we fix the bug.

I'd like my limbs back <g>
Comment 1 Elijah Newren 2005-09-29 15:51:27 UTC
This appears to be due to some other part of the software stack -- I tried
backing up to versions of Metacity from the beginning of August, July, June,
May, then to the Gnome 2.10 version, the 2.8 version, and the 2.6 version.  This
bug persists in all of them.  Maybe I need to try reverting to older gtk+
versions to see if any of those fix the issue?
Comment 2 Dooglus 2005-09-30 06:59:54 UTC
After playing around a lot, I discovered that the working border can be restored
by reverting to an older version of libgtk2.0-0.  I've uploaded a copy here:

  http://s89213869.onlinehome.us/libgtk2.0-0_2.8.3-0ubuntu1_i386.deb

I took it from the breezy install colony 5 image.

chris@chrislap:/tmp$ apt-cache policy libgtk2.0-0
libgtk2.0-0:
  Installed: 2.8.3-0ubuntu1
  Candidate: 2.8.4-0ubuntu2
  Version table:
     2.8.4-0ubuntu2 0
        500 http://archive.ubuntu.com breezy/main Packages
 *** 2.8.3-0ubuntu1 0
        100 /var/lib/dpkg/status

Now all we have to do is work out what changed between those 2 versions...

I notice there is a version between the two, 2.8.4-0ubuntu1.  It would be good
to be able to find a copy of that to see if the bug is in that version or not. 
Are old versions of breezy packages archived anywhere?

The changelog has this to say:

gtk+2.0 (2.8.4-0ubuntu2) breezy; urgency=low

  * debian/patches/003_typeclearname.patch:
    - don't clear the filename when not required (Ubuntu: #13810).


gtk+2.0 (2.8.4-0ubuntu1) breezy; urgency=low

  * New upstream version:
    - fix the fileselector warnings about non-local bookmarks (Ubuntu: #14011).


Neither looks relevant.
Comment 3 Sebastien Bacher 2005-09-30 07:43:45 UTC
reassigning to the right place
Comment 4 Sebastien Bacher 2005-09-30 09:35:02 UTC
the change from http://bugzilla.gnome.org/show_bug.cgi?id=316180 breaks this feature
Comment 5 Elijah Newren 2005-09-30 15:08:06 UTC
I'm not completely sure it's gtk's fault given the comments in the section of
Metacity code that draws draws that black outline.  Perhaps a gtk+ hacker or
Havoc could comment here?

metacity/src/tabpopup.c:display_entry() contains:

  if (popup->outline)
    {
      /* Do stuff behind gtk's back */
      gdk_window_hide (popup->outline_window->window);
      meta_core_increment_event_serial (gdk_display);
  
      rect = te->rect;
      rect.x = 0;
      rect.y = 0;

      gdk_window_move_resize (popup->outline_window->window,
                              te->rect.x, te->rect.y,
                              te->rect.width, te->rect.height);
  
      gdk_window_set_background (popup->outline_window->window,
                                 &popup->outline_window->style->black);
  
      region = gdk_region_rectangle (&rect);
      inner_region = gdk_region_rectangle (&te->inner_rect);
      gdk_region_subtract (region, inner_region);
      gdk_region_destroy (inner_region);
  
      gdk_window_shape_combine_region (popup->outline_window->window,
                                       region,
                                       0, 0);

      gdk_region_destroy (region);
  
      /* This should piss off gtk a bit, but we don't want to raise
       * above the tab popup
       */
      gdk_window_show_unraised (popup->outline_window->window);
    }
Comment 6 Elijah Newren 2005-09-30 15:12:34 UTC
Created attachment 52857 [details] [review]
The relevant gtk+ patch for bug 316180

Since the relevant patch was never attached to bug 316180 and it's relevant for
investigating this bug, I'm attaching it here.
Comment 7 Elijah Newren 2005-09-30 15:16:00 UTC
(Marking the patch commented-on since it isn't being proposed for anything;
sorry for the spam...)
Comment 8 Matthias Clasen 2005-09-30 15:29:39 UTC
Yes, with tims patch, gtk does not like gdk windows being mapped behind its back
anymore. I guess you could filter out the mapnotify to keep gtk from unmapping
the window again, but you are really messing up invariants here. Another option
would be to just use a plain X window.
Comment 9 Elijah Newren 2005-09-30 15:42:27 UTC
Created attachment 52859 [details] [review]
Continue the insanity; do even more stuff behind gtk+'s back and break even more invariants

This may be a Bad Idea (TM), but it at least is convenient as a temporary
workaround.
Comment 10 Elijah Newren 2005-09-30 15:44:57 UTC
So I'm reassigning back to Metacity because of Matthias' comment.
Comment 11 Sebastien Bacher 2005-09-30 16:14:31 UTC
the patch fixes the issue
Comment 12 Havoc Pennington 2005-10-02 18:38:45 UTC
We might clarify in the comments exactly what "piss off gtk" means which I think
is "we never gtk_widget_show(), from gtk standpoint we only realize, but on the
gdk level we are still mapping the window"

The patch I think is fine, but it would be slightly more logical to me if you
put setting the mapped flag right in front of the show() rather than just after
the hide()

Comment 13 Elijah Newren 2005-10-03 17:09:00 UTC
Created attachment 52984 [details] [review]
Alternate version of the patch, incorporating Havoc's comments
Comment 14 Elijah Newren 2005-10-03 17:11:59 UTC
2005-10-03  Elijah Newren  <newren@gmail.com>

	Get the tabbing window outline to work with gtk+ 2.8.4 again.
	Fixes #317528.

	* src/tabpopup.c (display_entry): gtk+ 2.8.4 needs to know the
	mapped state of its windows (see bug 316180), and since we
	manually map with gdk_window_show_unraised() we need to manually
	set the mapped state too