Plugin: CMake

[eranif]

I know the initial loading was slow

I guess you did not try that on Windows

The version with dockable window loads the data from sqlite database and that must be created by user -- there is a button for that

So basically you plan on making it an "On Demand" thing

I suggest using some "slick" controls, like using wxInfoBar that says: "Help is not available yet, would you like to create it? [create] [cancel]"

How do you plan on merging the two branching? (i.e. how do you plan on incorporating the background thread to your code)

I suggest that you will work directly on codelite's code and use something like:

Code: Select all

git diff origin/master > cmake-plugin.patch

to submit your changes so I could test them / apply them

Note that we plan on releasing a new codelite version _this_ weekend. So any changes you had in mind should be ready in the coming days ( I still need to build and test it on OSX)

If you want, I can create Czech translation for the plugin.

Quark66 already created a Czech translation for codelite maybe you can improve it (by adding the translation to the plugin)
Here is a link to his work in the translation forum:
http://forums.codelite.org/viewtopic.php?f=15&t=2006

Eran

[NTSFka]

I know the initial loading was slow

I guess you did not try that on Windows

I did and that was the reason to use SQLite . Then after many weird noises that were released from my HDD I realized there is something wrong somewhere, so that I found it's good to use transactions.

The version with dockable window loads the data from sqlite database and that must be created by user -- there is a button for that

So basically you plan on making it an "On Demand" thing

I suggest using some "slick" controls, like using wxInfoBar that says: "Help is not available yet, would you like to create it? [create] [cancel]"

The plugin uses a background thread now so it's more user-friendly If the help is not available and cmake path is valid, the plugin loads it in a separate thread on background. There is "reload" button too so it can be run manually if user wants to reload it (e.g. cmake was updated). It still takes a little bit more time that I want but is performed once at time so will be OK for now .

How do you plan on merging the two branching? (i.e. how do you plan on incorporating the background thread to your code)

I suggest that you will work directly on codelite's code and use something like:

Code: Select all

git diff origin/master > cmake-plugin.patch

to submit your changes so I could test them / apply them

Yes, it's definitely better to work directly on codelite's code than have separate sources what will be hard to synchronize. When some changes are done I'll post a patch here.
Maybe I create a clone on github so you can watch changes from time to time.

Note that we plan on releasing a new codelite version _this_ weekend. So any changes you had in mind should be ready in the coming days ( I still need to build and test it on OSX)

I read that somewhere on this forum. I'll do only some cleaning and complete tooltips. There is cmake project import on the plan but it takes some time before the cmake with Codelite generator will be released.

If you want, I can create Czech translation for the plugin.

Quark66 already created a Czech translation for codelite maybe you can improve it (by adding the translation to the plugin)
Here is a link to his work in the translation forum:
http://forums.codelite.org/viewtopic.php?f=15&t=2006

Ok, I'll look on it but don't think I will be able to finish it before 5.4 release.

There is big difference between the plugin version in the codelite's source and the current version. Shall I create a patch or will you handle it by yourself?

[eranif]

I did and that was the reason to use SQLite . Then after many weird noises that were released from my HDD I realized there is something wrong somewhere, so that I found it's good to use transactions.

Indeed. codelite is using sqlite intensively (for code completion among others) and without the transactions, this would not been possible

The plugin uses a background thread now so it's more user-friendly If the help is not available and cmake path is valid, the plugin loads it in a separate thread on background

There are still some things that are lacking: your worker thread is sharing the 'cmake' object with the plugin ( I am not sure how safe it is ), also, if for some reason, the user exits codelite while the worker thread is working - codelite won't be able to close until the background thread has completed its task. See codelite's version of the plugin which calls TestDestroy() before every execution (I did not see any call to TestDestroy() in your code)

There is big difference between the plugin version in the codelite's source and the current version. Shall I create a patch or will you handle it by yourself?

I will take the parts that changes the dialog to docking window + gauge and will merge them with codelite's version of the plugin. Hopefully that this will be last merge and we can continue working on the a single source tree

Your suggestion for making a fork of codelite for this purpose on GitHub sounds like a good idea

EDIT:
I just this parts in your code (as part of the "Entry" function):

Code: Select all

m_gaugeLoad->Hide();
Layout();

Accessing UI code from the background thread is strictly forbidden (it will definitely cause a crash on OSX)

Eran

[NTSFka]

There are still some things that are lacking: your worker thread is sharing the 'cmake' object with the plugin ( I am not sure how safe it is ), also, if for some reason, the user exits codelite while the worker thread is working - codelite won't be able to close until the background thread has completed its task. See codelite's version of the plugin which calls TestDestroy() before every execution (I did not see any call to TestDestroy() in your code)

I know about that it was on my plan. Thread safety of the 'cmake' object was not on my mind. I rather check everything.

I will take the parts that changes the dialog to docking window + gauge and will merge them with codelite's version of the plugin. Hopefully that this will be last merge and we can continue working on the a single source tree

Your suggestion for making a fork of codelite for this purpose on GitHub sounds like a good idea

When you done that, I will start making changes on that code.

EDIT:
I just this parts in your code (as part of the "Entry" function):

Code: Select all

m_gaugeLoad->Hide();
Layout();

Accessing UI code from the background thread is strictly forbidden (it will definitely cause a crash on OSX)

I completely forgot that when I moved that code from OnThreadUpdate

Jiri

[eranif]

CMakePlugin is now up-to-date with your latest code
Changes done:

- Fixed crash when codelite exits while the worker thread is still loading the help content. This only happens if the 'CMake Help' tab is not selected while exiting codelite
- The worker thread now checks for 'ReqeustStop' before every execute it performs (this way it react faster to shutdown requests)
- The worker thread is now deleted when the plugin 'UnPlug' method is called
- Changed the default splitter to be vertical
- Changed the wxRadioBox to wxChoice

Thanks for the effort!

EDIT:
I also made sure it compiles and runs properly on OSX and Windows

Eran

[NTSFka]

CMakePlugin is now up-to-date with your latest code

Thank you.

- Fixed crash when codelite exits while the worker thread is still loading the help content. This only happens if the 'CMake Help' tab is not selected while exiting codelite

The 'OnClose' function was supposed to wait for the worker thread competition but I didn't check the wxWidgets doesn't call EVT_CLOSE when 'Destroy' is called. And maybe, it should be a good idea to use 'DeletePage' instead of 'RemovePage'

- The worker thread is now deleted when the plugin 'UnPlug' method is called

I'd rather like to the CMakeHelpTab should be responsible for that. It's more clear and no dynamic_cast is required. The CMakeHelpTab's 'Destroy' function will be best place for that (I need to check first if this doesn't broke some wxWidgets internal rules or something like that) and not the 'OnClose'.

- Changed the default splitter to be vertical

Ok, I set the splitter to be horizontal because I find it in the default Codelite's layout more readable. I'll add some code that remembers the splitter position.

- Changed the wxRadioBox to wxChoice

Maybe it's better. I chose the wxRadioBox because it allows to faster topic change.

Thanks for the effort!

Thank you too!

EDIT:
I also made sure it compiles and runs properly on OSX and Windows

Thank you again

I assume you want to finish the 5.4 now so I'll make the changes after the 5.4 release.

What happened to the plugin's global settings dialog? No bottom line (I'm OK with that), added borders (too much unused space) and no minimal size (it looks weird when you open a dialog and its size is 20x20 or less).

[eranif]

No bottom line (I'm OK with that)

It does not look good on OSX

added borders (too much unused space)

Without them, it looks horrbible on OSX. On OSX you need at least 5 pixels around the controls otherwise the blue focus line is not drawn completely or in some cases the control itself is truncated

and no minimal size

This sounds like a bug to me, will check it out

And maybe, it should be a good idea to use 'DeletePage' instead of 'RemovePage'

When deleting a pointer that was created by another DLL (MSW talking here) I found that it often causes crashes. This is why the plugin 'Removes' and delete it in the UnPlug code

Eran

[eranif]

FYI: My work for cmake was accepeted and merged in cmake's git head.
http://www.cmake.org/cmake/help/git-mas ... eLite.html

Hopefully, it will be part of the next release
Eran

[Jarod42]

Some feed back about plugin CMake of CL 5.4:
(Note I use CMake 2.8)

- CMake exporter: I think there is a typo it should be CMAKE_CXX_FLAGS instead of CMAKE_CXXFLAGS.
- CMake option should do as custom Makefile: disable Compiler/Linking Settings when activated.
- compile one file fails (it uses the "normal" way in fact).
- No Dark theme for CMake files (EDIT: I reset colour and it works now)

[NTSFka]

And maybe, it should be a good idea to use 'DeletePage' instead of 'RemovePage'

When deleting a pointer that was created by another DLL (MSW talking here) I found that it often causes crashes. This is why the plugin 'Removes' and delete it in the UnPlug code

I meant calling 'DeletePage' in the UnPlug function so the page will be destroyed a little bit sooner.

FYI: My work for cmake was accepeted and merged in cmake's git head.
http://www.cmake.org/cmake/help/git-mas ... eLite.html

Hopefully, it will be part of the next release

Great!

Some feed back about plugin CMake of CL 5.4:
(Note I use CMake 2.8)

- CMake exporter: I think there is a typo it should be CMAKE_CXX_FLAGS instead of CMAKE_CXXFLAGS.
- CMake option should do as custom Makefile: disable Compiler/Linking Settings when activated.
- compile one file fails (it uses the "normal" way in fact).
- No Dark theme for CMake files (EDIT: I reset colour and it works now)

- I forgot test it.
- Codelite's plugin API doesn't allow that yet. Custom Makefile is a part of Codelite so it can disable Compiler/Linking Settings.
- I know about that. The main problem is the Codelite passes internal file output path to the make.

And thank you for the feedback.