Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Timothy Baldridge]

I've done a fair amount of work with core.async in gui libraries, and I
strongly recommend against it. Core.async by it's very nature consists of
performing IO operations on channels, this sort of thing shouldn't be done
inside a user interface. Your code will quickly become very complex with
dozens of channels crossing over each other and the state of your UI almost
never being completely clear.

The React pattern is much simpler, you have data, and a projection function
(component code), the data changes, and the UI is re-rendered to reflect
that. UI events become data that is passed to a common callback and handled
via a function that can mutate the data state. So it's a loop of data
state-> render code -> components -> events -> data state.

I agree with David's points at this part of his Om.Next talk:
https://youtu.be/MDZpSIngwm4?t=4m17s

Yes, fn-fx is not complete by any means, as I have time, I plan on working
more towards a Om.Next-esque model, but that will take some time.

Timothy

On Mon, Mar 21, 2016 at 8:15 AM, Jason Zwolak  wrote:

> I sat down to use fx-fn today and discovered another library fx-clj.
>
> fx-clj hasn't had any activity for over a year, but it does use
> core.async, which seems to be the right direction if you want clean UI
> code: http://www.infoq.com/presentations/core-async-clojure
>
> Any plans to incorporate core.async into fx-fn? fx-clj does seem to be
> more mature than fx-fn... and I'm not sure if the two projects need to be
> separate projects other than they started independently... I think the
> efforts may be best placed behind one project...
>
> I'm very interested in JavaFX on Clojure and have time to put behind a
> project that is using the best we know about GUI programming. At the moment
> that seems to be core.async and some kind of DOM that can be diffed.
>
> --
> Jason Zwolak
>
> On Fri, Mar 18, 2016 at 12:42 PM, Timothy Baldridge 
> wrote:
>
>> I dusted off the fn-fx code today and fixed a bunch of bugs, and
>> implemented a few examples: https://github.com/halgari/fn-fx
>>
>> One of the most complex examples so far is here:
>> https://github.com/halgari/fn-fx/blob/master/examples/getting_started/02_form.clj
>>
>> As you can see the library is capable of some rather decent UIs (grid
>> panes, event handlers, etc). This is mostly because the JavaFX API is very
>> uniform and therefore easy to generate wrappers/converters using reflection
>> and meta-programming.
>>
>> I will probably continue working on this as time goes on, but to some
>> extent I need a good use case to drive development on fn(fx), so if anyone
>> has some OSS project or some swing app, they'd like to switch over to
>> fn(fx), drop me a line.
>>
>> Timothy
>>
>> On Fri, Mar 18, 2016 at 5:30 AM, Mathias De Wachter <
>> mathias.dewach...@gmail.com> wrote:
>>
>>> Hi Timothy,
>>> I'm really glad to see some new commits on fn(fx)! I don't know about
>>> others, but you'll definitely have at least one very enthusiastic user if I
>>> can get to a point where I can use it easily for simple things, and
>>> adapt/contribute for more complex things.
>>> Do you think the project is in that state already? (Haven't tried yet...)
>>> Thanks,
>>> Mathias
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To post to this group, send email to clojure@googlegroups.com
>>> Note that posts from new members are moderated - please be patient with
>>> your first post.
>>> To unsubscribe from this group, send email to
>>> clojure+unsubscr...@googlegroups.com
>>> For more options, visit this group at
>>> http://groups.google.com/group/clojure?hl=en
>>> ---
>>> You received this message because you are subscribed to the Google
>>> Groups "Clojure" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to clojure+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> “One of the main causes of the fall of the Roman Empire was that–lacking
>> zero–they had no way to indicate successful termination of their C
>> programs.”
>> (Robert Firth)
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/NkLXh8KYXqk/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> clojure+unsubscr...@googlegroups.com.
>> For 

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Jason Zwolak]

I sat down to use fx-fn today and discovered another library fx-clj.

fx-clj hasn't had any activity for over a year, but it does use core.async,
which seems to be the right direction if you want clean UI code:
http://www.infoq.com/presentations/core-async-clojure

Any plans to incorporate core.async into fx-fn? fx-clj does seem to be more
mature than fx-fn... and I'm not sure if the two projects need to be
separate projects other than they started independently... I think the
efforts may be best placed behind one project...

I'm very interested in JavaFX on Clojure and have time to put behind a
project that is using the best we know about GUI programming. At the moment
that seems to be core.async and some kind of DOM that can be diffed.

--
Jason Zwolak

On Fri, Mar 18, 2016 at 12:42 PM, Timothy Baldridge 
wrote:

> I dusted off the fn-fx code today and fixed a bunch of bugs, and
> implemented a few examples: https://github.com/halgari/fn-fx
>
> One of the most complex examples so far is here:
> https://github.com/halgari/fn-fx/blob/master/examples/getting_started/02_form.clj
>
> As you can see the library is capable of some rather decent UIs (grid
> panes, event handlers, etc). This is mostly because the JavaFX API is very
> uniform and therefore easy to generate wrappers/converters using reflection
> and meta-programming.
>
> I will probably continue working on this as time goes on, but to some
> extent I need a good use case to drive development on fn(fx), so if anyone
> has some OSS project or some swing app, they'd like to switch over to
> fn(fx), drop me a line.
>
> Timothy
>
> On Fri, Mar 18, 2016 at 5:30 AM, Mathias De Wachter <
> mathias.dewach...@gmail.com> wrote:
>
>> Hi Timothy,
>> I'm really glad to see some new commits on fn(fx)! I don't know about
>> others, but you'll definitely have at least one very enthusiastic user if I
>> can get to a point where I can use it easily for simple things, and
>> adapt/contribute for more complex things.
>> Do you think the project is in that state already? (Haven't tried yet...)
>> Thanks,
>> Mathias
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "Clojure" group.
>> To post to this group, send email to clojure@googlegroups.com
>> Note that posts from new members are moderated - please be patient with
>> your first post.
>> To unsubscribe from this group, send email to
>> clojure+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/clojure?hl=en
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "Clojure" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to clojure+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> --
> “One of the main causes of the fall of the Roman Empire was that–lacking
> zero–they had no way to indicate successful termination of their C
> programs.”
> (Robert Firth)
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/NkLXh8KYXqk/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Timothy Baldridge]

>> If the app-state has changed then it starts re-rendering the UI.

That's pretty much exactly what fn-fx does in the latest version, with two
caveats: 1) there's no timer, just a watch on an atom. 2) If you properly
diff components you don't need to re-create them every time, just change
the properties that changed. So if you have a text box 5 components deep in
your app, and you change the background color, only the background color
property of that single component will be changed, the rest of the app will
remain unmodified.

On Thu, Mar 17, 2016 at 10:37 AM, Jason Zwolak  wrote:

> Paul, yeap, Seesaw is definitely something worth considering. Dave Ray
> hasn't abandoned the project, but I sent a personal email to him asking
> about the state of the project and it does seem the Seesaw is in more of a
> maintenance phase than a continue to move forward and improve phase. Dave
> Ray, if you're on this list, would you chime in?
>
> Also, I was at the talk you mentioned and was very impressed with their
> methods. What wasn't mentioned in the talk was the fundamental structure of
> the interface between Clojure and JavaFX. One point that _really_ struck me
> is that they have a reoccurring timer running in the background and each
> time it wakes up it checks for changes on the app-state (presumably an
> atom, but I do not remember). If the app-state has changed then it starts
> re-rendering the UI. If I remember correctly it recreates the UI components
> that rely on any part of the app state that has changed. It sounds a little
> similar to Facebook React. I questioned them on this approach as it sounded
> strange to me... and they convinced me it's a good approach for their
> project and inspired me to try something similar on my own... which I'm
> secretly working on ;-)
>
> One thing that makes this work so well for their approach is that they
> have animations that depend on the app state. So their reoccurring timer is
> almost like a video algorithm redrawing the on screen image at the
> specified frame rate.
>
> --
> Jason Zwolak
>
> On Thu, Mar 17, 2016 at 11:06 AM, Paul L. Snyder  > wrote:
>
>> Yow, old indeed!
>>
>> In 2011, Dave Ray released Seesaw, which is a very nice wrapper for Swing.
>> I've used it for a bunch of projects, and it works great. Of course, it
>> does look like Swing, but it's plenty usable. (It's also still being
>> maintained, so if you're looking for a toolkit that you can use right now,
>> it's a good way to go.)
>>
>>   https://github.com/daveray/seesaw
>>
>> That said, I'd also love to see a JavaFX wrapper. At the Conj in Philly,
>> Cognitect talked about a project where they'd used it extensively:
>>
>>   https://www.youtube.com/watch?v=ajX09xQ_UEg
>>
>> It's definitely piqued my interest.
>>
>> Paul
>>
>> On Sat, 12 Mar 2016, Jason Zwolak wrote:
>>
>> > +1 JavaFX.
>> >
>> > I know this is an old thread... but in case anyone comes across it
>> (like I
>> > did just now) and wants to see where things are, they should know that
>> > JavaFX has come a long way and seems to be Oracle's replacement for
>> Swing.
>> > Now JavaFX is no longer only in JavaFXscript... in fact, I believe
>> > JavaFXscript is deprecated in favor of the JavaFX Java classes.
>> >
>> > I've seen some major projects done with Clojure and JavaFX... even from
>> the
>> > guys at Cognitect.
>> >
>> > On Thursday, May 27, 2010 at 11:18:41 AM UTC-4, Luke VanderHart wrote:
>> > >
>> > > My side project is a fairly complex GUI application written in
>> > > Clojure. Recently, I've become irritated with using Java interop for
>> > > everything. It's not that Clojure doesn't have nice java interop - it
>> > > does. It's just that when interacting with a GUI framework, which is a
>> > > large part of my app, I have to be back in mutable object-oriented
>> > > land, worrying about class hierarchies, mutable state, locks, etc.
>> > > Yucky.
>> > >
>> > > So, with a perhaps dangerous lack of sanity and without any guarantee
>> > > of success, I've decided to try my hand at writing an idiomatic
>> > > Clojure GUI library. If I have success (which I doubt) I will of
>> > > course make it available as open source.
>> > >
>> > > I intend for it to be mostly declarative, with a nice DSL for defining
>> > > GUI elements. Each component will also implement map, and use one of
>> > > Clojure's reference types as an interface for inspecting / updating
>> > > its state. I may also implement some aspects of Functional Reactive
>> > > Programming wherever it's convenient to do so.
>> > >
>> > > What you all must help me decide is what GUI framework to use as the
>> > > underpinnings of it. It's genuinely hard to decide. I have at least
>> > > some experience with all of them, so I have no strong preference, but
>> > > I'd like to get your input. I did consider trying to make it abstract
>> > > enough that you could plug in *any* of them under the hood, but
>> > > there's enough 

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Jason Zwolak]

Paul, yeap, Seesaw is definitely something worth considering. Dave Ray
hasn't abandoned the project, but I sent a personal email to him asking
about the state of the project and it does seem the Seesaw is in more of a
maintenance phase than a continue to move forward and improve phase. Dave
Ray, if you're on this list, would you chime in?

Also, I was at the talk you mentioned and was very impressed with their
methods. What wasn't mentioned in the talk was the fundamental structure of
the interface between Clojure and JavaFX. One point that _really_ struck me
is that they have a reoccurring timer running in the background and each
time it wakes up it checks for changes on the app-state (presumably an
atom, but I do not remember). If the app-state has changed then it starts
re-rendering the UI. If I remember correctly it recreates the UI components
that rely on any part of the app state that has changed. It sounds a little
similar to Facebook React. I questioned them on this approach as it sounded
strange to me... and they convinced me it's a good approach for their
project and inspired me to try something similar on my own... which I'm
secretly working on ;-)

One thing that makes this work so well for their approach is that they have
animations that depend on the app state. So their reoccurring timer is
almost like a video algorithm redrawing the on screen image at the
specified frame rate.

--
Jason Zwolak

On Thu, Mar 17, 2016 at 11:06 AM, Paul L. Snyder 
wrote:

> Yow, old indeed!
>
> In 2011, Dave Ray released Seesaw, which is a very nice wrapper for Swing.
> I've used it for a bunch of projects, and it works great. Of course, it
> does look like Swing, but it's plenty usable. (It's also still being
> maintained, so if you're looking for a toolkit that you can use right now,
> it's a good way to go.)
>
>   https://github.com/daveray/seesaw
>
> That said, I'd also love to see a JavaFX wrapper. At the Conj in Philly,
> Cognitect talked about a project where they'd used it extensively:
>
>   https://www.youtube.com/watch?v=ajX09xQ_UEg
>
> It's definitely piqued my interest.
>
> Paul
>
> On Sat, 12 Mar 2016, Jason Zwolak wrote:
>
> > +1 JavaFX.
> >
> > I know this is an old thread... but in case anyone comes across it (like
> I
> > did just now) and wants to see where things are, they should know that
> > JavaFX has come a long way and seems to be Oracle's replacement for
> Swing.
> > Now JavaFX is no longer only in JavaFXscript... in fact, I believe
> > JavaFXscript is deprecated in favor of the JavaFX Java classes.
> >
> > I've seen some major projects done with Clojure and JavaFX... even from
> the
> > guys at Cognitect.
> >
> > On Thursday, May 27, 2010 at 11:18:41 AM UTC-4, Luke VanderHart wrote:
> > >
> > > My side project is a fairly complex GUI application written in
> > > Clojure. Recently, I've become irritated with using Java interop for
> > > everything. It's not that Clojure doesn't have nice java interop - it
> > > does. It's just that when interacting with a GUI framework, which is a
> > > large part of my app, I have to be back in mutable object-oriented
> > > land, worrying about class hierarchies, mutable state, locks, etc.
> > > Yucky.
> > >
> > > So, with a perhaps dangerous lack of sanity and without any guarantee
> > > of success, I've decided to try my hand at writing an idiomatic
> > > Clojure GUI library. If I have success (which I doubt) I will of
> > > course make it available as open source.
> > >
> > > I intend for it to be mostly declarative, with a nice DSL for defining
> > > GUI elements. Each component will also implement map, and use one of
> > > Clojure's reference types as an interface for inspecting / updating
> > > its state. I may also implement some aspects of Functional Reactive
> > > Programming wherever it's convenient to do so.
> > >
> > > What you all must help me decide is what GUI framework to use as the
> > > underpinnings of it. It's genuinely hard to decide. I have at least
> > > some experience with all of them, so I have no strong preference, but
> > > I'd like to get your input. I did consider trying to make it abstract
> > > enough that you could plug in *any* of them under the hood, but
> > > there's enough differences between the frameworks that that would get
> > > very ugly very fast.
> > >
> > > Possibilities are:
> > >
> > > AWT
> > > Pros: native widgets, bundled with Java, low-level
> > > Cons: few widgets, considered somewhat obselete
> > >
> > > Swing
> > > Pros: bundled with Java, good widget selection
> > > Cons: non-native widgets
> > >
> > > SWT
> > > Pros: native widgets, widely used
> > > Cons: requires platform-specific libs
> > >
> > > QT Jambi
> > > Pros: native widgets, huge widget selection, highly-regarded framework
> > > Cons: requires platform-specific libs, writing custom widgets is
> > > hairy, momentum and support seem to be lagging since Nokia dropped
> > > official support.
> > >
> > > Remember, 

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Jason Zwolak]

You can diff JavaFX components like that?

--
Jason Zwolak

On Thu, Mar 17, 2016 at 12:51 PM, Timothy Baldridge 
wrote:

> >> If the app-state has changed then it starts re-rendering the UI.
>
> That's pretty much exactly what fn-fx does in the latest version, with two
> caveats: 1) there's no timer, just a watch on an atom. 2) If you properly
> diff components you don't need to re-create them every time, just change
> the properties that changed. So if you have a text box 5 components deep in
> your app, and you change the background color, only the background color
> property of that single component will be changed, the rest of the app will
> remain unmodified.
>
> On Thu, Mar 17, 2016 at 10:37 AM, Jason Zwolak  wrote:
>
>> Paul, yeap, Seesaw is definitely something worth considering. Dave Ray
>> hasn't abandoned the project, but I sent a personal email to him asking
>> about the state of the project and it does seem the Seesaw is in more of a
>> maintenance phase than a continue to move forward and improve phase. Dave
>> Ray, if you're on this list, would you chime in?
>>
>> Also, I was at the talk you mentioned and was very impressed with their
>> methods. What wasn't mentioned in the talk was the fundamental structure of
>> the interface between Clojure and JavaFX. One point that _really_ struck me
>> is that they have a reoccurring timer running in the background and each
>> time it wakes up it checks for changes on the app-state (presumably an
>> atom, but I do not remember). If the app-state has changed then it starts
>> re-rendering the UI. If I remember correctly it recreates the UI components
>> that rely on any part of the app state that has changed. It sounds a little
>> similar to Facebook React. I questioned them on this approach as it sounded
>> strange to me... and they convinced me it's a good approach for their
>> project and inspired me to try something similar on my own... which I'm
>> secretly working on ;-)
>>
>> One thing that makes this work so well for their approach is that they
>> have animations that depend on the app state. So their reoccurring timer is
>> almost like a video algorithm redrawing the on screen image at the
>> specified frame rate.
>>
>> --
>> Jason Zwolak
>>
>> On Thu, Mar 17, 2016 at 11:06 AM, Paul L. Snyder <
>> p...@pataprogramming.com> wrote:
>>
>>> Yow, old indeed!
>>>
>>> In 2011, Dave Ray released Seesaw, which is a very nice wrapper for
>>> Swing.
>>> I've used it for a bunch of projects, and it works great. Of course, it
>>> does look like Swing, but it's plenty usable. (It's also still being
>>> maintained, so if you're looking for a toolkit that you can use right
>>> now,
>>> it's a good way to go.)
>>>
>>>   https://github.com/daveray/seesaw
>>>
>>> That said, I'd also love to see a JavaFX wrapper. At the Conj in Philly,
>>> Cognitect talked about a project where they'd used it extensively:
>>>
>>>   https://www.youtube.com/watch?v=ajX09xQ_UEg
>>>
>>> It's definitely piqued my interest.
>>>
>>> Paul
>>>
>>> On Sat, 12 Mar 2016, Jason Zwolak wrote:
>>>
>>> > +1 JavaFX.
>>> >
>>> > I know this is an old thread... but in case anyone comes across it
>>> (like I
>>> > did just now) and wants to see where things are, they should know that
>>> > JavaFX has come a long way and seems to be Oracle's replacement for
>>> Swing.
>>> > Now JavaFX is no longer only in JavaFXscript... in fact, I believe
>>> > JavaFXscript is deprecated in favor of the JavaFX Java classes.
>>> >
>>> > I've seen some major projects done with Clojure and JavaFX... even
>>> from the
>>> > guys at Cognitect.
>>> >
>>> > On Thursday, May 27, 2010 at 11:18:41 AM UTC-4, Luke VanderHart wrote:
>>> > >
>>> > > My side project is a fairly complex GUI application written in
>>> > > Clojure. Recently, I've become irritated with using Java interop for
>>> > > everything. It's not that Clojure doesn't have nice java interop - it
>>> > > does. It's just that when interacting with a GUI framework, which is
>>> a
>>> > > large part of my app, I have to be back in mutable object-oriented
>>> > > land, worrying about class hierarchies, mutable state, locks, etc.
>>> > > Yucky.
>>> > >
>>> > > So, with a perhaps dangerous lack of sanity and without any guarantee
>>> > > of success, I've decided to try my hand at writing an idiomatic
>>> > > Clojure GUI library. If I have success (which I doubt) I will of
>>> > > course make it available as open source.
>>> > >
>>> > > I intend for it to be mostly declarative, with a nice DSL for
>>> defining
>>> > > GUI elements. Each component will also implement map, and use one of
>>> > > Clojure's reference types as an interface for inspecting / updating
>>> > > its state. I may also implement some aspects of Functional Reactive
>>> > > Programming wherever it's convenient to do so.
>>> > >
>>> > > What you all must help me decide is what GUI framework to use as the
>>> > > underpinnings of it. It's genuinely hard to 

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Mathias De Wachter]

Hi Timothy,
I'm really glad to see some new commits on fn(fx)! I don't know about others, 
but you'll definitely have at least one very enthusiastic user if I can get to 
a point where I can use it easily for simple things, and adapt/contribute for 
more complex things.
Do you think the project is in that state already? (Haven't tried yet...)
Thanks,
Mathias

-- 
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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Timothy Baldridge]

It uses the same sort of logic that React does. Fn-fx creates a virtual
dom, and then diffs the previous virtual dom against the updated one. From
there you get a list of necessary updates. JavaFX has a rather uniform
property interface so applying these updates is quite simple.

On Thu, Mar 17, 2016 at 11:26 AM, Jason Zwolak  wrote:

> You can diff JavaFX components like that?
>
> --
> Jason Zwolak
>
> On Thu, Mar 17, 2016 at 12:51 PM, Timothy Baldridge 
> wrote:
>
>> >> If the app-state has changed then it starts re-rendering the UI.
>>
>> That's pretty much exactly what fn-fx does in the latest version, with
>> two caveats: 1) there's no timer, just a watch on an atom. 2) If you
>> properly diff components you don't need to re-create them every time, just
>> change the properties that changed. So if you have a text box 5 components
>> deep in your app, and you change the background color, only the background
>> color property of that single component will be changed, the rest of the
>> app will remain unmodified.
>>
>> On Thu, Mar 17, 2016 at 10:37 AM, Jason Zwolak  wrote:
>>
>>> Paul, yeap, Seesaw is definitely something worth considering. Dave Ray
>>> hasn't abandoned the project, but I sent a personal email to him asking
>>> about the state of the project and it does seem the Seesaw is in more of a
>>> maintenance phase than a continue to move forward and improve phase. Dave
>>> Ray, if you're on this list, would you chime in?
>>>
>>> Also, I was at the talk you mentioned and was very impressed with their
>>> methods. What wasn't mentioned in the talk was the fundamental structure of
>>> the interface between Clojure and JavaFX. One point that _really_ struck me
>>> is that they have a reoccurring timer running in the background and each
>>> time it wakes up it checks for changes on the app-state (presumably an
>>> atom, but I do not remember). If the app-state has changed then it starts
>>> re-rendering the UI. If I remember correctly it recreates the UI components
>>> that rely on any part of the app state that has changed. It sounds a little
>>> similar to Facebook React. I questioned them on this approach as it sounded
>>> strange to me... and they convinced me it's a good approach for their
>>> project and inspired me to try something similar on my own... which I'm
>>> secretly working on ;-)
>>>
>>> One thing that makes this work so well for their approach is that they
>>> have animations that depend on the app state. So their reoccurring timer is
>>> almost like a video algorithm redrawing the on screen image at the
>>> specified frame rate.
>>>
>>> --
>>> Jason Zwolak
>>>
>>> On Thu, Mar 17, 2016 at 11:06 AM, Paul L. Snyder <
>>> p...@pataprogramming.com> wrote:
>>>
 Yow, old indeed!

 In 2011, Dave Ray released Seesaw, which is a very nice wrapper for
 Swing.
 I've used it for a bunch of projects, and it works great. Of course, it
 does look like Swing, but it's plenty usable. (It's also still being
 maintained, so if you're looking for a toolkit that you can use right
 now,
 it's a good way to go.)

   https://github.com/daveray/seesaw

 That said, I'd also love to see a JavaFX wrapper. At the Conj in Philly,
 Cognitect talked about a project where they'd used it extensively:

   https://www.youtube.com/watch?v=ajX09xQ_UEg

 It's definitely piqued my interest.

 Paul

 On Sat, 12 Mar 2016, Jason Zwolak wrote:

 > +1 JavaFX.
 >
 > I know this is an old thread... but in case anyone comes across it
 (like I
 > did just now) and wants to see where things are, they should know that
 > JavaFX has come a long way and seems to be Oracle's replacement for
 Swing.
 > Now JavaFX is no longer only in JavaFXscript... in fact, I believe
 > JavaFXscript is deprecated in favor of the JavaFX Java classes.
 >
 > I've seen some major projects done with Clojure and JavaFX... even
 from the
 > guys at Cognitect.
 >
 > On Thursday, May 27, 2010 at 11:18:41 AM UTC-4, Luke VanderHart wrote:
 > >
 > > My side project is a fairly complex GUI application written in
 > > Clojure. Recently, I've become irritated with using Java interop for
 > > everything. It's not that Clojure doesn't have nice java interop -
 it
 > > does. It's just that when interacting with a GUI framework, which
 is a
 > > large part of my app, I have to be back in mutable object-oriented
 > > land, worrying about class hierarchies, mutable state, locks, etc.
 > > Yucky.
 > >
 > > So, with a perhaps dangerous lack of sanity and without any
 guarantee
 > > of success, I've decided to try my hand at writing an idiomatic
 > > Clojure GUI library. If I have success (which I doubt) I will of
 > > course make it available as open source.
 > >
 > > I intend for it to be 

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Colin Fleming]

That sounds great Timothy, thanks!

On 18 March 2016 at 06:32, Timothy Baldridge  wrote:

> It uses the same sort of logic that React does. Fn-fx creates a virtual
> dom, and then diffs the previous virtual dom against the updated one. From
> there you get a list of necessary updates. JavaFX has a rather uniform
> property interface so applying these updates is quite simple.
>
> On Thu, Mar 17, 2016 at 11:26 AM, Jason Zwolak  wrote:
>
>> You can diff JavaFX components like that?
>>
>> --
>> Jason Zwolak
>>
>> On Thu, Mar 17, 2016 at 12:51 PM, Timothy Baldridge > > wrote:
>>
>>> >> If the app-state has changed then it starts re-rendering the UI.
>>>
>>> That's pretty much exactly what fn-fx does in the latest version, with
>>> two caveats: 1) there's no timer, just a watch on an atom. 2) If you
>>> properly diff components you don't need to re-create them every time, just
>>> change the properties that changed. So if you have a text box 5 components
>>> deep in your app, and you change the background color, only the background
>>> color property of that single component will be changed, the rest of the
>>> app will remain unmodified.
>>>
>>> On Thu, Mar 17, 2016 at 10:37 AM, Jason Zwolak 
>>> wrote:
>>>
 Paul, yeap, Seesaw is definitely something worth considering. Dave Ray
 hasn't abandoned the project, but I sent a personal email to him asking
 about the state of the project and it does seem the Seesaw is in more of a
 maintenance phase than a continue to move forward and improve phase. Dave
 Ray, if you're on this list, would you chime in?

 Also, I was at the talk you mentioned and was very impressed with their
 methods. What wasn't mentioned in the talk was the fundamental structure of
 the interface between Clojure and JavaFX. One point that _really_ struck me
 is that they have a reoccurring timer running in the background and each
 time it wakes up it checks for changes on the app-state (presumably an
 atom, but I do not remember). If the app-state has changed then it starts
 re-rendering the UI. If I remember correctly it recreates the UI components
 that rely on any part of the app state that has changed. It sounds a little
 similar to Facebook React. I questioned them on this approach as it sounded
 strange to me... and they convinced me it's a good approach for their
 project and inspired me to try something similar on my own... which I'm
 secretly working on ;-)

 One thing that makes this work so well for their approach is that they
 have animations that depend on the app state. So their reoccurring timer is
 almost like a video algorithm redrawing the on screen image at the
 specified frame rate.

 --
 Jason Zwolak

 On Thu, Mar 17, 2016 at 11:06 AM, Paul L. Snyder <
 p...@pataprogramming.com> wrote:

> Yow, old indeed!
>
> In 2011, Dave Ray released Seesaw, which is a very nice wrapper for
> Swing.
> I've used it for a bunch of projects, and it works great. Of course, it
> does look like Swing, but it's plenty usable. (It's also still being
> maintained, so if you're looking for a toolkit that you can use right
> now,
> it's a good way to go.)
>
>   https://github.com/daveray/seesaw
>
> That said, I'd also love to see a JavaFX wrapper. At the Conj in
> Philly,
> Cognitect talked about a project where they'd used it extensively:
>
>   https://www.youtube.com/watch?v=ajX09xQ_UEg
>
> It's definitely piqued my interest.
>
> Paul
>
> On Sat, 12 Mar 2016, Jason Zwolak wrote:
>
> > +1 JavaFX.
> >
> > I know this is an old thread... but in case anyone comes across it
> (like I
> > did just now) and wants to see where things are, they should know
> that
> > JavaFX has come a long way and seems to be Oracle's replacement for
> Swing.
> > Now JavaFX is no longer only in JavaFXscript... in fact, I believe
> > JavaFXscript is deprecated in favor of the JavaFX Java classes.
> >
> > I've seen some major projects done with Clojure and JavaFX... even
> from the
> > guys at Cognitect.
> >
> > On Thursday, May 27, 2010 at 11:18:41 AM UTC-4, Luke VanderHart
> wrote:
> > >
> > > My side project is a fairly complex GUI application written in
> > > Clojure. Recently, I've become irritated with using Java interop
> for
> > > everything. It's not that Clojure doesn't have nice java interop -
> it
> > > does. It's just that when interacting with a GUI framework, which
> is a
> > > large part of my app, I have to be back in mutable object-oriented
> > > land, worrying about class hierarchies, mutable state, locks, etc.
> > > Yucky.
> > >
> > > So, with a perhaps dangerous lack of sanity and without any

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Kimmo Koskinen]

This could be React on desktop, +1 for that :)

-- 
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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Dave Ray]

Inline below..

Dave

On Thu, Mar 17, 2016 at 9:37 AM, Jason Zwolak  wrote:

> Paul, yeap, Seesaw is definitely something worth considering. Dave Ray
> hasn't abandoned the project, but I sent a personal email to him asking
> about the state of the project and it does seem the Seesaw is in more of a
> maintenance phase than a continue to move forward and improve phase. Dave
> Ray, if you're on this list, would you chime in?
>

 Yep. Seesaw's definitely in maintenance mode. Once upon a time it
overlapped a lot with my day job, but not anymore so I just don't have a
ton of enthusiasm to spend time on it. I'd be open to new maintainers if
someone's feeling adventurous. Otherwise, JavaFX seems like the future so I
think effort would probably be better spent there. A lot has changed in UI
land in the last 5 years.


> Also, I was at the talk you mentioned and was very impressed with their
> methods. What wasn't mentioned in the talk was the fundamental structure of
> the interface between Clojure and JavaFX. One point that _really_ struck me
> is that they have a reoccurring timer running in the background and each
> time it wakes up it checks for changes on the app-state (presumably an
> atom, but I do not remember). If the app-state has changed then it starts
> re-rendering the UI. If I remember correctly it recreates the UI components
> that rely on any part of the app state that has changed. It sounds a little
> similar to Facebook React. I questioned them on this approach as it sounded
> strange to me... and they convinced me it's a good approach for their
> project and inspired me to try something similar on my own... which I'm
> secretly working on ;-)
>
> One thing that makes this work so well for their approach is that they
> have animations that depend on the app state. So their reoccurring timer is
> almost like a video algorithm redrawing the on screen image at the
> specified frame rate.
>
> --
> Jason Zwolak
>
> On Thu, Mar 17, 2016 at 11:06 AM, Paul L. Snyder  > wrote:
>
>> Yow, old indeed!
>>
>> In 2011, Dave Ray released Seesaw, which is a very nice wrapper for Swing.
>> I've used it for a bunch of projects, and it works great. Of course, it
>> does look like Swing, but it's plenty usable. (It's also still being
>> maintained, so if you're looking for a toolkit that you can use right now,
>> it's a good way to go.)
>>
>>   https://github.com/daveray/seesaw
>>
>> That said, I'd also love to see a JavaFX wrapper. At the Conj in Philly,
>> Cognitect talked about a project where they'd used it extensively:
>>
>>   https://www.youtube.com/watch?v=ajX09xQ_UEg
>>
>> It's definitely piqued my interest.
>>
>> Paul
>>
>> On Sat, 12 Mar 2016, Jason Zwolak wrote:
>>
>> > +1 JavaFX.
>> >
>> > I know this is an old thread... but in case anyone comes across it
>> (like I
>> > did just now) and wants to see where things are, they should know that
>> > JavaFX has come a long way and seems to be Oracle's replacement for
>> Swing.
>> > Now JavaFX is no longer only in JavaFXscript... in fact, I believe
>> > JavaFXscript is deprecated in favor of the JavaFX Java classes.
>> >
>> > I've seen some major projects done with Clojure and JavaFX... even from
>> the
>> > guys at Cognitect.
>> >
>> > On Thursday, May 27, 2010 at 11:18:41 AM UTC-4, Luke VanderHart wrote:
>> > >
>> > > My side project is a fairly complex GUI application written in
>> > > Clojure. Recently, I've become irritated with using Java interop for
>> > > everything. It's not that Clojure doesn't have nice java interop - it
>> > > does. It's just that when interacting with a GUI framework, which is a
>> > > large part of my app, I have to be back in mutable object-oriented
>> > > land, worrying about class hierarchies, mutable state, locks, etc.
>> > > Yucky.
>> > >
>> > > So, with a perhaps dangerous lack of sanity and without any guarantee
>> > > of success, I've decided to try my hand at writing an idiomatic
>> > > Clojure GUI library. If I have success (which I doubt) I will of
>> > > course make it available as open source.
>> > >
>> > > I intend for it to be mostly declarative, with a nice DSL for defining
>> > > GUI elements. Each component will also implement map, and use one of
>> > > Clojure's reference types as an interface for inspecting / updating
>> > > its state. I may also implement some aspects of Functional Reactive
>> > > Programming wherever it's convenient to do so.
>> > >
>> > > What you all must help me decide is what GUI framework to use as the
>> > > underpinnings of it. It's genuinely hard to decide. I have at least
>> > > some experience with all of them, so I have no strong preference, but
>> > > I'd like to get your input. I did consider trying to make it abstract
>> > > enough that you could plug in *any* of them under the hood, but
>> > > there's enough differences between the frameworks that that would get
>> > > very ugly very fast.
>> > >
>> > > Possibilities are:
>> > >

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Mark Engelberg]

I'm also interested in JavaFX from Clojure.

-- 
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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Timothy Baldridge]

I've been working on a "React for JavaFX" library for some time. Sadly I
have no use for the library, so I haven't talked about it much yet. But the
newest iteration has a interface I'm pretty happy with:

https://github.com/halgari/fn-fx/blob/master/test/fn_fx/fx_dom_test.clj#L97-L145

If there was enough of a need for this sort of thing I could be convinced
to work on it more.



On Thu, Mar 17, 2016 at 9:06 AM, Paul L. Snyder 
wrote:

> Yow, old indeed!
>
> In 2011, Dave Ray released Seesaw, which is a very nice wrapper for Swing.
> I've used it for a bunch of projects, and it works great. Of course, it
> does look like Swing, but it's plenty usable. (It's also still being
> maintained, so if you're looking for a toolkit that you can use right now,
> it's a good way to go.)
>
>   https://github.com/daveray/seesaw
>
> That said, I'd also love to see a JavaFX wrapper. At the Conj in Philly,
> Cognitect talked about a project where they'd used it extensively:
>
>   https://www.youtube.com/watch?v=ajX09xQ_UEg
>
> It's definitely piqued my interest.
>
> Paul
>
> On Sat, 12 Mar 2016, Jason Zwolak wrote:
>
> > +1 JavaFX.
> >
> > I know this is an old thread... but in case anyone comes across it (like
> I
> > did just now) and wants to see where things are, they should know that
> > JavaFX has come a long way and seems to be Oracle's replacement for
> Swing.
> > Now JavaFX is no longer only in JavaFXscript... in fact, I believe
> > JavaFXscript is deprecated in favor of the JavaFX Java classes.
> >
> > I've seen some major projects done with Clojure and JavaFX... even from
> the
> > guys at Cognitect.
> >
> > On Thursday, May 27, 2010 at 11:18:41 AM UTC-4, Luke VanderHart wrote:
> > >
> > > My side project is a fairly complex GUI application written in
> > > Clojure. Recently, I've become irritated with using Java interop for
> > > everything. It's not that Clojure doesn't have nice java interop - it
> > > does. It's just that when interacting with a GUI framework, which is a
> > > large part of my app, I have to be back in mutable object-oriented
> > > land, worrying about class hierarchies, mutable state, locks, etc.
> > > Yucky.
> > >
> > > So, with a perhaps dangerous lack of sanity and without any guarantee
> > > of success, I've decided to try my hand at writing an idiomatic
> > > Clojure GUI library. If I have success (which I doubt) I will of
> > > course make it available as open source.
> > >
> > > I intend for it to be mostly declarative, with a nice DSL for defining
> > > GUI elements. Each component will also implement map, and use one of
> > > Clojure's reference types as an interface for inspecting / updating
> > > its state. I may also implement some aspects of Functional Reactive
> > > Programming wherever it's convenient to do so.
> > >
> > > What you all must help me decide is what GUI framework to use as the
> > > underpinnings of it. It's genuinely hard to decide. I have at least
> > > some experience with all of them, so I have no strong preference, but
> > > I'd like to get your input. I did consider trying to make it abstract
> > > enough that you could plug in *any* of them under the hood, but
> > > there's enough differences between the frameworks that that would get
> > > very ugly very fast.
> > >
> > > Possibilities are:
> > >
> > > AWT
> > > Pros: native widgets, bundled with Java, low-level
> > > Cons: few widgets, considered somewhat obselete
> > >
> > > Swing
> > > Pros: bundled with Java, good widget selection
> > > Cons: non-native widgets
> > >
> > > SWT
> > > Pros: native widgets, widely used
> > > Cons: requires platform-specific libs
> > >
> > > QT Jambi
> > > Pros: native widgets, huge widget selection, highly-regarded framework
> > > Cons: requires platform-specific libs, writing custom widgets is
> > > hairy, momentum and support seem to be lagging since Nokia dropped
> > > official support.
> > >
> > > Remember, the actual API won't matter - that will be completely
> > > abstracted away. So try to focus on the framework's look and feel.
> > > Also let me know if I've missed any of the framework's key
> > > characteristics.
> > >
> > > Thanks!
> > >
> > > -Luke
> > >
> > >
> >
> > --
> > 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 

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Timothy Baldridge]

I dusted off the fn-fx code today and fixed a bunch of bugs, and
implemented a few examples: https://github.com/halgari/fn-fx

One of the most complex examples so far is here:
https://github.com/halgari/fn-fx/blob/master/examples/getting_started/02_form.clj

As you can see the library is capable of some rather decent UIs (grid
panes, event handlers, etc). This is mostly because the JavaFX API is very
uniform and therefore easy to generate wrappers/converters using reflection
and meta-programming.

I will probably continue working on this as time goes on, but to some
extent I need a good use case to drive development on fn(fx), so if anyone
has some OSS project or some swing app, they'd like to switch over to
fn(fx), drop me a line.

Timothy

On Fri, Mar 18, 2016 at 5:30 AM, Mathias De Wachter <
mathias.dewach...@gmail.com> wrote:

> Hi Timothy,
> I'm really glad to see some new commits on fn(fx)! I don't know about
> others, but you'll definitely have at least one very enthusiastic user if I
> can get to a point where I can use it easily for simple things, and
> adapt/contribute for more complex things.
> Do you think the project is in that state already? (Haven't tried yet...)
> Thanks,
> Mathias
>
> --
> 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Paul L. Snyder]

Yow, old indeed!

In 2011, Dave Ray released Seesaw, which is a very nice wrapper for Swing.
I've used it for a bunch of projects, and it works great. Of course, it 
does look like Swing, but it's plenty usable. (It's also still being
maintained, so if you're looking for a toolkit that you can use right now,
it's a good way to go.)

  https://github.com/daveray/seesaw

That said, I'd also love to see a JavaFX wrapper. At the Conj in Philly, 
Cognitect talked about a project where they'd used it extensively:

  https://www.youtube.com/watch?v=ajX09xQ_UEg

It's definitely piqued my interest.

Paul

On Sat, 12 Mar 2016, Jason Zwolak wrote:

> +1 JavaFX.
> 
> I know this is an old thread... but in case anyone comes across it (like I 
> did just now) and wants to see where things are, they should know that 
> JavaFX has come a long way and seems to be Oracle's replacement for Swing. 
> Now JavaFX is no longer only in JavaFXscript... in fact, I believe 
> JavaFXscript is deprecated in favor of the JavaFX Java classes.
> 
> I've seen some major projects done with Clojure and JavaFX... even from the 
> guys at Cognitect.
> 
> On Thursday, May 27, 2010 at 11:18:41 AM UTC-4, Luke VanderHart wrote:
> >
> > My side project is a fairly complex GUI application written in
> > Clojure. Recently, I've become irritated with using Java interop for
> > everything. It's not that Clojure doesn't have nice java interop - it
> > does. It's just that when interacting with a GUI framework, which is a
> > large part of my app, I have to be back in mutable object-oriented
> > land, worrying about class hierarchies, mutable state, locks, etc.
> > Yucky.
> >
> > So, with a perhaps dangerous lack of sanity and without any guarantee
> > of success, I've decided to try my hand at writing an idiomatic
> > Clojure GUI library. If I have success (which I doubt) I will of
> > course make it available as open source.
> >
> > I intend for it to be mostly declarative, with a nice DSL for defining
> > GUI elements. Each component will also implement map, and use one of
> > Clojure's reference types as an interface for inspecting / updating
> > its state. I may also implement some aspects of Functional Reactive
> > Programming wherever it's convenient to do so.
> >
> > What you all must help me decide is what GUI framework to use as the
> > underpinnings of it. It's genuinely hard to decide. I have at least
> > some experience with all of them, so I have no strong preference, but
> > I'd like to get your input. I did consider trying to make it abstract
> > enough that you could plug in *any* of them under the hood, but
> > there's enough differences between the frameworks that that would get
> > very ugly very fast.
> >
> > Possibilities are:
> >
> > AWT
> > Pros: native widgets, bundled with Java, low-level
> > Cons: few widgets, considered somewhat obselete
> >
> > Swing
> > Pros: bundled with Java, good widget selection
> > Cons: non-native widgets
> >
> > SWT
> > Pros: native widgets, widely used
> > Cons: requires platform-specific libs
> >
> > QT Jambi
> > Pros: native widgets, huge widget selection, highly-regarded framework
> > Cons: requires platform-specific libs, writing custom widgets is
> > hairy, momentum and support seem to be lagging since Nokia dropped
> > official support.
> >
> > Remember, the actual API won't matter - that will be completely
> > abstracted away. So try to focus on the framework's look and feel.
> > Also let me know if I've missed any of the framework's key
> > characteristics.
> >
> > Thanks!
> >
> > -Luke
> >
> >
> 
> -- 
> 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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[chgraham]

+1 JavaFX
 

-- 
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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Jason Zwolak]

+1 JavaFX.

I know this is an old thread... but in case anyone comes across it (like I 
did just now) and wants to see where things are, they should know that 
JavaFX has come a long way and seems to be Oracle's replacement for Swing. 
Now JavaFX is no longer only in JavaFXscript... in fact, I believe 
JavaFXscript is deprecated in favor of the JavaFX Java classes.

I've seen some major projects done with Clojure and JavaFX... even from the 
guys at Cognitect.

On Thursday, May 27, 2010 at 11:18:41 AM UTC-4, Luke VanderHart wrote:
>
> My side project is a fairly complex GUI application written in
> Clojure. Recently, I've become irritated with using Java interop for
> everything. It's not that Clojure doesn't have nice java interop - it
> does. It's just that when interacting with a GUI framework, which is a
> large part of my app, I have to be back in mutable object-oriented
> land, worrying about class hierarchies, mutable state, locks, etc.
> Yucky.
>
> So, with a perhaps dangerous lack of sanity and without any guarantee
> of success, I've decided to try my hand at writing an idiomatic
> Clojure GUI library. If I have success (which I doubt) I will of
> course make it available as open source.
>
> I intend for it to be mostly declarative, with a nice DSL for defining
> GUI elements. Each component will also implement map, and use one of
> Clojure's reference types as an interface for inspecting / updating
> its state. I may also implement some aspects of Functional Reactive
> Programming wherever it's convenient to do so.
>
> What you all must help me decide is what GUI framework to use as the
> underpinnings of it. It's genuinely hard to decide. I have at least
> some experience with all of them, so I have no strong preference, but
> I'd like to get your input. I did consider trying to make it abstract
> enough that you could plug in *any* of them under the hood, but
> there's enough differences between the frameworks that that would get
> very ugly very fast.
>
> Possibilities are:
>
> AWT
> Pros: native widgets, bundled with Java, low-level
> Cons: few widgets, considered somewhat obselete
>
> Swing
> Pros: bundled with Java, good widget selection
> Cons: non-native widgets
>
> SWT
> Pros: native widgets, widely used
> Cons: requires platform-specific libs
>
> QT Jambi
> Pros: native widgets, huge widget selection, highly-regarded framework
> Cons: requires platform-specific libs, writing custom widgets is
> hairy, momentum and support seem to be lagging since Nokia dropped
> official support.
>
> Remember, the actual API won't matter - that will be completely
> abstracted away. So try to focus on the framework's look and feel.
> Also let me know if I've missed any of the framework's key
> characteristics.
>
> Thanks!
>
> -Luke
>
>

-- 
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: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Luke VanderHart]

Ok... thanks everyone for the extended discussion. I'm thrilled to get
so much feedback - apparently something like this is much-desired.

Tentatively, based on the feedback in this thread, I'm going to
provide a thick API and a Swing implementation. I will *attempt* to
keep it abstract enough that if someone wants to provide an
alternative SWT (or even platform specific w/ JNI) backend, it will be
possible, at least in theory. I can't make any guarantee that
implementation will be easy, though, and I don't expect any
alternative implementation will be anything like a drop-in replacement
for the Swing one. But, at least if people really like the API (in
which I'm investing considerable thought), they can re-use it for
other GUIs.

The general consensus seems to be that Swing can meet 95% of use
cases. The remaining 5% who need truly polished native apps are
probably going to end up doing a lot of work anyway to look good
across platforms, so the right answer for them is probably to use a
native library directly. Meanwhile, the rest of us will have a quick,
easy way to write acceptable GUI interfaces with no extra work or
library management. My goal is Netbeans-like quality out of the box.

Later on this week I'll probably start posting some stuff to github -
Design philosophies, use cases, and APIs, upon which I'd appreciate
feedback. Implementations will follow as I get time to work on them.
Thanks to everyone who has expressed an interest in contributing; if
and when I feel the project has a clear direction and a little
momentum, I'd definitely like some others on board.

Again, thanks to everyone for your input.

-Luke


On May 27, 11:18 am, Luke VanderHart luke.vanderh...@gmail.com
wrote:
 My side project is a fairly complex GUI application written in
 Clojure. Recently, I've become irritated with using Java interop for
 everything. It's not that Clojure doesn't have nice java interop - it
 does. It's just that when interacting with a GUI framework, which is a
 large part of my app, I have to be back in mutable object-oriented
 land, worrying about class hierarchies, mutable state, locks, etc.
 Yucky.

 So, with a perhaps dangerous lack of sanity and without any guarantee
 of success, I've decided to try my hand at writing an idiomatic
 Clojure GUI library. If I have success (which I doubt) I will of
 course make it available as open source.

 I intend for it to be mostly declarative, with a nice DSL for defining
 GUI elements. Each component will also implement map, and use one of
 Clojure's reference types as an interface for inspecting / updating
 its state. I may also implement some aspects of Functional Reactive
 Programming wherever it's convenient to do so.

 What you all must help me decide is what GUI framework to use as the
 underpinnings of it. It's genuinely hard to decide. I have at least
 some experience with all of them, so I have no strong preference, but
 I'd like to get your input. I did consider trying to make it abstract
 enough that you could plug in *any* of them under the hood, but
 there's enough differences between the frameworks that that would get
 very ugly very fast.

 Possibilities are:

 AWT
 Pros: native widgets, bundled with Java, low-level
 Cons: few widgets, considered somewhat obselete

 Swing
 Pros: bundled with Java, good widget selection
 Cons: non-native widgets

 SWT
 Pros: native widgets, widely used
 Cons: requires platform-specific libs

 QT Jambi
 Pros: native widgets, huge widget selection, highly-regarded framework
 Cons: requires platform-specific libs, writing custom widgets is
 hairy, momentum and support seem to be lagging since Nokia dropped
 official support.

 Remember, the actual API won't matter - that will be completely
 abstracted away. So try to focus on the framework's look and feel.
 Also let me know if I've missed any of the framework's key
 characteristics.

 Thanks!

 -Luke

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Quzanti]

+1 Swing with caveats

Will Swing itself continue to receive serious backing from Oracle?
Will they get JavaFX to do everything Swing can and then deprecate
Swing (if not officially then in practice?) It really depends on
Netbeans. All the LF issues and other minor ones got attention when
Sun began eating its own dogfood and developing Netbeans with Swing.
Although having said that is JDeveloper built on top of Swing or SWT -
I think probably Swing as JBuilder was so Swing wins whichever tool
Oracle eventually standardises on.

An example of the point I am trying to make is resolution
independence. There was a big push for resolution independence in
Swing, which got a long way, but then since JavaFX came along all
efforts in that area seem to have been JavaFX focussed.

On May 27, 4:32 pm, Sean Devlin francoisdev...@gmail.com wrote:
 +1 Swing.  There's a ton of documentation out there, and it got some
 serious love from Sun between java 5 and 6.

 On May 27, 11:27 am, Laurent PETIT laurent.pe...@gmail.com wrote:

  Although I work with SWT at work, I would say Swing for 2 reasons :

    * no additional dependency for users of your lib, and *no need* for users
  of your lib to deliver different final apps binaries for different platforms
    * may be easier to work with in your implementation (?)

  2010/5/27 Luke VanderHart luke.vanderh...@gmail.com

   My side project is a fairly complex GUI application written in
   Clojure. Recently, I've become irritated with using Java interop for
   everything. It's not that Clojure doesn't have nice java interop - it
   does. It's just that when interacting with a GUI framework, which is a
   large part of my app, I have to be back in mutable object-oriented
   land, worrying about class hierarchies, mutable state, locks, etc.
   Yucky.

   So, with a perhaps dangerous lack of sanity and without any guarantee
   of success, I've decided to try my hand at writing an idiomatic
   Clojure GUI library. If I have success (which I doubt) I will of
   course make it available as open source.

   I intend for it to be mostly declarative, with a nice DSL for defining
   GUI elements. Each component will also implement map, and use one of
   Clojure's reference types as an interface for inspecting / updating
   its state. I may also implement some aspects of Functional Reactive
   Programming wherever it's convenient to do so.

   What you all must help me decide is what GUI framework to use as the
   underpinnings of it. It's genuinely hard to decide. I have at least
   some experience with all of them, so I have no strong preference, but
   I'd like to get your input. I did consider trying to make it abstract
   enough that you could plug in *any* of them under the hood, but
   there's enough differences between the frameworks that that would get
   very ugly very fast.

   Possibilities are:

   AWT
   Pros: native widgets, bundled with Java, low-level
   Cons: few widgets, considered somewhat obselete

   Swing
   Pros: bundled with Java, good widget selection
   Cons: non-native widgets

   SWT
   Pros: native widgets, widely used
   Cons: requires platform-specific libs

   QT Jambi
   Pros: native widgets, huge widget selection, highly-regarded framework
   Cons: requires platform-specific libs, writing custom widgets is
   hairy, momentum and support seem to be lagging since Nokia dropped
   official support.

   Remember, the actual API won't matter - that will be completely
   abstracted away. So try to focus on the framework's look and feel.
   Also let me know if I've missed any of the framework's key
   characteristics.

   Thanks!

   -Luke

   --
   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.comclojure%2bunsubscr...@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 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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Jeff Rose]

We would definitely be interested in using something like this for
Project Overtone. (http://project-overtone.org)  We have already
migrated from directly using Swing with the built-in Java interop, to
creating a thin layer of clojure functions to trim out the boiler
plate, to now wishing we had something more idiomatic.

Swing without question.  People who are complaining about the look
haven't explored what you can do with the pluggable look and feel
system.  For example, try the demo on the substance page, where they
have a variety of different themes implemented:

https://substance.dev.java.net/

My guess is that using Swing will get the library used by vastly more
applications, because it will be available as a quick GUI for little
utilities and sample apps, as well as full fledged applications.
Nobody is going to deal with the pain of SWT unless they have a
serious app to build, and even then deployment is a total pain.  And
no, it isn't a one time thing.  Dealing with cross platform, native
code is an ongoing process that continues to be annoying every time
any one of the host platforms upgrades the GUI libraries.  Just think,
how often does one of windows, mac or linux upgrade the libraries?

The much more interesting conversation is about the style of library
you are envisioning.  Although it would require a small dependency,
one thing I would think about doing is using the MigLayout engine for
all layout functionality, under the hood.  It provides you with the
capabilities of all the Swing layout engines, but the interface is
straight forward and makes it easy to evolve your GUI overtime without
having to keep shifting which type of layout classes you are using.

Probably the two key aspects of the library design are going to be the
way you register for and handle events, and the way you update widget
state.  Dangling references to widgets is also a typical source of
memory leaks, so finding a way to cleanly keep track of widgets and
get rid of them once they are not needed is going to be valuable.  In
Overtone we have been using a simple event system that lets you
register for events (namespaced keywords), and emit them easily.  This
works pretty well, although it isn't the easiest kind of code to
debug.  How would a functional reactive style library work?

On May 27, 5:18 pm, Luke VanderHart luke.vanderh...@gmail.com wrote:
 My side project is a fairly complex GUI application written in
 Clojure. Recently, I've become irritated with using Java interop for
 everything. It's not that Clojure doesn't have nice java interop - it
 does. It's just that when interacting with a GUI framework, which is a
 large part of my app, I have to be back in mutable object-oriented
 land, worrying about class hierarchies, mutable state, locks, etc.
 Yucky.

 So, with a perhaps dangerous lack of sanity and without any guarantee
 of success, I've decided to try my hand at writing an idiomatic
 Clojure GUI library. If I have success (which I doubt) I will of
 course make it available as open source.

 I intend for it to be mostly declarative, with a nice DSL for defining
 GUI elements. Each component will also implement map, and use one of
 Clojure's reference types as an interface for inspecting / updating
 its state. I may also implement some aspects of Functional Reactive
 Programming wherever it's convenient to do so.

 What you all must help me decide is what GUI framework to use as the
 underpinnings of it. It's genuinely hard to decide. I have at least
 some experience with all of them, so I have no strong preference, but
 I'd like to get your input. I did consider trying to make it abstract
 enough that you could plug in *any* of them under the hood, but
 there's enough differences between the frameworks that that would get
 very ugly very fast.

 Possibilities are:

 AWT
 Pros: native widgets, bundled with Java, low-level
 Cons: few widgets, considered somewhat obselete

 Swing
 Pros: bundled with Java, good widget selection
 Cons: non-native widgets

 SWT
 Pros: native widgets, widely used
 Cons: requires platform-specific libs

 QT Jambi
 Pros: native widgets, huge widget selection, highly-regarded framework
 Cons: requires platform-specific libs, writing custom widgets is
 hairy, momentum and support seem to be lagging since Nokia dropped
 official support.

 Remember, the actual API won't matter - that will be completely
 abstracted away. So try to focus on the framework's look and feel.
 Also let me know if I've missed any of the framework's key
 characteristics.

 Thanks!

 -Luke

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[abhi]

+1 for swing

On Thu, May 27, 2010 at 8:48 PM, Luke VanderHart
luke.vanderh...@gmail.com wrote:
 My side project is a fairly complex GUI application written in
 Clojure. Recently, I've become irritated with using Java interop for
 everything. It's not that Clojure doesn't have nice java interop - it
 does. It's just that when interacting with a GUI framework, which is a
 large part of my app, I have to be back in mutable object-oriented
 land, worrying about class hierarchies, mutable state, locks, etc.
 Yucky.

 So, with a perhaps dangerous lack of sanity and without any guarantee
 of success, I've decided to try my hand at writing an idiomatic
 Clojure GUI library. If I have success (which I doubt) I will of
 course make it available as open source.

 I intend for it to be mostly declarative, with a nice DSL for defining
 GUI elements. Each component will also implement map, and use one of
 Clojure's reference types as an interface for inspecting / updating
 its state. I may also implement some aspects of Functional Reactive
 Programming wherever it's convenient to do so.

 What you all must help me decide is what GUI framework to use as the
 underpinnings of it. It's genuinely hard to decide. I have at least
 some experience with all of them, so I have no strong preference, but
 I'd like to get your input. I did consider trying to make it abstract
 enough that you could plug in *any* of them under the hood, but
 there's enough differences between the frameworks that that would get
 very ugly very fast.

 Possibilities are:

 AWT
 Pros: native widgets, bundled with Java, low-level
 Cons: few widgets, considered somewhat obselete

 Swing
 Pros: bundled with Java, good widget selection
 Cons: non-native widgets

 SWT
 Pros: native widgets, widely used
 Cons: requires platform-specific libs

 QT Jambi
 Pros: native widgets, huge widget selection, highly-regarded framework
 Cons: requires platform-specific libs, writing custom widgets is
 hairy, momentum and support seem to be lagging since Nokia dropped
 official support.

 Remember, the actual API won't matter - that will be completely
 abstracted away. So try to focus on the framework's look and feel.
 Also let me know if I've missed any of the framework's key
 characteristics.

 Thanks!

 -Luke















 --
 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 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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[faenvie]

in case, you want to abstract over swing ...

there is this guy from germany: Karsten Lentzsch. he is author of
http://www.jgoodies.com/ and has incredible knowledge about swing
and esp. in abstracting over swing.

He knows all the strongs and weaknesses of swing and beeing involved
in http://www.jgoodies.com/articles/jsr296_de.pdf he tried to move
things
forward but was not very lucky doing so - according to his
presentation at
the wjax munich in Oktober last year.

maybe Karsten could be asked  for his expertise ...

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Brian Troutwine]

+1 swing. Even if the resulting applications are as ugly as sin, a
working, idiomatic implementation gives us a reference point from
which to dream up better futures.

On Sun, May 30, 2010 at 10:38 PM, Antony Blakey antony.bla...@gmail.com wrote:

 On 31/05/2010, at 2:27 PM, James Cunningham wrote:



 On May 30, 9:23 pm, Antony Blakey antony.bla...@gmail.com wrote:
 I care about Mac and Windows primarily, and building software that will 
 sell (not dev tools) requires good native look and feel.

 Do you have a single example of an SWT app that has a decent feel on
 OS X? I've spent a fair amount of time with Eclipse lately, and---
 frankly---it feels about as native as an Alabaman in Nice. No native
 toolbar, no native tabs, slower and uglier than either Netbeans or
 Intellij. My only other experience with an SWT app was entirely
 negative from a performance and look-and-feel perspective (Vuze).

 Vuze looks OK to me in the 5 minutes I've just spent. In any case, my opinion 
 comes from doing parallel GUI development in IB and SWT to see if I could use 
 Clojure/SWT rather than MacRuby (XCode/IB). I'm not using the RCP which 
 imprints it's own not-really-OSX flavour in spite of the widgets.

 You have to do more than just use SWT to get a Mac application to feel right, 
 and one's GUI layout code needs to be parametric and rules based, rather than 
 just swapping the LF. That said, it's still easier than writing three UIs.

 Antony Blakey
 -
 CTO, Linkuistics Pty Ltd
 Ph: 0438 840 787

 The intuitive mind is a sacred gift and the rational mind is a faithful 
 servant. We have created a society that honours the servant and has forgotten 
 the gift.
  -- Albert Einstein


 --
 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 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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[laseray]

Let the best decider of a GUI toolkit be based on pragmatism and
design philosophy.

To that end Swing wins.

Clojure runs on JVM and takes advantage of anything Java that it does
not provide for in a Lispy way.
Swing is just another one of those things automatically there, which
can have a nice layer to make it more useful, interesting.

Clojure does not include any extra libraries, except ASM, to operate.
Won't need any extra ones by using a Swing-based layer.

Clojure is completely cross-platform with supported OS for Java. A
Swing layer will be also.

Clojure can already create simple GUIs with Swing in a few lines of
code. It can only get better with a dedicated layer.

Swing is already a good selling point for Clojure. It actually is
promoting Clojure to have read Swing support intrinsically.

You cannot say these things about any other toolkit at this time.

I am willing to do some work on the Swing layer, if it is wanted. If
others want to work on SWT, Tk, etc. they can do that.
That's what it comes down to, where the effort is put.

I will step up to put some of mine behind the Swing-based one, anybody
else?

Voting and debating points are okay, but results are better. Swing is
already a result, a layer is just furthering it.

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[lprefontaine]

We are willing to put some time into this at our end.
We are in the process of replacing our Java desktop apps by Clojure apps.
Removing Java code is a mid-term goal that we want to keep in our scope
as we move on.

Anything to reduce code size is a welcomed.

How and when do we start this ?

Luc P.

laseray lase...@gmail.com wrote ..
 Let the best decider of a GUI toolkit be based on pragmatism and
 design philosophy.
 
 To that end Swing wins.
 
 Clojure runs on JVM and takes advantage of anything Java that it does
 not provide for in a Lispy way.
 Swing is just another one of those things automatically there, which
 can have a nice layer to make it more useful, interesting.
 
 Clojure does not include any extra libraries, except ASM, to operate.
 Won't need any extra ones by using a Swing-based layer.
 
 Clojure is completely cross-platform with supported OS for Java. A
 Swing layer will be also.
 
 Clojure can already create simple GUIs with Swing in a few lines of
 code. It can only get better with a dedicated layer.
 
 Swing is already a good selling point for Clojure. It actually is
 promoting Clojure to have read Swing support intrinsically.
 
 You cannot say these things about any other toolkit at this time.
 
 I am willing to do some work on the Swing layer, if it is wanted. If
 others want to work on SWT, Tk, etc. they can do that.
 That's what it comes down to, where the effort is put.
 
 I will step up to put some of mine behind the Swing-based one, anybody
 else?
 
 Voting and debating points are okay, but results are better. Swing is
 already a result, a layer is just furthering it.
 
 -- 
 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 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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Joonas Pulakka]

I've been using Swing. But, one thing to consider is that many (most?)
big applications use extension libraries such as JIDE (https://jide-
oss.dev.java.net/), SwingX (https://swingx.dev.java.net/) or Flamingo
(https://flamingo.dev.java.net/). They contain extra widgets that have
their own extra APIs of course. So while abstracting the JDK
Swing (or any other toolkit) away would be a huge thing, it would be
somewhat lacking regardless.

Do you think the DSL you described would be easily extensible to work
with that kind of extension libraries? If not, maybe that could be one
reason to use a some other toolkit (more complete than basic Swing) as
a base for the DSL.

Best Regards,
Joonas

On May 27, 6:18 pm, Luke VanderHart luke.vanderh...@gmail.com wrote:
 My side project is a fairly complex GUI application written in
 Clojure. Recently, I've become irritated with using Java interop for
 everything. It's not that Clojure doesn't have nice java interop - it
 does. It's just that when interacting with a GUI framework, which is a
 large part of my app, I have to be back in mutable object-oriented
 land, worrying about class hierarchies, mutable state, locks, etc.
 Yucky.

 So, with a perhaps dangerous lack of sanity and without any guarantee
 of success, I've decided to try my hand at writing an idiomatic
 Clojure GUI library. If I have success (which I doubt) I will of
 course make it available as open source.

 I intend for it to be mostly declarative, with a nice DSL for defining
 GUI elements. Each component will also implement map, and use one of
 Clojure's reference types as an interface for inspecting / updating
 its state. I may also implement some aspects of Functional Reactive
 Programming wherever it's convenient to do so.

 What you all must help me decide is what GUI framework to use as the
 underpinnings of it. It's genuinely hard to decide. I have at least
 some experience with all of them, so I have no strong preference, but
 I'd like to get your input. I did consider trying to make it abstract
 enough that you could plug in *any* of them under the hood, but
 there's enough differences between the frameworks that that would get
 very ugly very fast.

 Possibilities are:

 AWT
 Pros: native widgets, bundled with Java, low-level
 Cons: few widgets, considered somewhat obselete

 Swing
 Pros: bundled with Java, good widget selection
 Cons: non-native widgets

 SWT
 Pros: native widgets, widely used
 Cons: requires platform-specific libs

 QT Jambi
 Pros: native widgets, huge widget selection, highly-regarded framework
 Cons: requires platform-specific libs, writing custom widgets is
 hairy, momentum and support seem to be lagging since Nokia dropped
 official support.

 Remember, the actual API won't matter - that will be completely
 abstracted away. So try to focus on the framework's look and feel.
 Also let me know if I've missed any of the framework's key
 characteristics.

 Thanks!

 -Luke

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Daniel]

You could be really odd and write a wrapper for Edje.

http://trac.enlightenment.org/e/wiki/Edje

Not a serious recommendation, really.  I just don't have any strong
positive opinions regarding any of the others except for QT, and as
you say

On May 27, 10:18 am, Luke VanderHart luke.vanderh...@gmail.com
wrote:
 My side project is a fairly complex GUI application written in
 Clojure. Recently, I've become irritated with using Java interop for
 everything. It's not that Clojure doesn't have nice java interop - it
 does. It's just that when interacting with a GUI framework, which is a
 large part of my app, I have to be back in mutable object-oriented
 land, worrying about class hierarchies, mutable state, locks, etc.
 Yucky.

 So, with a perhaps dangerous lack of sanity and without any guarantee
 of success, I've decided to try my hand at writing an idiomatic
 Clojure GUI library. If I have success (which I doubt) I will of
 course make it available as open source.

 I intend for it to be mostly declarative, with a nice DSL for defining
 GUI elements. Each component will also implement map, and use one of
 Clojure's reference types as an interface for inspecting / updating
 its state. I may also implement some aspects of Functional Reactive
 Programming wherever it's convenient to do so.

 What you all must help me decide is what GUI framework to use as the
 underpinnings of it. It's genuinely hard to decide. I have at least
 some experience with all of them, so I have no strong preference, but
 I'd like to get your input. I did consider trying to make it abstract
 enough that you could plug in *any* of them under the hood, but
 there's enough differences between the frameworks that that would get
 very ugly very fast.

 Possibilities are:

 AWT
 Pros: native widgets, bundled with Java, low-level
 Cons: few widgets, considered somewhat obselete

 Swing
 Pros: bundled with Java, good widget selection
 Cons: non-native widgets

 SWT
 Pros: native widgets, widely used
 Cons: requires platform-specific libs

 QT Jambi
 Pros: native widgets, huge widget selection, highly-regarded framework
 Cons: requires platform-specific libs, writing custom widgets is
 hairy, momentum and support seem to be lagging since Nokia dropped
 official support.

 Remember, the actual API won't matter - that will be completely
 abstracted away. So try to focus on the framework's look and feel.
 Also let me know if I've missed any of the framework's key
 characteristics.

 Thanks!

 -Luke

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Wilson MacGyver]

JavaFx has one other major issue. The scene graph isn't accessible outside
of JavaFx script.


On Friday, May 28, 2010, Luke VanderHart luke.vanderh...@gmail.com wrote:
 My understanding may be wrong, but I think JavaFX is intended more as
 a competitor to Flash or Silverlight than a GUI toolkit. It'd probably
 be great for a Clojure games framework, or for simple graphical
 drawing and such, but I'm not sure it's appropriate for a complex,
 high performance GUI. In fact, according to the Wiki page, if you want
 to use desktop style widgets, you actually end up embedding Swing
 components *within* JavaFX anyway.

 On May 28, 9:59 am, mmwaikar mmwai...@gmail.com wrote:
 I work on .Net, so my observation could be totally wrong, but I think
 JavaFx could be an option to consider (specially because of its JSON
 kind of syntax).
 I am working on a WPF project currently, and although WPF is big and
 complex, the kind of UIs one can build with it is amazing, and JavaFx
 looked similar to me in intent and purpose.

 So I am really surprised why no one mentioned JavaFx. Is it because
 it's new?

 On May 27, 11:18 am, Luke VanderHart luke.vanderh...@gmail.com
 wrote:

  My side project is a fairly complex GUI application written in
  Clojure. Recently, I've become irritated with using Java interop for
  everything. It's not that Clojure doesn't have nice java interop - it
  does. It's just that when interacting with a GUI framework, which is a
  large part of my app, I have to be back in mutable object-oriented
  land, worrying about class hierarchies, mutable state, locks, etc.
  Yucky.

  So, with a perhaps dangerous lack of sanity and without any guarantee
  of success, I've decided to try my hand at writing an idiomatic
  Clojure GUI library. If I have success (which I doubt) I will of
  course make it available as open source.

  I intend for it to be mostly declarative, with a nice DSL for defining
  GUI elements. Each component will also implement map, and use one of
  Clojure's reference types as an interface for inspecting / updating
  its state. I may also implement some aspects of Functional Reactive
  Programming wherever it's convenient to do so.

  What you all must help me decide is what GUI framework to use as the
  underpinnings of it. It's genuinely hard to decide. I have at least
  some experience with all of them, so I have no strong preference, but
  I'd like to get your input. I did consider trying to make it abstract
  enough that you could plug in *any* of them under the hood, but
  there's enough differences between the frameworks that that would get
  very ugly very fast.

  Possibilities are:

  AWT
  Pros: native widgets, bundled with Java, low-level
  Cons: few widgets, considered somewhat obselete

  Swing
  Pros: bundled with Java, good widget selection
  Cons: non-native widgets

  SWT
  Pros: native widgets, widely used
  Cons: requires platform-specific libs

  QT Jambi
  Pros: native widgets, huge widget selection, highly-regarded framework
  Cons: requires platform-specific libs, writing custom widgets is
  hairy, momentum and support seem to be lagging since Nokia dropped
  official support.

  Remember, the actual API won't matter - that will be completely
  abstracted away. So try to focus on the framework's look and feel.
  Also let me know if I've missed any of the framework's key
  characteristics.

  Thanks!

  -Luke

 --
 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

-- 
Omnem crede diem tibi diluxisse supremum.

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Zak Wilson]

Swing, mainly for deployment reasons.

It's not hard to set the look and feel to the platform's look and
feel. That's not perfect, but it's usually not bad either, though the
GTK1-style file chooser is horrid.

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[p2]

+1 SWT -- but if it's good, Swing works also.

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[laseray]

On May 29, 10:29 pm, Daniel doubleagen...@gmail.com wrote:
 You could be really odd and write a wrapper for Edje.

 http://trac.enlightenment.org/e/wiki/Edje

 Not a serious recommendation, really.  I just don't have any strong
 positive opinions regarding any of the others except for QT, and as
 you say

I would give that a point also, if it were really a practical
possibility. It is my preferred window manager.

I have spent quite a bit of time developing Swing GUI applications on
Linux under Enlightenment, plus some testing under KDE, XFCE. Swing
looks okay, is highly usable, and gave me less issues than SWT for LaF
under different window managers. When using the GTK LaF Swing can be
tweaked with gtk-chtheme for a custom appearance, including to look
fairly similar to KDE by using QtCurve. There are numbers of LaF for
Windows (e.g., substance) that give a good selection/conformance. Mac
basically has only one look for any particular major version of the OS
(for which there is quauqua, MRJAdapter, and others).

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[BerlinBrown]

I am not knocking all of these +1 Swing posts.  But I would love to
see one good public application built in Swing (besides Netbeans)

On May 28, 9:10 am, laseray lase...@gmail.com wrote:
 +1 Swing

 If I had my druthers I would go with QtJambi, but since Nokia dropped
 development for that it has not been able to keep pace with Qt. So
 that would be immediately out of sync. Plus the need for platform
 native compiled code is a minus. Fine for the main three (Linux, Mac,
 Windows) with precompiled libs, but separate compile for anything else
 equals ongoing maintenance effort. This defeats the point of having a
 cross-platform language. Java and Clojure will work (.e.g, on FreeBSD,
 OpenSolaris, AIX), but the GUI won't unless you make extra C/C++
 coding effort?

 SWT is a minus due to native code needs, too much XML configuration,
 and the fact that it does not look nearly as good as some people think
 when used cross-platform. Looks fine on Windows, the Mac side is
 getting better now that they are starting to use Cocoa underneath,
 Linux side is questionable with varying appearance across different
 window managers. Other OS? This is the same as for QtJambi, extra C/C+
 + coding effort needed to be really cross-platform.

 No reason to go with AWT exclusively. A lot of Swing wraps parts of or
 needs AWT anyway. You can't really get away from it and will be
 cutting off a limb, so to speak, if you go with it rather than Swing
 first.

 A lot of the misgivings about Swing look and feel across platform
 boils down to bad GUI development efforts. I have seen this many
 times. Many developers just do not understand the specific interface
 needs across different platforms and just leave parameters at the
 default settings, which only by luck will be near optimal. I have
 developed a number of Swing applications that look pretty close to
 native (at least on Linux, Mac, Windows, Solaris) so I can say that it
 takes some attention to platform specific details to make this happen
 (and access to multiple OS).  That is what it takes to develop a
 serious professional cross-platform desktop application, no way around
 it (you would even have to do this if going with QtJambi or SWT).

 Overall, I would go with Swing. The main reason is that it will
 already be cross-platform on any Java compliant OS that can run
 Clojure. I think that is the most important thing if you want a GUI to
 go along with the language. Nothing additional is needed to complicate
 matters, besides the GUI layer/framework on top of Clojure.

 Nonetheless, the best idea would be to ensure you have enough
 abstraction in your implementation so that other GUI toolkits could be
 almost dropped in place later on. That is, it should not close out
 other toolkits, but going with what will work now or sooner than later
 is better. Going with Swing is a way to get something out soon without
 having to spend additional effort worrying about C/C++ libraries,
 packaging and so on. Get something to work, then the additional
 toolkits can come.

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Brian Schlining]

 I am not knocking all of these +1 Swing posts.  But I would love to
 see one good public application built in Swing (besides Netbeans)


Here's a couple just off the top of my head...

jEdit http://www.jedit.org/
GanttProject http://www.ganttproject.biz/
Intellij IDEA, RubyMine, PhpStorm, WebStorm, PyCharm
http://www.jetbrains.com/
SmatCVS, SmartSVN, SmartGIT http://www.syntevo.com/index.html
LimeWire/FrostWire http://www.frostwire.com/
ImageJ http://rsbweb.nih.gov/ij/
Video Annotation and Reference System http://vars.sourceforge.net/

-- 
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlin...@gmail.com

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Brian Schlining]

 I am not knocking all of these +1 Swing posts.  But I would love to
 see one good public application built in Swing (besides Netbeans)


 Here's a couple just off the top of my head...


Also, Aqua Data Studio (my favorite db tool) http://www.aquafold.com/
-- 
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlin...@gmail.com

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Erik Söhnel]

I'd vote for swing and against anything that abstracts away the
toolkit so that you can switch the backend.

Implementing a clojure wrapper for the apache pivot toolkit gave me
a little insight on at least two GUI toolkits, namely swing and
pivot. Despite their goal of displaying widgets on a 2 dimensional
plane, their APIs differ in a lot of ways, like different
listener types, totally different approaches to layout. I'd say that
it would hardly possible to find a common API without implementing
substancial parts of, say, the layout engine yourself so that its
results look equal on every backend.

My main issue, besides the deployment hurdle with SWT, is that you
have to manage graphics resources manually in SWT
(see http://www.otug.org/groups/javasig/richclient.pdf).
Like, say you would like to have built a form where you have a lazy
seq of checkboxes for displaying the contents of a map.

Also, with swing, you can add a small gui to whatever program you are
going to ship, without bothering about the additional complexity
induced by including a gui.

Erik

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Marc Spitzer]

not being a programmer perhaps I should be quite, but I never do that.

+10 for swing, here is why:
1: it is there
2: it is good enough
3: doing the bare minimum  you are signing up for a large amount of
work, don't sign up for more.
4: people who build new gui libs usually have their own ideas how
things should work, often incompatible ideas.
5: there is someone else who wants to work with you on this.

1 is very important, if your users must install custom packages you
will have to answer a lot of emails and write good docs instead of
doing fun stuff.  you do not want to be supporting skeedo linux, HP-UX
 .  if your doing swing support is install java 1.5 or better.


but with that said +1 Tk,

marc




On Thu, May 27, 2010 at 11:18 AM, Luke VanderHart
luke.vanderh...@gmail.com wrote:
 My side project is a fairly complex GUI application written in
 Clojure. Recently, I've become irritated with using Java interop for
 everything. It's not that Clojure doesn't have nice java interop - it
 does. It's just that when interacting with a GUI framework, which is a
 large part of my app, I have to be back in mutable object-oriented
 land, worrying about class hierarchies, mutable state, locks, etc.
 Yucky.

 So, with a perhaps dangerous lack of sanity and without any guarantee
 of success, I've decided to try my hand at writing an idiomatic
 Clojure GUI library. If I have success (which I doubt) I will of
 course make it available as open source.

 I intend for it to be mostly declarative, with a nice DSL for defining
 GUI elements. Each component will also implement map, and use one of
 Clojure's reference types as an interface for inspecting / updating
 its state. I may also implement some aspects of Functional Reactive
 Programming wherever it's convenient to do so.

 What you all must help me decide is what GUI framework to use as the
 underpinnings of it. It's genuinely hard to decide. I have at least
 some experience with all of them, so I have no strong preference, but
 I'd like to get your input. I did consider trying to make it abstract
 enough that you could plug in *any* of them under the hood, but
 there's enough differences between the frameworks that that would get
 very ugly very fast.

 Possibilities are:

 AWT
 Pros: native widgets, bundled with Java, low-level
 Cons: few widgets, considered somewhat obselete

 Swing
 Pros: bundled with Java, good widget selection
 Cons: non-native widgets

 SWT
 Pros: native widgets, widely used
 Cons: requires platform-specific libs

 QT Jambi
 Pros: native widgets, huge widget selection, highly-regarded framework
 Cons: requires platform-specific libs, writing custom widgets is
 hairy, momentum and support seem to be lagging since Nokia dropped
 official support.

 Remember, the actual API won't matter - that will be completely
 abstracted away. So try to focus on the framework's look and feel.
 Also let me know if I've missed any of the framework's key
 characteristics.

 Thanks!

 -Luke















 --
 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



-- 
Freedom is nothing but a chance to be better.
--Albert Camus

 The problem with socialism is that eventually you run out
of other people's money.
--Margaret Thatcher

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Antony Blakey]

On 31/05/2010, at 9:44 AM, Marc Spitzer wrote:

 2: it is good enough

IMO This is the entire point. Swing is not good enough if you want to build 
something with native integration and correct look and feel. Everything else 
comes down to whether developers are prepared to pay the price for producing 
something great. And anyway is 'good enough' what we should be aiming for. How 
about going for something superlative rather than something mediocre.

Bundling SWT into a native wrapper isn't a big deal.

Antony Blakey
--
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Human beings, who are almost unique in having the ability to learn from the 
experience of others, are also remarkable for their apparent disinclination to 
do so.
  -- Douglas Adams 


-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Marc Spitzer]

On Sun, May 30, 2010 at 8:23 PM, Antony Blakey antony.bla...@gmail.com wrote:

 On 31/05/2010, at 9:44 AM, Marc Spitzer wrote:

 2: it is good enough

 IMO This is the entire point. Swing is not good enough if you want to build 
 something with native integration and correct look and feel. Everything else 
 comes down to whether developers are prepared to pay the price for producing 
 something great. And anyway is 'good enough' what we should be aiming for. 
 How about going for something superlative rather than something mediocre.

 Bundling SWT into a native wrapper isn't a big deal.

I do agree with you for 'a' native wrapper.  What is your opinion for
all native wrappers?  The thing is that each platform that requires
native code is a source of tech support requests.  Now let me go with
the things I have at work:
1: redhat 64 and 32 bit, various flavors
2: solaris x86 and sparc various flavors
3: aix various flavors
4: mac os various flavors including powerpc
5: windows
6 other linuxes

also lets not forget about LD_LIBRARY_PATH issues, incomparable
installed libs, the need to go off the reservation to get something
working.  Instead of yum working on my redhat boxes I need to compile
a specific version of something *AND* make sure this app finds it but
that the other apps do not.

and for all of the above tech support for swing is install right
version of java.  *AND* if you can not do that then tech support stops
and people can get back to coding.

well java is not good enough if you want a native look, you need C/C++
and binding that java uses.  And why should Luke be a martyr and pay
the price in his personal time/life for something that should be fun.
If it is fun he more likely to continue to work on it, as is the case
with most hobbies.   And who said that I valued native integration all
that much.  And no one is saying he should or should not make a
superlative swing wrapper or what ever he chooses to do.

Also please keep in mind that Better is a good target and generally
much more achievable then  superlative.  Shipped is also a wonderful
thing.  Better and shipped are really cool.  And if you keep shipping
better thing you get to superlative.


thanks,

marc







 Antony Blakey
 --
 CTO, Linkuistics Pty Ltd
 Ph: 0438 840 787

 Human beings, who are almost unique in having the ability to learn from the 
 experience of others, are also remarkable for their apparent disinclination 
 to do so.
  -- Douglas Adams


 --
 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



-- 
Freedom is nothing but a chance to be better.
--Albert Camus

 The problem with socialism is that eventually you run out
of other people's money.
--Margaret Thatcher

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Antony Blakey]

On 31/05/2010, at 10:44 AM, Marc Spitzer wrote:

 I do agree with you for 'a' native wrapper.  What is your opinion for
 all native wrappers?  The thing is that each platform that requires
 native code is a source of tech support requests.  Now let me go with
 the things I have at work:
 1: redhat 64 and 32 bit, various flavors
 2: solaris x86 and sparc various flavors
 3: aix various flavors
 4: mac os various flavors including powerpc
 5: windows
 6 other linuxes

I care about Mac and Windows primarily, and building software that will sell 
(not dev tools) requires good native look and feel.

 also lets not forget about LD_LIBRARY_PATH issues,

No Mac or Windows user would encounter these. 

 incomparable
 installed libs, the need to go off the reservation to get something
 working.  Instead of yum working on my redhat boxes I need to compile
 a specific version of something *AND* make sure this app finds it but
 that the other apps do not.

And this is just one reason Linux on the desktop is a million miles from Mac 
and Windows.

 well java is not good enough if you want a native look, you need C/C++
 and binding that java uses.  And why should Luke be a martyr and pay
 the price in his personal time/life for something that should be fun.

a) SWT is not martydom, and is a lot better than Swing for a native LF
b) Luke asked for opinions.

 Also please keep in mind that Better is a good target and generally
 much more achievable then  superlative. Shipped is also a wonderful
 thing.  Better and shipped are really cool.  And if you keep shipping
 better thing you get to superlative.

Not if your toolkit (Swing) places an upper bound on the quality of your app.

Antony Blakey
-
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Nothing is really work unless you would rather be doing something else.
  -- J. M. Barre


-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[rob levy]

This is a great idea, and is something that Clojure really needs in my
opinion (for starters it would be nice to be able to write GUI apps in
Clojure without worrying about the Java level, with its completely different
and completely annoying semantics). My vote is for Swing, simply because the
difference in look and feel doesn't seem to be all that great.  If the added
difficulty of deploying bought tremendous LAF benefits I would say yeah use
SWT, but really the differences don't seem to justify it.

Also, it could always be forked later on if there were a big enough
contingency of SWT fans, and the work put into building Swing version would
go a long way toward that goal, especially considering that this is going to
abstract away the Swing-specific stuff.

Rob

On Thu, May 27, 2010 at 11:18 AM, Luke VanderHart luke.vanderh...@gmail.com
 wrote:

 My side project is a fairly complex GUI application written in
 Clojure. Recently, I've become irritated with using Java interop for
 everything. It's not that Clojure doesn't have nice java interop - it
 does. It's just that when interacting with a GUI framework, which is a
 large part of my app, I have to be back in mutable object-oriented
 land, worrying about class hierarchies, mutable state, locks, etc.
 Yucky.

 So, with a perhaps dangerous lack of sanity and without any guarantee
 of success, I've decided to try my hand at writing an idiomatic
 Clojure GUI library. If I have success (which I doubt) I will of
 course make it available as open source.

 I intend for it to be mostly declarative, with a nice DSL for defining
 GUI elements. Each component will also implement map, and use one of
 Clojure's reference types as an interface for inspecting / updating
 its state. I may also implement some aspects of Functional Reactive
 Programming wherever it's convenient to do so.

 What you all must help me decide is what GUI framework to use as the
 underpinnings of it. It's genuinely hard to decide. I have at least
 some experience with all of them, so I have no strong preference, but
 I'd like to get your input. I did consider trying to make it abstract
 enough that you could plug in *any* of them under the hood, but
 there's enough differences between the frameworks that that would get
 very ugly very fast.

 Possibilities are:

 AWT
 Pros: native widgets, bundled with Java, low-level
 Cons: few widgets, considered somewhat obselete

 Swing
 Pros: bundled with Java, good widget selection
 Cons: non-native widgets

 SWT
 Pros: native widgets, widely used
 Cons: requires platform-specific libs

 QT Jambi
 Pros: native widgets, huge widget selection, highly-regarded framework
 Cons: requires platform-specific libs, writing custom widgets is
 hairy, momentum and support seem to be lagging since Nokia dropped
 official support.

 Remember, the actual API won't matter - that will be completely
 abstracted away. So try to focus on the framework's look and feel.
 Also let me know if I've missed any of the framework's key
 characteristics.

 Thanks!

 -Luke















 --
 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.comclojure%2bunsubscr...@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 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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Marc Spitzer]

On Sun, May 30, 2010 at 9:23 PM, Antony Blakey antony.bla...@gmail.com wrote:

 On 31/05/2010, at 10:44 AM, Marc Spitzer wrote:

 I do agree with you for 'a' native wrapper.  What is your opinion for
 all native wrappers?  The thing is that each platform that requires
 native code is a source of tech support requests.  Now let me go with
 the things I have at work:
 1: redhat 64 and 32 bit, various flavors
 2: solaris x86 and sparc various flavors
 3: aix various flavors
 4: mac os various flavors including powerpc
 5: windows
 6 other linuxes

 I care about Mac and Windows primarily, and building software that will sell 
 (not dev tools) requires good native look and feel.

I actually primarily do not care about mac or windows, personally or
professionally.  Also keep in mind that one of the selling points of
clojure is that it runs where *Java* runs not mac and windows, I would
think that in my mind anyway, be a strong contributing point.  Now to
be honest I am responsible for Macs at work but hopefully less of them
as time goes by.


 also lets not forget about LD_LIBRARY_PATH issues,

 No Mac or Windows user would encounter these.

Have you ever heard of DLL HELL?  It is a special case of library path
issues, they exist every where you have shared libs/DLLS being loaded.

And as a sysadmin I have had LD issues with OSX.


 incomparable
 installed libs, the need to go off the reservation to get something
 working.  Instead of yum working on my redhat boxes I need to compile
 a specific version of something *AND* make sure this app finds it but
 that the other apps do not.

 And this is just one reason Linux on the desktop is a million miles from Mac 
 and Windows.

your right we should all be using pcbsd much better, http://pcbsd.org/


 well java is not good enough if you want a native look, you need C/C++
 and binding that java uses.  And why should Luke be a martyr and pay
 the price in his personal time/life for something that should be fun.

 a) SWT is not martydom, and is a lot better than Swing for a native LF
 b) Luke asked for opinions.

 Also please keep in mind that Better is a good target and generally
 much more achievable then  superlative. Shipped is also a wonderful
 thing.  Better and shipped are really cool.  And if you keep shipping
 better thing you get to superlative.

 Not if your toolkit (Swing) places an upper bound on the quality of your app.

native integration is not quality, quality is quality native
integration is look and feel.


marc
-- 
Freedom is nothing but a chance to be better.
--Albert Camus

 The problem with socialism is that eventually you run out
of other people's money.
--Margaret Thatcher

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Antony Blakey]

On 31/05/2010, at 11:13 AM, Marc Spitzer wrote:

 I actually primarily do not care about mac or windows, personally or
 professionally.  Also keep in mind that one of the selling points of
 clojure is that it runs where *Java* runs not mac and windows, I would
 think that in my mind anyway, be a strong contributing point.  Now to
 be honest I am responsible for Macs at work but hopefully less of them
 as time goes by.

This is obviously another input into Luke's decision making. What kind of apps 
does he want to target, what kind of developers, what platforms, with what 
intentions.

 Have you ever heard of DLL HELL?  It is a special case of library path
 issues, they exist every where you have shared libs/DLLS being loaded.

That only happens if you try to share the DLL, which isn't necessary.

 And as a sysadmin I have had LD issues with OSX.

Consumer apps using SWT don't have this problem on OSX.

 your right we should all be using pcbsd much better, http://pcbsd.org/

LOL.

 native integration is not quality, quality is quality native
 integration is look and feel.

which is an essential part of quality from a user's perspective for the two 
consumer desktop platforms.

Antony Blakey
--
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The project was so plagued by politics and ego that when the engineers 
requested technical oversight, our manager hired a psychologist instead.
  -- Ron Avitzur

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[lprefontaine]

Antony Blakey antony.bla...@gmail.com wrote ..
 
 On 31/05/2010, at 11:13 AM, Marc Spitzer wrote:
 
  I actually primarily do not care about mac or windows, personally or
  professionally.  Also keep in mind that one of the selling points of
  clojure is that it runs where *Java* runs not mac and windows, I would
  think that in my mind anyway, be a strong contributing point.  Now to
  be honest I am responsible for Macs at work but hopefully less of them
  as time goes by.
 
 This is obviously another input into Luke's decision making. What kind of apps
 does he want to target, what kind of developers, what platforms, with what
intentions.

Vast survey indeed... how should we find the real numbers ?
Any suggestion is welcomed but I doubt we can find a core group of
developers that will win this survey.

 
  Have you ever heard of DLL HELL?  It is a special case of library path
  issues, they exist every where you have shared libs/DLLS being loaded.
 
 That only happens if you try to share the DLL, which isn't necessary.

Yep but then you need to ship the DLLs (and any other native implementations for
the various platforms) with a synced version of the wrapper.
Of course the native libraries may vary according to the platorm/maintenance
releases, ...

 
  And as a sysadmin I have had LD issues with OSX.
 
 Consumer apps using SWT don't have this problem on OSX.

So should we expect problems in other OSes ? What about testing then ?
Do we multiply the number of test suites to run by the number of platforms
we support multiplied by the different versions of SWT ?
Maybe we should include the captain's age in the equation above...

Wow, vast test program. How many man/years to get wrappers around SWT tested 
with a sufficient number of implementations and how can we keep up 
with future versions coming in (multiplied by the number of platforms, ...)

  your right we should all be using pcbsd much better, http://pcbsd.org/
 
 LOL.
 
  native integration is not quality, quality is quality native
  integration is look and feel.
 
 which is an essential part of quality from a user's perspective for the two
consumer
 desktop platforms.

Not true, we ship Swing based apps on different platforms and the value
has never been the look but what they allow users to achieve.
The single look and feel (aka uniformity) is welcomed by users,
some of them are switching regurlaly between Windows and Macs.

Were not in the cosmetics business however so we speak for our business
(cross-platform, cross-language, cross-)

A menu bar is a menu bar...
Even if I rarely use Windows, I'm not freaking because the widgets are not
the same as my usual desktop.
I hate Microsoft for the number of changes they make from version to version
because they move stuff around, not because they changed the look and feel
of individual apps. That's why I often start apps from command line
instead of digging endlessly in the startup menu.

I can even get myself around on a MAC without pain.

Swing is a much more logical choice effort wise. Of course we may 
start a Clojure-GUI group eventually but that is premature.. if 
worthwhile at all.

Luc P.
 
 Antony Blakey
 --
 CTO, Linkuistics Pty Ltd
 Ph: 0438 840 787
 
 The project was so plagued by politics and ego that when the engineers 
 requested
 technical oversight, our manager hired a psychologist instead.
   -- Ron Avitzur
 
 -- 
 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 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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Mike Meyer]

On Mon, 31 May 2010 10:53:45 +0930
Antony Blakey antony.bla...@gmail.com wrote:

 
 On 31/05/2010, at 10:44 AM, Marc Spitzer wrote:
  also lets not forget about LD_LIBRARY_PATH issues,
 No Mac or Windows user would encounter these. 

You forget that the Mac is a Unix box. It supports LD_LIBRARY_PATH. In
an ideal world - where every developer did things right - you'd never
need it on any system. We don't live in such a world. In particular,
OSX tends to ship with obsolete versions of *very* popular Unix
libraries. So much so that you wind up having to choose between
building obsolete versions of the tools you want, losing valuable
features and bug fixes; or building current versions of libraries in
the system, leading to having to make sure your code and only your
code finds it - even when you're dynamically loading frameworks that
want to use the system version of the same library.

On Windows, the problem is so common it's been given the name DLL
hell.

mike
-- 
Mike Meyer m...@mired.org http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O ascii ribbon campaign - stop html mail - www.asciiribbon.org

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[lprefontaine]

Mike Meyer mwm-keyword-googlegroups.620...@mired.org wrote ..
 On Mon, 31 May 2010 10:53:45 +0930
 Antony Blakey antony.bla...@gmail.com wrote:
 
  
  On 31/05/2010, at 10:44 AM, Marc Spitzer wrote:
   also lets not forget about LD_LIBRARY_PATH issues,
  No Mac or Windows user would encounter these. 
 
 You forget that the Mac is a Unix box. It supports LD_LIBRARY_PATH. In
 an ideal world - where every developer did things right - you'd never
 need it on any system. We don't live in such a world. In particular,
 OSX tends to ship with obsolete versions of *very* popular Unix
 libraries. So much so that you wind up having to choose between
 building obsolete versions of the tools you want, losing valuable
 features and bug fixes; or building current versions of libraries in
 the system, leading to having to make sure your code and only your
 code finds it - even when you're dynamically loading frameworks that
 want to use the system version of the same library.
 
 On Windows, the problem is so common it's been given the name DLL
 hell.
 
 mike
 -- 


Mike makes a good point here. We had an Xserve for 7/8 years and one thing
we found frustrating was the lack of updates for open source tools and
how the next Apple release would zap the ones we made ourselves in between.

It finally died last November and we were happy to replace it with an Ubuntu
server box were we can control what is updated and when.

As for the DLL hell, try to get an app. deployed to desktops through a central
IT controlled process. Even if you do not intend to share DLLs, you will
have a lot of explanations to give if your package contains a few...
I went through this several times.


Luc P.

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Antony Blakey]

On 31/05/2010, at 12:31 PM, Mike Meyer wrote:

 On Mon, 31 May 2010 10:53:45 +0930
 Antony Blakey antony.bla...@gmail.com wrote:
 
 
 On 31/05/2010, at 10:44 AM, Marc Spitzer wrote:
 also lets not forget about LD_LIBRARY_PATH issues,
 No Mac or Windows user would encounter these. 
 
 You forget that the Mac is a Unix box. It supports LD_LIBRARY_PATH. In
 an ideal world - where every developer did things right - you'd never
 need it on any system. We don't live in such a world. In particular,
 OSX tends to ship with obsolete versions of *very* popular Unix
 libraries. So much so that you wind up having to choose between
 building obsolete versions of the tools you want, losing valuable
 features and bug fixes; or building current versions of libraries in
 the system, leading to having to make sure your code and only your
 code finds it - even when you're dynamically loading frameworks that
 want to use the system version of the same library.
 
 On Windows, the problem is so common it's been given the name DLL
 hell.


I build installers that include chains of co-dependent base libraries with 
isolating setups (programatically mutated binary and load paths) for multiple 
platforms, so I know about this issue, but I'm talking specifically about SWT 
which doesn't suffer from that problem.

Antony Blakey
--
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Hi, I'd like to do $THING. I know that $SOLUTION_A and $SOLUTION_B will do it 
very easily and for a very reasonable price, but I don't want to use 
$SOLUTION_A or $SOLUTION_B because $VAGUE_REASON and $CONTRADICTORY_REASON. 
Instead, I'd like your under-informed ideas on how to achieve my 
$POORLY_CONCEIVED_AMBITIONS using Linux, duct tape, an iPod, and hours and 
hours of my precious time.
  -- Slashdot response to an enquiry


-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Antony Blakey]

I doubt this subthread is of any use to the OP at this point.

On 31/05/2010, at 12:31 PM, lprefonta...@softaddicts.ca wrote:

 Any suggestion is welcomed but I doubt we can find a core group of
 developers that will win this survey.

It's a survey group of 1 i.e. what are *his* responses to those questions.

 Yep but then you need to ship the DLLs (and any other native implementations 
 for
 the various platforms) with a synced version of the wrapper.
 Of course the native libraries may vary according to the platorm/maintenance
 releases, ...

And yet, somehow, commercial software is produced ...

 So should we expect problems in other OSes ? What about testing then ?
 Do we multiply the number of test suites to run by the number of platforms
 we support multiplied by the different versions of SWT ?

No, you treat SWT as a black box as regards testing. It has it's own test 
regime and cross-platform validation.

 Were not in the cosmetics business however so we speak for our business
 (cross-platform, cross-language, cross-)

You are begging the question then.

Antony Blakey
--
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The trouble with the world is that the stupid are cocksure and the intelligent 
are full of doubt.
  -- Bertrand Russell


-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[lprefontaine]

Antony Blakey antony.bla...@gmail.com wrote ..
 I doubt this subthread is of any use to the OP at this point.

I run a software business, I generally look at product decisions in terms
of cost/benefits from end to end over time not just looking solely at a
specific item and specific time frame. 

 
 On 31/05/2010, at 12:31 PM, lprefonta...@softaddicts.ca wrote:
 
  Any suggestion is welcomed but I doubt we can find a core group of
  developers that will win this survey.
 
 It's a survey group of 1 i.e. what are *his* responses to those questions.

Two alternatives seem to gather some support, Swing and SWT.  Now what are the 
cost/benefits of choosing SWT ?

 
  Yep but then you need to ship the DLLs (and any other native implementations
 for
  the various platforms) with a synced version of the wrapper.
  Of course the native libraries may vary according to the platorm/maintenance
  releases, ...
 
 And yet, somehow, commercial software is produced ...

Maybe but does it have to be more painful and complex than necessary ? 

What value brings SWT ?

a) Performance ? Maybe a few years ago but presently
Swing and SWT are similar in terms of performance in general.

b) Swing is bundled in the JRE, SWT is not. This means some extra work
   somehow.

c) Cosmetic aspect ? SWT wins for its ability to look like other apps
on a given platform. Swing offers a uniform look and feel.

So the only feature offered by SWT if I follow your point is c).
At what cost ?

 
  So should we expect problems in other OSes ? What about testing then ?
  Do we multiply the number of test suites to run by the number of platforms
  we support multiplied by the different versions of SWT ?
 
 No, you treat SWT as a black box as regards testing. It has it's own test 
 regime
 and cross-platform validation.

Impacts on testing/deployment:

a) Black boxes are good until top layers get hit.
   You still need to manage dependencies between the top wrapper and the 
   bottom layers. Swing has a major advantage here. No native wrappers,
   no need for a complex installation process or per platform dependency
   management.

b) No test completed = not a product yet. You have to test before delivering 
   anything to a desktop and that includes all the variants you intend to
   support. Swing is the same everywhere so the occurrences of GUI related
   problems are reduced. SWT opens the gate to potential problems
   since it is implemented in different components depending on
   the platform. Swing wins here.

c) Building/packaging/maintaning variants for every desktop type supported is
   significant work. Swing wins here.

d) I do not see writing installers has being a mundane and funny task.
   Having to write per desktop variant installers is another drawback of SWT.
   Delivering a single jar on all platforms is a big bonus.
   Complex installers have to be tested themselves, there subject to the
   same problems as any piece of software whatever good the tool you use maybe.
   Another level of complexity  Swing wins here. 
   
Back to why does producing software has to be more painful than necessary
and what value brings SWT overall.

 
  Were not in the cosmetics business however so we speak for our business
  (cross-platform, cross-language, cross-)
 
 You are begging the question then.

Swing has prove itself up to know (and improved a lot), why get entangled
in a complex process with all the above ramifications ?

Simplicity as some value. You should meditate a bit on this.

Luc P.

 
 Antony Blakey
 --
 CTO, Linkuistics Pty Ltd
 Ph: 0438 840 787
 
 The trouble with the world is that the stupid are cocksure and the intelligent
 are full of doubt.
   -- Bertrand Russell
 
 
 -- 
 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 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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Antony Blakey]

On 31/05/2010, at 2:04 PM, lprefonta...@softaddicts.ca wrote:

 Two alternatives seem to gather some support, Swing and SWT.  Now what are 
 the 
 cost/benefits of choosing SWT ?

See below.

 What value brings SWT ?
 
 a) Performance ? Maybe a few years ago but presently
 Swing and SWT are similar in terms of performance in general.

Not my experience, but YMMV, and in any case not the deciding factor for me.

 c) Cosmetic aspect ? SWT wins for its ability to look like other apps
 on a given platform. Swing offers a uniform look and feel.
 
 So the only feature offered by SWT if I follow your point is c).
 At what cost ?

Well, I'd argue that it's more than cosmetic, which I take you to mean 
pejoratively. In fact I place an enormous value on this point, for what seems 
to me to be a slight cost (and the major one is manual management of resource 
lifetime, not deployment).

 Back to why does producing software has to be more painful than necessary
 and what value brings SWT overall.

I guess we just differ in our assessment of 'necessary' and 'value' in this 
paragraph.

 
 
 Were not in the cosmetics business however so we speak for our business
 (cross-platform, cross-language, cross-)
 
 You are begging the question then.
 
 Swing has prove itself up to know (and improved a lot), why get entangled
 in a complex process with all the above ramifications ?
 
 Simplicity as some value. You should meditate a bit on this.

I'm a big fan of simplicity. However there are two sayings that come to mind:

1. Make everything as simple as possible, but not simpler. (Albert Einstein)
2. For every complex problem, there is an answer that is clear, simple - and 
wrong (H. L. Mencken).

Antony Blakey
-
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

In anything at all, perfection is finally attained not when there is no longer 
anything to add, but when there is no longer anything to take away.
  -- Antoine de Saint-Exupery


-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[James Cunningham]

On May 30, 9:23 pm, Antony Blakey antony.bla...@gmail.com wrote:
 I care about Mac and Windows primarily, and building software that will sell 
 (not dev tools) requires good native look and feel.

Do you have a single example of an SWT app that has a decent feel on
OS X? I've spent a fair amount of time with Eclipse lately, and---
frankly---it feels about as native as an Alabaman in Nice. No native
toolbar, no native tabs, slower and uglier than either Netbeans or
Intellij. My only other experience with an SWT app was entirely
negative from a performance and look-and-feel perspective (Vuze).

SWT sounded nice a few years ago, but in my opinion it never lived up
to its promise. If you want native GUIs there is no alternative to
using platform-specific toolkits; for cross-platform work SWT has
nothing on Swing.

 Antony Blakey

Best,
James

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Antony Blakey]

On 31/05/2010, at 2:27 PM, James Cunningham wrote:

 
 
 On May 30, 9:23 pm, Antony Blakey antony.bla...@gmail.com wrote:
 I care about Mac and Windows primarily, and building software that will sell 
 (not dev tools) requires good native look and feel.
 
 Do you have a single example of an SWT app that has a decent feel on
 OS X? I've spent a fair amount of time with Eclipse lately, and---
 frankly---it feels about as native as an Alabaman in Nice. No native
 toolbar, no native tabs, slower and uglier than either Netbeans or
 Intellij. My only other experience with an SWT app was entirely
 negative from a performance and look-and-feel perspective (Vuze).

Vuze looks OK to me in the 5 minutes I've just spent. In any case, my opinion 
comes from doing parallel GUI development in IB and SWT to see if I could use 
Clojure/SWT rather than MacRuby (XCode/IB). I'm not using the RCP which 
imprints it's own not-really-OSX flavour in spite of the widgets.

You have to do more than just use SWT to get a Mac application to feel right, 
and one's GUI layout code needs to be parametric and rules based, rather than 
just swapping the LF. That said, it's still easier than writing three UIs.

Antony Blakey
-
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The intuitive mind is a sacred gift and the rational mind is a faithful 
servant. We have created a society that honours the servant and has forgotten 
the gift.
  -- Albert Einstein


-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Laurent PETIT]

2010/5/28 Luke VanderHart luke.vanderh...@gmail.com

  Why not design it so that it can be backed by Swing or SWT or HTML
  (perhaps with some AJAX) or whatever?  It seems kind of silly to do an
  abstraction on a single backend, don't you think?

 Ideally, yes. In practice, I'd rather implement one framework well
 than implement only the lowest common denominator of several. We're
 not just talking creating a window with menus and a few buttons - My
 project, for example, is a word processor. Having a requirement that
 it work across multiple GUI toolkits sounds a little bit hellish.

 That said, I do plan the core API to be abstract enough from the
 underlying implementation that it could in theory be backed by a
 different framework. I just don't intend to do the work of providing
 bindings to multiple implementations and ensuring that behavior is
 consistent. If some enterprising soul wants to use the same basic
 interfaces to front an alternative implementation, I'll certainly try
 to make it conducive to that. But having a API with seamlessly
 interchangeable back-ends doesn't sound very feasible.

 By the way, do the SWT people only come out at night? Or is it a US vs
 Europe issue? Seems somewhat curious that 7 in a row vote for Swing,
 then the next 4 are all SWT advocates. Should I expect the QT fans to
 show up tomorrow? :p


From my little experience with counterclockwise (clojure eclipse plugin
adoption), there seems clearly to be more adoption of Eclipse technologies
in Europe than in USA.

That said, and being an Eclipse guy myself at work, and given the arguments
that say deployment is part of the dev job (which is partly true, deployment
is often devoted to specialized teams, not necessarily the dev teams), I
maintain my idea that starting with Swing may be easier for you.
The ideas of interfaces done with Swing not being performant enough seem
dated to me. IntelliJ IDEA, the new generation of Netbeans have certainly
proven that it is possible to write big professional applications with
Swing.

My 0.02 €,

-- 
Laurent

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Matthew Elder]

I will send patches!! get on github no.

;)

On 5/27/10, Luke VanderHart luke.vanderh...@gmail.com wrote:
 Thanks, Heinz... I may.

 Right now I'm still exploring what I want the API to be. I was hoping
 to achieve something a bit thicker that could insulate the user from
 Java classes completely. The user wouldn't even have to know Swing or
 handle JObjects or worry about the event thread... In other words, it
 wouldn't be a wrapper API for Swing, but a Clojure GUI api that,
 coincidentally, is /backed/ by Swing.

 This may be an unrealistic goal, but I've got pretty far down the path
 of designing it, though I definitely don't want to declare victory
 until I've figured out a strategy for covering every reasonably common
 use case.

 -Luke




 On May 27, 5:54 pm, Heinz N. Gies he...@licenser.net wrote:
 +1 For swing especially since I started this already. Look for clj-swing
 in github, since this seems quite a load of work I'd be glad for any help
 so :).

 Regards,
 Heinz
 On May 27, 2010, at 21:30 , Luc Préfontaine wrote:



  +1 for Swing.
  On Thu, 2010-05-27 at 11:59 -0700, Brian Schlining wrote:
  +1 Swing.
   +1 Swing.
+1 Swing.  There's a ton of documentation out there, and it got
some

 --
 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

-- 
Sent from my mobile device

Need somewhere to put your code? http://patch-tag.com
Want to build a webapp? http://happstack.com

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Matthew Elder]

Yes but not too much yak shaving, it is important to run with the
simplest thing that will work first.


On 5/27/10, Jason Smith ja...@lilypepper.com wrote:
 Why not design it so that it can be backed by Swing or SWT or HTML
 (perhaps with some AJAX) or whatever?  It seems kind of silly to do an
 abstraction on a single backend, don't you think?

 On May 27, 4:37 pm, Luke VanderHart luke.vanderh...@gmail.com wrote:
 Thanks, Heinz... I may.

 Right now I'm still exploring what I want the API to be. I was hoping
 to achieve something a bit thicker that could insulate the user from
 Java classes completely. The user wouldn't even have to know Swing or
 handle JObjects or worry about the event thread... In other words, it
 wouldn't be a wrapper API for Swing, but a Clojure GUI api that,
 coincidentally, is /backed/ by Swing.

 This may be an unrealistic goal, but I've got pretty far down the path
 of designing it, though I definitely don't want to declare victory
 until I've figured out a strategy for covering every reasonably common
 use case.

 -Luke

 On May 27, 5:54 pm, Heinz N. Gies he...@licenser.net wrote:



  +1 For swing especially since I started this already. Look for clj-swing
  in github, since this seems quite a load of work I'd be glad for any
  help so :).

  Regards,
  Heinz
  On May 27, 2010, at 21:30 , Luc Préfontaine wrote:

   +1 for Swing.
   On Thu, 2010-05-27 at 11:59 -0700, Brian Schlining wrote:
   +1 Swing.
+1 Swing.
 +1 Swing.  There's a ton of documentation out there, and it got
 some

 --
 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

-- 
Sent from my mobile device

Need somewhere to put your code? http://patch-tag.com
Want to build a webapp? http://happstack.com

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Sean Devlin]

For those of you complaining about the Swing LAF, learn to use the
UIManager class :)

(defn set-laf!
  [laf-name]
  (javax.swing.UIManager/setLookAndFeel laf-name))

On May 27, 7:51 pm, Armando Blancas armando_blan...@yahoo.com wrote:
  Remember, the actual API won't matter - that will be completely
  abstracted away. So try to focus on the framework's look and feel.
  Thanks!
  -Luke

 SWT, because of the native look and feel. I really don't like the
 looks of Swing. As a user of some Swing app, I don't find solace from
 thinking how convenient it was for the programmers to deliver that
 thing to me. As a developer, dealing with the packaging/deployment
 just comes with the job and the results, I think, are well worth the
 effort.

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[mmwaikar]

I work on .Net, so my observation could be totally wrong, but I think
JavaFx could be an option to consider (specially because of its JSON
kind of syntax).
I am working on a WPF project currently, and although WPF is big and
complex, the kind of UIs one can build with it is amazing, and JavaFx
looked similar to me in intent and purpose.

So I am really surprised why no one mentioned JavaFx. Is it because
it's new?

On May 27, 11:18 am, Luke VanderHart luke.vanderh...@gmail.com
wrote:
 My side project is a fairly complex GUI application written in
 Clojure. Recently, I've become irritated with using Java interop for
 everything. It's not that Clojure doesn't have nice java interop - it
 does. It's just that when interacting with a GUI framework, which is a
 large part of my app, I have to be back in mutable object-oriented
 land, worrying about class hierarchies, mutable state, locks, etc.
 Yucky.

 So, with a perhaps dangerous lack of sanity and without any guarantee
 of success, I've decided to try my hand at writing an idiomatic
 Clojure GUI library. If I have success (which I doubt) I will of
 course make it available as open source.

 I intend for it to be mostly declarative, with a nice DSL for defining
 GUI elements. Each component will also implement map, and use one of
 Clojure's reference types as an interface for inspecting / updating
 its state. I may also implement some aspects of Functional Reactive
 Programming wherever it's convenient to do so.

 What you all must help me decide is what GUI framework to use as the
 underpinnings of it. It's genuinely hard to decide. I have at least
 some experience with all of them, so I have no strong preference, but
 I'd like to get your input. I did consider trying to make it abstract
 enough that you could plug in *any* of them under the hood, but
 there's enough differences between the frameworks that that would get
 very ugly very fast.

 Possibilities are:

 AWT
 Pros: native widgets, bundled with Java, low-level
 Cons: few widgets, considered somewhat obselete

 Swing
 Pros: bundled with Java, good widget selection
 Cons: non-native widgets

 SWT
 Pros: native widgets, widely used
 Cons: requires platform-specific libs

 QT Jambi
 Pros: native widgets, huge widget selection, highly-regarded framework
 Cons: requires platform-specific libs, writing custom widgets is
 hairy, momentum and support seem to be lagging since Nokia dropped
 official support.

 Remember, the actual API won't matter - that will be completely
 abstracted away. So try to focus on the framework's look and feel.
 Also let me know if I've missed any of the framework's key
 characteristics.

 Thanks!

 -Luke

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Martin DeMello]

On Fri, May 28, 2010 at 7:29 PM, mmwaikar mmwai...@gmail.com wrote:
 QT Jambi
 Pros: native widgets, huge widget selection, highly-regarded framework
 Cons: requires platform-specific libs, writing custom widgets is
 hairy, momentum and support seem to be lagging since Nokia dropped
 official support.

I would love to see an idiomatic clojure QtJambi wrapper that solves
the writing custom widgets is hairy problem.

martin

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Luke VanderHart]

My understanding may be wrong, but I think JavaFX is intended more as
a competitor to Flash or Silverlight than a GUI toolkit. It'd probably
be great for a Clojure games framework, or for simple graphical
drawing and such, but I'm not sure it's appropriate for a complex,
high performance GUI. In fact, according to the Wiki page, if you want
to use desktop style widgets, you actually end up embedding Swing
components *within* JavaFX anyway.

On May 28, 9:59 am, mmwaikar mmwai...@gmail.com wrote:
 I work on .Net, so my observation could be totally wrong, but I think
 JavaFx could be an option to consider (specially because of its JSON
 kind of syntax).
 I am working on a WPF project currently, and although WPF is big and
 complex, the kind of UIs one can build with it is amazing, and JavaFx
 looked similar to me in intent and purpose.

 So I am really surprised why no one mentioned JavaFx. Is it because
 it's new?

 On May 27, 11:18 am, Luke VanderHart luke.vanderh...@gmail.com
 wrote:

  My side project is a fairly complex GUI application written in
  Clojure. Recently, I've become irritated with using Java interop for
  everything. It's not that Clojure doesn't have nice java interop - it
  does. It's just that when interacting with a GUI framework, which is a
  large part of my app, I have to be back in mutable object-oriented
  land, worrying about class hierarchies, mutable state, locks, etc.
  Yucky.

  So, with a perhaps dangerous lack of sanity and without any guarantee
  of success, I've decided to try my hand at writing an idiomatic
  Clojure GUI library. If I have success (which I doubt) I will of
  course make it available as open source.

  I intend for it to be mostly declarative, with a nice DSL for defining
  GUI elements. Each component will also implement map, and use one of
  Clojure's reference types as an interface for inspecting / updating
  its state. I may also implement some aspects of Functional Reactive
  Programming wherever it's convenient to do so.

  What you all must help me decide is what GUI framework to use as the
  underpinnings of it. It's genuinely hard to decide. I have at least
  some experience with all of them, so I have no strong preference, but
  I'd like to get your input. I did consider trying to make it abstract
  enough that you could plug in *any* of them under the hood, but
  there's enough differences between the frameworks that that would get
  very ugly very fast.

  Possibilities are:

  AWT
  Pros: native widgets, bundled with Java, low-level
  Cons: few widgets, considered somewhat obselete

  Swing
  Pros: bundled with Java, good widget selection
  Cons: non-native widgets

  SWT
  Pros: native widgets, widely used
  Cons: requires platform-specific libs

  QT Jambi
  Pros: native widgets, huge widget selection, highly-regarded framework
  Cons: requires platform-specific libs, writing custom widgets is
  hairy, momentum and support seem to be lagging since Nokia dropped
  official support.

  Remember, the actual API won't matter - that will be completely
  abstracted away. So try to focus on the framework's look and feel.
  Also let me know if I've missed any of the framework's key
  characteristics.

  Thanks!

  -Luke

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Luke VanderHart]

 I would love to see an idiomatic clojure QtJambi wrapper that solves
 the writing custom widgets is hairy problem.

I think QT Jambi's basic architecture precludes this. Jambi is
basically a bunch of JNI calls to a backend C++ QT app. As soon as you
start delving into Jambi's internals, you end up in C++ land.

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[laseray]

+1 Swing

If I had my druthers I would go with QtJambi, but since Nokia dropped
development for that it has not been able to keep pace with Qt. So
that would be immediately out of sync. Plus the need for platform
native compiled code is a minus. Fine for the main three (Linux, Mac,
Windows) with precompiled libs, but separate compile for anything else
equals ongoing maintenance effort. This defeats the point of having a
cross-platform language. Java and Clojure will work (.e.g, on FreeBSD,
OpenSolaris, AIX), but the GUI won't unless you make extra C/C++
coding effort?

SWT is a minus due to native code needs, too much XML configuration,
and the fact that it does not look nearly as good as some people think
when used cross-platform. Looks fine on Windows, the Mac side is
getting better now that they are starting to use Cocoa underneath,
Linux side is questionable with varying appearance across different
window managers. Other OS? This is the same as for QtJambi, extra C/C+
+ coding effort needed to be really cross-platform.

No reason to go with AWT exclusively. A lot of Swing wraps parts of or
needs AWT anyway. You can't really get away from it and will be
cutting off a limb, so to speak, if you go with it rather than Swing
first.

A lot of the misgivings about Swing look and feel across platform
boils down to bad GUI development efforts. I have seen this many
times. Many developers just do not understand the specific interface
needs across different platforms and just leave parameters at the
default settings, which only by luck will be near optimal. I have
developed a number of Swing applications that look pretty close to
native (at least on Linux, Mac, Windows, Solaris) so I can say that it
takes some attention to platform specific details to make this happen
(and access to multiple OS).  That is what it takes to develop a
serious professional cross-platform desktop application, no way around
it (you would even have to do this if going with QtJambi or SWT).

Overall, I would go with Swing. The main reason is that it will
already be cross-platform on any Java compliant OS that can run
Clojure. I think that is the most important thing if you want a GUI to
go along with the language. Nothing additional is needed to complicate
matters, besides the GUI layer/framework on top of Clojure.

Nonetheless, the best idea would be to ensure you have enough
abstraction in your implementation so that other GUI toolkits could be
almost dropped in place later on. That is, it should not close out
other toolkits, but going with what will work now or sooner than later
is better. Going with Swing is a way to get something out soon without
having to spend additional effort worrying about C/C++ libraries,
packaging and so on. Get something to work, then the additional
toolkits can come.

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Mikhail Kryshen]

I vote for Swing.

Swing components conform to JavaBeans specification, so a generic
Clojure library to construct and manipulate JavaBeans would make
a large part of the GUI framework.

On 27 май, 19:18, Luke VanderHart luke.vanderh...@gmail.com wrote:
 My side project is a fairly complex GUI application written in
 Clojure. Recently, I've become irritated with using Java interop for
 everything. It's not that Clojure doesn't have nice java interop - it
 does. It's just that when interacting with a GUI framework, which is a
 large part of my app, I have to be back in mutable object-oriented
 land, worrying about class hierarchies, mutable state, locks, etc.
 Yucky.

 So, with a perhaps dangerous lack of sanity and without any guarantee
 of success, I've decided to try my hand at writing an idiomatic
 Clojure GUI library. If I have success (which I doubt) I will of
 course make it available as open source.

 I intend for it to be mostly declarative, with a nice DSL for defining
 GUI elements. Each component will also implement map, and use one of
 Clojure's reference types as an interface for inspecting / updating
 its state. I may also implement some aspects of Functional Reactive
 Programming wherever it's convenient to do so.

 What you all must help me decide is what GUI framework to use as the
 underpinnings of it. It's genuinely hard to decide. I have at least
 some experience with all of them, so I have no strong preference, but
 I'd like to get your input. I did consider trying to make it abstract
 enough that you could plug in *any* of them under the hood, but
 there's enough differences between the frameworks that that would get
 very ugly very fast.

 Possibilities are:

 AWT
 Pros: native widgets, bundled with Java, low-level
 Cons: few widgets, considered somewhat obselete

 Swing
 Pros: bundled with Java, good widget selection
 Cons: non-native widgets

 SWT
 Pros: native widgets, widely used
 Cons: requires platform-specific libs

 QT Jambi
 Pros: native widgets, huge widget selection, highly-regarded framework
 Cons: requires platform-specific libs, writing custom widgets is
 hairy, momentum and support seem to be lagging since Nokia dropped
 official support.

 Remember, the actual API won't matter - that will be completely
 abstracted away. So try to focus on the framework's look and feel.
 Also let me know if I've missed any of the framework's key
 characteristics.

 Thanks!

 -Luke

-- 
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

Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Luke VanderHart]

My side project is a fairly complex GUI application written in
Clojure. Recently, I've become irritated with using Java interop for
everything. It's not that Clojure doesn't have nice java interop - it
does. It's just that when interacting with a GUI framework, which is a
large part of my app, I have to be back in mutable object-oriented
land, worrying about class hierarchies, mutable state, locks, etc.
Yucky.

So, with a perhaps dangerous lack of sanity and without any guarantee
of success, I've decided to try my hand at writing an idiomatic
Clojure GUI library. If I have success (which I doubt) I will of
course make it available as open source.

I intend for it to be mostly declarative, with a nice DSL for defining
GUI elements. Each component will also implement map, and use one of
Clojure's reference types as an interface for inspecting / updating
its state. I may also implement some aspects of Functional Reactive
Programming wherever it's convenient to do so.

What you all must help me decide is what GUI framework to use as the
underpinnings of it. It's genuinely hard to decide. I have at least
some experience with all of them, so I have no strong preference, but
I'd like to get your input. I did consider trying to make it abstract
enough that you could plug in *any* of them under the hood, but
there's enough differences between the frameworks that that would get
very ugly very fast.

Possibilities are:

AWT
Pros: native widgets, bundled with Java, low-level
Cons: few widgets, considered somewhat obselete

Swing
Pros: bundled with Java, good widget selection
Cons: non-native widgets

SWT
Pros: native widgets, widely used
Cons: requires platform-specific libs

QT Jambi
Pros: native widgets, huge widget selection, highly-regarded framework
Cons: requires platform-specific libs, writing custom widgets is
hairy, momentum and support seem to be lagging since Nokia dropped
official support.

Remember, the actual API won't matter - that will be completely
abstracted away. So try to focus on the framework's look and feel.
Also let me know if I've missed any of the framework's key
characteristics.

Thanks!

-Luke















-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Laurent PETIT]

Although I work with SWT at work, I would say Swing for 2 reasons :

  * no additional dependency for users of your lib, and *no need* for users
of your lib to deliver different final apps binaries for different platforms
  * may be easier to work with in your implementation (?)

2010/5/27 Luke VanderHart luke.vanderh...@gmail.com

 My side project is a fairly complex GUI application written in
 Clojure. Recently, I've become irritated with using Java interop for
 everything. It's not that Clojure doesn't have nice java interop - it
 does. It's just that when interacting with a GUI framework, which is a
 large part of my app, I have to be back in mutable object-oriented
 land, worrying about class hierarchies, mutable state, locks, etc.
 Yucky.

 So, with a perhaps dangerous lack of sanity and without any guarantee
 of success, I've decided to try my hand at writing an idiomatic
 Clojure GUI library. If I have success (which I doubt) I will of
 course make it available as open source.

 I intend for it to be mostly declarative, with a nice DSL for defining
 GUI elements. Each component will also implement map, and use one of
 Clojure's reference types as an interface for inspecting / updating
 its state. I may also implement some aspects of Functional Reactive
 Programming wherever it's convenient to do so.

 What you all must help me decide is what GUI framework to use as the
 underpinnings of it. It's genuinely hard to decide. I have at least
 some experience with all of them, so I have no strong preference, but
 I'd like to get your input. I did consider trying to make it abstract
 enough that you could plug in *any* of them under the hood, but
 there's enough differences between the frameworks that that would get
 very ugly very fast.

 Possibilities are:

 AWT
 Pros: native widgets, bundled with Java, low-level
 Cons: few widgets, considered somewhat obselete

 Swing
 Pros: bundled with Java, good widget selection
 Cons: non-native widgets

 SWT
 Pros: native widgets, widely used
 Cons: requires platform-specific libs

 QT Jambi
 Pros: native widgets, huge widget selection, highly-regarded framework
 Cons: requires platform-specific libs, writing custom widgets is
 hairy, momentum and support seem to be lagging since Nokia dropped
 official support.

 Remember, the actual API won't matter - that will be completely
 abstracted away. So try to focus on the framework's look and feel.
 Also let me know if I've missed any of the framework's key
 characteristics.

 Thanks!

 -Luke















 --
 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.comclojure%2bunsubscr...@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 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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Sean Devlin]

+1 Swing.  There's a ton of documentation out there, and it got some
serious love from Sun between java 5 and 6.

On May 27, 11:27 am, Laurent PETIT laurent.pe...@gmail.com wrote:
 Although I work with SWT at work, I would say Swing for 2 reasons :

   * no additional dependency for users of your lib, and *no need* for users
 of your lib to deliver different final apps binaries for different platforms
   * may be easier to work with in your implementation (?)

 2010/5/27 Luke VanderHart luke.vanderh...@gmail.com

  My side project is a fairly complex GUI application written in
  Clojure. Recently, I've become irritated with using Java interop for
  everything. It's not that Clojure doesn't have nice java interop - it
  does. It's just that when interacting with a GUI framework, which is a
  large part of my app, I have to be back in mutable object-oriented
  land, worrying about class hierarchies, mutable state, locks, etc.
  Yucky.

  So, with a perhaps dangerous lack of sanity and without any guarantee
  of success, I've decided to try my hand at writing an idiomatic
  Clojure GUI library. If I have success (which I doubt) I will of
  course make it available as open source.

  I intend for it to be mostly declarative, with a nice DSL for defining
  GUI elements. Each component will also implement map, and use one of
  Clojure's reference types as an interface for inspecting / updating
  its state. I may also implement some aspects of Functional Reactive
  Programming wherever it's convenient to do so.

  What you all must help me decide is what GUI framework to use as the
  underpinnings of it. It's genuinely hard to decide. I have at least
  some experience with all of them, so I have no strong preference, but
  I'd like to get your input. I did consider trying to make it abstract
  enough that you could plug in *any* of them under the hood, but
  there's enough differences between the frameworks that that would get
  very ugly very fast.

  Possibilities are:

  AWT
  Pros: native widgets, bundled with Java, low-level
  Cons: few widgets, considered somewhat obselete

  Swing
  Pros: bundled with Java, good widget selection
  Cons: non-native widgets

  SWT
  Pros: native widgets, widely used
  Cons: requires platform-specific libs

  QT Jambi
  Pros: native widgets, huge widget selection, highly-regarded framework
  Cons: requires platform-specific libs, writing custom widgets is
  hairy, momentum and support seem to be lagging since Nokia dropped
  official support.

  Remember, the actual API won't matter - that will be completely
  abstracted away. So try to focus on the framework's look and feel.
  Also let me know if I've missed any of the framework's key
  characteristics.

  Thanks!

  -Luke

  --
  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.comclojure%2bunsubscr...@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 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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Stuart Halloway]

+1 Swing. 
 +1 Swing.  There's a ton of documentation out there, and it got some
 serious love from Sun between java 5 and 6.
 
 On May 27, 11:27 am, Laurent PETIT laurent.pe...@gmail.com wrote:
 Although I work with SWT at work, I would say Swing for 2 reasons :
 
   * no additional dependency for users of your lib, and *no need* for users
 of your lib to deliver different final apps binaries for different platforms
   * may be easier to work with in your implementation (?)
 
 2010/5/27 Luke VanderHart luke.vanderh...@gmail.com
 
 My side project is a fairly complex GUI application written in
 Clojure. Recently, I've become irritated with using Java interop for
 everything. It's not that Clojure doesn't have nice java interop - it
 does. It's just that when interacting with a GUI framework, which is a
 large part of my app, I have to be back in mutable object-oriented
 land, worrying about class hierarchies, mutable state, locks, etc.
 Yucky.
 
 So, with a perhaps dangerous lack of sanity and without any guarantee
 of success, I've decided to try my hand at writing an idiomatic
 Clojure GUI library. If I have success (which I doubt) I will of
 course make it available as open source.
 
 I intend for it to be mostly declarative, with a nice DSL for defining
 GUI elements. Each component will also implement map, and use one of
 Clojure's reference types as an interface for inspecting / updating
 its state. I may also implement some aspects of Functional Reactive
 Programming wherever it's convenient to do so.
 
 What you all must help me decide is what GUI framework to use as the
 underpinnings of it. It's genuinely hard to decide. I have at least
 some experience with all of them, so I have no strong preference, but
 I'd like to get your input. I did consider trying to make it abstract
 enough that you could plug in *any* of them under the hood, but
 there's enough differences between the frameworks that that would get
 very ugly very fast.
 
 Possibilities are:
 
 AWT
 Pros: native widgets, bundled with Java, low-level
 Cons: few widgets, considered somewhat obselete
 
 Swing
 Pros: bundled with Java, good widget selection
 Cons: non-native widgets
 
 SWT
 Pros: native widgets, widely used
 Cons: requires platform-specific libs
 
 QT Jambi
 Pros: native widgets, huge widget selection, highly-regarded framework
 Cons: requires platform-specific libs, writing custom widgets is
 hairy, momentum and support seem to be lagging since Nokia dropped
 official support.
 
 Remember, the actual API won't matter - that will be completely
 abstracted away. So try to focus on the framework's look and feel.
 Also let me know if I've missed any of the framework's key
 characteristics.
 
 Thanks!
 
 -Luke
 
 --
 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.comclojure%2bunsubscr...@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 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 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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[BerlinBrown]

There are really only two mainstream options SWT and Swing.  Both will
suffice.

I preferred SWT just because I like the Eclipse project. As you know
SWT is the core GUI library behind SWT.  I just feel that SWT has more
large applications developed, Eclipse, azureus

Swing can be frustrating for the most basic things like working with
the layout manager and non-blocking calls.

SWT provides mature widgets like the Web Browser widget, the text
editor (JFaces), the calendar widget.

But yea, Swing does work out of the box, cross platform.

I am not really a GUI desktop developer, I like SWT slightly more but
I do some quick apps with Swing.

On May 27, 11:42 am, Stuart Halloway stuart.hallo...@gmail.com
wrote:
 +1 Swing.

  +1 Swing.  There's a ton of documentation out there, and it got some
  serious love from Sun between java 5 and 6.

  On May 27, 11:27 am, Laurent PETIT laurent.pe...@gmail.com wrote:
  Although I work with SWT at work, I would say Swing for 2 reasons :

    * no additional dependency for users of your lib, and *no need* for users
  of your lib to deliver different final apps binaries for different 
  platforms
    * may be easier to work with in your implementation (?)

  2010/5/27 Luke VanderHart luke.vanderh...@gmail.com

  My side project is a fairly complex GUI application written in
  Clojure. Recently, I've become irritated with using Java interop for
  everything. It's not that Clojure doesn't have nice java interop - it
  does. It's just that when interacting with a GUI framework, which is a
  large part of my app, I have to be back in mutable object-oriented
  land, worrying about class hierarchies, mutable state, locks, etc.
  Yucky.

  So, with a perhaps dangerous lack of sanity and without any guarantee
  of success, I've decided to try my hand at writing an idiomatic
  Clojure GUI library. If I have success (which I doubt) I will of
  course make it available as open source.

  I intend for it to be mostly declarative, with a nice DSL for defining
  GUI elements. Each component will also implement map, and use one of
  Clojure's reference types as an interface for inspecting / updating
  its state. I may also implement some aspects of Functional Reactive
  Programming wherever it's convenient to do so.

  What you all must help me decide is what GUI framework to use as the
  underpinnings of it. It's genuinely hard to decide. I have at least
  some experience with all of them, so I have no strong preference, but
  I'd like to get your input. I did consider trying to make it abstract
  enough that you could plug in *any* of them under the hood, but
  there's enough differences between the frameworks that that would get
  very ugly very fast.

  Possibilities are:

  AWT
  Pros: native widgets, bundled with Java, low-level
  Cons: few widgets, considered somewhat obselete

  Swing
  Pros: bundled with Java, good widget selection
  Cons: non-native widgets

  SWT
  Pros: native widgets, widely used
  Cons: requires platform-specific libs

  QT Jambi
  Pros: native widgets, huge widget selection, highly-regarded framework
  Cons: requires platform-specific libs, writing custom widgets is
  hairy, momentum and support seem to be lagging since Nokia dropped
  official support.

  Remember, the actual API won't matter - that will be completely
  abstracted away. So try to focus on the framework's look and feel.
  Also let me know if I've missed any of the framework's key
  characteristics.

  Thanks!

  -Luke

  --
  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.comclojure%2bunsubscr...@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 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 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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Brian Schlining]

+1 Swing. SWT comes with far to many deployment headaches.

 +1 Swing.
 
   +1 Swing.  There's a ton of documentation out there, and it got some
   serious love from Sun between java 5 and 6.
 
   On May 27, 11:27 am, Laurent PETIT laurent.pe...@gmail.com wrote:
   Although I work with SWT at work, I would say Swing for 2 reasons :
 
 * no additional dependency for users of your lib, and *no need* for
 users
   of your lib to deliver different final apps binaries for different
 platforms
 * may be easier to work with in your implementation (?)--


~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlin...@gmail.com

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Heinz N. Gies]

+1 For swing especially since I started this already. Look for clj-swing in 
github, since this seems quite a load of work I'd be glad for any help so :).

Regards,
Heinz
On May 27, 2010, at 21:30 , Luc Préfontaine wrote:
 +1 for Swing.
 On Thu, 2010-05-27 at 11:59 -0700, Brian Schlining wrote:
 +1 Swing.
  +1 Swing.
   +1 Swing.  There's a ton of documentation out there, and it got some

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Luke VanderHart]

Thanks, Heinz... I may.

Right now I'm still exploring what I want the API to be. I was hoping
to achieve something a bit thicker that could insulate the user from
Java classes completely. The user wouldn't even have to know Swing or
handle JObjects or worry about the event thread... In other words, it
wouldn't be a wrapper API for Swing, but a Clojure GUI api that,
coincidentally, is /backed/ by Swing.

This may be an unrealistic goal, but I've got pretty far down the path
of designing it, though I definitely don't want to declare victory
until I've figured out a strategy for covering every reasonably common
use case.

-Luke




On May 27, 5:54 pm, Heinz N. Gies he...@licenser.net wrote:
 +1 For swing especially since I started this already. Look for clj-swing in 
 github, since this seems quite a load of work I'd be glad for any help so :).

 Regards,
 Heinz
 On May 27, 2010, at 21:30 , Luc Préfontaine wrote:



  +1 for Swing.
  On Thu, 2010-05-27 at 11:59 -0700, Brian Schlining wrote:
  +1 Swing.
   +1 Swing.
+1 Swing.  There's a ton of documentation out there, and it got some

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Armando Blancas]

 Remember, the actual API won't matter - that will be completely
 abstracted away. So try to focus on the framework's look and feel.
 Thanks!
 -Luke

SWT, because of the native look and feel. I really don't like the
looks of Swing. As a user of some Swing app, I don't find solace from
thinking how convenient it was for the programmers to deliver that
thing to me. As a developer, dealing with the packaging/deployment
just comes with the job and the results, I think, are well worth the
effort.

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Antony Blakey]

On 28/05/2010, at 9:21 AM, Armando Blancas wrote:

 Remember, the actual API won't matter - that will be completely
 abstracted away. So try to focus on the framework's look and feel.
 Thanks!
 -Luke
 
 SWT, because of the native look and feel. I really don't like the
 looks of Swing. As a user of some Swing app, I don't find solace from
 thinking how convenient it was for the programmers to deliver that
 thing to me. As a developer, dealing with the packaging/deployment
 just comes with the job and the results, I think, are well worth the
 effort.

+1 SWT. I think arguments that focus on the ease of deployment are misguided 
because an app is *used* far more times than it is deployed, so one really 
should focus on the quality of the end application. In any case, deployment and 
packaging for different platforms is easy to automate.

Antony Blakey
--
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The trouble with the world is that the stupid are cocksure and the intelligent 
are full of doubt.
  -- Bertrand Russell


-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[BerlinBrown]

Swing seems like a proof of concept UI toolkit.

SWT just seems a bit more polished and easier to develop, working
apps.

That is just an opinion and I like that Swing is built-in.

On May 27, 8:13 pm, Antony Blakey antony.bla...@gmail.com wrote:
 On 28/05/2010, at 9:21 AM, Armando Blancas wrote:

  Remember, the actual API won't matter - that will be completely
  abstracted away. So try to focus on the framework's look and feel.
  Thanks!
  -Luke

  SWT, because of the native look and feel. I really don't like the
  looks of Swing. As a user of some Swing app, I don't find solace from
  thinking how convenient it was for the programmers to deliver that
  thing to me. As a developer, dealing with the packaging/deployment
  just comes with the job and the results, I think, are well worth the
  effort.

 +1 SWT. I think arguments that focus on the ease of deployment are misguided 
 because an app is *used* far more times than it is deployed, so one really 
 should focus on the quality of the end application. In any case, deployment 
 and packaging for different platforms is easy to automate.

 Antony Blakey
 --
 CTO, Linkuistics Pty Ltd
 Ph: 0438 840 787

 The trouble with the world is that the stupid are cocksure and the 
 intelligent are full of doubt.
   -- Bertrand Russell

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Joost]

Personally, I prefer SWT over Swing mostly because seems a lot more
useful and a little more responsive to the user.

But then I think Swing is horrible and SWT is just a bit better. I
seriously prefer Tk over both (except for the file selection dialogs
on Unix).

Consider this a + vote for SWT and possibly QT.

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Jason Smith]

Why not design it so that it can be backed by Swing or SWT or HTML
(perhaps with some AJAX) or whatever?  It seems kind of silly to do an
abstraction on a single backend, don't you think?

On May 27, 4:37 pm, Luke VanderHart luke.vanderh...@gmail.com wrote:
 Thanks, Heinz... I may.

 Right now I'm still exploring what I want the API to be. I was hoping
 to achieve something a bit thicker that could insulate the user from
 Java classes completely. The user wouldn't even have to know Swing or
 handle JObjects or worry about the event thread... In other words, it
 wouldn't be a wrapper API for Swing, but a Clojure GUI api that,
 coincidentally, is /backed/ by Swing.

 This may be an unrealistic goal, but I've got pretty far down the path
 of designing it, though I definitely don't want to declare victory
 until I've figured out a strategy for covering every reasonably common
 use case.

 -Luke

 On May 27, 5:54 pm, Heinz N. Gies he...@licenser.net wrote:



  +1 For swing especially since I started this already. Look for clj-swing in 
  github, since this seems quite a load of work I'd be glad for any help so 
  :).

  Regards,
  Heinz
  On May 27, 2010, at 21:30 , Luc Préfontaine wrote:

   +1 for Swing.
   On Thu, 2010-05-27 at 11:59 -0700, Brian Schlining wrote:
   +1 Swing.
+1 Swing.
 +1 Swing.  There's a ton of documentation out there, and it got some

-- 
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

Re: Which GUI toolkit would you like to see wrapped in an idiomatic Clojure library?

[Luke VanderHart]

 Why not design it so that it can be backed by Swing or SWT or HTML
 (perhaps with some AJAX) or whatever?  It seems kind of silly to do an
 abstraction on a single backend, don't you think?

Ideally, yes. In practice, I'd rather implement one framework well
than implement only the lowest common denominator of several. We're
not just talking creating a window with menus and a few buttons - My
project, for example, is a word processor. Having a requirement that
it work across multiple GUI toolkits sounds a little bit hellish.

That said, I do plan the core API to be abstract enough from the
underlying implementation that it could in theory be backed by a
different framework. I just don't intend to do the work of providing
bindings to multiple implementations and ensuring that behavior is
consistent. If some enterprising soul wants to use the same basic
interfaces to front an alternative implementation, I'll certainly try
to make it conducive to that. But having a API with seamlessly
interchangeable back-ends doesn't sound very feasible.

By the way, do the SWT people only come out at night? Or is it a US vs
Europe issue? Seems somewhat curious that 7 in a row vote for Swing,
then the next 4 are all SWT advocates. Should I expect the QT fans to
show up tomorrow? :p

-- 
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