<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    Thanks.  I didn't realize this.  If you have a chance, maybe you
    could spot check my plugins:<br>
    <blockquote><a href="https://github.com/sblatnick/geany-plugins">https://github.com/sblatnick/geany-plugins</a><br>
      <blockquote>quick-* plugins<br>
        external-tools<br>
        tab-utils<br>
        hide-menu<br>
      </blockquote>
    </blockquote>
    I worry most of them have at non-api calls.  Is there an easy way to
    tell what is API and what is not?  I primarily had been just
    grepping the code for what I needed.<br>
    <br>
    Also, since I'm on the topic of how to write plugins currently, can
    anyone suggest a good tutorial for adding plugins to the
    geany-plugins build system?  I think that may be the biggest thing
    keeping me from adding my plugins to geany-plugins.<br>
    <br>
    I apologize if I missed replying to anyone since there have been a
    lot of emails going around about plugins and I may have missed other
    references to mine.<br>
    <br>
    Thanks,<br>
    <br>
    Steve<br>
    <br>
    <div class="moz-cite-prefix">On 03/29/2015 09:51 AM, Colomban
      Wendling wrote:<br>
    </div>
    <blockquote cite="mid:55181F67.3050704@herbesfolles.org" type="cite">
      <pre wrap="">Hi,

Le 18/03/2015 18:11, Steven Blatnick a écrit :
</pre>
      <blockquote type="cite">
        <pre wrap="">
On 03/18/2015 10:42 AM, Thomas Martitz wrote:
</pre>
        <blockquote type="cite">
          <pre wrap="">Currently geany exports a pointer to a struct, that contains more
structs, which contain function points to the API functions.
Fortunately this is nicely hidden to developers via macros. But due to
gtkbuilder all functions and nothing prevents plugins from accessing
these. And the macros are awkward and strange anyway. There is
currently the linkage-cleanup PR in the works which improves this by
actually exporting the API functions, and _only_ the API functions to
plugins. 
</pre>
        </blockquote>
        <pre wrap="">Maybe I'm completely wrong on this from an architecture perspective, but
part of what I like about writing plugins for geany is accessibility. 
If we only get access to a subset of functions, then it seems less
flexible what our plugins can actually do.  Yes, this allows us to write
bad plugins that can do some sloppy things, but I say "so what".  They
are plugins.  […]
</pre>
      </blockquote>
      <pre wrap="">
In addition to what Thomas said (which is very true), realize two things:

1) plugins that use functions not part of the API won't work e.g. on
Windows (for technical reasons, all functions are currently actually
usable under *NIX, but on Windows only explicitly exported ones are).
So if you care about your plugin working on Windows you'll stick to the
official API anyway (the one we commit to and maintain).

2) before Geany 1.22, you couldn't use non-API anyway.  If you were
happy with the API before, you'll still be after this change.

Regards,
Colomban
_______________________________________________
Devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Devel@lists.geany.org">Devel@lists.geany.org</a>
<a class="moz-txt-link-freetext" href="https://lists.geany.org/cgi-bin/mailman/listinfo/devel">https://lists.geany.org/cgi-bin/mailman/listinfo/devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>