GNOME Bugzilla – Bug 338271
GtkTreeViewColumn header is not accepting all widgets
Last modified: 2014-08-03 20:55:09 UTC
The docs state that oone can set a custom widget for the GtkTreeViewColumn header. This is only half of the truth. The implementation always creates a button and either sets a lable as the child of the button or the custom widget the user provides. The problem with this approach is, that if the custom widget is e.g. a box containig buttons, the buttons won't work. Shouldn't it in gtk_tree_view_column_create_button() just use the user supplied child for tree_column->button, indead of adding another button around? Additionally/alternativly, if the button is not clickable, can't it forward the events to the child widget?
Created attachment 63523 [details] screen shot for desired result It would be cool, if someone could comment if a patch to make this possible in the treeviewcolumn has any chance to become accepted. If not I will try to work around, by hiding the headers and adding a table above (in a scrolled window). The scrolled window for the table and for the treeviwe will share the scoller.
Changing this for all users of custom header widgets is going to cause problems. A patch which adds a way to optionally leave out the extra button might be accepted...
Created attachment 64075 [details] [review] first implementation The implementation as such works for me. The patch applies against gtk-2.8.13, buut (with offsets) also against gtk-head. There are two 'issues' where I am glad for any comments: 1.) how to name the property (and the function): Currently 'wrap-header-widget'. Basically the boolean properties decides wheter the header-bin will be a GtkButton or a GtkFrame. I don't know if it is worth to add a enum and make it a enum property 'header-bin-type'. 2.) The frame looks different than colums with a button header, any idea?
Created attachment 64078 [details] [review] first implementation (+bugfix) okay a GtkFrame has no "clicked" signal.
I am not sure if I like this idea. Sorting and reordering columns is effectively disabled for non-button headers. (I see that you probably don't need this in your application). When placing another widget, I don't know if GtkFrame is the way to go here. I think this feature is too specific to go into main gtk+, not 100% sure yet.
I understand what you mean. But in the same way sorting is quite special to other apps. I don't think that people want to use sorting together with this. The alternative for me is to turn off headers and fake them with a table packed above the treeview. But then reordering columns of course also does not work.
To keep sorting intact I'd suggest to change GtkTreeView to emit signals expressing those sorting needs - but this could be quite complicated. More trivial and robust might be the approach to make the wrap-header-widget non-public and extend the gtk_tree_view_column_set_wrap_header_widget call in a way, that it has to pass callback functions for keeping sorting intact. If there are more than one or two callbacks are needed, it also might make sense, to introduce some interface for that purpose "GtkTreeViewHeaderProviderIFace".
closing old bugs