Also here it is -- a moment of can-kicking in action, from that thread:
> Hey! I also think Adjustment Layers are really important for GIMP. However, Layer Effects will be simpler to start with since they only affect one layer.
1,313 karma · joined June 4, 2023
> Hey! I also think Adjustment Layers are really important for GIMP. However, Layer Effects will be simpler to start with since they only affect one layer.
I am that kind of decades-long hosted-linux-from-a-Mac-desktop user who checks out desktop linux every six months or so to see if the daily driver situation is ready.
I edit quite a lot of photos and even though Darktable is a mess, I could use it and it's not the only option. I edit vector graphics and I think Inkscape is fine. I like FreeCAD. All of my coding tools appear to run in Electron, etc. etc.
But GIMP isn't an option. It's not even close to being what basic quick correct photo editing needs in terms of a workflow. And I'm simply never going to change what is not really a particularly deep or exotic workflow to fit it.
Krita is _sooooo_ close, and it's not even trying to be a photo editor first and foremost.
Adobe don't. The Adobe codebase is cruft that has taken a similarly long time to shake out. Lightroom was seemingly built like a skunkworks project almost like a desktop webapp (scripting around a core renderer, SQLite, simpler mode-oriented GUI) to avoid the intransigence and friction of Photoshop's codebase.
But this is what GIMP is up against. Cruft that earns money, that is driving not just what users want but how they think about what they want.
For GIMP to be more successful it doesn't need live non-global filters like blurs, but it would have been enormously beneficial to the project if it had global adjustment layers, say, 15 years ago.
Then youtube would have been filled with tutorials, there would have been momentum around the project, some commercial support interest, etc.
Kicking the can down the road has consequences. This great Ondsel blog article about how difficult it is to merge major changes into an open source project goes into it in some detail:
https://ondsel.com/blog/freecad-topological-naming/
Some decisions need to be taken at the right time; if you don't, you need a whole separate kind of energy to get them done without stopping everyone else.
(The successful Affinity suite is a result of taking some right decisions back in 2010 or 2011)
I am almost as far as you can get from an expert (and I am sure there is one here who can explain it better and hopefully correct me) but:
For example the TNP issue derives from OCCT (or something in the stack close to it, I am not exactly sure) not really handling face naming at all.
So if you want to avoid topological naming issues (which is a hard problem in CAD), you apparently have to do some work to track before and after and reconstruct your face naming from either side of the OCCT black box.
https://wiki.freecad.org/Topological_naming_problem
https://forum.freecad.org/viewtopic.php?t=27278
Then there are various fairly entrenched issues to do with filleting and chamfering. Basically, both these operations will fail if a chamfer or fillet would completely consume an existing edge. It also sometimes creates impossible objects when filleting, or used to.
Booleans can be slow.
And more generally, it seems if you track the FreeCAD project that OCCT can be inscrutable when things fail; error messages aren't the greatest etc.
The flip side of OpenCascade is that it seems to be highly portable and has for example been compiled to JS with Emscripten for this astonishing thing:
https://zalo.github.io/CascadeStudio/
It's a monumental open source project, for sure, and it's definitely not nothing that we have an open source CAD kernel; these are projects that perhaps have to extend beyond the working life of an individual developer if they are to be stable. And there are loads of projects built around it. So it's absolutely consequential and we're lucky to have it.
- bad (in places better called solipsistic) UX
- underlying architectural issues from its dependencies (e.g. OpenCascade's OCCT and Coin3D)
- a flood of competing workbenches and plugins so users struggle with initial workflow, many abandoned or undermaintained
- something of a reliance on knowledge of Python scripting to solve advanced issues
- and (akin to GIMP avoiding non-destructive-editing for two decades) a fundamental architectural issue: topological naming problems that other CAD packages have solved
But things in FreeCAD land are changing really fast -- there's a TNP implementation coming quite soon to core FreeCAD, there's a core assembly workbench, a materials system and really significant GUI and UX improvements.
The reason is things are changing is that that people central to FreeCAD looked across the open source landscape to Blender, and saw how a project can be run, and how commercial companies could consult on top of it.
Everything has changed within a matter of three years. Despite its issues, FreeCAD is now exciting to watch.
Whereas GIMP seems to still be circling around looking for the best solutions to things they never finish. Krita has become the thing GIMP could have been, and it is nine years younger.
This is the purest of comedy. I applaud it. And I think a twenty-seven-year-younger version of me who first used adjustment layers in Photoshop in early 1997 [0] might find it even funnier to imagine this future.
This isn't "skating to where the puck was". This is "skating to where the rink was before they tore it down and built a shopping mall, that they tore down to build offices that they are now going to tear down to build a retirement home for GIMP developers".
[0] when, I note, GIMP already existed. OK so they got a bit distracted building a GUI toolkit, and we should not forget the significant value it added. It's the real transformational product of the entire endeavour.
But seriously: this wasn't voodoo, weird niche case or hypothetical stuff by the early 2000s, when they were still building a GUI image editing app that really relied on advanced users having Lisp knowledge. And they continued to kick it down the road for literal decades.
And yet it is engineers who will be building this magical platform that you think is 'neat', that you think engineers generally somehow can't understand.
How is that going to work out?
Engineers are always greener on the other side of the fence.
Zapier, Tines, Workato (and doubtless some other gibberish names I haven't heard of) don't intend for a system like this to work, either. They won't bend over backwards.
The one thing this idea is not is neat, though. It's the opposite of it. It entrenches the opposite of neat.
I too am upset that Big EDIC has been thwarting this intuition for the better part of fifty years.
But I agree with you.
Many years ago I worked with an ex-IBM “strategist” who wrote and talked in this way. Supposedly something of a visionary; hired as an evangelist. Everyone was very impressed by him in meetings and customer consultancy.
But I am not sure if he ever said a single thing of substance.
At this point, the researchers also realized that the heat could inadvertently melt the adhesive cellophane and cause the flaming SPTs to suddenly eject from the toaster. Unfortunately, this did not occur.
There is one famous, very real, very popular American candy store in London -- Kingdom Of Sweets -- which is absolutely legit and has been trading for twenty years, having started elsewhere. It was famous in British geek culture for being where you bought all the sweets you heard US geeks talking about on Foothills and Surfers and the like.
And then there's a couple of likely legit competitors, and then... a whole layer of fakery, fraud and shell companies.
If you want American candy, sure.
(To American HNers: this isn't a joke about you. Or even really that much of a joke, alas)
1) these things are pretty and the physical design is fun—- and their appeal is universal across age and gender
2) the EVF/OVF technology is at its best in this specific device.
Both of these things combined are clearly worth the extra money; this camera is likely going to be difficult to get hold of in some markets for some time. Late demand for the X100V was astonishing.
Still: that doesn’t make the assertion about the size of Facebook’s FTC settlement and all GDPR settlements as significant as they think, for a bunch of important reasons that start to be obvious once you break it down.
The parent poster could be posting from a FAANG C suite, and it wouldn’t change that it’s an apples and oranges comparison.
I suspect the same applies for certain connected devices.
This isn't anywhere near as significant a point as you think.
Right, but the "separate business" here -- in a real-world analogy -- is akin to a commercialised offshoot of the department of transport.
They may not make the roads, but they decide what goes on all the maps, they control most of the road signs, they benefit from the traffic monitoring data, and if you were to open up a shop selling only advice on where to shop, they determine whether your shop can be seen behind their signs. They profit from how they manage this, and the only way to get better management is to pay for it. Everyone pays for it, so the advantage dissipates until you pay more for your signs.
There is little to no way to do business without these people, short of setting up a stall at the local covered market or farmer's market (Amazon, eBay, Facebook, Etsy) where you are beholden to another set of signage issues as well as the secondary knock-on effects of large-scale signage issues on the way to the market, over which you have even less influence.
Beyond that: it's literal word of mouth.
Schema-first feels more manageable.
I'm not going to say I haven't had to do that a _bit_ here, when I've got into quite advanced things.
(e.g. sometimes you might want to dynamically provide the values from an enum, or write your own decorators, or you might want a custom top-level resolver.)
It's built on the WebOnyx reference implementation, so there's some help out there.
But it's amazing how much code I haven't had to write, and being the sort of person I am with difficulties controlling focus, I absolutely love the schema-first approach. It interacts well with Eloquent scopes, with the ordinary API gate system, with policies and validations.
It's actually weird how good it is. You still have all the same issues you have with GraphQL generally (like limiting graph traversals to things a user is authorized to see), but you have so many tools.
And it gives me the opportunity to separate out the front end concerns in a way I could explain to someone else.
Apollo has been a bit of a pickle on the front-end, mind you. That's a decision I'd revisit.
But generally it has meant a flexible API interface and leads to nice low latency UIs.
Check it out:
And these really good third-party auth mutations for Passport:
Indeed.