@flyboarder I'm psyched for the project. I'm impressed with how seamless the Firebase + Hoplon cell experience is. It is nice to work with cells as usual, and be able see the data update in the Firebase console. Gives me some confidence with client/server stuff as I'm just dipping in. But I want to grow with a stack that has a lot of reach (Hoplon-based obviously 😃 ) I like that there is a desktop client story. I am also inspired by Nightcode and Klipse for distributing Clj compute into different (cloud) user-interfaces, and Eve for promising to remove ever more incidental complexity. As much as I am inspired and compelled by Clojure, I've been been cut with a lot of sharp edges on my slow ramp up. I see tons of room for bespoke graphical UI's for composable domain-specific computing to continue to evolve (admission: I started out in webdev on Dreamweaver). I think everyone around here gets it. There's been intermittent chatter about building cell editors/visualizers, etc as long as I've been following. As much as Clj is for engineer wizards, Hoplon is for visual designers. Designers want to design with bespoke composable design-systems. And those systems can benefit from bespoke editor-apps to compose design, visualize feedback, and facilitate flow. Making those editor-apps real-time-sync (like Crepl (http://thegeez.net/2017/02/03/crepl_collaborative_editor.html)) lets designers compose together. And those editor-apps can be built with Hoplon (and Meta!). Thx everybody for the inspiration! :end-rant

@onetom @alandipert Powerful! In-between arbitrary code and a contrained WYSIWYG dsl editor. Why did this style never take hold? Didn't Smalltalk do this first (putting code in a db)?

@chromalchemy have you played around with adobe's new xd?

it's only for prototyping, and still rough around the edges, but has a focus on composable designs

stops short of full parameterised data but has support for something similar to for-tpl and composable "symbols"

FWIW: I deleted my previous post/question but the solution for making hoplon lib is (hoplon :manifest true)

@jumblerg been trying to track down the issues with my font problem. So I basically have

(def sans-serif-strong (attrs/font :generic :sans-serif [:normal :700 :regular]))

(window
 (elem :sh (r 1 1)
       :tf sans-serif-strong
       "foo"))

(h/style (cell= (font-face [id] (get-in family [:normal :400 :regular]))))

I know this stuff is very much a WIP but this is in the current snapshot as well, just trying to figure out if I'm doing something wrong

So basically, in ui.cljs there's this code

(h/for-tpl [[id family] +fonts+]
              (h/style (cell= (font-face [id] (get-in family [:normal :400 :regular]))))

and with my above example, +fonts+ is {font-6 {:normal {:700 {:regular {:generic :sans-serif}}}}}

family is {:normal {:700 {:regular {:generic :sans-serif}}}}

the get-in evaluates to nil

so the result of the font-face call is @font-face{font-family:font-6;}

oh ft in my example should be :tf (fixed this with an edit)

i'll take a look at it now.

there's a little bit of extra machinery there because i was preserving the option to populate our own explicit registry of fonts rather than the one backed by the browser.

gotcha yeah i've been starting to grasp what you're going for 🙂 seems cool just haven't been able to get it to work so far

the way fonts currently work, as i'm sure you're well now aware after stepping through the code, is that the width, weight, and slope are attributes of the font placed in the variable when you construct it. in many cases, a file will only have that one font in it, so you're all set. in others, there might be an entire font-family, so you can specify that "path" to extract the specific font you want from the file or the font by its name on the host machine.

i was also working on an unfinished scheme, however, that would allow an explicit registry of fonts to be populated by font constructors, so exceptions could be thrown when a text property tried to access a font with certain properties that wasn't there.

this was to support things like markdown, or perhaps rich text, where content might request a bold, italicized version of a specific font at runtime.

my thinking has shifted since, and my plan is to differentiate between text italics (maybe :ti) and text boldness (maybe :tb) versus font slope and font weight, which are more granular.