<blockquote>
<p>My first thought was to use GTK signals, its probably not appropriate to have a signal for each feature for each language, but it is possible for there to be one signal per feature and the plugin callbacks then need to check the filetype of the current document and return false if its not one they handle, so the next plugin callback can be invoked</p>
</blockquote>
<p>Signals are a good start, but maybe too heavy-weight for the purpose.</p>
<p>I'd rather like to see interfaces (GObject-based) to be used. They are as powerful (if not more, since you can attach data with instances), but also allow for potential adoption of libpeas (in a future far away) which uses interfaces as natural extension points.</p>
<p>In some way, libpeas solves already exactly what we want here: plugins can extend or replace core functionality by implementing interfaces, which are registered in the core application and then instantiated when necessary. Because of this, our design should be compatible with that.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/geany/geany/issues/1458#issuecomment-294320018">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABDrJ-rLxqKQX9OQUaZZ5ehf4vWbOpWJks5rwTyJgaJpZM4M1Ajm">mute the thread</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/ABDrJ-aFIiRyHSqydqKJmk8TvOd9LVcTks5rwTyJgaJpZM4M1Ajm.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
<div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
  <link itemprop="url" href="https://github.com/geany/geany/issues/1458#issuecomment-294320018"></link>
  <meta itemprop="name" content="View Issue"></meta>
</div>
<meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>

<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/geany/geany","title":"geany/geany","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/geany/geany"}},"updates":{"snippets":[{"icon":"PERSON","message":"@kugel- in #1458: \u003e My first thought was to use GTK signals, its probably not appropriate to have a signal for each feature for each language, but it is possible for there to be one signal per feature and the plugin callbacks then need to check the filetype of the current document and return false if its not one they handle, so the next plugin callback can be invoked\r\n\r\nSignals are a good start, but maybe too heavy-weight for the purpose.\r\n\r\nI'd rather like to see interfaces (GObject-based) to be used. They are as powerful (if not more, since you can attach data with instances), but also allow for potential adoption of libpeas (in a future far away) which uses interfaces as natural extension points.\r\n\r\nIn some way, libpeas solves already exactly what we want here: plugins can extend or replace core functionality by implementing interfaces, which are registered in the core application and then instantiated when necessary. Because of this, our design should be compatible with that."}],"action":{"name":"View Issue","url":"https://github.com/geany/geany/issues/1458#issuecomment-294320018"}}}</script>