🚀 go-pugleaf

In article ... crj10@phx.cam.ac.uk (Clive Jones) writes:

  In article ..., kers@hplb.hpl.hp.com (Chris Dollin) writes:
  > What is the *advantage* of defining a window to be a pane? I mean, when you
  > move the parent window, you have to move the pane *yourself* -- the WIMP
  > doesn't do it for you. What does making it a pane give you over making it
  > an ordinary window and tracking opens of its logical parent?
  > 
  > I read the WIMP section of the PRM several times, looking for an answer, 
  > some time ago, but found one not. Can anyone enlighten me?

   Look on page 1151 of the RO2 PRMs! Basically, panes *are* entirely up to the
   application to handle. The pane bit is only used:

     To highlight the tool window if the pane gets input focus
     To treat a pane as transparent if toggling the tool window's size

   The explanation also, incidentally, remarks that care should be exercised in
   choosing the order of window opening to avoid unnecessary redraws...

Looks to me, then, that a summary of your answer is "none" [*1]. (I read p1151.
Given all the other stuff you have to do, giving the main window the focus when
inside the pane is no big deal. And what does it mean, ``treating the pane as
tranparent when toggling''?)

[*1] Ie, there's no point in bothering with panes.
--

Regards,    | "C gains much of its vaunted efficiency by employing a very
Kers.       | powerful pre-processor, usually called a ``programmer''."