If I come up with anything that might usefully tie Clojure data structures to JavaFX UI elements in a clean way, I may release it on github. For now it's just one or two .clj files with all my random monkey-coding, using lots of half-examples from various sources, which is pretty much how I learn. I played around with Seesaw (Swing-based) for a little bit, but it started to get a little too abstract for me, and anyway, as a friend of mine recently said, Swing looks like ass, even if you set it to look like the native platform, and I need my app to be "rich", etc. There's also a certain part of me that feels that "all these" asynchronous libraries out there (react? core.async? I really don't know what I'm talking about [I'm a hardware engineer]), add a lot of overhead with threads, etc., and I may be wrong, but it feels like there would need to be fewer layers between clicking the mouse and having something show up. I believe any cad/drawing/design tool needs to be as reactive and real-time as any game, so max 16ms latency. I'm not saying I have any evidence these libraries are slow... I'm just saying it feels like overkill when I'm not writing a big web server or anything. I'm probably wrong.
On Tuesday, January 13, 2015 at 8:05:40 AM UTC-8, tbc++ wrote: > > I've long thought that the Clojure world needs a JavaFX/React hybrid. > JavaFX2's API is extremely consistent, making it quite easy to program > against, but yes it still requires bindings and in-place mutation. > > However a React-like diff-ing engine on it would be quite impressive. But > now you're into the fun land of writing a library in order to write your > app. > > On Tue, Jan 13, 2015 at 8:15 AM, Colin Yates <colin...@gmail.com > <javascript:>> wrote: > >> Wow, there is a lot to deal with :), so let me throw out some ideas: >> - have you considered building a web-app instead of a desktop app? If >> so, have a look at one of the react based languages (om or reagent would be >> my choice). Alternatively take a look at other >> http://en.wikipedia.org/wiki/Functional_reactive_programming libraries. >> >> It is a different way of working, but its programming model restricts you >> in a way that removes many problems (if you see what I mean). >> >> Also, I would be reaching for an in-memory database (assuming a server >> isn't involved) about now, datatomic would be the obvious choice. >> >> I don't think what you are trying to do is stupid, I do think you might >> want to do some thought experiments about different architectures and >> paradigms (specifically FRP related paradigms). >> >> Oh, and have a quick scan through http://swannodette.github.io/, there >> are a few "mind-changing" posts. >> >> On Monday, 12 January 2015 18:53:07 UTC, MS wrote: >>> >>> (Cross-posted on StackOverflow) >>> >>> I'm trying to design a desktop UI for schematics, layout, drawing >>> stuff. Just looking for high level advice from actual software designers. >>> >>> Assuming an in-memory "database", (clojure map of arbitrary depth for >>> all user data, and possibly another one for application preferences, etc.), >>> I'm examining how to do the model-view-controller thing on these, where the >>> data may be rendered *and modified by* any one or more of: >>> >>> 1. A standalone text field that shows a single parameter, such as box >>> width. >>> 2. An "inspector" type of view that shows multiple parameters of a >>> selected object, such as box width, height, color, checkboxes, etc. >>> 3. A table/spreadsheet type of view that shows multiple parameters of >>> multiple objects, potentially the whole database >>> 4. A graphical rendering of the whole thing, such as both schematic and >>> layout view. >>> >>> Modifying any one of these should show up immediately in every other >>> active view, both text and graphical, not after clicking "ok"... so no >>> modal boxes allowed. If for some reason the table view, an inspector view, >>> and a graphical rendering are all in view, dragging the corner of the box >>> graphically should immediately show up in the text, etc. >>> >>> The platform in question is JavaFX, but I'd like a clean separation >>> between UI and everything else, so I want to avoid `bind`ing in the JFX >>> sense, as that ties my design data very tightly to JFX Properties, >>> increases the graininess of the model, and forces me to work outside the >>> standard clojure functions for dealing with data, and/or deal heavily with >>> the whole `getValue`/`setValue` world. >>> >>> I'm still assuming at least *some* statefulness/mutability, and the use >>> of built-in Clojure functionality such as the ability to `add-watch` on an >>> atom/var/ref and let the runtime signal dependent functions. >>> >>> Platform-specific interaction will rest tightly with the actual UI, such >>> as reifying `ActionListener`s, and dealing with `ObservableValue`s etc., >>> and will attempt to minimize the reliance on things like JavaFX `Property` >>> for actual application data. I'm not entertaining FRP for this. >>> >>> I don't mind too much extending JFX interfaces or making up my own >>> protocols to use application-specific `defrecord`s, but I'd prefer for the >>> application data to remain as straight Clojure data, unsullied by the >>> platform. >>> >>> The question is how to set this all up, with closest adherence to the >>> immutable model and minimal (or well-bounded) dependence on JFX. I see a >>> few options: >>> >>> 1. Fine-grain: Each parameter value/primitive (ie Long, Double, >>> Boolean, or String) is an atom, and each view which can modify the value >>> "reaches in" as far as it needs to in the database to change the value. >>> This could suck as there could potentially be thousands of individual >>> values (for example points on a hand-drawn curve), and will require lots of >>> `(deref...)` junk. I believe this is how JFX would want to do this, with >>> giant arrays of Properties at the leaf nodes, etc., which feels bloated. >>> With this approach it doesn't seem much better than just coding it up in >>> Java/C++. >>> 2. Medium-grain: Each object/record in the database is an atom of a >>> Clojure map. The entire map is replaced when any one of its values >>> changes. Fewer total atoms to deal with, and allows for example long >>> arrays of straight-up numbers for various things. But this gets >>> complicated when some objects in the database require more nesting than >>> others. >>> 3. Coarse-grain: There is just one atom: the database. Any time >>> anything changes, the entire database is replaced, and every view needs to >>> re-render its particular portion. This feels a bit like using a hammer to >>> swat a fly, and a naive implementation would require everything to >>> re-render all the time. But I still think this is the best trade off, as >>> any primitive has a clear access path from the root node, whether it is >>> accessed on a per-primitive level or per-record level. >>> >>> I also need the ability for one data template to be instantiated many >>> times. So for example if the user changes a symbol or shape which is used >>> in multiple places, a single edit will apply everywhere. I believe this >>> also requires some type of "pointer"-like behavior. I think I can store a >>> atom to the model, then instantiate as needed, and it can work in any of >>> the above grain models. >>> >>> Any other approaches? Is trying to do a GUI editor-like tool in a >>> functional language just stupid? >>> Thanks >>> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> <javascript:> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com <javascript:> >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
