Re: Inplace Tips for GtkTreeView (#346992)

[Kristian Rietveld <kris gtk org>]

On Thu, Aug 03, 2006 at 09:29:04AM -0500, Michael Urman wrote:
> >That fits my assessment. It looks a lot like a tooltip, but it doesn't
> >act much like one, and thus should be separate from tooltips. So what
> >more do you need to know to help you become sure whether or not this
> >belongs in GTK+?
> >
> >Arguments I see for having it in GTK+:
> >  * It requires API addition to CellRenderer interface (the patch uses
> >up a reserved pointer) to determine the real size of a column's
> >contents.

We are going to need a way to get the currently used instead of
requested space for a cell renderer anyway to fix some bugs.  I am still
contemplating if that is worth using one of the class padding pointers
or whether I can find another way to do it.

> >  * It makes it really easy for all applications to use this - just
> >set a property on a TreeViewColumn and it gets inplace-tips for that
> >column.
> >  * From the user perspective, it catches us up to Windows usability
> >in TreeViews.

Last time I used Windows it didn't put some popup window over the tree
view row.  But rather, as you said in the bug report, for example Windows
Explorer displays the name in the left pane; which is IMHO a much nicer
way of solving this problem.  Also, I feel that different applications
need a different solution for this problem.  Personally, I think that
"inplace hints" is too specific to put in GtkTreeView.

> >Arguments against:
> >  * It uses up one of two reserved pointers in the CellRenderer
> >Interface; even if it's doing so with a general function, there might
> >be something more important later.
> >  * It's unproven; only one app is using something close (but less
> >complete), and there have been reports it conflicts with button
> >presses in some environment. It hasn't gone through libegg.
> >
> >I'd really like to see this capability in GTK+, but the sooner we get
> >to a solid yes or no, the happier I'll be.

As I said above I personally don't think this belongs in GTK+.  Of
course this does not have to be a permanent no, we can always revisit
the issue once it's "proven" and more apps are using it to solve the
same problem.

> It's been two weeks without any hints to how I can help you (Kris, or

(I went on vacation and had some weeks off for studying; processing mail
backlog takes some time).

> anyone else) decide. Please give me some indication as to what the
> path is for ths sort of patch. I don't want it to disappear because I
> give up without feedback. I don't mind either a yes or no answer, but
> the silence saps my will to work with GTK+ development.

In my experience getting patches like this in always takes some time and
does not happen within a few days.  For now it seems like a good idea to
hold off, leave it in bugzilla for a while, have it mature and see
whether the app developers see a good use for this feature.


regards,

-kris.