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
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
>> 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
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,
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
>
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
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,
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
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
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
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
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
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
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
+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
+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
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
+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
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
+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 -
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
+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
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
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
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
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
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.
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
+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
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
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
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,
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/
--
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
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
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
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
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.
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:
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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
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
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
+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
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
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
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
+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
+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
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
+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
+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:
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
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
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
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:
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
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
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
74 matches
Mail list logo