wxDataViewCtrl unusual behaviour with GTK3 (Issue #22128)
ROSSANO PARIS
Describe the bug
Using "dataview" sample the wxDataViewCtrl behaviour applying a background colour is not the same for two different GTK3 versions.
I'm facing the same ununderstandable behaviour using an application of mine, thus I tried with the example.
GTK 3.18.9 - Linux Mint 18.2 Cinnamon - 64bit
"German Requiem" row selection
It works as expected, with the selected row highlighted and the correct foreground colour (white)
GTK 3.24.20 - Linux Mint 20.2 Cinnamon - 64bit
"German Requiem" row selection
It doesn't works as expected, the selected row shows the correct foreground colour (white), yet is not highlighted.
Platform and version information
- wxWidgets 3.1.5
- wxGTK
- OS LINUX
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
VZ
This is almost certainly theme-dependent, so I'd like to know how does highlighting look in this theme, i.e. how does the selected row look in Gnome File Explorer or some other native application?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
ROSSANO PARIS
thank you @vadz
This is how "Gnome File Explorer" shows selected rows
This is the wxDataViewCtrl aspect without changing its background colour, it works as expected.
Lets say, the problem rises as you change the wxDataViewCtrl background colour, from its default one, by using the option "Change background colour ..." provided by the example.
This kind of behaviour is observed from a GTK version greater than 3.18.9 and let me add, it happens in the same way even changing among themes provided by MINT
Here is my attempt to understand what is going on, I created my own renderer using an override of this function wxDataViewCustomRenderer::Render
The selection colour remains behind the cells background, and if you change the entire control background from its default it overlap the rows selection.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
ROSSANO PARIS
Excuse me @vadz
I'm trying to find a work around regarding the issue I'm facing, but no way ...
The way I followed is to detect if a row is selected by using the "int state" parameter of wxDataViewCustomRenderer::Render
A part that, the value is different using MSW or LINUX: MSW=1, LINUX=11
anyway, using the detected "selected row" I'm able to draw a coloured rectangle using the system highligh colour, but it is drawn only hovering the selected row as shown below with a short video.
I don't understand whether I'm facing a bug or whatever.
Am I missing something ? It sound so strange ...
Regards
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
VZ
Sorry, I didn't have time to look at this yet. The fact is that if you start changing the colours, things won't look good, at least in some theme, unless you change all of them.
As a workaround, maybe you could just change the attribute of (some of) the cells instead?
I'm not sure why are you trying to define a custom renderer and how is this supposed to help, but the flags you're seeing are defined in wxDataViewCellRenderState, i.e. you really just want to check for wxDATAVIEW_CELL_SELECTED (1) there.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
ROSSANO PARIS
Sorry, I didn't have time to look at this yet.
no worries
The fact is that if you start changing the colours, things won't look good, at least in some theme, unless you change all of them.
Excuse me , but I didn't change any colours regarding any theme, I changed wxDataViewCtrl background colour only, it i snot permitted ?
I'm not sure why are you trying to define a custom renderer and how is this supposed to help, but the flags you're seeing are defined in wxDataViewCellRenderState, i.e. you really just want to check for wxDATAVIEW_CELL_SELECTED (1) there.
I dint get you, I had to use custom render because of the issue I'm facing.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
VZ
What I meant was that if you change the background colour, you typically need to change the foreground colour as well, as otherwise the text will be unreadable for the themes that use foreground colour identical, or close, to your background colour.
I.e. IMO the only real solution is to allow changing the selection colour too and then require that the applications changes all of (foreground, background, selection) colours if it changes any of them.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
ROSSANO PARIS
What I'm trying to report happens even using "light blue" as background colour, which is definitely not similar neither with default foreground colour nor selection colour, the control stops highlighting selected rows, this behaviour is easy to verify using dataview example ... anyway, I give up.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
VZ
Sorry for being unclear. I do understand the bug you're reporting even though I didn't have time to even try debugging it yet. What I'm saying is that in general you don't want to do what you're doing anyhow because even if we fix this bug and it will work in this situation, there will always be other themes where the text will become unreadable if you don't change all the colours involved.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
ROSSANO PARIS
Again,
- it's not the text colour the problem, it is perfectly readeable; did you see our screen-shots ? Did you try the "dataview" example ? The foreground text colour changes correctly and accordingly with its selection status, the problem is that control does not highligh the selected rows changing their background colour, that's the only problem.
- this kind of issue happends even using XFCE as desktop, not only with GNOME
- this kind of issue happends on many up to date LINUX distributions and probably involve other similar widgets, previously it wasn't present.
- all linux distributions use themes, we are usign the defautl one they provide, not a custom one.
On my side, in my company, I have to invest time to solve a "problem" which we don't understand and without any valid indications, as it wasn't present for years since we are providing our work, we understand and respects your huge work and efforts, we are only trying to be helpful, but it seems the contrary.
Excuse me, I don't want to sound rude but, the answer should not be like: "don't change the background colour as you can mess up everything".
As a normal user, what am I doing so wrong ? It's obvious, the new background colour mustn't be equal to the system highlighting one.
I beg your pardon and nobody is claiming anything, yet in my opinion, if it is a bug, it should be solved (of course taking in consideration engagements, time and so on), then is up to the final user taking care about the colours she/he is going to use.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
paulcor
all linux distributions use themes, we are usign the defautl one they provide, not a custom one.
Background and selection colors are part of the theme. By setting a background color, you are overriding the theme. Your color may not work well with the theme's selection. What exactly do you think we can do about that?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.
VZ
I think the misunderstanding comes from the fact that you believe that setting the background colour is supported and guaranteed to work because apparently it used to work for you for a long time. As I've been trying to explain, changing just the background colour was never guaranteed to work ever since the systems using themeing became common (so for the last 25 years or so?). Only changing all of the colours (background and foreground and selection) may be reasonably expected to work.
Now I realize that there are several problems with this:
- We don't support changing the selection colour at all right now. This is something that should be done, but I just don't have time/energy/whatever for this right now. If you are motivated to do it, we would accept patches implementing this functionality and then you could use them in your application to ensure that your colours work on all systems, instead of just hoping that they do.
- It used to work for you but doesn't work any longer. This is something I don't understand as I'm not aware of any changes here. Maybe we didn't use the theme colours correctly before, in which case the change in wx was correct, even if it adversely affected your code. Maybe it's something else in which case it could be a bug that we didn't find yet. Please consider running git-bisect to find which change exactly broke this if it did work before.
But as Paul wrote, I don't really see what else could be done here. If you see another/better solution, please let us know.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.
You are receiving this because you are subscribed to this thread.