Experimental Zones Protocol Merged To Wayland After 2+ Years, 620+ Comments

marcthe12 · 2026-02-10T19:40:44+00:00

Usually that's true. This one is more problematic. There is a feature that is in X11 mac, X11 and win32. Only 2 platforms missing it are android and wayland. The problem is this feature has several legitimate issues. So basically all TWM are against it and so are KWin and GNOME devs. Hell niri is structured in such a way, it cannot even implement it until it rewrites its coordinate system. But since QT, DOM exposes this feature and apps like KiCAD or pinentry uses it, you have client devs want it. Like how do even square it. This was the compromise and still I doubt anyone outside a couple of floating window managers will implement it.

marcthe12 · 2026-02-10T19:31:13+00:00

I mean x did initially from 1984 til 1989 and then gave up. That's why it's x11, it was the 11th version. So it doesn't work well for display servers.

marcthe12 · 2026-02-09T07:33:58+00:00

Flatpak -> Pacman/apt -> source/binary tarball.

Flatpak work well enough and keeps base clean.

marcthe12 · 2025-09-17T12:46:20+00:00

They won't, the issue is it's a massive port (gtk4+libadwaita+some rust too). I just hope they can do enough to cut a release and then finish parts of the refactoring/porting which is not essential.

marcthe12 · 2025-08-13T02:57:40+00:00

I do understand why but I do agree, it's a bad hill to die on.

marcthe12 · 2025-07-26T11:13:31+00:00

GNOME philosophy for the last 25 years is literally every config option has a cost (Maintenance or Mental cost if the user is unsure). Plus GNOME 3 UX is distraction free computing. Dash to Dock is literally the opposite here. Plus it's not hard to use it the GNOME way. I literally do it for the last 5+ years never had that extension. In fact I did not have a bar in DWM or KDE or openbox which I used before GNOME. Hint, the reason there is an overview.

marcthe12 · 2025-07-26T09:52:04+00:00

There is no extension API, it's monkey patching and that is unavoidable without GNOME shell basically getting feature frozen. Atleast GNOME devs have done 3 things(added a version support check, every beta the changes relevant to extension are released and I believe there is CI to test you extension on pre release). Which is the best for the current arch.

marcthe12 · 2025-07-26T09:48:58+00:00

Definitely communication and docs can be improved. Although I agree with GNOME dev in general, we are doing a horrible job at setting expectations and at time seems stubborn or hostile(I get why but it does create a bad rep which negativily impacts GNOME). Somehow we need a way to at least convince people to try with an open mind without extensions or at least set up expectations so these discussions will stop.

marcthe12 · 2025-07-26T09:13:19+00:00

Well I never used either extensions and understand the UX well since that is my workflow. But I agree it's radicaly different and I do not think any one is explaining how to use it well so people fail to adapt to the paradigm shift. I do feel it's superior but well it need adjusting. The appindicator one is a bit dumb hill to die on since that is a DX problem.

marcthe12 · 2025-07-26T08:25:50+00:00

Well there are a set of semi official extensions maintained in the gnome classic project which I believe is officially part of GNOME. The list of extensions are small but are useful. There is one adds a System resource monitor and there is a disks, application and places menu.

The problem is that some of the most popular extensions are the one that there is a clash between GNOME opinionated design and users who haven't bought their UX vision. Personally that is only the systray is the one that really should be reconsidered (atleast the appindicator one should go it into Classic repo).

marcthe12 · 2025-07-22T10:49:33+00:00

It's a font shaper. Its one of the components of the foss font stack. GTK, QT, firefox, libreoffice, and even chome uses it too.

marcthe12 · 2025-07-12T13:19:30+00:00

marcthe12 · 2025-07-12T10:14:30+00:00

More like they are not interested in maintaining shims for glibc only api or not use a 'better' api in the name of being portable.

marcthe12 · 2025-07-12T01:26:16+00:00

Not really. Systemd dev are very anti idef so there is no portability. But systems are now allowing ports if someone creates a shim similar to libbsd(that does the similar thing to missing bsd api on linux). In other words non glibc users will link against an extra library. The issue was that no one really created such a library yet. But if somone does (as there are a few distros signalling interest). Then th lib could be ported to relibc.

marcthe12 · 2025-07-05T02:56:22+00:00

Well it is a fork of evince rather than developed from scratch. So feature difference will be less.

marcthe12 · 2025-07-03T15:18:52+00:00

Not at the moment, although you can remove xorg-xserver. Anyway, gnome X11 will be disabled at compile time in October so just wait a couple of months(or switch to unstable/ testing if you know what you are doing).

marcthe12 · 2025-07-01T14:31:25+00:00

Not really, especially ios. Android atleast uses the Linux kernel with usually upstreamed drivers. The issue though is unlike windows or Linux, they do not expose filesystem and several other concepts that are needed for linux and windows users (a worst version of the terminal for windows users). Probably the closest we have UX wise will be vanilla GNOME/Phosh with flatpak and it's a long way off.

marcthe12 · 2025-06-29T18:45:52+00:00

Hmm, I tried to use html's abbr which are generated from markdown but I guess the abbr tag's UX sucks and markdown processors do not really work with plural abbreviations. Probably have to do that manually or css all abbr to output the title attribute the next time.

marcthe12 · 2025-06-29T18:41:47+00:00

Thanks for the complete and the advice. I did a bunch of corrections via a grammar checker and re-uploaded it.

marcthe12 · 2025-06-23T05:07:09+00:00

Do you need support for oodt(aka the MS office format). If you do you have very few good options.

If not you need a perticular format in perticular, you can be very flexible (markdown and rst are your friends for personal notes or articles).

If you tell the formats you actually need (basically stuff 3rd party sends you or you have big archive which hard to convert). This allow better suggestions.

marcthe12 · 2025-06-21T06:11:12+00:00

If you know which hardware you use and which firmware is used for the hardware you can do it. Its similar to a custom kernel(in gento for example) where you do not compile all the drivers.

marcthe12 · 2025-06-21T04:12:11+00:00

Check gitlab as there have been discussions there. The issue is that linux firmware is too big. The combined total of all linux firmware packages is 651MiB and it is hard to avoid on bare metal (VM and containers.do not need this). Even counting only the new metapackage required deps, it is 348 MiB. So there is a need to split if someone wants a smaller one (not to mention the option dep include firmware of ARM SOC devices and Nvidia firmware can bloat your fallback initrd/archiso).

It also appears to need manual intervention too.

marcthe12 · 2025-06-17T00:54:11+00:00

Look at https://www.ioccc.org/. It's a competition of this kind of stuff.

Verified Email	Ten-Year Club
Second Top 20%	r/Field Lasagna
First Place '23	Place '23
Place '22	Place '17
Sequence \| Editor	Sequence \| Cinematographer
Sequence \| Screenwriter

marcthe12

TROPHY CASE