Package Details: hyprland-git 0.46.0.r115.ga6b26371-1

Git Clone URL: https://aur.archlinux.org/hyprland-git.git (read-only, click to copy)
Package Base: hyprland-git
Description: Hyprland is an independent, highly customizable, dynamic tiling Wayland compositor that doesn't sacrifice on its looks
Upstream URL: https://github.com/hyprwm/Hyprland
Licenses: BSD-3-Clause, BSD-2-Clause
Conflicts: hyprland
Provides: hyprland, wayland-compositor
Submitter: hertog
Maintainer: Vaxry (zjeffer, alba4k)
Last Packager: alba4k
Votes: 94
Popularity: 1.58
First Submitted: 2022-04-12 20:26 (UTC)
Last Updated: 2025-01-15 20:42 (UTC)

Dependencies (55)

Required by (64)

Sources (2)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 39 Next › Last »

alba4k commented on 2024-12-27 20:32 (UTC)

When I added it, I asked vaxry if it was better to add it as dep or as optdep. He said it should be a dep. Likely because of some stuff he wants to do with it in the future, but I really don't know. I'm trusting him on this one.

As for hyprland-meta-git, no not really. qtutils, unlike other hypr* projects, isn't meant to exist as standalone but is rather supposed to be a collection of stuff that hyprland uses. I guess this is also why it's called hyprland-qtutils and not hyprqtutils (this is just speculation on my end, tho).

<deleted-account> commented on 2024-12-27 19:49 (UTC)

If hyprland-qtutils is about to be removed as a mandatory dep - I think it should be added to hyprland-meta-git, in this case.

Fazzi commented on 2024-12-27 19:17 (UTC)

this package should not depend on hyprland-qtutils-git. It should be an opetdepend at the most.

<deleted-account> commented on 2024-12-27 17:41 (UTC)

I welcome the possibility, though.

alba4k commented on 2024-12-27 17:40 (UTC)

not just dependency-wise, you could argue ahah

<deleted-account> commented on 2024-12-27 16:35 (UTC)

Dependency-wise, hyprland is slowly turning into a DE.

Apologies for the offtopic.

<deleted-account> commented on 2024-12-22 14:05 (UTC)

Although, after some extra reading, I guess I'll return to O2.

<deleted-account> commented on 2024-12-22 13:50 (UTC)

I paid for 8 cores - I'm gonna use 8 cores.

O3 works well, so far. If there are any problems - I'll switch back to O2.

alba4k commented on 2024-12-22 13:47 (UTC) (edited on 2024-12-22 13:47 (UTC) by alba4k)

I don't think using all threads is necessarily a good idea, especially since you ofen run aur updates in the background. I use j14 on my 16 theads

alo, O2 is often recommended instead of O3

<deleted-account> commented on 2024-12-22 11:48 (UTC)

@xiota thanks for the tip! It looks like cmake uses just 2 cores, by default. Setting --jobs=$(nproc) and optimization flags to -O3 does quite a magic.