Bugzilla – Full Text Bug Listing
| Summary: | Editor drag and drop corrupts project explorer | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Sascha Konrad <konradsa> | ||||
| Component: | UI | Assignee: | Platform-UI-Inbox <Platform-UI-Inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | ericwill, nobody, psuzzi, sxenos | ||||
| Version: | 4.6 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Sascha Konrad
Is there any difference in the behavior between GTK3 and GTK2? This is my GTK version: org.eclipse.swt.internal.gtk.version=2.24.23 How do I switch to GTK3? I tried `export SWT_GTK3=1`, but doesn't seem to work. (In reply to Sascha Konrad from comment #2) > This is my GTK version: > org.eclipse.swt.internal.gtk.version=2.24.23 > > How do I switch to GTK3? I tried `export SWT_GTK3=1`, but doesn't seem to > work. What version of RHEL are you running in your 'backend' ? (In reply to Sopot Cela from comment #3) > (In reply to Sascha Konrad from comment #2) > > This is my GTK version: > > org.eclipse.swt.internal.gtk.version=2.24.23 > > > > How do I switch to GTK3? I tried `export SWT_GTK3=1`, but doesn't seem to > > work. > > What version of RHEL are you running in your 'backend' ? Red Hat Enterprise Linux Server release 6.6 (Santiago) Any update Stefan? Is there a way to disable the dragging and dropping via some configuration setting? Because once in a while, I drag and drop a text editor, and then I have to restart Eclipse since it corrupts my views. Very annoying!!! I really don't think we should accept this change for the final release considering the side effects it is creating for my configuration. I can't believe I am the only one having this issue. > I can't believe I am the only one having this issue.
I think you might be. Thousands of people are using the new builds and nobody else has reported this. It seems quite likely that the Exceed onDemand Client is related to the reproduction steps. I think if anyone else had encountered such a serious bug, they'd have said something.
Given the choice between fixing editor splitting for you by reverting the change and fixing it for everyone else by leaving it in place, I don't think we serve the userbase as a whole by reverting it.
FYI, GTK3 is the default. To enable GTK2 you need to use SWT_GTK3=0.
(In reply to Stefan Xenos from comment #6) > > I can't believe I am the only one having this issue. > > I think you might be. Thousands of people are using the new builds and > nobody else has reported this. It seems quite likely that the Exceed > onDemand Client is related to the reproduction steps. I think if anyone else > had encountered such a serious bug, they'd have said something. > > Given the choice between fixing editor splitting for you by reverting the > change and fixing it for everyone else by leaving it in place, I don't think > we serve the userbase as a whole by reverting it. > > > FYI, GTK3 is the default. To enable GTK2 you need to use SWT_GTK3=0. I understand where you are coming from Stefan, but I won't be the only one, it will affect hundreds of people at the company I work, and expect to get more complaints coming once the final version gets released. Fixing a minor feature for most while creating severe issues for a others (albeit a smaller group of users) is not acceptable either. Rather than going towards a solution, we are just swapping one problem for another. Two years ago, I was the first one to complain that drag&drop has become broken in Luna (https://bugs.eclipse.org/bugs/show_bug.cgi?id=434524), and I was told the same thing, that I am the only one and that no one else seems to be affected. Guess that wasn't the case either. All these features were working fine before Luna, I don't understand why two years later this is still such a buggy mess. For some reason, I can't get Eclipse to use GTK3 in my installation, it always defaults to GTK2 for some reason. I have tried various environment variables, jdk settings, etc. to no avail. If you have any suggestions, then please let me know. (In reply to Sascha Konrad from comment #7) > For some reason, I can't get Eclipse to use GTK3 in my installation, it > always defaults to GTK2 for some reason. I have tried various environment > variables, jdk settings, etc. to no avail. If you have any suggestions, then > please let me know. I don't believe RHEL 6.6 has GTK3 support -- GTK2.24 is the latest GTK available for that release. > Fixing a minor feature for most while creating severe issues for
> a others (albeit a smaller group of users) is not acceptable either
The thing you're claiming is broken - the inability to split the editor area - is a subset of the things that have been fixed for everyone else. Calling it a minor feature when it occurs for others but not when it occurs for you is a double standard.
Besides the fact that you first observed this in RC1, is there anything else to suggest that this is related to the D&D fix?
Could you explain what you were doing previously to split the editor area if you weren't using Drag & Drop?
Have you ever seen this without using the Exceed onDemand Client? (In reply to Stefan Xenos from comment #9) > > Fixing a minor feature for most while creating severe issues for > > a others (albeit a smaller group of users) is not acceptable either > > The thing you're claiming is broken - the inability to split the editor area > - is a subset of the things that have been fixed for everyone else. Calling > it a minor feature when it occurs for others but not when it occurs for you > is a double standard. > > Besides the fact that you first observed this in RC1, is there anything else > to suggest that this is related to the D&D fix? > > Could you explain what you were doing previously to split the editor area if > you weren't using Drag & Drop? The workaround I was using for the split issue was to install Vrapper and use the :vs command to create a split. The reason I believe that it got broken by this d&d change in RC1 is that before, while splitting via d&d did not work, I could drag editors from one side to another of an existing split fine without corrupting the Project Explorer. Now since RC1 d&d from one side to another, as well as dragging to split the editor, both have the same effect of corrupting the Project Explorer. I am not saying the issues you are trying to address shouldn't be fixed, but my quarrel is that it was broken for a whole of 2 years, so it cannot affect that many people either. And yet at the very end of the Neon development cycle (RC1 after all) such a patch gets introduced that obviously has the side effect of breaking something that was working fine before, and there is no time anymore to get to a point where both issues can be satisfactorily addressed. (In reply to Stefan Xenos from comment #10) > Have you ever seen this without using the Exceed onDemand Client? There is not other client supported by my company to try out, and I am also told that the performance of any alternatives won't be satisfactory either. It seems quite plausible that this is a problem in VWrapper or Exceed onDemand Client.
I'd suggest you:
- revert the change locally and see if it makes any difference.
- test this without vwrapper or Exceed onDemand Client.
Please report your findings.
> so it cannot affect that many people either
It affected everyone on GTK. Including you, as you mentioned above.
It seems very unlikely to assume that the majority of GTK users are also using both Exceed onDemand Client and VWrapper.
(In reply to Stefan Xenos from comment #13) > It seems quite plausible that this is a problem in VWrapper or Exceed > onDemand Client. > > I'd suggest you: > - revert the change locally and see if it makes any difference. > - test this without vwrapper or Exceed onDemand Client. > > Please report your findings. > > > so it cannot affect that many people either > > It affected everyone on GTK. Including you, as you mentioned above. > > It seems very unlikely to assume that the majority of GTK users are also > using both Exceed onDemand Client and VWrapper. Ok, I did some more testing with some fresh downloads of M7 and RC1. As expected, Vrapper has nothing to do with it. This is the behavior I see: M7: As expected, d&d to create a split is not possible. But I can pull an editor into a separate window, and then I can drag editors between these windows without a problem. No corruption. RC1: D&d to create a split is possible now, but corrupts Project Explorer. The same happens when dragging editor to another side of a split, or dragging it to a separate window. Any d&d action of an editor now seems to corrupt Project Explorer. Every time a restart of Eclipse is required to restore normal functioning. I am not an Eclipse developer, so I don't have a setup where I can modify the Eclipse code and try out different things. Again, I am not saying that the current patch is bad and that we shouldn't fix the d&d to split issue, but there may just be some minor tweaking required to the current patch to prevent the corruption. Good news, testing with RC3, Project Explorer corruption doesn't seem to be an issue anymore. Looks like something got fixed that took care of it. |