I haven't ever needed to only copy style.stroke or style.fill from an item - so I'm +1 on art.style.fillColor and art.style.strokeWidth..

I don't like art.fillColor because I would probably miss the ability to create a style and reuse it..

Yes, Director also does not use the style object. But I agree with Jonathan about the usefullness of being able to set style objects in one go.

And here's an idea: How about making style also accept plain JS objects:

art.style = {
    strokeColor: new RGBColor(1, 0, 0),
    strokeWidth: 1
}

My observation about characterStyle and style is probably wrong: There is also paragraphStyle, and both fields on the TextFrame are nothing else than a redirect to TextFrame.range.characterStyle / paragraphStyle. So I guess this is allright and should stay that way.

The question with all this is:

Shall I change that for 2.0.023, or wait? This will be the release for CS3, so maybe I should stick with the old way for a little longer? People would have to update their scripts, which might cause a lot of confusion....

Oooh I like the idea of having style accept JS objects! +1 on that one for sure.

Personally, I'm okay with changing it for 2.0.023 - but I wonder if it would be possible to implement a mechanism whereby we could beta test the new versions before they are released on Scriptographer.com..

This would give us some time to update our scripts and make sure Scriptographer is working correctly.

Also, if a new version of Scripto breaks scripts that are currently on Scriptographer.com, shouldn't they be disabled until the authors have updated them? It's a bit of crappy experience if people download Scriptographer only to find out that half of the scripts don't work..

Talking about versions, I would like to be able to perform a version check when people initialize a tool, to make sure people aren't using outdated versions of Scripto.

Yes yes yes, indeed.

All that is badly needed, but also a whole lot of work.

Already, producing just one new release and checking on versions and systems takes a long time. Now if I did that with the current version and the upcoming beta version (while the current one is already beta), I would have so much administrative work to do, I could no do new work on Scriptographer. Also, I would have to maintain branches, be able to build both (on both PC and Mac). I think that would simply be too much.

Giving access to the Scriptographer and Illustrator version is long overdue. Instead of making this a global variable that people will have to check against in each script, I had a better idea: I propably will define a special keyword that can be used in comments, and that the script file is checked against and an error is raisen if the version is not met.

E.g. something like:

// @ver: SG2.0.023+ IL11.0+

I will also expose the current versions as variables, but not sure yet where...

Probably there will be a global object, e.g. scripto, or sg, and this object will offer some values (sg.scriptDir, sg.version, etc.). There will also be the global "app", and the illustrator version can be read from app.version.

Not sure about the naming yet. Any propositions?

sg sounds good enough to me..

And I understand that doing beta releases for developers is a bit too much to propose.. Sometimes my mind is in the perfect world, and not the real one ; )

Well, I could hold back future releases (e.g. 2.0.024) and offer them on a special download page until people think it works well, and then swap on the main download page. That should be easy enough, and also cover most of the cases we had problems with.

More changes coming down the road for 2.0.024:

I moved activeDocument to app.activeDoument, documents to app.documents and fonts to app.fonts.

There is the script object that currently offers script.file (guess what), and script.preferences, which is a container for storing per script preferences:

script.preferences.key = value;

There is now app.version, which represents the Illustrator version.
And I am thinking about app.scriptVersion, representing the Scriptographer build number (e.g. 024, but as an integer, so 24), which should be enough to identify versions for a long time. The alternative would be scriptographer.version (e.g. 2.0) and scriptographer.build.The app object exposes all kinds of other things, which will appear in the Reference once I put it online.

I also want to decide about the other renaming changes that we had a poll about a while ago, so all changes can be taken care of at once, in every single script. I will help with that process...

Any thoughts?

I tend to think so too. And it would allow to separate things more logically, e.g. there would be scriptographer.scriptDirectory, which would be the root of all scripts (not evil), scriptographer.pluginDirectory, etc. Not sure if that's ever going to be used, but I get the feeling yes.