Scriptographer.org - Poll: Changes to the API

I am currently considering some important changes to the API that probably would break all existing scripts again, but they would be easy to update and the changes would make a lot of sense:

Adobe gavbe all Art prototypes names ending with "Item", and I would like to do the same:

Art -> ArtItem
Group -> GroupItem
CompoundPath -> CompoundPathItem
Path -> PathItem
PointText -> PointTextItem
TextFrame -> TextItem

etc.

Also, I would like to rename Grayscale to GrayColor, to be closer to Adobe's naming here too, and to make it more a family together with RGBColor and CMYKColor.

One of the reasons why I would to do is that I started adding support for symbols. As there are both the symbol objects in the palette window, and the symbol instances in the document, this naming scheme would help: Symbol (the objects in the palette window) VS SymbolItem (the instance in the document).

This naming scheme makes a lot of sense, as it makes it more intuitive to understand what for example the difference between a Rectangle and a Path is (one is an abstract object describing the dimensions of a Rectangle, the other is a Path item in the Illustrator document).

If I do the change, I would update all scripts that come with the plugin and also the ones people uploaded here to the new notation. I could assists people converting scripts they have not uploaded, but the changes would be very straght forward anyhow.

But before I go ahead, I would like to hear other people's opinions on this.

Yes, the version number will be added. I will need to find a way of doing this so even in versions of the plugin where the number is not exposed yet, the check can be done easly (e.g. as a global number that can be checked against a value, if the number is not there, the value is not greater than e.g. 2.017...). This is all to come soon.

I think this is a good time to make large changes like this, since not so many scripts have been uploaded yet (and the install base isn't huge)

Although I generally like shorter names, it does make things alot clearer for new users.. So +1 from me

btw: why is a TextFrame a TextItem and not a TextFrameItem?

TextFrameItem felt like too complicated. TextItem is the base class for PointTextItem, PathTextItem and AreaItem, which feels natural as a naming scheme. TextFrame was chosen because Text would have been a too general name.

I agree about the niceness of short names. I still hesitate with these changes... But using Item just feels more logical all in all.

I'm also considering prepending all GUI elements with a letter or two:

SGButton, SGDialog, etc.

AButton, ADialog (for Adobe, but also simply 'A')

But again, I am not shure... The problem right now is that for example List is far too general a name for an interface element. Button is OK... Maybe I just need to find a more specific name for that one, e.g. ListBox and HierarchyListBox. This feels more like the way to go.

Another problem is the use of Image in ADM vs Raster in AI... Raster would ideally be called Image (much more intuitive). Image could then be called Picture, as a GUI element... But that's not really an elegant solution either, althought that's how Adobe calls it internally.

But then again, if Raster becomes ImageItem, Image could stay that way... Argh, naming confusion ;)

In my opinion, the GUI functions are secondary citizens, and shouldn't mess up the namespace.. I wouldn't mind them being called SGButton.. or maybe AdmButton.. Or adm.Button ?

The difference between picture & image is probably going to be lost on most people.. But when you need to add an image to your dialog, you're going to take a look in the dialog reference first anyway.. So maybe picture isn't such a bad idea after all..

I wouldn't know what to call it otherwise..

Raster should become ImageItem (although RasterItem is fine by me too)..

Scripts

08.08.14, 15:24

15.05.14, 14:23

02.03.14, 19:16

18.11.13, 14:48