IntelliJ is swing! Well, knock me other with a feather :). Still wouldn't want to go anywhere near building a Swing app though :). On 14 Jan 2015 01:36, "Colin Fleming" <colin.mailingl...@gmail.com> wrote:
> 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 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.
