On 14 January 2015 at 05:50, Colin Yates <colin.ya...@gmail.com> wrote:
> My evolution of Java UI was swing>JSP>struts>JSF>velocity then onto > JavaScript/ExtJS. My instinct now when I hear the words "Java" and > "UI" is to run a mile :). > This is where I point out that you're currently using a Swing app every day :-) > I haven't looked at JavaFX (I think I had bailed before that appeared). > > > On 13 January 2015 at 16:05, Timothy Baldridge <tbaldri...@gmail.com> > 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.ya...@gmail.com> > 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 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. > > > > > > > > > > -- > > “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 a topic in the > > Google Groups "Clojure" group. > > To unsubscribe from this topic, visit > > https://groups.google.com/d/topic/clojure/Ut-HkNTqRUo/unsubscribe. > > To unsubscribe from this group and all its topics, send an email to > > clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > > -- > 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. > -- 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.
