Raise max prop len

[sgraf812]

256000 bytes was not enough to store 512x512 icons onwards.
The current setting allows up to 2048x2048 icons and should be quite future proof.

[sagb]

This limit is for icons in _NET_WM_ICON property.
They are parsed, transformed to Pixmap format, copied and resized on-the-fly, right after user press alt-tab and waits for something to appear on the screen.
Are you sure we should allow this data be 32 MB per window?

[sgraf812]

Well, it's not like the 16MB will need to be initialised, at least I don't think that's what XGetWindowProperty does. So we aren't really paying for it at this point. Rather the current behavior opens up room for surprising behavior, where icons are present but weren't loaded.

So I think the right thing would be to make the buffer as big as the data needs it to be.

The actual question here is whether icons of size 512x512 are supported or not. Spotify and VSCode are just two applications that sadly don't provide supersampled versions of their icons. Since I use both, I'd very much like them to show up properly.

I just spun up 10 instances of VSCode (which has 1024x1024 = 4MB icons) and the delay is noticable (a few hundred ms). We could work around that with some amount of caching, I guess, but I probably won't be the one to implement it, so...

[sagb]

I've installed spotify and vscode. Indeed, they have 512x and 1024x icons in _NET_WM_ICON property.
There are also badly named file icons. The following makes them recognized by alttab:

ln /usr/share/spotify/icons/spotify-linux-32.png /usr/share/icons/hicolor/32x32/apps/spotify.png
mkdir -p /usr/share/icons/hicolor/1024x1024/apps && ln /usr/share/pixmaps/com.visualstudio.code.png /usr/share/icons/hicolor/1024x1024/apps/code.png