Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Feedback

Hi Sascha.

>>Hi Sasha. 
>[Sascha] Why does everyone forget the "c" here ;-)

Sorry. I'll remember. 
As workaround, you can use c++ instead... :-))))

> See comments below.

>>But any tool integrator can add any types hierarchy he/she wants. 
>>That's
why we pass "tree" to wizard: wizard is really able to create any
structure of handlers. Do you mean is it really bad ?

>[Sascha] I see now. I was just confused that the tree gets exposed on
the interface even though it was not required (because the handlers do
provide name >and icon and so the wizard could setup the tree elements
rather than having the implementors of the interface do this). I
understand the hierachical 
>possibilities now. I'm still not sure that exposing the tree is the
best solution - maybe ICWizardHandlers could provide children rather
than giving them the 
>chance to mess up the tree. But I haven't had an in depth look, it was
just something that came to my eyes when checking out the new features.
It's not a >big issue, I just thought I'd mention this before api freeze
:).

Anyway, tool integrator have several ways to make CDT not working. :-).
Possibility to corrupt this tree is only one of them. On the other hand,
we can to allow, for example, remove old compilers from tree by means
of the latest compiler's version installed in another plugin. 

Request for children may be a good alternative, but it still shortens
the
freedom for integrator, anyway. May be we can implement it, but now
API is frozen.

Anyway, I hope that most CDT developers are not CDT enemies, and 
they would not mess data specially. Accidental errors seem to be 
not very probable in this case.
----
Oleg.

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


Back to the top