Support ueberzug for image preview about joshuto

[kamiyaa]

Closed via
#113
#115

[Beethoven-n]

ueberzugpp is intended as a drop in replacement for ueberzug. it should function identically for the moment. if all else fails you can just send it a command formatted to json

[kamiyaa]

Seems like ueberzug utilizes x11 features to accomplish this.
I no longer directly use x11 and it is slowly being phased out, so I'm not too motivated on getting this feature implemented.

However, if anyone else wants to implement this without introducing dependencies on x11, feel free!

[siduck]

Oh :( , almost most cli file managers I used did support ueberzug like clifm, lf, vifm etc! ueberzug depends on X yes , But Its the only image viewing protocol or such that works for every terminal unlike w3m , sixel etc , You can even play gifs with it I think , demo

I have a script which makes ueberzug work standalone , here

[DLFW]

Hi!
My 2 cents:
I guess an image preview feature will be wanted / needed / demanded by many users and it makes total sense to get it implemented. It's just super useful. On the other hand, I understand that avoiding certain dependencies (and X likely belongs to them) is necessary to keep the project slick, clean and flexible. Unfortunately, showing images in a terminal is something very special and will be hard to realize without some kind of dependency.

But I also guess that most users from the joshuto target audience will be fans of the “do one thing and do it well” idea and won't have a problem to integrate other programs with some configuration and scripting effort.

So, just a rough idea: What about some kind of script hook when selecting a file?
As soon as we have some textual file preview implemented, we could have a feature that can call a script (on_selection) with the preview field’s starting coordinate, total height, and the number of lines of the textual preview (all in terminal character cells). That would allow that external script to use Ueberzug or another solution like icat from Kitty to show an image. When the file selection changes, another hook-script (“on_deselection”) could be called in where the user could remove the image. Only when this 2nd script terminates, the first one (on_selection) is called again with the currently selected file. (I guess the latter must also be called when joshuto terminates and when tabs change. Also geometry changes must be considered somehow.)

People could do plenty of things with a hook-solution like this and joshuto could document some snippets to easily integrate image previews into joshuto. Joshuto itself wouldn't have any additional dependency or any bloat for this very special image-preview feature.

Any opinions?

[siduck]

I dont think using only icat would be good since only kitty users would be able to use it and it'd limit all the non kitty users as well like alacritty , st etc . A file manager being terminal specific like working only for one terminal ( to show images) wouldnt be a good idea ig :/

[DLFW]

Hm, seems I expressed myself not very clearly. I was not talking about “only using icat” at all. (I'm not using Kitty myself.) I was talking about using external user-scripts to control a preview program which could be Ueberzug or icat or anything else which supports drawing an image on the terminal by getting the cell coordinates. I basically proposed to handle the image preview in separate user scripts to keep the dependencies out of joshuto and to gain flexibility for the users.

Was my text that confusing? English is not my native lang but I'm a bit surprised that it's that bad.... :|

[siduck]

@DLFW no I did understand what you said! I just got a bit upset when I heard joshuto wouldnt be getting any ueberzug support. I like ranger and it has good image support but its a bit slow! thats why I tried joshuto and its fast but yeah ueberzug needs some support :D

[kamiyaa]

I've created a new issue to track the progress and discussion on getting file previews to work. #67

Unfortunately, I won't have much time to work on this :/

[DLFW]

I have provided #113 and some documentation how to implement image previes. If somebody can also test the documented recipe, in case this gets merged, that would be great. ;)

[siduck]

@kamiyaa I tried the scripts and it didnt work for me :(

[siduck]

[siduck]

i had those 2 scripts in my joshuto config's dir and ran this wrapper https://github.com/kamiyaa/joshuto/blob/main/docs/image_previews.md#joshuto-wrapper

[DLFW]

The problem is not with the hook scripts or the wrapper, but with the basic file preview.
Your screenshot shows that there is not preview area, ergo the preview-shown hook has not been invoked.

You need to configure a preview script, for example preview_script = "~/.config/joshuto/preview.sh". It's not necessary to have this script printing anything to stdout, but it will cause Joshuto to show the preview area. That will trigger the hook script which now has some place to draw its picture on.

[siduck]

works now! thanks @DLFW

[siduck]

but memory usage of ueberzug is way tooo high

[DLFW]

Hi,
I compared the mem usage with the Joshuto wrapper and with Ranger and cannot see a difference. Ueberzug's mem usage jumps around (it's garbage collected) but behaves similar in both.

Ueberzug itself is of course out of scope here. If there is no mistake in the wrapper logic, I cannot see what we can do about that.

[siduck]

Hi, I compared the mem usage with the Joshuto wrapper and with Ranger and cannot see a difference. Ueberzug's mem usage jumps around (it's garbage collected) but behaves similar in both.

Ueberzug itself is of course out of scope here. If there is no mistake in the wrapper logic, I cannot see what we can do about that.

yea i tested it with ranger and viewing multiple images with ueberzug sequentially increments its memory size

[siduck]

https://github.com/Adit-Chauhan/Ueberzug-rs
https://pkg.go.dev/gitlab.com/diamondburned/ueberzug-go

[Beethoven-n]

so seebye/ueberzug got archived.

good news, ueberzugpp has a wayland output method that works with sway, which could mean that wlroots is supported. this might be worth testing further integration

[DLFW]

Thanks @Beethoven-n for spreading awareness! Interesting... If ueberzugpp could act as a single abstraction bin to serve all terminals and X11+Wayland, I also think that it could make sense to think about a “hard” integration for a better out-of-the-box experience for Joshuto users.

However, I had some problems to get Überzug++ running reliably and I saw you also had some confusion. If Überzug++ provides no good out-of-the-box experience, Joshuto won't either, when we integrate it.

I just have merge-requested a doc-update for using Überzug++ with Joshuto's hook scripts (#359). I would propose to first check for some time how this project develops and if we stumble across some more user opinions. Maybe some Wayland&Non-Kitty-Users are around to check what out-of-the-box-happiness they experience with Überzug++?