Everyone appreciates clean, simple interfaces like the one you have, so I would not want to mess that up. If you are already [independent of my requested ehancement] going to provide a general-purpose mechanism to expose and allow edit/change of properties/parameters kept in the SharedObject, then, "Yes", you should have a Boolean and a Button. But if you quickly query your installed base of users, I think that almost everyone would accept a simple change of behavior, without any change in the user interface.
The changed behavior just becomes:
a. if there is a value in the QNAME field when the user exits, restore it on start up.
b. if there is a value in the QNAME field when the user saves to the clipboard, honor it as a filter.
Ok, so someone will complain -- I suspect very, very few. For the person who feels cheated by an auto-restored filter, it is quickly removed.
For the person who feels cheated by the filtered clipboard contents, I agree, that one is a little testier, since I can imagine legitimate use cases for having 'everything' in the dump, even when you are focused on a few objects from some new library. That does seem to require a change to the user interface, but if you are NOT already planning a general-purpose way to examine/edit the contents of the SharedObject, then it would seem that the least intrusive change would just be to have two menu items: Save Filtered and Save Unfiltered.
I'll be happy with either solution.
Thank you.