3 ms·

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

by nabla9 3y ago

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.

deleted 3y ago
[deleted]
BHSPitMonkey 3y ago
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.
thomastjeffery 3y ago
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.
riotnrrd 3y ago
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.)
- bsder 3y ago
  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.
deleted 3y ago
[deleted]
signaru 3y ago
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.
prmoustache 3y ago
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.

by nabla9 3y ago

deleted 3y ago

[deleted]

BHSPitMonkey 3y ago

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.

thomastjeffery 3y ago

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.

riotnrrd 3y ago

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.)

bsder 3y ago
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.

deleted 3y ago

[deleted]

signaru 3y ago

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.

prmoustache 3y ago

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.