[Libreoffice-bugs] [Bug 54021] EDITING: Fields in tablecontrols of a form could not be moved/sorted

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Sat Dec 5 23:35:40 UTC 2020


https://bugs.documentfoundation.org/show_bug.cgi?id=54021

Julien Nabet <serval2412 at yahoo.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |caolanm at redhat.com

--- Comment #48 from Julien Nabet <serval2412 at yahoo.fr> ---
Caolán: trying to understand how to trigger move action with Robert's example
(the pb with Lionel's file is a bit different since the first issue to deal
with is how to retrieve the connection in case of a registered database - here
Bibliography - which must be used)

To make some tests, I used this patch:
diff --git a/dbaccess/source/ui/browser/sbagrid.cxx
b/dbaccess/source/ui/browser/sbagrid.cxx
index 65b30505fbfc..467bb77ca2e7 100644
--- a/dbaccess/source/ui/browser/sbagrid.cxx
+++ b/dbaccess/source/ui/browser/sbagrid.cxx
@@ -1075,7 +1075,7 @@ void SbaGridControl::DoColumnDrag(sal_uInt16 nColumnPos)
         return;

     rtl::Reference<OColumnTransferable> pDataTransfer = new
OColumnTransferable(xDataSource, sField, xAffectedField, xActiveConnection,
ColumnTransferFormatFlags::FIELD_DESCRIPTOR |
ColumnTransferFormatFlags::COLUMN_DESCRIPTOR);
-    pDataTransfer->StartDrag(this, DND_ACTION_COPY | DND_ACTION_LINK);
+    pDataTransfer->StartDrag(this, DND_ACTION_MOVE | DND_ACTION_LINK);
 }

I think it might rather require here DND_ACTION_COPYMOVE (to have Move action
by default and Copy if I type Ctrl Key when dragging field) but I wanted to be
sure to test with DND_ACTION_MOVE.
I put some traces in vcl/unx/gtk3/gtk3gtkframe.cxx, I confirm ACTION_MOVE is
well detected.

Then I noticed https://developer.gnome.org/gdk3/stable/gdk3-Drag-and-Drop.html
"
GDK_ACTION_MOVE
Move the data, i.e. first copy it, then delete it from the source using the
DELETE target of the X selection protocol.
"

I searched about "DELETE target" and found
https://developer.gnome.org/gtkmm-tutorial/stable/sec-dnd-signals.html.fr#dnd-signal-move 
"
drag_data_delete: Gives the source the opportunity to delete the original data
if that's appropriate.
"

So I wonder if the pb isn't the missing drag_data_delete (at least for gtk3).
Trying to understand all this, I noticed this comment in
vcl/unx/gtk3/gtk3gtkframe.cxx
// For LibreOffice internal D&D we provide the Transferable without Gtk
// intermediaries as a shortcut, see tdf#100097 for how dbaccess depends on
this

it corresponds to:
https://cgit.freedesktop.org/libreoffice/core/commit/?id=73f84ab139cb1d2564f9292fba08d69a0ab822c1
"
Resolves: tdf#100097 dbaccess self-dnd depends on getting its own transferable
on drop that it set on drag. It does some uno tunnel foo to drag the data it
needs back out of it in some grotesque fashion.

So we have to follow the same style of hackery as under MacOSX to detect
on drop that there is an active drag started by ourself and so use that
active drag's transferable as the source transferable for the drop, rather
that use the intermediate universal GtkDnDTransferable.
"

Now I suppose we must add this signal but I got no idea how to implement this.
Of course there will still be how to apply this on other envs like Mac, Win,
Kf5,..

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20201205/f1c15ed3/attachment.htm>


More information about the Libreoffice-bugs mailing list