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

…rectly.

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

.markdownlint-configure-file.json

@@ -0,0 +1,4 @@
+{
+"default" : true,
+"MD013": {}
+}

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

@@ -21,7 +21,7 @@ The vision for the DREAM.3D project is to produce accessible software tools that
 
 ## 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:
+This software library is directly supported by USAF Contract *FA8650-22-C-5290* and has been cleared as publicly releasable under the following:
 
 ```text
 AFRL has completed the review process for your case on 14 Sep 2022:

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

@@ -1,24 +1,24 @@
-# Code Style Guide #
+# Code Style Guide
 
 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:
 
@@ -28,22 +28,22 @@ nullptr should be used in conjunction with only raw pointers and 0 (zero) should
     int i = 0; // Good
     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:
 
@@ -70,7 +70,7 @@ should be marked as deleted or default'ed or manually implemented.
 
 Note that with C++11, programmers now have the ability to inform the compiler which of these operations can be constructed by default and which can be ignored using the `default` and `delete` keywords.
 
-## Naming conventions ##
+## Naming conventions
 
 There is an include clang-tidy file that most IDE's can use to assist with some of the major areas. One area is the naming conventions that COMPLEX uses. Here are the basic rules:
 
@@ -84,7 +84,7 @@ There is an include clang-tidy file that most IDE's can use to assist with some
 - Free Functions are `UpperCamelCase`
 - Macros are `ALL_UPPER_SNAKE_CASE`
 
-## String Constants ##
+## String Constants
 
 String constants in C++ should be declared as:
 
@@ -103,6 +103,6 @@ When using ANSI C one should use a char* for constant strings:
 
 Using this type of approach allows for quicker code updates when constant values need to be changed.
 
-## Clang Formatting ##
+## Clang Formatting
 
 `clang-format` is a tool to automatically format C++ code. You should run 'clang-format' on your code before opening a Pull Request to make sure it passes the *clang-format pr* check. You can install `clang-format` and `git-clang-format` with `npm install -g clang-format`. To automatically format a file according to a project's C++ code style, run `clang-format -i path/to/complex/file`, which is supported on macOS/Linux/Windows. If you want to run `clang-format` on all the changed code on your latest git commit (HEAD), you can run `git-clang-format HEAD~1`. Run `git-clang-format -h`  for extra help.