Subject: Java floating JToolBar

From: Olivier Chapuis <[email-masked]>
Date: Wed, 26 Feb 2003 11:57:27 +0100

Hello,

A JToolBar is a tool bar that you can extract from the main java Frame
and can become an independent window (and you can put it back). With
my SUN Java 1.3.1 when I extract such a JToolBar, I get a 1x1
window. The explanation is simple, xprop gives:

WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified location: 70, 641
                program specified size: 250 by 23
                program specified minimum size: 1 by 1
                program specified maximum size: 1 by 1
                window gravity: NorthWest

This is exactly bug #707 (and #654, the first part of #863 and #714
are maybe caused by such broken hints). ResizeHintOverride fixes this
problem.  However, as the size hints are clearly broken we may want to
ignore these hints (and generate a broken size hints msg) and use the
the size given by XGetWindowAttributes.

Is this a good idea?

By the way, an other Java bug here is that when you extract the
toolbar for the second times its initial state is iconic (but the size
hints are correct ...). There is nothing to do at fvwm level I think,
however at the Java level you can do something like this:

toolbar.addAncestorListener(new AncestorListener(){
  public void ancestorAdded(AncestorEvent event)
  {
    Frame frame = (Frame)SwingUtilities.getWindowAncestor(event.getAncestor());
    if(!(frame instanceof ConsoleWindow))
    {
      if (frame.getState()==Frame.ICONIFIED)
        frame.setState(Frame.NORMAL);
    }
  }
});

where ConsoleWindow is the frame which "contains" the JToolBar. 
Also, when you move the toolbar with the grip you see a window
which follows the cursor only when you extract the JToolBar for
the first time. Again I think that this is a Java bug, but ...

Olivier 
--
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: Wed, 26 Feb 2003 12:16:29 +0100

> the size given by XGetWindowAttributes.

You can't rely on XGetWindowAttributes to have the correct values.
But we could completely ignore the the max_... size hints if

  * A maximum size of 1x1 was specified

AND

  * The requested size is larger than that.

Bye

Dominik ^_^  ^_^

---

From: Olivier Chapuis <[email-masked]>
Date: Wed, 26 Feb 2003 22:15:19 +0100

> You can't rely on XGetWindowAttributes to have the correct values.

Hum. Why? Do you mean that in AddWindow (add_window.c) the initial
size we get can be broken vs the size hints and after that the
application send a configure request which fixes the size of the
window relatively to these hints? 

>   * A maximum size of 1x1 was specified

What about being a bit more aggressive (see bug report #863): If max
size "<" requested size and the requested size is reasonable, say "=<"
the screen size then ignore the max size hints?  Or
  "* A maximum sizeof BROKEN_MAXSIZE_SIZExBROKEN_MAXSIZE_SIZE was specified"
with BROKEN_MAXSIZE_SIZE ~ 50.

Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 27 Feb 2003 09:04:16 +0100

> window relatively to these hints? 

Yes.

> the screen size then ignore the max size hints?

I am sure there are applications that can't calculate their
initial geometry properly and rely on the hints.  emacs and xemacs
are good candidates.

> Or

It is hard to guess which values are broken and which are not.  An
image editing program might well set the max size hints to 16x16
when editing a pixmap of that size.  I'd say we start with the
least aggressive setting and thing of a more aggressive approach
only when problems arise.  Remember, the bug *is* in the
application, and we are breaking the specs by patching fvwm, so we
should keep the possible effects to the bare minimum required.

Bye

Dominik ^_^  ^_^