The javascript is used mostly to drive the shell GUI, it shouldn't be taking seconds off all your mouse clicks. If there is really bad slowness, you should consider reporting that as a bug, it may not be the javascript that's at fault. The performance shouldn't be any worse than a typical lightweight web app running in firefox. That is of course if you ever end up using GNOME again for whatever reason.
I don't understand why you have to wonder what it's doing, the javascript is all self-contained and hosted locally. It's not using npm or anything like that. And the extensions are pretty much the same as any other app you use that supports plugins.
I don't understand what the issue here is or what you want me to learn, those seem to all be bugs that were already fixed. If there are additional unfixed problems that others aren't aware of, and you're not making it up, then please mention those, and maybe I can help you get them reported.
The issue here is that those bugs should never have made it to 'prod'. For absolute die hard fans who say "Gnome or bust", you encounter a bug, you report it, track it, get it fixed, and things are better, until next time the same high level symptom - UI slowness - is introduced, through a different mechanism making it a "different" bug.
Thing is, not everyone is a die hard fan. Developers on Gnome, by definition, are, but outside of that, customers are going to go with what works. And that's not Gnome. Customer's don't care that the UI slowness in version 1 was caused by X, and UI slowness in version 2 was caused by Y. There was UI slowness, which made it unusable, and, well, now they're using XFCE or OS X or Windows. It doesn't matter that there was a bug and it was fixed a year ago. The problem is that there was a bug a year ago, and that particular customer is gone and can't be recaptured - they've got a solution that works and they're not looking to switch to a different one. Especially one that has a history of problems.
I'm not sure where you heard any of that, but I have never heard any Red Hat employees say anything to that effect, ever. Fedora still exists, and to me that seems perfectly fine to install on a random laptop.
Not necessarily with that line of thought, Red-Hat has already acknowledged many years ago that there is no money to be made on the GNU/Linux desktop (Mandrake, SuSE and Canonical also found out years later).
If Fedora (or GNOME, for that matter) fits your needs, you should feel free to use it! But if you're wondering, like the grandparent comments, why projects like GNOME seem to be moving away from fitting your needs, the answer is that they're being designed for Red Hat's enterprise customers first and any use you get out of them is a happy afterthought.
Again I'm not sure where you got that, I have not heard any Red Hat or Fedora developers say that's the focus. In fact if you follow GNOME development, there are various other directions that people are pulling in. It might be the case coincidentally for some things, but that could be yet another one of those happy afterthoughts.
I can't say for sure what the deal is with GTK3, but GTK4 apps are GPU accelerated and should be faster. Though it may come at a cost of using more GPU memory, depending on the app.
I find it pretty disappointing that these type of articles and the resulting comments like yours often can't seem to praise something like IceWM or AwesomeWM without also bashing GNOME or XFCE or something else because of "bloat." Who cares? Do you even care? I don't think you do, you'll just delete that desktop and move on and use whatever you want, and that's the whole point.
Also, your characterization of GNOME's rationale is totally wrong. The goal was never to make a desktop with no features, it was more to make a desktop that is streamlined towards certain functionality. If that's not for you, then use a desktop that's more streamlined towards what you want. There's plenty to choose from. What is the real problem?
Edit: I also want to address another common misconception that I see -- the GNOME Foundation does not direct development in a top down fashion and does not impose any rationale on the project. If some feature was removed, it was probably because an individual volunteer working on it decided that it wasn't worth spending time on that anymore, possibly because the need was better filled by a different project.
All I can say is that GNOME 3 seems to take Havoc Pennington's famous essay about as far as it can go, considering configurability a bug. I don't know exactly when it started, but it definitely came to my attention bigtime with the infamous gnome-screensaver.
Yes, I would agree that a lot of GNOME developers still view that as a design goal. But not all do, and even so, having less configurability doesn't mean less features. If you ask me, practically speaking, what it has meant is that there is a larger collection of smaller apps to choose from. So if the app you want lacks a configuration option, you might be better served by trying to find a different app that just works the way you want the first time.
Can you elaborate? Is there something particular that you need that doesn't work on an RPi? If it turns out to be a small fix, then ultimately you may end up caring a lot less than you think.
Also, telling an individual user to "just use another DE" does not solve the problem, whose effects are widespread, on a whole ecosystem of software, its users, and developers.
Could you please explain specifically what one or more of these effects is? I may be able to offer suggestions on how to mitigate it. When I was talking about using something else I was specifically referring to the article, which is talking about using a different window manager, and makes a good case for switching, and may even be able to help you deal with some of those effects. I assume you agree with the article, if not then I don't understand because it seems odd to me to single out this one passing mention in a paragraph that otherwise goes against what was just said, so please elaborate if you can.
I'm not sure what the other user was thinking about, but I think that GNOME's push towards client-side window decoration is annoying and imposing. Depending on your WM, some applications become "useless", they waste space on small screens and just reinforce a sense of fragmentation. I get that it looks better on GNOME, and I appriciate it when using GNOME, but as there seems to be no system to remove the CSD on traditional systems, I still think it is an overall bad move.
Others may find that pushing towards server-side window decoration is annoying and imposing, so this is unfortunately an area where not everyone can be happy. In any case you may be interested to try a patch: https://github.com/lah7/gtk3-classic
Nope. I will continue to bash GNOME because it's something like "the opposing political party." I want Free Software, and by extension, Linux, to gain ground on desktops, and I genuinely believe that GNOME's "philosophy" is not a good one and is detrimental to this cause.
Roughly, I'd characterize it like the following: I believe that the best way for Linux to gain ground is to be a serious, perhaps even a little boring, but definitely "grown-up" desktop. Simplicity is very important, but tt should lean toward configurability and techniness.
What it should NOT do is what GNOME is trying to do, which is trying to streamline and appeal to everyone. This approach is like trying to beat Apple at their own game, which is dumb -- given that beating Microsoft at their own game is well within our reach. Heck, look at Windows 11, we're like a third of the way there already.
I'm afraid I don't understand what you're saying or what the point of your bashing is. GNOME and KDE and XFCE and whatnot are not political parties and are not opposed to each other. They're not really even close to being that, they're open source projects that collaborate on a sizable amount of things. If you believe there is a better way to do something then just contribute to another desktop. The existence of GNOME doesn't prevent you from doing that and isn't detrimental to it, especially when you consider that the cost of switching to another open source desktop is a big fat $0. Please don't unnecessarily politicize things, one of the benefits here is that you explicitly don't have to do that.
To put it another way: maybe some specific mode of "Linux gaining ground on desktops" with "configurability and techniness" is your goal, but people working on any given desktop (including GNOME) may not share that goal in the same way you do, and it doesn't make any sense to expect them to.
Obviously, I can't expect them to. I'm not paying them. But I can absolutely encourage and discourage different ways of thinking and doing, and I'm absolutely free to express that. And yes, I would like to discourage "the GNOME way."
To elaborate a bit about why I'm saying this; For quite some time, onboarding people to Linux was pretty easy. "Just use Ubuntu" was a really good answer. And then Unity came along, with a) bloat and b) this new paradigm that was ostensibly as simple as a Mac, but different enough that people wouldn't recognize it. And this was a terrible direction for Ubuntu to go, especially since XP was on its way out.
And now, when people ask me, hey, how do I get started with Linux, and they've heard of Ubuntu, I can't just say "Yeah, go for it." I have to launch into a thing and name 2 or 3 different distros, primarily due to the weirdness of GNOME. I appreciate freedom and choice, but I'm also quite free to say, I believe the following: I really wish the GNOME people would more-or-less give up, because they have mindshare not off of the quality of their current interface, but because of the momentum of their old one plus Ubuntu. I believe that (much like Windows, frankly) if they actually had to compete in this space on the merits, they'd lose out.
KDE (and LXDE and others) are doing a better job of making a predictable useful interface.
I don't understand what you're trying to discourage, what you're saying doesn't follow. That has nothing to do with "the GNOME way" and is mostly related to the decisions made by Canonical, who decided to make their own desktop, and then dropped it in favor of GNOME. Asking the GNOME people to give up isn't going to make it viable for Ubuntu to develop their own desktop again that is more to your liking. Your issue is with them, not with GNOME. And according to them, you seem to have it exactly backwards: it was Unity that was not able to compete on merits, so it was dropped in favor of GNOME.
But anyway it sounds like you just fixed that by using a different distro, you can even just suggest the KDE or LXDE spins of Ubuntu. Those still exist, and it's not hard to use them. If you're already using them then it's very hard for me to see what your actual complaint is or what you're trying to discourage. It's true you're free to express what you want, but please consider that what you're expressing may not be something that was done with having the full information. I've noticed there is a lot of confusion about what GNOME is and a lot of people seem to mix it up and equate it with Ubuntu or Red Hat or something, which is understandable, but it's not true. I'm only here to explain why.
And just to make it painfully clear: it is already hard enough to maintain open source and fix all the issues and improve the quality of the current interfaces, without people constantly demanding that open source maintainers give up and stop fixing bugs. If you want to get things fixed, you really don't need to do this.
It's not all that complicated. I'm presuming there are people and companies out there working to make these interfaces, to some extent, for other people to use. Maybe it's business, maybe it's love.
Thus, I'm commenting as a fan/user/potential customer, who might find this useful in some way. Or not. Sports fans can talk about their team or the state of the game or what they like and don't like. That's what I'm doing. I'm not "demanding," and if anything, I'm arguing for less work. By the GNOME people, because their thing is a waste of time. Go work on the better things :)
This is incorrect. GNOME users would not consider it a waste of time, just like KDE users would not consider it a waste of time for someone to do work on KDE, or Mac users would not consider it a waste of time to work on macOS, etc. Please consider that your suggestion can be considered rude, you are simply not the target audience.
In general, open source doesn't work like this. These are volunteers, nobody can really tell them to go work on something else, because they work on what they feel like, which may or may not be seeking the approval of people like you. If you want to find another project that seeks your approval, that's great, go do that, let us know about it later and maybe I'll even try it out. If your goal is to harass open source developers until they quit open source, then please stop doing that, that would be making it worse for everyone.
Sooo, I think this is an overly simplistic view, and this is probably the conversation we should all be having, what's driving a LOT of this isn't "what developers choose to spend their time on as something like a hobby." And perhaps it's not the developers who we should be talking about anyway, I'll grant that.
There are "moneyed" business interests who have a lot at stake at their team winning mindshare and profits. Now, I have no problem with businesses being businesses generally. But part of their "product" is these interfaces. And so again, what I would suggest is that pushing GNOME type interfaces is, long term, a bad strategy that is likely to continue the trend of "Linux" being a second class citizen, by wasting energy toward the impossible goal of beating MacOS at their own game.
Conversely, pushing more configurable and slightly more techy KDE-like interfaces I think has stronger likelihood of making "on the tech margin" people more excited and interested in Linux, and ends up helping more people overall.
Now, I could be wrong about this -- but, while I definitely agree with "no one should to demand what open source developers do, especially if they're not being compensated" -- it's equally as bad (if not worse) to suggest "let's not offer big-picture criticism of trends in open source software that affects a lot of people."
Aslo I absolutely accept that what I'm saying is rude. It 100% is.
I adhere to the idea that you should never be rude unless you feel there is something at stake that makes being rude worth it, and I think "trying to gain ground on the Linux Desktop" a thing that affects LOTS of people outside of the developers, is.
> I'm afraid I don't understand what you're saying or what the point of your bashing is. GNOME and KDE and XFCE and whatnot are not political parties and are not opposed to each other.
They surely where born that way, GNOME only exists due to the original Qt license.
Then Gtk+ was always the go to framework for C devs, while KDE was embraced by C++ community on GNU/Linux.
Murray did a very good job for the C++ refugees on GNOME/Gtk, but that has always been a minority versus being on KDE land.
I figured you would post that. I have heard no actual KDE developers saying that's a problem. They don't use Qt LTS. The "drama" there seems to be mostly confined to unrelated internet forums.
As for your posts about C, I can give a personal anecdote: I would agree with those sentiments, C has a lot of really bad problems as a language. But yet, I still write it a lot more often than C++. So It's not as simple as you're making it out to be. Also I checked some of those slides and I wouldn't describe anything there as a "flame war."
>Everything that implies taking sides is politics, no matter what.
If you really want to look at things that way, you could, but this seems to not be strictly true. Just because there is taking sides does not mean there has to be fighting or politics.
Gnome feels like what you’d get if someone read a lot about macOS and wanted to emulate it, but had never actually used it. Gnome makes it very easy for new users to get started and very hard for experienced users to adjust it. Mac makes it easy for new users, but still gives power users room to grow.
Specially in the what concerns the developer experience of macOS, regarding frameworks, IDE and languages.
On GNOME the documentation seems to have stagnated, then we had Anjuta, now GNOME Builder (which tries to be XCode like), a UI design tool that is being re-written from scratch, the various frameworks don't seem to compose, and then each binding does their own stuff, only adapts a couple of Gtk tutorial samples to their own language.
Naturally being GNU/Linux, everything that falls out of the UI only has POSIX or GNU/Linux specific C APIs to refer back to, yet another experience completely devoid of how things work on macOS (there is no Foundation, Accelerate, Core...).
Depends on the year, if you haven't been paying attention they are on their way out, and then we have again the issue of documentation, tooling, language bindings,...
> Gnome feels like what you’d get if someone read a lot about macOS and wanted to emulate it, but had never actually used it.
I find this statement humorous because I've said much the same thing about Linux Desktop GUIs in general. "It's like they were made by someone who's only ever had a GUI described to them in an email". Compared to a system like the original Macintosh or RiscOS that thought hard about how to abstract things for a graphical display and a mouse, or even Windows that just copied as much of that as they could get away with, it's really quite terrible.
Sorry to disappoint you but GNU/Linux is definitely not a third of the way to compete with a Windows 11 desktop, and the best it will ever manage is to run on top of Hyper-V.
> “Who cares? Do you even care? I don't think you do“
> “ The goal was never to make a desktop with no features”
Wow, your first paragraph you accuse people of lying at worst, or capriciously taking a position that doesn’t matter to them at best. It gets better in paragraph number two where you misquote GP and go boxing with that strawman.
So to address your first paragraph, I’d say people here care a lot, and the bashing they do is not out of a place of tribalism, but out of a place of constructive criticism. Most of us here would LOVE to see improvement in $ArchEnemySoftware, and the failures strike deep because this stuff means so much to us. A mixture of disappointment with the status quo, and/or poor judgement calls with design or execution, rather than knocking a bit of tech that doesn’t appeal to us.
As for the second paragraph, GP didn’t say “no features” in reference to GNOME, but decried the basic features that were removed, thereby rendering the software less useful to them.
I’d take a brighter outlook on discussions like these, if the points land on the right ears, perhaps positive change might happen in GNOME. We can hope anyway.
I'm not accusing anyone of that and I'm not misquoting, please stop with this hostility. In my experience, people are happy to switch when it suits them. By "no features" I was referring to those basic features. Sorry for the misunderstanding.
I also didn't see any constructive criticism, if you have any specific suggestions for positive change you'd like to make, then please make them. I'm all ears. But for the record, if you'd like to get involved in development, places like HN and reddit are generally not a good place to do it. The people who are most likely to listen to requests don't visit here.
So let me get this straight. According to you, I should not criticize software that does not meet my needs lest it be interpreted as bashing and ruin the party for those who do use the software in question?
That’s my take, please correct me if I’m not understanding your point properly.
Also, no hostility here. I find these discussions illuminating.
As for Reddit and HN, these places are excellent places for such commentary. Often times the maintainers of different packages heed complaints leveled here and change their ways. That’s a win for everyone if the change is a positive one.
If you have something you want me to understand, please explain. I'm happy to listen to what you have to say. Like everyone else, I'm not perfect, sometimes I don't understand things and I need some help from people like you.
That's not correct, as a show of good faith I've explicitly asked for specific details on what the complaint is. I can't help you if you don't provide those details. If it seems I haven't done that, I apologize, that was not my intention. I'll try to be clearer next time. Let me know if there's anything specific you want me to clear up.
I find it really weird how you seem to think you’re the arbiter of how much people care, when they can share their opinions, and what opinions are valid.
Perhaps you should keep those ideas to yourself and only concern yourself with your own level of contribution to the topic at hand. I don’t need you to mind my comments.
I don't think that at all, I'm just another person giving my opinion, like you. Also, I don't understand why you said that, but then asked me to keep my opinions to myself.
> “ I find it pretty disappointing”
- Then you go into the praise vs bashing.
What do you find disappointing? I guess that’s what I’m driving at.
When somebody knocks MacOS, and it’s a valid point, I hope somebody from Apple is reading! Then maybe it gets fixed. So why would that arrangement disappoint you?
For me personally I find the endless "Linux desktop wars" to be disappointing. It doesn't matter, this stuff is open source, if you really want it to be fixed then just go write a patch. But in my experience most people will just take a few minutes to switch to one of the many alternatives.
I'm just relaying what other people have told me, these type of forums are full of uninformed comments, and are not a good place to solicit feedback. You could hope that maybe an Apple engineer would read it but they probably won't. You would have better luck sending them feedback through their official channels, where you know they will read it. If you're giving feedback to a YC startup then this would be a good place, but otherwise not so much.
“ these type of forums are full of uninformed comments”
Hacker News has solid representation from Big Tech, FOSS projects, and Academia. What data do you have to back up that this is a bad place to air grievances with software?
Whenever anyone mentions Amazon, my ears perk up. If it is within my power to correct, I take action. So what data do you have to support the assertion that HN comments are uninformed, and that this is only a good forum for YC startups?
That's just my personal observation, I haven't seen many unfocused airings of grievances that ended in positive change. Sure there are knowledgeable people here, but they may not always be speaking within their area of expertise; it helps to direct it at someone who is within that area of expertise, in the case of HN, that area is startups.
I've seen plenty of complaints about Amazon here go unanswered. Amazon is a pretty big company, I'm guessing you don't know everything about it and may not be the right person to ask about many things. If I had a question, I'd definitely ask you if it was something you were an expert in, but I don't know what that is because you didn't say.
Thank you for doing that, it's really fortunate that you are, but please understand that not all of your coworkers do the same thing. I think it would be nice if they did, but currently they do not.
Yeah you’re right. But I care about this stuff a lot. I love tech, I love the life it has afforded me, and I want people to have a good experience, even if it is something as simple as billing software!
Obviously Amazon has some huge issues to overcome, both culturally and policy wise. If you keep bringing issues up, I’ll do my best to get them in front of the right folks.
The people that characterize GNOME this way are desperate to identify themselves with a certain sub group of Linux users that prides themselves in doing things the hardest possible way (such as recompiling your terminal every time you want to change the font size) because it makes them feel 1337. Don't sweat it too much, it's just a little bit of garden variety internet tribalism.
I don't understand why anyone has an issue with that. You know what else can copy and paste code all the time? Humans. But we have various ways of stopping employees who copy and paste code from stackoverflow and github without checking the license, so it's the same thing if you use one of these tools. There's nothing new I can see here to be upset about.
This would be a lot more interesting if it showed the various GPT-3 experiments at generating music and used that as a point of comparison.
> But we have various ways of stopping employees who copy and paste code from stackoverflow and github without checking the license
What would those be? I’ve worked at a number of organizations that were (rightfully) paranoid about accidentally incorporating GPL code, but even there I wasn’t aware of automated tooling to prevent it, it was only enforced through developer vigilance.
If you actually want a paid service, there are plagiarism detectors like Fossa and Codequiry. Although in my opinion, code review should be enough to catch any "accidental" incidents of plagiarism, the differences in writing style should make it very obvious when the employee has copied something. That of course probably won't apply if you suspect the employee is intentionally changing it around to obfuscate the origin of the code, but it seems that wouldn't be the case if they were just committing the output straight from a neural net. But automated scanners probably won't be able to catch those well either -- the way to catch that would be to make them do pair programming a lot.
>Although in my opinion, code review should be enough to catch any "accidental" incidents of plagiarism, the differences in writing style should make it very obvious when the employee has copied something.
You must do some CSI level code reviews. Best I'm able to do is figure out if code will work and if something can be done obviously better. Stylistic calls (beyond lint enforceable) are up to authors as far as I'm concerned.
And even then it's trivial to fix up naming schemes and such to march codebase - doubt that gets you out of copyright issues.
I mean in cases where someone just copy and pastes something without making any effort to match the style, or in cases where they can't explain what a piece of code does or how they came up with it. You should be able to spot those very easily in code review. If somebody is trying to fix up the naming schemes to avoid being detected and for whatever reason is able to explain the code perfectly, then I'd imagine that person would probably be doing the same bad things regardless of using copilot -- it's not like it's hard to search stackoverflow and github for code snippets.
Please don't assume bad faith. Glade was not "killed," there are technical reasons why Glade cannot be used for GTK4 (I can give more detail if you want). There is currently a new tool being developed by a Glade maintainer, catch this guadec talk later this month if you want to know more: https://events.gnome.org/event/9/contributions/191/
Nobody is particularly happy about having to edit the XML directly but it's the best option right now until the new tools stabilize.
I think that this might speak to the deeper problem that a lot of people have experienced with GTK: stability. The project isn't a huge well-funded company with lots of vendor-lock in like Microsoft is; it can't afford to be rethinking how the GUI toolkit should work every few years like Microsoft does. (Or continuing to support and maintain all the old no-longer-favored GUI frameworks like Microsoft does.)
It's great that GTK4 has decided to commit to API stability, but, at this point, it may be too little, too late as far as the project's reputation among many developers is concerned. Having to lose a venerable tool like Glade to get to the API-stable version doesn't exactly take the edge off.
I've posted about this before, but if you want GTK and you believe API stability is the most important thing then you should just use GTK3. The API there is frozen. I'm not sure what "reputation" you're referring to but if GTK does not meet your needs, and Qt (or something else) does, then I think that's great for you, you should just use that.
GNOME being slow and not having basic features like thumbnails in the file picker after almost 18 years was often attributed, by their maintainers, to be caused by GTK3 limitations. Even now Glade still needs a lot of "volunteering" to be production ready for GTK3. I don't use GTK anymore, this is my opinion after reading a lot about it and seeing recommendations like "if you need documentation just read existing code", "why is Glade missing X or Y? just copy some XML node, just edit the XML and pray".
Anyway who cares, maybe GTK4 is good and new GTK threads will not be full of people talking about how bad it was. But why not move the tools together with the rest? I know, it's open source, lack of maintainers, but I wouldn't dare to declare my toolkit stable until basic tools work. Qt is also guilty of doing that in some ways but at least the previous version is still production ready and they move really fast.
I don't know I'll ever get over my irrational anger about how they handle(d) GTK.
> if you want GTK and you believe API stability is the most important thing then you should just use GTK3. The API there is frozen
That is certainly not a solution, you just postpone the problem.
The real solution would be the Gtk4 to be 100% backwards compatible at both the API and ABI level with Gtk3 and similarly with Gtk5, Gtk6, etc.
Otherwise you're just subscribing to wasting your time - it might be now or it might be 5 years from now, it doesn't matter however as it will happen unless the Gtk developers finally decide to stop breaking their library every few years.
(of course don't get me wrong, it is their library and they can do whatever they please with it, they are giving it for free and they are not beholden to anyone - however that doesn't mean others like to have their code broken and waste time that they could use to improve their applications instead)
Alternatively GTK3 could get a higher level of ongoing support. That was what I was alluding to when I referenced Microsoft. For example, WinForms has technically been superseded for ages now, but, while it's not necessarily getting any big new features, WinForms apps still look decent on newer versions of Windows, benefit from things like updates to the common dialog boxes, and continue to be well-supported in new versions of the developer tools. So one doesn't necessarily have to have a lot of anxiety about leaving an old WinForms app on WinForms. With GTK3, on the other hand, I would guess that it's going to get the absolute bare minimum of love, and probably become a liability rather sooner than I might like, because the project simply doesn't have the resources to maintain a higher level of support.
And yeah, you're right, the GTK team isn't beholden to anyone. But... GUI code is expensive to write and expensive to maintain. So a GUI toolkit can have an outsize impact on the health of projects that use it. There's value in talking about things like this publicly, so that anyone who's shopping for a GUI toolkit can have a better understanding of what they might be getting into.
Ideally they could have done that with Gtk2 which would continue on to Gtk3 and Gtk4 without breaking backwards compatibility.
Of course yes, the next best thing wrt. backwards compatibility is at least not breaking what works - but IMO that is a waste of time for both the Gtk developers (sure, it'd be self inflicted, but still) who would need to support two (or three or four or however many times they decide to break their own APIs) libraries that do essentially the same thing in different ways, and for the developers who at the end of the day will most likely need to move on to the next version at some point to gain access to new features that they may need - so they'll spend that porting time anyway.
> And yeah, you're right, the GTK team isn't beholden to anyone. But... GUI code is expensive to write and expensive to maintain. So a GUI toolkit can have an outsize impact on the health of projects that use it. There's value in talking about things like this publicly, so that anyone who's shopping for a GUI toolkit can have a better understanding of what they might be getting into.
Indeed and this is why i mention my issues with backwards compatibility whenever i see it being relevant.
I do believe the Gtk developers are free to do whatever they want as they are not beholden to my -or anyone else's- wishes for stability, especially when they give out such an otherwise high quality library for free. However that is from their perspective.
From the library users' (that is the developers who use the library) perspective however there are additional issues, like all the time you spent learning the library (breaking the API invalidates your own knowledge which is something that is also important - unless you plan to somehow live forever it makes sense to want to avoid this sort of "knowledge churn" :-P) and writing the code that uses it (important especially for framework-style libraries like Gtk that put their tendrils everywhere in your application). And even if someone believes (wrongly, IMO) that commercial developers can afford all that time, it still is an issue with FLOSS since the vast majority of which is developed during its developers' free time: that time would have better been used to improve the applications instead of keeping up with their dependencies' breakage (e.g. XFCE or... Gimp :-P).
And of course from the end users' perspective it also means that even if the developers decide to drop a program, they can keep using it for a long time without having to worry about the libraries their program depends on getting stale (since they are linked dynamically), not supporting new features (like, e.g. Wayland - AFAIK Gtk2 apps do not support it natively and chances are if a new display server is made Gtk3 apps wont support it either) or having unfixable security issues (for the applications where that makes sense at least).
But yeah, Gtk developers - or any library developers - do not need to care about all of that nor they have to really. As you wrote, it is the developers who decide or not to use a library that care about such things mostly.
Sadly at last on Linux there aren't that many choices: of the "mainstream" toolkits only Gtk and Qt exist. Gtk is, well, Gtk and Qt cannot provide "perfect" ABI compatibility even if they wanted to because of C++ (there are some hacks that could be made but i am not aware of any project doing such a thing - i think only Haiku does something similar with proxy libraries that forward the GCC C++ 2.95 calls to modern GCC C++ calls for BeOS compatibility). But Qt is also a different beast, they are a middleware company with different priorities, the people that pay money on it (and thus affect these priorities) do not care much about providing a stable platform and can affort to waste time on upgrades. From other toolkits there is also Motif but that fell out of favor and got opensourced way too late to make much of a difference - its API/ABI is stable though and has been stable for decades, but that means nothing when barely anyone uses it or develops for it.
Personally i use Lazarus and LCL. LCL uses a variety of backends, kinda like wxWidgets, but unlike wxWidgets it doesn't break its API. This pushes the issue of keeping up to date to the LCL developers (who could have spent their time in fixing LCL's other issues - of which are many - instead) but that is how things are.
I think Java and SWT might be another stable solution for a native UI, AFAIK this never broke backwards compatibility either... or at least it never did back when i looked into it several years ago. Looking at some examples in their site, several of them seem to be somewhat old so it probably is stable (isn't it great how when you do not break your API left and right you get to also get time to build better documentation that you don't have to invalidate it after a while?)
> Qt cannot provide "perfect" ABI compatibility even if they wanted to because of C++
That does not really matter in practice though. I ship a Qt app as AppImage, it works fine from CentOS 7 to the very latest ArchLinux. I just ship libc++ along with it - which is the same that I have to do in Windows anyways.
Of course it matters in practice since we're talking about dynamic linking that applications can link against the OS-provided libraries so that they can keep gaining new features and bug fixes.
A trivial example on Windows would be how Win32 applications get to use the Win+; emoji popup even if they were made before Windows even got that feature, or how even classic VB applications can be made to run in HiDPI mode by ticking a shortcut checkbox despite being written decades before HiDPI was even a thing (assuming they use twip instead of pixel coordinates at least).
Or on Linux, how some old games made for it need their bundled SDL removed so that the games can use the system-provided version because the old version tried to use OSS or whatever was common at the time the game as written and the new version can use ALSA or even Pulse that didn't even exist in older times. And i remember reading on twitter about some distros planning to provide the SDL1-to-SDL2 wrapper as an option instead of the real SDL1 because it provides better compatibility with some modern window managers... and Wayland (that SDL1 doesn't support at all but the API doesn't really make a difference and could work perfectly fine with Wayland).
> which is the same that I have to do in Windows anyways.
Windows comes with WAY more functionality out of the box so that applications do not have to rely as much in their own libraries and can rely on the OS to provide and keep functionality up to date. Of course applications can ignore that, but they just do not get those new features and fixes.
The recent Visual C++ runtimes not being part of Windows is a baffling and really stupid decision though. I am certain it has more to do with internal politics and feuds between WinDiv and DevDiv than something practical.
> A trivial example on Windows would be how Win32 applications get to use the Win+; emoji popup even if they were made before Windows even got that feature, or how even classic VB applications can be made to run in HiDPI mode by ticking a shortcut checkbox despite being written decades before HiDPI was even a thing (assuming they use twip instead of pixel coordinates at least).
eh, I really really disagree with this. In my experience more often than not this kind of changes breaks the app in various ways. What if the app was using that shortcut for something else ? Now it's broken and can't be used anymore.
Likewise for the hidpi thing that windows does, it's terrible - running the app at original resolution and applying a 2x nearest neighbor filter to the whole window would be better than that mess of "crisp" text with upscaled pixmaps that were never made for this resolution.
> Or on Linux, how some old games made for it need their bundled SDL removed so that the games can use the system-provided version because the old version tried to use OSS or whatever was common at the time the game as written and the new version can use ALSA or even Pulse that didn't even exist in older times. And i remember reading on twitter about some distros planning to provide the SDL1-to-SDL2 wrapper as an option instead of the real SDL1 because it provides better compatibility with some modern window managers... and Wayland (that SDL1 doesn't support at all but the API doesn't really make a difference and could work perfectly fine with Wayland).
I strongly believe that for old games / software it's better to use a VM / emulator for hardware of that game's era.
> eh, I really really disagree with this. In my experience more often than not this kind of changes breaks the app in various ways.
What did break?
> What if the app was using that shortcut for something else ? Now it's broken and can't be used anymore.
Win+; is very unlikely to be used by anything and it is handled by the window proc of the EDIT window class, meaning that other stuff (e.g. accelerators, which are used to implement shortcuts) get to take first dibs. So if an application was using that shortcut it wouldn't reach the EDIT window proc anyway. It isn't any different than an application replacing the right click menu of a text field - the applications that do not do that (ie. most applications) get the new entries introduced in (IIRC) Vista about Unicode characters, etc and the (few) applications that replace it just do not get these options but their menus keep working.
> Likewise for the hidpi thing that windows does, it's terrible - running the app at original resolution and applying a 2x nearest neighbor filter to the whole window would be better than that mess of "crisp" text with upscaled pixmaps that were never made for this resolution.
Note that this is what Windows does by default, what i describe is something you can do manually.
But personally i disagree, i'd rather have crisp text (which is what the majority of a window contains) and a few upscaled bitmaps than lowres everything.
> I strongly believe that for old games / software it's better to use a VM / emulator for hardware of that game's era.
I play a ton of old games and i completely disagree with this. VMs pretty much never work properly and have all tons of issues. Emulators are very slow. And above all, running games on modern hardware allows for higher resolution and maxing out graphics that was often impossible in original hardware (e.g. forcing 32bit color, antialiasing, anisotropic filtering, etc). Not to mention the potential for mods that improve parts of the game which would be impossible on original hardware.
What you've said is really not correct, at all. For one, Glade is not deprecated in the sense that it doesn't work any more, it still works okay with GTK3, however it has a number of limitations that may make it difficult to use (which it always had, nothing has changed here). Two, a replacement is being worked on, I'm really not sure what your criticism is besides "go faster" which, I'm sure we all wish we could write code faster and have it work perfectly and do everything the first time, but that's not realistic.
Edit: Just to be clear here, in my opinion the new tools will likely end up being a large improvement on Glade. Glade is a pretty old application that by design does a number of weird things that don't match current best practices, you can see some of them if you read the blog post that was posted above.
> The fact that that Glade was deprecated without a replacement being ready means exactly that GNOME does not "value good UI/UX tooling".
That's a false dichotomy. It could be (and I believe is) that things are a tradeoff. They obviously value good tooling (what developer doesn't? and look at the docs), but they value other things too and had to make a decision. With limited resources you can't do it all.
> Nobody is particularly happy about having to edit the XML directly
I wouldn't mind editing a concise XML dialect (XML really doesn't have to be monstrous, a dialect it can be designed with humans in mind). A visual designer producing XML files as its output doesn't actually solve the problem. VisualStudio's developer experience (where you can change everything on the fly, go to the relevant piece of code in a click or two, refactor something and get it also changed in the designer etc) feels really seamless and fluent while PyQt with PyCharm+QtDesigner seems nice but not nearly like that. It seems to me nothing can be considered a serious and worthy improvement until we have an actual integrated visual RAD IDE. I would immediately buy the paid version of PyCharm (I'm using the community edition if they built a good and well-integrated visual designer in it, for whatever a desktop toolkit they prefer).
Thanks for the link, I will watch it when the opportunity comes.
However it is like the sibling comments mention, this hasn't been properly managed as message to the UI/UX community.
So when someone used to Forms, WPF/Blend, Qt Designer, Interface Builder, Delphi, C++ Builder, Swift UI, Flutter, JetPack Composer,... sees blogs and tutorials where .ui files are written by hand and direct use of GtkBuilder is praised, eventually all interest is gone.
That blog is just one developer's opinion, not an official statement. Although I will say I share the opinion, Glade messes up my ui files and I can't recommend using it if you want to use any newer widgets. It has always had those problems, but now with GTK4 it's no longer really worth it to try to work around them.
Also, Glade is not really even used by GNOME designers that much, what they do is make mockups in some other tool (usually Inkscape) and then have the developers implement it. I don't know about other GTK based desktops, though I think some Elementary developers are working on this: https://github.com/akiraux/Akira
>which violates the "no restrictions on use" clause from the GPL
This seems to be a bad interpretation. This is not adding restrictions on use, this is complying with other legal restrictions that are already there. If that were true, you wouldn't be able to have things like chat clients be GPL, because the same restrictions would apply there with allowing chat servers to collect data.
The GPL and the FSF legal eagles have a long history of replying, "Then you can't have things like that. Sorry."
I suspect there would also be an argument that an intentional distributed system like a chat client/server would be a different beast from an application like an audio editor.
It would be nice if you were more specific. Most of the serious complaints I see artists making about GIMP are about lack of non-destructive editing features, or about lack of support for specific workflows, which are technical issues, not UX ones (and ones that are being addressed, slowly).
I want to do a basic thing in gimp, draw a circle. How do you do that? First you click the rectangle button, then you select "elipse select", then you select an area, then you click edit and fill with color. This flow is much more unintuitive compared to anything else I've seen, why would you click on the rectangle to draw an ellipse? And then suddenly that button is no an ellipse, so next time you want to draw a rectangle you now have to click on the ellipse button and switch it back to a rectangle.
And that is just one thing, the whole program is littered with small obnoxious design decisions like that. Maybe you can learn to get used to it after a while, but if you have to go through a tutorial and get lost the first 20 times you try to draw a basic shape then your drawing program has bad UX. In the end you will learn that the ellipse button and rectangle button are the same things etc, but until you learn all those things the program is just frustrating to use.
That again is not a UX issue, that is a lack of shape tools for that particular workflow. Like, this is not something you can fix just by moving some buttons around or by changing the name of the ellipse tool to circle draw tool and having it fill automatically (i.e. bugfix-type things that a UX person would do), somebody has to implement an entirely new feature for that to work the way you are expecting, and then it would need to be redesigned as well. And GIMP historically has not been focused on shape drawing. If you want an open source program that focuses on shapes and vector drawing, you may want to use Krita or Inkscape. Or you can try developing what you're looking for as a GIMP plugin, and the going from there and trying to get it merged upstream if it's popular enough.
UX is User Experience, not User Interface. Lack of tools to do things quickly and easily with discoverability is a huge UX issue.
And then the rectangle button changing to an ellipse button just because that was the most recent sub tool you used is a UX issue that is purely in the UI. I probably lost several hours to that until I understood what happened, because I couldn't find the buttons I wanted to click on and then assumed I had to look for them elsewhere etc. And it still is bad even after I learned that since everywhere I look at tutorials how to do stuff the menu looks different since they had different previously active tools so it is a pain trying to figure out what to click.
What you're saying doesn't really make any sense to me, that's like saying you bought a sedan and found that it didn't have a pickup bed, so now it's a UX issue because you couldn't quickly and easily figure out how to move a refrigerator with it. Not everything is going to have the same tools, or support the same workflows. Maybe that's a problem that needs solving but it can't be solved by UX designers trying to redesign the sedan -- you would just get a trailer and put the refrigerator in that.
You're right about the tool menus, those are an actual UI issue, but they can be disabled. Maybe they should be disabled by default? I can't say.
Drawing a circle isn't a new feature, the feature already exists in the program. It is just that the workflow to use the feature is very burdensome, all they need is a button that does several of the steps at once. It wouldn't implement any new behaviour, it is just a quick button.
Now, it would take some work to implement those quick buttons, sure, but that is purely an UX change it doesn't add any new capabilities to the program, it just makes some actions easier to do.
Basically, the feature lacking in the program are those "quick buttons" which would make adding these simple UX fixes easy rather than burdensome engineering work.
And I'm saying you're mistaken, that feature never really existed. Trying to hack the ellipse tool into "quick buttons" to draw circles would not be what is expected, would not match the capability of other vector drawing tools, and would probably create other UX issues in the process. But of course, if you thought that was a good idea, you could easily make a plugin that does that, and test it out for yourself.
Zxzax is correct that GIMP is an alternative to Photoshop, so the tool pallet is appropriate for editing photos. The typical workflow is: (1) stack layers, (2) mask layers, (4) composite. It’s rare to draw a circle on top of a photo. Usually it’s most efficient to select an area of a photo with a rectangle to isolate it on a layer, then use masking to refine the non-rectangular edge. If your goal is to draw a 2D illustration & work with gradient meshes, then Inkscape is an alternative to Illustrator. Both those programs are for illustrating in 2D and there are purpose-built features for drawing & editing shapes.
That said, GIMP does have real UX issues. For example, the controls and GUI elements don’t scale well to high resolution screens and could be much better on tablets like the Surface. They’re also missing CMYK color space support. But, I always assume they’re waiting for Adobe patents to expire to add those features.
I've used photoshop, its UX wasn't nearly as bad. Me as a user had a pretty good experience with photoshop, but a really bad experience with gimp. Hence gimp has bad UX and photoshop has ok UX, according to me and most people I've seen. People trying to convince me and the other people that our experience wasn't all that bad with Gimp is the problem here, that attitude ensures Gimp will always have bad user experience.
Just to clarify, GIMP definitely has issues, and I'm not trying to convince you otherwise. But they are not issues that can be solved with more UX research or what you would typically call "UX work." That's what I think the misunderstanding here is, please don't misinterpret what I'm saying. The UX issues that are there are already known, what's left is to do the (hard) work of fixing it.
I'd argue that UX requires a lot of engagement and work by software engineers. Sure it isn't work people with the title of "UX designer" or whatever would do, which is why the UX role is usually bullshit, but it is still work needed to fix the UX. And small developer led teams often refuse to bother to even consider that they have to change anything to fix these things.
You are correct that it does, but not every change made by engineers is a UX change. But even if you want to think of it like that, the backend changes still need to happen first in order to get any significant UX change going.
>small developer led teams often refuse to bother to even consider that they have to change anything to fix these things.
Out of curiosity, what task were you using gimp/photoshop for: (a) edit a photo, (b) draw an illustration, (c) draw a diagram, (d) annotate an image or map?
The DPI scaling issues should be mostly fixed in GIMP 3.
CMYK support is not a UX issue, that is another thing that's missing on the backend. I don't think it has anything to do with patents, the problem is more because of lack of manpower.
I think this discussion highlights perfectly why Gimps UX sucks. It is because the people who made it has a view on UX like you do and refuse to put in the work to fix it, with arguments such as "That isn't an UX issue" and so on. Fact is that Gimps UX sucks and people will have to live with it since it is a free product so the developers don't have any reason to do what you want.
Anyway, you might be right about this issue, I am not an expert on image editing. However I do understand UX and your view on development will lead to horrible UX like what you have in Gimp. It might work great in enterprise products where you sell features and not UX, but a product intended to be used by normal users needs more work on UX for people to like them.
I'm saying this as some who's done UX and is familiar with the problems in GIMP, there really is no quick fix that can be done here. If you view everything as a UX issue that can simply be solved by moving things around, then we can't really have a discussion because there is no meaningful distinction we can make. The major issues with GIMP are mostly on the backend. The work is being put in to fix it, but it's slow going because there are not enough people working on it. I agree with you that people would really see it as a UX improvement if there were good shape tools like photoshop has, but my point is you can't just get that by changing around the ellipse select tool. If it were that easy, somebody would have done it by now. The GIMP people I've known have said they would love to fix a lot of things but it's harder than it seems and they don't have infinite time.
Just to make it a little clearer what I mean here: if there were actual shape drawing capabilities on the backend then it would be pretty easy to make any kind of circle/ellipse tool that you wanted, or set up the circle tool to do what you want by default, but those don't exist right now.
> If you view everything as a UX issue that can simply be solved by moving things around
That isn't what UX is about. I am making games, and stuff that isn't simply moving things about is a core part of user experience. For example consider a game where you want to move around armies on a map. You can implement that by moving around the armies using numpad only, or you can calculate a shortest path on a mouse click to a location and show it to the user. Both allows the same kind of movement, but the second offers way better user experience which is why all modern big strategy games uses it over one step at a time movement.
> but my point is you can't just get that by changing around the ellipse select tool
I never said that a good UX was easy, I just said that the developers of GIMP didn't want to put into the work to make GIMP have good UX, and a lot of that work is redesigning the technical architecture or implementing those features the tedious ugly way. It is possible to make it decently easy to make easy to use tools for gimp, I just don't know all the details of what those tools should do exactly but I know how to build that sort of things. When making games you don't have as patient users as you have in GIMP, so you'd never get away with that kind of UX, so from my perspective when your product has GIMP's level of UX then it isn't complete as a product since it would basically ensure business failure.
I'm not much of a gamer but what you are describing doesn't seem to be relevant, for example there are simpler games where moving using numpad is perfectly usable and desired. There is not really anything specific you're designing for there, you just chose to make that type of game.
>the developers of GIMP didn't want to put into the work to make GIMP have good UX
From what I have heard from GIMP developers, this is not correct. There is plenty of desire to fix issues, the main issue is lack of contributors. Please help if that's what you're interested in.
You're talking about "getting away with the UX" but I'm also not sure what you're talking about there, GIMP is not a commercial product that is trying to get customers. It's an open source project driven by volunteers who improve it in their free time because they feel like it.
From experience I am almost certain the issue has to do with architecture, the original developers didn't properly consider UX when making the first steps and that has shaped how everything else was implemented in it, and this is the end result. Fixing it at that stage is way too much work as you said, rewriting all tools and the UI from scratch would probably be the easiest way to fix the UX at this point. If it was easy then it would have been fixed as it is an open project as you said.
I don't understand why you have to wonder what it's doing, the javascript is all self-contained and hosted locally. It's not using npm or anything like that. And the extensions are pretty much the same as any other app you use that supports plugins.