You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Windows][Dark theme] Multiple preference pages use tab widgets, that are not dark theme aware #27
On Windows, multiple preference pages use tab widgets that are not dark theme-aware, thus stand out by using light colors:
(Checking with Spy++, the native Win32 widget they use is SysTabControl32)
While pages using dark theme-aware tab widgets use SWT_Window0-s
Ideally, the SWT/JFace widget should be fixed, affecting all of the affected dialogs. (And this is what the darkest dark plugin also does: it replaces all of the broken tab widgets)
changed the title [-][Windows] Multiple preference pages use tab widgets, that are not dark theme aware[/-][+][Windows][Dark theme] Multiple preference pages use tab widgets, that are not dark theme aware[/+]on Jun 23, 2022
Is there a dedicated bug for Windows not supporting TabFolder theming? CTabFolder is significanlty heavier widget with far more issues than TabFolder so just switching everywhere is not the right approach, esp if the real issue "windows theming of TabFolder" is not even investigated.
Yes. Bug 566359 - [Dark theme][win32]- TabFolder header not styled
IIUC this relies on Windows adding native support, which doesn't appear to have happened yet.
There is no hope Windows provide a style engine and this can be done natively. One possibility though would be to derive default colors in TabFolder from the parent folder, but I'm not certain it's desired in all cases. Can't the dark theme itself style the native TabFolder? cc @vogella
There is no hope Windows provide a style engine and this can be done natively. One possibility though would be to derive default colors in TabFolder from the parent folder, but I'm not certain it's desired in all cases. Can't the dark theme itself style the native TabFolder? cc @vogella
so just switching everywhere is not the right approach, esp if the real issue "windows theming of TabFolder" is not even investigated.
@akurtakov the above comment is what I referred to in planning council. On the understanding that the TabFolder -> CTabFolder is bandaid solution can you confirm that this is ok to proceed with bandaid solution for now?
I'm worried that the because of win-specific issues and adopting "bandaid", we're reducing the quality of other OS support. Linux for example behaves very well with TabFolders, better than with CTabFolders, so seeing this pattern spreading across the whole IDE is likely to negatively affect Linux.
@jonahgraham@mickaelistria@akurtakov I think this clearly shows that the "bandaiding" do not work/scale well... We can't put a restriction on every eclipse plugin to use CTab(Folder) just to improve dark-mode users... That will effectively require deprecate usage of TabFolder in all Platform code and every plugin written for eclipse...
I must confess it seems to be that there was already a decision, its a bit strange to merge all those PRs if it is not decided how to proceed?
Seeing this going on as search and replace of TabFolder with CTabFolder and there are many more places like that even outside Platform and getting complains from two of the most active Platform developers about it I think we should reconsider and this "bandaid" solution is not OK anymore.
Please work in proper fix in Win32 SWT TabFolder.
If you disagree with my assesment here feel free to send email to Eclipse PMC so it's discussed and voted there but punishing other OS users via CTabFolder (yes, it's slower, uglier and lacks integration) because Win32 port is not worked on is not OK.
Just to be clear, there is no one available to do this. Saying no to the bandaid means that we are deciding to live with status quo on Windows.
The colour of the tabs isn't the most important feature of dark mode in the IDE, and I don't care enough about this issue to argue for it and I will happily defer to more experienced Platform developers. The Planning Council will be requesting from the IDE WG more investment in this area so that (if we can find someone to do it) it can be fixed.
I attempted to define colors for TabFolder in the CSS file, but that action did not change anything. The color definition has been done somewhere else for TabFolder, and it is selected from that location. Need some more time to investigate further.
Also, I cannot open the CSS spy dialog multiple times in the preference dialog, which does not allow me to check all the defined properties and experiment with colors. Is there a specific reason for this?
Activity
[-][Windows] Multiple preference pages use tab widgets, that are not dark theme aware[/-][+][Windows][Dark theme] Multiple preference pages use tab widgets, that are not dark theme aware[/+]jonahgraham commentedon Jun 23, 2022
Thanks @pbalint for the bug report.
@Torbjorn-Svensson provided similar fixes for other UI in eclipse-platform/eclipse.platform.team#14 - so if that same way of fixing it can be applied here that would be great.
@betamaxbandit has also taken on dark mode fixes. @betamaxbandit this one be a good one to have a quick stab at.
jonahgraham commentedon Jun 28, 2022
@betamaxbandit has made the first PR for this (of the many that will be required to update all the UIs) in eclipse-jdt/eclipse.jdt.ui#126
akurtakov commentedon Jun 28, 2022
Is there a dedicated bug for Windows not supporting TabFolder theming? CTabFolder is significanlty heavier widget with far more issues than TabFolder so just switching everywhere is not the right approach, esp if the real issue "windows theming of TabFolder" is not even investigated.
betamaxbandit commentedon Jun 28, 2022
Yes.
Bug 566359 - [Dark theme][win32]- TabFolder header not styled
IIUC this relies on Windows adding native support, which doesn't appear to have happened yet.
mickaelistria commentedon Jun 28, 2022
There is no hope Windows provide a style engine and this can be done natively. One possibility though would be to derive default colors in TabFolder from the parent folder, but I'm not certain it's desired in all cases. Can't the dark theme itself style the native TabFolder? cc @vogella
vogella commentedon Jun 29, 2022
As long as SWT does not support it, we cannot style it via CSS. CSS "only" uses SWT API under the hood. Looks like it would be possible to support this in SWT, see https://bugs.eclipse.org/bugs/show_bug.cgi?id=566359#c2
improve Dark Theme on Windows eclipse-platform/.github#27 (#126)
jonahgraham commentedon Aug 3, 2022
@akurtakov the above comment is what I referred to in planning council. On the understanding that the TabFolder -> CTabFolder is bandaid solution can you confirm that this is ok to proceed with bandaid solution for now?
akurtakov commentedon Aug 3, 2022
If we are clear there is no one to do real fix - bandaid it is.
improve Dark Theme on Windows eclipse-platform/.github#27
mickaelistria commentedon Oct 4, 2022
I'm worried that the because of win-specific issues and adopting "bandaid", we're reducing the quality of other OS support. Linux for example behaves very well with TabFolders, better than with CTabFolders, so seeing this pattern spreading across the whole IDE is likely to negatively affect Linux.
improve Dark Theme on Windows eclipse-platform/.github#27
improve Dark Theme on Windows eclipse-platform/.github#27
laeubi commentedon Oct 10, 2022
Originally posted by @laeubi in eclipse-equinox/equinox#137 (comment)
@jonahgraham @mickaelistria @akurtakov I think this clearly shows that the "bandaiding" do not work/scale well... We can't put a restriction on every eclipse plugin to use CTab(Folder) just to improve dark-mode users... That will effectively require deprecate usage of TabFolder in all Platform code and every plugin written for eclipse...
I must confess it seems to be that there was already a decision, its a bit strange to merge all those PRs if it is not decided how to proceed?
akurtakov commentedon Oct 10, 2022
Seeing this going on as search and replace of TabFolder with CTabFolder and there are many more places like that even outside Platform and getting complains from two of the most active Platform developers about it I think we should reconsider and this "bandaid" solution is not OK anymore.
Please work in proper fix in Win32 SWT TabFolder.
akurtakov commentedon Oct 10, 2022
If you disagree with my assesment here feel free to send email to Eclipse PMC so it's discussed and voted there but punishing other OS users via CTabFolder (yes, it's slower, uglier and lacks integration) because Win32 port is not worked on is not OK.
jonahgraham commentedon Oct 10, 2022
Just to be clear, there is no one available to do this. Saying no to the bandaid means that we are deciding to live with status quo on Windows.
The colour of the tabs isn't the most important feature of dark mode in the IDE, and I don't care enough about this issue to argue for it and I will happily defer to more experienced Platform developers. The Planning Council will be requesting from the IDE WG more investment in this area so that (if we can find someone to do it) it can be fixed.
akurtakov commentedon Nov 14, 2024
Is this still relevant?
pbalint commentedon Nov 14, 2024
Yes, the tabs are still light-gray when dark theme is used
akurtakov commentedon Nov 14, 2024
@HeikoKlare I don't remember who looked at dark theme issues. If you do would you please let him know of this one.
HeikoKlare commentedon Nov 14, 2024
@BeckerWdf are you looking into theming related issues, in particular since you are working on the updated light (and dark) themes?
mvm-sap commentedon Nov 19, 2024
I will have a look into the issue and update here
mvm-sap commentedon Nov 19, 2024
I attempted to define colors for TabFolder in the CSS file, but that action did not change anything. The color definition has been done somewhere else for TabFolder, and it is selected from that location. Need some more time to investigate further.
Also, I cannot open the CSS spy dialog multiple times in the preference dialog, which does not allow me to check all the defined properties and experiment with colors. Is there a specific reason for this?