Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
CC plugin interface redesign
Alpha:
One of the main blockers against having multiple CC plugins (for example, integrating Clang) is the current state of the sdk. I would like to (at least begin) work on improving the interface, but first we should brainstorm what changes belong in the sdk, and what belongs in individual CC plugins.
My thoughts so far:
The sdk should:
* query plugins if they are active on a file
* ask the active plugin for updates to a shared CC scope toolbar
* have a unified keyboard shortcut/autolaunch, from which it asks the active plugin for the text to fill the autocomp box
* ask, at the correct time, the plugin for the html content of a documentation popup (if the plugin returns nothing, the popup stays hidden)
* keep track of dwell events, and ask the active plugin for tooltip contentsA CC plugin should:
* manage all parsing
* provide its own specialized refactoring/searching tools
* provide its own symbol explorer
What ideas do others have?
Also, there was some recent effort to remove GUI code from the sdk, however this CC redesign would do the opposite. Solutions?
oBFusCATed:
--- Quote from: Alpha on July 03, 2013, 03:23:16 pm ---My thoughts so far:
The sdk should:
* query plugins if they are active on a file
* ask the active plugin for updates to a shared CC scope toolbar
* have a unified keyboard shortcut/autolaunch, from which it asks the active plugin for the text to fill the autocomp box
* ask, at the correct time, the plugin for the html content of a documentation popup (if the plugin returns nothing, the popup stays hidden)
* keep track of dwell events, and ask the active plugin for tooltip contents
--- End quote ---
All these are spot on.
--- Quote from: Alpha on July 03, 2013, 03:23:16 pm ---A CC plugin should:
* manage all parsing
* provide its own specialized refactoring/searching tools
* provide its own symbol explorer
--- End quote ---
1. 100% done in the CC plugin.
2. Some parts might be extracted in the sdk, but this is a future task. First we need to have them :)
3. The UI should be unified, but it should be filled by the CC plugin. Because if you leave it to plugins
then will have clang symbol browser, symbol browser, fortran symbol browser, python symbol browser, etc, etc.
One thing you've missed is an API for getting the full symbol at one position in a file.
For example if you select a struct member and want to see it in the debugger tooltip, the debugger plugin needs to
expand the string to instance of the object, so the variable could be evaluated correctly by the debugger.
--- Quote from: Alpha on July 03, 2013, 03:23:16 pm ---What ideas do others have?
Also, there was some recent effort to remove GUI code from the sdk, however this CC redesign would do the opposite. Solutions?
--- End quote ---
No, they won't. See the cbdebugger_interface.h file. The SDK could be used just as a bridge, between plugins and the main app.
ollydbg:
--- Quote from: oBFusCATed on July 03, 2013, 04:06:14 pm ---...
3. The UI should be unified, but it should be filled by the CC plugin. Because if you leave it to plugins
then will have clang symbol browser, symbol browser, fortran symbol browser, python symbol browser, etc, etc.
...
--- End quote ---
Agree.
But if we have only one shared symbol browser tree, it may take times to switch from one tree to another. (building current CC's symbol tree takes several minutes).
--- Quote ---One thing you've missed is an API for getting the full symbol at one position in a file.
For example if you select a struct member and want to see it in the debugger tooltip, the debugger plugin needs to
expand the string to instance of the object, so the variable could be evaluated correctly by the debugger.
--- End quote ---
GDB has the ability to solve/parse the complex statement. Here is the example:
--- Code: ---instantA.memberB.memberC();
--- End code ---
If you hover on memberB, you can directly pass string "instantA.memberB" to GDB.
If you hover on memberC, you can pass string "instantA.memberB.memberC" to GDB.
I'm OK with all the changes.
oBFusCATed:
--- Quote from: ollydbg on July 04, 2013, 03:38:38 am ---Agree.
But if we have only one shared symbol browser tree, it may take times to switch from one tree to another. (building current CC's symbol tree takes several minutes).
--- End quote ---
Have I said something about rebuilding? :)
--- Quote from: ollydbg on July 04, 2013, 03:38:38 am ---
--- Code: ---instantA.memberB.memberC();
--- End code ---
If you hover on memberB, you can directly pass string "instantA.memberB" to GDB.
If you hover on memberC, you can pass string "instantA.memberB.memberC" to GDB.
--- End quote ---
I know gdb can do it, but currently there is no method in SDK to ask CC for the full token.
p.s. Alpha if you're not afraid of using git, we can work on this using my git-svn clone on github
Alpha:
--- Quote from: oBFusCATed on July 03, 2013, 04:06:14 pm ---The SDK could be used just as a bridge, between plugins and the main app.
--- End quote ---
Okay, I see.
--- Quote from: oBFusCATed on July 04, 2013, 01:11:59 pm ---
--- Quote from: ollydbg on July 04, 2013, 03:38:38 am ---Agree.
But if we have only one shared symbol browser tree, it may take times to switch from one tree to another. (building current CC's symbol tree takes several minutes).
--- End quote ---
Have I said something about rebuilding? :)
--- End quote ---
Having a single tab that various plugins can swap the contents with makes sense. The question is, when to swap? Each time the active editor changes? If there are split editors? No editor open? Swap on demand (with a combo box)?
--- Quote from: oBFusCATed on July 04, 2013, 01:11:59 pm ---p.s. Alpha if you're not afraid of using git, we can work on this using my git-svn clone on github
--- End quote ---
I have not used git before, but I am willing to try. Do you have a quick overview of normal git workflow?
What I want to do is first delete most of the CC plugin, except for the parser. Then add on/rewrite each feature as the changes to the SDK are finished.
Navigation
[0] Message Index
[#] Next page
Go to full version