Hi, This is a really neat project and one that I'm definitely interested in contributing to.

I tried creating a basic Counter App with the example Package.swift in the Readme.

I got this error in my terminal when I ran swift build

error: product 'SwiftGtk' required by 
package 'swift-cross-ui' target 'SwiftCrossUI' not found.

This is what my package.swift looks like

// swift-tools-version:5.5
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "Example",
    dependencies: [
            .package(url: "https://github.com/stackotter/swift-cross-ui", .branch("main"))

    ],
    targets: [
             .executableTarget(
            name: "Example",
             dependencies: [
        .product(name: "SwiftCrossUI", package: "swift-cross-ui")
      ]),
        .testTarget(
            name: "ExampleTests",
            dependencies: ["Example"]),
    ]
)

I'm running Pop OS which is a Ubuntu fork/derivative.

Currently only HStack, VStack, Button and Text are supported. The following view types would also be useful to have:

• [x] TextField
• [x] Slider
• [x] ForEach
• [x] Image

If you think of any more, reply below.

For reference on how to implement a container view, see the VStack implementation. For how to implement a non-container view, see the Button implementation.

Allows defining window properties from your app. Currently it has the following properties:

• title

• defaultWidth

• defaultHeight

• resizable

title is required, while the other values are optional and default to the previously hard-coded values if not set.

Linting is a great way of ensuring that a repository's code is neat. Setting up SwiftLint consists of two steps:

• [x] Create the SwiftLint configuration file and decide which rules to use
• [x] Create a GitHub action to automatically run SwiftLint

A GitHub action would be useful because it allows all supported platforms to be tested for each commit, making it a lot harder to break platform support.

The following two GitHub actions would be the most useful:

• [ ] SwiftLint
• [x] swift build on macOS
• [x] swift build on Linux

When closing the example app, the following output can be seen in the console:

(<unknown>:58068): GLib-GObject-WARNING **: 08:43:20.945: instance with invalid (NULL) class pointer

(<unknown>:58068): GLib-GObject-CRITICAL **: 08:43:20.945: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(<unknown>:58068): GLib-GObject-WARNING **: 08:43:20.945: instance with invalid (NULL) class pointer

(<unknown>:58068): GLib-GObject-CRITICAL **: 08:43:20.945: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(<unknown>:58068): GLib-GObject-WARNING **: 08:43:20.945: instance with invalid (NULL) class pointer

(<unknown>:58068): GLib-GObject-CRITICAL **: 08:43:20.945: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(<unknown>:58068): GLib-GObject-WARNING **: 08:43:20.945: instance with invalid (NULL) class pointer

(<unknown>:58068): GLib-GObject-CRITICAL **: 08:43:20.945: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

(<unknown>:58068): GLib-GObject-WARNING **: 08:43:20.945: instance with invalid (NULL) class pointer

(<unknown>:58068): GLib-GObject-CRITICAL **: 08:43:20.945: g_signal_handler_disconnect: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

Here's some basic documentation for getting started, basically all pulled from the README. I mainly thought this would be helpful because it means you can find all of the info you need to start working on the documentation site. Definitely can reword anything that needs to be reworded.

I split swift.yml into swift-macos.yml and swift-linux.yml so that you can have a badge for each in the README to show if a specific platform is failing. The images currently don't exist and are just question marks but that will be fixed once the workflows are there.

Currently doing padding before frame produces different behaviour than padding after frame when the frame height is set such that the content can scroll (the padding is either inside or outside of the scrolling area). This is clearly not the intended behaviour and will have to be solved eventually.

SwiftUI has a Picker view that allows a user to select an option from a list, which is implemented by the Menu widget in Gtk. It'd be nice for SwiftCrossUI to have a dropdown menu type too (called Picker for consistency with SwiftUI).

Theoretically, SwiftCrossUI should work on Windows, but I haven't managed to install Gtk on Windows in a way that Swift can use yet. If you use Swift on Windows, you'll probably have more luck than I did! Feel free to try and get it running.

If you do manage to get it working, please let us now how, so that we can setup a GitHub action for Windows builds. And if an code changes are required to get it running, just make a PR.

For example, currently buttons have their text updated every time the state of their parent view changes, which is completely unnecessary given that most of the time their label is static.

This could be achieved by adding extra checks to the update function for each view type (currently only text and button implement this).

SwiftUI approaches this by having the body of App be of type some Scene where a scene can define windows using a result builder.

The way I plan on approaching this is making App.body be of type some AppContent and having a Window struct that AppContentBuilder accepts. Then _App can setup the windows accordingly in run.