Declarative GUI with constraints-based layout engine for Python
github.com
github.com
Second, since it is just a set of equations, it allows to create higher-level design languages like “a remark below that input, same width and x” or automagic “every element has right-margin of min:20px to the edge”, which allows any dynamically created row to function without poisoning all elements with specifically located paddings/margins/etc. Tables and boxing always forces you to think in terms of their clumsy and situational size request/allocation process, which is usually too complex to reason about without an experiment.
That said, I have yet to see a constraints library which is powerful enough to do all the modern ui yadda yadda.
This would move web design to be a lot more like many other design tasks. Even if something parametric goes into designing type faces, as an example, on build, that is all gone.
I highly encourage taking a look at it and it has also been ported to a wide range of language.
I’m using Nim kiwi with my own GUI library now. I’ll have to take a peak at how enaml is using kiwi for its layouts.
https://kiwisolver.readthedocs.io/en/latest/
https://github.com/alexbirkett/kiwi-java
Personally I've been writing a CSS Grid implementation because I find the "Grid" (aka Table) to provide most of what I want: https://github.com/elcritch/cssgrid/blob/main/tests/tlayout....
Though I was running into issues when trying to add `min/max/minmax` functions with fracs, as they end up creating a constraints equation. It seems CSS Grid just gives up if you specify anything that'd require a constraint solver. At least on Chrome & Safari. Fair enough but I figure I'll add at least a 1-pass try for doing `minmax(1fr, 100px)` type of things.
Also, what kind of licensing would these apps be under?
I've seen this kind of GUI in programs that manage complicated hardware such as scientific instrumentation.
The reason is that Treeview is where a lot of "rubber meets the road". It scrolls. It has icons that likely change state. It has active widgets. It may have a LOT of widgets and be a good test of performance. It has text and all of the idiocy that entails. It may or may not have selection. It has a connection to backing data.
So, you get a nice microcosm of how you should plumb together the components of the UI toolkit if you look at the Treeview implementation.
However, I would like to provide the contrarian position, as well. I find that far too many people use Treeview as a substitute for actual design. I often find that the TreeView really should be something else--a config file, a table interface (table interfaces are really underused in GUI design given how many of your users are wedded to Excel for business things), etc. Everything doesn't need to be pointy-clicky and often throwing things out improves your GUI.
Treeviews tend to be the laziest of options--and, as we all know, programmers are very lazy.
Like anything coming close to AntD’s table tells me that it’s serious business.
You just had to drag-and-drop a control on the form. Handling events was just as easy. In the dialog editor you could association a standard event (like mouse or keyboard events) with a python function.
If you really wanted to, you could edit the event code because it was all just dictionaries, but you didn't need to.
For all the shit that Electron gets, it is reliably cross-platform with relatively little effort.
Check out the cool / weird DSL though!
As far as using it goes... It was alright. Very very fast to set something up, but has the usual "many things are now easy, but some things are now impossible" problem that many other frameworks introduce.
Last year, I finally got a chance to try things out, using Kiwi via C++.
The results, frankly, were underwhelming, at least for my purposes. It seemed that for most of what I wanted to be able to do, a "table" layout was more appropriate and provided more than enough flexibility. Creating layouts that do not in some sense use columns and rows is not unheard of, but it's rare.
But they usually don’t. It doesn’t mean that constraint-based layout lacks flexibility. Only specific engines do, but so do specific table engines. It’s easy to forget that css also sucked for 20 years straight, and still does, if you dig an inch deeper than usual. E.g. grid is cool, but did anyone try to page-break it in media print? Can we baseline—align divs & inputs that are not direct children of a flexbox? Not to mention internalized bugs like when your grid gets a parasite scroll when its scrollable child has large padding specified in particular units.
All that said, I think the best toolkit is the one which contains all of the tools and not only a subset.
They really need to make a GUI library with a default style that just makes it look really good. Instead I see defaults that are terrible across 99% of all gui libraries.
imgui is the exception here, but the defaults for imgui are very stylized.
[1] https://enaml.readthedocs.io/en/latest/get_started/installat... [2] https://github.com/spyder-ide/qtpy