btw. If you like me, I could to the same for the logout dialog. :)

Cool, I hardly ever use shutdown, maybe a couple of times a year for hardware cleaning maintenance.
99.99% it just a restart for new kernel or driver, once or twice a week.

I've sneaked in another commit, which is strictly speaking not related.

It marks restart as destructive, too. See the commit message for the rationale

Actually, I'd even be tempted to also mark suspend/hibernate as such... if you'd agree, just tell me and I'll update the commit to include them, too.

Cool, I hardly ever use shutdown, maybe a couple of times a year for hardware cleaning maintenance.
99.99% it just a restart for new kernel or driver, once or twice a week.

So that means.... you approve of this?
[Edit: I oversaw the "cool".]

I personally mostly use only hibernate (and restart in case of new kernels).

We could also export this in the control centre if desired... though I'd be happy for a pointer where this should be done.

But actually it might be a bit more difficult to get that in GUI form, given that it's an "arbitrary" string.

Cool, I hardly ever use shutdown, maybe a couple of times a year for hardware cleaning maintenance.
99.99% it just a restart for new kernel or driver, once or twice a week.

So that means.... you approve of this? [Edit: I oversaw the "cool".]

I personally mostly use only hibernate (and restart in case of new kernels).

All my PC's are serving something, so run 24/7

Well... the better if it doesn't just help me :-)

Would be great if you could review, and if good, merge it.

What about applet Exit@claudiux? You can configure shortcuts.

What about applet Exit@claudiux? You can configure shortcuts.

Uhm. Well I don't really think what I want is shortcuts, but really just which button is selected per default when going to te shutdown dialog.

Also, my commit doesn't add some completely new functionality to cinnamon (the shutdown dialog is already there and definitely a core part of it, in the sense that it's important functionality).

I don't think one should need to replace already existing code with an add-on, if one can rather easily achieve the same in the already existing code.

And in general (that is: not particular to Cinnamon, but to any software that has add-ons/extensions/plug-ins like from Firefox, Libreoffice, etc-) and not with respect to Exit@claudiux...

IMO, add-ons/extensions/plug-ins while having some advantages also nearly always come with a great deal of disadvantages - unless perhaps when they're completely maintained/developed/delivered by upstream and considered core of the code:

1. Security

   • When add-ons are developed 3rd-party and basically everyone can submit any of them... they're security-wise a nightmare. They can more or less execute arbitrary code and merely collecting them at some vendor site like addons.mozilla.org doesn't make them any less a security risk but give even a false sense of security.
     So I'd say it's rather a questionable decision if one simply downloads and executes such codes... and in some environments (work, research, etc. it may even be simply forbidden).
   • Even if one assumes a certain add-on is trustworthy and doesn't contain any malicious code, downloading code from remote in a safe manner is actually not so easy.
     There are things like downgrading and blocking attacks (which an MitM could use to e.g. prevent security updates to the downloaded code to reach the user).
     Often code is downloaded only via https and not further secured by some signatures. https in turn is pretty weak. There are typically around 150 root CAs which one blindly trusts, many of them under control of totalitarian countries and many of them having already been caught forging certs. Not to talk about thousands or tens of thousands intermediate CAs. All of which can then basically sign and fake everything at will.
   • Add-ons (unless packaged by the distribution, which is of course fine again) circumvent any security support, they're simply private per-user code which no one but the user has control of. They also outplay monitoring tools (think of things like check_apt which would report that software is outdated).
   • The model that software is distributed indirectly (by the Linux distribution) has also further security advantages: all users are guaranteed to have the exactly the same software (which makes it more likely that malicious code gets found). If one individually downloads code from some 3rd party, if that has malicious intent, they might give the evil version just selectively to some targets.

2. getting the code
   In particular if the above is a concern, and one doesn't just download and install code from some 3rd party but wants it to be packaged for ones distribution, the form of add-ons (except those that are core part of the main software like Window List in Cinnamon) makes it much more difficult that the user actually gets some add-on.
   Take Debian... as far as I can see only one 3rd party add-on is packaged at all (workrave-cinnamon). Even for other projects it's not much better. GNOME Shell has perhaps 20... Firefox also a few, but they've even dropped "core" add-ons like noscript.
   Till date I still can't use GPaste with Cinnamon, as it's Cinnamon applet hasn't been packaged for Debian. For GNOME shell it works out-of-the-box, as the applet is shipped by upstream GPaste (would he do the same for the Cinnamon applet, it would also be packaged already).

3. choosing the plugin
   Last time I've looked, which is admittedly already some years ago... there were like 10 or so applets for Cinnamon that all did system monitoring (like drawing a nice graph for CPU/IO/Net/Mem usage and temperature bars in the panel.
   All of them were in various shapes, none of them seemed really to be able to do "all" the typically desired functionality.

4. maintenance/lifetime of the plugin
   When using only the core plugins shipped by cinnamon upstream (like Window List, Workspace Switcher, etc.) one can be more or less sure that they'll just work. Cinnamon devs probably have an eye one them when changing the code.
   But any 3rd party plugin might basically stop working with any upgrade or become unmaintained at any point in time.

Long story short... I can of course see why add-ons have some advantages (in particularly also removing some development burden from upstream). But I also think they have disadvantages.

IMO their main use case is for functionality that is both ... not of general interest (like if you wanted a plugin that lets stickmen walk on top of your windows as a graphical effect... or I don't know... let's you "lock" windows via a passphrase) and that would require massive amounts of additional code.

Here the changes in code are simple and don't even add new code, but merely makes existing one configurable, which is why I would hope it will be - despite Exit@claudiux - merged. :-)

Cheers and have a nice weekend.

PS: Obviously I'd also hope that Cinnamon would make proper GPaste integration (isn't clipboard management something that neraly everyone wants?) as well as some system monitor applet part of the core

Add-ons are good and pretty much required for a software like Cinnamon, and they rightfully get the same power any software would get, you need to stop expecting that add-ons are some magically sandboxed thing

IMO, add-ons/extensions/plug-ins while having some advantages also nearly always come with a great deal of disadvantages - unless perhaps when they're completely maintained/developed/delivered by upstream and considered core of the code:

Cinnamon Spices are managed by the same upstream in the same GitHub organization. All contributed code is reviewed and the pipeline from submission to delivery is automated. The Spices infrastructure is also centrally managed. This is not Firefox or LibreOffice. The ecosystem is also built directly into Cinnamon and accessible via the system menus. Let's avoid assumptions here without facts. Many of the contributors to core also contribute Spices. The core feature that Spices offer is the option of immediacy for distribution rather than waiting for each new release or having to compile from source to get the latest updates.

TL/DR:

Cinnamon Spices are managed by the same upstream in the same GitHub organization. All contributed code is reviewed and the pipeline from submission to delivery is automated. The Spices infrastructure is also centrally managed. This is not Firefox or LibreOffice. The ecosystem is also built directly into Cinnamon and accessible via the system menus. Let's avoid assumptions here without facts. Many of the contributors to core also contribute Spices. The core feature that Spices offer is the option of immediacy for distribution rather than waiting for each new release or having to compile from source to get the latest updates.

Well that's good... but as laid out above, even then, the major issues remain:

• add-ons still effectively circumvents the security support of the distribution, cause they're individually installed by users
  This may be fine if you have only one laptop to administer, but a problem if you have thousands at e.g. a university campus, which is why admins often simply disable any such per-user code downloads.
  
  And even if you do it just on your own computer... is there a mechanism in place that will tell you when a - perhaps critical - upgrade is available, or when a plugin has been discontinued and thus receives no longer any upgrades?
• it's still problematic to get them packaged... I mean not per se, but simply no-one is doing it and looking at e.g. cinnamon-spices, where all is in one big repo, that would be a e.g. rather difficult task if one follows the usual Debian ways (because one would typically have to package all of them).
  so as said above... one must resort to individual downloads with the implied issues (e.g. having to trust untrustworthy CA/B forum certs).

Anyway... I merely made the above commits as I personally wanted that feature and then thought I'd do it properly in order to give something back (to Cinnamon... and the community).

Since the commits are pretty simply and non-intrusive, I though that would be a no-brainer and no lead to some extensive discussion where one needs to justify why a good feature should be merged.

I mean I would have expected this from GNOME, where one only get's a new feature merged if at the same time one removes at least 5 others and breaks at least one major functionality.

It's you guy’s project... take the commits if you want them... and if not.. no problem either. 😃

And even if you do it just on your own computer... is there a mechanism in place that will tell you when a - perhaps critical - upgrade is available, or when a plugin has been discontinued and thus receives no longer any upgrades?

There are Spices that offer this functionality and Mint ships with software that notifies on available updates as well. The threat factor is minimized though: Spices do not run with elevated permissions by default and anything that does require it requests with a user-visible prompt.

it's still problematic to get them packaged... I mean not per se, but simply no-one is doing it and looking at e.g. cinnamon-spices, where all is in one big repo, that would be a e.g. rather difficult task if one follows the usual Debian ways (because one would typically have to package all of them).

It's a different distribution model. Again, it is maintained and reviewed, no different than the core.

so as said above... one must resort to individual downloads with the implied issues (e.g. having to trust untrustworthy CA/B forum certs).

Again, this functionality is directly built into Cinnamon. It's all one ecosystem.

I mean I would have expected this from GNOME, where one only get's a new feature merged if at the same time one removes at least 5 others and breaks at least one major functionality.

I took issue with some of the assumptions you made and continue to make. I haven't reviewed the pull request. Please don't make a habit of launching into assumptions of things you don't understand. If you have the time, I would encourage you to look into the infrastructure so that you can correct some of your assumptions. There is code in core and in the individual Spices repositories. It's very hard to contribute effectively from an uninformed position. 😄

Here's my opinion.

First of all, thank you. It might sound silly, but that's the most important thing here. Thanks for making a PR. It's always appreciated, by me anyway and I think by most people. No matter what the change implements and how it implements it, I'm glad people take the time to contribute. We don't always have the resources to answer quickly, to give proper feedback and to make sure people are welcome and treated nicely when they try to help. At least I can say this, I really appreciate it.

Second, although Rick is right in what he says, I do see a difference between core and extensions. At least when it comes to users, some of them don't add extensions, won't add extensions, it's not part of the core experience obviously.

Third, we do suffer from configuration overkill and GNOME is right in trying to minimize configuration. It's also much easier not to accept unnecessary configuration options than to remove them once they've been accepted. GNOME is brutal when it comes to that, we're not. I'm about to start working on the new menu, I can't just make it better, faster.. I also need to make sure I support all the configuration that crept into it until now. It's a bit like technical debt in a way, it gets in the way of fixing bugs, redesigns and improvements.

Now when it comes to this PR. I think this is overkill. Not just because most people don't need it, but also because people who do need a quick way to perform a non-default endsession action can do it with a keyboard shortcut. For this reason I'd argue it shouldn't go in.

From a technical point of view:

• Not exposing a niche feature to UI settings can be a good idea, but it makes the feature even more niche as a result.
• Since the endsession dialog is now part of Cinnamon and not CSM, the gsettings schema should be in cinnamon directly, not CSM.
• I understand the logic of actions being unavailable but I think that's perfectionist. Tuning a default action is arguably going a little bit far already... implementing a preference in what to do in cases where the tuned action is unavailable, that's going way too far imo. Shutdown has always been default. You're introducing a configuration option, keep it simple. There's no reason for the selected action not to be available. If it is, just default back to shutdown?
• Restart is just as "destructive" as Shutdown, I agree with this. But I don't think suggested-action and destructive-actions are designed only for that. They're also associated with default actions. I can't think of an example where we have multiple colored action buttons in the same dialog.

@leigh123linux mentioned to me that we didn't have shortcuts for Shutdown/Restart.

The Shutdown and Logout shortcuts don't shutdown or logout, they pop up the endsession dialogs. They should be rephrased to be more explicit.

I think we should also expose actual actions for shutdown and restart.

Third, we do suffer from configuration overkill and GNOME is right in trying to minimize configuration.

Well, it's just my personal opinion, but OTOH I wouldn't be surprised if quite some users particularly of Cinnamon would share it.

GNOME is not right in doing so.

The desktop environment is the interface between the user and the computer, and as such it should be as configurable as reasonably possible.

Back then when they've started to remove more and more features and to impose GNOME Shell and paradigms , more and more people started to dislike that - and I don't think this was simply because people would have rejected it without even trying, but simply because one cannot professionally work with it.

They still seem to believe that DEs for computers should become like smartphone UIs, not realising that the two are completely different things.

And weren't these points amongst if not the main reasons for Cinnamon to be even started?

No offence meant, I merely say this with my users (who uses Cinnamon basically since shortly after GNOME shell came and since it got packaged for Debian) hat on:

But since a while I feel a bit like back then,... like on every mayor update kinda fearing whether something which I've really grown quite dependent upon (e.g. in my case that I can set a shortcut on Super_L alone to start a terminal) might have disappeared, not even hoping anymore that annoying issues (in my case e.g. from "worst" the less 4312, 12664, 4386, 12509, 12510, 12127) get fixed. And issues like 12636 make wonder whether Cinnamon might end up the same road than GNOME did.

(Having intentionally not "liked" the issues via # because they're not really related to this one.)

And yes, it's clear that more functionality makes maintenance more difficult, and that you also have to live with some changes you cannot really influence if you want to keep with the base libs.

people who do need a quick way to perform a non-default endsession action can do it with a keyboard shortcut.

That's the only kind of reason I'd say actually speaks against... but ... ;-)

• While most of the time I do e.g. want to default to hibernate, every know and then I don't (e.g. when restarting because of a kernel update, or when just wanting to suspend because I take a power nap and resuming takes quite a while (system with full disk encryption).
  So simply overriding the power button with the Hibernate shortcut (which luckily is still possible) has also it's drawbacks.
• And if that were ever to go away (and one would have to use a custom shortcut) it wouldn't be clear if e.g. things like screen locking would still be performed (actually I wouldn't be sure with the Hibernate shortcut right now, and would need to try it out first).
  Simply changing the default however, makes it clear that it's just the normal thing, merely a different default... and should you ever add further functionality to that, a user can be sure that he'd automatically inherit it.

Not exposing a niche feature to UI settings can be a good idea, but it makes the feature even more niche as a result.

Well the main reason I didn't do it is, because I'm not really good in GUI programming ^^ ... and since I thought it would be better to allow a list of defaults, one would need some GUI widget where one can e.g. drag&drop elements to some order but also completely disable them?

I think exposing stuff via dconf only is a nice way to let power users customise things to their needs and even give non-power users the chance to find it should they really want to.

Since the endsession dialog is now part of Cinnamon and not CSM, the gsettings schema should be in cinnamon directly, not CSM.

I'd agree, I merely choose CSM, because the first setting that seemed directly related to the shutdown dialog was quit-time-delay, so I figured for some reason it was meant to be there.

I'd update my PR but I guess looking at it's discussion this would be pointless.

I understand the logic of actions being unavailable but I think that's perfectionist. Tuning a default action is arguably going a little bit far already... implementing a preference in what to do in cases where the tuned action is unavailable, that's going way too far imo. Shutdown has always been default. You're introducing a configuration option, keep it simple. There's no reason for the selected action not to be available. If it is, just default back to shutdown?

Originally I even had planned to only make one default (which would have made it even more simpler), but then I realised that it actually may be more common that an option isn't available than one might think.

It's not just that one might have on computer which supports suspend or has a swap partition and another which doesn't (which would make it pretty static an the list of defaults arguably overkill).

Some 1-2 years ago I learned the hard way, that Cinnamon get's the info which methods are available from systemd (or logind, IIRC)... and that started claiming that hibernate wasn't available.

Reason was that it started to check whether swap was actually enable, any my setup (all done via systemd units) only enables it when I actually hibernate and disables it again after resume). (For the records, one can solve this via an env var SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1). One could even extend this setup (since I use a swap file), that the swap is deleted if no needed and one could use it's space for normal data (and I do know some folks who do that) - making it (i.e. whether or not hibernate is actually available) truly dynamic.

If it is, just default back to shutdown?

Well rather to cancel, IMO.

But I ahad also thought you wouldn't accept to simply change the default from shutdown to cancel (which would have been my first simplistic approach to not accidentally shut down anymore ;-) ).

Restart is just as "destructive" as Shutdown, I agree with this. But I don't think suggested-action and destructive-actions are designed only for that. They're also associated with default actions. I can't think of an example where we have multiple colored action buttons in the same dialog.

Well... I also only learned during this little exercise, that the red colour de jure doesn't mean default ;-) ... but it actually seems there is a blueish colour which is chosen for the default, when that's not also destructive.

In principle the idea of having two colours would be nice... but I guess users would only realise the meaning if this would be used more broadly.

Again, I could change the commits to always make the default one destructive (and restart not in addition), but seems pointless now.

@leigh123linux mentioned to me that we didn't have shortcuts for Shutdown/Restart.

And "Shut down" is a bit of a misnomer, because it actually just displays the dialog that lets you choose.

Thanks for making a PR. It's always appreciated, by me anyway and I think by most people.

Well thanks for the nice words. Likewise I appreciate the work you guys do which gives me a pretty good desktop, though I would of course have some wishes for further customisation and things like GPaste integration.

Still, should I now ever cross my lazyness threshold again and would want to contribute something, I'd probably feel the need to get green-lit first, whether a new functionality would be even accepted.

IMO, the whole thing still looks like a pretty minor change... few lines of code that are basically self contained an affect no other parts of Cinnamon (with the gsetting placement being explained above). It's only more commits as I wanted to make it more easily reviewable.

I kinda expected that any review discussions might be about my JS coding being 💩😅 ... not about whether the feature itself is acceptable.

Anyway... far too much discussion about not much. I guess it's best if I simply patch my JS file on every upgrade to default to hibernate and this PR being rejected whatsoever.

Cheers,
Chris.

PS:

I think we should also expose actual actions for shutdown and restart.

Overkill. 😘 (sorry, couldn't resist 😇)

Overkill. 😘 (sorry, couldn't resist 😇)

😂

There is something being completely left out of this discussion. An option like this is probably pointing to a flaw in the design. Currently when you get the end session dialog it can contain about 6 actions depending on your setup. A proper implementation would be to have it only show two at a time. The action you want to perform and cancel. For example, when you call this, it should be to shutdown, restart, hibernate, etc. The menu, user applet, status applet, or wherever you shut down from would give those options like so:

Then the dialog would only open with two actions. The chosen action and cancel. That cleans up the dialog and removes all need for this. ESC closes the dialog and enter activates the action. This just requires some rework in Cinnamon's backend to achieve.

A proper implementation would be to have it only show two at a time. The action you want to perform and cancel. For example, when you call this, it should be to shutdown, restart, hibernate, etc. The menu, user applet, status applet, or wherever you shut down from would give those options like so:

I think this shows already why making things quite configurable has also advantages: everyone has personal tastes that fit his uses cases better or worse :-)

I for example rarely select shutdown/restart/hibernate/etc. via the menu. I simply press my powerbutton and am quite happy with the (current) dialog there giving me the choice of how I want to end the session.

If this were to be changed to be separate dialogs with only the action (or an "ok") and cancel, I'd need n different keyboard shortcuts to get to them (and those I'd use rarely I'd likely forget).

To make things even more convoluted O:-) ... having Switch User and Logout in their own dialog, makes sense when one looks at it from the PoV of the system being shut down) or at least suspended.

But from the sessions PoV, at least logout is also an end of the session, just like restart, shutdown, etc. - one could even argue that hibernate/suspend are not really ending the session. ;-)