[Gvsig_english] Recent change for gvSIG 1.10 in SVN

César Martínez Izquierdo cesar.izq at gmail.com
Thu Jul 8 17:13:15 CEST 2010 

Hi Ben,

I strongly support this solution.

Regards,

César

2010/7/8 Benjamin Ducke <benjamin.ducke at oxfordarch.co.uk>:
> 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
>



-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   César Martínez Izquierdo
   GIS developer
   -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -  -
   ETC-LUSI: http://etc-lusi.eionet.europa.eu/
   Universitat Autònoma de Barcelona (SPAIN)
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

More information about the Gvsig_internacional mailing list