zxzax

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.

The GIMP developers are aware of this pitfall and want to avoid it, there is even a FAQ entry about it: https://www.gimp.org/docs/userfaq.html#i-dont-like-gimps-use...

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.

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.

That seems to not really be relevant, if you want to have a data-driven development process, then you have to, you know, collect data. If you said they should just use email or github issues or something, and have people submit their feedback manually, those have the same deal, and they still would have to comply with COPPA regarding that data.

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'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.

You really do not need to go to bat for 4chan trolls. There are much better ways to spend one's time.

>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.

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.

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.

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.

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).

People have lost their minds, because they don't want to see blackface, even in an ironic context? I wish you wouldn't say those things, because I feel the same way, I really don't want to see it, and I don't find it funny or worth seeing in any context. Please don't assume that everyone likes the same jokes that you do.

It still is irrelevant, if you use it offline, or you opt out of the analytics. Yes, an adult will probably have to set it up that way for them, but this has always been the case with any internet-enabled computer: it falls on the parents (or the school, childcare service, etc) to set up parental controls and oversee the child's online activity.

I mentioned this in the last thread here, but due to COPPA, generally it is illegal for businesses operating in the US to collect data on children under 13, even if you ask (there are exceptions but usually you need to prove that you have the parents' permission). They are doing what is required by the law, and in fact it was probably already illegal for children under 13 to use the product in ways that could generate personal data. So nothing has really changed, it seems they are only explaining what the situation already was.

I view that as a positive. Like a lot of other things in the US, the film industry has a long and racist past starting with the infamous "Birth of a Nation," which was highly profitable at the time of its production, but you couldn't make a blatant racist propaganda film like that now, which I'd say is for the better. The article mentions "Borat" which is an interesting example because I'd imagine a lot of people just don't get the joke and would also view it as a racist and anti-semitic film.

In my opinion, if it's desired to have FOSS driven by individual contributors, the legal education aspect for each contributor is just as important as the contributors knowing how to code. Sadly I think some projects are way behind on that.

You're really splitting hairs here, the "polite software" you're talking about also needs to "phone home" to check and offer the update, which probably leaks about as much information as you manually refreshing the project's web site every week.

I mean in terms of developer interest, I haven't seen anybody working towards getting those patches (or similar things) merged. It would be easiest to get this working in a rootless server (like XWayland) first and then go backwards from there. In the case of compositing on multiple monitors, scaling isn't independent of DPI settings. They are the same problem, because at some point you will get an app that is mismatched and you'll have to scale it along with its input coordinates.

The physical measurements could be used to inaccurately guess defaults, some Wayland servers might do that, but it's not preferred. The X server doesn't "misreport" DPI in the sense that it's purposefully sending a wrong value, there's a process that it does (I may not be remembering this exactly) where it tries to read from the EDID, which could be wrong values. If the values are there but wrong those will just get quietly passed through, if those are zero then it then tries to fill in measurements based on a default DPI. Random X clients with access to RandR can also change the measurements stored in the server for whatever reason -- basically there is no possible way for this value to always be correct if you just want a number that tells you what DPI to target.

You're right this could be fixed, just like every bug could technically be fixed if given enough attention, but somebody needs to take the time to backport the Wayland method to X, which I don't have high hopes for it happening any time soon. The main thing you're missing in the server, as I said, is scaling of input coordinates. The compositor or the toolkit can't do this, it has to happen in the server, because those events are sent directly from the server to the client. It's probably a better approach to get that working, and then put a prop on the root window, and then hack kwin/mutter/whatever to use that, but I don't think anyone has tried to implement it that way yet.

I completely disagree with your assessment, Audacity just crashed twice for me yesterday.

Also, with SQLite, it seems the major people reporting bugs are people who have paid support contracts with drh, which most likely requires sending identifying information.

I'm saddened that it's necessary to bother posting this, but Ardour also has a similar privacy policy, which you should read if you intend to use their services: https://ardour.org/privacy.html

Ardour also has a compile time optional "phone home" feature which checks for update announcements, so you should disable that when building if you care about this sort of thing: https://github.com/Ardour/ardour/blob/13f5fb3dee640f0bfb1d66...

Personal note: I do not consider these things to be issues with Ardour, or with Audacity. I commend PaulDavisThe1st and x42 and the rest of the Ardour contributors, as well as the Audacity developers, for their respective work on these two excellent projects.

I'm still not sure what you're saying, you're still downloading the source from an external website on the internet, which I would expect would have a privacy policy, and would do things like comply with the GDPR. And presumably, the ports collection is getting the original source from upstreams, which could be on github or a similar service, so you can't sidestep that if you want to maintain your own ports tree.

It absolutely does have to do with analytics: in particular, Debian has an opt-in anayltics system called "popcon" which is mentioned in the privacy policy.

Do you expect to be able to receive updates and security fixes to your installed programs? Or send back a patch or bug report? If so, then it absolutely is the norm, because all that needs to be done over the internet and can generate PII. It probably shouldn't be assumed that a distribution platform can avoid having a clear and straightforward privacy policy because it calls itself a "FOSS repo" and not an "app store." Or did I miss something? Do some people only exchange security updates and crash dumps off of physical media given in person?

I'm not sure what you're suggesting the difference is, or what specifically here is a "mobile cartel?" FOSS projects and other related things also have privacy policies, and in fact you probably want them to so that they're clear what they're doing with the data they've aggregated. Here's some examples:

https://docs.github.com/en/github/site-policy/github-privacy...

https://www.debian.org/legal/privacy.en.html

https://fedoraproject.org/wiki/Legal:PrivacyPolicy

https://www.fsf.org/about/free-software-foundation-privacy-p...

Controversial? This looks extremely similar to most other privacy policies. I would urge you to read the privacy policy on any other web sites that you visit, or for any other services that you use, and compare and contrast. A good starting point might be the privacy policy on your phone's app store.

I'm not sure why the word "fork" is being repeatedly mentioned or why people are thinking this is making the code unusable. At most, I would expect a patched distribution similar to VSCodium to pop up, i.e. not a hard fork. If there was willpower in the community to fork the project and fix all the other long standing issues, that would have happened already, so there is no reason to expect a fork here.

Those patches were never merged, and I doubt they will be, because there seems to be almost no interest in supporting high DPI displays on X without a compositor. If there was interest in those, at the very least somebody would have to adapt them and figure out how to use them with XWayland. In my opinion, any patch that doesn't fix this for Xwayland/Xwin/Xquartz is probably not going to fly. If you want this, you actually do need some level of protocol support for this, and I want to address a common misconception:

>X11 provides the necessary information via RandR to perform per-monitor scaling

This is not true. If it were true, it would be significantly easier to get DPI scaling to work on X11 and XWayland already. If you're referring to the physical size measurements, there are numerous problems with those, and they should never be used to do DPI scaling. If you're developing for Wayland, you should just ignore those measurements and use the scale provided by the server. If you mean that applications can draw themselves at arbitrary scales, they could always do that, without even bothering with RandR, but that will break down when you try to handle the compositing cases, e.g. stretching a window across monitors and expecting the display/input coordinates to scale correctly. So regardless of what you're trying to get the apps to do, some more work needs to be done there.

Even if those problems were fixed, DPI scaling would still not work without more changes in the server. The major reason why it can't even work is because of input coordinate scaling -- the server needs to be able to scale coordinates based on a factor provided by the client, and RandR does not provide this, and it doesn't make sense to add it to RandR either. If you want to standardize how this is done, the best way would just be to copy the method used by Wayland back into the X server. Part of it might be merging those patches by Keith that you linked, part of it might be somebody finishing this MR: https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests...

>Emacs does not. vim does not. OpenSSH does not. Python does not. ffmpeg does not.

And yet, Fedora [0], Ubuntu [1], and KDE [2] do. So what you're saying doesn't paint a full picture: even if upstream of those projects you mentioned doesn't take the automated bug reports, there is likely some downstream that is using them to aggregate crash data and turn those into bug reports. It is not feasible, on a large scale, to manually comb through crash dumps and ask people to figure out how to use gdb. Open source projects don't have any special sauce here.

Also, it seems very strange to complain about companies collecting data that they're required to collect by law. "Forking" there is a fool's errand, any other company legally doing business in the same areas will be following the same laws.

[0]: https://developer.fedoraproject.org/tools/abrt/about.html

[1]: https://wiki.ubuntu.com/Apport

[2]: https://community.kde.org/Telemetry_Use

According to the actual text of the GPL, that is not the spirit of it at all. Sorry to disappoint but this is a common misconception that I see. The word "community" appears zero times in the GPL. The community aspect might be a side effect that happens in some cases with it, but trying to use a license of some kind of panacea to maintain a community doesn't make any sense. That's not how communities work. It's the people who maintain your community, not the license.

Edit: The lack of enforcement of GPL is a different story, but you can trace that directly back to the very same community, including the FSF, who seem to have decided years ago that enforcing the GPL is not worth it anymore for some reason.

I agree with the rest of your comment but I just want to respond to this part:

>If you don't have thick skin, you should probably avoid upstream discussions

I have a humble request, please discontinue this attitude on your own projects and please encourage other upstreams to also discontinue it. I'm baffled as to why so many open source maintainers seem to confuse needing to defend technical decisions with "having a thick skin," they are not the same. It's perfectly possible to be opinionated and strongly scrutinize a technical decision, while also not being harsh and rude towards the person presenting it. If you believe those mailing lists are unsalvageably hostile, then in my opinion, they should just be shut down. That's not the kind of place to have official project communication.