Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

Semantic highlight

<< < (11/16) > >>

MortenMacFly:

--- Quote from: mistar on June 15, 2012, 11:57:49 pm ---Sources of the very-very-very preliminary version of SemanticHighlight plugin are attached.

--- End quote ---
To reach more tester, you should probably explain what dependencies you have, where they are available and how you "install" them.

MortenMacFly:

--- Quote from: mistar on June 15, 2012, 11:57:49 pm ---2. If you change compile options of some target and/or project, SH doesn't notice those changes. It will when we add an event posted on such changes (EVT_PROJECT_TARGETS_MODIFIED is NOT posted on such changes though, in fact there is currently no event posted!).

--- End quote ---
I could think of a project options changed and compiler settings changed events, in case the project/compiler options are changed in the UI dialogs and the user hit "OK". For the compiler options this is, however, tricky. For example: You can attach build scripts to projects or even single files that evaluate at run-time. They may even using system calls to obtain specific settings. So you don't know the full compiler option for a single file until you build the file. Here, you should try to obtain these from the editor -> project file -> active target -> compiler options. You would, however, receive the current compiler options in the mentioned events which should work in 95 percent of the cases.
However, in the end that should be the same as you would obtain in editor activated event when the settings dialog was shown (same chain: editor -> project file -> active target -> compiler options).

mistar:

--- Quote from: MortenMacFly on June 16, 2012, 05:33:43 am ---
--- Quote from: mistar on June 15, 2012, 11:57:49 pm ---Sources of the very-very-very preliminary version of SemanticHighlight plugin are attached.

--- End quote ---
To reach more tester, you should probably explain what dependencies you have, where they are available and how you "install" them.

--- End quote ---

To compile the plugin you need clang and llvm (see llvm.org) dynamic libraries installed.
The installation process should be quite easy, just install clang compiler and everything else should be installed as well ;)
Then, adjust SH project's paths and libraries to match those just installed and everything should work.


--- Quote from: MortenMacFly on June 16, 2012, 06:42:44 am ---
--- Quote from: mistar on June 15, 2012, 11:57:49 pm ---2. If you change compile options of some target and/or project, SH doesn't notice those changes. It will when we add an event posted on such changes (EVT_PROJECT_TARGETS_MODIFIED is NOT posted on such changes though, in fact there is currently no event posted!).

--- End quote ---
I could think of a project options changed and compiler settings changed events, in case the project/compiler options are changed in the UI dialogs and the user hit "OK". For the compiler options this is, however, tricky. For example: You can attach build scripts to projects or even single files that evaluate at run-time. They may even using system calls to obtain specific settings. So you don't know the full compiler option for a single file until you build the file. Here, you should try to obtain these from the editor -> project file -> active target -> compiler options. You would, however, receive the current compiler options in the mentioned events which should work in 95 percent of the cases.

--- End quote ---
I know there can be very tricky ways for specifying compiler options. I use for example `wx-config --cflags` to obtain the compiler/linker options for wxWidgets and such tricky ways are supported in SH already.


--- Quote from: MortenMacFly on June 16, 2012, 06:42:44 am ---However, in the end that should be the same as you would obtain in editor activated event when the settings dialog was shown (same chain: editor -> project file -> active target -> compiler options).

--- End quote ---
Calling my GetCompileOptions each time editor is activated is highly inefficient (several wxExecute calls to get options from commands like `wx-config --cflags`). Moreover, I avoid to process EVT_EDITOR_ACTIVATED each time the last active editor equals the current (windows switching for example), and there is (at present) no way for checking whether the options change at all, so I don't know whether to reparse sources or not ;) I can, of course, reparse them each time EVT_EDITOR_ACTIVATED occurs but nevertheless it is worse solution IMHO.

I also debate whether to lock editor during first (several seconds long) reparsing, but there are some difficulties, for example I have no access to the percentage of the elapsed process, so I could only display some information box.
Please, share your opinions on that and similar things.

MortenMacFly:

--- Quote from: mistar on June 16, 2012, 11:05:59 am ---Moreover, I avoid to process EVT_EDITOR_ACTIVATED each time the last active editor equals the current (windows switching for example), and there is (at present) no way for checking whether the options change at all, so I don't know whether to reparse sources or not ;) I can, of course, reparse them each time EVT_EDITOR_ACTIVATED occurs but nevertheless it is worse solution IMHO.

--- End quote ---
Yes, I think this is not really good. However, what about the other option(s) I suggested?

mistar:

--- Quote from: MortenMacFly on June 16, 2012, 05:15:45 pm ---
--- Quote from: mistar on June 16, 2012, 11:05:59 am ---Moreover, I avoid to process EVT_EDITOR_ACTIVATED each time the last active editor equals the current (windows switching for example), and there is (at present) no way for checking whether the options change at all, so I don't know whether to reparse sources or not ;) I can, of course, reparse them each time EVT_EDITOR_ACTIVATED occurs but nevertheless it is worse solution IMHO.

--- End quote ---
Yes, I think this is not really good. However, what about the other option(s) I suggested?

--- End quote ---
The events for project/target options changed and compiler options changed are IMHO the best solution here.
Since projects and targets are treated identically here (they are derived from CompileOptionsBase class) there might be one event kind.

And how about function returning true when C::B is starting and false otherwise? You have Manager::IsAppShuttingDown but no counterpart on startup.
If such a counterpart, say IsAppStartingUp, existed I could do all initializations in an event handler for EVT_APP_STARTUP when C::B is starting, in OnAttach when the plugin is loaded and in OnEditorActivated otherwise (I could then check in OnEditorActivated if IsAppStartingUp and do no initializations if so, as then all initializations would be done in OnAppStartup). This would solve, hopefully, the problem of messing up the GUI at C::B startup.

Also, did you consider adding a mutex for each wxScintilla control that would be publicly available? When I do highlighting I could aquire the mutex and then release it, and the same (internally in the control) when user types into the control. Now I have no tools to synchronize user input (which changes the layout of the control) and highlighting...

Navigation

[0] Message Index

[#] Next page

[*] Previous page