Re: GtkEntry selection color when not focused

[Owen Taylor <otaylor redhat com>]

Alex Larsson <alexl redhat com> writes:

> On Tue, 28 Aug 2001, Alex Larsson wrote:
> 
> > Having the color of the selection being the same when the widget is 
> > unfocused can be really confusing. I noticed this yesterday when testing 
> > the mnemonics in the color selector. Pressing alt-h toggles focus between 
> > the help button and the Hue entry, but the Hue entry never changes 
> > visually. Instead the "OK" button gets the default grab when the help 
> > button looses it, so it looks like focus is toggled between the ok and the 
> > help button.
> 
> Ok. Here is a new version that adds it to GtkEntry, GtkText and 
> GtkTextView. jrb is working on the corresponding GtkTreeView change.
> 
> I started doing the same for selectable labels, but it was a lot harder, 
> because selectable labels never get focus. What we need to do there is to 
> make selectable labels have cursor and keynav support. Then they need to 
> be made focusable, but not be in the tab focus chain.
> 
> But, in the meantime, can i check this in?
> 
> / Alex
> 
> Index: gtk/gtkentry.c
> ===================================================================
> RCS file: /cvs/gnome/gtk+/gtk/gtkentry.c,v
> retrieving revision 1.146
> diff -u -p -r1.146 gtkentry.c
> --- gtk/gtkentry.c	2001/07/19 18:47:03	1.146
> +++ gtk/gtkentry.c	2001/08/29 19:19:33
> @@ -2500,6 +2500,8 @@ gtk_entry_draw_text (GtkEntry *entry)
>  	  gint start_index = g_utf8_offset_to_pointer (entry->text, start_pos) - entry->text;
>  	  gint end_index = g_utf8_offset_to_pointer (entry->text, end_pos) - entry->text;
>  	  GdkRegion *clip_region = gdk_region_new ();
> +	  GdkGC *text_gc;
> +	  GdkGC *selection_gc;
>  
>            line = pango_layout_get_lines (layout)->data;
>            
> @@ -2507,6 +2509,17 @@ gtk_entry_draw_text (GtkEntry *entry)
>  
>            pango_layout_get_extents (layout, NULL, &logical_rect);
>            
> +	  if (GTK_WIDGET_HAS_FOCUS (entry))
> +	    {
> +	      selection_gc = widget->style->base_gc [GTK_STATE_SELECTED];
> +	      text_gc = widget->style->text_gc [GTK_STATE_SELECTED];
> +	    }
> +	  else
> +	    {
> +	      selection_gc = widget->style->bg_gc [GTK_STATE_ACTIVE];
> +	      text_gc = widget->style->fg_gc [GTK_STATE_ACTIVE];
> +	    }

Would it be better here to use base/text [GTK_STATE_ACTIVE]? --
it might require some fixing of the current color settings, but it
is better than overloading fg/bg [GTK_STATE_ACTIVE], which are used
for pressed in buttons already...

Of course, that does run into the problem that the CList uses
base/text[GTK_STATE_ACTIVE] for drawing the lines betweeen rows...

Really confusing thing about using ACTIVE for this ... "active"
is often used as a synonym for "focused" ... but 
NORMAL/INSENSTIVE/SELECTED are already in use, and PRELIGHT would
be almost as confusing.

> Index: gtk/gtktext.c
> ===================================================================
> RCS file: /cvs/gnome/gtk+/gtk/gtktext.c,v
> retrieving revision 1.104
> diff -u -p -r1.104 gtktext.c
> --- gtk/gtktext.c	2001/07/18 23:39:23	1.104
> +++ gtk/gtktext.c	2001/08/29 19:19:34
> @@ -4750,7 +4750,7 @@ draw_bg_rect (GtkText* text, GtkProperty
>         mark->index < MAX(old_editable->selection_start_pos, old_editable->selection_end_pos)))
>      {
>        gtk_paint_flat_box(GTK_WIDGET(text)->style, text->text_area,
> -			 old_editable->has_selection ?
> +			 old_editable->has_selection && GTK_WIDGET_HAS_FOCUS (text) ?
>  			    GTK_STATE_SELECTED : GTK_STATE_ACTIVE, 
>  			 GTK_SHADOW_NONE,
>  			 NULL, GTK_WIDGET(text), "text",
> @@ -4915,7 +4915,7 @@ draw_line (GtkText* text,
>  	  if ((mark.index >= selection_start_pos) && 
>  	      (mark.index < selection_end_pos))
>  	    {
> -	      if (old_editable->has_selection)
> +	      if (old_editable->has_selection && GTK_WIDGET_HAS_FOCUS (text))
>  		fg_gc = GTK_WIDGET(text)->style->text_gc[GTK_STATE_SELECTED];
>  	      else
>  		fg_gc = GTK_WIDGET(text)->style->text_gc[GTK_STATE_ACTIVE];

I think it would be better to avoid this change ... just leave GtkText
doing what it does now. 

Regards,
                                        Owen