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
dozen
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.asy
>> 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 prop
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 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 time
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, 20
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
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 u
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
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 unsu
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 wa
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
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 em
+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 beli
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
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 /
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 AP
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
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 la
+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 wrote:
>
> On 31/05/2010, at 2:27 PM, James Cunningham wrote:
>
>>
>>
>> On May 30
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.j
+1 for swing
On Thu, May 27, 2010 at 8:48 PM, 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 th
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 so
+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 bega
On 31/05/2010, at 2:27 PM, James Cunningham wrote:
>
>
> On May 30, 9:23 pm, Antony Blakey 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 d
On May 30, 9:23 pm, Antony Blakey 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
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
Antony Blakey 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
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 th
On 31/05/2010, at 12:31 PM, Mike Meyer wrote:
> On Mon, 31 May 2010 10:53:45 +0930
> Antony Blakey 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 Ma
Mike Meyer wrote ..
> On Mon, 31 May 2010 10:53:45 +0930
> Antony Blakey 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 su
On Mon, 31 May 2010 10:53:45 +0930
Antony Blakey 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 wor
Antony Blakey 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 woul
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
On Sun, May 30, 2010 at 9:23 PM, Antony Blakey 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 req
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
dif
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: r
On Sun, May 30, 2010 at 8:23 PM, Antony Blakey 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
> come
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 prod
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
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 di
>
>
> 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 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, WebSto
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 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
On May 29, 10:29 pm, Daniel 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
+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 un
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"
JavaFx has one other major issue. The scene graph isn't accessible outside
of JavaFx script.
On Friday, May 28, 2010, Luke VanderHart 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
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
wrote:
> My si
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 wrote:
> My side project is a fairly complex GUI application written in
> Cloj
+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 pr
> 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 en
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 fa
On Fri, May 28, 2010 at 7:29 PM, mmwaikar 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 w
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
look
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 wrote:
> > Remember, the actual API won't matter - that will be completely
> > abstracted away.
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 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 s
I will send patches!! get on github no.
;)
On 5/27/10, Luke VanderHart 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 would
+1 QT
On 5/27/10, Joost 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
> o
2010/5/28 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
> 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
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 wrote:
> Thanks, Heinz... I may.
>
> Right now I'm still exploring what I
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
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 wrote:
> On 28/05/2010, at 9:21 AM, Armando Blancas wrote:
>
> >> Remember, the ac
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. A
> 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
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 wor
+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 for Swing. We deal with multiple platforms here and have enough
headaches with this so lets not hammer again on our poor brains :)))
Luc
On Thu, 2010-05-27 at 11:59 -0700, Brian Schlining wrote:
> +1 Swing. SWT comes with far to many deployment headaches.
>
>
> > +1 Swing.
>
+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 wrote:
> > >> Although I work with SWT at work, I wo
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 t
+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 wrote:
>> Although I work with SWT at work, I would say Swing for 2 reasons :
>>
>> * no additional dependency for users of you
+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 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* fo
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 Van
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 ha
77 matches
Mail list logo