Application: gvSIG desktop

Aparte del problema inmediato que es que gvSIG no arranque, seguramente hay otro problema de fondo: parece que se intenta crear un directorio al arrancar gvSIG, dentro de la carpeta de instalación de gvSIG. Al no tener permisos suficientes en ese momento, lo normal es que falle.

Hi Cesar, this issue looks like #2274 and in part #2678. There are some SEXTANTE subfolders which need to be created the first time gvSIG is executed. If you execute gvSIG as administrator it doesn't happen anymore. Adding these subfolders in the org.gvsig.geoprocess.app.mainplugin plugin should prevent this issue.

Yes, the cause is probably the same pointed in your bugs.
However, the consequence is a major problem, as most users will think that gvSIG won't start on their system.

Some extra notes about this problem:
- The warnings happen even if gvSIG was initially installed as Administrator
- The problem with gvSIG getting blocked only happens if the user changes to another window (to any other open program) after clicking on gvSIG icon, so it will only hit to impatient users (like me) who use to change to other task while gvSIG starts...

¿Este bug os sigue sucediendo?

Ahora no tengo un Windows 7 a mano para probarlo, la semana que viene lo compruebo.
La clave para reproducir el bug era que cambiásemos de ventana antes de que apareciesen los warnings.

¿lo has probado?

Lo he podido reproducir con la 2.1 final. Hay varias cosas a tener en cuenta para reproducirlo:
- Primeramente hay que ejecutar un build más antiguo de la 2.1 (yo he probado con el 2222)
- Al final del proceso de instalación de la 2.1 final, en el momento en que se está cargando gvSIG hay que cambiar a otra ventana cualquier (que no sea de gvSIG). Esto provoca que los diálogos de error se queden ocultos tras el resto de ventanas, bloqueando la ejecución de gvSIG e invisibles para el usuario (ni siquiera aparece una entrada en la barra de tareas de Windows 7).

Para entender un poco mejor lo que esta pasando:
- creo que en algún momento durante el desarrollo de la 2.1 se ha cambiado la persistencia de algunos plugins. Esto provoca que al ejecutar dos builds muy diferentes aparezcan este tipo de mensajes de error (tipo "No se han podido leer datos almacenados del plugin: org.gvsig.geodb.app.mainplugin Quiza los datos almacenados se refieren a un plugin no presente")
- estos errores no son en sí mismo problemáticos, pero sí que es problemático que se muestren al usuario antes de que la ventana de gvSIG esté creada, ya que si el splash de gvSIG pierde el foco (cambiando a otra ventana de Windows) antes de que se creen los diálogos de error, estos quedarán ocultos detrás de las otras ventanas de Windows, invisibles para el usuario
- un 'workaround' simple es no cambiar de ventana durante la primera ejecución de gvSIG

En conclusión, creo que es un error que debe afectar a un número reducido de usuarios (que previamente instalaron builds en desarrollo) y con un workaround sencillo, pero aun así es grave porque es muy desconcertante para el usuario que ve que gvSIG aparentemente no arranca y que no tiene ninguna pista para ver qué está pasando (creo que algún usuario ha descrito en las listas un comportamiento así).

Según entiendo borrarlos no arreglará el problema, el problema está en la carpeta de preferencias de usuario.

Pensando en el futuro (porque puede volver a pasar con la 2.2 si se vuelven a hacer cambios similares), creo que la solución más sencilla sería que esos mensajes se muestren una vez creada la ventana principal de gvSIG. Con esto no quedarían ocultos y el problema desaparecería.

Cesar Martinez Izquierdo wrote:

Pensando en el futuro (porque puede volver a pasar con la 2.2 si se vuelven a hacer cambios similares), creo que la solución más sencilla sería que esos mensajes se muestren una vez creada la ventana principal de gvSIG. Con esto no quedarían ocultos y el problema desaparecería.

Si es eso parece que puede solucionar el problema es relativamente simple de hacer.
Entiendo que estamos hablando de los mensajes que se muestran por problemas en la compatibilidad de los ficheros de persisencia de los plugins. Estos se muetran en el metodo getPluginProperties de PluginServices, basaria con que en lugar de mostrarse directamente se encolase la presentacion del mensaje llamando a "pluginManger.addStartupTask".

Podria ser algo tan simple como:

    private void showMessageDialogDelayed(final String msg, final String title, final int type) {
        PluginsManager pluginManger = PluginsLocator.getManager();
        pluginManger.addStartupTask("Persistence_"+getPluginName(), new Runnable() {
           public void run() {
                JOptionPane.showMessageDialog(
                                (Component) PluginServices.getMainFrame(),
                                msg,
                                title,
                                type);
                    }
        }, true, 100);
    }

Y llamar a esta funcion en lugar de a "JOptionPane.showMessageDialog" directamente.

Eso si, si hubiesen otros dialogos que dejen bloqueado el arranque de a aplicacion esto no lo soluciona.

Otra opcion que tambien se podria probar es que en el launcher, cuando se cree el Frame del splash, que ahora se esta guardando en una variable local "f", guardar la instancia en la variable static del launcher "frame", que es accesible a trabes del metodo "getFrame" y es lo que se suele usar para poner como componene padre de los dialogos al llamar a JOptionPane. Mas tarde cuando se crea la ventana de gvSIG se machaca el valor de "frame" con el del MDI.

Asi supongo que todos los dialogos que estan tirando de "PluginServices.getMainFrame()" se mostrarian siempre encima del splash, en lugar de estar desvinculados de el ya que ahora el valor de "PluginServices.getMainFrame()" en esos momentos es null. El problema que le veo a esto es que como alguien espero null o el MDI y al ver que no es null se le ocurra hacer un casting antes de que se haya creado el MDIFrame cascaria (no creo que en ese punto nadie lo haga pero podria haber alguno).

Lo de usar el splash como ventana padre no sé si funcionaría, ya que es un JWindow y por tanto no sale en la barra de tareas. Se podría probar.

Lo del delayed message parece buena idea. Como dices si hay mensajes provinientes de otra parte tendríamos el mismo problema, pero podemos ir controlando que todos los mensajes al inicio usen este mecanismo.