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.
I'd like to request that NetBeans be able to take advantage of the increased screen area when multiple display cards and monitors are present. I beleive the Newer JDK's have methods of determining this now. I suppose what this would look like, and how it would work is really open to discussion, but I'd really like to say have a 'MainWindow' on both screens, andbe able to put any workspace on any screen (Whether or not the same workspace should be allowed on two screen at the same time is debatable.) For example I'd like to have the 'Editing' space on the left and the 'Form Editing' space on the right. Then at some other point I might want the 'Debugging' space on the left and the 'Running' space on the right. etc.etc. You can probably imagine the combinations. This could allow other things to happen. When you Debug, the Debugging workspace could be layed out with it's windows taking up all of one screen, while the other screen actually switches to the 'running' space, and the App you are Debugging appears over there. The 'Form editing' space could also run on one while the regular 'editing' space has the Source Editor window on the other. I'd really like to be able switch workspaces independantly on each screen (with a workspace switcher on each screen,) with no workspaces locked to any particular screen. However other people may instead want to spread a each workspace out across all screens, and have only one workspace switcher that switches both screens at once. I don't know what the trade offs are between these modes, or if it is possible to implement both.
See dicsussion on nbui for further info: http://www.netbeans.org/servlets/ReadMsg?msgId=253335&listName=nbui
Ugh, certainly not for 3.4, no human resources.
I just have a few questions on this... When a user picks 'Window->Dock Into->New Tabbed Window' does NB reparent the widgets in the pane being docked? or are they destroyed and recreated? If they are recreated, then I think a simple 'Other Screen' option could be added to the 'Dock Into' menu that would recreate them with a graphics configuration for the other screen. This would be all I needed I think to spread some items out onto other screens. I would think that NB wouldn't really need to know that the GC used was for another screen once the window was created. I would think that when switching workspaces it would just need to adjust the location and visibility of all the windows 'owned' by that workspace, and the fact that the location was relative to a different origin shouldn't make much difference. If anyone could point me to the right place to look into making a change like this, I think I'd like to give it a shot. I'm just lost as to where to start. -Kyle
Target milestone was changed from not determined to TBD
Should find the jdk API's dealing with this first, don't know about it yet.
So the API should be available since jdk1.4
*** Issue 21231 has been marked as a duplicate of this issue. ***
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
How does this not apply to the new window system? As of today, using 4.0 beta 1, I can't find a way to tell NB to open a window on DISPLAY=:0.1 instead of DISPLAY=:0.0 Am I missing something?
Implemented in main trunk, views and editors now can be dragged and dropped outside of main window on second monitor.