MacViews: Implemented Drag & Drop

ui/views/widget/widget.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "ui/views/widget/widget.h"
 
 #include "base/logging.h"
 #include "base/macros.h"
 #include "base/message_loop/message_loop.h"
 #include "base/strings/utf_string_conversions.h"
@@ skipping 763 matching lines @@
   dragged_view_ = view;
   OnDragWillStart();
 
   WidgetDeletionObserver widget_deletion_observer(this);
   native_widget_->RunShellDrag(view, data, location, operation, source);
 
   // The widget may be destroyed during the drag operation.
   if (!widget_deletion_observer.IsWidgetAlive())
     return;
 
-  // If the view is removed during the drag operation, dragged_view_ is set to
-  // NULL.
-  if (view && dragged_view_ == view) {
-    dragged_view_ = NULL;
-    view->OnDragDone();
-  }
-  OnDragComplete();
+#if !defined(OS_MACOSX)
+  DraggingEnded(view);

[tapted, 2016/05/26 12:31:42]

Hm - x11 spins its own runloop to "force" it to be synchronous.

e.g.

desktop_drag_drop_client_aurax11.cc has (in StartDragAndDrop(..)

  // Windows has a specific method, DoDragDrop(), which performs the entire
  // drag. We have to emulate this, so we spin off a nested runloop which will
  // track all cursor movement and reroute events to a specific handler.
  move_loop_->RunMoveLoop(
      source_window,
      cursor_manager_->GetInitializedCursor(ui::kCursorGrabbing));



RunMoveLoop calls X11WholeScreenMoveLoop which (eventually) does

  base::MessageLoopForUI* loop = base::MessageLoopForUI::current();
  base::MessageLoop::ScopedNestableTaskAllower allow_nested(loop);
  base::RunLoop run_loop;
  quit_closure_ = run_loop.QuitClosure();
  run_loop.Run();

(i.e. that last Run() line will block, running a nested message loop until the
drag is finished).

X11WholeScreenMoveLoop seems to be massively complicated though -- its git log
is huge (lots of corner cases and lifetime bugs :/ ).


Maybe an asynchronous drag and drop is a much nicer way to solve this use case.
But I'm out of my depth here :/. Presumably there's a good reason for it to be
done on x11 the way it is.

+#endif
 }
 
 void Widget::SchedulePaintInRect(const gfx::Rect& rect) {
   native_widget_->SchedulePaintInRect(rect);
 }
 
 void Widget::SetCursor(gfx::NativeCursor cursor) {
   native_widget_->SetCursor(cursor);
 }
 
@@ skipping 559 matching lines @@
   return new internal::RootView(this);
 }
 
 void Widget::DestroyRootView() {
   non_client_view_ = NULL;
   root_view_.reset();
 }
 
 void Widget::OnDragWillStart() {}
 
+void Widget::DraggingEnded(View* view) {
+  // If the view is removed during the drag operation, dragged_view_ is set to
+  // NULL.
+  if (view && dragged_view_ == view) {
+    dragged_view_ = NULL;
+    view->OnDragDone();
+  }
+  OnDragComplete();
+}
+
 void Widget::OnDragComplete() {}
 
 ////////////////////////////////////////////////////////////////////////////////
 // Widget, private:
 
 void Widget::SetAlwaysRenderAsActive(bool always_render_as_active) {
   if (always_render_as_active_ == always_render_as_active)
     return;
 
   always_render_as_active_ = always_render_as_active;
@@ skipping 103 matching lines @@
 
 ////////////////////////////////////////////////////////////////////////////////
 // internal::NativeWidgetPrivate, NativeWidget implementation:
 
 internal::NativeWidgetPrivate* NativeWidgetPrivate::AsNativeWidgetPrivate() {
   return this;
 }
 
 }  // namespace internal
 }  // namespace views