Should we unify our efforts to make a post-mortem Sxiv? #463
Comments
|
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):
|
|
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 |
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):
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.
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 |
|
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 |
|
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 |
|
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.
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
|
|
@0ion9 has my favorite fork, hopefully sees this..
My vote is yes and
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:
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 |
|
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:
|
That just creates pointless fracture. If someone wants to find a patch, he now needs to check in two different places. |
|
One thing I think that should be done in the nsxiv repo is to create some community guidelines, such as issue/pull request templates and how to contribute. What do you guys think? For the pull request template I was thinking on something like this (really simple, just to make sure some things are stated in the description) Whatthis pr adds this functionality Backwards compatible?Yes Whybecause this is very important, as stated in this issue and this other issue as well |
|
what i was thinking was that every fork that intends to diverge after rebasing from nsxiv should open a branch to track their specific patches and fixes so if those don't ever get merged to the master branch, when someone wants to make a build of nsxiv with for example svg support they won't need to dig through the commit fest of rxiv and just checkout the nsxiv branch that i would have to mantain tracking every commit done in rxiv to improve svg support rebasing on master every some commits, i think that is one if no the sanest solution, the downside is it would inflate the branch count but i think it will keep stuff cleener in the long term than hard keeping the individual diffs on a wiki. |
Well If some wants to clone the repo it would end up having all patches, and now userscripts. |
|
Then who gets to create a branch and who doesn't? Do we just let everyone (literally everyone) create their own branch in nsxiv repo? I think that would be madness. So why should certain patches get a branch and others not? Once again, this creates pointless fracture where someone now needs to look into two different places to find a patch. On suckless anyone can upload their patch, the git repo is writeable by all. The wiki should be the same. Anything that doesn't get into mainline nsxiv should go into the wiki as user patch. And about keeping patches updated, you should be able to do that with a github gist. |
|
@eylles seems good but I would change forks for features. Now this can only be important features like svg support and webp animated images. |
|
then how do we deal with fracture, patches that improve patches, and rebasing of patch sets over master? didn't we agreed on having webp support in as a compiletime option just like gif, that way anyone who doesn't wants webp or who doesn't have imlib2 with webp can simply disable it at compile time. |
The same way it's dealt on in suckless. If someone makes an improvement to a patch they can just put that in the wiki, under the same place. See this for example. |
|
it is finnicky, we don't have to strickly follow suckless (i think sxiv was never truly suckless but rather suckless adjacent) also we can adopt some parts of flexipatch into master to facilitate adding some features at compile time, i would persinally like to hear what @bakkeby has to say about adopting a subset of flexipatch into master. |
|
I don't think it's a good idea to litter the codebase with |
|
How do we plan to determine if something is a patch or suckless enough to go to the main repo? Right now if any 3 of us agree, it goes to the nsxiv. |
|
I think instead of the forks included as branches, we could add a presets page on the wiki and link the forks along with some comments. For the patches, though, I would rather them be hosted in a structured manner. For instance, on suckless.org, all patches are included in a single repository. Instead of following individual links in a wiki, you should be able to just clone the patches repository. |
|
@TAAPArthur I see that review requirement as more a way to ensure the code is up to par. The sucklessness of a patch can be determined with individual discussions, and then the implementation can be reviewed to be merged. |
|
i decided to pull the trigger on the wiki and scripts so added the url one used on rxiv to the wiki. |
|
@XPhyro So then, we shouldn't auto merge a patch once its gets reviewed but wait for some decision to be reached in discussions? Are we going to discuss every patch then? I guess I'm looking for guidelines for what we think acceptable patches. My view is basically every patch that is either a bug fix or is small and doesn't change default behavior/introduce new mandatory build dependencies should be allowed in. It isn't a very rigorous definition, but think the idea gets across. Like if it doesn't hurt (maintenance/readability/build-ability etc) to have the patch, it should be included in the main repro. |
|
@TAAPArthur I opened those pull requests directly as non-draft as those were discussed before in this issue. For the future, I think it would be better to first open an issue, a discussion or a draft pull request for a patch. There, we can discuss it. Also, I would agree with your definition, but still think there should be some discussion to make sure everybody's on the same page. @eylles Indeed, scripts being in the wiki seems to be standard practice (mpv, lf,...). For patches, I think we can set up an auto-merging patches repository. This would satisfy both the wiki and repo functionality. |
|
speaking of scripts, i'm screwing around with a script from https://unix.stackexchange.com/questions/491834/pipe-file-containing-list-of-images-to-sxiv-and-reflect-changes-immediadly i'm trying to generalize it more #!/bin/sh
hash_dir(){
find -L "$1" -maxdepth 1 -type f -iregex '.*\(jpe?g\|bmp\|png\|gif\)$' -print0 | xargs -0 md5sum | md5sum
}
old_checksum="$(md5sum *.jpg | md5sum)"
while /bin/true; do
new_checksum="$(md5sum *.jpg | md5sum)"
if [ "$new_checksum" != "$old_checksum" ]; then
old_checksum="$new_checksum"
# find . -maxdepth 1 -name \*.jpg -print0 | xargs -0 rxiv -i -t
find "$1" -maxdepth 1 -name \*.jpg -print0 | xargs -0 rxiv -i -t
fi
sleep 1
done |
|
@explosion-mental my refreshable timeout only improves things for particularly large (filesize) images. I have a bunch of RGB scans, 10-40mb pngs. Retouching and saving such a file while it's open in sxiv used to cause 'libpng:read error' + sxiv dropped the file from filelist, about 80% of the time. Patch reduces that to about 30%. ie. definitely not a complete answer to the problem, but does improve it with no obvious downside. (smaller files just never experience the same problem, IME) I agree it needs more testing; I suspect that the size at which load errors begin occurring will be relative to disk and CPU speed. It may even be a png specific issue, or even png (compression level 9) only issue. I can only say that it's not color model, as it occurs on rgb and grayscale images. The latter are just harder to trigger (3x the pixels are needed to produce an equivalently large filesize) |
|
If you decide to have the patches on the wiki, you may want to do it like dwl: https://github.com/djpohly/dwl/wiki/Patches |
|
I feel there is a bit of jumping the gun here before we have nailed down what this project is really about. As I see it there are two camps. 1) suckless approach This involves keeping the sxiv base as it is today and only take bugfixes. As far as I am aware this only includes PR #404 to update the manpage. Bespoke features are then added as individual patches that go on top of that base. The aim of this is to stay true to muennich's legacy while making it easier to tinker with sxiv to add your own customisations. 2) evolution approach This involves taking sxiv beyond what it is today by integrating new features (most are from the various pull requests on this repository). Ultimately this will result in a different product and it will be more bloated as we would be adding more features. Based on the discussion in this thread I get the feeling that people seem to expect a combination of the two where the features we are interested in are merged in, and those that are unwanted, too invasive or unstable are left as standalone patches. This hybrid approach is an idea that is not going to work very well. The patch approach works best if the base is consistent - it is a recurring mess trying to maintain patches against a continuously moving target. Let's explore the suckless approach further. As it has already been touched on the patches would have to be stored somewhere, which leads to:
The benefit of the latter is that you do not have the former. The question to ask is how do I contribute a patch (from the perspective of someone who is not an admin)? If we have a separate patches repository then I guess I can raise a pull request or create a new issue. If the patches are stored on the wiki then I suppose that the only thing that I can do is to raise a new issue on the main project asking someone to update the wiki with this or that. I do not think the wiki is updateable by just anyone that has a github account. It may come down to that github is not the best place to host this. Another approach is that individual patches can be added as gists, with the caveat that only the creator of the gist can maintain it (I think). The same goes for people providing their patches via their own forks, this may work in the short term, but such patches are only maintained as long as the original author has interest. It is not easy for someone else to improve on a patch or upgrading it (comparing to how it currently works for suckless patches on their sites repository). It should be noted that there would be some expectation that these standalone patches are maintained, more so if only a handful of people has access to update them. As such we may end up in a situation where we have "official" patches (despite what many people call them suckless never had any official patches, only community patches). In this case we also have to consider cross-patch compatibility. Another side of this to consider is that having to patch is not particularly user friendly and as such restricts the user base. Now let's explore the evolution approach further. I believe that most of those that fork sxiv want something more out of the program than what is currently there. As @yamirui passive-aggressively stated sxiv is feature complete. I would have to agree with that. To determine whether something is feature complete you have to look at what the aim of the project is, which as stated was to be an image viewer that was perfect for muennich himself. Given that through the nine years that he maintained sxiv he got to a state where he would no longer accept new pull requests I am inclined to believe that the project met its goals and as such is feature complete. For me the product is not feature complete until it serves me coffee, but that is highly subjective and should not be an indication of the goals of the project. Provided that we are progressing with nsxiv (if that is the name we are going for) then we also need to define the goals of the new project, what it is and what it is not. Adopting parts of sxiv-flexipatch as a base for this new project is something that I would advice against. As @N-R-K stated it makes the code a lot harder to read and to maintain. Granted there are already Personally I am of the opinion that new features that change behaviour or look and feel should be configurable and/or toggleable, within reason of course. As per the topic of this thread, about unifying rather than duplicating efforts, the logical conclusion would be to create and maintain a single product that just does more than what sxiv does (i.e. evolution). The end result would be something that anyone and everyone can use, regardless of how skilled they are in the arts of C, patching, knowledge of the code base and resolving conflicts. Ultimately more people would benefit from this. Circling back to my earlier point I would say that we should do one or the other, and not try to do a hybrid of an evolution of sxiv + patches. While the suckless approach would make it easier for people to find the patches they want or need the end result is that everyone would be duplicating effort applying and trying out patches with the aim of getting their "perfect build". Taking the evolution approach to expand on sxiv beyond what it is today with the aim of providing a stable and solid image viewer that has more quality of life improvements and is more accessible for others would be my preference. Perhaps we should do a poll between a suckless, evolution or hybrid approach? |
As for the suckless vs evolution approach, I do not oppose adding new features if
As long as these criteria are met, I'm fine with having new features. |
I think this is the best approach. The suckless approach is already there, it is sxiv. But, as @N-R-K said, this should not mean that we should just throw whatever feature we can think of into nsxiv. nsxiv should be patch compatible within reason, but patching should not be the focus. |
|
Yeh i also think patching should not be the focus, the focus should be, think of it as bas sxiv distro that has all the sensible stuff and bug fixes for base sxiv code, then others can come and mantain their own sxiv distro based on nsxiv, publish the patches/patch set specific of that distro in the nsxiv wiki, so if someone wants to add fetures from somw sxiv distro but not the other they can simply add the patches to their build without having to also add all small improvements and fixes over sxiv as nsxiv already takes care of them and new bugs present on cuatom builds and distros can be more easily traced to being introduced by the patches done to the baseline of nsxiv. I think that is a reasonable thing to do in order to allow indovidual forks abd builds to exist alongside a project that keeps adding fixes and compile time optional features. |
|
For visibility reasons, imo this should be kept open. Since sxiv's basically not maintained, we don't have to worry about littering the issue tracker. @qsmodo |
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.
The text was updated successfully, but these errors were encountered: