Should we unify our efforts to make a post-mortem Sxiv?

[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.

[GRFreire]

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

[TAAPArthur]

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

[qsmodo]

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.

[eylles]

@explosion-mental

[eylles]

@bakkeby

[eylles]

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...

[bakkeby]

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:

• bakkeby/sxiv-flexipatch

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.

[eylles]

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.

[explosion-mental]

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.

[eylles]

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.

1. it vould be achieved with a shell wrapper
2. 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.

[explosion-mental]

@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.

[eylles]

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

[N-R-K]

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...

[eylles]

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

[N-R-K]

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.