Skip to content

Conversation

@mbien
Copy link
Member

@mbien mbien commented Nov 9, 2022

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.

tab-list

This area got some fixes #3299 and pending improvements recently.#4792

@mbien mbien added Platform [ci] enable platform tests (platform/*) UI User Interface labels Nov 9, 2022
@mbien mbien added this to the NB17 milestone Nov 9, 2022
@mbien mbien added the Editor label Nov 9, 2022
@mbien mbien marked this pull request as ready for review November 10, 2022 17:44
@eirikbakke
Copy link
Contributor

This affects the appearance of tabs, not just the document list dropdown. Probably the UI tweaks that were done in #4286 should be adapted to the "Sort opened document list by project" mode as well before making this the default.

sortdoc

@mbien
Copy link
Member Author

mbien commented Nov 16, 2022

@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 :)

@neilcsmith-net
Copy link
Member

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.

@mbien mbien marked this pull request as draft November 16, 2022 18:06
@mbien
Copy link
Member Author

mbien commented Nov 16, 2022

converted it back to draft so that nobody can merge it by accident.

@neilcsmith-net
Copy link
Member

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?

@neilcsmith-net
Copy link
Member

neilcsmith-net commented Nov 16, 2022

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! 🤷

@mbien mbien force-pushed the defaults-enable-sort-by-project branch from da5af1b to 512d985 Compare December 5, 2022 20:22
@mbien mbien marked this pull request as ready for review December 5, 2022 20:22
@eirikbakke
Copy link
Contributor

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:

(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...

@mbien mbien marked this pull request as draft December 29, 2022 20:57
@mbien
Copy link
Member Author

mbien commented Dec 29, 2022

@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.

@neilcsmith-net neilcsmith-net modified the milestones: NB17, NB18 Jan 18, 2023
this also fixes an inconsistency and renders the tab line on top
when the setting is active (based on the UI property).
@mbien mbien force-pushed the defaults-enable-sort-by-project branch from 512d985 to 4405565 Compare March 5, 2023 01:00
@mbien mbien added the ci:dev-build [ci] produce a dev-build zip artifact (7 days expiration, see link on workflow summary page) label Mar 5, 2023
@apache apache locked and limited conversation to collaborators Mar 5, 2023
@apache apache unlocked this conversation Mar 5, 2023
@mbien mbien marked this pull request as ready for review March 5, 2023 01:03
@mbien mbien requested a review from neilcsmith-net March 5, 2023 01:04
@mbien
Copy link
Member Author

mbien commented Mar 5, 2023

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?

@eirikbakke
Copy link
Contributor

eirikbakke commented Mar 12, 2023

@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.

@mbien
Copy link
Member Author

mbien commented Mar 12, 2023

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?

@eirikbakke
Copy link
Contributor

@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.)

@neilcsmith-net
Copy link
Member

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?

@eirikbakke
Copy link
Contributor

@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.

@mbien mbien modified the milestones: NB18, NB19 Apr 12, 2023
@mbien
Copy link
Member Author

mbien commented Apr 12, 2023

moved to NB19

@mbien mbien modified the milestones: NB19, NB20 Jul 13, 2023
@mbien mbien removed this from the NB20 milestone Oct 11, 2023
@mbien
Copy link
Member Author

mbien commented Oct 11, 2023

removed milestone

@mbien mbien marked this pull request as draft October 11, 2023 10:28
@mbien
Copy link
Member Author

mbien commented Oct 14, 2024

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ci:dev-build [ci] produce a dev-build zip artifact (7 days expiration, see link on workflow summary page) Editor Platform [ci] enable platform tests (platform/*) UI User Interface

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants