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


Alain Magloire wrote: 
redirected to cdt-dev-ui list, i.e. please reply to this list instead of cdt-patch.

  
A patch to provide TextHover capability to CDT is available at

http://people.redhat.com/cmoller/TextHoverPatch/

    
Some issues:
                                                                                                                             
- Licensing issues (?) for the templates.
I never have a clue what to do with these licensing/copyright/copyleft things.  Suggestions are welcome.
- 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.
                                                                                                                             
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.
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.
It would allow contributions from third parties and better integration, i.e.
working with qt/motif or other libraries.

Let see if we can work this out.

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

Back to the top