WIP: Add 'subclass' mode #604
Conversation
|
Question 1: How do I get get to the object class vfuncs? It seems those are not part of analysis in normal mode? |
|
Currently we ignore |
|
The function definitions are present in the sys crates though, as part of the class structs. So the analysis should contain those, but I'm not sure where to look... |
|
They are in the .gir file as field and as virtual-method. The struct field in the sys crates comes from the former. You'd have to add it to parser.rs as a very first step |
src/parser.rs
Outdated
| @@ -153,7 +154,11 @@ impl Library { | |||
| fields.push(f); | |||
| }) | |||
| } | |||
| "virtual-method" => parser.ignore_element(), | |||
| "virtual-method" => { | |||
| self.read_signal(parser, ns_id, elem).map(|v| { | |||
There was a problem hiding this comment.
Yes, except that they might have annotations for the parameters and return value
There was a problem hiding this comment.
I figured. I'll get to that later. You have to have a fair amount of knowledge of gobject/gir internals here. Which I don't have :D.
|
At this point, most big building blocks seem in place, yet it is still far from finished. These things are currently still incomplete/lacking:
I'd like some feedback and/or help at this point. I've never really liked writing code generators, so I don't really feel like carrying this on my own :) |
vhdirk
force-pushed
the
subclass
branch
2 times, most recently
from
b8baad8
to
8030304
Compare
|
Also: I just noticed I'm missing return value signatures almost everywhere. |
|
Thanks a lot. I'll take a look over this in the next days, but for now can you put some generated output of this somewhere? Also my idea for manual implementations was to be able to ignore various vfuncs and then have a separate file that has those implementations only. And that file is read by GIR and inserted into the generated code (as we can't have them as separate files during compilation: parts need to be added to the same traits and impl blocks directly). |
|
I have some more pending commits, but my laptop refused internet connection. All add them asap. One of the largest pending issues is that the generated traits for interfaces lack a name. |
|
Current status of generated files: |
|
A PR making use of this is available here: gtk-rs/gobject-subclass#12 It almost completely covers the code generation for |
|
Just a heads up here, |
|
I know. It's been nagging about that all morning :). I'll remove those statements soon. Should make it a wee bit easier to debug. |
vhdirk
force-pushed
the
subclass
branch
2 times, most recently
from
e895709
to
b8ef2ce
Compare
vhdirk
force-pushed
the
subclass
branch
3 times, most recently
from
40e8025
to
77fa6b8
Compare
It needs to be regenerated by gir once gtk-rs/gir#604 is merged.
|
@sdroege I'm willing to update this PR to the new subclassing infrastructure, but it's been a while since I first made this. Since the interface has changed quite a bit, it might also make sense to start fresh. A bit of guidance towards may be needed here in order to get this accepted quicker. |
|
This now has to be updated for the new subclassing API that was merged into |
|
I figured as much. I've rebased this onto master again, but in order to make it work on the new infrastructure in glib, I'd need some time to figure out where everything has moved. |
Based on his work in https://github.com/sdroege/gst-plugin-rs, @sdroege and I have been working on a set of traits to make subclassing glib/gtk/gst objects possible without too much boilerplate. See https://github.com/sdroege/gobject-subclass and https://github.com/sdroege/gtk-subclass.
Currently, we're generating these traits by hand, and that's a lot of (repetitive) work. In this PR, I'd like to address that by reusing parts of gir. I'm not sure if this would ever be a candidate for inclusion. If not, I'd like to kindly ask for feedback as I/we go along with this.
This is a heavy WIP, that I just started a couple of minutes ago, so there simply nothing to see here. Yet.