Alain Magloire wrote:
- Licensing issues (?) for the templates.
I never have a clue what to do with these licensing/copyright/copyleft
things. Suggestions are welcome.
8)
Can you provide the file under CPL ?
I'll check with the Red Hat legal troops, but I don't see why not.
- 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?
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
|
