picom icon indicating copy to clipboard operation
picom copied to clipboard

Suggestion: Provide icon for picom

Open itaranto opened this issue 2 years ago • 9 comments

This is a minor OCD kind of bug, but anyway:

picom.desktop has Icon=picom but there's no picom.png nor picom.svg, instead we have compton.png and compton.svg.

A possible solution could be just to use Icon=compton in picom.desktop. This will require updating meson.build too since those icons are only copied if the compton option is enabled.

The alternative is to create (copy) compton's icons and name them "picom" instead.

Thanks.

itaranto avatar Jan 02 '23 20:01 itaranto

personally, i don't get the point of having an icon for a compositor since it doesn't have a gui, it's more a terminal thing.

absolutelynothelix avatar Jan 02 '23 20:01 absolutelynothelix

personally, i don't get the point of having an icon for a compositor

I was thinking about that too, compton.desktop has the NoDisplay=true property which makes it not to show up in launchers but picom.desktop has NoDisplay=false which makes no sense. Why you would launch picom from a graphical launcher anyway?

since it doesn't have a gui, it's more a terminal thing.

It's a daemon, not a CLI app, but yes, I get what you are saying.

itaranto avatar Jan 02 '23 21:01 itaranto

Both .desktop files used to be NoDisplay=true (see https://github.com/yshui/picom/pull/568). Apparently, another user requested a change and provided their reasoning for a menu entry in https://github.com/yshui/picom/pull/598. Although the referenced icon picom is not shipped (and does not exist...) as mentioned by @itaranto above.

Edit: I don't see a valid reason to create a menu entry for picom that should be shipped by default. Picom runs in the background and has no graphical runtime-interface. (Apart from obviously rendering your whole screen :laughing: ) Users are free to copy the .desktop file to ~/.local/share/applications/ and make appropriate changes there if they so desire to have some kind of graphical starter for picom. You'd have to provide your own way of killing picom later on anyway.

tryone144 avatar Jan 02 '23 22:01 tryone144

@tryone144, maybe we should get rid of the .desktop file then? we could add an example of it in the wiki if user really wants one.

absolutelynothelix avatar Jan 02 '23 22:01 absolutelynothelix

I haven't tested it, but they should be useful for easy/easier autostart configuration (see https://github.com/yshui/picom/commit/5d6326ae2892718a0d3680f9503364d00dc5859c). IIRC xfce can add those .desktop files directly to its autostart config (enable/disable).

tryone144 avatar Jan 02 '23 22:01 tryone144

@tryone144, ah, ok. then it's better to fix them and note somehow that their primary use is to simplify autostart and if user wants a launcher entry or something he could use the .desktop file as an example and modify it himself.

absolutelynothelix avatar Jan 02 '23 22:01 absolutelynothelix

If you ask me, I would set both to NoDisplay=true and remove the icons since the are useless.

But If you guys wanna keep the icons, at least picom.desktop should have a valid/existent icon.

itaranto avatar Jan 02 '23 22:01 itaranto

If you ask me, I would set both to NoDisplay=true and remove the icons since the are useless.

i support this. maybe also revisit the file and see what other properties we could add/remove/change to improve it.

p.s. you can dig into this and do a pull request if you want.

absolutelynothelix avatar Jan 02 '23 22:01 absolutelynothelix

I guess the solution to this would be either remove the icon reference or a designer contributing a svg. To me it's not just about an app icon, that as someone else said doesn't makes much sense for a command line application, but more as a logo to represent the project.

redtide avatar Jun 12 '23 08:06 redtide