Graphic programming in Scala...?

My personal belief is that you should target the web browser. It's all still a bit immature unfortunately. Swing seems like a step backwards in my opinion. The only "client-side application" web-based frameworks I know of is Lift and Scala+GWT. Lift is intimately tied to the server. Scala+GWT I know only by name. The way I've done it is to only rely on javascript + standard plugins for client-side programming and web-services for server communication. Don't know of client-side gui through Lift/GWT is scalable beyond standard forms etc.

On 25 December 2011 15:16, Dinotzar Tzar <dinotzar@gmail.com> wrote:

A not very well-researched and a bit fluffy question: Is there any future for graphic programming in Scala?

Scala's Swing library seems promising, but appears dormant (?) rather than actively developed.
I've seen references to reactive graphical programming, but these efforts seem a bit sketchy so far.

I ask because I'm a lousy GUI programmer, who needs help from a good library not to mess things up completely. (Maybe what I'm looking for is some rich, yet simple,  web based GUI stuff for Scala :)

I would imagine that Scala could be a wonderful place for graphic development, but there seems to be little interest in this topic (just consider the ratio of e.g. Scala Swing related questions on the mailing lists).

D.

I am not sure, but I know that Oracle gave the impression that most of
its future effort for the GUIs will go in JavaFX, both for desktop and
web development.
Maybe scala swing slowed down for this reason. However there is a new
project called ScalaFX. It should be a wrapper of JavaFX similar to
scala swing.
The only problem is that I don't know when JavaFX will work on Linux
and what is the status of ScalaFX.

The only alternatives are web frameworks like Play or Lift.
Another alternative is Vaadin, it is built on GWT and it is targeted
at java and scala developers.

are you looking for a graphics kit or a GUI kit?

for the former, maybe Processing / SPDE are nice alternatives (both use Java2D, i.e. Swing/AWT)

http://spde.technically.us/Spde.html

On 27 Dec 2011, at 16:16, guast wrote:

> I am not sure, but I know that Oracle gave the impression that most of
> its future effort for the GUIs will go in JavaFX, both for desktop and
> web development.
> Maybe scala swing slowed down for this reason. However there is a new
> project called ScalaFX. It should be a wrapper of JavaFX similar to
> scala swing.
> The only problem is that I don't know when JavaFX will work on Linux
> and what is the status of ScalaFX.
>
> The only alternatives are web frameworks like Play or Lift.
> Another alternative is Vaadin, it is built on GWT and it is targeted
> at java and scala developers.

According to the JavaFX 2.0 FAQ, it will reach General Availability in the first half of 2012 for Mac OS, and for linux, it'll be the second half .

On Tue, Dec 27, 2011 at 1:16 PM, guast <v.guast@gmail.com> wrote:

I am not sure, but I know that Oracle gave the impression that most of
its future effort for the GUIs will go in JavaFX, both for desktop and
web development.
Maybe scala swing slowed down for this reason. However there is a new
project called ScalaFX. It should be a wrapper of JavaFX similar to
scala swing.
The only problem is that I don't know when JavaFX will work on Linux
and what is the status of ScalaFX.

The only alternatives are web frameworks like Play or Lift.
Another alternative is Vaadin, it is built on GWT and it is targeted
at java and scala developers.

According to the JavaFX 2.0 FAQ, it will reach General Availability in the first half of 2012 for Mac OS, and for linux, it'll be the second half .

Just to add to that, the latest release of Java 7 (update 2) contains JavaFX. (on windows). The Mac developer preview is available at http://www.oracle.com/technetwork/java/javafx/downloads/devpreview-1429449.html
 --
~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~
Brian Schlining
bschlining@gmail.com

On Tue, Dec 27, 2011 at 4:20 PM, Sciss <contact@sciss.de> wrote:

are you looking for a graphics kit or a GUI kit?

for the former, maybe Processing / SPDE are nice alternatives (both use Java2D, i.e. Swing/AWT)

http://spde.technically.us/Spde.html

Yeah, I'm looking for a GUI kit (but Processing looks fun).


Thanks to all who answered: I'll take a look at GWT and Vaadin.

Lift looks frighteningly complex and weird, but that might be a faulty first impression.

Java/ScalaFX has to wait (I'm on Linux). I did look at the first version of JavaFX a few years ago, but that one seemed to add more problems that it solved. (I guess it will be different this time.)

Thanks!
D.

Scala+GWT is basically a scala to javascript compiler, with GWT support. So there's nothing server-side involved (although of course you can ajax into a server).Reactive-web is a framework I work on that requires Lift, but it gives you a much higher level of abstraction for ajax and comet: you don't have to worry about what happens via ajax or comet, you just link things up. It also has a typesafe javascript dsl. The idea (currently limited in implementation) is to be able to set up as much as possible to happen on the client side, but it's deeply integrated with the parts of the app that's running on the server. There are a ton of other scala web frameworks, from Play to unfiltered and everything in between, so to speak.

On Mon, Dec 26, 2011 at 10:50 AM, Trond Olsen <trond@steinbit.org> wrote:

My personal belief is that you should target the web browser. It's all still a bit immature unfortunately. Swing seems like a step backwards in my opinion. The only "client-side application" web-based frameworks I know of is Lift and Scala+GWT. Lift is intimately tied to the server. Scala+GWT I know only by name. The way I've done it is to only rely on javascript + standard plugins for client-side programming and web-services for server communication. Don't know of client-side gui through Lift/GWT is scalable beyond standard forms etc.

On 25 December 2011 15:16, Dinotzar Tzar <dinotzar@gmail.com> wrote:

A not very well-researched and a bit fluffy question: Is there any future for graphic programming in Scala?

Scala's Swing library seems promising, but appears dormant (?) rather than actively developed.
I've seen references to reactive graphical programming, but these efforts seem a bit sketchy so far.

I ask because I'm a lousy GUI programmer, who needs help from a good library not to mess things up completely. (Maybe what I'm looking for is some rich, yet simple,  web based GUI stuff for Scala :)

I would imagine that Scala could be a wonderful place for graphic development, but there seems to be little interest in this topic (just consider the ratio of e.g. Scala Swing related questions on the mailing lists).

D.

On Fri, Jan 6, 2012 at 9:50 AM, Naftoli Gugenheim <naftoligug@gmail.com> wrote:

Scala+GWT is basically a scala to javascript compiler, with GWT support. So there's nothing server-side involved (although of course you can ajax into a server).

Ah, I see.
 

Reactive-web is a framework I work on that requires Lift, but it gives you a much higher level of abstraction for ajax and comet: you don't have to worry about what happens via ajax or comet, you just link things up. It also has a typesafe javascript dsl. The idea (currently limited in implementation) is to be able to set up as much as possible to happen on the client side, but it's deeply integrated with the parts of the app that's running on the server.

I did take a look at Reactive-Web, but couldn't figure out what is was. (The Getting started guide ends with "Start coding!", and that's where my trouble starts... :)

I'm sure it's very useful, but I'm not experienced enough to figure out what is does. I might give it a shot in the future.

Thanks.
D.
 

There are a ton of other scala web frameworks, from Play to unfiltered and everything in between, so to speak.

On Mon, Dec 26, 2011 at 10:50 AM, Trond Olsen <trond@steinbit.org> wrote:

My personal belief is that you should target the web browser. It's all still a bit immature unfortunately. Swing seems like a step backwards in my opinion. The only "client-side application" web-based frameworks I know of is Lift and Scala+GWT. Lift is intimately tied to the server. Scala+GWT I know only by name. The way I've done it is to only rely on javascript + standard plugins for client-side programming and web-services for server communication. Don't know of client-side gui through Lift/GWT is scalable beyond standard forms etc.

On 25 December 2011 15:16, Dinotzar Tzar <dinotzar@gmail.com> wrote:

A not very well-researched and a bit fluffy question: Is there any future for graphic programming in Scala?

Scala's Swing library seems promising, but appears dormant (?) rather than actively developed.
I've seen references to reactive graphical programming, but these efforts seem a bit sketchy so far.

I ask because I'm a lousy GUI programmer, who needs help from a good library not to mess things up completely. (Maybe what I'm looking for is some rich, yet simple,  web based GUI stuff for Scala :)

I would imagine that Scala could be a wonderful place for graphic development, but there seems to be little interest in this topic (just consider the ratio of e.g. Scala Swing related questions on the mailing lists).

D.

Reactive-web is a framework I work on that requires Lift, but it gives you a much higher level of abstraction for ajax and comet: you don't have to worry about what happens via ajax or comet, you just link things up. It also has a typesafe javascript dsl. The idea (currently limited in implementation) is to be able to set up as much as possible to happen on the client side, but it's deeply integrated with the parts of the app that's running on the server.

I did take a look at Reactive-Web, but couldn't figure out what is was. (The Getting started guide ends with "Start coding!", and that's where my trouble starts... :)

Hmm, perhaps "Getting Started" should be renamed to "Setup." Although, the last line under "Start coding" is "Read on," meaning to read the rest of the site. Here are the essentials you should read: Under Core/EventStream and Core/Signal, read Introduction and skim the rest, checking out the Live Examples; skim whatever you find interesting under Core/SeqSignal; Under Web, read Events, Properties, and Elements. You may like what you see under Javascript and Testing, but using them would come later.  

I'm sure it's very useful, but I'm not experienced enough to figure out what is does. I might give it a shot in the future.

Thanks for the feedback, I see the site really needs some "refactoring" to make it clear what it is to people who don't already know what it is (unlike me)!
First of all, at the end of the day a reactive-web app is a Lift app. That means for example you'll typically use Lift's SiteMap to define page access rules etc., and Lift's css selectors to insert content into a page template. The primary thing reactive-web contributes is that it gives a much higher abstraction level for ajax-y and comet-y user interfaces. (Comet means partial page updates triggered by the server.) A higher abstraction level means less worrying about the low-level plumbing and more describing what you want to happen. To be clear, Lift already has a much higher level of abstraction than most web frameworks, allowing you to set up an scala ajax callback for an event in a one-liner, or a very straightforward way of implementing comet. But you still have to say imperatively "send this update to the browser," "attach this ajax function to this event," etc. If you are in middle of handling an ajax event and you want to update something in the browser, you return the javascript commands to do it. If you want to update the same thing in a server-triggered event (information was updated by someone else), you have to send the javascript, or the updated html, to the right comet actor. Also, Lift imposes a whole paradigm for dealing with comet; to be sure, a very good one, but it may not always be the best fit, and can involve extra work. With reactive-web, however, all you have to do is link things together and updates just happen. If they happen during an ajax call the updates will be sent that way; otherwise they can be sent via comet automatically. Here's a quick example:
//template:<div class="l:reactive"></div><table><tr><td class="name"></tr></table><button>Add</button>
//in BootReactions.init(true)
//snippet (definitions of Person and generateRandomPerson left to your imagination)val people = Var(List.empty[Person]) ..."table" #> Repeater { SeqSignal(people) map (_ map { person =>  ".name *" #> person.name})} &"button" #> (DomEventSource.click ->> {people ()= people.now :+ generateRandomPerson() })
Whenever you click the button, a new person will be added to the list. This will cause a single new <tr> element to be sent to the browser, via ajax. If more than one user has access to the same people Var (put it in a singleton object), the new user will also be sent to the other users via comet. In short, it makes "writing highly interactive and dynamic web applications" much simpler.There's much more, but I hope that whets your appetite!

Naftoli,

thanks for your response. I'm now ten times more interested in
reactive-web, and I will certainly take a look at it again, soon.
Great promotion.

D.

On 1/8/12, Naftoli Gugenheim wrote:
>> Reactive-web is a framework I work on that
>>> requires Lift, but it gives you a much higher level of abstraction for
>>> ajax
>>> and comet: you don't have to worry about what happens via ajax or comet,
>>> you just link things up. It also has a typesafe javascript dsl. The idea
>>> (currently limited in implementation) is to be able to set up as much as
>>> possible to happen on the client side, but it's deeply integrated with
>>> the
>>> parts of the app that's running on the server.
>>>
>>
>> I did take a look at Reactive-Web, but couldn't figure out what is was.
>> (The Getting started guide ends with "Start coding!", and that's where my
>> trouble starts... :)
>>
>
> Hmm, perhaps "Getting Started" should be renamed to "Setup." Although, the
> last line under "Start coding" is "Read on," meaning to read the rest of
> the site.
> Here are the essentials you should read: Under Core/EventStream and
> Core/Signal, read Introduction and skim the rest, checking out the Live
> Examples; skim whatever you find interesting under Core/SeqSignal; Under
> Web, read Events, Properties, and Elements. You may like what you see under
> Javascript and Testing, but using them would come later.
>
>
>>
>> I'm sure it's very useful, but I'm not experienced enough to figure out
>> what is does. I might give it a shot in the future.
>>
>>
> Thanks for the feedback, I see the site really needs some "refactoring" to
> make it clear what it is to people who don't already know what it is
> (unlike me)!
>
> First of all, at the end of the day a reactive-web app is a Lift app. That
> means for example you'll typically use Lift's SiteMap to define page access
> rules etc., and Lift's css selectors to insert content into a page template.
> The primary thing reactive-web contributes is that it gives a much higher
> abstraction level for ajax-y and comet-y user interfaces. (Comet means
> partial page updates triggered by the server.) A higher abstraction level
> means less worrying about the low-level plumbing and more describing what
> you want to happen.
> To be clear, Lift already has a much higher level of abstraction than most
> web frameworks, allowing you to set up an scala ajax callback for an event
> in a one-liner, or a very straightforward way of implementing comet. But
> you still have to say imperatively "send this update to the browser,"
> "attach this ajax function to this event," etc. If you are in middle of
> handling an ajax event and you want to update something in the browser, you
> return the javascript commands to do it. If you want to update the same
> thing in a server-triggered event (information was updated by someone
> else), you have to send the javascript, or the updated html, to the right
> comet actor. Also, Lift imposes a whole paradigm for dealing with comet; to
> be sure, a very good one, but it may not always be the best fit, and can
> involve extra work.
> With reactive-web, however, all you have to do is link things together and
> updates just happen. If they happen during an ajax call the updates will be
> sent that way; otherwise they can be sent via comet automatically. Here's a
> quick example:
>
> //template:
>
> Add
>
> //in Boot
> Reactions.init(true)
>
> //snippet (definitions of Person and generateRandomPerson left to your
> imagination)
> val people = Var(List.empty[Person])
> ...
> "table" #> Repeater { SeqSignal(people) map (_ map { person =>
> ".name *" #> person.name
> })} &
> "button" #> (DomEventSource.click ->> {people ()= people.now :+
> generateRandomPerson() })
>
> Whenever you click the button, a new person will be added to the list. This
> will cause *a single *new element to be sent to the browser, via ajax.
> If more than one user has access to the same people Var (put it in a
> singleton object), the new user will also be sent to the other users via
> comet.
> In short, it makes "writing highly interactive and dynamic web
> applications" much simpler.
> There's much more, but I hope that whets your appetite!
>