Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: Alpha on November 04, 2014, 12:58:28 am
-
I will be trying to draft up a settings page for CCManager as soon as I am able. Before then, I wanted to ask some opinions.
Settings belong in different categories; program interface choices should be in CCManager, language specific choices should be in the relevant plugin. My current thoughts (restricting to items that are not implemented) are:
CCManager/sdk side:
- enable code completion (global)
- enable tooltips (+display options)
- enable documentation popups (+display options)
- autolaunch CC after typing x characters
- timer delay for autolaunch after trigger character (generally scope/member type operators)
- case (in)sensitive CC
- autoselect on single match
- sort method... someday that YCM code path will be cleaned up and committed..
Plugin side:
- "fillup characters" - typing one will autocancel CC
- enable CC - (different than in sdk) this is if two CC plugins can provide for the same editor; CCManager will still only execute one of them, but this would allow a deterministic choice of which one
Is there anything I am missing? Items you think should be in a different category?
-
You've forgotten to mention the c++ parser settings and the settings for the symbol browser.
Do you plan to make a separate dialog or you'll keep the one in the Settings -> Editor?
-
You've forgotten to mention the c++ parser settings and the settings for the symbol browser.
These options are language specific, right?
So, they should be in plugin's configure panel.
-
These options are language specific, right?
So, they should be in plugin's configure panel.
Probably.
-
Yes, those were my thoughts as well. (I did not bother mentioning since those settings are already implemented.)
- timer delay for autolaunch after trigger character (generally scope/member type operators)
How many people would actually make use of such an option? I think the interface looks cleaner without this, and maybe a reasonable default is good enough for everyone?
Since there is extra room under general settings, I think we can fit the options there:
(http://www.pasteall.org/pic/show.php?id=79329)
(The combo box contains "disable", "enable", "force single page".)
-
How do you plan to handle the per-plugin panels?
Are they going to be a part of the CC settings or every plugin will register a separate item in the list in the dialog?
-
Plugin settings pages I plan to leave as is. They are still their own plugin, so I see no reason not to.
As for panels (such as scope and symbol tree), I hope to create a generic interface that plugins can share someday.. but that will have to wait.
-
Plugin settings pages I plan to leave as is. They are still their own plugin, so I see no reason not to.
This will be quite messy from the user friendliness point of view, but I guess it is OK as first step.
-
Has anyone timed how expensive (or cheap) ConfigManager::ReadXXX() calls are? Should I avoid using them during CC operations (caching settings instead)?
-
It depends how often they are called. If it is million times per second, I suppose it will make a difference, otherwise I doubt it.
-
Committed.
@ollydbg: Are you still working on remove unused variables in CC, they are mostly in CCManager(SDK) (http://forums.codeblocks.org/index.php/topic,19839.0.html)? The other part of these settings is to remove the redundancy from CC, but I do not want to duplicate your work.
-
Committed.
Good job.
@ollydbg: Are you still working on remove unused variables in CC, they are mostly in CCManager(SDK) (http://forums.codeblocks.org/index.php/topic,19839.0.html)? The other part of these settings is to remove the redundancy from CC, but I do not want to duplicate your work.
I will work on it. But there are some extra code changes. If you look at the option of "case sensitive", each parser instance has such option, and if we have many cbps opened by CC, we can set them differently for each parser instance. But now it becomes a global option. Maybe, there are other options we need to handle, so it will take some time to handle those issues.
I will post a patch when I finish the work in one or two days in that thread. :)
-
May I suggest a 4th option under 'settings -> editor -> general settings -> editor settings -> code completion -> tooltips' called 'enable on keypress only'? The reason being is my autohotkey shortcuts for navigation doesn't play nice when the mouse pointer unintentionally comes over a piece of code when scrolling by keyboard and shows a tooltip automatically which screws up the navigation completely. It would be nice to have an option to activate both tooltips and calltips (I think they are different as calltips can only be activated on function names) only by shortcuts.
Btw if someone can point me to the piece of code where popup window colours are handled, I'd like to submit a patch to register them in 'settings -> environment -> colours'. Thanks.
-
May I suggest a 4th option under 'settings -> editor -> general settings -> editor settings -> code completion -> tooltips' called 'enable on keypress only'? The reason being is my autohotkey shortcuts for navigation doesn't play nice when the mouse pointer unintentionally comes over a piece of code when scrolling by keyboard and shows a tooltip automatically which screws up the navigation completely. It would be nice to have an option to activate both tooltips and calltips (I think they are different as calltips can only be activated on function names) only by shortcuts.
I hereby support the above motion!
The option to activate both tooltips and calltips must be included, this truly is a regression!
-
Apologies for not being able to respond earlier. I will look into this over the weekend, and see what is possible.
-
Tooltip and calltip are different. The former is generated when mouse dwells. The later is shown when you are entering functions. So, do we need two options?
-
I don't think 2 separate options are needed. Only one 'enable on keypress only' for both of them would be enough imo. But I think it would be better if tooltips had a shortcut to launch them like debugger's 'Evaluate expression' tooltips.
Btw tooltips and calltips are displayed with a color (black on white background) which is not compatible with my theme colors (white on black background). But debugger's tooltips are displayed in compatible colors with my theme. Can this be applied to cc's tooltips and calltips too?
-
Btw tooltips and calltips are displayed with a color (black on white background) which is not compatible with my theme colors (white on black background). But debugger's tooltips are displayed in compatible colors with my theme. Can this be applied to cc's tooltips and calltips too?
I believe the relevant API is wxScintilla::CallTipSetBackground(), CallTipSetForeground(), and CallTipSetForegroundHighlight(). If you want to write up a quick, that would be nice. Otherwise I should hopefully get to it soon.
-
Committed initial option. Please report if it functions as expected.
-
I thought the tooltip shortcut would activate the tooltip for the expression under the mouse not the cursor but it will do, one extra click won't do much harm imo. ;) Thanks.
However there is an issue. When a function with arguments is completed, calltip kicks in automatically. Can this also be tied to the 'keybound only' setting like not launching automatically?
And for the color preferences will it be okay if I manage to submit a patch to tie the back, fore and highlight color settings to the color manager as the documentation popup settings are already there?
-
My thoughts had been that the logical expectation of a keyboard shortcut would be to activate on the keyboard's focus point (the caret/cursor), similar to how show calltips shortcut works.
When a function with arguments is completed, calltip kicks in automatically. Can this also be tied to the 'keybound only' setting like not launching automatically?
Yes, will do.
Tying to those settings sounds fine, in my opinion.
-
Attached a patch for the color configuration of tooltips. I'm not sure where to load the colors for tooltips though. I opted to load them in 'OnEditorOpen' but would it be better to load them in 'DoUpdateCallTips'?
-
When a function with arguments is completed, calltip kicks in automatically. Can this also be tied to the 'keybound only' setting like not launching automatically?
Yes, will do.
Committed.
-
Works fine thanks. However I never could and still don't understand the purpose of the red closing parenthesis.
-
Attached a patch for the color configuration of tooltips. I'm not sure where to load the colors for tooltips though. I opted to load them in 'OnEditorOpen' but would it be better to load them in 'DoUpdateCallTips'?
Committed, thanks (I did swap your values with default colours that better match previous settings). I think that loading them once per editor should be fine. No need for extra overhead.
However I never could and still don't understand the purpose of the red closing parenthesis.
Assuming we are talking about the same thing, that is "smart tab jump". Press tab to jump the caret past closing parenthesis and quotes (one step at a time) for the remainder of the line. Can be useful when inserting more code at the beginning of a pre-existing line.
-
Assuming we are talking about the same thing, that is "smart tab jump". Press tab to jump the caret past closing parenthesis and quotes (one step at a time) for the remainder of the line. Can be useful when inserting more code at the beginning of a pre-existing line.
I now know what it is, thanks. I guess it's an editor feature that I can't disable?
-
Smart tab jump is a feature added by Loaden in our editor control several years ago. But he is inactive now. Not sure there is an option to disable it.
-
Smart tab jump is a feature added by Loaden in our editor control several years ago. But he is inactive now. Not sure there is an option to disable it.
@scarphin, the related code is in sdk\cbstyledtextctrl.cpp, and you can search the keyword by "m_tabSmartJump".
-
Think you should seriously consider splitting the CodeCompletion settings out into their own dialog(ue). The way the debugger manager handles this is a good model IMHO.
-
Think you should seriously consider splitting the CodeCompletion settings out into their own dialog(ue).
I put the global ones where they are now since that rectangle was just awkward empty space before. I agree that a dedicated dialogue (dialog? ... I never figured this one out either) would make it more clear, but I myself do not have time to build one anytime soon.
(Sorry for the delay.)
-
So, to clarify where are the global settings at the current moment? I'm not sure I can find them.
-
First page of general editor settings. See screenshot near the beginning of this thread.