Introducing ctrl + alt + del

Almost everybody knows Ctrl + Alt + Delete, many new users wants to press these keys for specific expected things and "have nothing", so I just implemented it in Elive :slight_smile:

Of course is not an app to show in the menus but it will be triggered with this combo

I made this feature after notice a friend shut down the computer because he left it for 30 minutes, i told him to better lock the desktop instead, and he told me didn't found the option (he used to trigger this combo to lock the desktop), so I thought it was good to have

But... of course, like always, Elive do it in a better way than in windoze :slight_smile: so it includes more features too, which are especially handy for that situation, which is when a user wants to do something and don't know how (ctrl+alt+supr) lol

There's a screenshot:


You will have it soon automatically installed from your elive-upgrader :slight_smile:


Huh? Ctrl+Alt+Delete always opened GNOME System Monitor for me.

"always" --> yeah because is a new feature :slight_smile:

now all packages are ready, run "elive-upgrader" and try again :happy:

note: none of the options have been tested because I was very confident they works :speak_no_evil:, so betatesters of all these options are welcome!

Me I'm still extremely happy with Ctrl+Altand Backspace to instantly kill (or crash) X11 and get a back into 'gdm' login screen and if needed into a TTY where the 'Ctrl+Alt+Delete' does work for a reboot.
Most modern keyboards don't have 'sysreq' anymore which was another way of a controlled shutdown, alas.
I do think this addition is a good option to have and certainly better than having 'nothing' for that '3 fingered salute'. Nice work. :+1:

I do find it rather surprising that your friend can find the 'shutdown' button but not the 'lock' button above it. :face_with_head_bandage:

  • Considering there are quite a few similarities to the 'logout' widget, wouldn't it be nicer (for E16) to use an enhanced 'eesh exit logout' for that, rather than using zenity?

Note that killing X11 is only recommended when it is literally blocked, to crash the desktop is dangerous for your user desktop configuration (it can become corrupted if you crash it), I was used of this combo in the past but only because E was stuck, this is not happening on e16 anymore :slight_smile: (or almost never)

he probably didn't read it, and just tried to lock "in the place where he knows the lock is supposed to be"

The combo offers a menu with many options, one of them are to logout, and yes using "eesh exit"

  • update: actually implemented from "elive-pm logout" as a wrapper which was already in the TODO list, the reason of that is to make a global command for logout that works on both e16 & e25, so:
    if [[ -n "$EROOT" ]] ; then
        eesh exit
        if [[ -n "$E_START" ]] ; then
            enlightenment_remove -exit

lol remove? i just found a bug...

1 Like

Wouldn't that be E17? :thinking:
I don't have Stable readily available here, so I can't check.

And do 'eesh exit logout' to bring up the menu else the user will literally be kicked out of the session straight away, no questions asked. :shocked:

3 posts were split to a new topic: Python-EFL application template

i wrote enlightenment_remoVe instead of enlightenment_remoTe :rofl:

yeah exactly, that's what the user is meant to do from the menus, isn't? :thinking: mmh... maybe a good thing to ask an extra question to know if wants to logout or shutdown or suspend... ok changed

mmh... no :slightly_frowning_face: bullseye uses a different directory tree for the hooks, since bullseye is not yet the "official" version of elive none of the hooks on elive-upgrader are included on it, this is for security and reliability purposes of course (each distro has its own line of hooks), -could- be possible in some way to include them but stills a difficult and unreliable thing, for example the hooks are run as:

brainstormed idea... * if your version of elive is 1.2.3 and there's a hook for, this hook is run, same for a next one as 1.2.4 found, but the ones like 1.2.1 are not because they are older than your own elive system (so already included) * different distro will have a different number since it follows a different development thread, bullseye on this case would be 1.2.3 or would be 2.2.3 ? (in your case there's no version, its only the previous 1.2.3 buster system upgraded)

On the other hand, stills a problem in a different way: elive-upgrader always requires packages updated, and they are not very updated in bullseye at the moment, so even if elive-upgrader includes the hooks, there's not the packages updated with these new features (will be in a next full bullseye rebuild)

On the other hand, i think it makes sense to :thinking: :

  • if buster is 1.2.3 and there's a buster hook, use it
  • if bullseye is 1.2.3 (updated from buster) and there's a buster hook, use it
  • if bullseye is 2.2.3 (an officially new elive version) and there's a buster hook, don't use it (its older)
  • if bullseye is 2.2.3 (an officially new elive version) and there's a buster hook, don't use it (its older)
  • if buster is 1.2.3 and there's a bullseye hook, don't use it (buster = older than bullseye which means incompatible, should have its own thread)
    • buster can have 1.2.4 and 1.2.5 builds, but never 2.2.4 or 2.2.5, so hooks from newer distro should never be run

mmmh... this sounds like a complex feature to implement in a reliable (stable) way :thinking: i will note it...

update: I tried to implement it and it would have worked (using buster hooks/updates on bullseye too), but it -could- lead to bugs in the future, the real problem is the focusing on buster while we should focus on bullseye (or more like, to want to have bullseye supported as an official system while the focus dev is on buster), in short, the correct way is to simply use buster (as an official version) and then update to bullseye when will be ready (and so, the updates on elive-upgrader will happen from there)

I hope to make the switch to bullseye soon!, but i still working on the website (announcement, emails fixing crons, etc..) so probably will happen after that (in any case, the next release should use bullseye)

not heavy so sounds good... i will need to include some "demo files" on the user's home so they can know they can do these things :slight_smile:

update: @triantares I installed python-efl in buster and didn't worked (in bullseye does?), not the example of your link and not the examples in /usr/share/doc/python-efl/examples/ from the python-efl-doc package too

note: @triantares can you move the python-efl topic (your 2 comments) to a new thread on #get-involved:dev ? can be good to have this topic entirely separated for pythonistas :slight_smile:

note2: looks like a nice replacement of the ctrl-alt-del tool :slight_smile: if you really want to develop / play with it we can open a specific thread about it too, for example it will require to use gettext so that it can be translatable in other languages and the packager should correctly deal with it to include it on eltrans :thinking:

Ah, on Buster you'll have to point it to 'python3' because it still has 'python2" as the default.

Moved the other posts to #get-involved:dev so there's more of a reply reply there.

Note: Maybe we should set 'python3' as the default on Buster too if we're to keep using that base for a longer period. :thinking:
Python2 is really 'passé'.

ah, good to know, I was thinking should be probably that :slight_smile:

nah... buster is also passé lol (and doing such thing may lead to new bugs)
let's focus on the switch to bullseye instead of spending energy on improving buster :slight_smile:

Yeah, moving to Bullseye (with a full switch to python3) is the best way to go, I agree.
On top it's not that hard to set python3 as the default on Buster.

Avoiding system issues (I doubt there are any left, but still) this can simply be done on a 'per user' basis by appending an alias to point to the python3 version in '~.bashrc' with:
'echo "alias python=python3" >> ~/.bashrc'.