Use Markdown files for the Filer documentation. It actually works cor…

…rectly.

Signed-off-by: Michael Jackson <[email protected]>

PortingFilters.md

@@ -1,4 +1,4 @@
-# Porting a Filter #
+# Porting a Filter
 
 Depending on where the ported filter is coming from determines what you need to
 do. The sections are as follows:
@@ -13,17 +13,17 @@ do. The sections are as follows:
 </ul>
 
 
-## SECTION 1 : Porting From ***SIMPL*** to ***Filters Folder*** ##
+## SECTION 1 : Porting From ***SIMPL*** to ***Filters Folder***
 
 This will be the most common type of Filter porting. The steps for this are as
 follows:
 
-### Go to FreeNas and pull the custom build of DREAM3D ###
+### Go to FreeNas and pull the custom build of DREAM3D
 
 This custom build has **ALL** ***SIMPL*** plugins compiled so you don't need
 to worry about what filters will be available
 
-### Load up ***SIMPL*** DREAM3D and navigate to ***ComplexFilterGen*** ###
+### Load up ***SIMPL*** DREAM3D and navigate to ***ComplexFilterGen***
 
 Here you will need to set the command arguments using the following syntax:
 
@@ -40,14 +40,14 @@ Some nuances to note for this are as follows:
 You will need to update the various CMake files inside the target complex plugin in order to start compiling the new filter code inside of a complex build.
 
 
-## SECTION 2 : Porting stubs from existing folder to ***Filters Folder*** ##
+## SECTION 2 : Porting stubs from existing folder to ***Filters Folder***
 
 Some plugins have existing stubs in folders other than the primary ***Filters***
 folder.
 
-### Move the Filter and Algorithm files to the active ***Filters Folder*** ###
+### Move the Filter and Algorithm files to the active ***Filters Folder***
 
-### Update the Legacy UUID Maps ###
+### Update the Legacy UUID Maps
 <ol>
   <li> Open the LegacyUUIDMapping header file for this Plugin </li>
   <li> Find and uncomment the include statement for the filter being moved </li>
@@ -63,12 +63,12 @@ folder.
 
  > ***@@__MAP__UPDATE__TOKEN__DO__NOT__DELETE__@@***
  
- ### Update the CMakeLists.txt files to reflect the changes ###
+ ### Update the CMakeLists.txt files to reflect the changes
 
  This includes the ones for the unit tests and the one at the plugin level
 
 
-## SECTION 3 : Developing a Test File ##
+## SECTION 3 : Developing a Test File
 
 Firstly, it is important to ensure that each unit test does not just instantiate filter. Current standards require the following:
 <ul>
@@ -79,7 +79,7 @@ Firstly, it is important to ensure that each unit test does not just instantiate
 
 Test Files should **NOT** output strings to the terminal. Output should be in the form of catch2 errors.
 
-### Adding a new data file to ***DREAM3D Data Repo*** ###
+### Adding a new data file to ***DREAM3D Data Repo***
 
 For adding the data file to the DREAM3D repo one should follow the following steps:
 
@@ -100,7 +100,7 @@ GitHub Repo : <https://github.com/BlueQuartzSoftware/complex/releases/tag/Data_A
 
 Located at line 579 in the CMakeLists.text file in the ***complex*** repo, one must update the table accordingly.
 
-### Working with filters outside the current plugin  ###
+### Working with filters outside the current plugin 
 
 There will be times you may have to call upon filters from another repo. Typically this occurs in ***complex_plugins***. In order to do this one must create an application instance which is done so by wrapping it in a struct that gets nested in a shared pointer to make sure it cleans itself up after each test case. Here is the syntax for doing so:
 
@@ -118,11 +118,11 @@ The syntax for use of ***filterList*** is as follows:
 > REQUIRE(nullptr != filter);
 
 
-## SECTION 4 : Multithreading ##
+## SECTION 4 : Multithreading
 
 At the current time, the only filters that should be made parallel are those that could be considered "embarrassingly parallel". It is important to remember that the cost of creating a thread is hefty so it should only be done when there is a sizeable amount of work available for each thread. Complex has two types: ParallelTaskAlgorithm and ParallelDataAlgorithm. Task Runner is for parsing multiple objects and Data Runner is for parsing a single object. 
 
-### Syntax for Complex ###
+### Syntax for Complex
 
 This is an examplar use case and doesn't truly encompass all possible use cases for the functions, but instead serves to show how it should be structured in most cases.  
 
@@ -163,11 +163,11 @@ In the exectuting function:
 > dataAlg.execute(::FilterNameImpl(object, argument));  
 
 
-## SECTION 5 : Progress Updating ##
+## SECTION 5 : Progress Updating
 
 With out of core functionality on the way, it is now a requirement for each and every filter to have progress updates and checks for cancel. This section shows threadsafe progress updating and message structuring.
 
-### ThreadSafe Progress Messaging ###
+### ThreadSafe Progress Messaging
 
 This is an example that aims to reduce the number of times a mutex lock is called. 
 
@@ -189,7 +189,7 @@ This is an example that aims to reduce the number of times a mutex lock is calle
 
 This function should avoid being called too many times in a thread as it would significantly slow it down.
 
-### Message Structuring ###
+### Message Structuring
 
 For error messaging the following syntax should be used:
 
@@ -198,11 +198,11 @@ For error messaging the following syntax should be used:
 The number at the start is an arbitrary value save for the fact it must be negative.
 
 
-## SECTION 6 : Utilizing API's to the fullest ##
+## SECTION 6 : Utilizing API's to the fullest
 
 This section aims to tackle ***complex*** convenience functions from major API's:
 
-### Utilizing the ExecuteDataFunction ###
+### Utilizing the ExecuteDataFunction
 
 These templated varg functions aim to eliminate the need for type switches, this is done using functors. Below is example syntax:
 
@@ -224,7 +224,7 @@ In the executing function:
 > ExecuteDataFunction(FilterNameFunctor{}, selectedArrayRef.getDataType(), selectedArrayRef, argumentBool);  
 
 
-## SECTION 7 : Useful Tips and Tricks ##
+## SECTION 7 : Useful Tips and Tricks
 
 This section is just for basic genralized tips to help make our code better:
 <ul>

README.md

@@ -1,8 +1,8 @@
-# complex #
+# complex
 
 [![windows](https://github.com/BlueQuartzSoftware/complex/actions/workflows/windows.yml/badge.svg)](https://github.com/BlueQuartzSoftware/complex/actions/workflows/windows.yml) [![linux](https://github.com/BlueQuartzSoftware/complex/actions/workflows/linux.yml/badge.svg)](https://github.com/BlueQuartzSoftware/complex/actions/workflows/linux.yml) [![macos](https://github.com/BlueQuartzSoftware/complex/actions/workflows/macos.yml/badge.svg)](https://github.com/BlueQuartzSoftware/complex/actions/workflows/macos.yml) [![clang-format](https://github.com/BlueQuartzSoftware/complex/actions/workflows/format_push.yml/badge.svg)](https://github.com/BlueQuartzSoftware/complex/actions/workflows/format_push.yml)
 
-## License and Public Release Notice ##
+## License and Public Release Notice
 
 This software library is directly supported by USAF Contract *FA8650-22-C-5290* and has been cleared as publicly releasable under the following:
 
@@ -18,11 +18,11 @@ This software library is directly supported by USAF Contract *FA8650-22-C-5290*
 
 This clearance is in effect until 14 SEPT 2025 at which point any new additions created under USAF funding should be cleared. Public additions through the normal PR process will not be affected.
 
-## Introduction ##
+## Introduction
 
 `complex` is a rewrite of the [SIMPL](https://www.github.com/bluequartzsoftware/simpl) library upon which [DREAM3D](https://www.github.com/bluequartzsoftware/dream3d) is written. This library aims to be fully C++17 compliant, removes the need for Qt5 at the library level and brings more flexible data organization and grouping options.
 
-## Dependent Libraries ##
+## Dependent Libraries
 
 | Library Name | GitHub Source | Version |
 |--------------|---------------|---------|
@@ -42,7 +42,7 @@ This clearance is in effect until 14 SEPT 2025 at which point any new additions
 | nod  |<https://github.com/fr00b0/nod.git>  | 0.5.2 |
 | reproc  |<https://github.com/DaanDeMeyer/reproc>  | 14.2.4 |
 
-## Prerequisites ##
+## Prerequisites
 
 In order to compile `complex` you will need a C++17 compiler suite installed on your computer.
 
@@ -51,11 +51,11 @@ In order to compile `complex` you will need a C++17 compiler suite installed on
   + macOS 11.0 and Xcode 12.4 or higher
   + Linux with GCC Version 9.0 or higher or clang.
 
-## Install vcpkg ##
+## Install vcpkg
 
 The `complex` project uses the [vcpkg](https://www.github.com/microsoft/vcpkg) to manage it's dependent libraries. If this is not already installed on your system then you will need to download and compile it.
 
-### Windows ###
+### Windows
 
 Clone the vcpkg repository into a location that it will be used from. inside your home directory or at `C:/vcpkg` is a reasonable spot. *DO NOT USE A PATH WITH SPACES IN ANY OF THE FOLDERS*.
 
@@ -64,21 +64,21 @@ Clone the vcpkg repository into a location that it will be used from. inside you
 
 The `bootstrap-vcpkg.bat` file should be run automatically by CMake the first time. This will create the `vcpkg.exe` file. Additionally CMake should automatically find `vcpkg.exe`. If CMake does not find it, you may need to add it to your `PATH` variable.
 
-## Clone Appropriate Repositories ##
+## Clone Appropriate Repositories
 
 Within the folder DREAM3D-Dev clone both the `complex` and `DREAM3D_Data` repositories. The `DREAM3D_Data` repo is optional but does contain testing data.
 
 Create a location to keep the `complex` repositories and make builds. You can do either in-source our out-of-source builds.
 
     git clone --recursive https://github.com/bluequartzsoftware/complex
 
-## Configure complex with CMake ##
+## Configure complex with CMake
 
 For this example we are going to do an "in-source" build. By default git will ignore some basic names for build directories such as `Debug, Release, x64`. CMake can generate lots of project files from ninja, to nmake to Visual Studio. For this example we are going to use the `ninja` generator so we will need to keep the Debug and Release builds separated.
 
 The first time `complex` is configured with CMake, VCPKG will download, build and install the needed dependent libraries. This can take a few minutes so be patient. After `complex` is configured you can build it using your IDE (Visual Studio) or ninja (QtCreator, CLion) or cmake itself.
 
-### Windows with Visual Studio IDE ###
+### Windows with Visual Studio IDE
 
 This example shows how to configure complex to build using Visual Studio IDE
 
@@ -90,7 +90,7 @@ This example shows how to configure complex to build using Visual Studio IDE
 
     cmake -G "Visual Studio 16 2019" -A x64 -DCMAKE_TOOLCHAIN_FILE=%VCPKG_INSTALL_ROOT%/scripts/buildsystems/vcpkg.cmake -DCMAKE_BUILD_TYPE=%BUILD_DIR% -DVCPKG_MANIFEST_FEATURES="tests;parallel"  -DDREAM3D_Data_Dir=../../DREAM3D_Data ../complex
 
-### Windows with Ninja and IDE of choice (QtCreator, CLion, command line) ###
+### Windows with Ninja and IDE of choice (QtCreator, CLion, command line)
 
 Adjust the below commands to the sytle of your shell (The below example is done in Windows Command Prompt Batch file style).
 
@@ -106,7 +106,7 @@ In this example we are building a Release version of compled into a directory ca
 
     cmake -G Ninja -DCMAKE_TOOLCHAIN_FILE=%VCPKG_INSTALL_ROOT%/scripts/buildsystems/vcpkg.cmake -DCMAKE_BUILD_TYPE=%BUILD_DIR% -DVCPKG_MANIFEST_FEATURES="tests;parallel" -DDREAM3D_Data_Dir=../../DREAM3D_Data ../complex
 
-### macOS ARM64/M1 Compile and IDE of choice (QtCreator, CLion, command line) ###
+### macOS ARM64/M1 Compile and IDE of choice (QtCreator, CLion, command line)
 
     export NINJA_INSTALL=/opt/local/bin
     export PATH=$PATH:$NINJA_INSTALL
@@ -122,7 +122,7 @@ In this example we are building a Release version of compled into a directory ca
 
     cmake -G Ninja -DCMAKE_TOOLCHAIN_FILE=$VCPKG_INSTALL_ROOT/scripts/buildsystems/vcpkg.cmake -DCMAKE_BUILD_TYPE=$BUILD_DIR -DVCPKG_MANIFEST_FEATURES="tests;parallel" -DDREAM3D_DATA_DIR=$HOME/Workspace1/DREAM3D_Data -DVCPKG_TARGET_TRIPLET:STRING=$VCPKG_TARGET_TRIPLET ../complex
 
-## Required CMake Arguments ##
+## Required CMake Arguments
 
 + `-G` and one of the supported CMake generator strings
   + `Ninja` works very well on all platforms if you have [ninja](https://github.com/ninja-build/ninja/releases)
@@ -135,11 +135,11 @@ In this example we are building a Release version of compled into a directory ca
   + Linux: x64-linux-dynamic
   + Windows:
 
-## Adding Plugins ##
+## Adding Plugins
 
 By default the **only** plugin that is compiled is the `ComplexCore` plugin. If you would like to build any of the additional plugins you can provide additional arguments to the configuration command. **NOTE** For the `COMPLEX_EXTRA_PLUGINS` CMake argument, if you have multiple plugins separate each with a `;` character (which is why we double quote the value for the COMPLEX_EXTRA_PLUGINS variable.)
 
-### ITKImageProcessing ###
+### ITKImageProcessing
 
 This plugin gives complex access to the ability to read/write images and use the **ITK** library to process images.
 
@@ -148,28 +148,28 @@ There are 2 arguments that need to be added to the CMake configuration command
 + `-DCOMPLEX_EXTRA_PLUGINS="ITKImageProcessing"`
 + `-DVCPKG_MANIFEST_FEATURES="tests;parallel;itk"`
 
-### OrientationAnalysis ###
+### OrientationAnalysis
 
 This plugin gives complex the ability to process typical EBSD style of data.
 
 + `-DCOMPLEX_EXTRA_PLUGINS="OrientationAnalysis"`
 + `-DVCPKG_MANIFEST_FEATURES="tests;parallel;ebsd"`
 
-## VCPKG Options ##
+## VCPKG Options
 
-### Defining where VCPKG installs the dependent libraries ###
+### Defining where VCPKG installs the dependent libraries
 
 By default VCPKG will install any library that it compiles into vcpkg specific and platform specific locations. If you would like to specifically set where those libraries are installed the following cmake code will allow that:
 
 + `-DVCPKG_INSTALLED_DIR=$HOME/workspace/vcpkg-installed`
 
-### Disable VCPKG from checking for updates with each configuration ###
+### Disable VCPKG from checking for updates with each configuration
 
 Be default VCPKG will check for updates to the libraries that it compiles. If you would like to skip this step each time the following CMake code is needed:
 
 + `-DVCPKG_MANIFEST_INSTALL=OFF`
 
-## Defining where test data is stored ##
+## Defining where test data is stored
 
 Complex and its plugins require test files to be able to perform the unit tests. By default these will be store inside the build directory. This means that if you have multiple build directories, a separate copy of all the test files will be downloaded for each build directory. The developer can set the `DREAM3D_DATA_DIR` variable to a path that will be used. They will need to set this for **each** build directory. You **MUST** define `DREAM3D_DATA_DIR` using an absolute path. Relative paths **will not work**.
 
@@ -179,7 +179,7 @@ The developer can also turn off the downloading of any test data with the follow
 
 + `-DCOMPLEX_DOWNLOAD_TEST_FILES=OFF`
 
-## Python Bindings ##
+## Python Bindings
 
 Python bindings are available for complex. To install them, please use an Anaconda virtual environment like the following:
 

cmake/Plugin.cmake

@@ -222,8 +222,8 @@ function(create_complex_plugin)
     foreach(file_name ${ARGS_FILTER_LIST})
       #message(STATUS "CHECKING DOCS FOR ${file_name}")
       #string(REPLACE "Filter" "" file_name ${file_name})
-      if(NOT EXISTS "${${ARGS_NAME}_SOURCE_DIR}/docs/${file_name}.rst")
-        message(STATUS "!!!> DOCUMENTATION WARNING:${${ARGS_NAME}_SOURCE_DIR}/docs/${file_name}.rst Does Not Exist")
+      if(NOT EXISTS "${${ARGS_NAME}_SOURCE_DIR}/docs/${file_name}.md")
+        message(STATUS "!!!> DOCUMENTATION WARNING:${${ARGS_NAME}_SOURCE_DIR}/docs/${file_name}.md Does Not Exist")
       endif()
     endforeach()
   endif()

docs/Code_Style_Guide.md

@@ -3,24 +3,24 @@
 This is the style guide for the COMPLEX library. When contributing sources to the complex repository we ask that all contributions follow this style guide. These general rules have been developed over the years in an effort to allow efficient coding practices.
 
 
-## Source Code Line Endings ##
+## Source Code Line Endings
 
  All source code line endings should be in "Unix" style "\n". Every text editor understands these line endings on every platform **except** the "Notepad" application on Windows.
 
 
-## Use of Tabs ##
+## Use of Tabs
 
 Spaces should be used instead of hard tabs. This helps file portability across different editors. DREAM.3D uses a standard whereby all indents  use two spaces.
 
-## Always Use an Include Guard ##
+## Always Use an Include Guard
 
 Always use
 
     #pragme once
 
 at the top of *EVERY* header file.
 
-## Special Constants ##
+## Special Constants
 
 nullptr should be used in conjunction with only raw pointers and 0 (zero) should be used in conjunction with numeric values:
 
@@ -31,22 +31,22 @@ nullptr should be used in conjunction with only raw pointers and 0 (zero) should
     int i = NULL; // Bad 
 
 
-## Array Initialization ##
+## Array Initialization
 
 Prefer the use of C++11 std::array<N, T> instead of "C" style arrays.
 
     int32_t foo[3]; // BAD.. No initialization of the internal data
     std::array<int32_t, 3> foo = {0,0,0};
 
-## The Dereference operator `*` and the Address-Of Operator `&` Should Be Directly Connected with the Type-Specifier ##
+## The Dereference operator `*` and the Address-Of Operator `&` Should Be Directly Connected with the Type-Specifier
 
     int32*   p; // Correct
     int32   *p; // Incorrect
     int32*   p, q; // Probably error
 
 The _int32*  p;_ form emphasizes type over syntax while the _int32 *p;_ form emphasizes syntax over type. Although both forms are equally valid C++, the heavy emphasis on types in C++ suggests that _int32* p;_ is the preferable form.
 
-## Always Implement the "Big Five" in C++ Classes ##
+## Always Implement the "Big Five" in C++ Classes
 
 When writing C++ classes the programmer will always define the "Big Three" which are defined as:
 
@@ -88,7 +88,7 @@ There is an include clang-tidy file that most IDE's can use to assist with some
 - Macros are `ALL_UPPER_SNAKE_CASE`
 
 
-## String Constants ##
+## String Constants
 
 String constants in C++ should be declared as: