invite more menbers

[anton-liubushkin]

Kamil Khadeyev | darkwark — author of awesome scripts for Photoshop

Anton Lyubushkin | nvkzNemo :smile: → ZXP installer / manager & HTML-panels & scripts for Photoshop

[ff6347]

Hi @nvkzNemo welcome. You and @darkwark are invited. It should be visible under https://github.com/ExtendScript Check out the possible projects, come up with new ones or just sit back and watch what happens. Cheers Fabian

[codearoni]

I'd join this group!

[ff6347]

You have your invite. Welcome. Any contributions are welcome

[waterlooSunset]

I'd like to contribute, are you still accepting new members?

[ff6347]

@waterlooSunset you should have an invite. Welcome.

[andyinabox]

@fabianmoronzirfas can I join?

I've been working a bit with basil.js and created a simple development template for that framework: https://github.com/andyinabox/basiljs-template

[ff6347]

@andyinabox of course. You should see your invite under https://github.com/ExtendScript and have it as mail

[JavierAroche]

Hey guys, I'd like to join and contribute. These are my 2 open source projects: brackets-to-photoshop / descriptor-info

This guy is also pretty good :) @antonio-gomez photoshop-connection / photoshop-dom-event / photoshop-ui-manager

[ff6347]

Hey @JavierAroche & @antonio-gomez you both should have your invite under https://github.com/ExtendScript or as e-mail. Welcome!

[GitBruno]

Hey, would love to join and contribute. I am getting more interested in package management as I tend to use a lot of the same code over and over again. I like the idea of the extendscript-library. Is this still under development? I have been doing some research and found a few options ideas out there but nothing stood out to me. Might it be good to create scoped NPM space for it?

[ff6347]

@GitBruno You should have an invite. As email and on the home site of the org. If you give me your npm username I also invite you to the npm org we have.

[GitBruno]

Cool! it is extendscripter

[GitBruno]

I tried setup a scoped space. Only added the shims for now as a test. Have a look and let me know that you think of the concept/setup @fabianmoronzirfas

[ff6347]

cool. How do you maintain this? Manually?

Some questions that come to my mind:

• Why not publish this under the extendscript GitHub org?
• Why not publish this as well under the extendscript npm org?
• Is this taken form the https://github.com/ExtendScript/extendscript-es6-shim and https://github.com/ExtendScript/extendscript-es5-shim?
• Do we really need an package for each function?

If this is under your account you will get the PRs and question emails. If it is under an org account it will be seen more as a community effort and it is easier for someone else to take over if you are busy.

[GitBruno]

How do you maintain this? Manually?

At the moment yes, but it does not seem to bad when using the DRY method. npm takes care of most updates generally. I'm sure you have all sorts of clever ideas about this.

Why not publish this under the extendscript GitHub org?

That would be good! I'll transfer ownership right now. I started this before I was a member but also did not want to clutter the space as new member with something that was half baked. Needed to have a play to see if and how it would work exactly. Will need to get some serious feedback on this. Other things I am wondering about is if it is a good idea to have a global object where we can attach methods to?

Why not publish this as well under the extendscript npm org?

From what I know an organisation can only have one scope. So it might be good to keep it seperate? Happy to move this if you think that is better?

Is this taken form the https://github.com/ExtendScript/extendscript-es6-shim and https://github.com/ExtendScript/extendscript-es5-shim?

Yes, but not checked or tested

Do we really need an package for each function?

Not necessarily, but I tend to include only the functionality I need. It gives the freedom to include any fill or combination of you want. But also to repackage as you please. As you can see I also created some packages that reflect the es5 and es6 shim mentioned above.

So yeah, lots of things to discuss!

[GitBruno]

Just moved it all here. There is one thing we should resolve sooner rather then later, and that is the name of the scope. At the moment this is @extendscripters but this might be confusing? It might be more useful to call it @es-packages or @es-libs

[indiscripts]

Hi Fabian & Bruno,

Many things sound very interesting but I have no idea how to contribute, share, etc…

As you may know I'm working on IdExtenso, which already offers some ExtendScript modules to InDesign scripters. Well, that's a framework. Maybe its implementation appears too specific to fit the rules of this Org.

Anyway, a bridge may exist between our respective works, so let me know if anything could be done in that direction. I would still be happy to interact.

[GitBruno]

Hey Marc, great to hear from you.

IdExtenso is really cool! I have heard of it, but not got a chance to use it much. I guess loading a whole framework seems overkill some times and other times it forces me to work a certain way. The idea with dry npm modules is that we can select our own API. And then package the output as a complete script/plugin with only the functions it uses without the massive API bloat or needing to have the API pre-installed. There is room to create more complete solutions as well (I call them bundles). More complete solution can be build from the smaller ones.

So for example, you could port your idExtenso modules to the npm namespace. And then load them into your framework. But you bring up a good point and that is how do we do it? As we seem to be short of good guidelines. I mean do we need conventions? Which ones? These are hard questions to answer. But let's talk about it! Would love to get your feedback Marc, what would you need to know to contribute?

It seems we need to work on the guides a bit more first?

[ff6347]

Hi Guys. I can't join the discussion at the moment. I'll be AFK for the rest of the week in ca. 1hour. I'll take a look at this discussion on the weekend. Might be good to take this to the slack workspace where we can create threads on topics. If I should invite you drop me a line under fabian.moron.zirfas@gmail.com

[indiscripts]

Hi Bruno,

Thanks for your thoughts.

(…) More complete solution can be build from the smaller ones.

Yep, that's the best way to summarize our very topic. What could be the bricks, the design pattern(s), the paradigm, when pushing ExtendScript solutions for developers. That's really a deep, and complex issue that I try to deal with on my own.

As a package manager, JavaScript-oriented, npm is without doubt a powerful solution, if not simply the best, within node's runtime territory. I'm confident that extension/panel devs use this approach, or should, since they have to connect regular JS stuff with ExtendScript.

But IdExtenso provides something of an alternative when you only have to package pure ExtendScript bricks into a final, clean JSX. Its advantage here is that it knows the particularities of an ExtendScript/InDesign script (regarding the #targetengine directive, the language, the environment, various cross-versions issues, etc.) My preferred illustration of this is JSON. The usual, vanilla js, JSON brick is not ExtendScript compliant although it seems so. It even contains syntactic problems, because ES does not 100% comply with JS operator precedence. So, IdExtenso is designed to offer a better JSON module.

Now, the core distribution is not a so massive entity. It weighs about 120kb once jsxbin-compiled and already offers handy tools (log, json, environment scanner, string formatter, object cloner and many other.) Then you can add optional modules as need be. Things like BigInt or Random, obviously, have not to be #included in every project! In other words, the /etc branch in IdExtenso is similar to a package directory.

But I get your point when you write:

I guess loading a whole framework seems overkill some times and other times it forces me to work a certain way.

For sure, $$ has various postulates behind the scene. Its design can be intimidating to the point that one sometimes wonders if it is still actual ExtendScript code ;-)

Which leads us to

(…) how do we do it? As we seem to be short of good guidelines. I mean do we need conventions? Which ones? These are hard questions to answer.

So true. The big question is, indeed, about documentation and guidelines. I mean, having time to write, explain, and illustrate what we do. This is a domain where interaction with true people is needed. I have not the answer to “How do we do?” now. I'm just ready to discuss and share ideas in case of convergent motivations between us in this Org.

[GitBruno]

@indiscripts Maybe we can try and package JSON as a test?

shim.bundle.json includes

• shim.json (Standard JSON with parse and stringify)
• shim.json.clone
• shim.json.saveFile
• shim.json.readFile
• shim.json.validator
• shim.json.initiator
• shim.json.extenso

Generally, I think it is good to extend existing objects like JSON. Keeping existing functions JSON.stringify() and JSON.parse() working as expected. Said that, there is nothing stopping a user from overwriting the JSON object themselves. I changed my mind. It might in some cases be a good thing as long as it is setup properly and noted in the docs.

This is a hard one as we have to share the same global object but will result in good guidelines on how to do things in general. So yeah, we should not overwrite each other's methods when loading JSON so we are truly expanding it, rather than replacing. This will need some governance.

I will start setting mine up using Peer Dependencies

@fabianmoronzirfas yes invite to slack will be great. The Gitter looks dead :)

[ff6347]

@GitBruno Yes gitter died somehow. :-). And yes to guidelines. I'm currently not the one who can tackle this.

[bigarobas]

Hello everybody.

I'm actually working on an opensource Toolbox for building Adobe CC extensions with CEP. I'd really like to discuss it and have inputs from the community but I don't really know where to start :)

Here is project: https://github.com/bigarobas/plugincc/ And here is a more in depth article about the main concepts: https://github.com/bigarobas/plugincc/wiki/Mixed-context-in-Adobe-CC-extensions-with-CEP

Is this a good place for this kind of discussion ?

Thanks.

[ff6347]

There is a Adobe Slack workspace about scripting and cep. Maybe this would be a good place. @undavide what is the process to get in there. I can't remember.

[bigarobas]

Thanks Fabian,

I found this post from 2017 (https://forums.adobe.com/thread/2370212) in which @undavide lists 3 slack channels:

1) Extendscript has been created by Fabian Morón Zirfas to support the ExtendScript · GitHub. It now has very low traffic and targets all applications using Extendscript – but there is a good deal of PS devs.

2) Ps-Scripts (the slack channel, not the website) was founded if I remember correctly by Anton Lyubushkin, and was for – surprise surprise – PS scripting :-) Very low traffic here as well since many of its participants then migrated to:

3) Adobe Devs, that has been founded as a follow-up of the PePcon conference. It targets all kind of development around Adobe (panels, scripts, C++ plugins), and was initially and mainly frequented by ID developers. Me, I've tried to inject as many Photoshoppers as I could :-) and I would say that now it is better balanced – there are few guys on IL as well.

But I don't really know how to get invited :)

[ff6347]

I can try to invite you to some of them. Should I use your e-mail listed here at github? https://github.com/bigarobas

[bigarobas]

Yes please :) I think it's rashid.ghassempouri@gmail.com

[ff6347]

Got an invite for the Adobe-devs and extendscript one. Ps-Scripts needs to be done from one of the Admins of the workspace

[bigarobas]

Thanks a lot.

I've already received your invites! I also tried my luck at forums.adobe.com ...

If you need any help with any of the ongoing efforts to create some community drive let me know. I'm pretty new to this but it feels very fragmented for now.

And of course if you have any time to have a look at the project I was talking about I would love to have some feedbacks. I'm at that point where it's seems like a very good idea but also that I must be missing something huge!

Thanks again :)

[ff6347]

And of course if you have any time to have a look at the project I was talking about I would love to have some feedbacks. I'm at that point where it's seems like a very good idea but also that I must be missing something huge!

I'm so old school I did not yet dive into CEP. :-)

If you need any help with any of the ongoing efforts to create some community drive let me know. I'm pretty new to this but it feels very fragmented for now.

I can add you to this org if you like. But there is not a lot going on right now. The most active member is @GitBruno currently

[ff6347]

@bigarobas you should see an invite here https://github.com/ExtendScript

[bigarobas]

I'm IN :)

I'm such a newbie I don't even know what was before CEP ^^

[bigarobas]

@fabianmoronzirfas I started to have pretty interesting feedbacks especially on Adobe Devs Slack channel. thanks again :)

[ff6347]

Cool