[CTabFolder] Ask the renderer for the background of tab controls - #3548
Draft
vogella wants to merge 1 commit into
Draft
[CTabFolder] Ask the renderer for the background of tab controls#3548vogella wants to merge 1 commit into
vogella wants to merge 1 commit into
Conversation
updateBkImages() handed a control the flat getBackground() when it was wrapped below the tab row, or when no gradient was set. That only holds for the built-in renderer. One painting its own PART_BACKGROUND, like the IDE's CTabRendering, uses different colors for tab row and body, so a wrapped view tool bar showed a block of the tab row color on the body strip. A custom renderer is now asked for the background. The image is prefilled with getBackground() first, since a renderer may leave pixels untouched that on screen show the widget background. Adds Snippet396. Assisted-by: multiple AI agents and layers of automated tooling 🤖
Contributor
Test Results 210 files - 2 210 suites - 2 26m 2s ⏱️ - 1m 9s For more details on these failures, see this check. Results for commit 763c523. ± Comparison against base commit 2a8d3f1. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A control placed in a
CTabFolderwithsetTopRightwas given the flatgetBackground()whenever no gradient was set, and always when it had wrapped below the tab row. That assumes the folder background is a flat color at that position, which only holds for the built-in renderer. A renderer painting its ownPART_BACKGROUND, as the IDE'sCTabRenderingdoes, uses different colors for the tab row and the body, so a view tool bar that wrapped showed a block of the tab row color sitting on the body strip.The folder now asks a custom renderer for the background at the control's position, which is the path the gradient case already used, and keeps the flat shortcut for the built-in renderer. The image is prefilled with
getBackground()first, because a renderer may leave pixels untouched where on screen the widget background shows through; without that a renderer subclass that does not overridePART_BACKGROUNDwould hand out a blank image.Snippet396reproduces it with a two tone renderer. Four tests cover the wrapped case, the non-wrapped case without a gradient, a renderer that keeps the default background, and the built-in renderer with a gradient.Verified on GTK, including in a running IDE with the patched bundle substituted in: the wrapped tool bar goes from a flat tab row color to the rendered folder background. Note that themes which set
swt-draw-custom-tab-content-background: falsemake the band match the folder background anyway, so this is not visible there.