The current css specifies "FontAwesome 5 Free Solid", for .drawing and
.text-button. This results in the button icons/fonts not rendering
correctly on systems that do not have that exact version of
FontAwesome. This change adds the more generic "FontAwesome" as an
option allowing the icons/fonts to be rendered correctly on these
systems.
Github has (it seems) updated the way to generate the `tar.gz` file.
I can't reverse engineer the way they do it, but they seem to do more
than just `git archive` now.
This adds an option on top of existing brush types, to allow for filled
shapes in addition to non-filled ones.
Signed-off-by: flow <flowlnlnln@gmail.com>
Closes#120
- Link for strftime(3) manpage is updated to use Arch Linux's manpage
website because it is more up-to-date.
- Link for Fedora package is updated to use the official package instead
of Copr.
- It's not a console application, so Terminal must be false.
- It can open only one file at once, so %f should be used instead of %F on the exec line.
- NoDisplay=true should be added, because the application cannot be launched without the file parameter.
If the input file is invalid (example: `grim` did not work due to
invalid geometry), handle the error gracefully.
Previously we had a coredump due to `g_error`.
Most of the filesystems have max filename limited to 255 chars.
Let's set that limit and handle the case where the resulting `strftime`
format is larger.
Closes#74
Most of the `i18n` boilerplate was there, but the app still needed to
know what domain to look for. This must happen after initialization of
the `GtkBuilder` and before loading the glade file.
The domain is simply the `mo` file packaged with the app and usually
located under:
```
/usr/share/locale/$LANG/LC_MESSAGES/$APP.mo
```
Once again thanks to @maximbaz for pointing it out.
Closes#92
We need to verify the sources from github match our local content.
We do this by building our own version of the git release (using `git
archive`) and checking the SHA-256 checksums against the local and
remote.
After that it's safe to sign the remote `tar.gz` and upload the
signature file to the release.
One caveat is that if Github upates their git release commmand, this
script will break. We'll worry about it when that happens.
This drops support for `zip` signature. I wish there was a way to
prevent the zip source code when doing a new release.
Closes#90
