Hi, thanks for the response. Yes I've thought about a web-based platform. There are tools like LightTable and UpVerter which are inspiring, and I understand the V8 javascript engine renders stuff pretty quickly. Unfortunately that would require getting up to speed on yet another way of thinking about things, clojurescript, etc. I'm kind of still stuck in the 90's and I have only so much brain power/attention/time available. :) I'll take a look at datomic. There are so many libraries and various tools for asynchronous frp javascript web based back-end server json immutable reactive things I really can't keep up with all the cool kids.
On Tuesday, January 13, 2015 at 7:15:26 AM UTC-8, Colin Yates 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.
