The problem is that if another panel opens, that panel is not tied to our HTML output window, for example opening the Find dialog does not allow us to press return to search in the HTML output, and if we open a modal dialog, when that modal dialog is disposed, the *main window* will be brought to front (not the previously focused panel).
This effectively reverts commit 92953099e6.
This provided value during early development, but has been unused for years, and it would generate too much noise if converted to os_log.
So better to just remove it all and add os_log statements as needed.
This was required when we linked each framework as its own thing, which we do not do anymore, and if we do go back to this system, we can simply have symbols public by default.
Some targets were including headers from frameworks not specified in their link dependencies. For a clean build this could cause an issue because the header was not available at the time of building the target.
The updated link dependencies are also based on what a target’s tests require. Ideally tests would have separate link dependencies, but as we don’t want to maintain this manually, this will have to wait until the build system automatically handles link dependencies.
Currently the commit command uses constants from the CommitWindow framework but should actually not be linked with it. However, the optimizer will strip dead code, so it should not result in much if any difference in the resulting binary and does solve a build dependency issue.
Some commands clearly should not share output window frame, OTOH it might be tedious having to position every new command used (if the default position is undesired).
We should probably re-use last command’s frame if there isn’t already a frame stored for the command (that’s what TextMate 1.x did). It might also be possible to group commands via its semantic class, so all run commands use the same window frame, though currently semantic classes have unique (language) suffixes.
The latter is updated via a dispatch queue and thus might be delayed (to after end of current event loop cycle). This is relevant when WebView itself terminates the URL loading and calls the “WebView should close” delegate method.
Here the HTML output view property has been updated (via the WebView delegate method) but the command runner has not yet executed the completion code (which updates it’s “is running” state).
The motivation for using a panel was to avoid the window from becoming main (so key equivalents would be sent to the document window, if not handled by the HTML output window). Unfortunately window ordering ignores non-main windows when a window is closed meaning that bringing up the Find dialog from an HTML output window and then closing it, would bring the current main window to front, eclipsing the HTML output window.
