Physics student, hobby programmer, Free Software advocate.

My projects are opinionated yet configurable, batteries included yet fairly minimal and always free as in freedom, created to enhance the modern Linux / UNIX desktop experience.

I am currently interested in filling some of the holes of the Wayland desktop landscape and experimenting with user interfaces.


Last active 6 days ago


Last active 21 days ago
View more

Recent activity

Re: wlclock: -Dhandle-signals=disabled fails to build on FreeBSD 6 days ago

From Leon Plickat to ~leon_plickat/public-inbox

On Thu Nov 19, 2020 at 6:06 AM CET, Jan Beich wrote:
> Regressed by https://git.sr.ht/~leon_plickat/wlclock/commit/74a155389c20
> Found while packaging/testing meson_options.txt with non-default values.

Fixed, thanks for the report.

Do you need a point-release for packaging?

Friendly greetings,
Leon Plickat

Re: Mini-Survey: Does anyone use the `mode` and `alignment` options? 21 days ago

From Leon Plickat to ~leon_plickat/lavalauncher

Hi again.

I got an answer to the mini survey explaining a good use case for the
mode "full". To make it short: This mode is apparently useful for
phones, to replicate the android-typical "app drawer" thing at the
bottom of the screen.

As such, I decided to keep the "full" mode. However some changes will
still be made: "default" mode will be renamed to "aggressive" mode and
"simple" mode will be the new default.

Friendly greetings,
Leon Plickat

Mini-Survey: Does anyone use the `mode` and `alignment` options? 22 days ago

From Leon Plickat to ~leon_plickat/lavalauncher

This is a mini-survey asking any users of LavaLauncher whether they
use the `mode` and/or `align` options.

I have some things planned for LavaLauncher, however before I can
comfortably work on those things, I need to clean up the code base.
There being multiple different modes massively hurts code quality, so
I would like to remove these features.

LavaLauncher will then behave like it does if `mode` is set to
`simple`. This is the way I always imagined LavaLauncher to work, the
different modes were just a workaround for a bug in Sways layer shell
implementation. I have since fixed that bug in Sway and I believe
other compositors implementations of the layer shell have also been

Re: [PATCH] Fix typo a month ago

From Leon Plickat to ~leon_plickat/public-inbox


Friendly greetings,
Leon Plickat

[PATCH gmni] Correctly abort when launched with invalid URL 2 months ago

From Leon Henrik Plickat to ~sircmpwn/public-inbox

The return value of set_url() was not checked, meaning that when it
failed, gmnlm continued anyway, causing an assertion to fail and
subsequentially resulting in a segfault.
 src/gmnlm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/gmnlm.c b/src/gmnlm.c
index 41284df..5997edd 100644
--- a/src/gmnlm.c
+++ b/src/gmnlm.c
@@ -780,7 +780,9 @@ main(int argc, char *argv[])

[message trimmed]

Re: [PATCH] types: avoid casting to non-standard __off64_t 2 months ago

From Leon Plickat to ~leon_plickat/lavalauncher

Thanks, applied.

Friendly greetings,
Leon Plickat

Re: [PATCH scdoc] Exit parse_text() on linebreak with "++" 3 months ago

From Leon Plickat to ~sircmpwn/public-inbox

On Sat Aug 29, 2020 at 8:30 PM CEST, Drew DeVault wrote:
> I would really prefer if you added an automated test for this.

I get it. Would you prefer a test for the next line simply starting
with '\t' or doing a "full" indentation check with parse_indent()?

Friendly greetings,
Leon Plickat

[PATCH scdoc] Exit parse_text() on linebreak with "++" 3 months ago

From Leon Henrik Plickat to ~sircmpwn/public-inbox

This fixes a bug causing incorrect indentation when the first char in
the next line after an indented line ended with "++" is '\t'.
As suggested, I tested this patch with multiple different cases, like
linebreak on indented line and the next line having a (vastly)
different indentation. I also tried generating sway(5) and searching
through that for any unexpected formatting. All cases I tested have
the same result as if generated without this patch, just with correct
indentation after linebreaks. Therefore I still do not think the test
is necessary, so I did not include it in the patch.

src/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
[message trimmed]

Announcing LavaLauncher version 2.0.0 3 months ago

From Leon Plickat to ~leon_plickat/lavalauncher

I just released version 2.0.0 of LavaLauncher.

This is most radical update of LavaLauncher to date. This new version
not only introduces a lot of new features, but also completely
overhauls the configuration as well as basically all internal data
structures and operations. If all patches since the last version are
considered, this is almost a complete rewrite, hence the major version

- LavaLauncher is now configured via a configuration file instead of
  command flags. This not only provides a considerably more pleasant
  user experience, but also makes more complex configuration options
  possible, allowing LavaLauncher to gain a lot more useful features.

Re: [scdoc] Incorrect indentation when line ending with ++ is indented 3 months ago

From Leon Plickat to ~sircmpwn/public-inbox

On Wed Aug 26, 2020 at 3:50 PM CEST, Drew DeVault wrote:
> This patch might be a good solution but it would be better with a
> test attached.

I am not sure I understand what test you mean. Test whether the line
is indented before returning and otherwise using the old behaviour?

I may be missing something, but on an unindented line, whether we
directly return after a linebreak or let parse_text() explicitly
handle the newline makes little difference. The resulting output is
the same.

Unrelated, but should the queue be flushed to output before returning?