Hacker News Reader

Comment by nabla9 | Hacker News Reader

All these programs like GIMP, Blender, Dune, should split into two.

There should be a library that has the functionality and data structures to manipulate data. The UI should be a separate project with different people.

There could be multiple GUI's for the same project or same GUI framework for multiple projects.

View on HN

There are barely a handful of people contributing to Gimp regularly, how do you want to split that into multiple teams?

It looks to me like people are regularly fantasizing the size and structure of this project.

Couldashouldawoulda do not work when there aren't enough hands. We shouls be thanksful to have those powerful programs provided to us first and foremost.

This is what we did at ILM, with our in-house software package Zeno. The lowest level of complete functionality was the "Sg" namespace (short for Scene Graph). Above that lived user-and-SDK-friendly commandline utilities layer (SgCmd) that was used for all scripting. Above that, finally, was the Oz layer -- the graphical UI. Oz actions called SgCmds, but never saw or touched the Sg layer.

In theory, Oz was UI toolkit agnostic but, as anyone who's ever done UI work will understand, it rapidly became wedded to the toolkit we used (a heavily customized version of Tk). This made the eventual switching to Qt very, very difficult. So difficult it nearly destroyed the artists' faith in the R&D group. (Extremely late delivery, buggy, and coming at the manpower cost of not doing any improvements on the tool itself for a year and a half.)

How did Python scripting work with that? It sounds like Python could only call the SgCmd layer but couldn't redfine anything at the Oz layer.

And, how did Python call that SgCmd layer? If instead you wanted Tcl (or Ruby or ...) to call that SgCmd layer, how would that work?

Interested in this as I'm very much bumping into problems like this right now.

Sounds like you are sort of describing GEGL in the context of GIMP, though it would be difficult to draw that abstraction in a way that makes implementing competing GUIs straightforward or DRY.

Many CAD programs, opensource or proprietary, work almost this way. There is often a relatively lesser known CAD/geometry engine behind the front end everyone knows as the CAD program. Perhaps since engineering has more standard computations than art.

That's true for literally all software.

We would be much better off if GUI was a replacement for the shell instead of a replacement for every individual shell utility.

Reply on news.ycombinator.com