Make it all configurable.

[jperon]

This is quite a big change. The idea came from @paulfitz’ message: with this one, it would be possible to create standalone widgets from the code of a "personalized" one.

With that, the name pug_py doesn’t say all it does: it’s now starting from a configuration, that will define an entrypoint (for example a pug or a py code) and possibly other editors.

Another change is that it now uses RapydScript instead of Transcrypt or Brython (or PyScript that I tested too), as it’s far easier to interact with js. The only caveat I saw is that, for functions which really expect a pure Array (like grist.docApi.applyUserActions), it’s necessary to call the Array constructor, or to convert a python list with Array.from(LIST).

[jperon]

I had tested in my self-hosted instance, where the widgets are hosted in the same domain as Grist itself. Now I’m facing cross-origin problems while hosting at docs.getgrist.com. Perhaps I’ll have to go back to Brython…
@berhalak if you had time (but I don’t want to abuse), would you mind looking at this and, if possible, explain me what I’m doing wrong?

[jperon]

@berhalak Never mind, I ended finding the problem. It came from RapydScript, which builds an iframe, but which used, to pass messages between the iframe and its parent, a "pythonesque" equality. This one used an __eq__ property, and its access was forbidden because of CORS.

[jperon]

So here is a very basic showcase, featuring a customizable Markdown widget.

[jperon]

And here is a new version of the Kanban widget, which could very easily be put into its own repository, and whose configuration is more straight forward than the previous one.

[berhalak]

Sorry for the delay @jperon, it was busy week for me.

[jperon]

@berhalak Is there anything to do on my side, please? No hurry, but I’d like to have this merged before proposing widgets based on it if possible.
Many thanks!

[paulfitz]

@jperon currently @berhalak is on vacation. In any case, I'm not sure it is practical to review this PR in its current form, it is so large. I understand a lot of the files are copies of material from elsewhere, but they'd still need to be read for Grist Labs to sign off on their content.

I'm happy to say we are finally going to make progress on having a way to mark custom widget's as "community written" or something similar. As long as we have a way to let the user know who they are trusting when they use a widget, we can start decentralizing a little bit. The new way to mark a widget is slated to be done by the end of July, and may happen earlier.

Very sorry this bottleneck has dragged on so long...

[berhalak]

Suggested change

	[[widget.codes]]
	# You may define various editors below. There must be at least cfg and the entrypoint.

[berhalak]

Looks nice. One question about files in /js folders, I see jkanban and toastui* files. I think they are not needed?

[jperon]

Looks nice. One question about files in /js folders, I see jkanban and toastui* files. I think they are not needed?

The reason I left them there is that I intended to make this widget suitable for offline use. It can’t integrate the whole js libs world, for sure… but those ones looked to me as a reasonable bundle for quite common needs in a custom widget.

[jperon]

Sorry, related to jperon/kanban#1, I realized that I had uncommitted local changes… I had to rebase and force-push, so I think a "squash&merge" will be necessary to keep history clean.

[paulfitz]

The reason I left them there is that I intended to make this widget suitable for offline use. It can’t integrate the whole js libs world, for sure… but those ones looked to me as a reasonable bundle for quite common needs in a custom widget.

We do have a bundling mechanism for widgets that can pull in external dependencies. We use it to make the calendar widget (developed as a custom widget) available offline in Grist Desktop.