Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] CDT textHover 

Thomas Fletcher wrote:

-----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:
Since at present CDT hover and completion stuff is being done by different organisations,
What do you mean by different organizations?
At the very least, here at Red Hat I'm working on hover stuff and there's an IBM group working on completion. In addition, there was a post to this list a bit ago from someone else who has done, or is doing, hover stuff. It looks like we might wind up with a number of different hover/completion efforts and then either find a way for them to co-exist or let them darwin down to just one. 



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).


OK, will do.
I'm also interested in your statement about "Red Hat's copy" of the code. ... 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.
Sure, at some point I expect RH will fold our stuff back into the real CDT, but for right now I'm in sandbox mode with broken code all over the floor. When it gets past its current pre-alpha state we'll probably send it out into the World.
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).
Hmm, I was kinda looking for a standard "external" place. If, e.g., a new release of GTK+ comes out it would be nice to be able to distribute a new prop file to some location external to eclipse -- so you don't muck up the eclipse installation -- but standard so we know where to put it.
This kind of doc data is different from the eclipse docs. Eclipse docs are specific to the eclipse release they're in. The hover docs are specific to the release of other packages.
Right now, eclipse seems to have a pair of high-level directories .../features and .../plugins -- would a .../etc dir be possible? Then, under that, a .../etc/hoverdata dir to hold the (updated) prop files, and maybe .../etc/whatever dirs in case this kind of problem comes up again.
Inside RH, we've talked about asking the package maintainers for GTK, glibc, etc., if they'll let us include our prop file extractors in their distros and then install the prop file in the same place they install their docs. I think that's an even better solution than a eclipse-external standard location, but it's kinda long-term at best. 

Thanks,
Chris

Back to the top