GNOME Bugzilla – Bug 578249
Drag and drop of video on itself restarts it
Last modified: 2009-08-01 19:04:57 UTC
It is possible to drag by inititating drag&drop action with Totem (by clicking on Totem window while playing). This sometimes happens when you just click on the window. Now, if the dragged item is dropped back on Totem, it, Totem restarts playing from the beginning. This is annying. Summary if Totem is activator and beneficient of the d&d, it should not restart the movie. Other information:
Yes, happened to me too when I wanted to double-click the video for fullscreen and my mouse pointer slipped a bit. I have a patch which does nothing when the video window is dragged onto itself. I'll post it as soon as I can build totem again and test it (have to upgrade gtk+).
Created attachment 132993 [details] [review] proposed patch This patch fixes the problem by ignoring the drop when the source_window of the drop is the same as the drag one. It would be a cleaner fix if we didn't have to store context->source_window. But I couldn't figure out what the source_window really is (it's not bvw, it's not totem->win). Does anyone have an idea?
(In reply to comment #2) > It would be a cleaner fix if we didn't have to store context->source_window. > But I couldn't figure out what the source_window really is (it's not bvw, it's > not totem->win). Does anyone have an idea? It's a GdkWindow, so I suspect it's going to be gtk_widget_get_window (bvw) or gtk_widget_get_window (totem->win).
(In reply to comment #3) > It's a GdkWindow, so I suspect it's going to be gtk_widget_get_window (bvw) or > gtk_widget_get_window (totem->win). Hm, I tried that, but here's what I get in drop_video_cb: context->source_window: 0x8c7ef20 context->dest_window: 0x8acf198 gtk_widget_get_window (totem->bvw): 0x8c25640 gtk_widget_get_window (totem->win): 0x8acf198 Maybe it's a GdkWindow the BVW uses internally or something like that?
(In reply to comment #4) > Maybe it's a GdkWindow the BVW uses internally or something like that? Might be bvw->priv->video_window, which would be awkward.
(In reply to comment #5) > (In reply to comment #4) > > Maybe it's a GdkWindow the BVW uses internally or something like that? > > Might be bvw->priv->video_window, which would be awkward. Robin's solution is probably good enough for 2.26. Didn't your patch for GSEAL stuff remove the internal ->video_window?
(In reply to comment #6) > Didn't your patch for GSEAL stuff remove the internal ->video_window? It wasn't my patch, and it only stopped us creating the widget's GdkWindow (the creation was moved to the parent class' realization function) — bvw->priv->video_window still exists. (Quite why I have no idea.)
It's not bvw->priv->video_window either: bvw->priv->video_window: 0x1cb3f00 context->source_window: 0x29f5be0 context->dest_window: 0x1bff3c0 gtk_widget_get_window (totem->bvw): 0x1cb3dc0 totem->win: 0x1b026c0 It might be worth a try to remove bvw->priv->video_window and use the widget's window directly, maybe then context->source_window is something we know. That's what I'm going to try next.
*** Bug 583941 has been marked as a duplicate of this bug. ***
*** Bug 584229 has been marked as a duplicate of this bug. ***
Any news Robin? If not, feel free to commit the current patch with some additional comments in the struct.
bvw->priv->video_window is used for the zoom functionality, so it can't be removed. I couldn't find the window that is the drag and drop source. I also tried setting GTK_TARGET_OTHER_WIDGET but that didn't work either (maybe because of the same underlying reason). So, I'll commit this patch.
Committed to master and pushed. Should I also commit it to gnome-2-26?
(In reply to comment #13) > Committed to master and pushed. Should I also commit it to gnome-2-26? Yes please
Done!
*** Bug 590475 has been marked as a duplicate of this bug. ***