defaults

[zol]

It would be nice if the commandline version did not require so many arguments to be routinely supplied.
I mention the commandline version specifically because I don't think one should need a GUI or other support script just for more convenient defaults.

maxshapes
It seems better to have a moderate default for frequent/casual experimentation and reserve potentially enormous numbers for when one really means it.

I know it involves an arbitrary choice, but pretty much anything is better than a 20 tempfile surprize. I favour a low starting value of 10,000, which I can later raise when useful.
There's always the old "-m 0" convention for "No, really. I don't care how big it gets."

border
25% is just silly. That's 75% of the total area.
Besides which, it's a flat colour; cfdg is not really needed for that.
I almost always use 0.

Actually, the options are rather strange: -8px,0,8px,25%.
I probably would have gone with <signed-byte>px, maybe using the higher magnitudes for percentages, say sign(N)(|N|-100)%, i.e.+/- [1,27]%

hmm
It's probably not warranted at this stage, but user prefs/config files can be useful for supplying arbitrary defaults.

I don't actually know whether you think of cfdg as a complete application or just an engine to be used by a separate interface. Obviously, I regard it as the former.

[MtnViewJohn]

I agree that the default max shapes of 40,000,000 shapes is not a good idea. But 10,000 shapes is too low. Many designs use lots of shapes to create there desired look. If the default was low then people viewing the cfdg file would not see the intended look. Maybe 5,000,000 would be a better default.

You only get 75% border if you are rendering a very compact design. I think that the default border is pretty good for most designs. But controlling the fixed part of the border and the variable part of the border with one value was a bad idea. In cfdg 3.0 there will probably be separate options for the fixed and variable parts of the border.

Having a config file for defaults (.cfdg_prefs for example) is a good idea. I would have cfdg search for a config file in the current directory and then all the way up to the root directory. And then search for one in the users home directory. That way you could have defaults for viewing other people cfdg files in your home directory, and defaults for your own work in your work directory.

We want cfdg to be useful as a complete application and as an engine.

[zol]

I recall Kochlea might have taken about 5 million shapes to hit the default rendering limit, which is what I used to create the finished gallery image. (It has a lot of superimposed duplicates)

My point of view is that of getting an idea and doing many sketches while refining the code from the coarse to the fine. 'By default' one isn't interested in the details yet, but might be later, if onto something worth pursuing. Lowering the initial work for new users, casual usage, and after a hiatus when one might forget to supply some arguments.

Nevertheless, I see the problem with viewing others' work as intended (although one can be wrong in either direction there). Kochlea at low maxshapes has a different style entirely.

Separate prefs files would certainly do the trick there.

(It's almost temping to consider script directives so that artists can dictate what they consider a correct representation. Optional of course - not all users or works are particularly sensitive to these values.)

Ah, so "variable" border is more clever than I supposed. Just bad luck that I was playing with squares whenever I forgot to set it.

[alpt]

maxshapes
I favour a low starting value of 10,000, which I can later raise when useful.
There's always the old "-m 0" convention for "No, really. I don't care how big it gets."

It would be useful to have the maxshapes directive in the .cfdg itself.
For example, Qerc
needs exactly maxshapes=30.