Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

For everybody trying to figure out the point of Chimera Linux, it is Void Linux taken one step further. The founder used to be the maintainer of Void for PPC. That also explains the supported arch selection for Chimera.

My take on Chimera is that it is what a FreeBSD user would want if they were going to use Linux. They share the same compiler and userland. The build system rings a lot of bells.

At first, GNOME seems an odd choice but Chimera wants to avoid a lot of legacy and is pipewire and Wayland from the start.



It looks quite nice though yeah, the choice of GNOME makes me a little bit less enthused. I wonder if System76's COSMIC will ever take off enough to be a consideration, as I would really like to see a new stable, pragmatic, productivity + user-focused DE take off. Plasma's a bit too buggy, GNOME feels not so pragmatic and definitely not so user-focused, the rest feel like they lack some level of polish and maintenance. System76 seems to have money to put into something good here, and they seem to have the right incentives to make something focused on user's needs and sensibilities more than developer's ideals, so it seems like in some time it could become a major contender.


Gnome is one of my favorite DE as to me it is so easily usable and efficient with maximise use of the keyboard straight out of the box while still being very practical to use with a tactile screen.

I do understand that it may not be for everyone but my understanding is that when people say a desktop is not user focused, what they really mean is it isn't focused to people resistant to changes


> not user focused, what they really mean is it isn't focused to people resistant to changes

That, or "it's not aligned perfectly with all my personal needs"


Totally agree! I came from macOS and I like modern Gnome 45 even more the one I used back in 2008, v.2 or something like that.


I think in general, the GNOME foundation does a lot of good stuff overall, but I do not like the direction GNOME and Mutter have taken. Personally, I think that a lot of modern design is focused more on looking pleasing to UX/UI designers than it is focusing on genuine usability.

As an example, I feel like the usability of GNOME apps with client-side decorations is a lot poorer than the previous more traditional paradigms. The older paradigm may not be flawless, but it was much more consistent across applications, and most importantly, it's very easy to figure out. Trying to figure out how to do things in GNOME applications these days can be an exercise in frustration. I don't really want to play a game where I try to figure out what the trendy way to access the Settings dialog for a program is. Is it going to be somewhere in the global menu bar, or is it going to be on some nondescript button with dots or lines in it, or maybe something even MORE exciting? In the past, the worst thing was having to look through some defacto standard menus to find it. With modern applications, who knows.

Meanwhile, Mutter feels like it is resistant to practical concerns: they dug their heels on on server-side decorations, which did exactly what anyone could've told them it was going to do; now a bunch of applications have no or horribly broken borders on GNOME. I mean look, I know "it's really the application's fault because we said they had to deal with this" but also, I hope everyone understands that it genuinely doesn't matter, the outcome was predetermined based on the input.

On that front, I have a laundry list of complaints over how the direction Wayland has taken in GNOME in general, especially pushing things to clunky and unusable DBus interfaces that don't cover all of the important and already-common desktop use cases well enough. While I understand some of the reasoning, it is extremely difficult to argue that this isn't a focus on developer ideals over what would be ideal for users. Arguing that it's not "waylandy" to have input emulation in the Wayland protocol thus forcing you to use another binary protocol that's similar to Wayland but that you need to negotiate over DBus using desktop portals seems like a step very far in a weird direction when you are literally already speaking to the same compositor that's responsible for _dispatching_ input events.

Old man yells at cloud, but yeah GNOME definitely is "my way or the highway" in every regard, absolutely not a bastion of user-centric design or architecture. And that can be good if that's what you want, but I have a feeling it would be easily displaced by something that had a better attitude toward user concerns and pain points.

Even if KDE is buggy, it's extremely hard to argue it's not more user-centric. I'm wholly unsurprised when I see something like XWaylandVideoBridge coming out of KDE, as it's born out of trying to make things work for users rather than drawing a hardline.

That said, I do personally think GNOME and GTK4 are far better on phones and tablets than desktops. It's funny, because I simply would not consider them good options for desktop applications, but it all makes a lot more sense when you try it with a touchscreen. (That said, I don't view this as much of a saving grace because I've come to the conclusion that convergence is mostly a lie, something that you think is a good idea but in reality it's not; you just get something that's mostly bad on desktop, mostly bad on phone/tablet, or just generally not good on anything. GNOME is closer, IMO, to "mostly bad on desktop.")


Well I am far from agreeing about some of Gnome's technical choices but I am posting under the end user position. And I must say that as an end user, the client-side vs server-side decorations hasn't seemed to affect me. On modern apps I am looking for a burger/3 dots icon for settings, on more legacy one a file->preferences of file->settings and that's it.

Even if Gnome/GTK-4 supported server side decorations the problem of the heterogeneous app ecosystem would not be solved and you can observe the same regardless of the DE or even OS.

As a user the only major complaint I would have about Gnome is the regular breakage of extensions. On most distros it isn't an issue but it makes it rather unsuited to rolling release distros unless user is willing to regularly play with his package management config to prevent updates. On my Fedora machines it is not a big deal as the gnome major version is only upgraded on major Fedora version so I usually test with a VM before hand and if there is an extensions I really want to have I'll fix it o just wait a few weeks or months for the extension to be updated (or a fork being made).


lack of server-side decorations in mutter is primarily a technical problem that's not really easily solvable - currently the compositor code does not actually depend on any drawing library, to draw native serverside decorations it'd have to pull in entire gtk (a lot of effort was put into eliminating gtk from the wayland compositor path in the first place; mutter the X11 window manager, i.e. what xwayland applications use, has the dependency, so it can draw decorations)

serverside decorations are generally a broken paradigm too, pretty much no other system than X11 does them, and they introduce limitations and inconsistency to the application UI (the application can't reasonably control their contents so they're there to provide 3 buttons and waste a bunch of space), having integrated clientside decorations is one of the more visible reasons why gnome's UI feels polished and consistent

if the application is incapable of drawing reasonable decorations on its own, there is now libdecor (e.g. SDL uses it) and it has gained a gtk backend a while back, so it should be able to draw native decorations; while applications using a full toolkit have no problem in the first place, because the toolkits are fully capable of it


Full stop and without prejudice, libdecor is a bad idea. It requires linking to C code which is not normally necessary on Linux, and if you want to respect the GTK theme in GNOME, you need to link to GTK (even if indirectly: it still has to be in your process's address space) and have access to user settings. This is a whole lot of complexity that GUI libraries and container runtimes will need to deal with just for GNOME if they want something as ridiculous as native looking titlebars, especially considering a wide variety of applications that otherwise don't care about looking native would definitely like to have native titlebars. Another good example of a situation where it'd be nice is Wine, which can currently have native titlebars on X11 but not Wayland.

> lack of server-side decorations in mutter is primarily a technical problem that's not really easily solvable - currently the compositor code does not actually depend on any drawing library, to draw native serverside decorations it'd have to pull in entire gtk (a lot of effort was put into eliminating gtk from the wayland compositor path in the first place; mutter the X11 window manager, i.e. what xwayland applications use, has the dependency, so it can draw decorations)

Application developers and users don't care about Mutter's clean dependencies. It doesn't matter how the problem is solved, it just matters that it is solved. For all the application developers care, they can resolve the problem by having another process manage GTK shells around applications and not having Mutter actually do it.

As for not wanting GTK in Mutter, well, a lot of applications also don't want to have GTK in their process space, so it seems like this desire shouldn't be very surprising to GNOME developers.

What will happen here is that libdecor will be treated like a polyfill just for the snowflake case of GNOME and the damn-near rest of the world will figure out a way to do SSD. Exactly how doesn't matter, so as long as it's out of the application's own concerns. This is basically the only way that things can work, because if you wanted e.g. native titlebar regardless of whether you were on GNOME or KDE or something else entirely, you don't want to have every single flatpak/snap/whatever needing to pull in the entirety of GTK4 and Qt6 or whatever just to be able to try to have native titlebars. The only reason this works for GNOME is that GNOME is the only DE that does things that only work if they are the center of the universe, so you can have the GNOME case and the rest of the world case just fine. (I know the common argument here is "but what about Weston", but I am not aware of any desktop Linux system that boots into Weston, so it's really neither here nor there.)


What Gnome do you think doesn't feel user focused? I use 90% of the time minimalist window manager, but when I need a full desktop I find Gnome the best choice. Gnome isn't particularly exciting, but in my experience, everything I can't say about other desktops just works. Apart from that, Adwaita looks incredibly much better Qt.


I can't get past most apps having a title bar / chrome that feels like 1/3 of the window.


That was my biggest beef as well. However, I spend 99% of my time in foot (a snappy terminal which I configured to have no title bar) and Firefox (which doesn’t have the fat title bar). So, in practice, it hasn’t bothered me at all.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: