On Thu, Jul 03, 2003 at 08:12:29AM +0200, Olivier Chapuis wrote:
> Hello,
>
> Ok, this subject is delicate ...
>
> Examples of pb:
>
> - Start Mozilla, say that its position is +x+y. Set fullscreen (F11),
> if you have a not too recent version of Mozilla this works (with
> Mozilla-1.4 and maybe other this does not work as Mozilla use
> NET_WM_FULLSCREEN which is not implemented in fvwm (this not the point
> of this email). Reset to normal state (F11). Then, either Mozilla
> crash or the Mozilla window totally disappear (strange) or the new
> window position is
> +(x-"left_frame_width")+(y-"top_frame_height")
Yes, I noticed some of these problems too. Yesterday I found two
download windows I had shaded on the right side of page (0 1) in
the middle of page (1 2). I still have to find a way to reproduce
this, but chances are good that mozilla is doing something funny.
> - Other Mozilla pbs: resizing the window with the internal Mozilla
> resize grip.
Mine doesn't have a resize grip.
> - Tk experience:
> [EMAIL PROTECTED] olivier]$ wish
> % wm geometry . +0+0
>
> The top-left part of the frame is out of screen
>
> - This problem will happen with any QT, GTK, JAVA and Tk application
> which "move-resize" itself (after mapping).
>
>
> All this applications are not buggy! They all respect the ICCCM2 (or
> at least a really reasonable interpretation of the ICCCM2). Note that
> most of the actively developed window manager respect this (e.g.,
> icewm, kwin and metacity). Also this is documented in the EWMH spec.
>
> Of course fvwm no that, however it use a legacy way to move-resize
> a window because some "old" apps use this legacy logic (sorry I've no
> example, but Dominik has surely some).
See the endless discussions I had on the wm-spec list. The bottom
line of them always was that nobody of the people there cares a
bit about the traditional way vs. the spec conforming way of
handling configure requests. Thus, even with the latest EWMH
spec, manual user intervention is required to configure some
applications :-(
> I suggest that we add a new style:
>
> LegacyConfigureRequest / ICCCMConfigureRequest
>
> or
>
> ICCCMConfigureRequest / LegacyConfigureRequest
> to handle this problem. About default we can do something a bit more
> complex: detect if the app respect the EWMH spec, if yes use
> ICCCMConfigureRequest if not use LegacyConfigureRequest.
Yeah, but the wm-spec folks can't agree on a protocol for this :-P
In addition, it would be really helpful to have a standard way of
advertising which method the WM uses in order to allow
applications to detect it themselves. This would fix most of the
notorious Java... problems with fvwm.
> However, I think we need a new style (as there is no standard
> way to detect that an application respect the EWMH spec).
Having a style is not wrong anyway.
> Any opinions/comments/objections?
For a detection algorithm:
1) If the windows CR algorithm was set by a style or detected
before, use it.
2) If a window resizes itself to the *exact* size of the
display and the requested position of the client window is
either +0+0 or +border_width+border_height, put it at +0+0
and make a decision about the algorithm it uses based on the
requested position.
3) If a window resizes/positions itself so that interpreting its
position would shift it by exactly the width/height of the
left or top border, set the algorithm that would prevent this
shift (if possible).
4) If a window places itself in a way that would place it
exaclty on the border of the display, choose the algorithm
that keeps the border on screen.
So we should have three styles (I don't like the term "legacy"
because it displays a certain arrogance of the wm-spec people
against tradition):
MoveByProgramAlgorithm [SmartTraditional|SmartICCCM|ICCCM|Traditional]
with "SmartTraditional" being the default (i.e. use above
algorithm and use "Traditional" by default). However, the names
of the styles are all bad (hard too understand).
Bye
Dominik ^_^ ^_^
--
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 PROTECTED]
To report problems, send mail to [EMAIL PROTECTED]
