Hmm, that looks more like a mail application ;=)
As Tyson is already working on something, but at the moment has not much time, I would tend to just keep Kate's icon as is and look at the final stuff Tyson provides first.
Otherwise I think that is a bit unfair.

That's not a bad icon, but again, I think we owe it to the app developers to be as true to the original icon as possible. That text-origami-bird icon is cool, but it has nothing to do with Kate's original icon. The HIG specifically recommends against this:

https://hig.kde.org/style/icons/application.html
When creating a Breeze theme version of an existing app’s icon, is critically important that the icon’s existing brand and visual style be preserved. The goal is to create a Breeze version of the icon, not something completely new and different.

For example, here's Okular's original icon:

Here's the Deepin icon theme version of it, as @filipf pointed out up-thread:

IMO this version of the icon is both much better than the Breeze icon version, and also more true to the original. That's the kind of thing we should strive for with Breeze icons. If we want to make a totally new icon, it needs to be done in coordination with the app's developers and have their approval, and then it needs to formally replace the old Oxygen-style icon, not merely be a Breeze icon theme version of it.

I don't think glasses will ever look good at small sizes, can't we use something else for Okular? A clip? A highlighter?

In T10243#201370, @alex-l wrote:

I don't think glasses will ever look good at small sizes, can't we use something else for Okular? A clip? A highlighter?

Looks okay to me at 32px:

But again, if we want to actually change the icon rather than creating a Breeze version of it, that requires the consultation and permission of the developers (i.e. Okular people).

In T10243#201333, @ngraham wrote:

In T10243#201329, @alex-l wrote:

EDIT: I have already said this here and there but please don't run any automated script to SVG icons, because when opening them back in Inkscape they are corrupted and everytime I edit a Breeze icon I have to do additional work to fix shapes and gradients corrupted by the scripts.

This is something you should bring up in the VDG chatroom and discuss with @ndavis in particular as we currently make heavy use of these scripts for optimization purposes. Hopefully we can come up with a solution together.

I actually hand check for errors when I optimize. If the gradients are out of place, then I put them back into place, optimize again and check again. Usually, the gradients get messed up when they're missing some data that is supposed to be in there and they get optimized with SVG Cleaner. If you ever see Warning: The 'stop' element must have an 'offset' attribute. Fallback to 'offset=0'., you need to check the gradients.

There are a fair amount of icons with gradient handles that are lined up right, but are way off to the side. Those were there before I started working on breeze-icons and I fix them as I go.

In T10243#201379, @ndavis wrote:

In T10243#201333, @ngraham wrote:

In T10243#201329, @alex-l wrote:

EDIT: I have already said this here and there but please don't run any automated script to SVG icons, because when opening them back in Inkscape they are corrupted and everytime I edit a Breeze icon I have to do additional work to fix shapes and gradients corrupted by the scripts.

This is something you should bring up in the VDG chatroom and discuss with @ndavis in particular as we currently make heavy use of these scripts for optimization purposes. Hopefully we can come up with a solution together.

I actually hand check for errors when I optimize. If the gradients are out of place, then I put them back into place, optimize again and check again. Usually, the gradients get messed up when they're missing some data that is supposed to be in there and they get optimized with SVG Cleaner. If you ever see Warning: The 'stop' element must have an 'offset' attribute. Fallback to 'offset=0'., you need to check the gradients.

There are a fair amount of icons with gradient handles that are lined up right, but are way off to the side. Those were there before I started working on breeze-icons and I fix them as I go.

Most common problems for me are: (1) path that is correctly displayed but can't be edited with Inkscape, just moved around and (2) gradient correctly displayed but Inkscape's UI says the filling is "?" instead of gradient. You can check (2) with current 48x48 icon for Konsole/terminal, the shape is the ">" symbol.

Personally, I prefer branding icons much over functionality. It would be horrible if all my browsers and code editors would have the same icon. I want to know when I look in my task bar, what apps exactly I have open. Furthermore, it's always been like that ... no app on my phone or somewhere else uses a generic icon ... for good reason, I search for an app by looking at the icon and not at the text (in fact, some icons don't even have text like the icon in the bottom "favourite bar" on iOS).
Imho, a good branding icon gives some hint about the functionality as well, but it doesn't have to. And well the branding icon is designed by the application, not by breeze.

In T10243#201445, @alex-l wrote:

Most common problems for me are: (1) path that is correctly displayed but can't be edited with Inkscape, just moved around

Are you talking about some of the mimetype icons? Some of them define shapes, give them an ID and then reference the ID so the part can be reused. No SVG optimizer that I know of does that and they were like that before I started working on Breeze. I fix that as I go, but it requires manual edits to the code. I rarely touch mimetype icons and I've only seen it a few times, so I don't know how many are like that.

(2) gradient correctly displayed but Inkscape's UI says the filling is "?" instead of gradient. You can check (2) with current 48x48 icon for Konsole/terminal, the shape is the ">" symbol.

For me, the gradient is shown correctly in Inkscape's UI, but the gradient can't be changed to another gradient. I have to click the unset button (question mark icon), then click on the gradient button and it's back to working like it should without any extra work. For some reason, Inkscape can't change gradients unless the element is using a gradient that references another gradient.

In T10243#201461, @ndavis wrote:

Are you talking about some of the mimetype icons?

Also mimetype icons are definetly affected.

In T10243#201329, @alex-l wrote:

EDIT: I have already said this here and there but please don't run any automated script to SVG icons, because when opening them back in Inkscape they are corrupted and everytime I edit a Breeze icon I have to do additional work to fix shapes and gradients corrupted by the scripts.

Samples please, it would be nice to fix inkscape and/or scripts.
Also, we could store original/inkscape-friendly svg files in repo and run optimization script as part of install process.

The diagonal thing in Konsole icon is to add some identity, without it we would have a classic terminal icon.

Why "different"/non-classic icon is better than classic terminal icon? Classic one is already known and everyone will be able to find it in their menu.

Any ideas on how to add identity in general?

Basic/core applications (i.e. KWrite, Konsole, Dolphin, etc) come with the system "by default" and users need to find them easily without knowing how an app icon looks like in specific desktop environment. I guess people see them as "built-in" functions, not as stand-alone applications.

In T10243#201334, @ngraham wrote:

In T10243#201332, @alex-l wrote:

@ngraham I don't know about macOS, but ElementaryOS icons look so good because they are designed for each size and I don't think we have the manpower to do that to Breeze icons.

But we already do this. Despite the fact that we use arbitrarily scalable SVG icons, we generally provide several sizes for each one so they look pixel-perfect at the common sizes that they're intended to be viewed at.

We already explicitly suggest to make 48px application icons only (only few have more sizes). Titlebar and taskbar use ~22px icons, so you can either get bad looking small icons, or give up with nice details on 48px ones.

In T10243#202038, @mglb wrote:

We already explicitly suggest to make 48px application icons only (only few have more sizes). Titlebar and taskbar use ~22px icons, so you can either get bad looking small icons, or give up with nice details on 48px ones.

Potentially bad-looking small app icons is an acceptable price to pay IMO.

In T10243#202038, @mglb wrote:

In T10243#201329, @alex-l wrote:

EDIT: I have already said this here and there but please don't run any automated script to SVG icons, because when opening them back in Inkscape they are corrupted and everytime I edit a Breeze icon I have to do additional work to fix shapes and gradients corrupted by the scripts.

Samples please, it would be nice to fix inkscape and/or scripts.
Also, we could store original/inkscape-friendly svg files in repo and run optimization script as part of install process.

The diagonal thing in Konsole icon is to add some identity, without it we would have a classic terminal icon.

Why "different"/non-classic icon is better than classic terminal icon? Classic one is already known and everyone will be able to find it in their menu.

Any ideas on how to add identity in general?

Basic/core applications (i.e. KWrite, Konsole, Dolphin, etc) come with the system "by default" and users need to find them easily without knowing how an app icon looks like in specific desktop environment. I guess people see them as "built-in" functions, not as stand-alone applications.

As I said in another comment an example of problem in Inkscape is ">" symbol in Konsole 48x48px icon. Btw those scripts are just to save package's size, there is no point to run them after installation, also because SVG icons are rendered once and then stored in the cache, so there is any advantage in making them optimized but reducing loading time for the first time the icon is shown.

If KDE wants their apps to have an identity, and this is what someone expressed in this thread, we can't ship just generic icon. In fact I see Konsole used without Plasma in /r/unixporn posts on Reddit.

In T10243#202901, @alex-l wrote:

As I said in another comment an example of problem in Inkscape is ">" symbol in Konsole 48x48px icon.

Works OK here (Inkscape 0.92) - > is normal editable patch, with gradient recognizable by inkscape.

Btw those scripts are just to save package's size, there is no point to run them after installation, also because SVG icons are rendered once and then stored in the cache, so there is any advantage in making them optimized but reducing loading time for the first time the icon is shown.

I forgot about caching. s/install process/packaging process/ - but I'm not sure cutting 1MB from something downloaded usually every few months is worth it.

If KDE wants their apps to have an identity, and this is what someone expressed in this thread, we can't ship just generic icon. In fact I see Konsole used without Plasma in /r/unixporn posts on Reddit.

Yakuake/Konsole, 2 types - with full identity, and "generic looking but different than utilities-terminal":

Those are amazing and I love them! Especially the Yakuake icon where you've made the > character look like a subtle Y. That's just genius.

The Konsole icon with the K in it might be a bit too complicated, but the simple version is top-notch. I would strongly encourage you to submit them in patch form. :)

@mglb would you be interesting in submitting patches with those new icons?

Yes, I'll create review soon

To be honest I don't like the new icons. In general Uri with the original Breeze and Ken with its revamped version set original styles with their consistency. They are for me real visual designers. Instead now I see new icons added with lower quality, mixing different styles and even recycling icons from other sets (I hate this so much that I manually delete them from my installation). Breeze icons are not "take an icon from another set, remove/add gradients, done."

When I submitted my first Breeze icons the review process was more selective and we all agreed that we should avoid updating icons as much as possible. I appreciate the enthusiasm in improving Breeze but this is KDE and it deserves much more in my opinion.

Now with an update of my system I saw the Activities icon was updated. I discussed a new icon for Activities once and after many attempts Ivan decided that the old 3-dots one should remain. I was OK. But now Activities icon is replaced by... I don't know how to describe it. Sorry for who designed it but it's just bad.

I think I will just fork Breeze for personal use, saving my icons without any "optimization" script to preserve them.

In T10243#206508, @alex-l wrote:

To be honest I don't like the new icons. In general Uri with the original Breeze and Ken with its revamped version set original styles with their consistency. They are for me real visual designers. Instead now I see new icons added with lower quality, mixing different styles and even recycling icons from other sets (I hate this so much that I manually delete them from my installation). Breeze icons are not "take an icon from another set, remove/add gradients, done."

When I submitted my first Breeze icons the review process was more selective and we all agreed that we should avoid updating icons as much as possible. I appreciate the enthusiasm in improving Breeze but this is KDE and it deserves much more in my opinion.

Now with an update of my system I saw the Activities icon was updated. I discussed a new icon for Activities once and after many attempts Ivan decided that the old 3-dots one should remain. I was OK. But now Activities icon is replaced by... I don't know how to describe it. Sorry for who designed it but it's just bad.

I think I will just fork Breeze for personal use, saving my icons without any "optimization" script to preserve them.

It would be helpful if you pointed out what needed to be changed instead of making a vague complaint. Whenever I can, I try to use parts of icons that we already use or are similar enough to the existing style. I also try to make others do the same.

I didn't write that specific patch, but do you have any idea how tough it is to design icons with little documentation and little prior experience with making icons?

It would have been nice if thorough documentation was left behind by the creators of Breeze. The HIG at the time I started just didn't teach any of the little important details for making an icon that looks like it belongs in Breeze. Most of the colors that are still used in the older Breeze icons are undocumented, so we have a very incomplete color palette for making icons. I mean I'm not better than anyone else in that regard because writing is hard, but still.

I started making icons by learning how to make Breeze icons. I studied the existing Breeze icons for about half a year on my own (I was also working on making Breeze icons for YaST in this time) before I became a KDE developer. I can't expect other people to do that. When I started submitting icons, there weren't many people besides @ngraham to review them. Usually, its still just me, @ngraham and @trickyricky26; all people who haven't really seen much of the original designers of Breeze. Most of the colors in the older colorful Breeze icons are undocumented and the reasons why some shapes were chosen over (currently) more common designs were undocumented. If you know Breeze well and the current state of Breeze icons bothers you so much, why don't you help in the review process? It sure would have helped me when I started. Then I could have passed on more of what you already know.

These things are what happens when the experienced people with all the unwritten knowledge go away. The redesigning of icons is a direct result of that. People redesign when they don't understand the system they are working with.

This post might sound a bit hostile, but please understand that it's just so frustrating to work with so little from the beginning and have someone who is a capable designer and who seems to have some old forgotten knowledge complain about the state of things. Maybe you and everyone else had other things in your life, maybe you and everyone else got bored (I know I am getting bored with icon work). That's fair, but try to understand what the rest of us have to deal with and maybe help out.

In T10243#206510, @ndavis wrote:

These things are what happens when the experienced people with all the unwritten knowledge go away. The redesigning of icons is a direct result of that. People redesign when they don't understand the system they are working with.

This post might sound a bit hostile, but please understand that it's just so frustrating to work with so little from the beginning and have someone who is a capable designer and who seems to have some old forgotten knowledge complain about the state of things. Maybe you and everyone else had other things in your life, maybe you and everyone else got bored (I know I am getting bored with icon work). That's fair, but try to understand what the rest of us have to deal with and maybe help out.

Yeah.

I don't know what happened in the past, but I've heard some vague stories about some split in the VDG and how all the designers left in 2016 or something. I know Uri went off to do his own thing, Jens is gone, Andy is gone, Hugo is mostly gone, you're mostly gone, and so on. When I joined KDE in early 2017, the perception of the VDG seemed to have hit rock-bottom among developers, and it seemed to have no leadership or direction.

This is the world we were left with, and without a real maintainership hand-off, we've basically had to rebuild things ourselves without--as Noah points out--documentation, experience, or a deep understanding of why things came to be. As a result, in our enthusiasm, we've made some mistakes and had to revert changes that weren't popular. We were learning as we went, because we had to build up the knowledge and experience ourselves.

But this is a common fate for open-source projects where the maintainership duties are not handed off properly. Open-source projects are public. Without solid direction provided by a maintainer or leader, they drift randomly in different directions until either they die, or new leadership appears, at which point they might start to drift *consistently* in a different direction. :). The only way to ensure that a project goes in the direction you want it to go in is to continue being active in that project, or ensure that the leadership or maintainer positions are handed off to someone who shares your vision. You can't just say, "Hands off, we did things for a reason, please don't touch it," and then disappear without providing for proper succession, or else some weirdo internet randos like us may find it and decide that it's awesome but needs some changes, and you might not like those changes. :)

So come on back! :) Teach us your knowledge. Help us make icons that are beautiful and meaningful and also win the support of the developers of the apps they're going to be branding. We want to learn from you!

Thank you for your replies. As I said I discussed a new icon for Activities time ago but Ivan decided to stay with the 3-dots one. I can't always be around to check that previous decisions aren't overwritten by others. Isn't up to others to check if there were previous discussions on an icon? The one on the Activities icon is somewhere here on Phabricator. Found: https://phabricator.kde.org/M90

I know the guidelines on Breeze icons could be improved, but when I joined they were even worse but as I said who reviewed the icons was way more selective.

The most important rule in my opinion in VDG was: don't change things just for the sake of changing. In fact the current Dolphin, Gwenview, System Settings and other icons were designed for personal use by me but other VDG members noticed them from my screenshots and asked to submit them, despite the rule of not changing things. It is a matter of attitude: if there is broad agreement to update an icon then proceed. If you are not sure, keep everything as it is, trusting the previous designers who probably took that decision for reasons.

One single person who gives the OK to update the icon for a core KDE app? It's the opposite of our previous attitude...

In T10243#206539, @alex-l wrote:

Thank you for your replies. As I said I discussed a new icon for Activities time ago but Ivan decided to stay with the 3-dots one. I can't always be around to check that previous decisions aren't overwritten by others. Isn't up to others to check if there were previous discussions on an icon? The one on the Activities icon is somewhere here on Phabricator. Found: https://phabricator.kde.org/M90

While I agree that we should look for evidence of previous decisions, we can't be expected to go back and look in random places for evidence of old decisions. Most of the git commit summaries for old icons don't even have useful information for understanding why they were designed that way and no links to old reviews. We haven't done icon mockup posts since I started, so nobody ever thought to look in the Mockups section for icons. It seems like it would save time to submit a patch with the proposed icons and make the decisions there instead of making a mockup and then making the patch. The primary advantages to doing it that way is that it keeps the discussion all in one place (unless some of it happens in a chat room) and gives the reviewers direct access to the SVGs that the icon author made.

I'd like to point out that no real conclusion was made in the discussion of that mockup. You got stuck because one of the designers disapproved because of the similarity to the Windows 10 icon and nobody replied back. I'd also like to point out that the real problem with the activities icons (old and new) are not what they look like, but that Activities don't actually make much sense as a separate feature from Virtual Desktops. Users have been saying for a long time that one should be removed or merged with the other and my experience with attempting to design an activities icon also made that obvious to me (which was never committed, but I believe it influenced the one that was committed). It's just too difficult to make good icons for Activities and Virtual Desktops because they're too similar and the advantages of Activities are too abstract. Maybe it'll finally happen in the transition to Wayland.

I know the guidelines on Breeze icons could be improved, but when I joined they were even worse but as I said who reviewed the icons was way more selective.

The most important rule in my opinion in VDG was: don't change things just for the sake of changing. In fact the current Dolphin, Gwenview, System Settings and other icons were designed for personal use by me but other VDG members noticed them from my screenshots and asked to submit them, despite the rule of not changing things. It is a matter of attitude: if there is broad agreement to update an icon then proceed. If you are not sure, keep everything as it is, trusting the previous designers who probably took that decision for reasons.

One single person who gives the OK to update the icon for a core KDE app? It's the opposite of our previous attitude...

We still don't change things just for the sake of changing. That phrase is really not useful because the reasons for change are almost never for the sake of change itself. Otherwise, we would have turned Plasma into a trendy art piece instead of trying to make usable software. Choosing to not change for the sake of changing is also not the same as choosing not to change things. A more useful saying would be "Don't rush and change thoughtfully", which is actually just saying the obvious, but it's still easy to forget when you lack experience and you've got a long list of problems to fix.

Breeze is by no means perfect. While I respect the incredible amount of work done by the old designers, that means they aren't perfect, just like everyone else. The old icons have lots of problems, but are still what we base new icons on. Breeze has a fundamental problem in that it wasn't designed well for use with the freedesktop.org icon specs, which is why we have 32px monochrome and color icons used randomly in lots of 3rd party apps and even KDE apps. Every now and then a user or someone else points out an icon that doesn't make much sense (e.g., the plugins icon). There are lots of times when I'm not sure what to do, but there is an obvious problem with a bunch of old icons. I take a lot of time to figure out what to do and a lot of the time, there simply isn't enough usable material to work with inside our own bubble, so I (and others) have to look outside for inspiration.

Your interpretation of the situation and your expectations are just not fair and even a little insulting.

Anyway, we're very off topic now, but I just needed this opportunity to vent in response to someone else's vent.

In T10243#206539, @alex-l wrote:

Thank you for your replies. As I said I discussed a new icon for Activities time ago but Ivan decided to stay with the 3-dots one. I can't always be around to check that previous decisions aren't overwritten by others. Isn't up to others to check if there were previous discussions on an icon?

In any project, every single change can be seen as overriding a previous decision. Like I said, if you want previous decisions to have more weight, you or someone else needs to be around to provide the context, remember the discussion, bring up alternatives, etc. Previous decisions are not self-evident and self-enforcing, especially when the result is something that is problematic or accumulates complaints from users or developers. The hardest decisions to enforce in absentia are those that resulted in an imperfect compromise.

The one on the Activities icon is somewhere here on Phabricator. Found: https://phabricator.kde.org/M90

Unfortunately Phab search is so horrible that if you hadn't linked to it directly, there's no chance I would have ever found it even if I was specifically looking for it. :(

The most important rule in my opinion in VDG was: don't change things just for the sake of changing.

This is a strong pet peeve of mine and I agree 100%. As a result, we never do this; every change is because we think the change is a positive improvement.

For example we changed the activities icon because otherwise the icon it was using before was 1) used in other contexts, 2) nondescript and meaningless, and 3) monochrome when we were trying to consistently use colorful icons for System Settings KCMs. This is not "chang[ing] things just for the sake of changing"; those are three good reasons. Maybe the result isn't amazing. I wouldn't say it's my favorite icon either. But doing something for good reasons and failing is not the same thing as doing thing for no good reason, such as because we're bored and restless, because we like changing things around to justify our existence, or because we feel the need to chase design trends. I constantly push back on proposals that I believe originate from one of these reasons.

In fact the current Dolphin, Gwenview, System Settings and other icons were designed for personal use by me but other VDG members noticed them from my screenshots and asked to submit them, despite the rule of not changing things. It is a matter of attitude: if there is broad agreement to update an icon then proceed. If you are not sure, keep everything as it is, trusting the previous designers who probably took that decision for reasons.

When it comes to app icons, the VDG has in fact settled on a fairly strict guideline for apps that already have icons: don't erode the app's pre-existing branding; just make a Breeze-ey version of the icon. If you do want to make a Breeze icon that's substantially different from the app's existing icon, you need to have a conversation with the app's maintainer and/or developers to formally change the app's official icon to your new icon.

Various Breeze icons violate this guideline, to the point where the apps' developers reject them in favor of the old ones (for example, Okular and Kile). That's ultimately the point of this task: to improve the breeze icons for various apps of ours so that they 1) look better, 2) match the branding guidelines we've set out, and 3) become accepted by the apps' developers.

One single person who gives the OK to update the icon for a core KDE app? It's the opposite of our previous attitude...

That's a fair point. In general we should probably be more conservative when it comes to approvals. This requires more people with the time and willingness to review patches, of course. :). And note that for the two app icons we have changed so far--Kolf and Kile--we did seek and receive the approval of the apps' maintainers.

Activities don't add much on Virtual Desktops? It's litterally the only feature for me to use Plasma and don't consider any other DE, the reason I still use X11 despite it's insecure (Activities actually don't work on Wayland). Activities boosts productivity much more than any other software I ever tried! With this I'm done, good luck.

In T10243#206631, @alex-l wrote:

Activities don't add much on Virtual Desktops? It's litterally the only feature for me to use Plasma and don't consider any other DE, the reason I still use X11 despite it's insecure (Activities actually don't work on Wayland). Activities boosts productivity much more than any other software I ever tried! With this I'm done, good luck.

I didn't say that and you ignored all of the more important points. Oh well.

Would it be possible to add KPhotoAlbum to this list as well?

Sure, go ahead and edit the task. If you're dissatisfied with KPhotoAlbum's icon, VDG is happy to help.

Thanks! I've added a subtask...

Hi, after some longer feedback loop with Tyson Tan, Kate got a initial new icon.

It is a icon variant of the mascot Tyson created for us some years ago (and the mascot will likely get a refresh to fit the new style, too).

Initial commit here https://invent.kde.org/kde/kate/commit/4dfae551c33ebcd326d4c5c07d92bc1d8a561705

To ensure the icon is used at all, I at the moment just renamed it.
This can be changed later again if needed.
And if there is feedback for fine-tuning this is appreciated.
(the important aspect is "fine-tuning", not redo)

It's quite lovely! Much more aesthetically attractive than the current icon. However I fear that the recognizability as being a text editor has been lost; nothing about the icon connotes that it's for a text editor, which is compounded by the fact that the name "Kate" doesn't suggest that either. "KWrite" does though.

This is not a huge deal as many other apps have the same thing going on. But it's something to consider.

The icon should be submitted to the Breeze icon theme rather than renaming it in the code and changing the name you refer to it with. That breaks all 3rd-party icon themes (which I guess was the point, but is not so nice :) ).

In T10243#218606, @ngraham wrote:

It's quite lovely! Much more aesthetically attractive than the current icon. However I fear that the recognizability as being a text editor has been lost; nothing about the icon connotes that it's for a text editor, which is compounded by the fact that the name "Kate" doesn't suggest that either. "KWrite" does though.

This is not a huge deal as many other apps have the same thing going on. But it's something to consider.

Yes, that was done by intention.
First we tried some variants involving "text" in any kind, but that is just like the old icons that look somehow some either a mime-type icon or a generic "something".
If you look around, close to none of the currently relevant text editors have icons that have anything to do with "text" ;) (I look on you Atom, but same for Sublime and Co.)

The icon should be submitted to the Breeze icon theme rather than renaming it in the code and changing the name you refer to it with. That breaks all 3rd-party icon themes (which I guess was the point, but is not so nice :) ).

I am not that sure of that.
Actually, I would like to have this as default for any icon theme now and not the other way around being waiting for any and all theme to try to catch-up.
Actually, I was first very confused why my icon was never used before I remembered: ahhh, icon themes :P

Are you sure this is the best decision though? Icon themes will just theme the new icon again, it will only have a short-term effect.

Meanwhile I'm not actually seeing the new icon after updating the app from current git master. It should really be added to the Breeze icon theme.

In T10243#218612, @filipf wrote:

Are you sure this is the best decision though? Icon themes will just theme the new icon again, it will only have a short-term effect.

But than at least they theme the new one. Otherwise I will manually need to ping all themes around to update theirs, or?
And what is with themes no longer maintained? There Kate will be stuck with the themed old icon forever ;=)

In T10243#218613, @ngraham wrote:

Meanwhile I'm not actually seeing the new icon after updating the app from current git master. It should really be added to the Breeze icon theme.

Hmm, that is a bug then.
Thought the question is: Where is it missing? In the menus or in the application? For me the application uses it, e.g. in about, not sure if the system will prefer the new .desktop file thought.

I see it in the about window:

But not in the window's titlebar, or the window switcher, or Kate's task manager icon. Basically anything outside of Kate's direct control is using the old icon.

I assume that is because the desktop file we install doesn't have preference about the system wide one, or do you have only a master kate install without any system wide?

(also, do kwin/plasma actually see the desktop file in the custom install prefix, e.g. by being started with respective paths in the respective env vars?)

We should probably discuss this somewhere else so as to avoid derailing this poor task too much. :)

Gweview icon inspired by: Circle-icons-eye.svg

Update: submitted in Gwenview (T13400)

An icon proposal for Ark.

Update: Icon improvements and licensed LGPL.

Hi, just to avoid any wasted work:

For KWrite, one can think about altering the icon, not sure if that is needed, thought.
For Kate, we have a new icon, we don't alter that again nor do I want to have an altered version in Breeze.

Colored Kwrite icon proposition:

I like those!

Okular icon proposal.

With Okular, I'm interested in being more faithful to the original if we're going to redo the icon. See up-thread: T10243#201368.

In T10243#235453, @ngraham wrote:

With Okular, I'm interested in being more faithful to the original if we're going to redo the icon. See up-thread: T10243#201368.

The original okular icon looks to me like a mimetype icon. But I'll give it a try!

@tosta hi. thanks for your artwork proposals, they show you are skilled, makes me jealous :)

When it comes to designing icons, it is not only about art though, but also about feasibility when used in context. Icons are less often used in the size you are presenting your work here (and what the table above shows), but rather in smaller sizes (like in menus or window title bars etc) and on normal DPI displays.

So to see if icons are good, it would be good to have at least a 48x48 pixel version, but also smaller sizes liks 32x32 to get an impression how they will work (edit: or at least special icon variants with less details) and not e.g. look blury... cmp. also https://hig.kde.org/style/icons/colorful/index.html

In T10243#235458, @kossebau wrote:

@tosta hi. thanks for your artwork proposals, they show you are skilled, makes me jealous :)

When it comes to designing icons, it is not only about art though, but also about feasibility when used in context. Icons are less often used in the size you are presenting your work here (and what the table above shows), but rather in smaller sizes (like in menus or window title bars etc) and on normal DPI displays.

So to see if icons are good, it would be good to have at least a 48x48 pixel version, but also smaller sizes liks 32x32 to get an impression how they will work (edit: or at least special icon variants with less details) and not e.g. look blury... cmp. also https://hig.kde.org/style/icons/colorful/index.html

@kossebau, I'm not a profissional artist. Only an entusiast. I'm not fully skilled and not so familiar with icon development. The icons I'm submitted here is ideas based on personal hacks I have made to personalize my desktop. But I can try to made the required changes and submit it to KDE. I'll be pleased if someone of them will be approved.

I have a feeling they will, with some polish. :)

Use Breeze color palette.

In T10243#235530, @alex-l wrote:

Use Breeze color palette.

Hi Alex. Already using the palette and guidelines. See gwenview icon evolution:

Cool stuff. Could you start submitting your icons are merge requests to the breeze-icons repo?

https://invent.kde.org/frameworks/breeze-icons/-/merge_requests

@ngraham can you stop this please? You all are ruining all our previous work. Aren't you able to see how much wrong these icons are? Can we please stop recruiting people without the needed skills for this work and don't give OKs by people who contribute in other areas (you)? This is serious stuff exactly like code, don't treat imagery like a second citizen. In other communities (Mozilla, GNOME, Elementary) this doesn't happen.

@alex-l can you say me what's wrong with these icons? I'm trying to do it following all HIG recommendations (sizes, margins, colors...). I'm not a specialist as you said, @ngraham does not recruited me, and I'm aware his OK is not a approval. But I'm trying to help because I love KDE and I'm doing personal hacks and improvements for years. Please contact me privately if you want.

@alex-l nobody shares your opinion that app icons are different from logos and that therefore they should have a minimal, understated style and do not need to mimic the original version. This isn't a self-evident design truth, it's just your opinion on icon design, and nobody else seems to agree with you.

Breeze icons are a theme among many themes, and not the canonical source of truth regarding apps' icons; radically changing an icon requires the consent of the app's author for them to change not only the Breeze icon, but also to change the original icon, potentially adopting the Breeze icon as the new original icon.

You keep decrying that no real designers are reviewing icons yet you don't want to step up and do this, other than complaining that everyone else's work is crap. You should help guide new designers rather than just telling them to stop doing anything because the status quo is perfect.

@ngraham go to any art school and they will tell you the difference between a logo (branding) and an icon (software user interface).

You can say "nobody" agrees with me because all the other old VDG members are not around anymore, some of them went away like me because visual design is treated as a second citizen in KDE. Code developer are just "tell me your opinion on UI/UX, then I will decide what to do with MY software".

In KDE there is meritocracy, right? Why this doesn't apply to icons? Why there isn't even one Breeze Icons maintainer that is qualified to tell what contributions are OK?

I can understand this for other app icons that are missing in Breeze but replacing the old ones not. If you are not able to produce better icons just don't replace them.

Are you asking me to contribute back by teaching how to draw better icons? I already spent my time drawing icons just to see them replaced with no discussion. I spent my time discussing a matter for hours just to see a new generation of contributors not knowing previous discussion just taking another decision. What's the point of contributing now if someone will change everything just for the sake of changing? There is no enstablished workflow for visual design in KDE community, there is just a continous anarchy. If this was the case for code nobody would use KDE software at all.

Some people study to learn how to code. Other people study visual arts. I'm in the former category as a software engineer but since I think visual design is totally part of GUI development I learned it too.

In KDE any developer tries to teach basics of programming to new contributors, one is just supposed to know the basics. Should I spend my time to teach to others how to use a color palette? Are you serious?

This is the Mozilla logo:

This is the Firefox logo used in branding:

And this is the Firefox icon used as an UI element to launch Firefox:

Why Mozilla have no icon? Because it's not an application, it's a company with a branding. Firefox as a project has its own branding and this project include some icons to launch different version of Firefox.

This is what professional visual designers paid by Mozilla set. But hey hobbyists here disagree.

@tosta

In T10243#235383, @tosta wrote:

Gweview icon inspired by: Circle-icons-eye.svg

Update: submitted in Gwenview (T13400)

Here the gradient from blue to white in the center is definetely wrong... In Breeze icons you can see sligthly gradients but they mostly indicate a light source, they are not gradients from a color to another totally different one.

About the shape, it's cool but it's too much round compared to other shapes used in Breeze. And there are too much details namely all those circles.

Anyway this is just an eye, I think it's too generic as metaphor. In these cases you should provide reasoning on why this should be an improvement. Keep in mind that app icons, especially the core apps ones, shouldn't be updated without a strong reasoning.

In T10243#235386, @tosta wrote:

An icon proposal for Ark.

Update: Icon improvements and licensed LGPL.

ark.svg22 KBDownload

Here you totally missed the Breeze color palette... the gradient makes the icon look shiny and the reflection makes it look glossy. Don't you see we haven't anything like that in Breeze?

And the shape... why a circle should be better than the rectangle for an application to manage archives like Ark? I think the circle is hardly relatable to archives.

In T10243#235432, @tosta wrote:

Colored Kwrite icon proposition:

kwrite.svg29 KBDownload

DON'T write labels in the icon. This is so bad visually as small sizes and for localization... what if one just use generic names? Plasma has an option for that, I don't remember if it's the default.

Again the color has nothing to do with other Breeze icons... and there are too many details in center while the left border is basically inherited from flat design...

In T10243#235450, @tosta wrote:

Okular icon proposal.

okular.svg14 KBDownload

This is not bad, it could be a Breeze icon, but the combination of that red and that blue is very bad. You will have a hard time trying to mix blue and red, they don't fit together because of color theory reasons. In this cases do some search on how to design color palettes to learn how to mix different colors.

Anyway you should really try other tasks concerning icons and visual design. Breeze icons for core apps are too important.

In T10243#235550, @alex-l wrote:

Mozilla, GNOME

Both are now pale shadows of their former selves. Features = removed, customizability = gone. Truth-tellers told and told and told them "please no" until blue in the face, but sadly all their efforts were for naught. It's like software stopped improving and is now actually deteriorating, just look what they did to GitHub... Professional UX design only ever leads to ruin these days, it seems.

Relevant: The Decline of Usability and this tweet about Windows 95.

In T10243#235625, @alex-l wrote:

This is what professional visual designers paid by Mozilla set. But hey hobbyists here disagree.

https://pics.me.me/the-fox-is-out-of-the-bag-in-beta-on-63346294.png

Professional design = please no...

@alex-l. These icons was made using Inkscape default palette (the effort at it design time was to discuss the ideas). Later I redesigned the ark, gwenview and kwrite icons from scratch using the breeze palette and colorfull icon guidelines.

In the case of gwenview, I tried to maintain the colors and shapes of original icon, but changing its center to looks like a camera with an eye inside.

In the ark icon I tried to use some different of conventional design of file compressing programs icons - not so good, but its here to be discuted.

Kwrite's icon proposal was remade, the label was removed and colors changed.

And finally, Ocular's icon is one that it wasn't touched anymore.

In T10243#235641, @churaev wrote:

In T10243#235550, @alex-l wrote:

Mozilla, GNOME

Both are now pale shadows of their former selves. Features = removed, customizability = gone. Truth-tellers told and told and told them "please no" until blue in the face, but sadly all their efforts were for naught. It's like software stopped improving and is now actually deteriorating, just look what they did to GitHub... Professional UX design only ever leads to ruin these days, it seems.

Relevant: The Decline of Usability and this tweet about Windows 95.

In T10243#235625, @alex-l wrote:

This is what professional visual designers paid by Mozilla set. But hey hobbyists here disagree.

https://pics.me.me/the-fox-is-out-of-the-bag-in-beta-on-63346294.png

Professional design = please no...

This is not Reddit. Avoid off topic and shitposting. Thanks.

In T10243#235654, @tosta wrote:

As I said: use slight gradient to indicate source of light, NOT gradients between totally different colors.

Anyway don't spend more time trying to redesign Breeze icons for core apps. I'm totally against changes like these, I don't consider them to be an improvement, no offense.

I get it, you think that there is or should be a meaningful difference between an application's icon and its logo, and that the breeze icon theme should be full of icons, not logos. But there doesn't seem to be much agreement with this idea: not among the current generation of VDG people; not even among some of the prior VDG people, who have complained about this to me; not among the developers of the apps in question who have complained about their current Breeze icons; not among users who file bug reports and complain about it. Furthermore, this proposed icon/logo split does not match the state of reality for most of the app ecosystem in the wider world; most apps use their icon as a logo, and design it accordingly to be able to serve both roles. And I'm not sure your counter-example of Firefox is something we want to emulate. For example, if I go to https://www.mozilla.org/en-US/firefox/mobile/, I see the following:

To me, this is weird: the same brand name ("Firefox") is displayed with two different icons on the same page (fine, one is an icon and one is a logo). If I saw this on https://kde.org/applications/, I would file a bug report. Mozilla's choice is not something I would call self-evidently better design. To me it looks weird and inconsistent. And I think the app icon looks much better than the logo, which is bland, indistinct, and bears no relation to the name (there's no fox, not even a stylized abstract one).

I think you're a great designer and I would love for KDE to be able to continue benefiting from your expertise. But I think this will be difficult if it means that you're going to constantly try to push this idea of an app's icon not being its logo which does not seem to be very popular, because the conflict that it generates strains relationships, drives away conflict-averse people (as evidenced by people unsubscribing themselves from this Task), and makes you feel marginalized and unappreciated. That would be quite a shame and I hope we can figure out a way to continue working together.

Regardless, let's do the design review for proposed new icons in the applicable merge requests themselves, not here.

@ngraham logo vs icon discussion is a very minor issue (though I would be happy to see if Ken Vermette, Uri Herrera and others who contributed to Breeze Icons for apps agree or disagree with me), instead I want Breeze Icons to be treated like any other component like Kwin, Kirigami etc i.e. with maintainers/major contributors that have the final say. I followed the development of other KDE projects in the past and I know there are always developers that know very well that specific codebase because they contributed a lot over the years and took responsability as maintainers. This used to be the case also with Breeze Icons. My contributions to it is good just because of the input by previous contributors, I was even lucky enough to learn in person from Ken Vermette.

I think that when a group of people will contribute to Breeze Icons with new app icons and minor fixes to the current ones then they will have the right to make major changes and we will have good chances that those will be improvements, not changes for the sake of change like the icon for Activities. At the moment I see just the opposite and no offense, being good in an area doesn't imply being good in another one even if apparently similar.

You have a long history with Breeze icons and care a great deal about design. Maybe you should be reviewing icon patches and suggesting improvements and working on new versions of problematic icons.

Be the change you wish to see in the world. :)

Now that Kate has its own special icon, I don't think Kwrite needs to be changed.

In T10243#235907, @ndavis wrote:

Now that Kate has its own special icon, I don't think Kwrite needs to be changed.

I think the actual kwrite icon looks like a mimetype icon. It's palid and confuse.

Take a look at new Notepad icon from Microsoft as an example.
It's nice and looks like an application icon for a simple text editor program.

In T10243#235942, @tosta wrote:

In T10243#235907, @ndavis wrote:

Now that Kate has its own special icon, I don't think Kwrite needs to be changed.

I think the actual kwrite icon looks like a mimetype icon. It's palid and confuse.

Take a look at new Notepad icon from Microsoft as an example.
It's nice and looks like an application icon for a simple text editor program.

Isn't this from Windows Vista?

P.S. Text editor =! app for notes

In T10243#235943, @alex-l wrote:

In T10243#235942, @tosta wrote:

In T10243#235907, @ndavis wrote:

Now that Kate has its own special icon, I don't think Kwrite needs to be changed.

I think the actual kwrite icon looks like a mimetype icon. It's palid and confuse.

Take a look at new Notepad icon from Microsoft as an example.
It's nice and looks like an application icon for a simple text editor program.

Isn't this from Windows Vista?

P.S. Text editor =! app for notes

Not sure if it is from Vista or other version. But this icon fulfills its purpose - to represent an application for notes (notepad).
The actual Kwrite's icon, not (represent a text only editor). I have various icons I have made various icons for kwrite and other apps, perhaps only
of them is a good candidate to replace the current.

	kwrite-logo.svg8 KBDownload
	kwrite.svg8 KBDownload

@tosta The current KWrite icon can be improved, but there is no reason to replace it with a totally different one.

Hi all, if it's ok for me to weigh in on this a bit, I will say firstly that I love kate/kwrite, and was immediately blown away by both when I (finally) discovered them recently.

My main concern is that an icon should be not just unique but should quickly convey what the program is for. This is especially useful for new users who don't know what a program called "Kate" could possibly be for (the only clue would be if the user found teh shortcut in a properly organized and grouped menu). I'm not a big fan of the new Kate app icon, and have been finding it really hard to get used to it (as in, when visually scanning in my task list). I have included in the image below an example of some of my most used programs. I think the Kate icon could be improved by taking the Thunderbird approach, ie, a bird wrapping an envelope: unique, quickly conveys what it does. Just take the current Kate icon and add some kind of paper looking thing to it (could even use the one from the example below, with two sheets). I like gimp's new approach of having a preview with the app logo composited above it. I have several terminal applications in my taskbar, and each is slightly different so I know right away which one is for konsole. The other two icons below are for Kate and Kwrite as my system currently serves them in the switcher (I use Mate for my desktop). I like that that Kate icon conveys the strength of Kate: multi-document editing, and the Kwrite icon shows only a single document. I also like the fact that the kwrite icon in the message above has a distinctive color to set it apart from other text editors. In any case, thanks to all, hope it's ok that I barged in here like that.

Edit:

I should also mention that I really like the color and stylized KW logo for Kwrite (more than the green notebook), if it could incorporate the "single sheet" icon into that, it would be great.

Thank you @rrosch. @alex-l I will work with official Kwrite icon and try to improve it. Let it be clear that what I am presenting here are just ideas. Something that improves the distinction of applications by relating them to their functions as @rrosch said, which will be very important for new KDE Plasma users (especially the newly orphaned Windows 7) who will be added to our user base.

Another icon that need improvement is elisa.svg. It looks bad with dark background.

In T10243#236012, @tosta wrote:

Another icon that need improvement is elisa.svg. It looks bad with dark background.

there was another attempt at a new elisa icon, but the patch author seems to have disappeared and the patch doesn't apply correctly, which makes it very difficult to complete the patch.

I think KDE Connect has a quite outdated icon too.

I'm not quite versed with icon designing.. would someone like to take a jab at the revamp?
We recently had a revamp of the android app and it looks quite well with the times now, plus we're almost ready for the Windows release.

It'd be nice if someone breathes new life into the icon. :D