cullmann

At least now it got re-opened.

Yes, and if they think the spec is bogus and obsolete, fine, either help to improve it or just provide no icon theme that pretends to follow it, then distros know they need to install another one for 3rdparty apps...

I can do that, but I still think it would be nice to keep all applications work on all desktop envs.

If it is that way, there should be no theme index that states otherwise in the theme. As mentioned in the bug, that still is the case. Even if not the default on other distros, users will be able to pick it in desktop envs that honor the spec and trust that file.

We no longer do:

Git commit c8b8a4db63b575edf931c3d61aea1ed3d3d287f2 by Nate Graham. Committed on 01/05/2024 at 21:50. Pushed by ngraham into branch 'Plasma/6.0'.

kcms/icons: filter out GNOME's Adwaita and High Contrast icon themes

These are no longer FDO-compatible icon themes, and are apparently no longer intended to be used for non-GNOME apps--going against what an FDO icon theme is supposed to be used for.

I've contacted the GNOME folks about it, and unfortunately they've made it clear that the situation is intended; see https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/issues/2...

As such, allowing the user to select these icon themes will just give them an opportunity to break all their non-GNOME apps. Let's filter these themes out to prevent that possibility.

We still need to figure out a solution for when our apps are run in distros where Adwaita is used as the default icon theme, but that's a separate topic.

BUG: 486409 FIXED-IN: 6.0.5 (cherry picked from commit 813d22ff80ede0c7c08e4563621e3778459426f0)

M +12 -0 kcms/icons/iconsmodel.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/c8b8...

Yes, I just fail to see why one not went with some easy fix and then perhaps thinks about enhancing the spec. Errors can happen, I did break stuff in the past, too.

I as Kate maintainer can not understand their position in that bug. I see that one might forget about the implications of that rename, but now it got reported and the fix would be, at least the simple one, to just keep the old icons for these names. That would have zero bad impact on 'modern GNOME apps'.

I think you mean 'Breeze'. I think to have other icons, you just need no select a different icon theme, if you installed one, but please not Adwaita :)

I must confess we have a lot old bug reports around in the KDE project, too, therefore I can see the point that they might no set the priorities on such things.

In the most cases in KDE or Kate it will only happen if you trigger the interest of a dev (if it is no fatal bug) or you can provide some patch.

I can even see why they want that change, but even just keeping the old icons as compat would have been good enough, I just miss the issue why on doesn't do that directly after the issue is pointed out.

:( given the KDE developers (and other devs) did spend a lot time to ensure the applications they create work not just in their personal favorite desktop environment, this is all rather unfortunate, as it is now like it is in a released distro...

yzis never took of, yes.

I don't think it is the best design, but for the sizes of files one usually works with, it seems a good fit (with low complexity).

Before we had that, we had a icon that just looked like a text file mime type with zero recognizably.

Even if you used it for a week, you would not be able to know which application is running just looking at the icon. Could be any editor or some word processor.

With the current one, it is clear. And yes, I think that makes sense, that is a brand.

And it is what most other applications do, too. I doubt my mother has any idea what e.g. the Chromium icon means, but once seen a few times, it is clearly recognizable.

Amarok did 'die' because the dev team dissolved due to multiple issues.

I see no issue in getting inspiration from other programs.

All projects do that, and I think that benefits the users.

Code has semantic highlighting via LSP, that is something KDevelop had before Code or Atom existed.

Same for the 'go to everywhere' that most likely was first in Sublime.

:) Perhaps even some features from Kate did inspire others, it is not that young.

Thanks :)

Simple reason: Because the package is not optimized for that. It can be shrinked more, but that needs help. And I must confess, I rather spend my time on bug fixes than space optimizations.

Yeah, that seems to be the likely reason. But I am not sure why that ends up with pulse. But I am not the OpenBSD packager for that.

Kate not just uses the same shortcuts everywhere. But you are right that it has issues to be properly adjusted to macOS.

On my Mac Mini I used for the screenshot I just followed the linked howto (one can even just use the system Python with the latest macOS)

https://community.kde.org/Get_Involved/development/Mac

And yes, that needs initial effort, that is true. One can for sure improve this, but that needs volunteers.

KDE applications still need a lot love on non X11/Wayland systems. Kate got some polish in the last years on Windows, the macOS version still needs more.

Nice that Kate did help you to make the switch. The SQL plugin is unfortunately not that well maintained any more, help with that is welcome.

Yes ;=) The store description/feature list needs still tuning.