Nuevo GUI multitarea o ¿"entorno de ventanas"?

[Acerbaturix]

Hace ya un tiempecito que me hice con una GP2X, mas que para jugar para trastear, el caso es que por una cosa u otra la he tenido muy apartada hasta hace unos días... bien, desde el primer día que la probé, eché en falta una cosa, y es la incapacidad del 'menu' para permitirte tener multiples aplicaciones en ejecución al mismo tiempo, puediendo "maximizar/minizar" y cambiar de una otra, etc.

En definitiva, echaba en falta un "gestor de ventanas" (por llamarlo de alguna manera), algo al estilo de la gui de Symbian OS.

Eso es muy interesante para aplicaciones tipo PDA (no tanto para juegos). Por ejemplo, cojes pones un poco de musica en el reproducir de mp3, lo minizimas y te vas al lector de documentos a leer un ratillo ;).

Estuve ojeando un poco los proyectos de menus que hay por ahí adelante, pero no vi absolutamente nada referido a este tema, asique me puse a pensar como hacerlo.

El problema está en que las librerias gráficas para la GP2X, como SDL escriben directamente sobre el framebuffer del dispositivo, es decir, cada programa mediante las SDL escribe directamente en pantalla, lo cual es un modelo diferente al tipico de un PC, por ejemplo con X Windows, en las que las librerias gráficas utilizan por debajo xlib para comunicarse con el servidor X, y este último es el encargado de escribir en pantalla, gestionando así el acceso a la misma. De esta forma puede controlar que ventana esta delante, detras, y dibujar la pantalla a su antojo.

Eso es algo que con las SDL de la GP2X (por ejemplo), a pelo, no se puede conseguir, por que si hay varios pogramas en ejecución, y estan escribiendo en pantalla, se van a pisar las pantallas uno a otro... asique el objetivo principal era desarrollar un programa que "controlase" el acceso al framerbuffer, de forma que solo escriba en pantalla el proceso que esta en "primer plano".

La primera idea que se me ocurrió fue hacerlo a lo grande, podemos a hacer una especie de miniservidor X para SDL... obviamente es la mejor solución, los programas en vez de escribir directamente en pantalla lo harían a través de este servidor, y asi el control seria totalmente transparente al programa, pero claro, es una cosa un poco complicada :D.

Asique pensé en buscar alguna forma más rapida y "chapucera" de conseguir algo similar.

Pues bien, he estado un par de tardes programando un pequeña versión superalpha, a modo de prueba de concepto de mis ideas, y ahora mismo tengo un menu que es capaz de lanzar procesos, quedarse en segundo plano y cuando se pulsa una determinada tecla, manda una señal de STOP al proceso que está en primer plano, se carga el menu de nuevo en la pantalla (sin lanzar otro proceso, como lo hace el gp2xmenu) y te permite acceder a una pequeña barra de tareas para resumir la ejecución del proceso que estaba minimizado.

Esta implementación de momento tiene varios problemas y limitaciones. Para empezar, los procesos cuando se minimizan, se paran a nivel de sistema operativo, asique no valdría para lo que decía de escuchar musica en segundo plano. Pero ya tengo pensando como arreglar eso, aunque por desgracia, requerirá de cierta ayuda por parte de los programas (a diferencia de la solucion del "servidor X", que sería transparente). Además como mínimo existe un problema, y es que si el programa minimizado utiliza un modo de video diferente al de la GUI, se producen ciertros problemillas a la hora de mostrar cosas por pantalla...

Os quería poner un pequeño video del sistemilla en funcionamiento, pero como tengo tan pocos mensajes, no me deja :(. Si vais a YouTube y buscais los videos de acerbaturix, lo encontrareis.

El objetivo final es hacer esa especie de "servidor X" que permita tener un entorno gráfico propio en la GP2X, algo similar a qTopia, pero mas orientado a dispositivos sin raton y pantalla tactil, y hecho con SDL. Con su barra de tareas para reanudar aplicaciones, teclado en pantalla, barra de sitema con información de batería, cobertura wifi, etc. Y por supuesto con sus aplicaciones asociadas para configurar la consola, utilidades varias...

Me gustaría que me comentaseis que os parece la posibildiad de tener un entorno gráfico de este estilo en la GP2X, y por supuesto críticas e ideas al respecto :).

PDT: Siento el ladrillazo ;)

[Puck2099]

Si te sirve de algo, el servidor X está portado a la GP2X :)

Saludos

[Estopero]

joer puck vaya forma de tirar para abajo un preyecto! [baneo] jeje
es broma, de todas formas por lo que e leido, la idea es de hacer un servidor X orientado a una plataforma sin teclado y raton, me parece muy util! :D, yo te apoyo en tu proyecto y seguro q mucha gente te lo agradecera, un saludo!

< - >
Jur toy buscando el video pero no me aparece nada referente a gp2x, solo otros videos que parecen tuyos pero de otros temas jeje.

[Puck2099]

joer puck vaya forma de tirar para abajo un preyecto! [baneo] jeje

Ey, yo solo lo he dicho por si puede usar el servidor que está portado para hacer su proyecto más fácil y ahorrarse trabajo, no pretendía tirar abajo ningún proyecto... :(

[BuD]

Para vagos:
8qIzS5elxLY

El hecho de que el proyecto se haya pensado exclusivamente para la GP2X ya vale la pena antes que poner un servidor X. Te doy animos para que lo termines. :D

[Puck2099]

BuD, tío, explica qué es ese video, please, que no me entero de nada :p

[BuD]

BuD, tío, explica qué es ese video, please, que no me entero de nada :pPero si es del señor creador, a mi no me mires. Segun a mi entender, es un menu launcher con una barra en la parte superior donde te dice las aplicaciones abiertas...
Segun veo en el video, ejecuta una aplicacion, vuelve al menu sin dejar de ejecutar la aplicacion y luego desde la barra de arriba vuelve a darle foco a esa aplicacion.

[Acerbaturix]

Que susto me llevé con lo de X11, pensé que ya lo había hecho alguien [wei].

Estaba al tanto del port de X11, pero a mi X Windows siempre me ha parecido un entorno demasiado potente y pesado para ser utilizado en dispositivos embebidos. Como ha dicho puck se podría reutilizar el port de X11, por ejemplo haciendo un gestor de ventanas para la GP2X y un "escritorio", pero tendríamos a nuestras aplicaciones utilizando una librería gráfica que estaría delegando sobre xlib, la cual se comunicaría con el servidor X11 pasando por un par de niveles de la pila TCP/IP del kernel y finalmente el servidor X escribiendo en pantalla... un fregao [Ahhh]

Cuando en el mensaje anterior me referia al "servidor X", lo decía para que se entendiera. Se debe entender a ese servidor del que hablo como un programa que lo único que hará será gestionar el uso del framebuffer del dispisitivo, el sabrá que aplicaciones se estan ejecutando y cual quiere ver el usuario en ese momento, de forma que solo dejará a esa escribir en pantalla. Además de eso hará otras cosillas, como mostrar el menu, la barra de tareas, etc. (La idea para implementar esto a priori pasaría por hacer un wrapper de algunas funciones de SDL para que no vayan directamente al framebuffer, sino que se comuniquen con este "servidor", por ejemplo mediante memoria compartida)

En definitiva, el objetivo es terminar haciendo algo similar a qTopia pero con SDL y orientado a dispositivos como la GP2X, sin pantalla tactil, con pocas teclas y sin ratón.

qTopia tiene su propio gestor de ventanas que se encarga de gestionar el acceso al framebuffer, y que por supuesto es mucho más ligero que las X Windows (se usa incluso en móviles) y junto a eso proporciona un framework que se puede utilizar pa hacer aplicaciones para PDA, con sus widgets (botones, campos de texto, etc.), comunicacion entre procesos, teclado en pantalla integrado de forma transparente al programador...

Como digo ese sería el objetivo final, aunque lo hecho hasta ahora está lejisimos de eso :D

La idea me interesante desde el punto de vista de tener un mejor entorno gráfico en la GP2X e incluso potenciar el uso de SDL como sistema gráfico en otros dispositivos embebidos, además de que me parece divertida :D

Gracias BuD por poner el video, debería haberlo explicado arriba, pero como ya lleva un toco escrito y ademas no podía linkarlo...

La explicación viene siendo la que ha dicho BuD, se carga el "menu" (cutre donde los haya con 2 iconos que cargan 2 programs para probar), se elige el program a lanzar (el cual es una tontería que muestra un muñequito moviendose de un lado a otro), se ejecuta el programa y este se empieza a ejecutar mientras el menu sigue en segundo plano sin escribir en pantalla esperando a que se pulse la tecla START. Cuando se pulsa start, el menu lanza una señal de parada al proceso del "muñequito" y toma el control de la pantalla, se puede ver (mas bien intuir) que hay un contador de tiempo en el menu, y este ha avanzado. Luego pulsando otra tecla se despliega la barra de tareas para ver las aplicaciones en ejecución en 2º plano (ahora miso es tan cutre que solo se puede ver una :D) y si se elige la aplicación esta se despierta y recupera el control. Entonces se puede ver como el muñequito se empieza a mover donde lo había dejado antes :D

[Acerbaturix]

He estado esta tarde un ratillo con estas ideas otra vez, y tengo mas o menos lo mismo que el otro día, pero ahora ya con la posibilidad de mandar a aplicaciones a 2º plano y que estas se sigan ejecutando.

Os pongo otro video para que lo veais. Se arranca el entorno, arranco una aplicacion de ejemplo que reproduce un ficherillo wav continuamente, la mando a segundo plano y vuelvo al "escritorio". Lanzo otra aplicacion con un animación tonta, y el sonido se sigue ejecutando en 2º plano.


1C1rH_hjbg0

El sistemilla presenta varios inconvenientes.

El primero, es que, para que los programas que se quedan en background puedan seguir ejecutandose, estos deben ser ligeramente modificados. Basicamente el funcionamiento del programa debería tener 2 estados, y tener 2 manejadores de señales para modificar el estado. Este estado le indicaría a la aplicación si puede escribir en pantalla o no. Introducir esto en las aplicaciones a priori sería bastante sencillo, aunque habría que mirar de intentar hacerlo lo mas automatico posible.

La idea es que las aplicaciones, cuando se les indica que no pueden escribir en pantalla, decidan que hacer (esto si no me equivoco se hace ya mas o menos así en otros sitemas como Symbian o los MIDLET Java, por ejemplo para desactivar el audio de los juegos cuando te llaman por telefono, etc.). Los juegos, por ejemplo, no tiene mucho sentido que se sigan ejecutando, asique pueden ejecutar la llamada al sistema pause() para esperar a que llege la señal de reactivación, mientas que por ejemplo un reproductor de mp3 decidirá seguir ejecutandose, pero sin dibujar en pantalla.

El segundo inconveniente, es que si las aplicaciones que estan en segundo/primer plano simultaneamente tienen inicializado de manera diferente el framebuffer (diferente resolucion, diferente produndidad de color), es necesario andar reinicializando el framebufer cuando cambien de uno a otro, por que si no, no pueden escribir bien en pantalla, ya que las imagenes y demás estan optimizadas para una resolucion/color y se dibujan en otra.

Esto tb requiere de cierta colaboración por parte de los programadores para que las aplicaciones lo soporten...

Como veis, estas 2 cosas tienen el mayor inconveniente de requerir introducir código en los programas a ejecutar... pero, por suerte, en la implementación buena y definitiva con ese amago de servidor de ventanas del que hablo arriba, esto se podría arreglar de forma totalmente transparente ;).

Pero... queda un último problema. Lo mismo que pasa con la inicialización del video, pasa con el audio, pero claro, con el video, nunca va a haber mas de una apliaccion dibujando en pantalla, mientras que si puede (y debe) haber varias aplicaciones reproduciendo audio. El problema es que si el audio está inicializado por el reproductor de mp3 a estereo con una frecuencia de 44000, y llega un juego y lo cambia a mono con frecuencia de 22000, el audio del mp3 pasa a reproducirse con esa configuración (esto tb pasa ahora si utilizais madplay desde consola para reproducir música mientras haces otra cosa).

Este inconveniente del audio, por desgracia me parece que no tiene mucha solución... a ver si se me ocurre algo...

Pues nada, espero ideas, sugerencias, críticas... Unido a este sistemilla irá un entorno gráfico en plan menu, espero que bastante mejor que el GPH, que es cutre de cuidao [wei] , asique si teneis alguna idea al respecto para hacer un entorno mas usable, se aceptan sugerencias :D

[Zenzuke]

Uff, pues si requiere modificar los programas va a ser complicao. Aunque la idea es genial.

Ya se sabe que los programadores de la Scene son como los gatos, nunca se ponen de acuerdo para hacer algo todos juntos xDDDDDDDD (y que conste que lo digo con todo el respeto que se merecen)

[Acerbaturix]

Uff, pues si requiere modificar los programas va a ser complicao. Aunque la idea es genial.

Pues si, ese es el mayor problema y lo que más me echa para atrás de cara a seguir con esta funcionalidad. Imagino que al final lo que haré será que esten las 2 opciones, si ejecutas un programa que no soporta esto pues no puedes minimizar, o puedes minimizar pero parando el proceso. Y si usas uno que si lo soporta pues disfrutas de la experiencia completa [wei5] (el soportar esto no haría que dejase de funcionar con otros menus).

Relamente el código que habría que añadir a los programas sería pequeño, es poco mas que los {chdir(...) execl(...)} que hay que añadir ahora antes de salir del programa para ejecutar el menu de la GP2X (algo que en el sistemilla que estoy haciendo, ya no haría falta ejecutar).

Si finalmente hiciese esa versión con servidor de ventanas, la modificación en los programas sería menor, pero aun así, como muy mínimo requiriría recompilar los programas con una versión especial de las SDL... pero en el caso del servidor de ventanas hay otra cosa que me preocupa, y es el posible impacto en el rendimiento de las SDL :confused:


Ya se sabe que los programadores de la Scene son como los gatos, nunca se ponen de acuerdo para hacer algo todos juntos xDDDDDDDD (y que conste que lo digo con todo el respeto que se merecen)

Jejeje, normal, cada uno va a su arie y le gustan las cosas a su manera. Pasa igual en todo el mundillo opensource, al final acabamos haciendo 10 la misma cosa repetida, pero bueno, como lo hacemos por diversión, a cada uno nos gusta más nuestra manera de hacerlo [chuck2]