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.

On So 16.02.2020, 15:08, Bob Hepple wrote:
> Yeah - I doubt the fedora guys would accept that (modifying the
> compiler options, that is), they're pretty starchy when it comes to
> that sort of thing.
> 
> I could compile it into my own very obscure COPR repo without using
> the fedora macros. I think that you'd be better served by fixing the
> compiler error and having it in fedora proper. Your choice, of course.

It is not an error per se, just that the Fedora guys (or the people upstream
at RedHat) use slightly more paranoid compiler flags for builds than I use on
my machine.

The increased rigidity is not a bad idea, so I made some changes to LavaLauncher

On So 16.02.2020, 08:59, Bob Hepple wrote:
> I'm trying to create a package for fedora for lavalauncher but I am getting
> a compiler error in the build. This is on fedora-31. I'm attaching the
> error log and the spec file (feel free to add the spec file to the project
> - it might come in handy!).
> 
> The build works when following your build instructions so I could always
> fall back on that but the rpmbuild macros may be a bit stricter. I'd prefer
> to user the stricter approach if possible - and the fedora people would
> insist on that.

I must admit that I am unfamiliar with the RPM build process, as I have always
lived in the apt / pacman sphere, however looking through the logs, I believe
this error might be avoided by an additional compiler flag: -Wno-maybe-uninitialized

Thanks for the patch, however:

On Mo 27.01.2020, 13:11, Nicolai Dagestad wrote:
>  	FILE* log=stderr;
> +	int daemonize=0;

Style: - '=' is always surrounded by spaces.
       - '*' always has a right-gravity; This comes from * having a right
         associativity in C.

On Mo 27.01.2020, 13:11, Nicolai Dagestad wrote:
>  	char opt;
> -	while ((opt = getopt(argc, argv, "qf")) != -1)
> +	while ((opt = getopt(argc, argv, "qd")) != -1)

This is a test of the new any fancy mailinglist for LavaLauncher.

-- 
Leon Plickat
leonhenrik.plickat@stud.uni-goettingen.de
PGP: 1A011200

This fixes the bug where clicking on a border would enable border
dragging even if the border was hidden under a view.

Letting wio_view_at() report where the given coordinates are on a view
enables us to check for views and borders of views in the same loop,
easily solving this problem.

Additionally this makes the border dragging code cleaner and enables
other functions as well to see where on a view was clicked.
---
 include/view.h |  11 ++++-
 input.c        | 110 +++++++++++++++++--------------------------------
 view.c         |  48 ++++++++++++++++++++-
 3 files changed, 94 insertions(+), 75 deletions(-)
[message trimmed]

This matches Rios behaviour, with the small exception that wios resizing
is smooth while Rios snaps to a grid.
---
 include/server.h |   4 ++
 input.c          | 163 ++++++++++++++++++++++++++++++++++++++++++++++-
 output.c         |  36 ++++++++++-
 3 files changed, 200 insertions(+), 3 deletions(-)

diff --git a/include/server.h b/include/server.h
index 4e729a1..60842e1 100644
--- a/include/server.h
+++ b/include/server.h
@@ -26,6 +26,10 @@ enum wio_input_state {
 	INPUT_STATE_RESIZE_SELECT,
[message trimmed]