Thanks for the patch, but as you already explained, I won’t merge it for the reasons you listed.

[Original comment by pabloa@…]

How should I apply this patch? I did git clone git://code.i3wm.org/i3 and then cd i3; git apply 0001-Added-support-for-window-icons-_NET_WM_ICON-property.patch. After some warnings ("trailing whitespace", "space before tab in indent") the following lines appeared:

error: patch failed: src/render.c:199
error: src/render.c: patch does not apply

Am I doing something wrong? Is the patch for a newer/older version? Thanks.

[Original comment by anonymous]

Probably the patch is too old and doesn't apply cleanly any more. I've attached the patch that I currently use on top the next branch from git.

[Original comment by pabloa@…]

$ git branch 
  master
* next
$ git pull origin next
From git://code.i3wm.org/i3
 * branch            next       -> FETCH_HEAD
Already up-to-date.
$ git apply 0001-Added-support-for-window-icons-_NET_WM_ICON-property.2.patch
0001-Added-support-for-window-icons-_NET_WM_ICON-property.2.patch:103: trailing whitespace.
#ifdef USE_ICONS                              
0001-Added-support-for-window-icons-_NET_WM_ICON-property.2.patch:202: space before tab in indent.
        DLOG("_NET_WM_ICON is not set\n");
0001-Added-support-for-window-icons-_NET_WM_ICON-property.2.patch:213: space before tab in indent.
        /* Check that the property is as long as it should be (in bytes),
0001-Added-support-for-window-icons-_NET_WM_ICON-property.2.patch:216: space before tab in indent.
        const uint64_t crt_len = prop_value[0] * (uint64_t) prop_value[1];
0001-Added-support-for-window-icons-_NET_WM_ICON-property.2.patch:217: space before tab in indent.
        const uint64_t expected_len = (crt_len + 2) * 4;
error: common.mk: No such file or directory
error: include/atoms.xmacro: No such file or directory
error: include/window.h: No such file or directory
error: src/manage.c: No such file or directory
error: src/tree.c: No such file or directory
error: src/window.c: No such file or directory

Uhm :/

[Original comment by pabloa@…]

Sorry, my bad. The working directory was in a strange state. Now it applied cleanly; just a couple of warnings.

[Original comment by pabloa@…]

It works as expected. Thank you :)

It will be a pain to keep this updated though.

[Original comment by anonymous]

The patch fails to apply again.

Can you please refresh it?

It might be a good idea to also publish your Git repo/branch, so that it could get used as a remote for Git.

Thanks!

[Original comment by mariusmuja@…]

I published my branch on github: https://github.com/mariusmuja/i3wm

[Original comment by hasufell@…]

Not sure if I understand the reasons. The additional code is not really much and there are obviously people who would want to help with maintaining those pieces.

If you want simple decorative borders, then just use them and set USE_ICONS default to off in the Makefile.

(posting this after 5+ tries of captchas... horrible)

[Original comment by bl.nero@…]

Sorry for reviving an old thread, but I think that you should seriously reconsider your policy here. Keep in mind that some applications don't put their name in front of the window title. For example, Chrome would put the current web page title in front, and that makes it very inconvenient to find in the tabbed layout mode - especially that the padding inside the tabs are minimal, and the window titles melt into an incomprehensible blob of characters.

I completely understand and support the minimalism principle. However, I think that the minimalism should serve the user. The "nothing fancy" rule means that you shouldn't support 3D effects, drop shadows, and anything else that is eye candy, but not functional. However, this feature request is purely functional. It's not about eye candy, it's about usability.

So, here's my 2c (or a bit more).

Disclaimer: I started using i3 yesterday, so YMMV. And, BTW, i3 is by far the best WM I've ever tried. :)

After x+1 years on i3 now, I'm also realizing an icon indicator would help usability. It'd be all right to even manually apply a patch if someone would come up with something for 4.10.x. @mariusmuja did you abandon your work on this?

@lkraav The patch is available here. I don't know if it still applies, but it's not that big so it shouldn't be too hard to rebase it to the current master.

:) tyvm sir, works great.

ashinkarov/i3-extras#20 rebased patch posted

Hello dear upstream. While window icons was not accepted to core, perhaps I could request some insight into what has changed in i3-4.12 API, so that ashinkarov/i3-extras#32 patch doesn't easily build anymore even after a relatively sane rebase run? Could someone here take a look?

I think the discussion in the issue you referenced captures the issue pretty well.

Such a shame this wont get included in core. I really do see it as a usability improvement and not an eye candy request. Just adding my +1 anyway as I'd really love to see a merge of this reconsidered?

Has thought been given to this?

Is there any issue with having it an an option (default to disabled) in the config file?

People using i3 on their distros of choice would have to become proficient at packaging if they want this patch and the latest updates mainline.

https://faq.i3wm.org/question/778/why-is-patch-not-merged-and-made-optional/

I've been using the patch for a while, and after experiencing some of its complexities, I fully understand and support the reasoning behind the decision.

The main issue I had was that some applications don't actually set a _NET_WM_ICON. By studying how other window managers handle this situation I came up with a config and script that would inspect the .desktop files, extract the launcher icon path and then use xseticon to set the icon to the window! But even this did not work in all instances.

I've actually given up with this now and have settled on adding the window class and/or instance to the title like so:

for_window [class=".*"] title_format "[<b>%class</b>/<small>%instance</small>] %title"

I also came across others taking it further by using FontAwesome icons based on window class. You'll obviously have to define the class to icon relations yourself, but all this can be done through config without patches.

For the interested people, I currently maintain a window icons patch here:
https://github.com/mickael9/i3-window-icons

@mickael9 do you have any instrucitons about how to build and install https://github.com/mickael9/i3-window-icons ?

I know this is closed, but for anyone looking for an option to get some window icons without patching i3, have a look at this:
https://gist.github.com/dmelliot/437924ff581f3f1edd59f44833be6cc6

It's a bit hacky, but looks ok:

For anyone still looking out of this. I've made a little update on the original patch and it seems to be working good on last version i3 version 4.19.2-2-g46bc8411+.

Patch: http://sprunge.us/psfAjM

How to build and install:

• git clone https://github.com/i3/i3.git ~/i3 && cd ~/i3
• git switch stable
• patch -p1 < $(wget http://sprunge.us/psfAjM && echo "psfAjM")
• mkdir build && cd build
• meson .. <- this could highlight required dependencies that need to be installed
• ninja to build the project
• ninja install to install the binaries etc. (defaults to /usr/local)

(That patch won't work on big endian systems, but I doubt anyone will run into this. Just wanted to mention that cairo expects uint32_t to be used, i.e. native endian, but this line hardcodes little endian: win->icon[i] = (a << 24) | (r << 16) | (g << 8) | b;)

I think it might be time to reconsider supporting window icons.

Since we last thought about it in 2012 (almost 10 years ago!), window decorations have evolved considerably. For example, the appearance can be changed using https://i3wm.org/docs/userguide.html#pango_markup, possibly in combination with emojis.

Further, favicons in browsers work well to more quickly locate browser tabs, making an intuitive case in favor of showing window icons in i3, too.

Further points in favor of the feature:

1. User feedback (e.g. emoji reactions in this issue)
2. The willingness of contributors to support the icon patch over a long time
3. The small size of the patch

Personally, I’m tentatively in favor of merging, provided @Airblader and @orestisfl don’t have strong feelings against merging.

@browser-bug Would you be willing to submit the patch as a pull request and work with us to get it merged? At the very least, we’d need to add a config option that defaults to not showing icons so as to not change the default behavior.

Thanks,

No objections from my side. Another thing people will really be happy about.

@stapelberg I'm happy to hear the merging intent since it's a feature that I personally think will be more than welcomed by the community. Concerning my contribution, I've only changed one internal function (two lines) inside the original iconpatch that caused a little misalignment with respect to the new internal API. The true author I suppose to be @Irustand (who I can't find on GH). I have no problem submitting a pull request with the iconpatch changes but I honestly don't know if I'm competent enough to be working on further contributions to the matter.

@browser-bug Thanks for clarifying! I can pick this up if nobody races me to it within the next few days.

@stapelberg great! I would follow the topic with interest even as an outsider anyway, so ping me whenever you start working on it :D

@psychon concerning the LH/BH issue, I would propose something along the following lines:

const uint32_t i = 0x01;
#define IS_BIGENDIAN() ((*(char *)&i) == 0)

void window_update_icon(i3Window *win, xcb_get_property_reply_t *prop) {
[...]

        uint32_t data_le = (a << 24) | (r << 16) | (g << 8) | b;

        if (IS_BIGENDIAN()) {
            win->icon[i] = __builtin_bswap32(data_le);
        } else {
            win->icon[i] = data_le;
        }
}

Or as an alternative, this could be rewritten leveraging ntohl()/htonl() which if I understood correctly they should be a NOP for LH/BH systems but I've no knowledge on the subject.

Currently the iconpatch uses the CAIRO_FORMAT_ARGB32 for the image surface where

each pixel is a 32-bit quantity, with alpha in the upper 8 bits, then red, then green, then blue. The 32-bit quantities are stored native-endian. Pre-multiplied alpha is used. (That is, 50% transparent red is 0x80800000, not 0x80ff0000.)

I would propose something along the following lines:

Thanks! After re-reading... uhm... I think my original comment was wrong and this might actually already work fine on big endian systems. Sorry!

I believe the original patch author is @mariusmuja as seen in this PR description and here: ashinkarov/i3-extras@21b6cde with some other contributors: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=i3-wm-iconpatch