deps: Bump GirCore.Gtk-4.0 from 0.6.3 to 0.8.0 - #4
Merged
Conversation
--- updated-dependencies: - dependency-name: GirCore.Gtk-4.0 dependency-version: 0.8.0 dependency-type: direct:production update-type: version-update:semver-minor ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Updated GirCore.Gtk-4.0 from 0.6.3 to 0.8.0.
Release notes
Sourced from GirCore.Gtk-4.0's releases.
0.8.0
This is the first non-preview release of 0.8.0 which introduces GTK composite template support, GNOME 50 support (inlcuding GTK 4.22 and libadwaita 1.9) and under the hood fixes for several runtime errors.
Please be aware that there are resulting breaking changes:
Please continue reading to get an overview of all relevant changes and a description of the breaking changes and the newly introduced GTK composite template support.
Noteworthy
Since 0.8.0-preview.1
Gio.ListStore.New<T>method to allow a more idiomatic instantiation (#1495)Module.SetCustomDllImportResolver). Please be aware that this API is marked asExperimentaland should be avoided in favor of a custom GirCore build (#1501)GResource(#1510)GLib.UnhandledException.SetHandlerwill be triggered for regular callbacks (#1529)0.8.0-preview.1
out/refenums are now supported (#1459)outopaque typed records are now supported (#1463)Breaking changes
This release includes GTK composite support which is a major milestone for the GirCore project. To reach this goal there were some breaking changes necessary. Those mainly affect the usage of
Gtk.Builder, the creation of subclasses and to a lesser extent the creation of native classes. In total those changes are a first step to allow deeper integration with the GObject type system.The API was held as backwards compatible as possible. Warnings are raised for APIs which will be removed in a later release (0.9.0). Please read ahead carefully to get an overview of the breaking changes and how to resolve them.
The following sections describe the breaking changes and how to solve them. A more detailed explanation why the breaking changes are necessary can be found in the explanation of the diagnostic message 1007. Issue 1441 describes the available feature set between versions.
Instance creation
Since the beginning of GirCore constructors of GObjects were rendered as static factory methods. There is one exception: It is possible to create instances with a parameterless constructor or an array of
ConstructArgument. As GObject itself expects all objects to be creatable without a parameterized class specific constructor this public constructor will be marked as obsolete and a new factory method will be rendered as an alternative. This means the API is not yet removed but its usage is discouraged as the deeper integration with GObject requires a workaround to make it work.Subclasses
To make subclasses work they will rely on source generators to integrate dotnet deeply with the GObject type system. This requires some unsafe code to be rendered as C will call directly into dotnet code. For this to work projects using GObject based subclasses must set
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>in theircsprojfiles.The creation of subclasses includes several scenarios. The classic dotnet way of subclassing via a parent parameterless constructor now raises a warning. Please note that the
Initializemethod is called always if an instance of the subclass is created. Even if the instance is created by the GObject type system itself. Therefore it is safe to mark the member_valueas not null.Subclasses
To make subclasses work they will rely on source generators to integrate dotnet deeply with the GObject type system. This requires some unsafe code to be rendered as C will call directly into dotnet code. For this to work projects using GObject based subclasses must set
<AllowUnsafeBlocks>true</AllowUnsafeBlocks>in theircsprojfiles.The creation of subclasses includes several scenarios. The classic dotnet way of subclassing via a parent parameterless constructor now raises a warning. Please note that the
Initializemethod is called always if an instance of the subclass is created. Even if the instance is created by the GObject type system itself. Therefore it is safe to mark the member_valueas not null.