c++ - paso - interfaz grafica para lenguaje c

¿Cómo escribir una GUI para un proyecto grande de C++ multiplataforma? (11)

¿Debería separarse la GUI de la lógica de la aplicación?

Sí.

Si está separado, ¿cómo deben comunicarse la lógica y la GUI? ¿Son los sockets TCP / IP una buena opción? ¿Cuáles son otras posibilidades?

TCP / IP va demasiado lejos. Separe la lógica de la aplicación y la GUI utilizando POO o cualquier otro enfoque de programación estructurada.

¿Es una buena idea tener la GUI en un lenguaje diferente a un C ++? En caso afirmativo, ¿en qué idioma?

C ++ es lo suficientemente bueno en lo que respecta a las aplicaciones multiplataforma. Otras opciones son Java y .NET, en cuyo caso, la mayoría de las cosas de plataformas cruzadas se cuidan ... aunque no con el grado de control que proporciona C ++.

¿Es una buena idea tener una GUI basada en navegador?

La mejor idea siempre y cuando su aplicación no necesite un grado de control demasiado fino durante la interacción con el usuario.

A pesar de que la lógica central del proyecto es multiplataforma, puedo decidir que la GUI solo estará basada en Windows (.NET?) Y se comunicará con la lógica en la máquina Win / Linux relevante mediante Socket o un método similar. ¿Es una buena idea hacerlo?

En mi humilde opinión la complejidad añadida de usar sockets no vale la pena.

SciTE es un ejemplo bastante bueno de una aplicación multiplataforma simple. El código fuente debe ser fácil de seguir para un programador de Windows. Le sugiero que descargue la fuente y eche un vistazo a cómo dos plataformas (Windows y GTK) se han manejado con el mismo código base.

Tengo un gran proyecto de C ++ multiplataforma (Linux y Windows), para el que quiero crear una GUI.

Tengo algunas preguntas muy generales sobre los principios básicos de GUI para tal proyecto:

¿Debería separarse la GUI de la lógica de la aplicación?
Si está separado, ¿cómo deben comunicarse la lógica y la GUI? ¿Son los sockets TCP / IP una buena opción? ¿Cuáles son otras posibilidades?
¿Es una buena idea tener la GUI en un lenguaje diferente a un C ++? En caso afirmativo, ¿en qué idioma?
¿Es una buena idea tener una GUI basada en navegador?
A pesar de que la lógica central del proyecto es multiplataforma, puedo decidir que la GUI solo estará basada en Windows (.NET?) Y se comunicará con la lógica en la máquina Win / Linux relevante mediante Socket o un método similar. ¿Es una buena idea hacerlo?

¿Debería separarse la GUI de la lógica de la aplicación?

Debería, porque los widgets de UI son solo tipos de objetos y una de las reglas de OO dice que cada objeto debe ser confiable con las responsabilidades que puede cumplir. Un diálogo no sabe mucho acerca de la serialización, por ejemplo.

Si está separado, ¿cómo deben comunicarse la lógica y la GUI? ¿Son los sockets TCP / IP una buena opción? ¿Cuáles son otras posibilidades?

Depende de cuánta separación necesites. Utilizo mensajes asíncronos para la comunicación, y luego puedo usar diferentes capas de transporte sin muchos cambios. TCP / IP le permitiría usar la GUI en una máquina separada del núcleo, pero tiene una sobrecarga más alta que pasar mensajes de ventana, por ejemplo.

¿Es una buena idea tener la GUI en un lenguaje diferente a un C ++? En caso afirmativo, ¿en qué idioma?

Idealmente, debería usar la menor cantidad de idiomas posible a menos que realmente necesite las capacidades técnicas de un idioma determinado. Las GUI son más un problema de biblioteca que un problema de idioma, por lo que si puede encontrar una biblioteca de IU de C ++ muy buena (sugerencia: Qt), debe codificar todo su programa en C ++.

¿Es una buena idea tener una GUI basada en navegador?

Podría ser, pero debes pensar en los requisitos y no en las ideas. ¿Sus clientes quieren interactuar con su programa desde un navegador? ¿Pueden pagar los costos adicionales y el tiempo de desarrollo? ¿Tienes el know-how?

A pesar de que la lógica central del proyecto es multiplataforma, puedo decidir que la GUI solo estará basada en Windows (.NET?) Y se comunicará con la lógica en la máquina Win / Linux relevante a través de Socket o un método similar. ¿Es una buena idea hacerlo?

Podría ser una buena idea, pero vea la respuesta al # 3. También tenga en cuenta que va a trabajar en un programa cliente-servidor, que es mucho más complicado que un programa independiente. Finalmente, debe examinar los pros y los contras de una dependencia de .NET sobre el uso de una biblioteca de IU de C ++: lo que .NET le ofrece que no pudo obtener con wxWdigets, Qt, gtkmm, etc.

¿Debería separarse la GUI de la lógica de la aplicación?
Sí definitivamente....
Si está separado, ¿cómo deben comunicarse la lógica y la GUI? ¿Son los sockets TCP / IP una buena opción? ¿Cuáles son otras posibilidades?
... pero no tanto. Los enchufes serían excesivos (excepción: vea la pregunta 5). Por lo general, se dividen las clases en GUI y backend partes. Las clases de GUI luego llaman a los métodos del backend.
¿Es una buena idea tener la GUI en un lenguaje diferente a un C ++? En caso afirmativo, ¿en qué idioma?
Si es así, tendría que integrar los dos idiomas, por lo que recomendaría escribir todo en el mismo idioma. Pero para responder a su pregunta, podría, por ejemplo, crear enlaces de Python para su backend y escribir la GUI en Python (con PyGTK, PyQT o wxWidgets).
¿Es una buena idea tener una GUI basada en navegador?
Eso depende de cómo quieras desplegar tu aplicación. Si debería instalarse en cada computadora cliente, una interfaz web no tiene sentido. Si desea alojarlo centralmente, entonces puede optar por una interfaz web.
A pesar de que la lógica central del proyecto es multiplataforma, puedo decidir que la GUI solo estará basada en Windows (.NET?) Y se comunicará con la lógica en la máquina Win / Linux relevante mediante Socket o un método similar. ¿Es una buena idea hacerlo?
Creo que esto tiene sentido solo si el backend debe ser seguro (es decir, no debe estar instalado en las computadoras de los usuarios) o si tiene un enfoque similar al de un cliente ligero como en la pregunta 4. Escribir GUI multiplataforma es mucho más fácil que escribiendo backends multiplataforma (en mi opinión), por lo que debería hacer ambas partes multiplataforma. Por cierto, las GUI basadas en .NET no son solo para Windows. Mono ya es compatible con un gran subconjunto de Formularios de Windows, por ejemplo (pero no WPF, lamentablemente).

EDITAR:

Con respecto a su pregunta sobre Mono: Mono es mayormente estable, pero aún no todo está implementado. Para estar seguro, puede ejecutar The Mono Migration Analyzer (MoMA) para averiguar si algo no funcionará en Mono. Pero creo que el hecho de que tantas empresas estén utilizando Mono con éxito en entornos de producción significa que, al menos, debe considerar a Mono como una opción.

(1) Por lo general, sí, esto permite mantener la lógica de negocios y la interfaz de usuario por separado. También le permite tener más adelante, por ejemplo, una interfaz de usuario SaaS basada en navegador, así como un modo de operación sin red local de estilo de escritorio y aún compartir todo el código lógico de la aplicación.

(2) No usar sockets TCP / IP. Normalmente, la aplicación y la GUI se comunican mediante el paso de eventos y / o mensajes. Por ejemplo, cuando la aplicación desea notificar a la GUI que algo sucede, crea un evento sintético que luego se envía a la cola de eventos de la GUI. Si la aplicación también está basada en eventos, la GUI puede comunicarse con ella publicando eventos. Para las operaciones rápidas sin bloqueo, la GUI puede llamar directamente al código lógico de la aplicación, pero luego se debe garantizar que la llamada regrese rápidamente. Para operaciones más lentas, necesita un hilo separado de todos modos para procesarlos. Este subproceso puede ser el que procesa los eventos del lado de la aplicación, o puede generarse como un subproceso de trabajo cuando sea necesario.

El producto de nuestra compañía tiene una interfaz de usuario sobre el IDE de Eclipse, pero parte de la lógica de la aplicación está escrita en C ++. Las dos partes se comunican a través de CORBA, es decir, básicamente un mecanismo de evento asíncrono. Hemos estado contentos con esta solución.

En una escala más pequeña, las aplicaciones GUI suelen separar la UI y la lógica de la aplicación utilizando abstracciones como Model-View-Controller (MVC).

(3) Siempre es una molestia integrar componentes escritos en dos componentes diferentes. Creo que deberías hacerlo solo si tienes un beneficio obvio de plataforma. Por ejemplo, nos beneficiamos de los componentes IDE de Eclipse, mientras que la aplicación se beneficia de la velocidad bruta de C ++.

(4) Las GUI basadas en el navegador son excelentes, pero la integración con la lógica empresarial sufre de latencia y el modo sin estado de los servidores web hace que la arquitectura sea incómoda si en realidad tiene una aplicación de estilo de escritorio. Una GUI basada en navegador es buena para aplicaciones de software como servicio porque no requieren la instalación del usuario y el desarrollador del producto puede actualizarlas a voluntad, pero si no planea ofrecer su producto como un Producto de software como servicio (por ejemplo, Salesforce).

(5) Si la lógica de su aplicación es multiplataforma, trataría de esforzarme para que la interfaz de usuario también sea multiplataforma. De lo contrario, para aquellas plataformas en las que solo sea compatible con la lógica de la aplicación, es posible que necesite instalar dos sistemas operativos, uno para ejecutar la interfaz de usuario y otro para ejecutar la lógica de la aplicación. Hay buenos marcos de interfaz de usuario multiplataforma, al menos

AJAX / interfaz de usuario basada en navegador
Trolltech / Nokia Qt
Eclipse (SWT)
Java Swing (hmm ...)

Algunos usuarios ya dieron algunas buenas respuestas a tus preguntas, por eso quiero darte algunos consejos sobre cómo manejar mis proyectos.

P: ¿En qué sistema operativo debería ejecutarse mi aplicación?

Windows y Linux! -> Yo usaría C ++ o Java

P: ¿Es importante la velocidad de ejecución?

¡Sí! (cálculos, gráficos, acceso a los recursos del sistema ...) -> En vista de la velocidad, C ++ suele ser más rápido (no siempre)

P: ¿Se requiere un archivo de configuración?

A: si! Tengo que establecer algunos valores específicos del usuario y del sistema. -> Podríamos guardar la configuración en el registro, pero como también queremos usar nuestra aplicación en Linux, usemos xml (rapidxml sería una buena solución para C ++)

P: ¿Se requiere una base de datos?

R: Sí, tengo algunos datos / cálculos que necesito guardar (local / global). -> Local: utilizaría sqlite -> Si solo tiene que guardar relativamente poca información, considere una forma más rápida de almacenar esta información (¿xml ?!)

P: ¿Cómo debo estructurar mi aplicación?

R: SIEMPRE mantenga su GUI separada de la parte "lógica" -> Hace que sea más fácil cambiar su código más adelante y también podrá usar su código para otros proyectos. + Las razones ya mencionadas.

P: ¿Cómo debo estructurar mi GUI?

R: Piense en qué debe usarse su aplicación y qué deben poder hacer los usuarios. Ah, y por favor no cree una jerarquía demasiado profunda, lo que significa que el usuario no debería tener que abrir 10 ventanas para abrir la ventana que desea tener. Lo mismo ocurre con su código, no es una decisión acertada tener demasiados objetos que creen un nuevo objeto.

object->object->object->object->object->object->object->object

P: ¿Mi aplicación tiene que comunicarse con una aplicación de servidor?

A: si Tendrás que usar sockets! Pero tenga en cuenta que las comunicaciones a través de sockets no son muy rápidas y seguras, así que no las use si no tiene que hacerlo.

P: No estoy seguro de cómo empezar (somos un grupo de desarrolladores)

R: Al comenzar un nuevo proyecto, estoy pensando en todos estos puntos (quizás algunos más) + Para ver qué clases y métodos necesito, comienzo creando un Diagrama UML que me ayudará a entender dónde debo comenzar y el diagrama también me ayudará a realizar un seguimiento de mis clases y métodos y de cómo están involucrados entre sí. El Diagrama UML también ayudará a sus compañeros o clientes a comprender cómo se estructurará su aplicación.

Para proyectos más grandes usaría C ++ y wxWidgits o tal vez Qt. (Solo mi punto de vista)

Rgds Layne

Estoy de acuerdo con los comentaristas que dijeron "no hay suficiente información", pero dependiendo de sus necesidades, debe prestar MUCHA consideración a la interfaz de un navegador web.

Si los datos de transmisión en tiempo real y la interactividad de la gratificación instantánea no son importantes, la interfaz web puede ser bastante sencilla sin AJAX y solo CGI basado en formas triviales y HTML generado dinámicamente. Tenga en cuenta que la parte que existe a medida que el navegador se actualiza con el dinero de otras personas junto con cualquier cambio en Windows, Linux, Mac u otros sistemas.

Sus usuarios ya encuentran esto familiar. Puedes encontrar programadores para hacer el trabajo. Las bibliotecas ya existen en casi todos los idiomas principales para integrar un servidor web de forma nativa en una aplicación, si es necesario. O puede ejecutar un servidor centralizado de algún tipo.

El navegador ya cuenta con un buen medio para separar el contenido, la entrada (formularios), el estilo y la mejora, donde será fácil encontrar personas en el futuro que puedan desarrollar o cambiar el componente relevante.

Algunas personas pueden decir que no es bueno para versiones independientes de la aplicación, pero yo digo que está bien para ser independiente siempre que agregue algo de seguridad (ejecute un servidor web incorporado donde las solicitudes solo se contesten si provienen de la computadora local). La vida del usuario se puede hacer más fácil iniciando el navegador desde la aplicación o indicándole dónde ir en el mensaje de inicio (la URL http: // localhost: 7654 o lo que sea, no su destino eterno :-)).

Mi respuesta es muy genérica ya que no dijiste nada sobre tu aplicación.

¿Debería separarse la GUI de la lógica de la aplicación?

En el código, definitivamente. Ejecutar en un proceso separado, posiblemente en una máquina separada, también puede ser una buena idea, pero esto realmente depende de sus requisitos.

Razones para separarlo completamente:

Ejecutar la aplicación como un servicio de sistema o demonio (en segundo plano) mientras la GUI no se está ejecutando
Control de la aplicación de forma remota a través de una red
Posibilidad de múltiples implementaciones de GUI independientes, utilizando diferentes lenguajes de programación (por ejemplo, iPhone?)
Soporte para control automatizado (scripting) sin GUI
Implementar la separación más tarde, si no se hace inicialmente, es casi imposible

Razones por las que no se separan:

Se requiere la serialización de todas las E / S, lo que dificulta la implementación
Disminución leve del rendimiento si se transfieren grandes cantidades de datos (esto no afecta de ninguna manera a su aplicación GUI típica)

Si está separado, ¿cómo deben comunicarse la lógica y la GUI? ¿Son los sockets TCP / IP una buena opción? ¿Cuáles son otras posibilidades?

HTTP es una opción popular y evita la mayoría de los problemas con los firewalls y demás. En C / C ++ puede usar libcurl para solicitudes http / https y Boost.CGI (aún no aceptado en Boost) o una de las otras bibliotecas CGI para el servidor.

Otras opciones para IPC incluyen memoria compartida (Boost.Interprocess), sockets UNIX y otros protocolos de red. Sin embargo, no recomendaría esto a menos que se transfieran grandes cantidades de datos.

¿Es una buena idea tener la GUI en un lenguaje diferente a un C ++? En caso afirmativo, ¿en qué idioma?

No veo mucho beneficio de esto. Sin embargo, separar la GUI permite escribirla, posiblemente incluso implementaciones múltiples, en diferentes idiomas.

¿Es una buena idea tener una GUI basada en navegador?

Seguro. Si lo que necesita se puede hacer con HTML5 y JavaScript, ni siquiera considere una GUI tradicional, simplemente haga una aplicación web.

Los beneficios son:

Completamente multiplataforma
No hay instalación de software en las máquinas de los usuarios.
Todos los clientes utilizan siempre la última versión de la GUI
Los marcos de GUI web son realmente más agradables para trabajar que los marcos de GUI tradicionales
No es necesario separar la GUI en un proceso separado
Todavía es posible usar desde scripts (por ejemplo, usando el programa curl desde un script de shell)

Por otro lado, obtendrás una leve degradación del rendimiento, pero una vez más, no afecta lo suficiente a una aplicación GUI típica como para que importe.

A pesar de que la lógica central del proyecto es multiplataforma, puedo decidir que la GUI solo estará basada en Windows (.NET?) Y se comunicará con la lógica en la máquina Win / Linux relevante mediante Socket o un método similar. ¿Es una buena idea hacerlo?

Las API de las bibliotecas GUI multiplataforma son algo horribles. Qt hace un buen trabajo al parecer nativo en la actualidad y su API es bastante buena, aunque tiene un gran impacto en su aplicación. Intente restringir cualquier uso de Qt estrictamente a la GUI. La otra opción para una verdadera interfaz gráfica de usuario multiplataforma nativa es wxWidgets, que se integra mejor con otro código C ++, pero tiene una API muy desagradable y propensa a errores.

Para la interfaz de usuario web, definitivamente debe considerar Wt, que es un marco A ++X de C ++ de alto nivel, con una interfaz similar a Qt, pero utilizando prácticas modernas de C ++ en lugar de tomar el control de su aplicación como lo hace Qt.

Si desea un buen ejemplo de una solución GUI multiplataforma que sea gratuita y esté bien escrita, le sugiero que consulte wxWidgets ( 1 ). espero que esto ayude

Tienes muchas buenas respuestas, pero aun así escribiré las mías.

¿Debería separarse la GUI de la lógica de la aplicación?

Creo que es lo mejor. Así que puedes manejarlo más fácilmente cuando se trata de modificaciones. Además, use un marco de GUI que sea multiplataforma y tenga enlaces para otros idiomas, como GTK + o Qt.

Si está separado, ¿cómo deben comunicarse la lógica y la GUI? ¿Son los sockets TCP / IP una buena opción? ¿Cuáles son otras posibilidades?

Los sockets son una buena opción o mediante hilos si se trata de comunicación local.

¿Es una buena idea tener la GUI en un lenguaje diferente a un C ++? En caso afirmativo, ¿en qué idioma?

Creo que no es la mejor opción. Usa el mismo idioma para todo si puedes.

¿Es una buena idea tener una GUI basada en navegador?

Mientras no sea demasiado complejo. Creo que las GUI basadas en el navegador son solo para herramientas colaborativas o independientes de la plataforma absoluta (cada sistema operativo tiene un navegador) en la medida en que usted mantiene el programa principal en un servidor. Como alguien dijo avobe, si considera hacer una GUI web, considere hacer primero una aplicación web.

A pesar de que la lógica central del proyecto es multiplataforma, puedo decidir que la GUI solo estará basada en Windows (.NET?) Y se comunicará con la lógica en la máquina Win / Linux relevante a través de Socket o un método similar. ¿Es una buena idea hacerlo?

No en mi opinión, agrega complejidad, generalmente innecesaria, pero si realmente tiene que hacer eso, sí, los sockets son la mejor opción.

es mejor usar python como su lenguaje gui base con QT como plataforma gui. Si divide la interfaz gráfica de usuario y el programa base en procesos separados, puede utilizar estos mecanismos para la comunicación:

Señales y ranuras de Qt
módulo de subproceso en python
enchufes locales.
usar archivos [escribir configuraciones para archivar y señalar otro proceso para actualizar]

pero es mejor crear un proceso y llamar a su idioma base directamente desde python y comunicarse con las estructuras de datos del idioma nativo. Tu gato usa un trago para este propósito. pero como no puede llamar a las funciones de python desde C ++, puede usar la agrupación en python para realizar algunos cambios en los datos compartidos y hacer algo en función de estos cambios. Experimenté de dos maneras. Cuando utilicé Python para GUI y administración, puede ahorrar mucho tiempo.

1. ¿Debería separarse la GUI de la lógica de la aplicación?

Sí. Sin embargo, ver respuesta # 2

2. Si está separado, ¿cómo deben comunicarse la lógica y la GUI? ¿Son los sockets TCP / IP una buena opción? ¿Cuáles son otras posibilidades?

Creo que esta es la mejor respuesta al elegir un marco GUI, MFC, .NET, wxWidgets, Qt,…. El marco que elija se ocupará de la separación y la comunicación por usted, de la manera más sencilla posible.

No intentes reinventar la rueda. Los diseñadores de marcos han pensado mucho más en sus implementaciones y en las pruebas que usted podría permitirse.

Tenga en cuenta que la pregunta # 1 sugiere que está preguntando sobre la separación de la lógica en una sola aplicación. Sin embargo, las preguntas posteriores sugieren que puede estar pensando en dos aplicaciones separadas, tal vez incluso ejecutándose en máquinas separadas.

Considero que tener la GUI en una aplicación completamente separada siempre resultará en algo que será lento e inflexible. Sin embargo, si no le importa la velocidad y la flexibilidad, y especialmente si ya tiene la aplicación central ejecutándose con una interfaz de tipo de consola simple, esta podría ser la mejor manera de hacerlo.

3. ¿Es una buena idea tener la GUI en un lenguaje diferente a un C ++? En caso afirmativo, ¿qué idioma?

No.

Si usted es un equipo de programación de una sola persona, entonces se estará extendiendo demasiado tratando de dominar dos idiomas. Si usted es un equipo de varias personas, ¿por qué agravar los problemas de comunicación al establecer dos culturas diferentes?

4. ¿Es una buena idea tener una GUI basada en navegador?

No si puedes evitarlo. Si necesita una GUI basada en navegador, entonces lo sabrá. Si no necesita uno, entonces mantenga las cosas simples y omítalas.

5. Aunque la lógica central del proyecto es multiplataforma, puedo decidir que la GUI solo estará basada en Windows (.NET?) Y se comunicará con la lógica en la máquina Win / Linux relevante a través de Socket o un método similar. ¿Es una buena idea hacerlo?

Misma respuesta como # 4