• This PR implements a file monitor for the current output file, as discussed in #347.
• Uses toasts to indicate moves/deletions, renames, and modifications (with a button for reloading).
  • Updates the output file and unsaved changes flag accordingly.
• Refactors toasts and adds toasts with buttons.
• It makes special treatment for file row actions redundant, which is why it partially reverts #347 and fully reverts #343.

(For more details, see discussion below.)

• Adds caching like described in the first half of #393.
  • A cache is invalidated as soon as (the hash of) Cargo.lock changes. If that happens, the latest cache is restored anyway, but the cache is rebuilt at the end of the build process.
• Renames most of the steps, or adds names if they were missing.

Things to consider:

• rustfmt is already included in the used toolchain, and the step that's supposed to install it (rustup component add rustfmt) only logs that it's up to date. It could be safely removed as far as I can tell, but there would be no benefit in terms of time.

The current icon doesn't quite fit the HIG, would you be interested in help with a new one?

Here's a first idea I had, but I'd be happy to try something else:

Describe the bug Instead of immediately switching to pen eraser stays for one more stroke after I let go of the eraser button on the stylus.

To Reproduce Steps to reproduce the behavior:

1. Press and hold the eraser button on the stylus
2. Let go of it
3. Try to draw something with a "pen"
4. See that the tool for the current stroke is still eraser

Expected behavior I expect to be able to draw immediately after letting go of the eraser button.

** Console Output ** None

Desktop (please complete the following information):

• OS: Gentoo GNU/Linux
• Installation source: build from source commit 2b8248e60f010c3bf5df91f0ed849cbb47fcf367
• Desktop Environment: KDE Plasma 5.23

Additional context Wacom in-screen sensor & Wacom Bamboo Ink stylus, the issue is reproducible with other styluses

Hi Felix. These are just some suggestions to potentially clarify menus in the app.

What I found

• The use of "Sheet" everywhere. When the user has "show format option" active, the user is exposed to, in a way, multiple sheets. Therefore, options such as clear sheet, save sheet and so on could infer saving only the active "sheet". In this merged request, I changed "sheet" to "document" where necessary, while keeping "sheet" for "Sheet format", "Zoom to fit sheet width" etc.

• "Expand mode" to "Layout"

• "Endless vertical" to "Continuous vertical"

• "Export .." to "Export…"

Tell me what you think.

Fixes #124 when closed. Currently this provides 1:1/3:2/golden ratio-based constraints for lines, rectangles and ellipses.

Some problems:

• I'm not sure the current way to pass ratio to Builders is readable... it could be a parameter for Shaper::handle_event, or could be put in PenEvent?
• How Foci ellipses and bezier curves should be constrained?

The PR improves the contrast of the border around color buttons by mixing the default border color with the current foreground color. This fixes the issue mentioned in the first part of #305 - if you look closely, you can see that there is a border around the first button, but it is nearly identical to the current background color, making it look like an indentation issue.

dark theme | light theme :-------------------------:|:-------------------------: |

The PR also adds 1px of margin to the bottom of each button. This improves/fixes (?) the second issue mentioned in #305.

0px | 1px | 2px :-------------------------:|:-------------------------:|:-------------------------: | |

EDIT: The PR also fixes the border radius and brightness transitions when switching between or hovering over/clicking on colors.

TLDR:

• Closes #305.
• Fixes transition when hovering over & switching colors.

Adds "2D coordinate system", "3D coordinate system", "2D single quadrant coordinate system".

Things to consider/discuss:

1. Each shape builder currently emits 2 line shapes per axis, making it possible to only delete the positive/negative part.
2. The 3D coordinate system is very simplified (the X axis is at an 45° angle), making it simple to use but not suitable for accurate representations.
3. There is no 3D single octant coordinate system at the moment, and I don't think that's necessary either.
4. The boundary of the shape builders is currently computed by merging the AABBs of all the lines that are involved; this could be heavily simplified by creating a single AABB using the axes as half extends, but doing so wouldn't take the shape style into account. Realistically, the loosened operation should take care of minor differences due to the shape style, but I went for the most accurate and "future-proof" solution for now.
5. The 3D coordinate system builder could be turned into a two step builder (like the ellipse builder), allowing you to "define" your own X axis length.
6. (These builders should be grouped and collapsible, but that should probably be done in a separate PR/commit.)
7. (Rename some of the shapes? Improve some of the symbols?)

Extending https://github.com/flxzt/rnote/issues/17 and follow up on https://github.com/flxzt/rnote/discussions/177, I implemented paste from a direct screenshot save. Not sure if it's the way to go, but it works. The branching is getting a little too big though.

Many of the tool icons are not hinted to the pixel grid, have too much detail, or are using an older, smaller/less geometric GNOME symbolic style.

I'd recommend switching them to the following icons from Icon Library:

• Brush: paintbrush
• Shaper: shapes
• Typewriter: text3
• Eraser: eraser4
• Selector: edit-select-all
• Tools: wrench-wide

Specs

Rnote version: 0.3.1

Current behavior

When I open or import a pdf with rnote it just crashes.

Below is the cli output when I launch rnote and import a pdf.

$ flatpak run com.github.flxzt.rnote

(rnote:2): Gtk-CRITICAL **: 16:35:41.552: gtk_widget_set_parent: assertion '_gtk_widget_get_parent (widget) == NULL' failed

(rnote:2): Gtk-CRITICAL **: 16:35:41.553: gtk_widget_set_parent: assertion '_gtk_widget_get_parent (widget) == NULL' failed

(rnote:2): Gtk-CRITICAL **: 16:35:41.597: gtk_widget_set_parent: assertion '_gtk_widget_get_parent (widget) == NULL' failed

(rnote:2): Gtk-CRITICAL **: 16:35:41.597: gtk_widget_set_parent: assertion '_gtk_widget_get_parent (widget) == NULL' failed

(rnote:2): Gtk-CRITICAL **: 16:35:41.628: gtk_widget_set_parent: assertion '_gtk_widget_get_parent (widget) == NULL' failed

(rnote:2): GStreamer-WARNING **: 16:35:41.680: loop detected in the graph of bin 'marker_pipeline'!!

(rnote:2): Gdk-CRITICAL **: 16:35:53.507: gdk_memory_texture_new_subtexture: assertion 'x < 0 || x >= GDK_TEXTURE (source)->width' failed

(rnote:2): Gdk-CRITICAL **: 16:35:53.507: gdk_texture_get_width: assertion 'GDK_IS_TEXTURE (texture)' failed

(rnote:2): Gdk-CRITICAL **: 16:35:53.507: gdk_texture_get_height: assertion 'GDK_IS_TEXTURE (texture)' failed

Expected behavior

Previously (v0.2.5 or so) it was able to open pdfs without issues.

There is an option for a 2d coordinate system under the "shape builders" menu, but it is quite difficult to use the axes to sketch any of the common functions by hand. It would be useful if you could create sine/cosine/tan functions as shapes that you can put on top of the 2d coordinate system shape. There doesn't need to be any customisation for the functions, as if you're doing a sketch you won't mind getting an approximation by just dragging the functions along the axes, and if you're doing anything other than a sketch, you should probably just use actual graphing software and import a vector graphic from that.

Describe the bug When I open a PDF through rnote, the pages are not aligned with rnote pages.

To Reproduce Steps to reproduce the behavior:

1. Right click on pdf
2. Choose "Open Width"
3. Choose "rnote"
4. See error

(same happens when importing the pdf from a new rnote window)

Expected behavior The pages to be aligned.

** Console Output ** There was no output.

Screenshots

Desktop (please complete the following information):

• OS: EndeavourOS (rolling distro and kept up-to-date)
• Version: Rnote: 0.5.12
• Installation source: flatpak
• Desktop Environment: Gnome 43.2

Describe the bug The save button in the top left uses a download icon instead of the normal floppy diskette to represent saving, which just isn't intuitive and is confusing.

To Reproduce Steps to reproduce the behavior:

1. Look at the top left save icon
2. It's a download icon

Expected behavior The save button should use a save icon.

Screenshots

Desktop (please complete the following information):

• OS: Fedora
• Version: 37
• Installation source: Flatpak
• Desktop Environment: Gnome 43.2

Is your feature request related to a problem? Please describe. Currently it is only possible to export the selection, which has automatic, fixed bounds.

Describe the solution you'd like It would be nice to be able to export all strokes that are inside a user defined rectangle.

Describe alternatives you've considered Currently the only way to do that is either through a screenshot tool for bitmap images or for SVG's editing through an external program like inkscape after export.

Describe the bug When exporting selected elements that contain text pieces as raster images (jpg/png), the exported text color is incorrect (black instead of selected red). The text color is correct when exporting as pdf or svg (red). Included example problematic rnote file in attachment below.

The interesting thing is that when selection contains text elements with 2 different colors it works correctly (sometimes).

To Reproduce Steps to reproduce the behavior:

0. Open new rnote document.
1. Select "Typewriter"
2. Change color to red
3. Create some text
4. Pick "Selector" and select text
5. Menu -> Export -> Export selection
6. Set export format to png or jpg
7. Save file
8. The color of the text on the exported image is black

Expected behavior The color of the text on the exported image is red

** Console Output ** Only a few instances of

(rnote:2): Gtk-CRITICAL **: 15:14:16.460: The layout manager of type GtkBoxLayout 0x7fbdc8003200 does not create GtkLayoutChild instances

Screenshots N/A

Desktop (please complete the following information):

• OS: Debian
• Version: Sid
• Installation source: Flatpak
• Desktop Environment: Gnome 43.1

Additional context test.zip contains the test rnote file, exported png with wrong color, and exported svg with correct color.