[SRU] Find result is too light gray

Yup, thats a theme bug.

Should be fixed now.

You should see a dark selected_bg_color now.

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

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.

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.

Try this one.

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

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

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)

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)

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.

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

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 ?

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.

@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.

Yup, not an immediate concern

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.

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.

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

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.

@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.

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.

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

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

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!

Too late?

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