New OS X Interface Suggestion

[rgovostes]

I think it's kind of awkward to code on the left side like it is now, so I started my own Context Free IDE. I got bored after a little while, though, so I thought I'd just make a mock-up of the design I had in mind and post it for someone more motivated to poke at.



(Created in Interface Builder with lots of icky hacks, post-processed with Photoshop.)

The idea is to free the user from the structure of the file. The left pane offers a list of the different rules, where a "1" designates the starting rule. The right pane is obviously where the code is, with a header giving the percent chance of the rule executing. Some mechanism would be used to switch between the variations of a rule.

By using a GUI like this, the user worries less about file structure, and instead gets a spatial view of their design. At render time, a pre-processor would build the CFDG file, rather than the user having to touch it.

Summary of advantages:
+ Easily view the different rules of a design without scrolling
+ Easily view or change the primary rule
+ See a percentage for the current rule's chance
+ Code in a monospaced font
+ Less worry of typos, etc.

Cool features that I'd like, too:
+ Autocompletion (SQ+tab = SQUARE)
+ Ngon / rectangle rule generator

Comments / flames welcome.

[bigelectricat]

what would be cool too is if mousing over the different elements of the image will highlight the corresponding rule or maybe even values within the rule to make it easier for the lay person to change variables.

[rgovostes]

Hm, I'm not so certain that's possible - after all, a program could draw over the same spot over and over again, not to mention that the principle of "context free" means we can't assume it to be drawn at the same rotation or size or position each time.

Although it would make analyzing the behavior much, much easier.

[bigelectricat]

i guess you are right. it is impossible to keep track of thousands of random patterns that come from a few lines of instructions. not to mention the fact that the rendered image is rasterized. there is no way for the program to map those elements. unless somehow, a temporary file is created everytime the pattern changes direction. like a snap shot of the process or a history of the rendering. then a log file can be generated along with the history which allows the user to roll back and view which rule or variable affected the pattern. hmm... i see almost hundreds if not thousands of temp files on some examples already. nevermind.

[Jay Kominek]

it is impossible to keep track of thousands of random patterns that come from a few lines of instructions. not to mention the fact that the rendered image is rasterized.

I'm not sure exactly what the processing pipeline looks like, but it seems as though there are two stages. In the first, a list of shapes is accumulated by running through the rules. Keeping track of which shape came from which rule seems trivial.
The next stage takes all of these shapes and draws them into an image. Here is where you think there is a problem. Instead of drawing all the shapes into the same image, you make N images, one per rule. Shapes from rule n go into image n. Shapes from rule n+1 go into image n+1. The final image is produced by OR'ing (or whatever operation you prefer) the different subimages together.
After that, when you want to see which pixels came from a particular rule, you can reference the appropriate subimage, and redraw all the pixels in it as red in the display.
This would require proportionally more memory.

This ought to be equivalent to rendering N different versions of a particular CFDG, such that only one rule has primitives in it in any particular render.

[mtnviewmark]

'm not sure exactly what the processing pipeline looks like, but it seems as though there are two stages. In the first, a list of shapes is accumulated by running through the rules. Keeping track of which shape came from which rule seems trivial.
The next stage takes all of these shapes and draws them into an image.

Pretty much right! Indeed, there are two phases: Expand all the rules into a list of shapes to draw, and draw all the shapes. The only thing is that sometimes we pause while expanding the rules to draw the shapes we have. This is how we get the animated effect.

Keeping track of which rules the shapes were generated from is pretty easy, and keeping figuring out which shape (or shapes) are under the cursor when you click is also pretty easy -- just keep the list rather than throwing it away. (The only caveat is that if the list is over a million shapes, we spill it to files, and that would make this unworkable.)

I think the real problems are that a given pixel might represent many shapes - and so you'd have to present a list to pick from. In many images that list could be hundreds. The second problem is that I don't think it would be useful to know just which rule generated a shape. You'd need to know which rule spawned that rule, and so on. THAT would be really a lot of memory to keep track of!

[odinsdream]

Personally, I'd prefer for the code and render window to be completely separate from eachother, or at least "undockable."

This would allow you to reposition things however you like without relying on someone else's idea of what the interface should look like. Personally, I'd have a very tall, skinny code window on one side of my screen, and a fairly large, square-shaped Render window on the other side.

Combine this with a keystroke to start rendering, and you've got the perfect interface, in my opinion.

Text-folding would be nice, though, to collapse rules.

[PatternGuru]

Combine this with a keystroke to start rendering, and you've got the perfect interface, in my opinion.

Mmm, I asked for something like that (suggesting the F5 key since that would be natural for me to "run" something given I work in VisualStudio for 32 hours a week), but was instantly reminded that Ctrl+R is already available as a kyeboard shortcut for rendering.

I would like the F5, dockable/movable window parts and something like auto-completion (but then under Ctrl+Space for me please, as in VisualStudio) in the editor.

However, that's all just "nice" as far as MoSCoW is concerned. I'd rather have color for instance. Or some kind of collapse feature for rules or the original suggestion at the top of this thread.

[MtnViewJohn]

As has been said before, figuring out which rule generates a given pixel can't be done because of overwriting and because the required information is lost. But Context Free could have a break-point facility. I can think of two type of break-points:

1. "Code" break-points that are associated with a particular shape within a rule.
2. "Data" break-points that are associated with an area of the screen getting touched during rendering.