The crop corners were drawn with the center of the corner lines at the
edges of the crop. This resulted in the corners being visually cut if
the crop is dragged to the edge of the image. Instead, we can draw the
corner lines such that they are inside the edge of the crop, i.e.
shifted by half their linewidth.
We now use relative moves to draw the lines, which simplifies the
movements.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1824>
If crop.x changes due to a drag, crop.x + crop.width remains fixed, as
thet is the opposite edge. However, in the mapping of paintable to
widget coordinates, crop->x + crop->width can vary due to rounding
errors. This fixes that, so that crop->x + crop->width does not vary,
with the same fix in the y direction.
However, the edges of the circle can still remain jittery due to integer
rounding, which is not fixed by using 'width / 2.0' instead of 'width /
2', since the width and height might differ by a pixel. Instead, draw an
ellipse, which removes edge jitter completely.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-control-center/-/merge_requests/1824>
The resizing and movement mechanics for the avatar crop can be finicky,
because:
1. The crop resets to the last valid crop when you drag out of range, so
that a somewhat quick drag does not go to the edge.
2. A corner drag only works in one direction, as the use of
eval_radial_line is not correct.
3. A side drag acts the same as a corner drag.
4. A slow drag won't move the crop, especially if the widget is larger.
All these issues are fixed with this partial rewrite of the resize and
movement logic:
1. A drag out of range will result in a size that is guaranteed to touch
the edge, making a crop to the edge much easier.
2. Instead of fixing eval_radial_line, we just "bind" one side to the
pointer position, making both directions act the same for a corner
drag.
3. A side drag now scales around the center for the orthogonal side.
4. Rounding errors in calculating the previous delta are prevented.
The CcCropArea dialog fails to update cursor to 'default'
one when leaving the CcCropArea into the GtkHeaderBar.
Fix that by setting 'default' cursor in the "leave" event
of CcCropArea.
Closes#2359
It’s possible for `gdk_cursor_new_for_display()` to return `NULL`. It’s
OK to pass `NULL` to `gdk_window_set_cursor()`, but not OK to then unref
it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Instead of trying to fill the displayed pixbuf with the background
color (and failing at that), just make the pixbuf be an aspect correct
scaled size of the original picture and draw it at the correct offset
on the draw vfunc.
This allows us to get rid of deprecated gtk+ API usage and fixes the
background around the picture ending up black despite de code's
intent.
https://bugzilla.gnome.org/show_bug.cgi?id=740986
Change default size for avatar cropping to correspond with changes in cheese.
The default size should be based on maximal size of the image instead of
minimal size for cropping.
https://bugzilla.gnome.org/show_bug.cgi?id=739871
Cheese has an internal copy of UmCropArea, and exports the corresponding
um_crop_area_get_type() as part of libcheese-gtk. This leads to a crash
when taking a photo in the avatar chooser, as the control center copy of
the get_type() function is used. Renaming the function in Cheese would
be an ABI break, so at this stage it is best to do the rename in the
control center instead.
https://bugzilla.gnome.org/show_bug.cgi?id=697039
2014-10-15 15:08:46 +01:00
Renamed from panels/user-accounts/um-crop-area.c (Browse further)
