cycloptic

I said this in a sibling comment but, there are also plenty of examples of feature requests that were not rejected:

https://gitlab.gnome.org/GNOME/mutter/-/merge_requests?state...

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests?state=me...

If you're going to look at the pattern of historically rejected requests, please also consider looking at the pattern of requests that were accepted.

If you'd like, I can give you a more thorough explanation as to what is actually happening in any of those issues you've linked.

>So you're not really allowed to solve one without solving the other

The final comments from the developer directly contradicts this claim:

>I'd be happy to review a merge request that added the ability to disable recursive search in the file chooser using a GSettings option ... I was thinking more along the lines of having a key in the file chooser settings schema that would be observed by Nautilus.

The idea there is that the key should be in a standard location read by nautilus (or some other GTK file manager) if it also decides to implement that feature. Edit: I also should note that it appears there was not even initial consensus about this, the other GTK developer seemed to be skeptical at first.

I'm confused how that's related, the issue you're talking about is in the file manager, not GTK. I don't believe any of the primary nautilus maintainers are also primary GTK maintainers, at least not anyone in that issue. (Please correct me if I'm wrong about that)

But, since I've said this before, I'll say it again: If the other people who use the toolkit want to have input, they need to contribute more. AFAIK there are zero non-GNOME devs working full time on GTK. I hope that changes, i.e. I hope the other desktops can find funding to send more designers and developers to collaborate with the GNOME people so everyone can have their say. That is the real issue here, I think it's incorrect to suggest that anything was "taken." It's open source, there isn't anyone who's going to take the code away from you unless you blatantly violate the license.

That's only one example and the issue was closed specifically because it conflicts with their UX designs created by a professional designer: https://github.com/gnome-design-team/gnome-mockups/tree/mast...

As a point of comparison, you may want to look through all the other merge requests that actually do get accepted, the majority of them do: https://gitlab.gnome.org/GNOME/nautilus/-/merge_requests?sta...

You are of course welcome to have an opinion, and to choose whatever product you want based on that opinion. But if the extent of your opinion is "this person is a jerk and their work is terrible and not to my taste" that is unlikely to convince that person to change course, especially if they don't know you and if the decision is already made.

Sorry if it was not clear, by take it in another direction I generally mean find funding, get hired by someone else to work on it, or start another company to work on it if there is enough of a business opportunity there. It's very hard to make significant changes to a large codebase without a team of people.

I just don't want our community to turn to conspiracy theorizing and conjecture. We can do better.

Thank you, I figured there was a blog or comment somewhere with more info.

I'm not sure what you expect can be done about that. Every desktop is going to have its own set of features and APIs that other desktops don't. That's what they mean by "platform." Should e.g. KDE developers spend less time working on their own features and start contributing more to GNOME, to make GNOME apps work better in KDE, and vice versa? Maybe, but they would have to take the initiative to do it.

For me, it applies to everyone. I try hard to not hold a grudge. It's difficult but emotionally rewarding.

If we are trying to be good open source citizens and avoid unnecessary fights, you can apply it just to that.

I personally don't know the full history; you might consider looking for some old blog posts or politely contacting a GNOME developer for an explanation of the history. From what I understand, the run up to mobile was a major source of funding for GNOME 2 from several mobile companies, and that's where all the developers came from, but most of those companies were not able to keep up and failed to iOS/Android. So the funding dried up and Red Hat was one of the few companies that happened to survive because of their other business. That's what I've heard but you should talk to more people who were actually involved in the project back then if you want a more complete answer. (Please assume good faith and don't be hostile, we're all friends here, these are just developers trying to pay the bills like the rest of us)

>trying to hijack the project, and getting stalled half-way because of popular pushback

Again, please do not spread these unfounded conspiracy theories. I can explain more what I mean by this, but it seems unlikely you are willing to hear what I have to say. I can tell you if you're trying to convince me to be hostile towards any specific developers for any specific project, I will have to decline to get involved with that. You don't have to resort to character assassination, if you have some ideas on a good technical direction for a project, just make the argument and write the code: people will listen if your arguments are sound and your code works.

I would advise holding off judgement on specific individuals unless you have worked with them closely and you have a deep understanding of why certain decisions were made.

Again, if you are a developer and you disagree with someone's choices, you are free to take it in your own direction. You do not have to work on anybody else's stuff if you don't want.

Please do not spread these unfounded conspiracy theories. If you are a developer and you don't agree with direction changes, you don't have to work on them, you can work in the direction of your choosing. AFAIK there are numerous forks of GNOME over the years that are still going.

>Because you have honest and responsible politicians?

No it's actually the opposite -- by design, both parties are far too greedy and selfish and disorganized to do that on their own.

>The problem now is your tech overlords

No, it really isn't, and this fear-mongering rhetoric is extremely unhelpful. There is bi-partisan support for antitrust actions towards these companies. If trump's (former?) followers are serious about breaking up big tech, they should stop repeating trump's baseless lies about how big tech is some sort of satanic radical leftist communist conspiracy, and get it on these bi-partisan lawsuits.

He is doing the censorship in areas where he has control, e.g. his own party: https://www.detroitnews.com/story/opinion/2021/01/09/opinion...

>but we'll get close enough that a stable "red social media" ecosystem will emerge that's out of reach of cancellation

No it won't, because that platform already exists: Twitter. I follow lots of conservatives on Twitter who have no need to ditch the platform, because they actually are decent humans who don't promote racism, unhinged conspiracy theories, violence and sedition. All of those things are now confirmed as losing strategies for the party; businesses doubling down on a losing strategy will fail. This idea, that a certain person's particular brand of bad faith trolling represents all of republicanism, is senseless and divisive and it needs to stop. Retreating into a bubble with this attitude is going to be even more destructive for the republican party and make it even more vulnerable to getting hoodwinked by these bullshit salesmen. (Disclaimer: I don't personally belong to any political parties)

I've built cpython, it's about as inconvenient as building the compiler and runtime for any other major language. What OS ships binaries for gcc/clang but not python? I can't say I've seen any Linux distros that don't have it.

>Well that just means CMake has nothing at all going for it, if they are as portable.

Sorry, just to be clear, Visual Studio does not have built in support for autotools. (Unless they added it recently and I wasn't aware) But, there are a number of other less convenient ways to get that to work on Windows.

I guess I just don't see where there are footguns and unsafety here. Build scripts are intended to operate on a known, fixed set of inputs.

>Any portable build system, that already requires EVERY user to have that build system installed, is DoA for being a viable portable build system.

Why? I don't see how it's different from requiring a user to install a compiler to build a particular language. Operating systems don't have every compiler installed by default. To fulfill your requirements, one would have to re-implement every build system and compiler in POSIX shell. Honestly the "better way" that I see a lot of projects going with is to just support multiple options for build systems, because there is no one perfect solution that is going to work on all platforms.

The elephant in the room here is windows, and at this current point in time, CMake is about as portable there as autotools because Visual Studio has built in support for it.

>The separation of the configure step from the build step is needlessly confusing and makes some things impossible.

I'm confused. How do you propose CMake supports all those build generators without doing this?

(PS. I really don't think the syntax is that bad, aside that it is jarring for C programmers, most complaints are overblown and you get used to it once you learn the rules. It might be interesting if someone made a CMake variant with a less obscure syntax but I don't see much motivation for that to actually happen)

>The XRender extension does all the rendering client-side.

I'm not sure where you heard this, but it's not correct, you might consider checking the extension spec and the implementation in the server:

https://www.x.org/releases/X11R7.7/doc/renderproto/renderpro...

https://gitlab.freedesktop.org/xorg/xserver/-/blob/master/re...

The reason why it's not used in all cases is because it doesn't map 1:1 to cairo and there are things missing, e.g. curves probably being the most important. You would have to ask Keith for a definitive answer why this is since he wrote both XRender and Cairo. (I assume it's because Cairo already included the necessary tessellation steps at the time)

Indirect GLX does work great for simple use cases, once you start to add textures into the equation the amount of bandwidth used would probably make it unusable over the network. There has been no serious work in getting indirect GLX working past OpenGL 1.x. I think another one of the main problems is that nobody really came up with a good way for GL extensions to work well there, the server needs to manually add an implementation for every extension you want to use.

From a client perspective it is still the same thing if you're using cairo since that includes the fallback code already. But if you're making XRender requests directly then yeah it wouldn't be. (I don't know of many applications that do this, ideally it's something you want in the toolkit or drawing library)

>Since he is using the Cairo library everything is rendered locally and transferred in uncompressed form to the X server for drawing. The same is true for all font engines which use in the case of Xft the Xrender extension.

So this is not necessarily true, it depends on how you're using Cairo. If you're using Cairo's xlib surfaces, those will try to accelerate with XRender if that's available: https://cairographics.org/manual/cairo-XLib-Surfaces.html

As far as why the toolkits never got on board with it, some do actually use XRender in certain circumstances, but it's hard for all applications to make use of it properly. Most of the advantages go away if you have any images coming down the pipeline at all, or if you need to do any text layout or reading back from the pixmap, or if you have any GL/Vulkan usage in your application, etc. Plus historically I've heard the implementation of this was very inconsistent and on some servers it actually resulted in a slower rendering path, although this should not necessarily be the case if you're using the current Xorg with glamor enabled.

Using Xephyr in that way is essentially the same thing as client rendering. (Xephyr draws the whole framebuffer and then sends that)

Sorry I still don't see the point. We could speculate how things could have turned out differently if they made different decisions 20 years ago, but that would just be it: speculation. If you have some better way to design it that you think could preserve perfect backwards compatibility while allowing the same pace of feature development, you should let them know. Because AFAIK both of those are at odds, no developer can realistically spend time on both for an indefinite period of time, and if there are no new features that anyone wants then backwards compatibility is irrelevant anyway.

>Expecting that it is something that "shouldn't hold up a GTK release" is a completely wrong way of thinking about backwards compatibility

Why? Once you decide to refactor an API you have to maintain an extra piece to translate the old to the new, there is no way around that. Developers can spend time before the release working on this translation piece alongside the new features or they can just release it now so people can test the new API before deciding to invest in developing that. For an open source project I can't see how the first option really makes sense, and if your argument is that they should have been developing it the whole time, that is essentially what they were doing for the entirety of the GTK3 development cycle.

That is being generous in assuming that it's even possible to do this, sometimes a design is so flawed that you can't even make it work at all with the new stuff. At some point you have decide to cut deprecated APIs or you are left with an infinitely growing pile of technical debt. I referred to this elsewhere, but old GTK1/2 applications that use raw unscaled pixel buffers are an example: there is no backwards compatibility that is going to work here that makes them function correctly with high dpi. It simply cannot work if the application is hardcoded to use an old API that has no concept of dpi or scale and assumes a pixel is always the same size. (Maybe someone can cheat with AI upscaling algorithms but those are usually pretty slow :)

I guess to put it another way: I don't see any way that GTK4 could have been designed differently to do something like make it easier to compile GTK1 apps against it while reaping all the benefits of GTK4. If somebody wants to make a GTK1 shim for GTK4 that translates GTK1 API calls into GTK4 API calls, they can go do it now, it would probably be a pain and it's probably not going to magically get you all the new benefits that would come from just porting the application to GTK4 and refactoring to use its new techniques along the way.

That doesn't mean it doesn't work. The package was removed because it wasn't getting security updates, however I see no reason why it wouldn't work if you gather all the dependencies and recompile it.

Cool, I figured as much, I guess that means implementing ioctl() or some equivalent.

Any plans for what to do about GPU drivers?