By the way, if you have an interesting screenshot of LavaLauncher
running on your pine phone, I'd be interested to see it.

I am planning to replace the example picture with a tiny GIF that
loops over a few different examples to demonstrate some abilities and
I think phones are an important use case of LavaLauncher and should be
included there.


Friendly greetings,
Leon Plickat

LGTM, will commit. Only a single brace placement is off, but I'll just
fix that myself.

Thanks.

On Mon Jul 13, 2020 at 7:25 PM CEST, Nicolai Dagestad wrote:
> I also found out that there is a region outside the first button in
> which it is possible to escape the launcher without it being seen as
> outside the item (only with touch), but I don't think it is realated
> to this patch.

Nope, that should belong into a dedicated bug-fix patch.

On Mon Jul 13, 2020 at 1:10 PM CEST, Nicolai Dagestad wrote:
> I'm not against adding this. Is there something special in the wayland
> world that makes ressources not be free automaticcaly when a process
> exits ?

No, it is generally just good practice to clean up any allocated heap
object, despite the operating system de-allocing the memory on exit
anyway.

Another problem is reloading. When LavaLauncher reloads (due to a
config file change) it terminates the Wayland connection and restarts
it. Not cleaning up touchpoints would be another memory leak.

On Mon Jul 13, 2020 at 1:10 PM CEST, Nicolai Dagestad wrote:

Thank you very much. Overall this looks good to me and the behaviour
you describe sounds sane. I am especially happy that this fixes two
issues at once: Multiple touch points and aborting on motion being way
to sensitive. I can not test it since I lack touch hardware, but I
trust you did test this. There are just some minor fix-ups needed
after which I will commit your patch.

On Mon Jul 13, 2020 at 2:00 AM CEST, Nicolai Dagestad wrote:
> To support actions with multiple fingers, we would probably need to use
> frames.

Frames would be needed indeed. But for now I say we wait until there
is a reasonable use case for multi-touch before we overcomplicate
touch handling.

On Thu May 21, 2020 at 9:52 PM CEST, Philip White wrote:
> Just started using Mutt, and looks like my email client is messed up, so
> that last email didn't get sent correctly...hence the "DKIM signature: X
> fail" on lists.sr.ht.

I received your message, so everything is fine. And I am also not one
of those devs who will scream at you for slightly breaking mailing
list protocol, so don't worry.

But mutt kinda sucks, try aerc instead: https://git.sr.ht/~sircmpwn/aerc


Friendly greetings,
Leon Plickat

On Thu May 21, 2020 at 9:31 PM CEST,  wrote:
> Running the executable found at `build/lavalauncher`, but I was
> presented with the message "You need to provide the path to a config
> file"; this is a fine error message, and I am not at all confused by
> that, but my reaction to that is dismay because now I need to think
> about how I want to configure the tool.

Well, obviously you need to configure it. LavaLauncher has buttons
which display an image and execute a command; How am I (and therefore
LavaLauncher) supposed to know what images exists where on your
installation or what is a sensible command to run by default? There
simply can not be a default for this.

If I ever would make LavaLauncher start without a configuration file,

Today I released LavaLauncher version 1.7.0 and I though I should try something
new: Announcing the release on the Lavalauncher mailinglist. The new version
comes with many new features and changes. During the past few weeks I had the
chance to test LavaLauncher on compositors other than Sway and Wayfire, which
helped me refine its design.

CHANGELOG:
- New display mode 'simple'. This mode should be visually identical to 'default'
  mode, however the surface is _not_ sized to span the entire edge of the output
  it is anchored to. Instead it has the exact same size as the visual bar, and
  it is also only anchored to a single edge. On some compositors this may cause
  LavaLauncher to fit better onto the desktop geometrically. Also this mode
  has a smaller memory usage; Depending on screen size and bar size, the
  difference may be significant. Behold: On the current Sway release (1.4), the

On Di 18.02.2020, 08:13, Bob Hepple wrote:
> Here you go, hopefully final until the next release (if you could let
> me know when you release I can trigger the packaging).

LavaLauncher is essentially feature complete. There are a few things I'd like to
change in the future, but most of them are internal (one of which likely
requires a few changes to sway). My plan is to combine all these into a single
release, meaning 1.6 will be the latest stable version for the time being.
1.6 is also likely the last breaking change (with the exception of the '-m' flag
which I might remove).


Friendly greetings,
Leon Plickat

On Di 18.02.2020, 07:49, Bob Hepple wrote:
> whoops!
> 
> COPR is fixed up, here is the new spec file:
> [...]
> License:  GPL2

Thanks! (Although it is GPL version 3, not 2 :) I hate to be pedantic, but with
licensing stuff it is important.)


Friendly greetings,
Leon Plickat

On Mo 17.02.2020, 14:06, Bob Hepple wrote:
> Your code change worked very well - we now have some builds available
> for lavalaunch-1.6 for fedora-30 and 31 at
> https://copr.fedorainfracloud.org/coprs/wef/lavalauncher/builds/

Nice, I'll add that to the README.

> If you want to add the file lavalauncher.spec to your hg repo, feel
> free to do so - I am adding it to the end of this email. I hereby
> release it to the MIT license same as lavalauncher.

I will include the .spec file, however LavaLauncher is licensed under the GPLv3,
so you should probably change that for the COPR builds.