5 ms·
A big improvement over CSS, but still seems pretty manual and finnicky, I wonder if a constraint solver based system and syntax would be ideal for laying out UI
by pistoleer 2y ago
A big improvement over CSS, but still seems pretty manual and finnicky, I wonder if a constraint solver based system and syntax would be ideal for laying out UI.
For instance, being able to set the constraint "element.[x,y] = other.[x,y]+other.[width,height]/2;", instead of working with "attachment" objects.
- loa_in_ 2y agoI think there already are existing mature solutions like you described. Isn't QT constraint based?
- 1oooqooq 2y agoqt lost it's golden momentum taking way too long to relax licensing in the 90s. had they done it before the gtk shift the world would be very different. btw, gtk is based on tcl/tk which i believe is the, or one of the, original auto layout engines
- nine_k 2y agoQt is C++, while GTK is pure C. These are very different languages, and exposing a C interface for C++ code as rich and complicated as Qt is not easy.
- adastra22 2y agoAd yet TFA is kinda an example of that, no?
- nine_k 2y agoQt without slots and signals is a poorer experience. IDK if the Qt Designer can work without them.
- PaulDavisThe1st 2y agoGTK provides slots and signals, through an admittedly baroque C-level implementation. Pretty easy to use, but try not to open the hood.
- PaulDavisThe1st 2y agoGTK has no relationship to tcl/tk whatsoever.
- 1oooqooq 2y agoi see. always felt gtk layout experience similar. but i have much more exposure to tcl/tk than proper gtk.
- speps 2y agoLook up "cassowary" layout algorithm and all of its implementations.
- airstrike 2y agoThank you for this! If you or any one else has any other literature to recommend, I'm all ears!
- PaulDavisThe1st 2y agothe algorithm is cool but it does not scale well. it's awesome for small things (like mobile-style app GUIs), but not usable for full-scale desktop apps (e.g. a DAW).
- kragen 2y agowhen you say 'does not scale well', are you talking about the algorithm's performance or about some kind of maintainability concern?
- jacobp100 2y agoMaintainability. Think about having a list. You add constraints between all the rows etc. then remove a row in the middle. Now you have to update all the constraints
- kragen 2y agoi think that in cassowary that involves removing roughly one constraint for each thing on the row, then adding a new constraint for the newly adjacent rows? then because it uses an incremental solver it can reuse the part of the previous solution for the rows above the deleted row, just recomputing the positions of the rows below but that's a question of performance. 'maintainability' would be removing the code that adds the row to the list, which is trivial with cassowary
- 2y ago
- pavlov 2y agoApple adopted such a constraint-based system about 10 years ago in iOS and macOS. It's called Auto Layout. It's powerful but not trivial to adopt. In particular, the design experience in Interface Builder has gone backwards in usability. The old system of resizing rules visualized as "springs and struts" was easier to understand in a visual design tool. One might argue that's the cost of progress, and that designers using Interface Builder become better UI engineers when they have to figure out how to express themselves in constraints. But it seems to me that the reality is that a lot of people just stopped using IB. IB used to be a crown jewel of NeXT's development suite in the 1990s. It was simple and focused, and allowed you to build surprisingly powerful UIs that connected to high-performance native code (unlike its mainstream competitor Visual Basic). I don't think a lot of people have such fond feelings about Apple's current IB. Something was lost along the way.
- pistoleer 2y agoI sense a parallel between that and the dropoff of SQL over lossy and impedance mismatched but "easy" ORMs and document stores. People don't realize they're trying to have their cake and eat it too maybe? I wonder how we can stimulate "expert" tools and systems for those who don't want to take the greedy path of least resistance, and are tired of painting themselves into corners that way.
- bckr 2y agoStimulate? Or simulate? My learning path went something like this: (The dark ages of data processing for personal use) - Use a text file: Fine, you have to write your own read & write logic, but for small amounts of data this works. - Use a CSV file: less custom logic than plaintext - Use a JSON file: really nice to have structured data! - Use a Python pickle file: the idea is you can “pick up where you left off”, but it’s slow, clunky, and inflexible (Finally learning to use a database) - Use Google Sheets: oh, it’s nice to be able to index things without needing to read/write the entire dataset! You can also do searches and stuff, it’s great. - Django ORM + MongoDB: Oh my god, so horrible. MongoDB was supposed to be simple. This set up was slow and complicated. Migrations were a constant pain. And we didn’t even have any users. - Postgres: It all makes sense. SQL is great. You can think about and query your data in reasonable ways. And it’s fast. - DynamoDB: Yeah whatever, as long as you do validation on every read/write you’ll probably be fine.
- danielvaughn 2y agoI'd been working on a similar syntax for a while, mostly was inspired by some work I did in iOS back in 2015/2016. They used a constraint system and it's honestly pretty great, though some of the more complex features can be daunting. I'd love something like this: red-box { width: 100 height: 100 top: 10 left: 10 } blue-box { width: 50 height: 50 top: $red-box.bottom * 2 left: $red-box.right + 100 }
- pistoleer 2y agoYes, that's exactly what I'm talking about!
- danielvaughn 2y agoYeah it would be nice if it felt like saying "this goes here, that goes there." I wanted it to mirror how someone might verbally speak about layout. It gets harder when you consider multi-dimensional layouts like grids, but for 1D things like headers or lists, it would significantly reduce complexity.
- graypegg 2y agoI think CSS's own internal logic prevents this sort of syntax from working, since you could be talking about any element matching `red-box`. There's no good way to refer to a specific match of a selector, unless you enforce that the selector only selects 1 thing, even then, that would be conceptually hard to deal with. I think flexbox and grid handle a good chunk of what you'd want here, but having to handle constraints at the "group" level. Either flexbox, so the browser finds the best way to place elements into a line based on your rules, or grid for 2 dimensions: boxes { display: grid; /* there are only 2 columns, 100px each */ grid-template-columns: 100px 100px; /* all rows are 100px tall */ grid-auto-rows: 100px; > * { /* All children take up 1 col, and 1 row */ grid-column-end: span 1; grid-row-end: span 1; } } blue-box { /* blue-box must start at col #2 and row #2 */ grid-column-start: 2; grid-row-start: 2; }
- 2y ago