sxiv
sxiv copied to clipboard
muennich
Should we unify our efforts to make a post-mortem Sxiv?
Edit: The organization has been created: https://github.com/nsxiv
Sxiv is quite dead right now. Various forks are emerging and not only is it hard to pick the active ones from the cruft, we are also stupidly duplicating efforts instead of unifying them. Perhaps we should start working together, but I'm no veteran in the art of open-source so I don't know what exact steps we should take if this proves to be a reasonable suggestion.
What seems to be possible is to create an umbrella Github organization and then add members too it (Vifm being an example).
If you're think it's a good/bad idea or are interested in any manner, please chime in.
That's makes a lot of sense. As you just said, there's a lot of forks out there. We could choose a fork with some nice additions already built in to (or even muennich/sxiv if you prefer) and create this organization based on that. What do you guys think?
Here are some nice forks I know (please comment if you know any others):
- grfreire/sxiv (my fork 😉) and its also available on the aur
- eylles/rxiv
- qsmodo/sxiv
I don't object to this idea. Personally I'd be fine with having a fork that takes bug fixes instead of one that is actively developing new features. That said I don't find optional features hurtful given they done right. So long as there aren't any mandatory new dependencies and the config file is backwards compatible, I'd be content.
Do think it is worth considering starting form a clean fork and having someone who isn't the commit author look at all new commits for code quality
Do think it is worth considering starting form a clean fork and having someone who isn't the commit author look at all new commits for code quality
Agreed, a clean fork seems the best option.
i like the idea of unifiying efforts, but i wonder if this won't devolve into feature creep?
i know very rich from me when i have already merged #348 #386 (i had previously merged #392) #405 #403 #406 #437 #411 #440 #446 #453 #456 #459, a patch that provides a smarter implementation of #371 (which i have to fix so it ignores directories and doesn't segfault), some patches from https://github.com/1-7-1/sxiv-loop-patch, a wrapper script that takes care of remote files (i'm testing some changes to improve it), then i plan to refactor some code so that functions only have 1 return, then look into loading images from memory (since recent versions of imlib2 support that), then look into what is needed to implement reloading and after that i was even planning on embedding lua to config keybindings and have lua functions for some things ala mpv.
but what i see with the many forks of sxiv is that everyone who has a fork repo up has their own opinionated view of what their fork should be, i won't say that is bad as sxiv was a very opinionated project itself so it only makes sense the forks would be opinionated as well but we run into the posibility of having interest conflicts (which i expect we will have specially with the most fervent followers of the suckless philosophy as defined by suckless).
Basically we go back into the baazar and the cathedral, and the argument that open source and libre software development is like a bunch of cathedrals in a baazar, even when every cathedral prays the same message they all interpret the message differently.
i really like the intention but wonder if at this point wouldn't it be better to just rewrite sxiv from scratch...
Thanks for the ping @eylles.
I think it is just that sxiv is no longer maintained. Whether it actually needs further development is a different question.
It was @explosion-mental that suggested to treat sxiv like we do suckless tools and let users decide for themselves what extended features they would like through patches. This would still need a clean / base fork that takes bug fixes.
He challenged me to adopt a flexipatch build of sxiv where you decide which patches you want and features are added or removed during compile time via preprocessor directives. That is how I ended up with my fork:
In this case the "patches" are derived from pull requests on this repository. So far I have collated 22 of them.
While this works it is needless to say a lot more complicated to maintain due to having more than one set of code to deal with.
This approach also suffers from the same issue that all suckless projects have - that every patch is a diverging path which in turn lead to conflicts.
Personally I would prefer to see a reference build that has focus on maintenance and stability while including changes that makes sense and are stable. There are many proposed changes / pull requests that are really neat, which I believe is the very reason for this topic.
The concerns about feature creep and opinionated views as to what goes into the project and not are perfectly valid.
yeh, i have had to deal with some patches not wanting to collaborate on my fork, the fact that i decided to rebrand the program certainly doesn't helps but i did it as to say "this may and will break from what you expect of sxiv" in a similar way other projects that started as patched suckless forks got new names to symbolize their break from the expectations from vanilla.
on the camp of a reference fork/build i'd say it would have to add the most minimal changes that are either too minimal not to add or provide a feature that is a no brainer.
still achieving a consensus i feel will be the hardest part.
I totally hop in. Making a 'new' sxiv seems great, but I'm guessing there are several forks because people may want different outcomes. The most important question is, to fork or not? I couldn't make an image viewer from scratch so my option is to fork; if some here could, then I guess is worth giving a shot. We have the common ground of improving the program, so that's a good start, although it can have different interpretations.
The main point that I would keep is that it has to be a 'suckless' like tool (specially the 'adding features with patches' part). Mainly because there are already good minimal image viewers programs like feh, but only sxiv follows the suckless "standard" (config.h, some community patches, etc).
Here are some of my goals I have (some are from my sxiv fork):
- Image viewing by default. No patching should be needed to add support for webp animated or svg files (or other images format that I can't think of rn).
- Readability code? User experience? (i don't know how would I call this). I like user to tweak the source code, we get more patches that way. A good start is by having a 'good looking' config.h (I like mine)
- Integrate draw functions (drw). Wrapper for 'abstractions' or Xlibs thingys that most ppl don't know, idk but I find these nice. This has relation to the above.
Those are the most important, to me, that I can think of at the moment. I would like to know what others have in mind.
Like @qsmodo said, we should make a github org and go from there, but for that we should discuss if we want a new name for the program and, if yes, what would it be.
Anyways, I suggest we go to a matrix/jami/telegram/etc group, since this seems interesting to discuss.
I can open a matrix room, what about sxiv-dev or sxiv-post-mortem?
We can also use discourse if someone doesn't like matrix.
As a foss project i'd said it is better the avoid proprietary services like discord and partially proprietary services like telegram. (Then again we use github but that is a different matter)
i would like to mention that my fork has a couple commits that improve svg suport, and that i have been told that the svg suport has a mem leak while zooming a svg to the max upscale (which i haven't verified) and that it also breaks the fifo patch (tried to add that on a branch and it segfaults real good :D ).
On the regard of being able to pipe images into sxiv i think historically muennich was opposed to it for 2 reasons.
- it vould be achieved with a shell wrapper
- imlib2 could not load images from memory
Nowadays the second point is moot as imlib2 can load images from memory, and with some defining sxiv as a frontend to imlib2 it would make sense to support that feature.
An argument can be done that if such a wrapper script is so easy then we should provide it, which i would encourage as that is what i already do with the url wrapper for my fork as i don't like directly handling urls with libcurl inside C as that feature is served better with a reference script that then copy and modify with their preffered backend like wget if a gnu fan or sockets cuz "muh bsd is perfect".
One thing i would suggest is that we add comments to the less trivial parts of the code, decide on a coding style and add a vim modeline to every source file to enforce that coding style.
@eylles Yes please, open the room on matrix and send the link. We can change plat at any time if needed.
As for the libcurl thing, I think the viewer shouldn't support by default 'downloading images'.
It could be a patch that you can add or just download the image, view it and then remove it.
Okay i will open it and share the link, on the url handling the rxiv-url wrapper script can already do that, download the images to curl into a tmp dir, upon closing it removes the images, copy operations can be handled on the keyhandler for which i have an example on the wiki of my fork
Some of the pull requests makes perfect sense, such as scale fill, adding bar colors into Xresources, adding webp into the .desktop entry etc. But then there are svg and animated webp support which adds extra dependencies, something I'm personally not a fan of.
If the scope of the fork is to just do bugfixes and sensible maintenance then I think it's a good idea. And if extra deps are to be added, I would prefer if they can be disabled at compile time for those of us who don't want them.
@explosion-mental You mean suckless's libsl ?
Also abit off topic, but is there any info on why @muennich has stopped maintaining sxiv? I couldn't find any, hope he's doing well...
animated webp doesn't really add extra dependencies as imlib2 already supports webp just not the animations, that part iirc is implemented based on the gif code, one that we should add in order to support the animated versions of the formats supported by imlib2 is apng.
perhpas farbfeld support too cuz it is suckless?
regardless here's the matrix room https://matrix.to/#/#sxiv-dev:matrix.org
It adds libwebp as extra dep. Also, as of now atleast, I think this is a more appropriate place for discussion as it's more visible than a martix room.
i didn't noticed it adds libwebp, which if you take a look i don't mention on my fork exactly because of that, i had libwebp for something else so i guess that's why it compiles lol
@elkowar @yuri0r @Ytrewq13 @Dhruv-Vanjari @XPhyro @baskerville @quite @victor-frankenstein @adtac @escondida @Anupam-Ashish-Minz
I'm totally down to making a "new" sxiv, though I do not think the new fork or the GH organization should be named after sxiv. See this for an explanation from picom which is a compton fork.
As for the general discussion around the sucklessness: We certainly have different opinions in our own forks, but I imagine we could more-or-less unify on what this fork should include regarding general use. On the contrary, there is also the option to go full bspwm and have everything built-in, and just have an rc file to enable/disable features.
baskerville is the second largest contributor to sxiv with a whopping 7 commits...
It seems safe to conclude there is a general inclination to stick to a suckless philosophy (I also support it). Being it a general guideline, we will need to decide — and probably to vote — on a case-by-case basis which changes get accepted and which get rejected, so I think it's best not to overload this issue with premature discussions of "this should/shouldn't get in" and instead postpone this to dedicated issues in the yet-to-become organization.
- Do we have a yes for founding a Github organization? Apparently no one opposed it.
I do not think the new fork or the GH organization should be named after sxiv.
I agree. For a new name, we could go with the ungraceful but functional procedure of simply appending a "2" to the name, and name it sxiv2. I find that good enough. Or we could come up with a more becoming name. So:
- Should we use a new name for the new organization/task-force? If yes, which name would you like?
@0ion9 has my favorite fork, hopefully sees this..
Do we have a yes for founding a Github organization? Apparently no one opposed it.
My vote is yes and
Should we use a new name for the new organization/task-force? If yes, which name would you like?
sxiv2 sounds good enough, but I will suggest renaming it later (maybe?).
nsxiv -- which stands for New or Neo or Now Simple (or Small or Suckless) X Image Viewer
i would be real nice i everyone would eventually hop onto the matrix chat at a faster pace i guess https://matrix.to/#/#sxiv-dev:matrix.org
My opinions are:
- Create a GitHub organization (just named sxiv; no renaming needed, although a new name is also fine with me)
- Simply maintain sxiv, not create a new version of it. If a new version is wanted, that can be done too, but since sxiv is already very popular, it would be a good idea to simply maintain it. This would involve fixing bugs as well as accepting sensible new features (as long as they don't introduce new required dependencies. optional deps are fine as long as they can be disabled, like in #437)
- Chat on this issue should be done here, not in a Matrix room. Since this is where the development happens, this issue's comments are much more accessible than a Matrix room. In addition, these comments will stay here as long as the repository exists).
Note on names: If we are simply maintaining sxiv, then the name should not be changed to anything new. If a new fork/version of sxiv is created with the intention of being noticably different from sxiv, then that new version should be renamed.
The problem with having the same name is that makes it harder to package for distro maintainers. It also adds unnecessary confusion, especially for new users. Issues of the fork might end up here and vice versa.
@N-R-K thanks for pointing this out in chat, imlib2 depends on libwebp https://archlinux.org/packages/extra/x86_64/imlib2/ So technically needing libwebp for animated webp support isn't an additional dependency...
That's an optional dep that can be disabled at compile time. We shouldn't assume imlib2 = libwebp on all distros/environment.
Tho it seems the practice for most distros is to add webp into imlib2, arch, debian, void, as you pointed out in chat is part of the gentoo ebuild, so that marks major distros, i will check in slackware didtros and then on the bsds that do package sxiv, if every distro that alreafy packages sxiv compiles imlib2 with libwebp then it makes sense to support animated webp, tho a compile time var can be added to disable it just like with gif.
Freebsd has libwebp as a dependency for imlib2, netbsd doesn't, salix packages a version of imlib2 from before webp support was added into upstream
Random name suggestions:
- xiv - dropping the s, it's not so simple anymore
- sxv - treating it as a roman numeral and incrementing by one
- siv - if the aim would be to add native, gulp, wayland support down the line
- cxiv - community X image viewer
- ssxiv - succession sxiv (easy and familiar to pronounce)
- nsxiv - suggested earlier (new, neo, nasty, not)