Re: #80127 Rubberbanding issues
On 5/19/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: The traditional answer to this request is: a treeview is not a table. Oh, it isn't? Then it must be high time to undeprecate gtkclist. Otherwise there is a big hole in gtk's widget coverage. Seriously, the treeview has been touted as gtk's replacement for all things tabular and when no expanders are in sight, the user will see it as a table. Take a look at one! For example the one in the default filechooser. It clearly has columns and rows. How much more like a table can it get? It could have rectangular selection, and treat rows and columns symmetrically. But it doesn't do that, since it is not a table. Matthias ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: #80127 Rubberbanding issues
hi kris, selection is unfortunately limmited to whole lines. is that also the case for the rubber-banding. I needed to misuse the cell-renderers background color to get rectangular selections. Stefan Am Dienstag, den 16.05.2006, 15:14 +0200 schrieb Kristian Rietveld: Hey all, A few months ago I have been working on a rubberbanding feature for GtkTreeView. It is basically ready to go in CVS, but there are two issues left which are worth discussing here: I. We are not fully sure how to handle the interaction between rubberbanding and DnD. Right now we decide what to do when a drag starts, if the row where the drag started is selected we start a DnD operation. If unselected, we start a rubberbanding operation. This works pretty okay, but I think it will break apps (nautilus, and probably some others) out there when enabled by default. I see two options: - Either disable rubberbanding by default, - or come up with a method for deciding whether to DnD or rubberband without breaking current applications. I am tempted to go for disabling by default, and when enabled use the behaviour I described above. II. The rectangle color is currently hardcoded to black, since that looks best with the default theme. Picking a shade of one of the theme colors for the rectangle color will not always turn out nice, so I think it might be a good idea to add a style property for this to GtkTreeView and default to black for the default theme. Opinions? Suggestions? thanks, -kris. PS. The patch is here for those interested: http://bugzilla.gnome.org/show_bug.cgi?id=80127 ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: #80127 Rubberbanding issues
On Tue, May 16, 2006 at 05:37:06PM +0100, Ross Burton wrote: On Tue, 2006-05-16 at 12:25 -0400, Matthias Clasen wrote: II. The rectangle color is currently hardcoded to black, since that looks best with the default theme. Picking a shade of one of the theme colors for the rectangle color will not always turn out nice, so I think it might be a good idea to add a style property for this to GtkTreeView and default to black for the default theme. I recently removed one instance of hardcoded black from the treeview dnd code. It would be sad to reintroduce another one now; black does not work in hicolor-inverse and similar themes... And GtkTreeView uses fg_gc for this now. How about working out a shading of the theme colours that works for the popular themes (default and some other stock ones), and allow the other themes to override it if it looks bad for them. I've modified the rubberbanding code to use fg[GTK_STATE_NORMAL] as rubberbanding color and tried some different themes. This color seems to look good with all themes I tried, so I would propose to go for using the fg[NORMAL] color. thanks, -kris. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
