Page 1 of 5 123 ... LastLast
Results 1 to 10 of 43

Thread: Plugin Interface

  1. #1
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,541

    Default Plugin Interface

    Dear plugin developers,

    As you might know I'm currently working on Girder 3.2, more specifically the plugin mechanism. The current way of doing things with plugins is getting old and messy, updating it is prooving to be a major headache with lots of traps and problems. I am in favour of completely redesigning the structure. This redesign will be in such a way that you can easily modify your current plugins to the new architecture.

    The major goal of the redesign is 1 plugin type that can serve as an event generator and receiver ( hardware plugin / event plugin ). For the major part this will only mean that your plugins will need a few function name changes. For the plugins that are available in source code form I offer to do this myself ( maybe with a little help of the original author ;-) )

    However I do not want to do this if there is a strong opposition to this from the developers themselfs.

    I designed the base of the current mechanism three years ago, but I never envisioned that Girder would become this popular and multifunctional. I have been able to keep it going with some minor updates but I feel the time has come to throw out the old crap and give it a fresh shine.

    I hope that you feel the same and want to spend a little time on updating your plugins!

    The first draft is here
    http://www.girder.nl/devel32/api32.php

    The new girder.h is here
    http://www.girder.nl/devel/girder.h
    Ron
    No support through PM

  2. #2
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,541

    Default proposal

    Okay here is a first draft

    (removed)

    If you have better names or suggestions share them here.
    Ron
    No support through PM

  3. #3
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,541

    Default

    Ah of course we need a learn_event export, that slipped my mind, I'll update the data above.

    I think we are pretty much stuck with device numbers, I am going to include a list in Girder so girder has a text description of a missing plugin in the future. What is the drawback of plugin numbers ? ( aside from a limited number ( well limited ;-) )

    I'm not sure we should do away with most exports except for info_plugin, I use them to determine what kind of plugin it is. e.g. I use it to determine if it should appear on the plugin list for the commands. Of course there are other ways to determine this... not sure about this, let me sleep about that :-)

    About the gui thing indeed this one doesn't need the pointer to the command structure, as long as it has been updated before the GUI is called of course.
    Ron
    No support through PM

  4. #4
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,541

    Default

    As a side note, if there are binary only plugins that I/we cannot retrace the author of I could think about a wrapper .dll to load the old plugins.

    A second tool that we also need is a gml devicenumber actionid translator.
    Ron
    No support through PM

  5. #5
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,541

    Default

    Okay here is draft 2 of the API. I have not done any coding with this so anyone feel free to suggest changes.
    (removed)
    Ron
    No support through PM

  6. #6
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,541

    Default

    Actually trigger command should not allow for the payload. The payload is something that travels through girder along with an event. The payload persists until the event has ended, thus if a plugin uses trigger_command from the correct thread Girder will still have the original payload that came along with the event that triggered the plugin. ( is this clear ?)

    If you want to send a modified payload the plugin will have to send an event.

    I was going to assign new plugin ids because we now have overlapping hardware and action id's. Thus we need a tool that translates our existing .gml files to the new numbers. Preventing people from having to relearn all the events affected and the action plugins that are affected.
    Ron
    No support through PM

  7. #7
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,541

    Default

    The conversion is coming along pretty fine, the UIR plugin is already working. One thing though, the keyboard plugin, or any plugin that uses Hooks is gonna be problematic the hook is called into the context of the foreground application, so the plugin cannot directly call Girder through send_event . No fair! I really want to kick the windows messages out of Girder, lets see how I can work around this.
    Ron
    No support through PM

  8. #8
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,541

    Default

    Ah but suggestion are always welcome :-)

    About the context problem, I was indeed leaning towards fixing this inside the plugin instead of from within Girder.

    I've got the new system implemented for 99% now. Its working _very_ smoothly ( al least for completely new code i'm getting no crashes, I'm amazed :P ) I started around 1pm today its now 11 pm, that is a 10 hour straight coding session :roll: The new code feels and looks good, I'm going to make a few more modifications to the naming of the API tomorrow but overall I'm pretty happy with things as they are. I can also report that porting the plugins is a breeze. I hope to release a new snapshot/alpha release later this weekend.
    Ron
    No support through PM

  9. #9
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,541

    Default

    I've updated the API draft. If anyone thinks his favourite function/feature is missing speak up now.

    (removed)
    Ron
    No support through PM

  10. #10
    Join Date
    Jan 1998
    Location
    Jupiter, FL
    Posts
    13,541

    Default

    Thanks its corrected

    Draft 6 of the API is here

    (removed)

    the sparkling new header file is here

    (removed)
    Ron
    No support through PM

Page 1 of 5 123 ... LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •