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
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
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
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 change, from
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
[...]
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 report
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. But due
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 like two different
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
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
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
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
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?
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
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,
.init
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,
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
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
On 19 March 2015 at 09:16, Thomas Martitz ku...@rockbox.org 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
Am 19.03.2015 um 23:34 schrieb Lex Trotman:
On 19 March 2015 at 09:16, Thomas Martitz ku...@rockbox.org 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
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);
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
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
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
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
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: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
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
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
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
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
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
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
35 matches
Mail list logo
