GNOME Bugzilla – Bug 142494
treeview coordinate systems need documentation/auditing
Last modified: 2011-02-04 16:11:01 UTC
There appear to be three different coordinate systems: - tree coordinates, which are relative to the large area in the code these are also called rbtree coordinates - widget coordinates, which are relative to the visible area - tree window coordinates, which are relative to the gdk window backing the tree view. These used to be the same as tree coordinates, but with the introduction of incremental reflow, the window was changed to be as wide as the large area, but only as high as the visible area. So these coordinates are horizontally the same as tree coordinates, but vertically the same as widget coordinates. Events are reported in this coordinate systems. We have translation functions between tree and widget coordinates, but not to tree window coordinates, which are e.g. returned by get_cell_area(). This may cause a number of bugs, e.g. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=91845 I've appended a fix for this one here, but the most important thing to do is IMO to document the coordinate systems, so that people can actually figure out whats going on.
Created attachment 27677 [details] [review] the patch The patch is incomplete, it only adds the one needed transformation function.
Patch applied.
Here is a list of tree view functions dealing with coordinates, and what kind of systems they operate in. I think this should be documented, and we may need to add conversions widget<->tree window widget coordinates (relative to widget->window) gtk_tree_view_get_dest_row_at_pos (I think it fails to translate the x coordinate correctly before calling gtk_tree_view_get_path_at_pos) tree window coordinates (relative to tree_view->priv->bin_window) gtk_tree_view_get_path_at_pos (docs erroneously speak about widget coords...) gtk_tree_view_get_cell_area gtk_tree_view_get_background_area gtk_tree_view_column_cell_get_size gtk_cell_renderer_get_size tree coordinates (relative to the "origin of the tree") gtk_tree_view_get_visible_rect gtk_tree_view_widget_to_tree_coords gtk_tree_view_tree_to_widget_coords gtk_tree_view_scroll_to_point special: gtk_tree_view_column_cell_get_position
#140819 now has a patch for adding the widget<->tree window conversions.
Would you mind making gtk_tree_view_tree_window_to_tree_coords public (declare it in gtktreeview.h)? It is useful outside of gtk+-sources too.
*** Bug 140819 has been marked as a duplicate of this bug. ***
Matthias, would you mind if I remove gkt_tree_view_tree_window_to_tree_coords() again and replace the only usage of it with TREE_WINDOW_Y_TO_RBTREE_Y(), which is what all of gtktreeview.c uses internally to do this calculation? I wonder about to use for this outside of GTK+, usually you just want to use gtk_tree_view_widget_to_tree_coords(). And yes, this function is indeed misnamed, it should have been named gtk_tree_view_bin_window_to_tree_coords() (or actually gtk_tree_view_tree_to_tree_coords().) The patch in 140819 actually is the correct implementation for gtk_tree_view_widget_to_tree_coords(), but we need to make up another name for this since that name is already taken. The names with "drag_coords" which are currently in the 140819 patch don't make sense. Any suggestions? Maybe just gtk_tree_view_widget_to_bin_window_coords() and vice versa? And I agree that gtk_tree_view_get_dest_row_at_pos() needs to translate the x coordinate, nobody has probably ever noticed this. Since things are getting really confusing now I will update the documentation too once we get this nailed.
Created attachment 89485 [details] [review] audit of GtkTreeView coordinate systems incl. doc updates Basically the patch in the other bug was not the same as gtk_tree_view_widget_to_bin_window_coords() and vice versa. And right now I don't think x should be corrected in gtk_tree_view_get_dest_row_at_pos(). (Did I mention this stuff is confusing? ;) ) Anyway, I think this patch gets it all right, though I want to read through once more tomorrow. I will make the pretty image for the docs on my mac tonight.
Created attachment 89797 [details] attempt at image
Created attachment 89804 [details] better try, using tango colors and minus separator
Looks good to me upon cursory inspection. A bit unfortunate that some of the existing conversion functions are misnamed. Do we want to deprecate the misnamed ones and introduce a complete set of consistent names ?
(In reply to comment #11) > Do we want to deprecate the misnamed ones and introduce a complete set of > consistent names ? I've been thinking about that, I see two options in such a case: 1. We deprecate gtk_tree_view_widget_to_tree_coords() and rename it to gtk_tree_view_bin_window_to_tree_coords() (and vice versa). Though this will not create the possibility for us to have a gtk_tree_view_widget_to_tree_coords() which will call both gtk_tree_view_widget_to_bin_window_coords() and gtk_tree_view_bin_window_to_tree_coords(). 2. If we want to have gtk_tree_view_widget_to_tree_coords(), I see no other possibility than to have slice change in namespace, we would then end up with: gtk_tree_view_convert_widget_to_bin_window_coords() gtk_tree_view_convert_widget_to_tree_coords() gtk_tree_view_convert_bin_window_to_tree_coords() (and vice versa). Option 2) is probably not bad at all since those function methods are crystal clear.
Yeah, adding "convert" somewhere in the function name was my thought, too.
Created attachment 89848 [details] [review] updated patch Okay, I deprecated the old functions and added all new functions prefixed with gtk_tree_view_convert. Fixes some doc errors in the patch here and there... Will re-read and commit as the first thing tomorrow.
Committed on trunk. (r18119).