On Mon Nov 3 17:08:52 2025 +0000, Esme Povirk wrote:
That could still fail for complicated dependency graphs. I guess there's no general solution with a reasonable runtime that we can be sure will terminate. Maybe if option names are relatively consistent between devices, we could just hard-code some ordering rules for the ones that have been known to do this? It may be possible to make an additional configuration file in which information about the order of loading parameters can be placed, for example:
[Vendor_Product path] order Might you also consider creating an oriented dependency graph at the time of sane.ds initialization? Keep in mind that in O(n**2), the value of n is small in the context of the number of parameter settings. You can try another option. 1) Enter a global variable with the name of the last modified parameter 2) At the time of the first initialization of the settings window, this global variable will be empty, therefore there have been no changes. 3) When making changes to a global variable, save the changed parameter. 4) At the next initialization of the window, check the parameters from the registry and the real ones in sane. If the values differ, there may be two options: 4.1) The parameter name matches the name from the global variable - start the cycle again and return to point 4, check the parameter for a second match with the variable (there may be a complex relationship) 4.2) The parameter name does not match the name from the global variable - you need to replace the current value in sane with the value from the config This is an approximate algorithm for possible correction, what do you think? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9184#note_121010