What would Enaml 2.0 look like?

[sccolbert]

Hi Everyone!

I've been thinking lately that it might be time for me to devote some real effort into an Enaml version "2.0". I'd like some feedback from the community about that should look like.

Here some of my ideas to get us started. Please treat this as an open discussion: give your own ideas, comment on mine, tell us what you love/hate etc.

• I have no problem with making breaking changes for a version 2.0, but I think the overall user-api (not dev-api) should be similar enough.
• Grammar changes to make the templating system more flexible/usable.
• Full use of Python 3 type hinting.
• Remove the toolkit agnostic backend system. We don't support multiple backends right now anyway, although some in the community have made their own. We can do a lot better with everything if focus on a single toolkit. What should that backend be? Qt? Web? Skia? Our own custom native implementation?
• Add a hi-perf table/grid widget. I already built one of these to 80% full-feature for PhosphorJS, the port would be pretty easy. https://phosphorjs.github.io/examples/datagrid/
• Add dedicated high-perf data-driven controls.
• Add a high quality editor control.
• Keep or drop constraint layouts? Matplotlib uses kiwisolver, but that doesnt mean Enaml has to continue that trend. Especially if we switch to a web backend, it would be easier to target "abstract" layouts which could be translated to CSS.
• Licensing. Free for non-commercial use? It will be significant effort to do all of this, and I would need to monetize that somehow. If I could charge for commercial use of Enaml, then I could employ myself and/or others (like Mathieu?) to dedicate real time to the project.

[MatthieuDartiailh]

Here are some opinions:

* Grammar changes to make the templating system more flexible/usable.

Not sure what you have in mind, but yes ! I never found a case where I had enough flexibility and always ended doing thing much more manually.

* Full use of Python 3 type hinting.

Do you mean in the code base or in enaml files ? The code base could sure use type hints. Enaml files should support those since we properly parse them.

* Remove the toolkit agnostic backend system. We don't support multiple backends right now anyway, although some in the community have made their own. We can do a lot better with everything if focus on a single toolkit. What should that backend be? Qt? Web? Skia? Our own custom native implementation?

We never had multiple backend using a truly unified interface yes. However the ability to "easily" re-use the framework to build a backend using a different technology has been used (and I know of at least one bank that uses enaml-web). So I wish that capability could remain.

* Add a hi-perf table/grid widget. I already built one of these to 80% full-feature for PhosphorJS, the port would be pretty easy. [https://phosphorjs.github.io/examples/datagrid/](url)

Yes this has been really missing. In my own project I also had use for a tree view. Not sure if it would fit here so.

* Add dedicated high-perf data-driven controls.

Could expand a bit more ?

* Add a high quality editor control.

Could you add some details ? One thing that we should try to improve is support for editors (syntax highlighting, language server, etc), and tools (formatter, linter). This would require a better parser. Maybe inspired/forked from ruff.

* Keep or drop constraint layouts? Matplotlib uses kiwisolver, but that doesnt mean Enaml has to continue that trend. Especially if we switch to a web backend, it would be easier to target "abstract" layouts which could be translated to CSS.

I do not have a particular opinion here TBH.

[youpsla]

Amazing. I'm just an enaml-web user and would be sad if agnostic support is dropped except if the choosen one is web.