Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-ui-dev] Re: [cdt-patch] TextHover patch 

Chris Moller wrote:




- specific platform gtk.  Once the gnu.ui plugin
is created, we could move those things in.
It's not really gtk-specific -- help property files for any library can be added, and existing ones omitted. I just happen to use gtk a lot, so I built gtk prop files. Other groups/companies/platforms can tailor the included help files as necessary. One of my TODOs is to add a Preferences thing to make this easy.
Understood, what I mean is; the files(the gtk properties) do not belong in the cdt.ui plugin. This plugin(cdt.ui), is trying very hard to be platform/library/os/... agnostic. A better place could be the gnu.{core,ui} plugins or maybe a contribution 
of a gtk plugin.
One of the problems I've had all along is where to put the properties files. The notion I originally had was to use something similar to the *ix /usr/share directory. Right now eclipse has the two principal dirs "plugins" and "features" and I was thinking that adding one called "share" or "etc" might be a handy place to put whatever reference data might be useful: share/TextHover to hold the properties files, for example. I don't know if there's any other "common" data used anywhere else in Eclipse, but maybe it could be moved to "share" as well.
I'm not sure it's a good idea to scatter the text hover help files all over the place based on potential environment, but extending the "share" directory notion, the files could go into share/TextHover/linux, share/TextHover/windows, etc. Would that work?
The Eclipse way of handling this would be to have a plugin contribute the location of these files. (like the org.eclipse.cdt.gnu.ui plugin which hopefully will be created...) And in most cases the file would exist within the plugins root directory (similar to eclipse help documentation). 


1) Once contributor to rule them all !!!
It's probably not necessary to have two contributors
(CCompletionContributorManager __and__ CTextHoverContributor),
having one should be enough has it is the same information.
CCompletion, for example, could provide help, (see how the JDT
ties the javadocs to the completion)
I would say to provide more methods to IFunctionSummary.
Also note the CCompletionContributor is also use for the add_include_action:
Since I started writing the code for this, the completion stuff has changed a lot and trying to integrate into a moving target is difficult. When completion stabilises, maybe the text hover stuff could be integrated into it. 


The completion contribution did not move that much,
are you referring to code completion(content assist) ?
It would be nice to consolidate this for CDT-2.x: add include action contribution, 
and completion contribution(including hovering)
If you want to drive this, that would be great, let me know. We have some initial 
work that could be push down to the CDT.

Sure, I'll take it if no one else has signed up for it.


Did you something else in mind ?


2) Filter base on projects
If you are working on a Windows application, or QNX project you
probably do not want gtk completion or hovering.
I do like the idea of having one format, in your case the java properties, 
or XML format, whatever is easy to parse.




XML files would be more elegant, but property files were easier.




Java comes with XML parsers 8).
Yeah, but considering this was my absolute, very, first, Java project, the learning curve on prop files was a lot smaller than the one for XML parsers. Maybe for Version 2 I'll go read the right manual and switch over. One of the big behind-the-scenes parts of the texthover stuff was writing the parsers to extract info from primary sources to create the prop files. They'd have to be modified to produce XML. 



_______________________________________________
cdt-ui-dev mailing list
cdt-ui-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-ui-dev

Back to the top