[Users] [Bug 2577] Focus rectangle on folder list and message list headings doesn't get properly ...

[Michael Shell]

On Wed, 22 Feb 2012 22:10:49 -0500
Michael Shell <list1 at michaelshell.org> wrote:

> http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=2577
>
> I will try to look into this further and see if my eye catches any other
> "off by 0.5 to 1.0 pixel" errors. Sigh.


OK, to review, the first part of the phantom line bug can be addressed
by changing the code of src/gtk/gtkcmctree.c around line 936 to read:


   /* draw focus rectangle */
  if (clist->focus_row == row &&
      gtk_widget_get_can_focus (widget) && gtk_widget_has_focus (widget))
    {
      if (!area || gdk_rectangle_intersect (area, &row_rectangle,
					&intersect_rectangle))
	{   cairo_set_line_width(cr, 1.0);
	    cairo_set_antialias(cr, CAIRO_ANTIALIAS_NONE);
	    gdk_cairo_set_source_color(cr, &style->fg[GTK_STATE_NORMAL]);
	    cairo_move_to (cr, row_rectangle.x, row_rectangle.y + 0.5);
	    cairo_line_to (cr, row_rectangle.x + row_rectangle.width, row_rectangle.y + 0.5);
	    cairo_move_to (cr, row_rectangle.x, row_rectangle.y + row_rectangle.height - 0.5);
	    cairo_line_to (cr, row_rectangle.x + row_rectangle.width, row_rectangle.y + row_rectangle.height - 0.5);
	    cairo_stroke(cr);
	}
     }
    cairo_destroy(cr);



Now, a workaround for the second phantom line bug can be had by adding the
following two lines of code (the first one is long, so watch out for
email wrapping) to src/gtk/gtkcmctree.c:



cairo_rectangle(cr, cell_rectangle.x, cell_rectangle.y + row_rectangle.height + 1,cell_rectangle.width,cell_rectangle.height);
cairo_fill(cr);


after the cairo_fill(cr); on line 697 *as well as* after the
cairo_fill(cr); on line 706. 


This is a bit of a hack, but seems to work well enough in my tests.
It seems that when the user scrolls down the message list with the
keyboard (but not up), a single pixel grey line intrudes into the top of
the row below it. If the user then uses the mouse to select a message not
adjacent to the affected rows, the phantom line will remain, I am unable
to determine the source of this phantom line using test code in
gtkcmctree.c. It may be coming from a GTK+ operation of some sort and not
from drawing code within gtkcmctree.c itself. It even looks like a video
driver bug, but I disabled video card hardware acceleration in Xorg to no
effect.

The problem may be related to Claws' use of a single pixel wide 
spacer/border/cell line above each row. Given that recent versions of
Claws now use row stripeing, these spacer/cell/border rows must be
now be treated and updated as if they were part of the row they belong
to (e.g., any row color changes must now apply to them as well). The
above patch code forces a rewrite of the spacer line *below* the updated
row as well as the one above it (the top is normally the only one written
when the row is updated) thus overwriting any phantom line just below the
row.

It may be prudent in future versions of Claws to totally remove the code
for the spacer/cell/border (CELL_SPACING = 0) stuff (unless it is needed
for something other than I am aware of, what good is it now?) and the
default row height increased by 1-2 pixels to retain the same row spacing.

Incidentally, Claws' code in src/gtk/gtkcmctree.c does not seem to be able
to handle the case of

#define CELL_SPACING               1

being set to anything other than unity.

FWIW, to make these border rows visible (green) for test purposes to see
what is going on, add the line:

cairo_set_source_rgb (cr, 0.0, 0.9, 0.0);

before the cairo_fill(cr); on line 697 and again before the
cairo_fill(cr); of line 706 (in src/gtk/gtkcmctree.c).

On an otherwise uncorrected gtkcmctree.c, note how stepping the selection
row upward with the keyboard erases the borders while stepping downward
restores them. This is because they are being erased at the bottom of the
row, while only being written/restored on the top. When the eraser follows
the writer (upward movement), they are lost, when the writer follows the
eraser, they are restored. The two line patch causes both the top and
bottom borders to always be rewritten on update preventing the problem.


  Cheers,

  Mike Shell