Bugs item #769761, was opened at 2003-07-11 12:12
Message generated for change (Settings changed) made by tfleury
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: 4
Submitted By: Jeff Squyres (jsquyres)
>Assigned to: Neil Gorsuch (ngorsuch)
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: 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


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Oscar-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/oscar-devel

Reply via email to