I worked this issue on and off over the last 2 weeks. It can be done. I'm untrained on dojo/dijit UI classes so it's been slow going. I was able to get the setting page to display and function. Didn't get around to making the changes to disable writing back to the config file because I found a better solution.
I found out that the same query capability at run time was available built into the map. There is a little Up-arrow on a tab at the bottom of the map. If you click on it you see tabs with the different feature layers on them. Each tab has an Options menu with a Filter option. Once I found this functionality I stopped work on this issue.
As for getting the setting page to show up, the setting.js and setting.html files in a widget do not include the Ok, Cancel or Close window buttons. Nor do they include the code to change the widget icon. You'll have to code your own container to load the setting page into. Subtle differences between my container and the container they use caused the display of the fields to be horribly wrong. I had to change a few style settings at run time to get it to work. Since your container may be different from my own, comparing style settings of the page you invoke with your code and the same page invoked with their code will identify the differences.
The key to starting up the page after coding a container for it was finding the lines of code necessary to do so.
A call to
widgetManager.tryLoadWidgetConfig(setting)
asynchronously starts off the load process.
When it returns with a result, you'll need to lang.hitch a function to invoke
widgetManager.loadWidgetSettingPage(setting)
asynchronously. When that returns, place it in your container and run the setting page object's startup() method.
As for the setting object so casually passed around above, I went into the debugger and checked out what was in it when the setting page was invoked in the web appbuilder client. It turns out that all the necessary values to construct a setting object of my own were available as this.* values in the widget.js file.
The setting page appears to write to the config file on startup, which was a bit surprising. I suspect it has to do with setting up an initial default page if one isn't there. As I stopped work on this task about the time I noticed that, I can't add more detail.
As for node.js dependencies, haven't found any. All the code I've had to call to make this happen has been automatically deployed to each application.
I hope this will help others who find themselves wanting to do something similar.