This is some initial state framework to allow saving the hwnd settings between attaching and detaching. It is only stored in memory for the life of the app, uses the HWND id itself to decide if the same window (with a pid check as well in case of reuse). I am sure once rules/etc come along it can be extended further.
There are two problems one of which is pretty easy to resolve the other I am less sure on. The less-obvious one is the multi-united sets instance problem. If you have two UnitedSets apps running detach a hwnd from one and attach to another it would not preserve state as they dont have communication between them. I think from a stability point not having one single executable manage multiple windows is probably a good idea but to fix this will mean either storing that data in a durable fashion (ie to disk) syncing that data with other instances when changed (what happens when a new instance starts up?) or allowing another instance to ask us if we know about HWND X. The last isn't bad but would result in some delay on attach which is more jarring to the user (although could do async). For now maybe it is acceptable that multi-instances won't have the shared state.
Of course looking at this it would seem like this is gearing up for the split / multi-pane support. I think there is value in potentially doing multi-pane at a per app instance rather than per tab so tabs would still be independent (just repping a slice of the pane). Assuming though a tab is shared by multiple panes/hwndhosts then a potential solution would be:
hwndhost has some reference to its parent tab, this would allow you to get the tab name for example. For my restore code if the incoming hwnd had a custom name previously and the current tab does not then it overrides the custom name, otherwise it leaves it alone.
To show POC I moved detach tab to under the display name but clearly not what one would want in the app itself
Open for direction and can update the PR form there.
Do not merge this.
This is some initial state framework to allow saving the hwnd settings between attaching and detaching. It is only stored in memory for the life of the app, uses the HWND id itself to decide if the same window (with a pid check as well in case of reuse). I am sure once rules/etc come along it can be extended further.
There are two problems one of which is pretty easy to resolve the other I am less sure on. The less-obvious one is the multi-united sets instance problem. If you have two UnitedSets apps running detach a hwnd from one and attach to another it would not preserve state as they dont have communication between them. I think from a stability point not having one single executable manage multiple windows is probably a good idea but to fix this will mean either storing that data in a durable fashion (ie to disk) syncing that data with other instances when changed (what happens when a new instance starts up?) or allowing another instance to ask us if we know about HWND X. The last isn't bad but would result in some delay on attach which is more jarring to the user (although could do async). For now maybe it is acceptable that multi-instances won't have the shared state.
I ran into a problem I am not sure the best solution on. Under the tab options flyout there is a "Detach Tab" button. Now this calls detach on the hwndhost directly rather than calling the detach method on the tab itself. I think we should always be calling detach on the actual tab, but wasn't sure the best way to do so. I thought about passing the tab in, but the problem is: https://github.com/FireCubeStudios/UnitedSets/blob/4f59eb97e136f56e49dd50e1ce9e646bc453b4b9/UnitedSets/Windows/Flyout/Modules/Tab%20Settings/MultiWindowModifyFlyoutModule.xaml.cs#L24-L27
has no reference to the tab itself.
Of course looking at this it would seem like this is gearing up for the split / multi-pane support. I think there is value in potentially doing multi-pane at a per app instance rather than per tab so tabs would still be independent (just repping a slice of the pane). Assuming though a tab is shared by multiple panes/hwndhosts then a potential solution would be: hwndhost has some reference to its parent tab, this would allow you to get the tab name for example. For my restore code if the incoming hwnd had a custom name previously and the current tab does not then it overrides the custom name, otherwise it leaves it alone.
To show POC I moved detach tab to under the display name but clearly not what one would want in the app itself
Open for direction and can update the PR form there.