Wrap Dialog API?

[ff6347]

Would be a lot of work but might be useful. See http://yearbook.github.io/esdocs/#/InDesign/Dialog

[trych]

What exactly do you mean? Offer commands in basil.js to build dialogs and UI?

[ff6347]

Yes. It might be nice to have an easy way to create dialogs without the whole hassle of defining rows and columns. The idea is from an e-mail conversation with Marius. It is some work so nothing to do right away but it could be nice to have more interaction possibilities then alert, prompt and confirm. There is for example a integer input box which parses the value before submitting it to a variable. So there would be no need for pre-checking value types and parsing strings to numbers.

[b-g]

A long time ago @frederickk investigated and implemented a few very nice UI wrappers in basil style. I think there were a few nasty bugs on indesign end which prevented that we actually included it in the end.

@frederickk Longtime! :) Hope al is going well in SF? Could you give us some hints or maybe share your last code? We might be able to recycle a few "unproblematic" cases. Cheers! All the best, Benedikt

[ff6347]

We should NOT touch the script ui stuff. Just the dialogs I would say.

[frederickk]

Hey Benedikt! Sad I missed you in SF, next time you're in town let's meetup.

As for the UI wrapper you can find the latest code for ui wrapper (ui.js) within the "ui-beta" branch of my basil.js fork.

You'll see at the top of the file a list of TODO's I intend to resolve. However, the biggest problem (which @b-g alluded to) is I am unable to fully clear variables within the #targetengine.

You'll see a slew of examples to understand how it works. I'm happy to pick-up the torch again and continue to revise this ui implementation, especially if @fabianmoronzirfas has any insight on how to fully clear the #targetengine.

[ff6347]

Edit: Ups Sorry I've been logged in into a legacy account.
Hi @kenfrederick. Wow you did write a lot of code that never made it into Basil at all. After a quick search I found posts like this one from 2013 https://forums.adobe.com/thread/1242009 where hey suggest deleting all references and then calling the $.gc() (twice). I remember trying to port a project from InDesign dialogs to ScriptUI but then abandoned it because it was such a pain. I then went for ExtensionBuilder which got deprecated a year or two ago (after beeing broken for along time as well) and now I'm sneaking around HTML5 panels but never got the guts to start using it because of the painful development process and the awful gap between ES5 frontend and Extendscript backend. I used a lot of ScriptUI in AE but there it works way better then in ID but is also deprecated.

If you read between the lines you you get my next point. :-)

I actually would not go for ScriptUI. It has several different bugs in different versions of InDesign and is marked as deprecated by Adobe. it could be that it will disappear in the future. I would go for the basic InDesign Dialogs. They are robust and work pretty well. Yes they are blocking the execution thread but most of the time we want some input from the user and then go on with the execution. They also have a relatively easy row and column layout system.

[b-g]

Hi @frederickk, Many thanks for the links/invite! Very cool to revisit this nice code from the past! :) Will ping next time I'm in SF, for sure! All the best, Benedikt

[frederickk]

@fabianmoronzirfas I was chatting a bit with @b-g about contributing to Basil.js 2.0, specifically updating my UI implementation to work with latest 'develop' branch. Once, I've gotten re-oriented with my code I'll look into your suggestions to abandon ScriptUI.

[ff6347]

Sounds great 👍🏽

[trych]

@frederickk Just a heads up, although I have no idea if this issue is still relevant once you abandon ScriptUI, but the clearing of the basil variables from targetengine is basically already implemented into the new develop branch, as we needed it for the new b-less style anyways.

[b-g]

@frederickk
Would be super! Welcome back!

As a lot of things have changed under the hood ... I would recommend to really base every new feature/contribution on the current 'develop' branch (and rather copy any old code into it and not 'merge' the other way around).

[frederickk]

@b-g yeah, I did a quick diff and saw the plethora of changes and did exactly as you suggested.

@trych Excellent! I'll see if the current implementation of the UI branch works in regards to the targetengine issue

Stay tuned.