void SemanticHighlight::OnEditorOpen(CodeBlocksEvent & evt)
{
cbEditor * ed = static_cast<cbEditor *>(evt.GetEditor());
ProjectFile * pf = ed->GetProjectFile();
wxString projTitle = pf ? pf->GetParentProject()->GetTitle() : wxT("[None]");
Manager::Get()->GetLogManager()->Log(wxT("\tSH: processing cbEVT_EDITOR_OPEN: ")+evt.GetEditor()->GetTitle()+wxT("@")+projTitle);
}
Sorry to disappoint you but currently you won't be able to implement such plugin.
And the reason is that the editor control we are using doesn't support it.
We are using Scintilla (wxScintilla to be exact).
If you look at their mailing list you'll find info of other people trying to do it and you'll be able to read about their failures.
Here is the link to the discussion: http://groups.google.com/group/scintilla-interest/browse_thread/thread/35a1ba3c99488d8f/b7365d210b6aca39?hl=en&lnk=gst&q=semantic+highlight#
For the cast, you can test the EditorBase if it is a built in editor, then the cast is safe.
CodeBlocksEvent evt(cbEVT_EDITOR_OPEN, -1, 0, ed);
Manager::Get()->GetPluginManager()->NotifyPlugins(evt);
if (!eb) // was not open
{
CodeBlocksEvent evt(cbEVT_EDITOR_OPEN, -1, 0, ed);
Manager::Get()->GetPluginManager()->NotifyPlugins(evt);
}
Why is cbEVT_EDITOR_OPEN event posted in EditorManager::New instead of EditorManager::Open (after cbEditor::SetProjectFile is called)?Because it is defined as "about to be opened" if you like and plugins can intercept and interrupt this event in case they handle the file itself. So this won't change.
if (!eb) // was not open
{
CodeBlocksEvent evt(cbEVT_EDITOR_OPENED, -1, 0, ed);
Manager::Get()->GetPluginManager()->NotifyPlugins(evt);
}
s_CanShutdown = true;
extern EVTIMPORT const wxEventType cbEVT_EDITOR_OPENED;
#define EVT_EDITOR_OPENED(fn) DECLARE_EVENT_TABLE_ENTRY( cbEVT_EDITOR_OPENED, -1, -1, (wxObjectEventFunction)(wxEventFunction)(CodeBlocksEventFunction)&fn, (wxObject *) NULL ),
const wxEventType cbEVT_EDITOR_OPENED = wxNewEventType();
NotifyPlugins(cbEVT_EDITOR_OPENED);Since I've never participate in a big project like C::B, please guide me what to do to post a patch (I've searched the forum but dodn't find anything),Creating a patch to submit to BerliOS (Patch Tracker) (http://wiki.codeblocks.org/index.php?title=Creating_a_patch_to_submit_to_BerliOS_%28Patch_Tracker%29)
or point to some description.
Since I've never participate in a big project like C::B, please guide me what to do to post a patch (I've searched the forum but dodn't find anything),Creating a patch to submit to BerliOS (Patch Tracker) (http://wiki.codeblocks.org/index.php?title=Creating_a_patch_to_submit_to_BerliOS_%28Patch_Tracker%29)
or point to some description.
Patch submitted. How long does it take on average to incorporate the changes?Well, I had a look at this.
if (can_updateui)
{
if (ed)
{
SetActiveEditor(ed);
ed->GetControl()->SetFocus();
}
}
// check for ProjectFile
if (ed && !ed->GetProjectFile())
{
// First checks if we're already being passed a ProjectFile as a parameter
if (data)
Manager::Get()->GetLogManager()->DebugLog(_T("Project data set for ") + data->file.GetFullPath());
else
Manager::Get()->GetProjectManager()->FindProjectForFile(ed->GetFilename(), &data, false, false);
if (data)
ed->SetProjectFile(data,true);
}
BTW: This was wrong. This event fires when a file has either been created (so it is new from scratch) or newly opened, like File -> Open -> "...". The latter is the reason why it is called OPEN. Internally it means C::B creates a new editor and also loads the file into memory (as needed).Why is cbEVT_EDITOR_OPEN event posted in EditorManager::New instead of EditorManager::Open (after cbEditor::SetProjectFile is called)?Because it is defined as "about to be opened" if you like and plugins can intercept and interrupt this event in case they handle the file itself. So this won't change.
Hello mistar, may i ask what functions the plugin will be offered?
(it seems that wxAuiManager and wxExecute interfere in some way)...They have nothing to do with each other.
any ideas how to do this in another way?Have a look at other plugins that run external tools (e.g. CppCheck, CScope or alike), you can see how its done there.
(The output of C::B on stdout contains "caching results from `wx-config --cxxflags`", so maybe I can use this cache?)This information is not available via a public interface.
I've tried also to do this in a separate thread but the thread freezes (perhaps wxExecute in not thread-safe).We use threads a lot in C::B if yours freezes then you did something wrong. You can even use the thread abstractions available via the SDK for such purposes. Again: Have a look how other plugins do it (i.e. ThreadSearch).
Also note that parsing a file from scratch takes some time (when editing a file there are some optimizationsA second for every key press? :)
so in the final version it should take no more than a second).
A second for every key press? :)A second after last key press.
Hi guys!Hi, nice work.
Before my work on SemanticHighlight plugin goes on, let me introduce simple SHTool plugin I've just written
to demonstrate what can be achieved. The sources are attached.
This is a very simple tool plugin that colorize the syntax in a semantic way using hardcoded styles that I like
(see the sources).
To revert the styles to original ones just reopen the file.
I've tested it with C::B 10.05 and with latest svn version (with change of sdk version in manifest.xml to 1.13.2).
The plugin works best with project files (with all compiler options and search directories set up correctly).
The plugin links against libclang.so so you have to install clang first.
Also note that parsing a file from scratch takes some time (when editing a file there are some optimizations
so in the final version it should take no more than a second).
Have fun!
E:\code\cb\cb_trunk\src\plugins\contrib\SHToolhttps://codelite.svn.sourceforge.net/svnroot/codelite/trunk/sdk/clangThe problem is: I can't see this plugin works when I open a new project, I can see the SHTool plugin is loaded. :(Ok, it works now, I need to click the Menu->Plugins->SHTool, it works really NICE.
The editor is not highlighted by SHTool.
Yes, now this is only a simple tool (when you want to highlight sources just Menu->Plugins->SHTool; I forgot to write it explicitly), not real-time highlighter.The problem is: I can't see this plugin works when I open a new project, I can see the SHTool plugin is loaded. :(Ok, it works now, I need to click the Menu->Plugins->SHTool, it works really NICE.
The editor is not highlighted by SHTool.
mistar:AFAIK, clang_codeCompleteAt calls clang_reparseTranslationUnit, see the description of clang_defaultEditingTranslationUnitOptions here: http://clang.llvm.org/doxygen/group__CINDEX__TRANSLATION__UNIT.html (http://clang.llvm.org/doxygen/group__CINDEX__TRANSLATION__UNIT.html)
Is it possible to make the required changes in the SDK, so multiple plugins can be semantic highlight providers?
I guess if we make a CC plugin based on clang we have to implement the semantic highlight in it in order to prevent calling clang to parse the code twice.
Is the parsing required for CC and semantic parsing the same?
I think there is a better way: Instead of introducing another event, you could move the portion:Code...to after:if (can_updateui)
{
if (ed)
{
SetActiveEditor(ed);
ed->GetControl()->SetFocus();
}
}CodeThis way, you can use the already existing cbEVT_EDITOR_ACTIVATED event and don't screw anything.// check for ProjectFile
if (ed && !ed->GetProjectFile())
{
// First checks if we're already being passed a ProjectFile as a parameter
if (data)
Manager::Get()->GetLogManager()->DebugLog(_T("Project data set for ") + data->file.GetFullPath());
else
Manager::Get()->GetProjectManager()->FindProjectForFile(ed->GetFilename(), &data, false, false);
if (data)
ed->SetProjectFile(data,true);
}
I'll check this in my local copy and look for side-effects (but I cannot think of any for the moment...).
I'm afraid I don't really understand. When you load a project, C::B does not load all files, so there is no such event you are asking for. If you are interested in parsing all files when the project is opened, you need the EVT_PROJECT_OPEN or better EVT_PROJECT_ACTIVATE. Then, in addition you can use EVT_PROJECT_TARGETS_MODIFIED, EVT_PROJECT_FILE_CHANGED, EVT_PROJECT_FILE_ADDED and EVT_PROJECT_END_REMOVE_FILES to check for changes in the setup. There is EVT_SETTINGS_CHANGED for checking, if the project's settings have been changed.
However, it makes no sense to prepare semantic highlighting for files that are actually not really opened, a.k.a. shown as an editor. Imagine you have workspaces with several 1000 files - how long shall the user wait? So semantic highlight IMHO gets interesting, once you see a file in an editor, that's why I pointed you to the EVT_EDITOR_ACTIVATED event.
Have a look at the Code::Completion plugin. It does all that: Checking for project settings, checking for file changes, running external tools (like the compiler to query the compiler's internal settings), workign once a file is opened and so on. CC would not work if all that was not possible.
If you still believe you need more, provide patches. The one you provided does not help you much, it is the same as the EVT_EDITOR_ACTIVATED event, once you did the changes as I suggested. Maybe I'll understand better your needs if you show what you have in mind.
For the wxExecute issue: Run it as an external process, use the C::B SDK to do so, maybe even in a thread. then you won't have such issues. It works really nice in several plugins we already ave, so I see no reason why it should not work for you, except you might have done something wrong. Again: in that case provide a test case / sample to reproduce.
Why do you need this?This is an idea, but I don't like it because every time I catch EVT_EDITOR_ACTIVATED I search some set of editors for the one I am processing...
I think you need something like EVT_EDITOR_MODIFIED event*, so you get a notification, when the contents of the editor gets modified.
At the start you'll do the first pass on EVT_EDITOR_ACTIVATED and mark it as highlighted, then when you get a modified event you'll do the re-highlighting...
* If there is no such event you can add it easily I think, just make sure you don't fire it for every key press.cbEVT_EDITOR_MODIFIED
Probably you can use a timer and group multiple changes together...
BTW: why don't you program in C? Why people introduced C++? After all, you can do everything in pure C or better, assembly or pure machine code ;PWhat is this comment? Something serious or just a joke?
I do not want to scan all project's files ;)Aha - I guess I understood what you mean now. But keepin mind, that the file might have changed externally and this is checked only at the EVT_EDITOR_ACTIVATED IMHO. So to make sure you are getting the up-to-date file content, this event is still right for you. You could use some caching to avoid scanning if not really needed. However, I still think adding another event would be an overkill as you can do what you want with the events we have. But if you really insist... nag me again and I'll see.
But I really don't see why is EVT_EDITOR_ACTIVATED the same as EVT_EDITOR_OPENED/LOADED...
I need to 'process' a file whenever a tab for this file appears in the C::B tab bar and 'process' this file when its tab disappears.
This is exactly what you said: I do not need to process files that are not displayed as tabs (aka opened in my terminology).
EVT_EDITOR_ACTIVATED is posted every time an editor gets focus and this is not what I need (or I really don't understand you...).
By 'process' I mean (among others) getting the project the file belongs to (which cannot be done using EVT_EDITOR_OPEN)
to get compile options.
PS. I've checked that EVT_SETTINGS_CHANGED is not posted when a target's settings are changed...That is true, it fires only when the global setting are changed. In your use case, you might want to check EVT_BUILDTARGET_SELECTED or EVT_PROJECT_TARGETS_MODIFIED.
BTW: I have no problem adding new events, but I don't understand the logic behind the current system, so I can't comment if your proposal is good or not, I'm just telling you what would I do if I'm implementing you.Do we actually have a good documentation about the events present? WiKi / SDK help?
Note the ";P" at the end.BTW: why don't you program in C? Why people introduced C++? After all, you can do everything in pure C or better, assembly or pure machine code ;PWhat is this comment? Something serious or just a joke?
BTW: I have no problem adding new events, but I don't understand the logic behind the current system, so I can't comment if your proposal is good or not, I'm just telling you what would I do if I'm implementing you.
BTW2: If you use a hash table there would be no performance problems :)
Aha - I guess I understood what you mean now. But keepin mind, that the file might have changed externally and this is checked only at the EVT_EDITOR_ACTIVATED IMHO. So to make sure you are getting the up-to-date file content, this event is still right for you.This is a place to add EVT_EDITOR_EXTERNAL_CHANGE or-something-like-this event. C::B should responsible for reloading the text...
This is similar to using EVT_EDITOR_ACTIVATED instead of EVT_EDITOR_OPENED... just a workaround (or 'ugly hack' ;))PS. I've checked that EVT_SETTINGS_CHANGED is not posted when a target's settings are changed...That is true, it fires only when the global setting are changed. In your use case, you might want to check EVT_BUILDTARGET_SELECTED or EVT_PROJECT_TARGETS_MODIFIED.
Wiki is not up-to-date (hence I didn't realize that EVT_SETTINGS_CHANGED exists) but the sources are sufficient.BTW: I have no problem adding new events, but I don't understand the logic behind the current system, so I can't comment if your proposal is good or not, I'm just telling you what would I do if I'm implementing you.Do we actually have a good documentation about the events present? WiKi / SDK help?
BTW: there is the EventsDisplay plugin somewhere in the forums that shows them all...
This is a place to add EVT_EDITOR_EXTERNAL_CHANGE or-something-like-this event. C::B should responsible for reloading the text...Sure, and it does exactly that. What I meant is if you only listen to editor open, then this is not enough for such cases, including the user edited the file a lot (including "hard-core" like selecting all text and removing it). So how will you track these changes? I strongly believe EVT_EDITOR_OPENED is not enough to cover all these cases, however, EVT_EDITOR_ACTIVATED in addition to EVT_EDITOR_MODIFIED will do. So I don't think this is an ugly hack, but the way to go. In the end, if a user opened a file (EVT_EDITOR_OPENED is fired) it is because in 99% of the time the content of the editor will change. So whatever you get at the time EVT_EDITOR_OPENED fires is obsolete sooner or later.
I am using EVT_EDITOR_OPENED only to set up data for that editor, like libclang's index and translation unit and to do initial highlighting.This is a place to add EVT_EDITOR_EXTERNAL_CHANGE or-something-like-this event. C::B should responsible for reloading the text...Sure, and it does exactly that. What I meant is if you only listen to editor open, then this is not enough for such cases, including the user edited the file a lot (including "hard-core" like selecting all text and removing it). So how will you track these changes? I strongly believe EVT_EDITOR_OPENED is not enough to cover all these cases, however, EVT_EDITOR_ACTIVATED in addition to EVT_EDITOR_MODIFIED will do. So I don't think this is an ugly hack, but the way to go. In the end, if a user opened a file (EVT_EDITOR_OPENED is fired) it is because in 99% of the time the content of the editor will change. So whatever you get at the time EVT_EDITOR_OPENED fires is obsolete sooner or later.
My proposal therefore: Add the event you desire in your local copy as needed and provide it as a patch with the plugin sources. If all works out nicely we / I will add it officially to the SDK.
And, what is a purpose of EVT_EDITOR_OPEN then? why not to use EVT_EDITOR_ACTIVATED instead with workarounds?I told you already, what this event is for. A lot plugins make use of this that need to track editors, like the ReopenEditor plugin (have a look). Here, for a file list for example, the ACTIVATED event is not important. It is also important to intercept opening editors that are no text editors.
Again: I am not against adding another event, its just that I am not fully convinced it is the right thing to do for your purposes. I might be wrong though - so proof me wrong with your implementation / patch. 8)OK, I'll try ;)
What I meant is if you only listen to editor open, then this is not enough for such cases, including the user edited the file a lot (including "hard-core" like selecting all text and removing it). So how will you track these changes? I strongly believe EVT_EDITOR_OPENED is not enough to cover all these cases, however, EVT_EDITOR_ACTIVATED in addition to EVT_EDITOR_MODIFIED will do. So I don't think this is an ugly hack, but the way to go. In the end, if a user opened a file (EVT_EDITOR_OPENED is fired) it is because in 99% of the time the content of the editor will change. So whatever you get at the time EVT_EDITOR_OPENED fires is obsolete sooner or later.just after I wrote
My logic behind SH plugin is:I haven't written anywhere that I will use EVT_EDITOR_OPENED to track changes in source code...
Editor is opened => if c++ file, create an index and highlight the text (with compile options of the editor's project's active build target via 'Target->CompileOptions' map described below)
Editor is closing => if c++ file, destroy an index
BuildTarget is created or modified => get compile options of the target, execute those in `...` and add it to a map 'Target->CompileOptions'
BuildTarget is removed => remove options from the map.
Source file changed (I have a framework for this already) => reparse index (here enter some optimizations from clang, e.g. precompiled headers) and highlight the text.
That's all. Just a simple logic.
I just believe that couple of things I propose make the sources of C::B and also of my plugin more clear.Sure thing - that's why I encouraged you do it the way you believe is best for you (and clean code) and provide patches to the core if necessary. :D
Hi guys!
I'm almost done with the very basic real-time semantic highlighter (first parsing is quite slow, that is, 4s but next ones highlight sources quite fast, i.e., below 0.5s on my Pentium Dual-Core machine). The plugin crashes sometimes so I'm not going to attach the sources, but I'm working on it ;)
...
Its still very earlier to ask but this just pop in my mind and wondered what do you think.It will be possible to highlight differently all different (semantic) kinds of variables, i.e., global, local, member (public/private/static/non-static/...), parameter variables, and similarly for functions.
So..what you think on highlighting a member variables and is it possible? Keep the work, please.
Sources of the very-very-very preliminary version of SemanticHighlight plugin are attached.To reach more tester, you should probably explain what dependencies you have, where they are available and how you "install" them.
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!).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.
Sources of the very-very-very preliminary version of SemanticHighlight plugin are attached.To reach more tester, you should probably explain what dependencies you have, where they are available and how you "install" them.
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.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!).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).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.
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.Yes, I think this is not really good. However, what about the other option(s) I suggested?
The events for project/target options changed and compiler options changed are IMHO the best solution here.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.Yes, I think this is not really good. However, what about the other option(s) I suggested?
And how about function returning true when C::B is starting and false otherwise? You have Manager::IsAppShuttingDown but no counterpart on startup.You can do it yourself easily: Have a global var "startupdone" that is false initially, connect to the "cbEVT_APP_STARTUP_DONE" event and set it to true if this fires. Combined with IsAppShuttingDown you get a method that "bools" if it is safe to operate or not.
Also, did you consider adding a mutex for each wxScintilla control that would be publicly available?Well - that is not so easy. But what is wrong if you operate inside an event and call Skip() only if you have finished. This way you have the control exclusively during that time.
I cannot do it in the plugin, it has to be provided from outside, that is from the main application. The reason is that attaching a plugin may occur after EVT_APP_STARTUP_DONE is fired (loading plugin via Plugins->Manage plugins).And how about function returning true when C::B is starting and false otherwise? You have Manager::IsAppShuttingDown but no counterpart on startup.You can do it yourself easily: Have a global var "startupdone" that is false initially, connect to the "cbEVT_APP_STARTUP_DONE" event and set it to true if this fires. Combined with IsAppShuttingDown you get a method that "bools" if it is safe to operate or not.
The problem is that I do not want to block application until reparse-highlight process is completed, which may happen long time after OnTextChanged handler returns (I have threads, one for each editor for parsing/highlighting). Second, reparsing is much longer than highlighting and I need to lock the editor's control only for highlighting.Also, did you consider adding a mutex for each wxScintilla control that would be publicly available?Well - that is not so easy. But what is wrong if you operate inside an event and call Skip() only if you have finished. This way you have the control exclusively during that time.
*** before
(500 millisecond pause)
**** update
(control update)
(2000 millisecond pause)
*** after*** before
(500 millisecond pause)
**** update
(2000 millisecond pause)
*** after and control update simultaneouslyAs for 'bool IsAppStartingUp()' function, shall I provide a patch?Yes, just do it similar to the IsShuttingDown method. I'm off the next few days - so you have enough time for a patch... Otherwise I can do if I'm back ;-)
Ok, I'll try to do it myself.As for 'bool IsAppStartingUp()' function, shall I provide a patch?Yes, just do it similar to the IsShuttingDown method. I'm off the next few days - so you have enough time for a patch... Otherwise I can do if I'm back ;-)
wxEVT_SCI_MODIFIED(BEFORE_INSERT/DELETE)
UI (control) update
wxEVT_SCI_MODIFIED(TEXTINSERT/DELETE)wxEVT_SCI_MODIFIED(BEFORE_INSERT/DELETE)
wxEVT_SCI_MODIFIED(TEXTINSERT/DELETE)
UI (control) update@Morten: I'm affraid I've lost in C::B architecture. Please guide me how to do that or do it for me (I think it would take you 5 min or so :)).Ok, I'll try to do it myself.As for 'bool IsAppStartingUp()' function, shall I provide a patch?Yes, just do it similar to the IsShuttingDown method. I'm off the next few days - so you have enough time for a patch... Otherwise I can do if I'm back ;-)
@Morten: I'm affraid I've lost in C::B architecture. Please guide me how to do that or do it for me (I think it would take you 5 min or so :)).OK - I've done it and will commit after a few tests... (as this changes the SDK version).
Thanks!@Morten: I'm affraid I've lost in C::B architecture. Please guide me how to do that or do it for me (I think it would take you 5 min or so :)).OK - I've done it and will commit after a few tests... (as this changes the SDK version).
How about these changes? When do you expect them to be commited?@Morten: I'm affraid I've lost in C::B architecture. Please guide me how to do that or do it for me (I think it would take you 5 min or so :)).OK - I've done it and will commit after a few tests... (as this changes the SDK version).
How about these changes? When do you expect them to be commited?They are in head now, with the limitations I mentioned. Tell me when thee is new stuff to test.
* no config dialog so farI recently tested (http://forums.codeblocks.org/index.php/topic,17526.0.html) with providing semantic highlighting by hooking into the Scintilla lexer. Pros: seamlessly integrates into the pre-existing highlighting settings. Cons: the patch there is currently not usable (due to some sort of thread lock, I think, when you start typing).
Oh... I forgot: you need gcc >=4.6 with -std=c++0x or -std=c++11 to compile the plugin (or other compiler supporting 'auto' and simple lambdas).Do you have any plans to remove all these c++11 things in the future, because some of us are stuck on older distros, which have only gcc-4.1 or gcc-4.4?
Oh... I forgot: you need gcc >=4.6 with -std=c++0x or -std=c++11 to compile the plugin (or other compiler supporting 'auto' and simple lambdas).Do you have any plans to remove all these c++11 things in the future, because some of us are stuck on older distros, which have only gcc-4.1 or gcc-4.4?
But... Do you have any plans to migrate to *newer* versions of gcc in the future? ;)Yes, gcc4.4.6 will be my next gcc. Unfortunately if you're doing commercial software you have to work on older distros.
The code without c++0x features attached.
One more thing to config: in file CompileOptions.cpp change
#define GCC_VERSION_STR "4.6.3"
to your version (it is used in a workaround for clang using libstdc++).
And don't try to close editors while there are pending changes...
I'm working on it ;)
EDIT: fixed crashes on editor close.