This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-12-19
Channels
- # adventofcode (52)
- # babashka (47)
- # beginners (13)
- # clojure (36)
- # clojure-belgium (1)
- # clojure-europe (14)
- # clojure-nl (1)
- # clojure-norway (14)
- # clojurescript (2)
- # clojutre (9)
- # cursive (12)
- # datomic (3)
- # deps-new (3)
- # emacs (12)
- # fulcro (5)
- # guix (1)
- # honeysql (7)
- # introduce-yourself (1)
- # jobs (1)
- # kaocha (8)
- # lsp (5)
- # membrane (5)
- # mount (7)
- # nbb (5)
- # nrepl (2)
- # off-topic (60)
- # polylith (9)
- # reclojure (2)
- # reitit (8)
- # ring (17)
- # shadow-cljs (4)
- # spacemacs (31)
- # sql (7)
- # timbre (3)
- # xtdb (15)
Am I correct in saying there isn't a way to specify element shadows in the membrane UI model?
Follow up question, mostly out of curiousity: if someone were to provide an additional membrane element type in a library, would you expect that the library would include an implementation for IDraw
for all of the built-in membrane backends?
It's open data model so anyone can add a way to specify element shadows, but there's no builtin at the moment.
> Follow up question, mostly out of curiousity: if someone were to provide an additional membrane element type in a library, would you expect that the library would include an implementation for IDraw
for all of the built-in membrane backends?
I definitely wouldn't expect libraries to include implementations for all of the membrane backends. It depends on the library's goals, but I think it's completely valid to have a library with just a single IDraw
implementation (or in some cases, zero IDraw
implementations).
Obviously, it's also fine to go ham and provide IDraw
implementations for all the backends and even invent some new ones.
For posterity, I'm assuming you meant to type "but there's nothing builtin at the moment"
whoops. Yes, that's correct.