Custom GObjects

[badcel]

Some remarks for this implementation:

• If a System.Type has no Method Sys.Type GetGType() it is assumed that this type is a wrapper
• The Binding class is an example implementation. The GBinding has no _new function. Meaning it can only be created with an existing pointer or via the construct only properties.
• I don't use a type dictionary. I'm always asking the C typesystem for information. If this does not impact the performance I prefer it, because there is less code and no duplicated type information (C vs C#)

I suppose that in most cases it is okay, to just call the base constructor without any parameters. Because after the base constructor finished the object is constructed and we can set the properties of our instance afterwards in the C# constructor.

If there are some properties which are construct only (like in GBinding) we could call the Object(params Prop[] properties) constructor without the need to implement this kind of constructor in a subclass.

---

Edit:

Todo

• Register/FromExisting split
• Remove old properties code
• Rename property descriptors (remove 'Ex')
• Move Sys.Type to GObject.Type
• Generator
  • properties
  • events
  • events via property indexer
• Samples
• Test other libraries (Gtk, libhandy, etc)
• rename ConstructProp to ConstructParam as this is an actual construct in GObject used for a near-identical purpose.
• No custom code in wrapper libraries. Properly wrap Sys.Type + Sys.Value in Core

[badcel]

Missing;

• ClassInit: Call static constructor if called from C world
• InstanceInit: Call constructor if called from C world

[mjakeman]

I am liking this approach quite a lot more. The type registration is fundamentally the same but you've managed to bypass the typedict, which I always considered a necessessary evil.

I agree that we'd be better off not having a type dictionary if we can avoid it, since we're basically just reimplementing GType.

I might have a go at handling object lifecycles (wrapping, lifetimes, toggle refs, etc) on top of this branch to see if we can stick with this going forward.

[badcel]

I would suggest you create a new branch for your lifecycle management code on top of this. In this way we can discuss the pros and cons afterwards if i have s.th. working.

I think the code in this branch could be improved. I like your style of coding / documenting, it is very easy to read and follow along. I think whatever code we decide to take over, we should work over it together.

[badcel]

@na2axl An Update for you:

@firox263 and I just had a meeting on how to progress. We decided to generate parts of the core libraries to ease up object creation. The result of this inital work for this is in the Samples/Gtk3/Quickstart.

I'm probably going to implement the generator today. If this is done we have the most important things for the type system integration available.

Afterwards it would be nice if you can rebase your pull request #58 on this one. Than we have a foundation on which we can apply all the small things to make it nice and finalize the work on the properties.

If this is done the generator should generate the properties, too. The last part are methods and we need to figure out if we want / can generate them. (I'm not sure if this will be easy, because I want the async and await in this library).

[badcel]

I updated the code to generate the core classes partially. The code is compiling but not working because I had to remove the connections to the properties. I think this could be the start of our future gir.core base.