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 142971 - treeview doesn't allow to edit editable GtkCellRendererText by double-click
treeview doesn't allow to edit editable GtkCellRendererText by double-click
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: GtkTreeView
2.4.x
Other All
: High normal
: Small feature
Assigned To: gtktreeview-bugs
gtktreeview-bugs
Depends on:
Blocks:
 
 
Reported: 2004-05-22 18:10 UTC by Christian Neumair
Modified: 2018-04-15 00:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Proposed patch against GTK+ 2.4. Applies cleanly against HEAD as well. (683 bytes, patch)
2004-05-22 18:11 UTC, Christian Neumair
needs-work Details | Review

Description Christian Neumair 2004-05-22 18:10:07 UTC
Currently, the treeview doesn't allow users to edit an editable text cell
renderer by double clicking it. This is fishy since you can start editing by
first selecting it and then - after the double-click period - clicking it again.
But if you press the button again before the period is over, it is only
selected. This is really horrible usability-wise.

regs,
 Chris
Comment 1 Christian Neumair 2004-05-22 18:11:10 UTC
Created attachment 27937 [details] [review]
Proposed patch against GTK+ 2.4. Applies cleanly against HEAD as well.
Comment 2 James Cape 2004-05-22 20:29:28 UTC
One thing to keep in mind is that double-clicking on a row fires the
"row-activated" signal. So a behavior change to double-click-to-edit would
probably have to check if the cell is editable or not first.

The real question is one of expectations... Does the user expect double-clicking
on a row to edit the cell under the pointer or does he/she expect it to perform
the "activate" behavior (whatever that is). AFAIK, the current behavior is
"always activate", so perhaps a CTRL+double-click could start the edit?
Comment 3 Kristian Rietveld 2006-05-26 01:19:08 UTC
I think I like the idea of having a double click on an unselected row start editing.  However I am seeing some problems too:

* "row-activated" will not be emitted with the patch applied, because the button-press signal handler will return TRUE after it has start the editing operation.  Row activation is handled later in the button-press handler and that code will not be reached.  I guess some people might see this change as an API/ABI change, since it never returned TRUE and not activated the row in this case before ...

* The expection problem is indeed another problem.  I don't think a ctrl + double-click will help here, how many users are going to find out about that shortcut?

Not sure what to do.  I am afraid that we can't commit this patch at this stage.
Comment 4 Kristian Rietveld 2006-05-28 13:25:26 UTC
Might be slightly related with #119906.
Comment 5 André Klapper 2015-01-21 05:05:33 UTC
Comment on attachment 27937 [details] [review]
Proposed patch against GTK+ 2.4. Applies cleanly against HEAD as well.

Patch does not apply cleanly anymore ( https://git.gnome.org/browse/gtk+/tree/gtk/gtktreeview.c#n3209 ); setting needs-work status
Comment 6 Matthias Clasen 2018-02-10 05:01:56 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 7 Matthias Clasen 2018-04-15 00:16:06 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