-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Differences Between GL and Software Renderers #944
Comments
I'm not sure about this... The dialog should be using backgroundColor, so perhaps there is another issue somewhere. Perhaps you have an image so we can look at what might be wrong in the rendering? Moving to transparent by default is probably an option nevertheless but I'd like to know if we have an underlying issue. Adding a SetBackgroundColor to all widgets isn't something we should consider, as widgets should expose only logic/state APIs |
Suggest change of title to "Dialog background is not theme.BackgroundColor"? |
I'm using a dialog which on mobile contains a tabber with two tabs (Sign In/Sign Up), and on desktop (with more screen real estate) shows the two pieces of content side-by-side. Here are two screenshots (mobile & desktop) to show the problem that triggered this issue: It looks like dialog (modal popup) has theme.ShadowColor() as its background - which is fine as you'd want the dialog to have a different color than the window, but Group and Tabber use theme.BackgroundColor(). If the default was transparent, I think this issue would be resolved. |
The shadow colour is supposed to be used for the semi-transparent shadow drawn around the modal. |
Okay, let's use your suggested title for this bug and make dialog background the same as window background, ie. theme.BackgroundColor() |
dialog/base.go:58 seems to indicate we already are, I think there is a more subtle issue |
widget/popup.go:253 made me think it was rendering the background with the shadow color |
OK, not a problem. But now it seems we have 2 widgets using background colour but they look different... hmm. |
Hmm. I wonder if that is an artifact in the Gl renderer? if you capture the canvas from a software renderer do you see the same issue? |
Attempted in #949 |
I'd say that running the app as normal and a lot of screenshots will help. I'd suggest testing once with it as content of the window then another as the content of a dialog and see what changes. |
I think the title is not fitting well now. Probably something about subtle differences in background colours in GL renderer? |
I realised today that the software renderer does not support circle or line. I am working on this now |
All graphical types should be supported by the incoming #1141. In combination with the previous #947 for NRGBA transition this may now be resolved? |
Ping @stuartmscott |
This appears to be fixed |
Is your feature request related to a problem? Please describe:
"fyne.io/fyne/internal/widget".BaseRenderer implements BackgroundColor() and returns theme.BackgroundColor().
If an object (eg "fyne.io/fyne/widget".Group) is used in a dialog, its background does not match the dialog background.
Is it possible to construct a solution with the existing API?
There is no easy way to override the background color. One option is to make a custom widget extending Group which uses a different renderer - but this seems like overkill
Describe the solution you'd like to see:
Either baseRenderer should have a transparent background, or there need to be a SetBackgroundColor(color.Color) then BackgroundColor returns that, or if it is not set, return theme.BackgroundColor()
The text was updated successfully, but these errors were encountered: