Developer forums (C::B DEVELOPMENT STRICTLY!) > CodeCompletion redesign
CC plugin interface redesign
oBFusCATed:
--- Quote from: Alpha on July 07, 2013, 08:10:58 pm ---Thoughts?
--- End quote ---
Hm, why don't you do a live refactoring, one step at a time?
I doubt you'll be able to predict what we'll be needed from the start.
Just move some code around and see how the interface is coming along.
For example - extract the autocompletion list to be in cbplugin.cpp and to be common for all cc plugins.
Then continue with the rest of it - toolbar, symbol browser, tooltips, etc.
For the autocompletion list you can take two approaches:
1. define an autocompletion list item structure
--- Code: ---struct Item{
wxstring text, type;
cbAutocompletionTokenType tokenType;
cbAutocompletionScope scope;
};
--- End code ---
2. allow the CC plugin to tell the core, what kind of tokens can it produce and then make a struct with ints
--- Code: ---struct Item{
wxstring text; // contains the full text visible in the list
int iconIndex; // used for the icon
}
Also you'll define a function which returns the icons:
CC::GetTokenIcons() or CC::GetTokenIcon(int index)
--- End code ---
If you'd ask me I'd use the second approach, because it is more flexible and it will work for dynamic languages, where the type is not always available.
Alpha:
My reason behind using simply a wxArrayString (and, now that I think about it, it could just be a wxString, because the next step would be to concatenate it anyway) is that a CC plugin would register the icons it wants, and just embed those values in the returned string(s).
Alternatively, should the main app be responsible for registration?
--- Quote from: golgepapaz on July 07, 2013, 09:24:54 pm ---Since no filename is mentioned I am thinking one supposed to use
active editor right? This should be more generic and pass the filename
or better yet buffer as well
--- End quote ---
Active editor, because I can think of no circumstance in which one would want autocompletion on a non-active editor. Passing a filename or cbEditor* would, in my opinion, be an unnecessary level of indirection.
oBFusCATed:
What about scripts or the watch window when typing an expression?
p.s. Please don't use wxArrayXXXX they are bloody dangerous to use, because the operator[] is defined in the maddest possible way! Use std::vector or std::deque instead!
golgepapaz:
--- Quote from: Alpha on July 07, 2013, 11:49:10 pm ---My reason behind using simply a wxArrayString (and, now that I think about it, it could just be a wxString, because the next step would be to concatenate it anyway) is that a CC plugin would register the icons it wants, and just embed those values in the returned string(s).
Alternatively, should the main app be responsible for registration?
--- End quote ---
IMHO, that's a bad idea because using strings as a container object and marshalling, demarshalling necessary information is absurd.
I am sure there will be more information that needs to be conveyed than a simple string. First thing that comes to mind is
displayed vs inserted text. For example the code completion result for function int foo (int param) you can display it in the
completion list as foo(int):int or any variation thereof but you only need to insert the foo (maybe with parentheses)
also there is other information that I've mentioned before. I am sure you are not proposing to embed all this information in one string
which is very hard to use. Some data structures like the ones obfuscated gave examples of and I've mentioned are absolutely necessary.
--- Quote from: Alpha on July 07, 2013, 11:49:10 pm ---Active editor, because I can think of no circumstance in which one would want autocompletion on a non-active editor. Passing a filename or cbEditor* would, in my opinion, be an unnecessary level of indirection.
--- End quote ---
Yeah, probably but, IsProviderFor() needs it anyway so there is no need to be stingy. Thing is it can help decouple the CC plugin from the Manager to some extent and
because singletons are evil :D and there is an attempt in this direction(discussed http://forums.codeblocks.org/index.php/topic,17750.0.html). Also every method that is using active editor need boilerplate code something like this;
--- Code: --- cbEditor* editor = Manager::Get()->GetEditorManager()->GetBuiltinActiveEditor();
if (!editor)
return;
if (IsProviderFor(editor))
{
//Do stuff probably involving further indirection to cbStyledTextCtrl.
}
--- End code ---
Pass a viable and healthy editor and save the plugin developer from some suffering. :)
Alpha:
(This forum begins to annoy me: I spent a little over an hour yesterday, trying to submit this post, but gave up and am trying again now.)
It has occurred to me (and I am very surprised it did not occur earlier) that the modifications I plan for the sdk are larger, and should receive their own class; however, I am unsure where to hook it into the main application (as I have never changed something like this before in Code::Blocks). @devs: Suggestions?
The creation of, for example, a CCManager would fit... but I would prefer an option other than a new manager.
--- Quote from: golgepapaz on July 08, 2013, 03:55:47 am ---IMHO, that's a bad idea because using strings as a container object and marshalling, demarshalling necessary information is absurd.
I am sure there will be more information that needs to be conveyed than a simple string.
--- End quote ---
Actually, not exactly; for the specific purpose I had in mind, communicating with Scintilla, no other information is required.
From (wx)Scintilla api:
--- Code: --- // Display a auto-completion list.
// The lenEntered parameter indicates how many characters before
// the caret should be used to provide context.
void AutoCompShow(int lenEntered, const wxString& itemList);
--- End code ---
However, you have made me think ;). Having the additional information available will be useful in the future if, ex., we someday hook CC plugins into dialogue boxes, entry forms, etc.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version