Are you suggesting "political correctness" is the only reason someone might be discouraged from installing a program named after toilet humor and juvenile references to specific parts of the anatomy? I've let my kids watch plenty of children's movies with fart jokes in them, but I still don't want to hear more of that when I'm trying to use a tool to access a banking service. It seems there's even still a banking module with a crude poop icon: https://woob.tech/applications/bank.html
Doesn't really inspire confidence in their professionalism or trustworthiness with handling financial transactions, if you ask me.
In my opinion, you're wasting your time with layer shell. The design of it is very X11-like and flawed. Panels setting their own position is problematic and prevents the shell from doing layout updates in one pass. You'll want to drop it eventually and use a private shell similar to the way it's done in weston.
>Not sure why you'd knock the way GIMP and Inkscape LAF on other systems; they both look perfectly native on Windows, and much better than the majority of cruddy MacOS desktop app wrappers
In my experience Qt apps behave much better on Windows and Mac because they're designed to be native first. GTK was never designed to do that, it started out as a clone of Motif and it only ran on Unix, the cross-platform support was added later when some Windows developers wanted to port GIMP to Windows. To me GIMP and Inkscape always had some weird GTK widgets that don't look or act anything like Win32 widgets. I'd say use Qt if you want a better native experience on mac and windows.
>The GNOME team never opened libadwaita for public comment, or held any forums where I could voice concerns with the direction they were headed. I can understand how this all sounds accusatory, but I really do recommend that you research it.
I've researched it. This isn't how open source works, projects are not driven by public comments on forums. They're driven by people showing up to work together on a shared goal. Those who show up and write the code, get to be the decision makers.
>The community has been completely locked out of the GNOME decision-making process.
It doesn't make much sense to say this, the whole point here is the community makes the decisions for itself and nobody else. Every single contributor past the original founders are from the community.
>They won't accept contributions that allow cross-platform stylesheets
>the GNOME team pretty much doesn't care about anything the community has to say. It's a bad direction for the project to be heading in, and it definitely makes it harder for regular people to write good-looking, system-agnostic GTK apps
I've no idea where you got this. I've never seen any comments from libadwaita developers to suggest that. This doesn't need to be contributed either, if you have a stylesheet you want to work on you can just ship it as part of your app, or create another add-on library for platform extensions similar to this: https://github.com/GNOME/gtk-mac-integration
Regardless of where it ends up, the styles for GIMP on Win32 is just a theme, if that's not available in newer versions then somebody needs to port it to the new theming system. You could wait for a GIMP contributor to do it but that might take a long time.
>It was a really good library until it hit v14, when the developers lobbed off support for Glade files
I might still be misunderstanding, but the break was caused by GTK4. The GTK3 bindings are a separate crate. You can use those until the GTK4 gui designer is released. Breaking glade wasn't done on purpose.
>v9.0.0 allowed you to build programs functionally and register their various interfaces as closures. This made it fairly simple to not only separate UI code from function code, but was also really comfortable to write "like a normal app". v14 eliminated this workflow though
I can't really figure out what you mean for sure but I did some searches. Closure support is still there but it appears to have been moved to another crate called gtk-rs-core.
But that's the whole thing. Redhat and the foundation don't have any leadership over a decentralized group of open source developers. Gnome is not like the Linux kernel where there's one giant repository with one lead maintainer serving as a bottleneck. There are individuals who hold more influence but that's more because a lot of other volunteers chose to follow them, not because they seized power from anybody.
The only one out of those that's a intentional design is multiple monitors. The other ones are known shortcomings that are just really hard to fix. The memory leak was fixed a few years ago: https://feaneron.com/2018/04/20/the-infamous-gnome-shell-mem...
That isn't how gnome works, being decentralized and all. The foundation pays for very little of the development and has little to no influence over what developers actually do. If you wanted the community to have more influence over development, the way to do that would actually be to get more money for the foundation so they can afford to hire more developers from the community. Right now, they don't employ any. The funding they have now is actually shockingly small for a nonprofit based in the USA, and almost unnoticeable compared to what a tech company based in the USA would have.
Removal of features would still happen though because that's a natural part of any software project responding to the ever-shifting priorities of a large group of users.
If you've got some code to contribute to that, ping the developers on IRC. Adding more comments to that issue isn't helpful. These issues aren't suffering from a lack of comments, they're missing someone to step up and do the work. The original comment was that they were hostile to this, which isn't true.
It's not easy for me to take this comment seriously because gnome doesn't actually have anything anyone could define as leadership. It's a decentralized open source thing. You might be incorrectly assuming bad faith.
Iced looks pretty cool but it's focused on being a cross-platform toolkit and will probably not ever be the best choice for making programs native to Linux, like a desktop environment. If you thought there were enough problems between GTK and Qt with skinning, fonts, keybindings, and all that stuff, adding another toolkit to the mix just makes it worse.
That seems like a lot of revisionist history. From what I've seen GTK never had good cross-platform development support. Programs like GIMP and Inkscape always looked and behaved very oddly to me on other platforms. The little support that's there is because interested parties contributed it. If this is what you want, it's self-defeating to refuse to contribute it.
If you do not want to use Rust, you can always use another language like Python or Javascript. I might be misunderstanding because the rest of your complaints are jumping around a lot, it would be easier to understand what you're talking about if you shared some code illustrating what the problem is.
>Also gnome is so flawed in so many ways from leaking memory due to unfixable mismatch between js and compiled code, to nonsensical handling of multiple desktops, to add-ons that both rely on monkey patching your desktop due to lack of addon api and can with a single crash kill your whole session, to hostility towards themeing, to ugly header bars, to hostility towards support for non gnome desktops.
Most of these issues are just bugs, not issues with some vision. The gnome people I've talked to want them fixed and want help with fixing them. But I get that it's lot easier to complain on hacker news than it is to fix architectural issues in a large codebase.
>Implementing keyboard selection inside vte means that every terminal based on vte benefits; adding only hooks for you means that all the other terminals get no benefit.
The patch being pushed wasn't going to help other projects. The developer of that project was working on a fork of the library but it appears it didn't get much use and was abandoned: https://github.com/thestinger/vte-ng
I don't see much more that anyone from GNOME could have done there.
You've decided the best way forward for you is to write sysvinit and openrc scripts. That's an opinion completely focused around writing some additional code. You don't have to write it all from scratch to be expressing that opinion, you can express it a lot of different ways but that's all it encompasses. Unless we're talking about something else that I missed? Suggesting that something is better than something else is really meaningless without that.
I think you've got some things mixed up. The word "woke" usually means being aware of issues with discrimination in the workplace. I'd have to agree with the grandparent comment, if you're suggesting that being aware of discrimination makes it a toxic workplace then you probably need to do some kind of diversity training, not necessarily in the workplace but just generally considering why it's not a good idea to dismiss employee concerns offhand as "woke upheavals". It's not so fun being on the receiving end, if you end up as the one making the harassment complaint and the boss dismisses it by telling you to shut up and stop being woke. Similar things have happened to people I've known.
>If a bug is in systemd, I can't easily fix it myself. I now have to fight upstream to recognize my issue and fix it for me.
That's not true. You can do as you would with the shell script and patch it in your local copy. If this is too much hassle then that shell script workflow shouldn't be broken by systemd and you can always fall back to it. It's still possible to run shell scripts as systemd units. You could also run another service manager as a systemd unit as another workaround.
Also, in my experience, if you're fixing an actual crash, those patches are really likely to get accepted. Upstream appreciates that, I haven't seen them fight anyone over an easily verified issue. If you're submitting giant 10,000 line patches that change the public interfaces and cause regressions, that's a different story.
That's just re-stating the grandparent comment! If you think everyone is entitled to their opinion then the only tangible way to express that opinion would be to produce new code. What use is the opinion if nobody ever implements it?
I haven't seen any of these supposed Red Hat projects that have dependencies for political reasons. If that were really true then it would be trivial for anyone to remove those dependencies, and there wouldn't be anything for anyone to complain about. Any way you slice it doesn't seem like a cause for alarm.
I think it's fair to say that Linux isn't Unix and goes well beyond the design constraints of Unix that were imposed when it was originally started in 1969. That's the era you stick to when you insist on only doing things the Unix way, but there are a lot of other ways to know what your system does and have reliable tools. In current times the most common usage of Linux is Android, which is ostensibly not Unix-like at all regarding its userspace. If you're talking about GNU, that quite literally means "GNU is not Unix".
Doesn't really inspire confidence in their professionalism or trustworthiness with handling financial transactions, if you ask me.