You know what? The hate GIMP gets in the comments is entirely self-inflicted. Everyone praises Krita and Blender because their UIs are consistent and look good. GIMP, on the other hand, looks like a toddler worked on it: switches are huge compared to text, buttons and text have no padding and are squeezed together, and icons are oversized and scattered everywhere.
People might say, "You can just join the project and fix it yourself." But the team and community actively resist change and sabotage efforts to make GIMP more mainstream.
dvh 6 minutes ago [-]
I just installed Ubuntu 26.04 and it's gimp starts for 14 seconds.
mimasama 2 hours ago [-]
Zipped XML? Isn't that just OpenRaster? (which is already supported by GIMP anyway, but also supported by Krita and other image editors)
Gualdrapo 14 minutes ago [-]
> Krita and other image editors)
Krita is not an image editor but a digital painting program. GIMP is a much more complete image editor despite its quirks.
Ygg2 2 hours ago [-]
It's not that weird. Most of Office and Open office formats are just zipped folders of XMLs.
Better Zipped XML than whatever monstrosity Adobe files are. PDF/PSD... shudder.
herrherrmann 1 hours ago [-]
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).
berkes 22 minutes ago [-]
> with git
I suddenly imagine a zip format with built-in git. Does this already exist?
Basically a file-format that has built-in history, rollback, logs etc. Enabling all these "zipped XML" formats to get this feature "for free".
Could be as simple as adding the .git to the zip and ensuring the software that writes the content to the zip also runs the correct git operations.
But could also be a simplified subset and adding git-ability to the (de)compress libs and bins, which can operate on the compressed .git. Simplified, because it won't need networking/remotes probably not even branches.
rzzzt 17 minutes ago [-]
Involuntary reflex reply: ship an SQLite database as your data file?
I mean, zipping files in an archive and presenting them as a file is an ancient tradition in video games. For example Warcraft 3 used the MoPaQ archive to store data in .w3x file.
And Starcraft 2 data is just bunch of XML files.
TeMPOraL 25 minutes ago [-]
Except MoPaQ weren't zips IIRC, they had their own clever format here - at least the OG StarCraft / SCBW MoPaQs were, playing with that is what I learned binary data handling on :). The idea of zipping data files applies, of course (and many a game used a literal ZIP with custom extension).
But there's one material difference between StarCraft/Warcraft and Gimp: in Blizzard games, those were "zips" of heavy data files, notably read only data blobs. The game would read them, unpack in memory, and serve appropriately. Most of that data was key-value, text resources, or flat assets - images, sfx. With Gimp, we're talking highly structured data that's continuously being mutated. Very much not the best representation for that, even if you're just persisting it. They're only getting away with this because of SSDs - on spinning rust, you'd feel this.
(Also worth noting that, at least in StarCraft/SCBW, most of the files inside were custom, well-optimized binary formats. This predated the XML insanity of encoding data with 90%+ markup overhead.)
herrherrmann 1 hours ago [-]
Cool, I didn’t know that! But makes a lot of sense.
bulgur999 1 hours ago [-]
As usual, whenever GIMP is involved, all we get are negative, often unfounded comments about an excellent piece of free software that is massively used and developed with very limited resources, doing its job really well.
There’s something so pleasant about having GIMP around, efficient and so far removed from the disgusting greed that drives so many of the projects featured here.
unpopularopp 1 hours ago [-]
I’m going to take the bait:
I know a lot of people don't like that but sometimes I feel that FOSS projects are intentionally sabotaging themselves by ignoring industry standard options/conventions and instead they are following open source ideas just to be different. GIMP is the perfect example of that and generally speaking UI/UX is the main symptom.
Blender was able to move forward by not listening to the FOSS crowd but to the industry. And see where are they now compared to GIMP.
ChrisGreenHeur 55 minutes ago [-]
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.
berkes 14 minutes ago [-]
> Culture is important
Which brings us back to why so many people dislike Gimp, and/or see it as a posterchild example of bad FOSS alternatives.
I agree, and Culture IS important. And I think the culture around many Open Source "Alternatives" is harming themselves and the overall FOSS community. From Mastodon via Gimp to Nextcloud.
graemep 13 minutes ago [-]
Even the name is self sabotage.
bulgur999 46 minutes ago [-]
So GIMP has a larger user base than Blender, what is your point ?
Gualdrapo 9 minutes ago [-]
I don't know what it has to do with anything - GIMP has been around for a while and has been the de facto FOSS alternative for photoshop for so long. That doesn't make that several of its UX and UI decisions are at least questionable nor make that comment you're replying any less true.
Not to mention the fact that if you ever mention in any way that GIMP's UX/UI could be better to anyone of its veteran devs they would turn weirdly ultra defensive and take everything personal.
graemep 12 minutes ago [-]
Blender is something routinely recommend by normies. Gimp is not.
Blender is a very popular, maybe the most popular, for the tasks its used for. Gimp is not.
rplnt 12 minutes ago [-]
Market share might be more relevant when we're comparing products with different market sizes.
lukan 1 hours ago [-]
Do you have your special dark mode glasses on?
Because I fail to see all the comments here as negative and unfounded.
(and my guess why there is often negativity towards GIMP, is because it was too often advertised as a adequate Photoshop replacement, which it is not, so people got disappointed with it)
igleria 26 minutes ago [-]
I love that GIMP exists but... I have to say, it never got rid of the "backend developer doing frontend" feeling, and I've been aware of Gimp for 20 years now (did not know how to...ehem, run photoshop in my teens)
herrherrmann 1 hours ago [-]
… and the sizes of their updates are usually impressive! Seems to be a big project that is managed well to keep a good pace and keep the community in the loop. (Although I don’t know much about their inner workings.)
rimliu 1 hours ago [-]
Yes, it is very pleasant to have it around. Especially when you switch to something else.
dm319 49 minutes ago [-]
It's a great piece of software. Best feature - not having your colours retrospectively removed from your project [1].
Furthermore, it's free software. If people have a problem with it, they're free to show up and contribute, or fork if the community is really opposed to their ideas (they probably are for good reason, though).
dm319 2 hours ago [-]
Non-destructive filter layers caught my eye, and has been something I've missed since moving off Windows/Photoshop to Linux. Looking around it seems like they introduced this in V3, which is great to see.
Balinares 2 hours ago [-]
Haven't those existed in Krita forever?
maya335 2 hours ago [-]
That is probably the V3 feature I'd notice most in daily use. Non-destructive editing makes experimentation much less costly; without it, every “maybe this looks better” becomes another layer or file copy.
socalgal2 3 hours ago [-]
Zipped XML. Welcome to 1999 designs
ACCount37 2 hours ago [-]
Let's be honest, the real 1999 design would have been a custom binary format that happens to use the endian of the system it was developed on, and leaks bits and pieces of unflushed memory buffers whenever it writes to disk.
flohofwoe 2 hours ago [-]
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!
anygivnthursday 47 minutes ago [-]
Indeed, early 00s was still the SOAP XML era if I remember right, WSD, SOA, ...
reddalo 8 minutes ago [-]
SOAP XML is so uselessly convoluted.
The whole Italian e-invoicing system is based on SOAP XML, and it's atrocious. They approved the specs in 2013, so it was already dated when it came out.
stuaxo 34 minutes ago [-]
Jar
muhehe 2 hours ago [-]
What would you consider good modern design?
supriyo-biswas 2 hours ago [-]
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.
the SQLite archive format (it's probably worth linking to the main documentation[1], instead of the very old experimental repository) may not really be a good fit for something like GIMP's native file format. (To be clear, "SQLite archives" are not special compared to any other database: it's just a well-defined schema for an sqlar table, which the sqlite3 command line tool is able to create, update, and extract using syntax like the tar command.)
That being said, SQLite would still be a good choice, especially as it's a format that's really intended to be modified in-place, and has good data integrity features (eg: keep WAL enabled so that mid-save crashes/shutdowns don't corrupt your file), neither of which are provided by Zip. You could even just run zlib on data (be it XML or what have you) if optimizing the on-disk size of the file is desirable.
Not really a great option for an image format, where we therefore can't have multiple implementations. Unless I misremembered.
flohofwoe 2 hours ago [-]
The problem with using database blobs for load/save is that you usually need a full database client in the application. SQlite advertises that use case, but it is complete overkill. You never need to run any sort of complex SQL query on an image file format for instance. Using XML+ZIP in this day and age is also a strange decision, but at least that way the data is inspectable with unzip, a text editor and an image viewer (assuming they use a standard image format to store the raw pixel data).
batmansmk 59 minutes ago [-]
Think of Lightroom or automation over files. Many semi professionals from wedding photographers to designers want some form of batch automation and organization system over their files.
Several megabytes/gigabytes assets and you want to extract metadata, a preview, running as a batch some filter/compression/, conversion to CMYK, text injection ... fast partial read/write access would be nice.
Right now, most reads are performed through indexes because those files are slow to read.
If we take 10k sqlite files and want to retrieve a row, we would be around 3s on SSD, maintaining preemptive indexes become less important for a lot of use cases.
Change management and versioning also becomes quite efficient - sqlite can be configured to not offset bytes, so CVS like Epic Lore can efficiently delta the files and store minimal delta, or the file format itself can keep its edit history. Oh and it's 3x-10x less bytes without compressing the whole thing, so pages are stable through time.
About needing SQLite client, it's real but it's roughly the same size as an XML parser.
TeMPOraL 2 hours ago [-]
> You never need to run any sort of complex SQL query on an image file format for instance.
Sure you will. Plenty of features that don't exist, or are implemented badly, because you can't easily do it.
Quick mental translation table: if you think "iterate over every ..." or a `for` loop, that's your SELECT query. If you think about `if` conditions, that's the parts that go after FROM clause.
x3ro 2 hours ago [-]
In order to have any advantage from this, you would have the added complexity of splitting your file format into tables that can be queried in a useful manner. However, for an image file format, you most likely need to hold the entire definition in memory at all times anyway. Assuming that’s the case, doesn’t XPath get you there most of the way (assuming XML), with _way_ less complexity?
TeMPOraL 21 minutes ago [-]
Image data is just binary blobs. You aren't splitting that into channel columns or anything. But an image file for an editor like Gimp isn't one image blob. It's dozens or hundreds of them - one or more per layer - along with tons of associated metadata at every level.
All that tends to fit sensible schemas and managing it is what SQLite shines at.
zelphirkalt 1 hours ago [-]
SQLite is fast, but it won't be faster than a hot loop in C. Having the loop construct dictated by the file format seems bad. For images it seems more reasonable to have them in-memory, except for huge image edge cases.
TeMPOraL 33 minutes ago [-]
Images are the red herring. Pixel data is best read in hot loops in C, but that would be stored as blobs in SQLite anyway.
It's all the metadata around the image that's interesting. Images have layers, dozens or hundreds of them (this literally scales with how good your software is at handling those - the faster, and more powerful layer UX is, the more they get used). Some are pixel layers, other are effect layers, text layers, vector layers. Layers have metadata - names, sizes, colors, tags, types, special effects, and a bunch of other stuff I don't know because I don't use that 80% of features of GIMP/Photoshop/Affinity.
Then you have document level metadata, UI-specific metadata, etc. Also undo history. A lot of that is relevant to the work on images themselves, and changes in realtime, and can get even more useful if querying it wasn't such a PITA.
That - not the binary pixel blobs - is the selling case of using SQLite as application data format.
speedgoose 2 hours ago [-]
Compressed JSON with the binary content encoded in base64 strings, obviously.
berkes 9 minutes ago [-]
So you compress a format that inflates binaries with 30%?
That not only ends up larger than "just the binary", it also eats a lot of extra CPU to (de)compress AND encode-decode.
This idea is novel, but wasteful.
(edit: I thought you were serious, so I answered serious. You were not ;)
einpoklum 1 hours ago [-]
Why would zipped JSON be fundamentally superior to zipped XML?
speedgoose 1 hours ago [-]
To answer seriously, my parent comment is a joke, JSON is a simpler format that maps better to most programming languages internal memory representations. Developers tend to prefer JSON’s simplicity over XML.
berkes 1 minutes ago [-]
> most programming languages internal memory representations
Often heard wrt JSON but incorrect. It maps to the primitive types in JavaScript. But almost all programming languages treat floats and integers different, make distinction between char and strings and many have some form of date/time. JSON has neither.
In that direction, XML is much closer since every node is a triple (name, value, attributes) so can have type info, json is a tuple. And Protobuf, while not popular, gets this completely right.
elric 2 hours ago [-]
Welcome to 2026 unfounded hot takes.
Or less snarky: what's your gripe with zipped XML? It compresses reasonably well, has a useful structure, and has decades of mature tooling around it.
OskarS 1 hours ago [-]
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.
x3ro 2 hours ago [-]
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?
spider-mario 2 hours ago [-]
> For instance, we’re quite proud that a XCF file made by a small company for their logo in 1998 still renders the same way in the latest version of GIMP
How do they pronounce “XCF” such that it’s “a XCF file” and not “an XCF file”? “Xeceff”?
TeMPOraL 31 minutes ago [-]
A "ksceef"?
But yeah, in my mind, it's always been "ex see eff", so an XCF.
ajcp 2 hours ago [-]
I find some word processors don't test for vowel sound, and only adhere to the actual vowel letter.
left-struck 2 hours ago [-]
In my mind it’s similar to exif
Choco31415 2 hours ago [-]
The beginning of “XCF” sounds similar to the beginning of “Exit”.
With “a” vs “an”, the pronunciation is more important than the spelling.
spider-mario 2 hours ago [-]
> 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.
SwellJoe 2 hours ago [-]
You say "a exit"?
mattkevan 1 hours ago [-]
[flagged]
Jach 50 minutes ago [-]
Also curious what you dislike so much. And how does Photoshop compare? https://i.ytimg.com/vi/_ghez_hKxeo/hq720.jpg I like the way Gimp has looked more and disliked many of their experiments changing things. The screenshot you linked isn't even the default look anymore, they've got a dreadful dark mode if you like that sort of thing. The first thing I do on a new install is restore the light mode and color icons it has, and make all the tool icons visible at once.
dash2 33 minutes ago [-]
Your argument in favour of Gimp is that its default UI is dreadful? (I agree, but it's the fault of the Gimp UI, not of dark modes in general.)
Jach 25 minutes ago [-]
I don't like its default look, but the screenshot they linked was non-default and what I do like, so I'm wondering why they find it sloppy/bad. Perhaps they would like Gimp's default more? Here's a representative shot from 2020: https://www.lifewire.com/thmb/H9QCFUVFrU035srbCoZ5erwS20Q=/1... Not even the +/- buttons another comment complains about are in this one.
enquirewithin 51 minutes ago [-]
What do you want it to do?
I’ve used it, it works.
The handful of other things I’ve used that do the same thing or something similar are roughly the same.
All attempts at making the UI look better invariably obfuscated tools.
actionfromafar 1 hours ago [-]
Could you be very specific about what's sloppy? It would be very interesting to hear. I think I'm too numb from years of exposure.
dsego 49 minutes ago [-]
Just look at the spacing and button layout, nothing is aligned, buttons are touching, the plus button is wider than the minus button, sizing is all over the place.
voidUpdate 38 minutes ago [-]
> "Nothing is aligned"
The first two items in each row are aligned, and each item is aligned to one of two columns
> "Buttons are touching"
The only buttons that are touching are the + and - buttons which are part of the number input, as they are one connected part, and the units dropdown which is also part of the number selection in one item
arewethereyeta 51 minutes ago [-]
looks like the type of designs backend engineers do. Just throw everything in there
TiredOfLife 2 hours ago [-]
I thought every developer of this moved to the Glimpse fork
dspillett 2 hours ago [-]
That effort didn't last long. I think this is the first I've heard about it since inception, the repo (assuming this is the right one, https://github.com/joshgiesbrecht/Glimpse, it was the only GIMP related thing that came up amongst a sea of unrelated projects with the same name) is hasn't seen a commit in 7 years and what appears to be the official site away from a forge (https://getglimpse.app/about/) is currently unresponsive.
herbst 2 hours ago [-]
Pretty sure woke gimp was long discontinued
ben_w 2 hours ago [-]
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.
SwellJoe 2 hours ago [-]
Before the weird sex stuff, "gimp" was an insulting term for a crippled person. The fact that it's so long out of common use for that purpose that a lot of folks don't realize that is perhaps an argument for not taking it too seriously. On the other hand, disabled folks are certainly among the most oppressed and abused and in ways that aren't well-understood by most folks, so a decent person should be pretty careful about using language that could be demeaning. I dunno. It feels like an archaic term that ought not have any power today, but what do I know?
ChocolateGod 2 hours ago [-]
> Before the weird sex stuff, "gimp" was an insulting term for a crippled person. The fact that it's so long out of common use for that purpose that a lot of folks don't realize that is perhaps an argument for not taking it too seriously
It's a US specific slur when used in this context, not in other English speaking countries (let alone non-English countries) A lot of GIMP developers are European yet the Glimpse project tried to force American cultural/linguistic rules on a non-American project.
Words mean different things in different regions and languages, just because it's offensive in your language does not mean it's offensive in others.
amon_spek 9 minutes ago [-]
It's a decorative strip of fabric used to trim upholstery and hide tacks to me.
SwellJoe 1 hours ago [-]
They didn't try to force anybody to do anything. They forked a Free Software project as allowed by the license. You seem awfully sensitive.
ChocolateGod 22 minutes ago [-]
I remember the (now deleted) Gitlab issue on the GIMP project that called on for the name to change, it certainly wasn't friendly.
SwellJoe 2 minutes ago [-]
What do you believe the word "force" means?
TeriyakiBomb 2 hours ago [-]
In the UK, it’s the sex one and would be used as a general “idiot” word but that seemed to have mostly faded away. It’s not a word I’ve seen used in that context for many years.
Not refuting anything here, just adding some context from over here. Whichever way you slice it, it’s always been an awful name.
SwellJoe 2 hours ago [-]
Yeah, it's always felt like an "edgy" name a teenager or quite young man would come up with. Which makes sense, the original GIMP authors were college-aged boys when they created it.
I'd like it if they changed the name. We're (the Open Source community) not teenagers or annoying college kids anymore, by and large.
maybewhenthesun 59 minutes ago [-]
I like it that the scruffy teenager hacker mentality is preserved in the name. It was also a bit of self deprecating humour at the time, because using Gimp instead of Photoshop did make you feel crippled a bit.
I hope they never give in to the corporate-lawyer induced bland-washing .
SwellJoe 3 minutes ago [-]
I'm not a corporate lawyer.
I'm just a Free Software user and developer and I think it's nicer when I can recommend something to someone without having to think about whether I might be saying something rude or hurtful. I assume there was a stink about the name because it bothers some disabled folks. It's not my place to tell them not to be bothered, I'd rather just not do the shitty thing that bothers them.
It seems cringey and childish to insist on doing a thing that makes a bunch of people feel unwelcome based on something about themselves they can't change. And, for what? So you can feel like a scruffy teenaged hacker?
I like my Free Software community to welcome people of all sorts.
____mr____ 1 hours ago [-]
The issue is that there are a bunch of people like this[0] who get incredibly upset and politicize any attempts to be "the adult in the room" and ask for renaming of unsavory names.
The funniest of these is when Europeans talk about how they are being "forced" to comply with American cultural norms and you go through their account and they are so deeply steeped in American culture due to their participation in the anglophone internet spaces which are dominated by them. People in Europe will argue with you that you are importing woke culture if you suggest that they shouldn't say the N word, but are seemingly completely oblivious to the fact that the reason they find the word exciting to say and they say it in English is an import of American culture
I don't want to revel in the fork's demise for any reason besides relief that it didn't end up splitting GIMP's contributors and community in a way that would have harmed both projects.
> we could not find contributors willing to step up and help with non-code tasks like moderating communication channels
Gotta say though it feels ironic that they couldn't find enough people to be comment janitors considering the whole thing was based on wanting people to stop saying a particular word.
> As a result, we struggled to scale the project to match increasing demand.
‘Glimpse didn't fail; it was actually too popular’?
ChocolateGod 2 hours ago [-]
That's the thing, they didn't take any GIMP contributors.
Everyone that was behind Glimpse was third party to the GIMP project.
pndy 1 hours ago [-]
This wasn't even a serious project but an example of malicious virtue signaling with a long-term plan for sort of hostile takeover. People involved just took the original code and replaced every GIMP occurrence with Glimpse, added new logo/icon and called job done. Then went to the news sites trying to raise awareness of the supposed name controversy hoping noise will discredit GIMP while they'll portrait themselves as the saviors. Because who'd want to contribute to a software that has such bad reputation.
It's been over 24 years for me since I've used GIMP for the first time and the only problem that I had was always with GUI ergonomics. You had to understand everything anew after being more accustomed to proprietary software pieces. My friend never adapted to anything else but Photoshop - even Krita is beyond her abilities.
Nearly every discussion regarding GIMP on hn will include thread about the name 'problem' and this is getting tiresome. The name won't change and those who feel offended should focus on problems whose solution is genuinely productive.
ChocolateGod 18 minutes ago [-]
> This wasn't even a serious project but an example of malicious virtue signaling with a long-term plan for sort of hostile takeover. People involved just took the original code and replaced every GIMP occurrence with Glimpse
I recall one of the reasons given on the GIMP Gitlab issue to change the name was "it will encourage more contributors" that apparently don't contribute because of the project name. Glimpse certainly had a lot of contributors... not.
I can't think of a single project that changed a name to satisfy these people ever received more contributors as a result.
Lammy 58 minutes ago [-]
I feel like it would have though if Glimpse had managed to become the default image editor on at least one major distro, just by virtue of people stumbling in to contributing some fix or addition to ‘the thing that came with my OS’ without necessarily being aware of the history.
Like the FFmpeg/libav fork that eventually got back together. Or Compiz/Beryl, or Emacs/XEmacs, or GCC/EGCS, or whatever :)
roschdal 2 hours ago [-]
Zipped XML sounds like a bad idea. It's slow and bad. I say XCF forever.
EvanAnderson 2 hours ago [-]
SQLite would have been a lot better choice, in my opinion.
srvmshr 2 hours ago [-]
Pardon my ignorance about formats, but between XML & JSON, what would have made them choose XML? As I understand there is lot more tooling, standards & existing software examples around JSON for project & records management (e.g. VSCode's records as settings.json for example). Wasn't XML spearheaded by Microsoft but mostly used by Microsoft today?
cozzyd 2 hours ago [-]
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.
lelanthran 1 hours ago [-]
> 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?
actionfromafar 60 minutes ago [-]
JSON made me not hate XML. YAML made me not hate JSON.
Arainach 2 hours ago [-]
> It's slow and bad.
Seems to have been working great for MS Office.
dijit 2 hours ago [-]
“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.
graemep 8 minutes ago [-]
Its very widely used. Perfomrance might not be great, but adoption is.
mdp2021 1 hours ago [-]
> previous editions... used a sliver of the resources
Well of course, but given that the previously employed technique was blitting, fliedumping memory areas, you can't be more efficient than that. Using XML is for transparency (readability).
(And, note, in context, I regard the ms office file format as lousy. The OpenOffice/LibreOffice format is good.)
thaumasiotes 58 minutes ago [-]
I don't think your parent comment was talking about the resources involved in saving a file, but rather the resources involved in running the software.
mdp2021 55 minutes ago [-]
Thank you, probably so, but in that case I cannot see how said comment is consistent in the branch ("about file formats") - I do not get how it would follow.
Ygg2 2 hours ago [-]
Office documents since the 2007 have used a zipped XML approach. Just take an .docx and open it in 7zip.
EDIT: Narrowed the date.
dijit 9 minutes ago [-]
I’m aware. IIRC this was a response to Microsoft being forced to use some “open” protocol or something.
AltruisticGapHN 27 minutes ago [-]
Gimp is shite. The dialogs commit so many UX crimes devs should go to a mental asylum. Text editing in gimp is god awful.
Photopea.com + MPA Photopea AdBlock extension + "Install page as app" in Chrome and now you have a shortcut to a fullscreen / no ads clone of Photoshop that is 100 times more user friendly and not designed by absolute retarded morons.
Rendered at 09:52:07 GMT+0000 (Coordinated Universal Time) with Vercel.
People might say, "You can just join the project and fix it yourself." But the team and community actively resist change and sabotage efforts to make GIMP more mainstream.
Krita is not an image editor but a digital painting program. GIMP is a much more complete image editor despite its quirks.
Better Zipped XML than whatever monstrosity Adobe files are. PDF/PSD... shudder.
I suddenly imagine a zip format with built-in git. Does this already exist?
Basically a file-format that has built-in history, rollback, logs etc. Enabling all these "zipped XML" formats to get this feature "for free".
Could be as simple as adding the .git to the zip and ensuring the software that writes the content to the zip also runs the correct git operations.
But could also be a simplified subset and adding git-ability to the (de)compress libs and bins, which can operate on the compressed .git. Simplified, because it won't need networking/remotes probably not even branches.
Quick edit: hmm, I'm already ~1 hour late, the relevant thread starts at https://news.ycombinator.com/item?id=49327457
And Starcraft 2 data is just bunch of XML files.
But there's one material difference between StarCraft/Warcraft and Gimp: in Blizzard games, those were "zips" of heavy data files, notably read only data blobs. The game would read them, unpack in memory, and serve appropriately. Most of that data was key-value, text resources, or flat assets - images, sfx. With Gimp, we're talking highly structured data that's continuously being mutated. Very much not the best representation for that, even if you're just persisting it. They're only getting away with this because of SSDs - on spinning rust, you'd feel this.
(Also worth noting that, at least in StarCraft/SCBW, most of the files inside were custom, well-optimized binary formats. This predated the XML insanity of encoding data with 90%+ markup overhead.)
There’s something so pleasant about having GIMP around, efficient and so far removed from the disgusting greed that drives so many of the projects featured here.
I know a lot of people don't like that but sometimes I feel that FOSS projects are intentionally sabotaging themselves by ignoring industry standard options/conventions and instead they are following open source ideas just to be different. GIMP is the perfect example of that and generally speaking UI/UX is the main symptom.
Blender was able to move forward by not listening to the FOSS crowd but to the industry. And see where are they now compared to GIMP.
Gimp was never in such a situation.
Culture is important.
Which brings us back to why so many people dislike Gimp, and/or see it as a posterchild example of bad FOSS alternatives.
I agree, and Culture IS important. And I think the culture around many Open Source "Alternatives" is harming themselves and the overall FOSS community. From Mastodon via Gimp to Nextcloud.
Not to mention the fact that if you ever mention in any way that GIMP's UX/UI could be better to anyone of its veteran devs they would turn weirdly ultra defensive and take everything personal.
Blender is a very popular, maybe the most popular, for the tasks its used for. Gimp is not.
Because I fail to see all the comments here as negative and unfounded. (and my guess why there is often negativity towards GIMP, is because it was too often advertised as a adequate Photoshop replacement, which it is not, so people got disappointed with it)
[1] https://www.reddit.com/r/graphic_design/comments/rdtodb/adob...
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!
The whole Italian e-invoicing system is based on SOAP XML, and it's atrocious. They approved the specs in 2013, so it was already dated when it came out.
[1] https://sqlite.org/sqlar/doc/trunk/README.md
[2] https://www.sqlite.org/affcase1.html
That being said, SQLite would still be a good choice, especially as it's a format that's really intended to be modified in-place, and has good data integrity features (eg: keep WAL enabled so that mid-save crashes/shutdowns don't corrupt your file), neither of which are provided by Zip. You could even just run zlib on data (be it XML or what have you) if optimizing the on-disk size of the file is desirable.
[1] https://sqlite.org/cli.html#sqlite_archive_support
Not really a great option for an image format, where we therefore can't have multiple implementations. Unless I misremembered.
Several megabytes/gigabytes assets and you want to extract metadata, a preview, running as a batch some filter/compression/, conversion to CMYK, text injection ... fast partial read/write access would be nice. Right now, most reads are performed through indexes because those files are slow to read.
If we take 10k sqlite files and want to retrieve a row, we would be around 3s on SSD, maintaining preemptive indexes become less important for a lot of use cases.
Change management and versioning also becomes quite efficient - sqlite can be configured to not offset bytes, so CVS like Epic Lore can efficiently delta the files and store minimal delta, or the file format itself can keep its edit history. Oh and it's 3x-10x less bytes without compressing the whole thing, so pages are stable through time.
About needing SQLite client, it's real but it's roughly the same size as an XML parser.
Sure you will. Plenty of features that don't exist, or are implemented badly, because you can't easily do it.
Quick mental translation table: if you think "iterate over every ..." or a `for` loop, that's your SELECT query. If you think about `if` conditions, that's the parts that go after FROM clause.
All that tends to fit sensible schemas and managing it is what SQLite shines at.
It's all the metadata around the image that's interesting. Images have layers, dozens or hundreds of them (this literally scales with how good your software is at handling those - the faster, and more powerful layer UX is, the more they get used). Some are pixel layers, other are effect layers, text layers, vector layers. Layers have metadata - names, sizes, colors, tags, types, special effects, and a bunch of other stuff I don't know because I don't use that 80% of features of GIMP/Photoshop/Affinity.
Then you have document level metadata, UI-specific metadata, etc. Also undo history. A lot of that is relevant to the work on images themselves, and changes in realtime, and can get even more useful if querying it wasn't such a PITA.
That - not the binary pixel blobs - is the selling case of using SQLite as application data format.
That not only ends up larger than "just the binary", it also eats a lot of extra CPU to (de)compress AND encode-decode.
This idea is novel, but wasteful.
(edit: I thought you were serious, so I answered serious. You were not ;)
Often heard wrt JSON but incorrect. It maps to the primitive types in JavaScript. But almost all programming languages treat floats and integers different, make distinction between char and strings and many have some form of date/time. JSON has neither.
In that direction, XML is much closer since every node is a triple (name, value, attributes) so can have type info, json is a tuple. And Protobuf, while not popular, gets this completely right.
Or less snarky: what's your gripe with zipped XML? It compresses reasonably well, has a useful structure, and has decades of mature tooling around it.
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.
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?
How do they pronounce “XCF” such that it’s “a XCF file” and not “an XCF file”? “Xeceff”?
But yeah, in my mind, it's always been "ex see eff", so an XCF.
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.
I’ve used it, it works.
The handful of other things I’ve used that do the same thing or something similar are roughly the same.
All attempts at making the UI look better invariably obfuscated tools.
The first two items in each row are aligned, and each item is aligned to one of two columns
> "Buttons are touching"
The only buttons that are touching are the + and - buttons which are part of the number input, as they are one connected part, and the units dropdown which is also part of the number selection in one item
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.
It's a US specific slur when used in this context, not in other English speaking countries (let alone non-English countries) A lot of GIMP developers are European yet the Glimpse project tried to force American cultural/linguistic rules on a non-American project.
Words mean different things in different regions and languages, just because it's offensive in your language does not mean it's offensive in others.
Not refuting anything here, just adding some context from over here. Whichever way you slice it, it’s always been an awful name.
I'd like it if they changed the name. We're (the Open Source community) not teenagers or annoying college kids anymore, by and large.
I hope they never give in to the corporate-lawyer induced bland-washing .
I'm just a Free Software user and developer and I think it's nicer when I can recommend something to someone without having to think about whether I might be saying something rude or hurtful. I assume there was a stink about the name because it bothers some disabled folks. It's not my place to tell them not to be bothered, I'd rather just not do the shitty thing that bothers them.
It seems cringey and childish to insist on doing a thing that makes a bunch of people feel unwelcome based on something about themselves they can't change. And, for what? So you can feel like a scruffy teenaged hacker?
I like my Free Software community to welcome people of all sorts.
The funniest of these is when Europeans talk about how they are being "forced" to comply with American cultural norms and you go through their account and they are so deeply steeped in American culture due to their participation in the anglophone internet spaces which are dominated by them. People in Europe will argue with you that you are importing woke culture if you suggest that they shouldn't say the N word, but are seemingly completely oblivious to the fact that the reason they find the word exciting to say and they say it in English is an import of American culture
[0]. https://news.ycombinator.com/item?id=49327771
> we could not find contributors willing to step up and help with non-code tasks like moderating communication channels
Gotta say though it feels ironic that they couldn't find enough people to be comment janitors considering the whole thing was based on wanting people to stop saying a particular word.
> As a result, we struggled to scale the project to match increasing demand.
‘Glimpse didn't fail; it was actually too popular’?
Everyone that was behind Glimpse was third party to the GIMP project.
It's been over 24 years for me since I've used GIMP for the first time and the only problem that I had was always with GUI ergonomics. You had to understand everything anew after being more accustomed to proprietary software pieces. My friend never adapted to anything else but Photoshop - even Krita is beyond her abilities.
Nearly every discussion regarding GIMP on hn will include thread about the name 'problem' and this is getting tiresome. The name won't change and those who feel offended should focus on problems whose solution is genuinely productive.
I recall one of the reasons given on the GIMP Gitlab issue to change the name was "it will encourage more contributors" that apparently don't contribute because of the project name. Glimpse certainly had a lot of contributors... not.
I can't think of a single project that changed a name to satisfy these people ever received more contributors as a result.
Like the FFmpeg/libav fork that eventually got back together. Or Compiz/Beryl, or Emacs/XEmacs, or GCC/EGCS, or whatever :)
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?
Seems to have been working great for MS Office.
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.
Well of course, but given that the previously employed technique was blitting, fliedumping memory areas, you can't be more efficient than that. Using XML is for transparency (readability).
(And, note, in context, I regard the ms office file format as lousy. The OpenOffice/LibreOffice format is good.)
EDIT: Narrowed the date.
Photopea.com + MPA Photopea AdBlock extension + "Install page as app" in Chrome and now you have a shortcut to a fullscreen / no ads clone of Photoshop that is 100 times more user friendly and not designed by absolute retarded morons.