GNOME Shell & Mutter Complete Their Migration Away From GTK3

[oiaohm]

Stop spreading this marketing bs - libwsm has stalled 7 years ago so there is a close to none difference from X11 (with SECURITY extension not used at all in the wild).

While X11 has no doors installed at all, with Wayland you get the "please don't do bad things" sign on the wall. This is better, but still the same class of (in)security)

Not quite true. Wayland protocol has refused to implement quite lot features and those features have been pushed out to places like xdg-desktop-portals behind dbus security.

https://subscription.packtpub.com/book/networking-and-servers/9781783989669/10/ch10lvl1sec88/controlling-d-bus-message-flows

Yes dbus you have selinux, apparmor and other linux security module integration.

Wayland protocol has done a reduced attack surface compared to X11. So not quite the same as please don't do bad things.

gotar interesting problem right. Why do libwsm for Wayland if nothing needing authorization is ever going over the Wayland protocol because it all has been pushed over dbus. Yes 7 years ago you see a lot of items like screen-capture feature requests killed from Wayland issue list.

Lets take a close look at for one min.

https://github.com/mupuf/libwsm

From here
WSM_SCREENSHOT default: soft-deny Ability to take a still screenshot of the whole screen
WSM_SCREENSHARING default: soft-deny Ability to record the screen continuously
WSM_VIRTUAL_KEYBOARD allow/inject-only/filter-only/soft-allow/soft-deny/deny default: soft-deny Ability to inject or filter input on the keyboard
WSM_VIRTUAL_POINTING default: soft-deny Ability to modify the position of the pointer and simulate clicks
WSM_GLOBAL_KEYBOARD_SEQUENCE object: key sequence default: soft-deny Ability to receive global keyboard sequences when not on focus
WSM_FORWARD_RESERVED_KEYBOARD_SEQUENCE object: key sequence default: soft-deny Ability to receive reserved keyboard sequences instead of compositor when on focus
All in xdg-desktop-portal. or atk so over dbus for normal applications. Yes does ask if virtual-keyboard-unstable-v1.xml should be dropped from wayland protocol.

WSM_FULLSCREEN default: soft-allow Ability to use the entire screen
WSM_CLIPBOARD_COPY default: allow Ability to copy to the clipboard
WSM_CLIPBOARD_PASTE default: soft-deny Ability to paste from the clipboard
WSM_RAISE_FOCUS default: soft-allow Ability to raise the window and grab focus programmatically
The next two are dbus libnotify uses the dbus protocol.
WSM_NOTIFICATION_API default: soft-allow Ability to use the libnotify API to raise notifications
WSM_CUSTOM_NOTIFICATION_API default: soft-deny Ability to build custom notification UIs and have them displayed (i.e., raised and positioned for a set duration) by the compositor Possible future capabilities not related to the Graphic Stack

These device accesses
DSM_RECORD_VIDEO default: soft-deny Ability to read data on video capture devices
DSM_RECORD_AUDIO default: soft-deny Ability to read data on audio capture devices
Will not be in the Wayland protocol.

From here
DSM_USE_PASSWORD_STORE default: soft-allow Ability to use password store APIs
DSM_PRIVILEGED_HEADLESS default: soft-allow Ability to perform privileged actions without having a GUI
DSM_SESSION_LOCKER default: deny Ability to lock the user session
DSM_AUTHENTICATION_UI default: deny Ability to act as an authentication UI
DSM_PERMISSION_UI default: deny Ability to act as a permission UI
Dbus again none of this need to be done by Wayland protocol.

Yes libwsm features not routed by dbus in a Wayland solution.
WSM_FULLSCREEN default: soft-allow Ability to use the entire screen
WSM_CLIPBOARD_COPY default: allow Ability to copy to the clipboard
WSM_CLIPBOARD_PASTE default: soft-deny Ability to paste from the clipboard
WSM_RAISE_FOCUS default: soft-allow Ability to raise the window and grab focus programmatically
Very short list right.

Yes everything already over dbus basically has libwsm duplicating functionality. libwsm stalled mostly it does not make sense due to how much the wayland protocol is not implementing or will have a default state of deined.

[Weasel]

Just because something is hated doesn't mean that the people who hate it are correct or that it's wrong. Think of all the places in life where that way of thinking falls apart.

I guess I wasn't clear enough. I meant hated by programmers, not non-factors. Users are one thing, but if programmers (outside of pathetic GNOME circle of course) hate it, fork it, bring pitchforks against it, etc... you know you have a problem.

The notable forks of Gnome were Mate and Cinnamon. Cinnamon was forked by people who preferred a more conservative (Windows-like) UI, but it doesn't mean they're correct or wrong. They have differing opinions on how a desktop UI should work and that's fine. They only forked Gnome and Mutter though. They use vanilla GTK3 though, not a fork of it. The same is true of Mate. It was made to preserve Gnome 2's interface but it still uses GTK3.

Why isn't same done with Qt or other toolkits? Oh right because they stay sane.

With such overhauls, GTK isn't even GTK, should be renamed to something else.

[Weasel]

On a related note: god damn these forums are toxic lol

What's the problem, can't handle yourself?

If you found my post stupid, yours is twice as stupid.

Enjoy your new mirror!

[reza]

Who cares if your NVME can read at 7GB/s? Software shouldn't be made with that assumption.

I totally agree with this! Unfortunately more and more software is developed with this in mind.

For a test, I run softwares on my trusty little old ThinkPad X201 with HDD.

In the Linux world, I have a question: Is it me or KDE is slower to boot up compared to Gnome? KDE takes a long time loading the icons up. Is the same thing true that KDE is written with preference towards NVMe/SSD compared to Gnome?

In the Windows world: I have noticed Windows 7 runs just fine on 5400/7200 rpm HDD, but Windows 10 and then even worse Windows 11 is noticeably sluggish. Please note that I have tested this in an advanced way (with absolutely minimal resources, turning off a LOT of services (Windows Update, Spooling, XBox, etc.) so it does not seems to be about RAM issue, but rather something in software development to assume faster more performant storage device.

[Myownfriend]

I guess I wasn't clear enough. I meant hated by programmers, not non-factors. Users are one thing, but if programmers (outside of pathetic GNOME circle of course) hate it, fork it, bring pitchforks against it, etc... you know you have a problem.

"The pathetic Gnome circle". Are you an Xbox Live kid? lol

All dumb statements lol

Why isn't same done with Qt or other toolkits? Oh right because they stay sane.

You familiar with echo chambers? lol

With such overhauls, GTK isn't even GTK, should be renamed to something else.

Why? lol Explain. What makes GTK4 no longer GTK? Just code changes? Are so used to stagnant projects that you think software is never supposed to change much?

[Myownfriend]

What's the problem, can't handle yourself?

If you found my post stupid, yours is twice as stupid.

Enjoy your new mirror!

Don't try clever retorts, Pee Weasel. You're not good at it and it's cringey.

[Myownfriend]

Stop spreading this marketing bs - libwsm has stalled 7 years ago so there is a close to none difference from X11 (with SECURITY extension not used at all in the wild).

libwsm has nothing to do with what I'm talking about lol Why would I be referring to something that's not part of the Wayland protocol when describing the Wayland protocol?

[caligula]

I totally agree with this! Unfortunately more and more software is developed with this in mind.

Why I originally brought this up is because GNOME offers this integrated search for packages that could be installed. I meant that storing this cache on disk makes sense, even if you don't have a fast NVMe disk.

I did a small test. Storing the descriptions, names, names of the binary, and source (apt, flatpak, snap etc.) in lz4/json uses around 1 MiB per 30000 package descriptions. Now, even shitty PATA hard drives from 1990s have read speeds of at least 20 MB/s. Yes the cache can be a single contiguous block on disk. On my system doing deserialization & any full text search on the db took around around 5 milliseconds. Way below any Doherty Threshold you might think of. So, there really isn't any excuse not to use a persistent cache on disk. Besides you'll need to integrate with each package manager to keep the db in sync with what you have on disk. I can see how storing everything in RAM is convenient, but it's not strictly a requirement. Especially considering that they still sell new Macbook Pros with 8 GB of RAM, and according to a previous comment Gnome would require 1,7 GB just to launch to desktop. So that's nearly 25% of the machine's full capacity wasted on stupid shit nobody cares about.

[Hibbelharry]

Another funfact: cached RAM is not "taken" RAM so it doesn't show up as "used" RAM. You can have 90% of your RAM "free", it doesn't mean cache didn't fill it up. Your bullshit rhetoric is nothing more than asinine nonsense.

Except.... it's not. You might not know it, but there are quite a lot different kinds of caches. Cache used by any kernel related context does indeed show up as cache in any memory monitor, but what about caches used and built by userland applications? They will also do caching and keep some of those caches in RAM and their application contexts.

RAM used for no reason is a waste of resources. It takes energy to populate it (CPU power). Wasted energy.

Thats not a lot of energy compared to my general system consumption. If I can have a more fluid experience for a lot amount of waste I'll pick the first one.

Your 7 GB Firefox is big yikes. I suggest you look into the issue. My browser uses 500 MB. You have a problem.

No, not really. It's working fine, I'm just a poweruser. Keep some 100 tabs open and you'll see. You'll also need a lot of RAM if there is some javascript heavy sites.

Example: We do use Google Workspace at work. If I open any midsize sheet my browser RAM consumption grows by 700MB, some of our server cluster orchestration tools need no less than 1G when logged in, etc.

I guess I wasn't clear enough. I meant hated by programmers, not non-factors. Users are one thing, but if programmers (outside of pathetic GNOME circle of course) hate it, fork it, bring pitchforks against it, etc... you know you have a problem.

Except.. I'm working in a software company. Most of our devs writing software all day long use gnome for their everyday work.

Why isn't same done with Qt or other toolkits? Oh right because they stay sane.

Yeah...but no. No one forked GTK, glib, pango or the other relevant stuff. Or do you know any example?

I guess you really don't know the scope of GTK or comparative toolkits. You're mistaking Gnome with GTK I guess. Big difference.

With such overhauls, GTK isn't even GTK, should be renamed to something else.

Nonsense. Toolkits need to evolve. Qt did and does evolve, GTK did the same. And porting your app from one major version to the next of the very same toolkit always imposes work to do. Qt made some big steps and GTK did the same as many others. None of them needs a new name.

[caligula]

Something from 2006 is now 17 years old. No one in 2006 would call a 1989 33 MHz 486 "relatively modern". Pretty much everything in the past 15 years or so has had at least 4GB of RAM, and anything in the past decade has had 6-8GB minimum.

Please note that entry level Macbook Pro in 2023 has 8 GB of RAM. I don't remember if those were available in 2006, but I had a totally ordinary desktop Athlon Phenom from 2007 or 2008 that eventually was loaded with 8 GB of RAM (4x2). It's also becoming a trend that new systems have soldered memory & SSD, so those old systems from 2006 can actually have more disk space than new ones. I mean plenty. SATA3 disks are backwards compatible. That means your 17 year old system can easily hold something like 6 x 22 TB of data. Yes there are 22 TB SATA disks now. They also support GPUs that can drive multiple 4k displays.

Here's an example of what a computer bought in 2007 might look like now (with some updated parts):

Phenom 9600 4-core processor (around half the speed of 2018 ultrabook cpu i3-8130U)
8 GB of RAM (4 x 2 GB DDR2)
2 x 1 TB SATA SSD RAID1 or RAID0 ( < $200 upgrade)
2 x 16 TB SATA HDD, RAID1 (not necessary, but you might collect porn or something)
Bluray drive
10 x USB2
Gigabit LAN
8-channel audio
RX 580 or some other budget GPU (< $100 upgrade)
4 x 4k displays

Yea, so totally obsolete.

Now if we take a look at those 486s again, I've never seen a 486 with more than 32 MB of RAM. I've also never seen a system with more than 4 disk slots. Those 486s from 1989 either support 2 or at most 4 disks via ST-506, ESDI, or the first version of PATA (via ISA). GPU resolution might be limited to 640x480 at 24bit colors. So not anything you could use for anything serious.

You guys are squabbling over 200-300MB of RAM on systems that have nearly a factor of 30 more RAM to work with.

I'm talking about an unnecessary need to waste resources. Technologies such as Wayland were invented to shave off stupid shit like legacy X protocols and convoluted ways of doing simple things with unnecessary round-trips. You could also argue that modern processors are so fast that we should actually switch to more convoluted ways of doing IPC, event loops, and maybe switch to uncompressed image and audio formats. We could replace all asm optimized algorithms in ffmpeg with javascript. Why not? That's why TSMC is developing new lithography. To help us switch more efficient languages with slower ones so that we could do the same things slower.

It's funny how nobody really cares. Auditing a system where you have almost 2 gigabytes of "idle consumption". Nobody has any idea what this huge blob is shit using 25% of their RAM is. 10 years ago you could fit the whole Ubuntu Live CD tree times in that space. Now nobody knows what it's all used for. It just is.