The names of unit test methods are to long and the context is hard to grasp. We should work out some convention which we can apply to our unit tests which sattisfy our needs of simplicity and readability.

I had a small break through today regarding virtual methods and overriding thank's to the help of @webczat in gitter/chsharplang.

What do you think of the virtual method implementation in https://github.com/gircore/gir.core/tree/spike/virtual_methods ?

The code would would probably not stay like this from an public API point of view. But the executed calls would if you agree with this this attempt in general.

It does not integrate virtual methods in the original objects like Button, but there could be some code generated for subclasses to get this done via an attribute like shown in the branch. In this way we do not sacrifice on the performance if there is nothing overloaded.

I placed the Button subclass just at the end of the Quickstart program:

Could you test the code on windows, too @gircore/coreteam ?

Currently, if the build tool fails for whatever reason, it prints out the exception followed by a long stack trace. We should handle common failures gracefully and print out a helpful error message rather than >50 lines of stderr.

Particularly:

• GIR files cannot be found -> Instruct the user to pull the most up to date version of gir-files (and/or init submodules)
• Generation failure -> Print relevant inner exceptions only, rather than all of the threading-related exceptions Bullseye generates on failure. Could direct the user here to open an issue.

To allow easy binding of GTK widgets with viewmodels there needs to be some kind of binding mechanism.

Ideas:

• .NET 5 has new source generators
• https://github.com/badcel/BindingSharp
• https://developer.gnome.org/gobject/stable/GBinding.html

I've seen that the way we are separating projects now (Name.Core and Name.Wrapper) give us some limitations (by @na2axl)

I think our current arrangement is not intentional as such, but rather because we just built on top of what was already there (initially we had pure ABI structs in Name.Wrapper, hence the strange split)

In my opinion, we should keep the wrapper entirely auto-generated and move Sys.Value, etc to the Core namespace (we're already doing this with Sys.Type -> GObject.Type). This way, we get around any limitations while still keeping the nice separation between unmanaged functions and our 'safe' API.

Originally posted by @firox263 in #67 (comment)

This could be used in the autoatic build process to make sure the samples are compiling against the current code.

The generated methods for structs are all public and not part of a protected static class Native. This class should be generated to hide the low level access in the same way like it is done for classes.

Hello @badcel, @firox263 ,

I think we have to review the way to handle GInterface properties. I'm currently working on the widget catalog samples, I'm seeing that for now the generator is creating empty GInterfaces. I think we can at least generate an inner Native class which will contain the list of property names of that interface, so for example in the Box class we will have:

public static readonly Property<Orientation> OrientationProperty = Property<Orientation>.Register<Box>(
    Orientable.Native.OrientationProperty,
    nameof(Orientation),
    (o) => o.Orientation,
    (o, v) => o.Orientation = v
);

Also, since the Orientable interface for example can be used by many classes, I think it will be better to have the property descriptor in the interface, but not the properties.

public partial interface Orientable
{
    #region Properties

    public static readonly Property<Orientation> OrientationProperty = Property<Orientation>.Register<Orientable>(
        Native.OrientationProperty,
        nameof(Orientation),
        (o) => o.Orientation,
        (o, v) => o.Orientation = v
    );

    Orientation Orientation { get; set; }

    #endregion

    #region Native

    public static class Native
    {
        public const string OrientationProperty = "orientation";
    }

    #endregion
}

So in the implementations like Box we have:

public partial class Box : Orientable
{
    public Orientation Orientation
    {
        get => GetProperty(Orientable.OrientationProperty);
        set => SetProperty(Orientable.OrientationProperty, value);
    }
}

Like that we will not rewrite property descriptors in every implementations (what seems strange for me...).

What do you think ?

Static GProperty Descriptors

RFC

Please see the RFC here: https://github.com/gircore/rfcs/blob/master/rfc-002-static-properties.md
It explains the proposal and some potential solutions.

Summary

To allow Gir.Core be a part of the current C# UI ecosystem, the implementation of GProperties can be done using Static Properties, to match what it's done now using DependencyProperty in other libraries. For that we have the following goals:

• Declare GProperties of current Wrappers using Static Properties;
• Allow library users to declare GProperties of theirs Subclass using Static Properties;
• An high-level API will provide access to the GProperty value, to retrieve and edit it through the corresponding Property Descriptor.
• Property Descriptors must know the type (the C# type) of the GProperty;
• Property Descriptors must know the type (the C# type) of the GObject in which it will be registered;
• Property Descriptors must know the name of the GProperty;
• Property Descriptors must know if the GProperty is write-only, read-only, or read-write;
• Property Descriptors must allow an easy registration and initialization of the GProperty in the GObject;
• Property Descriptors must also describe child GProperties;
• All of these points must be implemented in an easy to use, DependencyProperty-like manner.

These goals can lead us to these achievements:

• Type System Integration with GObject, as discussed in #46, and described by [RFC001].
• Solid MVVM binding model, as discussed in #34, and described by [RFC003].

libhandy has released the first beta of the final API. The API is marked stable.

Update libhandy to a version >= 0.90.0 as soon as it is available as a package.

Once the code style is defined (see #59) add an editorconfig file to the project which adheres the code style document.

As we settle more and more on specific decisions how to progress, there is some need to document this project for our self and potential users.

From my point of view there are 3 kinds of documentation needed:

• API documentation: Which APIs are available?
• Developer documentation: How does everything work?
• User documentation: How to use the libraries?

We have several possibilities on how / where to document and should find a solution we want to stick with to avoid moving the documentation around:

• Github Readme
• gircore/gir.core repository with a folder named "Documentation": I saw this lately on some projects. In this case the documentation is part of the code and is tagged with releases, etc.
• Separate repository (RFC): Much space for comprehensive documentation
• Homepage (is generated automatically from github repository with markdown). Is able to generate API documentation
• Github wiki

I want as less dobuled documentation as possible. Even know I don't like the duplication between the github readme and the homepage. The homepage is already out of date.

Are there any preferences or suggestions or missing things?

Sample/GtkApp is confusing: Split it into several small examples

If we lookup 'GdkWin32Screen' in the typedict, since we don't provide bindings for Gdk's private API, we instead fallback to the next-best type of GdkScreen (as intended).

However, we only cache GdkScreen <-> Gdk.Screen and not GdkWin32Screen <-> Gdk.Screen, meaning that every time we do this lookup again, we go through the more expensive assembly search, rather than simply returning from the dictionary.

We should cache not only resolved types, but also ones that intentionally fail to resolve, to avoid unnecessary work.

This is particularly relevant for GStreamer, as we do this lookup every time we create an Element.

As discussed in #103, this issue is to find a solution about closures handling in Gir.Core libraries.
This issue can be related to #109

@firox263: Borrowing this to add a TODO

TODO 6/05/21:

• Reimplement Native->Managed marshalling (so we can call the user's provided delegate)
• Properly exclude certain parameters like userData
• Write unit/integration tests

Completed:

• Prototype Notified
• Prototype Async
• Prototype Default/Call
• Generator should use Native-suffix in native function calls
• Generator needs a way to marshal any arbitrary type from Native->Managed (this may require the generator rewrite to achieve?)
• Come to a decision whether DestroyNotify is useful in the end user API
• Implement Notify in Generator
• Implement Async in Generator
• Implement Call in Generator
• Fix DBusConnection and a few existing uses
• Memory Leak Testing

Move GObject / GLib into a new Runtime folder.

The code in GObject / GLib will be mostly written by hand as it is the foundation code to allow bindings and acts as some kind of runtime.

The remaining projects int he Libs folder will be as much autogenerated as possible.

This depends on #134 as there are some cleanups regarding csproj files which allow to avoid duplicated csproj code (General.props and Nuget.props).

If the generator is rewritten the following features should be thought of:

• Prefixing of interfaces (requires loading of other libraries while one library is generated, to detect if a type is an interface)
• Generation of properties which are defined in an interface (requires loading of a different XML than the one which is currently generated)

We need to free memory appropriately for structs and disguised structs ("structs as classes").

GStreamer defines a "free function", but does not have an attribute for this.

Hey there,

Since we are planning to use .NET 5 and function pointers, isn't right to also use unsafe contexts on some other points of the code ? I'm asking especially for structs, to use things like GLib.List* instead of an IntPtr. I think like that we will avoid a lot of marshaling/unmarshaling (which is an issue I'm facing while working on #103.

The unsafe context will only be used for Native classes, we will wrap them and provide safe contexts to end users through the high level API.

Any thoughts @badcel, @firox263 ?

...

There's still a problem with spacing between each field being wildly inconsistent, not really sure how to go about fixing that.

Originally posted by @firox263 in #127 (comment)

👍 Those vertical white space problems have s.th. to do with the documentation if it is generated / available or not. It is happening for fields in structs, too (but with one line less in between...).

It's not very nice but probably involves some update to Scriban. I did not take the time to reproduce the exact steps involved in it as the behavior is probably intended but not usefull for our case. So we would need to create some minimal samples and explain why it is bad for us and make some suggestions on how to improve it to the scriban project.

Integrating C# and GObject

RFC

Please see the RFC here: https://github.com/gircore/rfcs/blob/master/rfc-001-type-integration.md
It explains the proposal and some potential solutions.

Summary

Type Integration means that when the user creates a class that derives from GObject.Object, the library will automatically create a corresponding GType behind the scenes. Effectively, it allows us to write "native" GObject code using C#.

This enables us to implement the following features, among many others:

• GObject Properties - Subclasses can expose properties to the gobject type system, allowing for them to be viewable/changeable in GtkInspector, etc.
• Overriding Virtual Functions - Subclasses can override virtual functions (See GtkWidgetClass). For example, creating a custom container widget in Gtk with full control over sizing and layout.
• Composite Template Support - Supports binding a subclass to a composite template defined in an XML file. Particularly useful for complex custom widgets.
• Bidirectional Bindings - The possibility of using C# defined types from C and/or other language bindings. With .NET 5 we can use source generators to output native-callable functions.

Like with the namespace refactor (#27, PR #45), this will be a huge change that affects almost the entire codebase. For this reason, it is probably best to focus on completing this before we write more bindings.

@badcel, I am very intrigued by this project and it's goals. I too would like to see libhandy brought to .NET to help bring .NET Core to mobile devices (eg. smartphones) and responsive interfaces on desktops.

I saw your open invitation for contributors on issue 144 of GtkSharp and examined the projects current progress and have to say this is a very exciting project.

Is there an area where you would prefer to see contributions in this endeavor?

• Generate properties
• Generate native methods

The editorconfig code style is not consistently applied to the code base. It must be worked through the code files and be applied.

A thought:

We should probably check if the GType of generic type 'T' is equal to the gtype from the pointer. That way, we can avoid the expensive lookup in the type dictionary for cases where we know the type we want (e.g. Dialog.GetContentArea).

Originally posted by @firox263 in #65 (comment)

I created an issue so we don't forget about this comment. I currently don't see the expensive lookup. Perhaps you could just create a pull request?

Ideally, gir.core should be able to work 'out of the box' on Windows.

Building
I've managed to get the project building (see #37). This involves remapping shared library names to dll names in order to link with the proper libraries.

GTK Binaries
GTK Binaries must be installed manually at the moment. I am using the MSYS2 binaries since they are the recommended way to get GTK on Windows (from the website).

To link with the native libraries, I added a function that remaps the shared library name to the DLL name. This is problematic as MSYS2 and vcpkg use different DLL names (libglib-2-0.dll vs glib-2.dll). It looks like vcpkg might be updating their GTK builds to use meson directly, so hopefully this will be fixed.

Missing Libraries
There are a few other issues remaining, most notably that webkit2gtk doesn't build on Windows anymore (see PR for info). We might need some way of marking a lib as platform specific, so we don't unnecessarily generate wrappers.

Feedback is very much appreciated.

Floating reference handling is probably wrong.

See: GtkSharp/GtkSharp#197 and GtkSharp/GtkSharp@b58235b

Remove implicit casts from Object: This increases readability.

public static implicit operator IntPtr (Object? val);
public static implicit operator Object? (IntPtr val);

We should support using GStreamer with Plugins (as base GStreamer isn't all that useful). I think it's best we get this working ahead of any generator rewrite, since GStreamer uses GObject directly.

• GStreamer plugins have individual gir metadata files (see gstreamer-rs/gir-files).
• It would make sense to namespace plugins under Gst, for example GstAudio -> Gst.Audio.
  • I'm not sure if we can infer this from gir data?
• Parts of GStreamer rely on first-class interface support, so this will include #110 and #104.
• Outside of Gtk, GStreamer is the other big client of GObject, so there'll be intricacies to work around.
  • While typed properties (via property descriptors) are great and should be used whereever possible, GStreamer relies on being able to retrieve properties from string representations too.
• Easy GStreamer <-> Gtk interop for writing media-enabled applications.

Considerations:

• Investigate controlled properties?
• Allow for access to public struct member data (in the case of GstObject->flags)
• Fix clash in generator between capitalisation and reserved keywords (e.g. null->@null, whereas it should be null->Null, see Gst.State).

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 make Try/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:

• Support interface properties (#104)
• Support interfaces in Try/WrapPointerAs
• Allow user to implement GInterfaces for their subclasses
  • This will need to be done during type registration for GObject to recognise it

Future:

• Allow the user to export custom C# interfaces as GInterfaces?
  • Would be similar to object registration
• Prefix interfaces with I for consistency
  • Would be done alongside the generator rewrite

There is an update of scriban to version 3.0: https://github.com/lunet-io/scriban

Investigate whether we can/should cache the resolved DLL between calls to avoid a lookup each time we call a native method.

From #154:

na2axl: Maybe a way to cache the loaded library, to avoid redundant loading ?

badcel: I'm not sure if there is some caching on the side of NativeLibrary.TryLoad.
This reads a little bit like it: docs.
If you agreee I would avoid adding caching for now. If we see problems later or have definitive feedback that we are missing an opportunity here we can add the caching ourself.
gircore/coreteam what do you think?

badcel: Hm I added a Console.WriteLine and the ImportResolver method is called several times. So it looks like it is not caching. But I'm not sure if we should add caching and if this could result in some unexpected results.
Edit: I found no search results which did some caching. Perhaps there are multiple contexts involved and multiple calls are correct?

na2axl: I think we can check that by printing the returned IntPtr to the console, if the result is the same may be it's finally better to cache ?
But I've no problem to skip this for now.

From what I recall, the this(Native.@new) pattern breaks when subclassing, as we need to be going through either Object() or Object(ConstructParameter[]) for the type integration code to run. The IntPtr constructor would simply wrap the GtkApplication as a foreign-created object.

Originally posted by @firox263 in #95 (comment)

Are you sure about this? Can't we just add the type dictionary integration to the Object(IntPtr) constructor, too?

Enable the GStreamer samples and make them work again.

.....

We should think of how to deal with non-fatal errors however. GStreamer has a few instances of "Recoverable Errors", but I haven't looked into that too much yet.

Originally posted by @firox263 in #127 (comment)

Currently all global functions are public. Probably each function has some class where it could part of as a public static method.

Do we want to make the global class internal and call the global functions only from inside our library?

Alternatively we keep the global class public. In this case we should probably put the methods into a protected static Native class because the method signatures are full of IntPtr parameters. Then we could try to generate methods with a user friendly signature to access the native functions.

The WidgetCatalog will showcase the usage of every widgets in GTK3 (WidgetCatalog3) and GTK4 (WidgetCatalog4) with Gir.Core. This kind of sample is the first one experienced developers and newbies search when browsing a new UI framework.

Enable the DBus samples and make them work again.

Create own type for InitallyUnowned to match the GObject type hierarchy

We should define a code style we all agree on to avoid later discussion and ensure a consistent code base for gir.core This could be an RFC.

Found a really nasty bug with the type dictionary in our lookup code. If we don't instantiate an object before using it in WrapPointerAs<T>, it instead falls back (as intended) to the 'lowest common denominator' type. This is needed for Gdk objects, as a GdkScreen is actually a GdkWin32Screen (but of course, that's an internal type which is not exposed to bindings), so we default to GdkScreen instead.

The problem however, is we end up falling back to the last registered type, which in most cases ends up being either Gtk.Widget or a plain GObject. This always causes an Exception when used with WrapPointerAs<T> since you can't cast a true GObject type up to a Gdk.Screen for example.

Since this basically involves rewriting half the typedict, I've decided to do it all in one go and fix some of the other issues we had in the process. I'm currently working on this at firox263->feature/typedict.

TODO:

• Rewrite lookup code to search registered and non-registered types.
• Handle Unloaded Assemblies (e.g. Cairo, Pango, etc) Anti-Feature -> No Longer Considered
• Find a better way of obtaining the Namespace vs the Type Name from GObject (Currently it just takes the first "word" so GtkTextView -> Gtk + TextView. This is problematic with things like GtkSourceView where it doesn't fall under the Gtk assembly but does under the namespace).
• Do a check with TypeDescriptors to be sure the objects are derived.
• More robust handling of full type names. Assembly.GetType(string) needs the type name in the form Namespace.Type, so maybe each assembly should define some kind of metadata with the namespace it implements.
• Register recursively up the entire tree where possible, as this is much cheaper than doing it later.
• Optimise this with a few "fast paths" to avoid doing expensive lookups. This fixes #66
• Investigate more optimisations

We have several instances where delegates and callbacks get garbage collected when the computer is low on RAM. A typical error message looks something like this:

Process terminated. A callback was made on a garbage collected delegate of type 'GObject!GObject.WeakNotify::Invoke'.
   at Gtk.Global.main()
   at Gtk.Global.main()
   at Gtk.Global.Main()
   at GtkDemo.Program.Main(System.String[])

Once #52 is merged, I will try look into this along with some other changes to lifecycle code (e.g. ToggleRefs), so not very pressing at the moment.

The current class names of the high level classes are mostly prefixed with a "G" to avoid conflicts with the generated class for the low level api.

The namespace is "[Library].Core". The low level classes live in the namespace "[Library]".

Should the high level namespace be part of the low level namespace? I would like to separate the layers completely, allowing simpler class names and clean namespaces.

Should there be one global namespace for the high level api or should every library be on its on namespace? How would theses namespaces be named?

Feel free to post your opinion.

• Add the gir version to the package id (see #669 )
• Specify version number via directory build props
• Manually create releases via github workflow

Old:

• Should the version number be part of the code to allow "reproduceable" builds or be taken from a release tag?
• Should we take the version numbers from all of the projects individually? (GTK / GObject / Generator global tool / ...)?
• Do we just take the major version number of each project and add our own afterwards (the gir is not more specific than this)?
• Do we use our own version numbers completely and add the version of the GIR file into the package name, (like the *.so filename)? In this way each new major version of a library would be a new nuget and could be supported individually. (Preferred)
• Should the GirTool be released independently from the generated projects? (yes, as a global tool)
• Do we need to be able to update the libs independently from current develop branch? It would be simpler if not then we could always release from develop and rename develop to main.

It would be awesome to have a nuget package bundled up.

I'm keen to find a start creating c# apps for the Linux desktop/mobile software ecosystem, and I think this would go a long way.

This is a collection of ideas which could lead to better integration of this library into thje C# eco system. Those ideas are low on the priority list, as long as we are working on the basics of gir.core.

• Gio.SimpleAction: It should be able to create an action which is supporting the ICommandinterface

Enable the GtkMinimal sample and make it work again.

Use IndentWithInclude to simplify indentation. With this we can perhaps get rid of the whitespace parameter to indent code.

Scriban in its current version 3.0.3. still has a bug, which blocks this: scriban/scriban#266

Check if the consistent use of ~ helps in creating well formated documents (see: https://github.com/lunet-io/scriban/blob/master/doc/language.md#14-whitespace-control)

Verify if we really need the type dictionary. There was already an attempt to omit it: 34f0358

Were there any experiments with creating an object in Vala and importing it to C#?
Or just forecasts of how well it will work.

(Also interested in Meson)