Community
Participate
Working Groups
Using GTK3 I cannot drag and drop a file in the package explorer to a new location.
Please provide the OS and GTK versions.
(In reply to Dani Megert from comment #1) > Please provide the OS and GTK versions. Ubuntu 13.10 vanilla Output of apt-cache policy libgtk2.0-0 libgtk-3-0 libgtk2.0-0: Installed: 2.24.20-1ubuntu1 Candidate: 2.24.20-1ubuntu1 Version table: *** 2.24.20-1ubuntu1 0 500 http://de.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages 100 /var/lib/dpkg/status libgtk-3-0: Installed: 3.8.6-0ubuntu3.1 Candidate: 3.8.6-0ubuntu3.1 Version table: *** 3.8.6-0ubuntu3.1 0 500 http://de.archive.ubuntu.com/ubuntu/ saucy-updates/main amd64 Packages 100 /var/lib/dpkg/status 3.8.4-0ubuntu3 0 500 http://de.archive.ubuntu.com/ubuntu/ saucy/main amd64 Packages
Still a problem using Ubuntu 13.10 and Luna I20140422.
Some details: You can drag and drop if and only if the element is not selected beforehand.
See Snippet91 for similar behavior. http://git.eclipse.org/c/platform/eclipse.platform.swt.git/tree/examples/org.eclipse.swt.snippets/src/org/eclipse/swt/snippets/Snippet91.java
In Control.dragDetect, GDK_MOTION_NOTIFY doesn't seem to get sent in the case of a tree. If I force dragOnTimeout to true then it works. Now the question it, why is GDK_MOTION_NOTIFY not getting sent...
(In reply to Marc-Andre Laperle from comment #6) > If I force dragOnTimeout to true then it works. ...but then bug 344686 is back.
Created attachment 243091 [details] Drag and drop snippet Updated snippet to include an example for Table and List (in addition to Tree).
I think having bug 344686 back only in the case of GTK3 is much better than not having DND. Patch: https://git.eclipse.org/r/26531
I did a bit of testing: GTK 3.4.2 (Ubuntu 12.04) works as it is GTK 3.8.6 (Ubuntu 13.10) has the bug GTK 3.10.8 (Ubuntu 14.04) has the bug but GTK3 is not the default (as set in the Eclipse code)
Same behaviour here. Im using "Gnome Ubuntu 13.10". Cant drag and drop items on project explorer and package explorer. Also i cant resize columns in some views (eg: "Markers" view), but i can resize columns in others (eg: "Error Log" view).
Also, i can confirm that drag and drop works if I force eclipse to load GTK2 instead of GTK3. To disable GTK3, set the environment variable SWT_GTK3=0 before running eclipse.
Not working for me either (Linux, GTK 3.12.2). Works on GTK 2.24.24 with SWT_GTK3=0. I only tried it on Trees (Snippet91).
Still worth fixing for 4.4.2.
Same problem on: -Eclipse Platform Version: Luna (4.4) Build id: I20140606-1215 -Slackware 14.1 (Linux 3.15.8) -gtk+3-3.8.2-i486-2 Using the SWT_GTK3=0 workaround works fine for me.
Created attachment 248167 [details] Drag and drop with List to Button I'm investigating this issue now. My first observation is that it's not a Global Drag and Drop issue. I have reproduced it with trees (gtk3.10.10), but it does not reproduce with things like dragging from a list to a button to change the button text. (see snippet attached). I'll investigate further.
Further observations on Gtk3. As a note, DND works if you drag an item outside the container's border very rapidly and then move the element back into the container. (re-arranging works with the attached Drag and drop snippet) I tested with Gtk3.4, Gtk3.8, Gtk3.10. DND is glitchy in all of them. I'll continue to investigate this issue.
(In reply to Marc-Andre Laperle from comment #6) > In Control.dragDetect, GDK_MOTION_NOTIFY doesn't seem to get sent in the > case of a tree. If I force dragOnTimeout to true then it works. Now the > question it, why is GDK_MOTION_NOTIFY not getting sent... There are two mechanisms for Drag and Drop. - Click & Timeout (500 ms) - Click & Mouse movement Timeout based DND works as usual. (In Tree/List/Table it is hard-code-disabled). But Mouse-Movement based DND doesn't work globally at all (in gtk3), not just for trees. (I tested with other controls like Label/Button etc..) In Control: 2340: eventPtr = OS.gdk_event_get () indeed doesn't return a GDK_MOTION_NOTIFY when there is movement inside the container. I'll continue to investigate.
Hi Leo. I'm not sure it explains everything but there is some information about mouse motion changes in this blog post: http://blogs.gnome.org/alexl/2013/11/04/the-modern-gtk-drawing-model/ more interestingly, this comment and the links included in it: http://blogs.gnome.org/alexl/2013/11/04/the-modern-gtk-drawing-model/comment-page-1/#comment-1843
Hello Marc, Thank you for the links. I read them thoroughly and it helped me form a better understanding of motion events. I don't think SWT's DND is affected by the motion compression business thou. The reasons I think this is is as following: 1) Motion compression was introduced in gtk 3.8, but I have tested, DND motion events are not sent even as early as gtk 3.4. 2) Motion compression reduces the number of motions sent from 120/200 hertz to a single event per frame buffer. I.e a 'reduction' in events. But in our case, we're not getting any motion events at all within a container. For example, if I change the time out in DragDetect (long timeout) to 2 seconds, then there are still no motion events sent in these two seconds. But if I missed something, or if you have other interesting articles, please let me know. As things stand, my plan is as following: - I'm currently reading up on DND in GTK, (useful lecture notes btw: http://www.compsci.hunter.cuny.edu/~sweiss/course_materials/csci493.70/lecture_notes/GTK_dragndrop.pdf ) - I'll write a native C program that does DND the way SWT does it and then I'll investigate gtk2 / vs gtk3 behavior. - Once I've reproduced it and fixed it in the gtk3 side, I'll try to port the logic into swt.
I'm still working on this issue, but this is a list of my current observations: ### Not due Compression As stated above, issue is not due to compression as it occurs pre gtk 3.8 ### Motion notify works in native gtk2/gtk3 Motion_notify is sent in native GTK2 as well as GTK3.10. As an example, here is some native gtk2/3 code to illustrate; (It sends motion notify if you hover over a button) https://raw.githubusercontent.com/LeoUfimtsev/gitPicStore/master/gtk2_3_Motion_notify.c This means it must be something that SWT does that messes with the motion-notify event in the queue. ### SWT mixes low lvl gDt and high level gTk for DND. I noticed that SWT uses a mix of gDt and gTk. In native GTK, a 'drag-begin' event is sent when a drag begins. However, in SWT, it works as following: > gtk click event is handled. > while loop that checks low level gDk motion events. > if there are none, it sleeps. > If there is and it exceeds DND threshold distance, it manually triggers a drag-begin. > it then continues with higher level gtk-like dnd handling. Observe that there is a while loop with sleeping. ### SWT hasn't implemented 'drag-begin' signal In SWT, the 'drag-begin' event is not registered, nor handled at all. I wrote some code to register and handle it. However, I noticed that it too only get's handled if you drag the mouse outside the container. ### SWT's sleep/loop logic might be the cause Next I observed that in SWT, the dragDetect is called inside a gtk_button_press handler. dragDetect loops & sleeps and manually reads the event queue. I wrote native Gtk code to reproduce this logic and have observed that motion-notify event is blocked and there are no motion-notify events in the event queue either. I.e motion-notify is blocked in such logic. code: https://raw.githubusercontent.com/LeoUfimtsev/gitPicStore/master/gtk2_3_motion_notify_is_blocked.c However, what is not explained is why it worked in gtk2 and not in gtk3. ### Current plan: My next step will be to remove the thread sleep in swt and instead implement a drag-begin handler to see if drag-begin starts correctly. I will keep you posted on my findings.
I submitted a fix, Please review: https://git.eclipse.org/r/#/c/36717/ In GTK3, gdk no longer emits a motion event if a thread sleeps && a drag operation has not begun yet. To work around this, we monitor the mouse for movement on the SWT side instead: I tested: - Various controls (Trees/Tables/Buttons/Labels), DND now works. - Various gtk versions (gtk2, gtk3.8, gtk3.10, gtk3.14) (gtk 3.4 a bit flaky, but works) Please let me know your thoughts. As a note: I`ve researched alternative ways to fix this. For instance I`ve experimented with setting the source widget as DragSource with gtk_drag_source_set() and implemented a drag-begin listener. But the problem with this approach is that we lose the notion of 'timeout' and there are issues with composite widgets that have checkboxes inside them. Also going ahead with this approach would require a major rewrite of SWTs DND logic.
Leo, would you please test with org.eclipse.swt.examples.dnd.DNDExample ? DND still doesn't work in it.
Thank you for pointing this out. I'm investigating. Its peculiar. (with the patch applied) so far I've narrowed it down to layout issues: If I take two labels and make them drag/drop text between each other, then placing the labels: - Inside a composite & grid layout, then DND works. - Inside a 'group', DND starts correctly but no events reach the target. I'll investigate further.
Created attachment 248915 [details] DND works 50% of the time. I've written some tests. My observation is that DND (with the patch) works about 50%~ of the time. - 'Source' works all the time (afaict). - 'Target' works in some *container* widgets, not in others. Layouts do not seem to affect functionality (Fill/Row/Grid etc..) Tested working: - composite (Fill/Grid/Row) - nested composite - scrolled composite - sashform - coolbar - Label/Tree/Table/Button Tested NOT working: (i.e source works, target does not) - group (Fill/Grid) - tabfolder - composite inside a group. (i.e group blocks drop events by the looks). SWTs DNDexample uses 'group', thus it is not working. I'll investigate further.
In the Group/TabFolder widgets, in the createHandle() method, they combine input regions: gtk_widget_input_shape_combine_region() (thank you Alex.K for pointing this out). This causes them to 'steal' DND from their child widgets. Thus with those two containers DND doesn't work atm. I.e if you instead register drop-target on the Group/TabFolder (as oppose to a child widget), then DND works with them. This is problematic behavior. I'll investigate how I can fix that.
Created attachment 248965 [details] Group/TabFolder/ExpandBar DND fail. ExpandBar with ExpandItem also has the issue that DND can start but no DND Target events reach it's children. Unlike Group/TabFolder, ExpandBar/ExpandItem do not use region shaping.
*** Bug 444356 has been marked as a duplicate of this bug. ***
The DND breackage for group is caused by an issue with how children are added to the SWT Group container. We first need to address that in: https://bugs.eclipse.org/bugs/show_bug.cgi?id=453827
*** Bug 454489 has been marked as a duplicate of this bug. ***
Common part has been pushed - http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=d75a51833886fedc47fd1992d6bcd02c341104d6
With the ExpandBar completed, I traversed the majority of SWT GTK widgets and tested their DND (see below). In addition, all DNDExample bits work and DND snippets work in GTK3 now. I.e, for individual Widgets/Composites, all appears to work well now. However, in dynamically created sub-shell situations, there still appears to be issues, see Bug 457476. =============================== # Working/Tested GTK Widgets (Gtk2/Gtk3) as of ExpandBarFix 2015.01.14 ## Composites - Group (fixed) - ExpandBar (fixed) - TabFolder (fixed) - Composite (already working) - ScrolledComposite (already working) - SashForm (already working) # Widgets - Text - Button - Lable - Toggle Button - Checkbox - Canvas - Tree - Table - List - Text - Styled Text - Combo
Not sure if that is related but in 4.5.0.I20150126-2000 I do not get a review anymore if I DND a view. The UI looks frozen and flickers if I move the view around and drop it. Tested on a vanilla Ubuntu 14.04. Using SWT_GTK3=0 makes DND for views to work fine again.
w(In reply to Lars Vogel from comment #33) > Not sure if that is related but in 4.5.0.I20150126-2000 I do not get a > review anymore if I DND a view. > > The UI looks frozen and flickers if I move the view around and drop it. > Tested on a vanilla Ubuntu 14.04. Using SWT_GTK3=0 makes DND for views to > work fine again. What do you mean by 'review'? Do you mean the tracker (green preview squares?).
Sorry "preview" would have been the correct word.
(In reply to Lars Vogel from comment #35) > Sorry "preview" would have been the correct word. Seems kinda related. Although this issue was originally opened for DND on the SWT level, and then gradually expanded to the platform.Ui level also. i.e, In SWT, DND is defined for SWT widgets in package org.eclipse.swt.dnd. But the entire drag-and-drop business for parts and their preview is implemented in Workbench: org.eclipse.e4.ui.workbench.addons.dndaddon For example, if you set a break point in: org.eclipse.e4.ui.workbench.addons.dndaddon.DragAgent.dragStart(DnDInfo) Then try to drag a part, it should pause there. May I suggest you create a separate bug and link back here?
Moving the target from 4.4.2 to 4.5 as this bug is still work in progress and is dependent on more bugs that need to be fixed... as of now, only bug 453827 has been backported to 4.4.2 but that itself is quite an improvement for DND in GTK3.
Hi Leo, Do you think this bug can be fixed by RC1 which is scheduled for next week?
(In reply to Arun Thondapu from comment #38) > Hi Leo, > > Do you think this bug can be fixed by RC1 which is scheduled for next week? This specific bug (428852) is more of a linker to concrete bugs. The once that are crossed off the list are done and integrated (I believe?). I'm working on the overlapping DND issue, which is still a mystery. I'm not sure if this'll be done in time. The coordinate issue I haven't looked at yet.
(In reply to Leo Ufimtsev from comment #39) > > This specific bug (428852) is more of a linker to concrete bugs. > The once that are crossed off the list are done and integrated (I believe?). Yes, that is correct. I'm reducing the severity of the bug as most of the critical problems have been fixed already and DND is not exactly broken anymore on GTK3... > I'm working on the overlapping DND issue, which is still a mystery. I'm not > sure if this'll be done in time. The coordinate issue I haven't looked at > yet. No problem, lets target to fix the remaining ones for 4.5.1, I'm changing the target milestone accordingly.
I removed the DnD coords issue as it's not specific to Gtk3. (also it appears to be a bug in Gtk* and not SWT). As such, when the patch for Bug 457476 (overlapping widgets dnd) is merged & bug is closed, this bug can be closed also.
Last fix was backported, all dependencies now closed. This is fixed for now.
*** Bug 199059 has been marked as a duplicate of this bug. ***
*** Bug 298381 has been marked as a duplicate of this bug. ***
