Feature: fix borders for misbehaving applications

[Olivier Fourdan]

Hi,

On Thu, 20 Oct 2022 at 21:00, Cyrille <cyrille at enialis.net> wrote:
>
> From where I stand, this discussion cannot go anywhere.
>
> - Enrico I think you’re too sensitive in your choice of words because of the time invested in your big patch/merge request (I tried to read it, but my level is a bit too low and the merge request too big).
>
> - Xfce, even if used by lots of people (how many?) is still developed by very few people, so any big code addition is scary because it inherently add complexity, maintenance time, more tickets to sort and so on. I hope I got it right. So any big addition (and from what I seen in the merge request, it is) makes any maintainer reluctant to include it unless there are good reasons.
>
> - The reasons highlighted by Enrico are understandable, maybe just not any good enough to integrate such changes.
>
> - Sudden lots of activity in the mailing list, the merge request and the tickets for more-or-less considered no or low priority tasks may irritate some maintainers (by repeating themselves), so the tone is also not that relax as it was some emails ago.

I know it may sound like that, but that's not the point actually,
there are two things here.

1. Force window decorations

This is the actual topic of this thread, this is about
https://gitlab.xfce.org/xfce/xfwm4/-/issues/552 for MS Teams which
uses (ugly, yet functional) client side decorations.

So pretending that this feature prevents users from moving the
windows is just plain wrong.

Client side decorations have been discussed at length in many projects
and that ship has sailed now, a decade ago even, there really is no
point in arguing against CSD now, and in xfce.

FWIW xfwm4 has been supporting CSD for a long time, and will continue to do so.

And it is part of the xfwm4 design to let the application choose if
they want to be decorated (or placed, or sized, etc.). Which takes me
to the second point.

2. Adding features which do not adhere to the project goals and design

It may come as a surprise to some, but some "limitations" in xfwm4 are
on purpose, not just because of lack of time or contributors.

It has been discussed many times in the past, xfwm4 goal is not to
implement every feature to please every single user, there are other
perfectly fine projects that can do that if they will.

For example, xfwm4 is not a tiling window manager, it has some very
basic tiling features, but that's not a tiling window manager, it is
not meant to be. There's very good tiling window managers for those
who want that, but it does not mean that xfwm4 should become one.

Similarly, xfwm4 has no per-application configurations, that's what
fvwm was about, or even sawfish.

xfwm4 tries to limit the number of options to something manageable,
and make sensible choices about defaults.

This is what Havoc explained here https://ometer.com/preferences.html
and I tried (and sometimes failed) to stick to those principles for
xfwm4 from the beginning.

So contributing features that do not adhere to the philosophy of the
project, no matter how good those contributions are, is unlikely to
be accepted.

I completely understand that these (nice) features fulfill the needs
of Enrico, and possibly a few other people, but what matters to me is
does that help the vast majority of xfce users? My impression is that
it does not, even less so with complex configuration in xfconf which
is not designed for this purpose.

>
> I don’t know where this should go now.
>
> I would say (but I’m not maintainer nor regular Xfce developer) :
>
> - divide your big merge request in smaller pieces, one for each goal, one idea at a time
>
> - if some of, or all, your patches/merge requests are not accepted, you could still start by creating patched versions of xfce components involved using the AUR for ArchLinux and derivated distributions, perhaps also other similar packages. That way if this meets success and the patches are solid-enough it could be reconsidered.

Maybe some of these features would be better suited in a separate
project, something we could even host in xfce's gitlab? That would
probably be easier for Enrico to land his changes in his own project.

> All of this is only my sole opinion and may not reflect Xfce team opinion.
>
> If I’m completely mistaken, feel free to ignore this email ;-)
>
> Cyrille
>
> P.S. I, however, love the energy and explanations for your enhancement Enrico. It’s always good to have contributions ;-)

Yes, agreed. But maybe it's time would be better spent in turning xfwm4
into a Wayland compositor, that's a huge change that will require a lot of work.

Cheers



Olivier