Subject: Re: Some windows 'ignored'

From: [email-masked]
Date: Thu, 18 Mar 1999 09:27:37 -0500

Brad Giaccio <[email-masked]> wrote:
> Bob, Since we get so many requests about this could we put the patch
> somewhere in the distribution for people so it all stays together,
> and then make a FAQ entry (if there isn't one already) about it?

     I was planning to hack the option into the current CVS source in the
next couple of
days. The change includes man page documentation; but you're right, there
should be a
FAQ entry on this as well. So, the feature should be in the next dist, no
assembly required.

     I'm not sure how this will interact with the new layer paradigm,
though. I haven't had
much chance to look at the new layer stuff. I've been too busy trying to
get my standard
config to work again (are decors with gradients/pixmap textures supposed to
be working
again now? - mine don't).

- Bob

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Thu, 18 Mar 1999 14:32:06 +0000

> again now? - mine don't).

What's broken?

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 18 Mar 1999 09:49:37 -0500

On Thu, Mar 18, 1999 at 02:32:06PM +0000, Tim Phipps wrote:

> [email-masked] wrote:
>
> > config to work again (are decors with gradients/pixmap textures
> > supposed to be working again now? - mine don't).
>
> What's broken?

well 
AddToDecor <decor> 
+ Widowfont fixed

definetly fails

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Thu, 18 Mar 1999 10:07:15 -0500

> > > supposed to be working again now? - mine don't).

And, I we found that

AddToDecor <decor>
AddToDecor <decor> Widowfont fixed

works, so this is listed as a "+" problem.  I'm not sure but
I think Dominik indicated that he might have caused this and
was going to look into it.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Tim Phipps <[email-masked]>
Date: Thu, 18 Mar 1999 15:08:39 +0000

> definetly fails

Hmm, it works for me. Have you tried it all on one line?

Cheers,
Tim.

---

From: Matthias Clasen <[email-masked]>
Date: Thu, 18 Mar 1999 16:15:22 +0100

>From a quick look at the patch, it won´t work at all like this with
layers. We will need a different idea, perhaps a new command
to move override-redirects in a specific layer or just a global
option to make the Layer/Raise/Lower commands also work on 
override-redirects. For this to make sense, there would have to be
a way to determine the layer of an o-r window. Proposal: the layer of
an o-r window is the layer of the next lower managed window in the stacking
order.

This seems to be a borderline case for the principle of leaving 
o-r windows alone, since the stacking order is not really a per-window
resource, but rather something global.

Matthias

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 18 Mar 1999 16:21:32 +0100

> was going to look into it.

Er, um, did I? I can't remember. I had some trouble setting up
my new machine in the last two days and had no chance to touch
any code. It might be quit a while before I find time for this,
so if anybody else looks after this I'd be grateful.

Bye

Dominik

-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 18 Mar 1999 11:53:18 -0500

> Hmm, it works for me. Have you tried it all on one line?
 
The problem was 
+IconFont fixed

I realize it works all on one line the anitial problem was that bob and
I had both had broken configs with the new start logic I we both finally
traced it down to doing AddToDecor followed by pluses now this used to
work right up until the new start stuff.  So both of us have replaced
those pluses with AddToDecor's the complaint was that the shortcut no
longer works

---

From: Bob Woodside <[email-masked]>
Date: Thu, 18 Mar 1999 18:28:25 -0500

> AddToDecor <decor> Widowfont fixed

	Sorry I didn't have a chance to reply earlier in the day - I got tied
up at work (gee, sounds like my department must be kinda kinky :-) ).

	Yes, it's still the old "+" problem.

- Bob

---

From: Bob Woodside <[email-masked]>
Date: Fri, 19 Mar 1999 00:36:56 -0500

Matthias Clasen wrote:
> layers.

	Can't say that I'm surprised.

> We will need a different idea, perhaps a new command to move
> override-redirects in a specific layer or just a global option to
> make the Layer/Raise/Lower commands also work on override-redirects.

	Before we could do that, we'd have to make the heretical decision to
provide a non-standard, deprecated option to manage such windows in
spite of the app's instructions. As it is, they're not part of FVWM's
known universe, and events associated with them are just singular blips
from across the event horizon.

> For this to make sense, there would have to be a way to determine
> the layer of an o-r window. Proposal: the layer of an o-r window
> is the layer of the next lower managed window in the stacking order.

	I was thinking more along the lines of being able to define a layer
with the property of being eligible to be raised above non-managed
windows.

- Bob

---

From: Matthias Clasen <[email-masked]>
Date: Fri, 19 Mar 1999 12:25:57 +0100

> from across the event horizon.

We won't get any ...Requests from the server for them, thus managing them
will not be possible. If we want to go that route, I'd propose to write
a little tool xmanage which would allow to select a toplevel window 
(like xprop does) and unset the override-redirect flag on it. The fvwm
can start managing the window after recapturing.

This would keep fvwm cleanly ICCCM-compliant (with some little helper
doing the dirty work :-)

I don't know how well applications would grok their override redirect windows
being managed by the wm though. I would expect them to be very surprised
by anything other than a move or stacking-order change. This is probably all
fvwm should ever do to such formerly-override-redirect windows.

Matthias

---

From: Tim Phipps <[email-masked]>
Date: Fri, 19 Mar 1999 13:34:06 +0000

> can start managing the window after recapturing.

This sounds good, it's a shame that it would require a recapture though.
I don't like the way recapture loses state (i.e. it resets window states
back to the initial style). There is an enhancement request for a
recapture that reuses the FvwmWindow list.  I don't know how difficult
that would be to implement. If it's too difficult maybe a Capture
command is called for that just goes looking for uncaptured windows.

Cheers,
Tim.

---

From: Matthias Clasen <[email-masked]>
Date: Fri, 19 Mar 1999 14:45:29 +0100

> command is called for that just goes looking for uncaptured windows.

If it is simply to make fvwm aware of the formerly-override-redirect,
couldn't the hypothetical xmanage simple unmap/map the window after
removing the override-redirect ? I can't imagine what consequences
that could have for the offending client.

The Capture command would also be nice. And it should be possible to
reuse most of fvwm's initial capture code for that (you just have
to add a way to skip already-managed windows).  We could even
remove the builtin capture-at-startup and just call fvwm -f Capture...
hmm, could this perhaps even help to solve the problems with the 
initial capture happening too early ?

Matthias

---

From: [email-masked] (Paul D. Smith)
Date: 19 Mar 1999 09:09:26 -0500

I can barely follow the discussion here, but to me we seem to be getting
beyond the boundaries of what I think is appropriate for a 2.4 release;
are you guys thinking of making these major changes soon?  I'd like to
request they maybe go on a branch or be deferred until 2.5.x starts up.

If I understand things correctly we seem to be _really_ going out of our
way to implement very complex functionality to handle a very, very small
subset of windows; I don't think I have _any_ (except maybe a splash
screen or two) in all the apps I use.

I'd prefer to get what we have now stable, plus the GNOME patches and
_maybe_ the GSFR stuff if we can come to a resolution on that, and
seriously consider calling that 2.4.0.

Thoughts?

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <[email-masked]>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dan Espen <[email-masked]>
Date: Fri, 19 Mar 1999 12:11:26 -0500

> seriously consider calling that 2.4.0.

OK, these are "thoughts", sorry if they are all over the place.

If there   is  one feature slated     for 2.3 that   people  have been
requesting its the GNOME  stuff.  (I have no current  use for it.)  Do
we have a target date for that?   I know Jay  was doing some debugging
with the GNOME people.  Even after the patch  is applied, do we have a
feel for how long it will be before the  GNOME stuff will be ready for
beta test?

I think we have  to go  through long periods  of instability,  and now
seems like a good time for it.  On the other hand, there are some neat
enhancements in the NEWS file.  And, (I seem to have one more hand), I
think our users are still digesting 2.2.

As  far as creating   2.4 and making the   transition to 2.5 aren't we
pretty far away from that?  We haven't decided on  a 2.3 beta yet, and
we aren't in a state where thats feasible.

As far as splash screens go, FvwmBanner is a "splash screen".  Perhaps
it should have an option to create itself as an unmanaged screen so we
could get a better idea what this "problem" is all about.

> -- 
>  Paul D. Smith <[email-masked]>         Network Management Developmen

---

From: Matthias Clasen <[email-masked]>
Date: Sat, 20 Mar 1999 21:30:16 +0100

I'd be interested to hear if the following little program solves
everybodies problems with windows stuck at top of stack. In particular,
I don't know if it solves the problems with Exceed (are the non-X windows
override-redirect, technically ?). If this is the case, I'd propose 
to leave fvwms stack handling as it is now and put this program in 
the utilities dir together with a FAQ entry. 

What it does is: it lets you select a  top-level window and
toggles the override-redirect flag on it. This, together with
a unmap/map pair, lets fvwm get control over override-redirect 
windows. It is of course likely that using arbitrary window
manager functions on an o-r window will crash the client, 
but raise/lower/move are probably safe. 

I have also appended a minimal test-case program which puts
an override-redirect window permanently at top of stack.

--------------------------
/* xmanage.c */
#include <stdlib.h>
#include <stdio.h>

#include <X11/X.h>
#include <X11/Xlib.h>
#include <X11/Xmu/WinUtil.h>
#include <X11/cursorfont.h>

int x_error (Display *dpy, XErrorEvent *e)
{
  char buf[1000];

  XGetErrorText (dpy, e->error_code, buf, 1000);

  printf ("X Error:\n\tserial %i\n\terror code %i\n\trequest code %i\n\tminor
  code %i\n\t resource id %i\n\terror text %s\n",
        e->serial,
        e->error_code,
        e->request_code,
        e->minor_code,
        e->resourceid,
        buf);
}

Window
select_window (Display *dpy)
{
  int status;
  Cursor cursor;
  XEvent event;
  Window win = None;
  Window root = DefaultRootWindow (dpy);
  int buttons = 0;

  /* Make the target cursor */
  cursor = XCreateFontCursor (dpy, XC_crosshair);

  /* Grab the pointer using target cursor, letting it room all over */
  status = XGrabPointer (dpy, root, False,
                         ButtonPressMask|ButtonReleaseMask, GrabModeSync,
                         GrabModeAsync, root, cursor, CurrentTime);
  if (status != GrabSuccess)
    {
      fprintf (stderr, "Can't grab the mouse.\n");
      exit (1);
    }

  /* Let the user select a window... */
  while ((win == None) || (buttons != 0))
    {
      /* allow one more event */
      XAllowEvents (dpy, SyncPointer, CurrentTime);
      XWindowEvent (dpy, root, ButtonPressMask|ButtonReleaseMask, &event);
      switch (event.type)
       {
        case ButtonPress:
         if (win == None)
          {
             win = event.xbutton.subwindow; /* window selected */
          }
         buttons++;
         break;
        case ButtonRelease:
         if (buttons > 0) /* there may have been some down before we started
  */
         buttons--;
         break;
       }
      }

    XUngrabPointer (dpy, CurrentTime);      /* Done with pointer */

    return win;
}

int
main (int argc, char **argv)
{
  Display *dpy;
  Window root, win = None;
  XWindowAttributes attr;
  XSetWindowAttributes s_attr;
  int dummyi;
  unsigned int dummy;

  dpy = XOpenDisplay (NULL);
  XSetErrorHandler (x_error);

  win = select_window (dpy);
  if (win == None)
   {
     XBell (dpy, 50);
     exit (1);
   }

  if (XGetGeometry (dpy, win, &root, &dummyi, &dummyi,
                    &dummy, &dummy, &dummy, &dummy) &&
      win != root)
   {
     win = XmuClientWindow (dpy, win);
   }

  XUnmapWindow (dpy, win);

  XGetWindowAttributes (dpy, win, &attr);
  s_attr.override_redirect = !attr.override_redirect;
  XChangeWindowAttributes (dpy, win, CWOverrideRedirect, &s_attr);
  XMapWindow (dpy, win);

  XCloseDisplay (dpy);
  return 0;
}

----------------------------
/* teaser.c */
#include <X11/X.h>
#include <X11/Xlib.h>
#include <X11/Xatom.h>
#include <X11/Xutil.h>

int
main (int argc, char **argv)
{
  Display *dpy;
  Window win;
  XSetWindowAttributes attr;
  unsigned long mask;

  dpy = XOpenDisplay (NULL);

  attr.background_pixel = BlackPixel (dpy, DefaultScreen (dpy));
  attr.override_redirect = 1;
  mask = CWBackPixel | CWOverrideRedirect;

  win = XCreateWindow (dpy, DefaultRootWindow (dpy),
                        0, 0, 600, 400, 0,
                        CopyFromParent, /* depth */
                        CopyFromParent, /* class */
                        CopyFromParent, /* visual */
                        mask, &attr);
  XMapRaised (dpy, win);

  XSetCloseDownMode (dpy, RetainPermanent);
  XCloseDisplay (dpy);

  return 0;
}

---

From: Matthias Clasen <[email-masked]>
Date: Thu, 25 Mar 1999 21:43:29 +0100

Has anybody with access to X-under-that-other-windowing-system
tried my utility to put override-redirect windows under wm control ?

I'd be interested to hear if it helps.

Matthias

---

From: Tim Phipps <[email-masked]>
Date: Fri, 26 Mar 1999 09:43:29 +0000

> tried my utility to put override-redirect windows under wm control ?

These are two seperate problems.  The problem with X-servers on NT is
that NT windows are outside the X universe.  There is nothing that can
be done via X to manage them.  The only way to get an X window above
them is to do an XRaiseWindow which I think is incompatible with layers.

The other problem is with X windows that have override-redirect when
they really shouldn't.  I thought o-r was for menus only but it seems
like some programs have a ego problem and think they have a right to
force their behaviour on the user.

xmanage works nicely on Eterm.  I think it should go in utils but I'm
not sure if everyone has libXmu.  Coule it be rewritten to only use
Xlib?

Cheers,
Tim.