Am 29.03.2015 um 18:19 schrieb Colomban Wendling:
So anyway, I think I'd be in favor of a failable init(), maybe like
gboolean (*init) (..., GError **error); if we want to be able to
report messages and the like. Or just let each plugin do the same
msgwing_add() or whatever, but a common integr
Am 30.03.2015 um 23:07 schrieb Thomas Martitz:
Am 30.03.2015 um 14:57 schrieb Colomban Wendling:
If `pdata` is provided in geany_plugin_register(), how does it get
released? If it has to be a pointer to static data it's a bit limiting,
and forces use of (static) globals, which is one thing tha
Am 30.03.2015 um 14:57 schrieb Colomban Wendling:
If `pdata` is provided in geany_plugin_register(), how does it get
released? If it has to be a pointer to static data it's a bit limiting,
and forces use of (static) globals, which is one thing that this new API
tries to avoid, doesn't it? We c
Re-sending as I don't see my email in
https://lists.geany.org/cgi-bin/mailman/listinfo/devel
Thanks. I didn't realize this. If you have a chance, maybe you could
spot check my plugins:
https://github.com/sblatnick/geany-plugins
quick-* plugins
external-tools
tab-uti
Thanks. I didn't realize this. If you have a chance, maybe you could
spot check my plugins:
https://github.com/sblatnick/geany-plugins
quick-* plugins
external-tools
tab-utils
hide-menu
I worry most of them have at non-api calls. Is there an easy way to
tell
Hi,
Le 30/03/2015 08:52, Thomas Martitz a écrit :
>> […]
>>
>> ```
>> struct MyRealPlugin {
>> RealPlugin parent; /* offset 0 has the Geany struct, so it's binary
>> compatible */
>> /* plugin-specific fields here */
>> int the_game;
>> };
>> ```
>
> Now this is a big methodology ch
[...]
>>> In the future geany_plugin_register should be able to be used to
>>> register plugins recursivly, by passing the appropriate GeanyPlugin
>>> pointer, i.e. plugin A should be able to call
>>> geany_plugin_register(plugin_B, ...) to realize pluxies.
>>
>> How does the proxy plugin create pl
Hi,
in the hope I answered your pluxy-related questions in the other post
I'll try to concentrate on the loader for this reply.
Am 29.03.2015 um 19:04 schrieb Colomban Wendling:
Hi,
I'm answering both to the initial mail and this one here, so expect
mixed citations. This will avoid raising
[...]
> All this said, a counter argument is that many plugins will load
> external UI for configure(), and there we have no way to fail either.
>
>
> So anyway, I think I'd be in favor of a failable init(), maybe like
>
> gboolean (*init) (..., GError **error);
>
> if we want to be able to
Hi,
I'm answering both to the initial mail and this one here, so expect
mixed citations. This will avoid raising the same points twice :)
First, stuff extracted from the first mail.
Disclaimer: Sorry if some remarks look slightly off-formulated, but
while I altered them in the light of the last
Le 26/03/2015 00:22, Thomas Martitz a écrit :
> […]
>>
>> What if instead of PluginHooks it was called `Plugin` (GeanyPlugin is
>> taken, so for this discussion I'll use `Plugin` :) and instead of just
>> the callback function pointers it contained the (possibly
>> sub-)plugin's info, like this:
>
Le 26/03/2015 00:16, Thomas Martitz a écrit :
> Am 20.03.2015 um 19:45 schrieb Dimitar Zhekov:
>>
>>>
>>> Thinking about it, if the plugin can't run because it's missing resource
>>> files required for its operation, then I think it should be treaded like
>>> incompatible plugins.
>>
>> There seem
Hi,
Le 18/03/2015 18:11, Steven Blatnick a écrit :
>
> On 03/18/2015 10:42 AM, Thomas Martitz wrote:
>> 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.
Hello,
based on the discussion I refined my proposal (see below). Additionally
I have implemented all of this, including updating demoplugin.c, see
[1]. And last but not least, I have a fully working implementation of
proxy plugins aka pluxies (in fact, I simply updated my year-old branch
to
Am 26.03.2015 um 18:47 schrieb Dimitar Zhekov:
On 26.3.2015 г. 01:16, Thomas Martitz wrote:
Now, do we really want the plugins to run arbitrary resource checking
code, and display their own error messages, only because they are
queried (or registered, as you put it), each time the list is build
On 26.3.2015 г. 01:16, Thomas Martitz wrote:
Now, do we really want the plugins to run arbitrary resource checking
code, and display their own error messages, only because they are
queried (or registered, as you put it), each time the list is build?
Yes plugins should be able to run arbitrary
On 15-03-25 04:22 PM, Thomas Martitz wrote:
Am 18.03.2015 um 22:55 schrieb Matthew Brush:
[snip]
```
static Plugin my_plugin = {
.name= "Foo",
.version = "0.1",
.author = "Me",
.description = "Foo plugin",
.api_min = 200,
.abi_ver = GEANY_ABI_VERSION,
.ini
On 15-03-25 04:22 PM, Thomas Martitz wrote:
Am 18.03.2015 um 22:55 schrieb Matthew Brush:
On 15-03-18 09:42 AM, Thomas Martitz wrote:
tl;dr <-
Key functions
gboolean geany_load_module(GeanyPlugin *, GModule *)
What is the GModule* for? Is it a .dll that Geany opened on behalf of
the plugin
Am 18.03.2015 um 22:55 schrieb Matthew Brush:
On 15-03-18 09:42 AM, Thomas Martitz wrote:
tl;dr <-
Key functions
gboolean geany_load_module(GeanyPlugin *, GModule *)
What is the GModule* for? Is it a .dll that Geany opened on behalf of
the plugin based on selection in Plugin Manager?
That
Am 20.03.2015 um 19:45 schrieb Dimitar Zhekov:
Thinking about it, if the plugin can't run because it's missing resource
files required for its operation, then I think it should be treaded like
incompatible plugins.
There seem like two different things to me.
The first thing a loader needs t
On 18.3.2015 г. 23:15, Matthew Brush wrote:
Scope contains 20 source files and 22 headers. Using static is not an
option, and marking everything global as hidden will be cumbersome,
ugly, and easy to miss (inexperienced plugin developers are sure to miss
symbols).
Why does it need so many glo
On 18.3.2015 г. 22:51, Thomas Martitz wrote:
Am 18.03.2015 um 21:23 schrieb Dimitar Zhekov:
On 18.3.2015 г. 18:42, Thomas Martitz wrote:
Do you generally like or support my proposal?
Yes, because the final goal is to be able to support different languages
with gtk+ bindings, like/with libp
On 19.3.2015 г. 00:05, Thomas Martitz wrote:
Am 18.03.2015 um 22:15 schrieb Matthew Brush:
[...]
void (*init) (GeanyPlugin *plugin, gpointer pdata);
Please make this gboolean. A plugin may have the correct API and ABI,
but be unable to startup / initialize for some reason. For example,
Scope
Am 19.03.2015 um 23:34 schrieb Lex Trotman:
On 19 March 2015 at 09:16, Thomas Martitz wrote:
There is no other way of loading C shared libraries and registering them as
plugins.
Doesn't Geany already load dlls local and extract the symbols it wants
via dlsym()?
dlsym() takes an argument of the
On 19 March 2015 at 09:16, Thomas Martitz wrote:
> Am 18.03.2015 um 22:23 schrieb Lex Trotman:
>>
>> Hi Thomas,
>>
>> In general this looks like an improvement to the current method of
>> setting up plugins, except it continues to require the plugin .so file
>> to be dlloaded just to populate the
Am 19.03.2015 um 01:19 schrieb Matthew Brush:
On 15-03-18 03:55 PM, Thomas Martitz wrote:
Am 18.03.2015 um 23:21 schrieb Matthew Brush:
On 15-03-18 03:05 PM, Thomas Martitz wrote:
Am 18.03.2015 um 22:15 schrieb Matthew Brush:
[...]
void (*init) (GeanyPlugin *plugin, gpointer pdata);
Pleas
On 15-03-18 03:55 PM, Thomas Martitz wrote:
Am 18.03.2015 um 23:21 schrieb Matthew Brush:
On 15-03-18 03:05 PM, Thomas Martitz wrote:
Am 18.03.2015 um 22:15 schrieb Matthew Brush:
[...]
void (*init) (GeanyPlugin *plugin, gpointer pdata);
Please make this gboolean. A plugin may have the cor
Am 18.03.2015 um 22:23 schrieb Lex Trotman:
Hi Thomas,
In general this looks like an improvement to the current method of
setting up plugins, except it continues to require the plugin .so file
to be dlloaded just to populate the plugin manager. That will run the
dll initialization code, and may
Am 18.03.2015 um 23:21 schrieb Matthew Brush:
On 15-03-18 03:05 PM, Thomas Martitz wrote:
Am 18.03.2015 um 22:15 schrieb Matthew Brush:
[...]
void (*init) (GeanyPlugin *plugin, gpointer pdata);
Please make this gboolean. A plugin may have the correct API and ABI,
but be unable to startup /
On 15-03-18 03:05 PM, Thomas Martitz wrote:
Am 18.03.2015 um 22:15 schrieb Matthew Brush:
[...]
void (*init) (GeanyPlugin *plugin, gpointer pdata);
Please make this gboolean. A plugin may have the correct API and ABI,
but be unable to startup / initialize for some reason. For example,
Scope
Am 18.03.2015 um 22:15 schrieb Matthew Brush:
[...]
void (*init) (GeanyPlugin *plugin, gpointer pdata);
Please make this gboolean. A plugin may have the correct API and ABI,
but be unable to startup / initialize for some reason. For example,
Scope requires scope.glade in the plugin data direc
On 15-03-18 09:42 AM, Thomas Martitz wrote:
Hello,
tl;dr -> scroll down
I am working on a new plugin architecture that deals with some of the
shortcomings of the current state. My primary motivation is to be able
to use libpeas to load plugins, both C and non-C (Python!), as you might
have lear
Hi Thomas,
In general this looks like an improvement to the current method of
setting up plugins, except it continues to require the plugin .so file
to be dlloaded just to populate the plugin manager. That will run the
dll initialization code, and may therefore break Geany. Have you
thought abou
On 15-03-18 01:23 PM, Dimitar Zhekov wrote:
On 18.3.2015 г. 18:42, Thomas Martitz wrote:
- Global symbols. Plugins binaries have to export a number of global
symbols (geany_{functions,data,plugin}, plugin_{init,...,cleanup}). This
kind of sucks, because they pollute the global namespace (in the
Am 18.03.2015 um 21:23 schrieb Dimitar Zhekov:
On 18.3.2015 г. 18:42, Thomas Martitz wrote:
- Global symbols. Plugins binaries have to export a number of global
symbols (geany_{functions,data,plugin}, plugin_{init,...,cleanup}). This
kind of sucks, because they pollute the global namespace (in
On 18.3.2015 г. 18:42, Thomas Martitz wrote:
- Global symbols. Plugins binaries have to export a number of global
symbols (geany_{functions,data,plugin}, plugin_{init,...,cleanup}). This
kind of sucks, because they pollute the global namespace (in theory).
Luckily on unix or win32 systems this i
Am 18.03.2015 um 18:11 schrieb Steven Blatnick:
I personally hope whatever the group decides to do with the plugins
doesn't involve requiring a rewrite of all of them, because we'll
surely lose plugins and supporters that way.
Geany developers are committed to maintain compatibility for exis
I personally hope whatever the group decides to do with the plugins
doesn't involve requiring a rewrite of all of them, because we'll surely
lose plugins and supporters that way.
Concerning some of your perceived shortcomings:
On 03/18/2015 10:42 AM, Thomas Martitz wrote:
Currently geany expor
Hello,
tl;dr -> scroll down
I am working on a new plugin architecture that deals with some of the
shortcomings of the current state. My primary motivation is to be able
to use libpeas to load plugins, both C and non-C (Python!), as you might
have learned from other threads I started. However
39 matches
Mail list logo