QDrag custom pixmap icon not working in 4.6.0 tp2

[kleimola]

Hi!

If setting a custom pixmap with QDrag's setPixmap(const QPixmap &pixmap) it will follow the drag only for a very short moment and then stop (with artifacts). It also starts by flashing a black background. The drag operation itself works ok. This can be easily seen by compiling the 'puzzle' drag and drop example. Hopefully this will be fixed in the final release. I tried on 4.6.0~git20091218-0maemo1.

>> Johannes <<

[divanov]

http://qt.nokia.com/developer/bugreport-form/

http://bugreports.qt.nokia.com/browse/QTBUG-1692

[kleimola]

If setting a custom pixmap with QDrag's setPixmap(const QPixmap &pixmap) it will follow the drag only for a very short moment and then stop (with artifacts). It also starts by flashing a black background. The drag operation itself works ok. This can be easily seen by compiling the 'puzzle' drag and drop example. Hopefully this will be fixed in the final release. I tried on 4.6.0~git20091218-0maemo1.

Seems that the convenience functionality of movable items with QGraphicsItem::setFlag( ItemIsMovable ) works without problems though. So if the item's pixmap itself is ok as the dragging icon, then reimplementing the mousePress, mouseRelease and mouseMove in e.g. scene for more control will give similar behavior as with custom QDrag (not the MimeData functionality though I think). When using this approach you can skip all the dragEnter, dragLeave, dragMove and dropEvent functions (they seem not to be called without custom QDrag exec?). Since the default convenience functionality starts moving the item immediately (which may be unwanted with Maemo5's finger UI) you can delay it and even separate mouse press from move with this simple reference code example in a reimplemented QGraphicsScene

void MyScene::mouseMoveEvent(QGraphicsSceneMouseEvent *mouseEvent)
{
    if (mouseEvent->buttons() != Qt::NoButton && ourItem.isSelected()) {
        if((mouseEvent->screenPos() - mouseEvent->buttonDownScreenPos(Qt::LeftButton))
            .manhattanLength() > QApplication::startDragDistance()) {
                QGraphicsScene::mouseMoveEvent(mouseEvent);
        }
    }
}

void MyScene::mousePressEvent(QGraphicsSceneMouseEvent *mouseEvent)
{
    if (...) {
        // Don't dispatch mousePressEvent to the item if we don't want to move it
    }
    else
        QGraphicsScene::mousePressEvent(mouseEvent);
}

void MyScene::mouseReleaseEvent(QGraphicsSceneMouseEvent *mouseEvent)
{
    // Let QGraphicsItem handle mouseRelease first (otherwise our setPos() won't work)
    QGraphicsScene::mouseReleaseEvent(mouseEvent);
    if (...) {
        // If we need to cancel the drag or similar, we can reposition the item here
        ourItem->setPos(some_X_otherthanDragResult, some_Y_otherthanDragResult);
    }
}

Let me know if you know a better way or there's something strange here. I wonder if the default convenience functionality is faster/lighter than reimplementing everything with QDrag and the dragevents (when they will eventually work)?

>> Johannes <<

[gnuton]

Hi!
This is not an issue related to Qt itself, but it's an hildon desktop limitation.
If you kill hildon desktop drag & drop animations work fine.

Graphics view items are not affected by this.. problem start if you want to drag an Icon from a widget to another one.
Puzzle Qt example shows the issue. ColorCode example available in extras-devel shows it.

[jonjon.arnearne]

I know this is an old thread, but it was the only one google summoned when i hit this problem with drag/drop in maemo 5.

I found a workaround for this problem from gnuton's reply about hildon-desktop being the problem.

The solution that works for me is to set your application to be full screen.
Dnd works flawlessly, but this of course limits the dnd possibilities between applications, but it works between widgets in your own application at least!

Just call set fullscreen in your widget to work around this problem!

MyQWidget::MyQWidget(QWidget * parent)  : QWidget(parent)
{
setFullScreen();
}