Name: i3lock-fancy
Homepage: https://github.com/meskarune/i3lock-fancy
http://meskarune.github.io/i3lock-fancy/
Why? As the name says, it is a fancier version of i3lock which is in the repositories. I've seen it in action and it looks awesome.
Open source: yes
Source: https://github.com/meskarune/i3lock-fancy/archive/0.2.tar.gz
Description
Description
Revisions and Commits
Revisions and Commits
| R1440 i3lock | |||
| D1645 | R1440:34a11f560d0f Switch to i3lock-color for T4589 | ||
| R3906 i3lock-fancy | |||
| D1646 | R3906:392a96daa09b Initial commit for i3lock-fancy | ||
Related Objects
Related Objects
- Mentioned In
- R1440:da75d1893f3b: Revert "Switch to i3lock-color for T4589"
- Mentioned Here
- D1645: Switch to i3lock-color for T4589
Event Timeline
Comment Actions
For those packaging this: I do not want a separate fork of i3lock in the repo. Please change our i3lock to use the i3lock-color fork that is linked in the i3lock-fancy GitHub README. Also the binary needs to change from lock to i3lock-fancy or similar, I do not accept lock as a valid binary name because it's too generic.
Comment Actions
Re-opening. @feskyde, please fix your i3lock commit and properly test it. No illegal instructions or segfaults, no memory leaking.
Comment Actions
@feskyde Thanks for working on this. I am not sure if it is safe to install from the software-center or is it already patched?
Comment Actions
The i3lock package installs the original i3lock so you will end with a broken i3lock-fancy. Do not install it yet.
Comment Actions
So I got this response from PandorasFox:
There'll be some leaks reported in Valgrind.
There's some discussion in i3#168 - this is sorta intentional. We can do some cleanup at exit, but it complicates the code and doesn't really matter that much, since the OS handles that memory anyways. There's no leaks that occur more than once (i.e. all the leaked memory is only leaked once, so it's less of a leak and more of a "not bothering to clean up memory at exit, to keep the code cleaner/easier to maintain").
i3lock-color issue: https://github.com/PandorasFox/i3lock-color/issues/70
i3lock pull request: https://github.com/i3/i3lock/pull/168
Comment Actions
Well regardless of where the issue lies, we're not switching back to i3lock-color until it or its upstream i3lock resolves the issue.
Comment Actions
Given the lack of movement on this and it being broken in our repository, this is being pulled from the repo and being marked WONTFIX.