On Tue, Sep 21, 1999 at 12:58:57AM -0500, jason_at_sdf.lonestar.org wrote:
>
> Hi,
>
> I'm running fvwm2.3.8. If I 'WindowShade' a Netscape window, then open
> up another instance of Netscape (using the -remote 'openBrowser()' flag),
> it too is opened up in shaded mode, or so it seems. Because of my
> options, which are below:
>
> ---------
>
> GlobalOpts RecaptureHonorsStartsOnPage, ActivePlacementHonorsStartsOnPage, \
> CaptureHonorsStartsOnPage, NoStipledTitles, \
> SmartPlacementIsReallySmart
>
> Style "Netscape*" Icon netscape.xpm, RandomPlacement, SmartPlacement
>
> ---------
>
> ...the new Netscape window gets placed at the bottom of the screen, so
> that all I see is the titlebar. From both my and FvwmPager's points of
> view, this new window looks to be WindowShaded. But it isn't because if I
> move to the screen below, there is the new Netscape window in plain view.
> (The new window doesn't show up in FvwmPager until I move it, for some odd
> reason.)
>
> But wait, there's more. The new window is not the correct geometry. In
> fact, FvwmIdent reveals that it is of size 1018x32744. No, that is not a
> typo. :-) (It should be 1018x683, which is the un-WindowShaded size of
> the original Netscape window.)
>
> Now, I'm not convinced that this is an fvwm2 bug because I get the
> expected results when I 'WindowShade' a Netscape window, then use Alt-N
> (while over its titlebar) to open a new browser window. Both the Alt-N
> and "-remote 'openBrower()'" methods work as expected when the original
> Netscape window is not WindowShaded. The only time this happens is when
> the original Netscape window is WindowShaded, *and* the "-remote
> 'openBrower()'" method is used to open a new browser window. Maybe the
> new window is looking for the original window's geometry, but it's
> something weird and unexpected (in my case, 1018x-3) so it doesn't know
> quite what to do? If so, can fvwm2 'fake' the geometry, telling the new
> window instance what the un-WindowShaded geometry of the original window
> would be, instead of the 'bogus' 1018x-3 geometry? Or does the X server
> handle these type of inquiries? Hmm... I hope I'm making sense. Let me
> know if any info or clarifications are needed.
Eeek, another application that can't handle windowshaded windows.
XEmacs has the same quirk sometimes. The reason is that netscape
queries its own geometry - which is kind of screwed up when the
window is shaded. It takes the old window's height - which is
around zero, subtracts the height of the frame drawn by fvwm
which is usually about 20 to 30 pixels and uses the result
(-20 to -30) pixels to create a new window. The negative number
is interpreted as a very large positive number in the request
and fvwm limits the height to its max value.
Unfortunately I can't see what we can do about it. Of course
fvwm could prevent the window from becoming 32767 pixels high,
but if the window requests a screwed up geometry, fvwm is unable
to guess the correct height.
In the file events.c you will find these lines:
if (cre->value_mask & CWHeight &&
/* patch to ignore height changes to astronomically large windows
* (needed for XEmacs 20.4) */
Can you please add the following line before it:
if(cre->value_mask&CWHeight)fprintf(stderr,"cr: height=0x%x\n",(int)cre->height);
And send me the output this generates when you open the screwed up
window?
Bye
Dominik ^_^
--
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, dominik_vogt_at_hp.com
--
Visit the official FVWM web page at <URL: http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Tue Sep 21 1999 - 06:23:01 BST