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 :).

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.

Reply via email to