@State and .fileExporter don´t like each other

mlm

Hello David (I think is still only the two of us ;-),

now that I was able to experiment a little more I ran into an issue when using .fileExporter:
If a .fileExporter is present, it seems to prevent that changes to @State variables trigger an UI update.
I´d be happy to dig into this problem and try to fix it. I mean I want to learn how everything works. But I think I´d need a hint, where I should start looking? If you could give me the initial pointer in the right direction, that would be great.

Below is a code-snipped to illustrate/reproduce the issue. I've also created a small sample project over here (in the IssueWithState Folder: IssueWithState

import Adwaita

@main
struct IssueWithState: App {
    let app = AdwaitaApp(id: "de.virtualfridge.issueWithState")

    @State private var text = "This should not be there."
    @State private var openExporter = Signal()

    var scene: Scene {
        Window(id: "main") { window in
            VStack {
                Text(Loc.helloWorld)
                    .padding()
                Button("Show FileExporter if there") {
                    openExporter.signal()
                }
                Text(text)
                    .padding()
                    .onAppear {
                        // this currently only works if .fileExporter is commented out
                        text = "It's good now"
                    }
            }
            .topToolbar { ToolbarView(app: app, window: window) }
            // if the fileExporter is not there, the "text" change in the above .onAppear works just fine
            .fileExporter(open: openExporter) { _ in
                print("fileExporter finished")
            } onClose: {
                print("just closed")
            }
        }
        .defaultSize(width: 450, height: 300)
    }
}

Cheers, Michael

david-swift

Thank you for the bug report and the code snippet! I have fixed it in commit 90349fd435.

As you're interested in how it works:

FileDialog is basically a wrapper around its content. This means that it initializes its content and stores the pointer to the content's GTK widget in a ViewStorage. In general, each instance of a view has its own "view storage". Therefore, a new view storage object for FileDialog is created, which stores the view storage of its content under the view storage's content property. This is required in order to access it during updates (I mistakenly tried to update the FileDialog's view storage instead of the one of the content view). An update is triggered by the modification of an @State view property and basically means going through the whole view tree (the one actually written by the developer, with views such as FileDialog or Text) and the view storage tree (which stores references to GTK widgets) simultaneously and updating the GTK widget referenced by the pointer in the view storage based on the new properties of the view (in case an update is required). If the GTK widget does not match the view, so if we try to update the wrong view storage with a view, the update fails, which is what happened here.

I hope my explanation helps you understand how the framework works. I'm happy to answer further questions!

Cheers, David

mlm

Thank you! It works perfect now! :-)
And thanks for the great explanation! It really helps me understanding how it all works. Still a long way to go to really understand how it all works ;-)

Cheers, Michael