Drag & Drop

Involved development of the OpenMW construction set.
User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: Drag & Drop

Post by sirherrbatka » 28 Jan 2014, 13:15

I think We can do this together more effectivly. Gus will provide better coding skills, and I will help with my current knowledge about the CS. :-)

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: Drag & Drop

Post by sirherrbatka » 03 Feb 2014, 12:25

Ok, does anybody know how to convince Qt to use enum as type of the QMimeData? Documentation on this Qt metatype is not that great.

User avatar
pvdk
Posts: 517
Joined: 12 Aug 2011, 16:34

Re: Drag & Drop

Post by pvdk » 03 Feb 2014, 13:45

I think the best approach would be to subclass QMimeData and reimplement hasFormat(), formats(), and retrieveData(), or access the data directly.

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: Drag & Drop

Post by sirherrbatka » 03 Feb 2014, 13:49

Actually, that's my plan. ;-)

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: Drag & Drop

Post by sirherrbatka » 03 Feb 2014, 17:27

After small consultation on KDE mailing list I see another approach to the problem. We can pass accepting drops to the drop target and use only one type for all our universalid types. This would simplify mime handling, but would require a little bit (like 3 lines) of extra code in the drop sites.

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: Drag & Drop

Post by sirherrbatka » 04 Feb 2014, 11:53

Ok. On my DragDrop branch it is now possible to basicly drag individual universalids, however only individuals. Groups are not handled yet.

I think that If we want to have single icon for multi-drag we should allow storing vector of the universalids in the qmimedata subclass this way our subclass will be responsible for returning the correct icon that can be used as pixmap in the QDrag object. This should not be a problem and SHOULD work correctly but not sure if this is actually right design direction: we will tightly couple QDrag, our subclass and all drag sources (mostly tables at the moment).

@Graffy: what do you think about this?

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: Drag & Drop

Post by sirherrbatka » 05 Feb 2014, 11:54

*sigh*

Ok, I will just pretend that I'm software designing expert. :roll:

@Gus: Draging works. Now we need to implement mime for drop destination.

User avatar
sirherrbatka
Posts: 2121
Joined: 07 Aug 2011, 17:21

Re: Drag & Drop

Post by sirherrbatka » 11 Feb 2014, 10:29

I'm just investigating columns. It seems that they store only a record, but no information about universalid at the moment (so no information about the type).

I think We could simply implement some static templates (somewhere) to convert types of the records into the strings that could be used as part of mime formats. I'm not sure if it is birght idea, but certainly it would make things easier. What do you think about this, zini?

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Drag & Drop

Post by Zini » 11 Feb 2014, 12:17

That is probably not the way to go. I need to look some things up to answer properly and now I have some RL stuff to do. Will get back to you in an hour or so.

User avatar
Zini
Posts: 5134
Joined: 06 Aug 2011, 15:16

Re: Drag & Drop

Post by Zini » 11 Feb 2014, 13:11

Each table gives additional information about the content of a column via the cells in horizontal header. The file you want to look at is apps/opencs/model/world/columnbase.hpp. The display role specifies what kind of information are displayed in the column. Currently all IDs are specified as Display_String. But we could very easily split that up on a per UniversalID-type (or type group) basis.

Another option would be to expose the ColumnId (see apps/opencs/model/world/columns.hpp) in a new role (Qt::UserRole+2) in the same fashion as described above.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests