Difference between revisions of "Documentation:ToDo"
From The BABEL Development Site
(→ToDo) |
(→ToDo) |
||
Line 12: | Line 12: | ||
* En EM / Modulos: que el -RemoteMandatory se pueda configurar dentro del modulo en si, o al menos que tenga un valor x defecto si no hay parametro en linea de comando. | * En EM / Modulos: que el -RemoteMandatory se pueda configurar dentro del modulo en si, o al menos que tenga un valor x defecto si no hay parametro en linea de comando. | ||
+ | |||
+ | |||
+ | * Programa Visual_RPD_Editor: | ||
+ | ** Cambiar nombre, | ||
+ | ** Hacer generico para RPDs y "apps-configs?". | ||
+ | ** Meter en BABEL/CMake y Execution Directory?? | ||
Revision as of 20:17, 28 May 2009
ToDo
- ESTADO DEL CAMBIO: nonportables y CMake
Como sacar fuera mrpt opencv (Ya incluye: Añadir nombre IDL mientras compila )Hecho en parte. Queda ver metodo mas generico de incluir librerias aparte de OpenCV / MRPT.
- ESTADO DEL CAMBIO: Nuevos tipos de datos
- Meter en babel.idl algunos tipos de datos genéricos que puedan ser de utilidad, añadiendo su documentación a la wiki de BDL
- En EM / Modulos: que el -RemoteMandatory se pueda configurar dentro del modulo en si, o al menos que tenga un valor x defecto si no hay parametro en linea de comando.
- Programa Visual_RPD_Editor:
- Cambiar nombre,
- Hacer generico para RPDs y "apps-configs?".
- Meter en BABEL/CMake y Execution Directory??
- Permitir uso de tipos de otros módulos en los parámetros BDL de un servicio de un módulo dado
- El usuario lo introduciría como BABEL::<modulodefinitorio>::tipo
- Se metería como dependencia de módulo (sin servicio) en la lista de dependencias
- Cosas que faltan:
- Incluir en Endymion, en el idl del cliente, después del include babel.idl, el idl del servidor de tipos. Usar los preceptivos #ifdef para evitar inclusiones múltiples
- Tratar a las dependencias diferentemente si son de servicio que si son de módulo: si sólo son de módulo (y no hay ninguna que sea de un servicio de ese módulo), meterlas en el idl pero no crear objetos ni buscarlos en el servidor de nombres. En cualquier otro caso (lo cual incluye por ejemplo, las actuales dependencias de módulo que se necesitan para definir los manejadores de eventos), crear objetos remotos y buscarlos en el servidor de nombres.
- En el MD, al añadir una Dep. pregunta si se quiere añadir solo un servicio o todo el modulo. Avisar de las consecuencias en ese aviso al usuario...
- Montar un repositorio de módulos teniendo en cuenta sus dependencias y versiones
- Cambiar la gestión de cadenas de texto como tipo de datos mapeado de BDL a C++. Quizas, cambiar tb los sequences a std::vector<T> para que sea igual que en otros generadores futuros, ademas de evitar que el usuario tenga que hacer el "new Sequence" como ahora...
- Todos estos cambios tienen la mala parte de que en el gen. de ACETAO, podriamos apañar todos los tipos de datos complejos, pero cuando esten dentro de estructuras ya seria demasiado...
- De todas formas, ahora mismo YA hay que tratar los tipos de forma distinta si estan dentro de structs que cuando no lo estan, asi que quizas no es tan grave
- Añadir una aracne atom que dé información (nombre) del módulo
- Abordar genericidad (H)
- Abordar repetición de módulos (H)
- Generador para Player/Stage
- Docs sobre componentes del babel system
- Añadir flag a babel_generator.exe para saltarse el esperar tecla al final...