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 650614 - Group headers are no longer clickable
Group headers are no longer clickable
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
3.0.x
Other Linux
: Normal normal
: ---
Assigned To: gtktreeview-bugs
gtktreeview-bugs
: 650028 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-05-19 17:18 UTC by Will Thompson
Modified: 2018-04-15 00:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Will Thompson 2011-05-19 17:18:01 UTC
In 2.x versions of Empathy, I could click anywhere on the group-header rows of the contact list to expand or contract the group, not just on the disclosure triangle.

Since Empathy 3.0, clicking on the name of the group does nothing at all. One must click on the [+] or [-] (the new styling for disclosure triangles) at the right-hand side of the row.

Coupled with bug 632787, this means the only way to expand and collapse groups is by clicking on a tiny 16×16 pixel area. :)
Comment 1 Guillaume Desmottes 2011-05-20 12:01:59 UTC
Looks like a GTK+ change. With GTK+ 2, the EmpathyCellRendererExpander is
activated when we click anywhere on its row. While with GTK+3 we have to click
exactly on the expander.
Comment 2 Guillaume Desmottes 2011-05-20 12:09:04 UTC
I checked with Kris on IRC and that's a GTK+ 3 regression.
Comment 3 Kristian Rietveld 2011-05-20 12:18:00 UTC
This feature is relying on the GtkCellRenderer:activate signal and there's a Text renderer next to the Expander renderer in the same column.  In GTK+ 2 a non-editable renderer next to an editable renderer in the same column was treated as a single cell.  In GTK+ 3 we introduced "focus siblings" to handle this, but the case of a non-editable renderer next to an editable renderer is no longer automatically marked as focus sibling.  This can be verified in testtreeedit with a small modification.

Tristan, do you remember if we had a reason to change this behavior?  Or can I change the code to insert the focus sibling in this case?


(Actually I think the focus rectangle for this case is done with this code and not siblings:


  /* If no cell can activate but the caller wants focus painted,
   * then we paint focus around all cells */
  if ((flags & GTK_CELL_RENDERER_FOCUSED) != 0 && paint_focus &&
      !gtk_cell_area_is_activatable (area))
    render_data.focus_all = TRUE;

)
Comment 4 Matthias Clasen 2014-09-24 01:47:00 UTC
*** Bug 650028 has been marked as a duplicate of this bug. ***
Comment 5 Matthias Clasen 2018-02-10 05:01:48 UTC
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Comment 6 Matthias Clasen 2018-04-15 00:15:49 UTC
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla.

If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab:

https://gitlab.gnome.org/GNOME/gtk/issues/new