[SRU] Find result is too light gray

Bug #740864 reported by David Henningsson
46
This bug affects 5 people
Affects Status Importance Assigned to Milestone
One Hundred Papercuts
Low
James Schriver
light-themes (Ubuntu)
Medium
James Schriver
Natty
Undecided
Unassigned

Bug Description

Binary package hint: gedit

I'm not sure if this is a bug in gedit or the color theme in general, but just open a text file in gedit, select "Find" and search for a random word in the text. The currently selected match is in a very light gray background, difficult to distinguish from the background - quite annoying.
The non-selected matches have a more visible yellow background color and are not affected by this usability bug.

ProblemType: Bug
DistroRelease: Ubuntu 11.04
Package: gedit 2.30.4-2ubuntu1
ProcVersionSignature: Ubuntu 2.6.38-7.37-generic 2.6.38
Uname: Linux 2.6.38-7-generic i686
Architecture: i386
Date: Wed Mar 23 11:35:25 2011
InstallationMedia: Ubuntu 11.04 "Natty Narwhal" - Alpha i386 (20110322.1)
ProcEnviron:
 LANGUAGE=sv_SE:en
 LANG=sv_SE.UTF-8
 SHELL=/bin/bash
SourcePackage: gedit
UpgradeStatus: No upgrade log present (probably fresh install)

Related branches

Revision history for this message
David Henningsson (diwic) wrote :
Changed in gedit (Ubuntu):
importance: Undecided → Low
Revision history for this message
Vish (vish) wrote :

Yup, thats a theme bug.

affects: gedit (Ubuntu) → light-themes (Ubuntu)
Changed in light-themes (Ubuntu):
status: New → Triaged
Changed in hundredpapercuts:
assignee: nobody → Papercuts Ninja (papercuts-ninja)
importance: Undecided → Low
milestone: none → nt3-ayatana
status: New → Triaged
Revision history for this message
James Schriver (dashua) wrote :

Should be fixed now.

Changed in light-themes (Ubuntu):
assignee: nobody → James Schriver (dashua)
status: Triaged → Fix Committed
Revision history for this message
James Schriver (dashua) wrote :

You should see a dark selected_bg_color now.

Paul Sladen (sladen)
Changed in light-themes (Ubuntu):
milestone: none → ubuntu-11.04
Vish (vish)
Changed in hundredpapercuts:
assignee: Papercuts Ninja (papercuts-ninja) → James Schriver (dashua)
status: Triaged → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package light-themes - 0.1.8.13

---------------
light-themes (0.1.8.13) natty; urgency=low

  [James Schriver]
  * Ambiance/Radiance/apps/gedit.rc
    - Add gedit specific theming bits fixes (LP: #740864)
    - Minor gedit specific theming tweaks
  * Ambiance/gtk-2.0/gtkrc
    - Adjust dark settings to fix me-menu (LP: #664794)

  [Andrea Cimitan]
  * Ambiance/Radiance/gtk-2.0/gtkrc
  - Tweaked colors for overlay-scrollbars (LP: #767524)
  * Ambiance/Radiance/gtk-3.0/
  - Directories removed (unused)
 -- James Schriver <email address hidden> Sun, 17 Apr 2011 00:31:42 -0400

Changed in light-themes (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Andrea Cimitan (cimi) wrote :

I don't like this branch for a couple of reasons:
1) technically we are linking gedit to the pixmap theming engine just to hide the frame
2) removing the frame is inconsistent with the rest of our light-themes, where frames are always drawn around the scrolled window (there's in fact a frame, with a shadow-type != GTK_SHADOW_NONE)
3) the fix to this bug in not complete, as the text color is black and not white. this could potentially break not only the customization of colors in the appearance properties capplet, but also other color schemes (where black is not the color used)

just to fix this bug, we should try something like that (not tested if the text[ACTIVE] color is working fine or it could create issues):
style "gedit-notebook"
{
 base[ACTIVE] = @selected_bg_color
 text[ACTIVE] = @selected_fg_color
}

widget_class "*GeditNotebook" style "gedit-notebook"
widget_class "*GeditNotebook*Tab*" style "gedit-notebook"

I would remove this branch from the release and postpone it in SRU.

Revision history for this message
Paul Sladen (sladen) wrote :

James: Vish: per Cimi's concerns, would you be able to whip a patch that removes the Pixmap dependency (dropping the border change if required to do so) and which tries to reduce the patch down to the minimal size suggested in comment #7.

Revision history for this message
James Schriver (dashua) wrote :

Try this one.

Revision history for this message
Vish (vish) wrote :

Werent the other matches requested by the design team as per Bug #767531 ? "Recommended main changes to thin out the scrollbar"

@James, base[ACTIVE] = shade (0.9, @selected_bg_color) is better than base[ACTIVE] = @selected_bg_color , because if the active and selected are the same color we would not know the difference which is currently selected

Revision history for this message
Vish (vish) wrote :

Oh and gedit looks really good with :
widget_class "*Gedit*.<GtkScrolledWindow>" style "thin"
That removes an ugly border and might work better with the overlay scrollbars

Revision history for this message
Andrea Cimitan (cimi) wrote :

I don't want to remove the frame, the frame is everywhere, and without the frame there's 1 pixel gap with the overlay scrollbar, which is even less nice...
So please, just fix this bug adding the lines I suggested, other changes to gedit will be taken into account in a SRU and discussed in front of a beer at the UDS.
@Vish:
base[ACTIVE] = @selected_bg_color
text[ACTIVE] = @selected_fg_color

should be fine, I don't want to apply shades here, as we will add inconsistency with the rest of the theme (which is not applying shafws)

David Barth (dbarth)
tags: added: 0day-sru
Revision history for this message
Andrea Cimitan (cimi) wrote :

I've dived into this a little bit more, and it's not fixable without touching gedit's C code.

The bugreport is reproducible only if you keep the window focus on the find/find-replace window while selecting the items, in that way, main gedit window is then using ACTIVE colors, as it should do. If you keep the window focus on gedit (and not on the find/find-replace window) while searching for matches, the color will be the SELECTED (white on orange) as we want.

But in this case, if we apply this kind of tweak, by forcing ACTIVE colors to behave like SELECTED, then... when you select some text and unfocus gedit (like choosing another window) you'll see the selected text still orange giving the wrong impression gedit is still selected and focused!

I would say "Won't Fix", or postpone it to Oneiric while I will look into gedit's code if there's a way to force the find/find-replace dialogs to colorize the searched element with a selected color (if that makes sense or not, as I'm not so sure of that, it will be inconsistent with the rest of gtk+ apps)

Revision history for this message
Paul Sladen (sladen) wrote :

mpt: could you give some input on this (see comment #12). The problem is to do with the search+replace box over gedit stealing focus from Gedit itself and therefore making Gedit appear in-active.

Revision history for this message
Andrea Cimitan (cimi) wrote :

exactly. and this is not fixable through the theme... so "won't fix" for natty

Revision history for this message
Vish (vish) wrote :

We could try fixing this by editing :
/usr/share/gtksourceview-2.0/styles/classic.xml , thats the theme gedit uses by default
We have
 <!-- Search Matching -->
  <style name="search-match" background="yellow"/>

Maybe we need a new <style name="search-match-active">, or maybe we have that option already ?

Revision history for this message
Paul Sladen (sladen) wrote :

Otto: Cimi suggested that you might have some input on what to do about this too. Would you be able to fire up Gedit as it is now and select/search/replace some text to look at the behaviour and to the extent that it is inconsistent with other applications when the main window is focused/defocused.

Revision history for this message
Andrea Cimitan (cimi) wrote :
Revision history for this message
Andrea Cimitan (cimi) wrote :
Revision history for this message
Andrea Cimitan (cimi) wrote :

@vish, maybe... will discuss at UDS.
Though this is not something we can do in time for Natty, release if few days, we are in hard freeze now.

Revision history for this message
Vish (vish) wrote :

Yup, not an immediate concern

Changed in light-themes (Ubuntu):
status: Fix Released → Triaged
Changed in gedit (Ubuntu):
importance: Undecided → Low
status: New → Triaged
Changed in hundredpapercuts:
status: Fix Committed → Triaged
Revision history for this message
Paul Sladen (sladen) wrote :

There are at this stage three main options:

  a. Leave as-is (0.1.8.13): Selected text looks better during search-replace, but black-on-orange highlighted when another application is open. The borders are thinner and there the 'pixmap' theme engine is also loaded. (There is no risk of a crash).

  b. Fix properly: Figure out the real solution for Gedit, where the selected text remains readable when Gedit Search-and-replace is open, and returns to the defocused grey state when a different application is focused. This would solve the bug in a clean way.

  c. Partial revert: Drop the 'gedit.rc' changes introduced in 0.1.8.13 all-together. This would return to the previous status-quo of (0.1.8.12), without solving the highlighting being defocused when search+replace is open, and would require further re-evaluation later. It would drop the pixmap library loading (again, not a crasher, but increases the RSS size).

In an ideal world, I'd like to be able to present them all to the release team and let them choose based on the delta-size and impact, with guidance documented here on usability, style, and technical/code sanity from those in a position to give the relevant input. At the moment we don't have all three options, and don't (I feel) have enough expert input.

PS. Vish: Bug #767531 was filed to provide status-tracking of the proposed merge being signed (I'm uncomfortable signing things at this stage where there is not a corresponding bug report to provide a feedback/tracking/audit path). There is no Ayatana-Design line in this case, and it had not gone via the Ayatana-Design process.

Revision history for this message
David Barth (dbarth) wrote :

Let me try to clarify and help find the right plan of action:
1. the release is closed now
2. it can't go as a 0day-sru, because we would have to have a clear definition of what to put in, and a clear test plan, and do that for the next week before the release; i don't see that happen right now
3. so it's an SRU, a normal one, with a complete change description, a test plan, test packages, etc.

I invite you to continue commenting on the bug to provide that information.

In terms of scope for the change, being an SRU it can only fix real problems, so: reverting to gray to make sure unfocused windows are not mistakenly taken for focused ones, and cimi's changes to make sure the scrollbar is still usable.

Revision history for this message
Paul Sladen (sladen) wrote :

Proposed (minimal) change to achieve the partial revert (missing corresponding debian/changelog entries):

  bzr diff -r86..87 lp:light-themes

SRU process:

  https://wiki.ubuntu.com/StableReleaseUpdates

David Barth (dbarth)
tags: removed: 0day-sru
Revision history for this message
Matthew Paul Thomas (mpt) wrote :

Sorry, I don't understand the problem. For me the unfocused selection color in gedit is #e5e3e1, which is exactly the same as other native text fields, and very different from the #ffffff used for the rest of the document.

I don't know why there are five different colors used for the unfocused selection color in Firefox (#f077f6), Chromium (#e3e2df), Thunderbird (#b0b0b0), LibreOffice Writer (#fbdbc7), or gedit in a guest session (#b54c2f), but I guess those are five separate bugs.

Revision history for this message
David Henningsson (diwic) wrote :

@mpt, I'm attaching a screenshot. There are four moo:s in the text, three are yellow and one is #e5e3e1. The yellow ones stand out much more clearly than the light gray. It should be the other way around.

Also, I don't find #e5e3e1 giving enough contrast to #ffffff, at least not on my screen - and judging from the duplicates, I'm not alone in thinking so.

Revision history for this message
David Henningsson (diwic) wrote :
Revision history for this message
Paul Sladen (sladen) wrote :

irclogs. appears to have dropped at the crucial period so I can't link to it, but:

  <Cimi> chaotic: all these regressions must be fixed
  <chaotic> Cimi: yes, I could see that on those two sshots you did
  <Cimi> chaotic: a way to properly fix the bug is by patching gedit
  <chaotic> Cimi: I would say your fix is the best for now anyway

based on Otto's advice, I'm intending to upload the staged commenting-out to natty-proposed; then hopefully with mpt's input there can be some guidance for how to do this /should/ work in an ideal world for Ubuntu 11.10.

Paul Sladen (sladen)
summary: - Find result is too light gray
+ [SRU] Find result is too light gray
Revision history for this message
Kate Stewart (kate.stewart) wrote :

Given the folks noticing and duplicate bugs, am uping the priority and moving this so it gets considered for Oneiric.

Changed in light-themes (Ubuntu Oneiric):
milestone: ubuntu-11.04 → none
importance: Low → Medium
Revision history for this message
Martin Pitt (pitti) wrote :

Please also fix this in oneiric ASAP, so that this can proceed to -updates.

Changed in gedit (Ubuntu Natty):
status: New → Invalid
Changed in gedit (Ubuntu Oneiric):
status: Triaged → Invalid
Changed in light-themes (Ubuntu Natty):
status: New → Fix Committed
tags: added: verification-needed
Revision history for this message
Martin Pitt (pitti) wrote : Please test proposed package

Accepted light-themes into natty-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Revision history for this message
Adolfo Jayme (fitojb) wrote :

Too late?

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package light-themes - 0.1.8.13.1

---------------
light-themes (0.1.8.13.1) natty-proposed; urgency=low

  [Andrea Cimitan]
  * Don't load gedit.rc custom settings, as they are introducing
    regressions (LP: #740864)
 -- Paul Sladen <email address hidden> Fri, 29 Apr 2011 15:11:15 +0200

Changed in light-themes (Ubuntu Natty):
status: Fix Committed → Fix Released
Changed in hundredpapercuts:
status: Triaged → Fix Released
Andrea Cimitan (cimi)
Changed in light-themes (Ubuntu Oneiric):
status: Triaged → Incomplete
Changed in light-themes (Ubuntu):
status: Triaged → Fix Released
Adolfo Jayme (fitojb)
no longer affects: gedit (Ubuntu)
no longer affects: gedit (Ubuntu Natty)
no longer affects: gedit (Ubuntu Oneiric)
no longer affects: light-themes (Ubuntu Oneiric)
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers