-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Full Interface Support #110
Comments
Hi @firox263, you made a good point with this, maybe you can see if what I'm trying to do in #103 it is useful to you. I have:
Maybe the fact that the |
@na2axl This looks very good to me. Having interface properties generated already knocks one thing off this list. The next thing would be mapping between GInterfaces and their GTypes like we're doing for objects. I'll experiment on top of your branch a bit, and see if I can get something working. |
I did not check the code just in case it applies here: we could try do make smaller iterations on the develop branch and slowly get things working. @na2axl if complete parts of your code are already working as expected let's put them into develop. I'm thinking about the same for my type integration or. It should probably be split into several smaller ones as it contains several features. |
Some example code: Assume we have a subclass which implements the public class MySubclass : Gtk.Widget, Orientable
{
public Orientation Orientation
{
get => GetProperty(Orientable.OrientationProperty);
set => SetProperty(Orientable.OrientationProperty, value);
}
public void SetOrientation(Orientation orientation)
=> (this as Orientable).SetOrientation(orientation);
public MySubclass()
{
}
} If we try and use this: var subclass = new MySubclass();
subclass.SetOrientation(Orientation.Horizontal); We get the following critical:
To resolve this we need to make sure MySubclass implements the corresponding GInterface for |
To register an interface we need to do the registration in the corresponding subclass, to avoid heavy reflection. In my test I added a method like this to the private static void RegisterInterfaces(Type gClass)
{
var orientableInterfaceType = Gtk.Orientable.GTypeDescriptor.GType;
var interfaceStruct = new InterfaceInfo(
initFunc: InterfaceInit
);
IntPtr ptr = Marshal.AllocHGlobal(Marshal.SizeOf(interfaceStruct));
Marshal.StructureToPtr(interfaceStruct, ptr, true);
GObject.Global.Native.type_add_interface_static(gClass.Value, orientableInterfaceType.Value, ptr);
Marshal.FreeHGlobal(ptr);
}
private static void InterfaceInit(IntPtr g_iface, IntPtr iface_data)
{
} The method is executed directly after the type registration (currently per reflection). and the This fixes
But now the next error appears:
and a stack overflow
The hurdle is that if we implement an interface we want to call the methods defined in our subclass. According to the documentation we need to wire up our subclass methods into the interface structure. The properties should be defined in the I put the code here: https://github.com/gircore/gir.core/tree/spike/interfacesupport1 |
I made some good progress with installing properties into the Subclasses which needs to be done to implement interfaces. It is not yet working but I think it is not much left to have some working prototype code. |
This is now working in some preliminary way. I think it is not very bad. I would be interested in your opinions @gircore/coreteam . I added two additional (for now optional) properties to the Property class. It is the kind of the property which tells us if it is an enum / int / ... and the 2nd is the GObject type-id as we need both to create the C property descriptor ( Another probably better solution could be to add the "kind" property to the type descriptor. But it would require the TypeDescriptor of each class to be public. Currently I think this would be okay, as we made the Additionally I implemented it in a way that the subclass itself has to handle the setting of their own custom properties which itself installed. The code is quite easy. I tried to move it down into object but this made it very complex as the object class does not know anything regarding how to set a property of a more derived type and the types needed. I think the current code does not work if there is a even more derived class than See: #196 |
While trying to implement
TreeSelection
, I ran into an issue where I needed to get a GObject of some (theoretically) unknown type and return it as an interface. We should makeTry/WrapPointerAs
support returning interfaces as well as objects.After #102, I think interfaces are the only "big thing" left in terms of type integration before we've covered most of the GObject type system. Let's use this to track interface support.
To Do:
Try/WrapPointerAs
Future:
I
for consistencyThe text was updated successfully, but these errors were encountered: