Workflow

[eylles]

I had thought that perhaps keeping this repo attached to seebye's was good for the moment as it would allow everyone who already had a fork to just checkout 31463ec8152057d0b7d33517745ef2da2f239fc1 add this repo as the new upstream remote pull and rebase their commits over the new master, but it seems that detaching now today may be more convenient, i would like to hear everyone's feedback if you think it is better to detach now or follow the workflow i propose and detach later?

[jstkdng]

tbh detaching from seebye's repo is the best as ppl will always see commits behind the main repo and wonder why that is. A lot of future issues/questions could be avoided that way.

[N-R-K]

One more thing to keep in mind is that forked repos have lower score on search results, so people may not be able to find this repo via search if it keeps attached as a fork.

[eylles]

I know, that is why the intention was to detach after everyone had opened their PRs but seems the kind of workflow i thought of ain't convenient

[gokberkgunes]

Keeping the repository as the fork of the main project brings discoverability through Github's forks and network map. However, as you all stated there are severe disadvantages keeping the repository in such state.

At this point to cover the lost advantage, we may direct people to current repository on our personal forks. I contribute to this by adding a note on ueberzug-tabbed fork.

[jstkdng]

if we want this project to succeed then we'll have to promote it to other projects that use ueberzug. Only one that comes to mind is ranger.

[N-R-K]

Before jumping the gun, I think it's important to establish what the project's scope is.

Is it just going to be maintenance fork (only bug-fixes) or will there be active development (new features etc). And if it's going to be an active development, then there should be some criteria laid out on what type of features to add or not, how much backwards-compatibility is valued etc.

And the reason why I think setting a clear project scope is important is because of past experience with nsxiv - which was born out of a similar situation - the author of sxiv stopped maintaining it but the community wanted to continue it's development.

Unfortunately we didn't set a clear project scope at the beginning of the project so people had different ideas on where to go - some wanted to maintain backwards compatibility, some wanted to make drastic changes - which resulted in lots of unnecessary friction and conflict.

So I think it'd be a good idea to make it clear what the scope of this project is before going further.

[jstkdng]

I personally would like to add some needed features like more image support, wayland support, faster image loading and low memory usage.

[eylles]

First i think ueberzug should be what it was intended to be, a replacememt to w3m-img until we are already sixel capable in the terminal space.

https://www.arewesixelyet.com/

For that matter i don't see ueberzug really evolving or gaining more features than it already has, as all the work really needed now falls on the stretch of fixing design problems, usecase issues and optimize things about ueberzug.

On that note things like "more image format support" may ormay not fall within ueberzug itself but perhaps on the underliying libraries it uses.

"lower memory usage" is tricky, as again is the hog ueberzug, the application using it or the libs that ueberzug uses?.

"faster image loading" is an optimization thing, and could fall with either ueberzug or the program using it, for example vifm-img and lf-img (both use ueberzug) don't cache the images so large images are slow to load, thus we would have to do tests to see whois at fault.

"wayland support" i would deem impossible on the ueberzug side, as the way ueberzug works is an x11 capability to embedd windows into others not present in wayland, so that capability should be added to the program using ueberzug to not just use ueberzug but use the correct backend and or preview method for the environment (i'm working on a local prototype to merge vifm-img and my vifm-sixel along other backends and fallbacks, but goes slowly)

Other than that necessary work for correct working under x11 with many terminal emulators falls in the bug fixing cathegory, at least that is how i see things about ueberzug, not much space to develop but quite the room to polish and tune what is there.

[jstkdng]

I'm at least tackling the first 3 things in a small project of my own, ueberzugpp.

I started doing this because ueberzug's code logic is quite complex and adding features would be really hard + python is slow.

But yeah, sixel should be the way to go, and have x11 window embedding as a fallback on terminals that don't support sixel.

[eylles]

well, i did reconsider the idea of adding sixel support, for the next next release i will look into it, for the time being i want to update and merge this patch before cutting a release.

[jstkdng]

The libsixel bindings are quite old so that could be a problem. If you decide to use libsixel from a c extension you can use my implementation as a reference.

[eylles]

tbh for a moment i considered a more brute approach using imagemagick/graphicsmagick.

but again that will be for the next release after the impending one, the last priority for the first release under our maintenance (18.2.0) would be the patch to support multi-process terminals, unless there's something else that u think is necessary enough for this release that the ueberzug as packaged by most distros does desperately lack.

[jstkdng]

I think that patch can be replaced by this instead, as both try to do the same thing. https://github.com/seebye/ueberzug/commit/6aafc5e2d12d23996e4c20f7f45ef12ce784c087

Apart from testing the patch, it should be enough for a new release.

tbh for a moment i considered a more brute approach using imagemagick/graphicsmagick.

lmao, that is indeed a solution, not the cleanest one in my opinion.