This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Drag and drop some top components a few times. Now put them all back into a split pane, being sure to put at least two of them together as tabs. Now click on those tabs. If you click quickly enough, at least one of those tabs will jump away, and will either form its own split pane cell or will join another tab inside of the split pane.
I guess this is problem which also occassionally happens to me. :-) The problem is you wanted just to click on the tab, e.g. to select it, but in fact you clicked on it and moved as well, which generated mouse drag event, which consequently has started additional DnD and possibly moved the top component to another place. I'm sure about this since the window DnD can be triggered only by mouse drag event, no other way is currently possible.
Peter, This one worries me a lot. Assuming your explanation is correct (and it sounds like it is), I think we still have a problem. In every other DnD situation I've ever encountered (any OS, any application), dragging an object a little bit does not move it. Granted, there may be some corner cases, e.g., if an object is very close to a legitimate drop target and the user accidentally drags a couple pixels towards the target. Or, the user might get a spurious drag cursor, indicating that she accidentally started a drag. So by contrast our window system/DnD implementation will be seen as very temperamental and jumpy. Perhaps all we need to do is to turn down the sensitivity of drag initiation. Is this possible? It seems like a sensible idea, since most drags will be started when the user clicks in the middle of the window and starts dragging... or in the middle of a tab. If we wait for a few pixels until we initiate a drag, then I think there is no harm done. We are unlikely to miss the case when the user really wants to drag something. If drag sensitivity is a parameter, do you think it would be possible to expose it on the command line so that it could be experimented with? Or could it be an option (yet another option ;-) I would be happy to help figure out the best value. While we are considering this, I hope you will forgive me if I reopen the issue. Thanks! Dirk
That's fine Dirk, I'll look at the sensitivity of the drag start, I guess I could ignore e.g. first mouse drag event and if whitin some interval come the next one just then to start the drag, will look at it.
Seems to be not very fine the ignoring of the first event. The drag then seems to be starting like with some delay. What about to change the start gesture of move drag to be started the way Shift + mouse drag = drag move. Crtrl + mouse drag = drag copy. Those above posisbilities work, but beside it work also No modifier + mouse drag = drag move, which causes the problem, We could eliminate it and avoid the unintentional drag. What do you think about that?
Dusan, please make a ui decision.
I think Peter's proposal is preferable to having to put up with window jumpiness. Windows jumping around of their own accord is the kind of little thing that could make users seriously underestimate the IDE's quality. (Either that or they will think that the IDE is haunted...) Since window drag and drop isn't a frequently performed action, it's probably OK to make users use the modifiers (assuming that there are no conflicts with, say, editor key bindings).
Target milestone was changed from '3.4' to TBD.
Because Window System v1 will not be supported from now by our team, all old winsys issues (now "core/window system v1" issues) are going to be closed as WONTFIX. Changes in API which emerged both from UI spec and problems with adjusting to the older API are described in the document http://core.netbeans.org/windowsystem/changes.html. It shows also recommends how the client code should be adjusted to the new window system. If you think this issue apply also to the new winsys then change the subcomponent (to "core/window system") and REOPEN it.
issue doesn't apply to new window system - verified