Marco GUI adecuado para Scala?

Question

Por adecuado, quiero decir:

• maduro y utilizado ampliamente
• conjunto de widgets rico que hace así
• idiomática Scala
• Tienes un constructor WYSIWYG-ish pero GUI flexibles
• documentación API independiente (si es un contenedor, no debería hacerme referir el proyecto principal en otro idioma)

Sin ningún orden en particular.

¿Qué toolkits de GUI satisfacen las condiciones?

Answer 1

Yo diría que use .Net es maduro y se usa mucho.

Pero ...

que suponer que usted necesita para usar Scala. Para eso me quedaría con Java, ya que tiene una mejor herramienta de soporte como en IDEA o NetBeans. Por supuesto, puede mezclar Java y Scala. Entonces su GUI se puede hacer en Java que llama a back-end de Scala. También echa un vistazo a JGoodies que tienen muchas cosas buenas para construir UI en Swing. En este momento, no hay soporte de herramientas para las aplicaciones de la GUI de Scala (y para las que no tienen una GUI todavía está detrás de Java).

Answer 2

Scala tiene su propia biblioteca Swing. Esto utilizará la librería Swing estándar bajo el capó, pero tiene algunas adiciones agradables y sobre todo, porque está hecho de Scala, que puede ser utilizado de una forma mucho más concisa que la biblioteca de apertura Estándar:

import swing._ 

object HelloWorld extends SimpleSwingApplication { 
    def top = new MainFrame { 
    title = "Hello, World!" 
    contents = new Button { 
     text = "Click Me!" 
    } 
    } 
} 

Ver ¿Qué tan agradable y fácil es establecer las propiedades del widget?

A excepción de la sintaxis más agradable y las pequeñas adiciones (como la clase SimpleSwingApplication), creo que las ventajas y desventajas son más o menos lo mismo que con el swing de vainilla.

Aquí hay un Overview of Scala Swing.

Answer 3

Uso Java Swing. He aquí cómo se compara con sus requisitos:

• maduro y usado extensivamente: sí, a ton.

• conjunto de widgets ricos y rinde bien: esto es discutible. Cuando considera la posibilidad de complementar fácilmente Java Swing con bibliotecas adicionales (por ejemplo, SwingX), al menos funciona mejor que Scala Swing en este aspecto, aunque probablemente no tan bien como algunos otros kits de herramientas de Java (aunque no puedo hablar con ellos). .

• idiomático Scala: no es tan malo como se podría pensar. Unas funciones de ayuda hacen mejor:

  implicit class And[A](a: A) { 
      def and(f: A => Unit): A = { 
      f(a); a 
      } 
  } 
  

  Así que usted puede hacer

  val button = (new JButton("Press me!") 
      and (_ setForeground Color.red) 
      and (_ setFont new Font(null, Font.PLAIN, 12))) 
  
  val win = (new JFrame("Hello!") 
      and (_ add button) 
      and (_ pack()) 
      and (_ setDefaultCloseOperation JFrame.EXIT_ON_CLOSE) 
      and (_ setVisible(true))) 
  

  Ahora en cuanto a eventos y estado, esto sigue siendo, en mi opinión, un borde áspero en todo GUI marcos: los oyentes tienen sus problemas, los flujos de eventos tienen sus problemas.He tenido éxito general al aumentar los eventos de Swing con reactive-core y redo-signals (el mío, sin documentar) para facilitar la organización del estado.

  puede mejorar el nivel de detalle de la definición de los oyentes con unas cuantas más funciones auxiliares como

  def actionListener(f: => Unit) = new ActionListener { 
      def actionPerformed(e: ActionEvent) { f } 
      } 
  

  y

  def later(thing: => Unit) { 
      SwingUtilities.invokeLater(new Runnable { 
       def run() { 
       thing 
       } 
      }) 
      } 
  

  Personalmente, deseo Scala oscilación había tomado esta ruta. La redacción de envoltorios para las clases Java existentes es O (n) tiempo del programador, y no obtiene nada para las clases para las que los autores no eligieron escribir envoltorios. Crear azúcar sintáctico genérico te llevará mucho más rápido.

• Tengo un constructor de GUI WYSIWYG-ish pero flexible: uso formularios IntelliJ IDEA, para hacer una clase abstracta, y luego la subclase con una clase Scala. El costo organizacional es solo 1 archivo extra, y no escribo código Java.

• Documentación de API independiente: sí.

Answer 4

ScalaFX es una envoltura madura alrededor de JavaFX 2. Es superficialmente similar a Scala oscilación en algunos aspectos, pero tiene algunas características que hacen que se destaque:

• acoplamientos a bibliotecas de gráficos nativos - Esto significa acceso a la aceleración de hardware y otras ventajas, pero requiere que el tiempo de ejecución de JavaFX se instale en el sistema. Está incluido en la mayoría de las principales distribuciones de Java 8. Esto también significa que rinde muy bien en los sistemas con los que es compatible.

• Enlaces a la propiedad: esta es la característica más importante para mí. Digamos que tengo tres elementos: A, B y C. A y B son redimensionables, y se supone que C tiene una altura que es la suma de las alturas de A y B en todo momento. En Swing, esto implicaría escribir un conjunto de oyentes de eventos personalizados para realizar este trabajo. Los enlaces ScalaFX le permiten expresar esto simplemente usando el operador de enlace de propiedad: C.height <== A.height + B.height. Esto, entre otras características, crea una sensación muy idiomática de Scala.

• JavaFX Scene Builder (en beta como de la escritura) es un editor de GUI WYSIWYG (no lo he probado, sin embargo).

• La documentación es su punto débil. Al ser un envoltorio, a menudo hace referencia a la documentación de JavaFX.

Answer 5

Ahora que ha pasado algún tiempo, vale la pena señalar que ScalaJS también es una opción a considerar.

contra sus requerimientos:

• madura y ampliamente utilizado - HTML/CSS/JS son, ScalaJS no es (pero es sorprendentemente bueno teniendo en cuenta). Por lo tanto, puede encontrarse con problemas específicos de ScalaJS, pero la tecnología subyacente es muy sólida.
• conjunto de widgets ricos que rinde bien - Sí.
• idiomático Scala - No: terminará usando una gran cantidad de jquery, que en su mayoría se escribirán dinámicamente. ScalaTags hace mucho para mejorarlo.
• Tengo un constructor de GUI WYSIWYG-ish pero flexible - Sí, muchos.
• documentación de API independiente (si es un contenedor, no debería hacerme referir el proyecto principal en otro idioma) - Sí.

El inconveniente es que saca su GUI de la JVM y la lleva al explorador, por lo que no puede usar todas esas bibliotecas Java.