Scala UI futures

View: New views
11 Messages — Rating Filter:   Alert me  

Scala UI futures

by Jonathan Edwards-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Scala is an impressive and forward-looking language. Except for those of us who need to build a UI. Why is the Scala community investing in an old-fashioned UI like Swing? Swing just doesn't cut it in the modern world of Flex/Silverlight/JavaFX. These support a declarative scenegraph instead of procedural rectangular composition. F#+Silverlight has that today. The obvious solution is to wrap JavaFX's internal API's to enable its usage from Scala. But I can find no evidence that anyone is doing that, perhaps because Sun is not supporting those interfaces, and actively breaking them. There is a preliminary effort in Groovy. Or perhaps give up on Sun and build a portal to Flex. One way or another, something beyond Swing is needed to build state of the art UI's with Scala. It is the only thing stopping me from adopting Scala.

[There is no point in debating the merits of Swing here. The fact is that developers have been voting with their feet for a long time, and even Sun is investing in an alternative now. Whether fairly or not, Swing is now a dead end.]


Re: Scala UI futures

by Ingo Maier-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Jonathan, we have chosen to support Swing since we wanted to have a UI
framework with a Scala-esque API that is usable right now.

Before we started the wrapper, I have been developing a scene
graph-based framework that uses concepts from functional reactive
programming (FRP) instead of listeners. This even goes beyond what
JavaFX supports today. Unfortunately, I have been slowed down by various
things lately. While the FRP layer is much more stable than before, the
UI still needs a lot of work. I do realize that this is not something I
will be able to continue on my own, hence my focus for the rest of year
will be to bring it to a state where I can open up the code and others
will be able to participate in its development. It is a pretty ambitious
project though, and I can't say when and how experimental it will be.

On a side note, the Java platform right now lacks a lot of things for
modern UIs, such as cross platform, efficient graphics hardware support
that is exposed in public APIs as well as modern media APIs. I really do
hope this will change in the future, but as of now, we have to do a lot
of things on our own. I am also looking forward to Scala on MSIL, since
it seems to be a better platform for graphics related things, but again,
unfortunately not cross platform.

Ingo



Jonathan Edwards wrote:

> Scala is an impressive and forward-looking language. Except for those of
> us who need to build a UI. Why is the Scala community investing in an
> old-fashioned UI like Swing? Swing just doesn't cut it in the modern
> world of Flex/Silverlight/JavaFX. These support a declarative scenegraph
> instead of procedural rectangular composition. F#+Silverlight has that
> today. The obvious solution is to wrap JavaFX's internal API's to enable
> its usage from Scala. But I can find no evidence that anyone is doing
> that, perhaps because Sun is not supporting those interfaces, and
> actively breaking them. There is a preliminary effort
> <http://www.jroller.com/aalmiray/entry/fxbuilder_0_1_alpha>in Groovy. Or
> perhaps give up on Sun and build a portal to Flex. One way or another,
> something beyond Swing is needed to build state of the art UI's with
> Scala. It is the only thing stopping me from adopting Scala.
>
> [There is no point in debating the merits of Swing here. The fact is
> that developers have been voting with their feet for a long time, and
> even Sun is investing in an alternative now. Whether fairly or not,
> Swing is now a dead end.]
>


Re: Scala UI futures

by Ismael Juma :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ingo Maier <ingo.maier <at> epfl.ch> writes:
> On a side note, the Java platform right now lacks a lot of things for
> modern UIs, such as cross platform, efficient graphics hardware support
> that is exposed in public APIs

An interesting development is the Java Shader Language used by the effects
framework in JavaFX:

"JSL is simliar in syntax to GLSL/HLSL/Cg, but in practice it's closer
to Cg in that it can be compiled down into various targets (GLSL,
HLSL, Java, C, etc)."[1]

Unfortunately, it seems like there are no plans to expose it as a public API.

> as well as modern media APIs.

Available in JavaFX. Hopefully it will trickle down to the plain JDK in JDK7.

Best,
Ismael

[1] http://forums.java.net/jive/thread.jspa?threadID=45674&tstart=0


Re: Re: Scala UI futures

by Ingo Maier-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ismael Juma wrote:

> Ingo Maier <ingo.maier <at> epfl.ch> writes:
>> On a side note, the Java platform right now lacks a lot of things for
>> modern UIs, such as cross platform, efficient graphics hardware support
>> that is exposed in public APIs
>
> An interesting development is the Java Shader Language used by the effects
> framework in JavaFX:
>
> "JSL is simliar in syntax to GLSL/HLSL/Cg, but in practice it's closer
> to Cg in that it can be compiled down into various targets (GLSL,
> HLSL, Java, C, etc)."[1]

I have a prototype of a shader language in Scala as well. But that's not
the point. JSL GPU acceleration doesn't work on all major platforms on
graphics drivers of all three major vendors. And as you pointed out,
it's not public API. Just as the OpenGL/Java2D bridge is not public API.

>
> Unfortunately, it seems like there are no plans to expose it as a public API.
>
>> as well as modern media APIs.
>
> Available in JavaFX. Hopefully it will trickle down to the plain JDK in JDK7

Well, there is a start in JavaFX 1.2. We'll see how it works out. I was
postitive when they started the Java OpenGL pipeline as well. Years
passed and it's still not reliable.

Ingo

.
>
> Best,
> Ismael
>
> [1] http://forums.java.net/jive/thread.jspa?threadID=45674&tstart=0
>
>


Re: Scala UI futures

by Ismael Juma :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ingo Maier <ingo.maier <at> epfl.ch> writes:
> I have a prototype of a shader language in Scala as well. But that's not
> the point. JSL GPU acceleration doesn't work on all major platforms on
> graphics drivers of all three major vendors.

Sure, but we cannot blame Java for that. The drivers on platforms like Linux are
very flaky. Things are improving, however, and many bugs on the drivers have
been fixed after being reported by Sun engineers who ran into them during
testing. Also, the DirectX back-end for Windows should improve stability on that
platform, at least.

> And as you pointed out, it's not public API. Just as the OpenGL/Java2D
> bridge is not public API.

Yeap, that's a problem.

> Well, there is a start in JavaFX 1.2. We'll see how it works out. I was
> postitive when they started the Java OpenGL pipeline as well. Years
> passed and it's still not reliable.

As I said above, I don't think it's fair to blame Java for flaky drivers.
However, I don't blame you for your scepticism as there are many instances where
Sun started something promising and then messed it up a few months later.

Best,
Ismael


Re: Re: Scala UI futures

by Ingo Maier-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ismael Juma wrote:

> Ingo Maier <ingo.maier <at> epfl.ch> writes:
>> I have a prototype of a shader language in Scala as well. But that's not
>> the point. JSL GPU acceleration doesn't work on all major platforms on
>> graphics drivers of all three major vendors.
>
> Sure, but we cannot blame Java for that. The drivers on platforms like Linux are
> very flaky. Things are improving, however, and many bugs on the drivers have
> been fixed after being reported by Sun engineers who ran into them during
> testing. Also, the DirectX back-end for Windows should improve stability on that
> platform, at least.

I am not blaming Java or Sun for that matter. There are many driver
incompatibilities, not only on Linux, and Intel is pretty far behind
there. I guess it's comparable to web browsers, were you have to code
around HTML/CSS/Javascript incompatibilities, just that new graphics
drivers are released more often than browser revisions.

It's not that the Sun guys are bad engineers. After all, they would be
the first to come up with a cross platform solution. WPF/.Net seems to
work pretty well (I am not a WPF expert though) but MS is in a fortunate
position, since they only have to support one platform, one shading
language, one 3D API, and all of these are under their control. It's a
bit similar for Apple.

>
>> And as you pointed out, it's not public API. Just as the OpenGL/Java2D
>> bridge is not public API.
>
> Yeap, that's a problem.
>
>> Well, there is a start in JavaFX 1.2. We'll see how it works out. I was
>> postitive when they started the Java OpenGL pipeline as well. Years
>> passed and it's still not reliable.
>
> As I said above, I don't think it's fair to blame Java for flaky drivers.
> However, I don't blame you for your scepticism as there are many instances where
> Sun started something promising and then messed it up a few months later.

One thing I don't understand is their license policy with JavaFX. First,
they release something as open source. Then they release something more
advanced under a closed source license. You are not even allowed to
distribute the media components jar in binary form within your own
project. That's weird.

Ingo

>
> Best,
> Ismael
>
>


Re: Scala UI futures

by Ismael Juma :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ingo Maier <ingo.maier <at> epfl.ch> writes:
> I guess it's comparable to web browsers, were you have to code
> around HTML/CSS/Javascript incompatibilities, just that new graphics
> drivers are released more often than browser revisions.

True.
 
> One thing I don't understand is their license policy with JavaFX. First,
> they release something as open source. Then they release something more
> advanced under a closed source license. You are not even allowed to
> distribute the media components jar in binary form within your own
> project. That's weird.

I totally agree. :) This is a good example of Sun doing something interesting
(various client-side improvements) and then messing it up soon after (with a
weird license with lots of restrictions).

I find it particularly strange because they are playing catch-up and the
open-source card was one of the few things that they could have named as an
advantage versus flash and silverlight.

Ismael


Re: Scala UI futures

by Jonathan Edwards-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Ingo Maier wrote:
Jonathan, we have chosen to support Swing since we wanted to have a UI framework with a Scala-esque API that is usable right now.

Before we started the wrapper, I have been developing a scene graph-based framework that uses concepts from functional reactive programming (FRP) instead of listeners. This even goes beyond what JavaFX supports today. Unfortunately, I have been slowed down by various things lately. While the FRP layer is much more stable than before, the UI still needs a lot of work. I do realize that this is not something I will be able to continue on my own, hence my focus for the rest of year will be to bring it to a state where I can open up the code and others will be able to participate in its development. It is a pretty ambitious project though, and I can't say when and how experimental it will be.

On a side note, the Java platform right now lacks a lot of things for modern UIs, such as cross platform, efficient graphics hardware support that is exposed in public APIs as well as modern media APIs. I really do hope this will change in the future, but as of now, we have to do a lot of things on our own. I am also looking forward to Scala on MSIL, since it seems to be a better platform for graphics related things, but again, unfortunately not cross platform.

Wouldn't a wrapper on JavaFX solve many of these issues, such as cross-platform media codecs?

Scala + Silverlight is an interesting idea. I thought Scala had dropped .NET support. If .NET will eventually become a first-class platform (with tail calls!) then in the meantime maybe a JVM/.NET bridge could be used to access Silverlight.

Jonathan

Re: Scala UI futures

by Mohamed Bana-5 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I'm still not pleased with the font rendering provided by Silverlight,
JavaFX and SWING.  Do they allow customising of the rendering algorithm
etc?  I'm glad that Eclipse uses SWT, which on my machine delegates to
FreeType.


On Sun, 2009-06-07 at 10:36 -0400, Jonathan Edwards wrote:

> Scala is an impressive and forward-looking language. Except for those
> of us who need to build a UI. Why is the Scala community investing in
> an old-fashioned UI like Swing? Swing just doesn't cut it in the
> modern world of Flex/Silverlight/JavaFX. These support a declarative
> scenegraph instead of procedural rectangular composition. F#
> +Silverlight has that today. The obvious solution is to wrap JavaFX's
> internal API's to enable its usage from Scala. But I can find no
> evidence that anyone is doing that, perhaps because Sun is not
> supporting those interfaces, and actively breaking them. There is a
> preliminary effortin Groovy. Or perhaps give up on Sun and build a
> portal to Flex. One way or another, something beyond Swing is needed
> to build state of the art UI's with Scala. It is the only thing
> stopping me from adopting Scala.
>
> [There is no point in debating the merits of Swing here. The fact is
> that developers have been voting with their feet for a long time, and
> even Sun is investing in an alternative now. Whether fairly or not,
> Swing is now a dead end.]
>


Re: Scala UI futures

by jherber :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I would not rule out interfacing with the FlashVM.  Anything Silverlight can do, FlashVM will likely be able to do as well - and do it on OS X/Linux and many mobile platforms.  FlashVM is more ubiquitous than the JVM, and most of the tool chain is open source now.

Adobe is also leveraging multi-core and shader languages:  http://www.adobe.com/devnet/flash/articles/pixel_bender_basics.html

A first step would probably be a Scala wrapper around Flash/Flex basic artifacts to declaratively generate UI, perhaps using an internal Scala DSL.  You would also need some socket code to communicate events back and forth to a Scala server.  Coming from another direction, you could probably inject a generic event adapter into most Flash/Flex apps already built and have events forwarded to a Scala GUI server fairly easy.  I'll have to jump in and research this further along with Functional Reactive Programming that was mentioned.









Jonathan Edwards-3 wrote:
instead of procedural rectangular composition. F#+Silverlight has that today

...

perhaps give up on Sun and build a portal to Flex. One way or another,

Re: Scala UI futures

by Walter Smith :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Ingo,

Ingo Maier-3 wrote:
Before we started the wrapper, I have been developing a scene
graph-based framework that uses concepts from functional reactive
programming (FRP) instead of listeners. This even goes beyond what
JavaFX supports today. Unfortunately, I have been slowed down by various
things lately. While the FRP layer is much more stable than before, the
UI still needs a lot of work. I do realize that this is not something I
will be able to continue on my own, hence my focus for the rest of year
will be to bring it to a state where I can open up the code and others
will be able to participate in its development.
That's not how Open Source works best. Release it now, just as it is! There may be others that can help you already. If there are any papers about FRP, release them as well!

I do think that ScalaFX would be the best way to go, though. For a small community there are just far too many things to be done for a GUI framework to work well. Maybe your project could merge both.