Re: [XWEM]: X communication problem?

[Zajcev Evgeny]

Steve Youngs <address@hidden> writes:

> H-x r mozilla RET
> H-a x
> $ mozilla -remote openURL\(http://localhost/,newtab\) RET
> No running window found.

At last i found why this happen.  Same problem exists in ION window
manager.  They write:

  The browsers seem to check the first (lowest) window in each window
  manager frame for whether it is owned by a previous instance of the
  program. Xprop and xwininfo also use the lowest window in the window
  manager frame that was clicked on for the window to display
  information on. Ion arranges for the viewed main window to be the
  lowest so that the window info application will work for the main
  window but being stupid will fail for transients. Similarly the
  browsers will fail if they have no window visible in any frame. Why
  the window info tools don't find the child window of the WM frame
  that was actually clicked on and why the browsers look for their
  windows in such a manner (as far as I know, the ICCCM sets no limits
  on how many client windows are allowed in a single WM frame or how
  many levels of WM windows there are) and don't use e.g. root window
  properties is beyond me.
  
  Instead of mozilla -remote, you could use the gnome-moz-remote
  tool. It seems to use a saner method for locating an already running
  Gecko browser and should work with Mozilla Firefox/Firebird/Phoenix,
  Galeon and maybe other Gecko-based browsers as well.

xwem has also multiple clients in frame and managed client lowered, so
xprop and xwininfo tools works.  I see how to resolve problem.  When
client about to change state(demanage or iconify) it will be
reparented to some particular client-local window and lowers in it.  I
have done this in my local xwem and it works without any noticable
slow down.

-- 
lg