feat: shape styling options and easier highlighting

[anesthetice]

This PR introduces new shape styling options and a configurable highlighter brush type (for shapes).

The styling options include:

• Line Cap: Straight, Round
• Line Style: Solid, Dotted, Dashed (narrow, equidistant, wide)

As for the highlight mode, it simply adjusts the opacity of the active color(s) to a user-defined value.

Finally, this PR also re-arranges the shaper toolbar a bit.

fixes #852
fixes #375
(probably somewhat addresses other highlighting related issues but I am not 100% sure)

[flxzt]

Yes by using piet's abstraction the core logic is relatively trivially implemented - regarding integration into the UI what about adding another dropdown right above "shaper style"'s where a few predetermined stroke dash styles are available:

I am thinking about:

• solid
• dotted (1:1 ratio)
• short dashed ( 2:1, maybe? let's see what fits best)
• long dashed

this should give users some option without having complicated settings - for high precision shaping Inkscape is the better choice anyways.

What I think is worth discussing : what about offering more complicated choices like mixed dottted and shaped style's? Is that supported by piet currently?

[anesthetice]

Good suggestions, things should be kept relatively simple, concerning more complicated choices, they are somewhat possible, for example we could use a StrokeDash ~ [0, 3, 1, 3] and a round LineCap to create a dot-dash line

Implementation

Trickier than I initially thought, but still nonetheless possible, here's what I'm currently working on

• adding a shape_style entry to SmoothOptions shape_style: Option<ShapeStyle>
• ShapeStyle being a complex wrapper around piet::StrokeStyle
• ui: making a "Shaper Configuration"

Also considering adding a simple dashed line to the possible shapes

Tricky parts

1. piet::StrokeStyle contains piet::StrokeDash

/// A type that represents an alternating pattern of drawn and undrawn segments.
///
/// We use our own type as a way of making this work in `const` contexts.
///
/// This type `Deref`s to `&[f64]`.
#[derive(Debug, Default, Clone, PartialEq)]
pub struct StrokeDash {
    slice: &'static [f64],
    alloc: Option<Rc<[f64]>>,
}

Rc is neither Send nor Sync, which is required for items inside SmoothOptions

Currently trying to address this by using the Fragile crate, https://crates.io/crates/fragile, I thinks it's lightweight enough to add to rnote-compose (0 additional dependencies, read through the Fragile implementation, seems sound)

2. consistency

Hard to clearly explain this part, so I'll just be using an example:

Imagine you want a simple, pretty dashed line with rounded edges
unlike piet::LineCap::Butt, piet::LineCap::Round extends the length of a line in proportion to it's width, this will not be taken into consideration by piet::StrokeDash, it will have to be updated, neither will the width of the line itself, etc.

[MarcA711]

It would be useful if one can also select the brush style for the shape as well. This way one can select the brush marker and draw the shape line to highlight text. This would look much cleaner than highlighting the text freehand.

Moreover, why only implement styled lines for shapes? It would be useful to draw dashed/dotted lines freehand as well. Maybe this could be implemented similar to how it's done in Xournal++: You can select a pen independently (brush style, size, color, line style) and in the next step you choose if you want to use this selected pen freehand or with a shape. Why should freehand and shapes have different pens? This would also integrate nicely with #1175, because you can select the pen you want, draw something and use the hold feature to convert it to a shape.

[anesthetice]

It would be useful if one can also select the brush style for the shape as well. This way one can select the brush marker and draw the shape line to highlight text. This would look much cleaner than highlighting the text freehand.

Moreover, why only implement styled lines for shapes? It would be useful to draw dashed/dotted lines freehand as well. Maybe this could be implemented similar to how it's done in Xournal++: You can select a pen independently (brush style, size, color, line style) and in the next step you choose if you want to use this selected pen freehand or with a shape. Why should freehand and shapes have different pens? This would also integrate nicely with #1175, because you can select the pen you want, draw something and use the hold feature to convert it to a shape.

Good point, I'll see what I can do, under the hood pen strokes and shapes uses the same styles, so this might not be too complicated. I've also been thinking about having presets for pens and shapes, as having to switch back and forth within the settings is slightly inconvenient

[anesthetice]

Quick update: my Piet PR has been merged, and I’ve implemented the original idea - adding piet::StrokeStyle directly to SmoothOptions. As for the marker proposal, I tested it, but I don’t think it’s the best solution to the issues mentioned earlier. The preview doesn’t work (Worse, I'm not sure it can work at all), and (as expected) it still draws over text in an imported PDF. Instead, I’m considering adding a 'solid' and 'highlighter' option, where the highlighter would simply adjust the alpha of the current color to make it more transparent.

[flxzt]

the ShaperBrushType and ShaperStyle feel redundant.
What I think would make more sense is to integrate the Highlighter style into ShaperStyle and simply use the selected color opacity for this style.

[anesthetice]

the ShaperBrushType and ShaperStyle feel redundant. What I think would make more sense is to integrate the Highlighter style into ShaperStyle and simply use the selected color opacity for this style.

Yes that would probably be nicer, just to be clear you mean: make Highlighter a ShaperStyle (uses smooth_options + highlighter_opacity under the hood for the logic) and then just integrate the current Highlighter AdwSpinRow into the ShaperStyle GtkListbox?

Also could I have your thoughts on the following:

1. Moving everything inside the Shape Style popover into the Shape Configuration one
2. Using [0.00; 1.00] instead of [0; 100] for the highlighter opacity spin button
3. If it looks nicer, to only show the options for the active Shape Style and hide the rest?
4. Do you know of a way to make the content of an AdwSpinRow not be highlighted for manual editing when clicked on?

[anesthetice]

@flxzt In the end I don't think creating and using a highlighter shaper style is worth it as it doesn't fit the style or logic very well, however using a highlight mode toggle is pretty clean, also hiding the "unused" smooth or rough options seems nice (to me at least) as they are the same size

[flxzt]

I noticed the following unusual behaviour when activating the highlighter mode:
The fill of shapes seems to be affected when they are previously transparent. Maybe a special case for this needs to be added?

[anesthetice]

I noticed the following unusual behaviour when activating the highlighter mode: The fill of shapes seems to be affected when they are previously transparent. Maybe a special case for this needs to be added?

Good catch, never noticed as my background is white and my "transparent" fill color was always #FFFFFF as well, should be fixed now!

[flxzt]

what about this instead of manually implementing Deserialize ?

[flxzt]

I only pushed some minor adjustments (serialization with explicit names to avoid accidental breakage in case rust types are renamed), and some cosmetic code changes (builder pattern for piet's StrokeStyle). Looks good though, I'll merge when the CI finished successfully