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.
In tabs-1.png I have a bunch of editor tabs open - more than will fit on screen at once - and I am on the rightmost one. Fine. I press Shift-ESCAPE and get to tabs-2.png. Note that there is plenty of extra horizontal space available now, but the tabbed control does not use it. Annoying. I press Alt-RIGHT then Alt-LEFT and now have tabs-3.png, which is what I wanted to have after just pressing Shift-ESCAPE but didn't get. Now I press Shift-ESCAPE again to unmaximize. I get tabs-4.png which is definitely bad. Note that TestUtil is the selected tab, yet it is not shown on screen in the tab row at all! So I try to show it again using Alt-RIGHT Alt-LEFT. Now I get tabs-5.png, which is OK but again is not showing as many tabs as will fit. If I now press Alt-LEFT Alt-LEFT Alt-RIGHT Alt-RIGHT I can get back to tabs-1.png, which is what I wanted to have displayed after I unmaximized. Please fix the tab control to ensure at all times that: 1. The selected tab is always visible after maximizing or unmaximizing, or otherwise changing the window size, if it was visible before. 2. If the last tab in the row is completely visible (not cut off) then as many tabs to the left of it are being displayed as possible.
Created attachment 12181 [details] First stage - OK
Created attachment 12182 [details] Second stage - BAD
Created attachment 12183 [details] Third stage - OK
Created attachment 12184 [details] Fourth stage - BAD
Created attachment 12185 [details] Fifth stage - BAD
Sorry, forgot: in dev 031116.
Yet another aspect of the problem: if in e.g. tabs-1.png you press Ctrl-F4 twice, closing "FileOwnerQueryTest" and "TestUtil" but leaving "ProjectManagerTest" open and selected, you would expect "ProjectManagerTest" to be on the right, showing perhaps "AntBasedProjectType" and "ProjectManager" to the left of it. Instead it shows only "ProjectManagerTest" on the left, with a left scroll button behind it, and nothing to the right of it.
Well, 1. is easy - we listen for component events on the container and call makeVisible(getSelectionModel().getSelectedIndex()) on a resize event. 2. Is a little harder, but probably not too hard - as I recall, the only check is that at least the last tab remains on the screen (offset may not be greater than the number of tabs). It's a little more work to calculate the available space at each offset change and ensure that if the last tab is visible, a maximal number of tabs are to the left of it. The hard part is maintaining this state on arbitrary add/removes.
Tim: arbitraty add/remove? What's that? Opening of source editor from explorer or something different? If something different and non usual, we can happily ignore it IMO.
Basically, we could do a little more to ensure the selected tab is always visible after changes in the UI. I'm not sure what you're asking re arbitrary add/remove.
Should be fixed - any resize event will ensure that - the selected tab is made visible - the maximum possible number of tabs are displayed (no more big right margin)
x
Hmm, I don't think this is fixed - at least not in sources I am playing with right now (Jan 23). It seems sometimes I will have a source file on the rightmost tab which is modified (so " *" displayed in tab), and it is displayed right in the middle of the screen (so not fixed). Then if I Ctrl-S or Ctrl-Z to unmodify it, suddenly it jumps to the end of the row, but too far, so it is actually truncated a bit.
Created attachment 13079 [details] Screenshot when a file is modified; note that the right side of the window tab area is wasted even though there are plenty of tabs to show on the left
Created attachment 13080 [details] Screenshot after reverting the modification; note that the last tab is cut off unnaturally
Ah, this changed with the fix for another issue (user doesn't know what file he's modifying if the tab is offscreen) - now it will ensure the tab is visible if the title changes. Should be simple to fix, if the title changes and the tab is already visible, no change should happen.
Created attachment 13625 [details] Another example - had several files open, last one selected, then Shift-ESC; note selected tab is not fully displayed
Created attachment 13626 [details] Same after Alt-Left and Alt-Right; note that although now the selected tab is fully visible, the leftmost tab (the only one not fully visible) is cut off unnecessarily far to the right
Created attachment 13627 [details] Same after Alt-Right; now mostly OK (showing leftmost tab) though the rightmost tab is cut off abruptly (no "..." displayed) which may not be intentional
Okay, I don't know if it's perfect (if that's possible), but I suspect it's better enough that I can close this issue.
verified in NB 3.6 RC1