search

ueber-devel / ueberzug

Continuation of ueberzug
GNU General Public License v3.0
102 stars 6 forks source link

In some cases, the sub-cell position is wrong #24

Open randomcoder67 opened 2 weeks ago

randomcoder67 commented 2 weeks ago

In some cases ueberzug won't position an image correctly along the cell boundaries of the terminal.

I have encountered this in terminals which have a menu bar at the top (for example xfce4-terminal), and also in Alacritty when dynamic padding is not enabled.

Dynamic padding in Alacritty "spreads out" the padding, instead of only adding padding at the bottom and right

Alacritty with dynamic padding:

right

Alacritty without dynamic padding:

wrongg

Without dynamic padding, the top of the image is not aligned exactly with the cell boundary

eylles commented 2 weeks ago

yeh, vte terminals have presented problems to ueberzug since seebye was still actively developing it.

with alacritty and very likely vte terminals it may be the way that their size is reported to ueberzug, which happens in function get_size of the TerminalInfo class: https://github.com/ueber-devel/ueberzug/blob/e92e5f6576035469f32572df3a08898b29afc265/ueberzug/terminal.py#L10-L21

this is completely dependant on werether or not the padding is part of the window size reported as the x and y pixels, for this there isn't really much we can do as we got no way i'm aware of calculating how much padding the terminal is using on every direction, unless another control sequence is added specifically for the size of all the elements composing the terminal window, terminal emulators should limit themselves to only report the pixel size of their actual cell drawable area with TIOCGWINSZ to calculate the correct cell size.

i can't even label this a "won't fix" since i don't even think it could be fixed properly without modifiying the control sequence standar and then forcing every terminal emulator to comply by the book to this new standar.

it may be possible to cobble a hack for vte terminals and alacritty without dynamic padding but can't promise anything for the near future.

randomcoder67 commented 2 weeks ago

yeh, vte terminals have presented problems to ueberzug since seebye was still actively developing it.

with alacritty and very likely vte terminals it may be the way that their size is reported to ueberzug, which happens in function get_size of the TerminalInfo class:

https://github.com/ueber-devel/ueberzug/blob/e92e5f6576035469f32572df3a08898b29afc265/ueberzug/terminal.py#L10-L21

this is completely dependant on werether or not the padding is part of the window size reported as the x and y pixels, for this there isn't really much we can do as we got no way i'm aware of calculating how much padding the terminal is using on every direction, unless another control sequence is added specifically for the size of all the elements composing the terminal window, terminal emulators should limit themselves to only report the pixel size of their actual cell drawable area with TIOCGWINSZ to calculate the correct cell size.

i can't even label this a "won't fix" since i don't even think it could be fixed properly without modifiying the control sequence standar and then forcing every terminal emulator to comply by the book to this new standar.

it may be possible to cobble a hack for vte terminals and alacritty without dynamic padding but can't promise anything for the near future.

Would it be easier to code a way for users to specify an offset manually (in pixels)?