A call to cairo_close_path() adds a straight line to the beginning of
the current sub-path. This is used in some of the shapes to, well, close
the shapes.
Sub-paths can be created explicitly via cairo_new_sub_path(), but also
implicitly via cairo_move_to(). When a new sub-path is started, there is
no current point on the path. This means that e.g. cairo_line_to() is in
this start equivalent to cairo_move_to() (= no line is created) and that
cairo_curve_to() first does a cairo_move_to() to the beginning of the
curve. Similarly, cairo_arc() and cairo_arc_negative() first do a
line_to() to the beginning of the arc, and this line_to() can be
implicitly turned into a curve_to().
The problem with the code in gears.shape is that parts of the code
(implicitly) assume that there is not yet any path when the shape
function is called. If this assumption is broken, the call to
close_path() could go to the wrong point, because the path did not start
at the expected position.
Most of the functions in gears.shape already implicitly start a new
sub-path via a call to cairo_move_to(). Those that do not (necessarily)
begin with a call to cairo_move_to() are handled in this commit: They
get an explicit call to cairo_new_sub_path().
This change fixes the issue reported at
https://github.com/awesomeWM/awesome/pull/2804, because the shapes will
no longer be influenced by the pre-existing path. The move_to() that was
left around and caused that issue turns into a degenerate part (it only
has a move_to(), so nothing can be drawn) and is then discarded by
cairo.
Signed-off-by: Uli Schlachter <psychon@znc.in>
ccaa75f4b4