This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-06
Channels
- # aleph (79)
- # bangalore-clj (3)
- # beginners (49)
- # boot (74)
- # cider (10)
- # cljs-dev (21)
- # cljsrn (2)
- # clojure (105)
- # clojure-berlin (1)
- # clojure-brasil (1)
- # clojure-dusseldorf (1)
- # clojure-korea (1)
- # clojure-poland (3)
- # clojure-russia (38)
- # clojure-spec (146)
- # clojure-uk (20)
- # clojurescript (70)
- # cloverage (1)
- # component (1)
- # core-async (23)
- # css (16)
- # cursive (22)
- # datascript (1)
- # datomic (22)
- # defnpodcast (6)
- # emacs (60)
- # events (1)
- # hoplon (94)
- # jobs (1)
- # jobs-rus (13)
- # luminus (11)
- # off-topic (11)
- # om (48)
- # onyx (5)
- # proton (7)
- # re-frame (87)
- # reagent (39)
- # rethinkdb (1)
- # ring-swagger (14)
- # rum (6)
- # specter (14)
- # untangled (105)
- # vim (6)
- # yada (22)
@jumblerg are buttons supposed to work on ui? Every time I try and add one, like it shows at the bottom of the test file, it just makes my whole page blank
@vigilancetech I've used buttons with ui with no issue for what it's worth. Can you provide a sample of the code that's not working?
@jjttjj Well, unless I actually go right in to the ui-test.cljs and edit that, I get this error: adzerk.boot_cljs.util.proxy$java.lang.Throwable$ff19274a: Unsupported binding key: :sh
But there are numerous examples of buttons at the bottom of that file, and I tried incorporating them into very simple elements and even though I could get images and words to render, as soon as I added a button, poof blank page
@vigilancetech oh wait my mistake, I was actually using hoplon.ui/submit not button. it seems there is no longer a button element
but let me try and get a (window...) constructor together to illustrate
What about including other widgets? Or will it only support those that have been ui "wrapped?"
it's probably from an older version. I know they changed a lot of things fast and the api isn't really stable
well, like sliders, gages, etc...?
i'm definitely not an expert, just been playing around with ui for a few weeks, but my understanding is you build them all from raw elems
so like using the google closure library widgets will work? Cuz I think "button" is one of those
UI seems pretty experimental, i think it kind of assumes a full buy in to its philosophy for all user interface stuff. Though there may be no reason you couldn't get it to work with other widget systems
so if you need something that looks like a button, you make an elem with the appropriate colors, borders, shadow, etc
do you have a github repo of some ui stuff you've done that works?
so maybe I can get rid of that other error and start from scratch?
just something simple
unfortunately nothing public at the moment but maybe soon I'll try to put something out there
I randomly found on github some of jumberg's code using it, which was useful to me: https://github.com/jumblerg/computable-law/blob/master/src/human-dynamics/computeable-law.cljs
oh, nice, thanks, I'll check it out!
i think i had difficulties getting the page to actually run out of the box, (again, the ui api has changed really fast) but it was useful as code to look at
ok, well, I'll try.
the general idea is to forget everything you know about html and css. you're making all your own elements from now, using the attributes UI provides to describe how they should look
there are edge cases that ui is forced to deal with. like you can't use :p
, :g
, :sh
, etc to make an image show up on a page. so the library deals with these cases, but there aren't too many
ok, and one should be able to encapsulate many widgets inside that then.
I think I could live with that
you think its pretty robust so far?
I'm thinking if I factor the hell out of everything I shouldn't be in too much trouble if the API changes a bit
i think the creator(s?) are pretty open about it being very experimental. after the last question i asked about it here it was recommended i basically hack the ui library itself and make changes there as part of the workflow of using it. A lot of the form stuff was supposedly thrown in to meet some specific needs and not meant to be a complete implementation even at the time. So it's definitely rough around the edges and i don't think anyone is trying to claim it's in a 1.0 state or anything like that
personally i really like the idea of it and have found it to make more sense to me than other ui systems, which were all pretty much just CSS frameworks
but I've only been playing around with it on a toy project to learn a few things so far
right, ok.
basically html has all these semantic elements which all have default styles. you can pick a css framework (bootstrap, etc) and get some probably more sensible defaults. but you're still going to have to write your own CSS too, pretty much from the start
its looks like the button issue was a hangup on his computable-law project too
I thought one of the main gists of this project was to get you away from writing CSS
it seems like button
is required but not used. and also it almost definitely refers to an older ui library
ok, good, maybe I can just comment it out then and see something
and yeah i meant with something like bootstrap you're going to have to write your own css too
yes, that was the appeal
@vigilancetech: yeah, that repo is old. i removed the button element constructor because we can give any elem button semantics already by adding a click handler (and perhaps setting the mouse to pointer for desktops).
(elem :sh 300 :sv 60 :r 5 :b 2 :c :blue :m :pointer :click #(change-state! :home))
@dm3: a few that come to mind are:
1. forms. i think these, specifically, are largely solved on another branch, but certain form elements (like dropdowns) are stateful, and therefore depend on...
2. states. we need a general way for children of an elem to change based on the state of their parent. we’ve done this in more concrete cases via macros that set dynamic vars when the page is eval’d, but we need to do this with fns instead.
3. layers. many of the cases for absolute and relative positioning have been eleminated by ensuring that all types of elems take children, including image
, video
, etc, but there are cases (such as a dropdown list, again) where we need a component to appear in front of others in the layout. i’m also experimenting with the notion of an owner, which is an elem another elem might depend on for state, but is not necessarily the parent.
4. 100% height columns. this was actually solved, at one point, but regressed when experimenting with…
5. scrolling. we want to maintain the left right top bottom flow without introducing fixed, relative, absolute positioning schemes. so rather than making an entire page scrollable and then designating a menu as “fixed”, we should instead lay out the menu(s) and body lrtb and designate the body component itself as being scrollable. the way scroll contexts work in the dom complicates this. also, chrome does not use elastic scrolling on anything other than the body element last time i checked.
i think all of these issues are solvable, at this point, and i’ve implemented code to address them on various branches i have running locally (although some of these fixes, as is often the case with anything involving css properties, are mutually exclusive of others).
@dm3: i hadn’t considered that, but possibly (it’s interesting how, when you get the fundamental abstractions right, even unanticipated cases have a way of working out). one could potentially “fix” some menus by placing them in one layer while making the one behind it scrollable.
given a case where there was a fixed left sidebar menu, however, you’d need to specify the width of that menu twice, once for the menu itself on one layer, and again on the layer behind it so the elements in the scrollable layer would fill to the correct width.
a pragmatic solution might be needed 🙂 I think everywhere where an in-component scrolling is allowed, a custom scrolling scheme was used
it’s pretty cool to see so much interest in the ui project; my time has been a bit more constrained recently, but i do think we’re approaching a production-ready release. the remaining issues are solvable.
yeah, we might just need to make some less-than-elegant tradeoffs for some of the remaining cases so we can ship.
the advantages of maintaining the lrtb flow, however, are quite significant when it comes to making layouts work across different screen sizes, so i want to avoid introducing other layout schemes if at all possible.
not sure how it works now, but on v2 branch: https://github.com/hoplon/ui/blob/v2/tst/hoplon/material.cljs.hl
@dm3, @zilvinask: that’s quite dated… let me see what i can find.
(ns+ hoplon.demo
(:page
"index.html")
(:refer-clojure
:exclude [-])
(:require
[javelin.core :refer [defc defc= cell= cell]]
[hoplon.core :refer [defelem for-tpl when-tpl case-tpl]]
[hoplon.ui :refer [window elem image form line lines pick picks file files item send s b]]
[hoplon.ui.elems :refer [markdown]]
[hoplon.ui.attrs :refer [- c r d]]))
;;; model ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defc db {:session {:state :home}})
;;; queries ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defc= state (-> db :session :state))
;;; commands ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(defn swap-state! [state]
(swap! db assoc-in [:session :state] state))
;;; styles ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;-- breakpoints ---------------------------------------------------------------;
(def sm 760)
(def md 1240)
(def lg 1480)
(defn >sm [& bks] (apply b (r 1 1) sm bks))
;-- sizes ---- ----------------------------------------------------------------;
(def gutter 6)
;-- colors --------------------------------------------------------------------;
(def black (c 0x1F1F1F))
(def orange (c 0xE73624))
(def blue (c 0x009BFF))
(def yellow (c 0xF5841F))
;-- fonts ---------------------------------------------------------------------;
(def menu-font {:f 28 :ff "opensans" :ft :800 :fc :white :fw 1})
;;; views ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
(window
:title "Hoplon UI"
:route (cell= [[view]])
(elem :sh (r 1 1) :ah :mid :c orange :bt 8 :bc yellow
(elem :sh (>sm md) :p 50 :gv 50 :a :mid
(image :s 400 :m :pointer :click #(swap-state! :home) :url "")
(elem :sh (>sm (- (r 1 1) (+ 400 10))) :p 10 :g 10 :ah :end
(elem :sh (>sm :auto) :ah :mid :m :pointer menu-font "layout")
(elem :sh (>sm :auto) :ah :mid :m :pointer menu-font "fonts")
(elem :sh (>sm :auto) :ah :mid :m :pointer menu-font "layout")
(elem :sh (>sm :auto) :ah :mid :m :pointer menu-font "source")))))
those are the beginnings of a documentation site i started working on before i had to catch up with work
@jumblerg Thank you, I guess I still miss where does hoplon elements such as input/span/whatever meets e hoplon/ui ? Or does hoplon/ui has a replacement for them?
@zilvinask: if you’re looking for those, you’ll want to use the underlying hoplon core layer, which maintains a 1:1 correspondence with with the dom.
the objective of ui is to create a fresh, programmatic interface for creating user interfaces
ok, so lets say i want to make login screen with input field in the middle. How do i do that with hoplon/ui?
yeah thats what i understand. But then i need ‘input’, and i though that i can combine elem with input (which is hoplon.core)
here’s an example of a login viewstate i created:
(defelem authentication [_ _]
(public :title “Some Software Platform"
(elem :g 8
(image :sh (b (r 1 1) sm (r 1 2)) :p 4 :r 6 :b 1 :bc (c 0xCCCCCC) :url “pretty-picture.jpg")
(form :sh (b (r 1 1) sm (r 1 2)) :g 8 :submit c/authenticate-user
(field :sh (r 1 1) :key :email :prompt "email address")
(field :sh (r 1 1) :key :password :prompt "password")
(elem :ah :jst :m :default :fc font-grey
"Unable to log in? ")
(elem :sv 142 :fu :underline :m :pointer :click #(c/change-state :state/identification)
"Click here and we'll send a secret code to your email address instead.")
(elem :sh (r 1 1) :g 8
(submit :sh (r 2 5) :label "Sign Up" :submit c/register-user)
(submit :sh (r 3 5) :label "Sign In"))))))
forms are one of the rare cases where you’ll need something other than an elem
, since input elements carry different semantics for things other than layout.
@lightbulb that pavucontrol worked! What I had to do is set up shell a loop touching a source file and then the volume control became visible enough I could grab the knob and pull it down. WHAT a relief! Maybe my speakers are saved! (also worked for Facebook, and gave me Linux bragging rights on their help forum, as the Windows people look like they are eternally doomed to be confounded with this problem!) Thanks so much!
@vigilancetech that's awesome! totally forgot about pavucontrol, glad you were directed to it
@alandipert yes, but it would still be nice for speak to have a "volume." I'm putting it in the bazillionth place on my TODO list 😕
maybe someone could mention pavucontrol on the wiki?
@vigilancetech Glad you got it to work. I tried to build a tray mixer for pulseaudio like the Windows one in QT a year ago. It sorta worked. I want to revive that project at some point.
sadly now I'm using stumpWM sans tray right now. No time nor energy to configure one. Kind of interesting to see how well I'm getting along without one. Eventually I'll get around to it and then having a mixer there would definitely be good.
Not heard of stumpWM. I'll have a look. I'm using Openbox and Tint2. Not sure how much longer that will last with Wayland starting to actually happen.
I never even thought to look and see if there's an issue with stump and wayland. I wanted something lispy, and it was pretty much between stump and some emacs window manager
@micha I just want to give you an update on my javelin.core/none issue. I have created a new hoplon project and built a real minimal single page app but I have not been able to reproduce the issue yet. I will keep working on it and let you know when I figure it out. The main project i'm working on is quite large so its a bit of a needle in a haystack situation.
@vigilancetech I tried wayland on my laptop with just weston and well, none of my application would open. Basically if your WM doesn't get ported your only option will be to run your WM in a fullscreen xwayland session which defeats the point. Stay with X. I'd be quite happy with weston though once I can get my apps running on it.
@lightbulb well, for most of the rest I'm on Sabayon so I probably won't migrate there till they do. Right now, I've a critical project so I don't even dare upgrade!
is wayland the default in ubuntu LTS yet?
Not sure if Ubuntu will get Wayland. They went off on there own thing with MIR. Same sort of thing as upstart and systemd.
ah. i guess my plan will be to use whatever distro has i3
@dm3: it's on micha's attribute dev branch of hoplon