bugGNU Octave - Bugs: bug #53995, Fix text color in highlighted...


bug #53995: Fix text color in highlighted workspace variables when using a dark theme

Submitted by:  Mayeul Cantan <mayeulc>
Submitted on:  Sun 27 May 2018 10:42:42 PM UTC  
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Ready For Test Assigned to:  None
Originator Name:  Open/Closed:  Open
Release:  dev Operating System:  Any

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Sun 07 Apr 2019 06:30:04 PM UTC, comment #6:

I have pushed changeset
where a suitable foreground color for the configured background color is selected by means of QPalette.

Torsten Lilge <ttl>
Project Member
Wed 31 Oct 2018 12:42:57 PM UTC, comment #5:

Now that we stay with the workspace coloring, but have made them optional, should we add a selection possibility for the text colors or should we calculate suitable text colors from the selected background colors?

The first solution would give the possibility to select different text colors but the same background color.

Torsten Lilge <ttl>
Project Member
Thu 11 Oct 2018 03:59:16 PM UTC, comment #4:

Something like this https://bitbucket.org/carandraug/octave/commits/c5df81a0960108b08324e8ad21e1a26fa2f59f94?at=remove-workspace-colours which removes the colours based on attributes and the tooltip

While experiment with this, I found that the rename of a variable does not seem to work at all.

Carnë Draug <carandraug>
Project Member
Thu 11 Oct 2018 02:09:17 PM UTC, comment #3:

ideally we pick colours from the system settings but this is too specialized so we have users picking the colours they want. While finding an automatic way to automatically pick the best colours can be useful, I think first we should find a way to set them manually. So on the workspace menu, we would have a table where each row is one attribute, and one column to select the background colour and another the matching text colour, similar to what we have for the editor styles in the editor tab of the GUI.

But do we really need this colour coding of the variables by attribute? Not being a GUI user, this seems actually more distracting than useful (there's the option to sort by attribute if that's the important thing). If that's done, then the problem goes away since the colour is all done automatically based on the system theme.

Carnë Draug <carandraug>
Project Member
Wed 06 Jun 2018 12:56:08 PM UTC, comment #2:

Well, I chose black since the colors were set up above in the file. However, I saw since then that those could be changed.

I am not too familiar with themes either, I will probably ask KDE's Visual Design Group about this. The theme does provide a default highlighting color as well (and a color palette, as far as I know), but we are using custom highlighting colors in this case.

This is some custom highlight, I think we have multiple solutions:

  • Allow the user to change the text color in a related setting
  • Automatically determine the color that gives the best contrast
  • Change the default highlighting colors depending on the theme.
  • Hardcode black, which isn't desirable.

The color will also have to be changed in the tooltip, where it is already hardcoded to black, IIRC.

Mayeul Cantan <mayeulc>
Wed 06 Jun 2018 11:46:50 AM UTC, comment #1:

What do other programs do in this kind of situation? Is there a better solution than just using black?

I admit to not knowing how these things work, so this may be a silly question, but does the theme say what should happen when highlighting? If so, then shouldn't it provide the foreground and background colors for that?

John W. Eaton <jwe>
Project Administrator
Sun 27 May 2018 10:42:42 PM UTC, original submission:

When using a dark theme, text color defaults to a very light value (white in my case). The contrast is then too low to read information against the highlighted background in the workspace view.

Attached is a patch that sets the foreground color to black when the background is highlighted.
Of course, ideally we would compute the foreground color dynamically, but it looks like this is enough for most cases.

Also changes BackgroundColorRole (which is marked as obsolete in the documentation) to BackgroundRole.

I am not sure this is the right way to submit patches, but that's what was written on the website.

Mayeul Cantan <mayeulc>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #45182:  workspace-variables-dark-theme.png added by mayeulc (57KiB - image/png - Bug illustration: low contrast with a dark theme)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by jwe (Updated the item)
  • -email is unavailable- added by mayeulc (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-04-07 ttl StatusPatch Submitted => Ready For Test
    2018-10-11 mayeulc Attached File- => Added workspace-variables-dark-theme.png, #45182
    2018-06-06 jwe StatusNone => Patch Submitted
        Summary[patch] Fix text color in highlighted workspace variables when using a dark theme => Fix text color in highlighted workspace variables when using a dark theme
    2018-05-27 mayeulc Attached File- => Added highlight-foreground-color.patch, #44235

    Back to the top

    Powered by Savane 3.4