[Gvsig_english] Recent change for gvSIG 1.10 in SVN

Benjamin Ducke benjamin.ducke at oxfordarch.co.uk
Thu Jul 8 11:23:18 CEST 2010 

----- 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.

More information about the Gvsig_internacional mailing list