Drag & Drop

[sirherrbatka]

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.

[sirherrbatka]

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.

[pvdk]

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

[sirherrbatka]

Actually, that's my plan.

[sirherrbatka]

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.

[sirherrbatka]

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?

[sirherrbatka]

*sigh*

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

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

[sirherrbatka]

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?

[Zini]

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.

[Zini]

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.