Working on a bl-welcome frontend

xaos52 · 2016-08-31 08:57:03

johnraff wrote:

@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.

I sure do. And I would be delighted to profit from yours.

Both of us living in almost non-overlapping timezones could be an advantage.
Plus vetting each others code, of course.

johnraff wrote:

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.

Agreed.
bl-welcome-ng in collect-answers-mode could be the front-end for bl-welcome-ng in process mode. But we retain the flexibility to switch to something else later on.

Starting with an 'ng' branch on the bunsen-welcome repo, based on 'deuterium'?

johnraff · 2016-09-01 01:10:58

Sure, please go ahead and branch bunsen-welcome 'ng' off deuterium.
(What does ng stand for btw?)

How about, for a start, trying to replace all the package install instructions (calls to safeInstall() ) with instructions to add a package to the install list for later execution? Add an addToInstallList() function or something? The current bl-welcome can stay almost the same at that point.

Actually writing addToInstallList() would require some decisions on the format of the output file though. Apart from package names, in some cases it will be necessary to specify what repo they are to be installed from...

Head_on_a_Stick · 2016-09-01 07:07:11

johnraff wrote:

What does ng stand for btw?

Next Generation

johnraff · 2016-09-02 10:12:44

Thinking... rather than add alternative modes to bl-welcome (the "helper scripts" are in fact fragments, which are sourced) how about making a new bl-system-change (or other suitable name) script to read and execute the config file generated by bl-welcome?

That would allow bl-welcome to be changed less (less scope for typos) and - if it later turned out to be a good idea - bl-system-change might be written in python or some other language...

...and might in the future be a frontend to salt or some other system.

johnraff · 2016-09-20 07:12:01

@xaos52 Maybe the first thing we should decide on is the best format for the file that the UI will write to and which will be read by the system utility.

Even if we start off only listing repos to be added and packages to be installed, there might be other things in the future that we'd like to have done, so we should try to make the syntax as flexible as possible at this stage.

Any ideas?

johnraff · 2016-09-21 05:45:59

Thinking a bit more about what actions might be listed up for execution, it occurred to me that along with system-level things like repos and packages there are also possible user-level changes like tweaks to openbox/autostart to fix some annoyance...

Those user-level changes should go in a different, user-specific file, right? They can be executed by the user who created the file (via bl-welcome) as a normal user, as opposed to the system-wide changes in the other file, which would be executed at sudo level.

Head_on_a_Stick · 2016-09-21 06:26:51

johnraff wrote:

possible user-level changes like tweaks to openbox/autostart to fix some annoyance...

Sounds interesting

I agree that user-level configuration files should be preferred whenever possible.

xaos52 · 2016-09-21 10:34:44

johnraff wrote:

@xaos52 Maybe the first thing we should decide on is the best format for the file that the UI will write to and which will be read by the system utility.

I don't think so.

In a first phase we should keep the changes to the bl-welcome script and the sourced scripts to a minimum.

I think bl-welcome should first collect all the user answers and store them - either in a file or just as environment variables or variables global to the script.

Then it should give the user a summary of the collected answers, and ask for either confirmation or going through the answering phase again to adjust (some of the) answers.

After confirmation, the script should call itself with an option --process-answers for instance, and do the rest of the processing without user intervention.

After the process phase we either confirm that everything went OK or that some errors were encountered while processing, again asking confirmation from the user in both cases.

The only problem I see with this schema is that the script should be self-updating when a new version of package bunsen-welcome is detected.

We need to put a method in place to detect a new version of the package without running apt-get update - we don't want sudo permissions activated unless we really need it - and do this first of all.
When an update is available, we ask for sudo permissions, run apt-get update and apt-get install bunsen-welcome, and relaunch the new version of the script.

When no update is available, we delay asking sudo permissions until after confirmation by the user.

Any suggestions on how to do that?

I am thinking of downloading the list of available packages from the repo with curl or wget, scan it for the version of bunsen-welcome, and compare with our current version of it.

----

johnraff wrote:

Also, how about moving this discussion to the public Development zone, so anyone can contribute?
Or starting a new thread on the same topic?

I am OK with both suggestions. Your choice.

PS:
I have been quiet at the development front because
1. We have exceptional wheather here for september, and I am going for tours on the bike during the day.
2. I have bought a new SLR digital camera and have been playing with darktable and gimp for raw image after-processing. Having fun with that, and learning a thing or two, esp. with darktable.

Once the weather turns normal again, I will have more time to spend on development again.

johnraff · 2016-09-22 06:23:29

xaos52 wrote:

johnraff wrote:
@xaos52 Maybe the first thing we should decide on is the best format for the file that the UI will write to and which will be read by the system utility.
I don't think so.

Not quite sure what you're disagreeing with here, but anyway...

In a first phase we should keep the changes to the bl-welcome script and the sourced scripts to a minimum.

Definitely!

I think bl-welcome should first collect all the user answers and store them - either in a file or just as environment variables or variables global to the script.

I think it would be very difficult to store the user responses in string variables to pass to another script (or even bl-welcome again with a --process option). It's pretty much impossible to pass arrays between scripts, and strings present quoting problems. I think a file to hold the user's choices is the way to go. That also allows execution to be delayed to another time. As I mentioned above, I think two files would need to be created: one for system actions, one for the user's personal settings. (bl-welcome already offers to edit ~/.config/openbox/autostart if fdpowermon is removed.)

Then it should give the user a summary of the collected answers, and ask for either confirmation

OK

or going through the answering phase again to adjust (some of the) answers.

Good, but enabling "go back" will require an extensive rewriting of the script. Can we leave that for later?

After confirmation, the script should call itself with an option --process-answers for instance, and do the rest of the processing without user intervention.

I'm not keen on having the script call itself. bl-welcome is already quite complicated, and the new code for processing answers would have little in common with what's already there. In the interest on keeping the changes to bl-welcome to a minimum, can we make a new executable for processing the file(s) generated after user input? It needn't even be a shell script, maybe python would turn out to be better at this point...

We need to put a method in place to detect a new version of the package without running apt-get update

It's possible to get the versions of packages directly from the BL repository: http://pkg.bunsenlabs.org/debian/dists/ … 6/Packages (versions should be achitecture-independent). There's a little script in bunsen-utilities, /usr/bin/bl-pkg-versions which compares apt and github verions. We could reuse a bit of code from there.

I have been quiet at the development front...

No problem at all. I see this as a long-term project, and can't put much time into it at the moment till all my current loose ends are tidied up.

#21 2016-08-31 08:57:03

Re: Working on a bl-welcome frontend

#22 2016-09-01 01:10:58

Re: Working on a bl-welcome frontend

#23 2016-09-01 07:07:11

Re: Working on a bl-welcome frontend

#24 2016-09-02 10:12:44

Re: Working on a bl-welcome frontend

#25 2016-09-20 07:12:01

Re: Working on a bl-welcome frontend

#26 2016-09-21 05:45:59

Re: Working on a bl-welcome frontend

#27 2016-09-21 06:26:51

Re: Working on a bl-welcome frontend

#28 2016-09-21 10:34:44

Re: Working on a bl-welcome frontend

#29 2016-09-22 06:23:29

Re: Working on a bl-welcome frontend

Board footer