Allow for custom save/open commands. #1463
Conversation
There was a problem hiding this comment.
This looks great. I think that duplication between druid and druid-shell is okay, and there is precedent in types like MouseEvent (and I think at least one other that is slipping my mind?) the reality is that druid works at a higher level than druid-shell and will often need to store different information.
The docs are also excellent.
I'm really not worried at all about the breakage.
I do think it might be nice if we eventually expose better API for this via EventCtx; I think that using commands for some of this stuff is maybe a bit of hack, even if that's how we end up handling it internally? But what we have works just fine for now, so I don't think this is a priority.
druid/src/win_handler.rs
Outdated
| @@ -78,7 +78,7 @@ struct Inner<T> { | |||
| app: Application, | |||
| delegate: Option<Box<dyn AppDelegate<T>>>, | |||
| command_queue: CommandQueue, | |||
| file_dialogs: HashMap<FileDialogToken, WindowId>, | |||
| file_dialogs: HashMap<FileDialogToken, (WindowId, Selector<FileInfo>, Selector<()>)>, | |||
There was a problem hiding this comment.
I would probably create a named struct that holds these items, instead of a 3-tuple?
| // WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. | ||
| // See the License for the specific language governing permissions and | ||
| // limitations under the License. | ||
|
|
There was a problem hiding this comment.
let's add a brief //! module comment?
This is a proposal for addressing #1455; it allows setting custom selectors for open and save panels.
Some comments:
FileDialogOptionscode duplication, but I couldn't think of another way to present a nice API.Selectorisn't defined indruid-shell...SAVE_AScommand. I think this is justified because the way it's currently being dispatched (and handled, in my experience) doesn't need the runtime choice between having a save path and not having one.