Working on a bl-welcome frontend

xaos52 · 2016-08-26 07:28:36

I have just started work on a python3 script that allows to collect all user answers needed to run bl-welcome without further user intervention.

I am using a personal repo for the moment: https://github.com/xaosfiftytwo/bl-welcome-frontend
I will be updating it after every program change.

You can all follow development there.

Suggestions, improvements, bug reports etc ...are welcome.

Last edited by xaos52 (2016-08-26 07:29:58)

pvsage · 2016-08-26 09:17:13

What about saltstack? IIRC, this was proposed a while ago for the same purpose.

xaos52 · 2016-08-26 09:26:34

^ Yes, I remember nobody launching that 'general idea'.
If I understand it correctly - and I may be wrong - saltstack would replace the bl-welcome 'backend'. In other words, even if we go for saltstack, we would still need a graphical script that collects all the user answers, and that is then fed into saltstack.

Anyhow that part is still unclear to me, but we can have a closer look on this when the frontend is ready.

I will make the frontend output a 'config' file , which can then be sourced by either bl-welcome or the saltstack setup.

johnraff · 2016-08-27 06:55:40

This sounds interesting, and the idea of generating a config file makes it quite flexible. I had been thinking of an array (or two in fact) but it's very difficult to pass arrays out of a script, to something written in a different language.

Will the user interface be more-or-less the same - messages, warnings etc - but with actions deferred till the questions are all done?

In terms of the actual GUI, at the moment I would tend to prefer the same terminal-based approach, where the user gets to see the regular command output, and gets a taste of "hands-on" CLI work. I suppose doing all the work afterwards would take this away in fact, and the "salt" backend would remove it completely, so the front end could be curses, GTK or anything...

I think a lot of our users still enjoy the "bare-bones", "transparent" feeling of a terminal though. Opinions?

damo · 2016-08-27 07:17:17

The intro terminal was a well-known signature of #!, and now BL. A new user immediately gets some idea of the distro's philosophy.

Of course it needs improving and polishing, but I would hate to see it replaced with a run-of-the-mill gui with checkboxes and buttons.

xaos52 · 2016-08-27 09:45:43

@john @ damo,

So, you would prefer a modified bl-welcome or a bl-welcome frontend written in bash, using the style of the current bl-welcome and ouputting a file with the answers - just collecting all the answers up front, and then running them all without further user intervention, but showing the commands that are run and capturing errors if/when then occur, and then give contro back to the user. Something like:

An error has occurred processing command '...'. Cancel or Continue

By putting the collection of answers in a frontend, separate from bl-welcome - we could offer both options to the user - a gui or a terminal frontend.

And offer three options for the backend - either a bash script à la bl-welcome or a gui showing commands and results in a separate window as they arrive, or passing the answers on to 'salt' - providing feedback to the user is something to be examined when we go for this.

BTW:
I think the younger folks and newcomers to linux would prefer the 'gui with checkboxes and buttons' over the 'geeky' command-line interface. No?

Last edited by xaos52 (2016-08-27 09:48:01)

xaos52 · 2016-08-27 10:13:48

First decision to be made:

Do we want a gui frontend or not?

If not, is there another more urgent project that needs work?

Last edited by xaos52 (2016-08-27 10:14:50)

Head_on_a_Stick · 2016-08-27 10:40:54

johnraff wrote:

curses

I like this option but I do agree that a pure, terminal-based approach is more in keeping with the #! heritage.

damo · 2016-08-27 10:54:15

How easy would it be to run a gui if the graphical installer was used, or the screens if the text installer was used?

BTW:
I think the younger folks and newcomers to linux would prefer the 'gui with checkboxes and buttons' over the 'geeky' command-line interface. No?

My personal preference is to keep the screen method, but I appreciate the possible necessity to accommodate current expectations

Last edited by damo (2016-09-23 03:27:15)

xaos52 · 2016-08-27 12:09:43

How easy would it be to run a gui if the graphical installer was used, or the screens if the text installer was used?

Whatever we choose would run automatically at first reboot - just like bl-welcome now.
There is no dependency on the type of installer used, I think, or is there?

Last edited by xaos52 (2016-08-27 12:10:57)

damo · 2016-08-27 12:24:48

xaos52 wrote:

...
There is no dependency on the type of installer used, I think, or is there?

Just thinking out loud....

I imagine there is a way to record the user choice during installation, but I know nothing about live-install

pvsage · 2016-08-28 07:25:20

damo wrote:

I imagine there is a way to record the user choice during installation

Not sure about this. Isn't the graphical installer just a "prettier" interface?

johnraff · 2016-08-28 08:24:21

xaos52 wrote:

Do we want a gui frontend or not?

Right, this is a fundamental decision relating to the whole "BunsenLabs philosophy" - whatever that is. In #! it was easy - Philip made the setup that suited him and shared it with others.

Now, we're continuing the #! spirit, but like to think we're improving things a little, or at any rate, taking the distro/DE/whatever along a path that Philip might have followed, and that will appeal to the same people who liked CrunchBang.

As someone who put a biggish proportion of the work spent on bl-welcome (it was built on a foundation made by others) I feel a bit reluctant to speak out, but I will anyway: I like the current terminal-based frontend, and feel that hours spent rewriting it as a GUI might indeed be better spent on something else. (I do like the idea of deferring the actions till all the questions have been asked, though.)

But that's only one person's opinion - we need a consensus here, and I'm happy to go along with the majority.

is there another more urgent project that needs work?

I think there might be some, though some of our community have already raised concern that BL might be getting bloated. "Keep it simple" might be the best way to go.

Still, there's the "salt" backend that nobody suggested and pvsage mentioned earlier. I don't know if nobody has the time or inclination to develop that himself, but if not then there would seem to be plenty of work there for an experienced developer to do, just to find out if it's worth pursuing or not.

Another thing that I had on my TODO list (just copied in):

I'm starting to think that in the long term we should have
a "startbunsen" script to hold things we want only for BunsenLabs,
leaving LXDE or XFCE sessions clean.
It could be triggered from a /usr/share/xsessions/bunsenlabs.desktop
which we would set as default in lightdm.conf.

Of course keeping a BL session completely independent from eg LXDE is impossible - system settings - but I don't know if there would be any reward in looking into that?

damo · 2016-08-28 09:32:22

But that's only one person's opinion - we need a consensus here, and I'm happy to go along with the majority.

This needs community input IMO.

nobody · 2016-08-28 10:14:42

Head_on_a_Stick wrote:

johnraff wrote:
curses
I like this option but I do agree that a pure, terminal-based approach is more in keeping with the #! heritage.

While curses is well beyond any notion of purity, it lends itself well to the task.

In fact, there is no need to depart from the current UI. Using curses to just manage the terminal contents would be a good thing because it would do away with things like https://github.com/BunsenLabs/bunsen-we … lcome#L130. Of course a lot of things could be implemented in a more sensible manner if we were to se true input widgets, but that is optional. IDK right now, but I don't think current bl-welcome does handle e.g. resizing the terminal, right?

I've been itching for a long time to give Urwid a spin.

Needlessly to say, bl-welcome-ng, if written using curses, would NOT be a shell script anymore.

johnraff · 2016-08-29 01:31:35

twoion wrote:

IDK right now, but I don't think current bl-welcome does handle e.g. resizing the terminal, right?

Er, wrong actually. Try it. It doesn't adjust wrapping dynamically but it displays nicely in any terminal size.

In fact, this comes from the say() function in bl-include.cfg, so any script can (and some do) use it.

snippet:

    local width=$(tput cols 2>/dev/tty)
    fold -s -w $((width - 3)) <<< "${1-}" | sed 's/^/  /' # wraps text nicely and adds two leading spaces

Last edited by johnraff (2016-08-29 01:32:18)

xaos52 · 2016-08-29 10:47:03

I can understand that we hold on to bl-welcome - into which a lot of effort has been invested.
How about changing bl-welcome so that it can act as a front-end for itself, just collecting answers from the user, not processing them right away, but produce a summary of chosen options at the end, and ask for confirmation from the user. Then output a file containing bash assignments that can be sourced in by bl-welcome - or any other script - and processed.

This would require bl-welcome to be changed so it can run in 2 modes:
1. collect answers mode
2. process collected answers
This can be achieved by adding an option to bl-welcome:
-f | --front-end : Run in 'collect answers' mode
-p | --process : Run in 'process answers' mode

This would also require bl-welcome and all of its help scripts to handle the corresponding mode appropriately. Each script would be changed to contain a big case statement:

case $mode in
'collect':
...
...
;

'process':
...
...
;
esac

Reactions?

Last edited by xaos52 (2016-08-29 10:47:57)

damo · 2016-08-29 10:52:36

xaos52 wrote:

...collecting answers from the user, not processing them right away, but produce a summary of chosen options at the end, and ask for confirmation from the user. ...

I thought that this is what @johnraff was intending to work on.

xaos52 · 2016-08-30 09:33:03

damo wrote:

I thought that this is what @johnraff was intending to work on.

Can you confirm this, John?
Are you working on it already?
I do have time to work on this. If you want to do it yourself, no problem with me.

johnraff · 2016-08-31 05:09:25

xaos52 wrote:

damo wrote:
I thought that this is what @johnraff was intending to work on.
Can you confirm this, John?

Well, the topic has already come up several times and I think each time I've said I thought it was a good idea, both here and elsewhere:
"(I do like the idea of deferring the actions till all the questions have been asked, though.)"
"Like, a major rewrite of bl-welcome to a menu-style selection system: that could take a long time to get right..."
"If nothing else, the repetitions of 'apt-get update' after every repo modification could be avoided if all user choices were collected first, and executed en-masse afterwards."

Are you working on it already?

I'm thinking about it already. That's the way I work. I like to have a pretty good idea in my mind of what's going to happen before I start any coding. I haven't typed anything yet.

I do have time to work on this. If you want to do it yourself, no problem with me.

How do you feel about a collaborative approach?

Here's a random list of my thoughts on the subject to date:

bl-welcome is an interactive script. The user is constantly being consulted before going on - especially if something seems not to be going according to plan. I threw in tests after each operation to try and get out quickly if there's trouble. There's a lot of logic - if this, then that, depending on user choices.

There are some pages where users get a longish explanation of the implications of the choices on offer. This will be hard to do in a menu style: popups? "click here for more info" links? In fact I think your suggestion of running the script in "collect-answers" mode might be a better alternative to a "check the boxes" menu.

While most of the changes performed are at the system level, there are some things done at user level, for example changes to openbox/autostart. Maybe user tweaks should be separated out into a completely different script?

Meanwhile, we've already discussed moving some of the install pages (Java, Flash, "Dev" options) out into a new "system tweaks" pipemenu. That's a related project that needs doing sometime.

Considering the future possibility of using salt or some tool to configure the system, it would be good to have some kind of script-agnostic output of the user decisions. Your idea of a config file sounds promising. (Of course salt would still need some kind of custom salt-execute script to read the file, I guess.)

The actions that take time and get users tapping their fingers are perhaps apt updates and package installs. Every time a new repo is added to sources.list, apt has to be updated, and some metapackages pull in a ton of dependencies. So, I was wondering if a reasonable compromise to start with might be to defer add repository and install package actions, while doing everything else (which usually goes very quickly) in real time.

In that case, it might be enough to eg replace safeInstall() functions with addToInstallList() functions, while most of the code could stay the same.

The backend that executes the repo and package actions might be easily made from existing code, at least to start with, although a generic addRepo() function might be possible, if it was fed with url and test_regex strings...

The more I think about the UI, the more I tend to prefer the current terminal-based approach. Apart from being simple to code, it gives new users a gentle introduction into the world of CLI, and shows them what to expect as output from apt-get and friends.

@xaos52 do you think we have enough thinking in common to work together on this? If so, I'd be delighted to profit from your experience.

#1 2016-08-26 07:28:36

Working on a bl-welcome frontend

#2 2016-08-26 09:17:13

Re: Working on a bl-welcome frontend

#3 2016-08-26 09:26:34

Re: Working on a bl-welcome frontend

#4 2016-08-27 06:55:40

Re: Working on a bl-welcome frontend

#5 2016-08-27 07:17:17

Re: Working on a bl-welcome frontend

#6 2016-08-27 09:45:43

Re: Working on a bl-welcome frontend

#7 2016-08-27 10:13:48

Re: Working on a bl-welcome frontend

#8 2016-08-27 10:40:54

Re: Working on a bl-welcome frontend

#9 2016-08-27 10:54:15

Re: Working on a bl-welcome frontend

#10 2016-08-27 12:09:43

Re: Working on a bl-welcome frontend

#11 2016-08-27 12:24:48

Re: Working on a bl-welcome frontend

#12 2016-08-28 07:25:20

Re: Working on a bl-welcome frontend

#13 2016-08-28 08:24:21

Re: Working on a bl-welcome frontend

#14 2016-08-28 09:32:22

Re: Working on a bl-welcome frontend

#15 2016-08-28 10:14:42

Re: Working on a bl-welcome frontend

#16 2016-08-29 01:31:35

Re: Working on a bl-welcome frontend

#17 2016-08-29 10:47:03

Re: Working on a bl-welcome frontend

#18 2016-08-29 10:52:36

Re: Working on a bl-welcome frontend

#19 2016-08-30 09:33:03

Re: Working on a bl-welcome frontend

#20 2016-08-31 05:09:25

Re: Working on a bl-welcome frontend

Board footer