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.
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.
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?
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.
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.
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.
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.
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).
> 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.
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?
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?
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.
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’?
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.
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?
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.
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.
> 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. A lot of GIMP developers are European. The Glimpse project tried to force American cultural/linguistic rules on a non-American project.
> 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”?
> 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.
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.
Better Zipped XML than whatever monstrosity Adobe files are. PDF/PSD... shudder.
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.
EDIT: Narrowed the date.
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!
[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
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.
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 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?
> 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.
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.
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.
It's a US specific slur when used in this context, not in other English speaking countries. A lot of GIMP developers are European. The Glimpse project tried to force American cultural/linguistic rules on a non-American project.
How do they pronounce “XCF” such that it’s “a XCF file” and not “an XCF file”? “Xeceff”?
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.