force window decorations on chosen window class (a là kwin)

changed the description

added 5. Window Decorations Patch labels

I am in the same camp, @janp

It should theoretically be possible to restore the decoration with something like devilspie2's decorate_window(), however this doesn't work on Teams.

Another option is to patch the Teams distribution itself. This is the patch I made:

--- a/usr/share/teams/resources/app.asar	2021-03-02 01:39:54.504911801 +0100
+++ b/usr/share/teams/resources/app.asar	2021-03-02 01:40:19.354912259 +0100
@@ -21715,7 +21715,7 @@ function start(rootDir, parsedCommandLin
             options = {
                 webPreferences,
                 show: false,
-                frame: false,
+                frame:  true,
                 titleBarStyle: 'hiddenInset',
                 minWidth: constants.windowMinimumSize.width,
                 minHeight: constants.windowMinimumSize.height

But ultimately, I would prefer if devilspie2 would work. I wonder if there's a bug in Xfwm4 that prevents it from working. undecorate and decorate work fine on windows that have decoration to begin with...

Here's the config:

-- Decorate stupid undecorated windows
-- urgh, doesn't work in Teams
if ( string.find(get_application_name(), "Microsoft Teams") ) then
	decorate_window();
end

Or maybe a generic "force decoration" option would be a good idea for Xfwm4. There isn't a single instance in which I'd want an undecorated window.

On that note, there's a recent fork of devilspie2. I filed this issue in its bug tracker, see here

changed the description

Thank you for your feedback. The only (sigh) that I had so far! Personally I don't want to spend time to hack each misbehaving application. I am using that patch for over two months without problems. The only inconvenient is that, after adding a new window class in the comma separated list, the window manager has to be restarted. It would be cool make the xfwm config being reread upon changes so it can be immediately effective. Maybe some reader knows how to do it in a simple way.

I had a closer look ad the xfwm sources and figured out how to make the changes immediately active.

Attached there is the updated patch. The patch can be applied to the existing sources using the command

patch -p1 < [path to]/xfwm4-xfce-4.16.1.patch2

to build use

$ ./autogen.sh --prefix=/usr #(at least on Arch)
$ make

xfwm4-xfce-4.16.1.patch2

Seems like frame: false is no longer present in app.asar in the latest updates to Teams, which makes this even more problematic. It would really be great if this patch was added, so we could be able to move Teams to different desktops etc.

It's still present, just in a different form and inside minimized code. Use this to patch modern versions of Teams:

sed -z -i -e 's/frame:!1,titleBarStyle:"hiddenInset",minWidth/frame:!0,titleBarStyle:"hiddenInset",minWidth/' usr/share/teams/resources/app.asar

But I agree, it should really be an Xfwm feature.

But I agree, it should really be an Xfwm feature.

And I really strongly disagree.

@olivier

And I really strongly disagree.

In that case, devilspie2 is likely the best approach. Any idea why it wouldn't work on windows that are initially undecorated? Maybe some flag that's missing?

Possibly a race condition, i.e. devilspie and the client fight to set the window properties.

@olivier Hi Olivier, just curious, why do you disagree? Technical or "phylosophical" reasons?

I disagree because it is up to the client to decide, not the window manager.

IOW, better fix the offending applications than implementing workarounds in the window manager.

I guess that falls on the philosophical side, although gating features is an important part of maintaining a project - FWIW, I think xfwm4 already has way too many options (I cannot even remember them all myself!), whereas sensible defaults ¹ should be the norm.

To me, a good example of preferences gone too far is KDE, so citing kwin for an option is usually not a good idea - But KDE is not alone there, I also remember Sawfish which could apply different themes to different windows, eeks!

If you haven't read it yet, please consider reading Havoc's https://ometer.com/preferences.html

I substantially agree with you, having too many preferences could be problematic in several ways. However I find this feature quite useful. Is has lean impact and we could avoid to hack each single offending client to get the desired effect. Anyway I don't want to insist. If it can't be obtained from the upstream I'll keep patching. Thank you for your kind answer.

Imho an universal solution would be very much preferable. If not in the WM, then with an external tool like devilspie2. To that end I'd like to help.

I believe there to be a bug that prevents it from working. It's not a race condition, dp2 can't decorate Teams even if triggered long after Teams has started.

That's is actually something I've already got in mind w/ MR !55

This MR adds basic infrastructure for configuration items matching certain window attributes (class, wm_name, type, ...). So far just implemented initial positioning, but tweaking flags shouldn't be a big deal.

(Edit: removed wrong link that was pointing to ticket instead of MR :o)

mentioned in commit metux/xfwm4@d3d99cee

Update: implemented in !55 Turned out to be trivial, once window policies infrastructure is there.

Yet my point hasn't changed about this.

While your point is probably right in principle, the main issue here is that the application owner (Microsoft, in most cases, I believe) don't want to change their policy regarding window borders and decorations. There are plenty of posts and tickets on different Microsoft forums regarding this, and none of the receive any positive attention from the developers.

And therefore I don't agree that it should be up to the client (if I understand you correctly that the "client" in this case is the application) to decide, it should be up to the user. I, as a user, want to have all my main application windows decorated, and I don't care if Microsoft thinks differently. It it more important that the applications look and behave consistent on my desktop, than whether they look the same on other platforms.

If the application misbehaves, it is extremely helpful if the window manager can ensure that the users preference is overriding bad applications. I would even go as far as saying that without decorations, the window manager can not do it's job, because without borders and title bars you can not use the window manager features on the application window - like moving to different desktops, showing the window above og below other windows etc.

Fixing whatever prevents devilspie2 from working would satisfy both parties here, I think. And be less effort.

I can only agree w/ @Olen: for us, the FOSS community, the user's freedom (which includes freedom of choice) has hard priority over some arbitrary corporation's silly or ignorant marketing jerks.

Preferences on how an desktop environment should look like is very subjective, consistency within a desktop environment is very important to usability. Actually that's one of the most important factors for the MacOS fans being ones in the first place: Apple takes great care about really consistent UI - one doesn't need to love its look+feel, but it is very consistent. We, the FOSS community, can do even better: provide consistency and freedom of choice. But that requires tools to tweak unfriendly applications into the line w/ users choice.

But the issue goes even deeper: why did window managers been invented in the first place ? Simply because before, in the very early days of X, every single application had to implement window management in its own. Very inconsistent user experience and massive code duplication, many incompatibilities that were hard or impossible to fix. This is why window managers have been implemented: provide one central entity that controls the whole window management and relieve applications from this unnecessary massive duplication of code and implementation work. And now we have lots of different window managers, for different use cases or audiences. Users have the free choice. A fundamental core concept of X desktops.

FWIW, I installed MS Teams here, and I can move, resize and stack the window just fine, even if not decorated by the WM, that's what client-side decorations is all about.

So I stand by what I wrote, this is an application choice (if you ask me, it looks fairly ugly, but that's irrelevant) and xfwm4 must stick to that choice.

It might be just me who is stupid, but please tell me how to

"Keep window always on top"
"Keep window on visible workspace"
"Move window to another workspace" etc.

I really don't see your strong reasoning to not allow a minor and pretty non-intrusive modification that improves the user experience.

The client should implement the mechanism required to show the window menu, there is a protocol for that - If it doesn't, it's a client bug.

But you can also use Alt+Space to bring the window menu.

I've had those problem myself many times (complete crashes are even more often), and MS-teams is not the only one. And that's just one tiny example of many.

In general, applications should not mess with window management - that's what window managers are for. (yes, we need sane protocols for additional stuff in the title bar, but that's a whole different discussion) And if they do, users shall have the freedom to work around it.

I don't think anyone (except maybe Microsoft) disagrees that this is a bug in the application(s). The question is if the window manager can be allowed to force applications to behave reasonably and override obviously user-unfriendly choices, when the application developers refuse to fix it. Or, if you want to go the philosophcal path - should the window manager behave according to the wishes of the actual user of the application and window manager, or the application developer?

FWIW, I believe Teams, like many other cross platform MS applications these days, is using Electron, so I think it's more of a problem with Electron.

Anyway, this application is using client-side decorations, and xfwm4 follows whatever the application requests, I think I made very clear that no, the window manager should not force server-side decorations on apps which implement client-side decorations - You would end up with the window controls duplicated and all sort of similar discrepancies.

And again, it may look ugly to some, but none of that is really a blocker to use the application as I explained above.

@Olen: for me it is clear: the ultimate authority shall be the user (or machine owner). Computers and software exist only to serve their users, not the opposite way.

the main purpose of an operating-system is to give apps controlled access to the hardware and to control/limit applications, their windows in special. the OS should not give that control away to applications, unless we as user want it so.

i would like this option in the main xfce4-development-tree...

mentioned in commit metux/xfwm4@ea18e80d

mentioned in commit metux/xfwm4@39b89f47

mentioned in commit metux/xfwm4@c0e010f8

mentioned in commit metux/xfwm4@5956e17f

mentioned in commit metux/xfwm4@e324f529

mentioned in commit metux/xfwm4@75998b83

mentioned in commit metux/xfwm4@fb86cbd5

mentioned in commit metux/xfwm4@6dd4ddef

force window decorations on chosen window class (a là kwin)

Designs

Child items 0

Activity