Bugs item #769761, was opened at 2003-07-11 12:12
Message generated for change (Comment added) made by brechin
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=109368&aid=769761&group_id=9368
Category: Installation
Group: Future
>Status: Closed
>Resolution: Fixed
Priority: 4
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: Jason Brechin (brechin)
Date: 2004-02-24 13:19
Message:
Logged In: YES
user_id=274641
Tk is going away, perl-Qt is here to stay! The bug is no
longer a problem...
----------------------------------------------------------------------
Comment By: Jason Brechin (brechin)
Date: 2003-07-18 09:42
Message:
Logged In: YES
user_id=274641
There are also no updates while running big scripts (like
install_server)...
I don't think this is necessarily a problem that we should
spend much time on right now, since perl-Qt offers better
functionality that will solve this problem. The next release of
OSCAR will likely be switched over completely to Qt (right?).
----------------------------------------------------------------------
Comment By: Jason Brechin (brechin)
Date: 2003-07-16 09:30
Message:
Logged In: YES
user_id=274641
$window->update();
That should update the given window.
----------------------------------------------------------------------
Comment By: Jeff Squyres (jsquyres)
Date: 2003-07-16 08:50
Message:
Logged In: YES
user_id=11722
Actually -- I forgot to ask...
What's the Right function to call to make Tk just do window
refreshes and whatnot? i.e., what should I use in place of
the do_gui_updates() pseudocode function that I listed?
----------------------------------------------------------------------
Comment By: Jeff Squyres (jsquyres)
Date: 2003-07-16 08:49
Message:
Logged In: YES
user_id=11722
Good point about the handles, etc. I'm sure we can work
around this to make the new process be wholly new process,
unrelated to the parent (other than by getppid()). After
all, that's all that system() does.
I'll see if I can make this happen while I'm doing testing,
and will keep you posted.
----------------------------------------------------------------------
Comment By: Terry Fleury (tfleury)
Date: 2003-07-16 08:36
Message:
Logged In: YES
user_id=116599
It's not just a simple matter of doing a "fork" with an
event-driven GUI. Since the child process inherits all of
the parent's object pointers (to all of the windows,
buttons, etc.) when the child exits and destroys these
pointers, the parent no longer has valid object pointers.
You don't have this problem with non-gui stuff. The way it
was handled in the MAC collection window was to have a very
tight loop where there is a fork for tcpdump (notice
non-gui) and all events are processed manually within the
loop, thus allowing no possibility of any other event
routines to be called. I wrote the Qt stuff to be very much
event-driven and when I tried to do a fork() for the Opder
(to launch opd in the background), I had the sorts of
problems where object references were no longer valid when
the child process exited. Fortunately, Qt has a "Process"
object to handle situations where you want to call another
executable and monitor its output.
However, if you are more experienced than I in the ins and
outs of "fork" and you are confident that you can get fork
to work properly with the Tk/Qt GUIs, please implement it
and submit it. I would be interested in learning how to do
it. Thanks!
----------------------------------------------------------------------
Comment By: Jeff Squyres (jsquyres)
Date: 2003-07-16 07: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 13: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
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel
