MPV 0.31 Video Player Adds Pseudo Client Side Decorations, Wayland Improvements

[Gusar]

They kinda are already doing it on macOS though.

https://github.com/mpv-player/mpv/bl...cocoa/window.m

NSWindow is part of AppKit, a toolkit.

But they're using NSWindow for more than just decorations right, it's used for all OS interaction. Whereas GTK would be needed *just* for decorations, while everything else can be handled by lower-lever interfaces - X calls or Wayland protocol calls or even KMS/GBM calls. And even GTK isn't actually needed if Mutter devs implement the xdg-decoration protocol.

[Britoid]

But they're using NSWindow for more than just decorations right, it's used for all OS interaction. Whereas GTK would be needed *just* for decorations, while everything else can be handled by lower-lever interfaces - X calls or Wayland protocol calls or even KMS/GBM calls. protocol.

You could use GTK/GDK for interactions too, in which you'd have the benefit of supporting anything GTK/GDK supports and wouldn't need to implement any display server protocols. As far as I understand though, GTK right now doesn't make this as easy (or performant) as Application Kit/Cocoa does though.

You could also directly talk to the Quartz compositor if you really wanted to, but I don't think that's recommended and it's a private API.

And even GTK isn't actually needed if Mutter devs implement the xdg-decoration protocol.

This is probably never going to happen, and it's equally politics and technical reasons as to why. Mutter has gone down the macOS route, that the compositor shouldn't be drawing parts of applications and that applications should interface via the native toolkit. Something like libdecoration might help though for applications that want to interface directly with the display server without linking GTK, which is a compromising solution.

[tildearrow]

People love them because they think it gives you the macOS-like application distribution under Linux, but the technology is really really bad and not comparable to how macOS does it. So these reasons listed here are purely technical.

1) They're not guaranteed to run everywhere, unlike say a Flatpak, because AppImages are often compiled for an Ubuntu LTS which is nearly-always incompatible with a fast-moving distro like Fedora or Arch. This means the application author has to always keep trying to see what dependencies they can and can't bundle, which is painful to the point they give up in the end (Stremio, Peek etc dropped their AppImages).

Exactly! Sometimes they end up packaging pretty much the whole OS with the program in the AppImage... which results in a binary that is up to 3 times bigger than even their macOS counterparts (see LMMS).

2) FUSE... it uses FUSE to mount the application files at startup which causes multiple issues. It will slow the application startup quite significantly and because each subsequent launch remounts the files as a fresh mount, you'll loose any benefit of filesystem cache (the app won't launch faster the second time). It also doesn't work in envrionments where FUSE isn't enabled, which is fairly common in enterprise envrionments.

I never thought they used FUSE for the mounting process...

3) It's often bundle bingo in terms of what dependencys are bundled, I've seen AppImages bundle OpenSSL, GnuTLS, libcurl etc which is an awful idea for security reasons, compared to Flatpak where these come from mantained runtimes.

Does it matter? Developers in macOS/Windows land also bundle those libraries with their apps, and nobody complains?...

4) No native sandboxing, you can enable services that track AppImages on the disk and try and sandbox them with firejail, but this doesn't work as cohesive as sandboxing in Flatpak.

Flatpak: Forced sandboxing
Snap: I'm not sure
AppImage: Can be sandboxed, but done by application
Windows executable: Same as AppImage
macOS bundle: Best choice. Can be sandboxed, done by system.

5) Desktop intergration. The AppImage does self extract a desktop file, but it won't pick it up when you delete it. Again, you can add more services that watch the filesystem for new AppImages, which then executes them to extract desktop files, this is a big security issue. Flatpak natively intergrates with the various XDG standards. System-installed AppImages are also a pain to install.

I wish they would go the macOS way...
Like, dropping the AppImage to some apps directory and that's it...

6) They promote a bad security practice of setting things you download as executable and running them, this is how people stupidly install malware.

Not only it is a bad practice, but also is Average Joe-unfriendly. Who thought having to "make it executable" was a good idea?
I mean, any Windows user normally just downloads their app and runs it... like no need to "make it executable" or any of that stuff...


I really hate mentioning them, but I think Apple made the best application packaging scheme ever...

[ssokolow]

Not only it is a bad practice, but also is Average Joe-unfriendly. Who thought having to "make it executable" was a good idea?
I mean, any Windows user normally just downloads their app and runs it... like no need to "make it executable" or any of that stuff...

It means that, barring a buggy or badly designed viewer tool (I'm looking at you, MS Office macros), it's safe for an average Joe to just blindly double-click a file that was sent to them.

[flux242]

I wish they would go the macOS way...
Like, dropping the AppImage to some apps directory and that's it...

so they did https://github.com/AppImage/appimaged/
If I'm not mistaken appimaged looks for a default firejail profile and loads it if exists

and no, no FUSE were needed to mount squashfs last time I checked. That guy speaks gibberish
Usually the problem is not the AppImage but firejail profiles. If an app won't start with provided profile it's pita to figure out why.

And I like separation of concerns here - appimage for packaging and firejail for sandboxing. Both parts can be used independently.

[Britoid]

Does it matter? Developers in macOS/Windows land also bundle those libraries with their apps, and nobody complains?...

Well macOS and Windows have stable ABIs (less so for macOS lately) and you can always be 100% sure what's going to be on a users system. If a Windows or mac app was shipping its own copy of OpenSSL, then yeh I would still think that's bad.

I really hate mentioning them, but I think Apple made the best application packaging scheme ever...

Yeh. Their entire system is set up and designed around it though.

[Britoid]

so they did https://github.com/AppImage/appimaged/
If I'm not mistaken appimaged looks for a default firejail profile and loads it if exists

and no, no FUSE were needed to mount squashfs last time I checked. That guy speaks gibberish
Usually the problem is not the AppImage but firejail profiles. If an app won't start with provided profile it's pita to figure out why.

And I like separation of concerns here - appimage for packaging and firejail for sandboxing. Both parts can be used independently.

I'm not speaking jiberish, https://github.com/AppImage/AppImageKit/wiki/FUSE literally states "AppImages require FUSE to run. Filesystem in Userspace (FUSE) is a system that lets non-root users mount filesystems."

So please take back your comment.

[Britoid]

It means that, barring a buggy or badly designed viewer tool (I'm looking at you, MS Office macros), it's safe for an average Joe to just blindly double-click a file that was sent to them.

This my friends, is how ransomware was born.

[flux242]

So please take back your comment.

sorry, I can't because

The appimaged daemon described here 30 now uses an existing installation of firejail to run AppImages without the need of making them executable. firejail, in turn, uses in-kernel mounting, which should make the AppImages even a little faster to launch.

so ALL appimages I have are mounted as loop devices

[Britoid]

sorry, I can't because

so ALL appimages I have are mounted as loop devices

You said FUSE wasn't needed to mount them, which it is unless you have a daemon running as root mounting them. You accused me of lying which I wasn't, you were just being rude.

me:

2) FUSE... it uses FUSE to mount the application files at startup

you:

and no, no FUSE were needed to mount squashfs last time I checked. That guy speaks gibberish

./LibreOffice-fresh.full-x86_64.AppImage
dlopen(): error loading libfuse.so.2

AppImages require FUSE to run.
You might still be able to extract the contents of this AppImage
if you run it with the --appimage-extract option.
See https://github.com/AppImage/AppImageKit/wiki/FUSE
for more information

I guess I made that up.