(Also, currently our OpenRaster support is a plug-in that calls our PNG plug-in to do the rendering, so we'd have to rewrite it to be a core process if we wanted to use it as our main project file).
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.
OSTree, SQLite (single file DB), OCIRepository, git bundle. But it depends if you rather need code diffs or just versioning of large binary blobs (an image editor needs the latter).
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.)
I meant zipping colloquially as in compressing an archive format. But you seem to get the gist of it ;)
> 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.
Not just game files but also the map format for Warcraft 3 was a glorified MPQ (source: https://867380699.github.io/blog/2019/05/09/W3X_Files_Format).
So whenever you edited a WC3 map, you were zipping the current map into an archive. Much like the GIMP example. Of course, WC3 didn't use as many XML files, though SC2 changed that.
// 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.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.
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.
what I like about it being XML is I can just open it with any text tool and inspect it. It's human readable so I can edit and debug it manually, no need to have a parser or an extra application just to see what's in my file
Nothing wrong with XML, it is well understood, and the tooling is pretty good. But partial loads/edits is one thing it can not do.
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.
- Continuously parsing and writing and reparsing text, 90% of which is useless (that's the JSON/S-expressions vs XML argument)
- Forcing a diverse relational structure to fit a tree hierarchy, hand-writing all the logic that manages representation change - either explicitly, at serialization boundary, or implicitly, in every single access operation you're doing to refer to some data;
- Or worse, using an off-the-shelf, generic object/XML mapper, in which case you just compound the bloat even more.
SQLite is one of the single most battle-tested and ubiquitous piece of software in the history of mankind. Anything "simpler" you're going to pick up is much more likely to be buggy and broken, and will definitely be orders of magnitude slower.
With a zip file at least you know your file was corrupted.
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.
I agree with you that SQlite is overkill but honestly curious to know why you think xml+zip is strange? what would you use instead?
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.
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 ;)
You gain back most of the base64 overhead when you compress it though. It's slower but probably often worth it if the alternative is few more async HTTP queries that you would only fetch once.
That's not been my understanding of it - it maps better to most programming language representations of dictionaries and arrays, but not the 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.
But you don't need to think much about memory representation when you parse a JSON, and the developer experience is a lot more pleasing than browsing a XML tree. That what used to matter.
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?
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.
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.
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
- The icon theming is inconsistent. There's a group of black-and-white icons, a group of blue icons, and a group of colored icons. They are jumbled together and don't seem to indicate any kind of function.
- Tools are not functionally grouped in way which (to me) makes sense. Why is there no separation between "Select", "Adjust", and "Create" tools? Why is the color pipette not part of the color select thingy?
Tool options:
- Why does the Font selector have its label on top and to the right, rather than to the left?
- Why is there no spacing between the "+" of Size and the unit dropdown, like with the labels and the text selector right above?
- Why are window openers in the middle of text properties?
- Why do some options randomly have bold labels?
- Why are Hinting/Color/Style more to the right than the Justify options?
- Why does Color have a weird not-quite-rectangle with grey gaps, rather than reusing the design of the color selector in the toolbox?
- Why are there radio buttons for Justify, but dropdowns for Hinting, Style, and Box - despite them all having about the same number of options?
- Why do the options below Justify have icons rather than labels? Why is the first one using a different look and not visually centered with the other two?
- Why is the label for "Language" above the input field, rather than to the left of it?
Edit dialog on the screen:
- Why is the spacing between "backspace" and "bold" different from that between "bold"/"italic"/"underline"/"strikethrough"?
- Why is the spacing different from that between the font name and size?
- Why is there no spacing between font size and unit? Or, if they are a connected control, why are they not properly connected like -/+?
- Why is "reset to initial"(?) not a proper button?
- Why is the text size number field a different length than the other two? Do we expect people to enter 5-digit font sizes?
- Why does the gap to the right of "strikethrough" not match with anything?
So yes, I would say it is indeed a bit sloppy. There's probably another discussion to be had about its higher-level UX design, but (as a backend designer) this is the kind of stuff a backend developer ends up creating as a quick-and-dirty proof-of-concept before any of the front-end designers get involved.
It is functional, but definitely not enough effort went into making it good.
Most of which is barely maintained and low quality.
For example, just recently:
https://linuxiac.com/libxml2-becomes-officially-unmaintained...
But even before it became officially unmaintained, it was already quite unloved, and it's one of the most used xml library.
We are not in the peak Java/J2EE era anymore. Pretty much nobody is going to willingly work on the foundations unless they're getting paid because the majority absolutely loathes XML and would not see maintaining XML libs as fun, and guess what, they're not? xslt also got removed from web browsers because nobody wants to maintain those libraries. And corporations like Google don't want to pay a dev for those either.
https://developer.chrome.com/docs/web-platform/deprecating-x...
Meanwhile the tooling around JSON is as healthy as it's ever been, with very efficient implementations in most common programming languages and multiple SIMD impls in C, C++, Rust etc. People actually want to work on this.
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.
> 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 :)
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
I don't think I've actually heard the sex thing being used anywhere in the UK, except perhaps when discussing Pulp Fiction. Even in kink contexts!
:max_bytes(150000):strip_icc()/gimp-with-text-7c3c1626f71e4322a8fb9447c995e95a.jpg){kind=link}