Converting our in House Scripts to PerlGTK

[Mark342]

Sure, I've uploaded a new version that pulses at 1/200 (previous was 1/50).
It's available at the same link in my last post.

I had it set at 1/100 in the begining but switched to 1/50 because it was too slow and 1/50 was just right.
Now that I've tested it again, 1/50 seems WAY too fast.
I guess this is because I had a huge amount of windows open when I tested it the first time.

That said, it will still vary according to the speed of your CPU.
This was an oversight on my part.
It probably needs a timer to keep it consistent across all machines.

[Neal ManBear]

Thank you, Mark.

[Neal ManBear]

Woohoo! Works good. Looks good!
Are there any other bugs to work out?

[Neal ManBear]

I see what you mean. Hmm...... do you think it will be a problem?

[Mark342]

If this is a problem, the developers of diskdrake are in trouble!!
Because you can close the window while doing a partition operation.

When gezSwitch is embedded in the PCC, it no longer has control over the window's properties or events.
In fact, it also has no control over the menubar or the banner.
Because these parts are controlled by drakconf.
We have control over everything else though.

My suggestion is we give a very clear warning to the user.

Maybe something like this (needs polish):
"WARNING\n do not close the window\n or your system could\n be rendered unbootable."

This text should replace the current text in the dialog once the ok button is clicked.

We could use:

Code: [Select]

$apply_dlg->set_markup(string);for this.

[Neal ManBear]

My suggestion is we give a very clear warning to the user.

Maybe something like this (needs polish):
"WARNING\n do not close the window\n or your system could\n be rendered unbootable."

Suggestion: Change do to Do and the to this.

"WARNING\n Do not close this window\n or your system could\n be rendered unbootable."

Could it be done in red text?

"WARNING\n Do not close this window\n or your system could\n be rendered unbootable."

[Mark342]

Uhh, about how big is your initrd supposed to be?

Everytime I ran this program (which uses switch-themes) I have noticed the initrd's size has been steadily increasing
I just ran 'plymouth-set-default-theme PCLinuxOS --rebuild-initrd' and my initrd dropped in size from >70MB to about 7MB.

I checked the source of plymouth-set-default-theme and it calls another script when the "--rebuild-initrd" option is set.
This script is called "plymouth-update-initrd"

Plymouth-update-initrd contains a single line:

Code: [Select]

mkinitrd -f /boot/initrd-$(uname -r).img $(uname -r)
The "plymouth-something" scripts are packaged with plymouth while switch-themes seems to be specific to PCLinuxOS.
Maybe there is something wrong with switch-themes?

All of my testing was done in a virtual machine, but this is still a pressing issue.

[Neal ManBear]

Oh dear. Can we add a call to plymouth-update-initrd in the script?

[Mark342]

I traced switch-themes back through a chain of perl/shell scripts and found the script that does the initrd change.
Line 102 of switch-themes is where the chain starts.
And it goes:
(shell) switch-themes  > (perl) bootloader-config  > (perl) bootloader > (shell) make-boot-splash > (shell) make-boot-splash-raw

None of the above scripts but make-boot-splash-raw do much more than call the next one.

This file is the last one:
/usr/share/bootsplash/scripts/make-boot-splash-raw

Oddly, it contains this comment:

# Avoid duplicate files, adding another copy of glibc each time makes
# initrd grow fast

I don't know anything about the initrd though. (beyond that it contains startup modules)
So, I can't fix it.

I also wonder why all of that stuff going on in that script is necessary, because making a new initrd with mkinitrd takes just a few seconds.

I think Line 102 (and corresponding if statement) of switch-themes could changed to plymouth-update-initrd, but this needs testing.

======================================================

I wonder if it's possible to switch plymouth themes and leave bootsplash out of it.  Have you ever seen a bootsplash since using plymouth?

The command

Code: [Select]

plymouth-set-default-theme $theme_name --rebuild-initrd
Does the same thing as "switch-themes $theme_name", but doesn't have the "increasing initrd size" problem.

Another option would be to trap a signal destroy event and restore the original initrd or something like that ?
It would prevent scaring the day lights out of our users.
I tried running switch-themes in the background originally because it is immuned to what happens afterwards in the foreground.  But it's a bad thing to have to guess when it's done.

I had a similar idea of backing up the original initrd, but I didn't try trapping the destroy event.
I'm gonna try it out now.
 EDIT: no dice;

[Mark342]

ongoto

I experimented with forked processes, and it worked until the theme was successfully changed.
Then it would crash with an IO error.  
This is probably due to my inexperience with forked processes.

However,
I have another (easier, better) way:
Get ready because it seems so simple now.

The system() method will fork a child process to run the command, and automatically make the main program 'wait' until the child process is finished.
We will know when the command is done because the thread won't be running.
AND, the child process will keep going even if the main program exits.

So, instead of this:

Code: [Select]

sub switch_themes
{
my $theme = shift;
my $ret =`switch-themes $theme`;
return $ret;
}
We have this:

Code: [Select]

sub switch_themes
{
my $theme = shift;
system("switch-themes $theme");
return FALSE;
}There, I solved it.


But I strongly suggest we drop switch-themes.
My initrd is already back up to 20MB.

[Neal ManBear]

While I was sleeping (9 hours! unheard of! ) you guys have been busy. I'm impressed. It looks like you have found the causes of some bugs and found ways to fix them.

It will take a while for me to get caught up, so please continue as you are.

[Mark342]

ongoto,

Back in page one of this thread I experimented with drakwizard,and got it to show a radio list with the themes on the user's system.
The problem I ran into was the nonexistent integration with the PCC, and the inability to run it with 'drakwizard $name'.
If either one of those is solved, then it is most certainly an option for those who don't want to learn perl-gtk.

EDIT: I just found out how to get it integrated in the PCC
Edit /usr/sbin/drakwizard and add this line with the others:

Code: [Select]

switch => [ 'switcheroo', N("Theme switcher") ],
Then in /usr/sbin/drakconf.real find this:

Code: [Select]

title => N("Boot look'n feel"),
                list => [
                    "Boot Theme",
]
                    And add a name for the wizard in the list like this:

Code: [Select]

title => N("Boot look'n feel"),
                list => [
                    "Boot Theme",
                    "Boot Theme Wizard",
]               

Then in /usr/lib/perl5/vendor_perl/5.10.1/MDV/Control_Center.pm
Add this:

Code: [Select]

"Boot Theme Wizard" =>
   {
    binary => "$sbindir/drakwizard switch",
    embedded => 1,
    description => N("Change Boot theme"),
    long_description => N("Change Boot theme"),
    icon => 'boot-theme-mdk',
   },
I know it was just an example ongoto, but I just couldn't help myself.


Alternatively, in the Control_Center file we can change the "binary" field to point to an existing zenity script/application.
However, they won't have embedded GUIs like gezSwitch4.
On a positive note: Seeing synaptic open from the PCC is good fun.

[Neal ManBear]

If other people get interested in this then it might be worth doing a step-by-step post.

Call me interested.

[Neal ManBear]

 

I'm gonna remove that until we have finished with this! ......... done!

[Mark342]

I was waiting for ongoto to post a new version, but he hasn't and I'm impatient    so here is an updated file with all of the changes we've talked about.
The only thing it's missing is the markup for the dialog text because I'm not sure if we still want it.

http://www.box.net/shared/pxi6xdueu3

The only thing I can think of that still needs to be done is implementing a way for others to translate the app.
The Drakx libraries contain ways to do this, but we'll have to go on the hunt to learn how to use them.
I do know that the 'common' library at /usr/lib/libDrakx/common.pm contains translation subroutines.