Bugs item #769761, was opened at 2003-07-11 13:12
Message generated for change (Comment added) made by jsquyres
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=109368&aid=769761&group_id=9368
Category: Installation
Group: Future
Status: Open
Resolution: None
Priority: 5
Submitted By: Jeff Squyres (jsquyres)
Assigned to: Terry Fleury (tfleury)
Summary: No wizard GUI updates during opd/selector
Initial Comment:
When either the GUI OPD or the selector are running
(i.e., the first two buttons on the OSCAR wizard), the
main OSCAR wizard GUI does not get updated.
For example, if you hide the wizard and then bring it
back, it's blank until OPD/selector finishes.
This is different than most (all?) other sub-windows in
the wizard; although the main window gets marked "busy"
(i.e., you can't push other buttons), GUI updates still
occur so that things like hide/unhide still show the
main wizard window and its contents.
----------------------------------------------------------------------
>Comment By: Jeff Squyres (jsquyres)
Date: 2003-07-16 08:49
Message:
Logged In: YES
user_id=11722
That's not quite what I meant.
Isn't it fairly common for situations like this to do
something like (pseudocode typed off the top of my head):
-----
$pid = fork();
if ($pid == 0) {
exec(...run the command...);
printf("Failed to launch!\n");
exit(-1);
} else {
set_parent_window_busy();
$done = 0;
while (!$done) {
if (waitpid(-1) == $pid) {
$done = 1;
} else {
sleep(1);
do_gui_updates();
}
}
set_parent_window_unbusy();
}
-----
Since this situation happens all over the place (e.g., the
OSCAR package API scripts -- I just noticed that the same
no-GUI-updates behavior happens while the gm RPM is being
built/installed), perhaps this should be a subroutine in
lib/OSCAR somewhere -- OSCAR::run_subcommand() or something
like that...? Hence, instead of using system() everywhere,
we should use OSCAR::run_subcommand().
----------------------------------------------------------------------
Comment By: Terry Fleury (tfleury)
Date: 2003-07-15 14:09
Message:
Logged In: YES
user_id=116599
The problem is that the old oscar_wizard GUI stuff is based
on Perl-Tk, while the new Opder and Selector are based on
Perl-Qt. When you click on step 0 or 1, the appropriate
Perl script is run (as if invoked from the command line).
So the oscar_wizard waits for the Opder or Selector to
return from execution.
Even if we were to call the Opder/Selector via a subroutine,
there would be problems since Tk/Qt each have their own even
loop. The only real solution is to reimplement the entire
oscar_wizard in Perl-Qt. This should happen in the next
version. For now, we'll just have to live with the
oscar_wizard not updating during Opder/Selector execution.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=109368&aid=769761&group_id=9368
-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the
same time. Free trial click here: http://www.vmware.com/wl/offer/345/0
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
