Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Dinu SV
    @dinusv
    You kind of need cross-plugin communication
    Fredo Erxleben
    @fer-rum
    What comes to mind is: A plugin provides a fixed set of functionality. The application then brokers between plugins, offering the communication infrastructure and things like rendering
    A plugin then must be able to advertise the functions it is able to execute so another plugin can discover this and come along and say "Hey, run this function please"
    (On the other hand: The QML you write in the editor does exactly this brokering, doesn't it?)
    Dinu SV
    @dinusv
    exactly
    on top of that, I think it got the versioning figured out
    you can have: lcvcore and lcvcore2 folders
    if you import lcvcore 2.0, it will first look into lcvcore2 folder
    so then, if you have a plugin that depends on lcvcore 1.0, it will require you to import it
    so if you import lcvcore 2.0, and use its types with a plugin meant for lcvcore 1.0 , it won't accept them
    Fredo Erxleben
    @fer-rum
    And if one plugin refines the functionality of another plugin (like in your filter example) the 'base' plugin would have to expose the functionality as a library, so the 'refining' plugin can include and build on it.
    Dinu SV
    @dinusv
    yea, that right
    thats*
    Fredo Erxleben
    @fer-rum
    From the viewpoint of the application it would look like two different filter implementations and the application does neither know nor care if the plugins share some libraries amongst each other
    Note that the version checking would only work with respect to QML plugins, not neccessary QPlugin classes.
    Actually… are those two mechanisms compatible or will mixing them lead to chaos?
    Dinu SV
    @dinusv
    Why would you mix them?
    The version checking is done when looking up the qmldir file
    Then it's done only after the loading, when exposing the types to the qml meta's system
    Fredo Erxleben
    @fer-rum
    QML plugins only handle the QML afaik(?), you have to load required C++ background libraries separately(?)
    Dinu SV
    @dinusv
    They are loaded as well
    Fredo Erxleben
    @fer-rum
    (I only have experience with the reverse approach: Create a C++ plugin that then infects QML code into the QMLApplicationEngine)
    *injects
    Dinu SV
    @dinusv
    I see, that's not standard
    Fredo Erxleben
    @fer-rum
    According to which standard?
    section: Accessing Loaded QML Objects by Object Name
    Fredo Erxleben
    @fer-rum
    Ah, no. There were no QML objects manipulated from C++ code (beyond the usual). There were a bunch of C++ plugins. And sone used their interface to tell the application "Here are my QML files". And the application triggered the QMLApplicationEngine to please additionally load these QML files, which it then did.
    Dinu SV
    @dinusv
    Ah, i see
    Yea, the approach here is a bit different, basically a qmlplugin can add C++ types, this is how i register lcvcore's types to Live CV
    the void LcvcorePlugin::registerTypes(const char *uri) get's called automatically when the plugin is loaded
    Fredo Erxleben
    @fer-rum
    Maybe one can combine these two approaches. That would allow for plugins that do not provide QML but pure functionality.
    Dinu SV
    @dinusv
    behind the scenes I think the QPlugin and QPluginLoader are used
    You can anyway
    simply don't add any qml files to your qmldir file
    just the plugin itself
    Fredo Erxleben
    @fer-rum
    thats a point.
    Dinu SV
    @dinusv
    Fredo Erxleben
    @fer-rum
    How exactly does the plugin announce, which functionality it can fulfil?
    Dinu SV
    @dinusv
    what do you mean by functionality? you mean it's types?
    Fredo Erxleben
    @fer-rum
    Assume a plugin offers the function int computeFoo(int x, float y) how does the application know about it? As far as I understand, all you offer is a bunch of QML types.
    Do you have to share a library or can you just wrap the function in an QML type and register that?
    Dinu SV
    @dinusv
    I think you can only share types
    so you have to wrap the function in a type then
    I don't think you can expose static functions either
    So if you want to just have a function, you need a singleton type with that function (you can register singleton types and add them to the engine)
    Fredo Erxleben
    @fer-rum
    Looks feasible.
    Well that gives me enough to think about for the weekend. I will be off for now. Have a nice day/evening/morning/night (whatever applies :smile: )
    Dinu SV
    @dinusv
    Thanks, same to you!
    Hasan Emre Kırmızı
    @emrekirmizi
    Hi to all!