You are not logged in.

#126 2019-03-15 01:36:45

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: bl-exit replacement suggestions

So with regards to the above, some guidance with regards to what would be generally preferred would be appreciated.


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#127 2019-03-15 02:35:06

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,957
Website

Re: bl-exit replacement suggestions

Hi B_B your work on this necessary item on the Lithium TODO list has been most appreciated! To be honest, up till now I've been happy to leave all the heavy lifting to you, and most of the testing to @hhh and @damo, as this allowed me to think about some other things. Also, while improvements seemed to be coming in every day I thought I might wait till the code had settled down a bit before trying it out. That time might now have arrived though, and I will migrate bl-exit on my Buster VM to your version soon, and give my feedback FWIW.

Bearded_Blunder wrote:

...if it's my loginctl test or the long-string-of-goods-wagons I'm checking from @hhh as to which is the cause of the delay in their case, I'm certainly not wedded to any particular test with regards to if an X or Wayland session is running...

Wayland? BL is not going to be using Wayland on Buster or probably even Bullseye, so for our immediate needs a test for X would be enough. Of course if you want to future-proof your code now that's fine, as long as it doesn't hugely complicate things. And as long as the dbus calls will continue to work on Wayland anyway...

I've also looked into trying to make a reduction in arguments possible, and more options possible as bl-exit.conf options, for example enabling or disabling e.g cancel (use esc or alt+f4 buttons instead) and or sleep/lock buttons config.file options, though doing so at *my level* of skills with bash/yad might involve increased code duplication.

My personal opinion here would be to do all the formatting choices via config files, leaving options only for the CLI shutdown/reboot/etc direct calls. I doubt if users would really need to be able to switch vertical/horizontal, or whether to include a certain button or not, on a regular basis, and a one-off choice in their config file would keep things neater. My guess is that a large proportion of users would just stay with the defaults and not create a config file at all.

A bit of added complication in the script itself - as long as it's transparent and readable - is IMO preferable to complicating the lives of users.

Basically I'm willing to put some effort into further refining this with regards to my own efforts, but I'd appreciate more feedback.

Coming soon...

I *have* noted @damo's comment regarding font specification, and whilst I put a case against it, I'm again not wedded to that...

I'm with @damo on fonts. If we hard-code some specific font then that font will have to be added as a dependency of the package. Preferable, if this isn't unnacceptably ugly, to use the default "sans-serif", "serif" or "monospace" aliases which are defined in ~/.config/fontconfig/fonts.conf. In a default BL these are set to the Noto family (which comes in a standard BL install), although users can change it. If you really want a specific font, and don't mind having the package depend on it, then I'd go for @damo's suggestion of defining it in one place only, easily found and edited by users. In fact, that would be a good idea anyway, even if using "sans-serif", so users could easily change the font just for the exit dialog if they want.

I *do* have a strategy in mind which would make eg cancel, lock. and other "on-essential" buttons optional, but my testing indicates that it would make the script longer with more "mostly identical but longer/shorter" yad blocks....

This way, I think. As long as the code is readable, and doesn't slow things down. I haven't found simple variable tests to have much influence on running time. (Maybe have a look at eg the lightdm-gtk-greeter or slick-greeter config to see how they set whether certain items are displayed or not.)

I have little idea with regards to the packaging or dealing with conflicts with the old package, else I might be persuaded to maintain the entire thing as the maintainer of the old package seems unwilling to do, I wish I felt my skills were up to it and much respect for @johnraff that he can.

Just to make clear: in Debian a clear distinction is drawn between the "upstream" Developer who actually writes the code, and the Maintainer who puts it in a package, with the necessary Debian meta-data.

In BL I am the Maintainer of many (most atm though that could change) of our packages, but while I also wrote some of the code, most of it comes from the rest of our dev team.

I was always, and still am, the maintainer of bunsen-exit but wrote none of the actual code. The original python script was written by CrunchBang's Corenominal, but was since extensively modified by other BL developers. Then a new version was started which is now unfortunately half-finished. At this point your re-take seems to hit the spot in terms of what we need, and when it goes into the bunsen-exit package you will continue to be credited as the author, although I will continue to be the maintainer. At that point I might have a few suggestions/requests for modifying things in the script (such as the exact location of config files) which you as "upstream" will be at liberty to implement, or not. (As BL community members, though, I would imagine we can agree.. smile ) Your choice of WTFPL license will also be respected, although most BL material goes under GPL3.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#128 2019-03-15 03:35:49

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: bl-exit replacement suggestions

One of the specific reasons I chose WTFPL  Is that it *specifically* allows relicensing under GPL V(whatever) or any other license if you prefer... I just *like* WTFPL myself.. I's REALLY free.. I's as near as "Public domain" as is universally *accepted as free* as is possible as various jurisdictions permit, regardless of jurisdiction.

If you prefer *your own* function that parses configs is under GPL v (any) I will ofc respect that myself, since I incorporated it.. and will happily change license to suit.
You simply posted that without ant lenience specified..

Nevertheless I have no desire ti force your choice of license for your own function (which you failed to specify).
I really *don't care* about licensing... whereas *I do care* about being init-agnostic
@hhh I really do not wish to make this slow, If  I can optimize it I will be delighted to do so.
&& @ change the license @johnraffe I will be  be delighted to do so

Last edited by Bearded_Blunder (2019-03-15 04:37:51)


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#129 2019-03-15 04:58:58

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,957
Website

Re: bl-exit replacement suggestions

Licensing is declared at the packaging stage mostly. I don't think most people attach licenses to code snippets they share on forums.

As you say, WTFPL allows re-licensing as GPL. The main difference is that GPL specificly prohibits re-licensing under some more restrictive terms. It enforces freedom, so to speak.

It's quite common for Debian packages to contain files under some licence than GPL - as long as the resulting package can be distributed under Debian's terms then it's OK. BL try to follow Debian policy as far as possible.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#130 2019-03-16 13:27:13

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: bl-exit replacement suggestions

johnraff wrote:

Licensing is declared at the packaging stage mostly. I don't think most people attach licenses to code snippets they share on forums.

Which leaves the results in undefined territory, depending where posted they may end up as it were "owned" by the original poster, or whoever runs the board, or public domain, depending on exact circumstances, by so attaching something my *intent* to do the nearest thing to putting it into the public domain as some jurisdictions permit is made clear.  Even then the exact position varies according to various factors.
It does avoid equivalent situations to finding your personal photos suddenly copyright some social media page. So as a personal choice, for longer snippets I tend to.

johnraff wrote:

As you say, WTFPL allows re-licensing as GPL. The main difference is that GPL specificly prohibits re-licensing under some more restrictive terms. It enforces freedom, so to speak.

One could hold a completely pointless debate if that's a protection or a restriction on freedom, someone re-licenses a work under wtfpl to something more restrictive, you simply use the original rather than the more restrictively licensed derivative. My contribution is thus always free, your contribution can be GPL/MIT/BSD3 or something restrictive, I've left you your freedom.

Leaving aside that moot point, and returning to the first, GPL is too darned long to attach to snippets, wtfpl is short enough to include it its entirety, and the intended status is thereby clarified.

johnraff wrote:

It's quite common for Debian packages to contain files under some licence than GPL - as long as the resulting package can be distributed under Debian's terms then it's OK. BL try to follow Debian policy as far as possible.

Indeed, Apache, BSD, MIT are all fairly common, the minetest package even has stuff under wtfpl.

Last edited by Bearded_Blunder (2019-03-16 13:38:48)


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#131 2019-03-17 03:49:52

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: bl-exit replacement suggestions

I might add, that in another time and place, about a decade ago I ended up amidst heated exchanges over something to which I'd contributed and exactly who had what rights.. I'm not sure that forum even still exists, nevertheless I've not forgotten the experience & the main point is to avoid any chance of a repeat by effectively disavowing rights which wtfpl is a generally legally accepted means to do.


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#132 2019-03-17 08:38:32

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,957
Website

Re: bl-exit replacement suggestions

Re: snippets, I wasn't talking about bl-exit but the functions I had posted without any licence. Your attaching of a licence to your script is well within common practice I think.

Re: WTFPL and GPL it's not necessary to put the full licence at the top of the script. In single files, many people use something like:

#    Copyright (C) 2016  Fred Bloggs <somedev@domain.com>
#
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation, either version 3 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program.  If not, see <http://www.gnu.org/licenses/>.

This is not much longer than your WTFPL declaration, but I'm not particularly advocating that you change to GNU - it's your choice. Anyway, in a Debian source package all the copyright and licencing information is provided in debian/copyright so it's not actually necessary to put that info in the file itself, as long as the package maintainer is aware of the licence and records it correctly.

The licencing debate has been very long and involved many people so let's not rehash it here. Some people prefer this, or that... There are reasons IMO why the GPL is the most used, but your choice of WTFPL is no problem whatsoever.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#133 2019-03-17 19:07:59

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: bl-exit replacement suggestions

Sorry, after you effectively invited use of your snippet for parsing config, I didn't think about the implications of simply doing so from the standpoint of possibly treading on your toes.

I offer my apology for any upset of whatever nature caused.

Please make whatever changes you feel comfortable with, both to be properly credited, as it appears looking again that I've somewhat shortcut that aspect also as a work in progress as opposed to what's expected in a finished article, and with regards to license, I shall take due note & make revisions to suit in any updated repost. Or just make such changes at the final packaging stage.

The finer points of collaboration with others on projects has never been my strong suit, unless I'm really familiar with the person's or team's preferred methods I struggle getting the cooperation right simply moving furniture.  It's consequent to an autistic spectrum disorder and unlikely to change, and if I manage to get it right, you can rely on me slipping & getting it wrong again at some future date.  FOSS is an entirely new and strange minefield world.

Whatever method you pick to be happy about your contribution being there is completely fine by me.  If you prefer for simplicity to relicense the entire lot under something you're happy for your snippet to be, I'm fine with that too.

As far as your remark as to what's most commonly chosen is concerned, if I were the type who routinely chose the popular option, I'd be using systemd & this would never have got written.

GPL is so often chosen because it's like non-drying yellow paint, the instant you handle anything covered by it the only tidy solution is to paint the entire ocean liner yellow.  Not saying that's wrong, but personally I get tired of yellow.  There are other free colours.

johnraff wrote:

There are reasons IMO why the GPL is the most used, but your choice of WTFPL is no problem whatsoever.

Even that depends where you look to count up, for instance according to this on Github at least, MIT is most popular.  I couldn't quickly locate a breakdown for Debian.

Last edited by Bearded_Blunder (2019-03-18 01:21:44)


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#134 2019-03-18 06:23:27

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,957
Website

Re: bl-exit replacement suggestions

No apologies needed for anything. smile

I'm thinking the config-parsing function might be made available in bunsen-common, so scripts like yours will be able to just source /usr/lib/bunsen/common/bl-includes.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#135 2019-03-18 06:36:26

Bearded_Blunder
Dodging A Bullet
From: Seat: seat0; vc7
Registered: 2015-09-29
Posts: 730

Re: bl-exit replacement suggestions

That's a handsome regex in it, having once tried to produce one to test for something as seemingly simple as a valid IP address (sanitizing user input), I shudder at the thought of trying to write something myself for the job, I'm with whoever said that if a regex is the solution, you now have 2 problems.  The IP one ended up being something someone had previously posted on stackexchange  ops was either that or about 8 lines.... (this was some windows stuff.. not bash/shell scripting)


Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me

Offline

#136 2019-03-20 07:12:24

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,957
Website

Re: bl-exit replacement suggestions

@B_B do you have a GitHub (or GitLabs) account?
If your exit script was in a git repo I (and other devs) could fork it and make any suggested changes as pull requests for you to inspect before merging.


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#137 2019-04-09 18:54:53

hhh
Meep!
Registered: 2015-09-17
Posts: 8,628
Website

Re: bl-exit replacement suggestions

Here's my latest, a horizontal layout with icons, accelerators, and it will exit when unfocused (or Esc)...

    # Simple yad GUI
    --simple-gui) yad --class=WmanExit --title "Exit" --close-on-unfocus --undecorated --center --on-top --borders=5 --window-icon=gnome-logout \
                       --button=" _Logout!gnome-logout!":'bash -c "logoutctl terminate-session"' \
                       --button=" _Suspend!gnome-session-suspend!":'bash -c "logoutctl suspend"' \
                       --button=" Re_boot!system-reboot!":'bash -c "logoutctl reboot"' \
                       --button=" _Power Off!gnome-shutdown!":'bash -c "logoutctl poweroff"' \
                 ;;

Screenshot...

https://forums.bunsenlabs.org/viewtopic … 197#p85197

Online

#138 2019-04-24 19:27:48

hhh
Meep!
Registered: 2015-09-17
Posts: 8,628
Website

Re: bl-exit replacement suggestions

New bl-exit is working with my buster KDE Plasma session!

On my testing partition, I have lithium running and it's working fine there too, of course. However, I've just set up an awesome wm session and the logout is failing with a "Cannot get connection to the dbus message session" popup window that finally logs out after a minute, or it just restarts awesome without the logout. All the systemctl commands work fine.

My temp workaround is just to run a separate script for awesome that replaces the logout section with a hack...

logoutctl(){
    if [[ ! -z $YAD_PID ]]; then
#        kill -SIGUSR1 $YAD_PID

        pkill -INT awesome

    fi

Online

#139 2019-08-06 21:21:26

misko_2083
Member
Registered: 2016-05-24
Posts: 232

Re: bl-exit replacement suggestions

Bloody hell, didn't find the lithium branch when I ported bl-exit to gtk3. yikes
https://github.com/Misko-2083/bunsen-exit
-Ported bl-exit to python3, pygi and gtk3.
-Added misko.css style.
I thought, since it's deprecated the development has stopped.  monkey
misko.css style
https://i.imgur.com/aiDzHYu.png

Last edited by misko_2083 (2019-08-06 21:25:29)

Offline

#140 2019-08-07 02:38:18

johnraff
nullglob
From: Nagoya, Japan
Registered: 2015-09-09
Posts: 5,957
Website

Re: bl-exit replacement suggestions

^The development of the python implementation stopped because the developer who was working on it got too busy. We replaced it with a Yad frontend and an init-agnostic shell backend based on Bearded_Blunder's contribution.

The current bunsen-exit source package now builds two packages: bunsen-exit (the new shell-based implementation) and bunsen-exit-python (the old python application). bunsen-exit is the default but users can still install bunsen-exit-python if they prefer.

@misko_2083 would you be OK with us merging your improvements back into the Lithium python code?


John
--------------------
( a boring Japan blog , Japan Links, idle twitterings  and GitStuff )
In case you forget, the rules.

Offline

#141 2019-08-07 13:06:38

misko_2083
Member
Registered: 2016-05-24
Posts: 232

Re: bl-exit replacement suggestions

johnraff wrote:

@misko_2083 would you be OK with us merging your improvements back into the Lithium python code?

Not yet. It's working in Debian 10 but can't get the theme styles working.
Those css themes need to be ported to gtk 3.20.
Yes I've read it correctly ported, not just made compatible.
There was a big change in Gtk theming at some point.
I'm looking at a few css of the gtk 3.20 compatible themes and it doesn't make much sense.
Does anyone know how to make a gtk 3.20 compatible theme from these?

Edit:
On xfce for shutdown I use a 30 seconds delay app.
https://forum.xfce.org/viewtopic.php?pid=53565#p53565
Tested and it's working in xfce Deb-10. For Openbox it would require a small tweak.

Last edited by misko_2083 (2019-08-07 13:18:01)

Offline

#142 2019-08-07 13:13:55

ohnonot
...again
Registered: 2015-09-29
Posts: 4,092
Website

Re: bl-exit replacement suggestions

misko_2083 wrote:

Does anyone know how to make a gtk 3.20 compatible theme from these?

You might want to look at oomox; it can be made to look at the colors from those .css files & apply them to a GTK theme template.

Offline

#143 2019-08-07 13:25:14

misko_2083
Member
Registered: 2016-05-24
Posts: 232

Re: bl-exit replacement suggestions

ohnonot wrote:
misko_2083 wrote:

Does anyone know how to make a gtk 3.20 compatible theme from these?

You might want to look at oomox; it can be made to look at the colors from those .css files & apply them to a GTK theme template.

Thanks. It looks interesting.
Will have a look.

Offline

#144 2019-08-07 19:06:35

brogild
Member
Registered: 2019-07-04
Posts: 7

Re: bl-exit replacement suggestions

It's only a tiny niggle, and probably irrelevent if bl-exit is going away, but I would like it if the highlighted entry 'wrapped around' when using the arrow keys.

Told you it was tiny.

Offline

#145 2019-08-07 21:22:31

damo
....moderator....
Registered: 2015-08-20
Posts: 5,157

Re: bl-exit replacement suggestions

brogild wrote:

It's only a tiny niggle, and probably irrelevent if bl-exit is going away, but I would like it if the highlighted entry 'wrapped around' when using the arrow keys.

Told you it was tiny.

bl-exit isn't going away: the new default version uses yad as the frontend for a bash script, instead of gtk buttons for a python script. It should be possible to get the behaviour you want, but it would entail a lot of scripting to achieve, AFAICS.

You are welcome to have a go!


Be Excellent to Each Other...

FORUM RULES and posting guidelines «» Help page for forum post formatting
Artwork on DeviantArt  «» BunsenLabs on DeviantArt

Offline

#146 2019-08-10 18:04:58

d33vliter
New Member
Registered: 2019-08-10
Posts: 4

Re: bl-exit replacement suggestions

Good afternoon, I don't have internet to give a better answer and contribute, but I found the topic interesting. With everything I saw, I think that the most logical and that will work in the future is to make a basic script zenity, yad(like those on page 2) that fulfills its function. so it's easy, nice, configurable and long term in case you have to modify something, plus it can work in any distro without giving problems. It would be perfect to maintain the simplicity of what was crunchbang, to look beautiful, modern and workable and above all light. When I get home I get on the wave to see what I can contribute, I'm excited. Greetings!

Last edited by d33vliter (2019-08-10 18:07:05)

Offline

#147 2019-08-11 06:41:51

d33vliter
New Member
Registered: 2019-08-10
Posts: 4

Re: bl-exit replacement suggestions

damo wrote:

Icons only; Horizontal text only; Vertical aligned...

bb-exit.sh -mi &
bb-exit.sh -m &
bb-exit.sh -v &

https://cdn.scrot.moe/images/2019/03/03/exit.th.jpg

the v is perfect

Offline

#148 2019-10-08 16:56:38

manyroads
Member
From: around here, somewhere
Registered: 2019-04-16
Posts: 38
Website

Re: bl-exit replacement suggestions

FWIW here's the yad script I use in bspwm (I'm thinking of using on my BunsenLabs (Lithium) MX19 build.

#! /bin/bash

action=$(yad --width 300 --entry --title "System Logout" \
    --image=gnome-shutdown \
    --button="Switch User:2" \
    --button="gtk-ok:0" --button="gtk-close:1" \
    --text "Choose action:" \
    --entry-text \
    "Power Off" "Reboot" "Suspend" "Logout")
ret=$?

[[ $ret -eq 1 ]] && exit 0

if [[ $ret -eq 2 ]]; then
    gdmflexiserver --startnew &
    exit 0
fi

case $action in
    Power*) cmd="sudo /sbin/poweroff" ;;
    Reboot*) cmd="sudo /sbin/reboot" ;;
    Suspend*) cmd="sudo pm-suspend" ;;
    Logout*) 
    case $(wmctrl -m | grep Name) in
        *Openbox) cmd="openbox --exit" ;;
        *bspwm) cmd="bspc quit" ;;
            *Metacity) cmd="gnome-save-session --kill" ;; 
        *) exit 1 ;;
    esac
    ;;
    *) exit 1 ;;    
esac

eval exec $cmd

123884634_yad-logout-2.png 123884685_yad-logout-1.png


Pax vobiscum,
Mark Rabideau (manyroads)
"For every complex problem there is an answer that is clear, simple, and wrong."    ---H. L. Mencken
Reg. Linux User #449130 ~ MXLinux, antiX, BunsenLabs, ArchLabs

Offline

#149 2019-11-06 18:09:55

dolly
Miss Mixunderstand
From: /lab1
Registered: 2015-10-03
Posts: 390

Re: bl-exit replacement suggestions

The default bl-exit menu in Lithium is looking really good, and fits well into the general default theme scheme.

One thing it needs though in my opinion, is a stronger marking of which button is active when moving from one to another with the arrow keys. A strong easily recognizable contrast that leaves the user without doubt of which of the buttons that is chosen. Just a small suggestion. smile

Last edited by dolly (2019-11-06 18:14:04)


Keep BunsenLabs #!yish please.

Offline

#150 2019-11-06 20:47:53

Naik
Member
From: Lipsia
Registered: 2015-10-03
Posts: 181

Re: bl-exit replacement suggestions

dolly wrote:

The default bl-exit menu in Lithium is looking really good, and fits well into the general default theme scheme.

One thing it needs though in my opinion, is a stronger marking of which button is active when moving from one to another with the arrow keys. A strong easily recognizable contrast that leaves the user without doubt of which of the buttons that is chosen. Just a small suggestion. smile

I second that!


"Kaum macht [Mensch]* es richtig, funktioniert es sofort!"
BL-Kitchen on GitHub

Offline

Board footer

Powered by FluxBB