RE: [cdt-dev] CDT textHover

[Thomas Fletcher <ThomasF@xxxxxxx>]

> -----Original Message-----
> From: Chris Moller [mailto:cmoller@xxxxxxxxxx]
> Sent: August 7, 2003 2:41 PM
> To: cdt-dev@xxxxxxxxxxx
> Subject: [cdt-dev] CDT textHover
> 
> 
> Hey, folks,
> 
> A couple of observations/questions about CDT hover help:
> 
> In the current code, in 
> org.eclipse.cdt.internal.ui.DefaultCEditorTextHover 
> getHoverInfo() looks 
> for function info in the CCompletionContributorManager class, which 
> kinda commingles the hover and completion stuff.  Since at 
> present CDT 
> hover and completion stuff is being done by different organisations, 
> would it make sense to split these capabilities into separate 
> classes? 
> I've done that in Red Hat's copy of the code by replacing

What do you mean by different organizations? 
 
> IFunctionSummary fs = 
> CCompletionContributorManager.getDefault().getFunctionInfo(exp
> ression);
> 
> with
> 
> IFunctionSummary fs = 
> CTextHoverContributorManager.getDefault().getFunctionInfo(expression);
> 
> and adding a CTextHoverContributorManager class which looks for 
> extensions to the textHovers extension point.

I don't mind this, but at a fundamental low level, the things that
you want to do for code completion are a superset of the things
that you want to do for text hovering.  For example with code 
completion you would likely want to show all of the same information
in the additional "help" pane of a completion list that you would
show on a hover (namely, where it was defined and synoptic/comment 
type information about how to use the function/method/class/variable).

What I would suggest is that at the very least the TextHoverContribution
Manager goes back to the CCompletionContributionManager as one of its
lookup steps (which isn't to say it couldn't have more).

I'm also interested in your statement about "Red Hat's copy" of the 
code.  One of the benefits of a _common_ framework is that say someone
doing QNX development and Linux development would be able to co-exist
and use the QNX and/or RedHat specific tools in a single environment,
which might just be Rational's XDE =;-).  I'm just hoping to see some
of this work submitted as patches and/or come up for further discussion
so that it can be aligned in with the general development of the CDT.
 
> Next, my version of hover help relies on a collection of (at 
> least for 
> the moment) property files that, for example, describe glibc, 
> GTK+, X, 
> and whatever else, functions, and I'm planning to have the code use a 
> private URLClassLoader to locate the files on a customisable path. 
> (This allows the prop files to be replaced independant of Eclipse, as 
> well as allowing users to add their own prop files.)
> 
> So my question is: Is there a standard place in Eclipse to 
> put this kind 
> of data?  E.g., a lot of apps put stuff in /usr/share/whatever, and I 
> was thinking my "default" prop files could go there, or in some 
> Eclipse-standard equivalent.

The standard place is usually property files within your specific
plugin (I might be doing GTK/X/whatever development from Windows) so
that it is always self-contained to "eclise". In this case you 
likely want to follow something like the documentation plugin framework 
... but you can then extend it to _also_ include and search in a 
local environment if need be (this would by your external lookup
configureation).
 
> The follow-on question is: How should I my path customisation 
> be done? 
> Should it be done through the CDT configure stuff? Using an 
> environment 
> vbl?  Command-line opt?  All of the above?

I think that the path customization should be a specific property
which is a standard "Eclipse property" since it is more or less
specific per user.
 
> A third issue is that there appear to be a number (at least two that 
> I've seen) CDT hover mechanisms being pursued.  Is there a 
> mechanism/protocol for allowing run-time selection among multiple 
> extensions to the same extension point?  Or maybe some sort 
> of extension 
> chain?

Not mechanisms, but specific implementations.  If you go back to the
original post which was made about how to do this, one of the things
I noted was missing from the current framework was a way to select
which set you wanted to be able to use from a collection of plugins
(non-exlusive, more than one should be active at the same time, but
let the user decide which one's those are).  

To me this is a per project configuration with a global configuration
for seeding the initial project configuration when it gets created.
This would just be a list of extention point ids which are the ones
which should be active for a given project.

Thanks,
  Thomas