[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
--------------------------------------------------------------------
Jim Wright, IBM T.J. Watson Research Center
*** The Stellation project: Advanced SCM for Collaboration
*** http://www.eclipse.org/stellation
*** Work Email: jwright@xxxxxxxxxxxxxx ------- Personal Email:
jim.wright@xxxxxxx
