Package Details: vibrantlinux-git 1.2.2.r3.gd872dbc-1

Git Clone URL: (read-only, click to copy)
Package Base: vibrantlinux-git
Description: vibranceGUI replacement for Linux (NVIDIA only)
Upstream URL:
Keywords: digital vibrance vibrancegui vibrantLinux
Licenses: MIT
Submitter: gbr
Maintainer: gbr
Last Packager: gbr
Votes: 1
Popularity: 0.000783
First Submitted: 2019-02-06 22:37
Last Updated: 2019-11-20 06:34

Pinned Comments

gbr commented on 2019-10-20 09:13

Kind reminder: This is a git-based package, so unless the building process fails for you, there's no need to flag it out-of-date.

Latest Comments

1 2 Next › Last »

zee commented on 2020-02-22 00:32

the program is pretty solid right now so I probably won't be updating it anytime soon but I've moved all my projects to github.

zee commented on 2019-11-21 19:27

@gbr I see I'm very sorry about that, I just realized what my mistake was. I was using the canonicalPath function instead of canonicalFilePath, thank you very much for pointing this out, and finding the error yourself, this has been fixed and pushed as v1.2.4

gbr commented on 2019-11-21 17:45

@zee: I believe I found out what the problem is, I've sent a pull request on your repository, please check once you got time. Basically, the algorithm to detect if the program was already running, compares the directory path of each running process, whilst it should be comparing the executable path. That's why this error message will not show up as easily if you run Vibrant Linux from the build directory, for example. But once you move the binary to /usr/bin (where other multiple binaries are also running from), the error message pops up.

zee commented on 2019-11-20 17:05

@gbr that's strange, I'm not using the package but on my end if I follow the arch install instructions (git clone, cd, ./ then I can run it with no problem (v1.2.3). Are you sure it's up to date? That issue was there for like a second before I realized what I did wrong and fixed it. If your version is up to date and the problem persists please open an issue so I can try to sort it out, I imagine that would fit more than the package comments.

gbr commented on 2019-11-20 16:13

@zee: No worries, that's what package maintainers are for. :p However, in the last update, vibrantLinux doesn't seem to start anymore. If you try to launch if from the terminal, this error will show: Vibrant Linux is already running.

zee commented on 2019-11-20 05:44

@gbr sorry to be dropping so many changes on you but the install path now is (or at least should be) /usr/bin :)

gbr commented on 2019-11-19 16:30

@zee: Thank you for the heads up! I'll update it soon

zee commented on 2019-11-18 21:57

Just so you know I recently made changes to the repo, the 512, 256, 128, 64, 32, 16 icons are now all in the assets folder, so imagemagick should no longer be a dependency, and you don't have to resize the icon png anymore. Both icon.png, and icon512.png are the exact same.

zee commented on 2019-10-26 18:10

@gbr thank you for responding, I was wondering what the (make) thing was, should've been obvious now that I think about it. I might go ahead and shrink the image in that case to 512x512 for the next update I push, I didn't know there was a max, and I didn't even think about the icon dimensions. Also yeah you're right about the xcb libs, I didn't even consider that.

gbr commented on 2019-10-26 02:24

@zee: imagemagick is only a "make dependency", i.e., only used in the build process. The reason I'm using it though, is to downsize vibrantLinux's logo, because the dimensions of it (1024x1024) exceed the maximum icon resolution of the standard hicolor theme (512x512). Though I should probably generate 32x32, 64x64 and 128x128 icons as well, just in case...

Regarding libxcb and xcb-util-wm, adding them is a bit redundant, since xcb-util-wm is dependent of libxcb, which is dependent of qt5-base. But adding xcb-util-wm won't hurt, I guess. Anyway, thanks for developing vibrantLinux! :)