Copypaste integration
Brought to you by:
gsaurus
Menu
▾
▴
#5 Copypaste integration
Hello!
I come from a GitHub mirror where a dev kindly reffered me here. :)
I would like to use Pluma, but have a few question regarding its usage. As a reference, I want to use Pluma in this project: https://github.com/IngwiePhoenix/IceTea
So first off, I would like to know if it is possible to define internal modules. For instance, I would like to have a way with which I could define built-in plugins as well. Currently, if you go to src/, you'll see a few files such as Plugin and PluginStore. Those are my hacky attempts of building this ^^;. But I can tell from far away that this is only a temporary solution... So I would like to know if I could use Pluma to define built-in plugins?
Then, about #include. It seems that even private headers within src/Pluma/ are refferenced with <Pluma/...> paths. This is actually not required, since compilers resolve headers relative to the file. So in fact, it would be nicer to change <Pluma/Dir.hpp> to "Dir.hpp" - and why is it important? Well...
The main goal of my tool is to be so small, that you can build it with a single, simple command. It is a built tool, and it shouldnt be hard to build a build tool - at least, I think so. So currently, on Linux, all you do is g++ src/*.cpp -o icetea and you're good to go. In order for me to use Pluma in this, I would have to add a lot of include flags. Assuming I copied Pluma into my project as-is, the command would change to: g++ src/*.cpp src/Pluma/*.cpp -Isrc -o icetea. So this is a bit off. Not a dramatic problem, but it'd be nice to keep things as simple as it gets. I might actually fork Pluma for that purpose...
Then, how can I include a simple module? The scripting language can be extended to change it's functionality, so I would like to add a function to load a simple shared library/object. In the examples, Pluma seems to search one folder, and one folder only, and always returns a list. How can I do just a single file?
For that, let's assume that the root plugin class is IceTeaPlugin, the extension .nit (Native IceTea) and the script calling like so:
var utils = require "tools/utils"; // ./.IceTea/tools/utils.it
var packageManager require.native "tools/pkm"; // ./.IceTea/tools/pkm.nit
What would my C++ code look like to load a single plugin? I can access the string argument passed to the function as char*.
Would be nice to hear back!
Kind regards,
Ingwie
Hello Ingwie,
Pluma supports built-in modules, adding a provider directly to the manager. Check the final notes of the tutorial:
http://pluma-framework.sourceforge.net/?page_id=113
You can load a single plugin using the load function:
http://pluma-framework.sourceforge.net/documentation/classpluma_1_1PluginManager.htm#aa00400d23efa8a8f94e44dd1c5bf54e6
You are right about the includes, feel free to modify it to better fit your needs.
Cheers,
Gil
Hey!
I have done my little bit of re-structureing and alike and implemented a little fix:
On Mac OS X, "dylib" refers to a library, whilst a "bundle" is treatened as a plugin. Technically they are the same - both are dynamic loadable libraries in the end - but they are built a bit differently, and it also adheres more to the terminology.
Check out the commits on my fork, when you feel like it.
Direct mirror: https://github.com/IngwiePhoenix/pluma
Modified source: https://github.com/IngwiePhoenix/pluma-modified
The modified sourcetree is oriented towards my use case. I found the "load" function and I like how that one works. Will it let me supply the full path, even if the extension is a different one? For instance if I wanted to use
.itn(IceTea Native) for native plugins? I will read more into it, but it'd be nice to know a bit more about what I can do! ^^Kind regards,
Ingwie