Plugin System

[ld-cd]

OK I've been working on a plugin system, it is currently non functional, but most of the code is there. The repos here: http://github.com/ld-cd/loliwm When running loliwm I get the following error:

Inconsistency detected by ld.so: dl-close.c: 154: _dl_close_worker: Assertion `idx == nloaded' failed!

I think this is caused by line 16 in plugin.c, but its late over here and I need to sleep. Maybe one of you in a different timezone will work out whats causing it. Oh and by the way this is supposed to work by having a dynamically linked object in ~/.loliplugs, that contains a symbol plugin_init that when run returns the top node of a linked list of every function it wants to hook. The structs for a hook, and the linked list looks like this:

typedef struct hook{
  int hook;
  const char *symbol;
  void *handle;
};
typedef struct h_list{
  struct hook *function;
  struct h_list *next;
};

P.S. sorry for the lack of comments, I'll add some next time I have a chance.

[Cloudef]

I'm sorry, but the code as is, looks really too messy to be included. (It also has lots of other violations, like passing unknown strings to formatter argument, not handling heap allocation failures, casting when no casting is needed, etc. You probably want to get familiar with valgrind and static analyzers).

Also we probably don't want to use linked lists (even the current wl_list in loliwm/wlc sucks, and I need to replace them with chck's pools sometime).

We also need small message passing system working with function signatures, so others plugins can interact with other plugins, for example use PNG plugin for PNG compression for screenshots. It also makes possible to use function signatures to avoid calls that would lead seg fault (Plugin is expecting other plugin have different API).

We also need central "registry" which plugins can register configuration and keybindings, and loliwm will handle the conflicts.

The plugins will be what drives loliwm in the end and this is not enough.

As for your ld.so issue, it seems the ld.so internally asserts on dl_close and that seems like it's trying to close plugin that isn't open (is my guess).

[ld-cd]

I know the current setup is two messy to be merged, but its good to know what needs to be fixed. As I said I'm still a bit of a noob when it comes to programing, and this is really just a good way to learn that. On Feb 8, 2015 5:39 AM, "Jari Vetoniemi" notifications@github.com wrote:

I'm sorry, but the code as is, looks really too messy to be included. (It also has lots of other violatiaons, like passing unknown strings to formatter argument, not handling heap allocation failures, casting when no casting is needed, etc. You probably want to get familiar with valgrind and static analyzers).

Also we probably don't want to use linked lists (even the current wl_list in loliwm/wlc sucks, and I need to replace them with chck's pools sometime).

We also need small message passing system working with function signatures, so others plugins can interact with other plugins, for example use PNG plugin for PNG compression for screenshots. It also makes possible to use function signatures to avoid calls that would lead seg fault (Plugin is expecting other plugin have different API).

We also need central "registry" which plugins can register configuration and keybindings, and loliwm will handle the conflicts.

The plugins will be what drives loliwm in the end and this is not enough.

As for your ld.so issue, it seems the ld.so internally asserts on dl_close and that seems like it's trying to close plugin that isn't open (is my guess).

— Reply to this email directly or view it on GitHub https://github.com/Cloudef/loliwm/issues/60#issuecomment-73411154.

[Cloudef]

Yeah, it might be quite hard to contribute right now as well. Most of the open issues need deeper knowledge of wayland/x11 and compositor related components (drm, opengl, etc). The plugin system will be quite involved as well, however I hope to start work for that soon, plugins should have lower entry barrier for contributions.

[ld-cd]

I understand, thanks for your help.

[Cloudef]

I started the plugin work on feature/plugins branch. The initial plugin API draft is here https://github.com/Cloudef/loliwm/blob/feature/plugins/include/orbment/plugin.h

Currently I need to expose core apis for plugins to use for interacting with loliwm and wlc.

[onny]

I would like to see a statusbar in loliwm. Is this something I could achieve with a plugin system?

[Cloudef]

Yes, it's something that we could even have standard interface for. Currently however, there is no way to draw to screen from plugin, it's possible to expose wayland extension and launch bar as client though. But the first is something I will at least do sometime.