Hacker News

Gnome does UX and UI very well, though.

It's just sad. Nobody wants to fork it because nobody uses GIMP, so forks get almost no traction. People love the effort and commitment, install it, try it for a couple of tasks, fail, and never come back. It has built up this reputation of being terrible, and no one wants to give it a second chance after their first impression.

I think it's a lesson in how not to run an open-source project. I put it in the same category as Darktable, which gives off that exact same bad first impression.

Yep, even music software like Ableton Live is using zipped XML for the project files (although the much bigger audio files are stored independently in sub-folders). There were even efforts to use the XML format to manage Ableton project files with git in order to have a nicer change history (https://github.com/clintburgos/ableton-git).

From https://github.com/zepouet/Xee-xCode-4.5/blob/master/XeePhot...:

    // At this point, I'd like to take a moment to speak to you about the Adobe PSD format.
    // PSD is not a good format. PSD is not even a bad format. Calling it such would be an
    // insult to other bad formats, such as PCX or JPEG. No, PSD is an abysmal format. Having
    // worked on this code for several weeks now, my hate for PSD has grown to a raging fire
    // that burns with the fierce passion of a million suns.
    // If there are two different ways of doing something, PSD will do both, in different
    // places. It will then make up three more ways no sane human would think of, and do those
    // too. PSD makes inconsistency an art form. Why, for instance, did it suddenly decide
    // that *these* particular chunks should be aligned to four bytes, and that this alignement
    // should *not* be included in the size? Other chunks in other places are either unaligned,
    // or aligned with the alignment included in the size. Here, though, it is not included.
    // Either one of these three behaviours would be fine. A sane format would pick one. PSD,
    // of course, uses all three, and more.
    // Trying to get data out of a PSD file is like trying to find something in the attic of
    // your eccentric old uncle who died in a freak freshwater shark attack on his 58th
    // birthday. That last detail may not be important for the purposes of the simile, but
    // at this point I am spending a lot of time imagining amusing fates for the people
    // responsible for this Rube Goldberg of a file format.
    // Earlier, I tried to get a hold of the latest specs for the PSD file format. To do this,
    // I had to apply to them for permission to apply to them to have them consider sending
    // me this sacred tome. This would have involved faxing them a copy of some document or
    // other, probably signed in blood. I can only imagine that they make this process so
    // difficult because they are intensely ashamed of having created this abomination. I
    // was naturally not gullible enough to go through with this procedure, but if I had done
    // so, I would have printed out every single page of the spec, and set them all on fire.
    // Were it within my power, I would gather every single copy of those specs, and launch
    // them on a spaceship directly into the sun.
    //
    // PSD is not my favourite file format.

important here to remember that Blender was created within the industry as a commercial tool. When open sourced the leader of the project remained and knew quite well what separated a good creative tool from a bad one. It was always situated in a position where the core users were either hobbyists or professionals.

Gimp was never in such a situation.

Culture is important.

Even the name is self sabotage.

So GIMP has a larger user base than Blender, what is your point ?

I can guarantee that anyone turning up and contributing or forking this project will not lead to the outcome of a improved piece of software.

It will lead to someone with the insight on how to make actual material improvements frustrated and angry that they don't have the technical skill (or time) to grapple with a complex codebase, and the people with the technical skill working on the codebase dismiss people with actual knowledge in different domains.

"Patches welcome" is not any kind of welcome. It's basically a euphemism for "fuck off, I don't want to have a conversation to make something better, I just want to hack on Feature X".

No that would be an early 1990s file format ;)

1999 is exactly right for the start of the XML hype, everything had to be XML, it would single handedly solve the software crisis (after OOP failed to do that) because everything would be able to talk to everything!

SQLar[1], see [2] for some reasoning around why a database is preferred over zipped XML. Though, I'd be fine with a DBM-style database too as we only need the key-value part of it.

[1] https://sqlite.org/sqlar/doc/trunk/README.md

[2] https://www.sqlite.org/affcase1.html

Compressed JSON with the binary content encoded in base64 strings, obviously.

Fundamentally, it's not.

The problem was that people hyped it up as the solution for every problem and all the world's ills, so it wound up being used where it had no business being used (and therefore badly).

XML was a hammer used to bang in a lot of things that weren't remotely nail-shaped, and accordingly, a certain percentage of traumatised people despise it and react to any mention of it with fear and loathing.

It's kind of neat when you have an application for it that really leans into its strengths.

Thanks! I had the exact same question for various of these posts here. I know these may be different groups of people, but I always see people advocating for simplicity, and zipped-XML is as simple as it gets, needs barely any extra dependencies (none in GIMP I assume), and is proven to work well (Word etc).

I also don’t understand why SQLite would be preferable here, considering you will likely also store large binary files alongside your document definition.. What does a db engine give me here?

The obvious alternative is SQLite, and it has many advantages. If you want to do a "zipped list of files", SQLite does that just fine (that's what SQLar is), but it can do so much richer data. Even if you don't want that, it still offers resiliency that "zipped XML" can't match: if your software or computer crashes in the middle of saving your file, it'll almost certainly corrupt it. With SQLite, not an issue: all transactions are atomic, they either happen entirely or not at all.

I don't know what "mature tooling" you're talking about for zipped XML, but I guarantee you it's not going to be better (or more mature) than SQLite and its ecosystem.

> With “a” vs “an”, the pronunciation is more important than the spelling.

I know, hence my question about the pronunciation. If I had thought the spelling was more important, the “X” would have settled it so I wouldn’t have asked.

You say "a exit"?

https://itsfoss.com/news/glimpse-gimp-fork-archived/ Yep, it's dead.

I'm surprised it got that epithet, I'm used to "upset by weird sex stuff" as being a US-right position, and "woke" being a term that's used by US-right to denigrate US-left.

Then again, I'm also old enough to have seen it shift significantly in meaning at least once, and I think I'm seeing it shift meaning again.

json's only advantage is it's easier to write by hand, but that's not really a consideration here. XML has schema support and much more tooling available.

> As I understand there is lot more tooling, standards & existing software examples around JSON for project & records management

I don't understand why that is relevant; as long as there is a minimum level of tooling, libraries and support for their choice, what benefit would JSON bring over XML? I don't see a clear reason for one over the other.

Honestly, I'd have the same question if they chose JSON and someone asked why did they choose JSON over XML - Why wouldn't they?

JSON made me not hate XML. YAML made me not hate JSON.

“Great”.

No offence to anyone, but I would not consider the performance of MS office to be great.

I guess it's comparative, but then I compare to its previous editions which used a sliver of the resources to accomplish 95% of what modern o365 does.