Is our control auto-resizable horizontally ? This text will probably be bigger in certain languages.
I see it, it's auto.

The whole flyout has a fixed size but the NodeTypeMatch textview is sized as Auto, so it will compress the other views sized as * (the buttons) to make space for itself while possible.

I'm not sure about this one.
We are calling this from the onClose but there is no guarantee that the preferences have actually changed.
Plus the underlying object we care about is the PreferenceSettings instance and one can subscribe to that.
This can be modified from the API as well not only from the dialog.
However the Preferences dlg is modal so we should only do the update onClose when the dialog is present.

But I don't think we need to do the real time update so I'm ok with removing this.
So I would say to only consider the options on first occasion like the flyout show.

Its weirder if its not realtime as the visual state gets desynchronized with the internal state. Its fine if we reload the view each time the user opens and closes the preferences, which shouldn't happen too often while the flyout is still visible.

We can have the best of both if we introduce an object to represent the latest copy of the preferences settings we're interested in and comparing with it, but it could introduce maintenance bugs when modifying the code and not updating that object.

So, I'd prefer it to load every time instead of get bugged when not refreshing. Plus, this may be useful for other parts of the application that would benefit from dynamically updating.

Let's rename it then OnPreferencesClosed or something and maybe make it internal.

Can't make it internal as we're using it from another assembly (the autocomplete view extension) but we can rename it

We can access internals from our assembly since we have this [assembly: InternalsVisibleTo("NodeAutoCompleteViewExtension")].

But thinking more about it maybe we can avoid it all together and be more inline with the way other settings are handled.
So how about we define out DNA event in preferences for all the DNA settings and subscribe/react to it from the extension as usual.
The preferences is modal so we'll just need to postpone the action on Iddling - we do this in other contexts as well.

Updated

Very nice! Now we also have the api scenario covered and better handling of multiple req that could come from anywhere.

to be removed