Roadmap

[badcel]

Currently we have 2 draft pull request, both already have InitiallyUnowned as a separate type and the implicit bindings are gone. Probably there will be more draft pull requests which would need this, too. So to get the develop branch in shape we should work on #53, #54.

The next question would be how to integrate the INotifyPropertyChanged part. I would suggest that we work for #44 and #46 on separate draft pull requests (could be that we need several drafts per issue) but don't make the whole library working. Just for one or two example cases. If we all agree on the code in general we can than create a final pull requests in a final branch.

This final pull request should at first contain the final GObject type system integration part.

As the general route how the the wrappers should look like is clear at this point we could divide the work to port over the libraries. And finally merge everything into develop.

Afterwards we should get our self s.th. to drink :-)

Any thoughts?

[na2axl]

I agree with you.

The work @firox263 is doing on #48 is the most important now, since it will be the base of several other implementations and further thinking.

For the INPC implementation I think it will be something doable when a proper way to get/set properties will exist, so when GetProperty<T>(Property<T> prop), SetProperty<T>(Property<T> prop, T value) and everything related will be implemented. But for now we can at least create an OnpropertyChanged method :-).

I've browsed the source code yesterday, and from what I've seen I think the work on properties can be done in parallel with the work on type system integration, and the current Object.Properties.cs file is a great starting point! I can be wrong so I will let @firox263 give his point of view on that.

[mjakeman]

na2axl: I've browsed the source code yesterday, and from what I've seen I think the work on properties can be done in parallel with the work on type system integration, and the current Object.Properties.cs file is a great starting point! I can be wrong so I will let firox263 give his point of view on that.

I suppose type-system integration is a bit of a misleading name, as it really is object creation, property creation, lifetimes, and class registration. On that basis, I think very simple static properties should probably be part of the PR directly, as we'll need them in place for the call to g_object_new_with_properties.

My idea at the moment is we should try land the following as soon as possible, building on #52.

• Very basic static properties (based on your proposal)
• Removal of implicit casts and creating a GInitiallyUnowned class
• Construct-time properties based on @badcel's very nice param Prop[] idea
• A WrapPointer<T> function for wrapping a foreign IntPtr in a C# type/retrieving an existing one

Once this is done, the public API is mostly finalised, and we can then work on nice things like more in-depth properties, data bindings, INPC, etc. More importantly, it means the more involved parts of type integration (which are entirely behind the scenes) like object lifecycle management, composite templates, and virtual function overrides can be done on a separate PR and won't hold up development any longer.

badcel: I would suggest that we work for #44 and #46 on separate draft pull requests (could be that we need several drafts per issue) but don't make the whole library working. Just for one or two example cases. If we all agree on the code in general we can than create a final pull requests in a final branch.

This sounds good to me. What do you think of splitting #46 into what I've described above? I'm confident that we already have what we require wrappers/subclasses to implement (in terms of constructors, methods, etc), so with maybe another weeks' work, #52 could be merged. Then we can work on the other parts separately in conjunction with properties, since there's very little overlap.

What are your thoughts? @badcel @na2axl

---

badcel: Afterwards we should get our self s.th. to drink :-)

Of course 😉

[na2axl]

I suppose type-system integration is a bit of a misleading name, as it really is object creation, property creation, lifetimes, and class registration. On that basis, I think very simple static properties should probably be part of the PR directly, as we'll need them in place for the call to g_object_new_with_properties.

My idea at the moment is we should try land the following as soon as possible, building on #52.

• Very basic static properties (based on your proposal)
• Removal of implicit casts and creating a GInitiallyUnowned class
• Construct-time properties based on @badcel's very nice param Prop[] idea
• A WrapPointer function for wrapping a foreign IntPtr in a C# type/retrieving an existing one

@firox263, @badcel can I then start an RFC explaining technical details about my proposal + open an issue for that RFC for general discussion about the subject + open a PR based on #52 for code reviewing and progression tracking ?

[badcel]

This sounds good to me. What do you think of splitting #46 into what I've described above?

I'm fine with it 👍

What do you thing of my old suggestion that we start with this one, including a PR for develop, because it is independent of the rest:

Removal of implicit casts and creating a GInitiallyUnowned class

We can than work us through all the problems which will arise with the type system / properties.

---

Edit: If someone starts the work, please assign your self to the issue so no work is done twice. I would like to start shortly, but I'm not sure when this will happen exactly. So if one of you guys is quicker it is no problem for me. This is more like a task requiring great diligence.

[badcel]

As #75 is somewhat finished and we could merge this (or continue work there) the question comes up how to progress.

There are still a lot of things to do. For me the most pressing ones are the type integration(@firox263 ), clean up the code, align to our editor config, get the samples to work, clean up the samples, support the orignal libraries (me)

@na2axl I'm not sure on which part you would like to work or if you want to support both @firox263 and me? Other points which could be interesting for you are perhaps the question if / how we want to generate more code, the toolkit layer or the easy integration of 3rd party GObject based libraries (dotnet tool)?