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

 
 

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

Submitter:  Mayeul C. <mayeulc>
Submitted:  Sun 27 May 2018 10:42:42 PM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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

I have pushed changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/c76dd670a7a5
where a suitable foreground color for the configured background color is selected by means of QPalette.

Torsten Lilge <ttl>
Group 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>
Group 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>
Group 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>
Group 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 C. <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>
Group 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 C. <mayeulc>

 

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

Attach Files:
   
   
Comment:
   

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 rik5 (Updated the item)
  • -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)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-05-30 rik5 StatusReady For Test Fixed
        Open/ClosedOpen Closed
    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.13-f8d8.
    Corresponding source code