apache
enable "sort document list by project" by default.
as discussed on the dev list, this proposes to tweak the default setting of the documents list dropdown of the editor.
option can be changed back in the main options window:
tools -> options -> appearance -> document tabs -> "Sort opened documents list by default" checkbox
This won't influence already made user settings, only the out-of-the-box default.
This area got some fixes #3299 and pending improvements recently.#4792
This affects the appearance of tabs, not just the document list dropdown. Probably the UI tweaks that were done in https://github.com/apache/netbeans/pull/4286 should be adapted to the "Sort opened document list by project" mode as well before making this the default.
@eirikbakke thats funny. I was wondering who quietly changed the tabs back, wouldn't have guessed that it has something to do with this setting :)
IIRC it uses the multi-row tab renderer in this case, and code for those needs looking at to work properly with #4286
So, sorry, -1 to this change until we can fix that issue.
I think the problematic code is here - https://github.com/apache/netbeans/blob/master/platform/core.multitabs/src/org/netbeans/core/multitabs/impl/TabDataRenderer.java#L234 And I think it's currently not LAF-specific, and the position changes depending on where the tabs are located. Still, maybe as quick fix could just switch "under"line position for top and bottom tab positions?
And this seems to cover all the settings where they take over - https://github.com/apache/netbeans/blob/master/platform/core.multitabs/src/org/netbeans/core/multitabs/prefs/SettingsImpl.java#L57 Which is almost all of them! :shrug:
I don't think multitabs is ready to become the default tab renderer implementation yet. There were a lot of improvements to the FlatLAF renderer that should be ported over to multitabs first:
- https://github.com/apache/netbeans/pull/4286 (besides the underlineAtTop part)
- https://github.com/apache/netbeans/pull/4335
- https://github.com/apache/netbeans/pull/4349
(Example adjustments that are missing on multitabs: left editor border on 150% HiDPI scaling, lighter text color on non-active tabs, vertical alignment of text and X buttons against Project/Files/Services sidebar and the document tab area, adjustments to horizontal margins around text and X buttons etc.)
I can take a whack at this at some point, though it may take me a while to get around to it...
@eirikbakke ok, I convert this to draft so that nobody merges it by accident.
If anyone wants to close this completely feel free to do so.
added dev build label so that it is easier to test, build is linked on the build summary page for 7 days.
@eirikbakke since you did the tweaks to the regular tabs, would you like to do them for those tabs here too?
@mbien I started looking at it. Applying the past improvements to multitabs is going to be a somewhat bigger project, as it's a completely different implementation/code path with more generic functionality (multiple rows, group by project, tabs on left/right/bottom etc.). I might get back to it later.
For reference (as Neil linked earlier), the logic for deciding when multitabs are used instead of regular tabs is here: org.netbeans.core.multitabs.prefs.SettingsImpl.isEnabled
And the entry point for multitabs is at org.netbeans.core.multitabs.TabbedImpl.
I was wondering about that before: if multitabs can do everything what o.n.swing.tabcontrol can do, why are there still two implementations in use?
@mbien I don't know the history of the two implementations, but it seems like the regular tabcontrol implementation was much easier to customize for skinning purposes, so that's the implementation that was customized in all the old LAFs.
If at some point we get multitabs to support all the FlatLAF options that now exist for regular tabs, we could probably switch to multitabs in all cases for FlatLAF, and effectively deprecate the other one. (Unless multitabs turns out to have problems we aren't currently aware of.)
If at some point we get multitabs to support all the FlatLAF options that now exist for regular tabs, we could probably switch to multitabs in all cases for FlatLAF, and effectively deprecate the other one. (Unless multitabs turns out to have problems we aren't currently aware of.)
Switching to multitabs in all cases within the IDE might be good. But we need to be careful that it's an optional part of the platform so make sure we don't do anything that "breaks" cases where it's not included.
I'm not sure if we can make multitabs delegate better to the laf tabs so that most fixes can just go in there?
@neilcsmith-net Yeah, I think multitabs could only ever become the default for FlatLAF specifically. Regular tabs could be "deprecated" only in the sense that LAFs other than FlatLAF would be "deprecated".
I'm not sure if we can make multitabs delegate better to the laf tabs so that most fixes can just go in there?
I suspect this might be difficult, and perhaps not necessary. If multitabs can be skinned via UIDefaults properties, like FlatLAF, then all future skinning of the tab components could be done this way, rather than by changing LAF-specific code.
I also wonder to what degree we hope to continue maintaining the old non-flatLAF LAFs. (e.g. GTK LAF, Windows LAF, MacOS/Aqua LAF). Myself, I've completely moved over to FlatLAF.
reading through old PRs to figure our what still needs to be done:
Switching to multitabs in all cases within the IDE might be good. But we need to be careful that it's an optional part of the platform so make sure we don't do anything that "breaks" cases where it's not included.
we could probably set the default via branding so that it switches only for the IDE? Anything else what needs to be done here still before changing the default is possible?