RE: [stellation-res] #34471 Comment HoverText: Input Requested

["Jonathan Gossage" <jgossage@xxxxxxxx>]

> -----Original Message-----
> From: stellation-res-admin@xxxxxxxxxxxxxxx
> [mailto:stellation-res-admin@xxxxxxxxxxxxxxx]On Behalf Of Jim Wright -
> IBM Research
> Sent: Tuesday, March 11, 2003 11:19 PM
> To: stellation-res@xxxxxxxxxxxxxxx
> Subject: Re: [stellation-res] #34471 Comment HoverText: Input Requested
>
>
> At 07:26 PM 3/11/2003, Mark C. Chu-Carroll wrote:
> >On Tue, 2003-03-11 at 16:54, Jim Wright - IBM Research wrote:
> > >
> > > There are at least 4 options now.
> > >
> > > 1. Upgrade to GTK 2.0.6 (or 2.2.1) and see if the bug is resolved.
> > > This is the most appealing option ("let's just hope it goes
> away..."), but
> > > may be difficult to do with my current distro (RedHat 7.3), at least
> > without
> > > some help from Mark or another Linux guru, since upgrading
> GTK will require
> > > changing many other parts of my system; when I looked into it
> a few weeks
> > > ago, the interdependencies seemed pretty tangled.
> >
> >I strongly recommend this route. The way to do it is to grab the gtk
> >sources and compile and install them. The version of gtk2 that came with
> >RedHat 7.3 has a bunch of bugs that got fixed in later versions.
>
> I'll be glad to give it a whirl tomorrow (especially if you'll be around
> in case I toast my Linux installation).
>
>
> >I've  been using the development versions of xfce-v4, and there were a
> >bunch of problems that turned out to be specific to gtk-2.0.2 and
> >before. I'm using 2.0.8. (2.2 causes frequent crashes with RC1 - I
> >haven't tried it with RC2 yet.)
>
> So, would you recommend GTK+ 2.0.9 (the latest 2.0-vintage GTK according
> to gtk.org), or 2.2.1 (the "stable, bugfixed" version of 2.2) ??
>
> FWIW, the Eclipse R2.1 plan states 2.0.6 , but then says "2.2 required for
> DBCS", which implies 2.2 should work.  (When installing M5 or RC1 in the
> Linux-GTK config, I got a warning saying "2.0.6 or higher", so I assume
> either 2.0.8 or 2.0.9 should work.
>
>
> >Don't try to do an RPM upgrade - you'll see a huge number of bizzare
> >dependencies that need to be fixed in the "devel" versions of numerous
> >packages.
>
> That's just what I saw.
>
> >But if you just compile (with --prefix=/usr) and install
> >it, everything works correctly.
>
>  From your fingers to my keys .....
>
>
> > > 3. Change the Revision Selection dialog to use a separate
> label field for
> > > displaying the comment text for the current tree item.  I can
> easily make
> > > this field update dynamically (without clicking) as the cursor pauses
> > over a
> > > given tree node.  The comment field would be placed above or
> below the Tree
> > > widget, creating a certain cognitive disconnect between the
> comment and the
> > > corresponding item.   In addition, the hovertext dynamically resizes
> > per the
> > > length and linecount of the comment; this is not available
> with a separate
> > > label field (unless the dialog itself is resized dynamically,
> which is not
> > > an appealing solution).
> >
> >To be honest, I'm not overjoyed with the hoverhelp way of handling
> >comments. I'm not sure what the right solution is; but the version
> >comments are crucial data, and I expect that it will be a relatively
> >frequent process to browse through versions using the version comments.
> >The idea of going to each version and sitting the cursor over it and
> >waiting for the hoverhelp to come up just doesn't seem particularly
> >attractive.
>
> The hoverhelp is intended as a quick, relatively screen-conserving way
> to show comments as an auxiliary memory aid -- e.g. "I'm pretty sure I
> want revision 72 - let's check the comments -- yup, that's it".
>
> For situations where one wants to see comments for many revisions
> simultaneously,
> a table approach (branchName - version ID - 1st line of comments)
> is a pretty typical approach.  Multi-line comments might be handled using
> hover text (over the single-line comment field), clicking a [+]
> button next
> to a given comment field to open a multi-line field on it, or
> expanding the
> table vertically (with uneven row heights) so that all comments are
> displayed in
> their full glory.  There are also query-based approaches (keywords, free
> text...)
> and possibly non-tabular visual navigation techniques as well.  But I
> digress...
>
> It's quite possible that hovertext isn't the best way to go for comment
> display.
> However, the basic notion of a popup widget that appears when one hovers
> over a
> tree node (or table cell, or hotpost within an editor) seems like
> a fairly
> useful
> approach for a number of purposes.  The popup widget need not be a simple
> text field;
> it can be a dynamically-composed menu, a button panel, dialog, whatever.
> The underlying thought is "use tree nodes for structured
> navigation/presentation, then
> augment with context-dependent / options that pop up when you
> hover over a
> node".
> One such option could well be "show list of X (comments, branches,
> committers ....)
> and let me perform further actions using one or more list entries ..."
>
> I chose the current approach in order to explore the hovertext
> notion while
> providing
> some minimum-but-reasonable functionality for selecting a revision.
> Other ideas welcome, as always --
>
> - Jim

I personally find the hovertext paradigm as conventionally implemented very
frustrating because of the response time lag. I would find it more
acceptable if there were a key that could be used in conjunction with the
mouse to say "I'm here -- give me the hovertext NOW".

Regards

Jonathan