I would like to collect some opinions of Plasma users, just for fun, to get a better image. poll poll A big cause of issues that only occur on the user’s side is “changing settings away from the default”. It would be impossible to test all these cases. poll A desktop with a few bugs may be very fine for an advanced user, but problematic if the administrator is not around to help. poll Last question: poll

I am not a KDE dev, but interested in that topic.

To partiticipate you can sign up in the forum, and maybe stay a bit and help other users ;)

    • boredsquirrel@slrpnk.netOP
      2·
      2 months ago

      KDE Plasma can break a lot when it is modded. I see that the feature to reset the settings is really cool (but the option to show them is hidden).

      But still, your desktop is not managed, unlike your system packages.

      I had Plasma break a lot, but I think that was general instability, not because of extensions etc.

      So maybe you are right? Maybe not. Interesting to know anyways.

  • mox@lemmy.sdf.org
    8·
    2 months ago

    It’s probably worth noting that Plasma’s customization support is useful not only to people looking for a special look & feel, but also as a proving ground for new things (and new approaches to old things) that can eventually make their way into mainline Plasma. Making things harder to customize would mean fewer people experimenting, refining ideas, and solving problems. With that in mind, I think that removing customization in hopes of simplifying test cases would be a mistake.

    However, it’s my understanding that some of Plasma’s customization hooks allow third-party theme components to run arbitrary code, without even a warning, sandbox, or reasonable way for the user to inspect it beforehand. (This was in the news a couple months back, IIRC.) That was more or less okay 20-25 years ago, when malware on Free operating systems was almost unheard of, but it’s dangerous and irresponsible in today’s world, where extensions/plugins have become common attack vectors. I wouldn’t mind a little loss of customization to shut down that vulnerability, at least until safer extension APIs can be built.

    • boredsquirrel@slrpnk.netOP
      2·
      2 months ago

      Yes I agree. There is a switch you can use to block installing Addons.

      But that is also not nice. Sandboxing them, having a manual review process, would help. But that is a TON of work.

      I also change some things like UI buttons and find it to be a core requirement. At the same time, I could live without extreme theming, or just having widgets on the panel, or just having a bottom panel etc.

      This is a difficult decision, so I thought it would be a good idea to just find out what some users want.

      • mox@lemmy.sdf.org
        1·
        2 months ago

        Sandboxing them, having a manual review process, would help. But that is a TON of work.

        This is why it would make sense to have a restrictive and simple API that supports basic extensions with little oversight. Configuration only; no executable code.

        For the small minority of add-ons that would require executable code, there could be a separate API with a more involved installation process, making it obvious to the user that the trust and risk levels are different from the above. A sandbox feature could perhaps be developed in the long run, but that is indeed a ton of work and hard to get right, and isn’t really necessary for this approach to be effective. Just having a software-style installation process (e.g. through a distro’s package manager) and different APIs would go a long way toward protecting users.

  • Blaster M@lemmy.worldEnglish
    2·
    2 months ago

    I was fine with LXDE… until it got abandoned for LXQt… which is alright, but it’s more “kit car hackjobby” in its presentation than LXDE.

    • boredsquirrel@slrpnk.netOP
      1·
      2 months ago

      LXQt will get some love in Fedora, mainly by the KDE Devs. Excited to try it out!

      A problem of the small desktops is, that distros may lack behind in packaging.

      And as I wait for Wayland support, I assume LXQt may run, but have no GUI settings for the underlying compositor at all.

      With XOrg that may have been easy (I have no idea of XOrg) as all Window managers used it.

  • kde_user@lemmy.kde.social
    1·
    2 months ago

    Here is my take:

    1. Stability - I’d say very important, especially for a DE that is used by a lot of people as a daily driver.
    2. Customization - IMO this isn’t a simple yes/no question. It shouldn’t be about the number of settings exposed to users but rather the number of “useful states” a user can achieve.

    Let me give you an example with the multiline Icons-and-Text Task Manager. Of the main DEs I’ve tested, KDE is by far the most customizable and provides many related options, resulting in lots of different combinations (states). However, with none of those states I can achieve what I think would be much better (see my recent post here). My proposition is of a completely new alternative layout. I don’t think that can be efficiently achieved by simply adding a bunch of “partial” settings (such as, for example, a checkbox for keeping the rows at fixed height), because going that way would result in:

    • Many more potential combinations (different possible states). And an increased % of those would be unnatural (not very useful & confusing) to the end user.
    • Increased complexity of the code that tries to handle all the possible combinations (hence, more potential for bugs).

    So for the multiline task manager, I don’t need most of the current settings, so I could say I don’t need a lot of customization. But what I’d love to have is something that is currently not available, and that in itself could be interpreted as “a need for (another) customization”.

    Finding the “right” amount and type of customization is the key, but that’s very hard. Largely because making changes gets increasingly harder at the later stages. And also, what is “right” is subjective, of course.