Bug#930557: ITP: i3-gaps -- i3-gaps is a fork of i3wm featuring gaps, smart borders, smart gaps

[Socrates Tzagiousis]

Package: wnpp
Severity: wishlist
Owner: Socrates Tzagiousis <antiso...@gmail.com>

* Package name : i3-gaps
* Version : 4.16.1
* Upstream Author : Ingo Bürk
* URL : https://github.com/Airblader/i3
* License : (BSD-3-clause)
* Programming Lang: (C, Perl)
* Description : i3-gaps – i3 with more features including gaps, smart borders and smart gaps

i3-gaps is a fork of i3wm, a tiling window manager for X11. It is kept up to date with upstream, adding a few additional features such as gaps between windows

*** Why should it be submitted and differences to the original (vanilla i3): ***

i3-gaps is a popular fork of the most widely used tiling wm (vanilla i3), and is used exclusively by many people. It essentially contains a superset of functionalities to vanilla i3, and its gaps and smart border features as well as added i3bar RGBA transparency make it not only more pleasing to use, but easier to distinguish individual window frames without having to resort to colourful window frames and title bars as in the original.
It is included on the main repositories of most major distributions right now, and for good reason.

*** Maintaining the package: ***

I am a regular user and i plan to maintain the package by myself. I will need a sponsor, since i am starting out now.
It will also close this RFP bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909646)

[Philipp Kern]

Hi Socrates.

On 2019-06-15 15:11, Socrates Tzagiousis wrote:
[...]

> i3-gaps is a fork of i3wm, a tiling window manager for X11. It is kept
> up to date with upstream, adding a few additional features such as
> gaps between windows
>
>
> *** Why should it be submitted and differences to the original (vanilla
> i3): ***
>
> i3-gaps is a popular fork of the most widely used tiling wm
> (vanilla i3), and is used exclusively by many people. It essentially
> contains a superset of functionalities to vanilla i3, and its gaps and
> smart border features as well as added i3bar RGBA transparency make it
> not only more pleasing to use, but easier to distinguish individual
> window frames without having to resort to colourful window frames and
> title bars as in the original.
> It is included on the main repositories of most major distributions
> right now, and for good reason.

Why weren't the changes accepted upstream? Is this really a sustainable
fork that has sufficient interest?

Kind regards and thanks
Philipp Kern

[Michael Stapelberg]

Hey,

thanks everyone for reaching out.

The interest in making i3-gaps available to more people has prompted some discussion between Ingo (the maintainer of the i3-gaps fork, and an i3 core maintainer) and me.

The key concern about the i3-gaps fork is code quality: the implementation cannot easily be merged into i3 as-is. One example is that you cannot enable gaps and display title bars at the same time. The intention behind publishing the fork was to make the feature available to people who can live with the lower code quality and restrictions, not to have a long-term sustainable fork.

Ingo will outline what needs to be done to get i3-gaps into a mergable state, so that we can eventually bring these features to all i3 users.

For the time being, our recommendation is to NOT add i3-gaps to Debian or any other Linux distribution. Instead, if you have time and motivation, please consider helping improve i3-gaps with the goal of a merge.

Thank you,

--

Best regards,
Michael

[Dominik George]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi antisocrates,

> Ingo will outline what needs to be done to get i3-gaps into a mergable
> state, so that we can eventually bring these features to all i3 users.
>
> For the time being, our recommendation is to NOT add i3-gaps to Debian or
> any other Linux distribution. Instead, if you have time and motivation,
> please consider helping improve i3-gaps with the goal of a merge.

With that in mind, please reconsider your package, antisocrates, and
the invitation at hand ☺.

I strongly support the view not to add i3-gaps as a separate package,
now that it was made clear that there are efforts to get the gaps
feature merged.

Cheers,
Nik
-----BEGIN PGP SIGNATURE-----

iQJlBAEBCgBPFiEEPJ1UpHV1wCb7F/0mt5o8FqDE8pYFAl0Hz6IxGmh0dHBzOi8v
d3d3LmRvbWluaWstZ2VvcmdlLmRlL2dwZy1wb2xpY3kudHh0LmFzYwAKCRC3mjwW
oMTyliwpEADbI2jq1IiEhBjBi8qDSPaq3WGG8gNtC6kt57JXysUV+FerDrp9qwax
Z9HXHjyHyP4oxq0bpbJQHmYTjnNz4FknN2bqdqWO5/bBodOsYmrs4leailsqzDPX
aweB3HB46or6lZhCymwKZhhseL9Sv3aBbRBiusBI5umpuGlIwMm1cjXlGse6jUgp
+q28k9dydqHb14yxTjA4HPuWHamcoKAwT28IzTV5T6PaKKRiUgmdH6OqDXLpNTFO
8pWvldEHn8lL4QCFiu2kaDA3AAucAZ8++ebxzfyORksWAsLRT56tu+eBHt6nJyQs
hf+BeDAWUjOKmx304N38mPcHrhq+mFnNlaUtspxXhGEWOfSnce8ZDacN/ST6jepV
nB4vGdiyl6leUNTq9fDENg8UU00Hkpuz5n4pAzQMLc2nx6YLkujS7NOhNff8gwei
HiyYqCNK1ATw/X2r+RLl2oROgd+rBPQ5C2RZw2sm+sDd/hSZLEcO5kjDpXXyAze8
/8YhpbgsC5OSy7gK7UmKYm66pexKoto6VDeyh05gqG2z0eXTjpyM+19Rc6f9nZrv
Rnt/ON0xUFldZZ2s71nz0Wzc9zeDNQL40iisUZP1i8+qhoS7cuQKC3Kl0rUHkOqt
1ViYNdBszUkBuvCyuaZuPV3Oi2gpHfWbbqv8UBNjVK6iatZMf0UBgg==
=3IgO
-----END PGP SIGNATURE-----

[antisocrates]

A surprise, to be sure, but a welcome one.

Personally, seeing the popularity of vanilla i3 and by extension i3-gaps (which some people prefer aesthetically) in conjunction with the combined userbase of debian and all of its offspring, it became apparent i3-gaps should have been available sooner in debian.

If one was to graph the users the users of the debian-family of distributions and every other distribution family out there, it becomes clear that a lot of people might be missing something they are used to using elsewhere (most other big families of distributions have the fork available as can be seen here: https://repology.org/project/i3-gaps/versions).

And a lot of people have real trouble compiling this piece of software from source (mostly new linux users of the debian-derivatives).

Therefore since i use debian from time to time, when my gentoo box is occupied compiling for 12 hours straight, it occured to me i should package i3-gaps for debian and therefore all its derivatives to give people easy access.

Certainly, a merge is the superior solution and i am glad its actually being considered, but my understanding is that code refactoring/cleaning could take a considerable amount of time, and therefore the package should actually be available as a temporary solution for all those who want to use it, as it currently is everywhere else.

Again, i congratulate Michael and Ingo for their work.

[Michael Stapelberg]

> Certainly, a merge is the superior solution and i am glad its actually being considered, but my understanding is that code refactoring/cleaning could take a considerable amount of time, and therefore the package should actually be available as a temporary solution for all those who want to use it, as it currently is everywhere else.

I don’t think having it available temporarily is a good idea. It complicates the situation both for the package maintainers and for end users.

--

Best regards,
Michael

[Vincent Bernat]

❦ 17 June 2019 18:30 +02, Michael Stapelberg:

> Ingo will outline what needs to be done to get i3-gaps into a mergable
> state, so that we can eventually bring these features to all i3 users.
>
> For the time being, our recommendation is to NOT add i3-gaps to Debian or
> any other Linux distribution. Instead, if you have time and motivation,
> please consider helping improve i3-gaps with the goal of a merge.

It seems there is not much progress on this front. The issue on GitHub
does not show activity either. As other popular desktop distributions
(Fedora, openSuSE, Arch and Manjaro) are providing a i3-gaps package,
maybe an i3-gaps package in Debian could be reconsidered?

I would gladly sponsor it if there is no strong opposition from i3
maintainers.
--
Write and test a big program in small pieces.
- The Elements of Programming Style (Kernighan & Plauger)

[Michael Stapelberg]

I still think it’d be better to spend time on merging gaps rather than packaging gaps,

but it seems like nobody has the skill set and/or motivation.

Is there someone who would continuously maintain i3-gaps in Debian?

I wouldn’t want that package to diverge from upstream i3 in terms of which version is available in Debian.

I’m asking in particular because people might switch from X11+i3 to Wayland+sway over the next few years.

--

Best regards,
Michael

[Vincent Bernat]

❦ 3 October 2021 08:48 +02, Michael Stapelberg:

> I still think it’d be better to spend time on merging gaps rather than
> packaging gaps,
> but it seems like nobody has the skill set and/or motivation.

This is a very different skillset from packaging.

> Is there someone who would continuously maintain i3-gaps in Debian?
> I wouldn’t want that package to diverge from upstream i3 in terms of which
> version is available in Debian.

Alternatively, src:i3-wm could build both i3-wm and i3-gaps. It adds
extra work on existing maintainers but maybe you and Jakob would be OK
with that? I can propose a patch for that if it helps.
--
Use recursive procedures for recursively-defined data structures.

[Michael Stapelberg]

Personally, I don’t want gaps to be built from src:i3-wm.

It’s enough work to maintain one version of i3.

That said, sur5r is doing all of the Debian work since I retired from Debian,

so it’s ultimately up to him.

I will stress one more time that what we need here is not a one-time sponsorship offer,

but a multi-year commitment for maintaining the i3-gaps package in Debian.

On Sun, 3 Oct 2021 at 08:57, Vincent Bernat <ber...@debian.org> wrote:

 ❦  3 October 2021 08:48 +02, Michael Stapelberg:

--

Best regards,
Michael

[Vincent Bernat]

❦ 3 October 2021 09:16 +02, Michael Stapelberg:

> I will stress one more time that what we need here is not a one-time
> sponsorship offer, but a multi-year commitment for maintaining the
> i3-gaps package in Debian.

Let's hear from antisocrates. I can offer a multi-year commitment for
sponsorship and take over maintainance if needed. I can also maintain it
myself.

I suppose you would favor i3-gaps to conflict with i3-wm instead of
trying to be co-installable (with or without alternatives as the
difference is limited to a few binaries and I think this does not
include i3-msg).
--
Must I hold a candle to my shames?
-- William Shakespeare, "The Merchant of Venice"