I think it's a Freedesktop standard. It seems we have multiple of 2 and 3 starting from x4:

In T11084#256014, @ngraham wrote:

And I'm glad we don't have to put up with your sour attitude, passive aggression, and incessant whining anymore. Or at least, we didn't until your comment.

In T11084#255885, @ngraham wrote:

Maintainer decision to stay with the current circular indicator, sorry. :)

https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/759#note_218650

At the moment LabPlot doesn't even run on Neon (Cantor installed). Error:

In T12068#244966, @davidedmundson wrote:

See thread: "Discussion for Virtual Desktops and Activities" on plasma-devel . I can't find an archive link but I'm sure there is one.

There was definitely some support for something along this idea.

The proposal I made, was that:
Before:

• A window belonging to N activities *and* M VDs.
  
  After:
• Windows would belong to N VDs.
• Each VD would belong to one activity. To provide a sense of hierarchy.

As I just wrote here: https://phabricator.kde.org/T13582 most users don't know that restarting an Activity restores windows and applications' state (if they support XSMP protocol, most KDE apps do) just like the well-known session restoring after the login.

For reference xdg-session-management protocol is the work-in-progress replacement for XSMP in Wayland: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18

In T13582#244856, @ngraham wrote:

Third party apps don't need to support Activities or anything Plasma-specific at all but just XSMP (X Session Management Protocol),

Gotcha. That's pretty clever.

Unfortunately the point still stands since tons of apps sadly don't support it. It's not just Firefox; Thunderbird, LibreOffice, and all Electron apps also don't seem to support it. I'm sure there are more too.

In T13582#244491, @ngraham wrote:

Wow. Impressive.

This kind of leads me to what I consider the Achilles heel of activities: every individual app needs to be made activity-aware. That seems hard enough for KDE software over which we have total control, due to disagreements about the scope of what set of the app's settings should be activity-aware. But since 3rd-party apps don't support activities at all, the concept just breaks down if you want or need to use 3rd-party apps. :( 5 out of 11 of my pinned apps are non-KDE apps.

In T13582#244379, @ngraham wrote:

@alex-l You said:

I have a Firefox profile on each Activity with different favourites, history etc.

How did you do that? Does it let you have different sets of tabs per activity too?

It's not that Virtual Desktops and Activities are not useful but they are just presented in a way that doesn't make obvious how to use them. I wrote some blog posts in Planet KDE years ago explaining (creative) way to use Activities. But in fact if you need to explain intended workflows with blog posts you have a UI/UX problem.

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

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.

@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.

In T10243#235654, @tosta wrote:

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...

In T10243#235383, @tosta wrote:

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

Update: submitted in Gwenview (T13400)

This is the Mozilla logo:

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

@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.

Use Breeze color palette.

In T12068#223750, @alexde wrote:

Please bear in mind that the dimming may still be too strong for dark themes with a already dimmed screen.

Alright; if this effect becomes rewritten as I guess, it should be possible to introduce an option to satisfy everyone. ;) Thus, it's not necessary to focus on this specific effect now in the further course of the task. Sorry for the detour. :)

In my mockups there is already less dimming than in current implementation, I think that is already a good middle ground

In T12068#223688, @alexde wrote:

I think there are better ways to highlight a selected or hovered one, like putting a glowing frame around it. Maybe this can be considered for future mockups if there's consensus?

If you need some inspiration:

Please consider making Latte Dock just more integrated, for example presenting it as an "advanced panel" with its menu entry: right click on the desktop > add new panel > advanced panel. Maybe the process could still be "plasmashell" if possible. It could be shipped with an additional package ("plasma-advanced-panel" or something like that according to distro naming system) and each distro could decide to ship it by default or not. The release could be the same as Plasma to make clear that Latte Dock (or whatever would be it's name) 5.x.y is meant to work with Plasma 5.x.y. Maybe the layout manager could include classic Plasma panels.

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.

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

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."

@ngraham wouldn't right click a quick alternative way to open the more options menu?

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.

In T10243#201461, @ndavis wrote:

Are you talking about some of the mimetype icons?

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.

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

Would something like this being enough for Kate i.e. an origami bird made of current icon paper?

Here there is an example of brand artwork using that diagonal shape for Konsole:

What do you think about this kind of icon? This one is for Discover: the puzzle pieces indicate apps and other addons, the triangles the packages that ship the apps and the ">" shape looks like Plasma logo.

In T10243#201336, @starbuck wrote:

Maybe look forward for this then for Plasma 6?

@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.

@ngraham I think you have a problem with minimalism :) original Breeze icon for Gwenview, Kate and KWrite were even worse than the current ones by me, in fact I already tried to go back to some Oxygen style.

Just to be clear, is Gwenview icon enough descriptive and distinctive at the same time?

In T10243#201291, @cullmann wrote:

Actually, that is exactly what I want to have: an arbitrary logo that is distinguishable.
It does Kate a big disservice that we have no icon like Atom/Sublime/Vim/...
A generic "text" icon is nice for a mime-type.
Users will easily detect where to start Atom, but not where to start Kate, as it could just be any other "editor".

Hey there, Gwenview, Kate and Kwrite icons are by me.

The important thing is preserving the current ease in distinguishing active window from inactives (for all windows, not only Qt/KDE ones)

OK, but I don't think that changing Breeze theme for QtWidgets is a good idea to solve an issue with the title bar, only KDE/Qt applications using QtWidgets would benefit of this. And since then Breeze theme for QtWidgets and Breeze window decoration will only make sense if used together.

What do you think about inactive window title bar matching Plasma panels theme (90% opaque white by default with blur)?

The problem with that approach is that with a lot of tabs, the amount of remaining drag area is tiny and borderline useless, just like Firefox with CSD currently has

In T10870#188954, @mglb wrote:

In T10870#187536, @alex-l wrote:

Anyway consider that any change to mimetype icons imply a lot of work.

Scripting! <3 At least with some designs, like yours or mine

Hey @ngraham, you said tabs in the title bar prejudice usability in dragging the window like in Firefox and I think you are right, so I did the following mockup with a responsive layout for the title bar, can you let me know if it would be good for you? Thanks!

Another option would be displaying a label "Menu" instead of the hamburger menu when the window is narrow and File Edit View... labels when there is enough space and dragging area

In T10201#188377, @davidhurka wrote:

Is there a consensus that the titlebars are not liked enough by the users, possibly because they appear to waste too much space while looking empty?

If so, I want to suggest this: Make the menubar titlebar button expandable, so the menubar can be shown inside the titlebar.
For narrow windows:

• it would stay a hamburger button,
• or the menubar is cut off somewhere with a drop down button.
  
  The text in the menubar could be placed a bit downwards, to indicate that it belongs to the application, not the window system.
  
  Of course, this does not work for browsers which have no menubar by default.

Just a mockup but is this middle ground solution good enough?

In T11082#188332, @ngraham wrote:

One thing to note is that currently the window resize areas are invisible and drawn outside the window's bounds, so this won't actually impair that use case at all.

@ngraham I opened this, I hope everything is OK: https://phabricator.kde.org/T11082

Maybe this is just a perception from the point of view of the icons. When looking at the two images, I don't see a perceptible change with the titlebar height, but I notice it with the icons. If the icons were consistently the same size and the titlebar a different height, would that be good?

BTW. There were window tabs (not app controlled though) in KDE4, but nobody ported them.

@ngraham After thinking better, I think you're right but I also think that such a large title bar contributes a lot to making users hate server-side decorations. I can't think of any solution apart from making it more useful with tabs like in the Plasma Sets mockup.

May I suggest to change title bar size from medium to little? I'm on a 169 DPI screen (very high for desktop without UI scaling) and it's still very usable

At 16x16 the symbol could be removed and just show the document frame (I thought about this when I insisted to associate a color with mostly each mimetype).
Anyway consider that any change to mimetype icons imply a lot of work.

In my opinion we shouldn't touch Breeze theme for Qt apps or massively redesign KDE apps.
Please consider that KDE apps with Breeze theme could run in a DE without KWin and that not all the apps use Qt, KDE widgets and Breeze theme: KWin should make obvious for every app if its window is active or not. We should change Breeze theme for window decorations only.

Just a thought: since "alternatives" pattern seems to work, what if Bob find as alternative to application launcher (Kick off) a full screen launcher like the GNOME one, that:

Very cool!

@scherek except for the icon-only tabs (that I don't think would work), do you mean something like this?

@oussemabouaneni it's writter in the very first image: the browser (and other apps with tabs) should hide their tab bar. Managing shortcuts in a meaningful way shouldn't be a problem. The challenge would be integrating existing browsers like Firefox and not only the KDE one, Falkon.

I'm mostly with Andy on this.

I'm the author of this one: