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.
Product Version = NetBeans IDE 7.4 (Build 201310111528) Operating System = Linux version 3.2.0-57-generic running on amd64 Java; VM; Vendor = 1.7.0_45 Runtime = Java HotSpot(TM) 64-Bit Server VM 24.45-b08 I have multi-row tabs enabled. (Also --fontsize 16 in netbeans.conf). LAF = Nimbus. Occasionally, the labels on the left most tabs will be cut off on the left side. It seems to happen most frequently when the GUI designer is shown. Many times, switching from the GUI designer to the source view causes the problem to go away.
Created attachment 143016 [details] screen shot of problem
Cannot reproduce in Product Version: NetBeans IDE Dev (Build 20131210-226ec9ff52fb) Updates: Updates available Java: 1.7.0_45; Java HotSpot(TM) 64-Bit Server VM 24.45-b08 Runtime: Java(TM) SE Runtime Environment 1.7.0_45-b18 System: Mac OS X version 10.9 running on x86_64; UTF-8; en_US (nb) Reporter, can you provide exact steps to reproduce the tab state as on your screen shot?
Here is a scenario that produced the failure for me today: - 15 files open in the editor area. 3 rows of tabs. - A GUI form file opened in the source view - Switch to the Design view for the current file. This causes the right side of the window to show the Palette and Properties views and the tab labels become cut off. I'll attach new screen shots for this.
Created attachment 143061 [details] Before: source view open
Created attachment 143062 [details] After: design view, palette showing, tabs cut off
(In reply to mclaborn from comment #5) > Created attachment 143062 [details] > After: design view, palette showing, tabs cut off Well, there's nothing wrong in this screen shot. There's simply not enough horizontal space to put all tabs into three rows.
Something has changed in this behavior recently, probably in 7.4. If there are more tabs than will fit in the space, shouldn't the overflow windows be moved to the "extras" (sorry, don't know the correct term) menu, accessible via the down arrow on the right side? Failing that, if a portion of the tab must be cut off, it would be more helpful if it was the right side of the tab that was truncated, as the left side is the more significant (at least in my case).
Antoher thought: I would be OK with a temporary overflow to a 4th row of tabs (even though the limit in the options is 3) to allow for the palette, etc to show.
Multi-row tabs are just several JTables in a JScrollPane so there's no straightforward way of implementing 'right-hand side cut-off'. A temporary extra row isn't a solution either. You can open 100 files and there's no way to fit them into 4 (or 5 or 6 ...) rows. The tabs could show only a sub-set of opened files. But only as a new switch in Options window as not everybody would be happy with this solution. Please feel free to file a new RFE for it (or reopen and change this bug to 'Enhancement') but I'm closing this as 'invalid' as I don't see any error in the multi-row tab behavior.
Changing this from a bug to an enhancement request (even though I feel like it is really a bug). Please find a better way to handle the situation when multi-line tabs are enabled and there are too many tabs to fit in the allowed space. My primary objection is that it is unacceptable to cut off the left side of a tab. From a user perspective, moving least recently used files to the extras menu (down arrow) until the tabs all fit is an acceptable solution.
Created attachment 143428 [details] another screen shot See this most recent screen shot. Multiple tab rows is still set at 3. The last tab on the right is barely visible. Shouldn't it be on a new row? This really seems like a BUG to me rather than an enhancement request. Or is this a different problem?
(In reply to mclaborn from comment #11) > Created attachment 143428 [details] > another screen shot > > See this most recent screen shot. Multiple tab rows is still set at 3. The > last tab on the right is barely visible. Shouldn't it be on a new row? > > This really seems like a BUG to me rather than an enhancement request. Or > is this a different problem? Please file it as a new bug (with steps to reproduce), thanks.
Done. Bug 240032