Removing the ability to deactivate entries was done intentionally since it seemed redundant to removing them and I'm not sure there is a strong use case for it.

As a workaround for quickly disabling an entry you can add "Hidden=true" to the .desktop file in .config/autostart

But I have a severeal scripts enabled and I want to toggle them ftom time to time. For me this decision is a downgrade. I don't know why they "fixed" something that's was working fine...

A very convenient use case for this is to override system autostarted applications per user. You could just add it to autostart and disable it to prevent autostarting.

I can't disable, just remove them and this is exactly the problem. For whom a single check box was a problem and why it have to be removed? I'll say it again - it's a pure form of downgrade. There was a great option and now it's gone without any purpose.

I would urge to add reinstate the ability to enable/disable autostart scripts. I have a few scripts implemented (over the years from KDE SC 4.0) and it is very convenient to enable/disable those. Even the remember the correct path and command line options to re-add a script after deleting it is a pain.

User feedback has spoken lol. IIRC even macOS has the ability to both disable and delete autostart entries. :)

And GNOME :D

*** Bug 430522 has been marked as a duplicate of this bug. ***

There's another feature that is missing as a result of this feature missing: disabling a startup service on a per-user basis instead of on a system-wide basis.

In the past, I have always copied all the entries in /etc/xdg/autostart/ to ~/.config/autostart/, so that I could override whether they were enabled or disabled - as setting whether they were enabled/disabled in the file stored in the home directory overrode the file in /etc/. This let me enable/disable autostart entries without affecting global system files.

IF ANYTHING, I would have opted for this configuration page to detect system autostart entries, and disabling them would make a copy in the user's ~/.config/autostart directory with it disabled. This would be more ideal than having to copy the files myself.. And bringing back the previous functionality would AT LEAST make it easier than Editing The Files Myself.

I know that Nicolas Fella worked hard on this, and made the change intentionally. But when even GNOME and MacOS (supposedly, according to others in here) has a feature and you're removing it from KDE of all places, you need to rethink your objectives for a user interface. I would never expect this type of feature removal to happen in KDE.

This might be considered another bug, but another issue with this redesign is that the 'remove' button only appears when you hover the mouse over it. So when you're removing a bunch of them at once, you can't keep your mouse still and keep clicking, as the 'hover' event doesn't seem to fire until you've clicked once or jitter the mouse a bit.

I don't see any reason for the buttons to hide themselves. It's not friendly for touch screens, as you don't know where to touch. It's not friendly for mice, as you don't know where to hover your mouse until you try to. When you do hover over an entry, it looks weird for only one of them to have a button and the rest not to.

The fact that they highlight when you hover, and then change color when you click, makes it seem like SOMEthing should happen when you click... But nothing does. Clicking an entry does not result in any action being performed. You can't even select them, as they're not selectable items.

--------------------

It might be my headache talking (not related to this; I've had this headache for a while), or I might just be resistant to change. I'm sorry if I sound overly harsh, I really don't mean to.

I just don't understand the purpose behind the redesign, and every time I look at any of it to see if there's a tiny bit of, "Oh, well at least that's nicer than before," I just find more things I disagree with (or perhaps am just not used to? Like I say, I maybe the headache is talking).

Totally agreed!

Now there's no need to hover for buttons are always there but there is no option to enable/disable a startup entry. Please readd it. Thank you :)

(In reply to Nick Stefanov from comment #18)
> Plasma 5.21.3 - still no option to enable/disable startup entries. Why you broke it when it used to work fine? Now it's ugly and inconvenient. Is this the purpose? To make Plasma inconvenient? After this stupid change there's no other DE with such awkward start up settings at all. Kudos to the dead head dev who made it for the Golden Raspberry award.

I don't think it's a good idea to be hostile toward the developer responsible, especially since they're also the one assigned to fix this bug. Don't give them more reasons to want to avoid working on it or having anything to do with it.

That said, I know that the dev made this choice deliberately, and I'm not sure why they're also assigned to change it. That's a conflict of interest (albeit a relatively minor one) - they might just want the change to persist, even though everyone else doesn't want it to persist, so all they have to do to get their way is to literally do nothing.

Perhaps someone else should be assigned to fix this bug?

(In reply to Nate Graham from comment #6)
> User feedback has spoken lol. IIRC even macOS has the ability to both disable and delete autostart entries. :)

Since [Xuetian Weng's merge request][mr] would indirectly fix this, maybe have him assigned to this bug report.

[mr]: https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/253

The open merge request needs for the submitter to continue work on it. At this point is seems like there is a path forward, and the work just needs to be completed. I've pinged the submitter. Hopefully they can continue the work.

The MR is unrelated to this bug report. This report is about disabling entries as opposed to removing them, the MR is about controlling the system-wide autostart

The correct bug for that MR is https://bugs.kde.org/show_bug.cgi?id=428094

(In reply to Nicolas Fella from comment #21)
> The MR is unrelated to this bug report. This report is about disabling
> entries as opposed to removing them, the MR is about controlling the
> system-wide autostart

I think you've misunderstood something fundamental about both bugs. The way that system-level autostarts are controlled, is by copying them into the user-specific autostart folder and then setting them to disabled.

In other words, for one to be implemented, you have to implement both. Or rather, if you fix *this* bug, both bugs become fixed automatically. That's why so many people were upset about this change, because it used to be possible to control system-level autostart entries with the GUI (once they're copied over to the user's home directory), but that is no longer possible because of your change.

Nick, do you think that these comments are making people more like to want to work on it?

In fact, they're more likely to make someone think "man, if I try to work on this, I'll have to come into contact with that Nick Stefanov jerk. I think I'll do something else."

If you actually care about this getting done, your nagging and pestering is making it LESS LIKELY, not MORE LIKELY. If you keep it up, my conclusion will be that you don't actually care about this feature working, and are instead simply looking for an outlet for your poorly-handled emotions.

So. Stop it. This is a formal warning.

Issue not fixed; re-opening. Please don't destroy things and make extra work for other people if you can't control your own emotions.

*** This bug has been marked as a duplicate of bug 274920 ***