u/No-Dentist-1645

I love Niri, but sometimes the development speed of it seems a bit slow. I've been closely monitoring some feature PRs that I would love to have, primarily Hidden Workspaces, Floating Windows on top of Fullscreen Windows, and Sticky Floating Windows that follow you across Workspaces. The Pull Requests for these features already exist, but they have not yet been merged into the Niri main branch.

Now, I am not trying to blame the Niri devs for not merging these yet, they have a lot of work on their hands and they want to make sure that all features work perfectly before they can add them. However, they are still fun features, and you have always been able to try them today just by using the PR branches and compiling them yourself. However, the problem arises if you wanted to try multiple of these features yourself, since you can't just use all the different branches at the same time.

So, that's what this solves. Niri-QoL is a soft fork of Niri with some feature PRs added. This means that it is my intention to keep this fork closely aligned with the official Niri repository and merge their latest commits. What I have done is the work necessary to merge the quality of life features that I've been waiting to have been merged into the official Niri. These include:

• Hidden workspaces
• Add window-rule float-above-fullscreen
• Add open-sticky window rule for sticky floating windows across workspaces

Of course, credit for most of the hard work goes to the PR authors :).

You can install Niri-QoL by either cloning the repo and building it yourself or using the AUR package: https://aur.archlinux.org/packages/niri-qol-git

AI assistance disclosure: An LLM was used to assist in the supervised process of resolving merge conflicts while merging the PRs together. All output generated was thoroughly reviewed, I take responsibility for the resulting code as if it was fully my own and solemnly claim that its resulting quality is on par with what I would have produced without its assistance. This is on par with the upstream Niri contribution guidelines regarding AI contributions as well as already existing commits co-authored by LLMs.

Hello everyone,

In my free time, I've been working on a project that started off from inspiration by the recent AUR events and discussions. In my opinion, the current AUR system has some fundamental flaw that makes it really difficult to ever have truly "trustworthy" packages: a) strong centralization on official Arch maintenance, and b) lack of real "ownership" by project developers.

The first one is a problem, since the AUR is, as we all know, an unofficial, "user driven" reposotory. Anyone and everyone can submit a PKGBUILD for whatever package they want, no matter if they actually are the developer of said application or not. Of course, this has advantages: it's one of the reasons the AUR can even be as big as it currently is! However, one could also argue that someone might want an alternative that prioritizes trust and ownership over raw "repository package count". The second point is also a big problem for this, even if the owner of a piece of software decides to create and manage their own AUR package for their program, you still can't blindly "trust" the package. This is because the owner may, at some point, lose interest in maintaining the AUR package, at which point the package will be orphaned and anyone else can adopt it and keep maintaining it. Again, there are advantages to this design choice and I understand why Arch made it as such: it helps maintain AUR packages alive even after the original creator loses interest. But it's also a choice that reduces the "trust" of a package.

Because of these reasons, I have been working on an alternative to the AUR system entirely: centralized, author-controlled git repositories. The current name for the project is APRA (Arch Personal Repository Archives), but it is subject to change. The idea is, instead of trusting the names of a package on a centralized repository (AUR), where the owner may change at any moment's notice, you trust git repositories that belong to specific organizations or owners.

Here's a current minimal example. Let's say you want to have the "libfoo-git" package by the developer "cooldev". The idea is, that if the project author is interested in it, they can host their own APRA git repository under their account. It is a completely regular git repository, all you need is to name one of the branches as your packakge, "libfoo-git", together with a PKGBUILD with the recipe to install the program (basically how the AUR already works behind the scenes). Then, the user just needs to edit their APRA yaml config and add the repository, as such:

remotes:
  - name: cooldev
    url: https://github.com/cooldev/APRA-Repo.git
    whitelist: libfoo-git

Then, the user can just install the package with APRA as if it was an "aur wrapper" (even though it's not), as apra -S libfoo-git or apra -S cooldev/libfoo-git. APRA will then search cooldev's APRA repository and run the PKGBUILD. What is the advantage of this approach? That cooldev directly owns the git repo at the url for https://github.com/cooldev/APRA-Repo.git. The same person as the developer of said software has full control over the PKGBUILD, as well as who is allowed to contribute to it.

---

So, that's the project that I'm working on, and I would like to see if the community is interested in an approach like this. Knowing Reddit, I know some people will see this announcement and mistake it for something that it absolutely isn't, so here is a quick FAQ:

0. Why do we need yet another AUR wrapper like paru or yay?

It is not an AUR wrapper. In fact, it is specifically designed not to even talk to the AUR, similar to "base" pacman, since that would go against the entire idea of only reaching "trustable" package sources.

1. Is this meant to replace or compete with the AUR?

Not at all. The AUR is an amazing place, I use it all the time and love it! However, there are some fundamental design choices (that are perfectly valid and have their own advantages) that make it difficult to tell someone you can fully "trust" an AUR pacakge. This is an alternative, similar to Debian PPA's, where you the user, specifically add repositories you want to trust, and use those instead.

2. You can already create your own Unofficial User Repositories, why would I do this instead?

Yes, you can create your own user repository and add it to pacman's config. While this is true and there are already several user repositories, the friction required for a developer to create and maintain their own repository is significantly high, and you would also need to find and pay for some suitable hosting infrastructure for it. On the other hand, git repositories can be created as simply as clicking "new repository" on GitHub, and many if not most developers are already experienced with this.

3. Just read the PKGBUILD for AUR packages!!

I know I can read a PKGBUILD and probably confirm if it is secure or not. However, can you trust everyone and anyone who uses Arch to do the same thing? Plus, let's set something straight: requiring due diligence to read and verify every PKGBUILD you ever insntall can get annoying sometimes, especially the more AUR packages you have. Just think if you had to read the PKGBUILDs of every package you currently have installed, not just from the AUR. It would get tiresome, right? Fortunately, we don't have to do that, since we all implicitly "trust" the packages that are officially maintained in the Arch repos by trusting the Arch team. I want to add something like that, but instead of only trusting the Arch package maintainers, you can also trust the, say, Libreoffice developers, if they ever chose to create their own APRA repository.

4. It will be very hard to start such a project and convince program developers to actually use it

I know. However, that still won't stop me from trying :). If I can get at least one or two developers to use it, even if they still maintain their own AUR packages at the same time, I would consider that a win :)

---

TLDR:

I want a way for Software Developers to easily host and fully control their own package repositories for their own projects, increasing user trust in said packages since, well, they would be maintained by the same people who make the programs in the first place. This is what my project aims to do.

Let me know what everyone thinks! And of course, if you have any criticism of what is currently done poorly and wanna recommend a better way that it could be done, I'd love to hear it.

Hey all,

I am interested in installing one "quick navigation" plugin to allow me to easily go to a specific word on my screen with just a few keybinds. I haven't tried one yet, but from googling I found three main "active" plugins: leap.nvim, flash.nvim, hop.nvim. I am mostly looking for just a simple "go to this word" hotkey, currently hop.nvim looks like the ideal match for this, but leap and flash seem more capable and you can probably do way more with them, but I just don't know exactly *what* you could do and how that would help me with my workflow.

Has anyone here tried any or all of these plugins and can recommend one? I'm looking for general recommendations, but if you've tried leap and/or flash, I'd like to know how you take advantage of their extended functionality to help with your workflow.

WHY does it show up as "idle" when you just have the launcher open? Isn't the point of RPC to show your activity of what you are playing? "Ah yes, I am currently gaming the Modrinth Launcher™ Library Menu"

Please, just change it so that it shows what you are playing only when you are playing something. Just having "Playing Modrinth" on your profile as your constant status just because you have the launcher open in the background and you haven't opened it in hours only seems like bad advertising

PS: I know that you can disable it altogether in the settings. That's not what I want/I'm suggesting. I want it to never show up just as "idling", that's useless and annoying

Hello,

I have been developing a C++ Voxel Game during my free time for about 4 months already. I am currently using OpenGL for my graphics API, currently rendering is isolated to a `GLRenderer` class, which is just around 2k lines of code long. So far I have been able to apply some basic optimizations to it such as vertex culling and pooling without too much difficulty.

That being said, I keep hearing some people online claiming that OpenGL is an "old" API and that it doesn't fit "modern" GPUs that great. I know that Vulkan exists, but I also know that it's way too verbose, so I have reasons not to want to use it instead, since a) this is a project I can only work on during my free time as I said, and b) even if I wanted to go the extra mile and make Vulkan work, it would add too much development overhead in the future, and more related to the point of this post, I don't know if it's even worth it for a voxel game project. I have also heard about WebGPU and the C++ "Dawn" implementation, which WebGPU seems to be a more "modern" API that can be more optimized than OpenGL while also not being as verbose as Vulkan, but I have seen it described as a "browser-first" API, and from a bit of googling it doesn't seem like there are many (if any) voxel Games actually written using it.

For that reason, I've come to this subreddit for advice. My gut feeling is telling me that sticking to OpenGL is fine: there are many online examples of voxel games using it, so there must be a reason why they do. However, WebGPU and Vulkan do seem to be like the more modern choices, and I may be missing something. As I said, I am still on the very early stages of my own project, the OpenGL renderer class is about 2k lines long, so this seems like the best time to make a choice if I want to stay with it or move to something else.

What does everyone think, is OpenGL still a good choice, or do I have to switch to a more modern API if I want to have the best experience in the future?

I play some Steam games on my PC that can only run on Linux through Proton-GE specifically. For a long time, I have been using it through the proton-ge-custom-bin AUR pacakge without issue. However, recently (well a couple months ago) one of the dependencies for using Proton-GE, lib32-gst-plugins-base-libs, got removed from the main repos and now only exists as an AUR package. The problem is, that for building this package, it needs a lot of make dependencies (specifically, it wants to build 58 differnet lib32 libraries just to build it) and frankly it just seems like a huge pain to do just to get Proton-GE running when I didn't need to do it before.

Does anyone know if there's an alternative/workaround to get Proton-GE running on Arch without having to build all these lib32 dependencies, or do I just have to bite the bullet and install them?

EDIT: Solved, I am just going to install it through ProtonUp-Qt

I updated my phone a bit ago, but until now I'm noticing that pressing the usual "screenshot" key combo (power button + volume down) is no longer taking a screenshot? It just lowers the volume. Did they intentionally remove this key combo or could it be a bug?

EDIT: Solved, it seems to have been a bug. Fixed itself after another restart

As we all know, in C++ you usually have separate header + implementation files, so that each translation unit can be compiled into their own object and then linked into a final program. The advantage of this is that if you change the .cpp implementation code while *leaving the header file intact* (say, you just rename a variable or something), you can just recompile the single object and link it back to everything. However, this got me thinking. *Why* are we doing this manually to begin with? Couldn't the compiler figure it out by itself?

Let's imagine header files weren't a thing for a moment, and we just had code files and a dependency chain. The compiler already parses our code and it knows what function signatures look like and what the code scoped inside them looks like. Wouldn't it be possible for a compiler to parse the code file, compare it to a previous internal "cached" version, and if it notices that all the function signatures signatures/ABI is identical, it can just "know" not to recompile other TUs/objects that depend on it? Then in the other case, if the ABI *did* change, then it would rebuild all other objects that depend on it?

One problem with that is that C++ is famous for not having a build system story figured out, but even build systems like CMake don't do something like that, they just do a "dumb" check if the code file was written to at a later point than the last rebuild. At least on paper, it wouldn't seem like something outrageously complicated to do, instead of `#include "lib.h"`, we would just declare that this code `#requires "lib.cpp" ` as an indicator that we depend on that object. Is this something that was just not thought off when the language was first designed, or are there any other reasons why this would not be a good idea?