No way to write the plugins using a managed-code language like C#? Seems like the ability would vastly improve the language base. I have done CPP code but lately I do everything in Java or C#. It could easily open it up to people to code plugins in VB.NET, Python.net, etc, it seems.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you would like to extend Launchy to another language then I recommend creating a language proxy plugin like so..
For instance, let's say you want to add python support:
Create a c++ plugin for Launchy (called the proxy plugin) that loads up all of the python scripts in the plugin directory.
Then, any time an event occurs the c++ plugin forwards the request to the required python script.
Such a proxy plugin could be made for any language such as C#.
For future versions of Launchy I'm thinking about supporting python for scripting since I don't want to have to compile the plugins for each platform that Launchy supports.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-08-11
I tried to start writing a language proxy plugin and stopped when I realized what the end product would look like.
Unmanaged C++ "regular" Launchy plugin that loads a...
-> Managed C++ Launchy plugin that loads the...
-> C# plugins that implement the...
-> ILaunchyPlugin .NET interface created by whoever ends up making this language proxy plugin. :)
I think it's also possible to do it with COM Interop but that route left me even more confused than the managed wrapper.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to take a crack at managed code support, but I don't see how the language proxy would work. The architecture assumes that each dll provides exactly one plugin, so it's hard to see how a proxy for multiple plugins would route requests. For example, how would the suggested Python proxy know which script should handle a call to PluginGetName?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2007-12-05
I figured that you'd always lose a little bit of detail for things like PluginGetName (or you could return a concatenated list).
You could also return something like "Managed Plugin Loader (5 plugins loaded)"?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I would think it would be possible to create .Net plugins for Launchy. It's possible for unmanaged code to call managed dlls. I'm currently working on a plugin for Snarl, which is unmanaged. The C# code simply exposes the correct interfaces. It would be super awesome to be able to do that here. I would much rather do this in .Net because I'm not getting any C++ help here! ;) I can't even get the default plugin demo project to work. Don't know what's up with that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No way to write the plugins using a managed-code language like C#? Seems like the ability would vastly improve the language base. I have done CPP code but lately I do everything in Java or C#. It could easily open it up to people to code plugins in VB.NET, Python.net, etc, it seems.
If you would like to extend Launchy to another language then I recommend creating a language proxy plugin like so..
For instance, let's say you want to add python support:
Create a c++ plugin for Launchy (called the proxy plugin) that loads up all of the python scripts in the plugin directory.
Then, any time an event occurs the c++ plugin forwards the request to the required python script.
Such a proxy plugin could be made for any language such as C#.
For future versions of Launchy I'm thinking about supporting python for scripting since I don't want to have to compile the plugins for each platform that Launchy supports.
I tried to start writing a language proxy plugin and stopped when I realized what the end product would look like.
Unmanaged C++ "regular" Launchy plugin that loads a...
-> Managed C++ Launchy plugin that loads the...
-> C# plugins that implement the...
-> ILaunchyPlugin .NET interface created by whoever ends up making this language proxy plugin. :)
I think it's also possible to do it with COM Interop but that route left me even more confused than the managed wrapper.
I'd like to take a crack at managed code support, but I don't see how the language proxy would work. The architecture assumes that each dll provides exactly one plugin, so it's hard to see how a proxy for multiple plugins would route requests. For example, how would the suggested Python proxy know which script should handle a call to PluginGetName?
I figured that you'd always lose a little bit of detail for things like PluginGetName (or you could return a concatenated list).
You could also return something like "Managed Plugin Loader (5 plugins loaded)"?
I would think it would be possible to create .Net plugins for Launchy. It's possible for unmanaged code to call managed dlls. I'm currently working on a plugin for Snarl, which is unmanaged. The C# code simply exposes the correct interfaces. It would be super awesome to be able to do that here. I would much rather do this in .Net because I'm not getting any C++ help here! ;) I can't even get the default plugin demo project to work. Don't know what's up with that.