Non-ASCII characters in absolute `Icon=` paths break desktop entry rendering (`desktopapplications`)

[DoubyCz]

Summary

When a .desktop entry uses an absolute Icon= file path containing non-ASCII characters (diacritics/accents or other scripts), Walker does not render it correctly.

This is an internationalization issue and likely affects many languages, not only Czech.

Environment

• OS: Arch Linux (Omarchy)
• Walker: 2.15.0
• Elephant: 2.20.0
• Provider: desktopapplications

Reproduction

Two minimal test cases:

1. Works:

Icon=/home/user/.local/share/applications/icons/walker_lang_ascii_nospace.png

2. Broken:

Icon=/home/user/.local/share/applications/icons/walker_lang_cz_č.png

Both files exist and are valid image files.

Confirmed behavior from UI tests

• ASCII nospace -> OK (name + icon shown)
• ASCII with spaces -> OK
• Any non-ASCII in icon path -> BROKEN (fallback/full-path-like display, missing icon)

Tested non-ASCII samples:

• German: ä, ß
• Polish: ł, ż
• French: é
• Spanish: ñ
• Turkish: ğ
• Czech: č
• Russian: я
• Japanese: あ

Expected behavior

Absolute icon file paths should load regardless of UTF-8/non-ASCII characters.

Actual behavior

If path contains non-ASCII characters, icon rendering breaks.

Suspected root cause

In walker/src/providers/mod.rs, icon handling currently does:

if !item.icon.is_ascii() {
    image.set_text(&item.icon);
    image.set_visible(true);
    is_text = true;
}

This classifies valid non-ASCII absolute paths as text icons before normal file-path icon handling.

Suggested fix

Use semantic ordering:

1. If Path::new(&item.icon).is_absolute() -> load as file image.
2. Else use themed icon name (set_icon_name).
3. Text/glyph fallback only for explicit symbol-like values.

Avoid using is_ascii() as icon type detection.