Re: [cdt-dev] Preferences

["Alain Magloire" <alain@xxxxxxx>]

> 
> This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
> --------------enig94155EA1DBF88E2F377D4CB9
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
> 
> Either (a) or (b) would work fine.  (b) seems a bit more flexible, but 
> since I can't imagine there'd be any need for that flexibility (how 
> often are you going to have to morph one project into another?) I'd vote 
> for (a).
> 

Note: those changes will break the API.  However, I think only QnX was taking
full advantage of this ... so I'll have a chat with the folks here.

It was on the todo list to add a filter(or enablement) attribute
part of the extension point.  This should limit the conflicts, for example
filter base on the nature of the project.  But still modules, like std make project
may need to provide a property page to let users choose the right contributors
.. 

PR created to get this in 2.1

https://bugs.eclipse.org/bugs/show_bug.cgi?id=71667

you may want to add yourself to the Cc:
 
> With respect to x86/MIPS/whatever, part of the plan is to have code in 
> the in the Preferences dialog that scans the libhover docs path looking 
> for XML files and presenting the user with a button list to pick from.  
> It takes noticeable time to parse the doc files so if a user is, e.g., 
> using only straight C (i.e., no GTK, etc.) or whatever he can just 
> deselect unnecessary stuff and save time.  Is the Target stuff going 
> into that level of detail?  If not, I expect a manual libdocs selection 
> mechanism will still be necessary, so it shouldn't add any complexity.

This may be all fine for GTK, but things can get naughty for other
platforms.  I'll mention this to the folks working on the Remote Target
proposal, but  they should provide a way to retrieve the current target
of the project ... whatever "target" means.