This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-10-15
Channels
- # announcements (1)
- # babashka (81)
- # beginners (48)
- # calva (49)
- # clj-kondo (52)
- # cljdoc (7)
- # cljs-dev (39)
- # clojure (33)
- # clojure-australia (18)
- # clojure-europe (48)
- # clojure-italy (2)
- # clojure-morsels (2)
- # clojure-nl (3)
- # clojure-uk (6)
- # clojurescript (5)
- # community-development (2)
- # conjure (6)
- # cursive (3)
- # data-science (29)
- # datalog (4)
- # datomic (14)
- # events (1)
- # fulcro (1)
- # graphql (18)
- # gratitude (2)
- # helix (11)
- # introduce-yourself (2)
- # java (15)
- # keyboards (2)
- # lsp (6)
- # luminus (4)
- # membrane (32)
- # minecraft (1)
- # missionary (7)
- # nextjournal (2)
- # off-topic (28)
- # portal (28)
- # releases (1)
- # ring (1)
- # shadow-cljs (3)
- # sql (6)
- # xtdb (23)
Do you think there can be a benefit to abstract the representation of coordinates to types and protocols, instead of tying it to the vector representation?
there definitely might be. One thing I've realized is that a lot of the stuff in membrane.ui
assumes floating point coordinates, but some UIs like terminal have integer coordinate systems
related, I think it would be better to have the ui model be more firmly grounded on 2d geometry
well, for 2d UI anyway. Obviously, 3d geometry is important if you're making a 3d UI.
User interfaces in 3d (usually games) do a much better job of having a stronger mathematical basis since not having a strong theoretical foundation will bring you down much quicker when you're doing 3d
One of the things I'm interested in when I get the chance is to 1. try a new UI model, 2. extend the current UI model to work under the new model I think it can be done without breaking any existing code which, if true, would prove some of the strengths of clojure's default modeling constructs.
When I say "ui model", I mean is a few things:
• descriptions of what to draw like fills, strokes, paths, images, and text. Fills and strokes are currently a bit clunky. Text is definitely an area that could be simplified and expanded.
• descriptions for events. there's a few places where behavior is coupled that can be simplified and broken down further.
• common abstractions like ui/bounds
and ui/origin
that events and layout are based on. (`ui/bounds` is currently overloaded and should probably be broken into things like hit detection, pixel extents, framing for layout, etc). There should probably be even more common abstractions.
Having said that, the reason I haven't yet is that the current UI model works well enough to test the other ideas I have. Even with some of the weaknesses, it feels much better to me than html/css, but I'm probably a bit biased 😄.
I've never done ui work, myself, but just going by what you said in talks and docs, it looks like you also want a geometry abstraction layer
It has two benefits, one is that you finally get to talk about geometry (just data), second is if it ever gets computationally expensive the abstraction boundary gives you room to optimize
(defui item-row
[{:keys [time type descendants title kids id score url by expanded?]}]
(on
:mouse-down
(fn [_] [[:update $expanded? not]])
;; put the items side by side
(horizontal-layout
(translate 5 5 (ui/checkbox $expanded?))
(spacer 5 0)
(vertical-layout
(horizontal-layout
(spacer 5 0)
(ui/label score)
(spacer 10 0)
(basic/button {:text title :on-click (fn [] [[::load-url url]])}))
(horizontal-layout
(spacer 5 0)
(ui/label (str "By: " by))
(spacer 5 0)
(ui/label (str "At: " (str (java.time.Instant/ofEpochSecond time))))
(spacer 5 0)
(basic/button {:text (str "Comments: " (count kids))
:on-click (fn [] [[::load-comments kids]])})
)))))
looks great
Here, a little more sensible
(defui story-item
[{:keys [time type descendants title kids id score url by expanded?]}]
(horizontal-layout
;; (translate 5 5 (ui/checkbox $expanded?))
(spacer 5 0)
(vertical-layout
(horizontal-layout
(spacer 5 0)
(ui/label score)
(spacer 10 0)
(basic/button {:text title :on-click (fn [] [[::load-url url]])}))
(horizontal-layout
(spacer 5 0)
(ui/label (str "By: " by))
(spacer 5 0)
(ui/label (str "At: " (str (java.time.Instant/ofEpochSecond time))))
(spacer 5 0)
(basic/button {:text (str "Comments: " (count kids))
:on-click (fn [] [[::load-comments kids]])})
))))
for the checkbox, you can do (basic/checkbox {:checked? expanded?})
and it should "bind" expanded?
to the checked value
everything in membrane.ui
is stateless.
This should probably render the comments:
(defui comment-item
[{:keys [by text time kids]}]
(vertical-layout
(horizontal-layout
(spacer 5 0)
(ui/label text))
(horizontal-layout
(spacer 5 0)
(label-by by)
(spacer 5 0)
(label-at time))
(when kids
(horizontal-layout
(spacer 5 0)
(apply
vertical-layout
(mapv comment-item kids))))))
Also thinking text element components could be useful, esp when translating to web.
(text foo (paragraph bar) bazz)
, etc
yea, trying to do everything with just ui/label
isn't great
text is pretty painful to deal with so I've been putting off trying to figure out the right API for that. It's also pretty complicated with kerning, letter spacing, line height, bounding boxes, fonts, style, emoji, wrapping, aligning (baseline, center, vertical)
also there's markup like bold/italic, underlining, color, etc
On one hand, yeah, on the other, surrounding it with "constructors" lets you do plenty of calculations and formatting That's before getting in to efficient text editing data structures
> That's before getting in to efficient text editing data structures There's actually already a pretty good library for that https://github.com/mogenslund/liquid/blob/master/src/liq/buffer.cljc
my understanding was that ropes don't allow for markup
yea, I think there's definitely an 80/20 featureset that can be done without https://en.wikipedia.org/wiki/TeX making the perfect text library