On Tue May 11, 2021 at 2:29 PM CEST, Luis Cebrian wrote:
> Good day,
>
> firstly I would love to congratulate your hard work on lavalauncher,
> I've been using it for almost two years and it's an amazing and
> customizable launcher bar for wayland and I love it.

I am glad you like it.


> Secondly I've been killing the launcher everytime it executes a
> command with "& killall lavalauncher" after the given execution
> command so I have to launch it with a shortcut in sway everytime I use
> it because I just need it visible for each shot which doesn't bother

A new minor version of LavaLauncher has just been released, including
many fixes, a new layer shell version and a few minor changes.


Friendly greetings,
Leon Henrik Plickat

On Fri Apr 2, 2021 at 1:29 AM CEST, Ricardo Steijn wrote:
> Hello,
>
> I have a question regarding the processes executed by Lava Launcher.
>
> In my config i have the following:
>
> button {
> image-path "/path/to/img.jpg";
> command alacritty;
> }
>
> It seems however that the process still exists after exiting alacritty.
> This is produced by launching alacritty and closing it again.

Thanks, applied to master branch and lavalauncher-next.

Friendly greetings,
Leon Henrik Plickat

The BSD CI builds fine. And this does surprise me, given that
signal_source has nothing to do with the inotify code.

On Tue Mar 23, 2021 at 2:24 AM CET, Jan Beich wrote:
> ld: error: undefined symbol: signal_source
> >>> referenced by lavalauncher.c:190 (src/lavalauncher.c:190)
> >>>               lavalauncher.p/src_lavalauncher.c.o:(main)
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> ---
> src/lavalauncher.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/src/lavalauncher.c b/src/lavalauncher.c

I finally got around to apply this, in light of the coming Sway
version 1.6 updating the supported layer shell version. Once that
releases, I will issue a point release (2.1.0, which will probably be
the last release for major version 2).

I had to make some small changes (I was wrong, the protocol is still
at v1. Unstable protocols have two versions, one with a 'v' prefix and
one without.)

Thanks for your contribution.


Friendly greetings,
Leon Henrik Plickat

On Tue Feb 2, 2021 at 5:31 PM CET, Adrien Glauser wrote:
> [...] which makes me think that at least these two Wayland sessions
> have "objective" issues, visible from many use cases.
> [...] Does that make me and others users frustrated at Plasma 5
> Wayland issues conspiracy theorists?

No one is denying that there may be some issues. What matters is
what people do when they find that their use case is apparently not
supported in Wayland.

If Wayland or rather some implementation does not support your use
case and you feel like it should, you could just contact the developers,
/respectfully/ making them aware of your problem. If you are willing to
listen if the answer isn't a direct solution but rather suggesting

Thanks for the patch, review below.

On Tue Jan 26, 2021 at 5:49 PM CET, Bryan Ndjeutcha wrote:
> Second patch for center position
>
> - Removed default orientations in favor of an orientation config option

I am still not too sure about this, though I am not totally opposed to an
"orientation" option.

However, the way hiding is currently implemented, the size of the hidden bar
depends on the orientation, making the hidden bar awkward to use if the
orentation of the bar does not match the orientation of the screen edge it is
docked to. This needs to be changed before I can accept this patch.

On Sun Jan 24, 2021 at 12:56 AM CET, Drew DeVault wrote:
> I actually just gave you push access to the casa repository; I'm not
> particularly interested in its maintenance so you can help yourself to
> applying any patches you see fit.

Thank for the trust.

I'll do it in multiple patches then.


Friendly greetings,
Leon Plickat

On Sun Jan 24, 2021 at 12:41 AM CET, Drew DeVault wrote:
> Why not support any kind of axis event? Though if we're not sure it's
> from a finger it may be better to interpret any amount of "up" delta as
> committing to completely opening the drawer, and vice versa.

I initially had this idea as well, but have not yet come up with a way
to integrate it with the current approach of using an additional
touchpoint and the casa_surface_touch_{up,down}() functions for the
axis stuff.

Although I guess for discrete input devices the progress can be
manipulated directly, bypassing all of that.

I am just not sure about continous devices which are not guaranteed