[Gvsig_english] Recent change for gvSIG 1.10 in SVN

Benjamin Ducke benjamin.ducke at oxfordarch.co.uk
Thu Jul 8 17:03:20 CEST 2010 

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.

More information about the Gvsig_internacional mailing list