Mathusalem interfaces follow-up
A week ago, I was talking about how I could implement the interface composition idea in Mathusalem, the long running task manager project.
Let me remind you the concept: third party apps register a new object, this object implementing a few custom interfaces. So what I have to do is to generate an object implementing these interfaces. But there is a fairly high amount of possible combinations, so it’s not possible to define them all at compile-time.
I then proposed two solutions, one consisting on playing with GTypes, and one consisting on roughly mimicking GInterfaces using a hash table of “interface” objects. The latter seemed the most rationale way to do things at that time, mostly because the former looked horribly difficult, and GType black magic is frightening.
Finally, what did you do?
Well, I made it work. And to achieve this, I took the first idea.
The second one looked simpler, and was really simple to implement on the
GObject side. But the problem was that it wasn’t really possible to put such
an object on D-Bus without rewriting a fairly large amount of
from the D-Bus bindings for GLib.
The first one was actually very simple, I just have to generate an unique name for the new type and initialise required GInterfaces on it. This was actually done in less than 50 code lines. And I just had to patch the bindings for them to take GInterfaces into account.
Using GInterfaces actually gives you a really nice code, and allow you to hide DBus so that the object just does not know about it: by defining statically the functions for DBus using the regular functions, everything is transparent. Yay it breaks the ⤽no-code-in-interface⤝ guideline, but actually, it’s just marshalling stuff, there is no real code in there. I promise I’ll give you a small working example of it soon.
This interface stuff also mean I dropped the helper objects I was talking about last week. The code is really nicer now in that regard: simple and straightforward.
So, well, to make it short, it works now, and I bet we’re getting very close to a first preview release (and publication of my git repository as well). No UI yet, anyway, but dbus-viewer should do ;-)
And on the client side?
Just forget about it. Reusing the server code on the client was a really stupid idea from me, since the requirements are not the same. For instance, the client lib would not be focused on storing data and should not retrieve the whole task object if you only care about one of its property.
So I guess I will write another lib filling these requirements, maybe reusing
.h file, but that’s all. Bindings could also be done using high
level languages directly, since they usually have D-Bus bindings already.