3 Responses to “winpop not functional?”

1. admin says:

   March 3 at 11:00 am

   In article <1k618iINN…@darkstar.UCSC.EDU> mmco…@cats.ucsc.edu (Michael M Cohen) writes:
   

   >On crimson-vgx 4.0.5, displaying several audio
   >signals in separate overlapping windows.
   >winpop(wid); does not pop windows to the top
   >(or show any change at all). Any hints?
   >Is winpop obsolete in Xwin environ?
   >    MMCohen

   I’ve found winpop to work, but not quite as expected, under 4.0.[1-5].
   Used inside a program (to allow snapshotting), it seems to be necessary
   to wait a bit, e.g.
           winpop();
           sginap(10);
           redraw_window();
           system("scrsave …");
   before the window actually pops to the top — omitting the sginap()
   typically causes the redrawing to happen *before* the window pops.
   I’m guessing this happens because the window manager needs to intervene
   to actually raise the window.  If that’s true, a finite delay probably isn’t
   guaranteed to work.   True?  Anyway, does this fit what you’re seeing?

       Stuart Levy, Geometry Center, University of Minnesota
       sl…@geom.umn.edu
2. admin says:

   March 3 at 11:00 am

   >In article <1k618iINN…@darkstar.UCSC.EDU> mmco…@cats.ucsc.edu (Michael M Cohen) writes:

   >On crimson-vgx 4.0.5, displaying several audio
   >signals in separate overlapping windows.
   >winpop(wid); does not pop windows to the top
   >(or show any change at all). Any hints?
   >Is winpop obsolete in Xwin environ?
   >    MMCohen

   Just to follow up, my problem was doing
     winpop(wid);
   rather than the correct
     winset(wid); winpop();
   RTFM !!!

   MMC
   —

   ======================================================================
   =   Dr. Michael M. Cohen                   mmco…@dewi.ucsc.edu     =
   =   Program in Experimental Psychology     mmco…@fuzzy.ucsc.edu    =
   =   433 Clark Kerr Hall                    408-459-2655 LAB          =
   =   University of California – Santa Cruz  408-459-2700 MSGS         =
   =   Santa Cruz, CA 95064                   408-459-3519 FAX          =
   ======================================================================
3. admin says:

   March 3 at 11:00 am

   In article <C1s5xp….@news.cis.umn.edu>, sl…@geom.umn.edu (Stuart Levy) writes:

   |> In article <1k618iINN…@darkstar.UCSC.EDU> mmco…@cats.ucsc.edu (Michael M Cohen) writes:
   |> >
   |> >On crimson-vgx 4.0.5, displaying several audio
   |> >signals in separate overlapping windows.
   |> >winpop(wid); does not pop windows to the top
   |> >(or show any change at all). Any hints?
   |> >Is winpop obsolete in Xwin environ?
   |> >      MMCohen
   |>
   |> I’ve found winpop to work, but not quite as expected, under 4.0.[1-5].
   |> Used inside a program (to allow snapshotting), it seems to be necessary
   |> to wait a bit, e.g.
   |>   winpop();
   |>   sginap(10);
   |>   redraw_window();
   |>   system("scrsave …");
   |> before the window actually pops to the top — omitting the sginap()
   |> typically causes the redrawing to happen *before* the window pops.
   |> I’m guessing this happens because the window manager needs to intervene
   |> to actually raise the window.  If that’s true, a finite delay probably isn’t
   |> guaranteed to work.   True?  Anyway, does this fit what you’re seeing?
   |>
   |>     Stuart Levy, Geometry Center, University of Minnesota
   |>     sl…@geom.umn.edu
   

   Stuart is correct. Winpop sends a ConfigureWindow request to the X server,
   which redirects it to the window manager. It’s up to the window manager
   to decide what to do with the request. Unfortunately, different window
   managers do different things with the request. 4Dwm raises the window, and
   generates a synthetic ConfigureNotify event for the original client. Twm, on
   the other hand, raises the window but does not generate a ConfigureNotify
   event. This makes it very difficult for the GL to do something reasonable
   in order to guarantee that the winpop command has completed before returning
   control to the user. Note that you would only get Expose events (REDRAW in
   GL-speak) if the window was obscured to begin with.

   Calling sginap is only a partial work-around, because there’s no way to
   guarantee that the winpop has completed, even in a reasonable amount of time.
   For example, the X server could be processing a long request, or the
   window manager could be busy (e.g., if it’s in the middle of interactive
   window placement). A better strategy is to only draw when you get REDRAW
   events. You’ll only get these if the window was obscured to begin with, and
   after the winpop has completed.

   Peter Daifuku
   daif…@sgi.com