Drag & Drop

Involved development of the OpenMW construction set.
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Drag & Drop

Post by Zini »

This issue consists of 3 parts:

1. UniveralId / MME

Pretty much every piece of data in a loaded ESM/ESP file can be addressed by a CSMWorld::UniversalId. These pieces of data are what we are going to drag around, so we need a way to convert between QMineData and UniversalId. Each UniversalId::Type (except Type_None) should get its own MIME type.

2. Drag sources

For now we only have rows in record tables (this excludes the verification result table; no point in dragging anything here to anywhere else). Each row translates to a UniversalId. Please note that you should be able to drag multiple rows at once. Also note, that rows in the same table can contain different types in some cases.

We should investigate the possibilities of using the record icons instead of a rendering of the actual rows when dragging. For mixed type drags (only an issue with the referenceable recrod table), we may need a new icon, which our icon design team should be able to provide.

3. Drop destinations

For now we only have fields in record tables as drop destinations. Each table cell should define its mime type(s). This could either been done with a new ColumnBase::Role or by splitting up ColumnBase::Display_String.

If the mime type matches, the dragged content should be filled into the destination cell. If the drag holds multiple UniversalIds, we probably should use the first one (we will later have destinations outside of record tables that accept multiple IDs).


Important: Drag and Drop between sources and destinations that do not belong to the same document are forbidden (this may make it necessary to also encode an identifier for the document when creating a QMineData instance; not sure about that).
At one point we may allow copying over records from one document to another via drag and drop, but that is out of scope for this issue.

Note: More drag sources and drop destinations will follow later. Again, this is out of the scope for this issue, since these features aren't implemented yet.
CramitDeFrog
Posts: 20
Joined: 18 Aug 2013, 00:29

Re: Drag & Drop

Post by CramitDeFrog »

Try to help me understand the workflow, from the user's point-of-view, when using OpenCS. I understand that this feature will allow rows, these have MIME types, to be dragged around, but where will they be dropped? Wouldn't all the different tables be different MIME types which should be prohibited?
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Drag & Drop

Post by Zini »

You don't drag rows. You drag UniversalIds. These can be dropped at any place where an UniversalId of the matching type is used. For example you could drag a skill UniversalId to a skill field in a row of race table.
graffy
Posts: 142
Joined: 06 Feb 2013, 19:30

Re: Drag & Drop

Post by graffy »

Just thought I might weigh in on this one...
Zini wrote:This issue consists of 3 parts:

1. UniveralId / MME

Pretty much every piece of data in a loaded ESM/ESP file can be addressed by a CSMWorld::UniversalId. These pieces of data are what we are going to drag around, so we need a way to convert between QMineData and UniversalId. Each UniversalId::Type (except Type_None) should get its own MIME type.
That shouldn't be a big deal. I essentially did that to enable dnd for the content selector. Actually, you can subclass QMimeData, so that your custom data class directly translates, but my stab at that proved problematic. Easier to simply encode / decode it directly. I think what I did with EsmFile (will change that to ContentFile one of these days :) ) was to have the class itself produce the data in a QByteArray, which makes it immediately accessible to the QMimeData structure.
Zini wrote:2. Drag sources

For now we only have rows in record tables (this excludes the verification result table; no point in dragging anything here to anywhere else). Each row translates to a UniversalId. Please note that you should be able to drag multiple rows at once. Also note, that rows in the same table can contain different types in some cases.

We should investigate the possibilities of using the record icons instead of a rendering of the actual rows when dragging. For mixed type drags (only an issue with the referenceable recrod table), we may need a new icon, which our icon design team should be able to provide.
Multi-selection dragging sohuld be no big deal. It's supported (I think) in the content selector dnd code, even though the list view is set to single-selection.

w.r.t. the icon-dragging, using icons should be simple enough - I think I stumbled across examples of how to do that at one point...
Zini wrote:3. Drop destinations

For now we only have fields in record tables as drop destinations. Each table cell should define its mime type(s). This could either been done with a new ColumnBase::Role or by splitting up ColumnBase::Display_String.

If the mime type matches, the dragged content should be filled into the destination cell. If the drag holds multiple UniversalIds, we probably should use the first one (we will later have destinations outside of record tables that accept multiple IDs).
I don't see any issues with implementing that - once the initial dnd code is developed.

Zini wrote:Important: Drag and Drop between sources and destinations that do not belong to the same document are forbidden (this may make it necessary to also encode an identifier for the document when creating a QMineData instance; not sure about that).
Since two documents by definition represent two separate models, I don't think it should be an issue. The drop operation would require a lookup of the source index of the UniversalId item(s) that were dragged. If the index is from another model, Qt throws an exception, I believe. Try/catch would probably take care of it. Otherwise, as you indicate, an additional model-specific identifier could be implemented. Not certain how, but I don't suppose it'll be much of a problem.
CramitDeFrog
Posts: 20
Joined: 18 Aug 2013, 00:29

Re: Drag & Drop

Post by CramitDeFrog »

Sorry for the delayed response. I've been working on a project for school.

graffy, thank you for the breaking it down how to do it, but it's not why I'm confused. I am new to the project, so I don't understand the workflow that is being created in OpenCS. Zini's explanation is giving me a good idea.

Zini, each row is represented by an UniversalId, right? I was using rows and UniversalId interchangeably.
graffy
Posts: 142
Joined: 06 Feb 2013, 19:30

Re: Drag & Drop

Post by graffy »

Zini was correcting a more abstract issue - he's differentiating between the data and the view of it. That's the distinction of Model-View architecture. What we're concerned with is using drag/drop to relocate/reference data within the model (atomically, the "UniversalId"). The necessary changes to the view follow that.

To answer your question in terms of the view... I *think* the drag operation will always begin with a row, but your drop operation isn't always to another row in a table. I didn't design this thing, though, so don't hold me to that. :)
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Drag & Drop

Post by Zini »

Drag source and drop destination each can be anything.

Drag sources: Mostly rows, that is correct. But it also could be something completely different (e.g. a cell in the region map or an object in the scene view).

Drop destinations: These will never be rows. When dropping on a table, we drop into a cell. But there are many other types of drop targets (e.g. scene view or a filter field).
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Drag & Drop

Post by Zini »

A few clarifications and additions:

Regarding 1. UniversalID / MME

It seems the wording in my original posting was somewhat ambiguous. I wrote "These pieces of data are what we are going to drag around" while actually what we are dragging around are the universal IDs of these pierces of data.

Regarding 3. Drop destinations

a. Inserting data into cells must be done via commands, because otherwise we would bypass the undo stack. Do not manipulate table fields directly.

b. Since the original posting a new type of destination has been added: filter fields. This is a complex topic and we can address it when the basic drag and drop is implemented.
User avatar
sirherrbatka
Posts: 2159
Joined: 07 Aug 2011, 17:21

Re: Drag & Drop

Post by sirherrbatka »

I will do part 1 and see If I can do anything more without being annoying to death ;-)
User avatar
Zini
Posts: 5538
Joined: 06 Aug 2011, 15:16

Re: Drag & Drop

Post by Zini »

Okay. I also offered the task to gus. He is still busy familiarizing himself with the editor. I suggest you coordinate with him; maybe even split up the task. Its big enough and easily splittable.
Post Reply