Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development
BlackDoc documentation plugin
marked:
Ok, I am still waiting for some feedback about bugs and mistakes. Also feedback about autotools files I've added to the project will be very pleasant, just to be sure they work not only by me.
Now some ideas for the future to discuss.
The next large thing I want to implement in my plugin is the generation of help skeleton from C++ sources. This means, the plugin will parse project sources (maybe also doxygen comments) and then create BlackDoc files with appropriate names taken from classes/others names and fill this files with the info about class members etc. I need to do some research here: parsing the C++ code isn't simple because of preprocessor directives, and C++0x makes things even more scary. So this step may take time. This is only one more thing I really need from this plugin.
Several other ideas, I don't promise to create this all:
- BlackDoc project wizard to be able to create separate documentation project.
- 'Create BlackDoc file' item in the context menu, when you right-click over some name in the source code.
- Some text patterns which can be chosen while creating the BlackDoc file, for example 'class documentation file', 'namespace documentation file' etc.
- Export to other formats. At least *.chm is necessary, I think.
- Lists and tables with multiline items in the wiki-style lang.
- When the BlackDoc file is opened, some right-click or app menu features, like 'add current date', 'add table' etc.
- Maybe also the markup language highlighting, but is it possible without patching scintilla?
- Some other ideas?
killerbot:
wxwidgets in relationship to stl is a strange to my personally.
A few distro versions ago (I am using Opensuse) I couldn't build CB anymore. Why, the default wx library and dev files were the stl variant; and no longer the wxcontainer version. Switching to the wxcontainer version solved it.
Confusing is the least we can say.
If the language provides it, I would always prefer the language instead of abstractions like boost, wxwidgets, poco, qt.
Wxwidgets and qt, and poco add more functionality to their string classes for example, things lacking in the stl variant.
But enhancing the stl variant with for example boost string algo library brings nearly the same thing.
Nice thing about this : it is extending the stl string not replacing or reinventing the wheel.
But this is offcourse a matter of taste.
With respect to the C++0x, I am 100% in favor for using it, I think the compilers mostly used for building CB are gcc, and to some extend MSVC. Gcc is really taking the C++0x lead, and MSVC is not that far behind. That's the good news, .... the bad news we want to support distros with older gcc versions.
As has been mentioned as an example CentOS.
Here again I express my personal feeling, I have been running into CentOS and have been wishing it not so pleasant things ;-) . I know people want it to be stable, but its packages are so darn old, that it makes me turn into a synical mood and I want to suggest windows 3.11 to those users ;-)
Just kidding, but personal taste.
Waiting another 3 - 5 years before really using C++0x, I am sorry, that's what the C++ community can do without, we want things to move on, and we all hope to have another standard in 5 years (file system ? sockets ? string algorithm ,....).
Today is surely to soon to switch and put some people out in the cold, but we need to think about it and after the next CB release (whenever that might be ;-) ) we should consider putting it on the roadmap). By theway, that would be good for Centos, they can stick with that release of CB for like 20 years , to bad for the developer that wants to build CB him/her self on Centos :(
As for a new plug-in, I think the plug-in developer should be allowed to use C++0x, meaning his plug-in wil probably never been promoted to a contrib plugin in our repository, unless we have makefiles, projects files that might determine that there's no C++0x support and then disables that specific plug-in from the build being carried out at hand.
As another brain teaser : keep waiting on wxwidgets to move on, no thanks. Their 3.0 is even getting ready at a slower pace then the C++0x standard took 8).
And if you want to talk about a platform breaking code with every release , yes .. wxwidgets.
oBFusCATed:
Unfortunately, if you want to use a linux to write plugins for other commercial software products as I do (Autodesk Maya and Katana/Nuke by The Foundry in my case), you have to stick to the compilers they have been build with and the easiest option to do so is to use the distro and version they have being built on.
In my case Centos 5.6. I don't like Centos, nor do I like yum/rpm, but this is the easiest option and the most secure one in terms of compatibility.
ollydbg:
--- Quote from: jens on April 22, 2012, 03:07:44 pm ---
--- Quote from: MortenMacFly on April 22, 2012, 02:04:15 pm ---So well, still: If you are with VZ you should only use std::string and not mixed. ;-)
--- End quote ---
The problem is, that many users find wxString in wx2.9 much slower as in 2.8.
That might be (and is most likely) the cause for the much slower cc with wx2.9.
--- End quote ---
Off thread question:
Do we need to fix the string type std::string<char> or std::string<wchar_t> in CodeCompletion plugin? A lot of the parsing work is text/buffer manipulation. Also when we need to do the GUI part, we can translate to wxString.
Another thing is: if the part buffer char type is fixed. I can use more extreme fast lexer like QUEX or FLEX. The Current Tokenizer is quite limited.
Alpha:
--- Quote from: MortenMacFly on April 22, 2012, 11:25:30 am ---
--- Quote from: Alpha on April 22, 2012, 05:24:42 am ---Yes; compiled and tested on XP with the project file from my previous post.
--- End quote ---
But only, if hijacking the PCH chain.
--- End quote ---
Is this the proper way to do it?
--- Code: ---diff -r e8000aa19e1c BlackDoc-win.cbp
--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/BlackDoc-win.cbp Mon Apr 23 20:39:43 2012 -0400
@@ -0,0 +1,143 @@
+<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
+<CodeBlocks_project_file>
+ <FileVersion major="1" minor="6" />
+ <Project>
+ <Option title="BlackDoc" />
+ <Option pch_mode="2" />
+ <Option compiler="gcc" />
+ <Build>
+ <Target title="default">
+ <Option output="blackdoc" prefix_auto="1" extension_auto="1" />
+ <Option object_output="objs" />
+ <Option type="3" />
+ <Option compiler="gcc" />
+ <Option parameters="--debug-log --multiple-instance -na -ns -nd" />
+ <Option host_application="$(#cb)\devel\codeblocks.exe" />
+ <Option run_host_application_in_terminal="0" />
+ <Compiler>
+ <Add option="-g" />
+ <Add option="-pipe" />
+ <Add option="-mthreads" />
+ <Add option="-fmessage-length=0" />
+ <Add option="-fexceptions" />
+ <Add option="-Winvalid-pch" />
+ <Add option="-DBUILDING_PLUGIN" />
+ <Add option="-DHAVE_W32API_H" />
+ <Add option="-D__WXMSW__" />
+ <Add option="-DWXUSINGDLL" />
+ <Add option="-DcbDEBUG" />
+ <Add option="-DCB_PRECOMP" />
+ <Add option="-DWX_PRECOMP" />
+ <Add option="-DwxUSE_UNICODE" />
+ <Add directory="$(#cb)\include" />
+ <Add directory="$(#cb)\sdk\wxscintilla\include" />
+ <Add directory="$(#WX.include)" />
+ <Add directory="$(#WX.lib)\gcc_dll$(WX_CFG)\msw$(WX_SUFFIX)" />
+ </Compiler>
+ <Linker>
+ <Add option="-Wl,--enable-auto-import" />
+ <Add option="-mthreads" />
+ <Add library="wxmsw28$(WX_SUFFIX)" />
+ <Add library="codeblocks" />
+ <Add directory="$(#cb)\devel" />
+ <Add directory="$(#WX.lib)\gcc_dll$(WX_CFG)" />
+ </Linker>
+ <ExtraCommands>
+ <Add after="zip -j9 blackdoc.zip manifest.xml styles.css" />
+ <Add after="zip -j9 blackdoc.cbplugin blackdoc.dll blackdoc.zip" />
+ <Mode after="always" />
+ </ExtraCommands>
+ </Target>
+ <Environment>
+ <Variable name="WX_CFG" value="" />
+ <Variable name="WX_SUFFIX" value="u" />
+ </Environment>
+ </Build>
+ <VirtualTargets>
+ <Add alias="All" targets="default;" />
+ </VirtualTargets>
+ <Compiler>
+ <Add option="-Wall" />
+ </Compiler>
+ <Unit filename="Directory.cpp" />
+ <Unit filename="Directory.h" />
+ <Unit filename="ErrorMessage.cpp" />
+ <Unit filename="ErrorMessage.h" />
+ <Unit filename="FileCreationDialog.cpp" />
+ <Unit filename="FileCreationDialog.h" />
+ <Unit filename="FileSignature.cpp" />
+ <Unit filename="FileSignature.h" />
+ <Unit filename="FilesHandler.cpp" />
+ <Unit filename="FilesHandler.h" />
+ <Unit filename="HTMLActiveFileExporter.cpp" />
+ <Unit filename="HTMLActiveFileExporter.h" />
+ <Unit filename="HTMLActiveProjectExporter.cpp" />
+ <Unit filename="HTMLActiveProjectExporter.h" />
+ <Unit filename="HTMLBranchIndexBuilder.cpp" />
+ <Unit filename="HTMLBranchIndexBuilder.h" />
+ <Unit filename="HTMLContent.cpp" />
+ <Unit filename="HTMLContent.h" />
+ <Unit filename="HTMLDocument.cpp" />
+ <Unit filename="HTMLDocument.h" />
+ <Unit filename="HTMLExporter.cpp" />
+ <Unit filename="HTMLExporter.h" />
+ <Unit filename="HTMLFilesCreator.cpp" />
+ <Unit filename="HTMLFilesCreator.h" />
+ <Unit filename="HTMLFooter.h" />
+ <Unit filename="HTMLHeader.cpp" />
+ <Unit filename="HTMLHeader.h" />
+ <Unit filename="HTMLInnerParser.cpp" />
+ <Unit filename="HTMLInnerParser.h" />
+ <Unit filename="HTMLList.cpp" />
+ <Unit filename="HTMLList.h" />
+ <Unit filename="HTMLMainIndexBuilder.cpp" />
+ <Unit filename="HTMLMainIndexBuilder.h" />
+ <Unit filename="HTMLMenu.cpp" />
+ <Unit filename="HTMLMenu.h" />
+ <Unit filename="HTMLPageBuilder.cpp" />
+ <Unit filename="HTMLPageBuilder.h" />
+ <Unit filename="HTMLRemovePreviousFiles.cpp" />
+ <Unit filename="HTMLRemovePreviousFiles.h" />
+ <Unit filename="HTMLSourceCode.cpp" />
+ <Unit filename="HTMLSourceCode.h" />
+ <Unit filename="HTMLTable.cpp" />
+ <Unit filename="HTMLTable.h" />
+ <Unit filename="HTMLTags.cpp" />
+ <Unit filename="HTMLTags.h" />
+ <Unit filename="IFileData.h" />
+ <Unit filename="ProgressDialog.cpp" />
+ <Unit filename="ProgressDialog.h" />
+ <Unit filename="Project.cpp" />
+ <Unit filename="Project.h" />
+ <Unit filename="ProjectInfo.cpp" />
+ <Unit filename="ProjectInfo.h" />
+ <Unit filename="QuestionMessage.cpp" />
+ <Unit filename="QuestionMessage.h" />
+ <Unit filename="ReplacementDialog.cpp" />
+ <Unit filename="ReplacementDialog.h" />
+ <Unit filename="StringPreparator.cpp" />
+ <Unit filename="StringPreparator.h" />
+ <Unit filename="Text.cpp" />
+ <Unit filename="Text.h" />
+ <Unit filename="WarningMessage.cpp" />
+ <Unit filename="WarningMessage.h" />
+ <Unit filename="blackdoc.cpp" />
+ <Unit filename="blackdoc.h" />
+ <Unit filename="description-en.txt" />
+ <Unit filename="description-ru.txt" />
+ <Unit filename="documentation\html\help\description-en.html" />
+ <Unit filename="documentation\html\help\description-ru.html" />
+ <Unit filename="documentation\html\help\index.html" />
+ <Unit filename="documentation\html\help\styles.css" />
+ <Unit filename="documentation\html\index.html" />
+ <Unit filename="documentation\html\styles.css" />
+ <Unit filename="gpl-license.txt" />
+ <Unit filename="manifest.xml" />
+ <Unit filename="styles.css" />
+ <Extensions>
+ <code_completion />
+ <envvars />
+ <debugger />
+ </Extensions>
+ </Project>
+</CodeBlocks_project_file>
diff -r e8000aa19e1c HTMLExporter.cpp
--- a/HTMLExporter.cpp Sun Apr 22 14:29:08 2012 +0400
+++ b/HTMLExporter.cpp Mon Apr 23 20:39:43 2012 -0400
@@ -18,10 +18,15 @@
* along with BlackDoc. If not, see <http://www.gnu.org/licenses/>.
*
*/
+
+#include "sdk.h"
+
+#ifndef CB_PRECOMP
+ #include <projectmanager.h>
+ #include <editormanager.h>
+ #include <cbproject.h>
+#endif
-#include <projectmanager.h>
-#include <editormanager.h>
-#include <cbproject.h>
#include "HTMLExporter.h"
#include "QuestionMessage.h"
#include "HTMLActiveFileExporter.h"
--- End code ---
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version