v1cont / yad

Yet Another Dialog
GNU General Public License v3.0
657 stars 58 forks source link

Irregular icon size in list dialog #129

Closed magpie514 closed 3 years ago

magpie514 commented 3 years ago

I'm using yad (built locally from https://github.com/v1cont/yad/commit/6b2d263d4df9408e1f99b5fc1b0834dca8f48534 , although the issue started a few days ago) in Ubuntu 20.10 64b. I have a little script to have a list of template files, not unlike the create new file menus in Explorer. But a few days ago this...oddity started appearing. CopyQ uzzXtp The anomalously large icon was fine by the start of the month, and I didn't change the script for a while, so I wonder if this is some sort of regression.

Please let me know if any extra information is required.

The code used to produce this window is as follows:

#!/usr/bin/env bash

function main {
    local dest_dir="$1"
    local n=0
    [[ ! -d $dest_dir ]] && { echo "Destination path does not exist." ; exit 1; }
    [[ ! -w $dest_dir ]] && { echo "Destination path is not writable."; exit 2; }
    local templates_dir="$HOME/Documents/Templates/"
    local templates=""
    local sep=""
    for i in "$templates_dir"/*; do
        templates+="$sep$(gio info -a standard::icon "$i" | awk '/standard::icon/{print $2}' | sed 's/,//') $(basename "$i")"
        sep="\n"
    done
    local list;list=$(echo -e "$templates")
    echo "$list"
    local dest_file;dest_file="$(yad --title=Templates --window-icon=template --height=480 --width=300 --image=template\
    --text="Select template..." --center --on-top --undecorated --separator=""\
    --list --no-headers --column="1:IMG" --column="2:TXT" --search-column="2" $list 2> /dev/null)"

    [[ -z $dest_file ]] && { echo "Cancelled."; exit 3; }

    local dest_path="$dest_dir/$dest_file"

    [[ -f $dest_path ]] && {
        echo "$dest_path exists. Renaming..."
        n=1
        while [[ -f "$dest_dir/${dest_file%.*}(${n}).${dest_file##*.}" ]] ; do
            (( n++ ))
        done
        dest_path="$dest_dir/${dest_file%.*}(${n}).${dest_file##*.}"
    }

    echo "Copying template to $dest_path."
    cp "$templates_dir/$dest_file" "$dest_path"
}

main "$@"
v1cont commented 3 years ago

is this icon looks same in yad-icon-browser? and what the output of yad-tools --icon --size=16 <icon-name>?

magpie514 commented 3 years ago

Apparently no, it shows normally in the icon browser, and output of yad-tools is "$HOME/.local/share/icons/Papirus-Dark/16x16/categories/draw.io.svg", which seems normal. image

v1cont commented 3 years ago

try to add --icon-size=16 --keep-icon-size options

v1cont commented 3 years ago

and may you send me this icon by e-mail or attach it here?

magpie514 commented 3 years ago

No change with those extra options, it seems. image

Here is the icon in question: draw.io.zip

v1cont commented 3 years ago

thank you

v1cont commented 3 years ago

please check latest git

magpie514 commented 3 years ago

Strange, it's still doing it, with the extra options or without. image Building went fine and all files are proper. Looking at it closer, that icon is installed in $HOME/.local/share, since the tool is an appimage instead of a proper install. That seems to reflect in the icon name: image Could this difference be the culprit?

v1cont commented 3 years ago

yad forced to scale image only if icon specified by name. a full path to file means that image shows without changes

magpie514 commented 3 years ago

So the problem would be caused by gio giving a filename instead of an icon name? EDIT: Well, I fixed this specific instance by removing my local icon. Apparently my icon theme added an icon for this application, so now I don't need to point to the icon file anymore for that mimetype and my script just works.

I'm wondering if this was caused by some conflict between the manually added icon and the icon theme adding its own, forcing gio to be specific and changing the result in yad when it started returning a file path instead. Your last message gives credence to that theory, so I'll close this and assume the issue was more of a general system mishap.

Sorry for the misunderstanding and thank you for your time, regardless.