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.
Seen this in a couple of other UI's - instead of the Dock Into menu as the means of docking components, the following model could be used: - "Drag" a tabbed component (for example, the Filesystems tab). - Tabbed component should become a seperate window when the mouse leaves the tab area - If you drop it over the tabs of another mode, it gets docked into that mode - If you drop it somewhere else, it remains its own floating window. This could be enhanced with some visible feedback (for example, using a rectangle to highlight the tabbed area if that component is the target during a drag operation. It could be further enhanced with highlighting side/bottom/top areas of a window supporting top/left/right/bottom docking (make these areas the dock targets when the mouse pointer dragging the tab is within nnn pixels of the border). Note it will be necessary to know the correct z-order of overlapping windows in order to not end up sometimes docking into a window that is underneath another.
Target milestone -> 3.3.1.
Target milestone -> 3.4
Evaluation: DnD fow window system was developed by UI team for 3.3 version, namely by Rosta Levy. Due to unstability of provided solution it is not part of 3.3. For the 3.4 release cycle, DnD support will be maitained by core UI members. We'll need expertise from UI team to specify how exactly should DnD for winsys behave. Ui team, please, elaborate and take input from following sources: - core.netbeans.org/windowsystem contains older version of how DnD should behave - please finalize it. - we would need consultation of code your team wrote to maintain properly Impl sidenotes for core UI: a) understand written code, test it, see if it's usable and what parts are usable b) estimate and write down work that needs to be done c) refactor code to fit nicely into winsys logic d) ensure stability by writing tests wherever possible
UI team requests this as high priority.
Created attachment 4886 [details] Prototype: put it in lib/patches dir and run on jdk1.4
There is a prototype zip, put it in lib/patches dir of your last build and try out. Should help UI to make decisions in spec. You can drag TopComponents on their tab from one container to another container. There are many lacks: - cannot drop to the MultiContainerImpl (will be implemented) - cannot start drag from container containing only one TC (needs spec) - cannont drop to the same container at diff contraint (will be implemented) - cannot drop to the "free" area to move out of container (will be implemented) - cannot drag&drop to change tab order (needs spec). - cannot do copy drag (will be implemented for CloneableTopComonents) - size, image of cursor (needs spec) - changing cursor over drop target (needs spec) - kind of "drag over" gesture of drop target component (red rectangles) color, shape, etc. (needs spec).
Notes: There are up to now some issues: - There is a problem if during DnD is accessed clipboard (evne for read only typically for update Paste Action) from AWT thread, it causes freeze on jdk1.3 and couple of seconds delay in jdk1.4. Up to now solved to replane the accessing of clipboard for read out of AWT thread. - (MDI) The jdk internal frames switch on/off their glass panes by default so its necessary to keep it in consistent way during/after DnD, since the glass pane is ised for drop target drag over indications. It seems is solved. - the last new one, most significcant. If during DnD is poped op modal dialog it freezes. The AWT machinery is waiting for finishing the dialog but DnD wasn't finished and it prevents the mouse, key events to be propagated to the dialog.
The last issue (DnD + modal dialog = freeze) seems to be signifficant. So I created a bug for jdk, #4645584.
There seems to be possibility to hack the problem decsribed above. One thing prevented to close the dialog is set default close operation to DO_NOTHING_ON_CLOSE, which is used for our dialogs created via NbPresenter. The could be set listening on the opening of dialogs and in case they are opened during DnD change their default close operation to be able to be closed and thus recover the app. That seems to be only event passed thru DnD machinery to the dialog.
someone mistakenly put the milestone keyword into the status whiteboard field. Fixed
Created attachment 5297 [details] put in lib/patches in NetBeansIDE-dev-200204040100 build
There is a patch of milestone_2. Start drag on tab of TopComponent in container. Note it is working currently only under jdk1.4 and higher. These things should work: 1) Cursor indication, (note there are still missing the final icons, currently used my temporary ones only) 2) DnD to the same container under different constraint (if in split container). 3) DnD to another container 4) DnD to "free" area outside ide, in MDI also to the desktop pane area. 5) Container indication of possible drop operation.
Forgot to mention 6) Possible change drop operation. When pressed Ctrl indicaties copy drop operation, (successful drop in that case is valid only for TopComponents implementing TopComponent.Cloneable interface.
Created attachment 5308 [details] Updated patch with icons and fixed #22123.
Tried the latest patch on a recent dev build and was unable to run it - hangs on starting modules with tons of the same exception - probably something that changed since the patch was written. java.lang.NoClassDefFoundError at org.netbeans.core.NotifyException.<init> (NotifyException.java:87) at org.netbeans.core.NotifyException.<init> (NotifyException.java:40) at org.netbeans.core.NotifyException$1.run (NotifyException.java:144) at java.awt.event.InvocationEvent.dispatch (InvocationEvent.java:178) at java.awt.EventQueue.dispatchEvent (EventQueue.java:443) [catch] at java.awt.EventDispatchThread.pumpOneEventForHierarchy (EventDispatchThread.java:190) at java.awt.EventDispatchThread.pumpEventsForHierarchy (EventDispatchThread.java:144) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:138) at java.awt.EventDispatchThread.pumpEvents (EventDispatchThread.java:130) at java.awt.EventDispatchThread.run (EventDispatchThread.java:98)
A couple issues: - Drop targets don't seem to be working too well (I'll attach a screenshot to demonstrate) - More intuitive behavior if you drop a window where there is no target (e.g. on the desktop or some other inappropriate place), then the system should assume you want to create a new floating window containing the component (MDI if over the MDI desktop area, SDI if over the system desktop). For a sense of what I'm thinking of, try it in Eclipse. - The performance is terrible - 7-10 second hang between releasing the mouse and the docking happening on a WinXP machine @ 933Mhz, 256Mb, Windows L&F. - Re performance: Is the JDK's drag-and-drop support really the right tool for the job? I'm guessing that's what's responsible for the performance issues. Something that was a little more hardwired to the NetBeans window system might be slightly to maintain but offer reasonable performance. E.g.: - keep a hashmap of positions of opened, visible modes and regions within them that can be targets keyed by their boundary rectangles. - Iterate the rectangle set every few drag events and highlight the appropriate rectangle. - If the drop action happens over a target rectangle, fetch the Mode and call dockInto() Unless there is some bottleneck in the patch code, I don't think the performance is reasonable right now.
The performance is windows jdk1.4.x problem (see issue #22372). Unfortunately it seems I can't workaround the problem. About how to implement it: I don't see another way than using the jdk framework, There was already an attempt to by-pass it last year and it wasn't finished succesfully. Personally I don't believe there is another way. There could be better indication of possible drop in Desktop pane, which could also be a drop target with showing the indications rectangles, but I don't know how to indicate it the "outside" area.
Fixed in [trunk] Note 1: The feature runs on jdk1.4.0 and higher. Note 2: There is still the perf problem on WindowsOS (see issue #22372), therefore it is currently available there on switch (-J-Dnetbeans.winsys.dnd=true) only. In case the bug will be solved for 1.4.1 it will be enabled for that version also for Windows OS.
>The performance is windows jdk1.4.x problem (see issue #22372). >Unfortunately it seems I can't workaround the problem. Ick. >About how to implement it: I don't see another way than using the jdk >framework, There was already an attempt to by-pass it last year and >it wasn't finished succesfully. I wrote a prototype of what I was talking about (it does depend on a JTabbedPane being the parent of TopComponents, but this could be made pluggable, and Modes could expose tab rectangles to determine which component is being dragged). It works and is fast on Windows, but is not set up for docking into different quadrants of windows. I'll attach it tomorrow (it's on my laptop). >Personally I don't believe there is another way. >There could be better indication of possible drop in Desktop pane, >which could also be a drop target with showing the indications >rectangles, but I don't know how to indicate it the "outside" area. Change the cursor? Something that indicates a window with a * to indicate a new window? -Tim
verified in [nb_dev](20020426) - TM3 build I have filed issues: P2 issue 22372 - DnD is too slow (Windows only) P2 issue 22858 - After DnD Source Editor, whole Editor window is grey P3 issue 22622 - It's impossible Drag Properties Window while shown "No Properties" P3 issue 22123 - MDI after Escape drop -> drop indicator visible
*** Issue 25653 has been marked as a duplicate of this issue. ***
Resolved for 3.4.x or earlier, no new info since then -> closing.