Don't know about the other links you've posted, but for photocraft the vast majority of those issues are from the engine that process the image itself, not about the GUI. In fact, as far as I can tell, none of the artcraft apps are that complex in terms of GUI to be slow down by any choice of GUI framework really. There could be performance differences between them, yes, but not so much.
Why are you stating something that is not true as though it were a given, and then using that unearned precondition as the basis for your question? The premise is false. Artcraft is a complete fucking trainwreck, nothing more than scamware that falls apart as soon as you poke beyond the deceptive facade that was used to build hype.
(That said, on the scale of blame for it being bad, I would say the GUI framework accounts for 0% of that and the programming methodology accounts for 100% of that)
This does not match my experience, I use gridcraft (excel), vectorcraft (illustrator) often; they work fine.
It's ~100MiB each, installs in seconds; I can point my agent at the github repo and it will be able to run it and control the apps; e.g. look at how excel spreadsheets actually render and adjust the layout.
I'm not a power user, but for my particular use cases artcraft apps are better than the original counterparts (install-size + agent control).
UI for CAD-style apps is not that complex. You're typically looking at maybe hundreds of visible controls at most. Of course, assuming that the rendering of the picture/parts is handled separately.
Well, primarily users of Adobe software don't have efficiency in mind as their first priority. It's a little different if you are making a desktop widget and it eats a good chunk of your GPU while idle.
Most of these GUI software are vibe coded so state management essentially becomes somebody else's blackbox problem.
Can't you fix this scaling by chunking the entities? So not making one massive 10,000 thing entity but instead breaking it up into entities that group 500 things?
Of course you can, and you can also make it so that if UI changes, instead of having every single entity rerender, only the changed entity would rerender, and you can have a library that manages the changes or "dirty" state of these entities reactively.
So, which are the most advanced GUI frameworks that have ever existed, and why are they superior to GPUI or egui?
Which company in the past needed a GUI more than Microsoft? Maybe they have the answer? Or Apple?
I don't think social media apps are GUI heavy enough to have developed something advanced in this field.
GUI complexity and application complexity are two different things
arguments in the post sound reasonable but conclusion is off.
>I believe both GPUI’s and egui’s state models are dead ends for complex desktop applications.
Why do those complex Adobe clones work so well then?
They actually don't.
Slow, laggy UI is a common source of complaint on the issues.
Examples:
https://github.com/storytold/cadcraft/issues/752
https://github.com/storytold/cadcraft/issues/874
https://github.com/storytold/vectorcraft/issues/2292
https://github.com/storytold/artcraft/issues/2409
https://github.com/storytold/photocraft/issues/9327
Don't know about the other links you've posted, but for photocraft the vast majority of those issues are from the engine that process the image itself, not about the GUI. In fact, as far as I can tell, none of the artcraft apps are that complex in terms of GUI to be slow down by any choice of GUI framework really. There could be performance differences between them, yes, but not so much.
Why are you stating something that is not true as though it were a given, and then using that unearned precondition as the basis for your question? The premise is false. Artcraft is a complete fucking trainwreck, nothing more than scamware that falls apart as soon as you poke beyond the deceptive facade that was used to build hype.
(That said, on the scale of blame for it being bad, I would say the GUI framework accounts for 0% of that and the programming methodology accounts for 100% of that)
This does not match my experience, I use gridcraft (excel), vectorcraft (illustrator) often; they work fine.
It's ~100MiB each, installs in seconds; I can point my agent at the github repo and it will be able to run it and control the apps; e.g. look at how excel spreadsheets actually render and adjust the layout.
I'm not a power user, but for my particular use cases artcraft apps are better than the original counterparts (install-size + agent control).
How’s accessibility?
UI for CAD-style apps is not that complex. You're typically looking at maybe hundreds of visible controls at most. Of course, assuming that the rendering of the picture/parts is handled separately.
Hundreds of visible controls sounds like more complexity than you want.
These controls are largely independent; whereas the complexity being talked about here is interdependent GUI elements.
Something about every complex GUI being a spreadsheet-style calculation.
Well, primarily users of Adobe software don't have efficiency in mind as their first priority. It's a little different if you are making a desktop widget and it eats a good chunk of your GPU while idle.
Most of these GUI software are vibe coded so state management essentially becomes somebody else's blackbox problem.
Can't you fix this scaling by chunking the entities? So not making one massive 10,000 thing entity but instead breaking it up into entities that group 500 things?
Of course you can, and you can also make it so that if UI changes, instead of having every single entity rerender, only the changed entity would rerender, and you can have a library that manages the changes or "dirty" state of these entities reactively.
And that's why React exists.
Is diffing really that expensive even in complex applications?
AI critiquing AI’s favorite native UI framework, brilliant.