You are not logged in.
But what about running BL in a VM? If I put my Host PC to Sleep or perhaps hibernate, (or just closing the laptop lid) how will that effect the "test" to check for the functionality of the buttons?
No, it will not.
If you can't sit by a cozy fire with your code in hand enjoying its simplicity and clarity, it needs more work. --Carlos Torres
Offline
That said, I agree about not showing users non-functional options. (if they prove to be non-functional)
Which means the program needs to test each option before it shows the gui. It is possible of course...
I assumed that since you were offering that option in the OP:
When the swap space is not sufficient to hibernate, choose one of the options below:
1. I don't want to see the hibernate button.
that such testing was indeed possible. (You also mentioned various tests in the preceeding GitHub conversation.)
but it means checking if a feature will work before you know which feature the user intends to use. Testing all buttons functionality while only one button can be clicked. And this testing has be done every time the bl-exit screen is shown.
Sure. But how many milliseconds will that actually take in practice? And how often is the bl-exit screen brought up?
There is also the inhibitor locks to take into account.
Which allows you to inhibit system reboot while for instance your system backup is running.
Do you want bl-exit not to show any of the buttons when an inhibitor has been taken?
in that particular case a popup warning might be more appropriate.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
First of all a big THANK YOU to all who have taken the time to respond to
this questionnaire.
I am thinking of creating a bl-exit.ini config file for the bl-exit script, so that
most of the suggested options can be accommodated for.
The bl-exit script should work with default options in the absence of a config file.
It will be possible to specify specific behaviour per button.
In the absence of a specific button behaviour, the script will fall back
to a defined 'default' behaviour.
[default] - default behaviour when no [logout, suspend, ...] section is present
show = <never|always|ifavailable>
onError = <visual|stderr>
visual: show Pop-up window explaining where things want wrong
stderr: just write a message to stderr. No visual feedback.
[hibernate] - behaviour for a specific button
show = <never|always|ifavailable>
where never : never show button, never test if the action is available
always : always show button - don't test if the action is available or not
ifavailable: test CanHibernate before showing the button
if CanHibernate = "yes"
then
show the clickable button
else
show greyed out button
Working with a config file makes it possible to create the configuration file
using questions and answers while running the 'bl-welcome' script.
I plan to start coding this in a couple of says.
Should you find something missing in this schema, please let me know.
THANK YOU AGAIN.
Offline
Nice one, thanks for taking the time to do this!
Lenovo IdeaPad Yoga 13 | BunsenLabs Hydrogen (x64)
Intel Core i7-3537U | Intel HD4000 | 8GB DDR3 | 256GB SSD
Offline
Awesome. Rock me, Dr. Xaos.
No, he can't sleep on the floor. What do you think I'm yelling for?!!!
Offline
Pretty cool Xaos. Correct me if I'm wrong, bl-exit is python no? Is your .ini config going to be python as well or bash?
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
Wait... Maybe I'm as thick as a brick here.... but when I'm at the lightdm the power option at the default top right (as shown in screen shot below) does indeed have a hibernate function that works... How does it handle this same issue of swap space? Would it be easier to just "port" the lightdm hibernate to our own usage?
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
I am thinking of creating a bl-exit.ini config file for the bl-exit script, so that
most of the suggested options can be accommodated for.The bl-exit script should work with default options in the absence of a config file.
Sounds good Doc!
Working with a config file makes it possible to create the configuration file
using questions and answers while running the 'bl-welcome' script.
There have been a number of suggestions recently for more options to be added to the welcome script, but I'm wondering just how much more stuff needs to go there. It could end up as a huge sequence of questions for new users to work through, a lot of them about things they don't care about so much...
My concept of bl-welcome:
*) Things that need fixing right away for any users to get a good experience.
*) Things that are tricky or not obvious to new users, but important.
*) Things that are just a PITA to do manually, but easily automated.
I wonder if editing bl-exit's config file might be something that could be left to the user, like a lot of other text files in BL?
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
....
I wonder if editing bl-exit's config file might be something that could be left to the user, like a lot of other text files in BL?
Yes - let's not let the welcome script get too bloated
I imagine we will get round to producing a config HowTo for new users which could include things like this.
Be Excellent to Each Other...
The Bunsenlabs Lithium Desktop » Here
FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt «» BunsenLabs on DeviantArt
Offline
@Horizon-Brave
Pretty cool Xaos. Correct me if I'm wrong, bl-exit is python no? Is your .ini config going to be python as well or bash?
Yes, bl-exit is python2.
No, the config will be a text file with the .ini format (originally from windows)
But Python2 has modules to handle such files.
See ConfigParser
Wait... Maybe I'm as thick as a brick here.... but when I'm at the lightdm the power option at the default top right (as shown in screen shot below) does indeed have a hibernate function that works... How does it handle this same issue of swap space? Would it be easier to just "port" the lightdm hibernate to our own usage?
Lightdm works by calling the same dbus calls to login1.Manager that I will be using.
lightdm has the calls implemented in C. I will be using Python.
Problem with the lightdm implementation is that you need to be at the login screen to be able to suspend, hibernate ...
So you first have to log out of your session to be able to hibernate, while one of the attractions of hibernate is to return to your session, with all of your applications as they were before the hibernate.
Or am I missing something?
Is it possible to get to the lightdm login screen without first logging out of your session?
@johnraff & damo
Using the bl-welcome script to customize the bl-exit configuration was not more than suggesting a possibilty that using a config file provides.
Offline
Problem with the lightdm implementation is that you need to be at the login screen to be able to suspend, hibernate ...
So you first have to log out of your session to be able to hibernate, while one of the attractions of hibernate is to return to your session, with all of your applications as they were before the hibernate.Or am I missing something?
Is it possible to get to the lightdm login screen without first logging out of your session?
.
Well, if you right click on the desktop, and click lockscreen, it'll send you to the lightdm screen. From there you can click on the power button option in the top right, and choose hibernate, or whatever other power mode you wanted. When you log back in, your session is how you left it.
Atleast on my machine, when I'm logged into a session, I right click on the desktop, selecting lockscreen brings up lightdm (called by lightlocker I'm assuming). When I logged back in before even choosing one of the power options, my session was still active.
BUT! This is all dependent on the person using lightdm/lightlocker, which i'm sure not everyone does, so I sort of concede my own point... B.L probably needs it's own "in desktop" hibernate function since not everyone will be using lightdm/lightlocker.
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
Actually, one does not need to log out to hibernate using lightdm -- light-locker gives the user the option to hibernate as well.
Offline
^and ^^
Thanks. I was missing this.
Must be because I never use the openbox main menu.
Offline
^and ^^
Thanks. I was missing this.
Must be because I never use the openbox main menu.
heh. Also, I wanted to bring this up earlier, but I didn't want to diverge the conversation... As of now if you run the bl-exit script from the command line, (perhaps you're not using openbox specifically) it runs the script and you get the options to power off the system.
But if you run this command from a completely non-graphical target (ctrl + alt + f2 for example) it completely crashes and gives a segmentation fault error, because there is no graphical target/session. Should there be a better error message displayed or handled for this? Attached below is a screenshot of the error you get when you try the bl-exit command from a pure login shell and not from any x11 session:
This is probably a non-issue, but something to think about for later perhaps, just so a user won't be greeted with an ugly error message!
"I have not failed, I have found 10,000 ways that will not work" -Edison
Offline
^Good catch.
As bl-exit is now, if it is run without arguments, it is presumed to run in a graphical environment.
It would indeed be better to check whether that presumption can be proven true, and exit with an error message if it is not true.
Thank you for reporting this.
Edit:
Testing if the DISPLAY environment variable is set should be sufficient, I think.
Offline
Somebody mentioned that they cannot possibly imagine this to be a useful functionality on desktop machines. It is very important if one wants to preserve the current state AND wants to make sure it survives a power loss.
I personally have the suspend button call hybrid-suspend on desktop machines so even if a powerloss happens, they would not lose the state.
Offline
(Suspend/Hibernate) It is very important if one wants to preserve the current state AND wants to make sure it survives a power loss.
Good point. Even if power cuts might be rare where you live, there's always the possibility of a plug being pulled out. And desktops don't have batteries.
...elevator in the Brain Hotel, broken down but just as well...
( a boring Japan blog (currently paused), now on Bluesky, there's also some GitStuff )
Offline
For anyone interested, I have a working version of the 'configurable bl-exit' script available on github.
Apparently nothing has changed if you run the script without configuration file. You get the same buttons as the previous version.
Under the hood these changes were made:
1. the script can be launched from a console. You need to specify an action.
For instance:
bl-exit --suspend
2. You can now configure it to your taste using a config file:
The script searches for its config file in (in this order. Uses first one if it exists)
1. $XDG_CONFIG_HOME/bl-exit/bl-exitrc
2. $HOME/.config/bl-exit/bl-exitrc
The config script has the ini format.
All sections, options and values shouldbe in lower case.
The 'show' option has as possible values one of:
1. always
2. never
3. maybe
Values always and never should be clear for everyone.
'maybe' means that the script will check if the corrensponding action is available.
If it is available, the corresponding button is shown.
If it is not available the button is shown, but is greyed out and not clickable.
The option 'onerror' can take one of the values
1. novisual
2. visual
This controls whether on error a message is logged to $HOME/.xsession-errors or a popup screen is shown with some explanation of what happened.
For example if you want the 'hibernate' button to show up if it is available, and see visual feedback on error:
[hibernate]
show = maybe
onerror = visual
Each of the options is optional.
There are 3 levels that determine which options apply:
By default - hardcoded in the script - the cancel, logout, suspend, reboot and poweroff buttons are shown and onerror is set to novisual.
On the second level you can add a 'default' section. These options apply to all buttons. They override the hardcoded options. But they can in their turn be overridden by a button specific option. This isecion is optional.
The third level is a button specific section, one of
[logout]
[suspend]
[hibernate]
[hybridsleep]
[reboot]
[poweroff]
to control the options per button.
Each of these sections is optional.
Left to do:
1. Examine use of --force from the command line
2. Add hybridsleep DONE
3. Examining behaviour when inhibitors are active
4. Eventually showing explanation when hovering over a greyed out button
5. ...
Any feedback is welcome.
Edit:
- changed path to config file (thanks damo)
Offline
Downloaded the zip, put bl-exit in ~/bin and added it to my OB Menu. It will not start, but my old s11-exit works fine
<item label="Debrief">
<action name="Execute">
<command>s11-exit</command>
</action>
</item>
<item label="test">
<action name="Execute">
<command>bl-exit</command>
</action>
</item>
/home/sector11/bin/bl-exit
/home/sector11/bin/s11-exit
So I tried a copy in /usr/bin/ - no go either.
EDIT: I should add that they had proper permissions to run as a file.
Last edited by Sector11 (2016-04-13 12:24:25)
Debian 12 Beardog, SoxDog and still a Conky 1.9er
Offline
Paste output of
which -a bl-exit
please.
Offline