[Gvsig_english] Recent change for gvSIG 1.10 in SVN

Pablo Sanxiao psanxiao at cartolab.es
Thu Jul 8 17:24:04 CEST 2010 

Sounds good to me.

Cheers,

On Xov, 2010-07-08 at 16:03 +0100, Benjamin Ducke wrote:
> How about we introduce an environment variable (maybe GVSIG_CONFIG_DIR)
> which can be set by users to tell gvSIG where to find the base
> folder for storing config files? It seems to me that would be an easy
> way to do thing like reading config files from the application folder
> or a central server directory, if it is desired.
> 
> It could also easily be set from a startup script to neatly separate
> config files between different gvSIG versions.
> 
> E.g. to achieve what the Cartolab patch does you could put this
> into a startup batch file:
> 
>   set GVSIG_CONFIG_DIR="%CD%"
>   start gvSIG.exe
> 
> And it would take the pressure of us having to make a design decision
> about versioned config files before the release of 1.10.
> 
> For all those users who don't care: they simply get the same
> behavior as before.
> 
> If there are no objections to this, I will go ahead and make that
> change in Launcher.java  - it's really trivial.
> 
> Cheers,
> 
> Ben
> 
> 
> ----- Original Message -----
> > ----- Original Message -----
> > > Hi all,
> > >
> > > This change was really thinking for the gvSIG portable version where
> > > it makes a lot of sense to save the configurations in the
> > > application folder so that you can distribute a pre-configured gvSIG
> > > version ready
> > > to be used in courses, demos, etc.
> > 
> > Aah, I understand. Wasn't thinking of that (which just goes to show
> > that all these different use scenarios can be complex).
> > 
> > How about a fall-back mechanism for such cases? GvSIG could first
> > look for user settings in the home directory. And, if none are
> > found, look for default setting files within the application
> > directory. If those in turn are not found either, then it should just
> > do what
> > it has always done and attempt to create a set of default user
> > settings in the home directory.
> > 
> > >
> > > I agree with all the problems that this change could cause and you
> > > have commented but the old solution, although it is tested, it is
> > > not the good in my humbled opinion since, right know, gvSIG 1.9 is
> > > the last stable version, but many useful extensions are not adapted
> > > jet therefore many users need to have installed both versions, 1.1.2
> > > and 1.9 and
> > > cannot have different configurations for them it is really a
> > > problem.
> > 
> > Yes, that is a problem and one that needs to be addressed in 2.0 for
> > sure.
> > 
> > >
> > > Summarizing, I agree that the change should be reverted and the last
> > > solution proposal by Fran should be applied. To have a gvSIG version
> > > directory within the HOME directory could be a very good
> > > intermediate solution and could be applied in the 1.10 version since
> > > is a minor
> > > change.
> > >
> > 
> > Except that users won't know what hit them if they start 1.10 and all
> > their settings are reset to defaults.
> > 
> > Maybe a solution could be this:
> > 
> > On startup, look for settings folder gvSIG/<gvSIG-version>.
> > 
> > If it exists, then switch to that folder to manage the current
> > session's settings.
> > 
> > If "gvSIG" exists and contains settings files, but <gvSIG-version>
> > does not exist: copy the (old) user settings from gvSIG into
> > <gvSIG-version>, then use gvSIG/<gvSIG-version> for the current
> > session's settings.
> > 
> > That way, users will get their old settings when they first start.
> > 
> > But I still think that the whole mechanism is a little trickier than
> > it looks, because it's not just one or two xml settings files involved
> > here. E.g. the symbology extension manages library folders in "gvSIG",
> > there are raster color schemes to consider, andami settings, etc.
> > 
> > Also, how about installation scenarios where default settings are
> > deployed automatically (and intentionally overwrite older settings
> > in "gvSIG")? I have a setup here where this is the case and it saves
> > us a lot of time and nerves. If the settings behavior changes,
> > then this will all break with 1.10.
> > 
> > So I am a somewhat unwilling to consider this a minor change.
> > 
> > Best,
> > 
> > Ben
> > 
> > > Regards,
> > >
> > > On Xov, 2010-07-08 at 09:57 +0200, César Martínez Izquierdo wrote:
> > > > Hi,
> > > >
> > > > I agree with Ben, we should revert the change and devote some more
> > > > thinking on the topic before applying such a change. It is
> > > > problematic enough to be delayed for the next version.
> > > >
> > > > Regarding the implementation, probably you don't need to modify
> > > > the installer at all, everything could be done from gvSIG during
> > > > the start-up process.
> > > >
> > > > Regards,
> > > >
> > > > César
> > > >
> > > > 2010/7/8 Francisco José Peñarrubia <fpenarru at gmail.com>:
> > > > > Hi.
> > > > >
> > > > > This change comes from a patch to avoid conflicts between
> > > > > several installations of gvSIG, and some problems related to
> > > > > this conflicts in
> > > > > configuration. I think the solution of Cesar is better, and I
> > > > > will try to implement,
> > > > > but only partially. I will not touch the installation program,
> > > > > and we will create gvSIG/version directories.
> > > > > If the user wants to keep the old config and preferences, he
> > > > > must copy by himself the files.
> > > > >
> > > > > Ok with that?.
> > > > >
> > > > > Fran.
> > > > >
> > > > > César Martínez Izquierdo escribió:
> > > > >> Hi Ben,
> > > > >>
> > > > >> It seems that commit matches the following ticket:
> > > > >> http://forge.osor.eu/tracker/?func=detail&atid=732&aid=14411&group_id=89
> > > > >>
> > > > >> I think the idea was allowing different configurations for
> > > > >> different gvSIG installations.
> > > > >> However, I agree with you that it is not as good ideas as it
> > > > >> may seem at a first glance, and I suggest to better analyze all
> > > > >> the possible behaviours to select the desired one.
> > > > >>
> > > > >> Besides the multi-user problem that you point at, I see other
> > > > >> possible problems:
> > > > >> - If I install a new gvSIG version, should I set all my
> > > > >> configuration again? This looks as a regression to me.
> > > > >> - What happens if the user has no write permissions on the
> > > > >> gvSIG installation folder?
> > > > >>
> > > > >> I think it is ALWAYS a good practice to keep program
> > > > >> configurations on
> > > > >> the user home, and program installation on a different one, and
> > > > >> don't mix them up.
> > > > >>
> > > > >> I guess that the intention of this change was to be able to
> > > > >> execute 2
> > > > >> different gvSIG versions which may have conflicting
> > > > >> configuration files (because changes on code, etc). If this is
> > > > >> the case, I
> > > > >> would
> > > > >> suggest a different approach:
> > > > >> - Keep config in home.dir folder, under a versioned folder (for
> > > > >> example, ${HOME}/gvSIG/1.1 or ${HOME}/gvSIG/1.9).
> > > > >> - Whenever you install a newer version, copy the last version
> > > > >> configuration to the new dir. For example, if you new install
> > > > >> 1.10, copy config from ${HOME}/gvSIG/1.9 to ${HOME}/gvSIG/1.10
> > > > >> and update
> > > > >> any conflicting files on 1.10 folder.
> > > > >> - In this way, the user would find the old configuration in the
> > > > >> new versions, but version conflicts are avoided (so he would
> > > > >> still be able
> > > > >> to run 1.9 if desired)
> > > > >> - Drawbacks: configuration changes applied on 1.9 version
> > > > >> wouldn't apply to 1.10 version and vice versa. But this is
> > > > >> better than having
> > > > >> version conflicts, I think. Of course it could be solved with
> > > > >> smarter approaches, but for sure they would be more complex and
> > > > >> I don't think
> > > > >> there are resources available for this now.
> > > > >>
> > > > >> I have written all this off the top of my head, but I think
> > > > >> this topic should be carefully thinking, as it may create lots
> > > > >> of problems otherwise.
> > > > >>
> > > > >> Best regards,
> > > > >>
> > > > >> César
> > > > >>
> > > > >>
> > > > >> 2010/7/7 Benjamin Ducke <benjamin.ducke at oxfordarch.co.uk>:
> > > > >>
> > > > >>> Hi all,
> > > > >>>
> > > > >>> I have just had a look at the recent changes in SVN and found
> > > > >>> that the default location for gvSIG settings has been changed
> > > > >>> from $HOME/gvSIG:
> > > > >>>
> > > > >>> Launcher.java now has this:
> > > > >>>
> > > > >>>  andamiConfigPath = System.getProperty("user.dir") +
> > > > >>>  File.separator + "andami-config.xml";
> > > > >>>  pluginsPersistencePath = System.getProperty("user.dir") +
> > > > >>>  File.separator + "plugins-persistence.xml";
> > > > >>>
> > > > >>> Are you all sure this is a good idea? According to the Java
> > > > >>> documentation, "user.dir" is the "current working directory".
> > > > >>>
> > > > >>> But:
> > > > >>>
> > > > >>> 1. If the user launches gvSIG from a shell, then "user.dir"
> > > > >>> could be literally ANY location in the filesystem. So settings
> > > > >>> are bound
> > > > >>> to get lost between sessions or (even worse) they get restored
> > > > >>> from unexpected old storage locations.
> > > > >>>
> > > > >>> 2. If the user launches gvSIG via a desktop shortcut or a Mac
> > > > >>> OS App package, then "user.dir" will always point to the gvSIG
> > > > >>> installation folder. On a system set up for multiple users,
> > > > >>> with just one gvSIG
> > > > >>> installation folder, this can mean total chaos, as users
> > > > >>> overwrite each
> > > > >>> other's settings.
> > > > >>>
> > > > >>> All of that makes me a bit worried!
> > > > >>> Could someone please explain the reasoning behind this change
> > > > >>> and how it is supposed to work?
> > > > >>>
> > > > >>> I think the ONLY reasonable place for user settings has to be
> > > > >>> the user's home folder. If it is required to keep more than
> > > > >>> one set of settings, then those sets should all be kept in the
> > > > >>> home folder, perhaps in separate directories.
> > > > >>>
> > > > >>> Cheers,
> > > > >>>
> > > > >>> Ben
> > > > >>>
> > > > >>>
> > > > >>> ------ Files attached to this email may be in ISO 26300 format
> > > > >>> (OASIS Open Document Format). If you have difficulty opening
> > > > >>> them, please visit http://iso26300.info for more information.
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> Gvsig_internacional mailing list
> > > > >>> Gvsig_internacional at listserv.gva.es
> > > > >>> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >
> > > > > -- Fran Peñarrubia
> > > > > Scolab www.scolab.es
> > > > >
> > > > > Asociación gvSIG
> > > > > www.gvsig.com
> > > > >
> > > > > _______________________________________________
> > > > > Gvsig_internacional mailing list
> > > > > Gvsig_internacional at listserv.gva.es
> > > > > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
> > > > >
> > > >
> > > >
> > > >
> > >
> > > -- Pablo Sanxiao Roca
> > > Grupo de Desarrollo
> > > Cartolab - Laboratorio de Ingeniería Cartográfica
> > > http://www.cartolab.es
> > >
> > > ETS Ingeniería de Caminos, Canales y Puertos
> > > Universidade da Coruña
> > > Campus de Elviña - 15071 A Coruña (España)
> > > (34)981167000 ext. 5493
> > >
> > > _______________________________________________ Gvsig_internacional
> > > mailing list
> > > Gvsig_internacional at listserv.gva.es
> > > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
> > 
> > 
> > ------ Files attached to this email may be in ISO 26300 format (OASIS
> > Open Document Format). If you have difficulty opening them, please
> > visit http://iso26300.info for more information.
> > 
> > _______________________________________________ Gvsig_internacional
> > mailing list
> > Gvsig_internacional at listserv.gva.es
> > http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional
> 
> 
> ------
> Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.
> 
> _______________________________________________
> Gvsig_internacional mailing list
> Gvsig_internacional at listserv.gva.es
> http://listserv.gva.es/cgi-bin/mailman/listinfo/gvsig_internacional

-- 
Pablo Sanxiao Roca
Grupo de Desarrollo
Cartolab - Laboratorio de Ingeniería Cartográfica
http://www.cartolab.es

ETS Ingeniería de Caminos, Canales y Puertos
Universidade da Coruña
Campus de Elviña - 15071 A Coruña (España)
(34)981167000 ext. 5493

More information about the Gvsig_internacional mailing list