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

[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.va...@gmail.com>

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

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

> > clojure+u...@googlegroups.com<clojure%2Bunsu...@googlegroups.com>

[Stuart Halloway]

+1 Swing.

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

[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
bschl...@gmail.com

[Luc Préfontaine]

+1 for Swing. We deal with multiple platforms here and have enough headaches with this so lets not hammer again on our poor brains :)))

Luc

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

[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

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

[Antony Blakey]

+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

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

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

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

[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

[Laurent PETIT]

2010/5/28 Luke VanderHart <luke.va...@gmail.com>

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

[Matthew Elder]

+1 QT

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

--
Sent from my mobile device

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

[Matthew Elder]

I will send patches!! get on github nowwww.

;)

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

--

[Matthew Elder]

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

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

--

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

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

[Martin DeMello]

On Fri, May 28, 2010 at 7:29 PM, mmwaikar <mmwa...@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

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

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

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

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

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

[Wilson MacGyver]

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

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

--
Omnem crede diem tibi diluxisse supremum.

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

[p2]

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

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

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

[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
bschl...@gmail.com

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

[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

[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

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

[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

[Marc Spitzer]

On Sun, May 30, 2010 at 8:23 PM, Antony Blakey <antony...@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
>
>

[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 L&F
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

[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

[Marc Spitzer]

On Sun, May 30, 2010 at 9:23 PM, Antony Blakey <antony...@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 L&F
> 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

[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

[lprefo...@softaddicts.ca]

Antony Blakey <antony...@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
>

[Mike Meyer]

On Mon, 31 May 2010 10:53:45 +0930
Antony Blakey <antony...@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

[lprefo...@softaddicts.ca]

Mike Meyer <mwm-keyword-goo...@mired.org> wrote ..

> On Mon, 31 May 2010 10:53:45 +0930
> Antony Blakey <antony...@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.

[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...@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

[Antony Blakey]

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

On 31/05/2010, at 12:31 PM, lprefo...@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

[lprefo...@softaddicts.ca]

Antony Blakey <antony...@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, lprefo...@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
>
>

[Antony Blakey]

On 31/05/2010, at 2:04 PM, lprefo...@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

[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

[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 L&F. 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

[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 L&F 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>

> > > --
> > > You received this message because you are subscribed to the Google
> > > Groups "Clojure" group.
> > > To post to this group, send email to clo...@googlegroups.com
> > > Note that posts from new members are moderated - please be patient with
> > > your first post.
> > > To unsubscribe from this group, send email to

> > > clojure+u...@googlegroups.com<clojure%2Bunsu...@googlegroups.com>

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

[abhi]

+1 for swing

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com

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

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

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

[lprefo...@softaddicts.ca]

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 <las...@gmail.com> wrote ..

[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

[Roger Gilliar]

> 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.
>
----------------------------------------------------
Sounds like a good idea. Swing is great but to be useful needs some
higher level layer anyway. I'm doing something like you probaly have in
mind for JRuby. A high level GUI framework that supports (in theory)
different frameworks. Right now it works with swing and SWT. Maybe we
could share some ideas ?

Regards
Roger

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

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

[chgraham]

+1 JavaFX

 

[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

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

> ---

> 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+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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

--

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

[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

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+u...@googlegroups.com.

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

[Jason Zwolak]

You can diff JavaFX components like that?

--
Jason Zwolak

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

[Colin Fleming]

That sounds great Timothy, thanks!

[Mark Engelberg]

I'm also interested in JavaFX from Clojure.

[Dave Ray]

Inline below..

Dave

On Thu, Mar 17, 2016 at 9:37 AM, Jason Zwolak <jzw...@gmail.com> 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.

[Kimmo Koskinen]

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

[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

[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

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[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

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+u...@googlegroups.com.

[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