GNOME Bugzilla – Bug 602447
Missing function in GtkTreeView - gtk_tree_view_is_blank_at_pos()
Last modified: 2009-11-24 21:45:39 UTC
In Nautilus, using listview mode, there is no way to get context menu for the current folder (https://bugzilla.gnome.org/show_bug.cgi?id=94618). Despite being one of the most hated bugs in Gnome for almost 8 years, this problem has never been solved since when was first reported. Examining Nautilus source code fm-list-view.c, we can see that the problem happens because there is no way for the application to know over which kind of content in TreeView mouse pointer is when right click event is raised. This situation could easily be changed if there were a function in GtkTreeView which returned if mouse coords points to a blank area or a "texted" area. Thus, when right click occurs in TreeView over a blank area of a non selected item, Nautilus can consider that the background has been clicked and, then, present the current folder context menu. Similar behavior to Windows Explorer. The missing function could be: gboolean gtk_tree_view_is_blank_at_pos (GtkTreeView *tree_view, gint x, gint y); tree_view: A GtkTreeView. x: The x position to be identified (relative to bin_window). y: The y position to be identified (relative to bin_window). Returns: TRUE if coordinate points to a blank area or FALSE if not.
(In reply to comment #0) > This situation could easily be changed if there were a function in GtkTreeView > which returned if mouse coords points to a blank area or a "texted" area. > Thus, when right click occurs in TreeView over a blank area of a non selected > item, Nautilus can consider that the background has been clicked and, then, > present the current folder context menu. Similar behavior to Windows Explorer. What is your exact definition of a blank area? In your case it seems to be the area between two cells which could have content but has not been filled (because, for example, the string is not "long enough"). At first, I thought you were talking about the area at the bottom of the tree view below the last row.
The area below the last row, when available, is OK. The problem is how to achieve the background when there is no space below the last row. "Blank Area" in my definition is the horizontal space between two cells which could have content but has not been filled because of the text length. You understood perfectly. When right click occurs over a "blank area" or a "not filled area" of a non selected item, application can consider that the background was clicked and take the correct action. Thank you!
Created attachment 148141 [details] An example for gtk_tree_view_is_blank_at_pos function This source code (fm-list-view.c) is part of Nautilus project, and was modified to solve Bug 94618 using the gtk_tree_view_is_blank_at_pos function, as described in Bug report.
Hey, guys! Shouldn't we be discussing this issue? We have a serious problem that must be solved, we have a proposed solution, we have a source code demonstrating its usefulness, what is missing? I would like to emphasize the importance of finding a solution for this problem, since the Bug 94618 depends on it and is one of the most hated bugs in Nautilus for about 8 years. Is a serious usability flaw: TreeView is actually completely opaque and makes background unaccessible. It is a serious limitation and could be easily solved with the listed modifications (very simple ones). Other graphic Interfaces, like Windows, Mac, and KDE have this problem solved, but GNOME have kept this malfunctioning for such a long time and now, when there is a concrete purpose, there is no technical discussion about the subject. Thank you.
(In reply to comment #4) > Shouldn't we be discussing this issue? We have a serious problem that must be > solved, we have a proposed solution, we have a source code demonstrating its > usefulness, what is missing? A maintainer with enough spare time? Please remember that most of us are doing this in our copious spare time. I am not a student anymore, I have a full-time day job since the house needs to be paid for. And yes, as soon as this bug was reported it has been put on my list of things to look at (patch review and finding the much older bug that I vaguely recall was about the same issue).
I can understand this, even because I'm in the same condition. Somehow our monthly accounts must be paid and this are priorities. I agree. The only thing that makes me worried is the long time that such a significant bug have taken keeping the status NEW (bug 94618), almost without discussions and purposes. During this 8 years other bugs were fixed, new features were implemented, many versions of Nautilus were released, and the background unaccessible in TreeView. Anyway, I would like to thank and show my respect for the maintainers team, because, despite this, GNOME is still the best desktop environment.
Unfortunately, there are more bugs that are at least as significant and have been open for ~8 years. Anyway, back to the subject. There has been a bug reported on this issue in the past and I will mark this bug as a duplicate of that one. It is not worded exactly the same, but at least they share the need for the same solution: some way to figure out whether the area is "empty" or "blank". As is discussed in the mailing list thread linked from that bug, this might be fixed easiest by first pushing some refactorings I have done in the past to trunk. Hopefully, I will soon have time to find and update these patches. *** This bug has been marked as a duplicate of bug 350618 ***