Live data from Hacker News

Gimel Studio: Non-destructive, 2D image editor

gimelstudio.github.io

61–64 of 64 posts

Re: Gimel Studio: Non-destructive, 2D image editor

#61
post #58
post #57

Earlier quoted context omitted.

What you need is a DAG (directed acyclic graph), a tree is not sufficient, and allowing cycles would be messy. DAGs are also the fundamental structure of git commits, and this is what you will see if you do "git log --graph" as well as in most graphical tools. The advantage of letting a user do the layout manually is that he can reorganize nodes the way he wants, for example grouping together subgraphs that are funct…

I thought DAGs were trees, or was that the other way around? I may also be getting DAGs confused with merkel trees(which I also thought were the sameish thing). My laymans understanding is that once you cut the cycles off your graph(to turn it into a DAG) it now structurally is a tree.

DAGs are a superset of trees. All trees are DAGs, but not all DAGs are trees. One way of looking at it is: you a non-tree DAG if you allow the tree nodes to have multiple parents.

One of the reasons trees are so popular in software development, despite the fact most problems being solved with them factor into DAGs much more naturally, is that trees can be rendered nicely in plain text, while DAGs in general can not.

DAGs are really the fundamental structure of almost everything we work with. Git commits are arranged in DAGs. But so is code we write itself - think of a function A, called by functions B and C, both of which are called by function D and E; that's a DAG right there. Even the "abstract syntax tree" is, in a way, planarizing a DAG (it's tree-ish only because you duplicate symbols that are, in fact, a single entity). Filesystems look like trees, but the moment you add support for symlinks, they become a DAG (if you allow symlink loops to form, then it's not even acyclic anymore). Inter-module dependencies of your software form a DAG. Etc.

(Some things are even more naturally represented by a directed graph with possibility of cycles, but we try to avoid that as it's hard to deal with - a cycle is like an infinite loop if you try to step through it, so to handle it statically, you need to be able to compute a stable state of the entire cycle in one go - and if you have time/external input component, then you now have a dynamic system that you'll most likely have to simulate, and something that's tricky to reason about without control theory background.)

Re: Gimel Studio: Non-destructive, 2D image editor

#62
post #2

Interesting! I've done some visual node based editors in the past. One design principle I might suggest: develop a DSL and have the editor just be editing programs in that DSL. You might be able to use Racket—not sure—but alternatively you could copy what I've done here ( https://ohayo.computer ) and design a Tree Language ( https://jtree.treenotation.org/designer/ ). It makes the problem simpler IMO, as then you get…

This is one of the things I used to like about Maya. It appeared to be a command driven editor and everything you did in the UI translated to a command line command. You could set it to show the commands and even capture them and use them as a start for generating a script I don't know if it's still that way after the transition from Mel to Python. I haven't used Maya in 15 years Even more, Maya also was like a 3D ed…

Interesting! This is how I design all of my software.

Do you know the term for this pattern? Is it simply the "Command pattern"? I called it "User Methods" once (https://breckyunits.com/user-methods.html), but was never crazy about that term.

Re: Gimel Studio: Non-destructive, 2D image editor

#63
post #52

I'll be back in 5-10 years when the devs get over themselves and the application actually reflects the "simplicity, elegance, and usability" that it purports to. This may come off as unfair, but I say it as an artist who vividly recalls the frustration of using Blender and GIMP in the 2000s - and, particularly, of trying to get contributors to understand that, actually, the industry standard software had it right, yo…

I personally mostly see the usual HN comments here of people presenting valuable work and commenters shooting it down either because they are unaware of where it comes from, it doesn’t perfectly conform to what they expect or it’s not to their standards considering its insane cost of free. Your comment is very much in keeping with the tradition if I may say so.

My only reservation about this is that I don't quite see the appeal of node-based editing for static images.

Perhaps someone could explain to me what abilities this unlocks compared to a traditional editing system?

Re: Gimel Studio: Non-destructive, 2D image editor

#64
post #62

Earlier quoted context omitted.

This is one of the things I used to like about Maya. It appeared to be a command driven editor and everything you did in the UI translated to a command line command. You could set it to show the commands and even capture them and use them as a start for generating a script I don't know if it's still that way after the transition from Mel to Python. I haven't used Maya in 15 years Even more, Maya also was like a 3D ed…

Interesting! This is how I design all of my software. Do you know the term for this pattern? Is it simply the "Command pattern"? I called it "User Methods" once ( https://breckyunits.com/user-methods.html ), but was never crazy about that term.

It is the command pattern with the added stipulation that there must be some way to represent every command as a simple command line like expression. MelScript commands look a lot like shell commands.

Maybe that's not a requirement. Adobe products will export commands as JavaScript and you can (could?) script most of their tools.

https://helpx.adobe.com/photoshop/using/scripting.html

The difference there is it's an afterthought vs Maya where the UI you interact with is literally implemented in this scripting language, all of which is editable if you want to customize it.

Post reply on HN