Multi-select filename handling and complex visibility judgment

[Cirn09]

1. I found that when select multiple files, the selection.filename will be filenames string separated by \n, which makes it impossible to add quotes to one of filenames with spaces.

2. WinRar's "Open with WinRar" can judge visibility according to the actual file type instead of file extension, I hope ShellAnything can also support such complex judgment logic.

I think a good way to achieve the above two functions is to add plug-in or script engine support.

[end2endzone]

Hi. Thank you for the feedback. I really appreciate it.

I do have experience with using plug-in but not with script engines. In my opinion, enabling plugin or full scripting engines can be a high security risk. I think about people providing plug-ins that unsuspecting users could execute.

You are right about the \n issue. This is a limitation: you cannot run a commands with the following syntax:

compress.exe output.zip [file1] [file2] [file3] [file4] [file5] [file6] [file7]

I also had this problem in mind. The feature to support multiple files was implemented to easily paste the selected files to notepad or other text file editor to create lists, or batch files that would be manually modified by someone.

To workaround this I though of creating a <replace> action. This would allow replacing characters by others. Something along the lines of the following:

<replace text="${selection.path}" propertyout="myvariable" old="\n" new=" "/>

This does not solve problem about the paths with spaces that needs to be wrapped in double quotes...

Do you think this could be solved using a regular expression? If not, then you could use something like the following to force double quotes wrapping around each file (even the ones with no spaces in it):

<!-- replace \n entries with spaces and inserting double quotes between each files -->
<replace text="${selection.path}" propertyout="temp1" old="\n" new="&quot; &quot;"/>

<!-- wrap all files (the entire list) with double quotes -->
<property name="temp2" value="&quot;${temp1}&quot;" />

Please tell me what you think about the <replace> action.

Now about WinRar. I do not use WinRar myself. I am not certain about what you mean by "it can judge visibility according to the actual file type":

1. When you say that, do you mean "Windows File Type"? Like when you switch Windows Explorer to Details view and you see that *.xml files are "XML Document", *.bat are "Windows Batch File" and *.dll are "Application Extension"? If this is what you mean then no ShellAnything do not currently support this feature but we could simply implement a filetype attribute in the <visibility> or <validity> xml nodes.
2. But if you mean that WinRar's is actually looking at the file's content and is looking for something like a "rar file header" then no, ShellAnything do not currently support this feature. I do not plan to implement a feature that "reads" the first bytes of each selected files when you right click something. This would slow down the process and increase the time it takes to get the explorer's popup menu.

With this said, I am open to suggestions or push request. Can you propose a solution?

[Cirn09]

Thank you for your reply, I really appreciate it too.

First, for the \n problem, I think the solution of <replace> is not good enough, maybe you can add the variable selection.multi.separator (default is \n) as the separator character instead of fixed as \n.
For example:

<property name="selection.multi.separator" value="&quot;, &quot;" />
<property name="temp" value="[&quot;${selection.filename}&quot;]" />

The value of "temp" will be like ["file1", "file2", "filename with space", ...]
ps: My English is poor, Maybe you should give it a better name.

Second, I have many ideas for "complex visibility judgment", not only based on the judgment of the actual type of the file, but also based on the path, time, and even such weird logic like when select three folders and a zip file. In order to achieve these strange judgments, plug-in support is necessary.

Plug-in support also allows us to implement more cool features, such as providing users with more runtime variables(like selection.custom_format_filename) and providing new xml element and attribute (the <clipboard> action and <message> action could be implemented as plug-in.) and so on.
For security issues, I think that should be the responsibility of the plug-in developer and the user. The user should determine whether it is safe to run "ShellAnything" or "She11Anything" on the computer.

By the way, most decompression software (such as Winrar, 7zip, bandizip) supports the function of judging whether it is a compressed file based on the file header, and I don't feel any performance loss. Performance issues should be considered by plugin developers.

[end2endzone]

Using <property name="selection.multi.separator" value="&quot;, &quot;" /> to solve the \n problem is a very clever idea. However, it needs some refinement. I have created issue #52 for this specific problem and I leave this issue for plug-in specific discussion. @Cirn09, please create a comment in issue #52 so that it can be assigned to you.

You are right about 7-zip. I created foo.7z which I renamed foo.aaa. When I right-click on foo.aaa, 7-zip context menu is still proposing to "extract the content". I did not know that. It also means that I was wrong about the performance loss.

Regarding plug-ins, I am still uncertain. Don't get me wrong, I am not against the idea. As you said, it would open up many new possibilities.

However, I do have some concerns. For example:

1. Part of the private implementation would have to be moved to the public ShellAnything library. For example, the PropertyManager will have to be moved as it is private right now. To prevent to many dependencies, we may have to create a specific API for ShellAnything.
2. We will need multiple different interfaces for plugins. To solve the "visibility" issue by (for instance) peeking into the first bytes of the selected files, we will need something like a IValidatorPlugin which will also implement the Validator class (or it will provide an instance of Validator to the system through a function call).
3. To allow custom plugins for <clipboard> and <message> actions, we will need another type of plugin (for example IActionPlugin that would also implement the Action class or provide an instance of Action to the system through a function call) but more importantly we will need a way for the plugins to have access to configuration files so that it could parse the XML file. I don't like this. I know there are ways around this like converting unknown xml tags to text and having the plugin parse the XML from the giving text string.
4. Having plugins means that some dependencies used by ShellAnything (like TinyXML) may also need to be shared to plugins. I have seen many projects that went to a dependency nightmare when it is time to upgrade a version as plugins also have to upgrade to keep the system stable.
5. If we allow plugins, then other developers might develop nice plugins with cool and useful functionalities in their own Github but since the plugin and ShellAnything will be hosted at two different locations, users might get confused when they read about the <database> action (assuming a database plugin) which is unknow to ShellAnything. Don't get me wrong, I do not wish to "keep the control" of the development or something like that but I wish that ShellAnything and other related development should be keep in the same location.

For theses reasons, I am more a "let's define many other types of xml Validator directly in ShellAnything" kind of guy.

Again, I am not against the idea. It's just that I would like to know your point of view on how you think we should implement plugin support in ShellAnything.

Antoine

[end2endzone]

Maybe we should define multiple plugin interfaces and have them referenced like the following:

  <menu name="foo">
    <!-- bar.dll implements interface IValidatorPlugin interface. -->
    <!-- This plugin design implementation prevents plugins to register themselve to the 
    system as `Validator`. It is the system that uses the plugin, not the other way around. -->
    <visibility plugin="bar.dll" />

    <!-- fooicon.dll implements interface IIconPlugin interface. -->
    <icon plugin="fooicon.dll" />
    <actions>
      <!-- A custom email plugin action for sending emails -->
      <!-- email.dll must register itself to the system as the <email> `Action`.
      Parsing custom xml may be difficult of complex -->
      <email subject="bar" content="foo bar baz ${selection.path}" />
      <exec path="foo.exe" arguments="${selection.path}" />
    </actions>
  </menu>

I like the first 2 usage as this keep ShellAnything pretty much independent. I don't really like the <email> custom actions that much.

I hope you get my point.
Looking forward for your feedback and ideas.

Edit:
If someone have a special need for a custom <email> action, then it could also program email.exe and have <exec> call it which defy the purpose of the email plugin.

[Cirn09]

The workflow of ShellAnything includes judging visibility, setting menu format, and making actions after click.

Judging the visibility is suitable for plug-in expansion, I have already explained the reason above.

The setting menu format is also suitable, such as judging the file type to determine the icon and name, or displaying different title at different times.

After solving the \n problem, the <action> may not need plug-in support. Like the email example you gave, they can all be implemented through MyProgram.exe.

---

After thinking about the scope of the plugin, I found that there is no need to allow the plugin to add new xml elements.

First consider the plugin that extend the function of <visibility>, it can be achieved by adding new attributes to <visibility> or provide new property.
for example about new attributes, the time.dll plugin provides the function of judging visibility according to time. It provide two attributes named "start_time" and "end_time".

<visibility plugin="time.dll" start_time="08:00" end_time="16:00"/>

this example mean menu will visible when current time between 08:00 and 16:00.

and then why not move plugin="time.dll" to other place make all the attributes of <visibility> is condition, like this:

<plugins>
   <plugin path="C:\time.dll" condition="start_time;end_time" />
</plugins>
<menu name="example">
   <visibility start_time="08:00" end_time="16:00"/>
</menu>

and this change also make it possible to combine different plugins into one statement.

and here is other example about new property:

<plugins>
    <plugin path="C:\time.dll" property="time.is_daytime" />
</plugins>
<menu name="example2">
    <visibility property="time.is_daytime"/>
</menu>

I used to think it was difficult to realize the logic of visibility judgment through xml, but now I suddenly thought of a way. Multiple visibility elements can be written at the same level, the attributes under the same element is the relationship of logical AND, and the relationship between different elements is the logical OR,
E.g:

<visibility start_time="08:00" end_time="10:00"/>
<visibility start_time="14:00" end_time="16:00"/>

it mean visible when 08:00<current_time<10:00 or 14:00<current_time<16:00

then consider the plugin which extend the function of setting menu format, it only needs to provide new property.
for instance:

<plugins>
    <plugin path="C:\time.dll" property="time.now;time.icon_now" />
</plugins>
<menu name="now is ${time.now}">
    <icon path="${time.icon_now}">
    <!-- or <icon file="${time.icon_now_content}">,
    time.icon_now_content is byte data of icon file -->
</menu>

In the end, we just need IValidatorAttribute and IProperty (Maybe you should give them a better name). <clipboard> or <email> can achieve by external programe.
I have no idea to how to solve dependency nightmare, just hope plugin developers use less dependency.

These are my personal opinions. Looking forward for your review.

final version example:

<plugins>
    <plugin path="C:\time.dll" condition="start_time;end_time" property="time.now;time.icon_now;time.is_daytime" />
</plugins>
<menu name="now is ${time.now}">
    <icon path="${time.icon_now}">
    <!-- or <icon file="${time.icon_now_content}">,
    time.icon_now_content is byte data of icon file -->
    <visibility property="time.is_daytime"/>
</menu>
<menu name="example">
    <visibility start_time="08:00" end_time="10:00"/>
    <visibility start_time="14:00" end_time="16:00"/>
</menu>

Edit:
namespace? like this:

...
<plugin path="C:\time.dll" namespace="time" condition="start;end" property="icon_now" />
...
<icon path="${time.icon_now}">
<visibility time_start="08:00" time_end="16:00"/>
...

[end2endzone]

That's a lot of information to process in a single post.

About namespaces:
I do not think it is necessary. Users can always use a unique prefix for all properties related to a single plugin/module/functionality to group them under the same "namespace". For example: time.start or even myplugin.time.start to get a greater scope.

Regarding having multiple <visibility> or <validity> elements:
The feature is not currently supported by ShellAnything. I think it is a good idea but it should be a matter discussed in its own issue. IMHO, this feature should be implemented without plugin support. In other words, it should be a native functionality of ShellAnything. Please create a new issue about supporting multiple <visibility> or <validity> elements. Also, I do agree about the following:

Multiple visibility elements can be written at the same level, the attributes under the same element is the relationship of logical AND, and the relationship between different elements is the logical OR,

Edit: Multiple <visibility> or <validity> elements is discussed in #53.

Regarding plugins that set properties:
Looking at your final version example (above), I see that time.dll plugin would be able to set the following properties time.now, time.icon_now and time.is_daytime. As far as I understand, the names of each properties do not have to be specified in the xml. I do not think ShellAnything "needs" to know about these properties by reading the property attribute. What was you intention? Is it part of user documentation like for informing the user that this plugin defines these properties so that he can use them? If I am wrong, please clarify.
Note: I have removed property attribute from final example. If I am wrong feel free to add them back.

I am also puzzled by the condition="start_time;end_time" for the same reason. I mean, if I change it for condition="begin_time;end_time", the plugin won't be looking for the new begin_time attribute in the <visibility> element right? The code in time.dll still haven't changed and will still be looking for start_time and end_time attributes. Could we remove them completely? (unless they are ) Again, please clarify.

Visibility plugins:
We need to have an interface for validating. For this to work, I think that Validator class should be renamed as BaseValidator and the interface IValidator should be created like so:

  class IValidator
  {
  public:
    virtual ~IValidator() {}

    /// <summary>
    /// Validate the given context against a set of constraints.
    /// The possible constraints includes a minimum/maximum number of files/directories selected,
    /// a list of properties that must be defined,
    /// a list of file extensions,
    /// ...
    /// Note: this function is used to enable or disable a menu.
    /// </summary>
    virtual bool Validate(const Context & iContext) const = 0;
  };

Also, the Menu class holds a single Validator for visibility and a single Validator for validity. A Validator instance is assigned to a Menu by copy. I appreciate this design and would like to keep it that way. This means that a IValidator pointer cannot be assigned to a Menu and still be independent of the plugin. This is a problem. You cannot unload the plugin dll without clearing up all menus.

This is why I was proposing to use <visibility plugin="time.dll" start_time="08:00" end_time="16:00"/> (with the plugin attribute). This way, the plugin's path can be kept in BaseValidator class as a member. The custom attributes names (like start_time and end_time) could be provided by the plugin (see GetCustomAttributeName() function below) at the time of xml parsing and also be kept in the BaseValidator as "key and value" pairs. The key/value pairs are given back to the plugin at the validation time with the SetCustomAttributes() function. It would also support Validator to be passed by copy.

If we choose to use your proposed design, then we need a clear way to link a <visibility> element with its matching plugin. Maybe an id attribute or the plugin attribute:

<plugins>
   <plugin path="C:\time.dll" id="1" condition="start_time;end_time" />
</plugins>
<menu name="example">
   <visibility id="1" plugin="C:\time.dll" start_time="08:00" end_time="16:00"/>
</menu>

(in this example, I used both id and plugin attributes but like I said, only one is required. I prefer the plugin attribute)

Here is my final version of the xml configuration:

<plugins>
    <plugin path="C:\time.dll" description="This is a visibility plugin. It allow validating a menu at a specific time of the day. It requires 'start_time' and 'end_time' attributes." />
</plugins>
<menu name="example">
    <visibility plugin="C:\time.dll" start_time="08:00" end_time="10:00"/>
</menu>

With this setup, the condition attribute seems to be redundant.

Interfaces could be looking like this (note: this is a first draft version):

class IVisibilityPlugin : public : IValidator {
public:
  virtual bool Validate(const Context & iContext) const = 0;
  virtual int GetNumCustomAttributes() const = 0; //returns 2
  virtual const char * GetCustomAttributeName(int index) const = 0; //returns `start_time` or `end_time`.

  struct PluginAttribute {
    const char * name;
    const char * value;
  };
  virtual void SetCustomAttributes(const PluginAttribute * attributes, size_t num_attributes) = 0;
};
class IPlugin {
public:
  // Provides a unique name (for logs).
  virtual const char * GetPluginName() const = 0;

  // Tell the plugin that it is time to update its properties.
  // The plugin will eventually have access to the PropertyManager for C.R.U.D. operations.
  // or maybe with Context. I am not sure. The plugin could have access to selected files and directories using the property system.
  virtual void UpdateProperties() = 0;
  //virtual void UpdateProperties(const Context & c) = 0;
};

Looking forward for your reply and improvements.

[Cirn09]

Imagine a situation need combine multiple plugins.
For instance, I want to make the menu visible when the selected file type is zip and it is currently daytime. time.dll provides time judgment, and file_type.dll provides judgment of the true type of the file.
the xml file is as follows

<plugins>
    <plugin path="C:\time.dll" description="It allow validating a menu at a specific time of the day. It offer 'start_time' and 'end_time' attributes." />
    <plugin path="C:\file_type.dll" description="It allow validating a menu when select a special type file. It offer 'real_file_type' attribute." />
</plugins>
<menu name="example">
    <visibility plugin="C:\time.dll ${separator} C:\file_type.dll" start_time="08:00" end_time="16:00" real_file_type="zip"/>
</menu>

a little more complicated：

<menu name="example">
    <visibility plugin="C:\time.dll ${separator} C:\file_type.dll" start_time="08:00" end_time="16:00" real_file_type="zip"/>
    <visibility plugin="C:\time.dll ${separator} C:\file_type.dll" start_time="18:00" end_time="23:00" real_file_type="rar"/>
</menu">

It doesn't look very good, if it is this form：

<plugins>
    <plugin path="C:\time.dll" condition="start_time;end_time" description="..." />
    <plugin path="C:\file_type.dll" condition="real_file_type" description="..." />
</plugins>
<menu name="example">
    <visibility start_time="08:00" end_time="16:00" real_file_type="zip"/>
    <visibility start_time="18:00" end_time="23:00" real_file_type="rar"/>
</menu>

I think this version is better than the previous version. Users also can quickly know which plugin is processing a certain attributes through the xml file. I haven’t read the ShellAnything source code, and I don’t know why you tend to first one.

My idea is registering the plugin and its attributes and properties when parsing <plugins> element, and ask the plugin for the value when parsing the corresponding attributes under <visibility>.

Taking the above example as an example, if the current time is 19:00 and i selected a file foo.rar. So ShellAnything ask time.dll for start_time="08:00" first, and it's true. Then ask time.dll for end_time="16:00", it's false, so last condition is not necessary. Then next <visibility>, the results of the three condition are true, so menu is visible.

According to this idea, the interface should be designed like this:

class IVisibilityPlugin : public : IValidator {
public:
  struct Attribute {
    const char * name;
    const char * value;
  };
  // Verify that the plugin handle this attribute or not
  virtual bool isValidibleAttribute(const char * name) const = 0;
  // once only given one attribute key/value pair
  virtual bool Validate(const Context & iContext, const Attribute * attribute) const = 0;

  /* maybe will not use
  virtual int GetNumCustomAttributes() const = 0; //returns 2
  virtual const char * GetCustomAttributeName(int index) const = 0; //returns `start_time` or `end_time`.
  virtual void SetCustomAttributes(const PluginAttribute * attribute, size_t num_attributes) = 0;
  */
};
class IPlugin {
public:
  // Provides a unique name (for logs).
  virtual const char * GetPluginName() const = 0;
  
  enum PropertyType
  {
      NotPrivode = 0,
      Static,
      Dynamic
  }
  
  // Verify that the plugin offer this Property or not, and which type.
  virtual PropertyType GetPropertyType(const char * name) const = 0;
  
  // Static Property, only set once when plugin load
  virtual string GetStaticProperty(const Context & c, const char * name) const = 0;
  // Dynamic Property, ask each time when meet
  virtual string GetDynamicProperty(const Context & c, const char * name) const = 0;
};

saying again, I have not read the source code and not very well at C++, if this idea is difficult to achieve or I am wrong, please clarify.
Looking forward for your review.

[end2endzone]

Please don't feel bad about my questions about how you see things about this design. I want to make sure we understand each other's point of view before we move on with a plugin design that we will have to stick to for a long time.

Ok, I agree with your proposition, we will go with something similar as this configuration file:

<plugins>
    <plugin path="C:\time.dll" condition="start_time;end_time" description="..." />
    <plugin path="C:\file_type.dll" condition="real_file_type" description="..." />
</plugins>
<menu name="example">
    <visibility start_time="08:00" end_time="16:00" real_file_type="zip"/>
    <visibility start_time="18:00" end_time="23:00" real_file_type="rar"/>
</menu>

(see below the custom_attributes exception)

Please clarify this point: What happens if someone renames the attributes start_time to time1 and end_time to time2 in the xml without changing time.dll? Will time.dll still work? In other words, who owns the attribute names. Is it the xml file or time.dll? If its time.dll then functions like GetNumCustomAttributes() and GetCustomAttributeName(int index) are required. The functions can also be used as "xml validation" and prevent stability issues. If its the xml that owns attribute names, then please explain how the plugin is expected to know what to do with attributes called time1 and time2 ?

I also would prefer to rename the attribute condition to custom_attributes as a plugin might define new xml attributes without using them for a condition. It is true that start_time and start_time are conditions in case of a IVisibilityPlugin but it won't be the case for all plugins or all plugin interfaces. Think for example about an IIconPlugin which might define an attribute called sgvlib for knowing the location of svg library. Or IMenuPlugin with attributes that provides menus with "checkbox" support. Those attributes are not conditions but generic xml attributes.

Functions GetNumCustomAttributes() and GetCustomAttributeName(int index) should be moved from IVisibilityPlugin to the generic IPlugin. As explain above, all plugins may define custom attributes.

For the same reason, I think all custom attributes of a plugin should be given to the plugin at the same time and not "one after the other" as you suggested. Think for example of a plugin that validates a menu if the path of the selected file contains foo, FOO or FoO. The <visibility> element would look like this:

<visibility selection_contains="foo" case_sensitive="false"/>

In this particular case, the attributes selection_contains and case_sensitive attributes must be sent to the plugins at the same time (in the same Validate(...) call) for the plugin to make an accurate check.

The function definition should then look like I suggested:

  virtual bool Validate(const Context & iContext, const Attribute * attributes, size_t num_attributes) const = 0;

Also plugins should register to a PluginManager which would be a singleton. Ownership of the plugins instances should be to the PluginManager. The class Validator may keep a pointer to a IVisibilityPlugin that is required for dealing with all the custom attributes but they may not own a plugin instance.

Also, I would also propose to rename IVisibilityPlugin to IValidatorPlugin as it is the same Validator class that handles both <visibility> and <validity> elements.

I am uncertain about isValidibleAttribute. I do not think it is English. Maybe a typo. How about IsAttributeSupported. Also use PascalCase for function names (starts with a capital letter).

Regarding plugins that provides properties:
In your latest proposed interfaces, you removed UpdateProperties() function. This function was required for plugins that sets custom properties. The idea is that ShellAnything will tell each plugins to update their dynamic properties after the user clicks on a file but before updating the menus. From what I understand of your functions, ShellAnything will ask (as opposed to tell) the plugin to provide a new value for a given property. This is very interesting as ShellAnything will not have to give access to the PropertyManager.

The function GetStaticProperty() should not be given the Context. As you proposed, static properties will be set at the plugin "load time" where a Context is not available. If a property requires a Context then it means its not a static property.

There is also another typo: NotPrivode should be NotProvided but I would prefer Unknown.

The plugin should have a functions that provides the list of supported custom properties. The property names will be used for the name argument of the GetPropertyType(), GetDynamicProperty() and GetStaticProperty() functions. I would propose the following:

  virtual int GetPropertyCount() const = 0;
  virtual const char * GetPropertyName(int index) const = 0;

We could also also rename virtual PropertyType GetPropertyType(const char * name) const = 0; to virtual PropertyType GetPropertyType(int index) const = 0; which would be faster but that is just a proposition.

Also, we must stay away from std::string (in fact, all std namespace) in a plugin interface. We must only use base types. This is for binary compatibility reasons. See https://stackoverflow.com/questions/22797418/how-do-i-safely-pass-objects-especially-stl-objects-to-and-from-a-dll and https://stackoverflow.com/questions/2740573/how-to-share-classes-between-dlls. To make a long story short, a std::string pointer instantiated by a dll compiled with VS2010 is not compatible with a VS2017 dll that uses this std::string instance. Same goes for a VS2017 debug dll that uses a std::string instanciated by a VS2017 release dll.

Interfaces should also have a forced virtual destructor. See https://softwareengineering.stackexchange.com/questions/235674/what-is-the-pattern-for-a-safe-interface-in-c.

I think that is all.

Here is an updated version of the configuration file:

<plugins>
    <plugin path="C:\time.dll" custom_attributes="start_time;end_time" description="..." />
    <plugin path="C:\file_type.dll" custom_attributes="real_file_type" description="..." />
</plugins>
<menu name="example">
    <visibility start_time="08:00" end_time="16:00" real_file_type="zip"/>
    <visibility start_time="18:00" end_time="23:00" real_file_type="rar"/>
</menu>

and the interfaces:

class IValidatorPlugin {
public:
  virtual ~IValidatorPlugin() {}

  struct Attribute {
    const char * name;
    const char * value;
  };
  
  // all attributes given at the same time
  virtual bool Validate(const Context & iContext, const Attribute * attributes, size_t num_attributes) const = 0;
};

class IPlugin {
public:
  virtual ~IPlugin() {}

  // Provides a unique name (for logs).
  virtual const char * GetPluginName() const = 0;
  
  // Verify that the plugin handle this attribute or not
  virtual bool IsSupportedAttribute(const char * name) const = 0;

  // Get the number of supported attributes
  virtual int GetCustomAttributesCount() const = 0;

  // Get the name of the supported attribute at index.
  virtual const char * GetCustomAttributeName(int index) const = 0; //returns `start_time` or `end_time`.

  enum PropertyType
  {
      NotProvided = 0, //I would prefer Unknown
      Static,
      Dynamic
  }
  
  // Verify that the plugin offer this Property or not, and which type.
  virtual PropertyType GetPropertyType(const char * name) const = 0; //here we could use 'int index' as argument for faster processing.
  
  // Static Property, only set once when plugin load
  // name is the name of the property
  // value is the new value of the property that must be set by ShellAnything.
  // value_size is the size of the value buffer in bytes.
  //note: for this one, we could do the same as win32 api: change return type to int. If value is null, then return number of bytes required for value buffer;
  virtual void GetStaticProperty(const char * name, char * value, size_t value_size) const = 0;

  // Dynamic Property, ask each time when meet
  // name is the name of the property
  // value is the new value of the property that must be set by ShellAnything.
  // value_size is the size of the value buffer in bytes.
  //note: for this one, we could do the same as win32 api: change return type to int. If value is null, then return number of bytes required for value buffer;
  virtual void GetDynamicProperty(const Context & c, const char * name, char * value, size_t value_size) const = 0;

  // Get the number of supported properties
  virtual int GetPropertyCount() const = 0;

  // Get the name of the supported property at index.
  virtual const char * GetPropertyName(int index) const = 0;
};

[end2endzone]

I also forget to mention the following api are also possible for a good memory management:

  struct StringHandle {
    const char * value;
  };

  // GetDynamicProperty allocate the required memory for the output variable
  // and store its pointer in the returned StringHandle (similar to win32 HANDLE struct)
  virtual StringHandle GetDynamicProperty(const Context & c) const = 0;

  // Delete the allocated buffer in StringHandle::value;
  virtual void DestroyStringHandle(StringHandle * handle);

[Cirn09]

Perfect, I can't find any flaws.

[end2endzone]

Good. I see that you did not create a fork of ShellAnything. Would you like to contribute to the project? If so, please add a comment in the issues you would like to work on. I also cannot assign you an issue if you did not post at least once.