Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign

CC plugin interface redesign

<< < (16/28) > >>

Alpha:
I misspoke; the documentation popup is the only remaining feature that my refactoring has broken, and not yet fixed.  That will be the last (major) piece (I believe) of the autocompletion subset of functions.  The symbol browser is the next section I will deal with, but I currently do not have a clear plan in mind for it.  How much of the symbol browser should belong to CCManager?  Just the tab, and then various plugins supply content panels within it?  Or the entire interface, and then plugins supply the tokens for CCManager to populate it with?  Something else?

oBFusCATed:
If I were you I'd try to have a single tree that CC plugins has to fill when CCManager tells them to do.

Alpha:
For a single cbEditor instance, do we want multiple CC plugins to be able to provide content simultaneously (for tooltips, autocompletion, etc.)?

oBFusCATed:
Hm, tough question.
Probably the answer is mostly no, but it would be good if the auto completion list could have a list of matching abbreviations in it (this is a user request).
So, we'll need a way for all kind of plugins to be able to fill the list, not only plugins of CC-type.

Alpha:
Two different ways I can think of implementing that are: create a CCAutocompHook in the style of EditorHook,
or define a new CodeBlocksEvent, and have a CCManager::AddAutocompTokens() function that plugins subscribing to this event can call.

I think I prefer the second, because it reuses existing architecture.  However, it might end up looking uglier in the long term...

Navigation

[0] Message Index

[#] Next page

[*] Previous page