Implement drag and drop for model viewports

[m-7761]

setAcceptDrops(true); appears in modelviewport.cc. I think the event is handled in qtmain.cc. On Windows this produces an (/) icon when dragging the file over the window.

[zturtleman]

qtmain.cc only handles macOS open file from Finder / drop file on dock icon. It's unrelated to model viewport drag and drop which is not implemented (see ModelViewport::dragEnterEvent). I've disabled setAcceptDrops(true); to get rid of the (/) icon on Windows in 00409354154987ca1c4fba6598b50d7ec620b66d.

It might be nice to support it. Though it's unclear if it should open a new window or merge with existing model.

[m-7761]

I was just about to post that code (dragEnterEvent) but I still don't see why turning that on produces an (/) icon. I expect turning it off (not turning it on) does (/). That's how it is on native Windows apps.

Qt's icon differs from the native icon. It might be using the COM drop system instead of WM_DROPFILES. It might require more set up if so.

[zturtleman]

I don't have Windows set up to test it and :no_entry_sign: doesn't ever occur on GNU/Linux (or macOS?). My assumption based on your report was that setAcceptDrops(true) was causing the :no_entry_sign: and only over model viewports but from your last comment I take it that it's actually the whole window and that this is normal on Windows? So there was no bug just incorrect commit message.

[m-7761]

Yeah I suppose. I mentioned the icon because it's not what you'd expect from setAcceptDrops(true). Maybe Qt doesn't implement that API for child windows. Normally it would enable WM_DROPFILES. wxWidgets has a similar API that works to remove the (/) icon.

On a somewhat related note, I removed the feature that opens files into an "empty" window, because I thought it was needless complexity and inconsistent user-experience. But it might tie into that MacOs feature too. If so, it would be better if it's not ambiguous if the app is starting normally or via a drop. On Windows opening a file into a program is equivalent to passing the file(s) on its command-line. This feature (I'm unfamiliar with) appears to work by opening the program without a command-line and then generating a drop-event. Hence it doesn't know if it should spawn an empty window or not.

[m-7761]

It might be nice to support it. Though it's unclear if it should open a new window or merge with existing model.

Here is the criteria I just set up. Prior to this I was always opening in a new window, but I think this is correct:

        bool getEdited()const
        {
            return !getSaved()||m_undoMgr->canUndo()||m_undoMgr->canRedo(); 
        }

Edited: Oh, I noticed you asked about merging, not just whether to use a new or existing window. Maybe you didn't mean literally merging, but I don't know how to merge unless we used a Ctrl modifier or something. I hadn't even thought of that.