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
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 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
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.
I do find it rather surprising that your friend can find the 'shutdown' button but not the 'lock' button above it.
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 (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:
do_desktop_logout(){
if [[ -n "$EROOT" ]] ; then
eesh exit
else
if [[ -n "$E_START" ]] ; then
enlightenment_remove -exit
fi
fi
}
i wrote enlightenment_remoVe instead of enlightenment_remoTe
yeah exactly, that's what the user is meant to do from the menus, isn't? mmh... maybe a good thing to ask an extra question to know if wants to logout or shutdown or suspend... ok changed
mmh... no 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 1.2.3.1, 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 :
if buster is 1.2.3 and there's a buster hook 1.2.3.1, use it
if bullseye is 1.2.3 (updated from buster) and there's a buster hook 1.2.3.1, use it
if bullseye is 2.2.3 (an officially new elive version) and there's a buster hook 1.2.3.1, don't use it (its older)
if bullseye is 2.2.3 (an officially new elive version) and there's a buster hook 1.2.3.2, don't use it (its older)
if buster is 1.2.3 and there's a bullseye hook 2.2.3.1, 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 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
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 Dev ? can be good to have this topic entirely separated for pythonistas
note2: looks like a nice replacement of the ctrl-alt-del tool 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
ah, good to know, I was thinking should be probably that
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
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'.
, so betatesters of all these options are welcome!
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:
