Often, when opening or saving a file from some application program, one has to use the file dialog to navigate to a directory already open in some Dolphin window. I wished the known places in the standard file dialog included all directories currently active in Dolphin. Obviously, this would need some way of communication between the file dialog and Dolphin.
A straightforward solution would be to add a D-Bus command to Dolphin that allows to retrieve the currently active directory (or, rather, URL) for each of its windows. Some script can build a FUSE collection of links from that. This FUSE pseudo-directory can be added by hand as another known place to the file dialog.
However, this solution may be frowned upon for security reasons because the unrestricted access via D-Bus can bleed info on secret directories. As a countermeasure, before answering the D-Bus call in Dolphin, one may check the PID of the caller first, but that looks fragile? Any better ideas? Completely different approaches? I will try and develop such a solution.
It’s a good idea. There’s a longstanding feature request for this: https://bugs.kde.org/show_bug.cgi?id=412668
If you’d like to work on it, that would be fantastic!
Also, keep a close eye on Kitty - also yazi’s integration with zoxide and fzf - impressive options for using zoxide and/or fzf fuzzy stuff when opening or saving files…
Already when I open Dolphin, I’d hit F4 and type ‘z kitty’ to go to that folder… or hit ‘y’ to open yazi and then ‘z’ or ‘zi’ or ‘Z’ to locate a destination and jump there… But once a file is open in Kate, to then decide to save it in ‘helix’ folder isn’t so trivial; if you could hit ‘z’ for zoxide, ‘zi’ to list or ‘Z’ to fzf find… that’d be really cool…
Just learned from that “bug” report that one can drag&drop files into the file dialog to change its current directory. 
That’s quite helpful but quite unexpected behavior, at least for part-time Windows users.
The D-Bus solution would be very easy to accomplish. Any thoughts on the security implications, however?
Here is an approach that looks secure but overweight to me: Build a FUSE file system that, when accessed, sends a specific (novel) D-Bus message to Dolphin instructing Dolphin to display a list of its current directories. The user selects one of these and Dolphin returns that path as answer to said D-Bus message. (Things get more complex because typically Dolphin will have several windows = instances.)
Now that I learned from you comment that one can set the file dialog’s directory through drag & drop, I can envision another option: a list generated by Dolphin that consists of drag-&-droppable pseudo files. This would, however, only work in the standard file dialog, whereas a FUSE file system would be more open.
Revised idea: Add a button to the file dialog that starts a one-time D-Bus broadcast containing the info on where to send the answer. Every Dolphin window reacts by displaying a small bubble top-level overlay with its current path. When the user clicks one of these bubbles, that bubble window calls back directly to the file dialog with the selected path, then announces that a choice has been made so that all bubbles close. If the user cancels, clicks elsewhere (how to detect that?!?), or time runs out, a cancel signal is broadcasted (by whom?!?) so that the bubbles disappear.
Still feels somewhat ugly to me?! 
And how to make that accessible to blind users?
UI-wise, I’d add a new section that includes folders open in Dolphin to the Places panel shown in the open/save dialogs.
In terms of the implementation, I don’t think I can help you there, sorry.
Still learning more about the issue at hand.
The standard file dialog uses ~/.local/share/recently-used.xbel and ~/.local/share/user-places.xbel, which means the recently used files and directories are pretty much public knowledge. I take it that, hence, my security concerns have been completely overblown.
It would suffice for Dolphin to update ~/.local/share/user-places.xbel any time its active location changes. I’m still hesitating, however, because that would lead to many write accesses.
It seems I have to add that my wording “pretty much public knowledge” is meant figuratively. Go figure.