XFWM4 Window Problems, Part Deux

Wed Nov 15 12:39:59 CET 2006

Guys umm, Ok well FWIW i am running the latest beta, and it is being
experienced not only by me.

I just wanted to generally take a point on something of which i think that
is going on within XFWM4 but i can't prove it yet as i haven't read the
code.

The former issue basically was that we couldn't use
gtk_widget_set_size_request() on a window which had certain geometry
constraints, but had to use set_default_size ().

The result was that the window started to shrink once mapped, until it could
shrink no more (to the smallest possible size XFWM4 would allow itself.)

Olivier's explanation was that the window didn't obey the geometry
constraints initially, and hence XFWM4 "clamped" it into those constraints.
He failed, however, to point out the exact specs that XFWM4 implemented and
which are recommended by whatever that mandate that a WM should behave so.
It _may_ make some sense from SOME point of view to do that, but as long as
no spec _mandates_ it it is something to which i am coming now, namely:

** I think XFWM4 doesn't quite get the separation between policy and
mechanism..
Yeah you think this is a little nuts but before you think so read a little
further.

For one i think you guys keep too much state around, which window was
minimized/iconified, which window is there and that; surely that is the task
of a WM but i speculate you keep too MUCH state around, beyond what the
normal atoms hold on states and _beyond_ what a WM is meant to do. Of course
every WM can do what it wants sort of but it can reach an area when it stops
implementing a mechanism but starts enforcing policy.

I don't know the exact reasons for this above behaviour, and
<irony>thanks</irony> for "too lazy to check". Man, this is seriously not
how things like these work and it certainly does not give you guys any bonus
points wrt community-friendliness.

If you think you have enough of those points then, well, maybe you have some
credit from OS-cillation (commercial) and Hewlett-Packard (commercial), but
if you just keep ignoring testcases and checks from non-commercial
"entities" then this is just plain nuts as an open source project. If you
think you have enough corporate backers, and QA people who test XFCE and
XFWM4 in a paid fashion and this is enough then you are at a 45 degree angle
missing the goal.

XFWM4 thinks i has to things with windows that reach beyond what other WMs
do and does not only implement a mechanism, but also enforces a policies.
Even within the scope of a WM you can separate policy from mechanism, but i
*certainly* don't wan to go into that with XFWM, it's just too weird of a WM
for me.

You are trying to be a very good WM that can cope with every possible
situation and implement all the specs, but you're doing too much. Why does
this example code (which you haven't tried) work with all other WMs that
i've tested? Are you claiming that KWin or Compiz (Compiz before all;
because it's not just l33t but also a very good, very well implemented
window manager, which 99,9% of all people miss because they think it's just
some kind of leetness toy) aren't standards/EWMH compliant ?

XFWM4 before or all or what? (Even if you think that, then at least stand to
it, and say "We believe blindly that XFWM4 is better than any other WM so
please go away, kthx.")

A solution might be making XFWM4 pluggable, and allowing the extra
functionality that you've implemented which enforces policy and does not
only implement mechanism to be inside plugins:

GCEP: "Geometry Constrains Enforcement Plugin"

Sounds odd? Yes it sounds odd, but that's what you _are_ doing. That window
in the former issue back then was from Gtk+ side just not yet mapped or
whatever, and sizes have not yet been set,  yet XFWM4 already thought it
must intervene and clamp it to the size specified by the constraints, which
failed and forced Gtk+ or maybe XFWM4 itself (Olivier was fabulously
nebulosuly unclear on that matter) to shrink the window until it couldn't
shrink any further.

All that Olivier gave as us an explanation was basically "Well if you do
that, then it will work on XFWM4" (summed up), but failed to point out why
we should do this beyond the scope of XFWM4. Sure, the changes he proposed
didn't break behaviour on other WMs, but why does XMFW4 need special
treatment in this case ? It's rather blunt-off to say this, but it seems to
be rather an XFWM issue to me, then. (Unless Olivier can/could have pointed
it out beyond the scope of XFWM, but he didn't do so.)

And seriously, if anyone asks me here to "first read XFWM4 code" "before i
make any claims", then you first run this testcase and either tell me that
it's wrong or not, and then we're talking.

Sincerely,
M. Derezynski

On 11/15/06, Mike Massonnet <mmassonnet at gmail.com> wrote:
>
> Wed, 15 Nov 2006 08:38:56 +0100 - "Milosz Derezynski"
> <internalerror at gmail.com> wrote :
>
> > Hi Everyone,
> >
> Hello,
>
> > (Don't get me wrong, i'm using XFCE 4.4 beta myself and i think it's
> > an excellent desktop; but i think that XFWM4 is somewhat.. peculiar)
> >
>
>   Well well, Beta has some months behind it, and there is an RC2 out
> now.  I suggest an upgrade, it could be that this was indeed a problem
> (I'm bored to check now) and has been fixed.
>
> > Gordon Froh^W^WMilosz Derezynski
>
> Mike
> --
> http://massonnet.org/ Mike Massonnet (mmassonnet)        _
>                                                        ,_( ))___     (`
> GnuPG 0--" 0xF8C80F97                                  \'    _ `\    )
> C4DA 431D 52F9 F930 3E5B  3E3D 546C 89D9 F8C8 0F97     =`---<___/---'
>
>
> _______________________________________________
> Xfce4-dev mailing list
> Xfce4-dev at xfce.org
> http://foo-projects.org/mailman/listinfo/xfce4-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.xfce.org/pipermail/xfce4-dev/attachments/20061115/7f8e79fd/attachment.html>