Re: Clojure for Desktop UI Design Application
Something else to consider... If you really want to avoid doing a web app with all the complexity of server code, client code, html, css, database, etc, then you might want to look into [quil](https://github.com/quil/quil). It's a clojure wrapper of the processing library for doing data visualizations, code art, and even small GUI applications. It's not something you typically see used for large-scale applications, but it's quite fun and is actually fairly impressive considering it's scope. On the other hand, while the web app route may feel a bit overwhelming, it really is worth learning. Once you program web, you can deliver to any platform. It's ubiquitous. And once you get the hang of it, the paradigm isn't really all that challenging. But up to you obviously. Good luck -- 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.
Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
Awesome project! I'll echo the encouragement towards having Neanderthal implement the core.matrix protocols. You'll have much higher adoption if folks know they can just plug your tool in by changing a single line setting the underlying implementation to Neanderthal. And as Mikera points out, it would be nice if we kept the Clojure matrix API space cohesive. -- 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.
Re: Clojure for Desktop UI Design Application
On Tue Jan 13 2015 at 2:05:03 PM Christopher Small wrote: > > On the other hand, while the web app route may feel a bit overwhelming, it > really is worth learning. Once you program web, you can deliver to any > platform. It's ubiquitous. And once you get the hang of it, the paradigm > isn't really all that challenging. But up to you obviously. > > This rationale is the basis for my last 1.5 years of extra-work effort. Good luck :-). Coming from clojure, React really made investing in the web seem sane and worthwhile by offering composable abstraction. I still think it's a good idea to learn web tech, but it was kind of a frustrating slog. Another really helpful piece of 'tech' that fits with clojure philosophies is http://suitcss.github.io/ https://github.com/suitcss/suit/blob/master/doc/design-principles.md I think that plus React are great starting points. -- 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.
Re: Clojure for Desktop UI Design Application
Before coming to Clojure I did 2 years of work on WPF/Silverlight apps, and
let me say what those platforms offer blows the web stuff out of the water.
Yes it's not cross-platform, but the ability to describe a layout with data
is unparalleled in the web world. I could sit down, and have a UI to a CRUD
app in half a day. No CSS, no DOM elements to force into a layout I wanted,
etc. Ask anyone who's worked with WPF and they'll tell you "yep it's based
on mutability, but writing a UI is really easy".
JavaFX comes close to this, but I'd like to use pure data to interact with
it. I did some work on that in the past, and came up with something that
was pretty usable, but I think a React approach could take it even further.
Anyways, the results of my work allowed you to create JavaFX interfaces
like this:
{:type :border-pane :center {:type :group
:children [{:type:circle
:radius (planet-sizes size)
:centerY (/ (planet-sizes size) 2)
:centerX 0}]} :bottom
{:type :stack-pane :maxHeight 110
:prefHeight 110
:children [{:type :pie-chart
:data (map(fn
[{percent :planet.biome/percentage
type:planet.biome/type}]
(slide/build-item {:type
:pie-chart-data
:name (str type)
:value percent}))
(:planet/biomes planet))}]}}
Notice how you don't have to muck with all the junk found in the
browser, you just describe an panel, say what you want to put where
(center, bottom, etc). and the layout engine takes care of the rest.
And this entire thing is GPU accelerated so drawing of the GUI is
pretty fast. The web side of things has a place, but it's also mired
in decades of legacy, that's stuff you don't find in modern UI
toolkits like JavaFX, QT and WPF.
Timothy
On Tue, Jan 13, 2015 at 12:46 PM, Gary Trakhman
wrote:
> On Tue Jan 13 2015 at 2:05:03 PM Christopher Small
> wrote:
>>
>> On the other hand, while the web app route may feel a bit overwhelming,
>> it really is worth learning. Once you program web, you can deliver to any
>> platform. It's ubiquitous. And once you get the hang of it, the paradigm
>> isn't really all that challenging. But up to you obviously.
>>
>>
> This rationale is the basis for my last 1.5 years of extra-work effort.
> Good luck :-).
>
> Coming from clojure, React really made investing in the web seem sane and
> worthwhile by offering composable abstraction. I still think it's a good
> idea to learn web tech, but it was kind of a frustrating slog.
>
> Another really helpful piece of 'tech' that fits with clojure philosophies
> is http://suitcss.github.io/
> https://github.com/suitcss/suit/blob/master/doc/design-principles.md
>
> I think that plus React are great starting points.
>
> --
> 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 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.
Re: Clojure for Desktop UI Design Application
Yeah, Adobe Flex can do that, too, with all the same caveats.
On Tue, Jan 13, 2015 at 12:09 PM, Timothy Baldridge
wrote:
> Before coming to Clojure I did 2 years of work on WPF/Silverlight apps,
> and let me say what those platforms offer blows the web stuff out of the
> water. Yes it's not cross-platform, but the ability to describe a layout
> with data is unparalleled in the web world. I could sit down, and have a UI
> to a CRUD app in half a day. No CSS, no DOM elements to force into a layout
> I wanted, etc. Ask anyone who's worked with WPF and they'll tell you "yep
> it's based on mutability, but writing a UI is really easy".
>
> JavaFX comes close to this, but I'd like to use pure data to interact with
> it. I did some work on that in the past, and came up with something that
> was pretty usable, but I think a React approach could take it even further.
> Anyways, the results of my work allowed you to create JavaFX interfaces
> like this:
>
>
> {:type :border-pane :center {:type :group
>:children [{:type:circle
>:radius (planet-sizes size)
>:centerY (/ (planet-sizes size) 2)
> :centerX 0}]} :bottom {:type :stack-pane
>:maxHeight 110 :prefHeight
> 110 :children [{:type :pie-chart
> :data (map
> (fn [{percent :planet.biome/percentage
>type:planet.biome/type}]
>(slide/build-item {:type :pie-chart-data
>:name
> (str type)
> :value percent}))
> (:planet/biomes planet))}]}}
>
> Notice how you don't have to muck with all the junk found in the browser, you
> just describe an panel, say what you want to put where (center, bottom, etc).
> and the layout engine takes care of the rest. And this entire thing is GPU
> accelerated so drawing of the GUI is pretty fast. The web side of things has
> a place, but it's also mired in decades of legacy, that's stuff you don't
> find in modern UI toolkits like JavaFX, QT and WPF.
>
>
> Timothy
>
>
> On Tue, Jan 13, 2015 at 12:46 PM, Gary Trakhman
> wrote:
>
>> On Tue Jan 13 2015 at 2:05:03 PM Christopher Small
>> wrote:
>>>
>>> On the other hand, while the web app route may feel a bit overwhelming,
>>> it really is worth learning. Once you program web, you can deliver to any
>>> platform. It's ubiquitous. And once you get the hang of it, the paradigm
>>> isn't really all that challenging. But up to you obviously.
>>>
>>>
>> This rationale is the basis for my last 1.5 years of extra-work effort.
>> Good luck :-).
>>
>> Coming from clojure, React really made investing in the web seem sane and
>> worthwhile by offering composable abstraction. I still think it's a good
>> idea to learn web tech, but it was kind of a frustrating slog.
>>
>> Another really helpful piece of 'tech' that fits with clojure
>> philosophies is http://suitcss.github.io/
>> https://github.com/suitcss/suit/blob/master/doc/design-principles.md
>>
>> I think that plus React are great starting points.
>>
>> --
>> 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 sub
Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
It would be nice if that would be that easy. However, I am sceptical... On Tuesday, January 13, 2015 at 8:13:36 PM UTC+1, Christopher Small wrote: > > Awesome project! > > I'll echo the encouragement towards having Neanderthal implement the > core.matrix protocols. You'll have much higher adoption if folks know they > can just plug your tool in by changing a single line setting the underlying > implementation to Neanderthal. And as Mikera points out, it would be nice > if we kept the Clojure matrix API space cohesive. > -- 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.
Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
I'd like to politely add to the calls for this to become a pluggable core.matrix backend. On Tuesday, January 13, 2015 at 4:38:22 PM UTC-5, Dragan Djuric wrote: > > It would be nice if that would be that easy. However, I am sceptical... > > On Tuesday, January 13, 2015 at 8:13:36 PM UTC+1, Christopher Small wrote: >> >> Awesome project! >> >> I'll echo the encouragement towards having Neanderthal implement the >> core.matrix protocols. You'll have much higher adoption if folks know they >> can just plug your tool in by changing a single line setting the underlying >> implementation to Neanderthal. And as Mikera points out, it would be nice >> if we kept the Clojure matrix API space cohesive. >> > -- 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.
Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
Ditto to the others. This looks great, and I have a lot of core.matrix compatible code I'd love to test it out against! Thanks for releasing this! On Tuesday, January 13, 2015 at 5:07:51 PM UTC-5, Sam Raker wrote: > > I'd like to politely add to the calls for this to become a pluggable > core.matrix backend. > > On Tuesday, January 13, 2015 at 4:38:22 PM UTC-5, Dragan Djuric wrote: >> >> It would be nice if that would be that easy. However, I am sceptical... >> >> On Tuesday, January 13, 2015 at 8:13:36 PM UTC+1, Christopher Small wrote: >>> >>> Awesome project! >>> >>> I'll echo the encouragement towards having Neanderthal implement the >>> core.matrix protocols. You'll have much higher adoption if folks know they >>> can just plug your tool in by changing a single line setting the underlying >>> implementation to Neanderthal. And as Mikera points out, it would be nice >>> if we kept the Clojure matrix API space cohesive. >>> >> -- 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.
Re: Help with Incanter and Emacs
For something that's been "deprecated" for a while now, `use` sure still
shows up in A LOT of docs/tutorials/books/etc.
On Monday, January 12, 2015 at 7:48:44 PM UTC-5, Robert Berger wrote:
>
> Wish this was in the Incanter docs and in the Readme
>
> On Tuesday, August 13, 2013 at 12:09:20 PM UTC-7, Tim Visher wrote:
>>
>> LOL. I just realized I'd been missing that all along.
>>
>> It seems like the community is more and more leaning to something like
>> this, just FYI.
>>
>> (ns default.core
>> (:require (incanter [core :refer :all]
>> [charts:refer :all]
>> [stats :refer :all]
>> [datasets :refer :all])))
>>
>> `:use` has been discussed in the interest of deprecating it many times.
>>
>> I did not test the above declaration.
>>
>> On Tue, Aug 13, 2013 at 2:40 PM, Akhil Wali
>> wrote:
>> > Well this is embarrassing.
>> >
>> > I was having a wrong use syntax >.<.
>> > Changed the import line to this and it works.
>> >
>> > (ns default.core
>> > (:use [incanter core charts stats datasets]))
>> >
>> > Thanks for the help though!!
>> >
>> > On Tuesday, August 13, 2013 11:57:46 PM UTC+5:30, Akhil Wali wrote:
>> >>
>> >> Yes, by nrepl-jack-in.
>> >>
>> >> On Tuesday, August 13, 2013 11:54:24 PM UTC+5:30, Tim Visher wrote:
>> >>>
>> >>> And you're connecting to the project how?
>> >>>
>> >>> On Tue, Aug 13, 2013 at 2:11 PM, Akhil Wali
>> >>> wrote:
>> >>> > Well
>> >>> > Here's my project.clj.
>> >>> >
>> >>> > (defproject someproj "0.1.0-SNAPSHOT"
>> >>> > :dependencies [[org.clojure/clojure "1.5.1"]
>> >>> > [incanter "1.5.2"]])
>> >>> >
>> >>> > Here's my .lein/profiles.clj as well.
>> >>> >
>> >>> > {:user {:plugins [[lein-ritz "0.7.0"]
>> >>> > [compojure-app/lein-template "0.2.7"]]
>> >>> > :dependencies [[ritz/ritz-nrepl-middleware "0.7.0"]]
>> >>> > :repl-options {:nrepl-middleware
>> >>> >[ritz.nrepl.middleware.javadoc/wrap-javadoc
>> >>> >
>> >>> > ritz.nrepl.middleware.simple-complete/wrap-simple-complete]}}}
>> >>> >
>> >>> >
>> >>> >
>> >>> > On Tuesday, August 13, 2013 11:35:58 PM UTC+5:30, Tim Visher wrote:
>> >>> >>
>> >>> >> On Tue, Aug 13, 2013 at 1:59 PM, Akhil Wali
>>
>> >>> >> wrote:
>> >>> >> > Hi All,
>> >>> >> >
>> >>> >> > A really noob question.
>> >>> >> >
>> >>> >> > Why do I get "FileNotFoundException Could not locate
>> >>> >> > incanter__init.class or
>> >>> >> > incanter.clj on classpath: clojure.lang.RT.load (RT.java:443)"
>> >>> >> > when i
>> >>> >> > load
>> >>> >> > a file that uses incanter in emacs?
>> >>> >> > Here's the file...
>> >>> >> >
>> >>> >> > (ns default.core
>> >>> >> > (:require incanter core charts stats datasets))
>> >>> >> >
>> >>> >> > (defn plot []
>> >>> >> > (view (scatter-plot :Sepal.Length :Sepal.Width
>> >>> >> > :group-by :Species
>> >>> >> > :data (get-dataset :iris
>> >>> >> >
>> >>> >> > (plot)
>> >>> >> >
>> >>> >> > This works in lein repl just fine.
>> >>> >> > I'm using Emacs 24 and nrepl.el 0.1.8.
>> >>> >> >
>> >>> >> > This issue was posted on Github way long back. Seems to be
>> solved,
>> >>> >> > but
>> >>> >> > by
>> >>> >> > simply upgrading emacs. Doesn't really work in my case.
>> >>> >> > Any advise?
>> >>> >>
>> >>> >> Couple things.
>> >>> >>
>> >>> >> 1. I'm assuming you've declared the proper dependencies in your
>> >>> >> `project.clj` file since this works from `lein repl`, however it's
>> >>> >> worth checking.
>> >>> >>
>> >>> >> 2. How are you connecting to your project? Simply loading the
>> >>> >> namespace won't work if you haven't properly jack in. There's a
>> number
>> >>> >> of options here but the simplest is probably to use `M-x
>> >>> >> nrepl-jack-in` (usually bound to `C-c M-j`) from this file. It
>> should
>> >>> >> Just Work™.
>> >>> >>
>> >>> >> If that doesn't work, I'd probably post some more details about
>> the
>> >>> >> project somewhere. At least the `project.clj` and the whole ns
>> would
>> >>> >> be helpful in a gist of some sort.
>> >>> >>
>> >>> >> --
>> >>> >>
>> >>> >> In Christ,
>> >>> >>
>> >>> >> Timmy V.
>> >>> >>
>> >>> >> http://blog.twonegatives.com/
>> >>> >> http://five.sentenc.es/ -- Spend less time on mail
>> >>> >
>> >>> > --
>> >>> > --
>> >>> > 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
>> >>> > 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
>> >>> > For more options, visit this group at
>> >>> > http://groups.google.com/group/clojure?hl=en
>>
Re: [ANN] Neanderthal, a fast, native matrix and linear algebra library for Clojure released + call for help
It works for the development branch of Incanter 2.0 - which is a pretty significant project with a lot of matrix code. You can switch between Clatrix (native BLAS via JBlas), persistent vectors (regular Clojure vectors) and vectorz-clj (pure JVM code) transparently. I think it would be the same for Neanderthal - I don't see anything that would be inconsistent with core.matrix from an API perspective. On Wednesday, 14 January 2015 05:38:22 UTC+8, Dragan Djuric wrote: > > It would be nice if that would be that easy. However, I am sceptical... > > On Tuesday, January 13, 2015 at 8:13:36 PM UTC+1, Christopher Small wrote: >> >> Awesome project! >> >> I'll echo the encouragement towards having Neanderthal implement the >> core.matrix protocols. You'll have much higher adoption if folks know they >> can just plug your tool in by changing a single line setting the underlying >> implementation to Neanderthal. And as Mikera points out, it would be nice >> if we kept the Clojure matrix API space cohesive. >> > -- 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.
Re: Clojure for Desktop UI Design Application
On Tue, Jan 13, 2015 at 10:16 AM, Mike Haney wrote: > Anyway, given what I know today If I had to write a desktop GUI, my first > instinct would be Clojurescript+node-webkit Since I'm still investigating Clojure, my first instinct when writing a desktop GUI --- similar to what Timothy Baldridge mentions --- is to use C# + WPF. In particular I really like the Model-View-ViewModel architecture enabled by the fancy data binding that XAML/WPF can do. And the relatively new Assisticant [1] [2] seems to make that even easier (though I've haven't actually used it yet). Given that I'm more comfortable with .NET... for functional programming I've started to use F# for "real work" (as opposed to toy apps/solving koans while learning Clojure). While you can write WPF apps with F# there is still some work to do. FsXaml [3] [4] is trying to address this need. And while I'm still learning, it seems like F# can do React-like "Functional Reactive Programming" [5]. Of course ClojureCLR [6] is also an alternative for .NET-centric types but I only looked at it briefly. I spent some time trying to grok LightTable, but the Clojure/ClojureScript/Javascript/leiningen/Google Closure compiler/JVM/node-webkit combo caused me to give up for now. It didn't help that Windows support tends to be an afterthought. BTW LightTable is seriously considering jettisoning node-webkit and switching to the github Atom shell instead [7]. [1] http://assisticant.net/ [2] http://www.pluralsight.com/courses/clean-view-models-assisticant [3] https://github.com/fsprojects/FsXaml [4] Reed Copsey: New libraries for Client Side development in F# https://www.youtube.com/watch?v=z6R85_X2ivE [5] http://fsharpforfunandprofit.com/posts/concurrency-reactive/ [6] https://github.com/clojure/clojure-clr [7] https://groups.google.com/forum/#!searchin/light-table-discussion/atom$20shell$20chris$20granger -- 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.
Re: Clojure for Desktop UI Design Application
I'd be pretty interested in this too. Though not quite enough to write it myself (I've made "good enough" interfaces with Swing interop). The thought occurs that there may be quite a bit of common code that could be shared with respect to diffing / cursors etc. that would work equally well for Om, JavaFX2, maybe also some OpenGL rendering. This similarity might even be exploited to build re-targetable GUI code. OK I'll stop speculating now On Wednesday, 14 January 2015 00:05:40 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 > 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
Re: Clojure for Desktop UI Design Application
On 14 January 2015 at 05:50, Colin Yates 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 > 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 > 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 chang
Re: Clojure for Desktop UI Design Application
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" wrote: > On 14 January 2015 at 05:50, Colin Yates 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 >> 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 >> 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
DSL in RTL (Right to Left) languages.
Hi I need to write a dsl in Arabic which is a RTL. I am not sure how to get started with such a dsl in clojure. Any pointers with be really appreciated. 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.
Re: DSL in RTL (Right to Left) languages.
I would wrap everything in a tree walking macro that first reverses all lists and then starts evaluating other macros. I'd love to see an Arabic clojure file btw :D But non English source always makes me shudder a bit, one of the great things about programming is that everybody speaks English ;) cheers Jan > On 14 Jan 2015, at 05:52, clojure.u...@gmail.com wrote: > > Hi > > I need to write a dsl in Arabic which is a RTL. I am not sure how to get > started with such a dsl in clojure. Any pointers with be really appreciated. > > 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. -- 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.
Re: Clojure for Desktop UI Design Application
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 nod
Re: Clojure for Desktop UI Design Application
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 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 req
Re: Clojure for Desktop UI Design Application
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 codi
Re: Clojure for Desktop UI Design Application
What about node-webkit + Clojurescript? I think it would be ideal environment for desktop GUI? On Tuesday, January 13, 2015 at 7:05:40 PM UTC+3, 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 > 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:
Re: Clojure for Desktop UI Design Application
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 > 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 a
Re: Clojure for Desktop UI Design Application
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 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 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
Re: Clojure for Desktop UI Design Application
One lesson I would share is that things are usually much quicker than we expect. Always prove it is too slow before believing your intuition. On 13 January 2015 at 16:28, MS <5lvqbw...@sneakemail.com> wrote: > 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 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 signa
Re: Clojure for Desktop UI Design Application
You made the analogy to games/graphics, React model treats the DOM akin to a graphics buffer, and they themselves present it as similar to the doom3 architecture. In practice, it feels a lot like a scene graph, with the update/render methods on every component. I don't know how easy it is to fit javafx into this, but it works out with the DOM pretty well. If JavaFX can be described as a renderer of a static data structure, then you should be able to do the same kind of tree-diffing optimizations that React does to minimize what needs to be redrawn, and to present a functional/data interface. On Tue Jan 13 2015 at 11:52:36 AM Colin Yates wrote: > One lesson I would share is that things are usually much quicker than > we expect. Always prove it is too slow before believing your > intuition. > > On 13 January 2015 at 16:28, MS <5lvqbw...@sneakemail.com> wrote: > > 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 > 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 > b
Clojure and JVM Performance talk 3 Feb at Skills Matter London
Roll up! Roll up! The first talk at Skills Matter for the London Clojurians will be on 3 Feb. Tom Crayford will be talking JVM performance tuning and clojure for your edification, entertainment and enjoyment! More details and registration here: https://skillsmatter.com/meetups/6953-opening-the-grimoire-some-things-about-clojure-performance I'm sure Skills Matter will be as speedy as always with a video of the talk which will also be at the above URL. cheers, Bruce -- 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.
Re: Clojure for Desktop UI Design Application
I know it seems overwhelming, and if you try to keep up with all the latest "cool" libraries, -- 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.
Re: Clojure for Desktop UI Design Application
On Tuesday, January 13, 2015 at 10:15:26 AM UTC-5, 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. > Unless you want to go open source... -- 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.
Re: Clojure for Desktop UI Design Application
My evolution is similar to Colin's, with more SWT than Swing. And I understand where you're coming from - did Java for 15 years and C++ before that. I didn't even really learn about functional programming until about 3 years ago, and after an aborted dive into learning Scala I switched to Clojure 18 months ago and haven't looked back. Anyway, given what I know today If I had to write a desktop GUI, my first instinct would be Clojurescript+node-webkit. There's not as much to learn as you might think. It sounds like you already know Clojure, so Clojurescript isn't a big leap. Core.async is not, but by no means a requirement - you can safely ignore it for now and only reach for it if it solves a particular problem you are having. For the database, there is Datascript which is basically Datomic in the browser. This would give you a very capable embedded database that you can simply serialize to a file to store your "document" in a desktop app. Coming from a mostly server background, I found the React model very familiar and easy to pick up. You get a request, query the database, and render a template. It looks very different in React, but conceptually it's the same thing as PHP or Spring MVC or whatever. You also gain access to a huge number of JS widgets for just about anything you can imagine, from fancy input controls to graphs and charts and even 3d rendering. Here's a simple model you can start with and build on as-needed - use Datascript as your "source of truth" for your data, and all your event handlers and other application logic simply transacts against this DB. Your views simply query the DB to construct their data. All that's left is triggering when the view refreshes to reflect changes in the DB, and that will depend on which React wrapper library you are using. In my experience, to integrate with Datascript the easiest to hardest choices are: Rum, Quiescent, Reagent, Om. I've recently switched to Rum (by the same guy who wrote Datascript) and it's dead simple - like 3 lines of code, done! But Rum is very new and fairly low level, so it might not be the easiest to start with. For overall ease of use, Reagent is a great choice although the integration with Datascript is a bit more work. If you're interested, I can go into more detail on how you might integrate Datascript with a given library. On Tuesday, January 13, 2015 at 10:21:24 AM UTC-6, MS wrote: > > 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 t
Re: Clojure for Desktop UI Design Application
If you're looking for functional reactive programming in Clojure (rather than going web-based), there's a great library for Clojure bindings to RxJava: https://github.com/ReactiveX/RxClojure Jason Lewis vox 410.428.0253 twitter @canweriotnow blog http://decomplecting.org else http://about.me/jason.lewis On Tue, Jan 13, 2015 at 10:15 AM, 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
