[HN Gopher] Declarative GUI with constraints-based layout engine...
___________________________________________________________________
Declarative GUI with constraints-based layout engine for Python
Author : ducktective
Score : 93 points
Date : 2022-09-11 12:50 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| criddell wrote:
| Back around 2002 or so, I used to use PythonCard for in-house
| tools. PythonCard was a kind of a cross between HyperCard and
| Visual Basic and used wxWidgets for the UI elements. It was
| really excellent software.
| elcritch wrote:
| What's the distinctive part that made PythonCard useful?
| fayten wrote:
| Nucleic also makes Kiwi one of the fastest Cassowary Constraint
| implementations. It is very useful for implementing custom GUIs
| as it can make building internal component layouts and general
| layout systems fairly straightforward and it's very performant.
|
| 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
|
| https://github.com/PongoEngine/jasper
|
| https://github.com/yglukhov/kiwi
| elcritch wrote:
| I looked at the first Employee example in Nucleic but didn't
| see anything that struck me. Actually I didn't see a way to
| adjust layout at all. What am I missing? Without reading the
| paper, what is Cassowary Constraints solving for? I'd guess a
| bin packing implementing, which could be handy for graph
| networks come to think of it.
|
| 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.
| elwebmaster wrote:
| Why no HTML? Web is so big nowadays if it could render to HTML
| the platform coverage will be parallel to none.
| polotics wrote:
| As I always do when yet another UI option comes along, I went
| looking for a hierarchical "tree" view widget in the
| documentation. Could not find it.
| bismuthcrystal wrote:
| What are the implications, good or bad, of such absence?
| bsder wrote:
| It's often a bad implication.
|
| 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.
| analog31 wrote:
| Not the parent, but a tree view is convenient for an app that
| has a lot of settings. For instance you can take a dictionary
| of settings and create a tree view with the same structure.
| If a setting gets added later, you don't need to rearrange
| the GUI, it rearranges itself.
|
| I've seen this kind of GUI in programs that manage
| complicated hardware such as scientific instrumentation.
| cwilkes wrote:
| Interesting, it looks like a new implementation of
| https://en.wikipedia.org/wiki/Naked_objects from back in 2002
| era.
| deltasevennine wrote:
| Looks cool. One overall criticism for GUI libraries though (not
| just this one):
|
| 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.
| [deleted]
| luvz2code wrote:
| Is there anything similar for generating html/react UI's ?
| mhuffman wrote:
| You can use python with Electron ... with all that Electron
| implies.
| pen2l wrote:
| You can contain your native react creations in electron if you
| really don't want to go the native GUI kits route.
|
| For all the shit that Electron gets, it is reliably cross-
| platform with relatively little effort.
| hiptobecubic wrote:
| I was just thinking we used traits and enaml quite a lot in the
| scientific Python community and didn't realize that's what this
| was pointing to.
|
| 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.
| rcarmo wrote:
| This seems to be active, but I'm curious as to how small the apps
| can be given the Qt dependency (and the usual penchant for
| packaging a small Python runtime on cross-platform installs).
|
| Also, what kind of licensing would these apps be under?
| Existenceblinks wrote:
| Feel like the constraints-based layout is not the right design of
| constraints. I don't know if there is any research on type based
| (constraints) layout. How to type flex layout in composable way,
| could use some vector (matrix), and knapsack kind of algorithm. A
| child component spec should have some layout constraints to
| conform.
| PaulDavisThe1st wrote:
| I have been very excited about constraint-based layout for
| about 20 years, after seeing a demo of an music app at a
| conference in Bordeaux. It used the original Cassowary
| implementation.
|
| 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.
| Existenceblinks wrote:
| Yeah, I were obsessed a long time ago. It doesn't have to be
| automatic. Start from what we have in css, there's media
| query. Looking good on desktop/laptop/mobile seems like
| special case. So generally we might look for semantic that
| scales e.g. ratio, open height, open width, .. idk I don't
| figure it out yet, it's like a greenfield area where previous
| solution doesn't look like revolutionary.
| taeric wrote:
| I'll echo this. It sounds compelling to make a constraint
| based layout, but often you are just as well off with a very
| simple grid. And not a whole lot of components in a page.
| hermitcrab wrote:
| Qt 5 (which this seems to be based on) is getting quite old now.
| [deleted]
___________________________________________________________________
(page generated 2022-09-11 23:00 UTC)