studio - wpf tutorial español

¿Cuáles son las alternativas de código abierto para WPF/XAML?

Question

Si hemos aprendido algo de HTML / CSS es que los lenguajes declarativos (como XML) hacen un buen trabajo al describir interfaces de usuario porque:

1. Es fácil construir preprocesadores de código que puedan moldear el código de forma efectiva.
2. El código está en un formato bien estructurado (idealmente) bien definido por lo que es fácil de analizar.
3. La tecnología para analizar o rastrear efectivamente un archivo fuente basado en XML ya existe.
4. El código con guiones de UI se vuelve mucho más simple y fácil de entender.
5. Es lo suficientemente simple como para que los diseñadores puedan diseñar la interfaz ellos mismos.
6. Los programadores apestan a la creación de interfaces de usuario, por lo que debería ser lo suficientemente fácil para los diseñadores.

Recientemente eché un vistazo a la carne de una aplicación WPF (es decir, el XAML) y se ve sorprendentemente familiar para el estilo de lenguaje declarativo utilizado en HTML.

El estado actual del desarrollo de la interfaz de usuario de escritorio está muy fraccionado, de lo contrario no habría tanto esfuerzo duplicado en el dominio del diseño de la interfaz gráfica de usuario (por ejemplo, GTK, XUL, Qt, Winforms, WPF, etc.).

Hay 45 plataformas GUI para Python solo

¿Cuáles son algunas GUI de código abierto que representan estas características?

• estandarizado
• plataforma independiente
• lenguaje de marcado declarativo
• lenguaje agnóstico

WPF, o más específicamente XAML parece ser un paso bastante probable en la dirección correcta.

Actualizar:

Muchas gracias por la información, sigan viniendo. Estas son las opciones que he recopilado de los comentarios y respuestas.

GladeXML

• Editor: Glade Interface Designer
• Plataformas de SO: todas
• Plataforma GUI: GTK+
• Idiomas: C (libglade), C ++, C # (Glade #), Python, Ada, Pike, Perl, PHP, Eiffel, Ruby

XRC (Recurso XML)

• Editores: wxGlade , XRCed , wxDesigner , DialogBlocks (no libre)
• Plataformas de SO: todas
• Plataforma GUI: wxWidgets
• Idiomas: C ++, Python ( wxPython ), Perl ( wxPerl ), .NET ( wx.NET )

Formatos basados ​​en XML que no son gratuitos, no son multiplataforma o son específicos del idioma

XUL

• Editor: cualquier editor de texto básico
• Plataformas de sistema operativo: cualquier sistema operativo que ejecute un navegador que admita XUL
• Plataforma GUI: Gecko Engine?
• Idiomas: C ++, Python, Ruby como lenguajes de plugin no idiomas base

Nota: no estoy seguro de si XUL merece mención en esta lista porque es menos un lenguaje de GUI de escritorio y más de un lenguaje make-webapps-run-on-the-desktop. Además, requiere un navegador para funcionar. IE, es ''DHTML para el escritorio''.

CookSwing

• Editor: Eclipse través de WindowBuilder , NetBeans 5.0 (no libre) a través del Swing GUI Builder aka Matisse
• Plataformas de SO: todas
• Plataforma GUI: Java
• Idiomas: solo Java

XAML (Luz de luna)

• Editor: MonoDevelop
• Plataformas de SO: solo Linux y otros sistemas operativos basados ​​en Unix / X11
• Plataformas GUI: GTK+
• Idiomas: .NET

Nota: XAML no es un formato de código abierto puro porque Microsoft controla sus términos de uso, incluido el derecho de cambiar los términos en cualquier momento. Moonlight legalmente no puede ejecutarse en Windows o Mac. Además, la única plataforma que está exenta de acciones legales es Novell. Vea esto para una descripción completa de lo que quiero decir. XAML tampoco es un estándar de ECMA como C #, Managed C ++ y CLR.

Actualización: la pregunta ha cambiado de "¿Existe una alternativa de Código abierto para WPF? Porque la pregunta original era incorrecta, y apestaba. La dirección de esta pregunta ha cambiado de dirección para coincidir con la nueva entrada. las personas que respondieron antes cambiaron.

Answer 1

Novell tiene una implementación de fuente abierta de Silverlight, con gran soporte para XAML, llamada Moonlight:

http://en.wikipedia.org/wiki/Moonlight_(runtime)

http://www.mono-project.com/Moonlight

Answer 2

Qt está desarrollando QML, que se parece mucho a XAML excepto en JSON. Está disponible como una vista previa construida en contra de la versión actual, y está disponible en instantáneas de la próxima versión.

Aquí hay un pequeño fragmento de http://doc.qt.nokia.com/4.7-snapshot/declarative-ui-components-progressbar.html

import Qt 4.7
import "content"

Rectangle {
   id: main

    width: 600; height: 405
    color: "#edecec"

    Flickable {
       anchors.fill: parent
       contentHeight: column.height + 20

       Column {
           id: column
           x: 10; y: 10
           spacing: 10

           Repeater {
               model: 25

               ProgressBar {
                 property int r: Math.floor(Math.random() * 5000 + 1000)
                 width: main.width - 20

                 NumberAnimation on value { duration: r; from: 0; to: 100; loops: Animation.Infinite }
                 ColorAnimation on color { duration: r; from: "lightsteelblue"; to: "thistle"; loops: Animation.Infinite }
                 ColorAnimation on secondColor { duration: r; from: "steelblue"; to: "#CD96CD"; loops: Animation.Infinite }
               }
           }
       }
   }
}

Answer 3

• La Web está quitando la mayor parte de la energía de las aplicaciones de escritorio tal como están.

  Creo que la gran razón es que todos están tan concentrados en la web en este momento. HTML5 va a ser un gran avance en lo que la web puede hacer. Con rápidos intérpretes de JavaScript y navegadores capaces, la necesidad de un programa de escritorio comenzará a disminuir con el tiempo. Ese es el caballo en el que Google está apostando, y en mucha menor medida, Apple también.

• Crear algo bueno tendría implementaciones radicalmente diferentes para cada sistema operativo, por lo que el kit de herramientas básico no sería muy portátil.

  Si lo piensas bien, la Web es el único sustrato común que tenemos para desarrollar este tipo de infraestructura de manera multiplataforma. WPF es increíblemente diferente de una perspectiva arquitectónica frente a WinForms / código WinAPI directo. Adaptar algo así para cada sistema operativo requeriría una gran cantidad de tuberías muy diferentes para cada sistema operativo si tuvieras la oración de hacer algo que funcionara bien. (No es que las aplicaciones web sean muy rápidas, pero están mejorando).

• Ver y sentir siempre será un problema.

  ¿De quién es la apariencia que usa? ¿Tratas de adaptar la interfaz de usuario al sistema operativo Chrome para que parezca "nativa", o haces algo como lo hizo Swing hace años y desarrollas aplicaciones que se ven distintivamente diferentes de todo lo demás? (Uf, eso fue un accidente de tren ...) Y si elige adaptar la interfaz de usuario a la apariencia de cada SO, puede tener todo tipo de problemas de medición y diseño.