Conversation
Contributor
vogella
force-pushed
the
ctabfolder-bkimage-tests
branch
from
September 14, 2026 15:13
763c523 to
0826dd3
Compare
vogella
marked this pull request as ready for review
September 14, 2026 15:14
vogella
force-pushed
the
ctabfolder-bkimage-tests
branch
2 times, most recently
from
September 22, 2026 11:19
abf78f8 to
9058a2c
Compare
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. setRenderer() refreshes the backgrounds, since the renderer now decides between color and image. Adds Snippet394. Assisted-by: multiple AI agents and layers of automated tooling 🤖
vogella
force-pushed
the
ctabfolder-bkimage-tests
branch
from
September 22, 2026 11:23
9058a2c to
13a224d
Compare
…rers A background image per top right control takes a different code path on each platform. For a custom renderer, sample the color at the middle of the control from the rendered background and set it as a flat color. The built-in renderer keeps its gradient image. Assisted-by: multiple AI agents and layers of automated tooling 🤖
Contributor
Author
|
On Windows no difference: Before: 
After: 
Will also re-test on Linux / GTK |
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.With a custom renderer, the folder now renders
PART_BACKGROUNDfor the control's position into a temporary image, takes the color at the middle of the control and sets it as a flat background. The control gets no background image, so no platform specific image inheritance is involved. The built-in renderer keeps its flat color, or its gradient image when a gradient is set. The temporary image is prefilled withgetBackground(), because a renderer may leave pixels untouched where on screen the widget background shows through.setRenderernow refreshes the control backgrounds too.Snippet394reproduces it with a two tone renderer. Tests cover the wrapped case, the non-wrapped case with and without a gradient, a renderer that keeps the default background, a renderer set after layout, and the built-in renderer with a gradient.Verified on GTK in a running IDE. On Windows (Dark and Dracula themes) there is no visible change: the wrapped band is painted with the folder background there, and the theme CSS sets the
ToolbarCompositebackground explicitly. Themes which setswt-draw-custom-tab-content-background: falseare not affected either.