Porteus Settings Centre

[agreimann]

Guys,

I admit being too slow in writing an installer. I have decided to write a welcome assistant/box for Porteus, because I personally believe we NEED that a whole lot more. When I'm totally done, I'll see about attaching a zip archive of the program, licensed with the Gnu GPL version 3. I'm hoping that it will accomplish a) fixing the boot scripts, and removing the password and container requests out of it and b) Helping newbies to Porteus feel more comfortable and be given a setup assistant on first boot, just like how OS X or Windows does. When completed, it will, in a step-by-step process:

1. Welcome users to Porteus on first boot.
2. Temporarily close itself, then open the Porteus module manager to manage data archives.
3. Re-open itself, asking the user if they want to change the root password and *strongly* recommend that. Same will be applied to guest.
4. If yes, again, it will temporarily close, call Konsole, and ask the user to type a password.
5. The program will then finalize tasks, and close.

I'm not joking about this--I'm writing it along with writing this post.

[fanthom]

hmmm... some time ago brokenman wanted to do the same thing but he decided to not continue working on it.

Reason:
Porteus is a livecd linux and "Welcome" popup box at every boot can be little annoying.... (same as asking for changing default passwords)

How do you want to deal with it?

EDIT:\\
maybe popup window could appear only when "changes=" cheatcode is used?

[agreimann]

The "running at every boot" issue is really quite simple. We issue conditions in the program (after all, it IS a program.) so that way, if the program detects that the user has already run it, it will not start anymore, by leaving a visible file on the writable area of the disk. That way, on next boot, whether changes are used or not, the program will be "smart" enough not to run again until the user decides to run it. Thanks for your advice--I've already thought over this issue.

Another thing I was thinking is to allow it to automatically open up the wireless applet to set up the Internet--so they're ready to go.

[Ahau]

What's the writeable area of a CD?

It'd be easy enough on a USB or frugal install, but CD's may pose a problem. We could use the changes cheatcode as fanthom suggests, and then document the location of the program, so CD users could open it from the menu.

Did I just suggest documentation as a solution--again? Damn, I have tunnel vision!

[agreimann]

On a CD, this program will not work. On USB/writable media, it will. I don't know how you'd suggest working on this for CDs--I'm open for any and all suggestions.

[fanthom]

"if the program detects that the user has already run it, it will not start anymore"
i'm perfectly aware of this (this is the way porteus modtools asks for default path with optional modules). please imagine a person who doesn't save changes and boots porteus just to watch youtube, chat on gtalk, etc...

This could be very annoying for this particular type of users.

"changes=" means that user wants to save his settings and "Welcome" message with "settings wizard" could be very useful (especially for new members).
Unfortunately "changes=" is also not perfect as user intentions detector - some users may use "magic folders" or just /rootcopy...

I think the best compromise would be to create Kmenu/Lxde menu entry "Porteus Settings Wizard" called on user's request only (i could even drop "password check" function in rc.M in favor of that).
Maybe you could integrate following functions in the wizard:
- changing of default passwords
- wifi settings
- porteus save.dat manager
- language selection tool
- ??? ??? ???

after finishing, all settings could be stored in one xzm placed in /porteus/module (if writable) or ~/Desktop.
(w could also drop kmenu/lxde menu entries for psn/lst as simpler ==better)

BTW: here is brokenman's thread:
http://porteus.org/forum/viewtopic.php?f=53&t=229

other ideas?

[agreimann]

Again, thank you very much for all your advice.

How can I access the changes cheatcode (in other words, how can I have the program look for that? Do I look for the line and see if changes is there?) My original idea was to have the program look for a file, but Ahau is very right when he says CDs aren't "writable".

Also, I can implement the Language Settings Tool in it, but because I naturally only speak American English, I would have to put that part at the end.

As of right now, the welcome stage and the module manager part is complete. Thank you for your support on this project. I hope it'll work!

Posted after 6 minutes 55 seconds:
Update: The wireless connection portion and the user passwords part is complete.

[Ahau]

you can see the cheatcodes used with

cat /proc/cmdline

you can grep that for changes. Consolidating it as a menu item may be a more universal solution, but I think we're open to suggestions. I'd like to see it in action

[agreimann]

Excellent! I might just use that, and I guess make this a bash-based program, then. Thanks, Ahau. I have not tested the program yet--I will certainly need to re-write and test it later in my free time.

[brokenman]

My original plan was to drop a config file in the boot folder after the program had run once. Included in the boot script would be a check for that file. I abandoned the idea after thinking it through completely. We only offer an ISO which is essentially a file designed to be burnt to a cd/dvd. The welcome screen thingy just wouldn't work on this type of media. After disabling the KDE 'first run' wizard because it was just ... well .... annoying i decided against a Porteus one.

In the end i chose to create (as Fanthom suggested above) a menu item with the wizard available there. There isn't much difference between having something interrupt your booting process, to letting it boot completely and choosing the 'HELP ME' item from the menu. It is much more manageable that way. A couple of days ago i suggested that we should include a 'settings wizard' which could merge a couple of the items in the 'system' menu as that is getting a little cluttered IMHO.

Anyway, that's my 2 cents worth ... see what you can do with that.

[fanthom]

1) "Also, I can implement the Language Settings Tool in it, but because I naturally only speak American English, I would have to put that part at the end. "
you dont need to write LST from scratch, just call it form your app with function like:

Code: Select all

Exec=/tmp/.terminal -e /opt/porteus-scripts/language-selection-tool

and LST script will do the rest.
(ofc if you have enough time you could also write it from the scratch)

2) Let's stick to KDE/LXDE menu entry (and forget about "changes=" as it does not cover all scenarios)

@brokenman
"A couple of days ago i suggested that we should include a 'settings wizard' which could merge a couple of the items in the 'system' menu as that is getting a little cluttered IMHO."
agree...

[agreimann]

Okay, then. My program is now a bash script, but do not get me wrong, it'll be GUI in it's own right. It will use kdialog to accomplish this task. I guess it's a bash program in vain... since I won't use the changes cheatcode. I actually agree with that, because even if changes are appended to the boot menu, the user may or may not respect that.

With that said, here is how the Porteus Settings Assistant will work:

- It will have a welcome page.
- After that, it will open up the Module Manager to set up modules.
- When that is complete, it will prompt to open the control panel so the user can set the wireless connection.
- It will ask for the guest and root passwords to be changed and open Konsole for this task.
- Then, it will ask about changing the language and pop up the LST.
- Finally, it will tell the user everything's done and quit.

Also, guys, this program is complete and as soon as I test it, and iron out any bugs, ready to publish to Porteus! I guess we can just make this a menu entry as suggested. Thank you all for your advice & support!

Posted after 3 minutes 42 seconds:
Update: I will need to add "Changes will need to be enabled to save this on shutdown or reboot" or do I write this to media if writable? What do you think here? Somehow we'll have to save stuff.

Also, if this can't run, can we have a balloon that says "Run Porteus Settings Assistant" and then have the balloon close?

[fanthom]

"It will use kdialog to accomplish this task."
you can't i'm afraid. your app must be universal:
- use Xdialog instead of kdialog as many users does not like KDE and may not have kde xzm activated at all.
- your app must work for guest and root in the same way
- would be good to have one version which covers 32 and 64 bits

more to come when we see aplha version

[brokenman]

My only suggestion at this point is to use Xdialog in place of Kdialog. We converted everything to Xdialog from kdialog already. Fanthom and i follow this rule so that the scripts are available under all desktops. I have already made an Xdialog library you can use to simplify things too.

sh /usr/lib/macroport

Or add an .sh on the end if you are using rc1.

[Ahau]

I also think a menu might be of use, where a user can choose which stage of the script to run, without doing everythign else -- especially if this will replace several menu items in 'system'.